Chapter 8: Relational Database Design - خضوريietc.ptuk.edu.ps/read.php?file=0AhmadRabya.pdf ·...

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan

See www.db-book.com for conditions on re-use

Chapter 8: Relational Database Design

http://www.db-book.com/



©Silberschatz, Korth and Sudarshan 8.2 Database System Concepts - 6th Edition

Design of Relation Schemas

• A database can be modeled as:

a collection of entities,

Attributes are properties used to describe an entity.

• Relational database design?

• The grouping of attributes to form "good" relation schemas.

• To measure the quality of the design.

• The goals of the design activity are information protection

and minimum redundancy.


Informal Design Guidelines for

Relation Schemas

1. Clear Semantics to Attributes in Relations

2. Redundant Information in Tuples and Anomalies

3. NULL Values in Tuples

4. Generation of Spurious Tuples


1. Clear Semantics to Attributes in

Relations

Guideline #01:

Informally, each tuple in a relation should represent one

entity or relationship instance.

• Attributes of different entities (EMPLOYEEs,

DEPARTMENTs, PROJECTs) should not be mixed in the

same relation

• Only foreign keys should be used to refer to other entities

• Design a schema that can be explained easily relation by

relation.


A simplified

COMPANY

relational

database

schema.


Sample database

state for some of

the COMPANY

relational database


2. Redundant Information in Tuples

and Anomalies

• One goal of schema design is to minimize the storage

space used by the base relations.

• Grouping attributes into relation schemas has a

significant effect on storage space

• Information is stored redundantly wasting storage

• Example:

• Two relations EMPLOYEE and DEPARTMENT.

• Single EMP_DEPT relation.


Sample schema and states for EMP_DEPT

• In EMP_DEPT, the attribute values of a particular department

(Dnumber, Dname, Dmgr_ssn) are repeated for every

employee who works for that department. In contrast, each

department’s information appears only once in the

DEPARTMENT relation.



and Anomalies

Insertion Anomalies:

To insert a new employee tuple into EMP_DEPT, we

must include either the attribute values for the

department that the employee works for, or NULLs (if the

employee does not work for a department as yet).

It is difficult to insert a new department that has no

employees as yet in the EMP_DEPT relation.



and Anomalies

Deletion Anomalies:

If we delete from EMP_DEPT an employee tuple that

happens to represent the last employee working for a

particular department, the information concerning that

department is lost from the database.



and Anomalies

Modification Anomalies:

In EMP_DEPT, if we change the value of one of the

attributes of a particular department (say, the manager of

department 5) we must update the tuples of all

employees who work in that department; otherwise, the

database will become inconsistent.



and Anomalies

Guideline #02:

Design a schema that does not suffer from the insertion,

deletion and update anomalies.



Many attributes may be grouped together into a “fat”

relation.

If many of the attributes do not apply to all tuples in the

relation, we end up with many NULLs in those tuples.

This can waste space at the storage level.

Reasons for nulls:

attribute not applicable or invalid.

attribute value unknown (may exist).

value known to exist, but not yet available.



Guideline #03:

Relations should be designed such that their tuples

will have as few NULL values as possible.

Attributes that are NULL frequently could be placed

in separate relations (with the primary key)


Functional Dependencies

• A set of attributes X functionally determines a set of

attributes Y if the value of X determines a unique value for

Y.

• X -> Y holds if whenever two tuples have the same value

for X, they must have the same value for Y.

• We also say that there is a functional dependency from X

to Y, or that Y is functionally dependent on X.

• A functional dependency is a generalization of the notion of a

key


Functional Dependencies (Cont…)

• A functional dependency X -> Y is a full dependency if

removal of any attribute A from X means that the

dependency does not hold any more.

• A functional dependency X->Y is a partial dependency if some attribute A can be removed from X and the

dependency still holds.


Normalization

Normalization: The process of decomposing

unsatisfactory "bad" relations by breaking up their

attributes into smaller relations

Considered as a “filtering” or “purification” process to

make the design have better quality, through a series of

tests to certify whether a relation schema satisfies a

certain normal form.

• Normalization is a process of analyzing relation schemas

to achieve:

• Minimizing redundancy.

• Minimizing the insertion, deletion, and update anomalies


Key and Attributes

• If a relation has more than one key, each is called a

candidate key.

• One of the candidate keys is designated to be the

primary key, and the others are called secondary

keys.

• A Prime attribute must be a member of some

candidate key.

• A Nonprime attribute is not a prime attribute—that is,

it is not a member of any candidate key.


First Normal Form (1NF)

• Disallows composite attributes and multivalued attributes;

attributes whose values for an individual tuple are non-

