Conflict in life is inevitable. Get more than one person in a room to discuss a subject and varying points of view arise. This is the real world. As a data modeler I am often accused of not dealing
with the real world. It is true that logical data modeling, by definition, is not encumbered by constraints of any particular physical data management system, whether it be a flat file,
hierarchical database, relational database, or a card catalog. And it is also true that a logical data model can’t abend in the middle of the night, which is quite unlike the physical systems
which give life to the logical blueprint. But to say that a data modeler does not deal with the real world is like saying life exists without DNA. The real world is exactly what the data modeler in
fact expresses! An unambiguous, semantically correct and logically consistent view of the real world as perceived by those in charge of the business it represents is the goal of a logical data
model. A damn ambitious goal, don’t you think? But meeting this goal provides a stable yet flexible foundation for the continually evolving delivery of application systems which meet the needs of
businesses in the market place.
A logical data model consists of graphical symbols representing real world things and relationships between them. These things are called entities in data model terminology. For example the idea
that a Person participates in a 401K Retirement Plan may be represented in a logical data model. As stated above the goal of a logical data model is to reflect the business rules which govern how
the business defines and carries out its functions. It serves as a communication vehicle to capture and manage those rules. Most business rules are recorded in one of two places, if recorded at
all. They are embedded in the program code which runs in production systems every night. Or they exist in the memories of the business people working with them day in and day out. The logical data
model provides a way to capture and organize the business ramblings and vague utterances of these persons knowledgeable about the business. There are four categories of business rules which the
data modeler captures: definitions, facts, constraints, and derivation rules. The logical data model provides the structure and discipline to catalog business rules. In addition the logical model
is unencumbered by the constraints of any physical technology (e.g., COBOL, VisualBasic, IMS, DB2, ORACLE). This places the rules in a useable form whereby the rules can be the specifications for
the application systems which automate and support the business mission.
Effectively communicating the business rules is what the data model strives to do. However, the diagram and model constructs have not always provided this particular communication benefit for the
business person. The problem is much like a layman being asked to study an electrical wiring blueprint for a house and find flaws in the layout. From a technical standpoint, the logical data model
assists the technical user or system developer to a greater extent, as the representation of the business rules in an organized specification. But all is not lost on the usefulness of the logical
data model for those who are laypersons in the technique of logical modeling. It has been my experience that the value of a logical data model as a communication vehicle does not lie so much in the
diagram and supporting verbiage. The true value of a logical data model as a communication device is in its ability to facilitate the communication that occurs between the business persons during
the process of constructing and validating it. The logical data model provides the catalyst for useful and satisfying interaction to solve a problem, resolve a conflict, or create a consensus of
vision. As long as it retains the ability to get business people to talk and listen to each other, logical data modeling provides a wonderful and relevant means of communicating about the real
world.
