Down to the Basics of Business Modeling Concepts

Representing a segment of reality in a computerized database requires a model of that reality mappable to a data structure that provides intelligent information retrieval and facilitates data integrity enforcement.

It should be obvious that the foremost necessity for modeling is a thorough knowledge of the business being modeled. The modeling skills per se are necessary, but not sufficient without such knowledge.

It's also important to recognize that modeling is based on subjective perceptions of reality that vary with the perspectives and informational needs of the constituencies to be served by the database. This is another way of saying that business models are informal, with commonly understood meanings, and there is no formal -- that is, theoretical -- way to prefer one perception over another. The choices made are pragmatic, based on usefulness.

Since business reality is rather amorphous and complex, a useful business model singles out only those reality aspects that are essential, keeping things as simple as possible (but not simpler!). By "simple" I mean reliance on: 1) the most basic terms and concepts available -- language primitives that are deeply embedded in our culture and thinking and, therefore, do not require explanation; and 2) parsimony -- not more concepts and terms than is necessary.

Here are my definitions of the basic modeling concepts.

  • A type is the criterion for membership of an element in a set. We're concerned with two kinds of sets of elements: properties as sets of values and classes as sets of entities.
  • A property is a set of values. The property type is the criterion for membership of a value in the property set; it specifies by enumeration or range the setís legal values and their uses -- meaning, the operations applicable to those values.
  • An attribute is a subset of property values; it inherits its type from the corresponding property.
  • An entity is a unique set of attribute values.
  • A class is a set of entities; the class type is the criterion for membership of an entity in the class -- it specifies:
    1. The attributes shared by entities in the class
    2. Entity distinctness
    3. Any attribute(s) referencing attributes of entities in other classes
    4. Any other business-specific criteria for entitiesí membership in the class.
  • A business rule is a type specification statement. More specifically, a property business rule is a property type specification statement, and a class business rule is an entity type specification statement.
  • A business model is the intersect of the property and class business rules.
I caution the reader that these terms are often used in different, vague, or inconsistent ways. Vagueness, confusion, and inconsistencies can wreak havoc with business modeling and database design. So I urge you to focus on the specific definitions used above and ignore, for the purposes of this blog, any other uses of the terms to which you may be accustomed.

I'll share examples in next month's post. But, in the meantime, let me know in the comments below if you've encountered or used these definitions in different ways.

Fabian Pascal, Founder, Editor & Publisher, Database Debunkings

Fabian Pascal is an independent writer, lecturer, and analyst specializing in database management, with emphasis on data fundamentals and the relational model. He was affiliated with Codd & Date and has taught and lectured at the business and academic levels. Clients include IBM, Census Bureau, CIA, Apple, UCSF, and IRS. He is founder, editor, and publisher of Database Debunkings, a Website dedicated to dispelling myths and misconceptions about database management; and the Practical Database Foundations series of papers. Pascal, author of three books, has contributed extensively to trade publications including DM Review, Database Programming and Design, DBMS, Byte, Infoworld, and Computerworld.

Redundancy, Consistency, and Integrity: Derivable Data

Analysts should not take database consistency for granted. Here's why.

The Necessity of Foreign Keys

A proper understanding of data fundamentals requires the understanding of the importance of keys and primary keys. This time we take a look at another important type of key -- foreign keys.

Best practice?
  • 1/16/2013 5:36:47 PM

Hi Fabian, I like the idea of laying out the definitions in this way. What's your advice on how to make sure people within a company are all working from the same dictionary, so to speak, as they work on their business modeling? Should they have a document with all of their terms spelled out, for example?

Re: Best practice?
  • 1/17/2013 12:02:13 PM

Hi, Beth,

Of course, how businesses do that  makes the difference between success or failure.

The large and complex databases require (1) a formal process (2) management support (3) modeler-user-manager-dba team (4) thorough knowledge of the business (5) data foundation knowledge (6) proper documentation and design tools.

I believe that except for cases of relatively simple databases used by only a few application/users, the current practice of assigning a programmer/developer to do everything from business modeling to database design to database administration to application development will usually end up with serious problems.

The notion that eschewing this saves money and time is an illusion due to scarcity of foundation knowledge: the opposite is true. The argument that modeling and design is difficult, takes a long time, is expensive and so on is certainly true, but there is no free lunch: if you want the benefits of a true db system, that's the price for it, and thinking that you can eschew it and still get the benefits is delusional. You can do it, but then you must do it consciously and aware of the benefits you give up. The ndustry caters to this delusion by promoting magic wands.

Simplicity and parsimony are critical. Given the complex nature of business reality and the above process, it is crucial that we don't pile complexity of methodology and tools on top of it. Everything should be as simple as possible, but not simpler. That's the issue that the relational model addresses and the failure to comprehend that is one of the core problems in IT.

Re: Best practice?
  • 1/28/2013 9:02:07 AM

Good points, more than just a programmer/developer is needed to make sense and hopefully some company profits out of the data massage.

Lots of data, means lots of brainpower is needed to figure the best ways to use it, and the persistence to keep trying new ways of looking at what's going on. It's not the first result that will define the answers.

Re: Best practice?
  • 1/28/2013 1:10:29 PM

All that data were generated for different purposes and, therefore, do not have a common structure to which common sound operations can be applied for analytical purposes. There is this common delusion that such data can be taken as is and, without any effort, can be mined for information.

Another aspect is a disregard for the cruacial importance the ratio of method and tool complexity to usefulness. The purpose of models is to simplify the reality of interest to the most essential and to structure it optimally for multiple analytical purposes. Complexity and lack of generality defeats their purpose. This is largely missed by both business and IT and the industry encourages the opposite.

Codd's genius was not only to apply theory to data management, but also that the theory provides an optimal ratio of simplicity to generality: the relational approach is the simplest way to deal with data that is general enough to handle a vast majority of informational needs. In my paper "Businss modeling for database design" I specify the criteria that an alternative approach must satisfy to be superior. Unless it does, we trade down. The trite statement "the right tool for the right job" more often than not reflects a lack of foundation knowledge.

Best regards,
Fabian Pascal