All articles on this site is Copyright Craig D. Smith, 2001; (unless otherwise stated).  You may print or distribute.

Critique and Comparisons of Methods and Models

Entity-Relationship modelling has the primary benefit of allowing real world (Stanczyk, 1990, Flory, 1980) representation of the target system. 

The naming of entities is important for an easy and clear understanding and communications. The entity name is often expressed grammatically in the form of a noun rather than a verb.  When selecting an entity name you must test how well the name represents the characteristics and scope of the entity.  This can fall short if the users are not sure themselves i.e. lack of agreement on the business rules.

In the detailed ER model, defining a unique identifier of an entity is the most critical task. These unique identifiers are called candidate keys. From them we can select the primary key which is used to identify the entity.

Another method, source-driven requirements gathering (IBM White Paper, 1998), is a method based on defining the requirements by using the source data in production operational systems. This is done by analyzing an ER model of source data if one is available or the actual physical record layouts and selecting data elements deemed to be of interest.

The major advantage of this approach is that you know from the beginning that you can supply all the data because you are already limiting yourself to what is available. A second benefit is that you can minimize the time required by the users in the early stages of the project.  However, by minimizing user involvement, you increase the risk of producing an incorrect set of requirements.

Depending on the volume of source data you have, and the availability of ER models for it, this can also be a very time-consuming approach. Perhaps most important, some of the user's key requirements may need data that is currently unavailable. Without the opportunity to identify such requirements, there is no chance to investigate what is involved in obtaining external data. External data is data that exists outside the organization. Even so, external data can often be of significant value to the business users. Even though steps should be taken to ensure the quality of such data, there is no reason to arbitrarily exclude it from

being used.

User-driven requirements gathering is a method based on defining the requirements by investigating the functions the users perform. This is usually done through a series of meetings and/or interviews with users.

The major advantage to this approach is that the focus is on providing what is needed, rather than what is available. In general, this approach has a smaller scope than the source-driven approach. Therefore, it generally produces a useful data warehouse in a shorter timespan.

Relational databases, with few exceptions, can be modelled to accept input data effortlessly (the OLTP schema for transaction processing) or to provide good query performance (the "star" schema that is common in data warehousing), but not both (DBMS Magazine, August 1997). The approaches are mutually exclusive at this point, or else they require extensive behind-the-scenes work to perform. Because of their general-purpose approach, they provide no native support at all for modelling or what-if analysis.   One of the requirements (assumptions) of the system was the feature of Management Information systems.

According to the DBMS Magazine feature (August 1997), there has been some movement in this area, especially from Informix Software Inc.'s DataBlades and from Oracle, with impending integration of the Oracle database server with the Express OLAP server.  Express OLAP server is a multidimensional database.  This type of database model is excellent for analysis (multidimensional analysis).

The technique used in Multidimensional databases is to conceptualise business models as a set of measures described by ordinary facets of business.  The result of which is a "business view" model.  It is particularly useful for sifting, summarizing and arranging data to facilitate analysis. In contrast to the techniques for designing On-Line Transaction Systems (OLTP), which rely on entities, relationships, functional decomposition and state transition analysis, Multidimensional databases uses facts, dimensions, hierarchies and sparsity.

A fully normalized OLTP design for an order entry system may have dozens or even hundreds of tables, and making sense of the design for analysis is daunting (DBMS Magazine, August 1997).  Going back to the issue of business rules, the first-attempt "walk-through" of the ER model with the business users typically results in misunderstanding. Multidimensional databases are expressed in a way that is quite natural to business users.

When a customer has a question about their credit card bill, they want to see every transaction. When your overnight package is lost, you want to know who was the last person to see it intact.  This is an area where the relational model excels.

At the deployment stage, a doctor may want to review the medical history of a patient to test for a case of hypochondria.  The multidimensional model is designed to answer the questions that the doctor may have in analysing the patient's history.

However, the relational model has it's place; it has a strong ability to support operational processes, and that is where it belongs.

In this area, the relational model is being challenged by the Object model.  Object DBMSs extend the semantics of the object programming languages to provide full-featured database programming capability, while retaining native language compatibility.  The relationship approach allows for the independence from the application through the use of ER modelling technique at the conceptual level.  Coad and Yourdon (1991) state that the approach in Object-oriented analysis is not restricted to sequential steps, but in the individual object analysis.  This is opposed to identifying all the entities in one step with the relational approach.

Conclusion

There is no perfect database model.  Instead, there are database models for different organisations and projects.  Although not universally accepted as a database model, the Multidimensional database is included in the list of database models:

Hierarchical Systems

Network Systems

Relational

Object-Oriented Systems

Multidimensional method

What is important is that the database approach is taken for the benefits that it provides as opposed to the primitive file system.

Bibliography

Stanczyk, S.K. Theory and Practices of Relational Databases, Pitman Publishing, Great Britain, 1990

Flory, A. "An approach to designing an entity-relationship schema", published in Entity-Relationship Approach to Systems Analysis and Design, P.P. Chen (ed.), North-Holland Publishing Company, 1980

DBMS Magazine, "Multidimensional Modeling", by Neil Raden, August 1997, (Vol. 10, No. 9), Miller Freeman Inc., 1997, http://www.dbmsmag.com

IBM White Paper, Data Modeling Techniques for Data Warehousing. IBM Corp. 1998,