Re: Operationalize orthogonality

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 04 Jun 2006 12:52:43 +0200
Message-ID: <4482bb08$0$31651$e4fe514c_at_news.xs4all.nl>

x wrote:
> mAsterdam wrote:
>

>>Tony D wrote:
>>
>> > ... the relational model is orthogonal to type. That
>> > means the relational model makes no demands and imposes no
>> > restrictions on the types available (apart from the
>> > obvious requirement for a boolean type).

>
>
> I would say that there are some requirements on the types:
> - equality is defined

With a demarcated type base the equality need not only be defined, but also communicated/shared between the TB (type base) and (the rest of?) the DBMS. So it seems the DBMS and the TB at least need a common language for specifying and implementing operators.

> - the values can be denoted in the "relational" language
>

>>What would the requirements for a dbms be to have
>>this orthogonality implemented?

>
>

>>ISTM the dbms should not have native types
>>(except boolean and maybe type generators
>>like relation() and attribute() ) but instead
>>rely on a lower level, external to the dbms,
>>type system.

>
>
> What is "external" in software ? Crossing an interface ?

Yes (I used the term 'demarcated').

> That interface is then a set of requirements.

A protocol.

>>This poses the next question: what would
>>be the requirements for this type system?

>
>
> Whose requirements ?

Good question :-)

The users of the type system.

Which categories of users do we see?

The end-users of course would be the same as the end-users of the applications and the database.

The database (via a hypothetical dbms conforming to the protocol).

The aplication (via a language/app framework conforming to the protocol).

Am I forgetting users?

Both the application and the database would need some form of garantuee (thinking of 'leases' like in DHCP, but longer term) that a used type will remain valid. Received on Sun Jun 04 2006 - 12:52:43 CEST