How should i treat multi-valued logic in a canonical overlap calculation? - database

The Situation:
B->TCW
C->WG
TCB->OMW
L->UNM
TL->CGM
Now i have to calculate the canonical overlap and remove the redundancies.
After left and right reduction i get the following result
B -> TC
C -> WG
TCB -> OM
L -> UNM
TL -> C
So the question is, what would happen if i had two more functional dependences?
e.g.
B->TCW
C->WG
TCB->OMW
L->UNM
TL->CGM
BL ->-> F
BL ->-> G
From my point of view or understanding, i would say both new multi-valued logics does not has any influence to the canonical overlap. So the result would be the same just with the two multi-valued logics.
But what would happen if we had a multi-valued logic which has influence to the result?
Is it permitted to cross out the duplicates or is it not allowed, because if we have a multi-valued logic every letter will be a key value?

Related

Decomposing into 2NF

I'm currently studying normalization. I know how to normalize the data for given unnormalized list.
But this one is little bit confusing me
Q. Decompose R{a,b,c,d,e,f} into 2NF using following functional dependencies.
a -> b,c,d,e,f
b,c -> a,d,e,f
b -> f
d -> e
For this my answer is:
R0 = a - > b,c
R1 = b,c - > a,d,e
R2 = b - > f
Can anyone help me with this?
There are two main issues:
There is a lot of redundancy in your FDs set. You'll often save yourself some time if you compute the minimal cover first.
The way you split the relation doesn't make sense, regardless of the normalization level. The candidate keys for this relation are A and BC; but in your answer you have all the keys together in R0 and nothing else, which is redundant (one key per table is enough) and useless (think about it, there is nothing you can query for in such a table!); and again you put all the keys together in R1, which is redundant as well.
A better way to decompose that relation would be
R1(B, F), R2(D, E), R3(A, B, C, D)
which satisfies both 2NF and 3NF.
BTW you should check out this Stanford course, it is really useful to understand normalization. Wikipedia pages are also well written.
EDIT to answer your question on the comments: a functional dependency means that the values on the RHS are determined by the values on the LHS. In this case we have
A -> BC
BC -> A
if you replace the letters with something more intuitive this is equivalent to:
post_id -> { post_title, post_date }
{ post_title, post_date } -> post_id
That is, if you know the post_id you can figure out both the post_title and the post_date; at the same time, if you know both the post_title and the post_date you can track back the post_id. This is the meaning of a circular dependency.
That said, in every relation all the FDs should be preserved so in R3 both BC -> D and A -> D hold, but you don't need ABC -> D which is not in your FDs set and it is clearly redundant. As a side, A -> D is redundant as well since you already have A -> BC, BC -> D. This is why I mentioned to compute the minimal cover first.

algorithm for computing closure of a set of FDs

