Framework and method for verifying consistency of cross-layer data

Abstract

The computer analyzes the relationship schema of the database to generate a data entry schema encoded as JSON. A data entry mode is sent to a database client such that the client can validate entered data before the entered data is sent for storage. The entered data in accordance with the data entry pattern is received from the client, as the client uses the data entry pattern to validate the entered data prior to sending the data. The entered data conforming to the data entry mode is stored in a database. The data entry schema and the relationship schema have corresponding constraints on the data to be stored, such as a range limit of database columns or a set of distinct different significance values. The constraints may specify a format mask or a regular expression to which the values in the columns should conform, or a correlation between the values of the plurality of columns.

Description

[0001] Priority claim

[0002] This application claims the benefit of provisional application 63 / 413,835, filed on October 6, 2022, under 35 U.S.C. §119(e), the entire contents of which are hereby incorporated by reference as if fully set forth herein. Technical Field

[0003] The present invention relates to validation of entered data. More specifically, techniques are described that involve using a relational schema of a database to generate a client-agnostic schema that describes rules for consistently validating entered data on any client before storing the entered data in the database. Background Art

[0004] Relational databases have been successful in large part because they centralize the data model, thereby supporting uniform application semantics. This has worked well for more than 40 years, but the traditional relational model is no longer sufficient to meet the needs of rich application semantics that are increasingly implemented at the application layer rather than in the database. This makes the database more of a passive container that provides data storage and data access and manipulation, while application semantics migrate out of the database into tools and microservices. Due to the diverse ecosystem of client implementations, this new division of responsibilities can lead to divergence between modules, non-standard implementations, increased overall architectural complexity, and reduced efficiency. For example, complex rules for validating data stored in a specific table may be implemented and enforced by a specific client application. If a different client application or microservice accesses that same data, another client may make changes that cause the data to violate the validation rules. To prevent this, another client may implement and execute the same validation logic, duplicating work and increasing the likelihood of inconsistencies.

[0005] To avoid unnecessary duplication of validation rules implemented by the client, validation functionality can be centralized on the server side. Database servers provide extremely complex mechanisms (e.g., data types with length restrictions, check constraints, referential constraints, etc.) to ensure the cleanliness and integrity of stored data. However, this data integrity framework exists only within the database layer.

[0006] Unfortunately, there are also disadvantages to performing validation in the database layer. Specifically, when validation is performed on the server side, the client application may still generate malformed input that is rejected by the database. For example, a user may use a client to fill out a complex and detailed form. Only after the form is fully filled out and finally submitted to the database server will the user be notified that a validation error has occurred. Therefore, performing server-side validation may result in wasted database accesses and user annoyance due to entering data into a UI form, submitting the entered data, and then receiving a web page reminding that all fields in the form have not passed database-side validation. For this reason, client applications usually do implement their own independent validation mechanism to perform sanity checks on input data so that malformed input can be immediately rejected. The problem with this approach is that there is nothing to prevent the application-side rules and server-side rules from deviating or diverging across different application modules and microservices.

[0007] This trend of moving validation rules into the application has a number of drawbacks:

[0008] Causes a deviation in the validation semantics between the application and the database,

[0009] Require applications to re-implement validation across modules and microservices, and

[0010] Complicates development and creates silos.

[0011] Today, applications and databases have completely separate mechanisms to validate data. Databases use extremely complex constraints that can be of unlimited complexity and are therefore not suitable for client-side evaluation. Applications have their own custom rules to validate client input data, and these rules can often deviate from the database and across modules and microservices. There is currently no mechanism to ensure that user input is consistently verified within the application and in the database. For example, some applications avoid adding database constraints altogether if they already perform client-side checks on entered data, as application and database rules can easily deviate. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In the attached picture:

[0013] Figure 1 is a block diagram depicting an example database system that uses a relational schema of a database to generate a data entry schema, the data entry schema being a client-independent schema for validating entered data at a database client before storing the entered data in the database;

[0014] Figure 2is a flow chart depicting an example computer process for using a relational schema of a database to generate a data entry schema, the data entry schema being a client-independent schema for validating entered data at a database client before storing the entered data in the database;

[0015] Figure 3 is a block diagram illustrating a computer system in which embodiments of the present invention may be implemented;

[0016] Figure 4 is a block diagram illustrating a basic software system that may be used to control the operation of a computing system. DETAILED DESCRIPTION

[0017] In the following description, for the purpose of explanation, many specific details will be set forth so that the present invention is fully understood. However, it is apparent that the present invention can be practiced without these specific details. In other cases, well-known structures and devices are shown in block diagram form to avoid unnecessary confusion of the present invention.

[0018] General Overview

[0019] This article describes a cross-layer consistency method for verifying input data within an application and within a database using the same set of rules. In this method, validation rules are centrally declared within the database and shared by all application modules. In addition, a technique is described for communicating rules to applications in a client-independent format so that the client side can enforce constraints. This article will give a specific example of using JavaScript Object Notation (JSON) as a client-independent format for specifying validation rules, but the techniques described herein are not limited to any particular client-independent format. Therefore, an embodiment of using JSON as a specification language for validation rules and schematic constraints is described, which is fundamentally different from the conventional use of JSON as a payload transmission format.

[0020] Given a relational table definition and its associated constraints, a JSON representation is automatically generated that captures as many validation rules as possible for the table. Database clients can obtain and use the generated JSON as a language-neutral, cross-tier input validation mechanism for data entered to be stored in the table.

[0021] In an embodiment, a computer analyzes a relational schema of a database to generate a data entry schema and encodes the data entry schema in a client-independent format (e.g., JSON). As used herein, a "data entry schema" is a structured data set that describes validation rules and maps the validation rules to specific locations within a database schema. The data entry schema is sent to a database client so that the client can verify the entered data before sending it to be stored in a database. Entered data that conforms to the data entry schema is received from the database client because the client used the data entry schema to verify the entered data before sending the data. The entered data that conforms to the data entry schema is stored in the database.

