Mapping Specification Language for ORM Flexibility

Solution Overview

Problem

Existing Object-Relational Mapping (ORM) solutions are often ad-hoc, complex, and difficult to use, lacking flexibility and efficiency in translating data between object-oriented programs and database storage tables.

Innovation Solution

A mapping specification language is introduced that allows developers to control the mapping process from objects to database tables, enabling flexible compilation into runtime transformation functions and validation, supporting various mapping patterns like Table per Hierarchy, Table per Type, and Table per Class, while generating views that describe relationships between model extents and database tables.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If ad-hoc mapping solutions are used, then implementation flexibility is improved, but system complexity and difficulty of use increase

Engineering Contradiction:
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The mapping specification is divided into distinct components: source specification, filter (optional), and projection. Each component can be independently configured and combined to create different mapping patterns (TPH, TPT, TPC), allowing flexible implementation while maintaining a structured, manageable syntax that reduces overall system complexity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system supports multiple mapping patterns (Table per Hierarchy, Table per Type, Table per Class) that can be selected by changing parameters in the mapping specification. This allows the same specification framework to adapt to different database schemas and object models, providing flexibility without requiring completely different solutions for each pattern.

Inventive Principle:
Principle #35Parameter changes

2Extent of automation

If existing ORM solutions are used, then data translation capability is provided, but ease of operation and user-friendliness deteriorate

Engineering Contradiction:
Core Design Contradiction:
Extent of automationVSEase of operation

Solution Approach 1:

The mapping specification uses a simplified syntax that copies and adapts the familiar object-oriented programming style. Developers can express mappings using standard programming concepts (sources, filters, projections) rather than learning a completely new domain-specific language, making the system easier to operate while maintaining automated data translation capabilities.

Inventive Principle:
Principle #26Copying

3Manufacturing precision

If complex mapping specifications are used, then mapping precision and control are improved, but productivity and development time increase

Engineering Contradiction:
Core Design Contradiction:
Manufacturing precisionVSProductivity

Solution Approach 1:

The system performs preliminary validation of the mapping specification against the database schema and object model before execution. This early detection of errors and inconsistencies ensures mapping precision is maintained while avoiding time-consuming runtime debugging and correction, thereby improving productivity.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The mapping specification framework is designed to be universal, supporting multiple mapping patterns (TPH, TPT, TPC) and various data translation scenarios through a single unified syntax. This multi-functionality eliminates the need for developers to write separate specialized mappings for different patterns, reducing development time while maintaining precise control over each mapping scenario.

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

Data Source

PatentUS8739118B2Pragmatic mapping specification, compilation and validation
Publication Date: 2014.05.27
  • US8739118B2 patent drawing
  • US8739118B2 patent drawing
  • US8739118B2 patent drawing

AI summary

Facilitating translation of data between object oriented programs and database storage tables. A method includes receiving user input from a user. The user input includes a plurality of parts. Each part includes a specification of a source (such as a type source), optionally a filter, and a projection. Each projection assigns values to table columns. Based on the plurality of parts received, the method includes generating one or more views. The one or more views describe relationships between model extents and database tables.