Re: foundations of relational theory?

michael_at_preece.net (Mike Preece) wrote in message news:<1b0b566c.0310261944.38060f8e_at_posting.google.com>...

The news server at my ISP is down again today. Sigh.

> "daveb" <davebest_at_SuPsAaM.net> wrote in message news:<szYmb.85994$Ms2.20385@fed1read03>...
> > "mikepreece" <member31023_at_dbforums.com> wrote in message
> > news:3523845.1067151904_at_dbforums.com...
> > > What *is* a relation valued attribute? How does it differ from a
> > > multivalued attribute in Pick? I guess they're logically the same thing.
> > > How is a relation valued attribute physically represented in SQL-
> > > relational?
> > No,
> You mean they're not logically the same thing?
> > a Pick MV is an array, not a relation:
> =======
> So - a relation can't be an array?

No, a relation cannot be an array and an array cannot be a relation. An apple cannot be an orange. A relation is a set of tuples, and an array is not. An array is an ordered structure of addressible items, and a relation is not.

> > it is accessed by array index,
> As opposed to column & row, for instance?

Yes.

> > is ordered
> By ordered do you mean sorted?

Not necessarily. Consider the following array:

A[0] = 3
A[1] = 1
A[2] = 2

The array is not sorted, but it is ordered. In the array, the number 3 appears before the number 1 according to the indexing scheme.

A logically equivalent relation would look more like (omitting the attribute names):

A = { { 2, 2 }, { 0, 3 }, { 1, 1 } }

> > and allows duplicates.
> Depending on what you would call integrity constraints.

One can constrain anything; however, identity is an essential property of a relation. It is not an essential property of an array.

> > A relation must have at least one candidate key,
> ========
> So - an array index - whether it be in terms of column, row,
> attribute, multivalue or subvalue number - doesn't qualify as a
> candidate key?

Arrays do not have candidate keys. Relations do.

> What are the rules defining what a candidate key can and can't be?

A candidate key comprises an irreducible set of attributes drawn on data types that define the equals boolean operation.

> > is unordered (both row-wise
> > and column-wise), does not allow duplicates, and supports integrity
> > constraints.
> I'm still having difficulty with this. Sorry. For so many years spent
> in the application development trenches, much of what you call
> integrity constraints I've called input validation

You only describe the flaws in the file processing and/or data management products you have used.

> - and input
> validation is a function of the application

I disagree. It is a function of the data the application uses.

> > Access and updates are done using the relational calculus or
> > relational algebra.
> 'Fraid you've lost me there. What is it about the way Pick accesses
> and updates a multivalued attribute that fails to qualify as
> relational calculus or relational algebra? - never mind what the
> algerian relatives think of it.

What is it about the way Pick accesses and updates a multivalued attribute that you think qualifies as relational? It just doesn't.

> > Well, none of this applies to SQL since it's not actually relational. But
> > in a relational database, it
> (a relation valued attribute)
> > might be stored as separate file (table space)
> > to get disk parallelism, or it might be stored on the same physical disk
> > page so it gets read in at the same time (clustering),
> > or it might be
> > encoded into an in-place variable length string with special characters
> > (say, for example, char(254), char(253), etc) to denote the boundaries
> > between individual tuples and attributes.
> Hmmm... Are you telling me that in a relational database, as distinct
> from SQL, a relation valued attribute might be exactly equal to what
> in Pick is called a multivalued attribute?

No. A relation valued attribute has a single relation as its value and not multiple values.

> > To a programmer, it doesn't matter wihch way it is stored since they all
> > look the same - a nested relation.
> Depending on the API.

No. The API has nothing to do with the issue.

> > Any decent DBMS should be able to
> > change from one format to another on-line at any time.
> Like - by utilising different 'drivers' to access different data
> sources and storage formats?

No. By leveraging physical and logical independence. Received on Mon Oct 27 2003 - 18:46:57 CET