Dynamic Database Mapping for Unified Logical Model

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Data consumers face difficulties in accessing and using data from providers with different physical data models due to the lack of a common logical model, despite protocols like OData exposing data from various sources.

Innovation Solution

The system and method provide mapping between two data models by analyzing metadata to create system, metadata, and mapping tables, allowing data to be requested and processed using a single logical model, enabling effective data transfer between different data models.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If protocols like OData are used to expose data from different data sources, then data accessibility is improved, but the lack of a common logical model makes effective data usage difficult

Engineering Contradiction:
Improvedata accessibilityVSAvoiddata usage effectiveness
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent introduces a mapping layer as an intermediary between the protocol layer and the logical model layer. This mapping layer contains mapping tables that translate between protocol-specific data structures and the application's logical model, enabling effective data usage without requiring the application to understand multiple protocols or data formats

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system segments the data access architecture into distinct layers: protocol layer, mapping layer, and logical model layer. Each layer handles specific concerns independently, allowing the mapping layer to provide translation services without affecting the other layers, thus maintaining both accessibility and ease of operation

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If data is stored using different physical data models by different providers, then data provider flexibility is improved, but data consumer complexity increases

Engineering Contradiction:
Improvedata provider flexibilityVSAvoiddata consumer complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The mapping layer serves as an intermediary that absorbs the complexity of dealing with different physical data models. It maintains mapping tables that translate various provider formats into a unified logical model, shielding data consumers from provider-specific complexities while preserving provider flexibility

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent adds a new dimensional layer (the mapping layer) between the physical data models and the logical model. This additional dimension provides the translation functionality needed to handle multiple physical models without increasing consumer complexity, as consumers only interact with the simplified logical model

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

3Ease of operation

If mapping tables are created to provide logical model access, then data usage effectiveness is improved, but system complexity increases

Engineering Contradiction:
Improvedata usage effectivenessVSAvoidsystem complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The mapping functionality is extracted into a separate, dedicated mapping layer that is independent from the core application logic. This extraction concentrates the complexity in a manageable, isolated component that can be maintained and updated without affecting the rest of the system, while still providing effective data usage

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS10296499B2Dynamic database mapping
Publication Date: 2019.05.21 SAP SE
  • US10296499B2 patent drawing
  • US10296499B2 patent drawing
  • US10296499B2 patent drawing

AI summary

A method for providing mapping between a first data model and a second data model may include sending a request for metadata to a data producer providing data using the second data model. The metadata may be received from the data producer and analyzed to determine a structure of the second data model. System tables may be created based on the analysis of the metadata. The system tables may include data tables to store data from the data producer and to provide the mapping between the metadata of the second data model and the data tables in the first data model. Requests may be made to the data producer for data to be retrieved and populated in the data tables using the first data model.