Is x--->y a trivial functional dependency? - database

If y is a subset of x then x-->y is trivial functional dependency (it is well known). But I have doubt: y is not subset of x and x U y = R, then can I say x-->y is a trivial functional dependency.( I read it in some article)
Adding to above question: Why X U Y = R holds in case of multivalued dependencies(trivial)? Can somebody give an example so that I can understand?

No, you can't. Suppose R is {a1, a2} x is a1 and y is a2. x U y = R holds, but x-->y is not necessarily true.

Trivial functional dependency
No it is not a trivial functional. It is only a trivial functional dependency when a subset of attributes depends from the full set.
Definition of trivial functional dependency:
Eg.: (a,b) depends from (a,b,c) attributes.
In you case it is not a subset, so it is not a trivial functional dependency.
What you described is a key candidate. (X depends from itself (trivial), and it also determines all the other part, so this way the whole relation)
Multivalued dependencies
Multivalues dependencies can be threathed like it was some more general version of functional dependencies.
Some help:
Multivalued dependencies on Wikipedia
You can even find some examples there and also the formal definition.

Related

How do deal with combined entity types when computing the closure of a set of attributes

I'm revising for coming exams, and I am having trouble understanding an example question regarding the closure of attributes. Here is the problem:
AB→C
BE→I
E→C
CI→D
Find the closure of the set of attributes BE, explaining each step.
I've found many explanations of the method of closure when the given step is a single entity type, say 'C', using Armstrong axioms, but I don't understand how to answer for 'BE'.
First, you are confusing two very different things, attributes and entity types. Briefly, entity types are used to describe the real world entities that are modelled in a database schema. Attributes describe facts about such entities. For instance an entity type Person could have as attributes Family Name, Date of Birth, etc.
So the question is how to compute the closure of a set of attributes. You can apply the Armstrong’s axioms, trying at each step to apply one of them, until possible, but you can also simplify the computation by using the following, very simple, algorithm (and if you google "algorithm closure set attributes" you find a lot of descriptions of it):
We want to find X+, the closure of the set of attributes X.
To find it, first assign X to X+.
Then repeat the following while X+ changes:
If there is a functional dependency W → V such as W ⊆ X+ and V ⊈ X+,
unite V to X+.
So in your case, given:
AB → C
BE → I
E → C
CI → D
to compute BE+ we can procede in this way:
1. BE+ = BE
2. BE+ = BEI (because of BE → I)
3. BE+ = BEIC (because of E → C)
4. BE+ = BEICD (because of CI → D)
No other dependency can be used to modify BE+, so the algorithm terminates and the result is BCDEI. In terms of Armstrong’ axioms, the step 1 is due to Reflexivity, while the steps 2 to 4 are due to a combination of Transitivity and Augmentation.

Reflexivity in functional dependencies

