问题
I need to design database which would keep track of the following attributes:
stdnum // student number
postcode // postal code
phone_number // student phone number
city // student address: city
Also listed are functional dependencies:
stdnum -> postcode
stdnum -> phone_number
postcode -> city
phone_number -> city
I need to find lossless-join, dependency preserving, 3rd normal form decomposition of the attributes.
I have tried different decompositions but there was no one that obeys all requirements (they are: lossless-join, dependency preserving, 3rd normal form).
E. g. if I leave original relation without changes (table would have all 4 attributes) I would get lossless-join, dependency preserving but not 3NF, only 2NF.
The following decomposition:
(stdnum, postcode, phone_number, city) =
=(stdnum, postcode, phone_number) JOIN (postcode, city) JOIN (phone_number, city)
is in 3NF, dependency preserving, but not lossless-join.
Is there any solution for my problem?
Thank.
回答1:
Perhaps the purpose of the assignment is to make you discover the negative answer to your question "Is there any solution for my problem?".
Having your database as a single 4-attribute thing necessarily means there can be only one D (city) for each A (stud). Decomposing in the usual way for the B->D and C->D FDs, necessarily introduces the possibility of having two distinct D's associated with each A.
Dealing with that requires the introduction of a database constraint into the design, but database constraints are outside the scope of normalization theory proper.
And not decomposing necessarily means that you won't get 3NF.
Hence : perhaps the purpose of the assignment is to make you discover that normalization isn't a holy grail of database design. I think you were already on that track.
回答2:
Your breakdown of the original relation presumes these dependencies point to the same CITY.
postcode -> city
phone_number -> city
In real life that is not always the case. For instance, in my own locality there are addresses which have a phone number with a LONDON area code but which lie in a KINGSTON, SURREY postcode. And then there are mobile phones, which don't map to any geographical location.
So I would resolve your problem by changing the data model.
"Attributes are abstraction. You don't need to understand meaning of atributes. All information about them is in the functional dependencies listed in the task."
Thinking with concrete examples is a better way to understand the flaws in our abstractions. In this case perhaps you really have five attributes not four. Or perhaps there is functional dependency postcode -> city is valid but phone_number -> city is bogus. Or perhaps you need to model the fact that a student can have more than one phone number e.g. digs landline (shared), mobile (personnel).
回答3:
As explained in this slides, there's always a dependency preserving, lossless join 3NF. The described algorithm for computing it is implemented in this prolog script (explanation and source).
Such a decomposition always exists, and in this case it's the one you approached:
(stdnum, postcode, phone_number) JOIN
(postcode, city) JOIN
(phone_number, city)
You can run the Tableau Algorithm to check that it actually is lossless join.
回答4:
In dependency theory, a join dependency is a constraint on the set of legal relations over a database scheme. A table T is subject to a join dependency if T can always be recreated by joining multiple tables each having a subset of the attributes of T. If one of the tables in the join has all the attributes of the table T, the join dependency is called trivial.
The join dependency plays an important role in the Fifth normal form, also known as project-join normal form, because it can be proven that if you decompose a scheme R in tables R_1 to R_n, the decomposition will be a lossless-join decomposition if you restrict the legal relations on R to a join dependency on R called *(R_1,R_2,...R_n).
Another way to describe a join dependency is to say that the set of relationships in the join dependency is independent of each other.
Unlike in the case of functional dependencies, there is no sound and complete axiomatization for join dependencies, though axiomatization exist for more expressive dependency languages such as full typed dependencies. However, implication of join dependencies is decidable.
来源：https://stackoverflow.com/questions/7994867/designing-lossless-join-dependency-preserving-3nf-database