grantrollerson1's profile

143 Messages

 • 

9.8K Points

Monday, November 13th, 2023 1:57 AM

Holding a logical structure

Hello Data Governance Legends :boom::rocket:

I have a logical structure;

  • at the top we have Data Model
  • at the bottom, the lowest grain, we have Data Attribute
  • in between we have multiple layers (multiple logical containers), multiple roll-ups including ragged.

My thinking is to store this as;

  • Data Model contains Data Entity
  • Data Entity contains Data Attribute

to represent the multiple layers, there is an OOTB pathway

  • Data Entity source for Mapping Specification / then / Mapping Specification target for Data Entity

… but it doesn’t convey the sense of structure (rather, it talks to ‘flow’) plus has an additional hop. I am thinking instead of a site-specific relationship;

  • Data Entity contains Data Entity

Very keen though to NOT build site-specific elements … so I’m extremely interested to hear the community view :grinning::flashlight:

For hops/transformations in Application Logical layer, I’m also thinking to utilise the OOTB relationship Data Element sources / targets Data Element, rather than the OOTB alternative, which is a Complex Relationship called “Field Mapping”. Keen to hear if anyone thinks this is a good (or bad) idea :bulb:

Cheers
Grant

36 Messages

 • 

1.6K Points

1 year ago

Hi Grant,

I think this is a good idea and I do this here in our environment as well. I like simplicity and I found many of the OOTB relationships weren’t clear and also many of the folks in my company that use Collibra were confused by some of these relationships, so to minimize the learning curve I’ve created several with simpler language. An example of a custom relations we made is [COLUMN] is source for / is target of [COLUMN]. Or when we have incoming files from our service providers, we have processes to load that data to DB2, I’ve created [FIELD] links to/links back to [COLUMN]. There’s several more, but those are an example of two.

143 Messages

 • 

9.8K Points

Interesting, thx Lance. I’m wary of creating relationships through the physical layers b/c technical lineage will build using Data Element sources/targets Data Element (that then includes Column sources/targets Column), but I take your point.

The value of SaaS is sticking to the Happy Path by not creating “stuff” (which may then become technical debt and have a cost that feeds into TTCO), but I think these ones are valid.

Thank you for replying back, Cheers Grant

36 Messages

 • 

1.6K Points

1 year ago

That’s interesting you brought up the technical lineage and I’m assuming that’s the technical lineage harvester. I’m still learning a lot about Collibra and we’ve started using the technical lineage harvester fairly recently. I have several assets that are connected by this, but have a lot of issues connecting between different dictionaries. One of my issues I had just learned is our ETL team uses an alias name for our Mainframe DB and I can’t connect to the alias to create a domain because it’s only set in our DataStage environment. But back to the relationships, is there a way to see the actual relationships the harvester is putting together as far as the relationship it’s making it? I don’t find the Stitching tab under settings to be much value other than seeing if an asset is “stitched.” I say this because it has stitching from assets that don’t exist in any catalog because of this alias DB name that’s being used.

143 Messages

 • 

9.8K Points

1 year ago

Lance, when relating source Column to Report Attribute automated stitching will use the relationship Data Element targets / sources Data Element

Data Element includes these asset types; Column, Report Attribute (and all BI equivalents), Data Attribute, plus Feature & Field

Loading...