Skip to Content
Author's profile photo Former Member

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

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



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> , …. }


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!

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Hendrik Brandes
      Hendrik Brandes
      Hello Jürgen,

      very interesting blog!

      We have done some research in this area and believe that a DWDL makes more sense than today expected.

      But, our intention, when we first designed such a language, was to build a language, which a customer can learn and whose reflect the elements of his business. E.g. we do not want to have a technical abstraction - instead of having a business abstraction with a few technical hints.

      Even, if 730 has a automated data flow generation, I think the existence of a Domain-Specific-Language (DSL) for business needs and a tool for generation all items will bring more agility and shorter implementation-time to a BI project. If the language is designed for the project and the specific customer, even the consultants will benefit from it.

      For our next steps we plan to implement the DSL definition and generation native with ABAP, so we can do a lot things in the backend of netweaver without having any additional tools. BTW: Not only for BW/BI Objects...

      Kind regards,

      Author's profile photo Former Member
      Former Member
      thanks for your reply.
      Your idea about a Domain-specifc language is very interesting and keep me informed what's new with it.
      You're right a DWDL is technical and business don't want spend too much time in technical details. From my experience the transformation from business to technic requires good know how of both. That's the step where most of the errors happen, because of misunderstanding, wrong assumptions about system behaviour and more. So an experienced consultant writes a technical specification or concept, which objects have to created, which can be re-used, how cubes and DSO during staging are designed and how the transformation from one object to the other looks like. He does the transformation from business to technic and will still do for a while, in my personal opinion. This is very technical and I think a DWDL would help here a lot. The consultnat will still have to design and desscribe the objects, but he will also generate a script during this phasis. The script allows to generates all objects or returns error if assumptions were wrong.  

      As you say, the next step will be to write a first implementation in ABAP for use in SAP BW and spend more details on the language itself for syntax, parsing, etc.

      Kind regards,

      Author's profile photo Tammy Powlas
      Tammy Powlas
      I find myself putting all the InfoObjects in a spreadsheet and then cutting and pasting into BW

      I also write lots of documents about the InfoProviders and DSOs

      So I think this would be a great start "out of the gate" for sure.