Database I

Methodology

Entity-Relationship Data
Modelling

1
Entity Relationship (ER) Data
Model
 Developed by Chen in 1976 to facilitate the
database design
 Entity Relationship Model is a high-level conceptual
data model
 It is a semantic data model that is used for the
graphical representation of the conceptual database
design
 It is independent of any particular implementation of
the database
 We first develop our conceptual database design in
E-R data model and then later transform it into the
data model of our target DBMS 2
Constructs in ER Data Model
 The E-R data model supports following major
constructs:
 Entity
 Attribute
 Relationship
 The Entity
 The term entity is used in three different meanings or for
three different terms:
1. Entity Type:
 It is an object or concept that is identified by the enterprise
and having independent existence
 Or an entity can be a person, place, object, event, or 3

concept about which we wish to store data

The Entity (Cont.)
 The process of identifying entity types, their properties
and relationships between them is called abstraction
2. Entity Instance
 A particular object belonging to a particular entity type
 The following table lists the entity, defining properties
and instances:

4
The Entity (Cont.)
3. Entity Set
 A group of entity instances of a particular entity type is
called an entity set
 For example, all employees of an organization form
an entity set
 The term entity is used for all of the three terms
Discussed
 Most of the time it is used to mention an entity
type, next it is used for an entity instance and
least times for entity set
5
The Entity (Cont.)
(Entity Types)
 Classification of entity types
 Entity types (ETs) can be classified into
 Regular or Strong or Independent ETs
 Weak or dependent ETs
 Weak Entity Types
 An entity types that are existence-dependent on some other
entity type i.e. they can’t exists independently
 For example, in an organization we want to maintain data
about the vehicles owned by the employees, Now a
particular vehicle can exist in this organization only if the
owner already exists there as employee
 Similarly, if employee leaves the job and the organization
decides to delete the record of the employee then the
record of the vehicle will also be deleted since it cannot 6
exist without being linked to an instance of employee
The Entity (Cont.)
(Entity Types)
 Strong Entity Type
 An entity type whose instances can exist
independently, that is, without being linked to the
instances of any other entity type is called strong
entity type
 A major property of the strong entity types is that they
have their own identification (candidate key), which is
not always the case with weak entity types
 For example, an employee in the previous example is
an independent or strong entity type, since its
instances can exist independently

7
The Entity (Cont.)
 Naming Entity Types
 Following are some recommendations for naming entity
types
 Singular noun recommended, but still plurals can also be
used
 Organization specific names, like customer, client, gahak
anything will work
 Write in capitals, yes, this is something that is generally
followed
 Abbreviations can be used, be consistent. Avoid using
confusing abbreviations, if they are confusing for others
today, tomorrow they will confuse you too
8
The Entity (Cont.)
 Symbols for Entity Types
 A rectangle is used to represent an entity type in
E-R data model
 For strong entity types rectangle with a single line
is used whereas double lined rectangle is drawn
to represent a weak entity type as is shown below

9
Attribute
 Attribute
 An attribute of an entity type is a property or
quality of the instances of that entity type
 Entity instances of same entity type have the
same attributes (E.g. Student Identification,
Student Name) However, values of these
attributes may be same or different
 An attribute is identified by a name allocated to it
and that has to be unique with respect to that
entity type
10
Attribute (Cont.)
 Domain of an Attribute
 Domain is the set of possible values that an
attribute can have
 Domain is a form of a check or a constraint on
attribute that it cannot have a value outside this set
 Associating domain with an attribute helps in
maintaining the integrity of the database
 Domain is normally defined in form of data type
and some additional constraints like the range
constraint
11
Attribute (Cont.)
 Data type is defined as a set of values along with
the operations that can be performed on those
values
 Symbol used for an attribute is shown in the figure
below

12
Attribute (Cont.)
(Types of Attribute)
 Types of Attributes
 Attributes may be of different types:
 Simple/Atomic
 Composite
 Single valued
 Multi-valued
 Stored or Derived
 Simple/Atomic:
 Simple or atomic attributes cannot be further broken