atomic.

• The value of any attribute in a tuple must be atomic

(simple) value.


First Normal Form (1NF) Cont…



• DEPARTMENT relation is not in 1NF:

• The domain of Dlocations contains sets of values and

hence is nonatomic.

• Dlocations is not functionally dependent on the primary

key Dnumber.



• There are three main techniques to achieve first normal

form for such a relation:

1. Remove the attribute Dlocations that violates 1NF and

place it in a separate relation DEPT_LOCATIONS along

with the primary key Dnumber of DEPARTMENT.

• The primary key of this relation is the combination{Dnumber,

Dlocation}



2. Expand the key so, there will be a separate tuple in the

original DEPARTMENT relation for each location of a

DEPARTMENT.

• In this case, the primary key becomes the combination

{Dnumber, Dlocation}.

• This solution has the disadvantage of introducing

redundancy in the relation.



3. If a maximum number of values is known for the

attribute (for example, if it is known that at most three

locations can exist for a department) replace the

Dlocations attribute by three atomic attributes:

Dlocation1, Dlocation2, and Dlocation3.

• This solution has the disadvantage of introducing NULL

values if most departments have fewer than three

locations.

• From the 3 techniques, the first considered Best.


Second Normal Form (2NF)

• Second normal form (2NF) is based on the concept of full

functional dependency.

• A functional dependency X -> Y is a full functional

dependency if removal of any attribute A from X means that

the dependency does not hold any more.

• Definition: A relation R is in 2NF if every nonprime

attribute A in R is fully functionally dependent on the

primary key of R.

• For relations where primary key contains multiple attributes.


Second Normal Form (2NF) Cont…

• The EMP_PROJ relation is in 1NF but is not in 2NF.

• The attribute Ename violates 2NF because of FD2, as do

the attributes Pname and Plocation because of FD3.

• The functional dependencies FD2 and FD3 make Ename,

Pname, and Plocation partially dependent on the primary

key {Ssn, Pnumber} of EMP_PROJ, thus violating the 2NF

test.


Second Normal Form (2NF) Cont…

• If a relation is not in 2NF, it can be 2NF normalized into a

number of 2NF relations in which attributes are

associated only with the part of the primary key on which

they are fully functionally dependent.


Third Normal Form (3NF)

• Third normal form (3NF) is based on the concept of

transitive dependency.

• A functional dependency X->Y in a relation R is a transitive

dependency if that can be derived from two FDs X->Z and

Z->Y.

• A relation 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.


Third Normal Form (3NF) Cont…

• The dependency Ssn Dmgr_ssn is transitive through

Dnumber in EMP_DEPT, because both the dependencies

Ssn Dnumber and Dnumber Dmgr_ssn hold.

• The relation EMP_DEPT is in 2NF, since no partial

dependencies on a key exist.

• However, EMP_DEPT is not in 3NF because of the

transitive dependency of Dmgr_ssn (and also Dname) on

Ssn via Dnumber


Third Normal Form (3NF) Cont…

• We can normalize EMP_DEPT by decomposing it into the

two 3NF relation schemas ED1 and ED2.

• ED1 and ED2 represent independent entity facts about

employees and departments.

• A NATURAL JOIN on ED1 and ED2 will recover the original

relation.


LET‘S SUM UP...!


Dependencies: Definitions

Multivalued Attributes:– non-key attributes the values of them are not uniquely identified by (not functionally dependent on) the Primary Key.



Partial Dependency:– when an non-key attribute is determined by a part, but not the whole, of a COMPOSITE primary key.



Transitive Dependency:– when a non-key attribute determines another non-key attribute.


What is Normalization

Normalization allows us to organize data so that it:

Allows faster access (dependencies make sense)

Reduced space (less redundancy)


Normal Forms: Review

• Unnormalized – There are multivalued

attributes or repeating groups

• 1 NF – No multivalued attributes or repeating

groups.

• 2 NF – 1 NF plus no partial dependencies

• 3 NF – 2 NF plus no transitive dependencies


PART

Part_ID Descr Price Comp_ID No

Example 1: Determine NF

Part_ID Description

Part_ID Price

Part_ID, Comp_ID No

Comp_ID and No are not

determined by the primary

key; therefore, the relation is

NOT in 1 NF. No sense in

looking at partial or transitive

dependencies.


PART

Part_ID Descr Price Comp_ID No


Part_ID Description

Part_ID Price

Part_ID, Comp_ID No

In your solution you will write

the following :

There are M/V attributes; so,

not 1NF

Conclusion: The relation is not

normalized.


Product_ID Description

ORDER

Order_No Product_ID Description


All attributes are directly or

indirectly determined by the

