1.

14Data Modelin the Entity-Relationship(ER)Model

Bhavaaa
made
1.14.1 Using High-Ieved ConcepBualData Models for Database Design
The first step shown is requirements collection and analysis. Here the database designers
intervicw database users, to undestand the requirements, The requirements shoukd be complete as
possible, t is also useful to specity functional requirements. Which consists of operations that
willbe applicd to the database such as retrievals and updates, usually data flow diagrams, sequence
diagrams are used to specify functional requirenents.
Once all the requirements are collected, the next step is to design the conceptual schema using a
high-level conceptual data model, this step is called conceptual design. The conceptual design
contains deseriptions about entities, relationships and constraints, since these do not include
implementation details itis casy to undestand by non-technical users, The high level conceptual
design ensures that allthe requirements are met and the requirements do not conflict.
Modifications to the conceptual schema can be introduced if some functional requirements cannot
be specified.
The next step is the implementation of the database, using commercial DBMS, the commercial
DBMS, uses relational or the object-relational database model.
This step is called logical design or data model mapping.
During physical design phase, includes intermal storage structures, indexes, access paths, and file
organizations for the database files.

Figure 3.1]
Asinpified diagram
to lkustrate the
Miniworld main phases of
database desgn

REQUIREMENTS
COLLEcTION AND
ANALYSIS

Functional Requirements Data Requirenents

FJNCTIONAL ANALYSIS CONCEPTUAL DESIGN

High-Level Transaction Corceçhual Schema

Speccation n ahighlevel data mode

DBMSndopesdent LOGICAL DESIGN

(DAIA MODEL MAPPIC
DBMS pecde
Logical Conceptua) Schema
APPUCATION PROGRAM -n the date model ofa specic DBMS)
DESGN
PHYSICAL DE SIGN

TRANSACTION internalSchema
IMPLEMENTATKON

Applicaton Program

1.14.2 Entity Types, Entity Sets, Attributes, and Keys

1
 Entities and Attributes
" Entity is a thing in the real world with an independence existence, an entity may be an object
with a physical existence (for ex: person, car, employee) or it may be an object with a
conceptualexistence (for ex: a company, a job).
Attributes are the properties of the entity
For Ex An EMPLOYEE entity can be described by employee's name, age, address, salary and job. An
entity can have value for its attributes. the values become a major part of the data in the database.

Name John Smith Name Sunco Oil

Address = 2311 Kirby

Houston, Texas 77001
C Headquarters = Houston
Age = 55 Flgure 7.3
Two entites,
EMPLOYEE e, and
Home phone =713749-2630 COMPANY C,, and
President = John Smith their attributes.

1.14.3 Types of attributes occur in the

ER model:
Simple versus composue, single valued versus atbul
multivalued, and stored versus derived. ,
1.
Composite versus Simple
Composite attributes can be divided(Atomic) Attributes.
into smaller subparts, which represent more basic
independent meanings, for example, the address attribute of the employee entity can attributes with
street_address, city. State, and Zip, be subdivided into
Simple or atomic attributes.: Attributes that are not
Composite attributes can form a hierarchy: divisible are called simple or atomic attributes.
For example, street address can be
apartment_number
subdivided into three simple attributes: Number, street, and
The composite attribute is
referenced as a whole, there is no need to subdivide it into
attributes. component
Address
Figure 7.4
Ahierarchy of composte
attributes.

Street address City State

Zip

Number Street Apartment_number

Single- Valued versus Multivalued Attributes.

Single-valued. : Attnibutes having single values are called single-valued. For example, Age is a
valued attribute of a person. single
Multivalued Attributes: The attributes having a set of values for the same entity
attribute for a car, or a college degrees attributes for a person. for example, a colours
whereas two tons cars have two colour values. Similarly one Car with one colour have a single value
one degree and other many. person may have no college degree, other

2
 Stored versus Derived
