137 Messages
•
9.4K Points
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
Lance_Harlan
34 Messages
•
1.1K 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.
1
0
Lance_Harlan
34 Messages
•
1.1K 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.
0
0
grantrollerson1
137 Messages
•
9.4K 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
0