Database Row Properties for Advanced Functions

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing relational database management systems face challenges in introducing advanced functional behaviors without introducing new data types, which is costly and complex, and requires significant programming efforts, slowing the adoption of new user-defined data types.

Innovation Solution

Implementing row properties within a relational database management system as a mechanism to introduce advanced functional behaviors without adding new data types, where row properties are defined over existing columns and executed by the RDBMS to perform specific functional behaviors.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If new user-defined data types are introduced into the database to provide advanced functional behaviors, then the functionality and versatility of the database system is improved, but the engineering cost and complexity of implementing and maintaining these new data types increases significantly

Engineering Contradiction:
ImprovefunctionalityVSAvoidengineering cost
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary layer (the mapping mechanism and conversion functions) between the application programming language and the database system. This intermediary allows existing basic data types in the database to represent advanced functional behaviors through software abstractions rather than requiring new database data types. The mapping layer translates between basic database types and application-level complex types, thereby providing advanced functionality without modifying the core database data type system.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent creates software copies or representations of advanced data types through mapping functions and conversion routines. Instead of implementing new physical data types in the database, the system creates virtual representations in the application layer that map to existing database types. This copying approach allows the database to maintain its simple data type system while applications can use complex data types through software abstractions.

Inventive Principle:
Principle #26Copying

2Adaptability or versatility

If new user-defined data types are introduced into the database, then advanced functional behaviors are enabled, but the adoption rate is slowed due to lack of native support in programming languages and productivity tools

Engineering Contradiction:
ImprovefunctionalityVSAvoidadoption rate
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The mapping mechanism serves as an intermediary that translates between programming language data types and database data types. Since programming languages already have native support for basic data types, this intermediary layer allows applications to use familiar data types while the database stores data in its native format. This eliminates the need for programmers to learn or adapt to new database-specific data types, thereby accelerating adoption.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent makes existing database basic data types serve multiple functions by introducing mapping mechanisms. The same basic data type (e.g., VARCHAR) can represent different application-level concepts (e.g., address, phone number, email) through different mapping functions. This universality allows programming languages to continue using their standard data types while the database provides specialized functionality through the mapping layer, reducing the time needed for adoption.

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

3Adaptability or versatility

If a two-way conversion function is implemented between user-defined data types and basic data types, then compatibility between application and database is improved, but the system complexity and processing overhead increases

Engineering Contradiction:
ImprovecompatibilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent extracts the conversion logic from the core database engine and places it in the application layer or as separate mapping functions. This extraction allows the database to maintain its simple, efficient data type system while conversion functions handle the translation to and from application data types. By taking out the conversion complexity from the database core, the system achieves compatibility without increasing database system complexity.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The mapping functions serve as intermediaries that handle the two-way conversion between application data types and database basic types. These intermediaries are designed to be lightweight and efficient, using cached conversion rules and optimized translation paths. The intermediary layer manages the complexity of conversion while keeping the database engine simple and fast.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS8386522B2Technique to introduce advanced functional behaviors in a database management system without introducing new data types
Publication Date: 2013.02.26 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US8386522B2 patent drawing
  • US8386522B2 patent drawing
  • US8386522B2 patent drawing

AI summary

A row property provides a mechanism for implementing advanced functional behavior in a relational database management system (RDBMS) without introducing new data types. A row property is part of a table definition, such that, when a table is defined in the RDBMS, at least one row property is specified for one or more associated columns of rows of the table, wherein the row property has an associated functional behavior that is predefined within the RDBMS. The columns associated with the row property are generally of existing data types supported by an RDBMS. A row property may be invoked when the RDBMS processes a language statement that references the row property. When the row property is invoked, the RDBMS executes programming logic associated with the row property, in order to perform the advanced functional behavior using data stored in the associated columns.