So different logical data models

Not far ago I meet a big problem in understanding logical data modeling, which lead me to an idea to show the difference between logical models.

First thing is that word ‘logical’ in phrase of ‘logical data model’ is about detailed elaboration, not about implementation purposes. In other word, you can have two models one to describe e.g., business domain entities relationship, and one to describe tables composition in data base. Each of this model can be logical, but one should have purpose to communicate with business and one to communicate with DBA or tech specialists. It is obvious, but I’ve seen, that some people are confused about it. I think it happens because in Software Architecture your domain model implements somehow directly from model. So if you have entities with some relation, you implement its function and operations in code from model directly, or change model.

But in data architecture there is different situation. Most optimization do not lay down in inner structures. E.g., in software modelling you optimize function as inner structure, in data modeling you cannot optimize ingesting source just by data types, you will need optimal storage, joins paths, and other. So you may have two models, one for optimal process and business communication presentation, and one for optimal processes working with data.

Let’s name those models by it’s layers names. For example ‘Domain Logical Data Model’, ‘Implementation Logical Data Model’, ‘Enterprise Logical Data Model’ and look there are their place in Enterprise data model (EDM):

Fig. 1: Model composition. Composition idea was got from DMBOK-2nd Ed. Technics Publications, 2017

The main misunderstanding here is that Domain LDM is different from Implementation LDM. The goal of any models is to communicate. And Data Architecture is a bridge from business to technologies. But you can not directly translate from one to other, to make that bridge you may have two communication models, one for translation a concepts (mostly used by developers) and one model for optimal implementation (mostly used by DBA). That is the difference. And developer and your DBA should understand not only what and how he or she should do, but why he or she implementing it. On other hand stakeholders should understand what are tech specialists are doing. No matter how good and experienced are you, but command work with all sides will give you more insights and more value in your models than you try do it by yourself. Everyone will be grateful if you will maintain not only tables structure and connection information, but business logic in your data models.

Let me show you the example of all this layers and modeling transformation. Imagine we want to develop system that help us to get data about car. This is abstraction and will not have relevant business logic, we just need it to illustrate principles of modelling transformation.

Fig. 2: Enterprise CDM dummy example

We have some concepts here and can understand some things about business process. We can obtain from model such things as:

· Wares are enumeration. And business has list of it;

· Wares has some installation processes;

· Cars have some permitted related processes;

· So not every ware from list can be installed in car (because of car relationships).

This model is good to understand data boundaries and data concepts in enterprise vision on your data. All this information is provided on high level, this is the main concepts that mark boundaries for lower generalization levels (look at fig. 1) and you should elaborate it in lower-level models in this generalization level.

Let’s dive a bit deeper in enterprise LDM:

Fig. 3: Enterprise LDM dummy example

How much enterprise vision we can get here? We can get more detailed assumptions about our data and business, like:

· We have important car attributes that we should maintain

· Wares have installation place and influence on car attributes

· Processes has outer permissions from car, and inner constraints (we do not know why for now, but know that constraints exist).

· Ware can have more than one related processes.

Wow, that’s a lot of new information! So our understanding is more complex now. But level of generalization is the same! We cannot use this as model for domain or subject area or product model, because we need details not in model, but we need details in vision point, and what is not very simple process. One cannot just get enterprise logical data model and transform it in domain logical data model. It is transformation and metamorphose of model. Let us transform it from enterprise to domain and from domain to implementation. We will not dive into techniques but illustrate the main principle.

Let’s look how we can transform our simple enterprise LDM to complex Domain LDM:

Fig. 4: Domain LDM dummy example* (sorry for mistype, there is “vehicle”, not “vencil”)

Please, be sure you understand, that this models, are dummy. It depends on nothing, so do not look for logic in transformation for now. Usually, transformation is done through sessions and meetups with stakeholders, not through your very head.

So, we have some additional information about our enterprise, like Assemble policy. We should add that on enterprise models. But what is not all. We go deeper in vision and find some generalization in data classes, e.g., Motor car (for Truck, model may vary, so it is domain depended LDM). Moreover we ‘resolve’ some business logic from Ware to Assemble process.

So why we need it? Why we should conceptualize? There is a lot of reasons, but the main is that you should provide different communication models for different roles.

To meet business requirements in your data models, you should translate it from business not directly, but through conceptual modeling and mutual approval. It should give you the ontology defining a basic set of classes and properties as a common vocabulary to describe business objects to making reasonable decisions in your models and data architecture.

For example, we want to make data mart of our installations:

Fig. 5: Implementation LDM dummy example

You can see, what we not only specify data, not only get additional information, but have a clear dependence on out LDM of higher level. For example, we know that Ware should be type 0 slowly change dimension. That we can denormalize tables and include Instruction attributes in Process, and so on. It is very important to have concerted models, and track how changes in one will find their place in others.

This process is going through all stages while you get to implementation, where you resolve requirements as they should be implemented. All models are rest on higher level models.

Get attention, that these models are not notation specific. You should follow rules and polices in your company. No matter is it UML notation, or you design Crow foot. The main principle is area division and vision generalization, you cannot use one model for all, because design process, purposes and communication models are divergent.

Hope you find difference in logical models and understand, that it can find use on any generalization level. Thanks for reading and have a great day! 😊