Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-03-11
2001-01-09
Alam, Hosain T. (Department: 2771)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06173290
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates the coupling of state and behavior of an object in a DBMS and in application programs that access the DBMS.
2. Background Art
Existing Database Management Systems (DBMSs) cannot guarantee full coupling of an object's state and behavior in the client environment. In an object-oriented environment, a software application uses a module or entity referred to as an object. An object is comprised of both state and behavior. An object's state is determined by the set of values an object carries for a set of properties or variables. A property can be an attribute of the object or a relation between the object and one or more other objects.
Behavior is defined by the set of operations that can be performed with the object. Each operation is implemented in a routine that is referred to as a method. An object can include a plurality of methods. An operation is performed by invoking one of the object's methods. A method invocation usually occurs as a result of a message sent to an object by another object. The message identifies the method, or operation, that is to be performed. In addition, the message may contain a plurality of properties or arguments that are used by the method.
In the prior art, a DBMS only manages an object's state. Thus, for example, when an application needs an object, it can only retrieve the object's state from the DBMS. The object's method(s) must be retrieved from another source such as a class library, for example.
In addition, the introduction of user-written code in a DBMS engine can compromise the integrity of the engine and is therefore not recommended. To ensure the integrity of the DBMS, a separate implementation of the same object method used by a client is stored in the DBMS server environment. The implementation stored in the DBMS is referred to as a stored procedure. Stored procedure languages are not object-oriented programming languages. A stored procedure is not locally invokable in a client's environment and the DBMS does not use the client's object method. Thus, in the prior art, the same logic is duplicated for different environments. This results in increased development and maintenance costs, and the possibility of serious inconsistencies in object behavior.
As more fully described below, prior art capabilities do not include an ability to store a complete object definition that can be accessed in both a DBMS server and client environment. Object definitions used in these two different environments are effectively stored in separate locations resulting in synchronization issues. In addition, each client application must incorporate all the class libraries that contain any needed functionality. The use of polymorphism (e.g., the ability to refer to different things having different forms) is greatly restricted. Thus, there is added complexity in the management of each client application. This results in additional development and maintenance costs as well as the possibility for inconsistencies.
Relational DBMS
An attribute of an object can be set in a variety of ways. One way is by retrieving information stored in a database management system (DBMS) into a property of the object. A relational DBMS stores information in a table or relation. A table consists of a set of rows and columns. A column defines a field in a row. A row is collection of fields that represents one instance or record of data. The following provides an example of an Employee table for storing employee information:
First Name
Middle Name
Last Name
EmployeeID
Salary
Manager
Level
Peter
Thomas
Smith
345789
$50,000
804356
P4
In this example, the Employee table contains a single row (a table can contain multiple rows, however) that is comprised of seven columns or fields (i.e., First Name, Middle Name, Last Name, EmployeeID, Salary, Manager, and Level). The data stored in the Employee table can be retrieved and used by an application. A data manipulation language (DML) is used to formulate a query to retrieve the data. For example, a query can be used to retrieve the row of the Employee table illustrated above.
In addition to storing application data, the DBMS uses tables to store schema data, or metadata. Metadata contains information that describes the structure of the data stored in the DBMS. For example, metadata identifies the tables contained in the DBMS and the columns in each table. Metadata is defined using a data definition language (DDL).
The metadata may include a Tables relation to define each table in the DBMS. The following provides an example of the Tables relation that contains a record for the Employee table:
Name
Number of Columns
Employee
7
In the above example, the Tables relation contains a record for each table in the DBMS. Each record contains two columns: Name and Number of Columns. The Name field identifies the name of a table and the Number of Columns field defines the number of columns in the table defined by the record.
To further illustrate, the metadata may contain a columnName table that identifies all of the columns defined in a table in the DBMS. The following provides an example of an entry in the columnName table for the First Name column in the Employee table:
Name
Table Name
Column No.
Column Type
Length
First Name
Employee
1
char
20
Each column in a table has a record in the columnName table. Each record in the columnName table has fields that further define the associated column. For example, the columnName table may include Name, Table Name, Column No., Column Type and Length columns or fields. In the above example, the columnName table contains a record that defines the First Name column as the first column in the Employee table and having a length of twenty characters.
Stored Procedures
To implement logic, a relational DBMS uses stored procedures implemented in a special language (e.g., Oracle's PL/SQL) that execute safely in the database server environment and that can be invoked using queries. However, the stored procedures that run in a relational DBMS environment do not provide mechanisms to dynamically distribute the procedures to clients so that they can execute at the client. Thus, the logic implemented by a stored procedure in the DBMS must be duplicated at the client. This duplication requires additional development costs. Further, any modifications or upgrades must be ported to each storage site thereby duplicating development efforts and increasing costs.
Object-Oriented DBMS
Like relational DBMS's, an object-oriented DBMS (OODBMS) stores an object's state on disk. An OODBMS typically uses a library implementation to retrieve an object. An OODBMS stores an object's state on disk and maps it into programming language objects. The state is mapped into the object such that the state can be retrieved from the DBMS and stored in the object's attributes when the object is instantiated. The object's class is defined in a compiled library that includes the object's behavior. The library is linked into the program from compiled libraries (typically written in C++) and used at run time to define the object's behavior. It is up to the database designer to distribute the class libraries to the client systems and keep these libraries up-to-date with the methods and objects stored in the database, if any. A database designer must distribute the class libraries to client systems and ensure that they remain current and synchronized across multiple sites with the state definition contained in the DBMS.
FIG. 2
provides an illustration of object retrieval using an OODBMS. DBMS
200
consists of schema
202
and data
206
. DBMS
200
is an OODBMS. Schema
202
comprises the metadata that defines the structure for data
206
. Data
206
contains application data such as that stored in the Employee table illustrated above. DBMS
200
does not store both state and behavior information such that the behavior can be retrieved into a client environment. DBMS
200
may encode behavior
Alam Hosain T.
Sun Microsystems Inc.
The Hecker Law Group
LandOfFree
Method and apparatus for coupling object state and behavior... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for coupling object state and behavior..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for coupling object state and behavior... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2550130