Hierarchical Data Server Using CRUST Operators

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing query languages for hierarchical data structures, such as SGML, lack effective operators and operations to efficiently retrieve and modify data, as they are primarily designed for relational databases and do not utilize CRUST operators or set operations on property lists.

Innovation Solution

A dedicated query language and system that uses CRUST operators (Cast, Restrict, Unique, Sort, Traverse) and data vine lists to facilitate querying and modifying hierarchical data structures, allowing for recursive data access and manipulation within a hierarchical data server.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If SQL-like query languages are used for hierarchical data, then the system can leverage existing relational database tools, but the query capability is limited and less constructible for hierarchical structures

Engineering Contradiction:
Improvequery capabilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent changes the fundamental parameters of the query language from SQL's relational model to a hierarchical model with CRUST operators. This involves changing the data model parameters (from tables to hierarchical structures), the query syntax parameters (from SELECT-WHERE to CRUST operators), and the operational parameters (from set-based operations to recursive traversal operations). These parameter changes enable the system to natively support hierarchical data structures while maintaining query effectiveness.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The query language is segmented into distinct CRUST operators (Cast, Restrict, Unique, Sort, Traverse) that can be independently applied and combined. Each operator handles a specific aspect of hierarchical data manipulation, allowing the system to build complex queries from simpler, well-defined components. This segmentation makes the query language more constructible and easier to implement than a monolithic SQL-like approach.

Inventive Principle:
Principle #1Segmentation

2Productivity

If SQL-like languages with FLWOR expressions are used, then the system can process hierarchical data, but the operations are not optimized for hierarchical structures and lack CRUST operators

Engineering Contradiction:
Improvedata retrieval efficiencyVSAvoidquery construction ease
Core Design Contradiction:
ProductivityVSEase of operation

Solution Approach 1:

The hierarchical data structure serves itself through the CRUST operators that are specifically designed to work with hierarchical patterns. The Traverse operator automatically navigates the hierarchical structure, the Cast operator automatically converts data types appropriate for hierarchical data, and the Unique operator automatically handles duplication issues in hierarchical contexts. This self-service approach eliminates the need for complex manual query construction and optimization that would be required with SQL-like languages.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system performs preliminary actions by pre-defining the CRUST operators and their behavior patterns for hierarchical data. The operators are pre-configured to understand hierarchical relationships, traversal patterns, and data conversion requirements. This preliminary preparation of the query language infrastructure makes subsequent data retrieval operations more efficient and easier to construct, as users don't need to reinvent hierarchical query logic for each operation.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If the system is designed for relational databases, then the system can utilize existing database infrastructure, but it cannot effectively retrieve and modify hierarchical data structures

Engineering Contradiction:
Improvedata management reliabilityVSAvoidhierarchical data support
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The hierarchical data server is designed with universal CRUST operators that can handle multiple types of hierarchical data structures and operations. The same set of operators (Cast, Restrict, Unique, Sort, Traverse) can work with different hierarchical data formats, nested structures, and query patterns. This multi-functionality provides reliable data management for hierarchical structures while maintaining adaptability across various data types and scenarios, something that SQL-like languages cannot achieve with their relational-focused design.

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

Data Source

PatentUS9218393B2Hierarchical data server
Publication Date: 2015.12.22 LI QIFANG
  • US9218393B2 patent drawing
  • US9218393B2 patent drawing
  • US9218393B2 patent drawing

AI summary

A hierarchical data server provides a query and storage system for hierarchical data with three interfaces that are, data interface for accepting hierarchical data, query interface for accepting a query, and result interface for returning output of the query. The system models hierarchical data with one data object called data vine and one data structure type called data vine list. A data vine includes a name, a property list, and a child list. A data vine list is an ordered list of data vines. A data vine is recursively defined with its child list as a data vine list. The system introduces five basic operators, cast, restrict, unique, sort, and traverse. Each operator acts on one data vine list and returns another data vine list. A property list in a data vine is unordered with set operations implemented, which include default operation, update operation, elimination operation, replacement operation, and intersection operation.