Schema Compiler Merging Partial Database Schemas

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing database access models face challenges in efficiently managing data layout for shared components and maintaining transactional consistency across client and shared component modifications, with distributed transaction protocols being costly and scalable limitations.

Innovation Solution

A schema compiler exposes a network services API to merge and manage partial database schemas, identifying namespace conflicts and validating schema compatibility to create a merged schema that allows efficient data access while maintaining transactional integrity.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If database access is abstracted out through interfaces, then component independence and reusability are improved, but the ability to efficiently prescribe internal database layout is lost

Engineering Contradiction:

Improvecomponent independenceVSAvoiddata layout optimization

Core Design Contradiction:

Adaptability or versatilityVSProductivity

Solution Approach 1:

The database schema is segmented into multiple partial schemas, each associated with a specific component or service. This allows independent definition and optimization of data layouts for each component while maintaining overall system coherence through the schema merger mechanism.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

A schema merger acts as an intermediary between component developers and the database system. It receives partial schemas from various components, resolves conflicts, and produces a unified database schema that optimizes data layout for efficient access while maintaining component independence.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Adaptability or versatility

If shared components are built as separate network services, then service independence and scalability are improved, but transactional consistency between client and shared component modifications is lost

Engineering Contradiction:

Improveservice independenceVSAvoidtransactional consistency

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

Multiple partial schemas from different services are merged into a unified schema that is processed by a single database transaction. This allows transactional consistency to be maintained at the database level while services remain independent and can be scaled separately.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The schema merger serves as a coordination mechanism that receives schema definitions from multiple independent services, resolves conflicts, and generates a unified schema that can be applied atomically to the database, ensuring transactional consistency without requiring complex distributed transaction protocols.

Inventive Principle:

Principle #24Intermediary (Mediator)

3Reliability

If a distributed transaction protocol is implemented to maintain consistency, then transactional integrity is improved, but operational cost and complexity increase

Engineering Contradiction:

Improvetransactional integrityVSAvoidprotocol complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The schema merger acts as a centralized intermediary that coordinates schema changes from multiple services. It receives partial schemas, resolves conflicts, and generates a unified schema that can be applied in a single database transaction, eliminating the need for complex distributed transaction protocols while maintaining transactional integrity.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces complex mechanical distributed transaction protocols with a schema-based coordination mechanism. Instead of using distributed locking, two-phase commitment, or other complex transaction protocols, the system uses schema merging and conflict resolution to achieve consistent database updates with simpler operational mechanics.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

4Reliability

If a unified database schema is enforced, then data consistency is improved, but flexibility for domain-specific optimizations is reduced

Engineering Contradiction:

Improvedata consistencyVSAvoiddomain-specific optimization

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The database schema is divided into multiple partial schemas, each tailored to specific domain requirements or service needs. This segmentation allows domain-specific optimizations in data layout and structure while maintaining overall consistency through the schema merging process that integrates all partial schemas into a unified database schema.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS10346373B1Merging and vending partial database schemas

Publication Date: 2019.07.09 AMAZON TECH INC

AI summary

Technologies are disclosed for merging and vending partial database schemas. A schema compiler exposes a network services application programming interface (API) for merging partial database schemas for a database. Prior to merging partial database schemas, the schema compiler can determine whether namespace conflicts exist between the partial database schemas. If no namespace conflicts exist between the partial database schemas, the schema compiler can merge the partial database schemas to create a merged database schema. The merged database schema can then be provided to a database service that provides the database. The API can also include methods for retrieving partial database schemas from the merged database schema, updating or replacing database schemas in the merged database schema, and deleting partial database schemas from the merged database schema.