Re: Operationalize orthogonality
Date: Sun, 04 Jun 2006 19:05:12 GMT
Message-ID: <I9Ggg.49520$mh.40527_at_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 - 21:05:12 CEST