Question about relation normalization - database

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. ).

Related

How to identify the corrects step to complete 3NF?

This is an example from a textbook:
Consider the relation R (A ,B ,C ,D ,E ) with FD’s AB -> C,
C -> B, and A -> D.
We get that the key is ABE and ACE. With decompositions: ABE+=ACE+=ABCDE.
How do you check minimality? I know that AB+=ABD and the textbook says that because AB+ does not include C. Then it is minimal. C+=AB and A+=AD are also minimal. But I do not know why. How do you check minimality?
Also, do we have to find all the FD's besides the ones given to check whether to perform 3-NF or not?
We then check if AB -> C can be split into A -> C and B -> C, we notice that these do not stand on their own so AB -> C is not splittable.
We are left with the final relations: S1(ABC), S2(BC), S3(AD) and the key (since not present) S4(ABE) (or S4(ABC)). We then remove S2 because it's a subset of S1.
If it is in 3NF and there are no violations, then why do they split the original relation into: S1(A, B, C), S2(A, D), and S4(A, B, E).
Book name and page: Ullman's Database Systems page 103
How do you check minimality?
The authors don't use the word minimality here. To check for the minimal basis, follow the procedure in the first two paragraphs of example 3.27. It boils down to
". . . verify that we cannot eliminate any of the given dependencies."
". . . verify that we cannot eliminate any attributes from a left side."
Also, do we have to find all the FD's besides the ones given to check whether to perform 3-NF or not?
That question doesn't really make sense. 3NF isn't something you perform. The example in the textbook has to do with the synthesis algorithm for 3NF schemas. The synthesis algorithm decomposes a relation R into relations that are all in at least 3NF.
The synthesis algorithm operates on the FDs you've been given. In an academic setting, as you might find in a textbook, the assumption is that you've been given enough information to solve the problem. In real-world applications, you might be given a set of FDs from a business analyst. Don't assume the analyst has given you enough information; look for more FDs.
We then check if AB -> C can be split into A -> C and B -> C, we notice that these do not stand on their own so AB -> C is not splittable.
No. You verify (not notice) that you can't eliminate any attributes from a left side. Eliminating A leaves B->C; eliminating B leaves A->C. Neither of these are implied by the three original FDs. So you can't eliminate any attributes from a left side.
If [the original relation] is in 3NF and there are no violations . . .
The original relation is not in 3NF. It's not even in 2NF. (A->D)

Understanding candidate key

Consider R(A,B,C,D,E)
F = {BC->AE, A->D, D->C, ABD->E}.
I need to find all candidate key of the schema.
I know that BA,BC,BD are the keys, but i want to know how do discover them.
I saw some answers in candidate keys from functional dependencies = but i didn't fully understand them.
form what they suggest, I got L={B}, M={A,C,D}, R={E}
Now i need to add from M one at a time to L.
I start with A, i get BA. So BA->A, BA->B (trivial) and because A->D so BA->D and because D->C we get BA->C.
But, how we get E?
adapting the answer from https://stackoverflow.com/a/14595217/3591273
Since we have the functional dependencies: BC->AE, A->D, D->C, ABD->E, we have the following superkeys:
ABCDE (All attributes is always a super key)
ABCD (We can get attribute E through ABD -> E)
ABC (Just add D through A -> D)
ABD (Just add C through D -> C)
AB (We can get D through A -> D, and then we can get C through D -> C)
BC (We can get E through BC -> E, and then we can get C through D -> C)
BD (We can get C through D -> C, and then we can get AE through BC -> AE)
(One trick here to realize, is that since B never appears on the right side of a functional dependency, every key must include B, ie key B is independent and cannot be derived from other keys)
Now that we have all our super keys, we can see that only the last
three are candidate keys. Since the first four can all be trimmed
down. But we cannot take any attributes away from the last three
superkeys and still have them remain a superkey.
so the minimal keys are AB, BC, BD
update
this was a reduction approach, i.e succesively reduce the trivial superkey by use of functional dependencies, but one can take the opposite road and use an augment approach, i.e start with single trivial keys and augment them with other keys wrt dependency relations untill keys become superflous

