1. Database Analysis and Data Modeling
Well done, is better than well said.
~ Benjamin Franklin ~

2. Where are we? SDLC / DBDLC Data Analysis and Conceptual Modeling
I Planning
II Analysis
III Design
IV Implementation
V Maintenance & Support
Time
Resources
Conceptual Model
Logical Model
Internal / External Model
SDLC / DBDLC
Physical Model
Data Analysis and Conceptual Modeling

4. Chen –vs- Crow’s Foot Models
Figure 3.6

5. Attribute Examples Vehicle Unique Identifier (PK Candidate)
VIN [U] Make [R]
Model
ManufYear Age [D] EngineDetail [C] Color [M]
Required
Derived Attribute (Calc from ManufYear)
Composite Attribute (HP, NumCyls, CC)
Multi-valued Attribute (White with Blue Trim)

6. Example: Cardinality 1-1 1-M M-N
Read in both directions! A resident possesses a DL or they don’t. A drivers license is possessed by one and only one Resident.
A Resident registers zero or more Vehicles, a Vehicle is owned by one and only one resident.
A Driver is Licensed to drive one or more vehicles, A vehicle is licensed to be driven by one or more drivers.
Here are examples of the three basic relationship cardnalities. It should be noted how to read these diagrams properly:
For example:
A resident possessed one and only one DriversLicense, A drivers license is possessed by one and only one Resident.
A Resident owns one or more Vehicles, a Vehicle is owned by one and only one resident.
A Driver is Licensed to drive one or more vehicles, A vehicle is licensed to be driven by one or more drivers.

7. Example: Relationship Strength
Identifying Relationship
Existence-Dependent
Composite Identifier (PK)
BBPlayer is weak entity
“Player must be on a team”
Non-Identifying Relationship
Existence-Independent
BBPLayer is not weak
Here a way to help you remember: “A weaker line is dashed, a stronger line is solid.”
In General it is safer and to make all relationships non-identifying. This means your database will be more “accommodating” because it will optional on the many side of the relationship. Identifying relationships are only used when the requirements deem it so.
Suppose we were making a database for basketball intramurals.
In this case, the rules of the league would be you can’t be a player without being on a team, thus we’d model a strong relationship.
If we were modeling the NBA, we’d have lots of players who played one year, but were cut the next. In this case we would model a weak relationship. This would allow us to maintain a bit list of players, many of which are not on an NBA roster.
“Player need not be on a team”
Any relationship can be made Strong/Weak How and Why Depend on the Requirements!

8. Weak Entity Existence-dependent on another entity
A Strong Relationship produces a weak entity
Has primary key that is partially or totally
derived from parent entity
Beveled
Corners
You can’t have a dependent without a corresponding employee.
Note: You can’t do the beveled corners in Visio, so we will rely on the fact that the diagram depicts the relationship with a sold line for identifying weak entities.
Figure 3.19

9. Example: Composite Entity
Attributes
Employee may or may not participate
How do we represent the position the employee holds on the project committee?
Employee may or may not participate
Read the top one As:
An Employee participates on zero or more project committees, a project committee contains 1 or more employees.

10. Example: Relationship Degree
Unary
Binary
Ternary
Unary relationships are always existence independent. How can
Ternary relationships are always existence dependent and the “relationship” is always a weak entity. Always consists of binary relationships
FilmEvent is actually an associative (weak) entity because it cannot exist without the other three.

11. Recursive Relationships
The relationship exists between occurrences of same entity set (unary relationships)

12. Entity Sub-Type / Super-Type
Two Distinctions:
d = disjoint
o=overlap
Helps Depict “Is a” “part of” relationships.
Empno
Lname
Fname
DOB
Address
Employee d
Rate
Hourly
AnnualPay
StockOptns
Salaried

13. 3x5 Approach to ERD Write Entity on 3x5 card Write Attributes on back
Helps with entity placement issues in your diagram (esp. large ones)

14. ERD Design Methodology
Identify Entities
Identify Attributes for each Entity
For each Attribute identify the Attribute Type [C],[M],[D],[R],[U]
Identify Relationships / Bus. Rules
Establish Cardinality 1-1,1-M,M-M
Establish Participation for each end 0/1
Work Out Relationships
Sub-Type/Super-Type (is-a/has-a)
Establish Weak Entities in 1-M
Resolve M-M’s with Data (Assoc. / Comp. Entities)

15. Exercises Can you draw this diagram?
Can you establish these requirements and then draw the diagram?

16. Entity-Relationship Modeling
Questions?