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