Re: Operationalize orthogonality

From: J M Davitt <jdavitt_at_aeneas.net>
Date: Sun, 04 Jun 2006 19:05:12 GMT
Message-ID: <I9Ggg.49520$mh.40527@tornado.ohiordc.rr.com>

mAsterdam wrote:

> J M Davitt wrote:
> 

>> Pickie wrote:
>>
>>> Tony D wrote:
>>>
>>>> The only type absolutely required is the boolean type. You could (and I
>>>> stress, *could*) attempt to model everything from there on up in terms
>>>> of relations and booleans, but that would require a frightening degree
>>>> of circumlocution.
>>>
>>>
>>> How would you represent a count (IE the non-negative integers) using
>>> only booleans and relations?
>>
>>
>> You shouldn't. The point is that the relational model requires only
>> boolean scalars and the corresponding nullary, unary, and binary
>> operators. Beyond that, an RDBMS is expected to provide a mechanism
>> whereby other types and operators can be defined.

> 
> 
> Yes. Operationalizing the type orthogonality means isolating
> the type base such that the RDBMS only 'has' the minimum about
> types it /needs/, everything else would require the type base
> to be in charge. The RDBMS would need the type base to include
> "the mechanism whereby other types and operators can be defined",
> no?
> 

>> What types? Well,
>> integers, rationals, characters, and strings are undoubtedly useful.
>> How 'bout internet addresses? Points? Complex numbers? States?
>> Music? Telephone numbers? Mass? Length? Raster images? Vector
>> drawings?

> 
> 
> That these are still defined ad
> hoc (if they are defined at all)
> in many places is a sign of
> immaturity of our industry, IMO.
> 

>> You bet! It's all up to the user of the database system
>> The only thing the relational model demands is that, for each type,
>> an operator must be provided that can determine whether two values
>> of the same type are different.
>>
>> How would you represent a text string? I
>>
>>> ask because these seem to me to be basic concepts (or primitive types?)
>>> and both of them have simple ways to represent a boolean (zero and
>>> empty string respectively being false, all else true).
>>
>>
>>
>> It is expected that various RDBMSs would provide "off the shelf" support
>> for the types you consider primitive.

> 
> 
> In the orthogonal system we are discussing right now this
> expectation would not be appropriately directed.
> It should be redirected to the type base.

You're absolutely right. The only things I suspect we could reasonably expect a product to get right are some variety of characters and integers. But I didn't want to belabor the point that one man's primitives are another's poison.

[BTW: I'm glad to see that you weren't gone too long.]

>> But it could well be that a user
>> would want to define a numeric type that did arithmetic a bit
>> differently than they way you were probably taught in school. My
>> running example is that proposed by Iverson and made manifest in APL
>> and J: any value divided by itself is 1 - including "zero divided by
>> zero." Rationals are considered equal if they're close to each other.
>> How close? There's an epsilon value - commonly called fuzz - that
>> specifies closeness.
>>
>> At a "higher" level, consider states: we all recognize that TX and Texas
>> and Tex. are the same value, right? (I'm not talking about the sequence
>> of characters -- I'm talking about what they represent.) An RDMS
>> should provide a mechanism whereby a user can define a STATE type which
>> happens to know that all these are acceptable representations of the
>> same value.
>>
Received on Sun Jun 04 2006 - 14:05:12 CDT