I have the following problem: R(ABCDEFG) and F ={ AB->CD, C->EF, G->A, G->F, CE ->F}. Clearly, B & G should be part of the key as they are not part of the dependent set. Further, BG+ = ABCDEFG, hence candidate key. Clearly, AB->CD violates BCNF. But when I follow the algorithm, I do not end up in any answer. Probably doing something wrong. Can anyone show me how to apply the algorithm correctly to reach the decomposition?
Thanks in advance.
First, you should calculate a canonical cover of the dependencies. In this case it is:
{ A B → C
A B → D
C → E
C → F
G → A
G → F } >
Since the (unique) candidate key is B G, no functional dependency satisfies the BNCF. Then, starting from any functional dependency X → Y that violates the BCNF, we calculate the closure of X, X+, and replace the original relation R<T,F> with two relations, R1<X+> and R2<T - X+ + X>. So, chosing in this case the dependency A B → C, we replace the original relation with:
R1 < (A B C D E F) ,
{ A B → C
A B → D
C → E
C → F} >
and:
R2 < (A B G) ,
{ G → A } >
Then we check each decomposed relation to see if it satisfies the BCNF, otherwise we apply recursively the algorithm.
In this case, for instance, in R1 the key is A B, so C -> E violates the BCNF, and we replace R1 with:
R3 < (C E F) ,
{ C → E
C → F } >
and:
R4 < (A B C D) ,
{ A B → C
A B → D } >
two relations that satisfy the BCNF.
Finally, since R2 too does not satisfy the BCNF (beacuse the key is B G), we decompose R2 in:
R5 < (A G) ,
{ G → A } >
and:
R6 < (B G) ,
{ } >
that are in BCNF.
So the final decomposition is constituted by the relations: R3, R4, R5, and R6. We can also note that the dependency G → F on the original relation is lost in the decomposition.
Related
I have the below functional dependencies in minimal cover, and I am looking to put them into 3NF lossless join and dependency preserving decomposition.
FD 1: {A} -> {B,C,D,E};
FD 2: {F} -> {G,H,I,J,K};
FD 3: {G,H,I,L} -> {M};
FD 4: {N} -> {O,P,F};
FD 5: {N,B} -> {Q,L};
Key: {A,N}
The key is A,N and are the determinants of FD1 and FD4, I am unsure whether my 3NF decomposition should contain and extra table that contains all of the attributes from the FD1 and FD4 so that I can preserve the key? or that they should not be merged so that I can reduce redundancy if they were to be merged?
Thanks in advance!
In general the 3NF is found through an algorithm that details all the steps that produce a correct decomposition. Such algorithms are described in all good books on databases. For instance, in your case, the so-called “synthesis” algorithm produces the following decomposition:
R1 {A B C D E}
R2 {B L N Q}
R3 {F G H I J K}
R4 {G H I L M}
R5 {F N O P}
R6 {A N}
Note that the relation R6 contains the key of the original relation, and this is necessary to guarantee the lossless join property.
Motivation: I am attempting to study category theory while creating a Coq formalization of the ideas I find in whatever textbook I follow. In order to make this formalization as simple as possible, I figured I should identify objects with their identity arrow, so a category can be reduced to a set (class, type) of arrows X with a source mapping s:X->X, target mapping t:X->X, and composition mapping product : X -> X -> option X which is a partial mapping defined for t f = s g. Obviously the structure (X,s,t,product) should follow various properties. For the sake of clarity, I am spelling out the formalization I chose below, but there is no need to follow it I think in order to read my question:
Record Category {A:Type} : Type := category
{ source : A -> A
; target : A -> A
; product: A -> A -> option A
; proof_of_ss : forall f:A, source (source f) = source f
; proof_of_ts : forall f:A, target (source f) = source f
; proof_of_tt : forall f:A, target (target f) = target f
; proof_of_st : forall f:A, source (target f) = target f
; proof_of_dom: forall f g:A, target f = source g <-> product f g <> None
; proof_of_src: forall f g h:A, product f g = Some h -> source h = source f
; proof_of_tgt: forall f g h:A, product f g = Some h -> target h = target g
; proof_of_idl: forall a f:A,
a = source a ->
a = target a ->
a = source f ->
product a f = Some f
; proof_of_idr: forall a f:A,
a = source a ->
a = target a ->
a = target f ->
product f a = Some f
; proof_of_asc:
forall f g h fg gh:A,
product f g = Some fg ->
product g h = Some gh ->
product fg h = product f gh
}
.
I have no idea how practical this is and how far it will take me. I see this as an opportunity to learn category theory and Coq at the same time.
Problem: My first objective was to create a 'Category' which would resemble as much as possible the category Set. In a set theoretic framework, I would probably consider the class of triplets (a,b,f) where f is a map with domain a and range a subset of b. With this in mind I tried:
Record Arrow : Type := arrow
{ dom : Type
; cod : Type
; arr : dom -> cod
}
.
So that Arrow becomes my base type on which I could attempt building a structure of category. I start embedding Type into Arrow:
Definition id (a : Type) : Arrow := arrow a a (fun x => x).
which allows me to define the source and target mappings:
Definition domain (f:Arrow) : Arrow := id (dom f).
Definition codomain (f:Arrow) : Arrow := id (cod f).
Then I move on to defining a composition on Arrow:
Definition compose (f g: Arrow) : option Arrow :=
match f with
| arrow a b f' =>
match g with
| arrow b' c g' =>
match b with
| b' => Some (arrow a c (fun x => (g' (f' x))))
| _ => None
end
end
end.
However, this code is illegal as I get the error:
The term "f' x" has type "b" while it is expected to have type "b'".
Question: I have the feeling I am not going to get away with this, My using Type naively would take me to some sort of Russel paradox which Coq will not allow me to do. However, just in case, is there a way to define compose on Arrow?
Your encoding does not work in plain Coq because of the constructive nature of the theory: it is not possible to compare two sets for equality. If you absolutely want to follow this approach, Daniel's comment sketches a solution: you need to assume a strong classical principle to be able to check whether the endpoints of two arrows match, and then manipulate an equality proof to make Coq accept the definition.
Another approach is to have separate types for arrows and objects, and use type dependency to express the compatibility requirement on arrow endpoints. This definition requires only three axioms, and considerably simplifies the construction of categories:
Set Implicit Arguments.
Unset Strict Implicit.
Unset Printing Implicit Defensive.
Record category : Type := Category {
obj : Type;
hom : obj -> obj -> Type;
id : forall {X}, hom X X;
comp : forall X Y Z, hom X Y -> hom Y Z -> hom X Z;
(* Axioms *)
idL : forall X Y (f : hom X Y), comp id f = f;
idR : forall X Y (f : hom X Y), comp f id = f;
assoc : forall X Y Z W
(f : hom X Y) (g : hom Y Z) (h : hom Z W),
comp f (comp g h) = comp (comp f g) h
}.
We can now define the category of sets and ask Coq to automatically prove the axioms for us.
Require Import Coq.Program.Tactics.
Program Definition Sets : category := {|
obj := Type;
hom X Y := X -> Y;
id X := fun x => x;
comp X Y Z f g := fun x => g (f x)
|}.
(This does not lead to any circularity paradoxes, because of Coq's universe mechanism: Coq understands that the Type used in this definition is actually smaller than the one used to define category.)
This encoding is sometimes inconvenient due to the lack of extensionality in Coq's theory, because it prevents certain axioms from holding. Consider the category of groups, for example, where the morphisms are functions that commute with the group operations. A reasonable definition for these morphisms could be as follows (assuming that there is some type group representing groups, with * denotes multiplication and 1 denotes the neutral element).
Record group_morphism (X Y : group) : Type := {
mor : X -> Y;
mor_1 : mor 1 = 1;
mor_m : forall x1 x2, mor (x1 * x2) = mor x1 * mor x2
}.
The problem is that the properties mor_1 and mor_m interfere with the notion of equality for elements of group_morphism, making the proofs for associativity and identity that worked for Sets break. There are two solutions:
Adopt extra axioms into the theory so that the required properties still go through. In the above example, you would need proof irrelevance:
proof_irrelevance : forall (P : Prop) (p q : P), p = q.
Change the category axioms so that the identities are valid up to some equivalence relation specific to that category, instead of the plain Coq equality. This approach is followed here, for example.
I have this database:
R(A, B, C, D, E)
Keys: A
F = {A -> B, D -> E, C -> D}
I normalize it into 3NF like this:
R(A, B, C, D, E)
Keys: AD
F = {AD -> B, AD -> E, C -> D}
What I do is when I check D -> E, D is not a superkey and E is not a key attribute, so I treat D and A as a superkey {AD}. When I check C -> D, C is not a key but D is a key attribute so it's OK.
Is my normalization correctly?
There is a problem in your input data. If the relation R has the dependencies F = {A -> B, D -> E, C -> D}, then A cannot be a key. In fact, a key is a set of attributes whose closure determines all the attributes of the relation, which is not the case here, since:
A+ = AB
From F, the (only) possible key is AC, in fact
AC+ = ABCD
Normalizing means to reduce the redundancy by decomposing a relation in other relations in which the functional dependencies do not violate the normal form, and such that joining the decomposed relations, one can obtain the original one.
In you solution, you do not decompose the relation, but only change the set of dependencies with other dependencies not implied by the first set.
A correct decomposition would be instead the following:
R1 < (A B) ,
{ A → B } >
R2 < (C D) ,
{ C → D } >
R3 < (D E) ,
{ D → E } >
R4 < (A C) ,
{ } >
The algorithm to decompose a relation into 3NF can be found on any good book on databases.
I would like to build a kind of type hierarchy:
B is of type A ( B::A )
C and D are of type of B (C,D ::B)
E and F are of type of C (E,F ::C)
I asked here if this is possible to be directly implemented in Isabelle, but the answer as you see was No. Is it possible to encode this directly in Agda or Coq?
PS: Suppose A..F are all abstract and some functions are defined over each type)
Thanks
If I understood your question correctly, you want something that looks like the identity type. When we declare the type constructor _isOfType_, we mention two Sets (the parameter A and the index B) but the constructor indeed makes sure that the only way to construct an element of such a type is to enforce that they are indeed equal (and that a is of this type):
data _isOfType_ {ℓ} {A : Set ℓ} (a : A) : (B : Set ℓ) → Set where
indeed : a isOfType A
We can now have functions taking as arguments proofs that things are of the right type. Here I translated your requirements & assumed that I had a function f able to combine two Cs into one. Pattern-matching on the appropriate assumptions reveals that E and F are indeed on type C and can therefore be fed to f to discharge the goal:
example : ∀ (A : Set₃) (B : Set₂) (C D : Set₁) (E F : Set) →
B isOfType A
→ C isOfType B → D isOfType B
→ E isOfType C → F isOfType C
→ (f : C → C → C) → C
example A B .Set D E F _ _ _ indeed indeed f = f E F
Do you have a particular use case in mind for this sort of patterns or are you coming to Agda with ideas you have encountered in other programming languages? There may be a more idiomatic way to formulate your problem.
I have following classes: Classes B, C and D are the subclasses of A.
A ----+----------> B
|
+----------> C
|
+----------> D
Besides, I have an object property, hasObjectProperty, and some other classes X, Y, Z,
where X, Y, Z are disjoint classes.
Then I set restrictions to classes B, C and D as following:
(Here I use Manchester OWL syntax used in Protege as well http://www.co-ode.org/resources/reference/manchester_syntax/ )
B: (hasObjectProperty only X) and (hasObjectProperty some X)
C: (hasObjectProperty only Y) and (hasObjectProperty some Y)
D: (hasObjectProperty only Z) and (hasObjectProperty some Z)
now the question is, how can I describe a Class E, which should be the union of only Class B and C?
How can I describe a Class which can be both Class B and Class C (but not Class D)?
A ----+----------> B ------> E
|
+----------> C ------> E
|
+----------> D
is is possible?
I tried to define Class E's restriction like this. But a Reasoner will determine it as invalid.
E: ((hasObjectProperty only X) and (hasObjectProperty some X)) or ((hasObjectProperty only Y) and (hasObjectProperty some Y))
thanks a lot!
In order to restrict E to be exactly the union of B and C, you can state:
E ≡ (B or C)
i.e., that anything belonging to the union of B and C is in E, and vice-versa (encoding the subsumption relationship both ways).
Note that this necessarily makes E a superclass to both B and C since it contains them both, so you will instead get:
A --+---> E --+---> B
| |
+---> D +---> C