Have you ever thought about a Data Warehouse Definition Language (DWDL)?

[Former Member]

If you build new BW applications, you normally start from a concept or business blueprint. The business blueprint will be translated into a technical concept which describes the necessary infoobjects, used content, how the DSOs and cube sould look like for the application. Then you sit in front of your PC and start to enter the information from the concept paper into the SAP BW system manually. You or your team will generate all needed objects one after the other. This process takes dependent on the complexity of the application from days to weeks.

In software development automatism in creating code and application has developeed over the years and now you are able to create reliable and stable applications in less time than 5 or ten years ago. I just wondered, why is this not possible for building data warehouse applications? What is special? One day I got the idea, why not using a Data Warehouse Defintion Language (DWDL)?

This language could be very sipmle for the beginning. It would be very sufficient if this language allows the user to create the needed objects and activate them. The fine tuning and optimizing can be done by the BW devleoper or consultant who is specialized in backend. In the begining of building a BW application, the creation of the needed objects takes most of the time. If you had a tool which helps to decrease this time, you would have time for other and more important tasks in the project. So I made a very first design of this language. Some definitions I need:

h4.  = Technical name of the object

<DWType> = BW Object, like DSO, Cube, Multiprovider,...

<DWElement> = Infoobject

<CubeDimensin> = name of the dimension in cube

<BasicType> = char, integer, date, time, .... 

<Trans> = Bw 7.x Transformation

 }. 

2.) DELETE ELEMENT <DWElement>

3.) CREATE <Object Name> as <DWType> using { (<DWElement> [ in Dimension <CubeDimension>] | in key part | in data part ), ... }

4.) DELETE <Object Name>

5.) CREATE TRANSFORMATION <Trans> from <Object Name> to <Object Name> matching  { <DWElement> = <DWElement> , .... }

6.) DELETE TRANSFORMATION <Trans>

Further enhancements are possible, MODIFY statement should be possible but will be more complex than CREATE / DELETE

h3. The advantages from my point of view:

• Language is potential plattform or data warehouse independent. The concreate implemention is system / warehouse dependent. It allows e.g. easy creation of "identical" objects for many different warehouses if you think of a complex landscaoe with many different warehouse systems.

• Easy to learn and understand, similar to SQL

• allows automated generation of objects from concepts, no manuall transfer necessary. Supports further automated data flow generation.

• Reduces time, and therefore costs, in BW projects

• Logs and pseudo-versioning possible ( e.g. save different versions of the generation script ) 

• Enhanced Error and Exception handling in creation / deletion of object can be coded in the system dependent ipmlementation

h3.  The disadvantages from my point of view:

1. Only for first generation of objects helpfull. Optimization, enhancing and programming of rules still necessary
2. Potentially no big wins in BW 7.3 where automated data flow generation can be used
3. XML Export / Import of objects does exist and can be used.
4. BW consultant / developeer have to learn an additional language 

For me, a DWDL has a lot of advantages, but also some disadvantages.

The implementation could be in ABAP or in JAVA for SAP BW. SAP provides an interface to generate or delete the most needed objects. In my personal opinion a DWDL would also reduce the complexity and help to understand what's going on behind the scenes if you look into the system dependent implementation of this language.

But now I want to give the ball to you!