COMP1212 Anomalies and Dependencies
Dr. Mabruk Ali
Semantics of the Relation
Attributes
GUIDELINE 1: Informally, each tuple in a relation should represent one entity or relationship instance. (Applies to individual relations and their attributes).
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
Entity and relationship attributes should be kept apart as much as possible.
Bottom Line: Design a schema that can be explained easily relation by relation. The semantics of attributes should be easy to interpret.
Redundant Information in Tuples
and Update Anomalies Mixing attributes of multiple entities
may cause problemsInformation is stored redundantly
wasting storageProblems with update anomalies
◦Insertion anomalies◦Deletion anomalies◦Modification anomalies
Slide 4
Employee
Salary Project Budget
Role
Brown 20 Alpha 2 Technician
Green 35 Gamma
15 Designer
Green 35 Epsilon 9 Designer
Hoskins 55 Epsilon 9 Manager
Hoskins 55 Gamma
15 Consultant
Moore 48 Gamma
15 Manager
Moore 48 Epsilon 9 Designer
Data redundancyValues stored repetitively in
relations (esp. poorly designed relations)
Potential for anomalous data to be stored
This relation associates employees
with projects. Assume no
nulls are allowed.
Slide 5
Both values updated: OK
Update anomaliesEach person’s salary is repeated
for each project they are involved with. What does this imply when we need to increase someone’s salary?Employe
eSalary Project Budge
tRole
Brown 20 Alpha 2 Technician
Green Gamma
15 Designer
Green Epsilon 9 Designer
Hoskins 55 Epsilon 9 Manager
Hoskins 55 Gamma
15 Consultant
Moore Gamma
15 Manager
Moore 48 Epsilon 9 Designer
35
35
37
37
48Only one value updated: ANOMALY
50
Slide 6
If a project ends (i.e., is deleted), what happens to the data for employees on that project?
Employee
Salary Project Budget
Role
Green 35 Gamma
15 Designer
Green 35 Epsilon 9 Designer
Hoskins 55 Epsilon 9 Manager
Hoskins 55 Gamma
15 Consultant
Moore 48 Gamma
15 Manager
Moore 48 Epsilon 9 Designer
Brown 20 Alpha 2 TechnicianDelete project Alpha
Delete anomalies
What happens to(Brown, 20)?ANOMALY
Slide 7
Johnson hasn’t yet been assigned to a project, but no nulls allowed
Insert anomaliesWhat happens when we hire a
new person? (remember, no nulls allowed)
Employee
Salary Project Budget
Role
Brown 20 Alpha 2 Technician
Green 35 Gamma
15 Designer
Green 35 Epsilon 9 Designer
Hoskins 55 Epsilon 9 Manager
Hoskins 55 Gamma
15 Consultant
Moore 48 Gamma
15 Manager
Moore 48 Epsilon 9 Designer
Employee
Salary Project Budget
Role
Brown 20 Alpha 2 Technician
Green 35 Gamma
15 Designer
Green 35 Epsilon 9 Designer
Hoskins 55 Epsilon 9 Manager
Hoskins 55 Gamma
15 Consultant
Moore 48 Gamma
15 Manager
Moore 48 Epsilon 9 Designer
Johnson 36 ??? ??? ???
Where do we store(Johnson, 36) until then? ANOMALY
Slide 8
Employee
Salary
Brown 20
Green 35
Hoskins 55
Moore 48
Employee
Project Role
Brown Alpha Technician
Green Gamma
Designer
Green Epsilon Designer
Hoskins Epsilon Manager
Hoskins Gamma
Consultant
Moore Gamma
Manager
Moore Epsilon Designer
Project Budget
Alpha 2
Gamma
15
Epsilon 9
The solution: NormalisationBreaking up the relation
eliminates the worst of the redundancy
Functional Dependencies (FD) An important concept associated with
normalization. Functional dependency describes the relationship
between attributes.
For example, if A and B are attributes of relation R, B is functionally dependent on A (denoted A → B), if each value of A in R is associated with exactly one value of B in R.
An alternative way to describe the relationship between attributes A and B is to say that
“A functionally determines B”.
A Called (the Determinant) B Called (the dependent)
Characteristics of FDsDeterminants should have the
minimal number of attributes necessary to maintain the functional dependency with the attribute(s) on the right hand-side.
This requirement is called full functional dependency.
Identifying FDs
Identifying all functional dependencies between a set of attributes is relatively simple if the meaning of each attribute and the relationships between the attributes are well understood.
This information should be provided by the enterprise in the form of discussions with users and/or documentation such as the users’ requirements specification.
Identifying FDs (Cont)
However, if the users are unavailable for consultation and/or the documentation is incomplete then depending on the database application it may be necessary for the database designer to use their common sense and/or experience to provide the missing information.
Examples of FD constraints (1) social security number determines
employee nameSSN -> ENAME
project number determines project name and locationPNUMBER -> {PNAME, PLOCATION}
employee ssn and project number determines the hours per week that the employee works on the project{SSN, PNUMBER} -> HOURS
Types of functional dependencyFullPartialTransitive
Full Functional Dependency
Full functional dependency indicates that if A and B are attributes of a relation. B is fully functionally dependent on A, if B is functionally dependent on A, but not on any proper subset of A.
A functional dependency A → B is a partially dependency if there is some attribute that can be removed from A and yet the dependency still holds.
A B == LHS RHS
Slide 16
Example of Full FDExample: R(Year, Course_code,
Course_coordinator)◦ year + course_code course_coordinator ◦ (i.e., course_coordinator determined by
combination of both a particular year and a course_code)
◦ If we remove either Year or Course code from the left hand side (LHS) (the determinant), the dependency is no longer exist.Year
Course_code
Course_coordinator
Slide 17
Partial functional dependency
Subset of left hand side determines right hand side◦ “extra” attributes on LHS are unnecessary
Student ID
Date of Birth
InvoiceNumbe
rStuden
tName
InvoiceDate
Invoice
Total
R1(StudentId, StudentName,DateOfBirth)R2(InvoiceNumber, InvoiceDate, InvoiceTotal)
Slide 18
Now Full functional dependency
left hand side determines right hand side◦No “extra” attributes on LHS are
unnecessary
Student ID
Date of Birth
InvoiceNumbe
r
Invoice
Total
Slide 19
Transitive dependencyTransitive dependency
◦ part number determines supplier number◦ supplier number determines supplier name◦ therefore, part number alone also
determines supplier name
Ideally should not exist within the same relation
Partnumber
Suppliernumber
Suppliername
Partnumber
Suppliername
Transitive DependencyIt is important to recognize a transitive
dependency because its existence in a relation can potentially cause update anomalies.
Transitive dependency describes a condition where A, B, and C are attributes of a relation such that if
A → B and B → C, then C is transitively dependent on A via B
(provided that A is not functionally dependent on B or C).
MVD & JDNormal Forms will be discussed next
lecture.The fourth normal form makes use of
a new kind of dependency, called a multivalued dependency (MVD); MVDs are a generalization of FDs.
The fifth normal form makes use of an other new kind of dependency, called a join dependency (JD); JDs are a generalization of MVDs, just as MVDs are a generalization of FDs.
The End
Lecture 05 - ER to Relation Mapping 22