I'm looking for an easy to understand algorithm to compute (by hand) a closure of a set of functional dependencies.
Some sources, including my instructor says I should just play with Armstrong's axioms and see what I can get at. To me, that's not a systematic way about doing it (i.e. easy to miss something).
Our course textbook (DB systems - the complete book, 2nd ed) doesn't give an algorithm for this either.
To put it in more "systematic" fashion, this could be the algorithm you are looking for. Using the first three Armstrong's Axioms:
Closure = S
Loop
For each F in S, apply reflexivity and augmentation rules
Add the new FDs to the Closure
For each pair of FDs in S, apply the transitivity rule
Add the new Fd to Closure
Until closure doesn't change any further`
Which I took from this presentation notes. However, I found the following approach way easier to implement:
/*F is a set of FDs */
F⁺ = empty set
for each attribute set X
compute the closure X⁺ of X on F
for each attribute A in X⁺
add to F⁺ the FD: X -> A
return F⁺
which is taken from here
The set of all attributes functionally determined by α under a set F of FDs.
eg. Suppose we have these starting FDs and we want to compute all the closure using the below once.
A -> BC
AC -> D
D -> B
AB -> D
More FDs calculated by above present once
A+ -> (A,B,C,D)
B+ -> (B)
Similarly we can calculate C+, D+, (AC)+, (AB)+ and so on...
There is a very easy alg. to calculate all set of FDs though
RESULT <- α
MODIFIED <- TRUE
WHILE(MODIFIED) {
MODIFIED <- FALSE
∀ FD A->B IN F DO{
IF A ⊂ RESULT {
RESULT <- (RESULT) ∪ (B)
MODIFIED <- TRUE IF RESULT CHANGES
}
}
}
If by "play" he meant an exhaustive search, then in no way this is not-systematic ;) And a simple solution could look like iterative expansion*) of the set of dependencies on the rule-by-rule basis seems to be just a queue of items to be revisited and a few (two?) loops.. Have you tried it?
Btw. googling around I immediatelly found http://www.cs.sfu.ca/CourseCentral/354/zaiane/material/notes/Chapter6/node12.html - but I cannot verify if it is reasonable because my battery in laptop is literally going down!
*) Simply: apply them iteratively as long as anything has changed in the previous iteration. When applying ALL of them does not change anything in the current state (i.e. (A -> ABCDEF) += (ADEF) ==> (A -> ABCDEF) so no new symbol was added to the set), then it means, well, that no further expansions expand it furhter, so I think that's the point to assume the no-more-growing set to be complete.

boyce codd and finding candidate keys

needing desperate help with understanding boyce codd and finding the candidate keys.
i found a link here http://djitz.com/neu-mscs/how-to-find-candidate-keys/ which i have understood for most part but i get stuck
e.g
(A B C D E F)
A B → C D E
B C D → A
B C E → A D
B D → E
right as far as i understand from the link i know you find the common sets from the left which is only B, and common sets from the right which are none
now where do i go from here? i know all candidate sets will have B in them but i need guidance on finding candidate sets after that. someone explain in simple language
The linked article isn't written particularly well. (That's an observation, not a criticism. The author's first language isn't English.) I'll try to rewrite the algorithm. This isn't me telling you how to do this. It's my interpretation of how the original author is telling you to do this.
Identify the attributes that are on neither the left side nor right side of any FD.
Identify the attributes that are only on the right side of any FD.
Identify the attributes that are only on the left side of any FD.
Combine the attributes from steps 1 and 3.
Compute the closure of the attributes from step 4. If the closure comprises all the attributes, then the attributes from step 4 make up the only candidate key. (No matter how many candidate keys there are, every one of them must contain these attributes.)
Identify the attributes not included in step 4 and step 2.
Compute the closure of the attributes from step 4 plus every possible combination of attributes from step 6.
So for the FDs you posted, you'd end up with this.
{F}
{}
{B}
{BF}
The closure of {BF} is {BF}. That's not all the attributes. (But every candidate key must contain {BF}.)
{ACDE}
Compute the closure of these sets of attributes.
{ABF}
{CBF}
{DBF}
{EBF}
{ACBF}
{ADBF}
{AEBF}
{CDBF}
{CEBF}
{DEBF}
{ACDBF}
{ADEBF}
{CDEBF}
If I got those combinations right, every candidate key will be found among the possibilities in step 7. In your example, there are 3 candidate keys.
http://www.sroede.nl/projects/fdhelper.aspx
this would help'just put in ur relation and FD's
click generate at the bottom

Database Relational Homework help

