1. Yong Choi School of Business CSUB
Data Modeling 2
Yong Choi
School of Business
CSUB

2. Steps for creating an ERD
Identify the entities
Look for singular nouns (in real world situation, avoid noun w/o attributes)
Also avoid proper nouns
Identify the attributes
Look for entity characteristics or properties
Identify the relationships
Look for verb (between entities)

3. Entities??? Using original Chen’s notation
Made up for the class…….ambiguous…
Using original Chen’s notation
ANG Laboratory has several chemists who work on one or more projects. Chemists also may use certain kinds of equipment on each project. The organization would like to store the chemist’s employee identification number, his/her name, up to three phone numbers, his/her project identification number and the date on which the project started. Every piece of equipment, the chemist uses, has a serial number and a cost.

4. Entities
Project
Chemist
Equipment

5. Entities’ Attributes???
ANG Laboratory has several chemists who work on one or more projects. Chemists also may use certain kinds of equipment on each project. The organization would like to store the chemist’s employee identification number, his/her name, up to three phone numbers, his/her project identification number and the date on which the project started. Every piece of equipment, the chemist uses, has a serial number and a cost.

6. entities, attributes and identifiers
Chemist
Phone#
Emp#
Project
Proj#
Start-Date
Equipment
Serial#
cost

7. Relationships ???
ANG Laboratory has several chemists who work on one or more projects. Chemists also may use certain kinds of equipment on each project. The organization would like to store the chemist’s employee identification number, his/her name, up to three phone numbers, his/her project identification number and the date on which the project started. Every piece of equipment, the chemist uses, has a serial number and a cost.

8. Entities/Relationships & their Attributes
Start-Date
Proj#
Works-On
Project
Phone#
Emp#
Date-Assigned
Chemist
Uses
Serial#
Equipment
cost
Assign-Date

9. More about Relationship
Description of each relationship should be bidirectional.
Operate in both directions
Relationship between Student and Curriculum
A student is enrolled in many curriculums (student to Curr.).
Each curriculum is being studied by many students (Curr to student).

10. Degree of Relationship
Degree of a Relationship describes the number of entity participation
Unary (Recursive) Relationship: One instance related to another of the same entity type
Binary Relationship: Instances of two different entities related to each other
Ternary Relationship: Instances of three different types related to each other 16

11. Relationships
Entities can be associated with one another in relationships.
Relationship degree defines the number of entity classes participating in the relationship:
Unary relationship.
binary relationship.
ternary relationship.

12. Degree of Relationship …8

13. Unary (recursive) Relationship
It is possible for an entity to have a relationship to itself—this is called a recursive relationship.
Employee
Is supervised by
supervises

14. Binary Relationship

15. Ternary Relationship

16. Cardinality One – to – One (1:1) One – to – Many (1:M)
Each instance in the relationship will have exactly one related member on the other side
One – to – Many (1:M)
A instance on one side of the relationship can have many related members on the other side, but a member on the other side will have a maximum of one related instance
Many – to – Many (M:N)
Instances on both sides of the relationship can have many related instances on the other side

17. Optionality
The Optionality is a property of an attribute which specify if a value is mandatory or optional. 
To identify optional relationship, look for auxiliary verb such as can or may

18. Cardinality
The organization would like to store the date the chemist was assigned to the project and the date an equipment item was assigned to a particular chemist working on a particular project. A chemist must be assigned at least to one (or more) project and one (or more) equipment. Projects and equipments must be managed by only one chemist. A given project need not be assigned an equipment.

19. Complete ER Diagram 1 N Project Chemist 1 N Equipment Works-On Uses
Start-Date
Proj#
Works-On 1 N
Project
Phone#
Emp#
Date-Assigned
Chemist
Uses
Serial# 1 N
Equipment
cost
Assign-Date

20. Steps for developing an ERD 2
Identify the entities
Identify the attributes
Identify the relationships
Beginner: look for relationship-type related words and phrases such as zero, none, a, one, several, many…..
Optional relationship: look for auxiliary verbs such as may, might, can and based upon own judgment..)
Finalize business rules

