If B is functionally dependent on A (A -> B) can A be functionally dependent on B (B -> A)? Why?
Example:
A table contains five columns: Patient Number, Full name, Bed number, Ward number and Ward name.
Is it possible to say that Ward Number -> Ward Name and Ward Name -> Ward Number?
From my understanding a functional dependency A -> B means that given a tuple containing A there will always be the same B, but not the other way around.
A Ward will always have the same number and name making the functional dependency go both ways.
If B is functionally dependent on A (A -> B) can A be functionally dependent on B (B -> A)?
Yes. Informally, it might help you to think about it this way.
Say a relation has two candidate keys, A and B. Since A is a candidate key, it determines all the other attributes. So A->B. And since B is a candidate key, it also determines all the other attributes. So B -> A.
For a real-world example, think about a table of chemical elements. (WARNING: I'm not a chemist.)
element_name atomic_number chem_symbol
--
Hydrogen 1 H
Helium 2 He
Lithium 3 Li
...
Each of these three columns is a candidate key. And element_name determines atomic_number and chem_symbol, atomic_number determines element_name, and chem_symbol, etc.
Related
I am having problems understanding what criteria are used to determine relationship redundancy for a "circle" of relationships between 3 entities in the entity - relationship model.
I was starting with the following example: Course - department - teacher relationships.
Course - department - teacher relationships first example
My criteria to declare a relationship (A -> C) as non redundant (can NOT be inferred from A -> B -> C) is either:
A -> B has minimum cardinality 0 (ie. 1 element of A can be associated with 0 elements of B), since then, B can't be determined (and therefore C can't be determined).
OR
If A -> B and B -> C have a maximum cardinality of N (ie. 1 element of A can be associated with N elements of B and 1 element of B can be associated with N elements of C simultaneously). My assumption for this is that knowing the elements of B associated with A and knowing the elements of C associated with B can't be used to know one specific A -> C.
I consider the above "both ways": A -> B -> C and C -> B -> A. If going any way I get any of the above, I consider the relationship is NOT redundant since A -> C can't be inferred from A -> B -> C.
I am assuming this, regardless of the cardinality between the candidate redundant relationship A -> C.
Given my assumptions, I consider the example [Course (C) - department (D) - teacher (T)]. I deduce that the only relationship which is redundant is between course and teacher since:
T -> C:
T -> (1,1) D -> (1,n) C [Cardinality shown in parenthesis]. Which allows to deduce T -> C from T -> D -> C.
C -> T:
C -> (1,1) D -> (1,n) T. Which allows to deduce C -> T from C -> D -> T.
However, in the example given, the redundant relationship is Teacher and Department. The reasoning is that if the courses a teacher teaches are known and the department to which each course belongs is also known, it can be deduced to what department belongs each teacher. Also, given a department, if we know its courses, and we know the teachers who teach the courses we will know the teachers associated with department.
With my criteria, I don't see how this is the case, since:
D -> T:
D -> (1,n) C -> T (1,n). This complies with point 2) above and therefore D -> T can't be deduced from D -> C -> T.
There is also another example with the same relationships but different cardinality (shown in red), this is where I got my criteria from:
Course - department - teacher relationships second example
In this case, it is specified that there are no redundant relationships, for the following reasons:
T - D:
If we know the courses taught by a teacher, and the departments to which the courses are assigned, Do we know which department the professor belongs to? NO, since the course can be assigned to several departments.
This is where I deduced my criteria:
T -> D:
T -> (0,n) C -> (1,n) D. We have two 1->N relationships, therefore it is non-redundant.
Also it says: what if a course was only attached to a Department? Still, a teacher may not teach any courses, then we couldn't know his/her department. Which is my other criteria:
T -> (0,n) C [minimum cardinality of 0, we can't know C in some cases, and therefore, we can't know D.
It also adds: given a department, if we know its courses, and we know the teachers who teach the courses, we will know the professors associated with the department.
T - C:
A course can be assigned to several departments, and these may have several teachers, then you can not know the teacher concrete that the course teaches. Ie. We have two 1-N relationships:
C -> (1,n) D -> (1,n) T. Therefore, it is non-redundant.
C - D:
Given a course taught by a teacher, and he/she belonging to a department, we cannot know what other departments have associated the
course.
I am assuming:
D -> (1,n) P -> (0,n) C. We have two 1-N relationships therefore, it is non-redundant.
Finally I have a third example with Author (A), Editorial (E) and Book (B) as follows:
Author, Editorial, book example
I am told that the redundant relationship is Author - Editorial. However, I am finding no redundant relationships as per my criteria since they have two 1:N relationships:
E -> A:
E -> (1,n) B -> (1,n) A
B -> E:
B -> (1,n) A -> (1,n) E
A -> B:
A -> (1,n) E -> (1,n) B.
Thank you for taking the time to read until here. Are my criteria wrong? If so, what criteria should I use to consider a relationship redundant?
I have a relation R(a,b,c,d) where (a,b) is a primary key so I have the determinant a,b -> c,d.
In addition to that I have the following determinants: a,c -> b,d and a,d -> b.
Let's be ok that this relation is in 3NF.
I'm wondering if it's in BCNF or not. I was using a definition for the BCNF that recognize:
a relation is in BCNF if it's in 3NF and there's no determinant X -> Y such as X is non-key attributes and Y is a part (or the totality) of the key
which is not applicable in my case for the determinant a,d -> b for example. Another definition is that
A relation, R, is in BCNF iff for every nontrivial FD (X->A) satisfied
by R the following condition is true:
(a) X is a superkey for R
which left me undecided insofar as in a,d->b it's clear that (a,d) is not a superkey (nor a key), but we have (a,d) clearly a key to the relation R!
So, my question is:
Is the relation R in BCNF or not, and why?
And what's the right process to determine whether a relation is or isn't in BCNF?
About terminology
You say:
I have the determinant a,b -> c,d
This is wrong therminology. a,b -> c,d is a functional dependency (sometimes abbreviated with FD), which has a determinant a,b (sometimes called left hand side (LHS) of the FD) and a determinate c,d (sometimes called right hand side, RHS, of the FD). This terminology is used since the values of the attributes a,b uniquely determinate the values of the attributes c,d.
About the key
The information that:
(a,b) is a primary key
can be irrelevant when normalizing a relation when you have enough information about the functional dependencies. From those dependencies you can calcolate which are the candidate keys: set of attributes that uniquely determines all the attributes of the relation and such that you cannot remove any attribute from them maintaining this property (in other words, minimal sets of attributes that uniquely determines all the attributes of the relation). The information about the primary key can be relevant when you have only partial information about the functional dependencies that hold in a relation, but in your case the information about all the (candidate) keys can be derived from the functional dependencies.
In your example, for instance, there are three candidate keys:
1. a, b
2. a, c
3. a, d
You can verify this fact by computing the closure of the attributes of a candidate key to see if it contains all the attributes. For instance, let's try to calculate the closure of a,d (called a,d *):
1. a,d * = a,d
2. a,d * = a,d,b (since a, d -> b)
3. a,d * = a,d,b,c (since a, b -> c, d)
So a,d is a candidate key (which is also a superkey, i.e. a set of attributes that determines all the attributes of the relation).
About the BCNF
There are different definitions of BCNF. Using for instance the second one that you cited, all the three dependencies have a determinant which is a candidate key (and so a superkey), and so the relation is in BCNF.
Example:
Let R = (A, B, C, D)
Let F = {C -> AD, AB -> C}
Then how can I find the candidate keys?
The answer is {AB, BC}
Why?
Given a relation schema R with a set of attributes T and a non-empty set of non-trivial functional dependencies F describing a certain set of constraints that are assumed to hold in that schema:
Every attribute that does not appear in the right part of a FD in F must be present in any candidate key.
Every attribute that does not appear in the left part of a FD in F cannot be present in any candidate key.
To find all the candidate keys, for all the other attributes, you should try to add to the attributes of 1 above every possible combination of them, and see if the closure determines all the attributes of the relation (and such that you cannot remove any attribute from the combination without losing this property).
Note that, if the set F is empty, the only candidate key is constituted by all the attributes T.
In practice there are algorithms that can be relatively efficient (since the problem of finding all the keys is in the general case exponential).
A simple approach is to start from a canonical cover of the functional dependencies, in this case for instance from:
{ A B → C
C → A
C → D }
and after finding the attributes that must be present in any candidate key (in this case B), try to add to them the left hand side of the dependencies (in this case both AB, that is A, and C) (in any order, and possibly combining them) and compute the closure to see if they determine all the attributes. When you discover that some set of attributes determines all the relation attributes, you have found a candidate key (and it is not necessary to add other attributes to it). In your example:
(A B)+ = A B C D
(B C)+ = A B C D
So A B and B C are candidate keys (since you cannot remove any attribute to both of them without losing the property of determining all the other attributes). And since there are no other attributes (a part from D that cannot be present in a candidate key), you know that you have found all the candidate keys.
I have a question regarding functional dependencies.
I understand that functional dependency means that the value of an attribute can be determined by the value of another attribute.
Suppose we have this table
|A|B|C|D|
Here A and B are the primary keys.
Is it correct to say that both C and D are functionally dependent on both A and B ?
You are saying “A and B are the primary keys” but this phrase is ambiguous: you mean: “The primary key is A B” or “the are two candidate keys, A and B”? (and note that in a relation in a relational database you can have only a single primary key and many candidate keys).
Given the definition of a (candidate) key, that is that it determines all the other attributes and that you cannot remove any attribute without losing this property, in the first case you can say that:
A B -> C D
or, which is equivalent, that:
A B -> C
A B -> D
(so C e D depends on the combination of A and B), while in the second case, you have that:
A -> C D
B -> C D
or, which is equivalent, that:
A -> C
A -> D
B -> C
B -> D
(that is, C and D are functionally dependent both on A and on B).
"S (functionally) determines T" means that all appearances of a particular subtuple value for attribute set S have the same subtuple value for attribute set T. If we say an attribute X is determining or determined then it's understood that we really mean that set {X} is determining/determined.
A superkey is a set of attributes that determines every attribute. A CK (candidate key) is a superkey that contains no smaller superkey. There can be many CKs. One CK can be chosen as PK (primary key). (PKs play no role in relational theory.)
Since there can only be one PK, it's odd that you talk about a relation value or variable having more than one. Maybe you mean two CKs. Maybe you mean a 2-attribute PK.
It happens that if every subtuple value for a set of attributes appears just once then it is a superkey. (Each single-attribute superkey is a CK unless {} is the CK, which happens when the relation is limited to one tuple.) So it determines all attributes. But in general the dependencies tell us what the superkeys & CKs are.
So if each of A and B are CKs then each determines C and D, ie {C} and {D}. And if {A,B} is a PK then it determines C and D, ie {C} and {D}. It happens that if both T1 and T2 are determined by S then T1 U T2 is too. So either way, the CK(s) here determine(s) {C,D} also.
PS There is an ambiguity in English where it is not clear whether "both C and D are functionally dependent" means that C is dependent and D is dependent or that {C,D} is dependent. Similarly for "are functionally dependent on both A and B". So it is clearer to say "the set ..." rather than just using "both" and/or "and".
I am having a hard time understanding the 3 Normal form.
3 NF: 2 NF + No transitions
So, for eg: If I have,
A -> B
B -> C
Then the above is sort of a transition relation and hence won't be in 3 NF?
Am I understanding it correctly?
But in this answer What exactly does database normalization do? , by paxdiablo, it says,
Third normal form (3NF) - 2NF and every non-key column in a table depends on nothing but the key.According to this, it will be in 3 NF. Where am I going wrong?
A relation is in 3NF if it is in 2NF and:
either each attribute depends on a key,
or, if an attribute depends on a non-key, then it is prime.
(being prime means that it belongs to a key).
See for instance Wikipedia.
A relation is in Boyce-Codd normal form if only the first condition hold, that is:
each attribute depends on a key
So, in your example, if the relation has only three attributes A, B and C and the two dependencies, it is not in 3NF, since C is not prime, and depends on B, which is a not a key. On the other hand, if there are other attributes, and C is a key or part of a key, then it could be in 3NF (but this depends on the other functional dependencies, that should satisfy the above conditions).
The 2NF says that each non-prime attribute depends on each whole candidate key, and not by part of it. For instance, if a relation has attributes A, B and C, the only key is AB, and B -> C, then this relation is not in 2NF.
The 2-part 3nf definition you are trying for is:
2NF holds and every non-prime attribute of R is non-transitively dependent on every superkey. (X transitively determines Z when there's a Y where X → Y and Y → Z and not Y → X.)
The other definition of 3NF is:
For every non-trivial FD X → Y, either X is a superkey or the attributes in Y but not in X are prime. (X → Y is trivial when X contains Y.)
Then BCNF is:
For every non-trivial FD X → Y, X is a superkey
See this answer.
If your example's only columns are A, B and C and your two FDs form a minimal cover then the only candidate key is A and C is dependent on a non-superkey so it is not in 3NF (or BCNF).
You are (mis)using terms so sloppily that your sentences don't mean anything. Learn the terms and how they are used in their definitions to refer to various things and use them that way in reference to appropriate things. And get your definitions from a (reputable) textbook.