I am having trouble identifying transitive dependencies. I understand the concept behind it but looking at them and pulling them out is where I have my problems.
So I know
A → B
It is not the case that B → A
B → C
Then A → C is a transitive dependency.
I can't seem to identify the transitive dependency in this scenario:
Patient ID (PK)
Insurance_Co_ID (PK)
Doctor_ID (PK)
Fname
P_Lname
P_Street
P_City
P_Zip
P_Phone
Ins_First_Contact
Ins_Second_Contact
Ins_Phone
Doc_Fname
Doc_Lname
Doc_Beeper
I understand how to make 1NF, 2NF, ect diagrams, identifying partial dependencies and determinant, just having trouble on this. My take on this after doing research is finding only one transitive dependency but even then I am not sure. (Doc_Fname) → (Doc_Lname) → (Doc_Beeper) so (Doc_Fname) → (Doc_Beeper) or (Doc_Fname, Doc_Lname) → (Doc_Beeper)?
Please help and thanks!
Your example looks incorrect. If you know DOC_FNAME do you absolutely know DOC_LNAME? What if two docs have the same DOC_FNAME?
As for 3NF, the insurance company fields look suspect to me. What is INS_SECOND_CONTACT? Does that imply that you need a FIRST_CONTACT before you have a SECOND_CONTACT? Looks like a prime candidate for normalization to me.
Related
I am having trouble understanding Coq/CIC head normal form. More specifically, I don't understand what is a head. The reference manual (8.5p1) says that
Any term can be written as:
But the above definition is in the negative sense: it requires t0 not to be an application, but didn't say what can t0 be. In fact, as far as I can remember, the only thing that can be written as t0 t1 t2 ... is an application of a function or constructor t0.
Can someone help spell out what exactly can be the head here?
Yes, t0 t1 ... tn is an application, but the manual is talking about the form of t0 standing by itself.
In the manual, t or ti for some i usually denotes a term, so t0 can be any term, that is not an application, e.g. a λ-abstraction, etc. -- see the list in sect. 4.1.2 of the manual and the sect. 1.2.1 on syntax.
Also, this Wikipedia page might be of some help.
I have this relation:
wiki(url,title,abstract,link,category_id,category,heading,heading_pos)
And the FD's are:
F = {
url → title, abstract
category_id → category
url, heading_pos → heading
}
I need to find the keys and decompose into a set of Boyce-Codd normalized relations. I have tried to read related and similar questions but I'm unable to understand the given answers. Hope someone will help me with this assignment
Assuming 'wiki' as relation R and its attributes url,title,..heading_pos to be A,B,...H respectively.
We have,
R = {A,B,C,D,E,F,G,H}
FD's = {A->BC, E->F, AH->G}
The key here is ADEH.
We can first convert the relation R to 3NF and then to BCNF.
To convert a relation R and a set of functional dependencies(FD's) into 3NF you can use Bernstein's Synthesis. To apply Bernstein's Synthesis -
First we make sure the given set of FD's is a minimal cover
Second we take each FD and make it its own sub-schema.
Third we try to combine those sub-schemas
For example in your case:
First we check whether the FD's is a minimal cover (singleton right-hand side , no extraneous left-hand side attribute, no redundant FD)
Singleton RHS: We write the FD's with singleton RHS. So now we have FD's as {A->B, A->C, E->F, AH->G}
No extraneous LHS attribute: We remove the extraneous LHS attribute if any. There are no extraneous LHS attributes here.
No redundant FD's: We remove the redundant dependencies if any. There are no redundant dependencies here.
Second we make each FD its own sub-schema. So now we have - (the keys for each relation are in bold)
R1={A,B}
R2={A,C}
R3={E,F}
R4={A,H,G}
Third we combine all sub-schemas with the same LHS. So now we have -
S1 = {A,B,C}
S2 = {E,F}
S3 = {A,H,G}
Since none of the above decomposed relations contain contain a key of R, we need to create an additional relation schema that contains attributes that form of a key of R. This is to ensure lossless join decomposition that preserves dependencies. So we add -
S4 = {A,D,E,H}
This is in 3NF. Now to check for BCNF we check if any of these relations (S1,S2,S3,S4) violate the conditions of BCNF (i.e. for every functional dependency X->Y the left hand side (X) has to be a superkey) . In this case none of these violate BCNF and hence it is also decomposed to BCNF.
Note - The importance of some of these steps may not be clear in this example. Have a look at other examples here and here.
In a relation schema, if:
an attribute appears only on the left side then it is prime.
an attribute appears only on the right side then it is non-prime.
But what happens when there are attributes in the middle? Are they prime if they are a subset of the key?
Start from scratch with what you think a prime attribute is, because your definition is incomplete.
For an attribute to be prime, is has to be part of a candidate key. Now, in your case, it happens that A is prime and the rest are not (Since the only candidate key is A). But take this scenario: F={ {A->C}, {B->C}, {C->D}, {D->AB} }. In this case, there are two candidate keys: AB, and D.
This means that A, B, and D are all prime, since they are all parts of candidate keys, and C is not.
Could you give an example? I think I know what your confusion is, but I need more context to answer properly. I can think of 3 things you are referring to:
1) If you mean something like:
AB -> CD
and you think A is prime and D is non-prime, that's not what "left" and "right" means. Everything on the left of the arrow is prime, and everything to the right of it is non-prime.
2) Further, your point 1 is incorrect. An attribute only has to appear left once to be prime. BUT!!!!!! It also depends left or right of what. Are you talking about dependencies of candidate keys only, or all dependencies? To finish my answer I need to have a bit more context.
I have the following facts in dlv, knows (X,Y) means X knows Y.
knows(adam, dan).
knows(adam,alice).
knows(adam,peter).
knows(adam,eva).
knows(dan, adam).
knows(dan,alice).
knows(dan,peter).
knows(eva, alice).
knows(eva,peter).
knows(alice, peter).
knows(peter, alice).
I have defined the following predicates,
person(X) :- knows(X, _).
This will give all the persons from the facts. I am trying to find a predicate popular(X). that will give the popular person. It is defined such that if all persons knows X then X is popular. The answer for the above list of facts is alice and peter. I defined it as below,
popular(X):-person(X),knows(_,X).
X is popular if its a person and everyone knows X. But I am getting all persons as the result when I run it. Where am I making a mistake?
As per the comment string on the original post, you have defined popular to be "a person that is known by someone". Since - in your knowledge base - everyone is known by someone, everyone is popular.
Assuming "a popular person is one whom everyone knows but the popular person knows only other popular persons"; if we want to know if X is popular:
We either need to count all the people that know X and then compare that to the number of people;
Or we need to verify that it is never the case that someone doesn't know X.
I'll focus on the second way to do this, using forall. Take sometime and run some tests on your own to understand how that works. Here's an example of what you might do:
popular(X): - person(X),
forall(
( person(Y),
X \= Y
),
knows(Y,X)
).
If you run this, you get Alice and Peter as answers.
But if we include the other condition:
popular(X): - person(X),
forall(
( person(Y),
X \= Y
),
knows(Y,X)
),
forall(
knows(X,Z),
popular(Z)
).
That last line says X needs to know people that are popular exclusively... and now, if you run this, you're most likely going to get a 'out of local stack' - it's a bottomless recursive definition.
You always need to check if someone is popular to know if someone is popular to know if someone is popular... Try to think about the problem and why that is. Is there a way to check if someone is popular without needing to check if someone else is popular? What if someone 'knows' themselves? What if two people know each other? This might take a slightly more complex approach to solve.
By the way, notice that your definition of person returns multiple people - everyone is a person for every person they know. Besides making every check take a lot longer (since there are more 'people' to check), this might be a problem if you decide to go with the firs approach (the counting one).
Wouldn't it make sense to define explicitly who are the people and then define 'knowing' as a relation between people?
person('Alice').
person('Bob').
knows('Alice','Bob').
As said in lurker's comment (with slight modification and emphasis by me), the reason you get all persons as a result is
You have defined person as: X is a person if X knows someone. And you've defined popular as: X is popular if X is a person and someone knows X.
But you wanted to define: X is popular if X is a person and everyone knows X.
The following is an ASP solution for clingo 4. DLV might have slight differences in syntax.
% Project
person(P) :- knows(P, _).
% Separate helper predicate knows2/2.
% Not needed if polluting knows/2 with knows(X, X) is OK.
knows2(O, P) :- knows(O, P).
knows2(P, P) :- person(P).
% Everybody knows a popular person.
% When there is a person O that doesn't know P, #false is active.
% I.e. all rule instantiations where some O doesn't know P are discarded.
popular(P) :- person(P), #false : person(O), not knows2(O, P).
% Popular person knows only other popular persons.
% Redundant at this point, since the above rule already results
% in correct answer without further integrity constraints.
:- person(P), person(O), popular(P), not popular(O), knows(P, O).
#show popular/1.
consider a relation R = {P, Q, R, S, T} and the functional dependency F = {P -> Q, {Q, R} -> S, S -> {Q, R}, {S, T} -> phi}. Are there any redundant functional dependencies in F? If so, remove them and decompose the relation R to 3NF relation.
Plz answer this
{S,T}->phi is trivial, and hence redundant. Moreover, there are no redundant attributes so you have your canonical cover here.
To decompose to 3NF you should:
1) create table for each dependency in the canonical cover
2) identify a candidate key
3) if the candidate key is not included in any of the tables so far, add it as an additional table
4) remove tables if all their attributes are included in another table