Re: On Normalisation & the State of Normalisation

Op dinsdag 3 februari 2015 11:05:02 UTC+1 schreef Derek Asirvadem:
>
> ???
>
> b.1. As stated, and as you seem to understand, it is the developer's model, not mine.

Why are you saying this ? The subject of the thread is "normalization". Do you think whose model it is makes a difference as to "which normal form this is in" ? And if you are referring to my usage of the word "unskilled", I meant by that that anyone who understands what normalization really is, wouldn't be asking this question, because any such person would know that one of the following two is true :

• either all applicable dependencies are explicitly stated, and then this person would presumably know how to assess the NF level.
• or else it is assumed that the only applicable dependencies are those that are implied by the boxes and the key specifications they might hold, but in that case such a person would know that _every_ model of that nature satisfies 5NF trivially and by definition.

>
> b..2. It is not a conceptual model.

It is a conceptual model, and you even know the reason why. You stated it in b.3 immediately after.

>
> b.3. It is a logical model, minus the datatypes, which are irrelevant to the purpose of this thread.

a logical model is a logical model only if it gives a _full_ account of the details of every relvar involved. Meaning : anything that is "minus the datatypes" is not a logical model precisely because of that.

(I agree that the precise definition of the attributes datatype are orthogonal to NF questions/issues, but that brings me to my next point.)

A logical model is also a logical model only if it gives a _full_ account of all the constraints that apply to the relvars involved. Meaning in particular : a _full_ account of all the functional dependencies _including those_ that apply to the relation schema you get when, say, you join Street with Suburb and Town_. For example, The constraint that corresponds to the FD TownID -> Postcode that might apply to [the schema of] that join.

> b.5. "Relvars" scare, and confuse, developers. I had previously assured him that they are nothing to be concerned about, because it is a trick that theoreticians use to avoid definition in the physical universe, so he did not use it in our conversations. Neither he nor I have seen "relvars" mentioned in the texts defining the normal forms or Normalisation. Neither he nor I give a rats about them. If your point is relevant to Normalisation, please explain what you mean in those terms.

A relvar, as far as normalization theory is concerned, is a [possibly named] (S,D) pair where S is the relation schema for that relvar and D is the set of dependencies that apply to it. The members of D can be functional or join dependencies, and they must be termed exclusively in attributes of the schema of the relvar. I'm not considering other kinds of dependencies because I'm not certain to which extent there even exists a [sufficiently agreed-upon] "normalization theory" that incorproates/embraces them.

Anyway, what I was getting to is that had the author of the schema started off with a single relation schema for the _entire_ model (which is how the normalization procedure really goes), he might have noticed that in that schema, there was an FD that applied to the effect that TownID -> PostCode. The decomposition he [implicitly] applied has lost the expressibility of that FD, because there no longer is a relvar [with corresponding relation schema] in which both attributes appear. But the fact that the expressibility of an FD has been lost, does not mean that the FD itself no longer holds.

It is extremely rare for there to be database schemas in which there is not a single constraint that isn't a key constraint (attribute, tuple and foreign key constraints notwithstanding, of course).

(if by "physical universe", you meant "all the stuff that comes to be important once you start out with the details of physical database implementation, then no, relvars are not a concept that belongs to the physical universe.)

> b.7. The existential predicates are usually not stated nowadays, I am happy to provide them for you at your request. I was hoping to focus on the Normalisation issues.

You might have meant "external predicates". That they are not usually stated is precisely the problem. They are often quite helpful in identifying dependencies, read constraints.

> I would think, once you have been able to _read_ the model; to identify the dependencies conveyed therein; and thus notice the predicates are explicit, your categorical response might change.

It stays exactly as is. Received on Tue Feb 03 2015 - 13:16:25 CET