Bank introduced a stable and standardized Adastra bank data model (ABDM)

As the bank grew organically, three independent data warehouses, with data models based primarily on the data models of source systems, gradually formed. 

Over time, data integration and integrated reporting across data stores required more data warehouses and users increasingly felt the need for a single data layer to simplify everyday work significantly while speeding up all reporting, or changes to reporting. The single data layer would also eliminate the effect of any changes in the primary systems in the structure of the data warehouse, which was not only more expensive due to the development of individual data warehouses, but also brought users a series of unexpected surprises.

The solution to this problem was to integrate data into a single data model. Integrating and consolidating data, however, involves the use of a sufficiently universal data model that adheres to the needs and specifics of the applied sector (in this case, banking) and its respective customers. 

Creating such a model is time-consuming and requires extensive knowledge and practical experience, so creating such a perfect model from scratch is not feasible. As a springboard it was beneficial to use a practically validated sector model (industry model) as our banking data model (Adastra Banking Data Model), which contains best practices from a number of banks that can be easily developed according to the needs of the customer. This remains to be the advantage of tailored models. 

The ABDM contains hundreds of ready-made tables, links and thousands of columns with clearly defined semantics. The latest generation of the model contains an L2 layer, in addition to the L1 layer. Weighing all the pros and cons, the bank chose the Adastra Banking Data Model for its new data warehouse. A great choice for many reasons.

Our customer successfully used ABDM, featuring sophisticated data integration at the heart of the model, to create a new data warehouse with a comprehensive, user-friendly data base, above which a single data mart for reporting specific tasks can be effortlessly bu­ilt.

To ensure long-term stability, performance, clarity and to screen users from the primary structures of systems a data model requires commensurate abstraction, standardization and normalization. This significantly reduces costs associated with changes in the data warehouse data model, as the subsequent model is stable and virtually unchanged, and dramatically improves the return on investment in the new data warehouse itself.

An intriguing advantage of our model lies in its ability to be used for data warehousing, as an Operational Data Store and a specific OLTP database without needing to change it in any appreciable way.