XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML Schema as a data modeling tool

On 30 Sep 2013, at 12:48, Hans-Juergen Rennau wrote:

> Thank you, Michael. You wrote "It [XSD] is a hierarchic model, whereas the real world is a network." I would say, it is as much a network as it is hierarchic. Think of economic structures (e.g. a shop inventory), of administrative structures (a registration procedure), of biological structures (a cell). At any rate the structures I have been dealing with were usually hierarchic, unwieldy and confusing if not dealt with as such, and often straightforward to handle, otherwise. I could show you an ER diagram representing over 100 relational tables storing shopping cart data, and also a single tree representation which can be read like a newspaper. A concise tree representation can be read like a text, conveying a sense of the whole. An ER diagram with many boxes and very many lines is very hard to read. Doubtless you are right in warning about the problems how to model relationships which do not correspond to containment. But I wonder - would you really suggest giving up the benefits of hierarchical modelling, and what is the alternative? You know the German saying, "Not to see the wood because of all those trees", which I suggest to invert, not to see the trees, because they are part of a wood.

I agree, data modelling can easily produce a diagram so complex it fails in its purpose of communicating useful information. The answer to that is to leave out irrelevant detail; at a certain level of understanding, you are only interested in the fact that the system knows about employees, pensioners, and contractors, and not about the detailed information held for each employee &c.

And it's exactly at this high level that you tend to be dealing with a network. Customers book rooms in hotels. If you're interested in the customer's itinerary, then you see a hierarchy of customers and bookings; if you're interested in room availability in the hotel, then you see a hierarchy of hotels and bookings. Two hierarchic views of the same network model.
> 
> And then I am unsure in how far your argument applies to XSD specifically, or to XML in general, that is, to models based on node trees and constraints on those trees.

I think it applies to all attempts to do enterprise data modelling with tools that were designed for document modelling. It also gets down to the level of detailed database design; it's not at all obvious what the best design is for the customer/booking/hotel model in an XML database. What XML document should a booking go in? It might be best to organise them not by customer, not by hotel, but rather by day/month/year: a third hierarchic view.

Michael Kay
Saxonica




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS