Homepage (deutsch) Firmenprofil (deutsch) Tools (deutsch) Homepage (English)

WS

Exploiting OO in Data Warehouse Applications

Wilfried Schollenberger
Paper held on SEUGI 1996 in Berlin

Abstract

The new features of SAS Orlando, in particular composite widgets, the MVC (model/view/ controller) architecture, and the support for drag and drop, enable the implementation of new concepts for the user interface and the technical design of applications. Furthermore the benefits of a data warehouse can be improved by providing classes to access the data. A carefully designed OOAD environment allows building applications without using SCL in the FRAME entry.

This paper discusses the principles which have to be observed when setting up such an environment in order to achieve the best performance. The demo shows a class library which supports a drag and drop based user interface and an object oriented access to a data warehouse. The class library shown in the demo is designed to be built in an OO workshop of one week.

Introduction

The new features of SAS Orlando enable application developers to create powerful user interfaces in a much easier way than before. Drag and drop capabilities and the Model Viewer Controller (MVC) architecture lead to new user interfaces. Looking for user interface standards we have to recognize that standardisation is currently behind the state of the art. So I will discuss how user interfaces can be designed, exploiting the new features and being user friendly, easy to understand and easy to use. This will be the first part of my paper.

The improved implementation of the object oriented approach with composite widgets and the MVC architecture leads to new challenges when we want to use them in the best way. New strategies for developing classes become possible. But when we design classes, we should keep in mind, that the SAS System overall is a powerful tool, and that we are working for a particular purpose: information delivery systems. In the second part of my paper I will discuss some principles which, in my opinion, should be observed during the object oriented analyses and design.

Regarding the concept of data warehousing, I also want to discuss where different responsibilities should be located. As far as I can see, it is state of the art of application development, that the developer of a database should also provide the methods to access it. So we have to distinguish between classes, which should be part of the data warehouse, and classes which have to be located at the application development departments. In the third part I will show, how this can be implemented.

In the end, I want to show how easy application development can be, when the classes are well designed.

User Interface

Some years ago, we talked about

In my opinion all the results are still valid, though some are obsolete thanks to some software companies developing operating systems. But with drag and drop some questions changed:

In a number of tasks drag and drop is much easier and faster than any other technique of graphical user interfaces. But the interface should be consistent. So if we use drag and drop at all, we should provide such a mean additionally even if the task could be performed by another technique as well.

What is an intuitive graphical user interface? Let's have a look at the following example:

Obviously it is an information system. But without any additional information, no one would be able to use it. As before, when we got pull down menus, tool bars, and cut and paste, we have to get some general information about this kind of an interface.

In this case it could be as follows:

Object Oriented Analysis and Design of Classes

I do not attempt to repeat the whole philosophy of object oriented application development in this paper. There are some rules, how to do an object oriented analysis, but mainly it is a matter of experience. So you should not expect, that all your classes will be reused, when you build an application in the object oriented way for the first time.

Regarding the SAS System in my opinion it is reasonable to discuss, whether an application should be built in the object oriented way at all, since the SAS System also provides other powerful features, which support a modular design of applications and keep them maintainable.

But when we look at the data warehouse concept and distributed application development, where parts of the applications are developed in none EDP departments, the object oriented approach is a good mean to support this. Then the EDP departments support the other application developers by providing classes in order to ease their work and to support central maintenance. In this case the classes have to fulfil some special requirements:

The MVC Architecture

Before i am going to introduce the class library used in the example above, we must take a closer look at the Model/Viewer/Controller (MVC) architecture implemented in SAS Orlando (Figure 2).

The MVC architecture consists of 4 classes:

Usually there is at least one additional object involved to provide the data. On our case it is an instance of the Data Set Model class.

When the viewer object is determining the column and row dimensions of the display, it calls the _GET_COLUMN_INFO_ and the _GET_ROW_INFO_ methods of the controller object. The controller object calls methods of the Row Column Data Vector class to provide the information requested in this class. When the user modifies the display, e.g. resizes a column with the mouse, the _SET_COLUMN_INFO_ or the _SET_ROW_INFO_ methods of the controller object are called. In the same way the data is passed via the Data Vector class and the _GET_DATA_ and _SET_DATA_ methods. The viewer object is responsible for instantiating the controller and the utility classes. Then most of the logic is handled by the controller class.

