1. (C) 2000, The University of Michigan 1 Database Application Design Handout #3 January 21, 2000

2. (C) 2000, The University of Michigan 2 Course information Instructor: Dragomir R. Radev (radev@si.umich.edu) Office: 305A, West Hall Phone: 615-5225 Office hours: Thursdays 3-4 and Fridays 1-2 Course page: http://www.si.umich.edu/~radev/654w00 Meeting time: Fridays, 2:30 - 5:30 PM, 311 WH

3. (C) 2000, The University of Michigan 3 The entity-relationship model (cont’d)

4. (C) 2000, The University of Michigan 4 Recursive relationships DORMITORY 1:N ROOMS-WITH O O

5. (C) 2000, The University of Michigan 5 Showing properties Properties can be related to entities or to relationships. Example…

6. (C) 2000, The University of Michigan 6 Weak and strong entities Weak entities: cannot exist in DB unless other entities exist. Employee vs. dependent. EMPLOYEE DEPENDENT 1:N EMPLOYEE-DEPENDENT |O

7. (C) 2000, The University of Michigan 7 ID-dependent entities Entity in which the identifier of one entity includes the identifier of another entity Example: BUILDING - APARTMENT Identifier of apartment is [BuildingName, ApartmentName] PRODUCT - VERSION, TITLE - EDITION NUMBER

8. (C) 2000, The University of Michigan 8 More on weak entities STUDENT - ADVISOR (?) Logical dependency. PATIENT - PRESCRIPTION (?) Not all entities that have a minimum cardinality of 1 in relationship to another entity are weak.

9. (C) 2000, The University of Michigan 9 Subtype entities CLIENT can be INDIVIDUAL-CLIENT, PARTNERSHIP-CLIENT, or CORPORATE-CLIENT Generalization hierarchies IS-A relationships

10. (C) 2000, The University of Michigan 10 IS-A relationships CLIENT INDIVIDUAL CLIENT PARTNERSHIP CLIENT CORPORATE CLIENT 1 

11. (C) 2000, The University of Michigan 11 Example E-R Diagram Example: engineering company that analyzes the construction and condition of houses and other buildings and facilities. Entities: Employee, Engineer, Truck, Service, Client, Certification Relationships: Truck-Assgn, Eng-Skill, Qual- Engineer, Client-Service, Service-Provider, Referred-By Properties: Fee

12. (C) 2000, The University of Michigan 12 Documentation of business rules DB schema: tables, relationships, domains, business rules - the first three can be inferred from the E-R model, but not the business rules. Different ways to enforce business rules (even manual). Still at design stage...

13. (C) 2000, The University of Michigan 13 Example 1 The Jefferson Dance Club (page 60) Entities? Relationships? What are some design choices??

14. (C) 2000, The University of Michigan 14 Example 1 (cont’d) Evaluating E-R Data Models Queries: –Who has taught which private lessons? –Which customers have taken a private lesson from Jack? –Who are the full-time teachers? –Which teachers are scheduled to attend the dance on Friday?

15. (C) 2000, The University of Michigan 15 Example 2 San Juan Sailboat Charters How to select entities? Hint: look for nouns How to choose among alternatives?

16. (C) 2000, The University of Michigan 16 The relational model and normalization

17. (C) 2000, The University of Michigan 17 Background Abstraction Portability Ubiquity

18. (C) 2000, The University of Michigan 18 The relational model Relations (2-D tables) Tuples, attributes Functional dependencies Example: TotalPrice = ItemPrice x Quantity Notation: ID  Major Determinants: expressions on the LHS

19. (C) 2000, The University of Michigan 19 Groups of attributes as FD (ID, ClassName)  Grade Two cases: –If X  (Y,Z) then X  Y and X  Z –If (X,Y)  Z, nothing can be derived

20. (C) 2000, The University of Michigan 20 Keys Key: group of attributes that uniquely identifies a row. Example: (ID) vs (ID, Activity) FDs are determined by mental models of the users! Need to ask users! Determinants are not always unique. Keys are!

21. (C) 2000, The University of Michigan 21 Normalization Modification anomalies –deletion anomaly –insertion anomaly Splitting relations When can splitting a relation create problems? –E.g., student signing up for a non-existing activity –Referential integrity constraints

22. (C) 2000, The University of Michigan 22 Normal forms Codd (1970) - 1NF, 2NF, 3NF Boyce and Codd - BCNF later - 4NF and 5NF Not all anomalies are eliminated! Fagin (1981) - domain/key normal form (DK/NF)

23. (C) 2000, The University of Michigan 23 Relationship among normal forms 1NF 2NF 3NF BCNF 4NF 5NF

24. (C) 2000, The University of Michigan 24 First normal form (1NF) Relation Cells are of single value Repeating groups or arrays are not allowed as values Columns must have unique names Order of columns is insignificant No two rows may be exactly the same Order of rows is insignificant

25. (C) 2000, The University of Michigan 25 Second normal form (2NF) Key: (ID, Activity) Dependency: Activity  Fee Determinant (Activity) is only part of the key. Fee is partially dependent on the key of the table. Definition of 2NF: all nonkey attributes are dependent on all of the key! Of concern only in relations with composite keys!

26. (C) 2000, The University of Michigan 26 Readings for next time Kroenke –Chapter 5: The relational model and normalization –Chapter 6: Database design using Entity-Relationship models YRK (optional) –Chapter 3: Installation (MySQL preferred) –Chapter 4: MySQL or Chapter 5: mSQL –Chapter 6: SQL according to MySQL and mSQL