Data modeling and database design in ABAP, part three

Learn modeling techniques for database design and data modeling in ABAP with this multi-part series. Part three expands on the SAP structured entity relationship model (SERM) and bridge the gap to ABAP Business Objects.

Data modeling and database design in ABAP -- Part 1
Data modeling and database design in ABAP -- Part 2

In the last installment of this blog series, I introduced SERM concepts and relationship types. Now I will discuss further details and bridge the gap to ABAP Business Objects.

Relationship types with arity three: referential relationship types

In my opinion, the SAP documentation of the Data Modeler (BC-DWB-TOO) about referential relationship is hard to understand because it is not said explicitly that you need it for relationship types with arity three. But this becomes obvious if you look at the given example of the SAP library in detail: professors give courses in faculties. Before I present the SER model let me mention that usually these kind of relationships cause trouble. In general, it is not possible to express a relationship with arity three by binary relationships. Just look at following ternary relationship:

Professor       Course               Faculty
Dr. White       Measure Theory       Numerics
Dr. White       Statistics           Stochastics
Dr. Greene      Scientific Computing Numerics
Dr. Greene      Measure Theory       Stochastics
Dr. Greene      Statistics           Stochastics

Usually it is left as an 'easy exercise' to a student to prove that it is not possible to express this relationship by three binary relationships. By the way, does anybody have a short proof for the general statement?

In SAP-SERM we model this relationship by a so called referential relationship type. The entity type course depends both on professor and faculty so it is natural to express the relationship this way. Usually we have to take define a composite key with three components for the transparent table course.

Weak existence dependency

Sometimes existence dependency is called strong. The reason is that SAP SERM knows the concept of weak existence dependency. Let me give an example. Just imagine a 1:CN cardinality between source and target entities but the relationship is time depended so it possible that (perhaps for a certain time) some target entities are not related to a source entity. In this case we have a C:CN cardinality and called weak existence dependency. In a referential relationship type following cardinalities make sense: C:1, C:C, C:CN and C:N.

It is trivial that weak existence dependency doesn't make sense in the context of hierarchical relationship types but for referential and aggregational relationship types. In this case we speak of conditional-referential resp. conditional-aggregational relationship types.

DDIC integration

One further strength of the SAP Data Modeler is the DDIC integration. You can use the SAP Data Modeler for conceptual modelling but it is possible to link entity types to transparent tables and database views. Also you can set the customizing flag to show that a certain entity type corresponds to a customizing table.

Why Business Objects matter - SERM and UML

As I explained in the last installment of this weblog series, we can define data models for Business Objects that contain the entity types belonging to the business object - the business data. So Business Objects allow an integrated description of the structure in SERM and the behaviour (described by their methods).

We can use this integrated description of object data and object behaviour during the design phase of a software system. In object oriented design we model the software system perhaps using UML. If we want to create a relational data model from the object model, we have to translate UML elements to SERM -- entity types correspond to classes, entities to objects, a hierarchical relationship corresponds to composition, a referential relationship corresponds to a association and so on. The question, which UML elements correspond to the following SERM elements, is left as an easy exercise: entity type attributes, entity attributes, aggregational, conditional-aggregational, conditional-referential and referential relationship type.

On the implementation level, Business Objects offer even more, for example:

  • standard interfaces, think of SAP Archive Link integration by the use of generic object services,
  • event processing using asynchronous messages,
  • workflow integration, and
  • a concept of generic object identity by object type and object ID

In my opinion, business objects are far from being obsolete although their editor as well as their API are outdated. But we should still use them to define the main classes of our application and define their corresponding data model. Usually we should use the methods of a business object only as a wrapper and call an ABAP method to use the superior features of ABAP objects.


This content is reposted from the SAP Developer Network.
Copyright 2006, SAP Developer Network

SAP Developer Network (SDN) is an active online community where ABAP, Java, .NET, and other cutting-edge technologies converge to form a resource and collaboration channel for SAP developers, consultants, integrators, and business analysts. SDN hosts a technical library, expert blogs, exclusive downloads and code samples, an extensive eLearning catalog, and active, moderated discussion forums. SDN membership is free.

Want to read more from this author? Click here to read Tobias Trapp's weblog. Click here to read more about ABAP on SDN.



This was first published in December 2006

Dig deeper on SAP ABAP

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchManufacturingERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchCRM

SearchContentManagement

SearchFinancialApplications

Close