You are on page 1of 4

Prof.

Hasso Plattner
A Course in
In-Memory Data Management
The Inner Mechanics
of 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 at
www.openHPI.de. If you have any questions or remarks regarding the
online 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 33
Handling Business Objects
Enterprise applications are typically developed in an object-oriented fash-
ion: Real world objects, such as production facilities or warehouses as well as
artifacts like sales orders, are mapped to so-called business objects. A busi-
ness object is an entity capable of storing information and state. It typically
has a tree like structure with leaves holding information about the object or
connections 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 object
representinga sales order. It contains of a header leaf withgeneral 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 the
providedones are really usedinproductive systems. For the case at hand, the
leaf storing the delivery terms is not used– this may be the case, when delivery
terms have not been enteredin the system, yet, or if the company running the
systemdoes not maintain this information in its enterprise application. Each
sales order consists of a number of items and they each have an associated
schedule line with information about their delivery dates and quantities.
33.1 Persisting Business Objects
When persisting business object in a relational database model the major
challenge is to provide effective measures for object querying.
Let us assume that the database only stores the sales order numbers in a
sales order table and there is an additional table for each of the leaves. When
extracting the sales order, there is no way of knowing, which leaves are really
used and therefore one SELECT statement needs to be executed for every
leaf. In case the sales order consists of 50 leaves, of which only 5 are used, a
large 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 are
populated with data. In our example, the root object stores a bit mask that
contains the information which leaves are really populated. In the example
of Figure 33.1, the zero at the second position of the object data guide indicates
that the delivery terms leaf is not filled with data and a SELECT statement on
that table can be omitted.
33.2 Object-Relational Mapping
Another field of research is object-relational mapping (ORM) integrated in
the database. Object-relational mapping is used to map objects – as used
in most high-level programming languages – to their relational representa-
tions as used in relational databases. ORM inside the database is especially
interesting 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, business
applications are highly diverse. To deploy the same viewon business objects
throughout all applications a business objects repository should be used.
Such a repository is a central place for business objects definitions inside the
database, which are regularly pulled from applications and systems relying
on 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 directly
on the database side) does not require to modify each application’s ORM
framework.
Another advantage for business object handling inside the database is
the proximity to the actual data. Object-relational mappers aim at reducing
the 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 enforce
an efficient business object handling. One possibility to prevent such queries
is 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-off
between reduced attribute materialization and additional data requests pays
off.
Furthermore, having business objects on the database side allows to im-
plement business processes using storedprocedures andthus reducing client
application code. This way complex business processes can be implemented
using business objects instead of raw relational data.