1. Conceptual database design ERD’s
Conceptual DB Design
Conceptual database design
ERD’s

2. Relationship Meaningful associations among entities
We draw the “relationship type”—the abstract set of associations
Faculty teach Course
Patient has_a Lab_result
Relationship occurrence (Relationship Instance)—the specific relationship between two entity instances
Sward teaches N6803
ERD diagram shows the general (relationship type) but you might need to think about instances to decide the general cardinality

3. Diagramming a Relationship
One line between entities. Line does not have arrows
Label with a verb or short phrase
Relationships documented in both directions
UML typically labels in only one direction
But sometimes it’s not clear which direction the verb is describing
I want you to label verb BOTH directions

4. Diagramming a Relationship
Relationship is ONE straight line, no arrows.
Show both directions of relationship -
Above and below the line have name (verb) and arrow
The numbers in parentheses are cardinality. I’ll explain that soon.

5. Relationship Read the relationship in the direction of the arrows
student takes  class reads left to right: student takes class
student  has class is read right to left: “class has students”

6. Drawing tip
Try to be consistent in drawing the relationship—for example, top of relationship read left to right and bottom read right to left; for vertical relationships might put left side read bottom to top and right side read top to bottom.
The goal is clarity and readability of the design—don’t want to have to flip the diagram around multiple times in order to read it!

7. Structural Constraints
Cardinality
Minimum and maximum number of instances that can participate in a relationship
How many instances (rows) of an entity might relate to ONE instance of another entity

8. Cardinality - minimum
Think about person and vital signs in the SNDB database
Does every person HAVE to have a row in the vital signs table?
If I think of ONE generic person, how many vital signs can they have?
For ONE row in my vitals table, how many people can that set of vital signs belong to?

9. Cardinality - minimum Person has Vitals
Does every person HAVE to have a row in the vital signs table?
If it is possible that a person might not have any vital signs recorded, then the minimum cardinality is 0. 0 means a person might not have a row in the vital signs table.
If every person must have an entry in the vital signs table, then the minimum cardinality is 1.
Person in SNDB has vital signs, minimum cardinality is 0

10. Cardinality - minimum Vitals belong to Person
Now think about the relationship the other direction. If you choose a row in the vital signs table is it possible that this row does not match any person?
If you can have vital signs without belonging to a person, the minimum is 0
If every vital sign entry must belong to a person in the demog table, the minimum cardinality is 1.
In the SNDB, vital signs belong to person relationship, minimum cardinality that direction is 1

11. Cardinality - maximum
Think about person and vital signs in the SNDB database
If I think of ONE person, what is the most number of vital signs can they have?
If I think of ONE row in my vitals table, what is the most number of people that set of vital signs can belong to?

12. Cardinality - maximum Person has Vitals
Is it possible the person could have more than one record in the vital signs table?
If no, maximum cardinality is 1
If yes, maximum cardinality is Many (shown as M, N, or *)
A person in SNDB can have multiple vital signs, so maximum cardinality is M

13. Cardinality - maximum Vitals belong to Person
Now think about the relationship the other direction. If you choose a row in the vital signs table is it possible that this row would match more than one person?
If no, maximum cardinality is 1
If yes, maximum cardinality is Many (shown as M, N, or *)
In the SNDB, vital signs belong to person relationship, maximum cardinality that direction is 1

14. Cardinalities review Minimum Cardinality Maximum Cardinality
Fewest number that can be associated with other entity (your choices are 0 or 1)
Maximum Cardinality
Largest number that can be associated with other entity (your choices are 1 or M)
Establish BOTH directions of the relationship
Notation is (min,max)  note the COMMA here comma is read as “and”
For this class and in most cases, the only choices for minimum cardinality are 0 and 1. The only choices for maximum are 1 and M.
UML has an exception
UML allows specific range (2..3) or single number (Newborn has exactly 2 ApgarScore). We generally don’t model this way for this course but it can be helpful when deciding whether to denormalize a design, such as for performance reasons. For example, if we know newborn always has exactly 2 Apgar scores we may choose to flatten the design and put Apgar1 and Apgar5 (one-minute and 5-minute score) as two attributes of the newborn table.

15. Examples of Cardinalities
Person has vitals
Person may not have any vital signs min =0
Person may have multiple vital signs max =M
Person has (0,M) vitals
Vitals belong to person
A row in the vitals table must belong to a person min = 1
Each row belongs to ONLY one person max = 1
Vitals belong to (1,1) person
Many is represented as * or M or N
Read cardinalities as X and Y NOT X to Y. Relationships are X to Y

16. Cardinalities On diagram, put in parentheses after the point of arrow
Takes --> (0,N) Student could take no classes, might take many classes
(0,N) <-- Has Class might have no students, could have many students
For this course, and in most cases, minimum cardinality is 0 or 1 ONLY. Maximum cardinality is 1 or M(N, *) ONLY.

