Re: Scalars & atomic values & variables

Dawn M. Wolthuis wrote:

>Therefore, unless everyone is discussing the exact same set of objects
>(which could be defined by a set of types) and operators, the use of the
>term scalar is inexact and apt to be confusing as different values will be
>scalar in different models. When the whole idea of the model is to be
>extensible, then the term scalar is also not very useful as adding in
>another function/operator into the space and/or adding in new objects can
>change what is and is not a scalar.
>
>
If we think of scalars in terms of what can be seen by relational operators (union, projection, cartesian product, etc...) it would seem to me that defining scalars as values that cannot be "cracked open" with these operators would pretty well do it for me.

So, if we have a string (or char) it is scalar (or atomic) because no matter how we join, union or project on that value we will not get any wiser as to what is "inside" it.

e.g.
create table person
 ( person_id integer primary key,
   person_name char(20) );

If we decide to save that string as separate characters, we can use relational operators on it, and hence, it would not be atomic (or scalar) any more.

e.g.
create table person
 ( person_id integer primary key,
   ... );

create table person_name

  ( person_id integer,
    person_name_pos integer,
    person_name_char char(1),

We can get the 3. character for person_id=2 by SELECT person_name_char
  from person_name
  where person_id=2 and person_name_pos=3

The type system is orthogonal to the relational model (according to Date&Darwen Third Manifesto) so the types and operators on those types are a separate discussion from the relational model per se and the definition of scalar is very unambiguous.

regards,
Lauri Pietarinen Received on Mon Jan 05 2004 - 07:32:23 CET