Application Development Data Modeling Process
The solution is to compile a logical data model of the application (which is then practically 1:1 embodied in classes). It can be compiled both together with the developer (if he can and is ready to participate in the design), and without him (if he is “stupid”).
In this case, the application data model can be equally well represented both in the form of a UML Class Diagram (because classes are primary) and in the form of an ER diagram (because classes correspond to tables).
Case 3. Application supports different DBMS
There are applications that support different DBMS. As a rule, in the data layer (data layer) of such applications, an additional abstraction layer is implemented, which isolates the application from the specifics of the DBMS.
1C: Enterprise, for example, supports 5 DBMS. It turns out that one application can have 5 different physical data models. This suggests a generalization of these 5 physical data models in the form of one logical one – after all, they are essentially the same data. And this will also be the “logical data model of the application”.
If in some place (for example, in the description of the report generation algorithm) you need to refer to a field in the database, then you can not specify 5 different options for different DBMS, but specify the field once from the logical data model of the application.
If colleagues from 1C accidentally read this post, I ask them to clarify in the comments whether they have such an entity as the “logical data model of the application” or not.
Case 4: Large gap between the domain data model and the application’s physical data model
A large gap can arise, for example, in the case of implementing an application by extending the base product (examples are Liferay, Sharepoint, Docushare, Alfresco), which already has a database structure with extension points provided. Or in the case of using a framework that imposes restrictions on the structure of the database.
In this case, the database structure and the domain data model have very little in common.
This situation complicates the development, operation and modernization of the application – for example, it is difficult to compare the attribute of the entity of the subject area and the field of the database table. If the requirement is formulated in terms of the subject area, then it can be difficult to shift it to the implementation.
Building a logical data model for the application can also help in this situation.
On the one hand, it is close to the physical data model, and will easily allow you to translate the requirements formulated in terms of the logical data model of the application into tables and database fields.
On the other hand, mapping to the domain data model is described for it, it is documented and convenient for use by the analyst.
Appendix 3. Mandatory domain data models
How obligatory is the compilation of domain data models?
The conceptual data model of the subject area, from my point of view, should always be. In some cases, it may not be documented as an artifact and exist only in the head of team members – for example, if only a system analyst is involved in the design and this is not the first project in this subject area for him.
But this approach has many disadvantages – the same bus factor, etc. It is advisable to document it.
The need to draw up a logical data model of the subject area, from my point of view, depends on the level of detail of the document containing the requirements (whatever it is called – TK, SRS, FRD, etc.).
If the document is sufficiently top-level, then a conceptual domain data model is sufficient. If the document is detailed, then a logical domain data model is also needed.
If the work on creating an application was started on the basis of top-level requirements (containing only a conceptual data model), then compiling a logical data model of the subject area may be redundant: only the logical data model of the application may be sufficient.
It turns out the following scheme:
Total
It is necessary to distinguish between the domain data model and the application data model.
The conceptual data model is always for the domain, the physical data model is always for the application, the logical data model can be for both the domain and the application.
The logical data model of an application depends on the type of DBMS (for example, relational DBMS and document DBMS), but not on a specific DBMS (PostgreSQL and Oracle can use the same model). The physical data model of an application depends on both the type of DBMS and the specific DBMS.
Depending on the specifics of the project, a different set of data models can be compiled.
Almost always, a conceptual domain data model and one of the logical data models (domain or application) should be compiled.
My personal set, which I use in most projects, is the Conceptual Domain Data Model and the Application Logical Data Model.
In my specific conditions, it turned out to be optimal in terms of “benefit received / effort expended”.
What kinds of data models do you create in your projects?
PS Addendum 4. Microservice data model
I had only one case, which is not enough for any conclusions. Therefore, I placed this block after the “Total” section. If you have a different experience, write about it in the comments – I will be glad to know about it.
The domain data model does not depend on the architecture in any way, including the presence or absence of microservices. But how is the transition from a logical model to a physical one organized in the case of a microservice architecture?
As it was with us. At the stage of collecting requirements “according to the classics”, the conceptual and logical data models of the subject area were compiled.
After the microservices were identified at the design stage and their areas of responsibility were determined, the logical model of the domain was “cut” – which microservice will store which entities. This is necessary in order to pass this piece of the model (along with other requirements) to the sub-team that will deal with the microservice. The application was large, there were many sub-teams, some of them subcontracted. Giving everyone a common model was redundant.
The same entity of the subject area during “slicing” could get into several microservices at once: for example, information about organizations was needed in almost all microservices (with different props).
What is the name of this model? On the one hand, it remains a logical domain model – entities are domain concepts, not tables, the level of detail corresponds to the logical model. On the other hand, it is already partially tied to the implementation – that is, a microservice is defined in which this entity will be implemented.
Thus, between the logical domain model and the application data model (whether logical or physical) there may be another intermediate stage – “the logical domain data model planned for implementation within the application architecture component.”
