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?
Related
Let's say I have a Relation R := {id, name, emails}
Obviously id -> name is a functional dependency but is id -> emails also a Functional Dependency?
From what I understand id ->> email would be a multivalued dependency if you would turn the Relation into R := {id, name, email}.
But does this only apply after normalization and would it be functionally dependent before?
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.
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.
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.