Objectives

• Definition of terms
• List five properties of relations
• State two properties of candidate keys
• Define first, second, and third normal form Key Fields
• Describe problems frommerging relations
• Transform E-R and EER diagrams to relations
• Create tables with entity and relational integrity • Keysare special fields that serve two main purposes:
constraints – Primarykeysare unique identifiers of the relation in question.
Examples include employee numbers, social security numbers, etc.
• Use normalization to convert anomalous tables to Thisis how we can guaranteethat all rows are unique
well-structured relations – Foreign keysare identifiers that enable a dependent relation (on the
many side of a relationship) to refer to itsparent relation (on the one
side of the relationship)
Chapter 5 2
• Keyscan besimple(a single field) or composite(more than Integrity Constraints
one field)
• Keysusually are used as indexes to speed up the response to
user queries (More on this in Ch. 6) • Referential Integrity–rule states that any foreign key value (on the
relation of the many side) MUST match a primary key value in the
relation of the one side. (Or the foreign key can be null)
Chapter 5 5
– For example: Delete Rules
• Restrict–don’t allow delete of “parent” side if related rows exist in
Relation “dependent” side
• Cascade–automatically delete“dependent” side rows that correspond with
• Definition: A relation is anamed, two-dimensional table of data the “parent” side row to be deleted
• Set-to-Null–set the foreign key in the dependent side to null if deleting
• Table consists of rows (records) and columns (attribute or field) fromthe parent side  not allowed for weak entities
• Requirements for a table to qualify as a relation:
– It must have a uniquename
– Every attribute value must be atomic (not multivalued, not composite) Chapter 5 9
– Every row must be unique (can’t have two rows with exactly the same Figure 5-3 Schema for four relations (Pine Valley Furniture Company)
valuesfor all their fields)
– Attributes (columns) in tables must have unique names
– The order of the columns must be irrelevant
– The order of the rows must be irrelevant
Primary Key
NOTE: all relationsare in 1st Normal form Foreign Key
(implements 1:N relationship
between customer and order)

Combined, these are a composite

primary key (u niquely identifies the
order line)…individually they are
foreign keys (implemen t M :N
Figure 5-5
Chapter 5 3 relationsh ip between order and product) Referential integrity constraints (Pine Valley Furniture)

Chapter 5 6

Referential
integrity
Integrity Constraints constraints are
drawn via arrows
from dependent to
parent table
• Domain Constraints
– Allowable values for an attribute. See Table 5-1
• Entity Integrity
Chapter 5
– No primary key attribute may be null. All primary 10

key fields MUSThave data

• Action Assertions
Correspondence with E-R Model – Business rules. Recall fromCh. 4

• Relations (tables) correspond with entity types and Chapter 5 7

with many-to-many relationship types Figure 5-6 SQL table definitions

• Rows correspond with entity instances and with many-
to-many relationship instances
• Columns correspond with attributes

• NOTE: The word relation(in relational database) is Referential

NOT the same as the word relationship(in E-R integrity
model) constraints are
implemented with
foreign key to
Chapter 5 4 primary key
references

Chapter 5 11

Domain definitions enforce domain integrity constraints

Chapter 5 8
 Transforming EER Diagrams into
Relations

Mapping Regular Entities to Relations

Figure 5-10 Mapping an entity with a multivalued attribute
1. Simple attributes: E-R attributes map directly (a)
onto the relation
2. Composite attributes: Use only their simple,
component attributes
3. Multivalued Attribute–Becomes a separate
relation with a foreign key taken fromthe
superior entity Multivalued attribute becomes a separate relation with foreign key
Transforming EER Diagrams into
(b)
Chapter 5 12 Relations (cont.)
Mapping Binary Relationships
– One-to-Many–Primary key on the one side
becomes a foreign key on the many side
One–to–many relationship between original entity and new relation
Chapter 5 15
– Many-to-Many–Create a new relationwith the
Figure 5-8 Mapping a regular entity
primary keys of the two entities as its primary key
– One-to-One–Primary keyon the mandatory side
(a) CUSTOMER becomes a foreign key on the optional side
entity type with
simple
attributes

Chapter 5 19

(b) CUSTOMER relation Transforming EER Diagrams into

Relations (cont.)
Mapping Weak Entities
– Becomes a separate relation with a foreign
Chapter 5 13
key taken from the superior entity
– Primary key composed of:
• Partial identifier of weak entity Figure 5-12 Example of mapping a 1:M relationship
• Primary key of identifying relation (strong
entity)
a) Relationship between customers and orders

