.TH fd "" "" "/rdb Command"
.PC "Test for functional dependency of columns"
\fBfd \fIdeterminecolumn dependcolumn \fB< \fItable\fR
.PP
.II "column^functional dependency"
.II "functional dependency^test"
.II "test functional dependency"
The command
.B fd
reads
.I table
and tests whether its
.I determinecolumn
determines
.IR dependcolumn .
A column in a table functionally depends upon another column 
when there is only one value in the second column for each value in
the first.
This helps you to determine if a table is normalized.
(See the section on
.BR Normalization ,
below, for details on what this means.)
.SH Example
First let's look at our inventory table:
.DM
Item    Amount  Cost    Value   Description   
----    ------  ----    -----   --------------
   1         3    50      150   rubber gloves
   2       100     5      500   test tubes
   3         5    80      400   clamps
   4        23    19      437   plates
   5        99    24     2376   cleaning cloth
   6        89   147    13083   bunsen burners
   7         5   175      875   scales
.DE
.PP
Note that the first column,
.B Item,
is the key column for the table.
It functionally determines all of the other columns.
Each value in column
.B Item
is unique, so each value determines, or is the key,
to its row and all of the column values on it.
.PP
However, column
.B Cost
does not functionally depend upon
.B Amount
because there are two `5' values in
.B Amount
and each has a different value for
.B Cost
associated with it (on the same row or line).
The common sense (technically called the ``semantics'') of the
table is that knowing the number of items we have in inventory
does not tell us how much they cost.
.PP
Now let's see if
.B fd
can find the dependencies.
The command
.DM
	fd Item Cost < inventory
.DE
.PP
returns the message
.BR true .
This is correct, because
.B Item
is the key column.
However, the command
.DM
	fd Amount Cost < inventory
.DE
.PP
returns the message
.BR false .
This, too, is correct.
.SH Normalization
A key column should aways functionally determine all
of the other columns in the table.
But nonkey columns should not depend upon each other.
.PP
If there are too few data in the table, a
pseudo-dependency may be discovered.
Be sure your table has lots of data before you test it.
.PP
To normalize your tables, you must check for functional
dependencies.
When functional dependency is found with non\-key columns,
the columns should be projected and uniqued to form a second table.
Then the functionally dependent column, but not the
determining column, should be removed from the first table.
For example:
.DM
	column column1 column2 < table | uniq > newtable
	column `sed 1q table | sed s/column2//` < table > tmp
	mv tmp table
.DE
.PP
In the second table, the column that determines the other column
is the key for that table.
If you need to recreate the original first table, you can
join the two new tables by using the command
.BR jointable ,
as follows:
.DM
	jointable -j column1 table newtable > oldtable
.DE
.PP
Normalization, or simplification, is an important process.
Normalized files are smaller and are easier to maintain.
.SH "See Also"
.B
column,
jointable,
paste.rdb
.R
.br
COHERENT Lexicon:
.B
cut,
false,
mv,
paste,
sed,
true
.SO fd