Re: foundations of relational theory?

From: daveb <davebest_at_SuPsAaM.net>
Date: Sun, 26 Oct 2003 15:14:33 -0800
Message-ID: <szYmb.85994$Ms2.20385_at_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, a Pick MV is an array, not a relation: it is accessed by array index, is ordered and allows duplicates.
A relation must have at least one candidate key, is unordered (both row-wise and column-wise), does not allow duplicates, and supports integrity constraints. Access and updates are done using the relational calculus or relational algebra.

Well, none of this applies to SQL since it's not actually relational. But in a relational database, it 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.

To a programmer, it doesn't matter wihch way it is stored since they all look the same - a nested relation. But using the 80/20 rule, it might need performance tuning, so we simply give a hint to the database engine to choose which physical format we want. Any decent DBMS should be able to change from one format to another on-line at any time. This is merely one aspect of logical independence.

Dave Received on Mon Oct 27 2003 - 00:14:33 CET

Original text of this message