WO or attribute values are telaled fos exomole, tbe ave and birth date attributes of a peron. The value
Ee can be ketermined bythe brh date of theocrson Hence age nttnbute is called Derived, and
birth date is called stored attribute,
IV, Complex Attributes
s he cOmbination of composite aund Multivalued attributes which is nested arbitrarily, we are nesting
he conyosite attitbute between parenthesis ) and separating the components with commas, and by
displaying multivalued atuibutes between braces (0.
(adkl1ess phone((phone(area code, hone nunmbe)),Address(Street address
(Number,Sreet),city,state))
1.14.4NULL Values
A purticular entity may not have a applicable value for an attribute. For
example; an apartment_no
appies to only to those who stay in apartnent and not for other family homes. There are two types of
be further cassified into two cases. The first case
NULL. one is unknown, the unknown categorycan
missing- for example, if the height attribute
arises when it is known that theattribute value cxists but is the attribute
it is now known whether
of the person is listed as NULI. The second case arises when
valuc exists for ex: if the Home phone attribute of person is NULLL.

1.15 Entity Types, Entity Sets, Keys, and Value Sets

1.15.1Entity Types and Entity Sets:

the same attributes. Each entity type in the
Entity type defines a collection (or ser) of entities that have
shows two entity types: EMPLOYEE
database is described by its name and attributes.) Figure below
and COMPANY.
the database at any point in time is called an
The collection of all entities of a particular entity type in
name as the entity type.
entity set: the entity set is usually referred to using the same

EMPLOYEE COMPANY Flgure 7.6

Entity Type Name: Two entty types,
Name, Age, Salary Name, Headquarters, President EMPLOYEE and
COMPANY,and some
member entites of
Ce
cach
(Sunco O, Houston, John Smith)
(John Smith, 55, 80OK)

Entity Set (Fred Brown, 40, 3OK) (Fast Computor, Dallas, Bob King)
(Extension)

Jucty Clark, 25, 20K)

a rectangular box
An entity type is represcnted in ER diagrans (see Figure 7.2) as
enclosing the entity type name.
Attribute names are enclosed in ovals and are attached to their entity type by straight lines.
Composite attributes are attached to their component attributes by straight lines.

3
 displaycd in double ovals
Multivalued attributes are
fype in this notaio
Hyure 7.7(a) showsa CARctity

trator )CVt e

distinctfoa tah
1.15.2 Key Attribules of an Entity Type. attributes whose values are can te
mre
. key attribute : An entity type usually has one of is calleda key attribute, and its values
COMPANY
individual entity in the entity set. Such an attr1bute Name attributeis a key of the
used to identify cach entity uniquely For example, the sarre
the nanc.
are allowed to have
entity type in Figure 7.6 because no two companies
assciated with
Exch simple attribute of an entity type is
1.15.3 Value Sets (Domains) of Attributes. atribte
the set of values that maybe assigpedto that
a value set (or domain of values), which specifies betwecn 16 arxd 70, we can
for each individual entity. if the range ofages allowed for ernployces is
integer rurnbers
betwcen 16
specify the value set of the Age attribute of EMPLOYEEto be the set of
and 70.

1.16 Initial Conceptual Design of the COMPANY Database

We can now define the entity types for the COMPANY database, based on the Requirerents
Lications,Manager, and
I. An entity type DEPARTMENT with attributes Name, Number,
Manager_Start_date. Locations is the only multivalued attribute. We can specify that bth Narne aTal
Number are (separate) key attributes because cach was specified to be unique.
2.An entity type PROJECT with attributes Name, Number, Location, and Controlling_departrent Bah
Name and Number are (separate) key attributes.
3. An entity type EMPLOYEE with attributes Name, Ssn, Sex, Address, Salary, Birth date,
Department, and Supervisor. Both Name and Address may be composite attributes; however, this was
not specified in the requirements. We must go back to the users to see if any of them will refer to the
individual components of NameFirst_name, Middle_initial, Last_name- -or of Address.
4. An entity type DEPENDENT with attributes Employee, Dependent_ name, Sex, Birth date, and
Relationship (to the employee).

4
 (Name ) umte)
CLocticn 4 DEPARTME NIMaragt
Maner start ate

Name ) umber

Contreng dgartment

Fame (Mt )Lname (Proc)Hon)

