patternMinor
Normalization/normal forms - May a field describe an other field?
Viewed 0 times
fieldmaynormaldescribenormalizationotherforms
Problem
Like this:
I wonder if it violates this rule (because I don't fully understand the rule):
Every non-prime attribute of R is non-transitively dependent (i.e. directly dependent) on every superkey of R.
CREATE TABLE persons(
id serial8 NOT NULL PRIMARY KEY,
name varchar,
-- A lot of other fields
date_of_birth timestamp with time zone,
date_of_birth_precision varchar(16),
CHECK (date_of_birth_precision IN ('Years','Months','Days','Hours','Minutes'))
);date_of_birth_precision describes the precision of date_of_birth.I wonder if it violates this rule (because I don't fully understand the rule):
Every non-prime attribute of R is non-transitively dependent (i.e. directly dependent) on every superkey of R.
Solution
I disagree with the other answers on this one and do not believe this violates 3NF. This is because date_of_birth_precision does not imply date_of_birth nor does date_of_birth imply date_of_birth_precision.
It's important to note the definition of a functional dependency:
Given a relation R, a set of attributes X in R is said to functionally determine another set of attributes Y, also in R, (written X → Y) if, and only if, each X value is associated with precisely one Y value; R is then said to satisfy the functional dependency X → Y. Equivalently, the projection is a function, i.e. Y is a function of X.1 In simple words, if the values for the X attributes are known (say they are x), then the values for the Y attributes corresponding to x can be determined by looking them up in any tuple of R containing x. Customarily X is called the determinant set and Y the dependent set.
So let's ask ourselves, for a given value of date_of_birth_precision, does that imply a date_of_birth? Certainly not. For a given value of date_of_birth, does that imply a date_of_birth_precision? It doesn't, otherwise you wouldn't even be asking this question. Since neither implies the other, there is no functional dependency between the two. Therefore, this does not break 3NF because 3NF only qualifies the rules for functional dependencies; it says nothing about attributes which are not functionally dependent on each other.
I find the alternate definition of 3NF much easier to comprehend, personally:
A 3NF definition that is equivalent to Codd's, but expressed differently, was given by Carlo Zaniolo in 1982. This definition states that a table is in 3NF if and only if, for each of its functional dependencies X → A, at least one of the following conditions holds:
It's important to note the definition of a functional dependency:
Given a relation R, a set of attributes X in R is said to functionally determine another set of attributes Y, also in R, (written X → Y) if, and only if, each X value is associated with precisely one Y value; R is then said to satisfy the functional dependency X → Y. Equivalently, the projection is a function, i.e. Y is a function of X.1 In simple words, if the values for the X attributes are known (say they are x), then the values for the Y attributes corresponding to x can be determined by looking them up in any tuple of R containing x. Customarily X is called the determinant set and Y the dependent set.
So let's ask ourselves, for a given value of date_of_birth_precision, does that imply a date_of_birth? Certainly not. For a given value of date_of_birth, does that imply a date_of_birth_precision? It doesn't, otherwise you wouldn't even be asking this question. Since neither implies the other, there is no functional dependency between the two. Therefore, this does not break 3NF because 3NF only qualifies the rules for functional dependencies; it says nothing about attributes which are not functionally dependent on each other.
I find the alternate definition of 3NF much easier to comprehend, personally:
A 3NF definition that is equivalent to Codd's, but expressed differently, was given by Carlo Zaniolo in 1982. This definition states that a table is in 3NF if and only if, for each of its functional dependencies X → A, at least one of the following conditions holds:
- X contains A (that is, X → A is trivial functional dependency), or
- X is a superkey, or
- Every element of A-X, the set difference between A and X, is a prime attribute (i.e., each column in A-X is contained in some candidate key)
Context
StackExchange Database Administrators Q#37429, answer score: 2
Revisions (0)
No revisions yet.