primary key.

Relation is at least in 1 NF



ORDER



The relation is at least in 1NF.

There is a COMPOSITE Primary Key (Order_No,

Product_ID), so there can be partial dependencies.

Product_ID, which is a part of PK, determines

Description; hence, there is a partial dependency.

So, the relation is not 2NF.

No need to check for transitive dependencies (3NF)!




ORDER


We know that the relation is at least

in 1NF, and it is not in 2 NF.

Therefore, we conclude that the

relation is in 1 NF.


Product_ID

Description


ORDER


In your solution you will write the following:

1) No M/V attributes, therefore at least 1NF

2) There is a partial dependency

(Product_ID Description), therefore

not in 2NF

Conclusion: The relation is in 1NF



ISBN Title

ISBN Publisher

Publisher Address

BOOK

ISBN Title Publisher Address

All attributes are directly or

indirectly determined by

the primary key.

Relation is at least in 1 NF



ISBN Title

ISBN Publisher

Publisher Address

BOOK


The relation is at least in 1NF.

There is no COMPOSITE

primary key, so there can’t be

partial dependencies.

Relation is at least in 2NF



ISBN Title

ISBN Publisher

Publisher Address

BOOK


Publisher is a non-key attribute,

and it determines Address,

another non-key attribute.

There is a transitive

dependency, which means that

the relation is NOT in 3 NF.



ISBN Title

ISBN Publisher

Publisher Address

BOOK


We know that the relation is

at least in 2NF, and it is not

in 3 NF. Therefore, we

conclude that the relation is

in 2NF.


ISBN Title

ISBN Publisher

Publisher Address

BOOK


In your solution you will write the

following :

1) No M/V attributes, so at least 1NF

2) No partial dependencies, at least

2NF

3) There is a transitive dependency

(Publisher Address), so , not

3NF

Conclusion: The relation is in 2NF


Bringing a Relation to 1NF

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00

101 Lennon MSI 415 3.00

125 Johnson MSI 331 3.00



STUDENT


101 Lennon MSI 250 3.00

101 Lennon MSI 415 3.00


Option 1: Make a determinant of the repeating group (or

the multivalued attribute) a part of the primary key.

Composite

Primary Key



Option 2: Remove the entire repeating group from the relation.

Create another relation which would contain all the attributes of the repeating group, plus the primary key from the first relation.

In this new relation, the primary key from the original relation and the determinant of the repeating group will comprise a primary key.

STUDENT


101 Lennon MSI 250 3.00

101 Lennon MSI 415 3.00




STUDENT_COURSE

Stud_ID Course Units

101 MSI 250 3

101 MSI 415 3

125 MSI 331 3

STUDENT

Stud_ID Name

101 Lennon

125 Jonson



STUDENT


101 Lennon MSI 250 3.00

101 Lennon MSI 415 3.00


Composite

Primary Key



STUDENT


101 Lennon MSI 250 3.00

101 Lennon MSI 415 3.00


Composite

Primary Key

Goal: Remove Partial Dependencies

Partial Dependencies



STUDENT


101 Lennon MSI 250 3.00

101 Lennon MSI 415 3.00


Remove attributes that are dependent from the part but not the whole of the primary key.

For each partial dependency, create a new relation, with the corresponding part of the primary key from the original as the primary key.



STUDENT


101 Lennon MSI 250 3.00

101 Lennon MSI 415 3.00


STUDENT_COURSE

Stud_ID Course_ID

101 MSI 250

101 MSI 415

125 MSI 331

COURSE

Course_ID Units

MSI 250 3.00

MSI 415 3.00

MSI 331 3.00

STUDENT

Stud_ID Name

101 Lennon

101 Lennon

125 Johnson



Goal: Get rid of transitive dependencies.

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct

122 Sarah Smith 2 Mktg

Transitive

Dependency



Remove the attributes, which are dependent on a non-key attribute, from the original relation.

For each transitive dependency, create a new relation with the non-key attribute which is a determinant in the transitive dependency as a primary key, and the dependent non-key attribute as a dependent.

EMPLOYEE






EMPLOYEE

Emp_ID F_Name L_Name Dept_ID

111 Mary Jones 1

122 Sarah Smith 2

EMPLOYEE




DEPARTMENT

Dept_ID Dept_Name

1 Acct

2 Mktg


ALL THE BEST...!

Chapter 8: Relational Database Design - خضوريietc.ptuk.edu.ps/read.php?file=0AhmadRabya.pdf ·...

Documents

Transcript of Chapter 8: Relational Database Design - خضوريietc.ptuk.edu.ps/read.php?file=0AhmadRabya.pdf ·...