Name Wrka on
Departmert (Spervieor

(Brth date)
IEMPLOYEE Addres

Flgure 78
Prebnrvary des A r t y types
(Barth datSexEmpkyee for the COMPANY datatase
Some A the shown attr taAes wl
Dependent name)
Relationehip [DLPENDENT be tetined into relatiorships

Constraints
1.17 Relationship Types, Relationship Sets) Roles, and Structural
1.17.1Relationship Types, Sets, and Instances relationship
E2, ....En defines a set of associations or a
A relationship type R amongnentity types El,
set among entities from these entity types.
FOR between the two entity types EMPLOYEE
For example, consider a relationship type WORKS the department for which the employee
and DEPARTMENT, which associates each employce with
works in the corresponding entity set.
WORKS_FOR associates one EMPLOYEE entity and
Each relationship instance in the relationship set
one DEPARTMENT entity.
DEPARTMENT
EMPLOYEE WORKS_FOR

Figure 7.9
Some instances in the
WORKS FOR relatonship
set, which represenits a
relationshp type
WORKS FOR between
EMPLOYEE and
DEPARTMENT.

Relationships
1.172 Relationship Degree, Role Names, and Recursive entity
Degree ofa Relationship Type. The degree of a relationship type is the number of participating
types. Hence, the WORKS_FOR relationship is of degree two.

5
 aonship type of degree twois called binary, and one of degree three is called ternary. three
etanple of a ternary relationshio is SUPPLY, where cach relationship instance ri associates
suppher s, a part p, and a project i, whenever s supplies part p to project) in figure below
SPPLY POHCI

PART

Some relationship instances in

the SUPPLY ternary relationship
set
1.17.3 Role Names and Recursive
Relationships
The role name signifies the role that a participating entity from the entity type, and helps to explam
what the relationshipmeans. For example. in the WORKS FOR relationship type, EMPLOYEE
plays
the role of employee or worker and DEPARTMENT plays the role of department or
employer. same
entity type participates more than once in a relationship type in different roles. Such relationship types
are called recursive
relationships.
Figure below shows an example. The SUPERVISION relationship type relates an
employee to a
supervisor, where both employece and supervisor entities are members of the same EMPLOYEE entity
set. Hence, the EMPLOYEE entity type participates wice in
SUPERVISION: once in the role of
supervisor (or boss), and once in the role of supervisee (or subordinate), the lines marked '1' represent
the supervisor role, and those marked '2' represent the supervisee role, hence, el
supervises e2 and e3,
e4 supervises e6 and e7, and e5 supervises el and e4. In this example, each
relationship instance must
be connected with two l1nes, one marked with'1' (supervisor) and the other with '2'
(supervisee)
EMPLOYEE SUPERVSION

1.17.4Constraints on Binary Relationship Types

Relationship types usually have certain constraints that limit the possible combinations of entities that
may participate in the coresponding relationship set. We can distinguish two main types of binary
relationship constraints: cardinality ratio and participation.

6
 is called lernary
ationship type ol degree twois called binary, and oneof dee thrce
instance i aisocates thaee
AnCtample of alenary tlalionhin is SUPPLY whC cach rclationship
below
hes a suppliet s, a part p, and a roicct i. whenever ssupplies part po projectyJ n hgure

PAI

Some relatonshsp nstances in

the SUPPY ternary redationship
et
1.17.3 Role Names and Recursive
Relationships
The role name signifies the role that a participating entity from the entity type, and helps to explan
what the relationship means, For example, in the WORKS FORrelationship type, EMPLOYEE plays
the role of cmployee or worker and DEPARTMENI Plays the role of depart1ment or employer. Same
enity type participates more than once in a relationship type in different roles. Such relationship types
are called recursive relationships.

Figue below shows an example. The SUPERVISION relationship type relates an employee to a
supervisor, where both employee and supervisor entities are members of the sane EMPLOYEE entity
set. Hence, the EMPLOYEE entity type participates twice in SUPERVISION: once in the role of
supenisor (or boss), and once inthe role of superisee(or subordinate) the lines marked 'l' represent
the supervisor role, and those marked '2' represent the supervisee role, hence, el supervises e2 and e3,
ed supervises e6 and e7, and e5 supervises el and e4.In this example, each relationship instance must
be connected with two lines, one marked with 1' (supervisor) and the other with '2' (supervisee)
EMPLOYEE SUPEFVSON

1.17.4 Constraints on Binary Relationship Types

combinations of entities that
Relationship types usually have certain constraints that limit the possible
main types of binary
may participate in the corresponding relationship set. We can distinguish two
relationship constraints. cardinality ratio and participation.

6
 I.
Cardinality Ratios for Binary Relationships
Ihe cardinality ratio for a binary
that an cntity can relationshin specfies the maimm number of relationship instances
For example, inparticipate in.
the WORKS_HOR binary relationship type, DEPARTMENT: EMPLOYEE is of
Cardinal1ty ratio 1:N, meaning that each department can be related to (that is, employs) any nun
mpiees,y but an employee can be related to (work for) only one depart1ment. On the other hand, an
cmployee can be related to a maximum of one department.
The possible cardinality ratios for binary relationship types are 1:1, 1:N, N:1, and M:N.
An example of a 1:1binary relationship is MANAGES (Figure below), which relates a department
entity to the employee who manages that depart1nent.
Flyure 7.12 EMELOYEE MANACES DEPATMENT
AI at p
MANAM.S

