Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-05-06
2002-01-22
Breene, John (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
Reexamination Certificate
active
06341289
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates in general to the object oriented computing. More specifically, the present invention relates to the fields of object identity and partitioning, and mapping between the schema of an object oriented application program and the schema of a relational database.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time computers have become indispensable in many fields of human endeavor including engineering design, machine and process control, and information storage and access. In the early days of computers, companies such as banks, industry, and the government would purchase a single computer which satisfied their needs, but by the early 1950's many companies had multiple computers and the need to move data from one computer to another became apparent. At this time computer networks began being developed to allow computers to work together.
Computer networks are capable of performing jobs that no single computer could perform and they allow low cost personal computer systems to connect to larger systems to perform tasks that such low cost systems could not perform alone. In order for computer systems to cooperate in a network to perform some complex job, software must be developed which efficiently delegates parts of the chore or tasks to different computers in the network. One of the recent advances in the field of software development has been the emergence of object oriented programming technology.
The goal of using object-oriented programming is to create small, reusable sections of program code known as objects that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and reusable aspects of objects typically speeds development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a group of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
Using the unique features of an object oriented language, a programmer can write code to define software objects that model something in the real world. The software object may model the attributes or characteristics of the real-world object, and it many cases, may also model its behavior. For example, a programmer whose task it is to create an employee database program can create an object that models an employee and have certain attributes of a real employee, such as a name, an address, an employee number, and so forth. Exploiting the capabilities of object-oriented programming, a programmer could use the employee object in a manner that roughly corresponds to the way one would interact with a real employee. For example, the programmer could define the employee object to provide its address when the object is asked for that address.
Object oriented databases (OODBs) have been developed that are specially designed to facilitate storage and retrieval of objects. Objects that are stored in a data store are known as persistent objects because they “persist” after the program that created them has ceased executing.
Although object-oriented programming offers significant improvements over other programming types, program development still requires significant amounts of time and effort, especially if no preexisting objects are available as a starting point. Consequently, one approach has been to provide a program developer with a set of pre-defined, interconnected classes that create a set of objects. Such pre-defined classes and libraries are typically called object frameworks. Frameworks essentially provide a prefabricated structure for a working program by defining certain classes, class relationships, and methods that a programmer may easily use by appropriate subclassing to generate a new object-oriented program.
While object-oriented programming and the use of frameworks has greatly simplified the task of creating useful and efficient computer programs, some difficulties remain. One significant difficultly is in establishing effective integration between object-oriented programs and legacy or preexisting computer systems. As an example, integrating object-oriented programs with databases used to store large quantities of data.
A database is a structure in which a computer system may store a large quantity of data organized in a manner that facilitates efficient storage, search and retrieval. The most prevalent database model used today is known as a relationship database. In a relational database the data are organized in tables. Each data element is indexed by its row and column in the table. Each row, also known as a tuple, represents an entity that is useful or meaningful to the business or other database user, and each column in that row refers to a data element that defines a characteristic or attribute of that entity. For example, each row in a company's database of its employees may refer to a certain employee. One column may refer to an employee's name, another column to an employee's identification number, and another column to an employee's address.
Relational databases have thus been commonly used to facilitate the efficient storage and retrieval of data. These relational databases have been well suited to working with traditional procedural programming techniques. For example, a feature of most procedural programming languages allows a programmer to access an element of a table by specifying its row and column. Although a program would not necessarily access a database element using that feature of the programming language, the point is to note that relational schema and procedural programming share common concepts and programming philosophies.
In contrast, object-oriented programming techniques do not inherently interface smoothly with relational databases. For example, the concept of indexing a table of data elements by row and column is itself somewhat at odds with the object-oriented philosophy of handling an object in accordance with what it represents rather than how it is represented in a rigid data structure.
Despite the recent development of dedicated object-oriented databases, large amounts of data remains stored in existing legacy relational databases. Thus, there is a significant need to facilitate efficient interactions between these legacy relational databases and the newer object oriented systems. There has been specialized software developed to interface object-oriented software to relational databases. Such software typically includes a development tool, sometimes referred to as a scheme mapper, that allows a database programmer to map the legacy relational schema to a new object schema. Thus, although the objects are ultimately stored in the legacy relational format, the storage format is transparent to the application program which can access the objects using object oriented techniques.
One significant limitation in these systems is the difficultly in effectively partitioning the new object schema in a way that provides for increased database efficiency and reliability. Partitioning objects is the logical subdividing of objects into groups having a common characteristic. For example, “employee” objects could be partitioned into groups corresponding to their department. This allows for increased efficiencies because queries can specify what partition to search for objects in and avoid searching large amounts of unneeded objects. Additionally, partitioning can be used to promote security by providing a mechanism that can be used to limit access to certain types of objects. Using the employee object example again, partitioning to could be used to ensure that one person's access is limited to employee objects for a specific department.
When a new object oriented application is integrated with a new or legacy relational database system
Burroughs Tracy Kim
Lee Wilson Douglas
Luebbe Susan Carol
Breene John
Pham Linh M
Pitts S. Jared
Schmeiser Olsen & Watts
LandOfFree
Object identity and partitioning for user defined extents does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Object identity and partitioning for user defined extents, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Object identity and partitioning for user defined extents will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2875648