Re: How to normalize this?

On Thursday, May 2, 2013 3:40:28 AM UTC-7, Erwin wrote:

> > > It's often bothered me that normalization theory/procedure seems to quietly ignore the notion of "nullability or not" of any of the attributes in the "initial table design" ...
> > > Iow, that normalization theory per se doesn't actually allow to determine when and when not the phenomenon is "an artifact of the iniital table design".
> However, I'd argue that there is indeed "a phenomenon", and it's exactly the phenomenon you described as the "...a...b...c...d...some e..." vs. "...a...b...c...d..." confusion.

You have changed the meaning of "phenomenon" from some alleged constraint imposed by an original single-relation schema to certain difficulties with certain design processes or their presentation. (Presumably you were concerned with the latter but hypothesized the former as the cause.)

> Jan observes that in practice most of the time, making this "mistake" leads people to "discovering" the correct predicates for the business problem at hand, and seems to be on the side that therefore it must be a good thing, I personally am rather bothered with the fact that a theory would be useful because misunderstanding it or only partially understanding it, in practice mostly leads to correct designs being derived from less correct ones ...

I agree with you that most (all?) presentations of db design and of normalization and the role of the latter in the former are poor. But you seem to confuse the latter with the former.

Eg normalization addresses replacing some relations with others but doesn't generally address information equivalence and constraint preservation, which is different from non-loss decomposition or FD preservation.

Eg when you normalize a relation variable based on FDs you have have to know its FDs so you have to know its predicate. (If you didn't have have a predicate in mind, why would you even have a relation variable?) So normalization cannot be expected to generate proper predicates. I agree a design process, incorporating normalization, should.

Eg if your only predicate/variable on attributes A1,..,An is p(A1,...,An) then the only predicates you can express on a subset of Ai,... involve "exists Ai,... p(A1,...,An)". For any tuple to be in its value there has to be corresponding supertuple(s) in p. So if you find that you want to express predicates when there *doesn't* have to be all n values (or corresponding things) then this predicate is inadequate. If you don't bother to think about what predicates you are interested in ie queries you want to pose and only bump into it when normalization presents you with predicates on attribute subsets (what did you expect it to present you with?) then that is not a fault of normalization.

philip Received on Sun May 05 2013 - 01:28:01 CEST