A Data Model with a Meta-Entity Becomes Three-Dimensional

The following information protected by USA and international law. Any usage of this publication or its part can be allowed per request. Consultation available - leave your email address as a comment.

Foreword

The post describes some conclusions appeared recently, after the article “Data Modeling Techniques – Efficiency of Meta-Entities in an ERD” was published in the TDAN (http://tdan.com/data-modeling-techniques-efficiency-of-meta-entities-in-an-erd/19452).

Appreciation

First of all, I appreciate the help and support I got from my family, and especially, from my children Dima and Lara, without which my work on the article and this blog would not be possible.

Let me express my special thanks to David Hay (https://www.linkedin.com/in/davehaytx) who generously gave me a lot of very important advices which helped me to prepare the article and make it ready for the publication.

I am very grateful to Robert Seiner (https://www.linkedin.com/in/robert-s-seiner-445313) who published the article which became my first in the USA (after a dozen published earlier, including publications in editions of the Ukrainian Academy of Science).

What does Meta-Entity Bring to ERD?

The article describes the main practical achievement of the usage of meta-entities in an entity-relationship diagram – efficiency of the usage: reduction of relations makes the entity-relationship diagram more readable and reduces time for its program implementation.

Also, the usage of meta-entities helps to reveal more generic features of business entities, common for different business entities (some examples are in the article). It lets identify such features in a business process/model and use them to manage the appropriate business process. This is the reason for publication of this post.

Furthermore: probably, the most interesting effect of the usage of meta-entities in an entity-relationship diagram appeared because meta-entities not only becomes an organic part of their entity-relationship diagram, but also become a part of physical implementation of this entity-relationship diagram – they implemented as database tables (more details of the technique described in the article). On the other hand, meta-entities represent a different level of generalization in a data model.

Such way, meta-entities are an organic part of their data model (entity-relationship diagram) implemented in database tables, and, at the same time, represent (and such way, bring to their data model) a higher level of generalization. Hence, meta-entities become a higher level of their data model making a data model (entity-relationship diagram) 3-dimensional (Figure 1).

Figure 1

The adding a meta-entity to (and above!) an entity-relationship diagram is the process opposite to the regular top-down data modeling process. It happens because the addition of a meta-entity to an existing entity-relationship diagram is the improvement of the data model, and this improvement uses the bottom-up approach, which is provided after the process of creating the data model is completed (Figure 2).

Figure 2

Here is the example of such process (entities are taken from the article): initially, a housing authority had two different entities – Private Property Owner and State Property Owner. Each of these entities came from two different appropriate business processes which exist separately because the management of these two different types of business owner properties based on different requirements. After adding the Property Owner meta-entity to a data model, this meta-entity becomes not only a part of a logical (then, and physical) data models (eventually been implemented in a database table), but also reflects, along with all other entities, appropriate business entity. This reflection gives to a housing authority management an opportunity to consider the new meta-entity and work on finding general for both business entities new, common management solutions, and such way, provide unification of the management solutions.

Conclusion

1.      Addition of a meta-entity to an entity-relationship diagram is accompanied by creation relations of entities with representing them meta-entity, and as a meta-entity and entities are on the different levels of a data model, the relations between entities and a meta-entity make a data model 3-dimensional (Figure 1).

2.      Addition of a meta-entity creates premise for identification the appropriate entity in a business model (Figure 2). It allows unify the business management processes for business entities that become possible because of relations between different levels of a data model, and necessity to have these levels of a data model consistent to each other. The improvement of the business management process after adding a meta-entity to an entity-relationship diagram occurs in the opposite (bottom-up) direction to the regular modeling process because the addition of a meta-entity is the improvement of the initially created data model.

 

Responses on LinkedIn Discussions

After discussions of the post on LinkedIn, I found that some of my responses can be useful for the post readers and decided to add them to the post.

The article related to the process of a data model improvement – not of its creation, and this is a key point. The improvement begins after a data model already created – not during its creation. This process is opposite to the top-down process of creation, and it is the bottom-up process: generalization of already defined entities – this is what the blog post about.

The improvement aims simplification of a data model which became too complex because of multifunctional business entities which plays different roles in different business processes simultaneously. The improvement uses an already created data model as a base and simplifies it using generalization of entities. This generalization provided not as a simple aggregation of entities, but the generalization which is based on entities which may belong to different supperclasses. The generalization may replace relations of generalized entity in the improving data model not completely, but partially. Here is the major difference between meta-entity and superclass – it is mentioned in the article.

The category meta-entity exists (for example, Google search shows numerous results: IBM is among first ones; it also mentioned, for example, in the book “Conceptual Modeling of Information Systems” https://books.google.com/books?id=61mT383WC78C&pg=PA385&lpg=PA385&dq=%22meta-entity%22+definition&source=bl&ots=aXW28JVaKP&sig=5ihMooqZ94jyG0mWRQ2hWHjLtVE&hl=en&sa=X&ved=0ahUKEwj6756986DNAhWHkh4KHecxCGsQ6AEIQTAH#v=onepage&q=%22meta-entity%22%20definition&f=false ). The prefix meta- (in meaning "after", or "beyond") used because meta-entity created during the ERD improvement – after ERD creation, and meta-entity is created above the entities which it generalized.

The model becomes 3-dimensional because the meta-entity not only stays above entities it generalized, but at the same time represented in a database table becoming a part of a physical implementation of the data model.

The number of relations defines the number of possible ways in a data entering and search. The number of ways defines a number of SQL constructions, implemented in programs, for example, programs for data entry (allocation with decomposition) and programs for calculation of reports.

Such category as “View” used in the implementation of a data model in a database and not alternating with data modeling categories like “Entity”, “Dimension” (and in our case, “Meta-Entity”). A meta-entity should not be implemented as a view because it contains data which should be inserted, updated, and deleted – the same as a regular table. The usage of a view for a meta-entity implementation will just create technical difficulties and restrictions without any gain. By that reason, a meta-entity should be implemented as a table – the same way as a regular entity.

Implementation of the data model with meta-entities was provided with usage the Data Vault modeling approach that organically allows to present meta-entities along with entities: meta-entities were presented as hubs and links, and entities – as links and satellites. It allows implement the occasion when one entity covered by more than one meta-entity (the occasion mentioned in the article), for example, “Private Property Owner” has relations with two meta-entities, implemented as two hubs: “Property Owner” and “Individual”.

As the result, the number of relations minimized and the model became simpler, than it was initially, and more readable and understandable both by business subject matter experts and by developers.

The work with developers on the right implementation of a data model definitely requires some efforts to reach the right result. I met this issue and can recommend building SQL statements separately from other parts of programs – it allows get the SQL statements with the right usage of a data model based on a data architect’s vision, not a developer’s one. Then, the SQL statements can be embedded into the programs or called from them as functions or stored procedures. But this advice can be implemented when a project management set the predominant status of a data architect during a data model implementation – unfortunately, it happen not always … - it’s the topic for another discussion.

The serious answer on why stop at three dimensions: yes, you can add more dimensions, for example, time and money, but in this case, you will consider not a data model, but a model of a data model implementation (management of a data model implementation) – another than a data modeling field.

 

Meta-entities, as a generalization layer, save relations of the replaced entities with other ones, just reducing the relations number.  Meta-entities also contain data which reflect the modeled business process. These relations and data completely present the initial model which describes business relationships.


Particular business data reflect the business process they related to. By that reason, they have the traits of the business process.


A normalized data model (for example, 3-rd normal form) can be transformed into a completely denormalized data model (star-schema), or into a multilevel model (for example, Data Vault).


Levels of data mentioned, for example, by Martin Modell: http://www.martymodell.com/dadmc/dadmc03.html .


The perspectives of data are reflecting the vectors of measurement – they become dimensions in the star-schema approach. But cross-perspective relations between data from different perspectives (for example, different types of measurement related to the same business event (for example, transaction) allow to build data models as we have them (for example, relations of data from different dimensions to the same event fact data in a star-schema data model).


After the cross-perspective relations set and data from different perspectives form what usually considered as a transactional row, which has key attributes. These key attributes represent higher than other attributes level(s – plural form related to Data Vault modeling). Such way, perspectives can be transformed into multi-level model.