8.1 atabase System Concepts - 6 th Edition Chapter 8: Relational Database Chapter 8: Relational Database Design Design Features of Good Relational Design Lossless join decomposition Functional Dependency Theory Atomic Domains and First Normal Form Normal Forms: BCNF and 3NF Decomposition Algorithms Using Functional Dependencies Database-Design Issues
Chapter 8: Relational Database Design. Features of Good Relational Design Lossless join decomposition Functional Dependency Theory Atomic Domains and First Normal Form Normal Forms: BCNF and 3NF Decomposition Algorithms Using Functional Dependencies Database-Design Issues. Larger Schemas?. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Decomposition Algorithms Using Functional Dependencies
Database-Design Issues
8.2Database System Concepts - 6th Edition
Larger Schemas?Larger Schemas?
Two schemas:
instructor (ID, name, dept_name, salary)
department (dept_name, building, budget)
Suppose we combine instructor and department into inst_dept as follows:
Result is possible repetition of information (the amount of budget)
刪掉就無 EE資訊
重複
8.3Database System Concepts - 6th Edition
Disadvantage of Large SchemasDisadvantage of Large Schemas
Update anomalies:
Modifying the budget in one tuple but not all tuples leads to inconsistency.
Cannot insert a new department until the first instructor is hired
ID is part of PK.
Deleting the last instructor will lose the department information
刪掉 Kim 就無 EE 資訊
8.4Database System Concepts - 6th Edition
What About Smaller Schemas?What About Smaller Schemas?
Suppose we had started with inst_dept. How would we know to split up (decompose) it into instructor and department?
Intuition: put “strongly-related” attributes in the same relation
Write a rule: “every department (identified by its department name) must have only one building and one budget value”.
Denote as a functional dependency:
dept_name building, budget
In inst_dept, because dept_name is not a candidate key, the building and budget of a department may have to be repeated.
This indicates the need to decompose inst_dept
Not all decompositions are good. Suppose we decompose employee(ID, name, street, city, salary) into
employee1 (ID, name)
employee2 (name, street, city, salary)
The next slide shows how we lose information -- we cannot reconstruct the original employee relation -- and so, this is a lossy decomposition.
8.5Database System Concepts - 6th Edition
A Lossy DecompositionA Lossy Decomposition
8.6Database System Concepts - 6th Edition
Example of Lossless-Join DecompositionExample of Lossless-Join Decomposition
Lossless join decomposition
Decomposition of R = (A, B, C)R1 = (A, B) R2 = (B, C)
A B
12
A
B
12
r B,C(r)
A (r) B (r)A B
12
C
AB
B
12
C
AB
C
AB
A,B(r)
8.7Database System Concepts - 6th Edition
Goal of NormalizationGoal of Normalization
Decide whether a particular relation R is in “good” form.
1NF, 2NF, 3NF, BCNF, etc In the case that a relation R is not in “good” form, decompose it into a
set of relations {R1, R2, ..., Rn} such that
each relation is in good form
the decomposition is a lossless-join decomposition
The normalization theory is based on functional dependencies
Constraints requiring that the value for a certain set of attributes determines uniquely the value for another set of attributes.
A functional dependency is a generalization of the notion of a key.
8.8Database System Concepts - 6th Edition
First Normal FormFirst Normal Form
Domain is atomic if its elements are considered to be indivisible units
Examples of non-atomic domains:
Set of names, composite attributes
A relational schema R is in first normal form if the domains of all attributes of R are atomic
Non-atomic values complicate storage and encourage redundant (repeated) storage of data
Example: Set of accounts stored with each customer, and set of owners stored with each account
We assume all relations are in first normal form. (It is not required in Object Based Databases (see page 1.18))
Non-1NF should be normalized as discussed in Chapter 7.
ID Name Phone_number
1 John {6601, 6602}
ID Name
1 John
ID Phone_number
1 6601
1 6602
8.9Database System Concepts - 6th Edition
ID Phone_number
2222222222
456-7890123-4567
ID Phone_number
22222 {456-7890,123-4567}
8.10Database System Concepts - 6th Edition
Functional Dependencies Functional Dependencies
Let R be a relation schema
R and R The functional dependency
holds on R if and only if for any legal relations r(R), whenever any two tuples t1 and t2 of r agree on the attributes , they also agree on the attributes .
Example: Consider R(A,B, C, D ) with the following instance of r.
On this instance, A C is satisfied, but C A is not satisfied.
Note: A specific instance of a relation schema may satisfy a functional dependency even if the functional dependency does not hold on all legal instances.
For example, a specific instance of classroom may, by chance, satisfy room_number capacity.
We usually use functional dependencies to specify constraints on all legal relations
We say that F holds on R if all legal relations on R satisfy the set of functional dependencies F.
→ contains a candidate key of the original schema, done!
8.33Database System Concepts - 6th Edition
Comparison of BCNF and 3NFComparison of BCNF and 3NF
It is always possible to decompose a relation into a set of relations that are in 3NF such that:
the decomposition is lossless
the dependencies are preserved
It is always possible to decompose a relation into a set of relations that are in BCNF such that:
the decomposition is lossless
it may not be possible to preserve dependencies.
Goal for a relational database design is:
BCNF.
Lossless join.
Dependency preservation.
If we cannot achieve this, we accept one of
Lack of dependency preservation
Redundancy due to use of 3NF
8.34Database System Concepts - 6th Edition
Overall Database Design ProcessOverall Database Design Process
We have assumed schema R is given
R could have been generated when converting E-R diagram to a set of tables.
R could have been a single relation containing all attributes that are of interest (called universal relation).
R could have been the result of some ad hoc design of relations.
Normalization breaks R into smaller relations.
8.35Database System Concepts - 6th Edition
ER Model and NormalizationER Model and Normalization
When an E-R diagram is carefully designed, identifying all entities correctly, the tables generated from the E-R diagram should not need further normalization.
However, in a real (imperfect) design, there can be functional dependencies from non-key attributes of an entity to other attributes of the entity Example: an employee entity with attributes
ID, department_name and building, and a functional dependency department_name building
The schema is employee( ID, department_name, building), which is not in 3NF or BCNF.
Good design would have made department an entity
8.36Database System Concepts - 6th Edition
Denormalization for PerformanceDenormalization for Performance
May want to use non-normalized schema for performance
For example, displaying prereqs along with course_id and title requires join of course with prereq
Alternative 1: Use denormalized relation containing attributes of course as well as prereq with all above attributes
faster lookup
extra space and extra execution time for updates
extra coding work for programmer and possibility of error in extra code
Alternative 2: use a materialized view defined as course prereq
Benefits and drawbacks same as above, except no extra coding work for programmer and avoids possible errors
8.37Database System Concepts - 6th Edition
Other Design IssuesOther Design Issues
Some aspects of database design are not caught by normalization
Examples of bad database design, to be avoided:
Instead of total_inst (dept_name, year, size ), use
Also in BCNF, but also makes querying across years difficult and requires new attribute each year.
Is an example of a crosstab, where values for one attribute become column names
Used in spreadsheets, and in data analysis tools
8.38Database System Concepts - 6th Edition
※ ※ 2NF (2NF ( 完全函數相依完全函數相依 )) A functional dependency α → β is called a partial dependency if
there is a proper subset γ of α such that γ → β. We say that β is partially dependent on α.
A relation schema R is in second normal form (2NF) if each attribute A in R meets one of the following criteria:
It appears in a candidate key.
It is not partially dependent on a candidate key.
8.39Database System Concepts - 6th Edition
※ ※ 3NF3NF ((不可遞移函數相依)不可遞移函數相依) Let a prime attribute be one that appears in at least one candidate
key.
Let α and β be sets of attributes such that α → β holds, but β → α does not hold. Let A be an attribute that is not in α, is not in β, and for which β → A holds. We say that A is transitively dependent on α.
A relation schema R is in 3NF with respect to a set F of functional dependencies if there are no nonprime attributes A in R for which A is transitively dependent on a key for R.