Prof. Hasso Plattner

A Course inIn-Memory Data ManagementThe Inner Mechanicsof In-Memory Databases

September 29, 2013

This learning material is part of the reading material for Prof.Plattner’s online lecture "In-Memory Data Management" taking place atwww.openHPI.de. If you have any questions or remarks regarding theonline lecture or the reading material, please give us a note at openhpi-imdb@hpi.uni-potsdam.de. We are glad to further improve the material.

Chapter 33Handling Business Objects

Enterprise applications are typically developed in an object-oriented fash-ion: Real world objects, such as production facilities or warehouses as well asartifacts like sales orders, are mapped to so-called business objects. A busi-ness object is an entity capable of storing information and state. It typicallyhas a tree like structure with leaves holding information about the object orconnections to other business objects.

Fig. 33.1: Sales Order Business Object with Object Data Guide Representation

As an example, the left hand side of Figure 33.1 shows a business objectrepresenting a sales order. It contains of a header leaf with general information

209

210 33 Handling Business Objects

like the order number, the order date and the customer (business partner).As described in Chapter 3, typically only a small number of attributes of theprovided ones are really used in productive systems. For the case at hand, theleaf storing the delivery terms is not used – this may be the case, when deliveryterms have not been entered in the system, yet, or if the company running thesystem does not maintain this information in its enterprise application. Eachsales order consists of a number of items and they each have an associatedschedule line with information about their delivery dates and quantities.

33.1 Persisting Business Objects

When persisting business object in a relational database model the majorchallenge is to provide e↵ective measures for object querying.

Let us assume that the database only stores the sales order numbers in asales order table and there is an additional table for each of the leaves. Whenextracting the sales order, there is no way of knowing, which leaves are reallyused and therefore one SELECT statement needs to be executed for everyleaf. In case the sales order consists of 50 leaves, of which only 5 are used, alarge number of wasted SELECT statements needs to be executed.

To avoid those unnecessary SELECTs, a business object data guide struc-ture can help to store the information which leaves of a business object arepopulated with data. In our example, the root object stores a bit mask thatcontains the information which leaves are really populated. In the exampleof Figure 33.1, the zero at the second position of the object data guide indicatesthat the delivery terms leaf is not filled with data and a SELECT statement onthat table can be omitted.

33.2 Object-Relational Mapping

Another field of research is object-relational mapping (ORM) integrated inthe database. Object-relational mapping is used to map objects – as usedin most high-level programming languages – to their relational representa-tions as used in relational databases. ORM inside the database is especiallyinteresting for handling business objects on columnar databases.

One reason is the vast number of applications and systems, that are inter-acting with the business data. In contrast to most web applications, businessapplications are highly diverse. To deploy the same view on business objectsthroughout all applications a business objects repository should be used.Such a repository is a central place for business objects definitions inside thedatabase, which are regularly pulled from applications and systems relyingon the business objects. This way of modifying business objects or integrat-

33.2 Object-Relational Mapping 211

ing new business processes (e.g. implemented as stored procedures directlyon the database side) does not require to modify each application’s ORMframework.

Another advantage for business object handling inside the database isthe proximity to the actual data. Object-relational mappers aim at reducingthe usage of “SELECT *” queries, as they often occur in applications. Since“SELECT *” should be avoided when possible on columnar stores, object-relational mapping inside the database can prevent such queries and enforcean e�cient business object handling. One possibility to prevent such queriesis to track regularly requested business objects and only query attributes,which are likely to be used. Any additional attributes, which are unexpect-edly requested, will then incur additional queries. In most cases this trade-o↵between reduced attribute materialization and additional data requests payso↵.

Furthermore, having business objects on the database side allows to im-plement business processes using stored procedures and thus reducing clientapplication code. This way complex business processes can be implementedusing business objects instead of raw relational data.