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
Related
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 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.
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.
Does it make sense to define multiple flatMap (or >>= / bind in Haskell) methods in a Monad?
The very few monads I actually use (Option, Try, Either projections) only define one flatMap method.
For exemple, could it make sense to define a flatMap method on Option which would take a function producing a Try? So that Option[Try[User]] would be flattened as Option[User] for exemple? (Considering loosing the exception is not a problem ...)
Or a monad should just define one flatMap method, taking a function which produces the same kind of monad? I guess in this case the Either projections wouldn't be monads? Are they?
I have once seriously thought about this. As it turns out, such a construct (aside from losing all monadic capabilities) is not really interesting, since it is sufficient to provide a conversion from the inner to the outer container:
joinWith :: (Functor m, Monad m) => (n a -> m a) -> m (n a) -> m a
joinWith i = join . (fmap i)
bindWith :: (Functor m, Monad m) => (n a -> m a) -> m a -> (a -> n a) -> m a
bindWith i x f = joinWith i $ fmap f x
*Main> let maybeToList = (\x -> case x of Nothing -> []; (Just y) -> [y])
*Main> bindWith maybeToList [1..9] (\x -> if even x then Just x else Nothing)
[2,4,6,8]
It depends what "make sense" means.
If you mean is it consistent with the monad laws, then it's not exactly clear to me the question entirely makes sense. I'd have to see a concrete proposal to tell. If you do it the way I think you suggest, you'll probably end up violating composition at least in some corner cases.
If you mean is it useful, sure, you can always find cases where such things are useful. The problem is that if you start violating monad laws, you have left traps in your code for the unwary functional (category theory) reasoner. Better to make things that look kind of like monads actually be monads (and just one at a time, though you can provide an explicit way to switch a la Either--but you're right that as written LeftProjection and RightProjection are not, strictly speaking, monads). Or write really clear docs explaining that it isn't what it looks like. Otherwise someone will merrily go along assuming the laws hold, and *splat*.
flatMap or (>>=) doesn't typecheck for your Option[Try[ ]] example. In pseudo-Haskell notation
type OptionTry x = Option (Try x)
instance Monad OptionTry where
(>>=) :: OptionTry a -> (a -> OptionTry b) -> OptionTry b
...
We need bind/flatMap to return a value wrapped in the same context as the input value.
We can also see this by looking at the equivalent return/join implementation of a Monad. For OptionTry, join has the specialized type
instance Monad OptionTry where
join :: OptionTry (OptionTry a) -> OptionTry a
...
It should be clear with a bit of squinting that the "flat" part of flatMap is join (or concat for lists where the name derives from).
Now, it's possible for a single datatype to have multiple different binds. Mathematically, a Monad is actually the data type (or, really, the set of values that the monad consists of) along with the particular bind and return operations. Different operations lead to different (mathematical) Monads.
It doesn't make sense, for a specific data type, as far as I know, you can only have one definition for bind.
In haskell a monad is the following type class,
instance Monad m where
return :: a -> m a
bind :: m a -> (a -> m b) -> m b
Concretely For list Monad we have,
instance Monad [] where
return :: a -> [] a
(>>=) :: [] a -> (a -> [] b) -> [] b
Now let's consider a monadic function as.
actOnList :: a -> [] b
....
A Use case to illustrate,
$ [1,2,3] >>= actOnList
On the function actOnList we see that a list is a polymorphic type constraint by another type (here []). Then when we speak about the bind operator for list monad we speak about the bind operator defined by [] a -> (a -> [] b) -> [] b.
What you want to achieve is a bind operator defined like [] Maybe a -> (a -> [] b) -> [] b, this not a specialize version of the first one but another function and regarding it type signature i really doubt that it can be the bind operator of any kind of monad as you do not return what you have consumed. You surely go from one monad to another using a function but this function is definitely not another version of the bind operator of list.
Which is why I've said, It doesn't make sense, for a specific data type, as far as I know, you can only have one definition for bind.
I've read a lot of interesting things about type kinds, higher-kinded types and so on. By default Haskell supports two sorts of kind:
Simple type: *
Type constructor: * → *
Latest GHC's language extensions ConstraintKinds adds a new kind:
Type parameter constraint: Constraint
Also after reading this mailing list it becomes clear that another type of kind may exists, but it is not supported by GHC (but such support is implemented in .NET):
Unboxed type: #
I've learned about polymorphic kinds and I think I understand the idea. Also Haskell supports explicitly-kinded quantification.
So my questions are:
Do any other types of kinds exists?
Are there any other kind-releated language features?
What does subkinding mean? Where is it implemented/useful?
Is there a type system on top of kinds, like kinds are a type system on top of types? (just interested)
Yes, other kinds exist. The page Intermediate Types describes other kinds used in GHC (including both unboxed types and some more complicated kinds as well). The Ωmega language takes higher-kinded types to the maximum logical extension, allowing for user-definable kinds (and sorts, and higher). This page proposes a kind system extension for GHC which would allow for user-definable kinds in Haskell, as well as a good example of why they would be useful.
As a short excerpt, suppose you wanted a list type which had a type-level annotation of the length of the list, like this:
data Zero
data Succ n
data List :: * -> * -> * where
Nil :: List a Zero
Cons :: a -> List a n -> List a (Succ n)
The intention is that the last type argument should only be Zero or Succ n, where n is again only Zero or Succ n. In short, you need to introduce a new kind, called Nat which contains only the two types Zero and Succ n. Then the List datatype could express that the last argument is not a *, but a Nat, like
data List :: * -> Nat -> * where
Nil :: List a Zero
Cons :: a -> List a n -> List a (Succ n)
This would allow the type checker to be much more discriminative in what it accepts, as well as making type-level programming much more expressive.
Just as types are classified with kinds, kinds are classified with sorts.
Ωmega programming language has a kind system with user definable kinds at any level. (So says its wiki. I think it refers to the sorts and the levels above, but I am not sure.)
There has been a proposal to lift types into the kind level and values into the type level. But I don't know if that is already implemented (or if it ever will reach "prime time")
Consider the following code:
data Z
data S a
data Vec (a :: *) (b :: *) where
VNil :: Vec Z a
VCons :: a -> Vec l a -> Vec (S l) a
This is a Vector that has it's dimension encoded in the type. We are using Z and S to generate the natural number. That's kind of nice but we cannot "type check" if we are using the right types when generating a Vec (we could accidently switch length an content type) and we also need to generate a type S and Z, which is inconvenient if we already defined the natural numbers like so:
data Nat = Z | S Nat
With the proposal you could write something like this:
data Nat = Z | S Nat
data Vec (a :: Nat) (b :: *) where
VNil :: Vec Z a
VCons :: a -> Vec l a -> Vec (S l) a
This would lift Nat into the kind level and S and Z into the type level if needed. So Nat is another kind and lives on the same level as *.
Here is the presentation by Brent Yorgey
Typed type-level functional programming in GHC