The Relational Model and Normalization - Database Processing: Fundamentals, Design, and Implementation - page 125

Using another formula, we can compute the extended price of a part order by multiplying
the quantity of the item times its unit price, or:

ExtendedPrice = Quantity × UnitPrice

In this case, we say that ExtendedPrice is functionally dependent on Quantity and UnitPrice, or:

(Quantity, UnitPrice) S ExtendedPrice

Here the determinant is the composite (Quantity, UnitPrice).

Functional Dependencies That Are Not equations
In general, a functional dependency exists when the value of one or more attributes determines
the value of another attribute. Many functional dependencies exist that do not involve equations.
Consider an example. Suppose you know that a sack contains either red, blue, or yellow
objects. Further, suppose you know that the red objects weigh 5 pounds, the blue objects weigh 5
pounds, and the yellow objects weigh 7 pounds. If a friend looks into the sack, sees an object, and
tells you the color of the object, you can tell her the weight of the object. We can formalize this as:

ObjectColor S We i g ht

Thus, we can say that Weight is functionally dependent on ObjectColor and that ObjectColor
determines Weight. The relationship here does not involve an equation, but the functional de-
pendency holds. Given a value for ObjectColor, you can determine the object's weight.
If we also know that the red objects are balls, the blue objects are cubes, and the yellow
objects are cubes, we can also say:

ObjectColor S Shape

Thus, ObjectColor determines Shape. We can put these two together to state:

ObjectColor S (Weight, Shape)

Thus, ObjectColor determines Weight and Shape.
Another way to represent these facts is to put them into a table:

Object Color Weight Shape

Red 5 Ball

Blue 5 Cube

Yellow 7 Cube

This table meets all of the conditions listed in Figure 3-4, and therefore it is a relation. You
may be thinking that we performed a trick or sleight of hand to arrive at this relation, but, in
truth, the only reason for having relations is to store instances of functional dependencies. If
there were a formula by which we could take ObjectColor and somehow compute Weight and
Shape, then we would not need the table. We would just make the computation. Similarly, if
there were a formula by which we could take EmployeeNumber and compute EmployeeName
and HireDate, then we would not need an EMPLOYEE relation. However, because there is
no such formula, we must store the combinations of EmployeeNumber, EmployeeName, and
HireDate in the rows of a relation.