I need help about a normalization issue.
Consider a relation R(ABC)
with the following functional dependencies:
AB --> C
AC --> B
How can i modify this to Boyce–Codd normal form ?
If i leave it like this, it's a relation with a key attribute transitionally-dependent of a key-candidate.
I tried splitting into several relations but that way i lose information.
A relational schema R is in Boyce–Codd normal form if and only if for
every one of its dependencies X → Y, at least one of the following
conditions hold:
X → Y is a trivial functional dependency (Y ⊆ X)
X is a superkey for schema R
From Wikipedia
R has two candidate keys, AB and AC. It's clear that the second rule above applies here. So R is in BCNF.
If i leave it like this, it's a relation with a key attribute
transitionally-dependent of a key-candidate. I tried splitting into
several relations but that way i lose information.
I'm not quite sure what you're getting at here, but I think the terminology in English includes
prime attribute (an attribute that's part of any candidate key)
transitively dependent (but that refers to non-prime attributes)
candidate key (not key-candidate)
This relation is in BCNF
The AC and AB are super keys and the attributes B and C depend upon the super keys and so they are in BCNF
and
There is no Transitive dependency in this relation
Hope,this helps
Related
I have R(A, B, C, D, E, F) with following functional dependencies:
{AB}->{D}
{D}->{C}
{AC}->{E}
{E}->{B}
{BC}->{F}
The relation has 4 candidate keys AB, AC, AD and AE.
According to Wikipedia:
A relation is in the second normal form if it fulfils the following two requirements:
It is in first normal form.
It does not have any non-prime attribute that is functionally dependent on any proper subset of any candidate key of the relation.
Thus the above relations should be in 2nd Normal Form, as F is the only non-prime attribute of the relation and it is not dependent on any proper subset of any candidate key.
But one of the answers https://stackoverflow.com/a/10114098/13861908, on stack overflow, says that
A table is in 2NF if and only if, it is in 1NF and every non-prime attribute of the table is either dependent on the whole of a candidate key, or on another non-prime attribute.
According to this definition, the relation is not in 2nd Normal Form, as {BC} is neither a super key nor contain any non-prime attribute.
Clearly, I am missing out something. Please help.
I know that for a Relation to be 3NF It has to be 2NF and no transitive dependencies should exist but I couldn't answer the following question:
For a relationship to be 3NF :
A) All Attributes should depend on the primary key.
B) The relationship should only have one Foreign Key.
C) The relationship should only have one Primary Key.
D) The Relationship's Table should only have atomic values
D applies on a 3NF relationship because it's one of the conditions of 1NF and for a relationship to be 3NF it has to be 2NF and 1NF.
C is too general and doesn't apply just on 3NF but my book has chosen it as the answer!
B is not related to Normalization and A may be considered as 2NF but they didn't say all non-attributes so I don't know actually, what is the right answer here?
By definition of "superkey", all attributes depend on a superkey. By definition of "CK" (candidate key) as a superkey containing no smaller superkey, all attributes depend on a CK. By definition of "PK" (primary key) as a distinguished CK, all attributes depend on a PK. So A is an answer.
FKs (foreign keys) are irrelevant to normalization. So B is not an answer.
By definition of "PK", a relation/schema can have at most one, which we pick from among the CKs. There can always be a PK, because there is always at least one CK. Whether you must pick a PK depends on your textbook--PKs per se have no role in normalization theory. Unfortunately "should only have one" is not clear, because it might mean exacly one & it might mean at most one. So if it agrees with your textbook, C is an answer; otherwise not. Go with your textbook.
Presentations that talk about "atomic" values require them in either the definition of "relation" or the definition of "1NF" & higher NFs. So for your textbook presumably D is an answer. But actually the notion of atomic values, although ubiquitous, is confused & also "1NF" has no single meaning. Go with your textbook.
(None of the options guarantee 3NF.)
PS Your characterization of 3NF is not correct. Only certain transitive FDs (functional dependencies) matter--3NF is when/iff 2NF & no non-CK attribute is transitively dependent on a CK. (If one's "is in 1NF" is just "is a relation" then one can drop the "2NF &".) And be sure you get the correct definition of "transitive FD"--for sets X & Y, X->Y is transitive when/iff there exists set S where X->S & S->Y & not S->X & not S=Y. Get correct definitions from a good textbook.
Suppose i have Two strong entity E1 and E2 connected by a 1 to many relationship R.
E1 <--------- R ---------- E2
How many table will be created when i will convert the above ER diagram into database ?
I know that when E2 will be in total participation answer will be 2. Since, E2's primary key will merge perfectly. I am not sure about above. I have seen multiple places and found different answer. I am looking for some solid argument with answer.
Answer can be 2 or 3. I want to know which is more correct.
Chen's original method mapped every entity relation and relationship relation to a separate table. This would produce 3 tables:
E1 (e1 PK)
E2 (e2 PK)
R (e2 PK, e1)
Full participation by either E1 or E2 can be handled by an FK constraint.
As you can see, E2 and R have the same determinant / PK. This allows us to combine the two relations into one table, using a nullable e1 column if E2 participates partially in the relationship, non-nullable if it participates fully. Full participation by E1 still requires an FK constraint:
E1 (e1 PK)
E2 (e2 PK, e1)
I want to know which is more correct.
Logically, the two solutions are pretty much equivalent.
Making 3 tables maintains the structure of the conceptual (ER) model, but produces more tables which increases complexity in one way. On the other hand, it avoids nulls which create their own complexity.
Making 2 tables reduces the number of tables but introduces nulls. In addition, we have to resort to different mechanisms (nullable columns vs FK constraints) to implement a single concept (full participation).
Other requirements can also affect the decision. If I have 50 optional attributes, I certainly don't want to deal with 50 distinct tables! However, if I wanted to create another relationship (R2) which only applies to values in E2 which are already participating in R, I could enforce that constraint in the first design using an FK constraint: R2 (e2) referencing R (e2). In the second design, I would need to use a trigger since I only want to allow references to e2 which have non-null e1 values.
There is no ultimately correct answer. Conceptual, logical and physical modeling address different concerns, and as-yet unknown requirements will affect your model and contradict your decisions. As in programming, try to keep things simple, refactor continuously and hope for the best.
I was following this tutorial for BCNF decomposition. The functional dependencies given are:
A->BCD
BC->AD
D->B
These are concerned with the relation R(A,B,C,D). The conditions for BCNF include:
The relation must be in 3NF and when X->Y, X must be a superkey
The given relation doesn't have a transitive FD but D->B is a partial FD--or is it that the three FDs represent 3 separate relations?
If they represent 3 separate relations, why is it that D is not a key and if they are all in the same relation then D->B is a partial functional dependency.
If we write the given set of FDs with singleton right-hand side, we have -
A->BA->CA->DBC->ABC->DD->B
We can see at once 2 transitive dependencies. We have A->D and D->B so we don't need A->B and also we have BC->A and A->D so we don't need BC->D. So now we have -
A->CA->DBC->AD->B
or
A->CDBC->AD->B
The keys here are A, BC and CD. Since each attribute of the relation R comes at least once in each of the keys, all the attributes in your relation R are prime attributes.
Note that if a relation has all prime attributes then it is already in 3NF.
Hence the given relation R is in 3NF. I hope you get why you are completely wrong here - "The given relation though doesn't have a transitive FD but D->B is a partial FD ". I just proved that the relation is in 3NF which is a higher normal form then 2NF and hence in turns proves that the relation is in 2NF and hence no partial dependency.
To be in BCNF, for each functional dependency X->Y, X should be a key. We see that the last functional dependency D->B violates this since D is not a key. Therefore to convert into BCNF we can break our relationship R into R1 and R2 as -
R1(A,C,D)
R2(B,D)
Question like this:
Consider the relation scheme ABCDEF satisfying the following functional dependencies:
BC --> ADEF
CD --> B
E --> D
BC is a key and designated as primary. Explain why the relation is in 3NF.
It seems not a 3NF to me, because E-->D is a transitive dependency, but the question asked like this it must to be a 3NF ? So how do I explain it's a 3NF?
BC is a key and designated as primary.
This isn't relevant.
What is relevant is that there are three candidate keys: BC, CD, and CE.
A relation is in 3NF if and only if
The relation is in 2NF, and
every non-prime attribute is non-transitively dependent on every candidate key.
A non-prime attribute is an attribute that is not part of any candidate key.
Prime attributes: B, C, D, E.
Non-prime attributes: A, F.
E->D is a transitive dependency
No, it's not. Both E and D are prime attributes. A transitive dependency must involve either A or F. The FD E->D is a problem, but it's not a problem for 3NF. It's a problem for BCNF.
I'll leave it to you to figure out whether the relation is in 2NF. (That's the other prerequisite to this relation being in 3NF.)