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
Related
I am having problems understanding what criteria are used to determine relationship redundancy for a "circle" of relationships between 3 entities in the entity - relationship model.
I was starting with the following example: Course - department - teacher relationships.
Course - department - teacher relationships first example
My criteria to declare a relationship (A -> C) as non redundant (can NOT be inferred from A -> B -> C) is either:
A -> B has minimum cardinality 0 (ie. 1 element of A can be associated with 0 elements of B), since then, B can't be determined (and therefore C can't be determined).
OR
If A -> B and B -> C have a maximum cardinality of N (ie. 1 element of A can be associated with N elements of B and 1 element of B can be associated with N elements of C simultaneously). My assumption for this is that knowing the elements of B associated with A and knowing the elements of C associated with B can't be used to know one specific A -> C.
I consider the above "both ways": A -> B -> C and C -> B -> A. If going any way I get any of the above, I consider the relationship is NOT redundant since A -> C can't be inferred from A -> B -> C.
I am assuming this, regardless of the cardinality between the candidate redundant relationship A -> C.
Given my assumptions, I consider the example [Course (C) - department (D) - teacher (T)]. I deduce that the only relationship which is redundant is between course and teacher since:
T -> C:
T -> (1,1) D -> (1,n) C [Cardinality shown in parenthesis]. Which allows to deduce T -> C from T -> D -> C.
C -> T:
C -> (1,1) D -> (1,n) T. Which allows to deduce C -> T from C -> D -> T.
However, in the example given, the redundant relationship is Teacher and Department. The reasoning is that if the courses a teacher teaches are known and the department to which each course belongs is also known, it can be deduced to what department belongs each teacher. Also, given a department, if we know its courses, and we know the teachers who teach the courses we will know the teachers associated with department.
With my criteria, I don't see how this is the case, since:
D -> T:
D -> (1,n) C -> T (1,n). This complies with point 2) above and therefore D -> T can't be deduced from D -> C -> T.
There is also another example with the same relationships but different cardinality (shown in red), this is where I got my criteria from:
Course - department - teacher relationships second example
In this case, it is specified that there are no redundant relationships, for the following reasons:
T - D:
If we know the courses taught by a teacher, and the departments to which the courses are assigned, Do we know which department the professor belongs to? NO, since the course can be assigned to several departments.
This is where I deduced my criteria:
T -> D:
T -> (0,n) C -> (1,n) D. We have two 1->N relationships, therefore it is non-redundant.
Also it says: what if a course was only attached to a Department? Still, a teacher may not teach any courses, then we couldn't know his/her department. Which is my other criteria:
T -> (0,n) C [minimum cardinality of 0, we can't know C in some cases, and therefore, we can't know D.
It also adds: given a department, if we know its courses, and we know the teachers who teach the courses, we will know the professors associated with the department.
T - C:
A course can be assigned to several departments, and these may have several teachers, then you can not know the teacher concrete that the course teaches. Ie. We have two 1-N relationships:
C -> (1,n) D -> (1,n) T. Therefore, it is non-redundant.
C - D:
Given a course taught by a teacher, and he/she belonging to a department, we cannot know what other departments have associated the
course.
I am assuming:
D -> (1,n) P -> (0,n) C. We have two 1-N relationships therefore, it is non-redundant.
Finally I have a third example with Author (A), Editorial (E) and Book (B) as follows:
Author, Editorial, book example
I am told that the redundant relationship is Author - Editorial. However, I am finding no redundant relationships as per my criteria since they have two 1:N relationships:
E -> A:
E -> (1,n) B -> (1,n) A
B -> E:
B -> (1,n) A -> (1,n) E
A -> B:
A -> (1,n) E -> (1,n) B.
Thank you for taking the time to read until here. Are my criteria wrong? If so, what criteria should I use to consider a relationship redundant?
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.
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
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.
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