[0022] In an embodiment, the data entry schema and the relational schema have corresponding constraints on the data to be stored, such as range restrictions on database columns, such as minimum and / or maximum values ​​or a clear set of different valid values. Constraints can specify format masks or regular expressions that values ​​in a column should conform to, or dependencies between values ​​of multiple columns in the same row of a relational table.

[0023] 1.0 Sample Database System

[0024] Figure 1 1 is a block diagram depicting an example database system 100 in an embodiment. The database system 100 uses the relational schema 140 of the database 120 to generate a data entry schema 170, which is a client-independent schema for validating the entered data 190 at the database client 130 before storing the entered data 190 in the database 120. The database system 100 may be hosted by at least one computer, such as a rack server (such as a blade), a personal computer, a mainframe, a virtual computer, or other computing device. The database system 100 may include a database management system (DBMS), which may include one or more database servers, each of which may be middleware, such as a database server 110. The database server 110 may include and operate one or more relational databases, such as the relational database 120.

[0025] 1.1 Relational Database Schema

[0026] The relational schema 140 may define the relational database 120. The relational schema 140 is schematically shown as being external to the relational database 120 and the database server 110 to indicate that the relational schema 140 may or may not be external to the relational database 120, and may or may not be external to the database server 110, as discussed later herein. In one example, the relational schema 140 is stored in a database dictionary 125 in the database 120. The database dictionary is a database metadata container, as discussed later herein.

[0027] The relational schema 140 may define one or more relational tables, such as the relational table 150, which contain one or more table columns, such as the column 160, which store values ​​of a data type 161, such as numbers or text strings. If the particular data type is not the data type 161 of the column 160, then the database server 110 rejects any attempt to store a value of the particular data type into the column 160. The column 160 may be optional or required, as indicated by the optionality 162, which indicates whether the column 160 may or may not store a null value indicating no value.

[0028] 1.2 Check Constraints

[0029] In addition to or in lieu of column constraints 161-162 that restrict which values ​​can be stored in column 160, relational table 150 may have one or more CHECK constraints, such as check constraint 163, that verify the contents of relational table 150. CHECK constraint 163 may specify one or more restrictions, such as:

[0030] range constraints on the column 160, such as a minimum and / or maximum value or a clear set of distinct valid values,

[0031] The format mask or regular expression that the values ​​in column 160 must conform to,

[0032] · correlations between values ​​of multiple columns in the same row of the relationship table 150, and

[0033] Custom conditions, such as only allowing prime numbers.

[0034] CHECK constraints can be implemented using the same or similar predicate expression syntax as used in filtering queries to the database server 110, such as filters in the WHERE clause of a SELECT query in Structured Query Language (SQL). Thus, CHECK constraints can be very expressive and complex, such as compound expressions containing multiple expression operators, each of which expects multiple parameters, such as so-called binary operators, such as logical (i.e., Boolean) operators, and relational operators such as those used to apply relational algebra. Also, CHECK constraints can invoke user-defined functions (UDFs) that have complex and computationally intensive implementations.

[0035] The implementation of a UDF may or may not be transparent, making it difficult or impossible to analyze the implementation. For example, a UDF may be implemented only as a so-called object code consisting of a sequence of (one or more) instructions of an instruction set architecture (ISA) of a central processing unit (CPU). In this case, the database server 110 can execute the UDF, but may not be able to analyze the instructions that implement the UDF. For example, the database server 110 may apply a CHECK constraint that calls a UDF with opacity, which prevents the database server 110 from discovering the logical properties of the CHECK constraint because the CHECK constraint relies on the opaque UDF. For example, in some cases, the database server 110 may be more or less unable to fully model the CHECK constraint or generate an approximation of the CHECK constraint, such as to send the approximation to the database client 130, as discussed later in this document.

[0036] 1.3 Relationship schema specified in (one or more) DDL statements

[0037] The relational schema 140 and / or any schematic details (such as relational table 150, columns 160, and constraints 161-163) may be defined individually or collectively by one or more data definition language (DDL) statements as discussed later herein. The following is an example DDL statement that defines an example relational table containing example columns with example column constraints.

[0038]

[0039] 1.4 Client and Server

[0040] If the relational database 120 includes a relational table 150, the database client 130 may send the entered data 190 to the database server 110 to be stored in the relational table 150. The database client 130 is a software application that may or may not share a memory address space with the database server 110 and may or may not reside on the same computer as the database server 110. For example, the database server 110 may be embedded in the database client 130, located together in an operating system (OS) process, or may reside in separate processes that collaborate using inter-process communication (IPC). The collaboration of the database client 130 and the database server 110 may use a client-server database protocol, such as Open Database Connectivity (ODBC) or Java ODBC (JDBC).

[0041] 1.5 Interactive Data Entry

[0042] The entered data 190 may be any information that is entered into the database system 100 through the database client 130 and is data that is not automatically generated within the database client 130 itself. For example, the entered data 190 may be interactively (i.e., manually) entered into the database client 130, or may be received by the database client 130 from an external automated source. For example, an external system may use the database client 130 to store data in the relational database 120. In either case, the entered data may be more or less unreliable (i.e., invalid). For example, the entered data may not conform to the constraints 161-163 required to be stored in the relational table 150.

[0043] The entered data 190 can be stored in the relational database 120 only if it conforms to the relational schema 140. One goal of the database system 100 is for the database client 130 to ensure that the entered data 190 is valid before sending it to the database server 110 for storage. Since separation of concerns is a design principle, the database client 130 is not expected to obtain, understand, and directly enforce the relational schema 140. For example, the relational schema 140 may not be available to the database client 130, or the relational schema 140 may be expressed in a domain-specific language (DSL) (such as DDL) that the database client 130 may not understand.

[0044] 1.6 Data Entry Mode

