Company

LOGO
Entity-Relationship Diagram
Dr. Rim Moussa
Eng. School of Carthage
Steps
● Step 1. Understand the problem domain. Analyze DB requirements.
● Step 2. Design a conceptual database schema by creating an
ERD,
● Step 3. Design a Logical database schema.
● Convert the ERD to a normal form ERD: NF-ERD.
● Translate the ERD into a relational schema.
● Next Lecture on Normalization Theory
● Step 4. Design a Physical database schema.
● Denormalization for better performance.
● Adding redundant attributes in some relations, adding derived
attributes in some relations, merging/splitting relations, choosing
primary keys and foreign keys
● Defining indexes
● Do database prototyping & modify the design if necessary.
● Step 5. Verify the design with users. Iterate the steps if necessary.
2
Steps Towards an NF-ER
● ERD: Entity sets and Relationships sets
● ERD is DBMS independent
● Concentrate on “information requirements” not on “storage or
access efficiency”, i.e. conceptual design.
● Easy to understand by users and database designers
● Steps Towards an NF-ER
● Step 1. Identify the entity types.
● Step 2. Identify the relationship types and their participating entity
types.
● Step 3. Identify the attributes, keys, and identifier of each entity
type and relationship type and obtain an ER diagram
● Step 4. Convert the ER diagram to a normal form ER diagram
(Next Lecture Normalization Theory)
● Step 5. Translate the NF-ER diagram to a relational database
schema
3
Entity Sets
● An entity set is a set of entities of the same type that share the
same properties,
● An entity is represented by a set of attributes.
● Attributes are descriptive properties possessed by each
member of an entity set.
● Each entity has a value for each of its attributes
● Examples:
● People: Employees, students, customers
● Places: Cities, offices, routes, countries
● Things: Equipments, products, buildings
● Organizations: Teams, suppliers, departments
● Events: Employee promotions, project phases, account payments
● Concepts: Projects, accounts, complaints

4
Relationship Sets
● A relationship is an association among several entities
● A relationship set is a set of relationships of the same type.
● If E1 , E2 , ..., En are entity types, then an n-ary relationship
type R is a subset of the Cartesian Product E1 x E2 x ...x En
● Work  Employee X Department
● Boss  Employee X Employee
● Advisor  Professor X Student
● Degree of a relationship:
● It describes the number of entity participation
● n = 1, Unary (Recursive) Relationship
● n = 2 , R is binary
● n = 3 , R is ternary
● ...
5
Example: Instructor -Advise - student

6
Recursive Relationship type
● Boss: is-boss
● Person: is-father, is-mother, is-child, ...
● Marriage: is-spouse
● Friendship: is-friend
● Course: is-prequisite-course
● ...

7
Attributes
● For each attribute, there is a set of permitted values, called the
domain, or value set, of that attribute.
● The domain of attribute academic semester might be strings from
the set {Fall, Winter, Spring, Summer},
● The domain of attribute gender might be strings from the set
{Male, Female},
● An attribute takes a null value when an entity does not have a
value for it.
● Composite attributes can be divided into subparts
● name, address, date, timestamp

8
Attributes 2/2
● Multi-valued attribute (double oval)
● an attribute has a set of values for a specific entity
● An instructor may have zero, one, or several phone
numbers,
● Arrays, sets,... are not allowed
● Derived attributes (dashed oval)
● The value for this type of attribute can be derived from the
values of other related attributes or entities.
● Total amount of an Order,
● Number of orders or Revenue of a Customer
● Age of a Person –derived from the date of birth
● Number of employees in a department
● Primary key (underlined)
● a key for an entity is a set of attributes that suffice to
9 distinguish entities from each other.
Cardinalities 1/2
● Mapping cardinalities: express the number of entities to which
another entity can be associated via a relationship set.
● For a binary relationship set R between entity sets A and B,
the mapping cardinality must be one of the following:
● One-to-one. An entity in A is associated with at most one entity in
B, and an entity in B is associated with at most one entity in A.
● One-to-many. An entity in A is associated with any number (zero
or more) of entities in B. An entity in B, however, can be
associated with at most one entity in A.
● Many-to-one. An entity in A is associated with at most one entity
in B. An entity in B, however, can be associated with any number
(zero or more) of entities in A.
● Many-to-many. An entity in A is associated with any number (zero
or more) of entities in B, and an entity in B is associated with any
number (zero or more) of entities in A.

10
Cardinalities 2/2

An instructor may advise at

most one student, and a
student may have at most one
advisor
An instructor may advise many
students, but a student may
have at most one advisor.

An instructor may advise at

most one student, but a
student may have many
advisors

