this is a homework which I already did, I just need either confirmation if it is done correctly or hints how to solve it. Thanks.
This is the question:
The relation Vaccine is intended to record information about infants and their
vaccinations: when a particular infant had a particular vaccination; where the
vaccination took place; who administered the vaccine. The following gives the
relational heading:
Vaccine(VaccineCode, InfantId, Date, InfantName, InfantAddress,
MedicalCentreCode,MedicalCentreName, MedicalCentreAddress,NurseId,
NurseName)
Besides the functional dependencies with the primary key as their determinant,
Vaccine has the following non-trivial functional dependencies:
FD1:InfantId -> InfantName
FD2:InfantId -> InfantAddress
FD3:MedicalCentreCode -> MedicalCentreName
FD4:MedicalCentreCode -> MedicalCentreAddress
FD5:NurseId -> NurseName
Give this relation ship first in 2NF and then in 3NF.
My solution:
2NF:
Infant(InfantID, InfantName,InfantAddress)
Rest(VaccineCode, InfandID, Date, MedicalCentreCode, MedicalCentreName, MedicalCentreAddress, NurseId, NurseName)
Now Infant is in 2NF and also in 3NF but Rest relation isn't in 3NF.
3NF for all those relation will look like this (according to me ofcourse):
VaccinationDetails(VaccineCode, InfantID, Date ,MedicalCentreCode NurseId)
Infant(InfantID, InfantName, InfantAddress)
MedicalCentre(MedicalCentreCode, MedicalCentreName, MedicalCentreAddress)
Nurse(NurseId, NurseName)
Are my solutions 2NF and 3NF?
2NF requires that the relation a) be in 1NF, and b) have no partial key dependencies.
Projecting Infant (InfantID, InfantName,InfantAddress) from the original relation is correct. InfantName and InfantAddress are functionally dependent on InfantID; InfantID is part of the key {VaccineCode, InfantId, Date}.
Now Infant is in 2NF and also in 3NF but Rest relation isn't in 3NF.
That's right. 3NF requires a) the relation be in 2NF, and b) have no transitive dependencies. There's one transitive dependency from {VaccineCode, InfantId, Date} to MedicalCentreCode to {MedicalCentreName, MedicalCentreAddress}. So removing that transitive dependency by projection gives you
Infants {InfantID, InfantName,InfantAddress}
MedicalCentres {MedicalCentreCode, MedicalCentreName, MedicalCentreAddress}
Vaccinations {VaccineCode, InfantID, Date, MedicalCentreCode, NurseId, NurseName}
And there's another transitive dependency involving NurseID and NurseName. Projecting that one gives you
Infants {InfantID, InfantName,InfantAddress}
MedicalCentres {MedicalCentreCode, MedicalCentreName, MedicalCentreAddress}
Nurses {NurseID, NurseName}
Vaccinations {VaccineCode, InfantID, Date, MedicalCentreCode, NurseId}
Those four relations are all now in at least 3NF. (The first three are in 5NF.)
Going beyond your homework
But there's a small problem with this. As it stands now, you can enter the medical center code for "General Hospital", and the id number of a nurse who doesn't work there. You might think about how you'd express that dependency, and what the resulting relations might look like.
Related
I am struggling to work out what Normal Form this table would be in, as only functional dependencies are given:
{A,C} -> {B}
{E,C} -> {D}
{A,E} -> {F}
{D} -> {G}
{D} -> {H}
{F} -> {I}
The information given is that the primary key is {A,C,E}.
My working so far is that there are transitive dependencies so the table cannot be in 3NF. However all are fully functional dependencies so the table must be in 2NF.
The next part of the question asks for you to decompose it into 3NF, and this is what I have gotten, however am unsure if it is correct.
Table 1:
{A,E} -> {F}
Table 2:
{C,E} -> {D}
Table 3:
{A,C} -> {B}
Table 4:
{D} -> {G} AND
{D} -> {H}
Table 5:
{F} -> {I}
If someone could confirm if this is correct, or if not give some hints about where I have gone wrong, it would be greatly appreciated.
Thanks
Given the functional dependencies and the key specified, this means that the relation is composed by all the attributes present in the functional dependencies.
Since the (only) candidate key is {A,C,E}, and there are dependencies in which a non-prime attribute depends on part of a key (for instance {A,C} -> {B}), the relation is not in Second Normal Form.
For the 3NF, the five tables does not form a correct decomposition, since no relation contains the key. So, for the decomposition to preserve both data and dependencies, you should add the relation R(A, C, E) to the other tables. This is prescribed by the synthesis algorithm of the Third Normal Form.
I'm currently learning about functional dependencies and am struggling to get my head around the concept behind them.
Say I have the table:
Customer
|-----------|--------------|------------|------------------|------------------|
|Cust-ID | Cust-FName |Cust-LName |Cust-Email |Cust-Pw |
|-----------|--------------|------------|------------------|------------------|
|1 |John |Smith |jsmith#email.com |srt6564sdgjhy55y |
|2 |Adam |Borneo |adb#hotmail.com |45657ythjdfgqAfd |
-------------------------------------------------------------------------------
There are two candidate keys: cust-ID and cust-Email (only one email address may belong to one customer). Electing cust-ID as the P.K, would the only functional dependency be:
{Cust-ID} -> {Cust-FName, Cust-LName, Cust-Email, Cust-Pw} ?
Or, would I draw/represent both candidate keys:
{Cust-ID} -> {Cust-FName, Cust-LName, Cust-Email, Cust-Pw}
{Cust-Email} -> {Cust-ID, Cust-FName, Cust-LName, Cust-Pw} ?
Instincts tell me the former, but given this is a completely new topic I'd appreciate any help!
Functional dependency set is always a superset of [candidate] keys. In other words a key is a functional dependency with attribute list covering the whole relation. Therefore, both candidate keys that you listed are also functional dependencies.
Both
{Cust-ID} -> {Cust-FName, Cust-LName, Cust-Email, Cust-Pw}
{Cust-Email} -> {Cust-ID, Cust-FName, Cust-LName, Cust-Pw}
are functional dependencies in your case.
A functional dependency is a situation like this: whenever you have two rows which have the same value for column on the left hand-side of the arrow, then the values for columns on the right hand side of the arrow have to be equal. If you have two rows with the same Cust-ID then the name, email, and password columns have to be the same. If you have two rows with the same Cust-Email then (in your example) the name, email, and password columns have to be the same.
If your table in not in the third normal form, then it IS possible that you have functional dependency with a proper subset of the key on the left hand side. In fact, you define the candidate key and the normal forms (2NF, 3NF, BCNF) in terms of functional dependencies.
You can read more on functional dependencies on our company blog. It is the first part in a series of posts on data normalization.
how to tell if a relation state is an instance of the relation?
Given a relation schema VEHICLE (Vin#, Lic#, State, Model, Price, Reg_fee)
F (fd1, fd2, fd3, fd4, fd5, fd6)
fd1: (Lic#, State) -> Vin#;
fd2: Vin# -> Lic#;
fd3: State -> Reg_fee;
fd4: Vin# -> Model;
fd5: Vin# -> State;
fd6: Model -> Price
Given the relation state and functional dependencies, can you comment if the relation state is an instance of the relation schema?
Look at the sample data. If the sample data fulfills all the functional dependencies, then that state is an instance of the relation. If it doesn't, it's not.
In real-world database design, functional dependencies are expected to hold for all real data, not just for sample data. Model determines price in the sample data, but not in the real world.
I an reading through some examples of normalization, however I have come across one that I do not understand.
The website the example is located here: http://cisnet.baruch.cuny.edu/holowczak/classes/3400/normalization/#allinone
The part I do not understand is "Third Normal Form"
In my head I see the transitive dependencies in EMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone) as the following Name->->Office|Floor and Name->->Office|Phone
The author splits the table EMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone) into EMPLOYEE_OFFICE (Name, Office, Floor) and EMPLOYEE_PHONE (Office, Phone)
From my judgement in the beginning, I still see the transitive dependency in Name->->Office|Floor so I don't understand why it is in 3NF. Was I wrong to state that there is a transitive dependency in Name->->Office|Floor?
Reasoning for transitivity:
Here is my list of the functional dependencies
Name -> Office
Name -> Floor
Name -> Phone
Office -> Phone
Office -> Floor (Is this the incorrect one? and why?
Thank-you your help everyone!
5) you assume a naming sheme here ... offices 4xx have to be on floor 4 ... 5xx have to be on floor 5 ... if such a scheme exists, you can have your dependency ... as long as this is not part of the specification ... no. 5 is out of the game ...
1. Name -> Office
2. Name -> Floor
3. Name -> Phone
4. Office -> Phone
5. Office -> Floor (Is this the incorrect one? and why?
(1) You and the author and I agree that Name->Office.
(2) You and the author agree that Name->Floor. While that's true based solely on the sample data, it's also true that Office->Floor. I'd explore this kind of issue by asking this question: "If an office is empty, do I still know what floor that office is on?" (Yes)
Those things suggest there's a transitive dependency, Name->Office, and Office->Floor. So I would disagree with you and with the author on this one.
(3) You say Name->Phone. The author says Office->Phone. The author also says that "each office has exactly one phone number." So given one value for Office, I know one and only one value for Phone. And given one value for Name, I know one and only one value for Phone. I'd explore this issue by asking, "If I move to a different office, does my phone number follow me?" If it does, then Name->Phone. If it doesn't, then Office->Phone.
There isn't enough information here to answer that question, and I've worked in offices that worked each of those two ways, so real-world experience doesn't help us very much, either. I'd have to side with the author in this case, although I think it's not very well thought through for a normalization example.
(4) This is really just an extension of (3) above.
(5) See (2) above. This doesn't have anything to do with a naming scheme, and you don't need to assume that offices numbered 5xx are on the 5th floor. The only relevant question is this: Given one value for Office, is there one and only one value for Floor? (Yes) I might explore this issue by asking "Can one office be on more than one floor?" (In the real world, that's remotely possible. But the sample data doesn't support that possibility.)
Some additional FDs, based solely on the sample data.
Phone->Office
Phone->Floor
Office->Name
First of all,let me define 3NF clearly :-
A relation is in 3NF if following conditions are satisfied:-
1.)Relation is in 2NF
2.)No non prime attribute is transitively dependent on the primary key.
In other words,a relation is in 3NF is one of the following conditions is satisfied for every functional dependency X->Y:-
1.)X is superkey
2.)Y is a prime attribute
For Your Question,if the following FDs are present :-
Name -> Office
Name -> Floor
Name -> Phone
Office -> Phone
Then we cannot say anything about Office and Floor.You can verify this by applying and checking any of the Armstrong Inference Rules.When you apply these rules, you will find that you cannot infer anything about office and floor.
Hi everyone this is my first post here. I have a relation like this
Relation R = (CustomerNr, CustomerName, Date, Time, BarberName, Seat)
that could translate to this
R(A,B,C,D,E,F)
what are the dependencies?