Relation: R(ABCDE)
FD: F = {AB-> CDE, A->CD}
Solution: CK = AB
Prime Attribute = A,B
Non Prime Attribute = C,D,E
What normal form is R in?
R(ABCDE) is in 1NF because it has only atomic data and violates 2NF's rule.
if we were to decompose R into relation R1(A,C,D), R2 (A,B ,E) then it would be in BCNF( or higher)
Note:
The relation is in Normal forms if it does not violate some rules, so theoretically R1, R2 are also in 4nf --they don't violate 4nf's condition-- and may be higher normal forms(I have no idea about them).
I said BCNF above instead of 4nf because it is in bcnf because of decomposition while it is in 4nf because it is too simple to violate 4nf's rules
Related
I have the following question:
Consider relation R(A, B, C, D, E, F, H) with the following functional dependencies:
A --> D, AE --> H, DF --> BC, E --> C, H --> E
Consider three relational schema R1(A, D), R2(E, C), and R3(A, B, E, F, H). They form a decomposition for R.
(a) Do the original functional dependencies apply in R1, R2, and R3?
(b) Is this decomposition in 3NF? Explain your answer.
My attempt:
(a) The original functional dependencies apply in R1, R2, and R3 as long as the relation contains the attributes in the functional dependencies.
(b) No. Keys in R3 = {AEF, AFH}. From {AF}+ = {ABCDF} in R, in R3 {AF}+ = {ABF}. Hence we can form a functional dependency AF --> B, and the LHS of this functional dependency does not contain a key. The RHS also does not contain only key attributes.
The solution provided did not address (a) directly, and stated that the decomposition is in 3NF because the original FDs do not violate 3NF. Would like to know what I did wrongly here. Thank you!
In the following I assume that the dependencies given are a cover of the dependencies of R.
(a) Do the original functional dependencies apply in R1, R2, and R3?
When one decomposes a relation, not necessarily the dependencies of a cover applies to the decomposed relations. This happens when a decomposed relation does non contains all the attributes of a dependency. For instance, in your example, DF -> BC does not hold in any of R1, R2, R3, since the attributes DFBC are not all present in a single relation (we know that functional dependencies are meaningful only inside a relation).
This not necessarily means that the decomposition suffers from a “loss of dependency”, since the definition is more complex: A decomposition of a relation schema R with attributes A and cover of dependencies F preserves the dependencies if and only if the union of the projections of the dependencies of F over the decomposed relation is a cover of F.
In Ullman, Principles of Database Systems, Computer Science Press, 1983, an algorithm is shown to compute the closure of the union of the projection of a set of dependency over a decomposition. In your particular case, by applying that algorithm we can find that the dependency DF -> BC is actually lost.
(b) Is this decomposition in 3NF?
Here you answer is correct, since the third decomposed relation is not in 3NF. As you have correctly pointed out, the candidate keys for this relation are {AEF, AFH}, while in the relation the dependency AF -> B hold, and this is a dependency that violates the 3NF since AF is not a superkey and B is not a prime attribute.
It seems to me that Bernstein's synthesis / 3NF synthesis always yields BCNF subrelations, but that's apparently not true.
When one uses 3NF synthesis, one will have subrelations as a result, and they will each consist of either:
just one functional dependency along with all attributes of the schema, so the left side of the lone functional dependency will be a superkey, and that subrelation will therefore be in BCNF.
multiple functional dependencies each of which have the same left side, so they're each superkeys, and that subrelation will therefore be in BCNF.
no functional dependency where the schema includes the attributes making up the primary key of the original / non-decomposed relation, which would satisfy BCNF vacuously because of there being no functional dependencies.
What is an example of the 3NF synthesis algorithm yielding a non-BCNF decomposition and why it is so?
Bernstein's algorithm returns (one or more) components in EKNF, which lies between 3NF & BCNF.
Your claims of "that subrelation will therefore be in BCNF" are wrong. The FDs that hold in a component are all the ones in the closure of the original relation whose attributes are all in the component. So FDs could hold in a component that are not out of its superkeys. (Which by definition of BCNF is just another way of saying a component could be not in BCNF. Obviously--since we are told that the algorithm doesn't always give BCNF.)
Since your reasoning is unsound, finding a counterexample seems moot. But just about any presentation of BCNF gives an example non-BCNF 3NF relation, which it then decomposes to BCNF. You can join the non-BCNF 3NF relation with a projection on attributes of one of its CKs extended by a fresh non-prime attribute, and Bernstein's algorithm can decompose back to the 2 tables.
Chris Date's classic An Introduction to Database Systems has a non-BCNF 3NF schema R(S, J, T) with minimal/irreducible cover
{S, J} -> T
{T} -> J
CKs are {S, J} & {T, J}. Berstein gives component (S, J, T)--non-BCNF 3NF input R--in which both given FDs hold--plus redundant component (T, J).
For an example with an additional non-redundant component, extend the cover by {T} -> X. CKs are the same. {S, J} -> T again gives (S, J, T)--non-BCNF--plus component (T, J, X).
So, could someone please give me an example of the 3NF synthesis algorithm yielding a non-BCNF decomposition and tell why it is so?
A better "So, [...]" would be, So, what is wrong with my reasoning? You would do well to examine the assumptions you made about what FDs could hold in a component. (That article happens to point out (with reference) that "A 3NF table that does not have multiple overlapping candidate keys is guaranteed to be in BCNF.")
There is no "why" in mathematics. We assume things ("assumptions", "axioms", "premises") & other things follow. We can ask for a proof of something, but the proof does not say "why" the something is so, it's a demonstration that it is so. "Why" might be used trying to ask for a proof or for steps that you got wrong in or are missing from whatever almost-proof you have in mind.
PS Such a ubiquitous non-BCNF 3NF relation is Today's Court Bookings in the Wikipedia article on BCNF as I write. But beware that that particular example has perhaps unintuitive FDs. Indeed beware that almost every relational model Wikipedia page--including that one--has errors & misconceptions. So do many, many textbooks, especially re normalization.
The answer of philipxy is correct. Since you are asking for an example, here there are a couple of them.
The relation (with a cover of the functional dependencies):
R (A B C D)
A B → C
C → D
D → B
through the synthesis algorithm is decomposed in:
R1 (A B C)
R2 (C D)
R3 (B D)
and R1 is not in BCNF for the dependency C → B (the candidate key is AB). Note that C → B is not present in the original cover, but is a dependency implied from it.
Here is another (classical) example:
Phones (AreaCode, PhoneNumber, Subscriber, Town, Street)
AreaCode, PhoneNumber → Town
AreaCode, PhoneNumber → Subscriber
AreaCode, PhoneNumber → Street
Town → AreaCode
The Bernsteins’s synthesis algorithm produces two subschemas:
R1 (AreaCode, PhoneNumber, Subscriber, Town, Street)
AreaCode, PhoneNumber → Town
AreaCode, PhoneNumber → Subscriber
AreaCode, PhoneNumber → Street
and:
R2 (Town, AreaCode)
Town → AreaCode
since R2 is included in R1, the algorithm eliminates the second relation. The resulting relation is in 3NF but not in BCNF, since the relation has two candidate keys, (AreaCode, PhoneNumber) and (PhoneNumber, Town) and the functional dependency Town → AreaCode violates the BCNF.
I am struggling with Carnonical Cover, Dependency Preservation and Lossless Decomposition.
Are the approach and thoughts here correct?
R(ABCDEFG)
Provided is the following set of dependencies after a canonical cover has been made. I did not do the canonical cover myself but the assignment said I had to assume it had been done.
Fc:
A -> C
E -> A
C -> ABF
F -> CDG
A+ = ABCDFG
E+ = ABCDEFG
C+ = ABCDFG
F+ = ABCDFG
E = Candidate Key.
This list of functional dependencies is in 2NF since there are no partial dependencies. It is however not in 3NF since there are transitive dependencies.
However decomposing into the following 4 relations will result in it being not only in 3NF but also BCNF
R1 = {E,A}
E -> A
R2 = {A, C}
A -> C
R3 = {CABF}
C -> ABF
R4 = {FCDG}
F -> CDG
I use A in R1 as a foreign key to R2 and C in R2 as a foreign key to R3 etc.
There are no transitive dependencies and since all left hand sides are candidate keys in their respective relations it is in BCNF.
Is also lossless and dependency preserving?
What is decomposed
In the title you say:
What is the correct approach when decomposing dependencies
but one does not decompose dependencies, but relation schemas. So, in this case, here there is a relation schema R(ABCDEFG) with a set of functional dependencies and one must decompose that schema.
What is a decomposition
A decomposition produces a set of relation schemas with the following properties: a) every attribute of the original schema is present in some (possibly more than one) subschema; b) no other attributes are present. Moreover, a decomposition is redundant when a relation subschema is contained in another. In your case, this is true for R2, which is contained in R3: there is no need to have both relations, since it would imply unuseful data redundancy.
What is a good decomposition
To be really useful, a decomposition should satisfy two important properties: preserve functional dependencies and preserve data (lossless decomposition). But another property characterizes a good decomposition: it should be as small as possible: there is no point in decomposing a schema in too many subschemas, since this would produce a non natural and complex database.
Actually your decomposition is lossless and preserves the dependencies.
How to decompose
The final objective of all this stuff is to produce a decomposisition (lossless and dependency preserving) in which the subschemas are in BCNF or 3NF. The simple solution of decomposing by using the attributes of the functional dependencies is not, however, a good solution. For this, there are algorithms, described in textbooks, that produces decompositions either for BCNF or for 3NF (the so-called “analysis” algorithm for BCNF, and “synthesis” algorithm for 3NF), trying to produce not too many subschemas. For instance, the “analysis” algorithm in this case produce the following decomposition in BCNF, with only two subschemas:
R1 < (A B C D F G) ,
{ F → C
F → D
F → G
C → A
C → B
C → F
A → C } >
R2 < (A E) ,
{ E → A } >
This decomposition is lossless and preserves the dependencies (which is not always true for the analysis algorithm).
The relation is
Student(StdNo,StdName,appointNo,timing,advisor)
and the functional dependancies are:
StdNo->StdName
StdNo,appointNo->Timing,advisor
Timing->appointNo
By normalising to 2NF I get:
R1(stdNo,appointNo,Timing,advisor)
R2(stdNo,StdName)
I think this is already in 3NF. But I am having trouble reducing to BCNF.
For BCNF, i think the R1 relation violates BCNF as Timing-> appointNo and Timing is not a super key. How can i reduce to BCNF?
You are correct in considering that the decomposition in R1, R2 is in 3NF but not in BCNF, for the reason you have specified (timing → appointNo violates the normal form).
So you should decompose R2 in R3(timing, appointNo) and R4(StdNo, advisor, timing), and the final decomposition is R1, R3, R4.
Note that with this decomposition the dependency StdNo,appointNo → timing,advisor is not preserved.
I have a problem breaking this into BCNF:
Relation: R[A E P M N S T L]
FD's:
A -> EM,
A -> L,
M -> ST,
M -> N,
S -> T,
E -> P,
P -> E,
L -> A
This one was on one of my past exams, and I don't really know how to solve it.
I learned this on coursera by the woman (Jennifer Widom) who wrote our course literature:
-------------- BCNF ALGORITHM ------------
1. Take a FD that violates BCNF.
2. Decompose the FD to two other relations
3. First relation: The whole FD
4. Second relation: The rest of the Relation + the left hand side of the chosen FD
5. Iterate until all the new relations have key on its left hand side
-------------- BCNF ALGORITHM ------------
And I also tried another one that is basically the same, but written in a different way:
X->Y: R1({X}+), R2(R - {X}+ ; X) (Relation minus {X}+ (XY in this case), plus X.
So far, I'm here:
Obviously, A is key, so its FDs are already in BCNF. Question is, can I erase any redundant FDs maybe? If so, what is the thumb rule?
R1(MST) <-- BCNF.
R2(A E P M N L)
R3()
And have no idea where to go.
1. Take a FD that violates BCNF.
5. Iterate until all the new relations have key on its left hand side
Step 1 in mentioning BCNF violation can only make sense if it means you should identify the keys and non-key-implied FDs of each original and generated relation. Also, step 5 termination cannot be merely when there is a key on the left hand side, because a non-key determiner could be present. Clearly it is necessary and sufficient to stop when all relations are in BCNF. A particular full description of an algorithm may describe equivalent reorganizations and/or tests without explicitly mentioning BCNF.
If A is a key then so is L since L->A.
MSTNAELP keys A and L plus M->ST, S->T, E<->P
Those FDs are from non-keys. You picked M->ST. We get:
MST key M plus S->T
MNAELP keys A and L plus E<->P
Both have determiners not from keys, hence are not in BCNF. Pick S->T and E->P. We get:
ST key S in BCNF
SM key M in BCNF
EP keys P and E in BCNF
EMNAL keys A and L in BCNF