chapter 5: logical database design and the relational model chapter 5: logical database design and...
TRANSCRIPT
Chapter 5:Chapter 5:Logical Database Design and Logical Database Design and
the Relational Modelthe Relational Model
1
Modern Database Management8th Edition
Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden
By: Aatif KamalDated: March 2008
Chapter 5
ObjectivesObjectives Definition of termsDefinition of terms List five properties of relationsList five properties of relations State two properties of candidate keysState two properties of candidate keys Define first, second, and third normal formDefine first, second, and third normal form Describe problems from merging relationsDescribe problems from merging relations Transform E-R and EER diagrams to Transform E-R and EER diagrams to
relationsrelations Create tables with entity and relational Create tables with entity and relational
integrity constraintsintegrity constraints Use normalization to convert anomalous Use normalization to convert anomalous
tables to well-structured relationstables to well-structured relations
Chapter 5 3
INFORMAL DEFINITIONS RELATION: A table of values
A relation may be thought of as a set of rows. A relation may alternately be though of as a set
of columns. Each row represents a fact that corresponds to a
real-world entity or relationship. Each row has a value of an item or set of items
that uniquely identifies that row in the table. Sometimes row-ids or sequential numbers are
assigned to identify the rows in the table. Each column typically is called by its column
name or column header or attribute name.
RelationRelation is NOTNOT same
as RelationshiRelationshi
pp
Chapter 5 4
FORMAL DEFINITIONS A Relation may be defined in multiple
ways. The Schema of a Relation:
R (A1, A2, .....An)Relation schema R is defined over attributes A1, A2, .....An
For Example –CUSTOMER (Cust-id, Cust-name, Address, Phone#)
Here, CUSTOMER is a relation defined over the four attributes Cust-id, Cust-name, Address, Phone#, each of which has a domain or a set of valid values. For example, the domain of Cust-id is 6 digit numbers.
Chapter 5 5
FORMAL DEFINITIONS A tupletuple is an ordered set of values Each value is derived from an appropriate
domain. Each row in the CUSTOMER table may be
referred to as a tuple in the table and would consist of four values. <632895, "John Smith", "101 Main St. Atlanta, GA 30332", "(404)
894-2000"> is a tuple belonging to the CUSTOMER relation.
A relation may be regarded as a set of tuples (rows).
Columns in a table are also called attributes of the relation.
Chapter 5
RelationRelation
6
Definition: Definition: A relation is a named, two-A relation is a named, two-dimensional table of data dimensional table of data
Table consists of rows (records) and columns Table consists of rows (records) and columns (attribute or field)(attribute or field)
Requirements for a table to qualify as a Requirements for a table to qualify as a relation:relation: It must have a unique nameIt must have a unique name Every attribute value must be atomic (not multi-valued, Every attribute value must be atomic (not multi-valued,
not composite)not composite) Every row/tuple must be unique (can’t have two rows Every row/tuple must be unique (can’t have two rows
with exactly the same values for all their fields)with exactly the same values for all their fields) Attributes (columns) in tables must have unique namesAttributes (columns) in tables must have unique names The order of the columns must be irrelevantThe order of the columns must be irrelevant The order of the rows must be irrelevantThe order of the rows must be irrelevant
NOTE: all relations are in 1st Normal form
Chapter 5
Correspondence with E-R ModelCorrespondence with E-R Model
7
Relations (tables) correspond with entity Relations (tables) correspond with entity types and with many-to-many relationship types and with many-to-many relationship typestypes
Rows correspond with entity instances and Rows correspond with entity instances and with many-to-many relationship instanceswith many-to-many relationship instances
Columns correspond with attributesColumns correspond with attributes
NOTE: NOTE: The word The word relationrelation (in relational (in relational database) is database) is NOTNOT the same as the word the same as the word relationshiprelationship (in E-R model) (in E-R model)
Chapter 58
DEFINITION SUMMARY
Informal TermsInformal Terms Formal TermsFormal Terms
Table Relation
Column Attribute/Domain
Row Tuple
Values in a column
Domain
Table Definition Schema of a Relation
Populated Table Extension
Chapter 59
Relation Example
Chapter 5
Key FieldsKey Fields
10
Keys are special fields that serve two main Keys are special fields that serve two main purposes:purposes: Primary keysPrimary keys are are uniqueunique identifiers of the relation in identifiers of the relation in
question. Examples include employee numbers, question. Examples include employee numbers, social security numbers, etc. social security numbers, etc. This is how we can This is how we can guarantee that all rows are uniqueguarantee that all rows are unique
Foreign keysForeign keys are identifiers that enable a are identifiers that enable a dependentdependent relation (on the many side of a relationship) to refer relation (on the many side of a relationship) to refer to its to its parentparent relation (on the one side of the relation (on the one side of the relationship)relationship)
Keys can be Keys can be simplesimple (a single field) or (a single field) or compositecomposite (more than one field) (more than one field)
Keys usually are used as indexes to speed up Keys usually are used as indexes to speed up the response to user queriesthe response to user queries
11
Primary Key
Foreign Key (implements 1:N relationship between customer and order)
Combined, these are a composite primary key (uniquely identifies the order line)…individually they are foreign keys (implement M:N relationship between order and product)
Figure 5-3 Schema for four relations (Pine Valley Furniture Company)
Chapter 5
Integrity ConstraintsIntegrity Constraints
12
Domain ConstraintsDomain Constraints Allowable values for an attribute. Allowable values for an attribute.
Entity IntegrityEntity Integrity No primary key attribute may be null. All primary No primary key attribute may be null. All primary
key fields key fields MUSTMUST have data have data Action AssertionsAction Assertions
Business rules. Business rules.
13
Domain definitions enforce domain integrity constraintsDomain definitions enforce domain integrity constraints
Chapter 5
Integrity ConstraintsIntegrity Constraints
14
Referential Integrity Referential Integrity – rule states that any foreign – rule states that any foreign key value (on the relation of the many side) MUST key value (on the relation of the many side) MUST match a primary key value in the relation of the one match a primary key value in the relation of the one side. (Or the foreign key can be null) side. (Or the foreign key can be null) For example: For example: Delete RulesDelete Rules
Restrict:Restrict: don’t allow delete of “parent” side if related don’t allow delete of “parent” side if related rows exist in “dependent” siderows exist in “dependent” side
Cascade–automatically: Cascade–automatically: delete “dependent” side rows “dependent” side rows that correspond with the “parent” side row to be deletedthat correspond with the “parent” side row to be deleted
Set-to-Null: Set-to-Null: setset the foreign key in the dependent side to the foreign key in the dependent side to null if deleting from the parent side null if deleting from the parent side not allowed for not allowed for weak entitiesweak entities
15
Figure 5-5 Referential integrity constraints (Pine Valley Furniture)
Referential integrity
constraints are drawn via arrows from dependent to
parent table
16
Figure 5-6 SQL table definitions
Referential integrity
constraints are implemented with
foreign key to primary key references
Chapter 5
Transforming EER Diagrams into RelationsTransforming EER Diagrams into Relations
17
Mapping Regular Entities to Relations Mapping Regular Entities to Relations 1.1. Simple attributes: Simple attributes: E-R attributes map E-R attributes map
directly onto the relationdirectly onto the relation2.2. Composite attributes: Composite attributes: Use only their Use only their
simple, component attributes simple, component attributes 3.3. Multivalued Attribute: Multivalued Attribute: Becomes a Becomes a
separate relation with a foreign key separate relation with a foreign key taken from the superior entitytaken from the superior entity
18
(a) CUSTOMER entity type with simple attributes
Figure 5-8 Mapping a regular entity
(b) CUSTOMER relation
19
(a) CUSTOMER entity type with composite attribute
Figure 5-9 Mapping a composite attribute
(b) CUSTOMER relation with address detail
Chapter 5 20
Figure 5-10 Mapping an entity with a multivalued attribute
One–to–many relationship between original entity and new relation
(a)
Multivalued attribute becomes a separate relation with foreign key
(b)
Chapter 5
Transforming EER Diagrams into Relations Transforming EER Diagrams into Relations (cont….)(cont….)
21
Mapping Weak EntitiesMapping Weak Entities Becomes a separate relation with a Becomes a separate relation with a
foreign key taken from the superior foreign key taken from the superior entityentity
Primary key composed of:Primary key composed of: Partial identifier of weak entityPartial identifier of weak entity Primary key of identifying relation Primary key of identifying relation
(strong entity)(strong entity)
22
Figure 5-11 Example of mapping a weak entity
a) Weak entity DEPENDENT
23
NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity
Foreign key
Composite primary key
Figure 5-11 Example of mapping a weak entity (cont.)
b) Relations resulting from weak entity
Chapter 5
Transforming EER Diagrams into Relations Transforming EER Diagrams into Relations (cont.)(cont.)
24
Mapping Binary RelationshipsMapping Binary Relationships One-to-Many: One-to-Many: Primary key on the one side Primary key on the one side
becomes a foreign key on the many sidebecomes a foreign key on the many side Many-to-Many: Many-to-Many: Create a Create a new relationnew relation with the with the
primary keys of the two entities as its primary primary keys of the two entities as its primary keykey
One-to-One: One-to-One: Primary key on the mandatory side Primary key on the mandatory side becomes a foreign key on the optional sidebecomes a foreign key on the optional side
25
Figure 5-12 Example of mapping a 1:M relationship
a) Relationship between customers and orders
Note the mandatory one
b) Mapping the relationship
Again, no null value in the foreign key…this is because of the mandatory minimum cardinality
Foreign key
26
Figure 5-13 Example of mapping an M:N relationship
a) Completes relationship (M:N)
The Completes relationship will need to become a separate relation
27
New intersection
relation
Foreign key
Foreign key
Composite primary key
Figure 5-13 Example of mapping an M:N relationship (cont.)
b) Three resulting relations
28
Figure 5-14 Example of mapping a binary 1:1 relationship
a) In_charge relationship (1:1)
Often in 1:1 relationships, one direction is optional.
29
b) Resulting relations
Figure 5-14 Example of mapping a binary 1:1 relationship (cont.)
Foreign key goes in the relation on the optional side,Matching the primary key on the mandatory side
Chapter 5
Transforming EER Diagrams into Relations Transforming EER Diagrams into Relations (cont.)(cont.)
30
Mapping Associative EntitiesMapping Associative Entities Identifier Not Assigned Identifier Not Assigned
Default primary key for the association Default primary key for the association relation is composed of the primary relation is composed of the primary keys of the two entities (as in M:N keys of the two entities (as in M:N relationship)relationship)
Identifier Assigned Identifier Assigned It is natural and familiar to end-usersIt is natural and familiar to end-users Default identifier may not be uniqueDefault identifier may not be unique
31
Figure 5-15 Example of mapping an associative entity
a) An associative entity
32
Figure 5-15 Example of mapping an associative entity (cont.)
b) Three resulting relations
Composite primary key formed from the two foreign keys
33
Figure 5-16 Example of mapping an associative entity with an identifier
a) SHIPMENT associative entity
34
Figure 5-16 Example of mapping an associative entity with an identifier (cont.)
b) Three resulting relations
Primary key differs from foreign keys
Chapter 5
Transforming EER Diagrams into Relations Transforming EER Diagrams into Relations (cont.)(cont.)
35
Mapping Unary RelationshipsMapping Unary Relationships One-to-Many: One-to-Many: Recursive foreign key in the same Recursive foreign key in the same
relationrelation Many-to-Many: Many-to-Many: Two relations:Two relations:
One for the entity typeOne for the entity type One for an associative relation in which One for an associative relation in which
the primary key has two attributes, both the primary key has two attributes, both taken from the primary key of the entitytaken from the primary key of the entity
36
Figure 5-17 Mapping a unary 1:N relationship
(a) EMPLOYEE entity with unary relationship
(b) EMPLOYEE relation with recursive foreign key
Chapter 5 37
Figure 5-18 Mapping a unary M:N relationship
(a) Bill-of-materials relationships (M:N)
(b) ITEM and COMPONENT relations
Chapter 5
Transforming EER Diagrams into Relations Transforming EER Diagrams into Relations (cont…)(cont…)
38
Mapping Ternary (and n-ary) Mapping Ternary (and n-ary) RelationshipsRelationshipsOne relation for each entity and One relation for each entity and
one for the associative entityone for the associative entityAssociative entity has foreign Associative entity has foreign
keys to each entity in the keys to each entity in the relationshiprelationship
39
Figure 5-19 Mapping a ternary relationship
a) PATIENT TREATMENT Ternary relationship with associative entity
40
b) Mapping the ternary relationship PATIENT TREATMENT
Remember that the
primary key MUST be
unique
Figure 5-19 Mapping a ternary relationship (cont.)
This is why treatment date and time are
included in the composite
primary key
But this makes a very
cumbersome key…
It would be better to create a
surrogate key like Treatment#
Chapter 5
Transforming EER Diagrams into Transforming EER Diagrams into Relations (cont.)Relations (cont.)
41
Mapping Supertype/Subtype RelationshipsMapping Supertype/Subtype Relationships One relation for supertype and for each One relation for supertype and for each
subtypesubtype Supertype attributes (including identifier Supertype attributes (including identifier
and subtype discriminator) go into and subtype discriminator) go into supertype relationsupertype relation
Subtype attributes go into each subtype; Subtype attributes go into each subtype; primary key of supertype relation also primary key of supertype relation also becomes primary key of subtype relationbecomes primary key of subtype relation
1:1 relationship established between 1:1 relationship established between supertype and each subtype, with supertype and each subtype, with supertype as primary tablesupertype as primary table
Chapter 5 42
Mapping EER Model Constructs to Relations
Options for Mapping Specialization or Generalization.Options for Mapping Specialization or Generalization. Convert each specialization with m subclasses {S1, S2,
….,Sm} and generalized superclass C, where the attributes of C are {k,a1,…an} and k is the (primary) key, into relational schemas using one of the four following options:
Option A:Option A: Multiple relations-Superclass and Multiple relations-Superclass and subclasses.subclasses.
Create a relation L for C with attributes Attrs(L) = {k,a1,…an} and PK(L) = k. Create a relation Li for each subclass Si, 1 < i < m, with the attributesAttrs(Li) = {k} U {attributes of Si} and PK(Li)=k. This option works for any specialization (total or partial, disjoint or over-lapping).
Option B:Option B: Multiple relations-Subclass relations onlyMultiple relations-Subclass relations only Create a relation Li for each subclass Si, 1 < i < m, with the attributes
Attr(Li) = {attributes of Si} U {k,a1…,an} and PK(Li) = k. This option only only works for a specialization whose subclasses are works for a specialization whose subclasses are totaltotal (every entity in the superclass must belong to (at least) one of the subclasses).
Chapter 5 43
EER diagram notation for an attribute-defined specialization on JobType.
Chapter 5 44
Generalization. (b) Generalizing CAR and TRUCK into the superclass VEHICLE.
Chapter 5 45
Mapping EER Model Constructs to Relations (cont)
Option C: Single relation with one type attribute. Option C: Single relation with one type attribute.
Create a single relation L with attributes Attrs(L) = {k,a1,…an} U {attributes of S1} U…U {attributes of Sm} U {t} and PK(L) = k. The attribute t is called a type (or discriminating) attribute that indicates the subclass to which each tuple belongs: Works for Disjoint Works for Disjoint
Option D: Single relation with multiple type Option D: Single relation with multiple type attributes.attributes.
Create a single relation schema L with attributes Attrs(L) = {k,a1,…an} U {attributes of S1} U…U {attributes of Sm} U {t1, t2,…,tm} and PK(L) = k. Each ti, 1 < I < m, is a Boolean type attribute indicating whether a tuple belongs to the subclass Si. Works for overlapping as ks for overlapping as wellwell
Chapter 5 46
EER diagram notation for an attribute-defined specialization on JobType.
Chapter 5 47
EER diagram notation for an overlapping (nondisjoint) specialization.
Chapter 5 48
Mapping EER Model Constructs to Relations (cont)
Mapping of Shared Subclasses (Multiple Inheritance)
A shared subclass, such as STUDENT_ASSISTANT, is a subclass of several classes, indicating multiple inheritance. These classes must all have the same key attribute; otherwise, the shared subclass would be modeled as a category.
We can apply any of the options discussed in for EER-inhertance to a shared subclass, subject to the restriction discussed mapping algorithm. Below both options C and D are used for the shared class STUDENT_ASSISTANT.
Chapter 5 49
A specialization lattice with multiple inheritance for a UNIVERSITY database.
Chapter 5 50
Mapping the EER specialization lattice in Figure 4.6 using multiple options.
Chapter 5 51
Mapping EER Model Constructs to Relations (cont)
Mapping of Union Types Mapping of Union Types (Categories).(Categories). For mapping a category whose defining superclass
have different keys, it is customary to specify a new key attribute, called a surrogate key, when creating a relation to correspond to the category.
In the example below we can create a relation OWNER to correspond to the OWNER category and include any attributes of the category in this relation.
The primary key of the OWNER relation is the surrogate key,surrogate key, which we called OwnerId.
Chapter 5 52
Two categories (union types): OWNER and REGISTERED_VEHICLE.
Chapter 5 53
Mapping the EER categories (union types) in to relations.
Chapter 5 54
Mapping ExerciseExercise
FIGURE FIGURE An ER schema for a SHIP_TRACKING database.An ER schema for a SHIP_TRACKING database.
Chapter 5 55
Chapter Summary ER-to-Relational Mapping Algorithm
Step 1: Mapping of Regular Entity Types Step 2: Mapping of Weak Entity Types Step 3: Mapping of Binary 1:1 Relation Types Step 4: Mapping of Binary 1:N Relationship Types. Step 5: Mapping of Binary M:N Relationship Types. Step 6: Mapping of Multivalued attributes. Step 7: Mapping of N-ary Relationship Types.
Mapping EER Model Constructs to Relations Step 8: Options for Mapping Specialization or
Generalization. Step 9: Mapping of Union Types (Categories).
Chapter 5
Data NormalizationData Normalization
56
Primarily a tool to validate and improve a Primarily a tool to validate and improve a logical design so that it satisfies certain logical design so that it satisfies certain
constraints that constraints that avoid avoid unnecessary duplication of unnecessary duplication of datadata
The process of decomposing relations with The process of decomposing relations with
anomaliesanomalies to produce smaller, to produce smaller, well-well-structuredstructured relationsrelations
Chapter 5
Well-Structured RelationsWell-Structured Relations
57
A relation that contains minimal data A relation that contains minimal data redundancy and allows users to insert, delete, redundancy and allows users to insert, delete, and update rows without causing data and update rows without causing data inconsistenciesinconsistencies
Goal is to avoid anomaliesGoal is to avoid anomalies Insertion Anomaly: Insertion Anomaly: adding new rows forces user adding new rows forces user
to create duplicate datato create duplicate data Deletion Anomaly: Deletion Anomaly: deleting rows may cause a loss deleting rows may cause a loss
of data that would be needed for other future rowsof data that would be needed for other future rows Modification Anomaly: Modification Anomaly: changing data in a row changing data in a row
forces changes to other rows because of duplicationforces changes to other rows because of duplication
General rule of thumb: A table should not pertain to more than one entity type
Chapter 5
Example–Figure 5-2bExample–Figure 5-2b
58
Question–Is this a relation? Answer–Yes: Unique rows and no multivalued attributes
Question–What’s the primary key? Answer–Composite: Emp_ID, Course_Title
Chapter 5
Anomalies in this TableAnomalies in this Table
59
InsertionInsertion–can’t enter a new employee without –can’t enter a new employee without having the employee take a classhaving the employee take a class
DeletionDeletion–if we remove employee 140, we lose –if we remove employee 140, we lose information about the existence of a Tax Acc information about the existence of a Tax Acc classclass
ModificationModification–giving a salary increase to –giving a salary increase to employee 100 forces us to update multiple employee 100 forces us to update multiple recordsrecordsWhy do these anomalies exist?
Because there are two themes (entity types) in this one relation. This results in data duplication and an unnecessary dependency between the entities
Chapter 5
Functional Dependencies and KeysFunctional Dependencies and Keys
60
Functional Dependency: Functional Dependency: The value of The value of one attribute (the one attribute (the determinantdeterminant) ) determines the value of another determines the value of another attributeattribute
Candidate Key:Candidate Key: A unique identifier. One of the candidate keys A unique identifier. One of the candidate keys
will become the primary keywill become the primary key E.g. perhaps there is both credit card E.g. perhaps there is both credit card
number and SS# in a table…in this case number and SS# in a table…in this case both are candidate keysboth are candidate keys
Each non-key field is functionally dependent Each non-key field is functionally dependent on every candidate keyon every candidate key
61
Figure 5.22 Steps in normalization
Chapter 5
First Normal FormFirst Normal Form
62
No multivalued attributesNo multivalued attributes Every attribute value is atomicEvery attribute value is atomic Fig. 5-25 Fig. 5-25 is notis not in 1 in 1stst Normal Form Normal Form
(multivalued attributes) (multivalued attributes) it is not it is not a relationa relation
Fig. 5-26 Fig. 5-26 isis in 1 in 1stst Normal form Normal form All relationsAll relations are in 1 are in 1stst Normal Normal
FormForm
63
Table with multivalued attributes, not in 1st normal form
Note: this is NOT a relation
64
Table with no multivalued attributes and unique rows, in 1st normal form
Note: this is relation, but not a well-structured one
Chapter 5
Anomalies in this TableAnomalies in this Table
65
InsertionInsertion–if new product is ordered for order –if new product is ordered for order 1007 of existing customer, customer data 1007 of existing customer, customer data must be re-entered, causing duplicationmust be re-entered, causing duplication
DeletionDeletion–if we delete the Dining Table from –if we delete the Dining Table from Order 1006, we lose information concerning Order 1006, we lose information concerning this item's finish and pricethis item's finish and price
UpdateUpdate–changing the price of product ID 4 –changing the price of product ID 4 requires update in several recordsrequires update in several records
Why do these anomalies exist? Because there are multiple themes (entity types) in one relation. This results in duplication and an unnecessary dependency between the entities
11NF NF AnomaliesAnomalies
11NF NF AnomaliesAnomalies
Chapter 5
Second Normal FormSecond Normal Form
66
11NF PLUS NF PLUS every non-key every non-key attribute is fully functionally attribute is fully functionally dependent on the ENTIRE dependent on the ENTIRE primary keyprimary key Every non-key attribute must be Every non-key attribute must be
defined by the entire key, not by only defined by the entire key, not by only part of the keypart of the key
No partial functional dependenciesNo partial functional dependencies
Chapter 5 67
Order_ID Order_Date, Customer_ID, Customer_Name, Customer_Address
Therefore, NOT in 2nd Normal Form
Customer_ID Customer_Name, Customer_Address
Product_ID Product_Description, Product_Finish, Unit_Price
Order_ID, Product_ID Order_Quantity
Figure 5-27 Functional dependency diagram for INVOICE
Chapter 5 68
Partial dependencies are removed, but there are still transitive dependencies
Getting it into Getting it into Second Normal Second Normal FormForm
Figure 5-28 Removing partial dependencies
Chapter 5
Third Normal FormThird Normal Form
69
2NF PLUS 2NF PLUS no transitive dependenciesno transitive dependencies (functional dependencies on non-primary-(functional dependencies on non-primary-key attributes)key attributes)
Note: Note: This is called transitive, because This is called transitive, because the the primary key is a determinant for another primary key is a determinant for another attribute, which in turn is a determinant for attribute, which in turn is a determinant for a thirda third
Solution: Solution: Non-key determinant with transitive Non-key determinant with transitive dependencies go into a new table; non-key dependencies go into a new table; non-key determinant becomes primary key in the determinant becomes primary key in the new table and stays as foreign key in the new table and stays as foreign key in the old table old table
Chapter 5 70
Transitive dependencies are removed
Figure 5-28 Removing partial dependencies
Getting it into Getting it into Third Normal Third Normal FormForm
Chapter 5
Merging RelationsMerging Relations
71
View Integration–Combining entities from View Integration–Combining entities from multiple ER models into common relationsmultiple ER models into common relations
Issues to watch out for when merging Issues to watch out for when merging entities from different ER models:entities from different ER models: SynonymsSynonyms–two or more attributes with different –two or more attributes with different
names but same meaningnames but same meaning HomonymsHomonyms–attributes with same name but –attributes with same name but
different meaningsdifferent meanings Transitive dependencies Transitive dependencies –even if relations are in –even if relations are in
3NF prior to merging, they may not be after 3NF prior to merging, they may not be after mergingmerging
Supertype/subtype relationships Supertype/subtype relationships –may be hidden –may be hidden prior to mergingprior to merging
Chapter 5
Normalization – 1 to 3 NF revisited Just another way of explaining normalizations
rules
72
Chapter 5 73
First Normal Form Disallows
composite attributes multivalued attributes nested relations; attributes whose values for an
individual tuple are non-atomic
Considered to be part of the definition of relation
Chapter 5 74
First Normal Form
Above two are examples of Multi-valued, non-atomic attributes
So for one worst case you might require 1000 columns in your table…. Still not dynamic enough as what if 1001 person is hired?
Means we will forever be changing the structure of the database table
Chapter 575
First normal form
• “A relation is in first normal form if every attribute is Single valued for each tuple (record)”
• Each attribute in each row, or each “cell” of the table, contains only one value.
• No repeating fields or groups are allowed.
The first rule dictates that we must not duplicate data within the same row of a table.Within the database community, this concept is referred to as the atomicity of a table. Tables that comply with this rule are said to be atomic.
Chapter 576
First normal formStu_id Stu_Nam
eMajor Credit
sStatus
S1001 Smith Math 90 Senior
S1002 Lee CS, Math 15 Fresh
S1003 Jon Art, English
63 Junior
Stu_id
Stu_Name
Major1
Major2
Credits
Status
S1001
Smith Math Math 90 Senior
S1002
Lee CS Math 15 Fresh
S1003
Jon Art English
63 JuniorStudents table (students have more then one major).The rule of 1NF (every attribute is Single valued for each tuple) is violated in the records of S1002 and S1003, who have two values listed for Major.
Chapter 5 77
Normalization into 1NF
Chapter 5 78
Normalization of nested relations into 1NF
Chapter 579
Second normal form
A relation is in second normal form (2NF) if and
only if
1. It is in first normal form
2. All the non-key attributes are fully functionally dependent on the key.
If the relation is 1NF and the key consist of single attribute, then the relation is
automatically in 2NF.nonkey attributes = attributes that don’t appear in any candidate keynonkey attributes = attributes that don’t appear in any candidate key
Chapter 5 80
3.3 Second Normal Form (1) Uses the concepts of FDs, primary key Definitions
Prime attribute: An attribute that is member of the primary key K
Full functional dependency: a FD Y Z where removal of any attribute from Y means the FD does not hold any more
Examples: {SSN, PNUMBER} HOURS is a full FD since
neither SSN HOURS nor PNUMBER HOURS hold
{SSN, PNUMBER} ENAME is not a full FD (it is called a partial dependency ) since SSN ENAME also holds
Chapter 5 81
Second Normal Form (2) A relation schema R is in second normal
form (2NF) if every non-prime attribute A in R is fully functionally dependent on the primary key
R can be decomposed into 2NF relations via the process of 2NF normalization
If the relation is 1NF and the key consist of single attribute, then the relation is automatically in 2NF.
nonkey attributes = attributes that don’t appear in any candidate keynonkey attributes = attributes that don’t appear in any candidate key
Chapter 5 82
Normalizing into 2NF and 3NF
Chapter 5 83
3.4 Third Normal Form (1) Definition:
Transitive functional dependency: a FD X Z that can be derived from two FDs X Y and Y Z
Examples: SSN DMGRSSN is a transitive FD
Since SSN DNUMBER and DNUMBER DMGRSSN hold
SSN ENAME is non-transitive Since there is no set of attributes X where SSN X and
X ENAME
Chapter 5 84
Third Normal Form A relation is in third normal form if
It is in 2NF No non-key attribute is transitively dependent on
the key
Chapter 585
Third Normal Form
Stu_id Stu_Name
Credits Status
S1001 Smith 90 Senior
S1002 Lee 15 Fresh
S1003 Jon 63 Junior
Transitive dependency (A B C)Stu_id Credits Status
If Stu_id Credits and Credits Statusthen we can write Stu_id Status
Chapter 586
Third Normal Form
Stu_id Stu_Name
Credits
S1001 Smith 90
S1002 Lee 15
S1003 Jon 63
Credits
Status
15 Fresh
63 Junior
90 Senior
Transitive dependency is removed
StudentStatus
Chapter 5 87
Third Normal Form (2) A relation schema R is in third normal
form (3NF) if it is in 2NF and no non-prime attribute A in R is transitively dependent on the primary key
R can be decomposed into 3NF relations via the process of 3NF normalization
NOTE: In X Y and Y Z, with X as the primary key,
we consider this a problem only if Y is not a candidate key.
When Y is a candidate key, there is no problem with the transitive dependency .
E.g., Consider EMP (SSN, Emp#, Salary ). Here, SSN Emp# Salary and Emp# is a candidate
key.
Chapter 5 88
Normal Forms Defined Informally 1st normal form
All attributes depend on the key -atomicity 2nd normal form
All attributes depend on the whole key - 3rd normal form
All attributes depend on nothing but the key – no transitivity
Chapter 5 89
Successive Normalization of LOTS into 2NF and 3NF
Chapter 5 90
SUMMARY OF NORMAL FORMS based on Primary Keys
Chapter 5
Enterprise KeysEnterprise Keys
91
Primary keys that are unique in Primary keys that are unique in the whole database, not just the whole database, not just within a single relationwithin a single relation
Corresponds with the concept of Corresponds with the concept of an object ID in object-oriented an object ID in object-oriented systemssystems
92
Figure 5-31 Enterprise keys
a) Relations with enterprise key
b) Sample data with enterprise key