Common Object Model for Multi-Vendor Database Abstraction
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Developers face complexity in bridging data representations between applications and databases due to impedance mismatches, requiring intricate data transformations, and current solutions often necessitate database vendor-specific coding, leading to inefficiencies and increased development time.
Innovation Solution
A system and method that generates database entity models using entity models, receiving vendor-specific store schema descriptions to create a common object model, providing a unified interface across multiple database types and enabling common access, thus abstracting database vendor dependencies.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If database vendor specific store schema descriptions are used, then database access functionality is achieved, but programming effort and expenditure increase due to vendor-specific coding requirements
Solution Approach 1:
The patent introduces a common object model as an intermediary layer between the application and vendor-specific database systems. This mediator translates application data access requests into vendor-specific SQL operations, eliminating the need for applications to directly code vendor-specific database operations. The common object model serves as the intermediary that handles the complexity of vendor-specific implementations while presenting a unified interface to applications.
Solution Approach 2:
The patent creates a universal common object model that can work with multiple database vendors through a single interface. This universal model provides multi-functional capability by supporting access to different vendor-specific database systems (Oracle, SQL Server, DB2, etc.) without requiring separate coding for each vendor. The common object model adapts to different vendors while maintaining consistent application-level operations.
2Adaptability or versatility
If vendor-specific coding is used to access different database types, then database compatibility is achieved, but development time and expenditure increase
Solution Approach 1:
The patent creates a copied and abstracted representation of vendor-specific database schemas in the form of a common object model. Instead of directly working with vendor-specific schemas, the system creates a universal copy that mirrors the essential structure and operations across different vendors. This copied model can be generated automatically from vendor-specific schemas, reducing manual development time while maintaining compatibility.
Solution Approach 2:
The patent performs preliminary actions by automatically generating the common object model from vendor-specific store schemas before application development begins. This pre-generation of the common model eliminates the need for developers to manually adapt code for each vendor later. The preliminary creation of vendor-agnostic abstractions sets up the system for rapid development across multiple database platforms.
3Adaptability or versatility
If data transformations are implemented to bridge application and database models, then data mapping capability is achieved, but transformation complexity increases
Solution Approach 1:
The common object model serves as an intermediary that simplifies data transformations between applications and vendor-specific databases. Rather than implementing complex transformation logic directly in applications, the common object model mediates these transformations by providing a standardized representation that automatically maps to different vendor schemas. This mediator handles the complexity of data mapping internally while presenting simple operations to applications.
Data Source
AI summary
The claimed subject matter provides a system and/or method that generates or creates database entity models using entity models. The system can include devices and components that receive database vendor specific store schema descriptions. The vendor specific store schema descriptions can be employed in conjunction with mapping files that characterize a instance of a database to generate a common object model that can be used to provide a common interface comprehensible across multiple vendor or database types.