1. Database Design Sections 6 & 7 Second Normal Form (2NF), Unique Identifiers (UID), Third Normal Form (3NF), Arcs, Hierarchies and Recursive relationships

2. Capturing Business Requirements  Analyze the document  Assign entities and attributes  Draw entities and attributes  Define relationships between entities

3. 1NF Review  Do a quick review of normalization and First Normal Form (all attributes must be single- valued). Explain that we will cover the second rule of normalization.  First Normal Form (1NF)  First Normal Form requires that there be no multivalued attributes and no repeating groups. To check for First Normal Form, validate that each attribute has a single value for each instance of the entity.

4. 1NF Review  Classroom will have multiple values  This entity is not in First Normal Form SCHOOL BUILDING #code *name *address *classroom

5. 1NF Review – School Building 1NF  Classroom is now its own entity.  All attributes have only one value  Both entities are in First Normal Form SCHOOL BUILDING #code *name *address CLASSROOM #number *floor *size

6. Second Normal Form  Any non-UID attribute must be dependent on the entire UID  All attributes that are not part of the entity’s UID should be dependent on the whole UID. If the attribute changes does the UID also change?  This specifically applies to entities that have a UID that is composed of more than one attribute or a combination of attribute(s) and relationship(s).

7. 2NF Example Customer_id First_Name Last_Name Address City State ZIP If the ZIP code changes does the customer name change? What if the ZIP for a city changes?

8. 2NF Example CUSTOMER.. Zip ZIP city state zip

9. Second normal form violation: TAPE #number *format *rating MOVIE #id *title *category a copy of recorded on TAPE #number *format MOVIE #id *title *category *rating a copy of recorded on

10. Second Normal Form  Every object in an entity must be identified by a unique value.  In an ERD the symbol #id is commonly used for the unique identifier.  UID’s must be unique and NOT NULL.  In practice a number is typically assigned as a UID.  Some UID’s are composites being formed by barred relationships as in intersection entities for M:M relationships.

11. Example Composite UID  Composite UID is made up of two or more attributes together.  In bank example DD 6.5.4  The Bank number (UID in BANK entity) is part of the composite key for ACCOUNT, thus the use of the barred relationship

12. Intersection Entity in M:M EVENT #id *name *date *cost *description SONG #id *title *artist *duration PLAY LIST ITEM *comments for haveon

13. Third Normal Form  The rule of Third Normal Form states that no non-UID attribute can be dependent on another non-UID attribute.

14. Third Normal Form No non-UID attribute can be dependent on another non-UID attribute. CITY #id *name *size *population *mayor *state *state flower Third Normal Form Violation

15. Third Normal Form CITY #id *name *size *population *mayor STATE #id *name *flower *song *motto in have

16. Help you remember Normal Forms  This saying might help you remember the 3 normal forms  The truth the whole truth and nothing but the truth.  The truth (1NF) no multivalue attributes, and depend on key  The whole truth (2NF) – whole UID, attributes depend on the whole key  Nothing but the truth (3NF) – depends only on the key

17. UID types  Artificial UID we need some # to have a key, can use autonumber  Relationship is part of UID use bar to indicate that key of parent is part of child key makes a composite key  Composite key 2 attributes function as a UID Made of 2 unique attributes The 2 nd UID could be a key but function together with other key Use primary key and secondary key – both must be mandatory and must be unique

18. Arcs  Constraints two or more relationships on an entity.  Indicates that any instance of that entity can have only one valid relationship of the relationships in the arc at any one time.  Models an exclusive or across the relationships. An Arc is therefore also called an exclusive arc.

19. Subtype/Supertype Example VENUE #id *address o comments EVENT #id *cost *name *date o description PRIVATE HOME o accessibility feature? PUBLIC SPACE *rental fee held at the venue for

20. Modeled as an ARC PARTNER #id *first name *last name EVENT PLANNER *expertise DJ *specialty MANAGER *authorized expense limit OTHER

21. ARC Example MEMBERSHIP *ID *start date *expiration date o termination COMPANY #ID *name o contact name CUSTOMER #ID *first name *last name

22. ARCS  Arcs are similar to supertypes/subtypes, and are often modeled as such.  Use supertypes/subtypes when you want to represent classifications, or types of things.  Use arcs to represent mutually exclusive relationships between entities. (A type of “either/or” situation)

23. ARCS owned by LIST ITEM USER LIST owner of is referred to container of referring to contained is referred to referring to

24. ARCS (previous screen)  An arc always belongs to one entity.  Arcs can include more than two relationships.  Not all relationships of an entity need to be included in an arc.  An entity may have several arcs.  An arc should always consist of relationships of the same optionality: All relationships in an arc must be mandatory or all must be optional. Relationships in an arc may be of different degree, although this is rare.

25. Hierarchy vs. Recursive HierarchyRecursive A #id

26. Model Hierarchical Data M:1 relationships Company Division Department Team

27. Model Hierarchical Data TEAM DEPARTMENT DIVISION COMPANY within made up of

28. Model Hierarchical Data  The UID of ROOM is the room id and the SUITE it is located within, the FLOOR it is on, and the BUILDING in which it is located.  The UID of SUITE is the suite id, the FLOOR on which it is located, and the BUILDING in which it is located.  The UID of FLOOR is the floor number and the BUILDING in which it is located.  see notes ROOM #id SUITE #number o tenant FLOOR #number BUILDING #id *name located within located on contained in the container of

29. Recursive Relationships  A Recursive Relationship is a relationship between an entity and itself.  Example – Read the recursive relationship in the following E-R Diagram.  Each EMPLOYEE may be managed by one and only one EMPLOYEE  Each EMPLOYEE may be the manager of one or more EMPLOYEEs. EMPLOYEE #badge number *first name *last name o manager_id o job o hire date o salary o commission managed by the managed of

30. Recursive Relationship example Model Bill of Materials  Each COMPONENT may be a part of one or more COMPONENTs.  Each COMPONENT may be made up of one or more COMPONENTs.  Example – For the automobile manufacturing organization, consider all elementary parts, subassemblies assemblies and products as instances of an entity called COMPONENT. Then the previous complex E-R Model can be remodeled as a simple recursive relationship.  Bill of Materials data as a many-to-many recursive relationship COMPONENT #id made up of a part of

31. Many-to-Many examples part 1  Example – Consider the recursive model of a Bill of Materials structure. This model will track information about which components are part of a fan. But if a washer is part of a fan, will it also track how many washers are part of a fan? COMPONENT #id a part of made of of

32. Resolve M:M recursive relationship part 2  Resolve this M:M recursive relationship by adding the intersection entity ASSEMBLY RULE and two M:1 relationships back to the COMPONENT entity. ASSEMBLY RULE will have an attribute of quantity. ASSEMBLY RULE o quantity COMPONENT #identifier for a part of made up of

33. Example – A business hierarchy can be drawn as a recursive relationship TEAM DEPARTMENT DIVISION COMPANY within made up of ORGANIZATION ELEMENT #id *name within