Composite Key Mapping in Multi-Tenant Non-Relational Databases

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Multi-tenant non-relational database systems lack an efficient method for customers to define and manage composite keys across shared tables, restricting query capabilities and requiring complex metadata management, which hinders fast and flexible data access.

Innovation Solution

The system allows organizations to define composite keys for platform objects within a multi-tenant environment, generating metadata models and data definition scripts to map these objects onto shared non-relational databases, enabling efficient querying and dynamic access control through APIs.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If composite keys are defined in multi-tenant non-relational databases, then query capabilities are improved, but metadata management complexity increases

Engineering Contradiction:
Improvequery capabilitiesVSAvoidmetadata management
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary layer that translates composite key definitions from customers into the internal row key format required by the non-relational database. This intermediary translation mechanism allows customers to define composite keys using familiar relational concepts while the system automatically handles the complexity of mapping these to the underlying non-relational storage structure, thus improving query capabilities without exposing metadata management complexity to customers.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If physical database schema is altered to support composite keys, then data access flexibility is improved, but system downtime increases

Engineering Contradiction:
Improvedata access flexibilityVSAvoidsystem downtime
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent segments the database schema into two distinct layers: a customer-facing logical layer where composite keys are defined, and a system-level physical layer with immutable row key structures. This segmentation allows the logical schema to be flexible and adaptable to customer needs while the physical schema remains stable and requires no alterations. Customers can define and modify composite keys without triggering physical schema changes, thus maintaining data access flexibility while avoiding system downtime associated with physical schema alterations.

Inventive Principle:
Principle #1Segmentation

3Adaptability or versatility

If composite keys are supported in shared tables, then multi-tenant functionality is improved, but system complexity increases

Engineering Contradiction:
Improvemulti-tenant functionalityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a self-service mechanism where the system automatically generates unique row keys for each customer's data in shared tables by embedding customer identifiers within the composite key structure. This automatic key generation and embedding process eliminates the need for complex manual configuration and management of multi-tenant data separation. The system self-manages the complexity of maintaining isolated customer data in shared tables while providing full composite key support, thus improving multi-tenant functionality without requiring proportional increases in system complexity.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS10579691B2Application programming interface representation of multi-tenant non-relational platform objects
Publication Date: 2020.03.03 SALESFORCE INC
  • US10579691B2 patent drawing
  • US10579691B2 patent drawing
  • US10579691B2 patent drawing

AI summary

Disclosed are examples of systems, apparatus, methods and computer program products for providing application programming interface representation for multi-tenant non-relational database objects. A database system maintains a multi-tenant non-relational database associated with a number of enterprises, a number of records, and a number of data objects for each of the enterprises. A request is received from a user to retrieve a description of a data object from the number of data objects, and in response, the system determines that the data object is defined to be used in associated with a non-relational database, then retrieves a metadata model representing the data object. The system determines that at least one field of the data object is part of a composite key for the data object, then provides data object information to the user, including information about the composite key.