I am struggling to figure out how to find both conversions to this problem. I am trying to learn database design / database normalization before I jump into creating my first database.
For example: I am trying to convert the following to 2NF, and then 3NF showing both conversions. I am stuck on the 'both conversions' part.
(b, m, i, o, d, j, l, s, e, c, n, h, a, f, k, p, r, g)
The FD's:
b → f m → k b → e
m → l m → a i → c
n, h → p l → a l → k
r → g o → s
Thanks in advance!
If you are taking a course, then follow your teacher's plan first, before taking advice from others. But if you are learning on your own, here are a few tips.
One thing to realize is that normalization is a bottom up approach, and not a top down approach. Where it's most useful is when you are given a body of data that is already defined, and you want to know how normalized it is. In the early days of relational databases, there were plenty of systems being cut over from paper based manual systems, or from file and record systems, or from prerelational DBMSes. Normalization could help you understand that data better, and give you a real good handle on why the existing system wasn't working very well.
But if you want a top down approach, I suggest a completely different plan. Learn how to to ER modeling of the subject matter itself. Don't try to design a database with an ER model. That is not its strength. Instead, try to understand how the subject matter experts understand their data. ER modeling is simple, but it's abstract. The hard part about ER modeling is making sure that each attribute really describes the entity or relationship you are attaching it to. It's very easy to get this wrong.
Once you have a good ER model, and one that passes the reality test, convert it to a relational model. This is where you convert the entities and relationships into tables, and the attributes into columns, and put in foreign keys. If you do this fairly mechanically, you should end up in 3NF, most of the time. No gurantees about efficiency, however.
Now, as you begin tweaking this model for better performance, keep track of what you are doing to make sure that the only denormalization you perform is intentional. There are plenty of cases where a somewhat denormalized database works "better" than a normalized one, although it's easy to go wrong.
The more you do it, the better you'll get.
According to your FD's and Relation , your Candidate key will be: {bmiodjnhr}
Hence ,
Prime Attrbutes (9) ={b,m,i,o,d,j,n,h,r}
Non-Prime Attrbutes (9) = { l, s, e, c, a, f, k, p, g}
Now Checking for 2NF:
"Partial Dependencies are not allowed". Means part of Candidate key should not determine the Non- Prime Attribute.
Here Partial Dependencies are:
b → f
m → k
b → e
m → l
m → a
i → c
n, h → p
r → g
o → s
Hence Partial Dependencies exist, Relation is not in 2NF.
*How to resolve Partial Dependencies*
Decompose your relation like this:
R1= {bfe}
R2= {mkla}
R3= {ic}
R4= {nhp}
R5= {rg}
R6= {os}
R7= {bmiodjnr}
Now Checking for 3NF:
"Transitive Dependencies are not allowed in 3NF"
Means,
Your Database is in 3NF if and only if it follow any one or both of below rules:
Rule 1 : For Each given FD's , Left Hand Side(LHS) of FD should be Superkey for any table in Database.
OR
Rule 2 : For Each given FD's , Right Hand Side (RHS) of FD should be Prime Attribute for the ant Relation / Table.
Here Transitive Dependency is : l → a , l → k
Hence Transitive Dependencies exist, Relation is not in 3NF.
*How to resolve Transitive Dependencies*
Decompose your table like this:
R1= {bfe}
R2= {ml}
R3= {lak}
R4= {ic}
R5= {nhp}
R6= {rg}
R7= {os}
R8= {bmiodjnr}
**Now this is in 3NF.**
Hope it helps.
This is the Answer of your question. If you want to learn exactly how to check if a relation is in 2NF or 3NF or BCNF or how find a candidate key or how to decompose a table , Please refer "Normalization" section of my notes. Here is the link : DataBase Normalization
Related
Given a relation R(A,B,C,D,E) with functional dependencies: AB→C and C→D,
Find all key(s) of the relation R.
Which normal form is R in?
If R is not in BCNF, decompose R, as necessary, into a set of relations that are in BCNF.
Is your decomposition dependency-preserving? Briefly explain why or why not?
I am a little confused on finding the keys and normal form in R. Would anyone be able to explain it?
You should be able to get all your relation back with your keys.
So, in your example, if you start with the tuple (A, B, E), you can get C from AB, and then D from C; and that's it, you get your relation back, so you know that (A, B, E) is a key.
If you had, for example, started with the tuple (A, B), you wouldn't have been able to get E back, so you know that E must be part of your key tuple.
I'm trying to understand decomposition to BCNF. I have read many examples, yet I still do not understand few things. I followed this answer to try and solve following problem:
Attributes are customer name(A), address(B), phone(C), id(D) and accounts have a number(E), type(F) and balance(G).
What functional dependencies hold if customers have one and only one id, name, address and phone number and accounts have one number, type and balance and are owned by one and only one customer? Give a BCNF decomposition using these dependencies of R(ABCDEFG)
What I have come to so far:
To first obtain the FDs specified in the question:
D -> ABC // If we agree on same customer ID, then we agree on the name, address and phone #
E -> DFG // If we agree Account number, then we agree on customer ID, account balance and account type
The only candidate key we have is: {E} as all attributes can be obtained with this attribute.
Since there are no extraneous left-hand side attributes and no redundant FD, I have come to following relational tables:
R1={D, A, B, C}
R2={E, D, F, G}
Where the keys in these two relations are marked in bold
Now to check for BCNF we check if any of these relations (R1,R2) violate the conditions of BCNF (i.e. for every functional dependency X->Y the left hand side (X) has to be a superkey) .
Now we can see that E -> DFG has a left hand side that is a super key. However D -> ABC does not have a left hand side that is a super key. So that FD violates BCNF. But I don't know how to proceed into decomposing into BCNF.
When you check for satisfaction of the BNCF of the decomposed relations, you must check the functional dependencies separately for each relation.
So, in R1={D, A, B, C} the only (candidate) key is D (as you have noted), with all the non-trivial dependencies that have only D as left part; in R2={E, D, F, G} the only (candidate) key is E with all the non-trivial dependencies that have only E as left part. So in both relations there is no (non-trivial) dependency that violates the BCNF, and so the decomposition is correct and nothing else must be done.
My doubt is for a given set of funtional dependencies F = { AE -> BCD, B -> E
}. Is this in BCNF or 3NF? It's a question from a test I have recently done and I would say that it is 3NF, but my teacher said it's neither 3NF nor BCNF. (I believe it is an error).
I have obtained as candidate keys AE and AB, and as in the first functional dependency the left side is a candidate key and in B -> E, E is contained in a candidate key, so it is in 3NF.
Is this in BCNF, 3NF or neither?
Assuming that all the attributes of the relations are A B C D and E, and that the only dependencies given are the two described (F), you are correct. Since the (only) candidate keys are correctly A E and A B, and since the functional dependency B → E has a determinant which is not a superkey, the relation is not in BCNF. Given one of the definitions of BNCF: “for all the non-trivial dependencies X → Y of F+, X is a superkey”, there is a theorem that shows that a necessary and sufficient condition for this is that the property of being a superkey holds for all the dependencies in F.
On the other hand, since E is a prime attribute, i.e. an attribute of a candidate key, the dependency B → E does not violate the 3NF, so that the relation is in 3NF. This, again, given one of the definitions of 3NF: “for all the non-trivial dependencies X → A in F+, then X is a superkey or A is a prime attribute”, is due to a theorem that says that this condition is equivalent to check, “for each functional dependency X → A1,...,An in F, and for each i in {1..n}, either Ai belongs to X, or X is a superkey or Ai is prime”. And this is satified by the two dependencies of F.
You need to use a definition of a NF when you claim/show that a relation is in it.
You don't actually say what all the attributes are. I'll assume the attributes are A through E. Otherwise, the CKs (candidate keys) are not what you say.
You are right in your argument against BCNF. You are using the definition that all determinants of FDs (functional dependencies) are out of superkeys. You found a counterexample FD B → E.
If it were an either-or question re BCNF vs 3NF you could stop there.
in the first functional dependency the left side is a candidate key and in B -> E, E is contained in a candidate key
You don't show that the table meets the conditions of either of the following definitions (from Wikipedia that happen to be correct) that a table is in 3NF if and only if:
both of the following conditions hold:
The relation is in 2NF
Every non-prime attribute is non-transitively dependent on every [candidate] key
for each of its functional dependencies X → A, at least one of the following conditions holds:
X contains A
X is a superkey
each attribute in A-X is prime
You seem to using definition 2 (but not saying so). You show bullet 2 holds for AE → BCD. Pointing out that E is prime in B → E seems to be part of showing that E-B is all prime. But you need to show every FD satisfies a bullet. Note that more FDs hold than the given ones. Armstrong's axioms tell you what all the FDs are.
In practice it can be easier to show a schema is in 3NF by applying a 3NF algorithm.
I am studying for my databases exam and I've realized my professor did not teach a section of the normalization lecture notes, but glossed over them so I've been self studying and there is this example without solutions in the notes and I was wondering if I have been doing it right:
Given Relation R = {A,B,C,D,E,F,G,H,I,J}
And functional dependencies:
A,B -> C
A -> D,E
B -> F
F -> G,H
D -> I,J
Determine the primary key
Decompose R so it is in 2NF then show it in 3NF.
So, I got the primary key to be (A, B, D, F)
And then I tried to convert it to 2NF and I got relations:
(ABC), (DIJ), (ADE), (BF), (FGH)
And I honestly have no idea if this is right or how to then put it in 3NF... or if I've just skipped 2NF and already put it in 3NF. Any help?
It appears to me that you have skipped the NF2 and normalised the relation straight into the 3NF :)
The primary key for the original relation should be (A,B) as by inference rules (transitivity, such as A->D,E and D->I,J therefore A->I,J) it determines all other attributes. From this point onwards we have that:
FD1: A,B -> C
FD2: A -> D,E (Partial)
FD3: B -> F (Partial)
FD4: F -> G,H
FD5: D -> I,J
2NF (No partial dependencies allowed)
Now we can decompose the relation in three relations moving partial FDs to separate relations but preserving other FDs which might depend on those partial FDs, such as FD2 and FD5. This would give us the following results:
R1(A,D,E,I,J) -- FD2, FD5 (transitive)
R2(B,F,G,H) -- FD3 FD4 (transitive)
R3(A,B,C) -- FD1
Next, to achieve 3NF, transitive dependencies would have to be removed into separate relations in the same manner as NF2. Which, in turn, would result in the set of relations which you have already derived.
Good luck with your exams!
Let's consider, for instance, the following relation:
R (A,B,C,D,E,F)
where the bold denotes that it is a primary key attribute
with
F = {AB->DE, D->E}
Now, this looks to be in the first normal form. It can't be on the third normal form as I have a transitive dependency and it cannot be in the second form as not all non-key attributes depend on the whole primary key.
So my questions are:
I don't know what to make of F and C. I don't have any functional dependency info on them! F doesn't depend on anything? If that is the case, I can't think of any solution to get R into the 2nd normal form without taking it out!
What about C? C also suffers from the problem of not being referred on the functional dependencies list. What to do about it?
My attempt to get R into the 2nd normal form would be something like:
R(A,B,D)
R' (D,E)
but as stated earlier, I don't have a clue of what to do of C and F. Are they redundant so I simply take them out and the above attempt is all I have to do to get it into the 2nd form (and 3rd!)?
Thanks
Given the definition of R that { A, B, C } is the primary key, then there is inherently a functional dependency:
ABC → ABCDEF
That says that the values of A, B and C inherently determine or control the values of D, E and F as well as the trivial fact that they determine their own values.
You have a few additional dependencies, identified by the set F (which is distinct from the attribute F - the notation is not very felicitous, and could be causing confusion*):
AB → DE
D → E
As you rightly diagnose, the system is in 1NF (because 1NF really means "it is a table"). It is not in 2NF or 3NF or BCNF etc because of the transitive dependency and because some of the attributes only depend on part of the key.
You are right that you will end up with the following two relations as part of your decomposition:
R1(D, E)
R2(A, B, D)
You also need the third relation:
R3(A, B, C, F)
From these, you can recreate the original relation R using joins. The set of relations { R1, R2, R3 } is a non-loss decomposition of the original relation R.
* If the F identifying the set of subsidiary functional dependencies is intended to be the same as the attribute F, then there is something very weird about the definition of that attribute. I'd need to see sample data for the relation R to have a chance of knowing how to interpret it.
I think the primary key of R is set wrong. If F isn't functionally related to anything it has to be a part of the key
So you have R( ABCF DE) which is now in the first normal form (with F = {AB->DE, D->E}) Now you can change it to the second normal form. DE isn't dependant on the whole key (partial dependency) so you put it in another relation to get to second normal form:
R( ABCF ) F = {}
R1( #AB DE) F = {AB->DE}
Now this relation doesn't have any transitive dependencies so it is already in third normal form.
F doesn't depend on anything?
No, you just haven't been given any explicit information about it in the form
{something -> F}
And essentially the same can be said for C. You're expected to infer the other dependencies by applying Armstrong's axioms. (Probably.)
Think about how to finish this:
Given R (A,B,C,D,E,F)
{ABC -> ?}
[Later . . . I see that Jonathan Leffler has broken the suspense, so I'll just finish this.]
{ABC -> DEF} (By definition) therefore,
{ABC -> F} (By decomposition. Here's where F and C come in. And this is your third relation. ).