Multi-tenancy Database System Sharing Types and Container Management

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Multi-tenancy database systems face challenges in efficiently managing and upgrading shared resources across multiple tenants, particularly in transitioning between different system sharing types and deploying changes without causing inconsistencies or downtime.

Innovation Solution

The system employs a configuration method to determine a system sharing type, creating tables based on this configuration, and deploying content accordingly, allowing for transitions between standard, shared, tenant, and simulated setups, while using an exchanged shared database container approach to minimize downtime during upgrades and deployments.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If a multi-tenancy database system uses a single shared database container for all tenants, then resource utilization and system efficiency are improved, but system reliability and data isolation between tenants deteriorate

Engineering Contradiction:
Improvesystem efficiencyVSAvoiddata isolation
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent segments the database container into multiple isolated schemas, one for each tenant. Each schema contains tenant-specific tables and data, while sharing the same physical database container. This segmentation allows multiple tenants to share resources efficiently while maintaining data isolation through schema-level separation.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent creates a universal database container that serves multiple tenants simultaneously. The single database container is designed to host multiple schemas, making it a multi-functional system that can serve different tenants with isolated data spaces while sharing common infrastructure resources.

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

2Reliability

If the system performs upgrades by replacing shared database containers, then system reliability and data consistency are improved, but system downtime increases

Engineering Contradiction:
Improvedata consistencyVSAvoidsystem downtime
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent performs preliminary actions by creating a new shared database container with the upgraded schema structure before the current container is taken offline. The new container is prepared in advance with all necessary schema changes, so that when the switch occurs, the transition is immediate and consistent without requiring gradual updates during downtime.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent creates a copy of the shared database container with the upgraded schema. Instead of modifying the existing container in place, a new container is copied and prepared with the updated schema structure. This copy can be validated and tested before switching, ensuring data consistency while minimizing the time the system is offline.

Inventive Principle:
Principle #26Copying

3Reliability

If the system maintains parallel access to old and new shared database containers during upgrades, then system reliability is improved, but device complexity increases

Engineering Contradiction:
Improveupgrade safetyVSAvoidcontainer management
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces a schema management layer as an intermediary that handles the complexity of parallel container access. This layer manages the switching between old and new schemas, handling the coordination and validation logic. By placing this management logic in an intermediary layer, the complexity is isolated from the core application logic, making the system more maintainable despite the increased complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3477501B1System sharing types in multi-tenancy database systems
Publication Date: 2021.03.31 SAP SE
  • EP3477501B1 patent drawingFigure 1
  • EP3477501B1 patent drawingFigure 2
  • EP3477501B1 patent drawingFigure 3

AI summary

The present disclosure involves systems, software, and computer implemented methods for enabling multiple system sharing types in multi-tenancy database systems. One example method includes determining a system sharing type configuration for a database system. The system sharing type configuration is one of standard, shared, tenant, or simulated. Tables are created in the database system based on the system sharing type configuration and the table sharing type of each table. Content is deployed to created tables in the database system based on the system sharing type configuration and the table sharing type of each table. Access is provided to at least one application to the database system based on the system sharing type configuration and the table sharing type of each table.