For example: If you want to get the position where a user drops something on a table editor in coordinates of rows an columns, you have to overwrite the the drag and drop event methods to the controller class, rather than the ones of the viewer class which only work with pixels.

But in order to simplify the instantiation of such a table, you also must subclass the viewer class, because there you can fix the name of the controller class, and you can provide your own attribute screen to make the instantiation process easier.

The MVC architecture allows to display different kinds of data, e.g. SCL lists and SAS datasets with the same viewer class. It is also possible to create different controller classes for different datasets. But in this case you have to copy parts of the application logic to the different controller classes. In order to avoid this an additional distinction is necessary: to separate the data access from the application logic which is implemented in the controller class.

The OO DWH Extension

Following the philosophy of the data warehouse approach, the application developer should have a subject oriented interface to the data warehouse which is maintained by the people who are responsible for the data warehouse. Therefore we need a mean to access data in the data warehouse on an object oriented level, that is by a class which provides the data and the metadata. An implementation of this concept is the Motore engine in the OLAP++ extensions of SAS/EIS software. The engine provides all the necessary information and data for the objects on the screen encapsulating the real data access.

When you set up a data warehouse you can also provide means to access this data in the object oriented way. You have to define, how the classes to access this data should be set up, which methods they have to provide, and so on. Then application developers can use these classes and the data warehouse people can maintain the physical structure of the data warehouse and the corresponding access methods without forcing the application developers to maintain their applications. Additionally application developers can develop a set of classes to handle selections and display data, which can easily be used for a wide range of applications. Then we arrive at a layout like the one in figure 3.

The data access classes provides data and meta information to the different application classes. The selection of data, slice and dice, is mainly handled by dimension classes, but of course, the controller is also able to call the appropriate methods of the data access class, e.g. during a drill down.

The data display class, which is in fact a composition of different reusable classes, gets the data and the information how to display it from the data access class. In order to provide the drag and drop capabilities shown in the example above, the application developers have to define and to implement the representation and the actions of the different drag and drop actions.

Demo

The following demo is set up with a set of simple classes. They are developed in order to show the philosophy behind this concept and the main technical means to implement it. It is an environment to implement the application above with any SAS dataset.

First we instantiate a data access class as a widget object. This avoids subclassing the Frame class and the use of additional SCL code. The other objects can easily locate this widget and you can use more than one data access class in one frame. In the demo class we do not use any metabase, so we have to define the dimensions and the values to display manually.

Then we instantiate the different application classes in any order. The display object needs the name of the data access object, which can easily be determined by a double click at build time. The dimension objects need the name of the data access object and the name of the dimension they have to handle. The rest, especially the communication between these objects can be set up a runtime by these objects themselves. The data access object plays the major part, since it receives and sends all important messages. The dimension objects and the display object use the the drag and drop methods to exchange the necessary information directly.

When you want to further develop your data warehouse, you only have to maintain your existing data access classes. For example: When you decide to use the SAS/EIS metabase, you need a different class which accesses this metabase. But you do not have to change your application classes, since you already have a defined interface.

Summary

The SAS System provides all the necessary means to set up a powerful object oriented environment for EIS, MIS and DSS systems. In my opinion it is impossible, at least it is very difficult to set up a standardized tool to provide a subject oriented access to the data warehouse, since you would have to take care of many special problems like changes of the organization over time. But it is better, to handle these problems once when setting up a data warehouse than to do it often when developing an application or always when accessing databases.

Setting up reusable classes requires a reasonable amount of experience, and this applies to classes to access data in a data warehouse as well. With the SAS System it is quite easy to get this experience starting with simple cases. Later on, when you address the more complicated cases, the power of the SAS System assures that you will be able to build the appropriate elaborated classes.

Note: SAS and SAS/EIS are registered trademarks of SAS Institute Inc., Cary, NC, USA.

Copyright © 1996,1998:
Wilfried Schollenberger

WS Unternehmensberatung und Controlling-Systeme GmbH
Friedrich-Weinbrenner-Straße 20
D-69126 Heidelberg

Tel.: +49 6221 401 409
Fax: +49 6221 401 422
EMail: wisch@ws-unternehmensberatung.de


All Rights reserved