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!
Related
I have a relation R(a,b,c,d) where (a,b) is a primary key so I have the determinant a,b -> c,d.
In addition to that I have the following determinants: a,c -> b,d and a,d -> b.
Let's be ok that this relation is in 3NF.
I'm wondering if it's in BCNF or not. I was using a definition for the BCNF that recognize:
a relation is in BCNF if it's in 3NF and there's no determinant X -> Y such as X is non-key attributes and Y is a part (or the totality) of the key
which is not applicable in my case for the determinant a,d -> b for example. Another definition is that
A relation, R, is in BCNF iff for every nontrivial FD (X->A) satisfied
by R the following condition is true:
(a) X is a superkey for R
which left me undecided insofar as in a,d->b it's clear that (a,d) is not a superkey (nor a key), but we have (a,d) clearly a key to the relation R!
So, my question is:
Is the relation R in BCNF or not, and why?
And what's the right process to determine whether a relation is or isn't in BCNF?
About terminology
You say:
I have the determinant a,b -> c,d
This is wrong therminology. a,b -> c,d is a functional dependency (sometimes abbreviated with FD), which has a determinant a,b (sometimes called left hand side (LHS) of the FD) and a determinate c,d (sometimes called right hand side, RHS, of the FD). This terminology is used since the values of the attributes a,b uniquely determinate the values of the attributes c,d.
About the key
The information that:
(a,b) is a primary key
can be irrelevant when normalizing a relation when you have enough information about the functional dependencies. From those dependencies you can calcolate which are the candidate keys: set of attributes that uniquely determines all the attributes of the relation and such that you cannot remove any attribute from them maintaining this property (in other words, minimal sets of attributes that uniquely determines all the attributes of the relation). The information about the primary key can be relevant when you have only partial information about the functional dependencies that hold in a relation, but in your case the information about all the (candidate) keys can be derived from the functional dependencies.
In your example, for instance, there are three candidate keys:
1. a, b
2. a, c
3. a, d
You can verify this fact by computing the closure of the attributes of a candidate key to see if it contains all the attributes. For instance, let's try to calculate the closure of a,d (called a,d *):
1. a,d * = a,d
2. a,d * = a,d,b (since a, d -> b)
3. a,d * = a,d,b,c (since a, b -> c, d)
So a,d is a candidate key (which is also a superkey, i.e. a set of attributes that determines all the attributes of the relation).
About the BCNF
There are different definitions of BCNF. Using for instance the second one that you cited, all the three dependencies have a determinant which is a candidate key (and so a superkey), and so the relation is in BCNF.
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 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
Let R be a relation with Schema R(X,Y,Z)
and it's FDs are
{XY -> Z, Z -> Y}
I am not able to decompose it into BCNF .
Because r1(Z,Y), r2(Z,X) will lose FD XY -> Z and
R(X,Y,Z) itself is not the solution as Z->Y shows that Z should be a key ..
How to do this ???
Every conversion into BCNF may not be dependency preserving
We only need to give a counter example: Consider the following schema;
a b c and c->b
Clearly the above schema is in 3NF, because ab->c is a superkey dependency and ,from c->b we
can see that b-c=b, which is a subset of the primary key (such dependency is also allowed in 3NF).
But, the above schema is not in BCNF because c->b is neither super-key nor trivial dependency.
So we decompose above schema , keeping it lossless.
Only possible lossless decomposition is: ac and cb. (because,their intersection c is primary key for the 2nd table).
But clearly the dependency ab->c is lost.
Hence, proved.