Proper subset of candidate key along with non prime attribute determines non prime. Then is it partial dependency or in 2NF?
CAND KEY {AB} then BD-->C .
This is how you define a partial dependency: For example you have a relation R with columns A|B|C|D.
Based on the functional dependency defined by business AB is designated as primary key (candidate key) and B -> D FD exists.
In that case, even though AB is PK; but non key column D is uniquely identified by only B (part of the key composition) and not by the entire key composition AB.
So, D here is partially dependent on key column and thus hold a partial functional dependency which is against 2NF.
In your case, CK AB is not uniquely identifying all fields; C is partially dependent on B; moreover, C is dependent on non-key column D.
So, it has PFD (partial functional dependency) and surely not in 2NF.
Related
I read a statement that " If a relation is in 3NF and does not contain any overlapping candidate key then it is definitely in BCNF"
Suppose we consider a relation R(A,B,C,D) with following functional dependencies:-
AB --> CD
C --> A
Here only candidate key is AB and the resulting relation is in 3NF and not in BCNF because C is not a super key.
So the above statement doesn't hold true.
Where am I going wrong ?
Your relation has overlapping candidate keys. While it doesn't appear on the left-hand side of the given functional dependencies, we can derive the fact that BC is a candidate key.
Starting with C -> A, we can use Armstrong's Axiom of Augmentation to determine that CB -> AB, and since it's known that AB is a candidate key, that means all other attributes are determined.
All the examples of partial dependancy I have seen have only one attribute as a primary key.
A,B,C -> D,E,F
A,B-> D (composite PK)
Can i say "A,B->D" is a partial dependancy "A,B,C -> D,E,F" ?
As much as I can infer, you are asking whether the decomposition can involve the new table having a composite PK, for you have so far seen only single attribute key's examples.
Yes. The idea is that if you can uniquely determine one or more non-primary attribute(s), by a part (whether a single attribute or many) of the primary key, then you should create a separate table for that.
So, if A,B -> D, then create another table of {A, B, D} and remove duplication from the bigger table.
This link shows the single table broken to two after removing this redundancy, though it too uses a single attribute as the key. Still, you'd get the idea by looking at the table initially and after it was divided.
TL;DR Your title question is ill-formed re FDs, and your first sentence is ill-formed re FDs, and what you ask about saying is ill-formed re FDs. (Please rephrase your question to make sense re FDs by using terminology properly. Please make the connections between your sentences clear and explain your examples.)
We say that a FD (functional dependency) X -> Y holds or that Y is functionally dependent on X or that X functionally determines Y or that Y is functionally determined by X. We often leave the "functionally" out. We say that X -> Y is partial when some smaller/proper subset of X also determines Y. The terminology "partial" arises because Y is dependent on only part of X. A FD that is not partial is full. Notice that CKs (candidate keys) are not involved.
A,B,C -> D,E,F
A,B-> D (composite PK)
Normalization involves CKs. The only way that it involves PKs (primary keys) is that there is a tradition irrelevant to normalization to pick one CK to call "the PK". Of course, if there's only one CK then it's the only choice for PK and we can call it the PK.
I'll assume that A-F are the only attributes of some relation value or variable. If these two FDs (and those in their closure and no others) hold, then {A,B} is not a CK. {A,B,C} is the only CK.
Can i say "A,B->D" is a partial dependancy "A,B,C -> D,E,F" ?
It's never the case that an FD "is" a different FD. Maybe you mean "is a partial FD of". But it doesn't make sense to say that a FD "is a partial FD of" some FD. I don't know whether your "Can I can say" means "Is it true that" or "Does it make sense to say". But it doesn't make sense to say that. I don't know what you are trying to ask.
But here are some things that are true:
{A,B,C} -> {D,E,F} is not partial because no smaller/proper subset of {A,B,C} determines {D,E,F}. {A,B} -> {D} is not partial because no smaller/proper subset of {A,B} determines {D}. But {A,B,C} -> {D} is partial because smaller/proper subset {A,B} of {A,B,C} determines {D}.
A relation is in 2NF when no non-prime attribute is partially dependent on a CK. Ie when all non-prime attributes are fully functionally dependent on every CK. Since non-prime attribute {D} is partially dependent on CK {A,B,C}, this relation value or variable is not in 2NF.
In 2NF, can a partial dependency have a composite primary key?
This is also doesn't make sense. A partial FD doesn't "have" a PK or CK. I don't know what you are trying to ask. Maybe you mean "determinant" not "PK".
All the examples of partial dependancy I have seen have only one attribute as a primary key.
This also doesn't make sense since dependencies don't "have" PKs or CKs. Maybe you are trying to say, all the examples of partial FDs you have seen are in relations that have only one attribute as a CK. Maybe you are trying to say that all the examples of partial FDs you have seen have only one attribute as a determinant.
The only time that a partial FD can have a single-attribute determinant is when {} is its subset determinant. Ie if {J} -> Y is partial then {} -> Y. This is when the Y subrow value is the same in every tuple. So you have probably never thought about a partial dependency not having a composite determinant. (So you probably didn't mean "determinant" for "PK".)
(I also can't connect any these three quotes to each other or your examples.)
From the Database Management Systems book: given the relation SNLRWH (each letter denotes an attribute) and the following functional dependencies:
S->SNLRWH (S is the PK)
R->W
My attempt:
First, it is not 3NF: for the second FD, neither R contains W, nor R contains a key, nor W is part of a key.
Second, it is/not 2NF. If we examine the second FD, W is dependent on R, which in turn is not part of a key. STUCK.
2NF is violated if some proper subset of a candidate key appears as a determinant on the left hand side of one of your (non-trivial) dependencies. Ask yourself whether any of your determinants is a subset of a candidate key.
Usually 2NF is violated only when a relation has a composite key - a key with more than one attribute. It is technically possible for a relation with only simple keys (single attribute keys) to violate 2NF if the empty set (∅) happens to be a determinant. Such cases are fairly unusual and rarely thought worthy of consideration because they are so obviously "wrong". For completeness, here's a fun example of that special case. In the following relation Circumference and Diameter are both candidate keys. The dependency in violation of 2NF is ∅ -> Pi, the ratio of the circumference to the diameter.
2NF has to do with partial key dependencies. In order for a relation to fail the test for 2NF, the relation has to have at least one candidate key that has at least two columns.
Since your relation has only one candidate key, and that candidate key has only one column, you can't possibly have a partial key dependency. It passes the test for 2NF.
Accoring to Boyce-Codd Normal Form Definition,
Reln R with FDs F is in BCNF if, for all X -> A in F+
-A is subset of X (called a trivial FD), or
-X is a superkey for R.
“R is in BCNF if the only non-trivial FDs over R are key constraints.”
If R in BCNF, then every field of every tuple records information that
cannot be inferred using FDs alone.
What I dont understand is the above two statements about normal form,
Can someone give me an example?
Thanks!
Some Pre-requisite terms before I try to Explain:
• Non-key attribute: An attribute that is not part of any candidate key is known as non-key /non-prime attribute.
• Superkey: A set of attributes within a table whose values can be used to uniquely identify a tuple. A candidate key is a minimal set of attributes necessary to identify a tuple; this is also called a minimal superkey.
Now, BCNF is the advance version of 3NF, stricter than 3NF.
A table is in BCNF if every functional dependency X → Y, X is the super key of the table.
Consider a relation : R(A,B,C,D)
The dependencies are:
A->BCD
BC->AD
D->B
So, Candidate keys(or minimal super keys) are A and BC.
But in dependency: D->B, D is not a superkey.
Hence it violates BCNF form.
We can break this relation into R1 and R2 as:
R1(A,D,C) and R2(D,B) to get BCNF.
Is the relation from below correctly divided into relations in BCNF:
R(a,b,c,d,e) - a and b are primary keys and there are dependencies such as:
a → c
a → e
c → e
I split the above relations into:
AC(a,c)
CE(c,e)
AB(a,b,d)
Is it the case that a is a primary key and b is a primary key, or is it the case that {a,b} is the (composite) primary key? If the columns are separately primary keys, then you have a number of additional but not explicitly stated functional dependencies: a → bd and b → acde. If the columns {a,b} are a composite PK, then you have an additional functional dependency ab → cde. Either way, the AC and CE relations are fine, and the ABD relation is the other necessary one. The only issue is 'what are the candidate keys of ABD'? And the answer is 'either {a,b} as a composite PK, or a and b as two separate candidate keys'.
Are you sure about that primary key? Normally, determining all the candidate keys is part of these kinds of exercises.
An informal way of expressing what we know about candidate keys is that every attribute that's not on the right-hand side (RHS) of any functional dependency must be part of every candidate key.
Since I don't know how you determined that {ab} is a candidate key, I'd be inclined to say that, because {abd} is not on any RHS, {abd} must be part of every candidate key.
In short, your FDs say that {abd} is the primary key, not {ab}.
In order for your key and your decomposition to be right, you need to have the additional FD ab->d.