Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-08-02
2002-11-19
Breene, John (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06484180
ABSTRACT:
BACKGROUND OF THE INVENTION
Relational databases store information in tables, each of which has one or more columns and zero or more rows. Relationships may be defined between two or more tables to reflect real-world relationships between what is represented by the data contained in those tables. Database systems are very good at responding to queries that are written in terms of the relational model in which they store data.
Frequently, the data stored in a database corresponds to real world items. For example, a database may store information about the purchase orders received by a company. The real world items that are represented by the relational data are often constrained by limitations inherent in the real world domain of those items. For example, it may be company policy that P.O. boxes cannot be used as the mailing address for purchase orders. Rules that apply to data items, such as the “no P.O. box mailing address” rule, are generally referred to as “domain logic”.
Ideally, the database applications used to store information in a database implement the domain logic that applies to that information. For example, the database application used to enter purchase orders into a database should check the mailing address specified for each purchase order, and reject the address if it specifies a P.O. box.
Frequently, database application designers tie the domain logic that applies to a data item to the user interface component that is used to present the data item to a user. For example, the database application may present the user with a user interface that includes a user interface component (e.g. a text field) for receiving a mailing address. The application designer associates with that text field domain logic that checks to determine whether the text within the UI component represents a P.O. box. Using a database application design tool, the association of the “no P.O. box” domain logic with the text field may be accomplished by (1) selecting a user interface control associated with the text field, where the user interface control allows entry of validation logic for the text field, and (2) entering validation logic that verifies that the text in the text field does not specify a P.O. box.
Unfortunately, the domain logic thus created is tied to that particular UI component in the user interface, not to the mailing address information itself. Thus, if the application presents the mailing address information in another UI component of a second, different user interface, the “no P.O. box” domain logic would have to be repeated and tied to that other UI component as well. This would involve, once again, entry of validation logic that verifies that the text in the text field does not specify a P.O. box.
Tying the domain logic to user interface components tends to produce applications where the domain logic of the application is “scattered” among the various user interface components. The decentralized nature of the domain logic creates severe problems when, for example, the domain logic for a given type of data item must be modified. For example, if the company decided that mailing addresses can be P.O. boxes if the P.O. boxes are within a particular state, then the application programmer would have to make the appropriate revisions to the validation logic of each user interface component that allows entry of mailing addresses.
Object oriented programming provides certain benefits that the relational model does not. Object oriented programming allows programmers to model real-world things, such as purchase orders, in a way that they find intuitive. It also allows the domain logic that applies to those real-world things to be “encapsulated”, and the code that implements that logic to be re-usable. To achieve these benefits, applications that interact with relational databases are often written so that data is modeled using objects, even though the data for those objects is actually stored in a relational database.
Unfortunately, applications that model data using an object model frequently do so at the cost of sacrificing the efficiency of the relational model. For example, in the relational model, if a user only wants to see data from a particular column, data is only retrieved from that column. In an object model, if a user only wants to see data from a particular attribute of a particular object, the entire object may have to be instantiated before the one attribute value is supplied to the user. At the database level, instantiating the object may involve performing complex joins between multiple tables, and retrieving significantly more data than the user actually wants to see.
The following scenario illustrates the problem of systems that include components that must work together, but which model the same data differently. Specifically, a system for creating purchase orders will be described in which a database server that stores the data persistently uses a relational or “data model”, the JAVA runtime classes that manipulate the data use an object model, and multiple user interfaces, representing distinct end-user applications, present the data to users.
The Data Model
Referring to
FIG. 1
, it illustrates the data model for a Purchase Order that could be used by a relational database server. A Purchase Order is a contractual document that includes information describing the buyer, the seller, the goods and services being procured, delivery information and internal accounting.
In the schema shown in
FIG. 1
, the purchase order (PO) is modeled as a Header which has one or more Lines. Each Line has one or more Shipments, and each shipment has one or more Distributions.
The Header (PO_HEADERS table) stores information pertaining to the entire document (e.g. Buyer, Document Total, Approval Status, Supplier and so on). A purchase order has one and only one header.
The Line (PO_LINES table) stores information about what the buyer wants to order (e.g. Item Number and Description, Unit of Measure, Price, Order Quantity).
A purchase order must have at least one line, and may have more than one if the buyer wants to order different goods and services from the same supplier.
The Shipment (PO_SHIPMENTS table) stores information about where and when the order is to be delivered (e.g. Ship-To Location, Due Date, Shipment Quantity).
A line must have at least one shipment and may have more than one if the buyer wants a single order quantity to be shipped to multiple receiving docks, or shipped to the same dock on several different dates. If a line has>1 shipment, the total quantity of all shipments must equal the line quantity.
The Distribution (DISTRIBUTIONS table) stores information pertaining to the internal accounting for each shipment (e.g. Cost Center, Distribution Quantity).
Each shipment must have at least one distribution and may have more than one if the buyer needs to allocate procurement costs to multiple accounts. If a shipment has>1 distribution, the total quantity of all distributions must equal the shipment quantity.
In accordance with standard relational design, each of the Purchase Order tables store IDs (foreign keys) for referenced entities. In this example, the Purchase Order Header table (P_HEADERS) stores a buyer ID and a supplier ID. The Line table (PO_LINES) stores an item ID. To obtain the Buyer Name, Supplier Name, Item Number and Item Description these foreign keys must be resolved using a join to their corresponding primary key in the referenced tables (BUYERS, SUPPLIERS and ITEMS respectively).
Finally, within the Purchase Order itself, each child entity stores the unique identifier of its parent entity.
The Object Model
While the data model is optimized for quick data storage and retrieval, the object model is optimized for effective domain logic implementation at runtime and code reuse. Fundamental to the object model is the concept of domain objects. Domain objects are objects that represent items of significance in the real world that can be modeled and implemented in software. Domain objects can exist in any domain—business, scientific, natu
Broadbent Christopher
Harris Larry
Lind Barry
Lyons Liza
Ali Mohammad
Bingham Marcel K.
Breene John
Hickman Palermo & Truong & Becker LLP
Oracle Corporation
LandOfFree
Accessing domain object data stored in a relational database... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Accessing domain object data stored in a relational database..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Accessing domain object data stored in a relational database... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2990917