Criteria for considering redundant relationships in entity - relationship diagram? - database

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?

Related

Can A and B be functionaly dependent on each other?

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.

Finding the Primary Key and Normalising a Relation with Functional Dependencies

I am studying for my databases exam and I've realized my professor did not teach a section of the normalization lecture notes, but glossed over them so I've been self studying and there is this example without solutions in the notes and I was wondering if I have been doing it right:
Given Relation R = {A,B,C,D,E,F,G,H,I,J}
And functional dependencies:
A,B -> C
A -> D,E
B -> F
F -> G,H
D -> I,J
Determine the primary key
Decompose R so it is in 2NF then show it in 3NF.
So, I got the primary key to be (A, B, D, F)
And then I tried to convert it to 2NF and I got relations:
(ABC), (DIJ), (ADE), (BF), (FGH)
And I honestly have no idea if this is right or how to then put it in 3NF... or if I've just skipped 2NF and already put it in 3NF. Any help?
It appears to me that you have skipped the NF2 and normalised the relation straight into the 3NF :)
The primary key for the original relation should be (A,B) as by inference rules (transitivity, such as A->D,E and D->I,J therefore A->I,J) it determines all other attributes. From this point onwards we have that:
FD1: A,B -> C
FD2: A -> D,E (Partial)
FD3: B -> F (Partial)
FD4: F -> G,H
FD5: D -> I,J
2NF (No partial dependencies allowed)
Now we can decompose the relation in three relations moving partial FDs to separate relations but preserving other FDs which might depend on those partial FDs, such as FD2 and FD5. This would give us the following results:
R1(A,D,E,I,J) -- FD2, FD5 (transitive)
R2(B,F,G,H) -- FD3 FD4 (transitive)
R3(A,B,C) -- FD1
Next, to achieve 3NF, transitive dependencies would have to be removed into separate relations in the same manner as NF2. Which, in turn, would result in the set of relations which you have already derived.
Good luck with your exams!

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.

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.

Removing Anomalies from tables

I have this table and I am supposed to re-design it to remove all anomalies from it. I will not give the table but the dependencies.
The functional dependencies are
(Product, Store) -> Dept
Store -> Manager
Dept-> Assist
(Product, Store)->Price
Product-> Weight
Product-> Manufact
Manufact-> Manuloc
Product and Store are the keys in this relation
Ok so I have to remove the anomalies by breaking up the table and creating new ones and state what will be in each table. I am unsure how to do that.
Apply Armstrong's axioms and the rules derived from them. (I'm sure this is in your textbook. Check the index.) For example, given these two functional dependencies (FDs):
(Product, Store) -> Dept
Dept -> Assist
you can apply the transitivity rule to determine an unstated FD:
(Product, Store) -> Assist
From the FDs you're given, derive an irreducible set of FDs; this set determines your tables.
This example is from Date's Introduction to Database Systems. (He gives a more complete treatment of it.) Given
A -> BC
B -> C
A -> B
AB -> C
AC -> D
rewrite for right-hand singletons using Armstrong's axioms:
A -> B
A -> C
B -> C
A -> B
AB -> C
AC -> D
The FD A -> B occurs twice; we can discard one without losing information. We can reduce AC -> D to A -> D, and we can eliminate AB -> C. And we can eliminate A -> C, leaving
A -> B
B -> C
A -> D
From this irreducible set of FDs, you'd derive the two tables
A -> BD
B -> C

Resources