Transitive functional dependency is defined as:
If A → B and B → C then A → C (Reference: This Tutorial!)
If an attribute is dependent on a composite of two attributes ( i.e. A,B -> C), then is this a functional dependency?
Can we consider this type of dependence to be (or not) a transitive dependency?
If an attribute is dependent on a composite of two attributes (A,B->C) then this is a "functional dependency".
A transitive dependency occurs when you have a non-key predicate that is placed in a "child" relation when it properly belongs in the "parent" relation. In your case, A->C is a transitive dependency.
There is a pretty clear practical example of a transitive dependency on Wikipedia.
It should be noted that there is a difference between A->B, B->C and A,B->C. These are not equivalent dependencies.
TL;DR A "dependency" written with "→" is a FD (functional dependency). A "transitive dependency" written with "→" is a transitive FD. That's what "dependency" means (is short for) for "→".
A FD has one set determining another. Either set can have any number of attributes. (If a set has just one attribute we also say that that attribute determines or is determined.)
Transitive functional dependency is defined as:
If A → B and B → C then A → C (Reference: This Tutorial!)
That is unclear & wrong. So is your reference. A → C transitively when there exists S where A → S & S → C & not (S → A). So if A → B & B → C & not (B → A) then A → C transitively, but if A → B & B → C but B → A then A → C is not transitive via B, although it might be transitive via some other attribute set.
If an attribute is dependent on a composite of two attributes ( i.e. A,B -> C), then is this a functional dependency?
That means "If an attribute is the dependent attribute of a FD whose determinant is a composite of two attributes ( i.e. {A,B} -> C), then is this a FD?" You assumed there was a FD, so there's a FD. The answer is (trivially) "yes".
Maybe you mean something else that you have not written clearly?
Maybe you mean, can a FD have a set of attributes as determinant? Yes.
Can we consider this type of dependence to be (or not) a transitive dependency?
Look at the definition. {A,B} → C transitively when there exists S where {A,B} → S & S → C & not (S → {A,B}). But no such S involving A, B and/or C exists. So just knowing you have a "composite" determinant tells you nothing about whether a FD is transitive. So no we cannot "consider it to be" transitive. It might or might not be transitive in a particular relation.
Maybe you mean, if A → C & B → C then does {A,B} → C? Yes. Adding a determinant attribute to a FD that holds gives another FD that holds. Since A and B each determine C, any set containing A or B determines C. Does {A,B} → C transitively? Again no such S involving A, B and/or C exists. So this has nothing to do with transitivity.
Maybe you mean, if A → B & B → C then does {A,B} → C? Yes. As above, adding a determinant attribute to a FD that holds gives another FD that holds. Since B determines C, any set containing B determines C. Does {A,B} → C transitively? The only S involving A, B and/or C would be {B}, if not (B → A). So we can't "consider" {A,B} → C to be transitive here either.
Related
I am struggling with the plus operator between two propositions (maybe types) in Coq. I already could figure out this is something like "or" (maybe "xor") and I think it says that something is decidable but I cannot understand the complete meaning of it, and where does this sign come from (in classical mathematics).
P. S. Of course I already googled and researched but couldn't find the complete sophisticated answer I want.
That's the sum datatype, where A + B is basically A or B. The main difference with A \/ B is that it lives in Type, so it has computational content. That is to say, given A \/ B you cannot produce a boolean such that if A then true else false.
Another way to see it is that for A B : Prop, A + B -> A \/ B holds, but not the converse.
Prop is a special, impredicative sort in Coq; I recommend reading the manual about it.
The functional dependencies are :
BCD -> A (I stated this is a SK since BCD+=ABCDEFG)
BC -> E (also SK since BC+=ABCDEFG)
A -> F (not SK or prime)
F -> G
C -> D (not sk or prime)
A -> G (not sk or prime)
My steps:
1:(A,F),(ABCDEG)
(A,F),(C,D),(ABCEG)
(A,F),(C,D),(A,G),(ABCE) (so is this one in 3nf?)
I am only trying to set it to 3nf and not go any further.
When you decompose your dependencies, you should convert them into minimal set of functional dependency.
As you have stated, BCD and BC are both super keys, thus the D in BC is not really needed. Further, between A->F, F->G, A->G you can remove A->G, as that is implied by the the other two(you can't remove F->G, you will lose this dependency).
So the minimal set becomes:
(BC->AE), (A->F), (F->G), (C->D)
Now you can decompose into 4 relations: (ABCE),(AF),(FG),(CD).
This will be in the 3NF.
I'm still puzzled what the sort Set means in Coq. When do I use Set and when do I use Type?
In Hott a Set is defined as a type, where identity proofs are unique.
But I think in Coq it has a different interpretation.
Set means rather different things in Coq and HoTT.
In Coq, every object has a type, including types themselves. Types of types are usually referred to as sorts, kinds or universes. In Coq, the (computationally relevant) universes are Set, and Type_i, where i ranges over natural numbers (0, 1, 2, 3, ...). We have the following inclusions:
Set <= Type_0 <= Type_1 <= Type_2 <= ...
These universes are typed as follows:
Set : Type_i for any i
Type_i : Type_j for any i < j
Like in Hott, this stratification is needed to ensure logical consistency. As Antal pointed out, Set behaves mostly like the smallest Type, with one exception: it can be made impredicative when you invoke coqtop with the -impredicative-set option. Concretely, this means that forall X : Set, A is of type Set whenever A is. In contrast, forall X : Type_i, A is of type Type_(i + 1), even when A has type Type_i.
The reason for this difference is that, due to logical paradoxes, only the lowest level of such a hierarchy can be made impredicative. You may then wonder then why Set is not made impredicative by default. This is because an impredicative Set is inconsistent with a strong form of the axiom of the excluded middle:
forall P : Prop, {P} + {~ P}.
What this axiom allows you to do is to write functions that can decide arbitrary propositions. Note that the {P} + {~ P} type lives in Set, and not Prop. The usual form of the excluded middle, forall P : Prop, P \/ ~ P, cannot be used in the same way, because things that live in Prop cannot be used in a computationally relevant way.
In addition to Arthur's answer:
From the fact that Set is located at the bottom of the hierarchy,
it follows that Set is the type of the “small” datatypes and function types, i.e. the ones whose values do not directly or indirectly involve types.
That means the following will fail:
Fail Inductive Ts : Set :=
| constrS : Set -> Ts.
with this error message:
Large non-propositional inductive types must be in Type.
As the message suggests, we can amend it by using Type:
Inductive Tt : Type :=
| constrT : Set -> Tt.
Reference:
The Essence of Coq as a Formal System by B. Jacobs (2013), pdf.
I have this relation:
wiki(url,title,abstract,link,category_id,category,heading,heading_pos)
And the FD's are:
F = {
url → title, abstract
category_id → category
url, heading_pos → heading
}
I need to find the keys and decompose into a set of Boyce-Codd normalized relations. I have tried to read related and similar questions but I'm unable to understand the given answers. Hope someone will help me with this assignment
Assuming 'wiki' as relation R and its attributes url,title,..heading_pos to be A,B,...H respectively.
We have,
R = {A,B,C,D,E,F,G,H}
FD's = {A->BC, E->F, AH->G}
The key here is ADEH.
We can first convert the relation R to 3NF and then to BCNF.
To convert a relation R and a set of functional dependencies(FD's) into 3NF you can use Bernstein's Synthesis. To apply Bernstein's Synthesis -
First we make sure the given set of FD's is a minimal cover
Second we take each FD and make it its own sub-schema.
Third we try to combine those sub-schemas
For example in your case:
First we check whether the FD's is a minimal cover (singleton right-hand side , no extraneous left-hand side attribute, no redundant FD)
Singleton RHS: We write the FD's with singleton RHS. So now we have FD's as {A->B, A->C, E->F, AH->G}
No extraneous LHS attribute: We remove the extraneous LHS attribute if any. There are no extraneous LHS attributes here.
No redundant FD's: We remove the redundant dependencies if any. There are no redundant dependencies here.
Second we make each FD its own sub-schema. So now we have - (the keys for each relation are in bold)
R1={A,B}
R2={A,C}
R3={E,F}
R4={A,H,G}
Third we combine all sub-schemas with the same LHS. So now we have -
S1 = {A,B,C}
S2 = {E,F}
S3 = {A,H,G}
Since none of the above decomposed relations contain contain a key of R, we need to create an additional relation schema that contains attributes that form of a key of R. This is to ensure lossless join decomposition that preserves dependencies. So we add -
S4 = {A,D,E,H}
This is in 3NF. Now to check for BCNF we check if any of these relations (S1,S2,S3,S4) violate the conditions of BCNF (i.e. for every functional dependency X->Y the left hand side (X) has to be a superkey) . In this case none of these violate BCNF and hence it is also decomposed to BCNF.
Note - The importance of some of these steps may not be clear in this example. Have a look at other examples here and here.
consider a relation R = {P, Q, R, S, T} and the functional dependency F = {P -> Q, {Q, R} -> S, S -> {Q, R}, {S, T} -> phi}. Are there any redundant functional dependencies in F? If so, remove them and decompose the relation R to 3NF relation.
Plz answer this
{S,T}->phi is trivial, and hence redundant. Moreover, there are no redundant attributes so you have your canonical cover here.
To decompose to 3NF you should:
1) create table for each dependency in the canonical cover
2) identify a candidate key
3) if the candidate key is not included in any of the tables so far, add it as an additional table
4) remove tables if all their attributes are included in another table