Native support of JSON binary views in database management system

Abstract

The JSON binary view is an object view that returns a JDV object. The JDV objects are virtual as they are not stored in the database as JSON objects. Instead, the JDV objects are stored in split form across tables and table attributes (e.g., columns) and returned by the DBMS in response to database commands for requesting the JDV objects from the JSON binary view. Through the JSON binary view, changes to the state of the JDV object may be specified at the JDV object level. The JDV object is updated in the database using an optimistic lock.

Description

Field of the Invention

[0001] The present disclosure relates to storage of JavaScript Object Notation (JSON) objects in a database management system (DBMS), including a relational DBMS (RDBMS) and a DBMS that stores collections of tables or documents, such as JSON objects.

[0002] Related Applications

[0003] This application is related to U.S. patent application entitled “Techniques for Comprehensively Supporting JSON Schema in a RDBMS” filed on the same date by Zhen Hua Liu et al. with attorney docket number 50277-5882, the entire contents of which are incorporated herein by reference. Background Art

[0004] JSON is a lightweight data specification language for formatting "JSON objects". A JSON object consists of a collection of fields, where each field is a field name / value pair. The field name is actually the tag name of the node in the JSON object. The name of the field is separated from the value of the field by a colon.

[0005] Both RDBMS vendors and non-SQL vendors support JSON functionality to varying degrees. In particular, RDBMS vendors support storing JSON text in varchar or character large object (CLOB) columns and applying structured query language (SQL) and / or JSON operators to JSON text as specified by the SQL / JSON standard. RDBMS can also include native JSON data types. Columns can be defined as JSON data types, and dot notation can be used to reference JSON fields within the column. JSON operators can operate on columns with JSON data types.

[0006] Another important way that RDBMS vendors support JSON functionality is to enable the generation of JSON objects through object views of relational data. Under the object view approach, the data of individual JSON objects is stored and retrieved across multiple columns in one or more tables of the relational database. Each of the field values ​​of the JSON object can be stored separately in a corresponding column across multiple tables of the relational database. In fact, the values ​​of the JSON object are shredded across multiple columns of one or more underlying tables.

[0007] The object view method provides duality for querying JSON object content. JSON object content can be accessed as a JSON object or as relational data. Through SQL commands, JSON object content can be accessed as a table with rows and columns. Through object views, JSON object content can be returned as a JSON object with fields including object fields and array fields.

[0008] Unfortunately, RDBMS vendors have not implemented duality for changing the content of JSON objects under the object view approach. RDBMS provides a very efficient way to modify data as relational data, efficiently processing DML (Data Manipulation Language) commands issued against columns and tables.

[0009] However, RDBMS does not provide the capability to process commands that specify changes to JSON objects in object views. To change JSON objects, DML commands that specify changes to the underlying tables and columns must be issued.

[0010] Based on the above, it is desirable to provide a method for RDBMs to handle commands that specify changes to JSON objects returned by object views. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In the figure:

[0012] Figure 1 is a diagram depicting DDL statements defining a JSON duality view and JDV objects returned by the JSON duality view according to an embodiment of the present invention.

[0013] Figure 2A is a diagram of rewriting database commands based on a JSON duality view according to an embodiment of the present invention.

[0014] Figure 2B is a diagram depicting DDL statements defining a JSON duality view and JDV objects returned by the JSON duality view according to an embodiment of the present invention, wherein the JSON duality view is based on a single root table.

[0015] Figure 3 The present invention is a diagram depicting DDL statements defining a JSON duality view and a JDV object returned by the JSON duality view, wherein the JSON duality view includes a sub-table and a root table of an object field within an object view schema of the JSON duality view.

[0016] Figure 4 is a diagram depicting DDL statements defining a JSON duality view and a JDV object returned by the JSON duality view according to an embodiment of the present invention, wherein the JSON duality view includes a sub-table and a root table of an array field within an object view schema of the JSON duality view.

[0017] Figure 5 is a diagram depicting an archetype of an object hierarchy and a table hierarchy of a JSON duality view according to an embodiment of the present invention.

[0018] Fig. 6A is a diagram depicting the JDV objects returned by the three-table JSON Duality View.

[0019] Figure 6B is a diagram depicting an object hierarchy and a table hierarchy of a JSON duality view according to an embodiment of the present invention.

[0020] Figure 7 A base recordset hierarchy and a corresponding table hierarchy of a JSON duality view according to an embodiment of the present invention are depicted.

[0021] Figure 8 A version signature function according to an embodiment of the present invention is depicted.

[0022] Fig. 9 Depicted are a call hierarchy and a corresponding object hierarchy of a version signature according to an embodiment of the present invention.

[0023] Fig.10 Depicted are a call hierarchy and a corresponding object hierarchy of a version signature according to an embodiment of the present invention.

[0024] Fig.11 Depicted is a database command rewritten to return a JDV object according to an embodiment of the present invention.

[0025] Fig.12 A flow chart of optimistic serialized updating according to an embodiment of the present invention is depicted.

[0026] Fig.13A Depicted are DDL statements defining a JSON duality view with annotations depicting change permissions according to an embodiment of the present invention.

[0027] Fig. 13BDepicted are DDL statements defining a JSON duality view with annotations depicting change permissions according to an embodiment of the present invention.

[0028] Fig.14 Depicted are DDL statements defining a JSON duality view with annotations depicting change permissions and a JDV object returned by the JSON duality view according to an embodiment of the present invention.

[0029] Fig.15A and Fig. 15B The syntax of a DDL statement for defining a JSON duality view according to an embodiment of the present invention is depicted.

[0030] Fig.16 Depicted are DDL statements for defining a JSON duality view using a simplified syntax and a JSON schema for the JSON duality view.

[0031] Fig.17 A computer system is depicted that may be used to implement embodiments of the invention.

[0032] Fig.18 Describes the software systems that can be used to control operations. DETAILED DESCRIPTION

[0033] In the following description, for the purpose of explanation, many specific details are set forth to provide a thorough understanding of the present invention. However, it will be clear that the present invention can be practiced without these specific details. In other cases, structures and devices are shown in block diagram form to avoid unnecessary obscurity of the present invention.

[0034] Overview

[0035] This article describes JSON duality views. JSON duality views are object views that return JSON duality view objects ("JDV objects"). JDV objects are virtual in that they are not stored in the database as JSON objects. Instead, JDV objects are stored in a split form across tables and table attributes (e.g., columns) and are returned by the DBMS in response to a database command requesting a JDV object from a JSON duality view.

[0036] Importantly, through the JSON duality view, changes to the state of a JDV object can be specified at the JDV object level. From a general point of view, this capability is similar to specifying state changes at the column level within a DBMS. The DBMS can execute database statements that assign values ​​to columns. Similarly, the DBMS can execute statements that assign or set the state of a JDV object to a copy or instance of the JDV object that has been changed. The DBMS determines the specific underlying records in the database that need to be modified, and then modifies those records.

[0037] Thus, changes can be specified at the JDV object level or at the underlying attribute level of the underlying record storing the contents of the JDV object. The ability to specify changes at these two levels can be referred to as data manipulation duality.

[0038] Applications that modify JSON objects are configured based on the assumption that changes can be made to JSON objects serially. Changes are made serially when, at the moment of committing the new state of the JSON object, the current state of the JSON object reflects only those changes after the database transaction assigns a new state to the JSON object that reflects the changes made to the database transaction and then commits the new state of the JSON object.

[0039] To ensure serializability, you can use pessimistic concurrency control to change JDV objects. Under pessimistic concurrency control, the application starts a database transaction and "pessimistically" locks the JDV object, which at least locks all underlying records of the JDV object. The application then retrieves a copy of the JDV object through the JSON binary view, makes changes to the copy, and then issues a database command to the DBMS through the database transaction to update the JDV object to the copy.

[0040] Pessimistic concurrency control guarantees serializability because no other changes can be made to the underlying records while a JDV object is locked. Unfortunately, pessimistic concurrency control adversely affects system performance by generating relatively more locks, which are held for relatively long periods of time. Applications (especially Web applications that interact with the DBMS over the Internet) may hold locks on JDV objects for relatively long periods of time.

[0041] This article describes a method for updating JDV objects using optimistic concurrency control as an alternative to pessimistic concurrency control. The method minimizes locking while ensuring serializability. Under the method, a copy of the JDV object is retrieved from the DBMS through a JSON duality view. The copy of the JDV object is modified to a new version. A database statement is submitted to update the JSON object to the new version. In response, the DBMS updates and submits confirmation of the new version only if the DBMS can ensure serializability. The number of underlying records and the period of time that the records are locked are minimized. Before retrieving the copy to be modified, it is not necessary to lock all the underlying records of the JDV object as under pessimistic concurrency control.

[0042] The method of optimistic concurrency control is referred to herein as optimistic serializable updates.

[0043] Applicability to various types of DBMS

[0044] The method described in this article is applicable to various types of DBMS. DBMS manages databases. Database data can be stored in a collection of one or more records. The data in each record is organized into one or more attributes. In a relational DBMS, a collection is called a table (or data frame), a record can be called a row, and an attribute is called a column. In a document DBMS ("DOCS"), a collection of records is a collection or table of documents, and each of the records can be a data object marked with a hierarchical markup language, such as a JSON object or an XML document. Attributes are called JSON fields or XML elements. The term field used in this article refers to a JSON field.

[0045] These techniques are explained in the context of a relational DBMS that supports the execution of SQL statements to access and change the database of the DBMS. In a relational database, the columns of a table each store a scalar data type or a composite data type, such as an abstract data type. However, embodiments of the present invention are not necessarily limited to such a relational DBMS. In order to emphasize the applicability of the techniques described herein outside of a relational DBMS, the columns of a table are referred to herein as attributes, and the rows in a table are referred to herein as records. In the description of the SQL statements presented herein, the columns referenced in the SQL statements are referred to herein as attributes.

[0046] Root collection / table definition

[0047] JSON duality view can be used to return JDV objects of different complexity. JSON duality view has a single root table. Typically, JSON duality view maps the attributes of the root table to the scalar fields of the object view schema defined by the JSON duality view. JSON duality view typically maps attributes from multiple tables to the object view schema, as will be described in detail later. The tables or attributes mapped by the JSON duality view to the fields of the object view schema defined by the JSON duality view are referred to herein as the basic tables or basic attributes of the JDV objects returned from the JSON duality view, the object view schema, or from the JSON duality view. By mapping JSON fields to basic attributes and basic tables, the JSON duality view defines the object view schema.

[0048] Figure 1 A basic example of a JSON duality view based on only one table (which is the root table) is shown. Figure 1 , the DDL statement JDDL1 defines a JSON dual view employee_jdv1 based on the root table employee. The clause JSON MAPPINGVIEW specifies that the DDL statement JDDL1 is defining a JSON dual view with the subsequent name, which is employee_jdv1.

[0049] Like DDL statements commonly used to define views, DDL statement JDDL1 defines the following main query expression, which projects the attributes that are attributes of the view. In the case of a JSON duality view, the projected attributes are JDV objects that conform to the object view schema. The term view query expression in this article refers to the main query expression defined by the JSON duality view or the DDL statement that defines the JSON duality view.

[0050] The view query expression in JDDL1 projects the JSON object returned by the operator json_object(). The json_object() operator expression includes a field mapping that maps the field names of the object view schema to the following source SQL expression that evaluates to the value of the field. The SQL expression is typically the attribute name of the attribute in the source table listed in the corresponding FROM clause of the view query expression. JDDL1 maps the values ​​of the attributes empno, empname, job, and sal from the root table employee to JSON fields of the same name (i.e., empno, empname, job, and sal). By mapping the fields in this way, the view query expression defines the following object view schema that includes these fields at the root level of the object view schema. The root level will be described later.

[0051] JDV object 101 is the JDV object returned by employee_jdv1. An example of a query statement that can be executed to generate JDV object 101 is:

[0052] SELECT obj FROM employee_jdv1

[0053] JDV object 101 includes field-value pairs "empno":7369, "type":"ename":"SMITH", "job":"Accountant", and "sal":"1000", which are generated from the basic attributes empno, ename, job, and sal of the basic record of the root table employee, respectively. The records whose values ​​are used to generate field values ​​are referred to herein as basic records. As will be described in further detail, JDV object field values ​​can be generated from multiple basic records from multiple tables. The multiple basic records are referred to herein as basic record sets.

[0054] System Generated Fields

[0055] The fields JDVOID and VSTAG are fields automatically generated by the DBMS for any JDV object returned by the JSON duality view. Any object view mode of the JSON duality view is referred to herein as including these fields. The JDVOID field stores the JDV object identifier, which is a unique identifier generated by the DBMS for the JDV object, and is used to uniquely identify the JDV object among other JDV objects returned by the JSON duality view or even other JDV objects returned by other JSON duality views. If the corresponding JDV object identifiers in the JDVOID field match, the copies of the JDV object are referred to herein as being the same. However, these copies may be different versions with different content.

