Lists Home |
Date Index |
One property of a primary key is that it is constant. If it's variable,
then it's not a candidate primary key.
> -----Original Message-----
> From: Rick Marshall [mailto:email@example.com]
> Sent: Tuesday, August 26, 2003 8:32 AM
> To: Chris Angus
> Cc: firstname.lastname@example.org; email@example.com
> Subject: [xml-dev] A standard approach to glueing together reusableXML
> fragments in prose?
> ok, shoot the example - that's why most use customer numbers. however it
> shouldn't be necessary if the name is a primary key - in fact the
> customer number and name then become candidate keys and you have to
> select one as the primary key - redundant and not normalised properly :(
> i coined my terminology around 1980 .....
> On Wed, 2003-08-27 at 01:11, Chris Angus wrote:
> > Rick
> > Names make bad primary keys, as your example makes clear. If the
> > key is a system-supplied value that acts as a surrogate for the thing
> > the tuple represents (in those cases where the tuple is not a
> > of a relation) then the problem that you illustrate goes away since the
> > customer name no longer has a redundant representation. Your 'ownership
> > relationship' would seem to me to be another name for 'strong
> > or 'whole-part'.
> > Regards
> > Chris Angus
> > -----Original Message-----
> > From: Rick Marshall [mailto:firstname.lastname@example.org]
> > Sent: 26 August 2003 13:43
> > To: Chris Angus
> > Cc: email@example.com; firstname.lastname@example.org
> > Subject: RE: [xml-dev] A standard approach to glueing together
> > reusableXMLfragments in prose?
> > two quick comments on the last couple of posts:
> > 1. redundant data. relational models don't minimise redundant data
> > across the data base, only within the records. in fact the repetition of
> > data is in a sense it's own problem when it comes to updates.
> > take eg a customer name. if that is used as the primary key in a table
> > and multiple tables use it as a foreign key, then updating the customer
> > name leads to all the issues of referential integrity - how can you
> > guarantee to find and change all instances of that customer name. the
> > semantics gets worse when you delete the customer from the database
> > because you may want to delete all their address records, but not their
> > old invoice records!
> > in my case i'm interested in the semantics of the relationship between
> > tables and identified 3 cases of interest:
> > dynamic relationships - exist while the data associates, but data values
> > can change and the relationship disappears
> > equality relationships - if attribute a in tuple R changes and R is
> > "equality related" to R' on a then a in R' must also change
> > ownership relationships - if a tuple R containing attribute a is deleted
> > and R is "ownership related" to R' on a then R' must be deleted.
> > this helps to get the referential integrity rules working.
> > mind you it is also limited by relationships (or associations) from R.
> > Associations to R will not meet any referential integrity constraints.
> > 2. the strength of the approach was twofold any relations could be built
> > on data value associations - a true network model - and the lack of
> > "hardwired" pointers made the model robust
> > in many ways it was like xml because the data is explicitly readable
> > pretty easy to fix too if an update goes wrong because it's easy to find
> > the values that didn't change - not so if you're looking for dangling
> > pointers.
> > i'm starting to get an idea on how to answer murali's question regarding
> > multiple hierarchical views....
> > rick
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>