[
Lists Home |
Date Index |
Thread Index
]
you're right - it was 2am when i wrote that while working on a different
problem - should have thought for a bit longer
it's an issue for us because we have a lot of success using names etc
rather than system generated numbers wherever possible, but there is the
update issue ...
cheers
rick
On Wed, 2003-08-27 at 01:51, Murali Mani wrote:
> Rick, are you saying that if there are multiple candidate keys, then there
> is redundancy; I do not think that is correct..
>
> cheers and regards - murali.
>
> On 27 Aug 2003, Rick Marshall wrote:
>
> > 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>
> >
>
>
> -----------------------------------------------------------------
> 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>
|
