Isolation Layer Mapping for Flexible Schema Data Storage
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Predefined-schema data storage systems struggle to accommodate highly flexible schemas, leading to performance penalties when trying to store data with dynamic schema changes, as existing approaches either rob the database of optimization capabilities or require complex schema knowledge in applications.
Innovation Solution
An isolation layer is introduced that defines relationships between object model data fields and data store fields using attributes, allowing for a 'part structured and part variable' data schema without exposing it through the object model, using reflection to build a mapping table that adapts to changes in the data store structure.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If data is stored in XML or blobs in the database, then the schema can be stored and manipulated in a consistent manner, but the data store loses the ability to use schema knowledge to optimize operations
Solution Approach 1:
The patent segments the data storage system into multiple layers: an object model layer for structured data access, an isolation layer for schema mapping and transformation, and a data store layer for physical storage. This segmentation allows each layer to operate independently with optimized performance characteristics while maintaining schema flexibility through the isolation layer's mapping capabilities.
Solution Approach 2:
The isolation layer acts as an intermediary between the object model and the data store. It contains mapping tables that translate between object model properties and data store columns, allowing the system to maintain both structured access patterns and flexible schema representation without sacrificing performance optimization.
2Productivity
If some data is stored as normal database objects and the remainder as blob/XML or property/value pairs, then the data store can know about the schema and use it in operations, but the application must be written knowing which parts are stored where
Solution Approach 1:
The system uses reflection to automatically generate mapping tables at runtime by examining the object model properties and their associated attributes. This self-service mechanism eliminates the need for manual configuration of which data parts are stored where, as the system automatically discovers and maps the relationships between object properties and data store columns.
Solution Approach 2:
The patent uses attributes as parameters attached to object model properties to encode mapping information. These attributes can be dynamically configured and modified without changing the application code structure, allowing flexible schema management while maintaining optimized data access patterns.
3Adaptability or versatility
If the schema is moved to a higher layer in the software stack, then the schema can be flexible and variable, but the data store cannot use schema knowledge to optimize operations
Solution Approach 1:
The patent introduces a new dimensional layer (the isolation layer) between the object model and data store, rather than simply moving the schema to a higher layer. This isolation layer operates in a separate dimension of the software stack, containing mapping tables that bridge the structured object model and the flexible data store schema, thereby maintaining both flexibility and optimization capabilities.
Data Source
AI summary
The relationships between physical data store schema, object model, and end-user property may be encoded in the source of the object model using attributes. Reflection may be used to build the table of those relationships so that changes to the relationships between those three layers can be easily and quickly made without impacting higher levels in the software stack.