Re: 1GB Tables as Classes, or Tables as Types, and all that refuted

Ja Lar wrote:
> "Alfredo Novoa" <alfredo_at_ncs.es>...
>

>>On Mon, 22 Nov 2004 15:33:16 +0100, "Ja Lar" <jalar_at_nomail.com> wrote:
>>
>>
>>>"Why is it a great blunder to equate class with relvar"
>>>"Because it is a great blunder to mix type with value or variable". And
>>>"type = class"
>>
>>Indeed, the first statement is not clear for many people but
>>type=variable is an evident blunder for anybody who knows what type
>>and variable are.

>>>Try again: _Why_ is it a great blunder to "mix types with values"? The
>>>answer "that's obvious" is of no (logical) value - that's the hole point

>>>the paper this thread discusses.
>>
>>If you don't know what types, variables and values are, that is your
>>problem.

Actually don't ask the trolls. The otherwise knowledgeable Alfredo, when he goes on the defensive about the one true relational orthodoxy, he's in the trolling mode.

So don't ask him to provide a summary definition for a variable, because he has none. Such a definition would require formal (mathematical) semantics for the model he is defending. And there is none yet.

Only after we established there was some formal model, we can discuss about the adequacy of approach.

But to answer your question: in Date's sketch of a model called the third manifesto, a type is a name that denotes a "set of values". The difference between the type's denoted set of values and the set of values denoted by a "relvar" (aka table in common speak) is that the later is time varying while the former is fixed in the abstract. The next step is to consider the mapping between the name of the type and the set of all values of that type ( therefore the subset of the fixed immutable set) that are instantiated within the database (i.e. stored in a column, in a row, or in a whole table somewhere in the database. And the later is a time varying set that can just be as easily thought as a relvar, because maps a name (the name of the type) to a time varying set.

Depending on the circumstances of the design needs, the schema can make this mapping explicit, like in the example I presented from User type to the Users table, and there's *absolutely nothing wrong with that*. As Jan Hidders observed is so obvious that it's boring.

*Presumably* what Date can justifiably criticize is that some OO designers, some OO book authors and some O/R mapping products, do this mapping on auto-pilot. That is, for every object-type identified in their OO analysis (or corresponding loosely to every entity type in an ERD schema), they automatically make explicit the set of all instances by consecrating it with a table.

In some cases this auto-pilot relational schema design may result in less than perfect schema. So if you like the "recipe style" auto-pilot generation of relational tables from an OO class diagram can be considered an objectionable approach. Although empirically it has not been shown to result in the catastrophes associated with a "great blunder". That does not mean that by applying the transformation (making the mapping explicit from "object type" to a real table) with on a case by case basis is to be considered a great bundle.

Hope this clarifies your questions. I could come back if there's interest and if I have some time, with what can go wrong when going auto-pilot about this, how likely it is that things can go wrong, and how wrong is wrong (how bad are the consequences of having a less than perfect schema).

Costin Received on Tue Nov 23 2004 - 19:40:02 CET