entity-relationship (E-R) entity-relationship data model

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 entity-relationship data model

† basic building blocks: † basic building blocks:
„ entity „ relationship
† a “thing” or object in the real world that is † an “association” among several (not necessarily
distinguishable from all other objects distinct) entities (e.g., an employee works for a
† may have physical existence (e.g., employee, department, a student is enrolled in a course)
student) or be conceptual (e.g., a job, a college
course) in nature † may also have attributes (e.g., job designation
† has particular properties, a.k.a. attributes, that of employee for specific departments, enrollment
describe it (e.g., employee name, salary, student date of student for a given subject)
ID number) † relationship type/set: a set of relationship
† entity type/set: a set of entities that share the instances that have the same characteristics
same attributes; individual entities are called
entity instances

Example: E-R Diagram

(empid, ename, job, hiredate, (date, hourlyrate)
address, bday, age) (projid, projname, status)
entity types/sets
EMPPROJ
EMP PROJECT
(0, N) (1, N) † collection of entity instances of a particular entity type,
(1, 1) (0, N) characterized by a common set of attributes
(1, 1) † types of attributes:
PROJHEAD „ simple vs. composite
supervisor
supervisee

(0, 1) (1, 1)
PROJDEPT
„ 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
SUPERVISION
(0, N) constraint on entities)
† a simple attribute is associated with a domain or value
set, specifying the valid values for the attribute
NOTE: DEPT
EMP.ename (lastname, firstname, middlename) -> composite † composite multi-valued attributes may be nested (a.k.a.
{EMP.address} -> multi-valued: up to two addresses per
(deptid, dname)
complex attributes)
employee
EMP.age -> derived: current date - EMP.bday (in years)

1
 relationship types/sets relationship types/sets
† a relationship type, R, among entity types E1, E2,… En † degree of a relationship type:
defines a set of association among entities from these „ number of entity types associated by the relationship
types (referred to as the participating entity types); „ may be one of unary (a.k.a. recursive relationships),
each relationship instance in R represents an association binary, ternary, … n-ary
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

Structural Constraints

relationship types/sets optional M:N obligatory

† 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-to-
many), or M:N (many-to-many)
„ participation constraint
† indicates whether the existence of an entity (0,N) (1,N)
instance depends on its being related to another
entity instance via the relationship
EMP EMPPROJ PROJECT
† may be total (or obligatory) or partial (or optional)

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
(0,1) (1,1) owner entities)
† weak entity types normally have a partial key, which
is the set of attributes that can uniquely identify weak
EMP PROJHEAD PROJECT entity instances that are related to the same owner
entity instance

2
Example: Weak Entity Types

(empid, ename, job, salary)

(0, N)
(name, gender, bday)
(1, 1)
weak entity types/sets
EMPLOYEE EMPDEP DEPENDENT
† weak entity types are a.k.a. subordinate entity types or
(1, 1) (0, N) child entity types
† identifying entity types are a.k.a. dominant or parent
entity types
† weak entity types may participate in other relationship
HAS DB 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
(1, 1) (1, 1) relationships with degree higher than two
† weak entity types can be represented as complex
EMPINFO BENEFIT (composite, multi-valued) attributes (and vice-versa)
(address, bday, gender, telno, (expid, date, desc, amt)
degree, citizenship, religion)

Example: Complex Attribute as Weak Entity Type

(custid, compname, address,

continfo, creditlimit)
CUSTOMER
NOTE:
{CUSTOMER.continfo(contname, telno)}
-> up to 3 contact persons
(custid, compname, address, creditlimit) specialization/generalization
CUSTOMER † specialization
„ process of defining a set of subclasses of an entity
(1, 3) type; the entity type from which the subclasses
are derived is the superclass of the specialization;
superclass and subclass entities are also called
CUSTINFO
generalized and specialized entities, respectively
† generalization
(1, 1)
„ the reverse process of abstraction, in which the
differences of several entity types are suppressed
to identify their common features
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 Example: Partial Overlapping Specialization
(empid, ename, etype, job) (payno, paydate, cashamt, chk,
ccard, gchk, totalamt)
EMPLOYEE
PAYMENT

etype

d
o
=“A” =“R”
chk = “Y” ccard = “Y”
(honorarium, trvlallowance) (hourlyrate, vaclv, scklv)
gchk = “Y”

ADMIN RANK&FILE
CHECK CCARD

(0, N)
(chkno, bank, chkdate, amt) (ccardno, cctype, ccinst,
(tcardno, month, yr, totalhrs) approvalno, amt)

TIMECARD GIFTCHECK
HAS
(1, 1)
(gchkno, expdate, amt)

relational data model

database systems † 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
relational data model entities and provides mechanisms for depicting the
relationships that exist among these data entities
† serves as the theoretical foundation of most modern-
day commercial dbms software (relational dbms)
† concerned with three aspects of data: structure,
integrity and operators

relational data model: structure relational data model: structure

† relation (table) † attribute (column, field)
„ stores information about a logical data entity „ single logical characteristic of the data entity being
„ basic data storage structure used in relational modeled by the relation
database systems „ each attribute is defined on a domain (data type),
which is the set of all legal values from which
CUSTOMERS attribute values can be taken
custid custname address † tuple (row, record)
184 Erap Estrada San Juan „ stores information about an individual instance of
207 Cory Aquino Tarlac the data entity being modeled by the relation
285 Eddie Ramos Pangasinan
320 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

