Why Your Data Model Needs Semantics and Relationships

5 minutes reading

There is a built-in discrepancy between how businesses conceptualize their business domain, and how this conceptualization gets translated into concrete data models.

Modeling data with semantics and relationships resolves this discrepancy by delivering key capabilities to relational databases that logical and physical data modeling can’t deliver, such as defining abstract concepts, business rules, context and relationships that enrich data.

Data modeling

Data modeling is the cornerstone of successful data management and analysis for any organization. It offers a visual representation of data structures and their interrelationships, to establish data consistency, accuracy, and integrity thereby improving the overall quality of data and reducing the risk of errors.

As AI continues to reshape industries, having an up-to-date data modeling strategy is crucial to enable organizations leverage enterprise AI.

Data models

The term data model can refer to two distinct but closely related concepts. Sometimes it refers to an abstract formalization of the objects and relationships found in a particular application domain, for example: the customers, products, and orders found in a manufacturing organization. At other times it refers to the set of concepts used in defining such formalizations, for example: concepts such as entities, attributes, relations, or tables. So, the “data model” of a banking application may be defined using the entity-relationship “data model”.

A data model explicitly determines the structure of data. Data models are typically specified by a data specialist, data librarian, or a digital humanities scholar in a data modeling notation. There are three different types of data models produced while progressing from the requirements phase to the actual creation of the database to be used for the information system.

Conceptual data model

In the initial phase, the data requirements are recorded as a conceptual data model. This is essentially an organized view of concepts and their relationships described as a set of technology-independent specifications about the data. It is used to discuss initial requirements with the business stakeholders. The conceptual model is then translated into a logical data model.

Logical data model

The Logical Data Model is used to define the structure of data elements and to set relationships between them. The logical data model documents structures of the data that can be implemented in databases independently of physical considerations. Implementation of one conceptual data model may require multiple logical data models.

Physical data model

The final step in data modeling is transforming the logical data model into a physical data model. The physical data model organizes the data into tables, accounts for access, performance and storage information.

The information left behind from the conceptual model: business rules, relationships and context

When modeling is done to create a relational database, the conceptual model must be different from a logical model because there is no place in a relational database structure to capture, for example, business rules, describe relationships, provide context and record other key aspects of a conceptual model.

This semantic information collected and documented as part of the initial modeling is left behind when modelers and designers move on to define a logical data model. The “left behind” parts are used by software developers as they encode business semantics directly into custom programs, so it’s quite impossible to re-use this work elsewhere in the organization.

Similarly, the logical data model, being a subset of the conceptual model expressed using a particular technology, leaves behind some of its elements as it gets translated into a physical data model before it can be implemented in a relational database.

Semantic Graph Modeling:
Data modeling with no "left behind parts"

An Ontology is a model of a domain described by a set of abstract concepts and their relationships, as well as individuals thereof. Therefore, all three types of data models can be thought of as ontologies. They range from the most expressive one that describes business concepts and processes (the conceptual model) to less expressive ontologies. They progressively shift from describing business semantics to describing the data’s physical structures of the data as it is stored in databases (the logical and physical data model).

Ontologies represent knowledge as concepts organized as a network of nodes. As such, ontologies have hierarchical, inheritance, and inference capabilities that bear a similarity to object-oriented classes. An ontology is built from entities that are linked via relationships to form a hierarchical directed graph. The structure of the ontology can subsequently be mined to infer knowledge, for example, from an inheritance hierarchy defined for two entities, or a graph connectivity reflecting a relationship between two entities.

Virtual SQL Ontologies:
The solution to "left behind information"

Ontology above Schema

The Timbr platform enables ontology data modeling in SQL (or visually), implemented as a virtual layer on top of existing databases. There’s no need to add database infrastructure, to ETL data and no need to learn new query languages.

Timbr SQL ontologies make sure that the key information left behind by logical data modeling is kept by enabling the definition of abstract concepts that give common meaning to data and are enriched with business rules, relationships, context and logic. These concepts are mapped to existing databases to enable querying of the underlying data in standard SQL and connect to the popular business intelligence tools and data science notebooks in use by enterprises.

Among the many advantages of using virtual SQL ontologies mapped to the data, querying the context-enriched concepts instead of querying the data delivers an immediate and powerful benefit: SQL queries are reduced in size by up to 90%. This capability can be leveraged by architectures requiring LLM – RDBMS integration.

Applied to data lakes,  SQL ontologies can replace or empower their “gold layer” by using the model’s concepts to maintain an accurate, business-meaningful glossary or taxonomy of the terms that describe all the artifacts in a data lake, besides providing semantic and relationship enablement. This allows users to search, discover, understand and query the appropriate elements of the data lake with little or no need for interaction with the IT organization maintaining the data lake.

Modeling data with SQL ontologies introduces a new paradigm that leverages the huge SQL ecosystem, modernizing databases without adding to, or changing the organization’s IT infrastructure and delivering a universal solution for linking heterogeneous data sources and enabling smart data.

Read our blog that explains relationships in more detail.

Contact us to experience the benefits of virtual SQL Ontologies.

[1] Some of the explanations used in this article to describe data models, data modeling and ontologies are taken from the corresponding pages in Wikipedia.

Thank You!

Our team has received your inquiry and will follow up with you shortly.

In the meantime, we invite you to watch demo and presentation videos of Timbr in our Youtube channel:

Partner programs enquiry

The information you provide will be used in accordance with the terms of our

privacy policy.

Schedule Meeting

Model a Timbr SQL Knowledge Graph in just a few minutes and learn how easy it is to explore and query your data with the semantic graph

Model a Timbr SQL Knowledge Graph in just a few minutes and learn how easy it is to explore and query your data with the semantic graph

Graph Exploration

Register to try for free

The information you provide will be used in accordance with the terms of our privacy policy.

Talk to an Expert

The information you provide will be used in accordance with the terms of our

privacy policy.