Multiple Logical Data Models for Storage System Adaptability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current data management systems typically rely on a single logical data model to map to a physical data model or storage system, limiting flexibility and scalability, especially in handling diverse vertical domains and large volumes of dynamic data.

Innovation Solution

Implementing multiple logical data models that expose a data storage system using semantic mapping sets, allowing different modelling notations and accounting for the lifecycle of these models, including birth, retirement, merging, and splitting, while using a common notation for communication with the physical data model.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a single logical data model is used to map to the physical data model, then the system structure is simple, but the flexibility and scalability are limited

Engineering Contradiction:
ImproveflexibilityVSAvoidsystem structure
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent divides the single logical data model into multiple logical data models (first logical data model, second logical data model, etc.), each serving different vertical domains. This segmentation allows each model to be independently designed and optimized for specific domains while maintaining overall system flexibility and scalability.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a new dimension by adding multiple logical data models layered between the physical data model and application layers. This dimensional expansion enables the system to handle diverse vertical domains without increasing physical storage complexity, resolving the contradiction between flexibility and structural simplicity.

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

2Adaptability or versatility

If multiple logical data models are implemented to serve different vertical domains, then adaptability improves, but system complexity increases

Engineering Contradiction:
ImproveadaptabilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent creates a universal mapping mechanism that can handle multiple logical data models through a common physical data model interface. The mapping relationships establish a standardized way to interact with the underlying storage system, allowing different logical models to serve various domains while sharing common infrastructure, thus managing complexity.

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

Solution Approach 2:

The patent introduces mapping relationships as intermediaries between logical data models and the physical data model. These mappings act as mediators that translate between different logical models and the unified physical storage layer, enabling adaptability across domains while abstracting away the complexity of direct interactions.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If a single data model structure is used, then the system is easier to manage, but handling diverse vertical domains becomes difficult

Engineering Contradiction:
Improvedomain coverageVSAvoiddata management
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent segments the data management system into multiple logical data models, each optimized for specific vertical domains (e.g., different business domains or application areas). This segmentation allows domain-specific optimizations while maintaining ease of management through standardized mapping mechanisms to the physical layer.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies local quality by allowing each logical data model to have domain-specific characteristics and optimizations tailored to its vertical domain, while the underlying physical data model and mapping mechanisms maintain standardized management practices. This enables diverse domain coverage without sacrificing overall manageability.

Inventive Principle:
Principle #3Local quality

4Ease of operation

If multiple logical data models are used to expose the data storage system, then data access flexibility improves, but the complexity of managing model lifecycles increases

Engineering Contradiction:
Improvedata accessVSAvoidmodel lifecycle management
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent establishes mapping relationships that create feedback loops between logical data models and the physical data model. These mappings enable the system to track and manage the lifecycle of logical models (creation, modification, retirement) by monitoring changes in the underlying physical structure, thus improving data access flexibility while providing mechanisms to manage complexity.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS10423640B2Managing multiple data models over data storage system
Publication Date: 2019.09.24 MICROSOFT TECHNOLOGY LICENSING LLC
  • US10423640B2 patent drawing
  • US10423640B2 patent drawing
  • US10423640B2 patent drawing

AI summary

The use of multiple logical data models to expose a data storage system. Each logical data model may expose the data storage system using a semantic mapping set that maps sets of entities or attributes of the respective logical data model to corresponding sets of entities or attributes of the physical data model or perhaps directly to the data storage system itself. Each logical data model might serve a different vertical, and have a particular modelling notation selected by the logical data model provider. The mapping may also translate different logical modelling notations into a common logical modelling notation for use in communicating with the physical data model. The system may account for the lifecycle of the logical data model including birth or retirement of logical data model entities, and merging or splitting of logical data models.