Subject: RE: [xsl] many-to-many From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Mon, 29 Jan 2007 10:34:23 -0000 |
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@xxxxxxx] > Sent: 26 January 2007 20:30 > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxx > Systems Engineering and Safety Analysis Group Brookhaven > National Laboratory > Building 130 TEL 631 344 7230 > Upton, NY 11973-5000 FAX 631 344 4900
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] many-to-many, Ronan Klyne | Thread | [xsl] Newspaper Style Columns, Luke Jones |
Re: [xsl] XHTML templating (best me, Antony Quinn | Date | RE: [xsl] Error -- Could not find f, Girish.Chelankara |
Month |