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)

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

Example: Weak Entity Types

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)

(empid, ename, job, salary) EMPLOYEE (1, 1) (0, N) EMPDEP

(name, gender, bday) (1, 1) DEPENDENT (0, N)

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

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)