O

Tuesday, September 5th, 2023 2:25 PM

Relation between two columns with the same name

Hello! I am pretty new to Collibra and I am trying to establish relations between columns with the same name. For example, we have several different tables which contain the column “EmployeeNo”. I would like to create a relation between these columns. What relation would be most suitable in this case? I have only found the automated target and source relations, but I don’t have target and source, I have columns which are related to each other.
Many thanks in advance!

9 Messages

1 year ago

Hi Olga,
What is it you’re trying to represent by relating the columns together? Collibra is very flexible. You can use the out-of-the-box relations or create your own, but it’s important to think through what you’re trying to accomplish, decide on the best approach for you and your stakeholders, then be consistent with it.
If you are trying to find a way to indicate that the same concept is implemented in multiple places, I would recommend looking at the Business Glossary / Business Terms. You can then establish a plain-English business term called “Employee Number” with a plain-English business-oriented definition. Once you’ve done that, you can link the various columns to the “Employee Number” business term using the “represents” relation. This is a very common use case, and it will allow your users to look up individual concepts like Employee Number and easily find that data across your various systems and tables.

2 Messages

Thank you so much for your reply! I’ll try it out.

9 Messages

Sure thing! Don’t underestimate the power of the Business Glossary. Your Business Terms can be the anchors for a lot of the other content in Collibra, helping stitch it all together in terms everyone can understand.

7 Messages

1 year ago

I would agree one of the most valuable relationships that would address this situation is the relationship between Columns and Business Terms. In addition, you could also consider relating Physical model artifacts (Columns, Tables) to Logical model artifacts (Entities, Attributes). In a similar way, multiple physical artifacts (e.g. multiple occurrences of EmployeeNo) could map to the single logical model attribute (e.g. Employee Number), thus enabling a bit more precise management of data architecture and purposeful implementation. You can get even more sophisticated by having specific types of relationships between Columns (such as candidate PK/FK to satisfy referential integrity), but that is not something I would suggest pursuing in the early phases of implementation.

Loading...