Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: A standard approach to glueing together reusableXMLfragme
 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@z...] Sent: 26 August 2003 13:43 To: Chris Angus Cc: michael.h.kay@n...; xml-dev@l... Subject: RE: 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