[0045] Instead, the database client 130 obtains a data entry schema 170 that represents some limited aspects of the relational schema 170, but is not itself a relational schema, and is expressed in an open and standardized format that can be processed regardless of the subject matter of the database client 130 and regardless of the implementation of the database client 130. In other words, the data entry schema 170 is application and platform independent.

[0046] The data entry schema 170 is encoded in a client-independent format (e.g., in text form). For illustrative purposes, an example will be given in which the data entry schema 170 is encoded as JavaScript Object Notation (JSON), which is a data exchange format that can express structured and nested data. Most or all web browsers natively support JavaScript, which provides two benefits. First, web browsers can easily parse the data entry schema 170 because JSON conforms to the grammar and syntax of JavaScript, which means that any JavaScript application or browser application can process the data entry schema 170. Second, the database client 130 can be easily implemented in a web browser by implementing the database client 130 in JavaScript.

[0047] JSON parsing is common in general-purpose programming languages ​​such as Java, C#, C++, and Python. JSON grammar and syntax are internationally standardized, and the standard itself, "ECMA-404: JSON data interchange syntax," Second Edition, published by the European Computer Manufacturers Association (ECMA) in December 2017, is incorporated herein by reference in its entirety.

[0048] The data entry schema 170 is automatically generated from the relational schema 140. For example, the database server 110 may generate the data entry schema 170 and send the data entry schema 170 to the database client 130. The data entry schema 170 is an open (i.e., implementation-independent) artifact that any database client may obtain, interpret, and apply to the entered data for validation before sending the entered data to the database server 110.

[0049] 1.7 Impact of Server Verification on Clients

[0050] For example, the entered data 190 includes a field value 195, and the database client 130 may attempt to store the field value 195 in the column 160 by sending the entered data 190 to the database server 110 using a data manipulation language (DML) statement (such as an INSERT or UPDATE statement of SQL). If the field value 195 does not comply with the constraints 161-163, the database server 110 may reject the entered data 190, which may cause trouble to the user of the database client 130. For example, if the field value 195 is invalid because it does not comply with all of the database constraints 161-163, the database server 110 may reject the DML statement without requiring the database server 110 to execute the query plan.

[0051] One technical challenge is that when the database server 110 rejects the entered data 190, the user interface screen for interactive entry of the entered data 190 may be reset to empty entry fields or may no longer be displayed. The entered data 190 may contain many field values ​​entered in a sequence of various screens, and it may be difficult to return to a particular screen in the sequence to re-enter a particular field whose entered value is invalid. For example, the database server 110 may indicate to the database client 130 that the entered data 190 was rejected, but may not be able to indicate which of the many entered fields of the entered data 190 has an invalid value.

[0052] 1.8 JSON generation for client-side validation

[0053] Data entry schema 170 avoids these interactivity issues by using the following two phases of operation. The first phase generates data entry schema 170 from a portion or all of relational schema 140. For example, any of schema components 150, 160, and 161-163 may be explicitly excluded from conversion into data entry schema 170. For example, column 160 may have a flag that explicitly indicates that column 160 is included or excluded for generating data entry schema 170. Likewise, some schema components may be implicitly excluded from generating data entry schema 170, such as if at least a portion of CHECK constraints 163 are not transparent or otherwise do not support conversion into data entry schema 170.

[0054] The generation of the data entry schema 170 may require processing the schema components 150, 160, and 161-163 and converting some or all of these components into corresponding components in the data entry schema 170. For example, the field 180 may be generated from the column 160, and other fields within the data entry schema 170 may be generated from the same column 160 or other columns in the same relational table 150 or other relational tables in the relational schema 140. Since the data entry schema 170 is encoded in JSON that supports composite (i.e., multi-field) and nested data structures, related fields may be logically arranged into groups in the data entry schema 170. For example, the data entry schema 170 may contain a different JSON object for each relational table whose columns have corresponding fields in the data entry schema 170.

[0055] For example, field 180 itself may be a JSON object nested within another JSON object corresponding to relational table 150 along with other JSON objects representing other fields of other columns in relational table 150 in addition to column 160. However, it is not required that schemas 140 and 170 have the same schematic normalization. For example, relational schema 140 may have multiple relational tables arranged in a multidimensional master-detail pattern such as a star or snowflake, but data entry schema 170 may instead contain a flat set of fields without imposing any nesting or grouping.

[0056] 1.9 Transformation Constraint Semantics

[0057] Some constraints in relational schema 140, such as column constraints 161-162, may translate more or less directly into corresponding constraints in data entry schema 170. For example, data type 161 may specify that column 160 stores only numbers, and a corresponding numeric constraint may be generated for field 180 in data entry schema 170.

[0058] The semantics of field constraints 181-183 are as follows. If data type 161 has values ​​that can be naturally ordered, such as numerically or lexically, then value range 181 can specify upper and / or lower bounds (i.e., value limits) for field values ​​195, and each limit can be explicitly inclusive or exclusive. Value range 181 can alternatively specify a set of valid distinct single values, and all other values ​​of data type 161 are prohibited for field values ​​195. Format 183 can specify a pattern, mask, or regular expression to which field values ​​195 should conform, such as the format of a telephone number or email address. Data entry schema 170 can contain constraints, each of which specifies any of the following:

[0059] Regular expressions,

[0060] · The limit of the count of array elements,

[0061] · the limit on the count of array elements matching the criteria,

[0062] · the limit on the count of fields of JSON objects in the data entry schema 170,

[0063] an indication that the elements of the array should be distinct, and

[0064] An indication of whether the limit is inclusive or exclusive.

[0065] The data entry schema 170 may include a version identifier (e.g., from a monotonically increasing sequence of numbers or timestamps). In an embodiment, the version identifier of the data entry schema 170 is based on at least one of: a version identifier of the relational schema 140 and a unique identifier automatically generated when the data entry schema 170 is generated.

