Holding a logical structure
Hello Data Governance Legends 
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 
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
Cheers
Grant
Grant Rollerson
Posted 2 years ago · Edited 1 year ago·Last reply 2 years ago
5 comments
Grant Rollerson
OP2 years ago · EditedLance, 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
Lance Harlan
·2 years ago · EditedThat’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.
Lance Harlan
·2 years ago · EditedHi 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.
Lance Harlan
·2 years ago · EditedHi 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.
Grant Rollerson
OP2 years ago · EditedInteresting, 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