DBMS entity-relationship (E-R) data model | Relational Model | Data Model

entity-relationship (E-R) data model

entity-relationship data model
introduced by Peter Chen in March 1976 high-level, conceptual, semantic data model based on a perception of a real world that consists of a set of basic objects called entities, and of relationships among these objects used to depict the overall structure of a database in a graphical form known as an E-R diagram

entity-relationship data model
basic building blocks: entity a “thing” or object in the real world that is distinguishable from all other objects may have physical existence (e.g., employee, student) or be conceptual (e.g., a job, a college course) in nature has particular properties, a.k.a. attributes, that describe it (e.g., employee name, salary, student ID number) entity type/set: a set of entities that share the same attributes; individual entities are called entity instances

entity-relationship data model
basic building blocks: relationship an “association” among several (not necessarily distinct) entities (e.g., an employee works for a department, a student is enrolled in a course) may also have attributes (e.g., job designation of employee for specific departments, enrollment date of student for a given subject) relationship type/set: a set of relationship instances that have the same characteristics

Example: E-R Diagram
(empid, ename, job, hiredate, address, bday, age) EMP (1, 1) supervisee (0, N) supervisor PROJHEAD (0, 1) (1, 1) PROJDEPT (0, N) (date, hourlyrate) EMPPROJ (1, N) (projid, projname, status) PROJECT

entity types/sets
collection of entity instances of a particular entity type, characterized by a common set of attributes types of attributes: simple vs. composite single-valued vs. multi-valued stored (or, base) vs. derived key attributes: attributes whose values are distinct for each individual entity instance (establishes a uniqueness constraint on entities) a simple attribute is associated with a domain or value set, specifying the valid values for the attribute composite multi-valued attributes may be nested (a.k.a. complex attributes)

(1, 1)

SUPERVISION

(0, N)

NOTE: EMP.ename (lastname, firstname, middlename) -> composite {EMP.address} -> multi-valued: up to two addresses per employee EMP.age -> derived: current date - EMP.bday (in years)

DEPT (deptid, dname)

1

relationship types/sets
a relationship type, R, among entity types E1, E2,… En defines a set of association among entities from these types (referred to as the participating entity types); each relationship instance in R represents an association which includes exactly one entity instance from each participating entity type a relationship type is characterized by its degree and its structural constraints; furthermore, a relationship type may also have attributes one or more entity types may be associated via one or more distinct relationship types

relationship types/sets
degree of a relationship type: number of entity types associated by the relationship may be one of unary (a.k.a. recursive relationships), binary, ternary, … n-ary

Structural Constraints

relationship types/sets
structural constraints on a relationship type: cardinality ratio or mapping cardinality indicates the number of relationship instances that an entity instance may participate in for binary relationships, the common mapping cardinalities are 1:1 (one-to-one), 1:N (one-tomany), or M:N (many-to-many) participation constraint indicates whether the existence of an entity instance depends on its being related to another entity instance via the relationship may be total (or obligatory) or partial (or optional)

optional

M:N

obligatory

(0,N) EMP EMPPROJ

(1,N) PROJECT

Structural Constraints
optional 1:1 obligatory

weak entity types/sets
weak entity types do not have key attributes of their own (as compared to strong or regular entity types, which do) weak entity instances are identified by being related (through an identifying relationship), to instances of another entity type (called the identifying or owner entity type) weak entity types always have obligatory participation constraints with respect to their identifying relationships (i.e., weak entities are existence-dependent on their owner entities) weak entity types normally have a partial key, which is the set of attributes that can uniquely identify weak entity instances that are related to the same owner entity instance

(0,1) EMP PROJHEAD

(1,1) PROJECT

2

Example: Weak Entity Types
(empid, ename, job, salary) EMPLOYEE (1, 1) (0, N) EMPDEP (name, gender, bday) (1, 1) DEPENDENT (0, N)

weak entity types/sets
weak entity types are a.k.a. subordinate entity types or child entity types identifying entity types are a.k.a. dominant or parent entity types weak entity types may participate in other relationship types aside from their identifying relationships in general, any number of levels of weak entity types may be defined, and weak entity types may have more than one owner entity and/or participate in identifying relationships with degree higher than two weak entity types can be represented as complex (composite, multi-valued) attributes (and vice-versa)

