 | |
#391
 
| |||
| |||
|
Re: foundations of relational theory? - some references for the truly starving -
11-10-2003
, 12:12 AM
|
"Database Guy" <dbguy101 (AT) hotmail (DOT) com> wrote in message news:7fdee71c.0311081524.77d4fc78 (AT) posting (DOT) google.com... davebest (AT) usa (DOT) net (Dave Best) wrote in message In Pick, the primary key of a MV element is the primary key of the record plus its array index. Really? So how does PK persistence work when you insert or delete values in the array? DG It doesn't. Pick is not relational. I was just showing a mapping between the relational model and Pick's physical model, thereby exposing a weakness in the physical model. To preserve "PK persistence" as you call it, one would need to actually have a PK for the MV columns. This would be problematic, since it's really a collection of MV columns synchronized together that form a nested relation, and Pick itself doesn't know about the multi-column association; it's up to the application to maintain this. |
inherent - if the datum changes its position so does it's PK change.
#392
| |||
| |||
|
|
It doesn't. Pick is not relational. I was just showing a mapping between the relational model and Pick's physical model, thereby exposing a weakness in the physical model. To preserve "PK persistence" as you call it, one would need to actually have a PK for the MV columns. This would be problematic, since it's really a collection of MV columns synchronized together that form a nested relation, and Pick itself doesn't know about the multi-column association; it's up to the application to maintain this. Isn't the PK preserved anyway? The position of a multivalue is inherent - if the datum changes its position so does it's PK change. |
Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett
#393
| |||
| |||
|
|
And aren't PKs optional in relational theory, anyway? |
equivalent. It just sounds like they differ.
View A: No, primary keys are mandatory. There has to be at least one
combination of the attributes in a relvar that uniquely identify each
tuple, and one such combination of attributes is designated as the
primary key. The other possible combinations are regarded as
alternate keys - AKs - though 'alternative keys' would be better use
of English.
View B: Yes, primary keys are optional. There must be at least one
candidate key, but even if there is more than one CK, it is not
necessary to arbitrarily designate one of them as 'the' primary key.
View A could be described as the older view point and View B as the
more recent. The net result is the same: there is at least one
combination of the attributes in the relvar which uniquely identifies
each tuple. Note that the combination might be the empty set of
attributes, in which case the relvar contains at most one tuple.
Note too that neither view says anything about indexes - they are
irrelevant (even though most systems implement unique constraints -
aka candidate keys - using an index).
I personally subscribe to View B because it does away with the need
for AKs (and PKs, come to that). Occam's Razor: Entia non sunt
multiplicanda praeter necessitatem. If you have CK's, PK's and AK's
are unnecessary.
See C J Date: Datebase - Selected Writings (probably the 1989-1991
volume, but conceivably the 1991-1994 volume).
SQL DBMS do not mandate that each SQL table has a candidate key. This
is widely regarded (especially in c.d.t) as a defect in the SQL
standard and hence in the DBMS that implement an approximation to the
SQL standard.
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler (AT) earthlink (DOT) net, jleffler (AT) us (DOT) ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.