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?
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
- Data model conversion: Conceptual design to logical design using an ER model
- Four guidelines for enterprise conceptual data model (ECDM) entity selection
- What is a data model?
More about XML
This was first published in May 2008