Unified Data Model Linking Object and Time-Series Databases

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional databases are structured for a specific type of data and storing other types of data strains the database and the system, leading to inefficiencies and increased costs.

Innovation Solution

A unified data model is provided that integrates disparate databases, such as an object database and a high-scale time series database, allowing for the seamless integration and efficient handling of different data types by using a computing system that includes a database engine, request engine, response engine, and interface engine to facilitate data requests and responses across these databases.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If a database is structured for a specific data type, then storage efficiency and performance for that data type is improved, but the ability to store and process other data types deteriorates

Engineering Contradiction:
Improvestorage efficiencyVSAvoiddata type flexibility
Core Design Contradiction:
ProductivityVSAdaptability or versatility

Solution Approach 1:

The system segments data storage by creating separate specialized databases for different data types (object database for entity data, time series database for temporal data), while using a data mapper to segment the access layer. This allows each database to be optimized for its specific data type while the mapper provides unified access, resolving the contradiction between storage efficiency and data type flexibility.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The data mapper acts as an intermediary layer between the unified interface and the specialized databases. It translates generic interface requests into database-specific queries, enabling the system to maintain optimized storage structures while providing flexible access to multiple data types through a single interface.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If multiple specialized databases are used to store different data types, then data processing efficiency for each type is improved, but system complexity increases

Engineering Contradiction:
Improvedata processing efficiencyVSAvoidsystem architecture complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The unified interface provides universal access to multiple data types through a single standardized API. The data mapper implements multi-functionality by handling different data types (objects, time series, spatial data) through a common request/response mechanism, reducing the need for multiple specialized interfaces and simplifying the overall system architecture.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Ease of operation

If data from multiple specialized databases is integrated through a unified interface, then ease of operation is improved, but data integration complexity increases

Engineering Contradiction:
Improveinterface uniformityVSAvoiddata integration complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The data mapper serves as an intermediary that handles the complexity of integrating data from multiple specialized databases. It abstracts the integration logic from the unified interface, translating simple interface calls into complex coordination between multiple databases, thereby maintaining ease of operation while managing integration complexity in the mapper layer.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS12450208B2Unified data model and interface for databases storing disparate types of data
Publication Date: 2025.10.21 PALANTIR TECHNOLOGIES INC
  • US12450208B2 patent drawing
  • US12450208B2 patent drawing
  • US12450208B2 patent drawing

AI summary

Systems, methods, and non-transitory computer readable media may be configured to access first database and a second database. The first database may be structured for a first data type, and may include a first data of the first data type. The second database may be structured for a second data type different from the first datatype, and may include a second data of the second data type. The second data may be associated with the first data. A first information request relating to the first data and a second information request relating to the second data may be received. A first response to the first information request may be determined based on the second data. A second response to the second information request may be determined based on the first data. An interface, through which the first response or the second response is accessible, may be provided.