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.
Related
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.
This is a pretty basic question from early on in the semester, which I got wrong. I am asking this for a better and more accurate answer from others in preparation for the final exam.
Normalizing a table with 5 attributes A, B, C, D, and E. Where A and B is a composite key. With no other prime attributes.
a. If you have a partial dependency B to C, what would you do to normalize the relation?
b. If you have a dependency D to E, what would you do to normalize the relation?
Normalization is something that can be done only trough Functional Dependencies. So let's reformulate you question using them.
Normalizing a table with 5 attributes A, B, C, D, and E. Where A and B is a composite key. With no other prime attributes.
This means that we have a relation schema
R(A, B, C, D, E)
with the only non-trivial functional dependency:
A B → C D E
This relation is in Boyce-Codd Normal Form (BCNF) as well as in Third Normal Form (3NF).
If you have a partial dependency B to C, what would you do to normalize the relation?
Now we add the dependency B → C, which violates both the BCNF (that require that each determinant be a superkey) and the 3NF (that tolerates non-superkyes determinant if the determinate is a prime attribute, that is an attribute which belongs to any key, and C is not a prime attribute since the only key is A B).
In this case the normalization is simple, we decompose the original relation R in two relations, the first, R1(B, C), that represent the information that ties B and C, so that we can know for each value of B which is the only corresponding value of C, the second R2(A, B, D, E) that represents the fact the the values of D and E are uniquely determined by a couple of values A and B. The two relations R1 and R2 are both in BCNF and in 3NF, since the key of R1 is B, while the key or R2 is A B.
It is worth mentioning the fact that this decomposition is loss-less and dependency preserving.
If you have a dependency D to E, what would you do to normalize the relation?
Also in this case the strategy is to decompose R in two relations, this time in R1(A, B, C, D) and R2(D, E). Again, we can note that both relations are in BCNF and in 3NF, and that data and dependencies are preserved.
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
Consider the universal relation R = {A, B, C, D, E, F, G, H, I, J} and the set of
functional dependencies F = { {A, B}→{C}, {A}→{D, E}, {B}→{F}, {F}→{G,
H}, {D}→{I, J} }. What is the key for R? Decompose R into 2NF and then
3NF relations.
I tried every solution given on internet but still not able to understand the answer even my instructor is not answering me satisfactorily. Can someone please explain me this?
Yes this was asked in homework but it has already been marked wrong and i just want to learn this concept. Thank you.
There is a 6 step process that will lead you to the answer but in many cases the key is to figure out which attribute or set of attributes have only out going relations and no incoming. Here except for A,B all other attributes have dependencies on A,B directly or indirectly. Hence A,B is the key for this relation. This is not the perfect answer but will lead you to the goal in most of the cases.
Once you arrive at the key, use that key and check if you can reach all the attributes directly or transitively. If yes then bingo, you have your key. In your case with A,B we can get to all the attributes.
Attribute set closures
AB+=CDEFGHIJ
AF+=CDEGHIJ
A+=CDEIJ
A+=CDEIJ
B+=CFGH
Candidate keys {AB,AF}
Prime attributes {A,B,F}
Non-prime attributes {C,D,E,F,G,H,I,J}
The Problem "Consider a relation R with five attributes ABCDE. You are given the following dependancies
A->B
BC->E
ED->A
List all the keys for R.
The teacher gave us the keys, Which are ACD,BCD,CDE
And we need to show the work to get to them.
The First two I solved.
For BCD, the transitive of 2 with 3 to get (BC->E)D->A => BCD->A.
and for ACD id the the transitive of 1 with 4 (BCD), to get (A->B)CD->A => ACD->A
But I can't figure out how to get CDE.
So it seems I did it wrong, after googling I found this answer
methodology to find keys:
consider attribute sets α containing: a. the determinant attributes of F (i.e. A, BC,
ED) and b. the attributes NOT contained in the determined ones (i.e. C,D). Then
do the attribute closure algorithm:
if α+ superset R then α -> R
Three keys: CDE, ACD, BCD
Source
From what I can tell, since C,D are not on the left side of the dependencies. The keys are left sides with CD pre-appended to them. Can anyone explain this to me in better detail as to why?
To get they keys, you start with one of the dependencies and using inference to extend the set.
Let me have a go with simple English, you can find formal definition the net easily.
e.g. start with 3).
ED -> A
(knowing E and D, I know A)
ED ->AB
(knowing E and D, I know A, by knowing A, I know B as well)
ED->AB
Still, C cannot be known, and I have used all the rules now except BC->E,
So I add C to the left hand side, i.e.
CDE ->AB
so, by knowing C,D and E, you will know A and B as well,
Hence CDE is a key for your relation ABCDE. You repeat the same process, starting with other rules until exhausted.