How Knowledge Graphs, Dimensional Models and Data Products come together

As a Data Engineer and Data Modelling enthusiast, these concepts often come across my path. They are important milestones in translating a data strategy into concrete business value, but I often struggle to express how they relate in conversations. This article is my attempt to organise my thoughts on the topic, and I hope it’s useful to others who enjoy seeing a clean data model thrive in the wild!

In a data-driven organisation, or one with that ambition, clear abstraction of data assets is crucial. These assets should be modelled in a way that allows key business questions to be answered. The model should then be further developed in detail until it can be used as the target for ETL processes. Not trivial off course.

Knowledge graphs are a popular way to create such an abstract representation of a business or business domain. They sit at a sweet spot between business and technology: visual enough for business stakeholders to reason about, but structured enough for technical teams to work with.

One of the biggest advantages of a knowledge graph is how naturally it models reality. By connecting entities with verbs and relationships, we often avoid the many-to-many headaches that plague traditional Entity–Relationship Diagrams (ERDs). People tend to think in sentences, not tables — and knowledge graphs lean into that.

As more entities, verbs, and relationships are added, this style of modelling usually scales quite well and can cover a complex organisation’s activities.

The challenge starts when we try to operationalise a knowledge graph.

Graph databases are powerful and popular for good reason; however, relational databases — with normalised or dimensional models — are still the backbone of many operational and analytical data platforms. Translating a knowledge graph into a relational structure is possible, but not always obvious. How do we get from a knowledge graph to a dimensional model?

A simple set of heuristics often works surprisingly well:

• Entities in the graph map naturally to dimension tables

• Ownership relationships (for example, has) usually become dimension attributes or snowflaked dimensions

• Non-trivial verbs (not is, has, or other purely descriptive links) are strong candidates for fact tables

When you start designing star schemas around verbs, a pattern emerges: a verb is typically “owned” by a specific business domain.

Press enter or click to view image in full size

Star schema developing based on verbs

For example, buys or ships product are not abstract concepts — they are business processes, operated by a domain and generate valuable data. In a data mesh context, this maps well to the idea of data products:

• Each fact table and its dimensions, i.e. a star schema, becomes a data product than can answer questions about a specific process in a specific domain. (It does not mean that a data product is alway a star schema)

• The data product is owned by the domain that performs the verb associated with the fact table in the star schema.

• Conformed dimensions are shared with other data products when the same entity is the subject/object of different verbs. For example, the Product entity is owned by the Inventory domain, but shared with Logistics and Sales domains to complete the start schemas.

I recommend this and this for good introductions to data product concepts

Press enter or click to view image in full size

Once fact-table ownership is assigned, identifying the supporting dimensions becomes clearer. Although the owner of a dimension may not be as obvious as the owner of a fact table, a good guide is “who needs the dimension most?”. Let that domain own the dimension. Facts remain firmly owned by the domain responsible for the business action.

There’s also the issue of certain dimensions that aren’t domain-related, like the ubiquitous Date and Time dimensions. If no-one volunteers to handle this, the platform team can take care of it and share it with all data products.

There’s another complication. Sometimes, a Knowledge graph contains an entity that means different things for different verbs when examined closely. For instance, a Marketing department might define a Customer as someone who browsed the online store and added a product to their basket, while a Finance department might insist that the purchase must go through before classifying someone as a customer.

At the Knowledge graph level, it appeals to our aesthetics to have a single Customer entity. However, consider this quote:

“Total unification of the domain model for a large system will not be feasible or cost-effective” — Eric, Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software

There’s much more to the statement, and it was aimed at software development, but I think it is applicable here. We must allow for more than one version of entities such as Customer, Product, etc. The Logistics department can, for example, define customer in the way the serves shipping, Logistics will own and operate this version of Customer. The downside is that silos will develop but ontologies are used in large organisations to keep track of different entity subtypes. The metadata layer links the different versions of Customer, and they can remain connected in this way.

Press enter or click to view image in full size

Ontology linking different Customer entity versions

Closing thoughts

By treating verbs in a knowledge graph as fact tables, you gain a practical and intuitive path from business-friendly abstractions to analytics-ready star schemas. If your organisation is ready to embrace data mesh principles, these star schemas can become well-defined data products, owned by the domains that actually perform the work.

I hope this was useful. Let me know in the comments if you agree or disagree with anything.