Chapter 6. The Logical Model

only for RuBoard - do not distribute or recompile

In this chapter we explore solutions to the implementation of the general conceptual model (GCM) in data warehouses. One of the key components of our model is the concept of retrospection that was introduced in the previous chapter. Various options as to how it might be implemented are explored in this chapter. In connection with retrospection, the subject of existence, which was discussed in Chapter 3, is developed and used to show how some of the queries that were very difficult, if not impossible , to express using the Type 2 method in Chapter 4, can be written successfully.

Also in this chapter, the solution is developed further to show how it can be transformed into a relational logical model.

In practice, the logical modeling stage of the conceptual?logical?physical progression is now usually omitted and designers will move from a conceptual model straight to a physical model. This involves writing the data definition language (DDL) statements directly from the conceptual model. This practice has evolved over time because relational databases have become the assumed implementation platform for virtually all database applications. This applies to operational systems as well as informational systems such as data warehouses. However, many data warehouses are implemented not on relational data base systems but on dimensional database systems that are generally known as Online analytical processing (OLAP) systems. There are currently no standards in place to assist designers in the production of logical models for OLAP proprietary database systems as there are for relational systems. Even so, in order to produce a practitioner's guide to developing data warehouses, the logical design process must pay some regard to nonrelational database management systems. Where the target database management system is not relational, in the absence of any agreed-on standards, it is not possible to produce a physical model unless the designer has intimate knowledge of the proprietary DDL or physical implementation processes of the DBMS in question.

In this chapter we'll also consider the performance tradeoff . The temporal solutions that are put forward will have an impact on performance. We'll briefly consider the ramifications of this and suggest some solutions.

The chapter then provides recommendations as to the circumstances when each of the available temporal solutions should be adopted. Finally the chapter defines some constraints that have to be applied to ensure that the implementation of the representation of time does not compromise the integrity of the data warehouse.

only for RuBoard - do not distribute or recompile