I'm taking a class on databases and I'm doing an assignment on functional dependencies. As an example of taking given dependencies and deriving other non-trivial dependencies using Armstrong's Axioms, the TA wrote this and I can't wrap my head around it.
Considering the relation R(c,p,h,s,e,n) and F the set of functional dependencies {1. c->p, 2. hs->c, 3. hp->s, 4. ce->n, 5. he->s}:
Iteration 1:
From F, we can build F1
6. hs->p (transitivity: 1+2)
7. hc->s (pseudo-transitive. 1+3)
8. hp->c
1. hp->hs (reflexivity 3)
2. hp->c (transitivity: 8.1+2)
9. he->c
1. he->hs (reflexivity: 4)
2. he->c (transitivity: 9.1+2)
I understand most of it fine except the cases where 'reflexivity' is used (using quotes because that's pretty far from the definition of reflexivity in my textbook). Can anyone tell me how that's reflexivity? Also, how do I know when an iteration is over? Couldn't you find an infinity of ways to rewrite functional dependencies?
These are the classical Armstrong’s Axioms (see for instance wikipedia):
Reflexivity: If Y ⊆ X then X → Y
Augmentation: If X → Y then XZ → YZ for any Z
Transitivity: If X → Y and Y → Z, then X → Z
So in your example, to derive hp → c you can procede in the following way:
1. hp → s (given)
2. hp → hs (by augmentation of 1 adding h)
3. hs → c (given)
4. hp → c (by transitivity of 2 + 3)
Note that to produce hp → hs from hp → s the axiom to use is Augmentation, in which the role of Z is taken by h, and not Reflexivity, and this is the axiom to use also to derive he → c (by Reflexivity you can only derive, for instance, hp → hp, hp → p, hp → h).
You are also asking:
How do I know when an iteration is over? Couldn't you find an infinity of ways to rewrite functional dependencies?
The Armstrong’s Axioms can be applied to a set of functional dependencies only a finite number of times to produce new functional dependencies. This is simple to show since the number of attributes is finite, and, given n attributes you can have at most 2n * 2n different functional dependencies (since you can have any subset of the attributes both on the left and the right part, of course including the trivial dependencies).
A name doesn't tell you anything except what somebody decided to call something.
Trivial FD X -> X holds in any relation with the attributes in X. Ie a set of attributes in a relation functionally determines itself. That's reasonably called reflexive. It happens that it functionally determines every subset of itself. It happens "reflexivity" was chosen as the name for the more general rule & the more general rule was chosen as one of a set of sufficient but non-redundant rules.
Armstrong's axioms have been shown to be sound & complete. Sound means they only generate implied FDs. Complete means that if you keep applying an axiom until you don't get any new FDs by applying any of them then you get all the FDs that can be derived from the original set, ie that also must hold when the original ones hold. Any textbook tells you that you can generate such a transitive closure of a set of FDs by doing just that.
There are also sound & complete axiom sets for FDs + MVDs. But there aren't for FDs + JDs.

4NF, Multivalued Dependencies without Functional Dependencies

Sorry for asking a question one might consider a basic one)
Suppose we have a relation R(A,B,C,D,E) with multivalued dependencies:
A->>B
B->>D.
Relation R doesn't have any functional dependencies.
Next, suppose we decompose R into 4NF.
My considerations:
Since we don't have any functional dependencies, the only key is all attributes (A,B,C,D,E). There are two ways we can decompose our relation R:
R1(A,B) R2(A,C,D,E)
R3(B,D) R4(A,B,C,E)
My question is - are these 2 decompositions final? Looks like they are since there are no nontrivial multivalued dependencies left. Or am I missing something?
Relation R doesn't have any functional dependencies.
You mean, non-trivial FDs (functional dependencies). (There must always be trivial FDs.)
Assuming that the MVDs (multivalued dependencies) holding in R are those in the transitive closure of {A ↠ B, B ↠ D}:
In 1 R1(A,B) R2(A,C,D,E), we can reconstruct R as R1 JOIN R2 and both R1 & R2 are in 4NF and their join will satisfy A ↠ B. If some component contained all the attributes of the other MVD then we could further decompose it per that MVD. And we would know that, given some alleged values for all components, their alleged reconstruction of R by joining would satisfy both MVDs. But here there is no such component. So we can't further decompose. And we know that an alleged reconstruction of R by joining satisfies A ↠ B but we would still have to check whether B ↠ D. We say that the MVD B ↠ D is "not preserved" and the decomposition to R1 & R2 "does not preserve MVDs".
In 2 R3(B,D) R4(A,B,C,E), we can reconstruct R as R3 JOIN R4 and both R3 & R4 are in 4NF and the join will satisfy B ↠ D. Now some component contains all the attributes of the other MVD so we can further decompose it per that MVD. And we know that, given some alleged values for all components, their alleged reconstruction of R by joining satisfies both MVDs. That component is R4, which we can further decompose, reconstructing as AB JOIN ACE. And we know that an alleged reconstruction of R by joining satisfies both A ↠ B & B ↠ D. Because the MVDs in the original appear in a component, we say these decompositions "preserve MVDs".
PS 1 The 4NF decomposition must be to three components
MVDs always come in pairs. Suppose MVD X ↠ Y holds in a relation with attributes S, normalized to components XY & X(S-Y). Notice that S-XY is the set of non-X non-Y attributes, and X(S-Y) = X(S-XY). Then there is also an MVD X ↠ S-XY, normalized to components X(S-XY) & X(S-(S-XY)), ie X(S-XY) & XY, ie X(S-Y) & XY. Why? Notice that both MVDs give the same component pair. Ie both MVDs describe the same condition, that S = XY JOIN X(S-XY). So when an MVD holds, that partner holds too. We can write the condition expressed by each of the MVDs using the special explicit & symmetrical notation X ↠ Y | S-XY.
We say a JD (join dependency) of some components of S holds if and only if they join to S. So if S = XY JOIN X(S-Y) = XY JOIN X(S-XY) then the JD *{XY, X(S-XY)} holds. Ie the condition that both MVDs describe is that JD. So a certain MVD and a certain binary JD correspond. That's one way of seeing why normalizing an MVD away involves a 2-way join and why MVDs come in pairs. The JDs that cause a 4NF relation to not be in 5NF are those that do not correspond to MVDs.
Your example involves two MVDs that aren't partners & neither otherwise holds as a consequence of the other, so you know that the final form of a lossless decomposition will involve two joins, one for each MVD pair.
PS 2 Ambiguity of "Suppose we have a relation with these multi-valued dependencies"
When decomposing per FDs (functional dependencies) we are usually given a canonical/minimal cover for the relation, ie a set in a certain form whose transitive closure under Armstrong's axioms (set of FDs that must consequently hold) holds all the FDs in the relation. This is frequently forgotten when we are told that some FDs hold. We must either be given a canonical/minimal cover for the relation or be given an arbitrary set and be told that the FDs that hold in the relation are the ones in its transitive closure. If we're just given a set of FDs that hold, we know that the ones in its transitive closure hold, but there might be others. So in general we can't normalize.
Here you give some MVDs that hold. But they aren't the only ones, because each has a partner. Moreover others might (and here do) consequently hold. (Eg X ↠ Y and Y ↠ Z implies X ↠ Z-Y holds.) But you don't say that they form a canonical or minimal cover. One way to get a canonical form for MVDs (a unique one per each transitive closure, hopefully more concise!) would be a minimal cover (one that can't lose any MVDs and still have the same transitive closure) augmented by the partner of each MVD. (Whereas for FDs the standard canonical form is minimal.) You also don't say "the MVDs that hold are those in the transitive closure of these". You just say that those MVDs hold. So maybe some not in the transitive closure do too. So your example can't be solved. We can guess that you probably mean that this is a minimal cover. (It's not canonical.) Or that the MVDs that hold in the relation are those in the transitive closure of the given ones. (Which in this case are then a minimal cover.)
A Table is in 4NF if and only if, for every one of its non-trivial multivalued dependencies X ->> Y, X is a superkey—that is, X is either a candidate key or a superset.
In your first decomposition(1 with R1 and R2) B->>D is not satisfying so it's not dependency preserving decomposition as well as not in 4NF as A is not superkey in 2nd table.
On the other hand,second decomposition(2 with R3 and R4) is dependency preserving and lossless join with B and ACE as primary key in respective tables but it's not in 4NF because A->>B dependency exists in second table and A is not superkey, you have to decompose second table further in to two tables that can be {A B} and {A C E}.
So if I follow your reasoning (suraj3), are R1(A,B) and R2(B,C,D,E) correct decomposition? I think this will preserve the FD B->>D.

