Multi-tenancy Database Key Pattern Deployment

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Multi-tenancy database systems face challenges in efficiently deploying changes to key patterns and managing data separation, leading to issues with data consistency and duplicate records, especially when transitioning between different system sharing types or during software upgrades.

Innovation Solution

The method involves receiving a new shared container with a new key pattern, identifying and moving records matching the pattern from a read-only portion to a writable portion in a tenant container, while deleting records not matching the pattern, and using key patterns to enforce data consistency and prevent duplicate records.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If changes are deployed to key patterns in multi-tenancy database systems, then data consistency is maintained and duplicate records are prevented, but system complexity increases and deployment time is extended

Engineering Contradiction:
Improvedata consistencyVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the database schema into shared containers that can be independently deployed. Each container represents a distinct key pattern or data structure that can be updated separately, allowing changes to be applied to specific portions of the database without affecting the entire system. This segmentation enables targeted deployments that maintain data consistency while reducing overall system complexity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements preliminary actions by creating shared containers with predefined key patterns before they are needed by tenant databases. The deployment system prepares and validates the new shared container structure in advance, ensuring that when changes are deployed, the data migration and consistency enforcement can proceed smoothly without unexpected complications.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If key patterns are used to manage data separation in multi-tenancy systems, then data consistency is improved, but deployment time increases and downtime is extended

Engineering Contradiction:
Improvedata consistencyVSAvoiddeployment time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

By segmenting the database into independent shared containers, the patent enables parallel deployment of multiple key patterns simultaneously. Each container can be deployed and validated independently, allowing the system to update multiple data structures in parallel rather than sequentially, thereby reducing total deployment time while maintaining data consistency through the key pattern enforcement mechanism.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent uses copying by creating a new shared container with the updated key pattern and then migrating data from the old container to the new one. This copy-based approach allows the system to validate the new structure in isolation before actually using it, enabling faster deployments since validation can occur in parallel with data migration preparation.

Inventive Principle:
Principle #26Copying

3Productivity

If shared containers are used for multi-tenancy, then resource management is improved, but the risk of duplicate records increases during transitions

Engineering Contradiction:
Improveresource managementVSAvoidduplicate records risk
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent implements feedback mechanisms where the deployment system continuously monitors and validates data consistency during the transition from old to new shared containers. Key patterns are enforced with validation rules that provide immediate feedback on potential duplicate records, allowing the system to detect and correct issues before they propagate through the tenant databases.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent introduces an intermediary deployment system that acts as a mediator between the shared container updates and tenant databases. This intermediary layer handles the complex task of migrating data while enforcing key patterns, filtering out duplicate records, and ensuring that only valid data is transferred to the tenant databases, thereby reducing the risk of duplicates during transitions.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Adaptability or versatility

If individual tenant upgrades are performed with transparent system sharing type changes, then system flexibility is improved, but data consistency maintenance becomes more complex

Engineering Contradiction:
Improvesystem flexibilityVSAvoiddata consistency maintenance
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the multi-tenancy system into independent shared containers that can be updated individually. This segmentation allows the system to perform targeted upgrades to specific key patterns without affecting other parts of the database, enabling flexible tenant-specific upgrades while maintaining data consistency through isolated container boundaries and enforced key patterns.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentEP3477488B1Deploying changes to key patterns in multi-tenancy database systems
Publication Date: 2020.11.18 SAP SE
  • EP3477488B1 patent drawingFigure 1
  • EP3477488B1 patent drawingFigure 2
  • EP3477488B1 patent drawingFigure 3

AI summary

The present disclosure involves systems, software, and computer implemented methods for deploying changes to key patterns in database systems. One example method includes receiving a new shared container that includes a new key pattern for a logical split table and an updated read-only-portion physical table for a logical split table. The updated read-only-portion physical table includes records that match a complement of the new key pattern. Records that match the new key pattern are identified in the read-only-portion physical table of the logical split table in a current shared container. The identified records are moved from the read-only-portion physical table in the current shared container to a writable-portion physical table in a tenant container. Records not matching the new key pattern are deleted from the writable-portion physical table of the logical split table in the tenant container.