Virtual Column Object-Relational Mapping Schema Stability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional object relational mapping techniques require frequent updates to the relational database schema to match changes in the object model, leading to resource-intensive modifications and disruptions in database applications, especially in fast-paced development environments.

Innovation Solution

The introduction of a virtual column in the relational model that allows new attributes to be added to an object type without requiring new columns in the corresponding table, with unmapped attributes stored in a virtual column or an auxiliary table as name-value pairs, enabling seamless mapping between object and relational models.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If the relational model is modified to match changes in the object model, then the object model can be updated frequently, but the database schema modification requires large amount of resources and may slow down the database

Engineering Contradiction:
Improveobject model flexibilityVSAvoidresource consumption
Core Design Contradiction:
Adaptability or versatilityVSLoss of energy

Solution Approach 1:

The patent segments the attributes of an object type into two categories: mapped attributes that correspond to distinct columns in the table, and unmapped attributes that are stored in a virtual column. This segmentation allows the relational model to remain stable while the object model can be modified freely, as changes to unmapped attributes only affect the virtual column storage rather than requiring schema modifications.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The virtual column acts as an intermediary between the object model and the relational model. It absorbs the flexibility requirements of the object model without propagating changes to the underlying relational schema, thereby enabling frequent object model updates without triggering resource-intensive database schema modifications.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If the database schema is modified to add new columns for new attributes, then the mapping between object and relational models remains consistent, but the database upgrade disrupts applications using the database

Engineering Contradiction:
Improvemapping consistencyVSAvoidapplication continuity
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

By segmenting attributes into mapped and unmapped categories, the patent enables new attributes to be added to the object model without requiring corresponding columns in the relational table. New unmapped attributes are stored in the existing virtual column, allowing mapping consistency to be maintained through the virtual column mechanism while avoiding database schema modifications that would disrupt applications.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The virtual column is pre-configured in the table schema to accommodate future attributes. This preliminary action ensures that when new attributes are added to the object model, they can be immediately stored in the virtual column without requiring subsequent database schema changes, thereby maintaining application continuity while ensuring mapping consistency.

Inventive Principle:
Principle #10Preliminary action

3Stability of the object's composition

If developers are limited to making only major releases of software, then the database schema remains stable, but the development speed is reduced

Engineering Contradiction:
Improvedatabase schema stabilityVSAvoiddevelopment speed
Core Design Contradiction:
Stability of the object's compositionVSProductivity

Solution Approach 1:

The patent enables developers to add new attributes to the object model at any time without being constrained to major releases. By segmenting attributes into mapped and unmapped categories and storing unmapped attributes in a virtual column, the system maintains database schema stability while allowing continuous object model evolution, thereby significantly improving development speed without sacrificing schema stability.

Inventive Principle:
Principle #1Segmentation

4Adaptability or versatility

If new columns are added to the table for new attributes, then the object model can be extended, but the device complexity increases

Engineering Contradiction:
Improveobject model extensibilityVSAvoidtable structure complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

By segmenting attributes into mapped and unmapped categories, the patent allows object model extension without increasing table structure complexity. New attributes are classified as unmapped and stored in the virtual column, avoiding the need to add new columns to the table. This maintains simple table structures while enabling unlimited object model extensibility.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS9430554B2Object-relational mapping based on virtual columns
Publication Date: 2016.08.30 BLOCK INC
  • US9430554B2 patent drawing
  • US9430554B2 patent drawing
  • US9430554B2 patent drawing

AI summary

A server system allows object relational mapping. Objects of an object type are stored as records in a table corresponding to the object type. The server system allows new attributes to be added to an object type without altering the corresponding table. The object type comprises a set of mapped attributes that correspond to distinct columns of the associated table. The object type further comprises unmapped attributes that fail to map to distinct columns of the table. The table is associated with a virtual column for storing the unmapped attributes. The unmapped attributes of an object of the object type are encoded into a value and stored in the virtual column. The virtual column may be a column of the same table or a column of an auxiliary table. The unmapped attributes may also be stored as name value pairs in an auxiliary table associated with the table.