An instructor may advise

many students, and a
student may have many
advisors.

11
Primary Key
● Entity
● specify how entities within a given entity set and
relationships within a given relationship set are
distinguished.
● a key for an entity is a set of attributes that suffice to
distinguish entities from each other, so it's minimal.
● Relationship
● primary-key(E1) ∪ primary-key(E2 ) ∪ ⋯ ∪ primary-key(En )
∪ {a1, a2 , ... , am }
● the relationship set R has attributes a1, a2 , ... , am
associated with it
● Primary-key must be minimal

12
Choosing the right relationship
● We could deduce works-for from Stars-in and Owns instead

13
Weak Entity Set
● A weak entity set is one whose existence is
dependent on another entity set, called its
identifying entity set;
● Instead of associating a primary key with a
weak entity, we use the primary key of the
identifying entity, along with extra attributes,
called discriminator attributes to uniquely
identify a weak entity.
● Example 1: Person and his/her Pets
● Example 2: Different provinces of a country
may have cities with the same name. So,
city name cannot be used to identify a city.
● City Waterloo, Ontario, Canada
● City Waterloo, Iowa, US
● City Waterloo, Illinois, US
14
Weak Entity Set
● Example 3: The existence of a Child entity depends on the
existence of an associated EMPLOYEE entity. Thus, if an
Employee entity is deleted, its associated Child entities are
also deleted.
● existence-dependency relationship type (denoted “EX”)

15
Weak Entity Set
● identifier-dependency relationship type (denoted “ID”): An
entity cannot be identified by the value of its own attributes,
but has to be identified by its relationship with other entity

16
Specialization
● Specialization is the process of
designating subgroupings within an
entity set is called specialization.
● We refer to this relationship as the ISA
(“is a”) relationship,
● Two types of specialization
● Overlapping specialization, e.g
student and employee
● Disjoint specialization, e.g. instructor
and secretary, male and female,
deposit account and checking
account

17
Entity-Relationship vs UML Entity Class Diagram

18
Order-Entry System (C. J. Date )

19
ERD for a SHIP-TRACKING DB (El Masri et al.)

20
ERD COMPANY database (El Masri et al.)

21
UML COMPANY database (El Masri et al.)

22
COMPANY DB state (El Masri et al.)

23
COMPANY DB state (El Masri et al.)

24
Notation

25
ERD → Logical Relational Schema (ElMasri et al.)

26
Examples of ERD slide#7 → DB Logical Schema

