There are several ways of measuring a data model’s quality, and all require a standard for comparison. One method that will be used to provide an example of data model validation is The Data Model Scorecard® (Hoberman, 2015).
- How Well does the Model Capture the Requirements? Here we ensure that the data model represents the requirements. If there is a requirement to capture order information, in this category we check the model to make sure it captures order information.
- How Complete is the Model? Here completeness means two things: completeness of requirements and completeness of Metadata. Completeness of requirements means that each requirement that has been requested appears on the model. It also means that the data model only contains what is being asked for and nothing extra. Completeness of Metadata means that all of the descriptive information surrounding the model is present as well; for example, if we are reviewing a physical data model, we would expect formatting and null-ability to appear on the data model.
- How Well does the Model Match its Scheme? Here we ensure that the model level of detail (conceptual, logical, or physical), and the scheme (e.g., relational, dimensional, NoSQL) of the model being reviewed matches the definition for this type of model.
- How Structurally Sound is the Model? Here we validate the design practices employed to build the model to ensure one can eventually build a database from the data model. This includes avoiding design issues such as having two attributes with the same exact name in the same entity or having a null attribute in a primary key.
- How Well does the Model Leverage Generic Structures? Here we confirm an appropriate use of abstraction. Going from Customer Location to a more generic Location, for example, allows the design to more easily handle other types of locations such as warehouses and distribution centers.
- How Well does the Model Follow Naming Standards? Here we ensure correct and consistent naming standards have been applied to the data model. We focus on naming standard
structure, term, and style. Structure means that the proper building blocks are being used for entities, relationships, and attributes. For example, a building block for an attribute would be the subject of the attribute such as ‘Customer’ or ‘Product’. Term means that the proper name is given to the attribute or entity. Term also includes proper spelling and abbreviation. Style means that the appearance, such as upper case or camel case (words without space e.g. NoSQL, is consistent with standard practices. - How Well has the Model been Arranged for Readability? Here we ensure the data model is easy to read. This question is not the most important of the ten categories. However, if your model is hard to read, you may not accurately address the more important categories on the scorecard. Placing parent entities above their child entities, displaying related entities together, and minimizing relationship line length all improve model readability.
- How Good are the Definitions? Here we ensure the definitions are clear, complete, and accurate.
- How Consistent is the Model with the Enterprise? Here we ensure the structures on the data model are represented in a broad and consistent context, so that one set of terminology and rules can be spoken in the organization. The structures that appear in a data model should be consistent in terminology and usage with structures that appear in related data models, and ideally with the enterprise data model (EDM), if one exists.
- How Well does the Metadata Match the Data? Here we confirm that the model and the actual data that will be stored within the resulting structures are consistent. Does the column Customer_Last_Name really contain the customer’s last name, for example? The Data category is designed to reduce these surprises and help ensure the structures on the model match the data these structures will be holding.