HAS

DB

(1, 1) EMPINFO (address, bday, gender, telno, degree, citizenship, religion)

(1, 1) BENEFIT (expid, date, desc, amt)

Example: Complex Attribute as Weak Entity Type
(custid, compname, address, continfo, creditlimit) CUSTOMER (custid, compname, address, creditlimit) CUSTOMER (1, 3) NOTE: {CUSTOMER.continfo(contname, telno)} -> up to 3 contact persons CUSTINFO

specialization/generalization
specialization process of defining a set of subclasses of an entity type; the entity type from which the subclasses are derived is the superclass of the specialization; superclass and subclass entities are also called generalized and specialized entities, respectively generalization the reverse process of abstraction, in which the differences of several entity types are suppressed to identify their common features

(1, 1) CONTINFO (contid, contname, telno)

specialization/generalization
specialization typically used to denote that: certain attributes (a.k.a. specific or specialized or local attributes) of the superclass may apply to some, but not all, of the superclass instances; the common (a.k.a. generalized) attributes are depicted on the superclass some relationship types may be participated in only by instances that are members of specific subclasses

specialization/generalization
characteristics of specialization/generalization subclass membership: entity instances of the superclass that are members of a given subclass are identified through defining attributes or defining predicates disjointness constraint: indicates whether the subclasses of the specialization are disjoint or overlapping completeness constraint: specifies whether or not every instance in the superclass is a member of some subclass in the specialization; may be total or partial in general, specialization/generalization may have several levels

3

Example: Total Disjoint Specialization
(empid, ename, etype, job) EMPLOYEE etype d =“A” (honorarium, trvlallowance) ADMIN =“R” (hourlyrate, vaclv, scklv) RANK&FILE (0, N) (tcardno, month, yr, totalhrs) HAS TIMECARD

Example: Partial Overlapping Specialization
(payno, paydate, cashamt, chk, ccard, gchk, totalamt) PAYMENT

o chk = “Y” gchk = “Y” CHECK (chkno, bank, chkdate, amt) CCARD (ccardno, cctype, ccinst, approvalno, amt) ccard = “Y”

GIFTCHECK (gchkno, expdate, amt)

(1, 1)

relational data model

database systems
relational data model

first proposed by Edgar Frank Codd in 1970 in the paper entitled “A Relational Model of Data for Large Shared Data Banks” implementation data model that represents data based on the mathematical notion of a relation models data as a set of relations that represent data entities and provides mechanisms for depicting the relationships that exist among these data entities serves as the theoretical foundation of most modernday commercial dbms software (relational dbms) concerned with three aspects of data: structure, integrity and operators

relational data model: structure
relation (table) stores information about a logical data entity basic data storage structure used in relational database systems
CUSTOMERS custid 184 207 285 320 custname Erap Estrada Cory Aquino Eddie Ramos address San Juan Tarlac Pangasinan

relational data model: structure
attribute (column, field) single logical characteristic of the data entity being modeled by the relation each attribute is defined on a domain (data type), which is the set of all legal values from which attribute values can be taken tuple (row, record) stores information about an individual instance of the data entity being modeled by the relation

Ferdie Marcos Ilocos Norte

4

relational data model: structure
heading attribute set of the relation the degree or arity of a relation represents the number of attributes body set of tuples contained in the relation the cardinality of a relation represents the number of tuples

relational data model: structure
properties of a relation there are no duplicate tuples: the combination of attribute values for each tuple must be unique tuples are unordered: the order in which the tuples occur is not important attributes are unordered: the order of attributes is not important as long as the correspondence between attributes and their values is maintained domain values are atomic: each value stored in an attribute of any given tuple contains exactly one logical value (normalized)

Example: Relational Database

relational data model: structure
other characteristics of a relation basic relational theory is based on the first normal form assumption, hence: multivalued attributes are stored in separate relations composite attributes are represented by their simple component attributes null values or nulls are used to represent attribute values that may be unknown or may not apply to a tuple