Chapter 5 16
Note the mandatory one

b) Mapping the relationship

Figure 5-11 Example of mapping a weak entity

a) Weak entity DEPENDENT

Again, no n ull value in the

foreign key… this is because
of the man datory minimum
cardinality
Foreign key
Figure 5-9 Mapping a composite attribute
Chapter 5 20

(a) CUSTOMER
entity type with
composite
attribute

Chapter 5 17

(b) CUSTOMER relation with address detail Figure 5-13 Example of mapping an M:N relationship
a) Completes relationship (M:N)

Figure 5-11 Example of mapping a weak entity (cont.)

Chapter 5 14

b) Relations resulting from weak entity

NOTE: the doma in constraint

for the foreign key should
NOT allow null value if
DEPEND ENT is a weak
entity
The Completes relationship will need to become a separate relation
Foreign key
Chapter 5 21

Composite primary key

Chapter 5 18
 Figure 5-13 Example of mapping an M:N relationship (cont.)
b) Three resulting relations

Transforming EER Diagrams into

Composite primary key
Relations (cont.)
Mapping Associative Entities
Foreign key New
intersection – Identifier Not Assigned
Foreign key
relation • Default primary key for the association relation
is composed of the primary keys of the two
entities (as in M:N relationship)
Figure 5-16 Example of mapping an associative entity with
– Identifier Assigned an identifier (cont.)
Chapter 5 22 • It is natural and familiar to end-users b) Three resulting relations
• Default identifier may not be unique

Chapter 5 25

Primary key differs from foreign keys

Figure 5-14 Example of mapping a binary 1:1 relationship
a) In_charge relationship (1:1)

Chapter 5 29
Figure 5-15 Example of mapping an associative entity
a) An associative entity
Often in 1:1 relationships, one direction is optional.

Chapter 5 23

Transforming EER Diagrams into

Relations (cont.)
Mapping Unary Relationships
Chapter 5 26

– One-to-Many–Recursive foreign key in the same

relation
Figure 5-15 Example of mapping an associative entity (cont.) – Many-to-Many–Two relations:
• One for the entity type
b) Three resulting relations
• One for an associative relation in which the
primary key has two attributes, both taken
fromthe primary key of the entity

Figure 5-14 Example of mapping a binary 1:1 relationship (cont.)

Chapter 5 30
b) Resulting relations

Composite primary key for med from the two foreign keys

Chapter 5 27

Figure 5-17 Mapping a unary 1:N relationship

Foreign key goes in the relation on the optional side,

Matching the primary key on the mandatory side

Chapter 5 24 Figure 5-16 Example of mapping an associative entity with

an identifier (a) EMPLOYEE entity with
unary relationship

a) SHIPMENT associative entity

(b) EMPLOYEE
relation with
recursive foreign
key

Chapter 5 31

Chapter 5 28
 Figure 5-18 Mapping a unary M:N relationship Figure 5-20 Supertype/subtype relationships
Anomalies in this Table
(a ) Bill-of-materials
relationships (M:N) • Insertion–can’t enter a new employee without having
the employee take a class
• Deletion–if we remove employee 140, we lose
information about the existence of a Tax Acc class
First
Well-Structured Normal Form
Relations
• Modification–giving a salary increase to employee 100
• No multivalued
• A relation that contains minimal dataredundaattributes
ncy and
forces us to update multiple records allows users to insert, delete, and update rows without
(b) ITEM and
Every attribute value is atomic
causingdata inc•onsistencies
Why do these anomalies exist?
CO MPONENT
relations Because there are two themes (entity types) in this
5-25 is not in 1st Normal Form
Fig.lies
• Goal is to avoid•anoma
– Insertion Anomaly–addingnew rows forces user to create
one relation. This results in data duplication and an duplicate data (multivalued attributes)  it is not a
unnecessary dependency between the entities relation
– Deletion Anomaly–deletingrows may cause a loss of data that
would be needed for other future rows
Chapter 5 Chapter 5 Chapter 5
stforceschangesto
• Fig. 5-26 isin 1 Normal form
– ModificationAnomaly–changingdata in a row
32 37 42 other rows because of duplication
• All relationsare in 1st Normal Form
General rule of thumb: A table should not pertain to
more than one entity type
Chapter 5 Chapter 5 40 45

Transforming EER Diagrams into Figure 5-21

