What is logical data dictionary in Collibra ?

What is logical data dictionary in Collibra ?
A logical data dictionary is a type of domain in Collibra. It is described as, “Represents details of organizational data, independent of any particular technology and uses vocabulary of a business area to communicate with non-technical stakeholders.”

You can find this information by going to your Collibra portal settings, then clicking Domain Types on the left.

How can we create one?
Remember that domains are a collection of similar assets. Out of the box, Collibra’s logical data dictionary can contain assets with the type Data Model, Data Entity, or Data Attribute.

Here is the Collibra OOTB asset model.

Domains must be created in communities. To create one, go to the community you want it placed in, then click the global create button (white plus sign in the green box at the top). Then search for your logical data dictionary domain and follow the prompts on the screen.

Hope that helps!

Hello @alexandracannon.lithia.com or anyone out there in the community ,

Adding on to @mudassar.abdul.teck.com 's question…how would you differentiate using a business glossary vs a logical data dictionary? I’ve seen practices where information placed in business term assets (i.e. definitions and descriptions) are replicated exactly into logical data dictionary assets. How would you differentiate usage between the two asset types?

Thanks!

@marichelle.tanag.1
Here’s my 2 cents.

I also see a lot of overlap between the two. Both capture definitions using business-friendly terminology. I would say that a business glossary is likely wider than a logical data dictionary. You could have business terms that wouldn’t belong in a data model. Data dictionaries, even logical, tend to be more of IT tools for understanding or modeling data. Glossaries are purely business term for organizing definitions and acronyms.

They can definitely hold similar information. If it’s exactly duplicated, you can probably just pick which one makes more sense for your org.

If you are using the definitions primarily for architecting or modeling, consider a logical data dictionary. If they are purely used by business teams, keep everything in a glossary. If you have both scenarios and the information is different enough to justify it, use both! It is really dependent on your use cases.

Very interesting discussion, different people have different takes. What resonates with me is when I think about it on a persona level. There are loads of examples that bring it all to life but there are 3 that I like to use.

Let’s say you have Customer Phone Number that exists physically, logically and conceptually.

As an Engineer I want to see columns containing Customer Phone Number in various physical data dictionaries. I want to know the technical parameters on the data, who owns it so I can request access to it and also the data quality of the data so I understand what data is fit for my given purpose and I can make an informed decision around what data I should be consuming.

As an Owner of a System I want to see how data in my system is represented logically. I want to know all instances of Customer Phone Number in my system and ensure that I have the correct controls over this data. I also need the option to document how Customer Phone Number is represented in my System specifically and any nuances specific to my System.

As the Owner of the Concept Customer Phone Number I need to know all the different Systems in my organisation that are consuming Customer Phone Number and what my sources of it are, it might be my responsibility to ensure that these Systems are in line with Policy and Regulation. I also need to understand all the different business processes that are consuming Customer Phone Number.

As rightly mentioned above, the 3 are effectively different lenses on the data and if you can apply ownership at every level and link everything up, it can be pretty powerful!