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 was conceived forty-five years ago to help with the design of relational databases and defining a formal vocabulary for the organization. The ANSI definition differentiated between three data models – conceptual, logical and physical.
Data modeling quickly established itself as the process used to define and analyze data requirements, needed to support the business processes within the scope of information systems in organizations. This process involves close engagement between professional data modelers and business stakeholders, as well as potential users of the information system.
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"
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%.
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.
Acknowledgements:
[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.