how to determine functional dependencies and multivalued dependencies?

i have the following table
Case ( referenceID, startDate, endDate, caseDetail, caseType, caseTypeRate,
lawyerName, lawyerContact, clientID, clientName, clientAddress, clientContact,
serviceProvided, serviceDate, serviceCost,
otherPartyID, otherPartyName, otherPartyContact )
my FDs are
referenceID-->caseDetail
referenceID-->caseType
referenceID-->ServiceProvided
lawyerContact-->lawayerName
clientID-->clientName
am i correct or are there more? i'm still a bit unsure of how it works after reading the theory. i need clear examples. how do i determine the mvds as well?
Functional dependency:-If one value for X there is only one value of Y then we can say that Y is functionaly dependent upon X and written as follow.
X -> Y
Multivalue dependecy:-If for one value of X there are more than one values of Y then we can say that Y is multivalue dependency upon X and it is written as followes.
X ->-> Y
Loosely speaking, a functional dependency expressed as x -> y means, "When I know any value of x, I know one and only one value of y." So the value of x determines one and only one value of y.
To determine whether a functional dependency exists, you ask yourself the question, "If I know any value for x, do I know one and only one value for y?", and then answer it.
In your case, I'd guess that most of these additional functional dependencies will hold. It's hard to tell for sure, since there's no sample data, and since I don't know what the columns mean. (Trying to determine functional dependencies based solely on column names is very risky. Here, "startDate" could mean just about anything.)
referenceID -> startDate
referenceID -> endDate
referenceID -> caseType
referenceID -> caseTypeRate
clientID -> clientName
clientID -> clientAddress
clientID -> clientContact
otherPartyID -> otherPartyName
otherPartyID -> otherPartyContact
There are others.
Wikipedia has a concise example of a multi-valued dependency.
Here is a good example of how to determine a MVD: https://web.archive.org/web/20140212170321/https://www.cs.oberlin.edu/~jdonalds/311/lecture08.html.
Basically, follow this algorithm:
1) Figure out if A determines a set of values for B,
2) Figure out if A determines a set of values for C, and then
3) Determine if B and C are independent of each other.
A, B, C are a set of attributes. If the conditions are satisfied then
A -->> B and A -->> C are MVDs.

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