Back to EveryPatent.com
United States Patent |
6,119,126
|
Yee
,   et al.
|
September 12, 2000
|
Object-relational query builder which determines existence of structures
from information loaded from the server and cached locally on the
client computing system
Abstract
One embodiment of the present invention provides a method for constructing
a query for an object-relational database. This method displays at least
part of a schema for the object-relational database to a user in a
graphical representation. Next, the method allows the user to perform
graphical manipulations on the schema. The method then generates a query
based upon the schema and the graphical manipulations, and this query is
sent to the object-relational database. Another embodiment of the present
invention provides a method for processing an object-relational query for
transmission from a client to an object-relational database server. This
method receives the query at the client, and parses the query to determine
which object-relational structures the query is attempting to access. The
method then determines from data dictionary information, loaded from the
object-relational database server and cached locally on the client, if the
object-relational structures the query is attempting to access exist in
the object-relational database server. If they do not exist, the method
indicates an error condition. Yet another embodiment of the present
invention provides a method for displaying objects defined within an
object-oriented programming system that are stored in a relational table
structure. This method displays a table of objects, so that a first object
in the table is represented by an identifier. The method next receives a
command from a user to provide a more-detailed display of the first
object. In response to this command, the method retrieves attributes of
the first object from a data store, and displays an expanded
representation of the first object by displaying the attributes.
Inventors:
|
Yee; David R. (Pacifica, CA);
Gaunce; David Brennan (Mountain View, CA)
|
Assignee:
|
Oracle Corporation (Redwood Shores, CA)
|
Appl. No.:
|
087122 |
Filed:
|
May 29, 1998 |
Current U.S. Class: |
707/3; 707/6; 707/10; 707/103R |
Intern'l Class: |
G06F 017/00 |
Field of Search: |
707/3,4,5,6,7,10,101,102,103,200,201,202
709/216,213
345/302
|
References Cited
U.S. Patent Documents
5634053 | May., 1997 | Noble et al. | 707/4.
|
5802524 | Sep., 1998 | Flowers et al. | 707/103.
|
5915249 | Jun., 1999 | Spencer | 707/10.
|
6023684 | Feb., 2000 | Pearson | 707/10.
|
Other References
Hu et al., Design and implementation of an object-relational multimedia
database, ICICS, Proceedings of International Onvference, vol. 1, pp.
573-577, 1997.
Loeser et al., iWebDB-Web site administration based on object-relational
database technology, IDEAS, International Symposium Proceedings p. 92-91,
1999.
More et al., Extended collective I/O for efficient retrieval of large
objects, HIPC, 5th International Conference, pp. 359-366, 1998.
Wang et al., Parallel/distributed simulation with the COMPOSE
object-relational database, ASSET, Proceedings, IEEE Workshop, pp.
162-165, 1997.
|
Primary Examiner: Black; Thomas G.
Assistant Examiner: Jung; David
Attorney, Agent or Firm: Park & Vaughan LLP
Claims
What is claimed is:
1. A method for processing a query for transmission from a client computing
system to an object-relational database server, comprising:
receiving the query at the client computing system;
parsing the query to determine which object-relational structures the query
is attempting to access;
determining, from data dictionary information loaded from the
object-relational database server and cached locally on the client
computing system, if the object-relational structures the query is
attempting to access exist in the object-relational database server;
if the object-relational structures do not exist on the object-relational
database server, indicating an error condition; and
if the object-relational structures exist on the object-relational database
server, sending the query to the object-relational database server.
2. The method of claim 1, further comprising, if the object-relational
structures exist on the object-relational database server:
displaying the query to a user; and
if a command is received from the user to send the query, sending the query
to the object-relational database server.
3. The method of claim 1, further comprising:
displaying the query to a user at the client computing system; and
allowing the user to modify the query through manipulations of graphical
objects representing the query.
4. The method of claim 3, wherein allowing the user to modify the query
includes allowing the user to add new tables to the query.
5. The method of claim 3, wherein allowing the user to modify the query
includes allowing the user to remove tables from the query.
6. The method of claim 3, wherein allowing the user to modify the query
includes allowing the user to type the query in manually.
7. The method of claim 3, wherein allowing the user to modify the query
includes allowing the user to paste in the query from a clipboard.
8. The method of claim 3, wherein allowing the user to modify the query
includes allowing the user to select different columns for the query.
9. The method of claim 3, wherein allowing the user to modify the query
includes allowing the user to modify conditions of the query.
10. The method of claim 1, wherein receiving the query includes importing
the query from a file containing the query.
11. The method of claim 1, wherein receiving the query comprises:
receiving, at the client computing system, a command in the form of a
manipulation of a graphical object in a graphical user interface from a
user of the client computing system; and
converting the command into a corresponding object-relational database
query.
12. The method of claim 11, wherein the graphical object includes a visual
presentation of data dictionary elements.
13. The method of claim 1, wherein receiving the query includes receiving
manually typed input from a user.
14. The method of claim 1, wherein indicating the error condition includes
informing a user that the query is not valid.
15. The method of claim 1, wherein determining if the object-relational
structures the query is attempting to access exist in the
object-relational database server further comprises:
determining that the query includes a reference to an attribute of an
object from a table; and
using the data dictionary information to expand a type for the object to
verify that the attribute exists in the object.
16. A method for processing a query for transmission from a client
computing system to an object-relational database server, comprising:
receiving the query from a user of the client computing system;
displaying the query to the user of the client computing system through a
graphical user interface;
allowing the user to modify the query through manipulations of graphical
objects representing the query;
parsing the query to determine which object-relational structures the query
is attempting to access;
determining, from data dictionary information loaded from the
object-relational database server and cached locally on the client
computing system, if the object-relational structures the query is
attempting to access exist in the object-relational database server;
if the object-relational structures do not exist on the object-relational
database server, indicating an error condition; and
if the object-relational structures exist on the object-relational database
server, sending the query to the object-relational database server.
17. An apparatus for processing a query for transmission to an
object-relational database server, comprising:
a client computing system;
a parser, within the client computing system, that parses the query to
determine which object-relational structures the query is attempting to
access;
a query checking mechanism, within the client computing system, that
determines, from data dictionary information loaded from the
object-relational database server and cached locally on the client
computing system, if the object-relational structures the query is
attempting to access exist in the object-relational database server;
an error handler, within the client computing system, that indicates an
error if the object-relational structures do not exist on the
object-relational database server; and
a communication mechanism, within the client computing system, that is
configured to,
send the query to the object-relational database server if the
object-relational structures exist on the object-relational database
server, and to
indicate an error condition if the object-relational structures do not
exist on the object-relational database server.
18. The apparatus of claim 17, further comprising a display mechanism,
within the client computing system, that displays the query to a user.
19. The apparatus of claim 17, further comprising a query editing
mechanism, within the client computing system, that allows a user to edit
the query through manipulations of graphical objects representing the
query.
20. The apparatus of claim 19, wherein the query editing mechanism is
configured to allow the user to add new tables to the query.
21. The apparatus of claim 19, wherein the query editing mechanism is
configured to allow the user to remove tables from the query.
22. The apparatus of claim 19, wherein the query editing mechanism is
configured to allow the user to remove tables from the query.
23. The apparatus of claim 19, wherein the query editing mechanism is
configured to allow the user to type the query in manually.
24. The apparatus of claim 19, wherein the query editing mechanism is
configured to allow the user to paste in the query from a clipboard.
25. The apparatus of claim 19, wherein the query editing mechanism is
configured to allow the user to select different columns for the query.
26. The apparatus of claim 19, wherein the query editing mechanism is
configured to allow the user to modify conditions of the query.
27. The apparatus of claim 17, further comprising a query receiving
mechanism that receives the query from a file containing the query.
28. The apparatus of claim 17, further comprising a query receiving
mechanism that receives a command in the form of a manipulation of a
graphical object in a graphical user interface from a user of the client
computing system, and converts the command into a corresponding
object-relational database query.
29. The apparatus of claim 28, wherein the graphical object includes a
visual presentation of data dictionary elements.
30. The apparatus of claim 17, further comprising a query receiving
mechanism that receives a manually typed query.
31. The apparatus of claim 17, wherein the query checking mechanism is
configured to determine that the query includes a reference to an
attribute of an object from a table, and to use the data dictionary
information to expand a type for the object to verify that the attribute
exists in the object.
32. A program storage device storing instructions that when executed by a
computer perform a method for processing a query for transmission from a
client computing system to an object-relational database server,
comprising:
receiving the query at the client computing system;
parsing the query to determine which object-relational structures the query
is attempting to access;
determining, from data dictionary information loaded from the
object-relational database server and cached locally on the client
computing system, if the object-relational structures the query is
attempting to access exist in the object-relational database server;
if the object-relational structures do not exist on the object-relational
database server, indicating an error condition; and
if the object-relational structures exist on the object-relational database
server, sending the query to the object-relational database server.
Description
BACKGROUND
1. Field of the Invention
The present invention relates to relational database systems, and more
particularly to a relational database system that facilitates persistent
storage of "objects" from an object-oriented programming system within a
tabular-relational framework. The present invention additionally provides
a graphical user interface for viewing and performing operations on
object-relational data.
2. Related Art
As object-oriented programming systems are increasingly used by computer
programmers, numerous software tools and systems have been adapted to
handle objects and their related methods. However, existing relational
database systems are not designed to accommodate and manipulate objects,
which are typically composed of attributes, some of which may reference
other objects. For example, a conventional relational database system
stores data in tables, which comprise rows and columns of entries
containing scalar values. At present, it is not possible to store objects
in these tables because the entries in these tables are not designed to
accommodate objects.
Additionally, a number of graphical tools are presently used to manipulate
and view database structures such as tables. However, existing tools are
not designed to manipulate and view database structures that store
objects. Existing tools only allow a user to view and manipulate scalar
values stored in tables; they do not allow the constituent attributes of
an object to be viewed and manipulated, nor do they allow objects
referenced within other objects to be retrieved for viewing and
manipulation.
Hence, what is needed is a database system that facilitates persistent
storage of objects. Additionally, what is needed are database tools that
allow objects stored within a database system to be easily viewed and
manipulated.
Another issue in viewing stored objects in a database system is the fact
that many database systems are designed to work within a client-server
distributed system. Typically, a client computer system accesses
information contained in a database on a server computer system. In order
to achieve a reasonable level of performance in such a system, it is
desirable to minimize the number of communications that take place between
client and server computer systems across the communication network. These
communications are typically time-consuming and can potentially clog up
the communication network. To this end, some existing distributed database
systems attempt to minimize the number of communications that take place
by first examining a query on the client to ensure the query properly
references existing database structures on the server before sending the
query to the server. If the query does not properly reference existing
database structures on the server, the query is not sent to the server.
Instead, a user on the client computer system is asked to correct the
query or enter a new query. In this way, unnecessary communications from
client to server computer systems are avoided. However, these distributed
database systems are not designed to accommodate objects. In particular,
these distributed database systems are not designed to determine whether a
query properly references object data stored on the server.
Hence, what is needed is a distributed database system that can determine
whether a query properly references object data stored in database
structures on a server before the query is sent to the server.
SUMMARY
One embodiment of the present invention provides a method for constructing
a query for an object-relational database. This method displays at least
part of a schema for the object-relational database to a user in a
graphical representation. Next, the method allows the user to perform
graphical manipulations on the schema. The method then generates a query
based upon the schema and the graphical manipulations, and this query is
sent to the object-relational database.
Another embodiment of the present invention provides a method for
processing an object-relational query for transmission from a client to an
object-relational database server. This method receives the query at the
client, and parses the query to determine which object-relational
structures the query is attempting to access. The method then determines
from data dictionary information loaded from the object-relational
database server and cached locally on the client, if the object-relational
structures the query is attempting to access exist in the
object-relational database server. If not, the method indicates an error
condition.
In a variation on this embodiment, if the object-relational structures
exist on the object-relational database server, the method sends the query
to the object-relational database server. In another variation, if the
object-relational structures exist on the object-relational database
server, the method displays the query to a user, and if a command is
received from the user to send the query, the client sends the query to
the object-relational database server.
Yet another variation includes displaying the query to a user at the client
computing system, and allowing the user to modify the query through
manipulations of graphical objects representing the query. These
modifications may include adding new tables to the query, selecting
different columns for the query, and modifying conditions of the query.
Yet another embodiment of the present invention provides a method for
displaying objects defined within an object-oriented programming system
that are stored in a relational table structure. This method displays a
table of objects, so that a first object in the table is represented by an
identifier. The method next receives a command from a user to provide a
more-detailed display of the first object. In response to this command,
the method retrieves attributes of the first object from a data store, and
displays an expanded representation of the first object by displaying the
attributes.
In a variation on this embodiment, displaying the expanded representation
of the first object includes displaying an expanded representation of the
entire first table.
Another variation includes receiving a command from the user to provide a
more-detailed display of an attribute of the first object. If this
attribute represents a second object, the method retrieves attributes of
the second object from the data store, and displays an expanded
representation of the second object by displaying the attributes of the
second object.
In another variation, retrieving the attributes of the first object from
the data store includes retrieving the attributes of the first object from
an object table. This object table contains a collection of objects that
can be referenced from other tables.
DESCRIPTION OF THE FIGURES
FIG. 1 illustrates the structure of a distributed database system in
accordance with an embodiment of the present invention.
FIG. 2 illustrates the internal structure of client 100 from FIG. 1 in
accordance with an embodiment of the present invention.
FIG. 3 illustrates the internal structure of backend 204 from FIG. 2 in
accordance with an embodiment of the present invention.
FIG. 4 is a flow chart illustrating operations related to processing a
query in accordance with an embodiment of the present invention.
FIG. 5 illustrates how a graphical representation of an object entry in a
table can be expanded in accordance with an embodiment of the present
invention.
DEFINITIONS
Object-relational database--a database including objects defined within an
object-oriented programming system that are stored in a relational table
structure.
DETAILED DESCRIPTION OF THE INVENTION
The following description is presented to enable any person skilled in the
art to make and use the invention, and is provided in the context of a
particular application and its requirements. Various modifications to the
disclosed embodiments will be readily apparent to those skilled in the
art, and the general principles defined herein may be applied to other
embodiments and applications without departing from the spirit and scope
of the present invention. Thus, the present invention is not intended to
be limited to the embodiments shown, but is to be accorded the widest
scope consistent with the principles and features disclosed herein. For
example, many of the components and operations described below can be
implemented using computer hardware, or alternatively, using computer
software.
Description of Database System
FIG. 1 illustrates the structure of a distributed database system in
accordance with an embodiment of the present invention. This system
includes clients 100 and 110, and server 130, which are coupled together
through a network 120. Clients 100 and 110 can be any type of node on a
computer network with computational capability and including a mechanism
for communicating across network 120. This includes, but is not limited to
personal computers and workstations. Server 130 can be any node on a
computer network including computational capability and data storage
capability as well as a mechanism for servicing client requests for
computational or data storage resources. Network 120 may be any
communication channel through which computer systems can communicate. This
includes, but is not limited to, local area networks, such as an Ethernet
or Token ring, and wide area networks, such as the Internet.
Clients 100 and 110 include query builders 102 and 112, respectively. Query
builders 102 and 112 are computational resources that allow users of
clients 100 and 110 to form and/or manipulate queries to be sent over
network 120 to server 130. Many of the features of the present invention
reside within query builders 102 and 112.
Server 130 includes listener 131, which is a process that listens on
network 120 for requests from clients 100 and 110 to server 130. Server
130 additionally includes processes 132, 133 and 134, which receive and
process queries from clients 100 and 110. In one embodiment, these queries
are in the form of SQL commands. Processes 132, 133 and 134 use parser 135
to parse queries from clients 100 and 110 before applying the queries to
database 136. In the illustrated embodiment, parser 135 includes resources
to parse queries with object-relational expressions.
Database 136 may be any type of system that facilitates persistent storage
of data. This includes, but is not limited to, relational database systems
and hierarchical database systems. Database 136 includes data dictionary
137, which includes information about what data exists within database 136
and how this data is stored. More particularly, in one embodiment, data
dictionary 137 includes schema information describing the structure of
data stored within database 136.
The system illustrated in FIG. 1 operates as follows. A user of client 100
forms a query by manipulating query builder 102. Query builder 102 allows
the user to form and graphically manipulate the query until the user
decides to send the query to server 130 across network 120. At server 130,
listener 131 receives the query and passes it to a process, such as
process 132. Process 132 parses the query using parser 135, and this
parsed query is applied to database 136. In one embodiment of the present
invention, a representation of the parsed query is compared against
information from data dictionary 137 acquired from database 136 to verify
that the query is accessing a valid structure within database 136 before
the query is applied to database 136. Finally, after the query is
processed, data values can be returned through network 120 to client 100
so that the user can view the results of the query.
Description of Client Software Architecture
FIG. 2 illustrates the internal structure of client 100 from FIG. 1 in
accordance with an embodiment of the present invention. Client 100
includes technology stack 200, which includes various layers used to
implement a client of a database system. Technology stack 200 primarily
includes query builder 102 and client database access programmatic
interfaces (client database API) 206.
As illustrated in FIG. 2, query builder 102 includes user interface 202,
which is coupled to backend 204. User interface 202 manages the
presentation of queries and database structures to a user of client 100.
In one embodiment, user interface 202 includes a graphical user interface,
which allows a user of the client to graphically view and manipulate
queries and data for database 136 from FIG. 1. User interface 202
additionally calls functions from toolkit 205 to manipulate and display
objects and other database structures to the user. Toolkit 205 generally
includes portable functions to manipulate and display objects on client
100. Backend 204 manages the internal representation of queries and the
database schema and is described in more detail below with reference to
FIG. 3.
Client database API 206 exists below query builder 102. It includes support
files and other resources for communication with database 136 on server
130. Client database API 206 includes network connection 208, which
facilitates communications for queries sent across network 120 to server
130.
Description of Back End
FIG. 3 illustrates the internal structure of backend 204 from FIG. 2 in
accordance with an embodiment of the present invention. Backend 204
includes application layer 310, software communication bus layer 320,
query representation layer 330 and schema representation layer 340.
Application layer 310 communicates with user interface 202 and manages one
or more documents on a display. This involves managing and manipulating
data that represents what is being presented on the display.
Below application layer 310 is software communication bus layer 320, which
manages communication between user interface 202 and backend 204. More
specifically, software communication bus layer 320 manages caching and
other communication details that user interface 202 does not need to know
about. Software communication bus layer 320 provides message-based
abstraction to clearly separate application layer 310 from query
representation layer 330.
Software communication bus layer 320 sits above query representation layer
330. Query representation layer 330 keeps track of information related to
queries. This includes information about what data sources are represented
in a query, what fields are displayed, what conditions are used to
restrict result sets and how fields are ordered. Query representation
layer 330 also knows about data types. In a conventional database system,
data types are scalar values. However, in an object-relational database
system the types can be objects. Query representation layer 330 sits above
schema representation layer 340. Schema representation layer 340 keeps
track of information related to the database schema.
Query representation layer 330 includes query governor 332, query validator
334, parser 336 and reformulator 338. As illustrated, query governor 332
sits on top of and controls the operations of query validator 224, parser
336 and reformulator 338. Query governor 332 manages a parsed
representation of a query and some persistent display characteristics.
Query governor 332 additionally manages methods for manipulating parsed
representations including constructing (parsing), reformulation into
object-oriented SQL text and validation. Query validator 324 manages a
lower-level representation of the query and understands the interface to
schema representation layer 340. Parser 336 understands how to parse a
query into lexical elements. (In one embodiment, it also understands how
to reconstruct a query out of lexical elements.) Reformulator 338 can
rebuild SQL statements from an internal representation of a query.
Schema representation layer 340 includes schema governor 342, schema
namespace 344 and connection/fetch unit 346. As illustrated, schema
governor 342 sits on top of and controls the operations of schema
namespace 344 and connection/fetch unit 346. Schema governor 342 maintains
cached client-side representations of a Relational Database Management
System's (RDBMS's) data dictionary information, and provides methods for
acquiring information from the cache so that query representation layer
330 does not need to know how to interface with client database API 206.
Schema governor 342 knows how tables are related to each other. It knows
what fields are associated with each table. It knows about object types as
well as relational information. Query validator 334, parser 336 and
reformulator 338 communicate with schema governor 342 to retrieve database
schema information.
Schema namespace 344 stores field and type information in an access
structure. In one embodiment, this access structure is a hash table that
facilitates rapid retrieval of the field and type information, as well as
information about data accessing privileges.
Connection/fetch unit 346 handles connections to a database system as well
as fetches from the database system. In the illustrated embodiment,
connection/fetch unit 346 communicates with client database API 206 from
FIG. 2.
As illustrated in FIG. 2, software communication bus layer 320, query
representation layer 330 and schema representation layer 340 utilize
workbench 348. Workbench 348 includes general programming utilities. For
example, workbench 348 may include utilities to implement list and hash
tables and utilities to manage memory.
Description of Query Manipulation
FIG. 4 is a flow chart illustrating operations related to processing a
query in accordance with an embodiment of the present invention. The
system starts in state 400 and proceeds to state 402. In state 402, the
system receives a query. The query can be received from a number of
sources. In one embodiment, a user may type in a query, the user may paste
in a query from a clipboard or the query may be retrieved from a file.
Next, the system proceeds to state 404. In state 404, parser 336 (from
FIG. 3) begins to parse the query. More specifically, the parser 336
operates on the "from" clause of the query. The system next proceeds to
state 406. In state 406, the schema governor 342 (from FIG. 3) loads type
and table information for the types and tables implicated by the query. In
one embodiment, this information is retrieved from database 136 on server
130 (from FIG. 1) and is cached locally on client 100. This reduces
unnecessary communications across network 120 to retrieve schema
information.
The system next proceeds to states 408, 410 and 412. In these three states,
schema governor 342 (from FIG. 3) handles three different types of table
entries; state 408 handles nested objects; state 410 handles referenced
objects; and state 412 handles scalar values. Nested objects are objects
whose attributes are stored directly in a table structure. Referenced
objects are objects stored in an object table that are "referenced" by a
pointer, or some other type of index, from another location inside of
another object or inside of a relational table. Scalar values are simply
conventional data values (such as integers or characters) that are stored
in table structures. In state 408, the system expands nested objects into
their constituent attributes. In contrast, in state 410 referenced objects
are not expanded. This is because referenced objects may refer to other
objects in such a way as to create a recursive structure that may be
impossible to fully expand. In state 412, conventional scalar types are
directly included in tables. The system next proceeds to state 414.
In state 414, the system stores table and type information in schema
namespace 344 (from FIG. 3). The system next proceeds to state 416. In
state 416, query representation layer 330 begins to parse the "where"
clause and the "select" clause to determine columns referenced by the
query. It does so in order to validate the SQL query being parsed. This
validation ensures that the query will validly access an existing data
storage structure within database 136. This validation on the client side
of the database system prevents unnecessary communications across network
120 for invalid queries. The system next proceeds to state 418. In state
418, the system stores a representation of the query in an internal form.
The system next proceeds to state 420. In state 420, the system displays
the resulting query to a user of client 100. This display process involves
software communication bus layer 320 and application layer 310 as well as
user interface 202. From state 420, the system can proceed to any of
states 422, 424, 426, 428 and 432 under user control.
States 422, 424 and 426 allow a user to modify the query by graphically
manipulating a representation of the query on a graphical display. These
operations are controlled by user interface 202 and application layer 310.
(Note that these operations are representative, but not exclusive.) In
state 422, the system allows the user to add new tables to the query. The
system next returns to state 404 because the data source (or from clause)
needs to be reparsed. In state 424, the system allows the user to select
different columns. Another operation (not shown) allows a user to enter
formulaic expressions that are treated like columns. For example, "base
salary+100," or simply a number, such as "100."The system next returns to
state 420 to display the resulting query with the different columns
selected. In state 426, the system allows the user to modify conditions
(or the "where" clause) of the query. The system then returns to state 416
to reparse the "where" clause.
Alternatively, from state 420 the user can command the system to proceed to
state 428. In state 428, the system starts the process of saving or
showing the resulting SQL statements that are generated from the graphical
representation. In order to do so, the system proceeds to state 430 in
which reformulator 338 (from FIG. 3) generates SQL statements from the
internal representation of the query. From state 430, the system next
either proceeds to state 433 or state 420. In state 433, the system saves
the SQL statements (possibly to a file) before proceeding to end state
434. In state 420 the system displays the resulting query the user.
However, note, that in this case, the query is displayed as SQL
statements, not in a graphical representation.
From state 420, the system may also proceed to state 432 in which the query
is sent across network 120 to server 130 to be processed. The decision to
send the query can be made automatically by the system, or alternatively,
can be made by the user who commands the system to send the query. The
system next proceeds to state 434, which is an end state.
Description of Graphical Representation of Object Relational Tables
FIG. 5 illustrates how a graphical representation of an object in a table
can be expanded in accordance with an embodiment of the present invention.
The graphical representation illustrated in FIG. 5 includes a table 500,
which includes a number of entries including, employee.sub.-- A 510,
employee.sub.-- B 520 and employee.sub.-- C 520. These entries are objects
containing data for employees of a company. As is illustrated in FIG. 5,
user interface 202 (from FIG. 2) allows a user to select a table entry,
such as employee.sub.-- B 520, using a pointing device, such as a computer
mouse. When the entry is selected, the system retrieves the attributes for
the object from the database and displays an expanded representation of
the entry including the attributes. In the illustrated example,
employee.sub.-- B 520 is expanded into its three constituent attributes,
employee.sub.-- B.number 522, employee.sub.-- B.address 522 and
employee.sub.-- B.salary 524.
Note that an attribute may itself be an object or a reference to an object.
If this is the case, the attribute can be selected by the user for further
expansion, and the system will expand the object referred to by the
attribute into its own attributes. This feature allows a user to navigate
through an interconnected mesh of objects that refer to each other.
The foregoing descriptions of embodiments of the invention have been
presented for purposes of illustration and description only. They are not
intended to be exhaustive or to limit the invention to the forms
disclosed. Accordingly, many modifications and variations will be apparent
to practitioners skilled in the art.
Top