Staff(staffID, #superior) Part(partID, …..)

Staff includes a dummy record in Composition(#majorpart, #minorpart)
order to handle big boss who doesn't
have a superior
Solution1:
Person(personID, #spouseID, gender…..)
/!\Integrity: if P1.spouseID= P2.personID
then P2.spouseID = P1.personID
/!\ Integrity ”religious wedding”:
if P1.gender = 'M' and P1.spouseID= P2.personID then P2.gender ='F' and vice versa
Solution2:
Person(personID, gender…..)
Marriage(#husband-personID,#wife-personID)
/!\ Integrity: Person with husband-personID gender is 'M'
and Person with wife-personID is 'F'
27
Examples of ERD slide#11 → DB Logical Schema
Instructor(I-ID,.. ) Student(S-ID, ..#I-ID)
OR
Instructor(I-ID,.. ) Student(S-ID, ..)
Advise(#I-ID,#S-ID)

Instructor(I-ID,.. )
Student(S-ID, ..#I-ID)

Instructor(I-ID,.., #S-ID)
Student(S-ID, ..)

Instructor(I-ID,.. )
Student(S-ID, ..)
Advise(#I-ID,#S-ID)

28
Examples of ERD Weak Entity Sets→ DB Logical
Schema
Country(ctry-name, ...)
Province(prov-name, #ctry-name …)
City(city-name, #prov-name, #ctry-name …)

Employee(EmpID, ...)
Child(NRIC, #Emp-ID, name, DoB, Sex)

Employee(EmpID, ...)
Child(Given-Name, #Emp-ID, DoB, Sex)

29
Examples of ERD slide#18 → DB Logical Schema

Solution #1: One single Table

Account(AcctID, name, balance, interest-rate, start-date, maturity-date, overdraft-limit)
/!\ Integrity
EITHER Case Fixed-Deposit Account: interest-rate null and start-date null and
Maturity-date null and overdraft-limit = null
OR Case Checking Account: interest-rate=null and start-date=null and
maturity-date=null and overdraft-limit  null
We can not have both, the specialization is disjoint

30
Examples of ERD slide#18 → DB Logical Schema
Solution #2: One single Table and a new column “Type”
Account(AcctID, name, balance, type, interest-rate, start-date, maturity-date,
overdraft-limit)
Type is boolean (either 0 or 1)
/!\ Integrity:
Type = Fixed-Deposit Account (0) OR Type = Checking Account (1)
/!\ Integrity:
If Type = Fixed-Deposit Account (0) then Interest-rate null and start-date null and
Maturity-date null and Overdraft-limit = null
If Type = Checking Account (1) then Interest-rate=null, start-date=null and
maturity-date=null and Overdraft-limit  null

Solution #3: Different tables

Fixed-Deposit-Account(AcctID, name, balance, interest-rate, start-date, maturity-date)
Checking-Account(AcctID, name, balance, overdraft-limit)
Nota: the primary keys are independent from each others, we can have a
Fixed-Deposit-Account with acctID=1 as well as a Checking-Account with acctID=1

Solution #4: Different tables with one table for shared attributes
Account(AcctID, name, balance, [account-type])
Fixed-Deposit-Account(#AcctID, interest-rate, start-date, maturity-date)
Checking-Account(#AcctID, overdraft-limit)
31
Examples of ERD slide#18 → DB Logical Schema
Solution #1: One single Table
Person(ID, name, street, city, tot-credits, salary, rank, hpw)
employee/student specialization is overlapping: a student
might be employee
Instructor/secretary specialization is disjoint
/!\ Integrity
EITHER Secretary: rank = null and hpw  null OR
Instructor rank  null and hpw = null

Solution #2: One single Table and we add Person Type attribute
Person(ID, name, street, city, type, tot-credits, salary, rank, hpw)
Type: emp-student-instructor, emp-student-secretary, secretary, instructor,
/!\ Integrity
EITHER Secretary: rank = null and hpw  null OR Instructor: rank  null and hpw = null
If type = emp-student-instructor or type = instructor then rank  null and hpw = null
Else if type = emp-student-secretary or type = secretary then rank = null and hpw  null

32
Examples of ERD slide#18 → DB Logical Schema

Solution #3: Different tables

Student(ID, name, street, city, tot-credits)
Instructor(ID, name, street, city, salary, rank)
Secretary(ID, name, street, city, hpw)

Solution #4: Different tables and one table with shared attributes
Person(ID, name, street, city)
Student(#ID, tot-credits)
Instructor(#ID, salary, rank)
Secretary(#ID, hpw)

33
Examples of ERD slide#20 → DB Logical Schema

Customer(C-ID, credit, discount, balance)

Address(A-ID, address)
Customer-Address(#C-ID, #A-ID)
Order(O-ID, #C-ID, date, #ship-to-Adress-ID)
Item(I-ID, description)
OrderLine(#O-ID, #I-ID, quantity, outstanding-quantity)
Warehouse(W-ID, #addressID)
Item-in-Warehouse(#I-ID, #W-ID, quantity, SDL)

34
Examples of ERD slide#21 → DB Logical Schema
Ship-Mvt(#ship-name, timestamp, lon, lat, )
Ship-Type(type, tonnage, Hull)
Ship(ship-name, owner, #home-port, #type)
Port(port-name, #SC-name, #SOL-name) /!\ minimal PK
Visit(#ship-name, #port-name, #port-SC, startD, endD)/!\ minimal PK
SC(name, continent)
SOL(name)

35
Examples of ERD slide#22 → DB Logical Schema

Location(loc-name)
Department(d-name, number, nbr-of-emp, #manager-ssn, startdate-mgmt)
Dept-Loc(#loc-name, #dept-name)
Employee(Ssn, bdate, fname, Miit, lname, adr, sal, sex, #boss-ssn)
Dependent(name, #Ssn, sex, birth-date, relationship)
Project(proj-number, name, #loc-name)
36 Works(#Ssn,#proj-number, hours)
References
● P. Chen, “The Entity-Relationship Model: Toward a Unified View of
Data”, ACM Transactions on Database Systems, Volume 1, Number
1 (1976), pages 9–36.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.526.369
&rep=rep1&type=pdf

● T. W. Ling: Database schema design using Entity-Relationship

approach https://www.comp.nus.edu.sg/~lingtw/cs4221/er.pdf
● A. Silberschatz, H. F. Korth and S. Sudarshan: Database System
Concepts, Mc Graw Hill Education, 7th Edition 2020.
● H. Garcia-Molina, J. Ullman and J. Widom: Database Systems -the
complete book, 3rd edition, Prentice Hall 2008
● R. Elmasri and S. B. Navathe, Fundamentals of Database Systems,
7th edition, Addison Wesley 2015.

37