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.
Related
I'll make this brief. I have to normalize this table, but the NULL entries are throwing me off.
I know {EID --> Managing Since} is a functional dependency, because EID is unique and cannot point to two different values of the same attribute.
But is {Branch Name --> Managing Since} a dependency?
Seattle points to (05/01/2007), but also points to a NULL value.
Does this mean it cannot be a dependency, as it would not have been so if it pointed to another date instead of a NULL?
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.
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.
Preface: I don't have experience with rules engines, building rules, modeling rules, implementing data structures for rules, or whatnot. Therefore, I don't know what I'm doing or if what I attempted below is way off base.
I'm trying to figure out how to store and process the following hypothetical scenario. To simplify my problem, say that I have a type of game where a user purchases an object, where there could be 1000's of possible objects, and the objects must be purchased in a specified sequence and only in certain groups. For example, say I'm the user and I want to purchase object F. Before I can purchase object F, I must have previously purchased object A OR (B AND C). I cannot buy F and A at the same time, nor F and B,C. They must be in the sequence the rule specifies. A first, then F later. Or, B,C first, then F later. I'm not concerned right now with the span of time between purchases, or any other characteristics of the user, just that they are the correct sequence for now.
What is the best way to store this information for potentially thousands of objects that allows me to read in the rules for the object being purchased, and then check it against the user's previous purchase history?
I've attempted this, but I'm stuck at trying to implement the groupings such as A OR (B AND C). I would like to store the rules in a database where I have these tables:
Objects
(ID(int),Description(char))
ObjectPurchRules
(ObjectID(int),ReqirementObjectID(int),OperatorRule(char),Sequence(int))
But obviously as you process through the results, without the grouping, you get the wrong answer. I would like to avoid excessive string parsing if possible :). One object could have an unknown number of previous required purchases. SQL or psuedocode snippets for processing the rules would be appreciated. :)
It seems like your problem breaks down to testing whether a particular condition has been satisfied.
You will have compound conditions.
So given a table of items:
ID_Item Description
----------------------
1 A
2 B
3 C
4 F
and given a table of possible actions:
ID_Action VerbID ItemID ConditionID
----------------------------------------
1 BUY 4 1
We construct a table of conditions:
ID_Condition VerbA ObjectA_ID Boolean VerbB ObjectB_ID
---------------------------------------------------------------------
1 OWNS 1 OR MEETS_CONDITION 2
2 OWNS 2 AND OWNS 3
So OWNS means the id is a key to the Items table, and MEETS_CONDITION means that the id is a key to the Conditions table.
This isn't meant to restrict you. You can add other tables with quests or whatever, and add extra verbs to tell you where to look. Or, just put quests into your Items table when you complete them, and then interpret a completed quest as owning a particular badge. Then you can handle both items and quests with the same code.
This is a very complex problem that I'm not qualified to answer, but I've seen lots of references to. The fundamental problem is that for games, quests and items and "stats" for various objects can have non-relational dependencies. This thread may help you a lot.
You might want to pick up a couple books on the topic, and look into using LUA as a rules processor.
Personally I would do this in code, not in SQL. Each item should be its own class implementing an interface (i.e. IItem). IItem would have a method called OkToPurchase that would determine if it is OK to purchase that item. To do that, it would use one or more of a collection of rules (i.e. HasPreviouslyPurchased(x), CurrentlyOwns(x), etc.) that you can build.
The nice thing is that it is easy to extend this approach with new rules without breaking all the existing logic.
Here's some pseudocode:
bool OkToPurchase()
{
if( HasPreviouslyPurchased('x') && !CurrentlyOwns('y') )
return true;
else
return false;
}
bool HasPreviouslyPurchased( item )
{
return purchases.contains( item )
}
bool CurrentlyOwns( item )
{
return user.Items.contains( item )
}