2 Introduction To Car-Racing Duality Views Example

Data for Formula 1 car races is used here to present the features of JSON-relational duality views. This use-case example starts from an analysis of the kinds of JSON documents needed. It then defines corresponding entities and their relationships, relational tables, and duality views built on those tables.

Note:

An alternative approach to creating duality views is available to migrate an application that has existing sets of related documents, so that it uses duality views.

For that you can use the JSON-to-duality migrator, which automatically infers and generates the appropriate duality views. No need to manually analyze the different kinds of documents to discover implicit entities and relationships, and then define and populate the relevant duality views and their underlying normalized tables.

The migrator does all of that for you. By default, whatever document parts can be shared within or across views are shared, and the views are defined for maximum updatability.

See Migrating From JSON To Duality in Oracle Database Utilities.

For the car-racing example we suppose a document-centric application that uses three kinds of JSON documents: driver, race, and team. Each of these kinds shares some data with another kind. For example:

  • A driver document includes, in its information about a driver, identification of the driver's team and information about the races the driver has participated in.

  • A race document includes, in its information about a particular race, information about the podium standings (first-, second-, and third-place winners), and the results for each driver in the race. Both of these include driver and team names. The racing data is for a single season of racing.

  • A team document includes, in its information about a team, information about the drivers on the team.

Operations the application might perform on this data include the following:

  • Adding or removing a driver, race, or team to/from the database

  • Updating the information for a driver, race, or team

  • Adding a driver to a team, removing a driver from a team, or moving a driver from one team to another

  • Adding race results to the driver and race information

The intention in this example is that all common information be shared, so that, say, the driver with identification number 302 in the driver duality view is the same as driver number 302 in the team view.

You specify the sharing of data that's common between two duality views by including the same data from underlying tables.

When you define a given duality view you can control whether it's possible to insert into, delete from, or update the documents supported by the view and, overriding those constraints, whether it's possible to insert, delete, or update a given field in a supported document. By default, a duality view is read-only: no inserting, deleting, or updating documents.

See Also:

_________________________________________________________

  • Car-Racing Example, JSON Documents
    The car-racing example has three kinds of documents: a team document, a driver document, and a race document.
  • Car-Racing Example, Entity Relationships
    Driver, car-race, and team entities are presented, together with the relationships among them. You define entities that correspond to your application documents in order to help you determine the tables needed to define the duality views for your application.
  • Car-Racing Example, Tables
    Normalized entities are modeled as database tables. Entity relationships are modeled as joins between participating tables. Tables team, driver, and race are used to implement the duality views that provide and support the team, driver, and race JSON documents used by the car-racing application.