Uploaded by i211765

Week 13 Functional Dependency (1) 1

advertisement
Functional
Dependencies
Database Development
• Requirements Analysis
• Collect and Analyze the requirements of the users.
• Conceptual Design
• Design a conceptual model, e.g., ER model.
• Logical Design
• Translate the ER model into the relational model.
• Normalization.
• Database Building (Physical Design)
• Build the database and write application programs.
• Operation, Maintenance, & Tuning
• Use, maintain, and “tune” the database.
2
Normalization
• Decides which attributes should be grouped together in a relation
• Validates and improves the logical
proceeding to physical design.
design to the point before
• Based on the concept of Functional dependency.
3
Normalization
• Normalization
• To ensure you have a “good” design.
• To prove you have got a “good” one.
• To rescue a “bad” one.
• How?
• Decompose a “bad” table into several “good” ones.
• Move from a lower normal form to a higher (better) one.
• But what’s a “good” design?
4
Good Database Design
•
•
no redundancy of FACT (!)
no inconsistency
 examples: M/F or 1/0, Ahmed or Ahmad etc.,
 this creates anomalies
 Anomalies: Abnormal, Deviation from common rule
•
•
•
no insertion, deletion or update anomalies
no information loss
no dependency loss
5
Data Redundancy
• Major aim of relational database design is to group attributes into relations
to minimize data redundancy and reduce file storage space required by
base relations.
• Problems associated with data redundancy are illustrated by comparing the
following Staff and Branch relations with the StaffBranch relation.
6
Data Redundancy: Example-1
• StaffBranch relation has redundant data: details of a branch are repeated for every
member of staff.
Dr. Ejaz Ahmed
7
Redundancy leads to anomalies
StudentDepartment
Student
Department
StudentDepartment
Could we insert a department without a student?
We cannot insert a department who has no students, as studentID will have a NULL value,
which is not allowed as studentID is the primary key.
Insert Anomaly
• The inability to insert valid data into database due to absence of
certain another data is called insertion anomaly.
• To update a value, we need to update multiple rows.
• After update, same object has different values which leads to inconsistency
Update anomaly
• When redundant data is updated, data inconsistency may occur
due to partial update of data.
Can we keep student 3 and delete student information ?
We cannot delete student 3 without loosing department information as student 3 is the only
student of that department
Delete anomaly
• A delete anomaly occurs when deletion of some information
leads to loss of some another valid data
SOLUTION
• These anomalies are addressed by Normalization.
• The normalization makes sure that all these three issues and
other possible be addressed at the time of designing.
• Based on the concept of Functional dependency.
Functional Dependency
• The attributes of a table is said to be dependent on each other when an
attribute of a table uniquely identifies another attribute of the same table.
• It defines a relationship between two attributes, typically between the PK
and other non-key attributes within a table.
• Functional Dependency helps to maintain the quality of data in the
database.
• It plays a vital role to find the difference between good and bad database
design.
RollNo  FirstName
RollNo  LastName
RollNo  Marks
FirstName  RollNo
LastName  RollNo
Marks  RollNo
Functional Dependency
• Let R be a table,
• and let X and Y be sets of attributes of R (X is on LHS and Y is on RHS of an arrow
pointing from left to right),
• if the value of X always uniquely determines the value of Y.
then Y is functionally dependent (FD) on X,
• We write: X --> Y
(read “X functionally determines Y”, or “X arrows to Y”)
Or Y is associated with X
• X is called the determinant. Y is the dependent.
X
Y
Y is functionally dependent on X /
X functionally determines Y
(All attributes) of X uniquely determines Y (All attributes)
SSN
Movie (title, year, length, filmType, studioName, starName).
title, year length
title, year filmType
title, year studioName
shorthand: title year length,filmType, studioName
Functional Dependencies
• Functional dependencies (FDs) are used to specify formal
measures of the "goodness" of relational designs
• FDs and keys are used to define normal forms for relations
• FDs are constraints that are derived from the meaning and
inter-relationships of the data attributes
Types of Functional Dependencies
• Fully functionally dependent
• Partially functionally dependent
• Trivial functional Dependence
• Non-Trivial functional Dependence
• Completely Non-Trivial functional Dependence
• Transitive Dependency
Example_01: Fully Functionally Dependent
ItemPrice
SupplierID, ItemID  Price
SupplierID  Price
ItemPrice
SupplierID  Price
ItemPrice
ItemID  Price
ItemPrice
SupplierID, ItemID  Price
SupplierID  Price
ItemID  Price
Fully Functionally dependent
Fully functionally dependent
• If X and Y are attribute set of a relation, Y is fully functionally
dependent on X if Y is functionally dependent on X, but not on
any proper subset of X
Example_02: Partially Functionally Dependent
StudentID, DeptID  DeptName
DeptID  DeptName
Partial Functionally dependent
Partial functionally dependent
• A functional dependency X Y is a partial dependency if there
is some attribute that can be removed from X and yet the
dependency still holds.
FD1:
StudentID, CourseID  StudentName
FD2:
CourseID  CourseName
FD3:
StudentID, CourseID  CourseName
FD4:
CourseID  CourseName
FD5:
StudentID, CourseID  Grade
StudentID Grade
CourseID Grade
Partial Functionally dependent
Full Functionally dependent
Partial Functionally dependent
Full Functionally dependent
Full Functionally dependent
Trivial Functional Dependency
• The functional dependency XY is a trivial functional dependency if Y is
subset of X.
StudentID, StudentName  StudentID
StudentID  StudentID
Non-Trivial Functional Dependency
The functional dependency XY is a non-trivial functional dependency if Y is
not a subset of X.
StudentID Branch
StudentID, StudentName  Branch
StudentID, StudentName  StudentName , Branch
Completely Non-Trivial Functional Dependency
• The functional dependency XY is completely non-trivial functional
dependency if X intersection Y is null.
StudentID Branch
StudentID, StudentName  Branch
StudentID, StudentName  StudentName , Branch
Non-trivial
Transitive Functional Dependency
A transitive dependency in a database is an indirect relationship
between values in the same table that causes a functional
dependency.
• Let X,Y,Z be attributes of a relation R,
• If X Y and YZ, then Z is transitively dependent on X.
FD1:
StudentID  DepID
FD2:
DepID  DepName
FD3:
StudentID  DepName
Transitive Functional Dependency (Example)
FD1:
Book → Author
FD2:
Author → Author_Nationality
FD3:
Book →Author_Nationality:
Download