0.2 Introduction to algorithms  (Page 6/8)

In an alternative framework, called the Zachman Framework , a data model instance may be one of six kinds (according to John Zachman , 1987):

• a conceptual data model (schema) consists of entity classes (representing things of significance to the organization).
• a contextual data model (schema) describes the semantics of an organization. This consists relationships (assertions about associations between pairs of entity classes).
• a logical data model (schema) describes the semantics, as represented by a particular data manipulation technology. This consists of descriptions of tables and columns, object oriented classes, and XML tags, among other things.
• a physical data model (schema) describes the physical means by which data are stored. This is concerned with partitions, CPUs, tablespaces, and the like.
• a data definition This is the actual coding of the database schema in the chosen development platform.
• a data manipulation describes the operations applied to the data in the schema.

The significance of this approach, according to John Zachman, is that it allows the six perspectives to be relatively independent of each other. In each case, of course, the structures must remain consistent with the other model instances although the details change. The table/column structure may be different from a direct translation of the entity classes, relationships and attributes, but it must ultimately carry out the objectives of the conceptual entity class structure and contextual relationship structure. Zachman regards each instance as a separate perspective of the database not a methodology, however development projects and software tools often proceed from conceptual data model , to contextual data model , followed by the logical data model . In later stages when the database platform is known, this model may be translated into a physical data model followed by the data definition . When the database is operational data manipulation takes place.

Different modelers may well produce different models of the same domain. This can lead to difficulty in bringing the models of different people together. Invariably, however, this difference is attributable to different levels of abstraction in the models. If the modelers agree on certain elements which are to be rendered more concretely, then the differences become less significant.

There are generic patterns that can be used to advantage for modeling business. These include the concepts PARTY (with included PERSON and ORGANIZATION), PRODUCT TYPE, PRODUCT INSTANCE, ACTIVITY TYPE, ACTIVITY INSTANCE, CONTRACT, GEOGRAPHIC AREA, and SITE. A model which explicitly includes versions of these entity classes will be both reasonably robust and reasonably easy to understand.

More abstract models are suitable for general purpose tools, and consist of variations on THING and THING TYPE, with all actual data being instances of these. Such abstract models are significantly more difficult to manage, since they are not very expressive of real world things. More concrete and specific data models will risk having to change as the environment changes.