A data model is a precise representation of an information landscape, in much the same way as a map is a precise representation of a geographic landscape. “Precise” is the key characteristic of a data model, which means that there is a clear, unambiguous way of reading every symbol and term on the model. A team of business analysts for example, will all read the data model the same way and understand exactly what is being communicated, and then afterwards can debate whether the data model reflects their understanding of the business or whether the measures on the data model reflect what is required in the business requirements. An application development team will all read the data model the same way and understand exactly what is being communicated, and afterwards can discuss the ideal way these structures should be implemented.
Without the data model, we rely more on conversations and requirements documents, both of which are traditionally ambiguous. Conversations and requirements documents are often essential inputs to the data model, however.
For example, “A Customer has Accounts” is typical of an ambiguous statement that might be made verbally or appear in print. Business analysts discussing this statement would need to invest valuable time first understanding exactly what is being communicated. Developers discussing this statement might make erroneous assumptions as to what a customer or account is, leading to a poor design choice.
“A Customer has Accounts” cannot appear on a data model until this statement is made precise, which involves answering many questions first, such as these ten:
- What is a Customer?
- What is an Account?
- Can a Customer own more than one Account?
- Can an Account be owned by more than one Customer?
- Can a Customer exist without an Account?
- Can an Account exist without a Customer?
- Can you identify a Customer without an Account?
- Can you identify an Account without a Customer?
- Does a Customer go through a lifecycle?
- Does an Account go through a lifecycle?
Once these ten questions are answered, the results can be shown visually on a data model, leading to our precise communication tool. Here is an example of a data model which captures the answers to a number of these questions:
This model is read as follows:
- Each Customer may own one or many Accounts.
- Each Account must be owned by one Customer.
Once this model is created, business analysts, developers, and other important roles to application development do not need to invest valuable time asking the same questions again such as those that appear above. Instead they can jump right in and read the model which conveys the answers to these questions, and then discuss and debate parts of the model, continuously improving it to reflect reality and the necessary business requirements.
For example, everyone can read the model above and know that an Account can only be owned by one Customer, not two and not zero. Because everyone reads this statement the same way, it can be discussed to determine if everyone agrees with this statement. For example, if someone can prove that we can have joint accounts, that is an Account may be owned by two Customers, than this model will need to change.
Since all application development roles read the model syntax the same way, they can jump right in and discuss the semantics. A simple formula:
data model = less analysis time + more successful development decisions
About Steve Hoberman
Steve’s Data Modeling Master Class is recognized as the most comprehensive data modeling course in the industry. Steve is the author of nine books on data modeling, including the bestseller “Data Modeling Made Simple.” He is also the author of “Data Modeling Made Simple with ER/Studio Data Architect,” “Data Modeling Made Simple with CA ERwin Data Modeler r8,” and “Data Model Scorecard: Applying the Industry Standard on Data Model Quality.”
One of Steve’s frequent data modeling consulting assignments is to review data models using his Data Model Scorecard® technique. He is the founder of the Design Challenges group, Conference Chair of the Data Modeling Zone conference, and recipient of the 2012 Data Administration Management Association (DAMA) International Professional Achievement Award.