OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] A standard approach to glueing together reusableXML fra

[ Lists Home | Date Index | Thread 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:rjm@zenucom.com]
> Sent: Tuesday, August 26, 2003 8:32 AM
> To: Chris Angus
> Cc: michael.h.kay@ntlworld.com; xml-dev@lists.xml.org
> Subject: [xml-dev] A standard approach to glueing together reusableXML
> fragments in prose?
> 
> chris
> 
> 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 .....
> 
> cheers
> 
> rick
> 
> On Wed, 2003-08-27 at 01:11, Chris Angus wrote:
> > Rick
> >
> > Names make bad primary keys, as your example makes clear.  If the
> primary
> > key is a system-supplied value that acts as a surrogate for the thing
> that
> > the tuple represents (in those cases where the tuple is not a
> representation
> > 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
> aggregation'
> > or 'whole-part'.
> >
> > Regards
> > Chris Angus
> >
> > -----Original Message-----
> > From: Rick Marshall [mailto:rjm@zenucom.com]
> > Sent: 26 August 2003 13:43
> > To: Chris Angus
> > Cc: michael.h.kay@ntlworld.com; xml-dev@lists.xml.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>




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS