J

Friday, June 3rd, 2022 7:00 AM

Conceptual and logical data layer with SAP

Hi all,
we are currently starting to integrate some SAP systems with Collibra using Safyr. The ingestion of assets coming from the SAP DD is running smoothly and leads to a couple of pre-defined physical data-assets in Collibra (schema, tables, columns.,…). On the other end we are quite clear about the conceptual layer for these objects. Where we currently are struggling is , how we can define and build the logical layer in between without creating a huge manual effort?

What we found is that in the meta data ingested with Safyr there are some elements clearly belonging to the physical layer but also some, we would potentially expect in the logical layer (e.g. data type, data size of an attribute). Hence we think about splitting the information from Safyr into physical but also logical assets.

It would be great to know if there is anybody being one step further, having already decided how to model the SAP structures above the physical layer and perhaps how effort for manual maintenance can be limited! Thanks a lot!

1.2K Messages

2 years ago

In my opinion there is unclarity which is the best way to go.
The “Guided stewardship” model proposed by collibra seems only applicable for Banks and Insurance companies, still heavily relying on mainframe systems. In mainframe systems, it is common to have multiple tables representing the same data structures (i.e. for active/history/archive/regions/products). Therefore, Collibra came up with the idea of deduplicating those physical structures with a logical layer. Great, excellent work, that really solves it for mainframe use cases.
But it does not make any sense for most modern applications where there is just 1 table for each entity.

Therefore, I decided to ignore this model and to adopt the more classical “Business Term” model, where you just create business terms for your conceptual layer and link them directly to your physical data assets (columns, fields, tables, etc.)

Creating a logical dictionary might make sense if you’re trying to capture data models and compare with physical implementations, but weigh the pros and cons before exploding the number of assets and complexity of your models.

Hi Arthur, thanks a lot for you quick reply. Interesting, as we also thought about this option to directly connect BTs with the physical layer and leave the others away. But we were unsure if this is really a practical thing to do. And yes, we will definitely have find the right balance between advantages of comprehensive data abstraction layers and the effort to be invested for it.

Loading...