Shared Data

An important part of the duality-view use case is that there are some parts of different JSON documents that you want to remain the same. Duplicating data that should always be the same is not only a waste. It ultimately presents a nightmare for application maintenance and evolution. It requires your application to keep the common parts synced.

The unspoken problem presented by document-centric applications is that a JSON document is only hierarchical. And no single hierarchy fits the bill for everything, even for the same application.

Consider a scheduling application involving students, teachers, and courses. A student document contains information about the courses the student is enrolled in. A teacher document contains information about the courses the teacher teaches. A course document contains information about the students enrolled in the course. The problem is that the same information is present in multiple kinds of documents, in the same or different forms. And it's left to applications that use these documents to manage this inherent sharing.

With duality views these parts can be automatically shared, instead of being duplicated. Only what you want to be shared is shared. An update to such shared data is reflected everywhere it's used. This gives you the best of both worlds: the world of hierarchical documents and the world of related and shared data.

There's no reason your application should itself need to manage whatever other constraints and relations are required among various parts of different documents. Oracle Database can handle that for you. You can specify that information once and for all, declaratively.

Here's an example of different kinds of JSON documents that share some parts. This example of car-racing information is used throughout this documentation.

• A driver document records information about a particular race-car driver: driver name; team name; racing points earned; and a list of races participated in, with the race name and the driver position.

• A race document records information about a particular race: its name, number of laps, date, podium standings (top three drivers), and a list of the drivers who participated, with their positions.

• A team document records information about a racing team: its name, points earned, and a list of its drivers.

Stable Data Structure and Types

Another important part of the duality-view use case is that the basic structure and field types of your JSON documents should respect their definitions and remain relatively stable.

Duality views enforce this stability automatically. They do so by being based on normalized tables, that is, tables whose content is independent of each other (but which may be related to each other).

You can define just which document parts need to respect your document design in this way, and which parts need not. Parts that need not have such stable structure and typing can provide document and application flexibility: their underlying data is of Oracle SQL data type JSON (native binary JSON).

No restrictions are imposed on these pliable parts by the duality view. (But because they are of JSON data type they are necessarily well-formed JSON data.) The data isn't structured or typed according to the tables underlying the duality view. But you can impose any number of structure or type restrictions on it separately, using JSON Schema (see below).

An example of incorporating stored JSON-type data directly into a duality view, as part of its definition, is column podium of the race table that underlies part of the race_dv duality view used in the Formula 1 car-racing example in this documentation.^Foot 1

Like any other column, a JSON-type column can be shared among duality views, and thus shared among different kinds of JSON documents. (Column podium is not shared; it is used only for race documents.) See Schema Flexibility with JSON Columns in Duality Views for information about storing JSON-type columns in tables that underlie a duality view.

JSON data can be totally schemaless, with structure and typing that's unknown or susceptible to frequent change. Or you can impose a degree of definition on it by requiring it to conform to a particular JSON schema. A JSON schema is a JSON document that describes other JSON documents. Using JSON Schema you can define and control the degree to which your documents and your application are flexible.

Being based on database tables, duality views themselves of course enforce a particular kind of structural and typing stability: tables are normalized, and they store a particular number of columns, which are each of a particular SQL data type. But you can use JSON Schema to enforce detailed document shape and type integrity in any number of ways on a JSON-type column — ways that are specific to the JSON language.

Because a duality view definition imposes some structure and field typing on the documents it supports, it implicitly defines a JSON schema. This schema is a description of the documents that reflects only what the duality view itself prescribes. It is available in column JSON_SCHEMA of static dictionary views DBA_JSON_DUALITY_VIEWS, USER_JSON_DUALITY_VIEWS, and ALL_JSON_DUALITY_VIEWS. You can also see the schema using PL/SQL function DBMS_JSON_SCHEMA.describe.

Duality views compose separate pieces of data by way of their defined relations. They give you precise control over data sharing, by basing JSON documents on tables whose data is separate from but related to that in other tables.

Both normalizing and JSON Schema-constraining make data less flexible, which is sometimes what you want (stable document shape and field types) and sometimes not what you want.

Oracle Database provides a full spectrum of flexibility and control for the use of JSON documents. Duality views can incorporate JSON-type columns to provide documents with parts that are flexible: not normalized and (by default) not JSON Schema-constrained. See Schema Flexibility with JSON Columns in Duality Views for information about controlling the schema flexibility of duality views.

Your applications can also use whole JSON documents that are stored as a column of JSON data type, not generated by a duality view. Applications can interact in exactly the same ways with data in a JSON column and data in a duality view — in each case you have a set of JSON documents.

Those ways of interacting with your JSON data include (1) document-store programming using document APIs such as Oracle Database API for MongoDB and Oracle REST Data Services (ORDS), and (2) SQL/JSON programming using SQL, PL/SQL, C, or JavaScript.

JSON-relational duality views are special JSON collection views. Ordinary (non-duality) JSON collection views are not updatable. JSON collection views, along with JSON collection tables (which are updatable), are JSON collections. You can use a JSON collection directly with a document API. In particular, the documents in duality views and the documents in JSON collection tables can have the same form and are thus be interchangeable.

This means, for example, that you could start developing an application using a JSON collection table, storing your JSON documents persistently and with no schema, and later, when your app is stable, switch transparently to using a JSON-relational duality view as the collection instead. Your application code accessing the collection can remain the same — same updates, insertions, deletions, and queries. (This assumes that the documents stored in the collection table have the same shape as those supported by the duality view.)

JSON duality views are listed in these static dictionary views, in order of decreasing specificity — see *_JSON_COLLECTION_VIEWS, *_JSON_COLLECTIONS, *_VIEWS, and *_OBJECTS in Oracle Database Reference.

Enforcing structural and type stability means defining what that means for your particular application. This isn't hard to do. You just need to identify (1) the parts of your different documents that you want to be truly common, that is, to be shared, (2) what the data types of those shared parts must be, and (3) what kind of updating, if any, they're allowed. Specifying this is what it means to define a JSON-relational duality view.