[0066] When the relational schema 140 is modified, the data entry schema 170 may be automatically regenerated so that the data entry schema 170 is based on the latest version of the relational schema 140. Each regeneration of the data entry schema 170 may contain a new and different version identifier. In an embodiment, the database server 110 may optionally be configured to reject the entered data 190 if the entered data 190 does not contain the latest regenerated version identifier of the data entry schema 170.

[0067] In JSON, a field can be an array containing multiple values. If field 180 represents an array whose multiple values ​​are provided as elements in field value 195, then uniqueness 182 requires that field value 195 contain no duplicates, which is different from requiring that column 160 contain no duplicates. For example, column 160 may contain data for many users, and uniqueness may be required only within a user's data, rather than across all users' data. In this case, field value 195 may be an array of multiple values ​​for one user and should not contain duplicates, but column 160 may contain duplicates as long as each repetition of the same value is stored for a different corresponding user.

[0068] The following contains example field constraints for example fields. Each example field corresponds to a corresponding example column in the example DDL statement presented earlier in this article. The example fields and example field constraints are encoded as JSON in the following example data entry schema.

[0069]

[0070] In the above sample data entry schema, the field "Category" is required and is nested as one of the "properties" of "Product". Valid category field values ​​must be strings of a maximum of ten characters and must be exactly one of the enumerated literals "Home" or "Apparel". To generate the above sample data entry schema, the field names and types were inferred from the table column definition. The string length limit (maxLength) of the field was inferred from the varchar or char length of the table column. Field constraints (such as enumerations and min / max checks) are inferred from the CHECK constraints of the table column. The list of required fields is inferred from the NOT NULL constraints of the table column.

[0071] 1.10JSON PRECHECK Constraints

[0072] In an embodiment, the standard SQL DDL syntax is enhanced to express the following novel example constraints as CHECK constraints.

[0073] CONSTRAINT <name>CHECK WITH JSON PRECHECK(cond1 AND cond2 AND…condN)

[0074] For column 160, the above example constraints have the following novel features. <name>" indicates that the constraint itself is a first-class database object that can be individually identified, referenced, and processed, such as in the manner given herein. Each of cond1-condN can reference the same or a different corresponding column.

[0075] The above "JSON PRECHECK" explicitly indicates that the constraint should be used to generate the data entry schema 170, but the constraint is not necessarily enforced by the database server 110. In other words, the content in the column 160 does not need to conform to this novel constraint. In this article, PRECHECK specifies that the database client 130 applies the data entry schema 170 to the entered data 190. Optionally, the database server 110 can also enforce the PRECHECK when receiving the entered data 190 from the database client 130.

[0076] The database server 110 may provide a built-in function or UDF, and when the database server 110 receives the entered data 190, the function may be optionally called to result in: a) applying the data entry schema 170 to the entered data 190, or b) applying certain field constraints (such as value ranges 181) to the field values ​​195. In this document, applying the schema 140 or 170 to the stored or entered data, respectively, may be referred to as validating the data with the schema.

[0077] 1.11 Client Constraint Processing

[0078] As explained above, the first operating phase generates the data entry schema 170, which may be immediately or eventually followed by the second operating phase, which requires the database client 130 to use the data entry schema 170 to verify the entered data 190 before sending the entered data 190 to the database server 110. For example, the database client 130 may have a more or less hard-coded mapping between specific fields in the data entry schema 170 and specific user interface widgets displayed in the screen. For example, the field 180 may represent a time type, and the database client 130 may map the field 180 to a text entry widget into which the user can enter the time as a text string. For example, the fields in the data entry schema 170 may have identifiers, and the data entry widget may have its own identifier. The database client 130 may have a mapping from the corresponding identifier of each field in the data entry schema 170 to the identifier of the corresponding corresponding widget.

[0079] In another example, the database client 130 lacks predefined user interface screens and instead processes the data entry mode 170 to dynamically generate corresponding (one or more) screens. For example, the database client 130 can detect that the field 180 represents a time type and generate a corresponding widget for entering a time value. The dynamically generated widget can be general to any data type 161, such as a text entry widget, or can be specific to a specific data type. For example, a date can be entered into a calendar widget.

[0080] 1.12 Data entry mode complies with JSON SCHEMA standard

[0081] JSON itself can specify complex data structures, but lacks expression syntax for traversing these data structures. As a representation standard, basic data processing such as filtering and validation is lacking in JSON. The data entry schema 170, while encoded entirely in JSON lacking expressions, can contain expressions such as regular expressions and / or compound expressions composed of expression operators with predefined semantics.

[0082] In an embodiment, the data entry schema 170 is JSON that complies with the JSON Schema of the Internet Engineering Task Force (IETF), although JSON was originally created for use without a schema and the techniques herein do not require a schema to be applied to the data entry schema 170. The above example data entry schema is encoded as JSON that complies with JSON Schema. "JSON Schema Validation: A Vocabulary for Structural Validation of JSON", published by the IETF on June 10, 2022, is incorporated herein by reference in its entirety.

[0083] 1.13 Standardized Constraint Semantics

[0084] JSON Schema can provide standardized semantics for field constraints 181-183. For example, uniqueness 182 can be encoded using the "uniqueItems" keyword of JSON Schema, and the data entry schema 170 can have constraints encoded with a rich vocabulary of so-called validation keywords of JSON Schema, which have standardized semantics that can be utilized by the data entry schema 170 and the database client 130. In this case, any application that understands JSON Schema can fully and automatically use the data entry schema 170 to validate the entered data 190.

[0085] The following is an example mapping of DDL CHECK conditions to JSON Schema validations (i.e., field constraints). This example mapping can be used to generate a data entry schema 170 from a relational schema 140. In this example mapping, <value>Always a literal, and never an expression or a reference to a different column.

[0086]

[0087]

[0088] 1.14 Data Type Conversion

[0089] The following is an example mapping of SQL column types to JSON field types. This example mapping can be used to generate a data entry schema 170 from a relational schema 140.

