In the Data Modeling and Database Design in ABAP - Part 2 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 this kind of relationships cause trouble: in general it is not possible to express a relationship with arity 3 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 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 last instalment 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.