21. Data Model Notation 1-to-1 relationship 1-to-M relationship
M-to-N relationship

22. Data Model Notation

23. Data Model Notation weak entity relationship (see the next slide)
optional relationship
recursive relationship
Employee

24. Weak Entity relationship
A weak entity is an entity that cannot be uniquely identified and existed by itself alone.
Thus, a weak entity is an entity that exists only if it is related to a set of uniquely determined entities (owners of the weak entity).
More examples on the textbook
Each employee might have none or multiple dependents. However, dependents must belong to at least one employee.
EMP
DEP
weak entity notation

25. 1:1 relationship
A person must have one and only one DNA pattern and eac pattern must be applied to one and only one person.
This is a 1:1 mandatory relationship and demonstrates a segmentation denormalization.
This is difficult to implement in a database, since declarative referential integrity will get caught in a "Chicken and the Egg" situation. Basically, this is a single entity.

26. 1:1 with optional relationship (OR) on one side
A person might not or might be a programmer, but a programmer must be a person.
This is a 1:0 relationship; optional only on one side.
It is assumed that the mandatory side of the relationship is the dominant.
Again, triggers or programs must be used to control the database.

27. 1:M relationship
Each department hires many employees, and each employee is hired by one department.

28. 1:M with OR on many side
A person might be a member or might not, but could be found multiple times (if the member entity represents membership in multiple clubs, for instance). A member must have only a single person.
This is a 1:M mandatory relationship, the most common one seen in databases.
A member must be a person, no questions asked. The foreign key in the member table would be mandatory, or not-null.

29. 1:M with OR on both side
A person might have no phone, one phone or lots of phones, and that a phone might be un-owned or can only be owned by a person.
This is a 0:M (zero to many) optional relationship.
This is implemented in a database as a nullable foreign key column in the phone table that references the person table.

30. M:N relationship
Each student takes many classes, and a class must be taken by many students.
STUDENT
CLASS
IS_TAKEN_BY
TAKE
** Many-to-many relationships cannot allowed in the data model because they cannot be represented by the relational model (see the next slide for the reason) **

31. Example M:N Relationship
Table to represent Entity
3 to 3
30 to 30
300 to 300
3000 to 3000
30,000 to 30,000
300, 000 to 300, 000

32. Example of M:N
Many-to-many relationships is a second sign of complex data.
When x relates to many y's and y relates to many x's, it is a many-to-many relationship.
In our example schema, a color swatch can relate to many types of sweaters and a type of sweater can have many color swatches. 

33. Transformation of M:N
When transform to relational model, many redundancies can be generated.
The relational operations become very complex and are likely to cause system efficiency errors and output errors.
Break the M:N down into 1:N and N:1 relationships using bridge entity (weak entity).
CLASS
STUDENT
ENROLL

34. Converting M:N Relationship to Two 1:M Relationships
Bridge Entity

35. Bridge (Associative - textbook) Entity
ENROLL entity becomes a weak entity of both STUDENT entity and CLASS entity
MUST have a composite (unique) identifier
STU_NUM (from STUDENT entity) and CLASS_CODE (from CLASS entity)
Another MUST know M:N example on the textbook page 63 and 64

36. M:N with optionality on both side
A person might or might not work for an employer, but could certainly moonlight for multiple companies. An employer might have no employees, but could have any number of them.
This is a M:M (many to many) optional relationship. Conceptually, it means that
Again, not hard to visualize, but hard to implement. Most solutions of this situation involve creating a third "Associative Entity" to resolve the M:M into two 0:M relationships. This might be an entity called employee because it does link the person to the employer the person works for.
After broken down, optional relationship notation on both side of associative entity

37. Recursive relationship
Each student is taught by a STA (student teaching assistant). Each STA can teach several students.
A recursive relationship is an entity is associated with itself.
Student
teaches
is taught by