Relations (cont.) Functional
Mapping Supertype/subtype Dependencies
relationships to relations and Keys
Mapping Ternary (and n-ary) • Functional Dependency: The value of one
Relationships attribute (the determinant) determines the
–One relation for each entity and one value of another attribute Example–Figure 5-2b
Table with multivalued attributes, not in 1st normal form
for the associative entity • Candidate Key:
–Associative entity has foreign keys to – A unique identifier. One of the candidate keys
each entity in the relationship will become the primary key
• E.g. perhaps there is both credit card number and
SS#in a table…in this caseboth are candidate keys
Chapter 5 33
– Each non-key field is functionally dependent on
These are implemented as one-to-one
everycandidate key
relationships Question–Is this a relation? Answer–Yes: Uniqu e rows and no
multivalued attributes

Question–What’s the primary key? Answer–Comp os ite: Emp_ID, Course_Title

Chapter 5 Chapter 5 38 43 Note: this is NOT a relation

Chapter 5 Chapter 5 41 46

Figure 5-19 Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship with

associative entity

Figure 5.22 Steps in normalization

Data Normalization
• Primarily a tool to validate and improve a
logical design so that it satisfies certain
constraints that avoid unnecessary
duplication of data
• The process of decomposing relations with
anomalies to produce smaller, well-
Chapter 5
structured relations
34

Chapter 5 Chapter 5 39 44

Figure 5-19 Mapping a ternary relationship (cont.)

b) Mapping the ternary relationship PATIENT TREATMENT

Remember T his is why But this makes a It would be

that the tr eatment date very better to create a
primary key and time are cumbersome surrogate key
MUST be included in the key… like Treatment#
unique composite
Chapter 5 primary key 35

TransformingEER Diagrams into

Relations (cont.)
Mapping Supertype/Subtype Relationships
– One relation for supertype and for each subtype
– Supertype attributes (including identifier and
subtype discriminator) go into supertype relation
– Subtypeattributes go into each subtype; primary
key of supertype relation also becomes primary key
of subtype relation
– 1:1 relationship established between supertype and
each subtype, with supertype as primary table

Chapter 5 36
 Figure 5-27 Functional dependency diagram for INVOICE

Order_ID  Or der_Date , C ustomer_ID, Customer_Name, Customer_Address MergingRelations

Customer_ID  Customer_Name, Customer_Address
• View Integration–Combining entities from multiple ER
Product_ID  Produc t_Description, Product_Finish, Unit_Price
models into common relations
Order_ID, Product_ID  Orde r_Q uantity
• Issuesto watch out for when merging entities from
Therefore, NOT in 2 nd Normal Form different ERmodels:
Chapter 5 50
– Synonyms–two or more attributes with different names but
same meaning
– Homonyms–attributes with same name but different meanings
– Transitive dependencies–even if relations are in 3NF prior to
merging, they may not be after merging
– Supertype/subtype relationships–may be hidden prior to
merging

Figure 5-28 Removing partial dependencies

Chapter 5 54

Table with no multivalued attributes and unique rows, in 1st

normal form

Getting it into
Second Normal
Form
Enterprise Keys
Partial dependencies are removed, but there
are still transitive dependencies
• Primary keys that are unique in the whole
Chapter 5 51
database, not just within a single relation
Note: this is relation, but not a well-stru ctured one • Corresponds with the concept of an object ID
in object-oriented systems
Chapter 5 47

Third Normal Form

• 2NF PLUS no transitive dependencies(functional
dependencies on non-primary-key attributes)
• Note: This iscalled transitive, because the primary
key is a determinant for another attribute, which in Chapter 5 55

turn is a determinant for a third

Anomalies in this Table • Solution: Non-key determinant with transitive
• Insertion–if new product is ordered for order 1007 of dependencies go into a new table; non-key
existing customer, customer data must be re-entered, determinant becomes primary keyin the new table
causingduplication and stays as foreign key in the old table
• Deletion–if we delete the Dining Table from Order 1006,
we lose information concerning this item's finish and Figure 5-31 Enterprise keys
price
a) Relations with
• Update–changing the price of product ID 4 requires Chapter 5 52 enterpr ise key
update in several records
Why do these anomalies exist?
Because there are multiple themes (entity types) in
b) Sample data with
one relation. This results in duplication and an enterprise key
unnecessary dependency between the entities
Chapter 5 48
Figure 5-28 Removing partial dependencies

Chapter 5 56
Getting it into
Third Normal
Form

Transitive dependencies are removed

Chapter 5 53

Second Normal Form

• 1NF PLUS everynon-key attribute is fully
functionally dependent on theENTIRE
primary key
– Every non-key attribute must be defined by the
entire key, not by only part of the key
– No partial functional dependencies

Chapter 5 49