[0090]

[0091]

[0092] 1.15 Predefined formats and formatting functions

[0093] The data entry schema 170 is a semi-structured document. However, except as shown in the example mappings above, the data entry schema 170 does not contain Extensible Markup Language (XML), and the relational database 120 does not store XML.

[0094] In the absence of JSON Schema, the data entry schema 170 can have any predefined validation semantics for which the database server 110 can generate representations into the data entry schema 170, as long as the database client 130 can enforce these semantics by interpreting the data entry schema 170. JSON Schema provides predefined and composable validation semantics that can be declaratively arranged and configured in the data entry schema 170. Clients and servers in the database system 100 can adopt JSON Schema as described herein, or can alternatively agree on other predefined semantics that may be more or less difficult for multiple parties to agree on. Either way, the data entry schema 170 can be generated and enforced as discussed herein.

[0095] The following is an example function that may be called under a PRECHECK condition. As explained earlier herein, PRECHECK is performed by the database client 130, and optionally thereafter by the database server 110. Therefore, for the same field value 195, there may be two executions of the same PRECHECK. However, the two executions may use different implementations of the same PRECHECK. The following example function may be implemented as JavaScript for use by the database client 130, and may alternatively be implemented as a built-in function or UDF for use by the database server 110. In an embodiment, the built-in function or UDF is a minimal wrapper that delegates to a JavaScript implementation, as long as the database server 110 can execute JavaScript.

[0096]

[0097] As long as the database client 130 can execute JavaScript, the above example function can be explicitly referenced in the format 183. However, the preferred embodiment of the format 183 does not reference the example function and does not require JavaScript on the client. Instead, the format 183 is generated as a JSON attribute of the field 180. For example, as shown in the above example function, the generated attribute can be named "format" and can have a value that identifies a predefined format. A predefined format is a complex format that is referenced only by name without parameters. In various embodiments, each predefined format is implemented or not by a corresponding example function as shown above.

[0098] 2.0 Sample Data Entry Schema Generation Process

[0099] Figure 2 is a flowchart depicting an example computer process that database system 100 may perform to use relational schema 140 of database 120 to generate data entry schema 170, which is a client-independent schema for validating entered data 190 at database client 130 before storing entered data 190 in database 120. Figure 1 discuss Figure 2 The following three example embodiments each use Figure 1 to execute the different corresponding components Figure 2 As described below, the three embodiments each use a different method to obtain the relational model 140 to generate the data entry model 170.

[0100] In the first embodiment, the database server 110 performs steps 201-203 and 205-206 by directly accessing the relational schema 140 locally. In the second and third embodiments, a corresponding component outside the database server 110 generates the data entry schema 170, which requires steps 201-202.

[0101] In a second embodiment, steps 201-202 are instead performed by database client 130, which accesses relational schema 140 by connecting to database server 110, which performs the remaining steps 203-206.

[0102] In a so-called offline third embodiment that uses neither relational database 120 nor database server 110, the software tool analyzes DDL statements (e.g., in database management scripts). The third embodiment generates data entry schema 170 by executing steps 201-202, and does not execute steps 203-206. For example, the third embodiment can work even if relational database 120 and database server 110 do not exist.

[0103] Step 201 analyzes the relational schema 140 to discover tables, columns, and database constraints, such as column constraints. Identifiers and configurations of all these database objects are discovered by examining the relational schema 140, which can be encoded as DDL statements or stored in a database dictionary. The database dictionary will be discussed later in this article. Step 201 can iterate the discovered tables, columns, and database constraints to ignore (i.e., not process) database objects that explicitly should not or implicitly cannot be transformed into part of the data entry schema 170.

[0104] Step 202 generates the data entry schema 170 from the relational schema 140. Step 202 may iterate the discovered tables, columns, and database constraints to generate corresponding portions of the data entry schema 170, as discussed previously herein.

[0105] Step 203 sends the data entry schema 170 to the database client 130. For example, the database client 130 may request the database server 110 to perform step 203. For example, as long as the database server 110 includes a web server, the database client 130 may send a Representation State (REST) ​​request or other Hypertext Transfer Protocol (HTTP) request to the database server 110 to request a copy of the data entry schema 170.

[0106] In the first and second embodiments, the database client 130 performs step 204. In step 204, the database client 130 verifies that the entered data 190 complies with the data entry mode 170, and then sends the verified entered data 190 to the database server 110. Step 204 may be caused when the entered data 190 is entered as input into the database client 130 in an interactive manner (which may involve a user interface screen, a web page in a web browser, or a command line).

[0107] In step 205, the database server 110 receives the entered data 190 from the database client 130. For example, the database server 110 receives a DML statement containing the entered data 190. The DML statement may specify that a field value 195 is written to a column 160. The database client 130 may include a database driver that generates the DML statement, which is a plain text statement that can be generated and / or sent by the database client 130 with or without a database driver. Of course, before sending the entered data 190, the database client 130 should successfully verify the entered data 190 using the data entry model 170.

[0108] Step 206 stores the entered data 190 in the relational database 120. For example, when executing a DML statement, the database server 110 may store the field value 195 in the column 160. Before storing the entered data 190, step 206 verifies that the entered data 190 conforms to the relational schema 140. If the verification fails, then the storage of the entered data 190 by step 206 does not occur. For example, the DML statement is rejected and not executed.

[0109] 2.1 First Example Activity

[0110] The following example activities A1-A3 illustrate behaviors that the database server 110 may or may not implement and perform. Activity A1 is an optional (e.g., redundant) validation as discussed earlier herein and may be skipped (i.e., not performed). Activity A1 occurs between steps 205-206 described above and determines whether to terminate without performing the final step 206. Figure 2 processing.

