Achieving the physical alignment of the environments -production, pre-production, development, etc.- of a database is essential when testing. This way, the data will be consistent between the environments and the uncertainty regarding possible errors in the executions will be reduced.

Moreover, in the case at hand, the need to perform data conversions between environments in the segmentation movements will be avoided.

Throughout this article you will learn about the different types of physical alignment of environments that exist, we will answer the question of why data should not be transferred directly and how to solve these challenges.

You are ready?

Let's go!

What types of physical alignment of environments exist?

At the metamodel level

On one hand, the alignment of the databases must occur at the metamodel level. This is that the structure itself is leveled between environments: the tables, their fields, the indexes and a long etcetera that should have the same characteristics.

Why is this essential? If a field does not exist your application may crash. If a column is smaller than other, the data will not fit into it. Among other possible examples.

At data level

But, now we expose another case, another type of alignment: that of the data itself. Mainly from catalog or parameter tables, tables that are not included in the structure of the business entities on which we carry out segmentation movements. And that, consequently, are not completed in a habitual way unless specific processes are used for it.

A real case: the product brochure

Let's take the following example: a table with the company's product catalog, each of them identified with a unique code and many other tables that refer to those products by the given code.

In this scenario, with the same products (or a good part of them) in two environments, we find that the code of the same product is different in both, depending on the procedure for creating them. To all this we add that, for various reasons, we cannot simply transfer that table of products from the origin environment of the movements to the destination environment.

Consequently, segmentation between these environments will lead to data integrity issues in the best situation. Both these scenarios referential integrity and functional level.

Why not directly transfer data to achieve physical alignment across environments?

Many might raise this question. The simplest solution seems to just delete the table or tables that contain the product catalog, parameters, etc. and insert again all the records from the reference database.

However, this solution has significant obstacles:

• The size of certain tables may exceed the manageable volumes of the database.
• Even assuming tables can be moved completely, if there are physical constraints, the order in which data is entered is critical. Otherwise, disabling the restrictions is additionally required.
• Data present in the environment up to that point is completely discarded. They are rendered useless with the consequent damage. There is never a good time to make data in an environment unusable!

How has this situation came across?

Why do these data -products, rates, etc.- not have the same identifier in all environments? The reason can be in many points:

• Because there are sequences and they change differently in the environments.
• Not all deliveries are made to all environments so they are naturally misaligned or the order of deliveries between environments is different.
• Depending on the release cycle, it will be tested in one environment or another. Development will always arrive before pre-production. Even in the development stage configurations that will never get to be real will be discarded in production environments.

Besides, from our experience, in most cases this process is not procedural, it is not the responsibility of anyone and, therefore, no one assumes it, despite its importance.

The icaria TDM solution to achieve the physical alignment of environments

With the icaria TDM data alignment process you can forget about this problem. Next, let's take a closer look at the different solutions offered by the product.

Complete transfer

Creation of specific plans for the movement of tables: it allows applying conditions to transfer part of the records, work in incremental mode, etc.

However, if we have other tables with referential integrity to these catalog tables, this procedure is not the best solution.

Segmentation

Segmentation is generally associated with the movement of customer structures, accounts or insurance policies, but this is not it´s only use.

In large product brochures, it is shown as a perfect alternative capable of dealing with size problems in database and avoiding referential integrity errors arising from the order of insertion of the records. On the contrary, it can be significantly slower to execute and complex to design, compared to the full transfer.

Alignment

Faced with these two limited solutions, with significant disadvantages, icaria TDM has a specific module for the task of aligning environments that overcomes both the segmentation speed problems and the complete transfer referential integrity problems.

Information maintenance

But this is not all, this software also provides a differentiating factor: managing to keep the environment data that references these tables consistent, valid and usable after the process. That is, that customers maintain the same rate, product, promotion, etc. after alignment.

The process of physical alignment of environments in detail

The alignment process begins with the identification of the catalog tables by the data architect. This information is transferred to icaria and from that moment on the tool takes control of the process.

After making a recognition of the tables, the physical restrictions are evaluated, the degree of misalignment between environments and the tables that, by not being directly involved in the process, will be essential to modify.

During the process, physical constraints are removed, if possible, to speed the alignment. Tables are prioritized based on the cycles found between them. And the different data domains are processed in parallel with the same objective.

The key to this process is to be able to analyze the list of affected tables, those that have referential integrity when referring to the first ones -strange keys- and establish the mechanisms for updating their data so that, after changing the sequential -primary key - of the aligned table, the external data continues to functionally point to the same information.

Conclusion

Most teams involved in software development deal with alignment issues on a daily basis. That´s good because the environments are not and manual and partial alignments need to be done periodically. That´s also good, because being aligned at the functional level, they are not aligned at the sequential level, which causes doubts in the comparison of data. Or because they simply don't have the ability to align environments without doing it manually, and this is costly, error-prone, and has serious impacts on software release.

The different icariaTDM alternatives allow us to address these problems and approach the solution from the most appropriate point of view, even allowing different solutions to be executed depending on the state of the environment.

If you want to know more about icariaTDM click on this link.