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.
