When it comes to operational, third normal form approaches, too many database models today have very low levels of business veracity. This is because current IT trends work against incorporating too much truth inside the entity-relationship diagram. Instead, development teams center on the finished product and excessively worry about describing a solution rather than describing the actual organization.
Developers and managers pressure database designers to create models that align with the development-focused solution over the option of doing an accurate job expressing the business data. This causes models to be "lite" versions of the business rules surrounding the solution space rather than describing the organization in a head-on fashion.
One item marking this business-rule-depletion is the use of surrogate keys across most entities within the design. By heavily relying on surrogates, the business items that identify objects become lost - they may possibly be listed, at most, as candidate keys, but nothing more. As well, models fortified with surrogate keys often have virtually every entity defined as a strong entity, whereas existence dependencies, more often than not, are undocumented. This lack of weak entities dismisses the possibility of expressing subtleties such as: Customers needing to exist before their Customer Address, or Orders needing to exist before their Order Lines, and so forth.
There are times and places where the interactions expressed by these associative business rules are truly important. It would be unusual, if not irrational, for a business to establish an Order Line before an Order is considered. Such a circumstance is indeed putting the data cart before the object horse. However, today it seems more important to have a data model not riddled with ungainly composite keys than for the data model to drive the order whereby objects may be created.
High veracity database models reflect the semantics of the organization. They provide very detailed explanations of the nature of the data important to a business just by reading across the logical entities, relationships, and attributes. These models express the actual business attributes that are uniquely identifying objects, along with which objects must exist before others, as well as the data-driven nature of the associations between objects.
Logical database models should allow their observer to review the model’s content, and in so doing learn about the organization and data within the solution space. Lower veracity data models only provide fuzzy high-level descriptions of the business; the detailed rules are not to be found. Semantics directly extrapolated from a low veracity design may be overly abstract or even contradictory to reality.
As mentioned above, trends in database modeling today work against the need for accuracy and detail in describing the business. Developers and project managers dismiss most efforts to model such details as extraneous, time-consuming, or simply too tedious. This attitude leaves more and more rules unexpressed within the database model. If such were not the case, we might see many logical models with complex composite primary keys itemizing the trickling down of existence dependencies across a host of tables. When these aspects are hidden outside of the database model, those rules and relationships still exist, only buried somewhere within the code populating and maintaining those databases.
One can only hope the right people can always find those rules when needed. To combat this result, designers need to advocate even more for a proper design, regardless of whether or not that compromise leads to exchanging one sin for another, by creating circumstances where the physical model contains abstracted low veracity elements while the logical model retains a high veracity description. Having wildly variant logical and physical models is very painful to maintain over time; but not having any database model with the real business rules is fundamentally worse.