Central Repository Schema Simplification for Cross-System Data Exchange
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing data management systems face challenges in efficiently sharing data across systems with different data layouts, vocabularies, languages, requirements, and protocols, leading to complexity, cost, and errors in maintaining transformational mappings, and do not support optimized schema design and management.
Innovation Solution
A central repository system manages data objects and models, applying rules to flatten data structures, remove extraneous data, and enable efficient data exchange, eliminating the need for manual transformation mappings by generating products from a centralized hub.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If development teams create transformational mappings to ensure data communication between applications, then data sharing capability is improved, but system complexity and maintenance cost increase
Solution Approach 1:
The patent segments the data model into a canonical model (enterprise-level) and local models (team-level), allowing each team to work with simplified local models while automatically transforming to the canonical model. This segmentation eliminates the need for teams to maintain complex transformational mappings between each other, as the central system handles the canonical transformations.
Solution Approach 2:
The central repository system acts as an intermediary between development teams and the canonical model. Teams interact with simplified local models in their own data languages, and the central system automatically transforms these to the canonical model for enterprise-wide communication. This intermediary eliminates the need for teams to directly manage complex transformational mappings.
2Measurement precision
If development teams manually maintain transformational mappings, then data transformation accuracy is improved, but time consumption and error rate increase
Solution Approach 1:
The central repository system performs self-service by automatically generating and maintaining transformational mappings between the canonical model and local models. The system autonomously handles schema evolution, transformation generation, and updates without requiring manual intervention from development teams, thereby eliminating maintenance time while preserving accuracy through systematic generation.
Solution Approach 2:
The system performs preliminary action by pre-defining the canonical model with standardized data structures and relationships. Local models are designed to map to this pre-established canonical structure, so transformations are generated in advance based on the canonical schema rather than requiring manual maintenance after the fact.
3Stability of the object's composition
If development teams use rigid data objects from the repository, then data consistency with canonical model is improved, but flexibility for customization is reduced
Solution Approach 1:
The patent segments data objects into canonical model definitions (stable, enterprise-wide) and local model instantiations (flexible, team-specific). Teams can customize local models to their specific needs while the canonical model remains stable. The central system handles the mapping between these segments, allowing customization without compromising consistency.
Solution Approach 2:
The system introduces dynamics by allowing local models to be dynamically configured and evolved based on team needs, while automatically maintaining their relationship to the stable canonical model. The transformational mappings are dynamically generated and updated as local models change, providing flexibility without sacrificing consistency.
4Quantity of substance
If development teams include all data objects from the canonical model, then data completeness is improved, but processing performance and resource consumption worsen
Solution Approach 1:
The patent segments data objects into the complete canonical model (for reference) and selective local model subsets (for consumption). Each development team only works with and consumes the specific subset of data objects relevant to their product, rather than all canonical model objects. The central system maintains the complete canonical model for consistency while local teams process only necessary data.
Solution Approach 2:
The system extracts only the necessary data objects from the complete canonical model for each local team's consumption. Local models are created by extracting relevant canonical model elements based on team-specific requirements, eliminating unnecessary data processing while maintaining completeness for the extracted subset.
Data Source
AI summary
Methods and systems disclosed herein describe generating products using data objects and/or entities that comply with a canonical/governed model(s). The data objects and/or entities may be obtained from an enterprise model or a combination of an enterprise model and one or more local models within a central repository to generate the new product data structures. Once all the data objects and/or entities have been added to the new product, one or more simplification rules may be applied to the new product to flatten (optimize for consumption) the data structure of the product such that superfluous or extraneous code snippets may be removed, or reduced, in such a way that the product complies with the canonical model. The new product may then be exported to an executable data format, which can either be incorporated in another application or used as a standalone product.