[0056] The DBMS generates a JDV object identifier based on the definition of the JSON duality view of the JDV object. JDDL1 includes an OBJECT ID clause that specifies one or more object ID attributes for the JDV object identifier. The one or more object ID attributes must include at least the primary key of the root table. JDDL1 includes the clause OBJECT ID(empno), thereby defining empno as the object ID attribute of the JDV object identifier generated for employee_jdv1.

[0057] The value of the object ID attribute does not become part of the JDV object identifier; instead, the object ID attribute value is an input for generating a JDV object identifier. The data type domain of the object ID attribute includes many data types. For example, the primary key can be an integer, a real number, or a string character. On the other hand, the JDV object identifier generated for any JDV object from any JSON duality view has the same data type. The JDV object identifier has a data type that enables the JDV object identifier to be effectively compared to determine equality. Equality is determined without the need for data type conversion, which may be required when the primary key is used directly as a JDV object identifier. If the corresponding JDV object identifiers of the JDV objects match, the JDV objects are logically versions of the same JDV object, although their contents may be different because the JDV objects have different field values. In addition, the object ID attribute value is encoded in the JDV object identifier in such a way that the original input object ID attribute value can be generated from the encoding. The encoding can also include such information as the data type and length of the object ID attribute.

[0058] Version Identifier

[0059] Field VSTAG is the version signature field that contains the version signature. The version signature is unique for each version of a particular JDV object. As will be explained in more detail, the version signature is generated using basic attribute values ​​as input to a hash-based algorithm (much like the algorithm used for digital signatures). As the basic attribute values ​​of the JDV object change, the JDV object changes and transitions from one version to another. Each version produces a different version signature because the basic attribute values ​​have changed.

[0060] The version identifier can be used to determine whether a previously retrieved JDV object has changed. If the version identifier of a previously retrieved JDV object returned by the JSON duality view does not match the version currently returned by the JSON duality view, then any underlying primitive property values ​​have changed.

[0061] According to an embodiment, the DBMS implements functions that can be used to generate JDV object identifiers and version signatures ("version signature functions"). These functions can be used in database statement rewriting that references JSON duality views.

[0062] refer to Figure 2A , database statement JQ21 is a SELECT statement that projects the JDV object to be returned from employee_jdv1. JQ21 is rewritten as database statement JQ21' to include a json_object() operator expression. The field mapping of this json_object() operator expression maps the JSON fields to the basic attributes of the root table employee.

[0063] Additionally, the field mapping maps the fields JVDOID and VSTAG to function calls for generating a JDV object identifier and version signature. JVDOID is mapped to OID_FROM_PK(empno). Oid_from_pk() is a JDV object ID function that takes as input one or more JDV object identifier attributes (one of which should be a primary key). In the case of JQ21', the primary key empno is the unique JDV object identifier attribute defined for employee_jdv1.

[0064] VSTAG is mapped to object_sig(record_sig(empno,ename,job,sal)). obj_sig() and record_sig() are version signature functions. record_sig() takes one or more input primitive attributes as input parameters. In JQ21', the input attributes include all primitive attributes mapped by the field mapping of the json_object() expression. The version signature functions will be described in more detail later.

[0065] Finally, a primary key may include multiple attributes. When a primary key includes multiple attributes, the value of the primary key referred to in this article refers collectively to the values ​​of the multiple attributes.

[0066] Query by specifying JDVOID

[0067] The JDV object ID can be used to identify JDV objects in database statements. Database statements can be rewritten to use the primary key of the root table to identify the root record in the corresponding root table. In order to facilitate the use of primary keys in this way, the DBMS implements object ID conversion functions, which are functions that convert the JDV object identifier encoding of the object ID attribute value into the object ID attribute value. The converted value can be referenced by a predicate expression. If the object ID attribute value is the primary key value on the object ID attribute, the converted value can be referenced by a predicate expression on the primary key to select the corresponding JDV object by selecting the record of the JDV object in the root table.

[0068] Figure 2A A rewrite of database statement JQ22 is shown that specifies returning a JDV object with a particular JDV object ID. Database statement JQ22 is similar to JQ21, except that JQ22 includes a predicate on the JVDOID field.

[0069] JQ22 is rewritten as JQ22'. It includes the object ID conversion function call EXTRACT_PK_COL("56ADEEBD") in an equality predicate that compares the return value of the function to the object ID attribute empno. The DBMS generates the predicate in this way in response to determining that empno is the primary key (the primary key is the object ID attribute defined by the JSON duality view employee_jdv1).

[0070] The JSON duality view may specify multiple object ID attributes. According to an embodiment, a JDV object ID is generated as a concatenation of the corresponding encodings of each value of the multiple object ID attributes. The object ID conversion function includes a parameter that specifies which object ID attribute value is to be returned.

[0071] For example, the employee table has a primary key that includes multiple attributes, namely, empno and emptyp. Therefore, the object ID clause of employee_jdv1 is OBJECT ID (empno, emptyp).

[0072] The predicates in the database statement rewritten from JQ22 will include a predicate with two equality predicate conditions, one for each object ID attribute of the primary key, as follows:

[0073] WHERE EXTRACT_PK_COL(“56ADEEBD”,1)=empno and

[0074] EXTRACT_PK_COL(“56ADEEBD”,2)=emptyp

[0075] The second argument to extract_pk_col() is a number that identifies the object ID attribute to return based on the attribute's positioning in the object ID clause of the corresponding JSON duality view.

[0076] The rewrite of JQ22 to JQ22' is an example of avoiding the evaluation of functions for predicate expressions that reference object view schema fields of a JSON duality view. Under function evaluation, JDV objects from a JSON duality view are each materialized into an in-memory representation that can be evaluated to determine whether a field satisfies a predicate expression, such as the predicate expression in JQA below.

[0077] JQA=SELECT obj FROM employee_jdv1

[0078] WHERE obj.job = "Manager"

[0079] Under function evaluation, each JDV object returned by the JSON binary view employee_jdv1 is materialized into a navigable in-memory representation that can be evaluated by the function to determine whether the field job is equal to "Manager".

[0080] To avoid function evaluation for evaluating the predicate expression, JQ* can be rewritten to replace the predicate expression on the field job with predicate expressions on the basic attributes of job, similar to that described for JQ22 and JQ22'. The DBMS's execution of the rewritten statement avoids function evaluation of the predicate expression on the field job of the JDV object in the JSON duality view employee_jdv1, thereby improving execution speed and reducing the computer resource consumption of the DBMS to evaluate JQ*.

[0081] For purposes of illustration, when a database command may be issued to a DBMS to request a JDV object from a JSON duality view and the JDV object is returned as a result of the database command or otherwise generated upon execution, the JDV object is referred to herein as being returned by the JSON duality view. JQ22 is an example of such a database statement. Even if the JDV object is a virtual object, if the JDV object can be returned by the JSON duality view, the JDV object is referred to as being from, in, or contained by the JSON duality view.

[0082] According to an embodiment, the JDV object returned by the JSON duality view has a JSON data type native to the DBMS. The JDV object stored in the memory may have an OSON (Oracle TM JSON) data type storage format. The OSON format encodes strings and other forms of values ​​according to the local dictionary stored in the JSON object, and includes encoding mappings and offsets that represent the hierarchical relationship between the fields of the JSON object. This format not only compresses the JSON document, but also enables efficient navigation of the JSON object to facilitate the evaluation of path expressions for the JSON object. Since OSON provides these two advantages, it is used for byte-addressable memory and block-based memory.

[0083] Cardinality relationship

[0084] As already mentioned, a JSON duality view may map fields to attributes of a base table other than the root table of the JSON duality view. The other table may be a base table of child fields of an object field or an array field. Constructing a JSON duality view definition for a multi-table JSON duality view depends on the cardinality relationships between parent fields and their corresponding child fields and between the root table and one or more base tables.

[0085] JSON objects have intra-object cardinality relationships. Cardinality relationships can exist between a JSON object and any of its subfields, between an object field and any of its subfields, or between an array field and any of its subfields. For a subfield of a JSON object, object field, or array field, the JSON object, object field, or array field may be referred to herein as the parent of the subfield. The parent of an object field or array field may be referred to herein as a parent field.

[0086] There are two types of intra-object cardinality relationships between a parent and its child fields. When the parent field is an array field, the parent has a 1:N (one-to-one or many) cardinality relationship with its child fields. There may be multiple instances of the child field, one for each element of the array field. When the parent field is an object field, the parent has a 1:1 (one-to-one) cardinality relationship with the object field's child fields.

[0087] In an embodiment, a multi-table JSON duality view is defined based on a view query expression that includes a subquery expression within an outer query expression. The outer query expression references a parent table, and the subquery expression references a child base table of the parent table. The parent table has a 1:1 or 1:N cardinality relationship with the child base table. The parent table and the child base table may be referred to as correlated in this article, and the child base table referenced in the subquery expression may be referred to as a correlated subquery table in this article.

[0088] The 1:1 or 1:N cardinality relationship between the parent table and the child table of the JSON duality view corresponds to the primary-foreign key relationship defined by the database dictionary of the DBMS. Such a primary-foreign key relationship is referred to as a registered primary-foreign key relationship in this article. A registered primary-foreign key relationship specifies a primary key in a table and a foreign key in another table.

[0089] A parent table has a 1:N cardinality relationship with a child table when a single record in the parent table corresponds to one or more records in the child table. A 1:N cardinality relationship applies to array fields; the child fields of an array field have base attributes that are attributes of the child table. A 1:N cardinality relationship is based on a registered primary-foreign key relationship where the parent table includes a primary key and the child table includes a corresponding foreign key. One record in the parent table with a particular primary key value corresponds to one or more records in the child table with an equal foreign key value.

[0090] With respect to parent and child tables, a cardinality relationship may be referred to herein as a PK:FK relationship. A PK:FK relationship corresponds to a registered primary-foreign key relationship, where the parent table includes a primary key and the child table includes a foreign key.

[0091] A parent table has a 1:1 cardinality relationship with a child table when a record in the parent table corresponds to only one record in the child table. A 1:1 cardinality relationship applies to object fields; child fields of an object field have base attributes that are attributes of the child table. A 1:1 cardinality relationship is based on a registered primary-foreign key relationship where the parent table has a foreign key and the child table has a corresponding primary key. One record in the parent table has a foreign key value that corresponds to only one record in the child table that has a primary key value.

[0092] With respect to parent and child tables, a cardinality relationship may also be referred to herein as an FK:PK relationship. An FK:PK relationship corresponds to a registered primary-foreign key relationship, where the parent table includes a foreign key and the child table includes a primary key. Typically, a child table may be a dimension table.

[0093] FK:PK situation-object field

[0094] Based on the FK:PK relationship that the root table has with the child table, a JSON duality view can be constructed for an object view schema that includes an object field, where the subfields of the object field are mapped to the base attributes of the child table. The child table is related to the root table through a subquery expression that includes the field mapping in the json_object() operator expression. Figure 3 depicts such a duality view of JSON.

[0095] refer to Figure 3 JDDL3 is the DDL statement used to define and create the JSON binary view employee_jdv3. Similar to JDDL1, the view query expression of JDDL3 maps the fields of the root table employee to the JSON fields empno and ename, etc.

[0096] In addition, the view query expression includes a subquery expression of the object field dept_info. Specifically, dept_info is mapped to the following subquery expression by the view query expression.

[0097] SELECT json_object('deptno'value deptno,'dname'value dname,'loc'valueloc)

[0098] FROM dept

[0099] WHERE dept.deptno = e.deptno.

[0100] The subtable dept is a correlated subquery table in the subquery expression. Based on the foreign key e.deptno of the employee table and the primary key dept.deptno of the dept table, the employee table has a FK:PK relationship with the subtable dept. The subquery expression defines a scalar subquery because it should return at most one record from the dept table. The subtable dept is a correlated subquery table in the subquery expression because (1) the dept table is in the FROM clause of the subquery expression, (2) the dept table attribute dept.deptno and the employee table attribute e.deptno are each operands in the subquery predicate expression dept.deptno = e.deptno, and the employee table is in the FROM clause of the outer query expression that contains the subquery expression.

[0101] The subquery expression projects the JSON object returned by json_object(). The field mapping of the operator maps the fields of the object field dept_info to the basic attributes of the child table dept. Specifically, the fields deptno, dname, and loc are mapped to the basic attributes with the same names in dept, namely, the attributes deptno, dname, and loc, respectively.

[0102] JDV object 301 has an example JDV object returned by employee_jdv3. In addition to the subfields of JDV object 101, JDV object 301 also includes a JSON object dept_info as another subfield of JDV object 301. JSON object dept_info includes subfields mapped by the field mapping of the json_object() operator in the subquery expression of employee_jdv3, which are deptno, dname, and loc.

[0103] The value of the subfield of the JDV object 301 is filled from the basic record of the root table employee having the value of the basic attribute deptno of 094. The attribute deptno is the foreign key of the table employee corresponding to the primary key deptno in the table dept. The registered primary-foreign key relationship is based on the primary key deptno of the table dept and the foreign key deptno of the table employee. In the JDV object 301, the field value of the subfield of the object field dept_info is filled from the following basic record in dept whose primary key deptno value 094 was equal to the value of the foreign key deptno in the table employee.

