Learn not only the HOW, but the WHEN and the WHY also
I think all of us ever had to deal with constructing databases for business applications. As an ABAP Developer, one of our responsibility is to create flexible, consistent, and centralized databases that serves data for many application.
There are many-many possible approaches, methods and best practices to construct good databases that can be confusing. As a beginner, it’s very frustrating, I know that feeling well. When I was newbie in ABAP, I clearly remember for that I just couldn’t choose the appropriate solution, I only could apply that I saw from senior developers in certain scenarios. As a beginner, you don’t have any other chance, so let’s do it!
However, this is the first step to learn something new! Be careful, because you can easily have problems with this learning process, if you don’t go deeper and get more knowledge to understand the given topic in every detail. In this case, you make a huge mistake, since you apply methods that you don’t know WHEN and WHY to use, the only you know is HOW to use it.
To create flexible, consistent, and centralized databases, we have to think as an Architect. To decide which approach to use for building database tables, first we always have to analyze the business requirements, and the existing system environment.
Building database tables with simple built-in types
Let’s check the example below that is about building a database table that contains a few fields. The table, Customer contains general information about our customers, such as the Customer ID, the Customer Name, the Phone Number, the Email, and besides that we want to store their addresses also. We have to store four different types of the address, such as Current Address, Permanent Address, Billing Address, and Shipping Address. I don’t care about the Customer ID, the Customer Name, the Phone Number, and the Email for the sake of the simplicity, instead I am going to focus on the addresses, but note that you can easily apply the same approach for them also.
Get Familiar with the Two-Level Domain Concept
Now comes the magic that is called to Two-Level Domain Concept. This concept helps us to have a better maintainability via abstraction. If you familiar wit the Object Oriented concepts, you can easily understand this concept also. In OO programming, we use interface, and class inheritance to abstract the common characteristics, like common methods, properties. In the ABAP Data Dictionary, we can achieve similar abstraction with the help of Domains.
If we carefully check the different addresses, we can find that they have the same characteristics, namely they all have CHAR data type, with a 60 length. Why should we define and maintain 4 times the same characteristics in different places, if we have Domains?
Why do we need Data Elements?
Alright, we define a domain, ZADDRESS that has CHAR data type, with a 60 length. What now? The problem is that all the addresses have the same characteristics, but they have different semantic meanings:
- Current Address: the address where I live right now,
- Permanent Address: the address where I'm always available, usually my parents’ address,
- Billing Address: the address where I want to get the bill of my order,
- Shipping Address: the address where I want to get my order.
As you can see, we cannot reuse the general ZADDRESS domain in this form without losing the semantic meanings. To solve this problem, let me introduce to you the other participant of the Two-Level Domain Concept, called Data Elements. On the one hand, we encapsulate the technical properties into a single Domain for further reuse, like we did in the case of the ZADDRESS, on the other hand, we are able to reuse that domain, and add semantic meanings to the database fields, using the Data Elements.
So, our task is to take the ZADDRESS domain and reuse its technical properties to build four different Data Elements: the ZCURRENT_ADDRESS, the ZPERMANENT_ADDRESS, the ZBILLING_ADDRESS, and the ZSHIPPING_ADDRESS. They all inherit their data types, lengths, and other properties from the ZADDRESS domain. We only need to give the semantic meaning to the Data Elements that helps us and the others to clarify the usage of the given data element, such as we need to provide a short description, different long labels, a detailed documentation, and so on.
Two-Level Domain Concept: we encapsulate all of the reusable technical information into a single domain, whether it’s an Email, Time, or Date, and then we build different data elements with different meanings to make them more expressive: Email (Work Email, Personal Email), Time (Departure Time, Arrival Time), or Date (Departure Date, Arrival Date).
As we have the different data elements, there is nothing left, than reusing them in our tables. From now on, if we perform any changes on the domain, ZADDRESS, then the system will look for all the objects that refer to this domain and will adjust the sizes for all of them.
Conclusion
This kind of centralization ensures the consistency of our database, since we only have to maintain the properties of a field type on a single place, in the ZADDRESS, nowhere else. Besides, thanks to the centralized ABAP Dictionary, we are able to decrease the implementation costs also, since we can reuse existing types, instead to create a new one, in every cases.
I usually see ABAP Developers who don’t use domains and data elements for building complex databases, instead they use ABAP built-in types. In general, they might think, it’s a waste of time, but I think, it’s the opposite. The built-in types are applicable in simple situations, but when it turns to complex, we should use domains and data elements.
As you could see, applying the Two-Level Domain Concept requires some initial preparation work, but later when you have to modify your data structures, then the cost of the centralized maintenance pays off.
What's your opinion?