переведи Bahta-Atay [21] propose Single-Table Data Mapping (STDM) and Multi-Table Data Map-
ping (MTDM) algorithms to map JSON documents into relational tuples, which are inspired by
the universal and binary approaches [59]. STDM and MTDM algorithms build a JSON tree derived
from the JSON document, where nodes represent JSON elements and edges represent parent-child
relationships (see Figure 2(b)). Then, they store the JSON tree in the following tables:
(1) The STDM maps the JSON tree into a table:
❶ STDM (elementID, parentElementID, elementName, valText, valNumeric).
(2) The MTDM creates two separate tables to store non-leaf and leaf nodes, respectively:
❶ NonLeafTable (elementID, parentElementID);
❷ LeafNodeTable (elementID, parentElementID, value).
Irshad et al. [66] propose transforming JSON schema into a relational schema by parsing the
JSON schema file, preserving the extracted information in the following metadata tables, creating
relational tables with a vertical table approach by reading these two metadata tables, and storing
the JSON data in the created tables.
(1) RelationalStructureMasterTable (RS_ID, level, objectName, tableName, attributeCategory, parentLevel, pkCol-
umn);
(2) RelationalStructureChildTable (RS_CID, attributeName, columnName, attributeDataType, required, RS_ID).
DiScala and Abadi [46] present a three-phase unsupervised machine learning (ML) algo-
rithm to automatically design a relational schema for an input JSON document. The first phase
starts with transforming the JSON data into a flat table similar to the universal relation model.
Next, it identifies “soft” functional dependencies among attributes. After that, it leverages them to
decompose the previous flat table into a collection of smaller tables joined by primary-to-foreign
key relationships. Each small table consists of a group of attributes that exhibit similar functional
relationships and are likely to correspond to an independent semantic entity. The second phase
searches these entities to discover semantically equivalent entities with overlapping attributes and
merge them into a single entity to eliminate redundant storage. The third phase combines the inter-
mediate tables produced from the previous two phases to create a relational schema for avoiding
excessive normalization.
DVP is proposed in [118], which presents Dynamic Vertical Partitioning (DVP) technology
utilizing heuristics to adapt the data layout for the workload dynamically. DVP groups some at-
tributes accessed together in queries into the same partition (smaller table) by an algorithm with
polynomial complexity. This dynamic partition is based on two criteria: awareness of workload
access patterns and data sparseness awareness. Specifically, when the DVP is invoked, it starts
with the current layout (or an initial partitioning) and generates a new layout by incrementally
refining the current schema. At each iteration, DVP examines all existing attributes and partitions.
For each attribute-partition pair, DVP calculates the gain of moving the attribute to the specific
partition. When there is no further cost improvement, DVP stops and returns a new layout.
Petković [101] proposes using the following schema to store JSON documents, where it assigns
a unique ID for each element and preserves its corresponding parent ID.