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

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

Chen –vs- Crow’s Foot Models Figure 3.6

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)

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.

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!

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

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.

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.

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

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

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

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)

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

Entity-Relationship Modeling Questions?