database design sections 6 & 7 second normal form (2nf), unique identifiers (uid), third normal...
TRANSCRIPT
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?
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.
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