[0111] In activity A1, the database server 110 detects whether the entered data 190 conforms to the data entry schema 170. If activity A1 detects that the entered data 190 is invalid, the last step 206 is skipped, and the DML statement is rejected without executing it, for example. For example, if the entered data 190 instead comes from a database client that lacks the data entry schema 170, then the validation of the entered data 190 by activity A1 with the data entry schema 170 may fail, and even if the entered data 190 appears to be valid if compared with the relational schema 140 instead, the validation of activity A1 may fail. If the entered data 190: a) contains an invalid field value, b) lacks a value for a required field, or c) contains a value for an invalid field (such as an unrecognized field, a prohibited field, or too many fields in total), then the entered data 190 is invalid with respect to the data entry schema 170.

[0112] 2.2 Second Example Activity

[0113] Unlike activity A1, activities A2-A3 require behavior that is somewhat independent of Figure 2 Activity A2 illustrates future developments in the database server 110, which unfortunately, in the prior art, may require a restart after rebuilding its code base (e.g., to include a new data entry format for the data entry mode 170). For example, an original equipment manufacturer (OEM) may include some data entry formats and accompanying implementation logic in the database server 110, such as a timestamp format for a timestamp JSON field that can specify a date, time, and time zone. The implementation logic correctly accommodates leap years that cannot be directly expressed with a format mask or regular expression. If a user desires a new data entry format that is not the stock data entry format provided by the OEM, then the user should provide a format mask, regular expression, or accompanying implementation logic for the new data entry format. The new accompanying implementation logic should be added to the code base of the database server 110. Under the prior art, modifying the code base of the database server requires restarting the database server.

[0114] Activity A2 can add a new data entry format to the relational database 120 without restarting the database server 110. For example, the accompanying implementation logic of the new data entry format can be contained in an Oracle PL / SQL package, which the database server 110 can dynamically add to the relational database 120 without restarting the database server 110.

[0115] 2.3 Third Example Activity

[0116] Example activity A3 actually operates in reverse by generating the definition of a new relational table from a data entry schema. For example, a data entry schema may pre-exist and be widely used, and a new database may expect a corresponding relational schema. Example activity A3 may: a) analyze the data entry schema to discover its elements (e.g., fields and field constraints) and their configuration, and b) iterate these elements to generate corresponding portions of (one or more) DDL statements that define corresponding relational schema elements. Example A3 may generate a new relational schema or insert / replace elements in an existing relational schema. Example activity A3 may: a) be performed by a database server 110, which may or may not execute DDL statements to actually create (one or more) tables and columns, b) be performed by a software tool that generates DDL statements and sends them to the database server 110 for execution, or c) be performed by an offline software tool that generates DDL statements even if the database server 110 does not exist.

[0117] 3.0 Database Overview

[0118] Embodiments of the present invention are used in the context of a database management system (DBMS). Accordingly, a description of an example DBMS is provided.

[0119] Generally speaking, 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, where the combination of software and computing resources is dedicated to providing a specific type of functionality on behalf of the server's clients. A database server controls and facilitates access to a specific database, processing client requests to access the database.

[0120] 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 running on a client computer that interacts with the database server. Multiple users may also be collectively referred to as users in this article.

[0121] A database consists of data and a database dictionary stored on a persistent storage mechanism such as a set of hard disks. A database is defined by its own separate database dictionary. The database dictionary includes metadata that defines the database objects contained in the database. In fact, the database dictionary defines most of the contents of the database. Database objects include tables, table columns, and tablespaces. A tablespace is a set of one or more files that are used to store data for various types of database objects (such as tables). If the data for a database object is stored in a tablespace, then the database dictionary maps the database object to one or more tablespaces that hold the data for the database object.

[0122] The DBMS consults the database dictionary to determine how to execute database commands submitted to the DBMS. Database commands can access database objects defined by the dictionary.

[0123] Database commands can be in the form of database statements. In order for a database server to process database statements, the database statements must conform to the database language supported by the database server. A non-limiting example of a database language supported by many database servers is SQL, including proprietary forms of SQL (e.g., Oracle Database 11g) supported by database servers such as Oracle. SQL data definition language ("DDL") instructions are issued to a database server to create or configure database objects, such as tables, views, or complex types. Data manipulation language ("DML") instructions are issued to a DBMS to manage data stored in a database structure. For example, SELECT, INSERT, UPDATE, and DELETE are common examples of DML instructions found in some SQL implementations. SQL / XML is a common extension of SQL that is used when manipulating XML data in an object-relational database.

[0124] A multi-node database management system consists of interconnected nodes that share 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.

[0125] 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, a combination of software and computing resources dedicated to performing specific functions on behalf of one or more clients.

[0126] Resources from multiple nodes in a multi-node database system can be allocated to run the software of a particular database server. Each combination of software and allocation of resources among nodes 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).

[0127] 3.1 Query Processing

[0128] A query is an expression, command, or set of commands that, when executed, causes a server to perform one or more operations on a data set. A query may specify source data objects (or objects), such as tables (or objects), columns (or objects), views (or objects), or snapshots (or objects), from which result sets (or objects) are to be determined. For example, source data objects (or objects) may appear in the FROM clause of a Structured Query Language ("SQL") query. SQL is a well-known example language for querying database objects. As used herein, the term "query" is used to refer to any form of representation of a query, including queries in the form of database statements and any data structures used for internal query representation. The term "table" refers to any source object that is referenced or defined by a query and that represents a set of rows, such as a database table, a view, or an inline query block (such as an inline view or a subquery).

[0129] Queries can perform operations on data from the source data object(s) row by row as the object(s) are loaded, or on the entire source data object(s) after the object(s) have been loaded. Result sets generated by some operations can make available to other operations(s), and in this way, result sets can be filtered out or narrowed based on certain criteria, and / or joined or combined with other result sets(s) and / or other source data objects(s).

[0130] A subquery is a portion or component of a query that is distinct from the other portion(s) or component(s) of the query and can be evaluated separately from the other portion(s) or component(s) of the query (i.e., as a separate query). The other portion(s) or component(s) of the query can form an outer query, which may or may not include other subqueries. A subquery nested within an outer query can be evaluated separately one or more times, while computing results for the outer query.

