Database Design

Sections 6 & 7Second 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 ExampleCustomer_idFirst_NameLast_NameAddressCityStateZIPIf the ZIP code changes does the

customer name change?What if the ZIP for a city changes?

2NF Example

CUSTOMER ......

Zip

ZIPcity

statezip

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

Intersection Entity in M:M

EVENT#id

*name*date*cost

*description

SONG #id

*title*artist

*duration

PLAY LIST ITEM*comments

for for

have on

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 NormalForm Violation

Third Normal Form

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 2nd 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*addresso comments

EVENT#id

*cost*name*date

o description

PRIVATE HOME o accessibility

feature?

PUBLICSPACE

*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

*nameo 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 tocontainer 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

Hierarchy Recursive

A#id

Model Hierarchical Data

M:1 relationships Company Division

Department

Team

Model Hierarchical Data

TEAM

DEPARTMENT

DIVISION

COMPANY

within

within

within

made up of

made up of

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#numbero tenant

FLOOR

#number

BUILDING#id

*name

located within

located on

contained in

the container of

the container of

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_ido job

o hire dateo salary

o commission

managed by

the managed of

Recursive Relationship exampleModel 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 for

a part of

made up of

Example – A business hierarchy can be drawn as a recursive relationship

TEAM

DEPARTMENT

DIVISION

COMPANY

within

within

within

made up of

made up of

made up of

made up of

ORGANIZATIONELEMENT

#id*name

within