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:
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.
- The attributes shared by entities in the class
- Entity distinctness
- Any attribute(s) referencing attributes of entities in other classes
- Any other business-specific criteria for entities’ membership in the class.
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.