Display Complex Relations in Global Views?

Hey all,

Can one display complex relations — or any of their characteristics — in global views? I would have thought this possible, but I cannot seem to select any complex relation (or the constituent components) is a view.

If not, does anyone have a suggestion of how to summarize this information in a similar way?

Thanks,
Tom

Tom Friesen

Posted 5 years ago · Edited 1 year ago·Last reply 1 year ago

8 comments

georgecheung

·1 year ago

I believe this marketplace solution can be used to display complex relations in a tabular format through hierarchies: https://marketplace.collibra.com/listings/create-hierarchy-view-for-complex-relations/

kathybarton

·4 years ago · Edited

Thanks! I am new to the world of Collibra and I forget about things like ideation. Voted!

kathybarton

·4 years ago · Edited

I just ran into this issue today, trying to display the complex relations we’re using to represent ETL mapping. We have a mapping spec with a source and target and a custom attribute to capture the logic we use in the transformation, e.g., Target Total Cash = Source Cash A + Source Cash B. Is there any way to see that Transform Logic attribute in a table view? I’m open to OOTB workarounds.
Thx!

Tom Friesen

OP4 years ago · Edited

Hey Kathy…

If I understand correctly, you’re wanting to see the Transformation Logic in the Field Mapping complex relation in a table. Me too! I don’t think Collibra has tackled the display of complex relation components in tables.

Arthur’s suggestion above about denormalizing the complex relation to a text attribute would work. If the Complex Relation are 1:1 with the related Asset Type, you could extend that idea and use multiple characteristics for a nice clean view. Unfortunately, I don’t think this is the case for you.

You may want to up-vote ideation ideas https://productresources.collibra.com/ideation-platform/?id=DCC-I-57 and https://productresources.collibra.com/ideation-platform/?id=DGCPLAT-I-624

arthurburkhardt

·5 years ago · Edited

I guess you could denormalize that in a text attribute, like

source value	target value	description
FR	FRA	France
CA	CAN	Canada

The attribute denormalized value would look like
FR=>FRA (France)
CA=>CAN (Canada)

It can be a daily workflow to denormalize, and play with assignments to hide the attribute.

Do you have an example of what you are trying to achieve?

Tom Friesen

OP5 years ago · Edited

Thanks for the suggestion, @arthur.burkhardt . I like the out-of-the-OOTB thinking, but it has the problem of being visible as an attribute to anyone who can see the asset, whereas the complex relation is only visible to those who can see all assets in the complex relation.

One example we are looking at would be the concept of an Authentication Mechanism complex relation, that would include things like

System (the system being accessed)
Identity Provisioning System (the system authenticating the access)
Data Subject (the type of person accessing the system)
VPN Requirement (binary flag)
Critical Period (the times of year in which this Authentication Mechanism is business-critical)

We are torn between representing this as a Complex Relation or as an Asset itself. In either case, be anticipate its editing being facilitated by a workflow. But the display of information in these global views is important. For example, a privacy steward might want to see all systems which are accessible by Employees (Data Subject) outside of VPN.

We have a similar use cases in relating Licenses (a custom governance asset) with Systems and Third Parties (a custom Business Dimension).

The challenge in representing this as an asset is to somehow establish a naming convention and a visibility that makes sense to the stakeholders. In the case of Authentication Mechanism, there will likely be multiple entries for any given System, meaning we either have really long asset names, or really cryptic ones.

Open to any ideas!

arthurburkhardt

·5 years ago · Edited

Yes, using an asset would make sense in that case.
Rather than having meaningful names (ie. “Some very long system name and weird convention is accessed over SFTP by those guys in summer”), why not using a simple identifier? e.g. “ACC-00001” ?
Then you can provide the meaning in the description. would that work?

Tom Friesen

OP5 years ago · Edited

That’s along the same lines that I was thinking. Thanks, Arthur!