[
Lists Home |
Date Index |
Thread Index
]
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
On Tue, 2003-08-26 at 18:50, Chris Angus wrote:
> Michael
>
> Very often the network model has one or more 'natural' hierarchies within it
> which are readily discovered if the edges are suitably qualified. Looking
> for the edges which represent whole-part relations will often do the trick,
> although sometimes a node may look to be part of more than one whole. In
> such a circumstance one may need to resort to differentiating between 'weak'
> and 'strong' aggregation or decide that there is more than one hierarchy or
> arbitrarily 'break' one of the edges. Obviously for this kind of technique
> to work it is necessary to have an understanding of the underlying nature of
> the relations represented in the model.
>
> Chris Angus
>
> -----Original Message-----
> From: Michael Kay [mailto:michael.h.kay@ntlworld.com]
> Sent: 26 August 2003 09:15
> To: 'Murali Mani'; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] A standard approach to glueing together
> reusableXML fragments in prose?
>
> <snip>
> Data that is sent from A to B has to be encoded as a
> sequence of bits, and hierarchies lend themselves well to such
> serialization. This absolutely gives you a design challenge because the
> models that you get from your data analysis are graphs rather than
> trees. We certainly need a much more mature understanding of the
> methodology of translating between the graph object models that come out
> of data analysis and the hierarchic representation of these models as
> XML, and I would love to see something that gives you the ability to get
> multiple hierarchic XML views over the same network data model.
> </snip>
>
>
> -----------------------------------------------------------------
> 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>
|