down or subdivided
 For example, attributes stName, stFatherName,
stDateOfBorth of an entity type STUDENT are 13
example of simple attributes
Attribute (Cont.)
(Types of Attribute)
 Composite Attributes:
 An attribute consists of collection of other simple or
composite attributes then it is called a composite
attributes
 For example, stAdres attribute may comprise of
houseNo, streetNo, areaCode, city etc.
 Single valued
 An attribute that holds a single value
 For example, branchNo attribute of branch entity
 Multi-valued
 An attribute that holds multiple values
 For example, branch entity may have multiple values
for branch telephone no attribute 14
Attribute (Cont.)
(Types of Attribute)
 Stored or Derived
 Normally attributes are stored attributes, that is, their
values are stored and accessed as such from the
database
 However, sometimes attribute’s values are not stored
as such, rather they are computed or derived based
on some other value
 For example, we may store the name, father name,
address of employees, but age can be computed from
date of birth

15
Attribute (Cont.)
(Types of Attribute)
 Symbols used for different types of attributes
are shown below

16
Attribute (Cont.)
 The Keys
 A key is a set of attributes that can be used to
identify or access a particular entity instance of an
entity type or out of an entity set
 An entity type may have many instances, from a
few to several thousands and even more
 For example, think of whole population of
Pakistan, the data of all Pakistanis lying at one
place, say with NADRA people
 Now if at sometime we need to identify a
particular person out of all this data, how can we
do that? 17
Attribute (Cont.)
 Can we use name for that, well think of any name,
like Mirza Zahir Iman Afroz, now we may find
many people with this name in Pakistan
 However, if you think about
 National ID Card number, then no matter
whatever is the population of Pakistan, you will
always be able to pick precisely a single person
 Here National ID Card is the key
 We can have super, candidate, primary, alternate
or foreign key
18
Example
 Conceptual Design
 Entity
 The database will store records data about STUENT,
for each STUDENT in the database we record name,
address, rollno, schools attanded
 Attributes
 For each name, there always will be one and only one
name for each STUDENT. The value for name will be
subdivided into first, middle and last name
 For each address, there always will be one and only
one
 address for each STUDENT. The value for address
will not be subdivided. 19
Example (Cont.)
 For each student we will record schools, these may be
more than one school recorded for each student
 Keys
 For each STUDENT we will assume that there is an
attribute rollno, that will be unique to identify individual
entity instances
rollno

STUDENT
STUDENT

name

schools address

20
firstname middlename lastname
Example (Cont.)
 Logical Design (Mapping to Relational Model)
 Map1: For strong entities, develop a new relations and
make the key attribute a primary key
 Map1(a): Map atomic attributes to columns of a relation
 Map1(b): Composite attributes form the columns from the
atomic parts of the composite attribute
 Map1(c): For multi-valued attributes develop the primary-
foreign key relationship
rollno firstname middlename lastname address
STUDENT_SCHOOL

STUDENT rollno schools

21
Relationship
 Relationship:
 A relationship is any association, linkage, or
connection between the entities of interest to the
business
 It is a two directional, association between two
entities, or between an entity and itself
 Each relationship has a name, an optionality
(optional or mandatory), and a degree (how
many)

22
Relationship (Cont.)
 An example of a relationship would be:
 Employees are assigned to projects
 Projects have subtasks
 Departments manage one or more projects
 Relationship Type:
 An abstraction of a relationship i.e. a set of
relationships instances sharing common attributes
 Participants:
 Entities enrolled in a relationship

23
Relationship (Cont.)
 Naming Relationships:
 A relationship name is usually a verb or verb phrase that
denotes the connection between entities (noun)
 STUDENT and CLASS have ENROLL relationship. However,
it can also be named as STD_CLS
 Symbol for Relationships:
 Shown as a Diamond
 Diamond is doubled if one of the