CUSTOMERS
custid custname address
184 Erap Estrada San Juan
† other characteristics of a relation 207 Cory Aquino Tarlac
„ basic relational theory is based on the first normal 285 Eddie Ramos Pangasinan
form assumption, hence: 320 Ferdie Marcos Ilocos Norte
† multivalued attributes are stored in separate
relations LOANS
loanno loandate loanamt duedate interest custid
† composite attributes are represented by their
78-2007 Oct-08-2007 P 25,000.00 Oct-08-2008 P 2,500.00 184
simple component attributes
79-2007 Dec-04-2007 P 10,000.00 Jun-03-2008 P 1,250.00 207
„ null values or nulls are used to represent attribute
01-2008 Jan-10-2008 P 75,000.00 Apr-10-2008 P 7,500.00 184
values that may be unknown or may not apply to
a tuple
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

relational data model: integrity integrity of single relations

† 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
† 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 integrity of single relations
† entity integrity † relational database scheme
„ keys may be simple or composite „ example 1
„ entity integrity rule CUSTOMERS(custid, custname, address)
† for any relation, there can be no duplicate LOANS(loanno, loandate, loanamt, duedate,
tuples and that no candidate key values can
be null interest, custid)
„ entity integrity can be enforced by mechanisms PAYMENTS(orno, paydate, payamt, loanno)
provided by the dbms; operations (insert or
update) that create a duplicate candidate key or „ example 2
one containing nulls are rejected DEPT(deptno, dname, location)
† constraints on null values AK dname
„ specifies whether or not null values are allowed EMP(empid, ename, job, deptno, sal, mgrid)
for the attributes in a relation

integrity among relations 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.
† 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

Relational Database Scheme

integrity among relations CUSTOMERS(custid, custname, address)

LOANS(loanno, loandate, loanamt, duedate, interest, custid)
FK custid References CUSTOMERS Nulls Not Allowed

† referential integrity
CUSTOMERS
„ referencing and referenced tuples
custid custname address
† the referencing tuple contains the foreign key 184 Erap Estrada San Juan
value that represents a reference to the tuple
207 Cory Aquino Tarlac
containing the matching primary key value (the
referenced tuple) 285 Eddie Ramos Pangasinan

† a referenced tuple may have many referencing 320 Ferdie Marcos Ilocos Norte
tuples associated with it
LOANS
† not all tuples in the referenced relation are
loanno loandate loanamt duedate interest custid
referenced tuples
78-2007 Oct-08-2007 P 25,000.00 Oct-08-2008 P 2,500.00 184
„ foreign key attributes are not required to have the
same name as the primary key attributes being 79-2007 Dec-04-2007 P 10,000.00 Jun-03-2008 P 1,250.00 207
referenced; they should, however, be defined on 01-2008 Jan-10-2008 P 75,000.00 Apr-10-2008 P 7,500.00 184
the same domain

6
Example: Self-referencing Relation
Relational Database Scheme
DEPT(deptno, dname, location)
AK dname integrity among relations
EMP(empid, name, job, deptno, sal, mgrid)
FK deptno References DEPT Nulls Allowed
mgrid References EMP Nulls Allowed † referential integrity
DEPT „ referential integrity rule
deptno dname location † for all time, the relational database must not
10 Sales Cebu contain any unmatched foreign key value
20 Accounting Manila „ referential integrity may be violated when tuples
30 Purchasing Manila are inserted, deleted, or updated; can be enforced
by the dbms automatically or via application code
EMP
„ foreign key rules ensure that referential integrity is
empid name job deptno sal mgrid
imposed during delete and update operations
7200 George Bush Manager 10 P45,000.00 7560
† Cascade
7405 Bill Clinton Programmer 20 P30,000.00 7720
† Restrict
7560 Hilary Clinton President P95,000.00
7632 Al Gore Programmer 20 P25,000.00 7720
† Nullify
7720 Fred Thompson Analyst 10 P75,000.00 7200

integrity among relations integrity among relations

† relational database scheme † relational database scheme
CUSTOMERS(custid, custname, address) DEPT(deptno, dname, location)
LOANS(loanno, loandate, loanamt, duedate, interest, AK dname
custid) EMP(empid, name, job, deptno, sal, mgrid)
FK custid References CUSTOMERS Nulls Not Allowed FK deptno References DEPT Nulls Allowed
Delete Restrict, Update Cascade Delete Nullify, Update Cascade
PAYMENTS(orno, paydate, payamt, loanno) mgrid References EMP Nulls Allowed
FK loanno References LOANS Nulls Not Allowed Delete Restrict, Update Cascade
Delete Cascade, Update Restrict

scenario
database systems 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
transformation from the assignment of department heads is done on rotation basis, hence, the dates
when such positions are assigned to an employee are monitored.
entity-relationship model to BLAC INC is a large complex composed of many buildings, and each
the relational data model 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) (roomno, telno)

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

(empid, ename, hiredate, (bldgid, bldgname, location)

address, bday, age)

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