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?
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
- 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
- XML basics: What is XML?
- DB2 9 Viper helps hospital cure performance pain by storing XML, relational data in one DBMS
Dig Deeper on Data modeling tools and techniques
Related Q&A from Pete Stiglich
Learn about the roles of data architects when it comes to making data management project decisions. Continue Reading
Find out why it’s important and how to organize an enterprise conceptual data model development. Learn how a data governance organization can help ... Continue Reading
Learn how to convert a logical data model into a physical data model via data modeling best practices. Find out how DDL and your data modeling ... Continue Reading