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?
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.
If you're dealing with a hierarchy of records, where most of the keys have ancestors, will you have to create a chain of all of the keys before you can retrieve a leaf?
Example (in Go):
rootKey = datastore.NewKey(ctx, "EntityType", "", id1, nil)
secondGenKey = datastore.NewKey(ctx, "EntityType", "", id2, rootKey)
thirdGenKey = datastore.NewKey(ctx, "EntityType", "", id3, rootKey)
How do you get the record described by thirdGenKey without having to declare the keys for all of the levels of the hierarchy above it?
In order to get an individual entity, its key must be globally unique - this is enforced through each entity key being unique within its entity group. The ancestor path forms an intrinsic part of the entity key for this reason.
So, the only way to get a single entity with strong consistency is to specify its ancestor path. This can be done either with a get-by-key or with an ancestor query.
If you don't know the full ancestor path, your only option is to query on a property of the entity, but bear in mind that:
this may not be unique within your application
you will be subject to eventual consistency.
To supplement tx802's answer:
If you want to load an entity by key, you need its key. If the key is such a key that has a parent, in order to form / create the key, you also need the parent key to be created prior. The parent key is part of the key, just like the numeric ID or the string name.
Looking from the implementation perspective: datastore.Key is a struct:
type Key struct {
kind string
stringID string
intID int64
parent *Key
appID string
namespace string
}
In order to construct a Key which has a parent, you must construct the parent key too, recursively. If you're finding it too verbose to always create the key hierarchy, you can create a helper function for it.
For the sake of simplicity, let's assume all keys use the same entity name, and we only use numeric IDs. It may look like this:
func createKey(ctx context.Context, entity string, ids ...int) (k *datastore.Key) {
for _, id := range ids {
k = datastore.NewKey(ctx, entity, "", id, k)
}
return
}
With this helper function, your example is reduced to this:
k2 := createKey(ctx, "EntityType", id1, id2)
k3 := createKey(ctx, "EntityType", id1, id3)
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.
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?