[0131] Generally speaking, a query parser receives a query statement and generates an internal query representation of the query statement. Typically, the internal query representation is a set of interconnected data structures that represent various components and structures of the query statement.

[0132] The internal query representation may be in the form of a node graph, with each interconnected data structure corresponding to a node and a component of the represented query statement. The internal representation is typically generated in memory for evaluation, manipulation, and transformation.

[0133] Hardware Overview

[0134] 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 these technologies, or can include digital electronic devices (such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are permanently programmed to perform these technologies), or can include one or more general-purpose hardware processors that are programmed to perform these technologies 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 implement these technologies. 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 combines hard-wiring and / or program logic to implement these technologies.

[0135] For example, Figure 3 3 is a block diagram illustrating a computer system 300 upon which embodiments of the present invention may be implemented. Computer system 300 includes a bus 302 or other communication mechanism for communicating information, and a hardware processor 304 coupled to bus 302 for processing information. Hardware processor 304 may be, for example, a general purpose microprocessor.

[0136] Computer system 300 also includes a main memory 306, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 302 for storing information and instructions to be executed by processor 304. Main memory 306 may also be used to store temporary variables or other intermediate information during the execution of instructions executed by processor 304. These instructions, when stored in a non-transitory storage medium accessible to processor 304, make computer system 300 a special-purpose machine customized to perform the operations specified in the instructions.

[0137] Computer system 300 also includes a read only memory (ROM) 308 or other static storage device coupled to bus 302 for storing static information and instructions for processor 304. A storage device 310, such as a magnetic disk, optical disk, or solid state drive, is provided and coupled to bus 302 for storing information and instructions.

[0138] The computer system 300 may be coupled to a display 312, such as a cathode ray tube (CRT), via the bus 302 for displaying information to a computer user. An input device 314, including alphanumeric and other keys, is coupled to the bus 302 for communicating information and command selections to the processor 304. Another type of user input device is a cursor control 316, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 304 and for controlling cursor movement on the display 312. Such input devices typically have two degrees of freedom in two axes, a first axis (e.g., an x-axis) and a second axis (e.g., a y-axis), which allows the device to specify a position in a plane.

[0139] Computer system 300 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that is combined with a computer system to make or program computer system 300 into a special purpose machine. According to one embodiment, computer system 300 performs the techniques described herein in response to processor 304 executing one or more sequences of one or more instructions contained in main memory 306. These instructions may be read into main memory 306 from another storage medium, such as storage device 310. Execution of the sequences of instructions contained in main memory 306 causes processor 304 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0140] The term "storage medium" as used herein refers to any non-transient 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 disks, magnetic disks, or solid-state drives, such as storage device 310. Volatile media include dynamic memory, such as main memory 306. 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, CD-ROMs, any other optical data storage media, any physical media with hole patterns, RAMs, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips, or cassette tapes.

[0141] 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 302. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0142] Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 304 for execution. For example, the instructions may initially be carried on a magnetic 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 computer system 300 may receive the data on the telephone line and use an infrared transmitter to convert the data into an infrared signal. An infrared detector may receive the data carried in the infrared signal and appropriate circuitry may place the data on bus 302. Bus 302 carries the data to main memory 306 from which processor 304 retrieves and executes the instructions. The instructions received by main memory 306 may optionally be stored on storage device 310 before or after execution by processor 304.

[0143] The computer system 300 also includes a communication interface 318 coupled to the bus 302. The communication interface 318 provides a two-way data communication coupled to a network link 320, wherein the network link 320 is connected to a local network 322. For example, the communication interface 318 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection with a corresponding type of telephone line. As another example, the communication interface 318 can be a local area network (LAN) card to provide a data communication connection with a compatible LAN. A wireless link can also be implemented. In any such implementation, the communication interface 318 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0144] The network link 320 typically provides data communications to other data devices through one or more networks. For example, the network link 320 can provide a connection through a local network 322 to a host computer 324 or to data devices operated by an Internet Service Provider (ISP) 326. The ISP 326 in turn provides data communication services through a global packet data communication network, now commonly referred to as the "Internet" 328. Both the local network 322 and the Internet 328 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 320 and through the communication interface 318 (which carry the digital data to and from the computer system 300) are example forms of transmission media.

[0145] Computer system 300 can send messages and receive data, including program code, through the network(s), network link 320, and communication interface 318. In the Internet example, server 330 can transmit the requested code for an application program through Internet 328, ISP 326, local network 322, and communication interface 318.

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

[0147] Software Overview

[0148] Figure 4 4 is a block diagram of a basic software system 400 that may be used to control the operation of the computing system 300. The software system 400 and its components (including their connections, relationships, and functions) are merely exemplary 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.

[0149] Software system 400 is provided for directing the operation of computing system 300. Software system 400, which may be stored on system memory (RAM) 306 and fixed storage (eg, hard disk or flash memory) 310, includes a kernel or operating system (OS) 410.

[0150] OS 410 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 402A, 402B, 402C ... 402N, may be "loaded" (e.g., transferred from fixed storage 310 into memory 306) for execution by system 400. Applications or other software intended for use on computer system 300 may also be stored as a downloadable set of computer-executable instructions, for example, for downloading and installation from an Internet location (e.g., a Web server, app store, or other online service).

[0151] The software system 400 includes a graphical user interface (GUI) 415 for receiving user commands and data in a graphical manner (e.g., "clicks" or "touch gestures"). In turn, these inputs can be operated by the system 400 according to instructions from the operating system 410 and / or (one or more) applications 402. The GUI 415 is also used to display the results of operations from the OS 410 and (one or more) applications 402, so that the user can provide additional input or terminate the session (e.g., log off).

