Data Graph

In most cases, the details of your business require that different Data Objects be related to one another in either of two ways:

• in a containment relationship, much as our XML CarPolicy elements contained Vehicle elements; or

• in a non-containment relationship, with one Data Object referencing another.

The SDO structure that organizes Data Objects is called a data graph. A data graph is primarily a tree that has, at its root, a single Data Object. The Objects in a data graph may have different properties and even be from different types of data sources.

As shown in Figure 10.1, a graph can be more complex than a tree structure. The solid lines show containing relationships. An Object of type CarPolicy includes

• a property named vehicles, which references an array of Objects that are each of type Vehicle

• a property named drivers, which references an array of Objects that are each of type Driver

Figure 10.1: Data graph

The dashed lines show a series of referencing relationships:

• Each Object of type Vehicle includes a property that references the primary driver.

• Each Object of type Driver includes a property that references a vehicle.

• The references can form a cycle, with a vehicle referencing a driver and a driver referencing a vehicle. A cycle is possible only for a referencing relationship, not for a containing one.

In most cases, the root does not have business data but is a generic Object that unites the subordinate Objects into a hierarchy, as illustrated in a later example.

Relationship to the Data in a Data Source

You can create a data graph to do processing that is internal to your code. In many cases, however, the meaning of a graph depends on how data is organized in a particular type of data source.

For SQL data, a Data Object represents a row of data in most cases, with each property of the Data Object's type representing a column and with the data graph as a whole representing the rows returned from a database query.

A column can contain a foreign key, which is a value that references a row in a second table. A table of employees, for example, usually has a column that contains a department ID, and each of those IDs is also in a column in a table of departments.

In keeping with how a foreign-key relationship is usually reflected in a data graph, each selected row in the employee table is represented by an Employee Object; each selected row in the department table is represented by a Department Object; and each Employee Object refers to a Department Object.

For XML data (including a Web-service message), a Data Object represents an element in most cases, including

• the attributes of that element

• child elements that have no subordinate elements

Each property of the Data Object represents an attribute or element. If an XML element includes a child element that itself has subordinate elements, the child element is usually represented by a second Data Object that is referenced from the first.

Change-Tracking

SDO allows for change-tracking, which has two main purposes:

• to allow for a reversal of changes to Data Objects

• to submit changes to a data source in light of changes that were made to the Data Objects when your code was disconnected from the data source

You can enable change-tracking by setting a property in a data graph or Data Object. A data graph enabled in this way retains details on additions and deletions of Data Objects. A data graph or Object enabled in this way retains details on the changes made to the data that is internal to a single Object.

Inverse Integrity

As you alter Data Objects in a data graph, the SDO runtime can retain the integrity of your data by making related changes to other Objects in the graph. For example, your company transfers an employee from one department (Sales) to another (Marketing). To begin that transfer, a service retrieves data from a relational database into a data graph, which now includes details on the employee (as stored in the Employee table) and on each of the two departments (as stored in the Department table).

As shown in Figure 10.2, one Data Object

• contains data that is specific to the employee

• references a Data Object that contains data on the Sales department

Figure 10.2: Employee transfer at start

As shown in Figure 10.3, the service changes the Data Object so that the reference is not to the Sales department but to Marketing.

Figure 10.3: Employee transfer after the service's change

As shown in Figure 10.4, the SDO runtime ensures inverse integrity, which means that the Data Object that holds data on the Marketing department automatically references the new employee, while the Data Object that holds data on the Sales department does not. Your logic is simpler than would be the case without SDO.

Figure 10.4: Employee transfer after the SDO runtime reacts

Your service updates the relational database by submitting the changed data graph. Your update (like your original reading of data) is usually by way of a Data Access Service, as described later.

Terminology

We are obliged to tell you the following detail. A data graph (as expressed in two words) is a general phrase. A DataGraph, in contrast, is a separate object whose use was required in earlier versions of SDO. This separate object is still available as an option for creating and accessing data graphs but is no longer central to using or understanding the technology.