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...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.
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.