System and method for providing an object-oriented interface...

Data processing: database and file management or data structures – Database design – Data structure types

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C707S793000

Reexamination Certificate

active

06490581

ABSTRACT:

FIELD OF THE INVENTION
The field of the invention is databases, and in particular providing an object-oriented graphical user interface through which a relational database can be manipulated.
BACKGROUND OF THE INVENTION
Known graphical user interfaces to Relational Database Management Systems (“RDBMS”) can list of all the tables in the database. A “table,” which is also called a “relation,” is a collection of stored records. Each record consists of one or more fields or attributes. A table is referred to with a name (table name), and each attribute (field) in a table has a name and a type. For example, a collection of records that each stores an employee identifier, an employee name and an employee age can form a table. In this example, the table is called the EMPLOYEE table. The attribute names are “employee identifier,” “employee name,” and “employee age”. The attribute type identifies the type data that the attribute can hold (e.g. INTEGER, CHARACTER). The actual data stored in a field (e.g., John Smith or Maria Williams stored in an “employee name” attribute) is called a “attribute value” which is also known as “data.” A record is a correlated set of stored fields. For example, a stored employee identifier correlated with a stored employee name and a stored employee age is a “record.”
With RDBMS's graphical user interface, the attributes within each table are presented to the user, and the user can manipulate (e.g., access, modify, delete) the data in the database by entering one or more commands. A command or group of commands used to manipulate data is referred to as a query. The query can concern a single table or multiple tables. One of the most popular languages for making queries is “Structured Query Language” (“SQL”). An example of a SQL query given the above described table is:
SELECT Employee_Identifier, Employee_Name FROM EMPLOYEE WHERE Employee_Identifier>1000
The above query will return a set of records including employee identifiers greater than 1000 and employee names associated with those identifiers. Information about an application is stored in a number of tables in a given database. There are guidelines to follow for distributing the information among many tables. Usually, the pieces of data that are closely related (one to one relationship, such as first name, last name, sex, social security number, and birthday) go together in a table. The database schema is a list of all the tables and their attributes.
To retrieve information which are scattered among multiple tables, an operation known as JOIN has to be performed. The JOIN operation joins together two tables on the basis of common values in a common attribute. For example, suppose the above described Employee table contains, “Employee identifier”, “Employee name”, and “Employee age” and that a LOCATION table includes the attributes “primary employee office location,” “secondary employee office location,” “employee telephone extension,” and “employee identifier”. The EMPLOYEE table can be JOINed with the LOCATION table on the shared attribute (“key”) “Employee identifier” to relate an employee with his/her locations. The JOIN operation results in the attributes “employee identifier”, “employee name”, “employee age”, “primary employee office location”, “secondary employee office location”, and “employee telephone extension”. The “employee identifier” is a primary key in table EMPLOYEE, in that “employee identifier” uniquely identifies a row of attributes in the EMPLOYEE table. The “employee identifier” is a foreign key in table LOCATION, in that it references the primary key in EMPLOYEE. Getting other information about an employee from the various tables in the RDB is a non-trivial exercise requiring the execution of many-way JOINs (JOINing multiple tables).
When a user wants to perform a multiple table query, a user often needs to have an intimate knowledge of both the database schema and a query language, e.g., SQL. Database schema can be complex. For example, in addition to the EMPLOYEE table and the LOCATION table described above, the database may include additional tables holding information about salary, employment status, employee's education, and employee's performance records. To perform a query, one has to know exactly how the information in one table is related to another table and what are the primary and foreign keys. Furthermore, SQL can require a substantial amount of time and effort to master. In most known systems, a user is disadvantageously required to be well acquainted with the schema of the database and the SQL language to perform even a simple query, such as determining the locations of a subset of employees. More complex operations on the database require even higher levels of knowledge and skill with SQL. This disadvantageously reduces the usefulness of a database to potential users who have neither the time nor the inclination to learn the schema and/or SQL.
In one paradigm, an entity that manipulates data is represented as an abstraction called an “object.” This object-oriented paradigm is described in James Rumbaugh,
Object-Oriented Modeling and Design
, Prentice Hall, 1991. An object includes a description of a structure of data, ways in which the object manipulates data, and the object's relationship with other objects. A tool (called “OSP”) for mapping an object model to a relational database schema is described in co-pending U.S. application Ser. No. 09/312,798, “System and Method for Mapping a Relational Database to an Object-Oriented Paradigm”, filed May 17, 1999. OSP enables an application developer to view a relational database in terms of objects, and permits the developer to manipulate the data in the database using object-oriented programming languages, such as C++. While OSP facilitates database manipulation for computer programming experts, it can be difficult to use for users who are not expert programmers, or else not programmers at all. Thus, the OSP tool alone does not address the issue of facilitating searches of relational databases by those less savvy in programming.
SUMMARY OF THE INVENTION
An embodiment of the present invention provides a graphical, object-oriented view of information stored in a relational database. An embodiment of the present invention can advantageously be published on the World Wide Web on the Internet and/or an Intranet. Users with no knowledge of a database query language or the layout of the data in the database can advantageously perform sophisticated queries with just a few mouse clicks, in accordance with an embodiment of the present invention.
In accordance with an embodiment of the present invention, an object model is mapped to a database schema, e.g., using a graphical user interface or a text editor. Mapping an object model onto a database schema means representing the relationship among the tables in the database in terms of objects. In turn the present invention provides a user friendly representation of the object model. For example, the present invention can present the object model on a web site. The web site can advantageously be deployed on the Internet, an Intranet, or even be represented only locally on a user's computer. Having the information graphically represented as objects advantageously obviates the need to know the database schema for performing any query. An embodiment of the present invention advantageously hides the complexity of the database schema using the object model, and transparently to the user works out the details of the mapping between the object model and the database schema. In this way, a user is advantageously provided with an intuitive and easy to understand representation of the data in the database.
In an object model in accordance with an embodiment of the present invention, an object may have various traits or characteristics. For example, an object may be capable of inheriting a property from another object. For example, given the class human every object in the class can be said to inherit the properties of another class, mammal. (That is,

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

System and method for providing an object-oriented interface... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with System and method for providing an object-oriented interface..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for providing an object-oriented interface... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2958266

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.