Re: Proposal: 6NF

paul c wrote:
> David Cressey wrote:
>

>>  ...
>>
>>> PMFJI, when it comes to a dbms engine, I don't know the difference
>>> between a type and a domain.
>>>
>> In the context of a dbms engine,  a type would be the built in datatypes
>> that the engine supports,  like INTGER, DECIMAL, CHAR, and DATE, and also
>> the builtin functions and operations,  like "+" or "weekday(x)".
>>
>> A domain would be what you get when you say CREATE DOMAIN.  It's a 
>> set,  but
>> it has no functions and operations other than the ones it inherits 
>> from the
>> data type it is based on.
>>
>> Does this make sense?
>>

There's lots of potential confusion, here. The D+D crowd can be expected to say, "Wait! The only types that should be built-into a dbms are boolean, tuple, and relation." Their view is that *users* should be able to specify what integers, rationals, strings, dates, gender, countries, currencies, etc., etc. the database should be able to handle. And, by handle, I mean represent, store, and operate upon.

In that regard - and, acknowledging that dbmses are limited to what computers are capable of representing - types and domains are the same thing. Types and domains are *not* what SQL says you get after CREATE DOMAIN, and operations must (generally) be defined independently of types -- although, of course, types must be extant before operations.

The "what computers are capable of representing" remark is important: while we might describe the set of, let's say, "extended integers" as "zero and naturals and negative naturals and infinity and negative infinity," it's obviously impossible to represent many of those values using computers. As much as we may dislike the situation, the machines we use limit us and it is, I think, more appropriate to use the word type rather than domain. Received on Wed Oct 18 2006 - 23:41:59 CEST