[0152] The OS 410 may execute directly on the bare hardware 420 (e.g., the processor(s) 304) of the computer system 300. Alternatively, a hypervisor or virtual machine monitor (VMM) 430 may be inserted between the bare hardware 420 and the OS 410. In this configuration, the VMM 430 acts as a software "buffer" or virtualization layer between the OS 410 and the bare hardware 420 of the computer system 300.

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

[0154] In some cases, VMM 430 can allow a guest operating system to run as if it were running directly on bare hardware 420 of computer system 400. In these instances, the same version of the guest operating system that is configured to execute directly on bare hardware 420 can also execute on VMM 430 without modification or reconfiguration. In other words, VMM 430 can provide full hardware and CPU virtualization to guest operating systems in some cases.

[0155] In other cases, the guest operating system may be specially designed or configured to execute on VMM 430 to improve efficiency. In these instances, the guest operating system is "aware" that it is executing on a virtual machine monitor. In other words, VMM 430 may provide paravirtualization to the guest operating system in certain circumstances.

[0156] A computer system process includes an allocation of hardware processor time, and an allocation of memory (physical and / or virtual), an allocation of memory 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.

[0157] cloud computing

[0158] The term "cloud computing" is used generally 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 allows resources to be rapidly provisioned and released with minimal management effort or service provider interaction.

[0159] A cloud computing environment (sometimes referred to as a cloud environment or just a cloud) can be implemented in a variety of different ways to best suit different requirements. 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 generally intended for use by or within a single organization. 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) bound together by data and application portability.

[0160] 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 be delivered instead as a service layer within a cloud environment for use by consumers (either internally or externally to the organization, depending on the public / private nature of the cloud). Depending on the specific implementation, the precise definition of the components or features provided by or within each cloud service layer may vary, but common examples include: Software as a Service (SaaS), in which consumers use software applications running on a cloud infrastructure, while the SaaS provider manages or controls the underlying cloud infrastructure and applications. Platform as a Service (PaaS), in which consumers can use software programming languages ​​and development tools supported by the supplier of the PaaS to develop, deploy, and otherwise control their own applications, 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 provide processes, storage, networks, and other basic 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), where the consumer uses a database management system or database server running on a cloud infrastructure, while the DbaaS provider manages or controls the underlying cloud infrastructure and applications.

[0161] The above basic computer hardware and software and cloud computing environment are presented to illustrate the basic underlying computer components that can be used to implement the example embodiment(s). However, the example embodiment(s) are not necessarily limited to any particular computing environment or computing device configuration. Alternatively, according to the present disclosure, the example embodiment(s) may be implemented in any type of system architecture or processing environment that a person skilled in the art would understand as being capable of supporting the features and functions of the example embodiment(s) presented herein.

[0162] In the foregoing description, embodiments of the present invention have been described with reference to numerous specific details, which may vary from implementation to implementation. Accordingly, the description and drawings should be viewed 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 resulting claims in the specific form of the set of claims issued from this application, including any subsequent corrections.< / value> < / name> < / name>

Claims

1. A computer-implemented method, include: Generate a non-relational data entry schema from a database's relational schema; wherein the data entry schema encodes one or more validation rules in a client-independent format, the one or more validation rules being applied to data to be stored at a particular location in the relational schema; Send data entry mode to database client; receiving, from a database client, entered data that the database client has verified as conforming to the data entry pattern based on the data entry pattern; as well as The entered data that conforms to the data entry mode is stored in the database. 2 . The method of claim 1 , wherein the one or more validation rules comprise check constraints specified in a relational schema of a database.

3. The method of claim 2, wherein the check constraint comprises at least one item selected from the group consisting of: Compound expressions, expressions based on multiple columns in the database, and An indication of whether check constraints should be used to generate the data entry schema.

4. The method of claim 1, wherein the data entry mode comprises at least one item selected from the group consisting of: version identifier, Regular expressions, the limit of the count of object attributes, The limit of the count of array elements, limit on the count of array elements matching the criteria, An indication that the elements of an array should be distinct, an indication of whether the limit is inclusive or exclusive, Specifications for time zone data entry, JavaScript Object Notation (JSON), and JSON that complies with the Internet Engineering Task Force (IETF) JSON Schema standard.

5. The method of claim 1, further comprising adding a new data entry format to the database without restarting a server of the database, wherein the generating the data entry mode is based on the new data entry format.

6. The method according to claim 1 further comprises the server of the database detecting whether the entered data conforms to the data entry mode.

7. The method according to claim 6, in: The entered data conforms to the relational schema of the database; The detecting whether the entered data conforms to the data entry mode includes detecting that the entered data does not conform to the data entry mode.

8. The method of claim 1, wherein the sending data entry mode comprises using at least one selected from the group consisting of Representation State (REST) ​​and Hypertext Transfer Protocol (HTTP).

9. The method according to claim 1, in: The sending data entry mode includes sending a semi-structured document from a server of a database; Extensible Markup Language (XML) is not included in at least one item selected from the group consisting of a relational schema of a database and a data entry schema.

10. The method of claim 1, further comprising generating a definition of a relational table from a data entry schema in a non-relational schema.

11. A computer-implemented method, include: Generate a non-relational data entry model from the relational model of the database, where: The generating of the data entry mode is not performed by the database server, and The data entry schema encodes one or more validation rules in a client-independent format, the one or more validation rules being applied to data to be stored at a particular location in the relational schema; receiving, from the database client, entered data that the database client has verified as conforming to the data entry schema based on the data entry schema; and The entered data that conforms to the data entry mode is stored in the database.

12. The method of claim 11, wherein said generating a data entry pattern comprises checking at least one item selected from the group consisting of: the database's relational schema in the database dictionary, and A set of one or more data definition language (DDL) statements.

13. The method of claim 11, wherein the database does not exist during the generating data entry mode.

14. The method of claim 11, wherein the database client executes the generating data entry mode.

15. One or more non-transitory computer readable media storing instructions which, when executed by one or more processors, cause the steps of any of claims 1-14 to be performed.

Images