Functional Dependencies

• A Functional Dependency describes a relationship between attributes within a single relation.
• An attribute is functionally dependent on another if we can use the value of one attribute to determine the value of another.
• Example: Employee_Name is functionally dependant on Social_Security_Number because Social_Security_Number can be used to uniquely determine the value of Employee_Name.
• We use the arrow symbol -> to indicate a functional dependency.
  X -> Y is read X functionally determines Y

  Student_ID -> Student_Major
  Student_ID, CourseNumber, Semester -> Grade
  Course_Number, Section -> Professor, Classroom, NumberOfStudents
  SKU -> Compact_Disk_Title, Artist
  CarModel, Options, TaxRate -> Car_Price
      

  
  
• The attributes listed on the left hand side of the -> are called determinants.
  One can read A -> B as, “A determines B”. Or more specifically: Given a value for A, we can uniquely determine one value for B.

Keys and Uniqueness

• Key: One or more attributes that uniquely identify a tuple (row) in a relation.
• The selection of keys will depend on the particular application being considered.
• In most cases the key for a relation will already be specified during the conversion from the E-R model to a set of relations.
• Users can also offer some guidance as to what would make an appropriate key.
• Recall that no two relations should have exactly the same values, thus a candidate key would consist of all of the attributes in a relation.
• A key functionally determines a tuple (row). So one functional dependency that can always be written is:

            Key -> All other attributes  

• Not all determinants are keys.

Modification Anomalies

• Once our E-R model has been converted into relations, we may find that some relations are not properly specified. There can be a number of problems:
  • Deletion Anomaly: Deleting one fact or data point from a relation results in other information being lost.
  • Insertion Anomaly: Inserting a new fact or tuple into a relation requires we have information from two or more entities – this situation might not be feasible.
  • Update Anomaly: Updating one fact in a relation requires us to update multiple tuples.
• Here is a quick example to illustrate these anomalies: A company has a Purchase Order form:

Browse More Articles

Tweet

Written by sutha

We are Creative Blogger Theme Wavers which provides user friendly, effective and easy to use themes. Each support has free and providing HD support screen casting.