Database Reference
In-Depth Information
Table 3.11
Table with No Multivalue Dependency
StudentID
TimeBlock
WeekDay
10
9 am-12 pm
Monday
10
1 pm-4 pm
Monday
10
1 pm-4 pm
Tuesday
10
9 am-12 pm
Tuesday
11
1 pm-4 pm
Monday
11
9 am-12 pm
Tuesday
12
7 pm-10 pm
Wednesday
no multivalue dependency between the columns StudentID and TimeBlock. Similarly, you can
verify that there is no multivalue dependency between the columns StudentID and WeekDay.
Note that the above analysis should be done in a table with three or more columns. For a table
with two columns, multivalue dependency is called trivial multivalue dependency. For a table with
nontrivial multivalue dependency, it is not qualiied as in 4NF. A modiication anomaly can occur
in this type of table.
In the above normalization process, modiication anomalies are gradually removed as the table
is normalized to a higher level. he ultimate goal of table normalization is to eliminate all kinds
of anomalies. Now, the question is whether there is a normal form that can achieve this goal.
heoretically, the answer is yes. DKNF will eliminate all types of anomalies.
Domain-Key normal form
: Being in the DKNF, a table has no modiication anomaly. In
other words, if a table has no anomaly, it is in the DK/NF. heoretically, that is great. However,
unlike the normalization process shown above, the process to normalize a table to have the
DK/NF is mostly based on the designer's knowledge about the business requirements and his/
her design experience. here is no predeined rule to follow. In general, the DK/NF cannot be
achieved by a normalization process shown in the previous sections. he key to the converting
process is the designer's understanding of the business rules and constraints. It is a crucial step to
identify the requirements and constraints of an underlying business. Once business requirements
and rules are identiied for a database project, the designer can construct tables and relationships
to meet the requirements and rules. here may be some business rules that cannot be imple-
mented at this stage; you, as a database designer, can implement those rules later in database
application.
In 1981, Ronald Fagin deined the
Domain-Key normal form
as the following:
A relation is in DK-NF if and only if every
constraint
on the relation is a logical
consequence of
key
constraints and
domain
constraints.
he deinition seems a bit abstract. Indeed, in Fagin's deinition of the DK/NF, the words
such as constraints, keys, and domains have very general meanings. A domain constraint is a
rule that speciies the format, type, or range of allowed values for a column. hat is why domain
constraints are also called attribute constraints. A key constraint checks the uniqueness of the
rows in a table. he word “constraints” means rules to be enforced on functional dependency,
