Using a Fact Model to verify a Data Model

One of the main problems with verifying that a structured data model correctly defines the facts that have been provided by the Subject Matter Experts (SME) about the business is that frequently the modelling notation, whether UML, ERD, ORM or XSD, may be unfamiliar to the SME so they are unsure about what exactly is being said. Even when the basic concepts of a data model are explained there is still concern that the SME might misinterpret the model and sign-off something that is actually incorrect.

Often these mistakes will result in additional downstream cost once the mistake is discovered and remedial work is carried out. To avoid ambiguity or misunderstandings it can be useful to use a Fact Model to express the facts in "natural language" so that they can be read as a set of individual statements that are more easily comprehended and individually verified by the SME.

For example, take the following model fragment (in the UML notation):

An experienced data modeller or software developer would quickly identify the following facts (amongst others):

• A Consolidated Account is a type of Sales Account.


• A Customer Account is a type of Sales Account.


• A Consolidated Account aggregates one or more Sales Accounts.


• A Sales Account must have a Registered Address which is a valid Address.


• A Sales Account must have an Account Number which is a valid Account Number.


• A Sales Account may have a Credit Limit …


• A Sales Invoice must be Posted To one and only one Customer Account.


• ...and so on

As a set of definitive atomic statements I think it is much easier for the SME to review each of these facts and confirm whether it is correct or not and, if it isn't correct, amend it.

Facts can also be used to explain or elaborate less obvious features of a model, such as rules captured as constraints on a Class, Attribute or Relationship. For example, all of these facts are in the model but not part of the diagrammatic representation:

• An Address must have a Building Number or Building Name.


• An Account Number is a numeric string of exactly six digits


• A Customer Name is an alphanumeric string up to 40 characters in length.


• ...and so on

OK it can be a bit tedious pouring over 1000's of statements but with a complex data model there are a lot of benefits to breaking down the model this way when it needs to be verified with the business stakeholders, some of which are:

• Each fact is expressed atomically, i.e. cannot be reduced to even simpler facts, so reviewed independently of any other fact.


• Being a "natural language" the reader has better comprehension of what each fact is actually stating.


• The Fact Model can be distributed as a text document to multiple recipients who can read and amend it without requiring access to the modelling software used to create the original model.

Not so long ago producing a Fact Model was a standard feature of most data modelling software (and is still a part of some such as Oracle Designer) but seems to have fallen out of fashion with the newer modelling languages such as UML and XSD.

However, if there is a lot of formal data modelling being performed then a Fact Model can be very useful and well worth investing the time to create an appropriate language (or using one of the established languages such as NORML or SBVR) and reporting capability.