Configurative Reference Model-Based Development of Data Warehouse Systems

Developing Data Warehouse Systems requires specifications of the underlying business need in the form of information models. The development of information models is often both expensive and extensive. Against this background, reference models provide useful means to reduce the costs of information modelling, because they can be used as a starting point for the construction of project-specific information models. However, reference models only provide benefits if the reduced effort resulting from their application is not overlapped by the adaptation costs. In this context, configurable reference models comprise rules which allow modifications of the original reference model depending on company or project individual determinations of configuration parameters. This paper provides concepts for a reference model-based Data Warehouse System development. Extensions of multi-dimensional modelling techniques are proposed which allow for configuring reference models. Moreover, influences of these reference models on the Data Warehouse engineering process are discussed and an appropriate tool support is presented. 1. MOTIVATION From a business perspective, developing Data Warehouse Systems is an integrative task of organisational and application system design. Within the organisational scope, it is necessary to identify what kind of data has to be provided to whom (decision maker) for what kind of management decision (Holten 2003). Within the application system scope, it is necessary to implement the underlying data basis whereupon this task comprises selection and configuration of relevant Software and Hardware components for the Data Warehouse System architecture (Inmon, Hackathorn 1994). In this context, information models foster the structuring of the two design areas (Karami 1988; Kotterman, Konsynski 1984). Depending on their technical relationship, information models are e. g. divided into the phases requirements definition, design specification, and implementation (e. g. Scheer 1992). Requirements definitions specify original business demands as they describe “what” the