Decomposing into 2NF

I'm currently studying normalization. I know how to normalize the data for given unnormalized list.
But this one is little bit confusing me
Q. Decompose R{a,b,c,d,e,f} into 2NF using following functional dependencies.
a -> b,c,d,e,f
b,c -> a,d,e,f
b -> f
d -> e
For this my answer is:
R0 = a - > b,c
R1 = b,c - > a,d,e
R2 = b - > f
Can anyone help me with this?
There are two main issues:
There is a lot of redundancy in your FDs set. You'll often save yourself some time if you compute the minimal cover first.
The way you split the relation doesn't make sense, regardless of the normalization level. The candidate keys for this relation are A and BC; but in your answer you have all the keys together in R0 and nothing else, which is redundant (one key per table is enough) and useless (think about it, there is nothing you can query for in such a table!); and again you put all the keys together in R1, which is redundant as well.
A better way to decompose that relation would be
R1(B, F), R2(D, E), R3(A, B, C, D)
which satisfies both 2NF and 3NF.
BTW you should check out this Stanford course, it is really useful to understand normalization. Wikipedia pages are also well written.
EDIT to answer your question on the comments: a functional dependency means that the values on the RHS are determined by the values on the LHS. In this case we have
A -> BC
BC -> A
if you replace the letters with something more intuitive this is equivalent to:
post_id -> { post_title, post_date }
{ post_title, post_date } -> post_id
That is, if you know the post_id you can figure out both the post_title and the post_date; at the same time, if you know both the post_title and the post_date you can track back the post_id. This is the meaning of a circular dependency.
That said, in every relation all the FDs should be preserved so in R3 both BC -> D and A -> D hold, but you don't need ABC -> D which is not in your FDs set and it is clearly redundant. As a side, A -> D is redundant as well since you already have A -> BC, BC -> D. This is why I mentioned to compute the minimal cover first.

boyce codd and finding candidate keys

needing desperate help with understanding boyce codd and finding the candidate keys.
i found a link here http://djitz.com/neu-mscs/how-to-find-candidate-keys/ which i have understood for most part but i get stuck
e.g
(A B C D E F)
A B → C D E
B C D → A
B C E → A D
B D → E
right as far as i understand from the link i know you find the common sets from the left which is only B, and common sets from the right which are none
now where do i go from here? i know all candidate sets will have B in them but i need guidance on finding candidate sets after that. someone explain in simple language
The linked article isn't written particularly well. (That's an observation, not a criticism. The author's first language isn't English.) I'll try to rewrite the algorithm. This isn't me telling you how to do this. It's my interpretation of how the original author is telling you to do this.
Identify the attributes that are on neither the left side nor right side of any FD.
Identify the attributes that are only on the right side of any FD.
Identify the attributes that are only on the left side of any FD.
Combine the attributes from steps 1 and 3.
Compute the closure of the attributes from step 4. If the closure comprises all the attributes, then the attributes from step 4 make up the only candidate key. (No matter how many candidate keys there are, every one of them must contain these attributes.)
Identify the attributes not included in step 4 and step 2.
Compute the closure of the attributes from step 4 plus every possible combination of attributes from step 6.
So for the FDs you posted, you'd end up with this.
{F}
{}
{B}
{BF}
The closure of {BF} is {BF}. That's not all the attributes. (But every candidate key must contain {BF}.)
{ACDE}
Compute the closure of these sets of attributes.
{ABF}
{CBF}
{DBF}
{EBF}
{ACBF}
{ADBF}
{AEBF}
{CDBF}
{CEBF}
{DEBF}
{ACDBF}
{ADEBF}
{CDEBF}
If I got those combinations right, every candidate key will be found among the possibilities in step 7. In your example, there are 3 candidate keys.
http://www.sroede.nl/projects/fdhelper.aspx
this would help'just put in ur relation and FD's
click generate at the bottom

Database Relational Homework help

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.

Resources