Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-04-22
2003-10-07
Kindred, Alford (Department: 2172)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C715S252000
Reexamination Certificate
active
06631386
ABSTRACT:
FIELD OF THE INVENTION
The invention relates generally to the field of digital data processing systems, and more particularly to data base management systems (DBMS's). The invention specifically provides a database version control subsystem for use in connection with a DBMS to facilitate versioning of a database.
BACKGROUND OF THE INVENTION
Databases are generally used to store large amounts of information in a structured manner for subsequent retrieval and processing. Databases, in turn, are managed by data base management systems (DBMS's). A DBMS allows one to submit a query identifying a number of criteria for the, information that is to be retrieved from the database. Queries may be submitted by a user, in which case the DBMS can return the subset of information stored in the database that conforms to that identified by the query for, for example, display to the user. Alternatively, queries may be submitted by an application program, in which case the DBMS can return the information to the application program for processing. The DBMS can also receive information from an user or application program for storage in the database, and the DBMS can, after receiving the information, use the information to update the database.
In one type of DBMS, generally referred to as a relational database system, information is stored in tables, with each table comprising a two-dimensional array organized a plurality of rows and columns. Information stored in a relational database system is in the form of records, with each record comprising one or more fields each associated with an attribute. For example, an organization such as a company or a government agency might maintain a database identifying its employees, and in that case each record may be associated with each employee, with attributes including information such as an employee number, name, address, department, office location, salary, date of hire, tax information and other information that the organization would deem useful in managing its employees. Similarly, a member ship organization such-as a club or an association may maintain a database identifying its members, and attributes may include information such as a member number, name, address, membership classification if the organization has various classes of membership, renewal data, and other information that the organization would deem useful. In a table in a relational database system, the attributes associated with the records are stored in the same order, so that for all records the “j-th” field will be associated with the same attribute. Generally, information from one or a combination of predetermined ones of the attributes of each record will be selected to comprise a record “key,” whose value is used to uniquely identify the respective record.
Database queries issued by an user or an application program can be based on any attribute, including but not limited to the attributes selected to define the record keys. A query can, for example, ask for information from a record or records having a particular key value, set of key values or range of key values, in which case the DBMS will return information from the records, if any, whose key value or values correspond to those set forth in the query. Similarly, a query can ask for information from records based on criteria relating to the other attributes, in which case the, DBMS will return information from the records, if any, whose attributes contain the value or values that correspond to those set forth in the query. In addition, a query can ask the DBMS to establish a new record, in which case the DBMS will add a row to the table in which information for the record can be stored; the information to be stored in the new record may be provided with the query or in a later query. A query can ask the DBMS to update one or more records, in which case the query will identify the records to be updated, in a manner similar to that described above for a retrieval, and the information to be used in the update; in response to such a query, the DBMS will use the information contained in the query to update the identified records. Alternatively, a query can ask the DBMS to delete one or more re cords, in which case the DBMS will delete the records; the records to be deleted can be identified in the query in a similar manner to that described above for a retrieval.
In many kinds of applications, it is desirable to allow a user to make use of one or more tables, or portions thereof, of a database as they exist at a particular point in time and update the information therein, with the updates not being visible to other users while the information is being updated. Currently, that is accomplished by means of a check-out/check-in scheme. In such a scheme, a user “checks out” the database table or tables, or portions thereof, (hereinafter “tables”), that he or she wishes to use, after which the DBMS makes a copy of the tables that have been checked out, from the original “live” database. Thereafter, the user can operate with the copy, updating the information in his or her copy as appropriate. While the one user is operating with his or her copy, other users can use the live database, updating the information therein, including information in the tables that have been checked out. When the user has finished, he or she can check the checked-out portion back into the database, in the process updating the live database as necessary. For example, for a database that is used in connection with a computer-assisted design project, a user working on one aspect of a design may wish to check out a portion of the database reflecting that aspect at one point in the design process, make changes to the design, and, if and when he or she is satisfied with the changes, update the database with the changes. As a specific example, if the live database is used in connection with design of an airport, a user may which to check out a portion of the database reflecting the design of a terminal or a particular facility of a terminal, such as electric power distribution, water distribution, heating, ventilation and air conditioning (“HVAC”), or other systems. Similarly, for a database relating to structure of a company, a user who wishes to re-structure a portion of the company may wish to check out a portion of the database reflecting the portion that he or she wishes to restructure.
There are a number of deficiencies with check-out/check-in schemes. For example, since, in check-out/check-in schemes, copies are made of the live database, a relatively large amount of storage may be required, particularly if a number of users have checked out tables from the database. In addition, check-out/check-in schemes typically do not allow tables to be checked out from a checked-out copy, that is, they do not provide a hierarchical check-out scheme. Using the above example in which a database is used in connection with design of an airport, if a user checks out a portion of the live database relating to a terminal, check-out/check-in arrangements do not allow, a user to thereafter check out a portion of the database relating to a particular facility of the terminal from the checked-out portion. Accordingly, if a user wishes to check out tables from a checked out copy, he or she will first need to check the copy back in again.
In addition, typically in a check-out/check in scheme, when a user modifies a record in the a table of a live database after the table has been checked-out therefrom and before it is checked back in, a conflict will exist as between the copy of the record in the checked-out copy and the copy of the record in the live database. In that case, the conflict will not be discovered until the checked-out copy is checked back in again. Typically, a user who is using the checked-out copy will not discover that a record has been modified in the live database, and, similarly, the user who is using the live database will not discover that a record has been modified in the checked-out copy, until the checked out copy is checked in. As part of the chec
Arun Gopalan
Banerjee Jayanta
Vasudevan Ramesh
Ditthavong & Carlson P.C.
Kindred Alford
Oracle Corp.
LandOfFree
Database version control subsystem and method for use with... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Database version control subsystem and method for use with..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Database version control subsystem and method for use with... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3116771