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

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

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.

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

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

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).

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?

2NF Example CUSTOMER.. Zip ZIP city state zip

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

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.

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

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

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

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

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

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

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

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.

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

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

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

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)

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

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.

Hierarchy vs. Recursive HierarchyRecursive A #id

Model Hierarchical Data M:1 relationships Company Division Department Team

Model Hierarchical Data TEAM DEPARTMENT DIVISION COMPANY within made up of

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

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

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

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

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

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