participant is dependent on the other
 Participants are connected by
continuous lines, labeled to indicate
cardinality
24
Relationship (Cont.)
 Relationship Roles:
 The labels “manager” and “worker” are called “roles”

 They specify how employee entities interact via the “works-

for” relationship set
 Roles are indicated in ER diagrams by labeling the lines
that connect diamonds to rectangles, Roles are optional

25
Relationship (Cont.)
(Structural Constraints)
 Structural Constraints
 Structural constraints are information about how two (or
more) entities are related to one another
 There are two types of structural constraints:
 Cardinality and participation
 Cardinality Ratio of a Relationship
 Cardinality is the number of entities (one or more) that will
be related to another entity (or entities)
 For example, there are four ways in which the entities
AUTOMOBILE and STUDENT can be "numerically
involved" in a relationship:
 one-to-one (1:1)
 many-to-one (M:1)
 one-to-many (1:M), and
 many-to-many (M:N). 26
Relationship (Cont.)
(Structural Constraints)
 One-to-One (1:1)
 In this type of relationship, one entity is
associated with one other entity, and vice versa
 E.g. the student/automobile relationship would be
one-to-one, symbolically:
STUDENT:AUTOMOBILE :: 1:1

27
Relationship (Cont.)
(Structural Constraints)

STUDENT:AUTOMOBILE :: 1:1
28
Relationship (Cont.)
(Structural Constraints)
 Many-to-One (M:1)
 More than one entity is associated with one entity
 If the STUDENT:AUTOMOBILE relationship
(shown in last slide) were many-to-one
 We would say that many students are associated
with one automobile and one automobile is
associated with many students; that is:
STUDENT:AUTOMOBILE::M:1

29
Relationship (Cont.)
(Structural Constraints)

STUDENT:AUTOMOBILE::M:1

30
Relationship (Cont.)
(Structural Constraints)
 One-to-Many (1:M)
 One entity is associated with more than one entity
 The sense of a one-to-many
STUDENT:AUTOMOBILE relationship would be
that a student is associated with many
automobiles and an automobile is associated with
one student
 Clearly, if we define a relationship as 1:M (or
M:1), then we need to be very clear about which
entity is 1 and which is M
STUDENT:AUTOMOBILE::1:M
31
Relationship (Cont.)
(Structural Constraints)

STUDENT:AUTOMOBILE::1:M

32
Relationship (Cont.)
(Structural Constraints)
 Many-to-Many (M:N)
 In many-to-many relationships, many occurrences
of one entity are associated with many of the
other
 Many-to-many is depicted as M:N, as in M of one
thing related to N of another thing
 If our STUDENT:AUTOMOBILE relationship were
many-to-many, a student would be associated
with many automobiles and an automobile with
many students:
STUDENT:AUTOMOBILE::M:N
33
Relationship (Cont.)
(Structural Constraints)

STUDENT:AUTOMOBILE::M:N

34
Relationship (Cont.)
(Structural Constraints)
 Participation: Full/Partial
 To show that every automobile is driven by a
student, but not every student drives an
automobile
 By putting a double line between the relationship
diamond and the AUTOMOBILE entity to indicate
that every automobile is driven by one student,
Put another way, every automobile in the
database participates in the relationship
 The single/double lines are called participation
constraints (a.k.a. optionality constraints) and are
depicted in figure on next slides 35
Relationship (Cont.)
(Structural Constraints)

Mandatory; if an automobile is in the database,

must be related to some student.

Optional

36
Relationship (Cont.)
(Structural Constraints)
 A graphic on how
to read an ER
diagram is
presented in Figure

37
Relationship (Cont.)
 Types of Relationships (By number of participant
entities):
 Unary Relationship
 An ENTITY TYPE linked with itself, also called recursive
relationship. Example Roommate, where STUDENT is
linked with STUDENT
 Binary relationship
 A Binary relationship is the one that links two entities sets
