[
Lists Home |
Date Index |
Thread Index
]
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>
>
|