The Problem "Consider a relation R with five attributes ABCDE. You are given the following dependancies
A->B
BC->E
ED->A
List all the keys for R.
The teacher gave us the keys, Which are ACD,BCD,CDE
And we need to show the work to get to them.
The First two I solved.
For BCD, the transitive of 2 with 3 to get (BC->E)D->A => BCD->A.
and for ACD id the the transitive of 1 with 4 (BCD), to get (A->B)CD->A => ACD->A
But I can't figure out how to get CDE.
So it seems I did it wrong, after googling I found this answer
methodology to find keys:
consider attribute sets α containing: a. the determinant attributes of F (i.e. A, BC,
ED) and b. the attributes NOT contained in the determined ones (i.e. C,D). Then
do the attribute closure algorithm:
if α+ superset R then α -> R
Three keys: CDE, ACD, BCD
Source
From what I can tell, since C,D are not on the left side of the dependencies. The keys are left sides with CD pre-appended to them. Can anyone explain this to me in better detail as to why?
To get they keys, you start with one of the dependencies and using inference to extend the set.
Let me have a go with simple English, you can find formal definition the net easily.
e.g. start with 3).
ED -> A
(knowing E and D, I know A)
ED ->AB
(knowing E and D, I know A, by knowing A, I know B as well)
ED->AB
Still, C cannot be known, and I have used all the rules now except BC->E,
So I add C to the left hand side, i.e.
CDE ->AB
so, by knowing C,D and E, you will know A and B as well,
Hence CDE is a key for your relation ABCDE. You repeat the same process, starting with other rules until exhausted.

Question about relation normalization

Let's consider, for instance, the following relation:
R (A,B,C,D,E,F)
where the bold denotes that it is a primary key attribute
with
F = {AB->DE, D->E}
Now, this looks to be in the first normal form. It can't be on the third normal form as I have a transitive dependency and it cannot be in the second form as not all non-key attributes depend on the whole primary key.
So my questions are:
I don't know what to make of F and C. I don't have any functional dependency info on them! F doesn't depend on anything? If that is the case, I can't think of any solution to get R into the 2nd normal form without taking it out!
What about C? C also suffers from the problem of not being referred on the functional dependencies list. What to do about it?
My attempt to get R into the 2nd normal form would be something like:
R(A,B,D)
R' (D,E)
but as stated earlier, I don't have a clue of what to do of C and F. Are they redundant so I simply take them out and the above attempt is all I have to do to get it into the 2nd form (and 3rd!)?
Thanks
Given the definition of R that { A, B, C } is the primary key, then there is inherently a functional dependency:
ABC → ABCDEF
That says that the values of A, B and C inherently determine or control the values of D, E and F as well as the trivial fact that they determine their own values.
You have a few additional dependencies, identified by the set F (which is distinct from the attribute F - the notation is not very felicitous, and could be causing confusion*):
AB → DE
D → E
As you rightly diagnose, the system is in 1NF (because 1NF really means "it is a table"). It is not in 2NF or 3NF or BCNF etc because of the transitive dependency and because some of the attributes only depend on part of the key.
You are right that you will end up with the following two relations as part of your decomposition:
R1(D, E)
R2(A, B, D)
You also need the third relation:
R3(A, B, C, F)
From these, you can recreate the original relation R using joins. The set of relations { R1, R2, R3 } is a non-loss decomposition of the original relation R.
* If the F identifying the set of subsidiary functional dependencies is intended to be the same as the attribute F, then there is something very weird about the definition of that attribute. I'd need to see sample data for the relation R to have a chance of knowing how to interpret it.
I think the primary key of R is set wrong. If F isn't functionally related to anything it has to be a part of the key
So you have R( ABCF DE) which is now in the first normal form (with F = {AB->DE, D->E}) Now you can change it to the second normal form. DE isn't dependant on the whole key (partial dependency) so you put it in another relation to get to second normal form:
R( ABCF ) F = {}
R1( #AB DE) F = {AB->DE}
Now this relation doesn't have any transitive dependencies so it is already in third normal form.
F doesn't depend on anything?
No, you just haven't been given any explicit information about it in the form
{something -> F}
And essentially the same can be said for C. You're expected to infer the other dependencies by applying Armstrong's axioms. (Probably.)
Think about how to finish this:
Given R (A,B,C,D,E,F)
{ABC -> ?}
[Later . . . I see that Jonathan Leffler has broken the suspense, so I'll just finish this.]
{ABC -> DEF} (By definition) therefore,
{ABC -> F} (By decomposition. Here's where F and C come in. And this is your third relation. ).

Resources