I have two Functional Dependencies from one relation:
meetid -> pid
meetid, pid -> status
For relation Meetings(meetid,pid,status)
I want to use promotional approach to make multivalued dependencies from this. The problem is that I'm not sure if meetid ->> pid is legal to do in this situation, as the complementation rule will make the other MVD illegal (I think): meetid ->> status.
The other FD will create a dependency that I see as a trivial MVD.
meetid,pid ->> status
Is this relation doomed to be trivial when promoting them to MVDs, or am I missing something in the process?
The two dependencies:
meetid → pid
meetid, pid → status
are not minimal, since they can be simplified (for instance by computing a canonical cover) in:
meetid → pid
meetid → status
and from this we know also that meetid is the only candidate key of the relation. From a FD X → Y one can always derive the MVD X →→ Y, so, you have both the MVD dependencies:
meetid →→ pid
meeditd →→ status
(Note that the second one can also be derived from the first one by complementation).
Note also that none of them is a trivial MVD, since a MVD X →→ Y is trivial (that is, always true) if either Y is the empty set or XY are all the attributes of the relation.
Furthermore, we can note that the schema is in 4NF, since it is in BCNF and each left hand side of non-trivial MVDs is a superkey.
Finally, note that every functional dependency can be “promoted” to a multivalued dependency, so that we have also meetid, pid →→ status (and this is trivial).
Related
I have a question on the definition of 3NF given by Chris Date in his book "Database Design and Relational Theory", page 78.
The definition given in the book is: "A relvar R is in 3NF iff for every non-trivial FD X -> Y, either X is a superkey, or Y is a subkey."
(For Date "Y is a subkey" means that Y is contained in a candidate key, and no assumption is made on the cardinality of the set Y in the Date definition.)
It seems to me, however, that this definition is not equivalent to the usual definition (that can be found in other references) saying that "R is in 3NF if for every FD X -> Y, either the FD is trivial, or X is a superkey, or every element in Y\X is contained in a candidate key".
Consider now the relvar with 5 attributes R(A,B,C,D,E) with the following FD cover:
{A,B} -> C,
{C,D} -> E,
E -> B
These imply {A,E} -> {B,C}. The candidate keys of R are K1 = {A,B,D}, K2 = {A,C,D} and K3 = {A,E,D} and so the FD {A,E} -> {B,C} shows that R is not in 3NF if we use Date's definition.
However, it is in 3NF if we use the "usual" definition (since every attribute is actually contained in a candidate key).
Is there something I do not understand? Or is Date really using another (stronger than the usual one) definition of 3NF?
The Date definition says "Y is a subkey means that Y is contained in a key, ...".
The 'usual definition' (where did you get that) says "or every element in Y\X is contained in a key".
Then they both say "Y ... contained in a key".
You can equivalently write {A,E} -> {B,C} as two FDs {A,E} -> {B}; {A,E} -> {C}. Now each Y\X is "contained in a [candidate] key".
So you seem to be quibbling about the wording "every element in Y", which the Date definition isn't explicit about(?) Or perhaps it is, and you haven't quoted Date in full?
For R(A,B,C,D,E,G,H) here's the minimal cover:
{A->E,D->H,D->G,E->C,G->B,G->C,H->D}
Candidate keys:
{AH,AD}
By the definition of BCNF, none of the attributes on left side are SK or CK. Thus, it's not in BCNF. Is it safe to conclude that all of the FDs are violating BCNF? If so, in the process of decomposition to BCNF, as the algorithm says, to take the FD that violates BCNF, for example: X->Y, and do the procedure of R1(XY) and R2(R-Y)
In our case, do I need to that do that all over the FDs? If I do so, I get in the end
R1(AE), R2(EC), R3(GB), R4(DH), R5(DG) and R6(AD)
But still missing G->C and H->D and R6 isn't in the FD from the start. So that doesn't make it dependency preserving?
Is it safe to conclude that all of the FDs are violating BCNF?
Yes
... and do the procedure of R1(XY) and R2(R-Y)
The standard analysis algorithm decompose the original schema in two subschemes R1(X+), R2(R - (X+ - X)). So if you start, for example, from AE, you produce R1(AEC) (since A+ = AEC), and R2(ABDGH). Then you repeat the steps in the remaining relations, if there are other dependencies that violates the BCNF.
For instance, in this case a decomposition that can be obtained is:
R4(AH)
R5(BG)
R6(DGH)
R7(CE)
R8(AE)
Note that, with this decomposition, the dependency G -> C is not preserved (it is a known fact that the algorithm can produce the loss of one or more dependencies).
I'm relatively new to MySQL. Thank you in advance if any of you could point a direction on my problem. I am stuck on my project on the problem below. I have a data table below to show insurance premiums under different insurance variants.
ins_id (PK)
insurance_type
local_household (Variant A)
ss_medical_level (Variant B)
company_type (Variant C)
base
percentage
1
ss_pension
yes
x
x
2
ss_pension
no
x
x
3
ss_medical
yes
x
x
4
ss_medical
no
first
corporation
x
x
5
ss_medical
no
first
non_corporation
x
x
6
ss_medical
no
second
x
x
7
ss_medical
no
third
x
x
Variant C -> Variant B -> Variant A. They are transitive functional dependent by the sequence C > B > A
(-> means depends on)
In short, I am seeking a way to maintain these variants.
What I am trying to achieve is to design a schema to maintain the variants, and make it possible for easy future sustainable management on the variants. There will be more variants added for other types insurance. I had a draft design on the schema relations, but I am stuck on the variants part. I still did not get my head around on the transitive functional dependency design.
my current schema
I think I found the direction to solve my problem. I got inspired by this thread to use a path enumeration method.
https://www.youtube.com/watch?v=wuH5OoPC3hA
Disclosure: I am taking Stanford's online database course. The forum there is dead, and I'm hoping for some help on SO.
Here's the quiz question:
Consider relation R(A,B,C,D,E) with multivalued dependencies:
A -» B, B -» D
and no functional dependencies. Suppose we decompose R into 4th Normal Form. Depending on the order in which we deal with 4NF violations, we can get different final decompositions. Which one of the following relation schemas could be in the final 4NF decomposition?
And here is my thinking:
Since we are given that there are no functional dependencies, the only key is set of attributes (A,B,C,D,E). In other words, both multivalued dependencies in the question are violating, and we must decompose them.
I am following the decomposition algorithm given in lecture:
Compute keys for R [done]
Repeat until all relations are in 4NF
Pick any R' with nontrivial A -» B that violates 4NF
Decompose R' into R_1(A, B) and R_2(A, rest)
Compute functional dependencies and multivalued dependencies for R_1 and R_2
Compute keys for R_1 and R_2
I see two ways to decompose the relations: start with A -» B or B -» D.
Starting with A -» B
R(A,B,C,D,E)
|
+-----------+
| |
R_1(A,B) R_2(A,C,D,E)
Since B and D are no longer in the same relation, we do not have a 4NF violation, and we're done. I'm not sure how to compute the FDs, MVDs, and keys at this point.
Starting with B -» D
R(A,B,C,D,E)
|
+-----------+
| |
R_1(B,D) R_2(B,A,C,E)
|
+----------+
| |
R_3(A,B) R_4(A,C,E)
At this point, (A and B) and (B and D) are decomposed into their own relations, so we have no violations, and we're done.
The answer choices:
At this point, I'm completely stumped. I do not see any of the relations in the answer choices, nor can I come up with an idea that will get me there:
CE
AD
AE
ABD
I don't need the answer outright, but what am I missing?
A correct answer is AD.
How is this obtained?
Consider that, like for functional dependencies, you can have multivalued dependencies implied by other multivalued dependencies. For instance, there is a pseudo-transitivity rule (or multi-valued transitivity rules) that says:
If X →→ Y holds, and Y →→ Z holds, then X →→ Z − Y holds
For this rule, from A →→ B and B →→ D you can derive A →→ D. So, if you decompose the relation in 4NF you could start from this dependency, and get a table with attributes AD. Or, alternatively, in your first decomposition, after finding R_1(A,B) and R_2(A,C,D,E), you should continue to decompose R_2, since it still contain the non-trivial MVD A →→ D, to find R_3(A, D) and R_3(A, C, E).
yesterday I took a database exam and the question about normalization was strange.
We had table R(ABCDEFG) and functional dependencies G->B, C->DG, CF->E, F-A. Which are the candidate keys for R? I only found one: CF. Then R1(DFG), which are the candidate keys for R1? I only found one: DFG. State a correct 3NF normalization for R. I stated ((C,F), E), ((G, B)), ((F), A), ((C), D)
and then the functional dependency GDF->C was added. What is now a correct 3NF normalization of R? I said ((G, D, F, C)), ((G), B), ((F, ); A), ((C), D), ((C, F), E)
Did I solve it correct?
Then even more strange, we should state what is what when the following are listed:
Product ID
Order number
Customer ID
Quantity
Customer name
Product name
Date
I concluded
G= Product ID
C= Order number
F= Customer ID
D= Quantity
A= Customer name
B= Product name
E= Date
Is this correct? What does the FD GDF->C mean in plain English?
"Yesterday I took a database exam and the question about normalization
was strange. We had table R(ABCDEFG) and functional dependencies G->B,
C->DG, CF->E, F-A. Which are the candidate keys for R? I only found
one: CF.
That seems OK.
Then R1(DFG), which are the candidate keys for R1? I only found one:
DFG.
With the very same set of FD's ??? With no FD's at all ??? Anyway, this one seems correct too.
State a correct 3NF normalization for R. I stated ((C,F), E), ((G,
B)), ((F), A), ((C), D)
((G), B) instead of ((G, B)) would be more like it.
((C), DG) instead of ((C), D) would be more like it too.
and then the functional dependency GDF->C was added. What is now a
correct 3NF normalization of R? I said ((G, D, F, C)), ((G), B), ((F,
); A), ((C), D), ((C, F), E)
Addition of this FD (/constraint) doesn't alter the 3NF form. All dependencies that are expressible in the 3NF design are still "out of complete keys". The fact that this additional dependency could not be preserved by the decomposition, does not lower the normal form. It's a dependency preservation issue, not a normal form issue.
Did I solve it correct?
Best option is to ask the teachers.
"Then even more strange, we should state what is what when the
following are listed:"
The folly. The question itself forces you to make assumptions. Date. What date is that ? Date of birth of the customer placing the order ? Date when the ordered product was assigned its current name ? Or perhaps Date when the order was placed ? Presumably so, but the thing is, this should be clearly spelled out in the specs and database designers should really be taught NEVER TO ASSUME ANYTHING ABOUT THE SPECS. Assumption is the mother of all screwups.
What does the FD GDF->C mean in plain English?
In plain English, and assuming your answer, it means that once a certain combination of {customer id, product id and quantity} has been used in an order, there can no longer appear a second order (with a different order id) with the very same {customer id, product id and quantity}. Or, iow : each customer can order a certain specific quantity of a certain specific product only once.