e.g. STUDENT-CLASS
 Ternary Relationship
 A Ternary relationship is the one that involves three entities
e.g.VENDOR-PART-WAREHOUSE
38
Example
 Consider a model for a simplified airport that
records PASSENGERS and FLIGHTS
 Suppose that the attributes of PASSENGER
are name, articles of luggage, and frequent
flyer number. Suppose the attributes for
FLIGHT are flight number, destination, time
of departure, and estimated time of arrival
 Draw the ER diagram

39
Example (Cont.)
 Carry out all the
steps performed for
1st example on slide 19
 Step 1: Examine attributes
in the primary entity to find
out if information about one
of the attributes is to be recorded
 Step 2: If another entity is appropriate, draw the second
entity with its attributes. Repeat steps performed in 1st
example
 The other entity in this problem is FLIGHT as shown on
next slide
40
Example (Cont.)
 Step 3: Connect entities
with relationships if
relationships exist
 The specifications do not tell us whether this should be 1
or M, so we chose 1
 We also chose full participation on both sides as shown
on next slide

41
Example (Cont.)

42
Example (Cont.)
 Logical Design (Mapping to Relation Model)
 Perform all the mapping rules discussed in slide 21

name ffn luggage

Passenger

flight# destination depart arrive Flight

43
Relationship (Cont.)
(Mapping Rules)
 Mapping to Relational Model
 Map2(a): For each M:N relationship,
create a new table with the primary
keys of each of the two entities that
are being related in the M:N relationship
 E.g. STUDENT, COURSE relationship
Student
Fname Midname lstname RollNo Address

Course Enroll
CNo CName CreditHrs CNo RollNo
44
Relationship (Cont.)
(Mapping Rules)
 Map2(b): For binary 1:1 relationships, include the
primary key of Entity A into Entity B as the foreign
key
 Map2(b)-i: if one of the sides has full participation in the
relationship, and the other has partial participation, then store
the primary key of the side with the partial participation
constraint on the side with the full participation constraint
 Consider STUDENT-AUTOMOBILE relationship on slide 36

Student
Fname Midname lstname StdNo Address

VID Make BodyStyle Color Year StdNo Automobile 45

Relationship (Cont.)
(Mapping Rules)
 Map2(b)-ii: For binary 1:1 relationships, if both sides have
partial participation constraints, there are three alternative
ways to implement a relational database:
 You may select either one of the relations to store the key
of the other (and live with some null values)
 You can create a new relation to accommodate the
relationship that would contain the key of the two related
entities (as is done in Map2a)
 Create a new table with just the keys from the two tables
e.g. STUDENT and AUTOMOBILE, in addition to the two
tables, STUDENT and AUTOMOBILE. In this case we
would map the relations as we did in the binary M:N case;
and if there were any null values, these would be left out of
the linking table
46
Relationship (Cont.)
(Mapping Rules)
 Map2(b)-iii: For binary 1:1 relationships, if both sides have full
participation constraints, you may use the semantics of the
relationship to select which of the relations should contain the
key of the other
 Map2(c): For binary 1:N relationships, we have to
check what kind of participation constraints the N side
of the relationship has:
 Map2(c)-i: For binary 1:N relationships, if the N-side has full
participation, include the key of the entity from the 1 side, in
the relation on the N side as a foreign key
 Example on next slide

47
Relationship (Cont.)
(Mapping Rules)
Student
Fname Midname lstname StdNo DormName

Dorm
DormName Supervisor

48
Relationship (Cont.)
(Mapping Rules)
 Map2(c)-ii: For binary 1:N relationships, if the N-side
has partial participation, the 1:N relationship is
handled just like a binary M:N relationship with a
separate table for the relationship. The key of the new
relation consists of a concatenation of the keys of the
related entities
 Map3(a): For 1:N recursive relationships, reinclude
the primary key of the table with the recursive
relationship in the same table, giving it some other
name
 Map3(b): For M:N recursive relationships, create a
