comp1212 comp1212 anomalies and dependencies dr. mabruk ali

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

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.

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


Green Gamma

15 Designer

Green Epsilon 9 Designer


Hoskins 55 Gamma

15 Consultant

Moore Gamma

15 Manager


35

35

37

37

48Only one value updated: ANOMALY

50

If a project ends (i.e., is deleted), what happens to the data for employees on that project?

Employee


Role

Green 35 Gamma

15 Designer



Hoskins 55 Gamma

15 Consultant

Moore 48 Gamma

15 Manager


Brown 20 Alpha 2 TechnicianDelete project Alpha

Delete anomalies

What happens to(Brown, 20)?ANOMALY

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


Role


Green 35 Gamma

15 Designer



Hoskins 55 Gamma

15 Consultant

Moore 48 Gamma

15 Manager


Employee


Role


Green 35 Gamma

15 Designer



Hoskins 55 Gamma

15 Consultant

Moore 48 Gamma

15 Manager


Johnson 36 ??? ??? ???

Where do we store(Johnson, 36) until then? ANOMALY

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

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

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)

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

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

comp1212 comp1212 anomalies and dependencies dr. mabruk ali

Documents