Re: Operationalize orthogonality
Date: Sun, 04 Jun 2006 13:28:14 +0200
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
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.
> 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 - 13:28:14 CEST