Editing Functional dependency (section)

== Examples ==

=== Cars ===
Suppose one is designing a system to track vehicles and the capacity of their engines. Each vehicle has a unique [[vehicle identification number]] (VIN). One would write ''VIN'' → ''EngineCapacity'' because it would be inappropriate for a vehicle's engine to have more than one capacity. (Assuming, in this case, that vehicles only have one engine.) On the other hand, ''EngineCapacity'' → ''VIN'' is incorrect because there could be many vehicles with the same engine capacity.

This functional dependency may suggest that the attribute EngineCapacity be placed in a relation with [[candidate key]] VIN. However, that may not always be appropriate. For example, if that functional dependency occurs as a result of the [[transitive relation|transitive]] functional dependencies VIN → VehicleModel and VehicleModel → EngineCapacity then that would not result in a normalized relation.

=== Lectures ===
This example illustrates the concept of functional dependency. The situation modelled is that of college students visiting one or more lectures in each of which they are assigned a teaching assistant (TA). Let's further assume that every student is in some semester and is identified by a unique integer ID.

{| class="wikitable"
|-
! Student ID !! Semester !! Lecture !! TA
|-
| 1234 || 6 || Numerical Methods || John
|-
| 1221 || 4 || Numerical Methods || Smith
|-
| 1234 || 6 || Visual Computing || Bob
|-
| 1201 || 2 || Numerical Methods || Peter
|-
| 1201 || 2 || Physics II || Simon
|}

We notice that whenever two rows in this table feature the same StudentID,
they also necessarily have the same Semester values. This basic fact
can be expressed by a functional dependency:
* StudentID → Semester.

If a row was added where the student had a different value of semester, then the functional dependency FD would no longer exist. This means that the FD is implied by the data as it is possible to have values that would invalidate the FD. 

Other nontrivial functional dependencies can be identified, for example:
* {StudentID, Lecture} → TA
* {StudentID, Lecture} → {TA, Semester}

The latter expresses the fact that the set {StudentID, Lecture} is a [[superkey]] of the relation.

=== Employee department ===

A classic example of functional dependency is the employee department model. 

{| class="wikitable"
|-
! Employee ID !! Employee name !! Department ID !! Department name
|-
| 0001 || John Doe || 1 || Human Resources
|-
| 0002 || Jane Doe || 2 || Marketing
|-
| 0003 || John Smith || 1 || Human Resources
|-
| 0004 || Jane Goodall || 3 || Sales
|}

This case represents an example where multiple functional dependencies are embedded in a single representation of data. Note that because an employee can only be a member of one department, the unique ID of that employee determines the department.

* Employee ID → Employee Name
* Employee ID → Department ID

In addition to this relationship, the table also has a functional dependency through a non-key attribute

* Department ID → Department Name

This example demonstrates that even though there exists a FD Employee ID → Department ID - the employee ID would not be a logical key for determination of the department Name. The process of normalization of the data would recognize all FDs and allow the designer to construct tables and relationships that are more logical based on the data.