CUSTOMERS custid 184 207 285 320 LOANS loanno 78-2007 79-2007 01-2008 PAYMENTS orno paydate payamt loanno 1085683 Nov-10-2007 P 5,000.00 78-2007 1087645 Jan-04-2008 P 1,250.00 79-2007 loandate Oct-08-2007 Dec-04-2007 Jan-10-2008 loanamt P 25,000.00 P 10,000.00 P 75,000.00 duedate Oct-08-2008 Jun-03-2008 Apr-10-2008 interest P 2,500.00 P 1,250.00 P 7,500.00 custid 184 207 184 custname Erap Estrada Cory Aquino Eddie Ramos Ferdie Marcos address San Juan Tarlac Pangasinan Ilocos Norte

relational data model: integrity
integrity constraints: set of rules that ensure the correctness of the data contained in the relational database database-specific integrity constraints based on business rules that govern the semantics of the applications for which the database was designed varies from one database to another database-independent integrity constraints applies to all relational databases, regardless of the semantics of the applications involves candidate keys and foreign keys

integrity of single relations
entity integrity every tuple in a relation must be distinct; for this purpose, non-null keys (a subset of the relation’s heading) are defined on a relation superkey: possesses the uniqueness property candidate key: possesses the uniqueness and the irreducibility properties; minimal superkey; main tuple-level addressing mechanism primary key: candidate key chosen as the main means of identifying a tuple in the relation alternate key: any candidate key not chosen as the primary key

5

integrity of single relations
entity integrity keys may be simple or composite entity integrity rule for any relation, there can be no duplicate tuples and that no candidate key values can be null entity integrity can be enforced by mechanisms provided by the dbms; operations (insert or update) that create a duplicate candidate key or one containing nulls are rejected constraints on null values specifies whether or not null values are allowed for the attributes in a relation

integrity of single relations
relational database scheme example 1 CUSTOMERS(custid, custname, address) LOANS(loanno, loandate, loanamt, duedate, interest, custid) PAYMENTS(orno, paydate, payamt, loanno) example 2 DEPT(deptno, dname, location) AK dname EMP(empid, ename, job, deptno, sal, mgrid)

integrity among relations
referential integrity associations among relations must be depicted with (ideally) the minimum amount of data redundancy; foreign keys serve this purpose foreign key a subset of the attribute set of a relation R1 such that its values are required to match the values of some candidate key in a relation R2 (R1 and R2 are not necessarily distinct), or is null. the foreign key in R1 is said to reference or refer to R2.

integrity among relations
referential integrity foreign keys may also be simple or composite referencing and referenced relations the referencing relation represents the relation containing the foreign key the referenced relation represents the relations containing the primary key being referenced a self-referencing relation represents a relation containing a foreign key that references the same relation’s primary key

Example: Foreign Key Notation and Referential Integrity

integrity among relations
referential integrity referencing and referenced tuples the referencing tuple contains the foreign key value that represents a reference to the tuple containing the matching primary key value (the referenced tuple) a referenced tuple may have many referencing tuples associated with it not all tuples in the referenced relation are referenced tuples foreign key attributes are not required to have the same name as the primary key attributes being referenced; they should, however, be defined on the same domain

Relational Database Scheme CUSTOMERS(custid, custname, address) LOANS(loanno, loandate, loanamt, duedate, interest, custid) FK custid References CUSTOMERS Nulls Not Allowed CUSTOMERS custid 184 207 285 320 LOANS loanno 78-2007 79-2007 01-2008 loandate Oct-08-2007 Dec-04-2007 Jan-10-2008 loanamt P 25,000.00 P 10,000.00 P 75,000.00 duedate Oct-08-2008 Jun-03-2008 Apr-10-2008 interest P 2,500.00 P 1,250.00 P 7,500.00 custid 184 207 184 custname Erap Estrada Cory Aquino Eddie Ramos Ferdie Marcos address San Juan Tarlac Pangasinan Ilocos Norte

6