17. Details, details, details
Use a comma (X,Y) for our ERD
Your book uses two dots (X..Y)
Read as X and Y. You’d read (1,*) as “one and many”
Place by the entity to which the cardinality refers (read the direction of the arrow)
Patient has  (0,*) Allergy
(1,1)  belongs to
Each patient has (min of 0 and up to many) allergies Each allergy belongs to 1 and only 1 patient

18. Cardinality and Participation
Unfortunately, the terminology can be confusing
Some authors say minimum and maximum cardinality. We use this verbiage.
Connolley and Begg use “cardinality” for the maximum and “participation” for the minimum
Other authors use “optional” and “mandatory” for the minimum (0=optional, 1 = mandatory)

19. Cardinality Placement
Look Here Notation
Client has many visits Client (0,*) has Visit
Look Across Notation
Client has many visits Client has (0,*) Visit
Classic ERD cardinality is placed by the “first” entity when you read the relationship
Client has 0 and many visits, the 0,* goes near client
UML and This class Cardinality is placed after the verb. Reads like English: subject, verb, [cardinality], object Client has 0 and many visits
For example, placement of cardinalities varies. Storey (in your ref list, 1991) uses Look Here notation
Client has Visit
(0,*) (1,1)
Chen (one of the first to propose ERD, 1976) uses Look Across notation
I don’t care if you remember what it’s called. Just be consistent on your diagram. You will need to know when we get to logical design which direction is which for the cardinality. I prefer to use the Look Across method for this course because it makes the ERD “read” in a more intuitive left-to-right manner and doesn’t require “criss-crossing” the cardinality to determine the relationship type.

20. Relationship Degree Number of entities participating in a relationship
Binary = two entities
Unary (AKA Recursive AKA Ring) = one entity
Ternary (3 entities), N-ary (3 or more…)

21. Binary Relationships Most common. Two entities SalaryHistory Employee
EmployeeID
Name …
SalaryHistory
EmployeeID
DateOfChange …
has  (1,*)
(1,1)  belongs to

22. Recursive (Unary) Single entity
Two rows in the same table are connected to each other in some manner, with different ROLES
for example, an employees table might link individual employees to their manger
Use one line, but two verbs and two cardinalities

23. Recursive Relationships
Different rows in same table related via different roles
manages  (0,*)
(1,1)  reports to
A role is the “purpose” of the entity in the relationship—for example, in the above example the employee might be a MANAGER or might be a STAFF
Employee
EmployeeID
Name …

24. Dealing with Recursives
Think of the relationship “unfolded” !
Employee (Manager)
EmployeeID
Name …
manages  (0,*)
(1,1)  reports to
Employee (staff)
EmployeeID
Name …
We only draw the entity
ONCE on the ERD because of the
principle of minimality

25. Ternary, N-ary
Sometimes it takes more than 2 entities to describe a relationship (books used by a teacher in a class)
Called an N-ary relationship (N = any number of entities; sometimes specified as ternary etc, but more often described as N-ary)

26. N-ary Cardinalities
Exception to our cardinality placement rules! Establish cardinality one way for each entity.
Course
CourseID …
Faculty
EmplId …
(1, *)
(1,*)
(0,*)
This is the place where we make an exception to the cardinality rules. For each one entity, look at the cardinality if we have ONE of EACH of the other entities. I find this easiest to do if I instantiate the entity—create a sample with pretend data.
Fac_Course_Book
Sward, N6803, Connolly & Begg
Sward, N6803, SQL handbook
Konefal, N6803, Connolly & Begg
Thompson, N6803, McFadden et al
For one book/one course (Connolly & Begg, N6803) there is 1..* faculty (me and irek)
For one faculty/one course (Sward, N6803) there is 0,* books
For one faculty/one book could be matched together in 1,* courses (Marge Pett uses APA book in multiple courses)
Another example:
Preceptor precepts Student for a Course
(1,*) (0,*) (1,*)
Student can have multiple preceptors for a given course
Student can pair up with the same preceptor for a different course
Preceptor has multiple students for the same course
PreceptorStudent table:
StudentPID, PreceptorPID, CourseID (all are keys)
Imagine you have one faculty and one course. How many books can you have (min and max)? Now imagine you have one book and one course, how many faculty match that?...
Book
ISBN
BookTitle …

27. HW - Cardinalities
Each employee reports to 1 manager. A manager might not have any employees (new manager), or they might have several. Recursive. Employee reports to (1,1) manager; manager has (0,*) employees
Each employee has at least 1 salary history record (they might have more, they get a new record every time they make a change). Each record in the Salary table belongs to 1 employee. Binary. Employee has (1,*) salary history; salary history belongs to (1,1) employee
Etc.

28. ERD Thoughts
Is it possible for an entity to not be related to any other entity?
Yes, but it’s rare
Draw as an isolated entity with no relationships
Can entities be related more than once?
Yes, if the relationships have different meanings
There are roles associated with the separate meanings

29. Two relationships, same entities
Draw this way
on the ERD— two relationship lines but each entity appears only once.
Principle of
Minimality
You can have more than one relationship between the same two entities.
Two relationship lines implies that these are two separate relationships! Each relationship will be dealt with individually in logical design.