Object Modeling vs. ER Modeling

Early approaches to data modeling were designed to simplify the construction of relational databases. Thus, these methods focused on representing entities and relationships, which would ultimately be implemented by tables in a relational database. The attributes of each entity became columns in a table, and the relationships between entities became either foreign keys (with one table pointing to another) or intersection tables (containing the keys of two or more related tables).

Object-oriented analysis and design takes a process-oriented approach rather than a data-oriented one. You define objects by their behaviors (based on use -- cases are documented during analysis), and the re lationships among objects represent interactions, generally described as requests for service from o ne object to another. The information required to represent an object is defined as part of that object and is available to other objects only by request.

The limitation of each approach is exactly the strength of the other. Entity-relationship (ER) modeling lacks any sense of process, so such models must be augmented by process models, create/retrieve/update/delete (CRUD) matrices, and other design templates that capture the characteristics of the activity or business process that the database must support. Object models lack a direct connection to database schemata, so they provide little guidance regarding the physical construction of a database.

Kroenke's Semantic Object Modeling system uses an object approach at the conceptual level, representing semantic objects that can be described by a combination of data- and action-oriented attributes. Kroenke's goal is t o develop tools that can "compute" the database schemata and even the application (i.e., entry and retrieval forms and the transition from one type of object to another) from a user's description of the semantic objects involved. Emphasis on semantics rather than on tables puts design decisions into the hands of business analysts and users rather than programmers. This makes the resulting applications and databases easier to understand and change.