[
Lists Home |
Date Index |
Thread Index
]
On Tue, 26 Aug 2003, Michael Kay wrote:
> There was never a single definition of the hierarchical data model. Most
> writers equated it with the model implemented by the IBM product
> variously known as IMS or DL/I. Other writers (incorrectly) use the term
> to embrace the network data model (Codasyl) as well.
>
> I was never a fan of hierarchical databases myself (I worked extensively
> with Codasyl databases) but the statement that "redundancy cannot be
> avoided" is quite wrong. I've just been re-reading the relevant chapter
> from Tsichritzis and Lochovsky's "Data Models" (1982) which has an
> extensive discussion of the various techniques developed by vendors and
> users to support m:n relationships without redundancy: the most
> comprehensive solution being "spanning trees" which allowed multiple
> hierarchic views over the same data records. And although "foreign keys"
> were not part of the model, they were widely used in practice at the
> application level (just as they are in XML). The solutions seem rather
> ad-hoc (I said I'm not a fan), but it's quite wrong to say that they
> don't exist.
I also use Tsichritzis and Lochovsky's "Data Models" often times.. It is
well written, and does teach the basics.
I will check up these things, but I will mention these things for your
perusal..
going off in another track, we may think in terms of logical model as well
as physical model.. we are thinking of XML/relational/hierarchical as
logical models.
(a) If we have redundancies in logical model, then users might get
"unexpected" results, they modify something, something else also changes
and so on..
(b) If we have redundancies in physical model, we burden the physical
model with consistency etc, updates might take longer etc..
But there are cases when redundancy is useful also..
What people who work on research can provide is ways by which we can
remove redundancy, but whether a redundancy should be removed or not will
depend on the application requirements...
I think a graph can be translated to tree with provision for foreign
keys/IDREF.. this translation, to the best of my knowledge is not
difficult..
> It would actually do us no harm as a community to relearn some of this
> stuff. XML is hierarchical for a very good reason: it is optimized for
> data interchange. 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.
>
> Michael Kay
cheers and regards - murali.
|
