A Handling Property Graphs Using a Two-Tables Schema
For property graphs with relatively fixed, simple data structures, where you do not need the flexibility of <graph_name>VT$ and <graph_name>GE$ key/value data tables for vertices and edges, you can use a two-tables schema to achieve better run-time performance.
Note:
Support for the two-tables schema approach described in this topic has been deprecated and will probably be removed in a future release.
Instead, you are encouraged use the property graph schema approach to working with graph data, described in Property Graph Schema Objects for Oracle Database.
The two-tables schema approach is a deprecated alternative to the recommended approach of using the property graph schema (described in Property Graph Schema Objects for Oracle Database).
-
The property graph schema approach is designed mainly for heterogeneous and/or large graphs. When a graph model is used to present a dynamic application domain in which new relationships and possibly new data types for the same property name(s) are introduced and added to the graph model on the fly, using the property graph schema is recommended.
When a graph model is used to present a dynamic application domain in which new relationships and possibly new data types for the same property name(s) are introduced and added to the graph model on the fly, using the property graph schema is recommended.
-
The two-tables schema approach is designed for homogenous graphs.
If a graph model represents an application domain where the set of relationships is already known and the total number of distinct relationships is relatively small (less than 1000), then the two-tables approach is a potential option. This situation usually happens when the original data source is from one or a set of existing relational tables or views.
An example of where the two-tables approach might be useful is if all nodes are employees of a specific organization, and each employee has a limited and fixed set of attributes and potential relationships. An example of where the two-tables approach would not be useful is if the nodes can be any individuals who can have different attributes and relationships, and where attributes and relationships can be dynamically added and altered.
In the flexible key/value approach (not two-tables), Oracle Spatial and Graph stores property graph data with a flexible schema: <graph_name>VT$ for vertices and <graph_name>GE$ for edges. In this schema, vertices and edges are stored using multiple rows where each row represents a key/value property associated with the vertex (or the edge) with a flexible data type, determined by the attribute T (type). This schema design can easily accommodate a heterogeneous graph where vertices (edges) have different set of properties or data types of property values.
On the other hand, for a property graph with a homogeneous structure, you can store graph data using a two-tables schema. With this approach, each vertex is stored as a single row in a named vertex table, and each edge as a single row in a named edge table. This way, each column in the row corresponds to a property with a fixed data type. The in-memory analyst can then use this approach to construct and manage the in-memory graphs.
Note:
The two-tables approach is mainly for providing graph data for the in-memory analyst to existing Blueprints-based Java APIs, and text indexing does not work with the two-tables approach.
Graph data change tracking is only available when the property graph schema approach is used.
The following topics focus on how to create a property graph using a two-tables schema, as well as how to execute read and write operations over this data.