Database Schema Version Conversion for Continuous Data Operations

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Changing a database schema often requires interrupting user access and can lead to data loss and service disruptions, especially when multiple systems depend on the schema, and autonomous AI systems are not authorized to manage these changes due to potential disruptions.

Innovation Solution

A method and system for creating conversion rules to translate data between different database schema versions, allowing schema changes to be made autonomously and minimizing downtime by supporting multiple schema versions concurrently, with user intervention only when necessary to avoid data loss.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If database schema changes are applied directly, then the schema structure is updated, but user access is interrupted and service disruption occurs

Engineering Contradiction:

Improveschema update capabilityVSAvoiduser access continuity

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The schema evolution process is segmented into distinct phases: the original schema version continues to serve user requests while a new schema version is created and tested. This segmentation allows schema updates without forcing all users to switch simultaneously, maintaining service continuity while enabling schema adaptability.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The new schema version is created and prepared in advance before being made active. Conversion rules are pre-defined and validation is performed on the new schema before it becomes the default, allowing schema changes to be applied without interrupting user access to the existing schema.

Inventive Principle:

Principle #10Preliminary action

2Adaptability or versatility

If schema changes are made to accommodate new requirements, then the database structure becomes more adaptable, but data loss risk increases

Engineering Contradiction:

Improveschema flexibilityVSAvoiddata loss risk

Core Design Contradiction:

Adaptability or versatilityVSLoss of substance

Solution Approach 1:

Conversion rules act as an intermediary mechanism between the original schema and the new schema. These rules define how data is transformed during schema evolution, ensuring that data is preserved and properly converted rather than lost during the transition process.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The system validates conversion rules and performs data validation before applying schema changes. This feedback mechanism ensures that data integrity is maintained throughout the schema evolution process, preventing data loss by identifying and correcting issues before they occur.

Inventive Principle:

Principle #23Feedback

3Reliability

If multiple schema versions are supported concurrently, then user access continuity is maintained, but system complexity increases

Engineering Contradiction:

Improveservice continuityVSAvoidschema management complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The database system is designed to universally support multiple schema versions through a common interface. The schema manager can handle different schema versions using the same conversion rules and validation mechanisms, reducing the complexity that would otherwise arise from managing multiple version-specific systems.

Inventive Principle:

Principle #6Universality (Multi-functionality)

4Productivity

If autonomous AI systems are authorized to manage schema changes, then operational efficiency improves, but disruption risk increases

Engineering Contradiction:

Improveschema change efficiencyVSAvoidservice stability

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The system enables autonomous schema evolution through self-service mechanisms where the database can automatically create new schema versions, define conversion rules, and validate changes without requiring constant human intervention. This maintains efficiency while reducing disruption risk through automated validation and rollback capabilities.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

Automated validation and testing provide feedback to the autonomous schema management system, allowing it to detect potential issues before they cause disruptions. This feedback loop enables efficient autonomous operation while maintaining service stability through automated quality control.

Inventive Principle:

Principle #23Feedback

Data Source

PatentUS12493594B2Methods and systems for changing a database schema

Publication Date: 2025.12.09 ENGYN PTY LTD

AI summary

Disclosed are a method and a system for changing a database schema. The method comprises receiving a request to make a set of changes to a first version of the database schema of a database, and creating, based on the set of changes to the first version, a conversion rule for converting data records maintained by the database between the first version and a second version of the database schema. The second version results from the application of the set of changes to the first version of the database schema. The method further comprises storing the conversion rule for retrieval when performing data operations on the data records in accordance with any database schema version in a set of supported versions comprising the first version and the second version of the database schema. Also disclosed are methods and systems for performing data operations on databases supporting multiple versions of a database schema.