[0104] For reasons that will be explained, a JSON duality view definition must map fields to the primary key of any base table. However, it is not required to map the foreign keys of base tables to subfields as base attributes.

[0105] PK:FK Case - Array Field

[0106] Based on the PK:FK relationship that the root table has with the relevant child table in the subquery expression, a JSON duality view can be constructed for an object view schema that includes an array field with subfields mapped to the base attributes of the child table. Figure 4 A JSON duality view is depicted that returns a JDV object with information from a department and a list of employees in that department.

[0107] refer to Figure 4 , JDDL4 is a DDL statement used to define and create a JSON binary view deptvf. The view query expression of JDDL4 maps the fields deptno, type, dname, and loc to the attributes with the same names in dept (i.e., the attributes deptno, type, dname, and loc, respectively).

[0108] In addition, the view query expression includes a subquery expression for the array field dept_info. Specifically, dept_info is mapped to the subquery expression

[0109] SELECT json_arrayagg(json_object('empno'value empno,'ename'valueename,'job'value job)

[0110] FROM employee

[0111] WHERE d.deptno=e.deptno…

[0112] The employee table is a related subtable in the subquery expression. Based on the primary key deptno of the dept table and the foreign key e.deptno of the employee table, the dept table has a PK:FK relationship with the employee table.

[0113] The json_arrayagg() operator is an aggregate operator that, when included in a query expression, returns a JSON array with an element for each record that matches the predicate condition in the WHERE clause of the query expression. The elements have values ​​specified by the input parameter of the aggregate operator, which is a SQL expression. In the case of the above subquery expression, the SQL expression evaluates the JSON object returned by the json_object() operator. The field mapping of the json_object() operator expression maps the fields of the JSON object to the attributes of the related child table employee. Specifically, the fields empno, ename, and job are mapped to the base attributes in the table employee with the same attribute names (i.e., empno, ename, and job, respectively).

[0114] JDV object 401 is a JDV object returned by deptvf. The subfield values ​​of deptno, dname, and loc are obtained from a basic record in table dept with a primary key value of deptno=094. The values ​​of the elements of the subarray field emp_info are obtained from table employee, which has a foreign key deptno corresponding to the primary key deptno in the parent table dept. The array emp_info has three elements, each of which contains a value from one of the three records in table employee with a foreign key attribute value of deptno=094. Each element includes an object field, which has fields empno, ename, and job, and the values ​​of these fields are obtained from a corresponding one of the three records of the basic attributes with the same name.

[0115] Generic model for JSON duality view implementation

[0116] According to an embodiment, a JSON duality view is constructed based on PK:FK and FK:PK relationships of a table hierarchy reflecting an object hierarchy of an object view schema. The object hierarchy collectively represents hierarchical relationships between parent fields and corresponding child fields of the object view schema, including intra-object cardinality relationships. The table hierarchy also reflects a JSON duality view table implementation scheme of the corresponding object hierarchy. Figure 5 Object hierarchy and table hierarchy prototypes are depicted, which are object hierarchy 501 and table hierarchy 502 .

[0117] Object hierarchy 501 represents an object hierarchy that may appear in an object view mode. An object hierarchy is similar to a directed graph, with at least one node at each level. The top level of the hierarchy includes a single root node O5R at the root level, which corresponds to the root object of the object view mode. The root node O5R contains subfields of the root object. The nodes below the root level correspond to object fields or array fields. The subfields of the root node may be referred to as root subfields or root fields in this article. For illustrative purposes, object hierarchy 501 depicts a simple "single path" hierarchy with only one node at each level.

[0118] Node O5L1 is a node at the next level L1 and is a child node of the root node O5R. Node O5L1 may be referred to herein as a child node O5L1 with respect to the root node O5R, and the root node O5R may be referred to herein as the parent of the node O5L1. The child field of node OL51 is a child field of a corresponding array field or an object field in the parent root node O5R. If the corresponding field is an array field, the parent root node O5R and the array field have a 1:N cardinality relationship with the child node OR5L1. If the corresponding field is an object field, the parent root node O5R and the object field have a 1:1 cardinality relationship with the child node OR5L1.

[0119] Node O5L2 is a node at the next level L2 and is a child node of node O5L1. Node O5L2 may be referred to herein as a child node O5L2 about node O5L1, and node O5L1 may be referred to herein as a parent node of child node O5L2. The child field of node OR5L2 is a child field of a corresponding array or object field in parent node O5L1. If the corresponding field is an array field, parent node O5L1 and the array field have a 1:N relationship with child node O5L2. If the corresponding field is an object field, parent node O5L1 and the object field have a 1:1 relationship with child node OR52.

[0120] Table hierarchy 502 represents the parent-child table arrangement of the object hierarchy of the JSON duality view. For the JSON duality view defined by the view query expression, one or more child tables are each a related subquery table in the corresponding subquery expression. The table hierarchy includes a table for each node in the object hierarchy. A table at a certain level corresponds to a node at that level in the object hierarchy; the table includes basic properties of the scalar subfields of the corresponding node in the object hierarchy.

[0121] The table hierarchy includes a root table at the root level and corresponds to the root node and the root object of the object hierarchy. The table hierarchy 502 includes a root table T5R. The root table T5R corresponds to the root node O5R and is a base table of the scalar subfield of the root node O5R.

[0122] At the next level L1 is the base table T5L1. It includes the basic attributes of the corresponding node O5L1. In the JSON duality view defined by the view query expression, the base table T5L1 is referenced in the following subquery expression, which is nested in the main outer-query expression of the view query expression that references the root table T5R related to the base table T5L1. The base table T5L1 is a child table of the root table T5R, which can also be called the parent table of the child base table T5L1.

[0123] At the next level L2 is the base table T5L2. It includes the basic properties of the scalar subfields of the corresponding node O5L2. In the JSON duality view defined by the view query expression, the base table T5L2 is referenced in the following subquery expression, which is nested in the subquery expression that references the root table T5L1 related to the base table T5L2. The base table T5L2 is a child table of the base table T5L1, which can also be called the parent table of the child base table T5L2.

[0124] Based on the registered primary and foreign key relationships, the tables in the table hierarchy have a PK:FK or FK:PK relationship. If the intra-object cardinality relationship between the parent node and the child node corresponding to the parent table and the child table in the object hierarchy is 1:1, the parent table and the child table have an FK:PK relationship. If the intra-object cardinality relationship between the parent node and the child node corresponding to the parent table and the child table is 1:N, the parent table and the child table have a PK:FK relationship.

[0125] As previously mentioned, the object hierarchy 501 and the table hierarchy 502 are each depicted as simple "single-path" hierarchies with only one node at each level. However, at any level below the root level, the object hierarchy and the table hierarchy may have multiple child nodes and tables. For example, in an object hierarchy with an object view mode with a root array field and a root object field, the root node has two child nodes, one representing the array field and the other representing the object field. The table hierarchy includes a base table for each of the two child nodes; these base tables are child tables of the root table.

[0126] Example three-table JSON duality view

[0127] An example three-table JSON duality view is described below, which, for the purpose of illustration, implements an object hierarchy and a table hierarchy with a single path. As used herein, a path is a sequence of nodes in one or more parent-child relationships as described above, with one node at each level. A single-path object hierarchy and table hierarchy can be represented using a path notation as shown below.

[0128] Below is Figure 3 Path notation for employee_jdv3 shown in .

[0129] EMPLOYEE->{DEPT}

[0130] Path notation refers to tables in a table hierarchy, starting with the root table in parent-child order. Arrows connect parent and child tables in a PK:FK or FK:PK relationship. The arrow is called the cardinality vector and points to the table with the primary key in the relationship.

[0131] The brackets surrounding the table name are used to specify that the table is the base table for the scalar subfields contained in the array field. Thus, Figure 4 The JSON duality view deptvf described in can be expressed as follows:

[0132] DEPT<-[EMPLOYEE]

[0133] Three tables employee, project, and project_assignment are used to illustrate various JSON duality views that can be achieved by changing the root table. The example arrangement uses different root tables among the three tables. Table project_assignment includes foreign key attributes empno and projectno, whose corresponding primary keys of the same name are in the employee and project tables, respectively.

[0134] The first example is the view employee_view represented by the following notation. It returns a JDV object with information about an employee's assigned projects.

[0135] EMPLOYEE<-[PROJECT_ASSIGNMENT]->{PROJECT}

[0136] 6 depicts a JDV object 601, which is an example of a JDV object returned by employee_view. JDV object 601 includes scalar fields empno and ename and an array field assigned_projects as root subfields of JDV object 601. The elements of the array field each contain scalar subfields ass_eid and ass_projid and an object field proj_info as subfields. The object field proj_info includes scalar fields projid and projname as subfields.

[0137] If the JSON duality view employee_view is defined by the view query expression, the table employee is both the root table and the parent table related to the child table project_assignment. The related attributes are empno in the table employee and ass_eid in the table project_assignment. The base table of the scalar root child fields of the JDV object 601 is the table employee. The base table of the child scalar fields of the array field assigned_projects is the table project_assignment.

[0138] In the view query expression, the first outermost subquery expression includes a second subquery expression for the object field proj_info. With respect to the second subquery expression, project_assignment is the parent table and is related to the child table project in the second subquery expression. The related attributes are projno in table project_assignment and projno in table project. The base table of the child scalar fields of the object field proj_info is table project.

[0139] Figure 6B An object hierarchy 611 and table hierarchy 612 of employee_view with nodes in each of three levels are depicted. In the object hierarchy 611, the root node includes three child fields, scalar fields empno and ename and an array field assigned_projects. The array field assigned_projects is the parent of the child node at level L1. This node includes child fields of assigned_projects, namely, scalar fields ass_eid and ass_projid, and object field proj_info{}. The object field proj_info{} is the parent of the child node at level L2. This node includes child fields of proj_info{}, namely, projid and projname.

[0140] In the table hierarchy 612, the root table is the employee table, and the attributes empno and ename of the employee table are the basic attributes of the scalar subroot fields empno and ename. The child table of the root table at level 1 is the basic table project_assignment and includes the basic attributes ass_eid and ass_projid of the basic table project_assignment. The basic attributes ass_eid and ass_projid are the basic attributes of the subscalar fields ass_eid and ass_projid of the array field assigned_projects.

[0141] The basic table project_assignment is a child table of the root table employee. The relevant attributes are empno and ass_eid of the tables employee and project_assignment respectively.

[0142] The child node at level L2 includes the basic table project and the basic attributes projid and projname of the basic table project. The basic attributes projid and projname are the basic attributes of the child scalar fields projid and projname of the object field proj_info.

[0143] Related foreign keys do not have to be mapped to fields in the object view schema.

[0144] Example PROJECT_VIEW

[0145] The second example is a view project_view represented by the following notation. It returns a JDV object with information about projects and assigned employees.

[0146] PROJECT<-[EMPLOYEE_PROJECT_ASSIGNMENT->{EMPLOYEE}]

[0147] JDV object 602 is an example of a JDV object returned by the JSON duality view project_View. JDV object 602 includes sub-scalar fields projid and projname and an array field assignment_employees, each element of which contains sub-scalar fields ass_eid and ass_proj_id (of the array field) and a sub-object field employee_info. The object field employee_info includes scalar fields empno and ename.

[0148] In the JSON duality view project_view, table project is both the root table and the parent table related to the child table project_assignment. The root table of the scalar root subfields of the JDV object 602 is table project. The base table of the child scalar fields of the array field assignment_projects is table project_assignment.

[0149] Table project_assignment is the parent table and is related to the child table employee. The corresponding related attributes are ass_eid in table project_assignment and empno in table employee. The base table of the child scalar fields of the object field employee_info is table project.

[0150] Recordset Hierarchy

[0151] The basic record set of a JDV object includes a hierarchy of record subsets, which is referred to herein as the basic record set hierarchy. The basic record set hierarchy mirrors the table hierarchy of the corresponding JSON duality view of the JDV object. The root record subset is at the root level of the hierarchy and includes a record from the root table. Each subsequent level in the record set hierarchy includes a record subset for each basic table at the same level in the corresponding table hierarchy. The child basic table corresponding to the "child" record subset has a cardinality relationship with the "parent" record set of the parent basic table of the child basic table.

[0152] Figure 7 The basic record set hierarchy 702 generated for the JDV object 601 of the JSON duality view employee_view is depicted. Since the table hierarchy 612 is the table hierarchy of employee_view, the basic record set hierarchy 702 replicates the table hierarchy 612 and is also Figure 8 Depicted in.

[0153] refer to Figure 7 , the basic record set hierarchy 702 includes a root record subset R70, a record subset L71, and a record subset L72. The root record subset R70 is at the root level and corresponds to the root table employee in the table hierarchy 612. The record subset L71 is at the first level L1 of the basic record set hierarchy 702 and corresponds to the basic table proj_assignment. The record subset L72 is at the second level L2 and corresponds to the basic table proj. Replicating the parent-child relationship of its corresponding basic table, the record subset L71 is a child of the root record subset R70 and the record subset L72 is a child of the record subset L71.

[0154] Root record subset R70 includes one record from the root table employee. Record subset L71 includes three records from the base table proj_assignment. Root record subset R70 and record subset L71 have a PK:FK ("1:N") relationship. Therefore, for one root record in record subset R70, record subset L71 includes three records from the base table proj_assignment. Record subset L71 and record subset L72 have a FK:PK ("1:1") relationship. Therefore, record subset L72 includes three records from the base table project, one record for each record in record subset L71.

[0155] Multi-table version signature

[0156] As mentioned above, the JDV object is returned by executing a database statement that references the corresponding JSON duality view. During compilation, the database statement is rewritten based on the JSON duality view to access the data of the JDV object from the basic attributes of the basic record set of the JDV object.

[0157] According to an embodiment, a version signature is generated by rewriting a database statement to recursively call a version signature function within the database statement. The version signature function is recursively called by implementing a basic version signature call, which calls the version signature function as an input parameter, which in turn can call the version signature function as an input parameter. The version signature function returns a signature of a specific type generated using a hash algorithm for a specific type of input. The input parameters of the version signature function include (1) a call to another basic signature that returns a signature, (2) basic attributes of a basic table, (3) and object or array field names.

[0158] Figure 8 The version signature function in an embodiment of the present invention is described. In particular, Figure 8 Depicts the version signature functions record_sig(), aggr_sig(), and obj_sig().

[0159] record_sig() returns the record signature of a record. record_sig() generates a record signature based on the following input, which includes one or more basic attribute values ​​of the record or one or more attribute input parameters.

[0160] object_sig() returns the object signature. There are several ways to call object_sig(). First, the call to object_sig() can have as input parameters one or more record signatures returned by record_sig() and / or an object signature returned by object_sig(). Second, object_sig() can include as input parameters arguments of object or array field names and the object signature returned by object_sig().

[0161] aggr_sig() returns the array signature. aggr_sig() is used to generate the signature of an array field. The input to aggr_sig() is a set of signatures including the object signature returned by object_sig() and / or the record signature returned by record_sig(). The set of signatures each corresponds to an element of an array field.

[0162] The version signature of a JDV object is the object signature returned by a single primitive call to object_sig(), except as described later. Typically, database statements are rewritten so that the arguments to the single primitive call to object_sig() are other calls to the version signature function, which can make additional calls to the version signature function in a similar manner.

[0163] The calls are constructed so that the calls form a call hierarchy that reflects the object hierarchy of the JSON duality view. The call hierarchy originates from a basic object_sig() call. Below the level of the basic signature function call, the call hierarchy includes one or more levels, each of which includes a set of version signature function calls corresponding to nodes at a corresponding level in the object hierarchy; the one or more calls are input parameters to the version signature call in the previous level within the call hierarchy. For each node at a particular level in the object hierarchy, at the corresponding level of the call hierarchy, there may be (1) a row_sig() call based on the basic properties of the scalar subfields of the node, (2) an object_sig() call for each object_field() of the node, and (3) an array_sig() call for each array field of the node.

[0164] The goal of version signature generation is to generate version signatures in a deterministic manner. In order to be deterministic, the version signatures of instances of the same JDV object should match if the values ​​of the basic attributes of the corresponding basic record sets of the instance remain the same. In addition, the basic records belonging to each record subset should remain the same. If any value of the basic attribute between the corresponding basic record sets is different, the version signatures should be different. In an embodiment, if the corresponding record subsets of the instance contain different basic records, the version signatures are different.

[0165] Illustrative rewrite of version signature function

[0166] In order to illustrate how to use the version signature function to generate a version signature through database statement rewriting, the following database statement JQB rewriting is described. For the definition of employee_jdv3, refer to Figure 3 This statement requests a version signature for the JDV object returned by employee_jdv3.

[0167] JQB=SELECT VSTAG FROM employee_jdv3

[0168] Fig. 9 Describes JQ9, a rewritten version of JQB that uses versioned signature function construction. Fig. 9 Also depicted are an object hierarchy 901 (ie, the table hierarchy of employee_jdv3) and a call hierarchy 902 (which represents the call hierarchy represented from JQ9).

[0169] refer to Fig. 9 , the call hierarchy 902 includes a basic object_sig() call at the base level of the call hierarchy 902. At the next level of the call hierarchy 902 corresponding to the root level of the table hierarchy 901 are version signature function calls that are input parameters to the basic object_sig() call. These version signature functions include a record_sig() call that includes the basic attributes of the root table employee of the root scalar subfield as input parameters. Also included is an obj_sig() call for the object root field dept_info, for which the subtable dept is the base table.

[0170] At the next level of the call hierarchy 901 (which corresponds to level L1 of the object hierarchy 901) is a call to record_sig(), which serves as an input parameter to the base object_sig() call. The input parameters to record_sig() are the basic attributes of the subtable dept, which are the basic attributes of the scalar subfields of the object field dept_info.

[0171] In JQ9, the SELECT clause of the main outer query expression includes the base object_sig() call and the input version signature function calls corresponding to the root level of the object hierarchy 901, namely, calls to record_sig() and obj_sig(). JQ9's subquery expression is the input parameter of the obj_sig() call in the main outer query expression. The subquery expression projects the recordsig() call corresponding to the lowest level of the table hierarchy.

[0172] Declarative Overrides of Array Fields

[0173] To illustrate how to generate a version signature by rewriting a database statement for a JDV object having an array field, the following rewriting of the database statement JQC is described. The database statement requests the version signature of the JDV object 401 by specifying the JDV object identifier of the JDV object 401 in the predicate. For the definition of deptvf., refer to Figure 4 .

[0174] JQC=SELECT VSTAG from DEPTVF

[0175] WHERE JVDOID = "59XF45"

[0176] Fig.10 JQ10 is illustrated, a rewritten version of JQC constructed using a version signature function. Also depicted is an object hierarchy 1001 and a call hierarchy 1002 of the JSON duality view deptvf, which represents a call hierarchy to the base signature represented by JQ10.

[0177] refer to Fig.10 , call hierarchy 1002 includes a basic object_sig() call at the top level of the call hierarchy. The next level of call hierarchy 1002 corresponds to the root level of object hierarchy 1001. This level includes a record_sig() call, which has input parameters as the basic attributes of the root table dept. This level also includes an obj_sig() call, where array_sig() is used as an input parameter. The obj_sig() call is a wrapper for array_sig() to include the field name of the corresponding array field emp_info. The field name is used to calculate the object signature, as will be explained later.

[0178] array_sig() generates a signature array from the elementary records from employee, which correspond to the elements in the array field employee_info respectively. The input parameters of the array_sig() call are the record_sig() call at the next level L1. The input parameters of record_sig() are the elementary attributes of the table employee, i.e. the elementary attributes of the subfields of the array field emp_info.

[0179] In JQ10, the SELECT clause of the main outer query expression includes a version signature function corresponding to the root level of object hierarchy 1001. The subquery expression of JQ10 is the input parameter to the obj_sig() call in the main outer query expression. The subquery expression projects the array_sig() call, which also corresponds to the root level of object hierarchy 1001. The record_sig() call in the subquery expression corresponds to level L1 of object hierarchy 1001.

[0180] array_sig() behaves as an aggregate function, similar to how the json_arrayagg() operator behaves. When included in a query expression, array_sig() returns the record signature generated for the corresponding table records that match the predicate condition of the query expression. The record signature is generated by calling record_sig() for each record in the table using the input parameters described previously.

[0181] The database statement JQC is an example of a database statement that can be used to generate a version signature for a JDV object by identifying a JDV object identifier in a predicate expression. In an embodiment, when a version signature is referred to as being generated by the DBMS for a JDV object, the DBMS executes a database statement such as JQC that requests a version signature for the JDV object (e.g., a VSTAG field) and identifies the JDV object using a predicate expression on the JDV object identifier (e.g., an equality comparison between the JVOID field and the JDV object identifier). The database statement can be a previously compiled database statement that involves rewriting the database statement using a version signature function, such as shown in JQ10.

[0182] Sort the inputs to the version signature function

[0183] According to an embodiment, record_sig() and object_sig() generate signatures by applying input parameter values ​​in order. If applied in different orders, the input parameter values ​​generate different signatures for the same set of input parameter values. In order to deterministically generate version signatures for multiple copies of a JDV object, the call hierarchy for each copy should apply the input parameters of record_sig() and object_sig() in the same order. Therefore, the input parameters are applied according to an ordering scheme.

[0184] For record_sig(), the ordering scheme generates the record signature by applying the attribute values ​​of the attribute arguments in the order of the attribute names. For object_sig(), if the input argument is a call to record_sig(), the record signature returned by that call is applied first, followed by the object signature returned by the input argument to obj_sig() or array_sig(). object_sig() can only take one record_sig() call as an input argument.

[0185] If an object_sig() call includes multiple input calls to object_sig(), each object_sig() input call should itself include an input parameter that specifies the field name of the object field or array field to which the object_sig() call corresponds. For example, the following object_sig() call is used to represent a JSON binary view of a person and their shipping and billing addresses, which are represented by object fields.

[0186] obj_sig(record_sig(fname,lname),

[0187] obj_sig(“del_addr”,record_sig(…),

[0188] obj_sig(“bill_addr”,record_sig(…))

[0189] The calling obj_sig() call first applies the record signature of record_sig(), then the object signature returned for the object field bill_addrr, then the object signature returned for del_addr.

[0190] If an object_sig() call includes more than one object_sig() and array_sig() input calls, any array_sig() input calls should be wrapped in an obj_sig() call that specifies the field names of the corresponding array fields. For example, the following object sig() call is used to represent a JSON binary view of a person, their current address, and previous addresses. The current address is represented by an object field, and each of the previous addresses is represented by an array of address fields.

[0191] obj_sig(record_sig(fname,lname),

[0192] obj_sig(“cur_address”,record_sig(…),

[0193] obj_sig(“prev_addresses”,array_sig(record_sig(…)))

[0194] The array_sig() call applies a set of record signatures generated for base records from the corresponding base table. For multiple copies of the same JDV object returned by the JSON duality view, the same set of record signatures may be generated, but in different orders. If the same set of signatures is generated, but in different orders, the underlying base attributes of the base record from which the record signatures were generated may not have changed. To reflect this fact, arr_sig() is configured to generate array signatures "interchangeably", that is, to generate array signatures for a set of signatures so that the order of the signature set is independent of the resulting version signature.

[0195] Finally, not all base properties are used as input to the record signature function. The JSON duality view can define base properties to be excluded from version signature generation. For a JSON duality view, the set of base properties used as input to the version signature function can be referred to as the version signature pattern with respect to the JSON duality view. The base properties to be excluded can be defined by annotating the view query expression to indicate that these base properties are to be excluded from the version signature pattern, similar to how change permissions can be declared for base properties, as described later.

[0196] Declarative rewrite of the entire JDV object with VSTAG

[0197] Generating a version signature by rewriting a database statement using a version signature function has been illustrated by rewriting a database statement that only requests the VSTAG field.As mentioned previously, the JDV object returned from the JSON duality view automatically includes a VSTAG field containing the version signature. Fig.11 Depicts a database statement that is rewritten to return an entire JDV object with a VSTAG field in a multi-table JDV object.

[0198] refer to Fig.11 , the database statement JQ11 to JSON duality view deptvf (see Figure 4 ) requests a JDV object. Based on the definition of deptvf, the DBMS rewrites the database statement JQ11 into the database statement JQ11'.

[0199] Segment 1102 is the portion of JQ11' that is constructed to generate a version signature for the JDV object returned by the JSON duality view deptvf. Segment 1102 maps the field VSTAG to a basic object_sig() call. Because the field name is not required, the call to array_sig() is not wrapped in a call to object_sig().

[0200] The base obj_sig() call is wrapped inside a call to snapshot_sig. snapshot_sig() appends the snapshot time to the version signature. snapshot_sig() is optional. The snapshot time enables the version signature to be regenerated using the snapshot query associated with the snapshot time. The snapshot query is calculated to reflect the state of the database at the snapshot time associated with the query.

[0201] Pessimistic locking

[0202] According to an embodiment, pessimistic concurrency control is used to provide transactional consistency for updating JDV objects. Under pessimistic concurrency control, before a database transaction modifies any part of a JDV object, the database transaction issues record locks on all base records in a base record set to prevent modification of any base record in the set that may need to be changed. Issuing locks in this manner before attempting to modify any base record of a JDV object is referred to herein as pessimistic locking of a JDV object.

[0203] A database transaction with a lock on a record prevents other database transactions from acquiring a lock on the record, thereby preventing any of the other database transactions from also modifying the record until the database transaction releases the lock. When the database transaction terminates by committing or aborting, the database transaction releases the record lock.

[0204] Pessimistic concurrency control is used to execute a database transaction in response to receiving a select-for-update database statement. The following database statement JQD is a select-for-update statement issued by the database transaction to DBMS 100 to pessimistically lock a JDV object 601 whose base record set is a base record set hierarchy 702 .

[0205] JQD=SELECT obj FROM employee_view WHERE obj.empno=34FOR UPDATE

[0206] Holding record locks on a base record set is not sufficient in itself to prevent other database transactions from changing a JDV object while those locks are held. Without otherwise preventing measures, a database transaction may be able to insert a record into a child base table of a JDV object, where the inserted record will belong to a child record set corresponding to the child base table, and where the associated foreign key value of the child base table is equal to the foreign key value of the child record set. For example, while a database transaction has all base records in record subset L71 locked, another database transaction may add another record to proj_assignment, where the associated foreign key ass_eid=34, thereby adding another base record to record subset L71 and modifying the contents of JDV object 601.

[0207] To prevent a record with a related foreign key value from being inserted into a child base table of a JDV object (which may change the contents of the JDV object) while the database transaction causes the current base record to be pessimistically locked, the database transaction issues a foreign key value lock on the child base table to the DBMS. A foreign key value lock is issued on any related foreign key of the child table that is related to the parent table's primary key.

[0208] An example of a mechanism for locking foreign key values ​​is a foreign key index lock. A foreign key index is an index on the foreign key of a registered primary-foreign key relationship. A foreign key value locks the index entry for that foreign key value, preventing the insertion or deletion of records with that foreign key value or updates of foreign keys in records to or from that foreign key value.

[0209] Consistent read and current read

[0210] There are various capabilities that are important for optimistic serialization of updates. These are (1) consistent read mode and (2) current read mode, (3) object disassembly, and (4) delta record set generation. Consistent read and current read are modes for executing database commands and database operations that are related to transaction consistency.

[0211] Object disassembly is actually reverse engineering JDV objects into logical basic record sets. In other words, object disassembly extracts and derives basic record sets from JDV objects. Basic record sets are referred to as derived record sets in this article. Incremental record set generation compares the derived record set with the basic record set generated for the JDV object from the database to determine the difference between the two. The difference is represented by the incremental record set. Since these capabilities are important for optimistic serialization updates, a description of these capabilities is provided in this article before describing optimistic serialization updates.

[0212] In consistent read mode, reads of database data during the execution of one or more database statements of a database transaction return data consistent with the SCN (system change number) associated with the database transaction. SCN is referred to as snapshot time in this article. Transaction consistency requires that reads reflect only transactions committed before SCN and any uncommitted database changes made by database transactions.

[0213] In transaction processing in a DBMS, the changes made by a database transaction to a record require changes to the data block storing the data for that record. These changes are recorded in a change record, which may include redo records and undo records. Redo records can be used to reapply the changes made by a database transaction to a data block. Undo records are used to reverse or undo the changes made by a transaction to a data block.

[0214] Undo records are used to provide transaction consistency by performing operations referred to herein as "consistent read operations". Each undo record is associated with an SCN. For a data block read for a database statement, the DBMS applies the required undo records to a copy of the data block so that the copy is in a state consistent with the snapshot time of the database statement. The DBMS determines which undo records are applied to the data block based on the corresponding SCN associated with the undo record. The term consistent read operation refers to an operation performed on database data to ensure that the data is consistent with the snapshot time. Such an operation includes applying undo records to data blocks, as previously described. Another example of a consistent read operation is to check the transaction metadata in the data block to determine whether the data in the data block is transactionally consistent with the SCN time. Applying undo records to data blocks can be performed in response to determining that the data block is inconsistent with the snapshot time in transactions.

[0215] In the current read mode, the read operation reflects the uncommitted confirmed changes to the data block. A consistent read operation is not performed. For example, a data block contains an uncommitted confirmed record in a table with a specific foreign key value. The uncommitted confirmed record is inserted by a database transaction that has not yet been committed and confirmed. Before the database transaction is committed and confirmed, another database transaction operating in the current mode reads the data block containing the uncommitted confirmed record. The database transaction is executing a query that filters records based on foreign key values. When the database transaction reads the data block, the consistent read operation is abandoned, and therefore, the database transaction reads the uncommitted confirmed record. If the foreign key is indexed by a foreign key value index, the database transaction can also read the data block storing the index entry of the record in the foreign key value index.

[0216] Object disassembly

[0217] Object disassembly extracts derived record sets from JDV objects based on the mapping of basic attributes and tables of the corresponding JSON duality view. In fact, the derived record sets are generated according to the corresponding object hierarchy and table hierarchy of the JSON duality view.

[0218] Like a base record set, a derived record set consists of a hierarchy of record subsets with parent-child relationships, as described previously for the base record set hierarchy. For each level in the table hierarchy and for each base table at that level, at least one derived record is generated that has base attributes of the base table for the object view schema fields that correspond to the base table; the base attributes have corresponding scalar values ​​for the corresponding fields.

[0219] A derived record includes the basic attributes required by the JSON binary view. Therefore, a derived record may not include all attributes of the corresponding base table. Therefore, a derived record is referred to as skeletal in this article.

[0220] If the base table corresponds to an array field, the derived record subset includes a derived record for each element in the array field, the derived record having a base attribute corresponding to a corresponding scalar subfield of the array field. For each element, the corresponding derived record includes a scalar field value for the corresponding base attribute.

[0221] If at a certain level, the base table is a child table of a parent that is a base table of an array field, then the base table corresponds to the sub-object fields of the array field. The derived record subset of the child table includes a derived record for each element with the base attributes from the child table that correspond to the corresponding scalar subfields of the array field.

[0222] Incremental Recordset Generation

[0223] Incremental record set generation generates an incremental record set including one or more delta tuples by comparing the derived record set of the JDV object with the base record set generated for the JDV object from the database. The derived records in the derived record set can be versions of the same record in the base record set; the records in the derived record set and the base records in the base record set are referred to herein as counterparts or collectively referred to as counterpart sets. The incremental tuples and base records belonging to the counterpart set contain the same primary key value.

[0224] As mentioned previously, the JSON duality view must map the JSON fields to any primary key of any base table of the JSON duality view. Therefore, a derived record has the same primary key value as its counterpart base record. The counterpart record is identified by finding the derived record and the base record with the same primary key value. Logically, the counterpart record is the same record, but may be a different version of that record.

[0225] A delta tuple represents (1) a set of changes or deltas between records in the counterpart set, or (2) base records deleted from or inserted into the base record set. A delta tuple includes base attributes and values ​​and is tagged to specify the changes, if any, represented by the delta tuple.

[0226] For each counterpart set, a delta tuple is generated and populated with the same base attribute values ​​as the corresponding derived record. The base attribute values ​​in the delta tuple are then compared with the base attribute values ​​in the corresponding base record of the counterpart set. If the base attribute values ​​in the delta tuple do not match the corresponding base attribute values ​​in the corresponding base record, the base attribute in the delta tuple is marked as changed, and the delta tuple is also marked as changed. If there is no difference between the corresponding base attributes, the delta tuple is marked as unchanged.

[0227] If the derived record has no counterpart, a delta tuple is generated that represents the insertion of the base record into the corresponding base table of the derived record. The delta tuple is marked as "add" and filled with the same base attribute values ​​as those of the derived record.

[0228] If the base record has no counterpart, a delta tuple is generated that represents the deletion of the base record from its base table. The delta tuple is marked as "deleted" and filled with the same attribute values ​​as those of the base record.

[0229] A derived record set may contain duplicate derived records for the same base record. In this case, the correspondence set includes multiple derived records and the base record. For each set of duplicates, only one delta tuple is generated that incorporates the changes represented by the duplicates. For example, if a derived record indicates a change to one attribute and another derived record indicates a change to another attribute, a single delta tuple is generated that specifies the changes to both attributes. If derived records in a correspondence set indicate conflicting changes (e.g., different changes to the same base attribute), an error is generated.

[0230] Optimistic Serializable Updates

[0231] Fig.12 is a flowchart depicting a process for optimistic serialization updates using JDV objects. An optimistic serialization update may be performed in response to an UPDATE statement that uses a JDV object ID to identify a JDV object to be updated and identifies a modified version of the JDV object to which the JDV object is to be set, as follows:

[0232] UPDATE deptvf SET object=myJDVO

[0233] WHERE object.JVDOID=myJDVO.JVDOID

[0234] Compiling and executing an UPDATE statement requires more than Fig.12 More execution steps are described in . Fig.12 Describes the steps associated with implementing optimistic serialization updates. Update statements are executed by a database transaction with a snapshot SCN (referred to herein as the current snapshot SCN). Except as described below, database transactions are executed in consistent read mode.

[0235] refer to Fig.12 , generating the current version of the JDV object. The basic record set generated for the JDV object is stored as the current basic record set (1205).

[0236] Next, the updated JDV object is compared with the corresponding VSTAG of the current version (1210). If the VSTAG matches, the DBMS determines that the modified JDV object does not represent an update to the current version of the JDV object. The process terminates. This step is referred to as the pre-update version check in this article.

[0237] If it is determined that the VSTAG matches, object disassembly is performed to generate a derived record set (1215). Next, a delta record set is generated based on the derived record set and the current base record (1220).

[0238] Next, an "incremental change operation" is performed. An incremental change operation only changes the base record corresponding to the incremental tuple that represents a modification, deletion, or addition of a base record to the base table of the JSON duality view. In an embodiment, this step requires determining for each incremental tuple whether the incremental tuple represents a change to the base record, and if so, generating a change operation for the change. The change operation can be generated by issuing a DML command that effects the change. The base record is identified using the primary key value in the incremental tuple, and an UPDATE command is issued for the incremental tuple that represents the change to the base record; the UPDATE command only updates the attributes marked as changed in the incremental tuple. An INSERT command is issued for the incremental tuple marked as added; the statement specifies the attribute value specified in the incremental tuple.

[0239] Incremental change operations are sequenced and checked to ensure that primary and foreign key relationships and constraints imposed by the JSON duality view definitions are not violated, as will be described in further detail later.

[0240] Issuing UPDATE and DELETE statements against a base record lock causes the DBMS to issue a lock on that record. There may typically be many base records in the current base record set for which no DML commands are generated at this step. The effect of not locking all base records is that fewer records are locked. Fewer record locks reduce lock contention and rework of database transactions, thereby improving system performance of the DBMS. The system performance gain from reduced lock contention is even greater when compared to pessimistic locking. Not only are fewer records locked, but the locks that are issued are also held for a much shorter period of time.

[0241] Next, a foreign key value lock is issued for any PK:FK relationships in the table hierarchy of the JSON duality view (1225).

[0242] Next, "post change validation" is performed. Post change validation ensures that the changes made to the base records by the incremental change operation can be executed in a transaction serial manner when the change operation is committed. Essentially, this guarantee is provided by determining whether there are uncommitted changes to any base records of the JDV object by another database transaction when post change validation is performed.

[0243] In consistent read mode, a version signature is generated for the JDV object (1235). In current read mode, a version signature is generated (1240). Next, the version signature pair is compared (1245).

[0244] If the paired version signatures match, no other database transaction is changing the base record of the JDV object or inserting or deleting base records that change the content of the JDV object. In this case, the only base record changes that affect the content of the JDV object are the uncommitted base record changes made by the current database transaction. Therefore, changes to the JDV object have been serialized.

[0245] In response to determining that the version signature pair matches, the database transaction is committed and confirmed (1250). Otherwise, the database transaction is terminated.

[0246] Updates to JDV objects that fail the pre-update version check will also not pass the post-change validation. In this respect, the pre-update version check is redundant. However, the pre-update version check actually disqualifies the update without having to trigger additional processing that occurs after the pre-update version check (such as performing incremental change operations and accompanying record locking), thereby improving system performance.

[0247] Optimistic serialization updates can be performed on multiple JDV objects at the database statement level or the database transaction level. At the database statement level, an incremental record set is generated and incremental change operations are performed on each JDV object. Then, post-change verification is performed on each of the JDV objects. If for each JDV object, the version signature generated in the consistent read mode matches the current read mode, the database statement is committed.

[0248] At the database transaction level, multiple database statements can be executed and multiple JDV objects can be changed by generating corresponding incremental record sets and performing corresponding incremental change operations. In response to receiving a request to commit a database transaction, post-change verification is performed on each of the JDV objects. If for each JDV object, the version signature generated in the consistent read mode matches the current read mode, the database statement is committed.

[0249] Post-change checking can be applied to optimistic updates of various record sets found in various DBMSs. Various record sets include, for example, record sets including one or more rows, one or more XML documents, or one or more JSON objects. Any implementation of post-change checking requires the ability to generate record sets in a consistent read mode, a current read mode, and techniques for deterministically detecting differences between two record sets, including through the use of deterministically generated version signatures based on version signature schemas.

[0250] Change operation validation and change operation sequencing

[0251] Change operation validation refers to checking whether the change operation used to update the JDV object violates the constraints imposed by the corresponding JSON duality view. Such constraints include predicate constraints and change permission constraints. Change operation validation can be performed after the incremental record set is generated and before the post-change validation.

[0252] Predicate constraints can be defined by predicate expressions that are not related predicate expressions in the view query expression. Such predicate expressions are referred to in this article as filter predicate expressions. Mutation operations will be checked against the predicate constraints and may result in predicate constraint errors if the mutation operation violates the predicate constraints. For example, the JSON duality view deptvf (see Figure 4 ) includes the following filter predicate expressions in the subquery:

[0253] e.job<>"Manager"

[0254] For JDV objects 401 (see Figure 4 ) that changes the field job from "SMITH" to "MANAGER" generates a delta tuple with the updated value of the specified attribute job being "MANAGER". During validation of the change operation, the DBMS determines that the attribute value in the delta tuple does not satisfy the filter predicate expression e.job <> "Manager", thereby detecting a predicate constraint violation and preventing the update.

[0255] Another type of constraint is a change permission constraint defined by a JSON duality view. As will be explained later in this document, a JSON duality view can declare change permissions for a base attribute or base table. For example, a change permission declared by deptvf can prohibit updating the base attribute job. The modification to JDV object 401 that changes the field job from "SMITH" to "SENIOR ACCOUNTANT" generates an incremental tuple that specifies the updated value of the base attribute job as "SENIOR ACCOUNTANT" and marks the base attribute as changed. During the validation of the change operation, the DBMS determines that the base attribute for which the change permission defined by deptvf is NOT UPDATABLE has been changed, thereby detecting a change permission violation and preventing the update.

[0256] Another type of constraint is a mapped field constraint. If the updated JDV object includes a field that is not mapped by the corresponding JSON duality view, a mapped field constraint violation is generated.

[0257] The change operations are ordered to satisfy FK-PK dependencies. Specifically, the record with the foreign key value has an FK-PK dependency on the record with the primary key value. If the record with the primary key value has been inserted into the database, the dependency is satisfied; otherwise, the dependency is not satisfied. If an incremental change operation inserts a specific base record and another incremental change operation inserts another base record that has an FK-PK dependency on the specific base record, the change operation for the specific base record is executed before executing the incremental change operation for the other base record.

[0258] Changes to the License Statement

[0259] JSON duality views can define change permissions by declaring the change permissions in the view query expression of the JSON duality view. Change permissions can be declared by annotating the view query expression with a change permission declaration. For illustration, Fig.13A and Fig. 13B Depicts the JDDL3 and JDDL4 versions of DDL statements using change declaration annotations. Fig.13A and Fig. 13B In the example, DDL statements JDDL3' and JDDL4' define the JSON binary views employee_jdv3 and deptvf respectively.

[0260] refer to Fig.13A , JDDL3' includes various change permission annotations, as follows:

[0261] 1. In the clause FROM dept WITH (UPDATE), the WITH (UPDATE) annotation declares that the basic attributes of the employee table are updateable.

[0262] 2. In the clause FROM dept WITH (UPDATE), the WITH (UPDATE) annotation declares that the basic attributes of the table dept are updateable.

[0263] 3. In the clause 'sal' value sal WITH(NOUPDATE), the WITH(NOUPDATE) annotation declares that the base attribute sal of the table employee is not updatable. Therefore, the usual change permission declarations that can be made for base attributes at the base table level can be overridden for specific base attributes at the attribute level annotation.

[0264] refer to Fig. 13B ',JDDL4' includes the following changed license notice:

[0265] In the clause FROM employee e WITH (DELETE, INSERT, UPDATE), the WITH comment declares that the basic attributes of the employee table are updateable, and the basic records of the employee table can be deleted or inserted. By default, the basic records of the child table have no change permission.

[0266] Unnesting and nesting

[0267] The FK:PK relationship between the parent table and the child table has been described as being used to define object fields, corresponding child fields, and basic attributes. According to an embodiment, basic attributes in the child table can be used for fields that are not contained in the object fields and are actually "unnested" to the previous level in the object hierarchy. Specifically, the basic attributes in the child table are mapped to the fields at the object hierarchy level corresponding to the parent table of the child table. Such unnesting is effected by using the UNNESTING clause in the view query expression of the JSON duality view. Basic attributes mapped in this manner are referred to as unnested basic attributes in this article; fields mapped to unnested basic attributes are referred to as unnested object field attributes in this article.

[0268] Fig.14 Depicted is a JSON duality view employee_jdv14 for which unnested base attributes are defined. employee_jdv14 is similar to employee_jdv3, except that JDDL14 includes an UNNEST clause that qualifies the correlated subquery expression, which has the effect of declaring the projected attributes of the subquery as unnested base attributes of the fields at the object hierarchy level of the parent table employee.

[0269] JDO1401 is the JDV object returned by employee_jdv14. All fields in JDO1401 are at the same level of the object hierarchy, including the fields deptno, dname, and loc.

[0270] Base attributes of a base table may also be "nested". That is, a base attribute is mapped to a subfield of an object field, which is at a lower level in the object hierarchy than the base table. Such unnesting is effected by using a json_object() operator expression that maps a base attribute to a subfield of an object field. A base attribute mapped in this manner is referred to herein as a nested base attribute; a field mapped to a nested base attribute is referred to herein as a nested base attribute.

[0271] Simplified DDL syntax

[0272] The view query expressions of the JSON duality view may be very complex and very tedious to write and interpret manually. According to an embodiment, the DDL statement for defining the JSON duality view can be generated using a simplified syntax that references tables in a manner that indicates root tables and base tables and basic annotations about object or array fields corresponding to the base tables. Based on the definitions of the referenced tables defined in the database dictionary and the registered PK:FK relationships, the DBMS generates metadata defining the JSON duality view in the database dictionary. By default, the attributes in the referenced table are mapped to fields according to the object hierarchy implied by the DDL statement. The DDL statement does not need to explicitly reference attributes.

[0273] An example of the use of the simplified syntax is the DDL statement JDDL1' (see Figure 1 ). The JSONIZE clause declares the JSON binary view employee_jdv1 using the employee table. In response to the DBMS receiving JDDL2', the DBMS creates the JSON binary view employee_jdv1, mapping the basic attributes of the employee table to the fields of the object view schema, as shown in JDDL2.

[0274] DDL3' is an example DDL statement that defines a multi-table JSON duality view (i.e., JSON duality view employee_jdv3) with object fields using simplified syntax. The expression in the JSONIZE clause is referred to herein as a simplified table-object mapping and is shown below:

[0275] employee('dept_info':{DEPT})

[0276] This mapping specifies the employee table as the root table and the dept table as a descendant of the root employee table and a base table for object fields, as well as specifying the object field name, i.e., dept_info. The parentheses associated with the employee table specify that the contained table dept is a child table of the parent employee table. The square brackets indicate that the dept table is a base table for object fields with the specified field name, i.e., dept_info. This arrangement requires an FK:PK relationship between the employee table and the department table that is supported by a registered primary-foreign key relationship where the primary key is the primary key of the dept table and the corresponding foreign key is the foreign key of the employee table. The DBMS checks its database dictionary to determine if such a registered primary-foreign key relationship exists between the primary key deptno of the dept table and the foreign key deptno of the employee table.

[0277] In response to this determination, the DBMS determines that the attribute deptno of employee and the deptno of table dept are relevant attributes for the JSON duality view employee_jdv3, and creates the JSON duality view employee_jdv3. This determination is made without these attributes being explicitly referenced as relevant attributes in JDDL3'.

[0278] In addition, the DBMS determines that the subfields of the object dept_info are the fields deptno and dname because these are the attribute names of the table dept, and the DBMS also determines that these attributes are the base attributes of these subfields. The DBMS automatically defines the view employee_jdv3 in this way without these fields and attributes being explicitly referenced in JDDL3'.

[0279] JDDL4' is an example DDL statement that defines a multi-table JSON duality view (ie, JSON duality view deptvf) with an array field using a simplified syntax. The JSONIZE clause contains the simplified table object mapping shown below:

[0280] dept('emp_info':[employee])

[0281] The mapping specifies that table dept is the root table and table employee is the child table and base table of the array field of the root table employee, and specifies the name of the array field, i.e., emp_info. The parentheses associated with table dept specify that the table employee contained therein is a child table of the parent table dept. The square brackets indicate that table employee is the base table of the array field with the specified name, i.e., 'emp_info'. This arrangement requires a FK:PK relationship between table dept and table employee that is supported by a registered primary-foreign key relationship where the primary key is the primary key of table dept and the corresponding foreign key is the foreign key of table employee. The DBMS relies on its database dictionary to determine if such a registered primary-foreign key relationship exists, i.e., a registered primary-foreign key relationship between the primary key deptno of table dept and the foreign key deptno of table employee.

[0282] In response to this determination, the DBMS determines that the attribute deptno of employee and the deptno of table dept are related attributes for the JSON duality view deptvf, and creates the JSON duality view deptvf. This determination is made without these attributes being explicitly referenced as related attributes in JDDL 3'.

[0283] In addition, the DBMS determines that the subfields of the array field emp_info are the fields empno, ename, and job, because these are the attribute names of the table employee, and the DBMS also determines that these attributes are the base attributes of these subfields. The DBMS automatically defines the view employee_jdv3 in this way without these fields and attributes being explicitly referenced in JDDL3'.

[0284] Fig.15A and Fig. 15B A BNF (Backus-Naur Form) grammar is shown that shows a simplified syntax of a DDL statement that defines a JSON duality view. This grammar is an embodiment of a relational DBMS.

[0285] Simplified DDL syntax - GraphQL

[0286] Another simplified syntax that can be used to define JSON duality views is GraphQL (e.g., see GraphQL, October 2021 edition). The DDL statement identifies the root table and an object notation with syntax similar to GraphQL. Using this object notation, the DDL statement defines a root object, a root field, and zero or more GraphQL object fields and corresponding child fields. GraphQL object fields are associated with child tables. Based on the registered parent foreign key relationship between the child table and the corresponding parent table, the DBMS automatically determines whether the registered parent foreign key relationship corresponds to a PK:FK relationship or a FK:PK relationship between the parent table and the child table. Based on this determination, the DBMS treats the GraphQL object field as a JSON object field or an array field. Finally, similar to what was previously described, the child table of a particular GraphQL object field can also be the parent table of the child table of a nested GraphQL object field at the next level in the object hierarchy.

[0287] Fig.16 Describes the DDL statement JDDL-GQ that defines the JSON binary view deptvfq using GraphQL. The JSON binary view deptvfq is similar to deptvf. The clause FROM dept identifies the table dept as the root table.

[0288] Using square brackets for object notation, JDDL-GQ maps scalar root fields to property names of the root table dept. For example, the JSON field DeptNumber is mapped to the property deptno. Using object notation, JDDL-GQ also maps the GraphQL object field emp_info to a child table of the root table dept, namely the table employee. Based on the registered primary-foreign key relationship (where table dept has a primary key deptno and table employee has a foreign key deptno), the DBMS determines that this relationship corresponds to a PK:FK relationship between the tables, so Emp_info is an array field. JDDL-GQ maps the subfields EmpNum and EmpName of the array field to the base properties empno and ename of the table employee.

[0289] View Object View Mode

[0290] The DBMS generates output describing the view by using the DDL command DESCRIBE. This output describes the details of the view's metadata, such as the view query expression.

[0291] Users also find descriptions of the object view schema of the JSON duality view useful. According to an embodiment, the DBMS may generate an output describing the object view schema of the JSON duality view. According to an embodiment, the DBMS is configured to provide a function to be called that generates a description of the JSON schema. The function takes the JSON duality view as a parameter. Alternatively, the syntax of a DDL statement requesting the object view schema may also be used.

[0292] Fig.16 An example of a description of the object view schema of deptvfq is shown. The description conforms to the JSON schema.

[0293] Finally, database commands submitted to the DBMS can use a simplified syntax to generate query expressions similar to view query expressions. Similar to how JSON duality views are defined, registered parent foreign key relationships can be used to generate query expressions that return JSON objects with array fields or object fields.

[0294] JSON Duality View Metadata

[0295] In response to receiving a DDL statement defining a JSON duality view, the DBMS generates JDV metadata defining the view in the database dictionary. The metadata defines various aspects, such as:

[0296] 1. Fields, field names, object hierarchies, object view modes, and table hierarchies.

[0297] 2. Root table and the mapping between root fields and root attributes.

[0298] 3. Mapping between basic tables and basic attributes to object fields and subfields of array fields.

[0299] 4. Object and Array Fields Mapping between FK:PK relationships to object and array fields, and for each FK:PK relationship, the related attributes and tables.

[0300] 5. Change the mapping between permissions and base tables and attributes.

[0301] 6. Version signature pattern set.

[0302] 7. A view query expression in the case where a DDL statement defines a JSON duality view using a view query expression.

[0303] 8. One or more JDV object identifier attributes, including one or more JDV object identifiers corresponding to the primary key.

[0304] JDV metadata can be cached in volatile memory in a compile-time form. The cached JDV metadata provides faster access to JDV metadata. The faster access is accelerated not only by caching the metadata in lower latency volatile memory, but also by storing the metadata in a compile-time format that is organized for more efficient access by database processes that use the metadata to perform operations such as compilation.

[0305] The terms correlated tables and correlated attributes are generally used in this article to refer to tables and attributes involved in the FK:PK relationship of an object field or tables and attributes involved in the PK:FK relationship of an array field. When used with respect to tables or attributes, the term "correlated" does not limit tables and attributes to those that are related by an outer query or subquery query expression in a view query expression of a DDL statement or stored in JDV metadata. As shown above, DDL statements can be used to define JSON duality views without describing view query expressions, such as DDL statements like JDDL3'. Database statements requesting JDV objects in a JSON duality view can be rewritten to include correlated subqueries of object fields or array fields based on mappings on JDV metadata (including mappings between FK:PK relationships and object fields and mappings between FK:PK relationships and array fields).

[0306] JSON Duality View DOCS

[0307] The JSON duality view and related content described in this article can be implemented in DOCS. Figure 1 Similarly, DOCS provides a view mechanism that can be adapted to map attributes of collections and tables to fields of an object view schema. DDL statements (such as simplified DDL syntax) can be used to define JSON duality views and generate JDV metadata that defines JSON duality views.

[0308] DOCS provides a primary key for a table or collection of documents. For example, a JSON document in a collection might have an "_id" field that is used as the primary key. A collection or table of documents might also have one or more foreign keys with the primary key value. The database dictionary for DOCS can define registered primary-foreign key relationships that can be used to automatically generate JSON duality views using the simplified DDL syntax described previously.

[0309] In DOCS where documents are stored as JSON objects, the JSON duality view can define a root collection and a subcollection, and the PK:FK relationship between the root collection and the subcollection can be used to define an array field in the object view, whose related properties include the primary key property in the root collection and the foreign key property in the subcollection. Similarly, the FK:PK relationship between the root collection and the subcollection can be used to define an object field.

[0310] A base record set includes a hierarchy of record subsets, each of which includes one or more JSON objects from the corresponding base collection. The parent-child relationship between a parent record subset and a child record subset is based on the registered parent-foreign relationship between the primary key and foreign key of the collections of the parent record subset and the child record subset.

[0311] DBMS Overview

[0312] A database management system (DBMS) manages a database. A DBMS may include one or more database servers. A database includes database data and a database dictionary stored on a persistent storage mechanism (such as a set of hard disks). Database data can be stored in one or more collections of records. The data within each record is organized into one or more attributes. In a relational DBMS, collections are called tables (or data frames), records are called records, and attributes are called attributes. In a document DBMS ("DOCS"), a collection of records is a collection of documents, each of which can be a data object tagged with a hierarchical markup language, such as a JSON object or an XML document. Attributes are called JSON fields or XML elements. A relational DBMS can also store hierarchically tagged data objects; however, the hierarchically tagged data objects are contained in the attributes of the record, such as attributes of JSON type.

[0313] A user interacts with the database server of a DBMS by submitting commands to the database server that cause the database server to perform operations on the data stored in the database. A user may be one or more applications that interact with the database server running on a client computer. Multiple users may also be collectively referred to as users in this article.

[0314] Database commands may be in the form of database statements that conform to a database language. The database language used to express database commands is Structured Query Language (SQL). There are many different versions of SQL, some standard and some proprietary, and with various extensions. Data Definition Language ("DDL") commands are issued to a database server to create or configure data objects, such as tables, views, or complex data types, referred to herein as database objects. SQL / XML is a common extension of SQL used when manipulating XML data in object-relational databases. Another database language used to express database commands is Spark REST, which uses a syntax based on function or method calls. TM SQL.

[0315] In DOCS, database commands can be in the form of function or object method calls that invoke CRUD (create, read, update, delete) operations. An example of an API for such function and method calls is MQL (MondoDB TM In DOCS, database objects include collections of documents, views, or fields defined by a JSON schema against a collection. Views can be created by calling functions provided by the DBMS for creating views in the database.

[0316] Changes to a database in a DBMS are made using transaction processing. A database transaction is a set of operations that change database data. In a DBMS, a database transaction is initiated in response to a database statement that requests a change, such as a DML statement that requests an update, insertion of a record, or deletion of a record, or a CRUD object method call that requests the creation, update, or deletion of a document. DML statements or commands refer to statements that specify changes to data, such as INSERT and UPDATE statements. DML statements or commands do not refer to statements that only query database data. Committing a transaction refers to making the changes of the transaction permanent.

[0317] Under transaction processing, all changes of the transaction are made atomically. When committing a transaction, either all changes are committed or the transaction is rolled back.

[0318] In a distributed transaction, multiple DBMSs use a two-phase commit confirmation method to commit and confirm the distributed transaction. Each DBMS executes a local transaction in a branch transaction of a distributed transaction. One DBMS (coordinating DBMS) is responsible for coordinating the transaction commit confirmation on one or more other database systems. Other DBMSs are referred to as participating DBMSs in this article.

[0319] Two-phase commit confirmation involves two phases, the prepare commit confirmation phase and the commit confirmation phase. In the prepare commit confirmation phase, the branch transaction is prepared in each of the participating database systems. When the branch transaction is prepared on the DBMS, the database is in a "prepared state" so that it can guarantee that the modifications performed on the database data as part of the branch transaction can be committed. This guarantee may require persistent storage of the change record of the branch transaction. The participating DBMS confirms when it has completed the prepare commit confirmation phase and has entered the prepared state of the corresponding branch transaction of the participating DBMS.

[0320] In the commit confirmation phase, the coordinating database system commits and confirms the transaction on the coordinating database system and the participating database systems. Specifically, the coordinating database system sends a message to the participants, requesting the participants to commit and confirm the modifications specified by the transaction to the data on the participating database systems. Then, the participating database systems and the coordinating database system commit and confirm the transaction.

[0321] On the other hand, if a participating database system fails to prepare, or the coordinating database system fails to commit the confirmation, then at least one of the database systems cannot make the changes specified by the transaction. In this case, all modifications at each of the participants and the coordinating database system are rolled back, restoring each database system to its state before the changes.

[0322] A client can issue a series of requests, such as requests for the execution of queries, to a DBMS by establishing a database session. A database session includes a specific connection to a database server established for a client, through which the client can issue a series of requests. A database session process executes within a database session and handles requests issued by a client through the database session. A database session can generate an execution plan for a query issued by a database session client and marshal slave processes for execution of the plan.

[0323] A database server may maintain session state data about a database session. The session state data reflects the current state of the session and may include the identity of the user for whom the session was established, the services used by the user, instances of object types, language and character set data, statistics about session resource usage, values ​​of temporary variables generated by processes executing software within the session, cursor storage, variables, and other information.

[0324] The database server includes multiple database processes. Database processes run under the control of the database server (i.e., can be created or terminated by the database server) and perform various database server functions. Database processes include processes that run within a database session established for a client.

[0325] A database process is a unit of execution. A database process can be a computer system process or thread, or a user-defined execution context, such as a user thread or fiber. Database processes can also include "database server system" processes, which provide services and / or perform functions on behalf of the entire database server. Such database server system processes include listeners, garbage collectors, log writers, and recovery processes.

[0326] A multi-node database management system consists of interconnected nodes, each running a database server that shares access to the same database. Typically, the nodes are interconnected via a network and share access to shared storage to varying degrees, such as shared access to a set of disk drives and data blocks stored thereon. The nodes in a multi-node database system may be in the form of a group of computers (e.g., workstations, personal computers) interconnected via a network. Alternatively, the nodes may be nodes of a grid consisting of nodes in the form of server blades interconnected to other server blades on a rack.

[0327] Each node in a multi-node database system hosts a database server. A server, such as a database server, is a combination of integrated software components and an allocation of computing resources, such as memory, nodes, and processes on the nodes for executing the integrated software components on processors, the combination of software and computing resources being dedicated to performing specific functions on behalf of one or more clients.

[0328] Resources from multiple nodes in a multi-node database system can be allocated to software running a particular database server. Each combination of software and resource allocation from a node is a server referred to herein as a "server instance" or "instance." A database server can include multiple database instances, some or all of which run on separate computers (including separate server blades).

[0329] The database dictionary may include multiple data structures that store database metadata. For example, the database dictionary may include multiple files and tables. Some data structures may be cached in the main memory of the database server.

[0330] When a database object is said to be defined by a database dictionary, the database dictionary includes metadata that defines the properties of the database object. For example, metadata in a database dictionary that defines a database table may specify the attribute names and the data types of the attributes, and one or more files or portions thereof that store the table data. Metadata in a database dictionary that defines a procedure may specify the name of the procedure, the procedure's parameter and return data types, and the data types of the parameters, and may include source code and its compiled version.

[0331] Database objects may be defined by a database dictionary, but the metadata in the database dictionary itself may only partially specify the attributes of the database object. Other attributes may be defined by data structures that may not be considered part of the database dictionary. For example, a user-defined function implemented in a JAVA class may be partially defined by a database dictionary by specifying the name of the user-defined function and by specifying references to files containing the Java class source code (i.e., .java files) and the compiled version of the class (i.e., .class files).

[0332] Native data types are data types that are supported by the DBMS "out of the box." On the other hand, non-native data types may not be supported by the DBMS out of the box. Non-native data types include user-defined abstract types or object classes. Non-native data types can only be recognized and processed by the DBMS in database commands after the non-native data type is defined in the database dictionary of the DBMS (for example, by issuing a DDL statement to the DBMS that defines a non-native date type). Native data types do not have to be defined by a database dictionary to be recognized as valid data types and processed by the DBMS in database statements. Typically, the database software of the DBMS is programmed to recognize and process native data types without having to be configured to the DBMS (for example, by issuing a DDL statement to the DBMS to define the data type) to do so.

[0333] Hardware Overview

[0334] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. The special-purpose computing device can be hard-wired to perform the technology, or can include a digital electronic device (such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs)) that is permanently programmed to perform the technology, or can include one or more general-purpose hardware processors that are programmed to perform the technology according to program instructions in firmware, memory, other storage devices, or combinations. Such special-purpose computing devices can also combine customized hard-wired logic, ASICs or FPGAs with customized programming to complete the technology. The special-purpose computing device can be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that incorporates hard-wired and / or program logic to implement the technology.

[0335] For example, Fig.17 1 is a block diagram illustrating a computer system 1700 upon which embodiments of the present invention may be implemented. Computer system 1700 includes a bus 1702 or other communication mechanism for communicating information, and a hardware processor 1704 coupled to bus 1702 for processing information. Hardware processor 1704 may be, for example, a general purpose microprocessor.

[0336] The computer system 1700 also includes a main memory 1706, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 1702 to store information and instructions to be executed by the processor 1704. The main memory 1706 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 1704. When such instructions are stored in a non-transitory storage medium accessible to the processor 1704, the computer system 1700 is presented as a special-purpose machine customized to perform the operations specified in the instructions.

[0337] Computer system 1700 also includes a read only memory (ROM) 1708 or other static storage device coupled to bus 1702 to store static information and instructions for processor 1704. A storage device 1710, such as a magnetic disk, optical disk, or solid state drive, is provided and coupled to bus 1702 to store information and instructions.

[0338] The computer system 1700 may be coupled to a display 1712, such as a cathode ray tube (CRT), via the bus 1702 to display information to a computer user. An input device 1714, including alphanumeric and other keys, is coupled to the bus 1702 to communicate information and command selections to the processor 1704. Another type of user input device is a cursor control 1716, such as a mouse, trackball, or cursor direction keys, for communicating directional information and command selections to the processor 1704 and for controlling cursor movement on the display 1712. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to be positioned in a specified plane.

[0339] The computer system 1700 may implement the techniques described herein using customized hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that is combined with the computer system to make the computer system 1700 a special purpose machine or programmed as a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 1700 in response to the processor 1704 executing one or more sequences of one or more instructions contained in the main memory 1706. Such instructions may be read into the main memory 1706 from another storage medium, such as the storage device 1710. Execution of the sequences of instructions contained in the main memory 1706 causes the processor 1704 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0340] The term "storage medium" as used herein refers to any non-transitory medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks or solid-state drives, such as storage device 1710. Volatile media include dynamic memory, such as main memory 1706. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, read-only compact disks (CD-ROMs), any other optical data storage media, any physical media with a pattern of holes, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips, or tape cassettes.

[0341] Storage media are distinct from but can be used in conjunction with transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that comprise bus 1702. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0342] Various forms of media may be involved in carrying one or more sequences of one or more instructions to the processor 1704 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 1700 may receive the data on the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal and appropriate circuitry may place the data on the bus 1702. The bus 1702 carries the data to the main memory 1706, from which the processor 1704 retrieves and executes the instructions. The instructions received by the main memory 1706 may optionally be stored on the storage device 1710 before or after execution by the processor 1704.

[0343] Computer system 1700 also includes a communication interface 1718 coupled to bus 1702. Communication interface 1718 provides bidirectional data communication coupled to a network link 1720 connected to a local network 1722. For example, communication interface 1718 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection to a corresponding type of telephone line. As another example, communication interface 1718 can be a local area network (LAN) card that provides a data communication connection to a compatible LAN. Wireless links can also be implemented. In any such implementation, communication interface 1718 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0344] The network link 1720 typically provides data communication to other data devices through one or more networks. For example, the network link 1720 can provide a connection through a local network 1722 to a host 1724 or to data equipment operated by an Internet Service Provider (ISP) 1726. The ISP 1726 in turn provides data communication services through the global packet data communication network now commonly referred to as the "Internet" 1728. Both the local network 1722 and the Internet 1728 use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 1720 and through the communication interface 1718 (which carry the digital data to and from the computer system 1700) are example forms of transmission media.

[0345] Computer system 1700 can send messages and receive data, including program code, through the network(s), network link 1720, and communication interface 1718. In the Internet example, server 1730 can transmit the requested code for an application program through Internet 1728, ISP 1726, local network 1722, and communication interface 1718.

[0346] The received code may be executed by processor 1704 as it is received, and / or stored in storage device 1710 or other non-volatile storage for later execution.

[0347] Software Overview

[0348] Fig.18 1 is a block diagram of a basic software system 1800 that may be used to control the operation of the computing system 1700. The software system 1800 and its components, including their connections, relationships, and functions, are meant to be exemplary only and are not meant to limit implementation of the example embodiment(s). Other software systems suitable for implementing the example embodiment(s) may have different components, including components with different connections, relationships, and functions.

[0349] Software system 1800 is provided to direct the operation of computing system 1700. Software system 1800, which may be stored in system memory (RAM) 1706 and on fixed storage (eg, hard disk or flash memory) 1710, includes a kernel or operating system (OS) 1810.

[0350] The OS 1810 manages low-level aspects of computer operation, including managing the execution of processes, memory allocation, file input and output (I / O), and device I / O. One or more application programs, represented as 1802A, 1802B, 1802C ... 1802N, can be "loaded" (e.g., transferred from fixed storage 1710 to memory 1706) for execution by the system 1800. Applications or other software intended for use on the computer system 1700 can also be stored as a set of downloadable computer-executable instructions, for example, for downloading and installation from an Internet location (e.g., a Web server, application store, or other online service).

[0351] The software system 1800 includes a graphical user interface (GUI) 1815 for receiving user commands and data in a graphical manner (e.g., "clicks" or "touch gestures"). The system 1800 can then act on these inputs according to instructions from the operating system 1810 and / or (one or more) applications 1802. The GUI 1815 is also used to display the results of operations from the OS 1810 and (one or more) applications 1802, so that the user can provide additional input or terminate the session (e.g., log out).

[0352] The OS 1810 may execute directly on the bare hardware 1820 (e.g., processor(s) 1704) of the computer system 1700. Alternatively, a hypervisor or virtual machine monitor (VMM) 1830 may be inserted between the bare hardware 1820 and the OS 1810. In this configuration, the VMM 1830 acts as a software "buffer" or virtualization layer between the OS 1810 and the bare hardware 1820 of the computer system 1700.

[0353] VMM 1830 instantiates and runs one or more virtual machine instances ("guest machines"). Each guest machine includes a "guest" operating system, such as OS 1810, and one or more applications designed to execute on the guest operating system, such as (one or more) application 1802. VMM 1830 presents a virtual operating platform to the guest operating system and manages the execution of the guest operating system.

[0354] In some cases, VMM 1830 can allow a guest operating system to run as if it were running directly on bare hardware 1820 of computer system 1700. In these cases, the same version of the guest operating system that is configured to execute directly on bare hardware 1820 can also execute on VMM 1830 without modification or reconfiguration. In other words, in some cases, VMM 1830 can provide complete hardware and CPU virtualization for the guest operating system.

[0355] In other cases, the guest operating system may be specifically designed or configured to execute on the VMM 1830 to improve efficiency. In these cases, the guest operating system "knows" that it is executing on the virtual machine monitor. In other words, in some cases, the VMM 1830 can provide paravirtualization for the guest operating system.

[0356] A computer system process includes an allocation of hardware processor time and an allocation of memory (physical and / or virtual) for storing instructions executed by the hardware processor, for storing data generated by the execution of instructions by the hardware processor, and / or for storing hardware processor state (e.g., contents of registers) between allocations of hardware processor time when the computer system process is not running. A computer system process runs under the control of an operating system and may run under the control of other programs executing on the computer system.

[0357] cloud computing

[0358] The term "cloud computing" is generally used herein to describe a computing model that enables on-demand access to a shared pool of computing resources, such as computer networks, servers, software applications, and services, and that allows resources to be rapidly provisioned and released with minimal management effort or service provider interaction.

[0359] Cloud computing environments (sometimes referred to as cloud environments or clouds) can be implemented in a variety of different ways to best meet different needs. For example, in a public cloud environment, the underlying computing infrastructure is owned by an organization that makes its cloud services available to other organizations or the public. In contrast, a private cloud environment is typically intended for use by or within a single organization only. A community cloud is intended to be shared by several organizations within a community; while a hybrid cloud includes two or more types of clouds (e.g., private, community, or public) that are bound together by data and application portability.

[0360] In general, the cloud computing model enables some of those responsibilities that may have previously been provided by an organization's own information technology department to instead be delivered as a service layer within a cloud environment for consumption by consumers (whether internal or external to the organization, depending on the public / private nature of the cloud). The precise definition of the components or features provided by or within each cloud service layer may vary depending on the specific implementation, but common examples include: Software as a Service (SaaS), in which consumers use software applications running on the cloud infrastructure, while the SaaS provider manages or controls the underlying cloud infrastructure and applications. Platform as a Service (PaaS), in which consumers can develop, deploy, and otherwise control their own applications using software programming languages ​​and development tools supported by the PaaS provider, while the PaaS provider manages or controls other aspects of the cloud environment (i.e., everything under the runtime execution environment). Infrastructure as a Service (IaaS), in which consumers can deploy and run arbitrary software applications, and / or provision processing, storage, networking, and other underlying computing resources, while the IaaS provider manages or controls the underlying physical cloud infrastructure (i.e., everything below the operating system layer). Database as a Service (DBaaS), in which the consumer uses a database server or database management system running on a cloud infrastructure, while the DbaaS provider manages or controls the underlying cloud infrastructure, applications, and servers, including one or more database servers.

[0361] In the foregoing specification, embodiments of the present invention have been described with reference to numerous specific details that may vary from implementation to implementation. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what the applicant intends to be the scope of the invention, is the literal and equivalent range of the set of claims claimed in this application, in the specific form in which such claims are claimed, including any subsequent corrections.

Claims

1. A method, include: The DBMS receives a request for returning a JSON object from a JSON duality view, the JSON duality view defining an object schema for the JSON object, wherein the JSON duality view maps basic attributes of a plurality of basic tables to a plurality of fields of the object schema; In response to receiving the request, the JSON object is generated including the following items: the plurality of fields of the object schema; Object identifier field; Version signature field; Generating the JSON object includes: Retrieving the set of base records of the JSON object based on the JSON duality view; populating the plurality of fields with values ​​based on attribute values ​​of the set of base records; and A version signature of the JSON object is deterministically generated based on the attribute values ​​of the set of base records.

2. The method according to claim 1, Wherein the object schema defines an object hierarchy, the object hierarchy include: a root level having an object field and one or more root fields that are scalar fields, wherein the root table includes one or more root attributes, each of the one or more root attributes being a base attribute of a corresponding root field of the one or more root fields; as well as A first level has a plurality of sub-fields of the object field, wherein the sub-table of the root table comprises a first plurality of first attributes, each first attribute of the first plurality of first attributes being a base attribute of a corresponding sub-field of the plurality of sub-fields.

3. The method according to claim 2, Wherein the root record from the root table is the base record of the JSON object; wherein the first record from the subtable is a base record of the object field; Generating the JSON object includes generating a version signature for the version signature field by at least performing the following operations: generating a specific signature by calling at least a basic signature function using as input a corresponding value of at least one or more first attributes of the first plurality of first attributes; and The version signature is generated by calling at least a basic signature function, the basic signature function using at least the specific signature and a value of at least one of the one or more root attributes as input.

4. The method according to claim 2, further comprising: include: In response to receiving the DDL statement, the DBMS generates and stores in a database dictionary metadata defining the JSON duality view; The DDL statement includes a view query expression, wherein the view query expression: Projecting the first json_object function expression into an outer query expression, the outer query expression mapping the one or more root fields to the one or more root attributes of the root table; The first json_object function expression includes a subquery expression, the subquery expression projects a second json_object expression, and the second The json_object expression maps the plurality of sub-fields of the object field to the first plurality of first attributes included in the sub-table; and The view query expression relates the foreign key of the root table to the primary key of the child table.

5. The method according to claim 2, receiving a DDL statement, wherein the DDL statement identifies the root table, the subtable of the root table, and the name of the object field; The primary-foreign key relationship defined therein is based on the foreign key of the root table and the primary key of the child table; wherein the DDL statement does not explicitly reference the correlation between the foreign key and the primary key; Based on the defined primary-foreign key relationship based on the foreign key and the primary key, the DBMS generates and stores in a database dictionary metadata defining the JSON duality view.

6. The method of claim 5, wherein the DDL statement comprises an expression conforming to GraphQL.

7. The method according to claim 1, Wherein the object schema defines an object hierarchy, the object hierarchy include: a root level having an array field and one or more root fields that are scalar fields, wherein the root table includes one or more root attributes, each root attribute of the one or more root attributes being a base attribute of a corresponding root field of the one or more root fields; as well as A first level has a plurality of sub-fields of the array field, wherein a sub-table of the root table comprises a first plurality of first attributes, each first attribute of the first plurality of first attributes being a base attribute of a corresponding sub-field of the plurality of sub-fields.

8. The method according to claim 7, Wherein the root record from the root table is the base record of the JSON object; wherein each of the plurality of sub-records from the sub-table is a base record of the array field; Generating the JSON object includes generating a version signature for the version signature field by at least performing the following operations: generating a plurality of first signatures by invoking a base signature function for at least each of the plurality of sub-records, the base signature function using as input a corresponding value of each of at least one or more of the plurality of sub-records; and An array signature is generated by calling a basic signature function, the basic signature function using the plurality of first signatures. The version signature is generated by calling at least a basic signature function using as input a specific signature based at least on the array signature and a value of at least one of the one or more root attributes.

9. The method of claim 8, wherein the specific signature is the array signature.

10. The method of claim 2, further comprising: include: In response to receiving the DDL statement, the DBMS generates and stores in a database dictionary metadata defining the JSON duality view; The DDL statement includes a view query expression, wherein the view query expression: Projecting the first json_object function expression into an outer query expression, the outer query expression mapping the one or more root fields to the one or more root attributes of the root table; The first json_object function expression includes a subquery expression, the subquery expression projects a second json_object expression, and the second The json_object expression maps the plurality of sub-fields of the array field to the first plurality of first attributes included in the sub-table; and The view query expression relates the primary key of the root table to the foreign key of the child table.

11. The method according to claim 2, Receiving a DDL statement, wherein the DDL statement identifies the root table, the sub-table of the root table, and the name of an array field; The primary-foreign key relationship defined therein is based on the foreign key of the root table and the primary key of the child table; wherein the DDL statement does not explicitly reference the correlation between the foreign key and the primary key; Based on the defined primary-foreign key relationship based on the foreign key and the primary key, the DBMS generates and stores in a database dictionary metadata defining the JSON duality view.

12. The method of claim 11, wherein the DDL statement comprises an expression conforming to GraphQL.

13. The method according to claim 2, wherein include: receiving a request for a JSON object from the JSON binary view, the JSON object having an object identifier field equal to an object identifier; In response to the request, calling an object identifier function to convert the object identifier into a primary key value; selecting a root record from the root table, the root record having the primary key value for a primary key of the root table; The JSON object is generated based on the root table.

14. The method of claim 2, wherein include: receiving a request for a JSON object from the JSON binary view, the JSON object having an object identifier field equal to an object identifier; In response to the request, calling an object identifier function to convert the object identifier into a first primary key value and a second primary key value; selecting a root record from the root table, the root record having the first primary key value for a first primary key of the root table and having the second primary key value for a second primary key value; as well as The JSON object is generated based on the root table.

15. The method of claim 2, wherein include: receiving a request for a JSON object from the JSON binary view, the JSON object having a root field equal to a specific value; In response to the request, multiple records are filtered from the root table by comparing the specific value with a root attribute corresponding to the root field to select a specific record having the specific value for the root field from the multiple records without performing an object function evaluation on any of the multiple records to select the specific record. selecting a root record from the root table, the root record having the first primary key value for a first primary key of the root table and having the second primary key value for a second primary key value; as well as The JSON object is generated based on the root record.

16. The method of claim 2, receiving a database command, wherein the database command identifies the root table, the sub-table of the root table, and the name of an object field or an array field; The primary-foreign key relationship defined therein is based on the foreign key of the root table and the primary key of the child table; wherein the database command does not explicitly reference the correlation between the foreign key and the primary key; Based on the defined primary-foreign key relationship based on the foreign key and the primary key, the DBMS generates a query expression, and the query expression returns a JSON object including the object field or the array field.

17. The method of claim 5, wherein the database command includes square brackets to indicate that the sub-table is a base table of the object field.

18. The method of claim 16, wherein the database command includes square brackets to indicate that the sub-table is a base table of an array field.

19. The method of claim 5, wherein the DBMS generates and stores in a database dictionary metadata defining the JSON duality view include: Utilizes SQL tokens and parses constructs.

20. The method of claim 16, wherein the DBMS generates and stores in a database dictionary metadata defining the JSON duality view include: Utilizes SQL tokens and parses constructs.

Images