xsl-list
[Top] [All Lists]

RE: [xsl] many-to-many

2007-01-29 03:34:46
Data modelling is a bit off-topic for this list, though of course the way
you model the data does have a bearing on how you transform it.  It's also
true, of course, that it doesn't matter too much how you model it, because
you can always transform it to something else.

Even where relationships are one-to-many, you don't always want to model
them in XML using the natural parent-child hierarchy. For example, the
relationship between person and country-of-birth is many-to-one, but it
would be unusual to have a list of people grouped by country of birth. Part
of the reason for that is that an object such as person is likely to be at
the "many" end of a number of separate one-to-many relationships. So in
general, in an XML document, you will have some relationships modelled by
the parent-child structure of the XML, and others modelled by foreign keys -
which might be IDREFs, URIs, or something of your own invention.

Whether the links are one-to-many or many-to-many, one of the design choices
that needs to be made is whether to represent only one direction of the
relationship or both. For example, if you link book to author, do you also
link author to book? Generally, I think I'm in favour of only representing
one direction; if you represent both then this creates the possibility of
inconsistency, which imposes extra requirements on validation, and it
doesn't actually help navigation much because you can do that efficiently
using xsl:key in either case. However, this can be affected by ordering: the
authors of a book are generally in some conventional order and the ordering
needs to be captured. I think it's unusual, however, for both directions of
a relationship to have intrinsic order.

Remember also that more often than not, many-to-many relationships have
attributes associated with the relationship itself, for example in the
invoice-part example cited, there's a quantity of each part ordered, and the
price of a part might also vary from one invoice to another. So it's often
useful to decompose it into two one-to-many relationships with an extra
entity in the middle ("order-line").

In the XML world, I've often found that basing the XML design on the
arrangement of the traditional paper document turns out to work well. Often
XML documents represent messages passed between applications as part of a
business process, and these relate closely to the paper documents used in
the pre-electronic version of the business process.

As to your actual question, one area I had to tackle this was in modelling
genealogical data: see the case study in my XSLT book. The relationships
here aren't directly between people, they are between people and family
units (the family unit being an abstract entity invented for the purpose of
modelling relationships between people!). Certainly these relationships need
to be navigated in both directions, but you have a free choice whether to
model them in the source XML as links from person-to-family,
family-to-person, or both. You could also have a viable model that dispenses
with the "family" object entirely. In this particular example, appealing to
traditional paper document designs doesn't help much.

Michael Kay
http://www.saxonica.com/


-----Original Message-----
From: Brown, William S [mailto:wsbrown(_at_)bnl(_dot_)gov] 
Sent: 26 January 2007 20:30
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: [xsl] many-to-many

Esteemed experts,
There are a number of examples out there on the net of 
modelling 'many-to-many' relationship in XML.
A recent one is
http://en.wikibooks.org/wiki/XML:_Managing_Data_Exchange/The_m
any-to-many_relationship
and it is helpful, as far is it goes.
However, Kevin Williams points out in
http://www-128.ibm.com/developerworks/xml/library/x-xdm2m.html
that the usual understanding of the 'many-to-many' 
relationship is that it is a two-way street.

That is, to use an example from the first document, I can 
structure data about movies and actors such that each actor's 
info is represented only once in the XML but pulled out 
repeatedly as I generate a list of movies and the many actors 
that appeared in each; same actors appear in multiple movies.
Or, to use the classic example, I can represent details for 
each part only once, but re-use it as I generate invoices, 
each of which contains many of the same parts.
Each of the above articles suggests an ID/IDREF approach for 
doing this.
However, Williams notes that in relational databases it is 
simple to run the query in reverse, i.e., list the movies 
that each actor has appeared in, or list the invoices on 
which each part appears. Since the ID/IDREF is treated as 
unidirectional, he suggests a double IDREF structure - paired 
pointers pointing in opposite directions.
Which brings me to my question -
has anyone seen any sample xml/xsl that actually demonstrated 
running the query in forward and reverse. Everything I've 
seen uses ID/IDREF and xsl:key in one direction and calls 
that a 'many-to-many' structure. But I'm not clever enough to 
navigate back upstream (William implies it can't be done) or 
to implement the XSL for the dual ID/IDREF.
The first (wiki) article contains sample xml and xsl for 
anyone who wants to investigate the issue.
I hope you find this diverting (or at least can show me how 
to do it LOL).

Best,

William S. Brown              wsbrown(_at_)bnl(_dot_)gov
Systems Engineering and Safety Analysis Group Brookhaven 
National Laboratory 
Building 130                 TEL 631 344 7230
Upton, NY 11973-5000         FAX 631 344 4900

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>