da

The relationship type WORKS_ON (Figure below) is of cardinality ratio M:N, because the mini-world
rule is that an employce can work on several projects and a project can have several employees.
EMPLOYEE WORKS ON PROECT

...

Flgure 7.13
An MNrelabrnstp
WORKS ON

IL Participation Constraints and Existence Dependencies.

This constraint specifies the mninimum number of relationship instances that each entity can
participate in.
There are two types of participationconstraints: total and partial
The participation of EMPLOYEE in WORKS_FOR is called total participation, meaning that
every entity in the total set of employee entities must be related to a department entity via
WORKS_FOR. Totalparticipation is also called existence dependency.
In Figure 7.12 we do not expect every employee to manage a department, so the participation
of EMPLOYEE in the MANAGES relationship type is partial, meaning that some or part of
the set of employee entities are related to some department entity via MANAGES, but not
necessarily a. Cardinality ratio and participation constraints, taken together, as the structural
constraints of a relationship type.
1.175 Atributes of Relationship Types
Relationship types can also have attributes, similar to those of entity types.
For example. to record the number of hours per week that an employec works on a particular
projct, wecan include an attribute Hours for the WORKS ON relationship type.

1.18 Weak Entity Types

Enity types that do not have key attributes of their own are called weak entity types.
in contrast, regular entity types that do have a key atribute, which include all the examples
discussedso far are called strong entity types.
Entities belonging to a weak entity type are identified by being related to specific entities rom
another entity type inconmbination with one of their attribute values. We call this other entity
type the identifying orowner entity type.
A weak entity type always has a total participation constraint (existence dependency) with
respect to its identifying relationship.
Two dependents of two distinct employees may, by chance, have the same values for
Birth date, Sex, and Relationship, but they are still distinct entities. They are Name,
identified
distinct entities only after determining the particular employee entity to which each as
is related. dependent
A weak entity type normally has a partial key, which is the
weak entities that are related to the same attribute that can uniquely identify
owner entity.
Weak entity types can sometimes be represented as complex
attributes. (composite, multivalued)
1.19 A Sample Database Application
1.19.1 E-R diagram for the requirements ofa
company.
The company is organized into
departments. Each department has a unique name, a
unique number, and a particular employee who manages the department. We keep track
of the start date when that employee began
may have several locations.
managing department. A department
the
A department controls a number of
projects, each of which has a unique name, a unique
number, and a single location.
We store each employee's name, Social
Security number,2 address, salary, sex
(gender), and birth date. An employee is assigned to one department, but may work on
several projects, which are not necessarily controlled by the
track of the current number of hours per week same department. We keep
that an employee works on each project.
We also keep track of the direct
supervisor of each employee (who is another
employee).
We want to keep track of the
dependents of each
keep each dependent's first name, sex, birth date,employee for insurance purposes. We
and relationship to the employee.

8
 A) ry )

Chddyy DPAruNT
( t datey

MANAE9 CONTOUS

H N

M PlOECI
WKS ON

C r aton
Nanber
DEPENOE NIS OF

GEEONT

Nare ) S e s ) B t h date Relatunahip

luure 72

1.19.2 Refining the ER Design for the COMPANY Database

In our example,we specify the following relationship types: DEPARTMENT.

MANAGES, a 1:l relationship type between EMPLOYEE and
EMPLOYEE participation is partial. DEPARTMENT participation is not clear from
department must have a
the requirements. We question the users, who say that a
Start_date is
manager at all times, which implies total participation. 13 The attribute
assigned to this relationship type. EMPLOYEE.
WORKS_ FOR, a 1:N relationship type between DEPARTMENT and
Both participations are total.
CONTROLS, al:N relationship type between DEPARTMENT and PROJECT. The
be
participation of PROJECT is total, whereas that of DEPARTMENT isdetermined to
partial, after consultation with the users indicates that some departments may control
no projects.
SUPERVISION, a l:N relationship type between EMPLOYEE (inthe supervisor role)
and EMPLOYEE (in the supervisee role). Both participations are determincd to be
partial, after the users indicate that not every employee is a supervisor and not every
employee has a supervisor.
WORKS_ON, determined to be an M.N relationship type with attribute Hours, after
the users indicate that aproject can have several employees working on it. Both
participations are determined to be total.
DEPENDENTS_OE, a l:N relationship type between EMPLOYEE and DEPENDENT,
which is also the identifying relationship for the weak entity type DEPENDENT. The
participation of EMPLOYEE is partial, whereas that of DEPENDENT is total.