Example: Self-referencing Relation
Relational Database Scheme DEPT(deptno, dname, location) AK dname EMP(empid, name, job, deptno, sal, mgrid) FK deptno References DEPT Nulls Allowed mgrid References EMP Nulls Allowed DEPT deptno 10 20 30 EMP empid 7200 7405 7560 7632 7720 name George Bush Bill Clinton Hilary Clinton Al Gore job Manager Programmer President Programmer 20 10 deptno 10 20 sal P45,000.00 P30,000.00 P95,000.00 P25,000.00 P75,000.00 7720 7200 mgrid 7560 7720 dname Sales Accounting Purchasing location Cebu Manila Manila

integrity among relations
referential integrity referential integrity rule for all time, the relational database must not contain any unmatched foreign key value referential integrity may be violated when tuples are inserted, deleted, or updated; can be enforced by the dbms automatically or via application code foreign key rules ensure that referential integrity is imposed during delete and update operations Cascade Restrict Nullify

Fred Thompson Analyst

integrity among relations
relational database scheme CUSTOMERS(custid, custname, address) LOANS(loanno, loandate, loanamt, duedate, interest, custid) FK custid References CUSTOMERS Nulls Not Allowed Delete Restrict, Update Cascade PAYMENTS(orno, paydate, payamt, loanno) FK loanno References LOANS Nulls Not Allowed Delete Cascade, Update Restrict

integrity among relations
relational database scheme DEPT(deptno, dname, location) AK dname EMP(empid, name, job, deptno, sal, mgrid) FK deptno References DEPT Nulls Allowed Delete Nullify, Update Cascade mgrid References EMP Nulls Allowed Delete Restrict, Update Cascade

scenario

database systems
transformation from the entity-relationship model to the relational data model

Personnel in the Baguio Livelihood and Cooperative, Inc. (BLAC INC) are organized into departments. A department must have at least two employees belonging to it. Every department must have a head. Although an employee works for a single department, he or she may be assigned to be the head of at most three departments, regardless of what department the employee belongs to. A corresponding honorarium, which may vary for each department, is given to the head in addition to the basic salary. The assignment of department heads is done on rotation basis, hence, the dates when such positions are assigned to an employee are monitored. BLAC INC is a large complex composed of many buildings, and each department may have offices in any of these buildings. Specific rooms are provided for the use of each department. A department may use many rooms but cannot share rooms with other departments. To facilitate communication, telephones are installed in every room. Design a simple locator database that can keep information about the company’s organizational and physical set-up.

7

E-R diagram: BLAC INC
(deptid, dname) DEPT DEPTRM (roomno, telno) ROOM

relational database scheme
DEPT( deptid, dname, head, assigndate, honorarium ) AK dname FK head Ref EMP Nulls Not Allowed, Delete Restrict, Update Cascade EMP( empid, ename, hiredate, address, bday, deptid ) FK deptid Ref DEPT Nulls Not Allowed, Delete Restrict, Update Cascade BLDG( bldgid, bldgname, location ) AK bldgname ROOM( roomno, telno, deptid, bldgid ) FK deptid Ref DEPT Nulls Allowed Delete Nullify, Update Cascade bldgid Ref BLDG Nulls Not Allowed, Delete Cascade, Update Cascade

(1, N) (1, 1)

(0, 1)

(2, N)

(1, 1)

DEPTEMP

(assigndate, DEPTHEAD honorarium)

RMBLDG

(1, 1)

(0, 3)

(1, N)

EMP (empid, ename, hiredate, address, bday, age)

BLDG (bldgid, bldgname, location)

relational database scheme
DEPT( deptid, dname, head, assigndate, honorarium ) AK dname FK head Ref EMP Nulls Not Allowed, Delete Restrict, Update Cascade EMP( empid, ename, hiredate, address, bday, deptid ) FK deptid Ref DEPT Nulls Not Allowed, Delete Restrict, Update Cascade BLDG( bldgid, bldgname, location ) AK bldgname ROOM( roomno, telno, bldgid ) FK bldgid Ref BLDG Nulls Not Allowed, Delete Cascade, Update Cascade DEPTRM( roomno, deptid ) FK roomno Ref ROOM Nulls Not Allowed, Delete Restrict, Update Cascade deptid Ref DEPT Nulls Not Allowed, Delete Cascade, Update Cascade

8

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.