CODEWITHSUNDEEP
databasedatabase-designrelational-databasedatabase-normalizationdatabase-theory
Gary
Gary

Reputation: 67

Normalization Theory Explanation needed

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

Upvotes: 0

Views: 195

Answers (2)

philipxy
philipxy

Reputation: 15118

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)).

Upvotes: 1

Walter Mitty
Walter Mitty

Reputation: 18940

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.

Upvotes: 1

Related Questions