1.20 ER Diagrams, Naming Conventions, and Design Issues

L.20.1 Notation for ER Diagrams

Entity types such as EMPLOYEE, DEPARTMENT, and PROJECT are shown in
rectangular boxes.
 WORKS FOR, MANAGES, CONTROLs. and
Relationship ypes such
WORKS ON are shown in diamondshaped boes altxhed to the participating entity
Iy.es with straight lines
Anvibutes are shown in ovols, and each altribute is attached by a straight line to its entity
type or relationship type
Component attributes of acomposite attribute are attached to the oval representing the
Composte attnbute, as illustrated by the Name attribute of EMPLOYEE.
Multivalued anibutes are shown in double ovals, as illustrated by the Locations
attribute of DEPARTMENT Keyatributes have their names underined.
Derived atributes are shown in doted ovals,as illustrated by the Number_of_employees
attribute of DEPARTMENT.
Weak entily types are distinguished by being placed in double rectangles and by having
their identifying relationship placed in double diamonds, as illustrated by the
DEPENDENT entity type and the DEPENDENTS_OF identifying relationship type.
Theputial key of the weak entity type is underlined with a dotted line. In Figure 7.2 the
cardinality ratio of cach binary relationship type is specified by attaching a 1, M, or N
on cach participating edge.
The cardinality ratio of DEPARTMENT: EMPLOYEEin MANAGES is 1:1, whereas it
10
is I:N for DEPARTMENT: EMPLOYEE in WORKS_FOR, and M:N for WORKS_ON.
The participation constraint is specifiedby a single line for partial participation and by
double lhnes for total participation.
Figure 7.4 shows a pictorial representation of the symbols in e-r diagram.

Sood

10
 Meaing Figure 7 14
Semay of he ntatn

Fnty

Wak Enty

Aonahp

hdnthying Relahonahp

Artnbute

Key Artribute

Mvaed Atrbute

Q Composte Atrbute

Demved Amrbute

Total Parbcpion of E, nR

Cardinality Ratio 1: Ntor E, £, n R

Structural Constrant (mun, ma

R on Partcpation of En R

1.20.2 Proper Naming of Schema Constructs possible, the meanings attached to the
> One should choose names that convey, as much as
d1fferent constructs in the schema.
ones, because the entity type
Choose to use singular names for entity types, rather than plural
type.
name applies to each individual entity belonging to that entity
names are uppercase letters, attribute
Use the convention that entity type and relationship type
lowercase letters.
names have their initial letter capitalized, and role names are
database requirements, the nouns uppearing
As a general practice, given a narrative description of the
and the verbs tend to indicate names of relationship
in the narrative tend to give rise to entity type names,
that describe the nouns coesponding to
types. Attribute names generally arise from additional nouns
left to right and from top to bottom.
entity types ER diagram of the schema readable from
To explain this naming convention further, we have
one exception to the convention in Figure 7.2-the
top. When we describe this
DEPENDENTS_OF relationship type, which reads from bottom to
entity type) are DEPENDENTS_OF
relationship, we can say that the DEPENDENT entities (bottom
to read from top to bottom, we
(relationship name) an EMPLOYEE (top entity type). To change this
HAS_DEPENDENTS,
could rename the relationship type to

11
Frame Mt (name Flgure 7.15
Bdate ERdagrams for the company schena, wth structural con
Name strants speofd uing(min, max) rotation arxd role rames
Ssn
meAdtess Salary
Sex Locations
WORKS FOR (4N)
(1,1), Name Number
Employee Department
EMPLOYEE Start dato) Number ot_enployees: DEPARTMENT

o.anoget MANAGES
Department
Maraged)
(ON Controling

CONTROLS
Departent

Hours
(0.N) Worker
Supervisor (0.1) Controlled
|Supervisee (1.1)) Project
WORKS_ON Project PROJECT
(1N)
SUPERVISION (0,N)
Employee Name
Location
Number

DEPENDENTS OF

(1,1)Dependent
DEPENDENT

Name Sex Birth date

Relatonship