separate table for the relationship (as in mapping rule
Map2(a))
49
Relationship (Cont.)
Crow’s Foot or Barker's Notation
 Crow’s foot notation

50
Relationship (Cont.)
Weak Entity
 In the figure, the
EMPLOYEE–
DEPENDENT—
HOBBYAR is
depicted

51
Relationship (Cont.)
Weak Entity
 Map4-Develop a new relation for each weak
entity, If there is a composite attribute,
include only the atomic parts of the
composite attribute. To relate the weak entity
to its owner, include the primary key of the
owner entity in the weak relation as a foreign
key

52
Relationship (Cont.)
Attributes of Relationships
 In slide 44 we considered the M:N relationship STUDENT–
COURSE
 Now consider adding the attribute grade to the ER diagram
 If we put grade with the STUDENT entity, we would have a
multivalued attribute that had to be somehow related to the
COURSE entity to make sense
 Similarly, if we put the grade attribute with the COURSE
entity, the COURSE entity would have to be related to the
STUDENT entity
 The correct place for the grade attribute in the diagram
would be on the relationship, enroll, because grade
requires both a STUDENT and a COURSE to make sense
 This is shown on next slide
53
 Relationship (Cont.)
Attributes of Relationships
 An attribute like grade
is called a "relationship
attribute" or "intersection
attribute“
 When it is recognized
that the attribute has to
be identified by more than
one entity, the attribute is
moved to the relationship
between the two (or more)
entities that identify it
54
Relationship (Cont.)
Attributes of Relationships
 So the diagram
will evolved to
the one shown
on left side

55
Enhancements in E-R Data
Model (EER- Data Model)
 The basic concepts of ER modeling (as
originally developed by Chen) were not
sufficient to represent the requirements of
more complex applications, such
 Generalizations and Specializations
 An ER model that supports these additional
semantic concepts is called the Enhanced
Entity Relationship (EER) model

56
Enhancements in E-R Data Model
(EER- Data Model) (Cont.)
 Generalizations and specializations are associated with
the concepts of super-classes and sub-classes and
attribute inheritance
 For example, a STUDENT entity contains information
about students
 However, suppose we wanted to store information about
all people at an institution say staff and faculty
 Think of a super-class called PERSON that contained a
sub-class for STUDENT, another sub-class for STAFF,
and yet another sub-class for FACULTY
 The super-class in a database is called a generalization,
and the sub-classes are called specializations
57
Enhancements in E-R Data Model
(EER- Data Model) (Cont.)
 To visualize a problem with ER diagrams
 Where one of the attributes for an entity has values
that vary according to "the situation"
 For example, suppose we are modeling student
athletes who may play more than one sport
 Some information in the ATHLETE entity contains
attributes that have different values for different
sports
 These different values are called "variants"
Name RNo Sport Info
Ahmad 1234 Cricket 20 ODI, 3 Wickets Athlete 58

Saima 2345 Tennis 220,City Rank14

Enhancements in E-R Data Model
(EER- Data Model) (Cont.)
 We are actually storing information about two
different, but related, things:
 (1) a generalization called, "students," who have a name,
id, etc.; and
 (2) specializations — sports (tennis, cricket, golf, etc.),
each with their own different attributes
 These variants are most easily handled by removing
the variant from the generalization and treating it as
a subclass entity and leaving the original, "fixed
part" of the entity as a super-class
59
 Enhancements in E-R Data Model
(EER- Data Model) (Cont.)

A superclass entity may be a

member of more than one
subclass of a
No overlapping
specialization

60
Enhancements in E-R Data Model
(EER- Data Model) (Cont.)
 Map5:
 For each generalization/specialization entity
situation, create one table for the generalization
entity and create one table for each specialization
entity
 Add the attributes for each entity in their each
respective tables
 Add the key of the generalization entity into the
specialization entity
 The primary key of the specialization will be the
same primary key as the generalization
61