Modeling One-To-Many Relationships With XML, Page 3
When to Use Each Technique
Nine times out of ten, I've seen developers use the Containment relationship approach to implement one-to-many relationships. I believe that this is more out of ignorance of other approaches than anything else.
When passing small documents between components, the Containment relationship approach is very expedient. However, it may not model reality (that is, true containment relationships) and does not provide the most flexible data access.
The Intra-document relationship approach provides much more flexible data access. You can model many relationships between elements, not just containment relationships. The use of ID/IDREF attribute types makes Intra-document relationship access very efficient.
The Inter-document relationship approach can come in handy in certain situations where it's beneficial to have several smaller documents. However, in the ease of use category, it's a little bit awkward at this point, although this should improve with XPointer support. When passing data between components, it can get a little tricky.
The following table summarizes the characteristics of the three approaches:
|Technique||Passing Data||Flexibility||Ease of Use|
I would like to see the Intra-document approach used more frequently and to become the "default" choice of developers for relating elements. Legacy and true containment relationships would use the Containment approach. Inter-document relationships are going to become more and more prevalent as we move to persisting documents in XML databases.
We shouldn't throw away all that we've learned in modeling relational databases and object models when designing XML vocabularies. With both technologies, we're modeling a problem domain that can be represented in a format that is technology neutral. We just happen to implement the model using documents, elements, and attributes as opposed to tables, row, and columns.
We looked at the Containment, Intra-document, and Inter-document approaches for modeling one-to-many relationships in XML by using the familiar Department and Employee problem domain. We discussed when each approach might be appropriate.
So, now you have a few new techniques in your toolbox for modeling XML. The next time you design an XML vocabulary, don't use the "fly by the seat of your pants" method. Model it first, and then consider various implementations. The rest is up to you!
To download the example XML streams, DTDs, and stylesheets, click here.
I'm hoping to find more books and articles on this topic. David Carlson's book, Modeling XML Applications With UML, is the best resource I've found to date. As XML becomes more and more pervasive, well-designed XML vocabularies and modeled data will become more important. The following link will take you the associated Web site for this book: http://www.xmlmodeling.com/.
About the Author
|Jeff Ryan is an architect for Hartford Financial Services. He has eighteen years of experience designing and developing automated solutions to business problems. His current focus is on Java, XML, and Web Services technology. He may be reached at email@example.com.|
|Other Articles Written by Jeff Ryan|