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