Is it possible for a functional dependency to violate 1NF? for example
R={A,B,C,D,E} F=Any FD that violates 1NF
What kind of functional dependency will violate 1NF? I understand examples of function dependencies violating 2NF, 3NF and BCNF but I've never seen an example of an FD violating 1NF. Is this even possible?
Unlike other normal forms, 1NF is concerned with structure rather than functional dependencies. So the simple answer to your question is no.
However, there is an element of controversy about whether 1NF excludes the possibility of relation-valued attributes (RVAs). If you take the view (as many people do) that RVAs are prohibited by 1NF then any functional dependency based on a relation-valued attribute cannot be satisfied by a 1NF relation. By that interpretation of the rule such FDs would be forbidden by 1NF. It would be stretching the meaning of words to say that the FD itself was a violation of 1NF, but it would be true to say that a relation satisfying such an FD would be a violation.
Alternatively, you can take the view that if it is of any value at all then 1NF ought to mean nothing more or less than the requirement that data is always represented as relations. Under that interpretation there is no strong reason to exclude the possibility of RVAs and - given that their exclusion might exclude some potentially important FDs - there is good reason to permit them. That is my view, although it is possibly a minority view even among those who have considered the issue. If you agree then the answer to your question is unequivocally no.
Related
we are in 1NF if we don't have a non-atomic domains in our relation.
we are in BCNF if we don't have a functional dependency on the left hand side that is not a superkey.
as far as i know BCNF definition isn't concerned whether a relation has a non-atomic domains or not.
so i assume that not all BCNF schemes are in 1NF, and not all 1NF schemes are in BCNF.
i ask that question because i saw the following picture.
from the picture it looks like BCNF is subset of 3NF which is subset of 2NF which is subset of 1NF.
therefore it's the most restrictive.
so from that picture i kinda assume that BCNF schemes cannot have a non-atomic values.
but from where i read it, the definition never mentioned something about atomicity in BCNF.
1NF is not considered a normal form as the others, since nowadays it is considered implicit to the relational data model. In other worlds, if a table is not in 1NF, it is not a relation, while all the “other” normal forms are defined only for relations. So, obviously, any normal form from the second one, implicitly implies the so-called First Normal Form.
What's the main point of Normalization?
I mean if a normal form is not in 2NF, it is because of partial dependency i.e. a non key attribute is dependent on a part of a candidate key.
So, let's say, for a relation R(A,B,C) with FDs:
AB->C, B->C
Clearly, AB is the candidate key and B->C is the partial dependency.
Solution: Decompose the relation such that (B,C) forms a new relation with B as the key.
Now, if a relation is not in 3NF, it is because a non key attribute is dependent on another non key attribute i.e. to say
if FDs for a relation R(A,B,C) are:
A->B,B->C
Clearly, A is the key and B->C shows transitive dependency, so not in 3NF.
Solution: Decompose the relation such that (B,C) forms a new relation with B as the key.
So, what's the exact difference?
I mean, why such a marked distinction? Essentially in both of the cases the action is same.
Decompose the relation using the dependency where the determinant (B here) is either PART of a key or not.
Why have separate terms like partial dependency or transitive dependency?
Why not just see, if there exists a dependency wherein a non prime attribute is determined by a something which is NOT a candidate key( no matter whether it is a partial key or another non prime attribute )
Why can't we implement a method like this:
1 NF -- having all elements in the atomic form
X NF -- if there's any
dependency of the form non_key -> non_prime_attribute(s) ,
decompose the relation with one of the new relation having this
particular "non_key" as the key with those non_prime_attributes.
BCNF
: Where for all the dependencies of the form X->Y, X is a superkey?
Can we have such NF condition format? Does it combine all the conditions?
So, what's the exact difference?
2NF is not 3NF & definitions of 2NF are not definitions of 3NF. There isn't any particular semantic or syntactic structural similarity that would leave some kind of "difference" other than that a 2NF relation can have the sort of problem FD (functional dependency) that violates 3NF that a 3NF relation doesn't have. You can find definitions all over the place. You almost give them correctly here yourself. But a NF (normal form) is a condition, not a process. What do you mean "actions are the same"? Being in 3NF implies being in 2NF, so naturally decomposing to 3NF also gives 2NF. But there are relations that are in 2NF but not in 3NF, and there may be decompositions for a relation to 2NF that don't get to 3NF. Those decompositions will involve in a removal of all problem partial FDs that does not result in the removal of all problem transitive FDs.
(Because 3NF is always achievable and there are no other disadvantages compared to 2NF, 2NF isn't even useful. It's just a condition that was discovered first that is not as strong as 3NF.)
(3NF is frequently defined in terms of 2NF plus no transitive dependencies of non-prime attributes on CKs, but actually no such FDs implies no partial FDs of non-prime attributes on CKs, hence 2NF, so the first condition is redundant.)
Why not just see, if there exists a dependency wherein a non prime attribute is determined by a something which is NOT a candidate key
Why should that condition be helpful? It is not a description of just getting rid of the problem FDs of 2NF & 3NF--that's what putting into 3NF does.
Getting rid of non-trivial FDs that are not determined by superkeys happens to give BCNF. It implies 2NF & 3NF. But it is different from both of them. A BCNF relation exhibits no FD-based update anomalies. It is always achievable. However 3NF is alway achievable while "preserving FDs", whereas BCNF is not. There are cases where in order for a FD that held in the original to be enforced in a view/query that gives it via constraints on its components we need an EQD (equality dependency) constraint. That says two column sets have the same set of subrow values, which is more expensive to enforce than a FD. Either you have BCNF & an EQD & fewer update anomalies or you have 3NF/EKNF & a FD & certain update anomalies.
The NF that really matters is 5NF, which implies BCNF, with no update anomalies & with other benefits. (We might then decide to denormalize for performance reasons.)
PS Normalization to a given NF does not necessarily involve normalization to lower NFs.
It almost sounds as though you want to know why they called these two normal forms by different names instead of inventing just one form that covers both cases. If that's not the case, please ignore this answer.
Part of the answer is that the forms weren't discovered at the same time. And part of the answer is that the problem with 1NF that gave rise to 2NF is not the same as the problem with 2NF that gave rise to 3NF, even though they both exhibit harmful redundancy.
What might satisfy you a little more is BCNF. BCNF was actually discovered later than 4NF, so that name was already in use. But BCNF has to be placed between 3NF and 4NF, because it is more restrictive than 3NF but less restrictive than 4NF. So it was discovered "out of sequence", so to speak.
In BCNF, every (non trivial) determinant is a candidate key. That seems to be what you are looking for. I conjecture that any relation that is in 1NF and where every determinant is a candidate key, could be shown to be in 2NF and 3NF. But the proof is beyond me.
2NF and 3NF are essentially historical concepts and your question is a reasonable one. There is no real reason to apply them in practical database design because better tools exist today.
When it comes to teaching there is possibly some justification for mentioning 2NF and 3NF. Doing so allows students to explore the concepts involved (as you have done) while also teaching them a bit about the origins and rationale of design theory. In school maths lessons I was taught long division and differentiation from first principles. No one uses those techniques in practice, they are just teaching aids.
Before checking for 2NF the relation should be in 1NF. In simple words 2NF have only full dependencies only, no partial dependencies in relation. Full dependency means if x gives y, then by removal of any element in x, then y is not having any relation. If by removal of x, you are having relation with y then it is partial dependency. For 3NF we have to check for the 2NF, in 3NF we should not have any transitive relations like if x gives z, then there is no relation like x gives y and y gives z.
Solution for 2NF create a table for the partial dependcies and add foreign key in new relation which is primary key on the previous relation.
Solution for 3NF create a relation for both x gives y and y gives z. Add keys to relations.
When is BCNF not able to preserve functional dependencies?
When is a 3NF decomposition desired instead of a BCNF decomposition preserving functional dependencies?
Please explain with an example.
I saw this question but it does not answer my question:
Decomposition that does not preserve functional dependency
When is BCNF not able to preserve functional dependencies?
Turns out this question is problematic in a certain way that "ok you defined 'prime number' but when is a number prime?" is, but "ok you defined 'simplest form of a fraction' but when is a fraction in simplest form?" isn't. Definition(s) say "when". But what you mean is something like, multiple conditions apply so what more simple/intuitive definition or non-brute-force algorithm characterizes this? But it has been shown that (informally) there is no non-exponential/non-exhaustive algorithm to enumerate BCNF decompositions that do/don't preserve FDs (functional dependencies).
When is a 3NF decomposition desired instead of a BCNF decomposition [not] preserving functional dependencies?
If a 3NF design is not in BCNF then it preserves a FD that is not out of a superkey and so cannot be declaratively enforced in most SQL DBMSs. But the BCNF design, not having preserved the FD, needs a constraint enforced that is equivalent to two SQL FK (foreign key) constraints to each other, which cannot be declaratively enforced in most SQL DBMSs. Since there's nothing special about cycles that prevents DBMSs from enforcing them and the two designs can represent each other, there isn't any reason per se why a DBMS couldn't support both.
There's a similar mental complexity for these two design forms--3NF plus FDs not out of CKs vs BCNF plus extra equality dependencies. But since the 3NF relation is the join of its BCNF components, the meaning of a 3NF tuple is the AND/conjunction of the meanings of the BCNF components. Since a user implicitly knows this and should be explicitly told it, and since constraints are not needed to query or modify a database (they're for integrity), the BCNF design is in some sense simpler. But if the user is always wanting to update both components then the 3NF design is in some sense simpler.
Thus, in case we are not able to get a dependency-preserving BCNF decomposition, it is generally preferable to opt for BCNF, since checking functional dependencies other than primary key constraints is difficult in SQL.
-- Database System Concepts 6th Edition (2011) by Silberschatz, Korth & Sudarshan
You can find an example facing this choice in most textbooks, and dozens are online in pdf. It must involve overlapping (composite) CKs (candidate keys).
The meaning of an SJT tuple (s,j,t)--simplified notation--is that student s is taught subject j by teacher t. The following constraints apply:
For each subject, each student of that subject is taught by only one teacher
Each teacher teaches only one subject (but each subject is taught by several teachers).
[...] From the first constraint, we have the FD {S,J} → T. From the second constraint, we have the FD T → J.
-- An Introduction to Database Systems 8th Edition (2004) by Date
(A 3NF design can suffer from further problems that could be eliminated by further decomposing the BCNF design to higher normal forms. This is why we should always decompose to 5NF then if desired explicitly denormalize. So any non-BCNF 3NF table should have come from such a denormalization.)
I'm looking at a specific example of a relation with a composite primary key. Based on its functional dependencies, I know it is in 1NF. While normalizing it to 3NF I came across a situation I have not yet encountered. I followed the steps for all partial dependencies and transitive dependencies, but the last step of normalizing to 3NF requires you to create a relation that contains the primary key and all non-prime attributes dependent on it.
In my specific case, I have the primary key, but no full functional dependencies on it. Do I make a table containing only my composite primary key? Or do I not make one at all?
I have no confusion of composite and primary keys. See my comment below to see why I believe my question is different from that one
It is perfectly legitimate to have a relation that consists of a composite key and no other attributes. It's not only theoretically valid, but also it happens in the real world.
In such situation, that relation is merely asserting the existence of something identified by the composite key. And it would be used by the user of the data to test for existence and not for the same kind of lookups that a relation with non key attributes is typically used for.
FDs (functional dependencies) have nothing to do with 1NF, no matter which of the various meanings for "1NF" you are using. So it's not clear what you're trying to say about 1NF. A relation by definition has a value for each attribute of each tuple. A thing like a relation with something like a "list of values" for some part like an attribute of some part like a tuple is not a relation so CKs (candidate keys) & FDs do not apply. If you define a "1NF relation" as one without certain data types (because of some fuzzy application-dependent received wisdom about "atomicity", or in Codd's sense of having no relation-valued attributes) then satisfaction does not depend on whether FDs hold on the design with that data type. (Moreover if the "normalized" "atomic"-attributed version of such a "non-1NF" "non-atomic"-attributed design satisfies a FD then the original has a certain constraint, but it's not a FD constraint.)
FDs that aren't partial are full. The only partial FDs that matter on the way to 2NF & 3NF are partial FDs of non-prime attributes on CKs. When these are gone you have 2NF. (From "followed the steps for all partial dependencies and transitive dependencies" it sounds like your plan is to decompose to 2NF then to 3NF.) Partial FDs just aren't mentioned in a definition of 3NF that requires 2NF. Also, definitions for 3NF and the common algorithm for putting a relation into 3NF just don't make use of partial FDs.
There can also be other partial FDs. They just don't matter. In particular, all the FDs of attributes on proper superkeys are partial. Just follow the definitions for determining what normal form(s) a relation is and follow the algorithms for putting a relation into a normal form. This goes for all definitions and algorithms. There is no point in worrying about every property you notice that it might be "bad".
PS You shouldn't put a relation into 3NF by first putting it into 2NF. That can exclude some good 3NF decompositions of the original from being found. Use an algorithm for 3NF. (The usual one for 3NF actually generates decompositions in the slightly stronger EKNF (Elementary Key Normal Form)).
I'm doing a homework question where I have to convert a database to 1NF, 2NF and 3NF. I have gotten to 2NF and it does not appear to have any transitive dependencies. Does that mean that it is already in 3NF?
Yes. When a relation (variable or value) is in a given normal form it can also be in higher normal forms at the same time. (But beware that sometimes people sloppily say that a relation is in a given normal form but they mean that it's in that normal form but also not any higher one.)
Being in a normal form is a property of a relation. The way they are named, 1-2-3-BCNF-4-5 are stricter and stricter conditions. So when a relation meets one of those conditions it meets all the preceding ones and it might meet later ones. You happen to have a 2NF relation that is also a 3NF relation. Or to put that anther way, you have a 3NF relation that, like every 3NF relation is also in 2NF. You just happened to notice that it was in 2NF before you noticed it was in 3NF.
Yes, unless you missed a transitive functional dependency.