An “object graph” is a collection of related objects which are represented in forms including binary, text, XML (“Extensible Markup Language”), etc. FIG. 1 illustrates a class schema. The class schema 3 represents the classes that may be present in a given object graph, attributes associated with the classes, the relationships between the classes, and associated accessors. Further, the class schema 3 encapsulates the class definitions necessary to create the class. For example, the class schema in FIG. 1 contains a Purchase_Order class 2 with a PURCHASE_ORDER_ID attribute. The Purchase_Order class 2 is related to a LineItem class 4—with a one-to-many relationship. Further, the Purchase_Order class 2 contains an accessor, LineItems, for the relationship to the LineItem class 4. The LineItem class 4 contains a LINEITEM_ID attribute, a QUANTITY attribute, and a DISCOUNT attribute. Further, the LineItem class 4 contains an accessor, Product, for the relationship to the Product class 6, and an accessor, Purchase_Order, for the relationship to the Purchase_Order class 2. The LineItem class 4 is related to a Product class 6 with a one-to-one relationship. The Product class 6 contains a PRODUCT_ID attribute, a NAME attribute, and a PRICE attribute.
The class schema 3, illustrated in FIG. 1, may be used to create numerous object graphs that conform to the class schema. For example, FIG. 2 illustrates an exemplary object graph 8 that conforms to the class schema (3 in FIG. 1). The object graph 8 contains a Purchase_Order_Object_1 10 that contains a PURCHASE_ORDER_ID attribute. The Purchase_Order_Object_1 10 is related to three LineItem objects 11, 12, and 13. As specified by the class schema 3, each LineItem object 11, 12, and 13 contains a LINEITEM_ID attribute, a NAME attribute and a PRICE attribute. Each LineItem object 11, 12, 13 is related to one Product object. For example, LineItem_Object_1 13 is related to Product_Object_1 14, LineItem_Object_2 12 is related to Product_Object_2 15, and LineItem_Object_3 11 is related to Product_Object_2 15. As specified by the class schema 3, each Product object 14, 15 contains a PRODUCT_ID attribute, a NAME attribute, and a PRICE attribute. The Purchase_Order_Object_1 10 may be called the root of the object graph 8 because the Purchase_Order_Object_1 10 (explicitly or implicitly) references all objects in the object graph 8 and is the entry point into the object graph 8.
As shown in FIG. 2, objects typically include a wealth of data and behavior corresponding to the union of all possible applications of the data. As such, object graphs can be quite large. Relational database management systems (RDBMS) allow for the partial retrieval of data corresponding to an object. Retrieval of part of the object, e.g., part of a table row, is called a projection. There are difficult to solve problems related to using projected object graphs. For example, a method defined on an object may require certain attributes, and, thus, if not all the attributes are retrieved, some methods may fail or produce incorrect results. In this case, sending the entire object graph shown in FIG. 2 would be inefficient when all that is really needed is a small portion of the object graph.
As an example, FIG. 3 illustrates a projected version of the object graph 8 that is actually needed by a client process. Note that only a few of the attributes shown in FIG. 2 are needed by the client process. In this case, it would be inefficient to send the large object graph shown in FIG. 2 when all that is really needed is the small object graph shown in FIG. 3.
Still referring to FIG. 3, the subset of object graph 8′, includes the primary key for each object within the object graph, e.g., the primary key for the Purchase_Order_Object_1 10′ is “PURCHASE_ORDER_ID.” Additionally, some objects also include a secondary key. Typically, object graphs require that objects within the graph all include their primary key. Depending on the database requirements, the secondary key may also be required.
In addition, if part of an object is fetched in one transaction, and the rest in another transaction, the two parts may be inconsistent with each other. Because these sorts of problems are difficult to solve, systems that use objects typically fetch the entire object graph. The most innovative systems define groupings of attributes as part of the object schema. This requires the application developer to guess which groups will be needed in the future and to insert this information into the application manually. Unless the proper groups exist in the schema, the results may not be optimal.
USPTO Backgrounds
USPTO Backgrounds