The document discusses the entity-relationship (ER) model and its components, including entities, attributes, and relationships, providing an overview of how to translate diagrammatic models to relational schemas. Key concepts such as cardinality, participation constraints, and the role of weak entities are explained, along with specific examples of relationships between entities. It emphasizes the importance of systematizing database design and ensuring integrity constraints are maintained within the schema.

1. 1
More on Data Modeling
The Entity-Relationship (ER) Model

2. 2
Sid Cid Grade
Enrolled
Sid Name Login Age Gpa
Students
How do we come up with the right set of tables?
• Can be subjective but helpful to systematize
• Start from a diagrammatic model and then
translate to a relational model
• Diagrammatic model: E-R Model

3. 3
Overview of Database Design
› Conceptual design: (ER Modeling typical)
– What are the entities and relationships in the
enterprise?
– What information about these entities and
relationships should we store in the database?
– What are the integrity constraints or business rules
that hold?
– A database `schema’ in the ER Model can be
represented pictorially (ER diagrams).
– Can map an ER diagram into a conceptual/logical
schema (relational schema).
› ****Followed by schema refinements, physical
db design, application and security design.

4. 4
ER Model Basics
› Entity: Real-world object distinguishable from other
objects. An entity is described (in DB) using a set of
attributes.
› Entity Set: A collection of similar entities. e.g., all
employees.
– All entities in an entity set have the same set of attributes.
(Until we consider ISA hierarchies, anyway!)
– Each entity set has a key. (underlined)
– Each attribute has a domain. (set of possible values)
Employees
ssn
name
lot

5. 5
ER Model Basics (Contd.)
› Relationship: an association among two or
more entities.
– e.g., Attishoo works in the Pharmacy department.
› An n-ary relationship connects n entities
–(e1, e2, .., en)
– In above example n = 2, (Attishoo, PharmDept)
› Relationship Set: collection of similar
relationships.
– Can have attributes
– Key is a subset of combination of entity keys

6. 6
ER Model Basics – Relationship Sets
› Since is an attribute of relationship
› Key for relationship set (for now) is (ssn,
did)
– i.e. combination of keys of all participating
entities
› WorksIn(ssn, did, since)
– we shall revise this to allow only a subset (under
certain conditions)
lot
dname
budget
did
since
name
Works_In Departments
Employees
ssn

7. 7
ER MODEL BASICS
(CONTD.)
Same entity set
could:
• participate in different
relationship sets
• or in different “roles”
in same set
unique attr name =
role indicators + attr
name
• e.g. supervisorssn
Reports_To
lot
name
Employees
subor-
dinate
super-
visor
ssn
Reports_To (e1, e2)
Reports_To (supervisorssn, subordinatessn

8. 8
Relationship Constraints
lot
dname
budget
did
since
name
Works_In Departments
Employees
ssn
Many-to-Many
1-to-1 1-to Many Many-to-1

9. 9
Relationship observations
• Bidirectional i.e. two directions
• Constraints in either direction are independent
• Constraints for each direction have a min and max
• How many times is A associated with B in this relationship
• And vice versa
A B A B

10. 10
Relationship Constraints
lot
dname
budget
did
since
name
Works_In Departments
Employees
ssn
Many-to-Many
1-to-1 1-to Many Many-to-1
M M

11. Key Constraints (2)
› So far this diagram says:
– An employee can work in many departments or none
– A dept can have many employees.
lot
dname
budget
did
since
name
Works_In Departments
Employees
ssn

12. 12
Key Constraints (3)
› Now lets revise it to say:
– A dept has at most one manager
› A dept can occur only once in any valid Manages
instance
› We call this a Key constraint on Manages
dname
budget
did
since
lot
name
ssn
Manages
Employees Departments
1 ?
Did Eid
d1 e1
d1 e2
d2 e1
Manages

13. 13
Participation Constraints: Total vs Partial
› Does every department have a manager?
– YES :– total (at least one)
› Every did value in Departments table must appear in
a row of the Manages table (with a non-null ssn
value!)
– No :- partial
Did Eid
d1 e1
d1 e2
d2 e1
Did Dname
d1 CSC
d2 ECE
d3 NE
Departments Manages
Partial Participation

14. 14
Notation for Relationship Cardinality
Constraints (different in different texts)
› Each employee should have at least one dept but at
most two
› Each dept can zero to unlimited number of
employees
dname
budget
did
since
lot
name
ssn
Manages
Employees Departments
0..* 1..2

15. 15
Different notations (zyBooks circled)

16. 16
zyBooks notation comments
I will use a superset of zyBooks’s notation!!
e.g. explicit diamond for relationship.
Key!! (underline)

17. 17
Participation Constraints
(zyBooks: Relationship Minima and Maxima)
› A dept has at most one manager
– the maxima of participation of Departments in Manages
is 1.
– The minima of participation of Departments in Manages
is 0 (not every)
› No constraints for Emp in Manages
lot
name dname
budget
did
since
name dname
budget
did
since
Manages
Employees
ssn
Departments
minimum
maximum

18. 18
Participation Constraints contd
(zyBooks: Relationship Minima and Maxima)
› Every dept has at most one manager
– the maxima of participation of Departments in Manages
is 1.
– The minima of participation of Departments in Manages
is 1 (not every)
lot
name dname
budget
did
since
name dname
budget
did
since
Manages
Employees
ssn
Departments
new minimum

19. 19
Relationship Minima and Maxima contd.
› Every department has at most one manager in
manages relationship
› An employee can work in one or more
departments
– silent about minima and maxima of departments so
we assume 0 or more
lot
name dname
budget
did
since
name dname
budget
did
since
Manages
since
Employees
ssn
Works_In
Departments

20. Weak Entities
› Employees have insurance policy for Dependents.
› How do we model this?
– Dependents be an entity with an emp attribute
capturing who they are related to PLUS
– a relationship EmpDep to Employee?
› Then EmpDep will pretty much redundant since information
it records is already in Dependent
– No relationship, just keep the Dependent entity with
the emp attribute
› Then a relationship with another entity is implicit in attribute
which is undesirable
– Don’t add the emp attribute to Dependent
› Then the link between Employee and Dependent is broken
20

21. Weak Entities
› A weak entity can be identified uniquely only by
considering the primary key of another (owner)
entity.
– Owner/identifying entity set and weak entity set must
participate in a one-to-many relationship set
› (one owner, many weak entities).
– Weak entity set must have total participation in an
identifying relationship set.
21
lot
name
age
pname
Dependents
Employees
ssn
Policy
cost
Combines minima and maxima notations into a single symbol