Database Design Redundant Functional Dependencies (FD's) - database

I have not understood how the following problem must be approached.
Any help in learning how to solve this question will be much appreciated!
Consider Relation Schema R = {ABCDEFG} with a set of Functional Depenedencies
F = {GA -> D, DC -> E, GF -> A, CA -> GB, AF -> D, F -> G}
Identify any redundant Functional Dependencies.

Consider GA -> D. To check whether it is redundant we need to check whether we can infer D from GA by using dependencies other than GA -> D. However, no other dependency is applicable to GA so GA -> D is not redundant.
Consider AF -> D. If we know AF, then we also know AFG since F -> G. Moreover, since GA -> D we also know D. Hence, we have inferred D from AF without using the dependency AF -> D meaning that AF -> D is redundant.
If your lecture slides also discuss redundant (extraneous) attributes you can check that G is an extraneous attribute in GF -> A since F -> G.

Related

Candidate Keys on Functional Dependencies?

The relation R=(A,B,C,D,E) and functional dependencies F are given as follows:
F={A->BC, CD->E, B->D, E->A}
E, BC and CD can be a candidate keys, but B cannot.
Anyone could point me how this fact is calculated? I google it but couldn't understand more as what I known before.
You can find all the dependent attributes of a given set of attributes by computing the closure of its functional dependencies. Let me demonstrate:
A -> ABC -> ABCD -> ABCDE
A determines BC (given) as well as itself (trivially) therefore A -> ABC. Add the fact that B -> D to get ABC -> ABCD. Finally, add CD -> E to get ABCD -> ABCDE. We stop here because we've determined the whole relation, therefore A is a candidate key.
You should verify that, starting from E, BC and CD, you can indeed determine the whole relation.
Starting from B, we get:
B -> BD
and that's it. The rest of the relation can't be determined from BD, so it's not a candidate key.
A more visual way of doing it is to sketch the functional dependencies:
Starting from any set of attributes, try finding a path to every other attribute by following the arrows. You can only get to E if you start at E or visited both C and D.
From B, you can reach D, but without C, you're not allowed to go to E, which also excludes A. So B can't be a candidate key.

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

Functional dependency - Left hand side with three attributes

Assuming we have the following functional dependencies :
AB -> C
DEG -> H
A -> B
DG -> H
We can see that B can be removed due to the closure of B+, which is (G-(AB ->C) U (A -> C) = ACB
In order to find the minimal cover, how do I approach the other left hand redundancies in regards to DEG -> H, DG -> H - can these be reduced, and if so can you explain using the closures!
Many thanks, Matthew
There are a small set of rules to do this. It is really easy.
A functional dependency set is minimal;
If there are only single
attributes on the right sides of the depencencies. And...
There is no functional dependency that can be removed, a way by keeping the original cover. And...
You can't remove attribute from the left side of the dependency and keep the original cover
So if you are finding a minimal cover you must make these sure. Of course you must keep the closure equivalent.
If you take a look at:
AB -> C
DEG -> H
A -> B
DG -> H
You can easily find redundancy. There is no point to include both DEG → H and DG → H because DG → H already covers all that DEG → H covers. So you can remove it.
Still equivalent:
AB -> C
A -> B
DG -> H
You can still see that from the first line you can remove B because it depends funcitonally from A.
Still equivalent:
A -> C
A -> B
DG -> H
We have found a minimal cover. No dependencies can be removed to keep the closure, and there are only single attributes on the right side, and DG is the only double attribute on the left side, that must be kept. We cannot remove neither D or G and keep the origninal closure.
We can proove this using Armstrong axioms. If we can get the original set, then this is truely an equivalent minimal set.
(I will post it later - I hope it is correct.)

Removing Anomalies from tables

I have this table and I am supposed to re-design it to remove all anomalies from it. I will not give the table but the dependencies.
The functional dependencies are
(Product, Store) -> Dept
Store -> Manager
Dept-> Assist
(Product, Store)->Price
Product-> Weight
Product-> Manufact
Manufact-> Manuloc
Product and Store are the keys in this relation
Ok so I have to remove the anomalies by breaking up the table and creating new ones and state what will be in each table. I am unsure how to do that.
Apply Armstrong's axioms and the rules derived from them. (I'm sure this is in your textbook. Check the index.) For example, given these two functional dependencies (FDs):
(Product, Store) -> Dept
Dept -> Assist
you can apply the transitivity rule to determine an unstated FD:
(Product, Store) -> Assist
From the FDs you're given, derive an irreducible set of FDs; this set determines your tables.
This example is from Date's Introduction to Database Systems. (He gives a more complete treatment of it.) Given
A -> BC
B -> C
A -> B
AB -> C
AC -> D
rewrite for right-hand singletons using Armstrong's axioms:
A -> B
A -> C
B -> C
A -> B
AB -> C
AC -> D
The FD A -> B occurs twice; we can discard one without losing information. We can reduce AC -> D to A -> D, and we can eliminate AB -> C. And we can eliminate A -> C, leaving
A -> B
B -> C
A -> D
From this irreducible set of FDs, you'd derive the two tables
A -> BD
B -> C

BCNF Decomposition

I am trying to figure out the correct steps in performing a BCNF decomposition. I found this example, but I do not understand how to perform the correct steps.
Schema = (A,B,C,D,E,F,G,H)
FD's + {A -> CGH, AD->C, DE->F, G->G}
Could someone show the correct steps?
Determine a minimal cover using your FD's:
{A -> C, A -> G, A -> H,
B -> nothing,
C -> nothing,
D -> nothing,
E -> nothing,
F -> nothing
G -> nothing
H -> nothing
DE -> F}
Note AD -> C drops out because A alone determines C which implies D is redundant in the FD (see Armstrong's Axioms - Augmentation).
3NF and BCNF definitions relate to dependencies about compund keys. The only compound key
you have here is DE. Neither D or E participate in any other non-null FD's
so eliminating transitive dependencies and ensuring that dependent attributes rely on the
'key, the whole key, and nothing but the key' is not an issue here.
Break into relations so that the FD left hand side is the key and the right hand sides
are the non-key dependent attributes of that key:
[Key(A), C, G, H]
[Key(D, E), F]
Now eliminate these attributes from the cover, whatever is left are standalone relations.
[Key(B)]
This should be in 3NF/BCNF

Resources