Re: foundations of relational theory?
From: Mike Preece <michael_at_preece.net>
Date: 26 Oct 2003 19:44:20 -0800
Message-ID: <1b0b566c.0310261944.38060f8e_at_posting.google.com>
So - a relation can't be an array?
> it is accessed by array index,
As opposed to column & row, for instance?
> is ordered
By ordered do you mean sorted?
> and allows duplicates.
Depending on what you would call integrity constraints.
> 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?
What are the rules defining what a candidate key can and can't be?
> 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 - and input validation is a function of the application that runs as part of the DBMS but not essentially as a function of the database itself. That aspect of integrity constraints concerning maintaining *referential* integrity (if that's the correct term to use to describe the integrity of references between related data) I have less difficulty with. That is obviously more integral to the database. I'm interested in this distinction because I'm working on a development project of my own within the Pick DBMS which has an input validation layer with functional requirements distinct from those of the database I/O layer.
> 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.
> 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?
> 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.
> 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.
Can you please elaborate on this a bit?
> 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?
> This is merely one
> aspect of logical independence.
Thanks Dave!
Date: 26 Oct 2003 19:44:20 -0800
Message-ID: <1b0b566c.0310261944.38060f8e_at_posting.google.com>
"daveb" <davebest_at_SuPsAaM.net> wrote in message news:<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,
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?
> it is accessed by array index,
As opposed to column & row, for instance?
> is ordered
By ordered do you mean sorted?
> and allows duplicates.
Depending on what you would call integrity constraints.
> 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?
What are the rules defining what a candidate key can and can't be?
> 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 - and input validation is a function of the application that runs as part of the DBMS but not essentially as a function of the database itself. That aspect of integrity constraints concerning maintaining *referential* integrity (if that's the correct term to use to describe the integrity of references between related data) I have less difficulty with. That is obviously more integral to the database. I'm interested in this distinction because I'm working on a development project of my own within the Pick DBMS which has an input validation layer with functional requirements distinct from those of the database I/O layer.
> 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.
> 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?
> 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.
> 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.
Can you please elaborate on this a bit?
> 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?
> This is merely one
> aspect of logical independence.
Thanks Dave!
Cheers,
Mike.
Received on Mon Oct 27 2003 - 04:44:20 CET