JSON is a text-based format that leverages data structures and basic types found in most programming languages: objects, arrays, strings, and numbers. JSON is commonly used for information exchange between web clients and web servers. Many relational database systems now support JSON, and JSON is the primary data model for many NoSQL systems. MongoDB is one such document database that natively supports storing and querying JSON objects. JSON features in relational databases are described in Section 13.5, and examples of JSON usage in Oracle appear in Section 13.6. Mongo DB is discussed in Chapter 14.
JSON objects are denoted by curly braces { } and arrays are denoted by square brackets [ ]. Each key is a text string enclosed in quotation marks " ". Values in JSON can be a string, number, object, array, Boolean, or null. FIGURE 13.2 shows an example of a JSON object that contains two objects, a corporate customer and an individual customer, that correspond to the CUSTOMERLIST graph of Figure 13.1. The first open curly brace { indicates the beginning of an object, and the last line of the figure is the corresponding closing curly brace } that denotes the end of the object.
The first nested object begins on the second line with an opening {. The key "customerType" is the name of a data field, and the string "Corporate" is the value of the field. The values of "customerType", "status", and "name" are all string types. The key "address" has an object as its value (denoted by { and }). The object has three string fields ("street", "city", and "state") and one number field ("zip"). The key "telephone" has an array as its value. The array elements are objects consisting of three fields. The first object (the corporate customer) has only one object in the array telephone. The second object (the individual customer) has two objects in the telephone array. Note that objects can omit fields (the "status" field is not present for the individual customer), and the elements of an array do not have to be the same type. JSON is both case sensitive and type sensitive. Thus, "name", "Name", and "NAME" are not identical, and "10" and 10 are not identical.
There is an Internet Engineering Task Force draft for JSON Schema, a specification language that is intended to be the basis for developers creating validators for JSON. Public domain validators, schema generators, document generators (for testing purposes), and other schema software based on JSON Schema are available online for a variety of programming languages as well as web-browser implementations. An example of a JSON Schema document (which is also a JSON document) is given in FIGURE 13.3. The example illustrates basic specifications to validate objects and arrays, as well as some constraints on strings and number values. More sophisticated validation, such as using regular expressions to describe patterns, can be found in the JSON Schema draft available online at json-schema.org.
In Figure 13.3 the first two keys, $schema and $id, are required schema keywords that specify which JSON Schema draft version is being applied and the URI for the schema file itself, respectively. The draft used in the example is version 2019-09. The file is a local path with details replaced with “…”; note that the backslash character is an escape character in JSON and must be represented by \ in the URI. The keys title and description are annotations that provide information but do not place any requirements on the input that is being validated. The remaining keywords are assertions that describe what a valid input document conforms to or looks like. The keyword type identifies a JSON type. The first usage of type indicates that the schema definition is intended to validate an object. Subsequent usages of type are used to enforce JSON types for the keys in the object, as well as for nested objects and arrays.
In the example, we illustrate that objects can have properties (the keys in the object), properties can be required (both customerType and telephone must be present in any valid object), and the object can be limited to the specified properties by setting additionalProperties to false (the default is to enforce the specified constraints but also allow any additional keys and values to be ignored by the validator). Assertions that are enforced for the input are as follows:
The keys customerType, status, and name have values that are type string.
The two values that are valid for customerType are given by the enum array with values Corporate and Individual.
address is a nested object with four keys (street, city, state, and zip). Additional constraints on state limit it to two letters, and zip has a minimum and maximum value.
telephone is an array of objects. In order to enforce that there is at least one telephone value per customer object, the telephone key must be required, and then the array must have at least one element (enforced by minItems set to 1).
JSON Schema, while not yet an adopted standard, has ample potential for data integrity specification and enforcement.
JSON and XML (described in Section 13.4), are both human and machine readable; both are intended to be self-describing formats for facilitating data exchange between applications. JSON is popular with developers because it tends to be shorter and easier to write because end tags are not required. JSON supports arrays whereas XML does not; however, JSON data must be validated in program code or by using a draft version of JSON Schema. XML is commonly used for enterprise-level data exchange where validation or data integrity enforcement is required. XML has two standards for specifying data, both illustrated in Section 13.4, which allow constraints to be specified separate from program code and enforced by a parser. The constraints include regular expressions for string values as well as ranges and formats for numbers. There is no standard query language associated specifically with JSON; however, some document databases (such as MongoDB, discussed in Chapter 14) support sophisticated querying of JSON documents.
3.16.82.82