We write software for complex engineering systems. The engineering design needs to be complete at every level of maturity. The devices are naturally hierarchical, from parts to components to systems. Missing items lead to very poor and often the wrong designs. For this reason, I prefer using XML schema definition that expresses strict hierarchical relationships immediately, without a conceptual data model. We do draw diagrams, but they are drawn in Visio or by engineering simulation programs.

I am trying to explain the use of XML schema definition versus the use of a conceptual data model to our software person who has an enterprise software background. Could you help me articulate my view?

    Requires Free Membership to View

    Login

Both XML Schema Definition (XSD) and a Conceptual Data Model (CDM) can express strict hierarchical relationships. However, XML Schema is meant to describe an XML document while a conceptual data model is meant to describe business objects and how these relate – it is a business model from a "data" point of view (for the CDM, actual data does not have to exist). It is technology and application neutral. A CDM usually takes the form of an Entity Relationship Diagram (ERD) but a Unified Modeling Language (UML) class diagram could be used as well for expressing constraints which an ERD might not be as capable of.

In addition, the CDM is not intended to be a design document (it's for understanding the business before a solution is designed) and so will not have all the gory details needed for implementing any data-related system.

One thing that an XML Schema Definition cannot express (easily) is a many-to-many relationship given its hierarchical nature. XSD itself is an XML document, not a model and so the relationships aren't as easy to identify due to the variable structure of the doc, e.g. lines may or may not be proporly indented. Even showing a well formed XSD to a business person or even to most technologists will be an invitation for glossy eyed incomprehension. Also, importantly, many-to-many relationships can be expressed easily in a CDM - this is important because parts may be used for many components, and a component has many parts, etc. Below is a sample CDM demonstrating parts explosions, which may or may not be applicable to your business.

The above CDM helps to visualize the parts explosion and has business rules (relationships) which are documented in business terms so that the business can immediately validate or point out the correct relationship easily. The Inclusive OR relationships indicates a Component (for example) may be comprised of both many (per crows feet notation) Parts and many sub Components (per recursive many to many relationship of Component to itself). As the saying goes "a picture is worth a thousand words".

The CDM should be developed before the XSD to ensure that your XSD is aligned with the business.

More about conceptual data models

More about XML

This was first published in May 2008

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top