1. Entity Relationship Diagram
Chapter 4 PART 1 pp

2. Domain Modeling Define system requirements by:
understanding “things” (within the problem domain) that needs to be stored
Domain Modeling Techniques
Entity Relationship Diagram (ERD) – Ch 9 part1
Domain Class Diagram – Ch 9 part2

3. Entity Relationship Diagram
ERD
a data modeling technique
Used to later build the database

4. ERD: Entity Entity A noun - person, place, object, event, etc.
Which “Things”?
Within our scope &
We need to remember it!

5. ERD: Attributes Attribute A characteristic
Information about the entity that is within the scope
Attribute Type
Examples
Atomic/Simple
JobTitle, Salary
Composite
Name, Address
Derived
Age, TotalPay
Separate Address: StreetAddr, City, State, Zip
But don't separate StreetAddr  houseNo & streetName

6. ERD: Primary Key
An attribute (or a group of attributes) that uniquely identifies an instance
Every entity must have a Primary Key!
3 Rules for a good Primary Key is…
Unique - no duplicate values
Required - cannot be null
Static - does not change (e.g. build name – poor PK)
Tip: Try to match the PK name with the Entity Name
Order  OrderNo
Dept  DeptCode

7. ERD: Other Terms Candidate Key Natural Key vs. Surrogate Key
Multiple unique attributes may exist, if so pick the attribute that is used most often.
Natural Key vs. Surrogate Key
ENTITY: Building
PRIMARY KEY: BuildingName
ISSUE: BuildingName is unique but its value may change over time.
SOLUTION: add a Surrogate Key: BuildingID
Surrogate Key - an auto-generated integer defined as the Primary Key.
Non-Key Attribute
Any attribute that is not part of the primary key

8. ERD: Relationships Relationship An association between entities
Represents a "NEED TO KNOW the relationship" between the instances of each entity
Occurs in two directions
Left to Right: A Department employs _?_ Employees
Right to Left: An Employee is employed by _?_ Department

9. ERD: Relationships Cardinality - # of associations between instances
Min:
zero - optional
one - mandatory
Max:
one
many
Cardinality - # of associations between instances

10. ERD: Relationships Type of Relationship
Determined by the _____________ Cardinalities
One to One
One to Many
Many to Many

11. ERD: Relationships Be careful with mandatory 1’s on both sides
Can have >1 relationship between the same 2 entities
Thus, Use precise relationship names!
Add the cardinalities

12. Practice: ERD Academic Department "employs" Student "is member of"
Student Organization is "sponsored by"
Course is "offered by"
Course "has"
Faculty "teaches"
Student "registers for"
Faculty – anyone who teaches
and/or does research
Student Organization
Student
Academic Department
Course
Faculty
CourseSection CRN -PK

13. Associative Entity Where do we place the following attributes?
Example 1: Employee and Project
Add StartDate – the date an employee started working on a project
Example 2: Employee and SkillType
Add ProfLevel – how proficient is the employee at that skill
Example 3: Student and CourseSection
Note: CourseSection’s PK is CRN (and assume CRN is unique & never reused)
Add Grade – the grade that a student made in a particular section

14. Associative Entity – the steps
Adding an Associative Entity
Know when to add an associative entity
Name the new entity appropriately
Determine the concatenated PK
Determine the cardinalities
Add any non-key attributes

15. Associative Entity Assume these are annual awards &
a student can receive a particular
award more than once.
Is there an issue with this design?

16. Associative Entity
This design resolves the issue: Students can receive a particular annual award more than once.
FYI…Anytime you need to keep a log , or historical account of something you may have to add some type of date field (year, semester, or a full date for daily logs) to the primary key.

17. ABC Office Furniture - Order Form
For office use only:
Order no: ______
Date: __________
A business object is not always = 1 Entity It may require more!

18. ABC Office Furniture - Order Form
The data needs may differ from one organization to another.

19. What’s wrong with this ERD?
Textbook Fig 4-8

20. Multi-Valued Attributes
Rule of Atomic Values - no multi-values attributes
Employee Table
EmpID
LastName
FirstName
Title
DepNames
111
Smith
Robert
Accountant
Bobbie, Sue
222
Jones
Leo
Programmer
333
Lopez
Trent
Sales Rep
Trent Jr., Trevor, Sue
444
Miller
Anne
Mike
Assume we need to store data about dependents for medical benefits purposes.
Issue?

21. Multi-Valued Attributes
Resolution!
PK?
Employee Table
EmpID
LastName
FirstName
Title
111
Smith
Robert
Accountant
222
Jones
Leo
Programmer
333
Lopez
Trent
Sales Rep
444
Miller
Anne
Dependents Table
EmpID
DepName
111
Bobbie
Sue
333
Trent Jr.
Trevor
444
Mike
Assume a dependent is carried on only one parent/guardian’s policy.

22. Multi-Valued Attributes
Sometimes we resolve the multi-valued attribute…
…and then later notice that there are actually more attributes.

23. Understand these entities …
general
specific

24. ERD: Degree of the Relationship
Refers to how many ___________ participate in the relationship.
Unary Relationship (aka: Recursive Relationship)
Binary Relationship
Ternary Relationship
n-ary Relationship

25. Review ERD Tips

26. ERD General Tips Entities Primary Keys
Reminder & Tips
For example…
Entities
Entity name - use a singular name
Employee  not Employees
An entity with only one instance should not be modeled!
We would model an entity called Student which would have over 17,000 instances (i.e. students)
We would NOT model an entity called Baylor as it would just have one instance.
Primary Keys
Primary keys are Required!!
All entities must have a primary key attribute denoted.
A good primary key…
must be unique
must always have a value
doesn't change over time
These are not good PKs:
Name  may have duplicates
SSN  everyone may not have a SSN
BuildingName  it may be renamed
A good primary key name:
should match the entity name
Use the Entity name and append: ID, No, Code, etc
Employee  EmployeeNo
Student  StudentID 26

27. ERD General Tips Attributes A good attribute name… specific name
Reminder & Tips
For example…
Attributes
A good attribute name…
specific name
don’t add entity in the name
startDate  not date
startDate  not employeeStartDate
No Composite attributes!
No: address  Yes: address, city, state, zip
No: name  Yes: firstName, lastName
No Derived attributes!
No: totalPay  Yes: hoursWorked, payRate
No: age  Yes: BirthDate
No Redundancies!
Someone’s birthdate should appear in only one place in the entire ERD. Repeating that fact is redundancy! 27

28. ERD General Tips Relationships Miscellaneous
Reminder & Tips
For example…
Relationships
In Analysis, only resolve a many-to-many when there is a non-key attribute.
Otherwise, the model will be unnecessarily busy. In Design, however, we will resolve all many-to-many’s.
Name all Relationships (even on associatives)
Be careful with mandatory one-to-one relationships
In this case A & B may be the same concept. If so, use one entity!
Miscellaneous
Report/Form is usually >1 entity
Order Form  may need 4 entities 28