 |
Claims  |
|
|
What is claimed is:
1. In a computer system, a method for generating a hypertext report, the
method comprising:
receiving input specifying a first report, said first report being based on
information taken from a first subset of a set of relational database
tables, said set of relational database tables including records that
provide access to stored information; said first report being a design
document separate from said set of relational database tables and
specifying display of a plurality of information items associated with
records in said first subset of tables, said information items being
differentiated by being associated with records having different values of
a particular field in said first subset of tables;
receiving input specifying a second report, said second report being based
on information taken from a second subset of said set of relational
database tables, said second report being a design document separate from
said set of relational database tables and specifying display of
information associated with records in said second subset of tables;
combing the information items from said first report and the information
from said second report into the hypertext report; and
if information in said first report is relatable to information in said
second report by virtue of at least one of said second subset of tables
having the particular field, generating at least one hypertext link and
placing said at least one hypertext link in the hypertext report for
cross-referencing relatable information in the two reports, the hypertext
report, when displayed to a user, allowing the user to navigate between
related information at different locations in the hypertext report by
invoking said at least one hypertext link.
2. The method of claim 1, wherein at least one of said reports includes a
one-to-many relation.
3. The method of claim 1, wherein at least one of said reports includes a
many-to-one relation.
4. The method of claim 1, where at least one of said reports includes a
one-to-one relation.
5. The method of claim 1, wherein at least one of said reports includes a
grouping of information based on a unique index, said grouping including
at least one group header serving as a hypertext jump destination based on
the value of its unique index.
6. The method of claim 1, wherein at least one report includes a grouping
of information based on an index which is not unique, said grouping
including a single group header having a jump destination based on the
non-unique index value.
7. The method of claim 6, wherein members of the grouping which are not
unique are placed into a hypertext browse sequence.
8. The method of claim 1, wherein at least one report includes a detail
band ordered by a unique index, so that any other band in the hypertext
report can contain a link object for accessing the detail band of the
report.
9. The method of claim 8, wherein said link object is synthesized by the
system based on a unique identifier.
10. The method of claim 9, wherein said unique identifier is based on a
report name and a key value of the unique index.
11. The method of claim 1, wherein at least one of said reports includes a
grouping of information based on a grouping expression which is a unique
index, the grouping of information being associated with a topic
expression which is a unique identifier.
12. The method of claim 11, wherein said unique identifier is based on a
report name and a key value of the unique index.
13. A method for creating hypertext reports in a relational database
management system, the method comprising:
receiving input specifying a first report of database information, said
first report being based on information from a first subset of a set of
relational database tables, said set of database tables including records
being provide access to stored information, said first report being
separate from said set of relational database tables and specifying
display of information associated with records in said first subset of
tables;
receiving input specifying a second report of database information, said
second report being separate from said set of relational database tables
and being based on information taken from a second subset of said set of
relational database tables, said second report specifying display of
information associated with records in said second subset of tables;
combining the information from said first report and the information from
said second report into the hypertext report;
determining whether information of the first report can be linked to
information of the second report by virtue of at least one common field
between said first and second subsets of table; and
if information of the first report can be linked to information of the
second report, generating a hypertext link and placing said hypertext link
in the hypertext report for cross-referencing information in the second
report to information in the first report, the hypertext report, when
displayed to a user, allowing the user to navigate between related
information at different locations in the hypertext report by invoking
said hypertext link.
14. The method of claim 13, wherein said step of generating a hypertext
link includes generating a unique topic identifier for identifying the
information of the second report as a topic.
15. The method of claim 14, wherein the unique topic identifier is based on
a name of the second report and a value taken from information of the
second report.
16. The method of claim 14, wherein said step of generating a hypertext
link further includes generating a hypertext jump to said topic of the
second report.
17. The method of claim 13, wherein at least one of the reports includes a
one-to-many relation.
18. The method of claim 13, wherein at least one of the reports includes a
many-to-one relation.
19. The method of claim 13, wherein at least one of the reports includes a
one-to-one relation.
20. The method of claim 13, wherein said step of determining includes:
determining whether information of the first report can be related to
information of the second report.
21. The method of claim 20, wherein said step of determining includes:
determining whether a foreign key relation exists between information of
the first report and information of the second report.
22. A hypertext report system comprising:
input means for specifying a first report of relational database
information from a set of relational database tables and a second report
of relational database information from the set of relational database
tables, said set of relational database tables including records that
provide access to stored information, each of said reports representing
the relational database information but being separate from the relational
database tables;
means for combining said first and second reports into the hypertext
report;
comparison means for determining whether information of the first report
can be linked to information of the second report by virtue of at least
one common field between tables in said first and second reports; and
means for generating a hypertext link and placing said hypertext link in
the hypertext report for cross-referencing information in the second
report to information in the first report if information of the-first
report can be linked to information of the second report, the hypertext
report, when displayed to a user, allowing the user to navigate between
related information at different locations in the report by invoking said
hypertext link.
23. The system of claim 22, wherein the hypertext link comprises a unique
topic identifier for identifying the information of the second report as a
topic and a hypertext jump for jumping to the unique topic identifier.
24. The system of claim 22, wherein the comparison means includes means for
determining whether information of the first report can be related to
information of the second report.
25. The system of claim 24, wherein the comparison means further includes
means for determining whether a foreign key relation exists between
information of the first report and information of the second report.
26. A method of presenting information from a plurality of reports based
on, but separate from, a set of tables in a relational database system
wherein
each table includes a number of records, each record having a number of
fields for storing information,
said plurality of reports includes first and second reports containing
information derived from respective first and second subsets of said set
of tables, and
each respective subset of tables has a structure defined by fields in
common between pairs of tables in the respective subset,
the method comprising:
determining a particular field in said first subset of tables that
corresponds to a field in said second subset of tables;
combining said plurality of reports into a hypertext report that is
separate form said set of tables;
generating hypertext links and placing said hypertext links in portions of
said hypertext report that correspond to said first report, which
hypertext links specify said second report and respective values for the
particular field;
displaying a portion of said hypertext report corresponding to at least a
portion of said first report with information based on records in said
first subset of tables, the displayed information being correlated with
the particular field, at least a portion of the displayed information for
each record denoting a respective one of said hypertext links; and
in response to user input specifying a given hypertext link in said
hypertext report corresponding to a given value of the particular field,
displaying a portion of said hypertext report corresponding to at least a
portion of said second report with information based on records in said
second subset of tables, the displayed information for said second report
being correlated with records having the given value of the particular
field, the hypertext report thus allowing the user to navigate between
related information at different locations in the hypertext report by
invoking said hypertext links.
27. The method of claim 26 wherein said plurality of reports includes a
third report containing information derived from a third subset of tables,
and the method further comprises:
determining a further particular field in said second subset of tables that
corresponds to a field in said third subset of tables;
generating additional hypertext links and placing said hypertext links in
portions of said hypertext report that correspond to said second report,
which hypertext links specify said third report and values for the further
particular field;
in connection with said step of displaying said second report, displaying
at least a portion of the displayed information correlated with each
record with an indication denoting a respective one of said additional
hypertext links; and
in response to user input specifying a given additional hypertext link in
said hypertext report corresponding to a given value of the further
particular field displaying a portion of said hypertext report
corresponding to said third report with information based on records in
said third subset of tables, the displayed information for said third
report being correlated with records having the given value of the further
particular field.
28. The method of claim 26 wherein said first and second subsets of tables
have at least one table in common, said table in common including said
particular field.
29. The method of claim 26 wherein said information displayed in said first
report includes information derived from records in a single table.
30. The method of claim 26 wherein each of said first and second subsets
has at least one table linked to another table in a one-to-many
relationship.
31. The method of claim 26 wherein at least one of said first and second
subsets has at least one table that is not a table of the other of said
first and second subsets.
32. A method of presenting information based on a set of tables, in a
relational database system wherein
each table includes a number of records, each record having a number of
fields,
the method comprising:
providing a first report containing information based on records in a first
subset of tables, including information that is correlated with a
particular field in said first subset of tables;
providing a second report containing information based on records in a
second subset of tables, including information that is correlated with
said particular field;
combining said first and second reports into a hypertext report document
that is separate from aid set of tables;
establishing respective hypertext links and placing said hypertext links in
said hypertext reports for portions of information in said first report
that correlate with respective given values of the particular field, said
hypertext link for a given portion of information in said first report
specifying a portion of information of said second report that is
characterized by records in said second subset of tables having the value
of said particular field in said given such record, the hypertext report,
when displayed, allowing the user to navigate between related information
at different locations in the hypertext report by invoking said hypertext
links.
33. The method of claim 32 wherein said first and second subsets of tables
have at least one table in common, said table in common including said
particular field.
34. The method of claim 32 wherein said information displayed in said first
report includes information derived from records in a single table.
35. The method of claim 32 wherein each of said first and second subsets
has at least one table linked to another table in a one-to-many
relationship.
36. The method of claim 32 wherein at least one of said first and second
subsets has at least one table that is not a table of the other of said
first and second subsets.
37. A method of presenting information from a plurality of reports based
on, but separate from, a set of tables in a relational database system
wherein
each table includes a number of records, each record
having a number of fields, and
said plurality of reports includes first and second reports containing
information derived from respective first and second subsets of said set
of tables,
the method comprising:
determining a particular field in said first subset of tables, which
particular field has key values that are at least partly matched by values
in said second subset of tables;
combining said plurality of reports into a hypertext report that is
separate from said set of tables;
generating hypertext links and placing said hypertext links in portions of
said hypertext report that correspond to said first report, which
hypertext links specify said second report and respective values for the
particular field;
displaying a portion of said hypertext report corresponding to at least a
portion of said first report with information based on records in said
first subset of tables, the displayed information including portions
correlated with different values for the particular field;
displaying in said first report an indication denoting said hypertext
links; and
in response to user input specifying a given hypertext link in said
hypertext report corresponding to a given value of the particular field,
displaying a portion of said hypertext report corresponding to said second
report with information based on records in said second subset of tables,
the displayed information for said second report being correlated with
records having the given value of the particular field, the hypertext
report thus allowing the user to navigate between related information at
different locations in the hypertext report by invoking said hypertext
links.
38. The method of claim 37 wherein said plurality of reports includes a
third report containing information derived from a third subset of tables,
and the method further comprises:
determining a further particular field in said second subset of tables,
which further particular field has key values that are at least partly
matched by values in said third subset of tables;
generating additional hypertext links and placing said hypertext links in
portions of said hypertext report that correspond to said second report,
which hypertext links specify said third report and values for the further
particular field;
in connection with said step of displaying said second report, displaying
in said second report an indication denoting said additional hypertext
links; and
in response to user input specifying an additional hypertext link in said
hypertext report corresponding to a given value of the further particular
field, displaying a portion of said hypertext report corresponding to said
third report with information based on records in said third subset of
tables, the displayed information for said third report being correlated
with records having the given value of the further particular field.
39. The method of claim 37 wherein said first and second subsets of tables
have at least one table in common, said table in common including said
particular field.
40. The method of claim 37 wherein said information displayed in said first
report includes information derived from records in a single table. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material which
is subject to copyright protection. The copyright owner has no objection
to the facsimile reproduction by anyone of the patent document or the
patent disclosure as it appears in the Patent and Trademark Office patent
file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
The present invention relates generally to information processing
environments and, more particularly, to modeling information in a data
processing system, such as a Database Management System (DBMS).
Computers are a powerful tool for the acquisition and processing of
information. Computerized databases can be regarded as a kind of
electronic filing cabinet or repository for collecting computerized data
files; they are particularly adept at processing vast amounts of
information quickly. As such, these systems serve to maintain information
in database files or tables and make that information available on demand.
Of these systems, ones which are of particular interest to the present
invention are Relational Database Management Systems (RDBMSs).
The concept of relational databases is perhaps best introduced by reviewing
the problems surrounding traditional or non-relational systems. In a
traditional database system, the task of retrieving information of
interest (i.e., answering a "database query") is left to the user; that
is, the user must give detailed instructions to the system on exactly how
the desired result is to be obtained.
Consider the example of a simple query: "Who are the teachers of student
John Smith?" In a traditional system, several explicit instructions are
required before the query can be answered. One instruction, for instance,
is typically to instruct the system to allocate sections in memory for
data to be read from a storage disk. Another command may tell the system
which disk files to open and read into the allocated memory for
processing. Still other commands may specify particular search strategies,
such as use of specific indexes, for speeding up the result of the query.
And still even further commands may be needed for specifying explicit
links between two or more files so that their data may be combined. Thus,
instead of just telling the system "what" is desired (i.e., the desired
data result as expressed in a query expression), one must specify internal
procedures (i.e., the "how") for obtaining the data. Even for a simple
query, such as that above, the task is complex, tedious, and error-prone.
From the user's perspective, such details--ones directed to the physical
implementation--are completely irrelevant; the user is interested only in
the result. Thus, the lack of separation of logical operations from the
physical representation of the data (i.e., how it is internally stored and
accessed by the system) in traditional systems burdens users with
unnecessary complexity. Moreover, as traditional database products employ
proprietary data access procedures, knowledge of one product is not
necessarily helpful in use of another. And where database systems differ,
their practitioners cannot effectively communicate with one another.
In 1970, Dr. E. F. Codd invented the "relational model", a prescription for
how a DBMS should operate. The relational model provides a foundation for
representing and manipulating data, that is, a way of looking at data. The
model includes three basic components: structure, integrity, and
manipulation. Each will be described in turn.
The first of these, structure, is how data should be presented to users. A
database management system is defined as "relational" when it is able to
support a relational view of data. This means that data which a user can
access and the operators which the user can use to operate upon that data
are themselves relational. Data are organized as relations in a
mathematical sense, with operators existing to accept relations as input
and produce relations as output. Relations are perhaps best interpreted by
users as tables, composed of rows (tuples) and columns (attributes).
Ideally, data in a relational system is perceived by users as tables and
nothing but tables. This precludes the user from seeing explicit
connections or links between tables, or having to traverse between tables
on the basis of such links. It also precludes user-visible indexes on
fields and, in fact, precludes users from seeing anything that smacks of
the physical storage implementation. Thus, tables are a logical
abstraction of what is physically stored.
The integrity aspect, on the other hand, dictates that every relation
(i.e., table) should have a unique, primary key to identify table entries
or rows. The integrity of the data for the user is of course crucial. If
accuracy and consistency of the data cannot be achieved, then the data may
not be relied upon for decision-making purposes.
Data manipulation, the last component, may be thought of as cut-and-paste
operators for tables. Data manipulation is of course the purpose for which
databases exist in the first place. The superiority of manipulating tables
relationally (i.e., as a whole, or sets of rows) is substantial. Users can
combine data in various tables logically by matching values in common
columns, without having to specify any internal details or the order in
which tables are accessed; this provides users with a conceptual view of
the database that is removed from the hardware level. Non-relational
DBMSs, in contrast, require complex programming skills that form an
inherently unreliable means to interact with databases.
The general construction and operation of a database management system is
known in the art. See e.g., Date, C., An Introduction to Database Systems,
Volume I and II, Addison Wesley, 1990; the disclosures of which are hereby
incorporated by reference.
Today, relational systems are everywhere--commonly seen operating in
corporate, government, academic settings, and other shared environments. A
typical installation will employ one of the popular UNIX-based RDBMS
running on a minicomputer. By submitting queries to the DBMS from a remote
terminal (e.g., using a SQL "query editor"), users are often able to
handle many of their own data processing needs directly. Thus, relational
technology is not only just another way to build a database system, but it
also offers a set of underlying principles that provide very direct
practical benefits to the user.
A chief aim of the RDBMS is to provide company management with timely
reports from which meaningful business decisions can be made. If back
orders, say, at a given branch store are higher than at other branches,
prompt attention can rectify the position, but only if the reporting
system clearly indicates the possible anomaly to those capable of taking
action.
Traditionally, the database system has produced printed daily, weekly or
monthly order-status reports for branches and consolidated reports for
head office. There are several problems with the way current databases are
used to generate these regular printed reports for management, however.
First, different management levels require different data, so either the
number of distinct reports tends to proliferate or the system needs to
produce a complex, combined form from which each manager extracts his or
her figures. Second, to solve what may turn out to be an isolated problem,
such as a fluctuation in back orders for a particular salesperson,
customer, or branch, a new or revised report is produced and perpetuated,
adding to the paper and data overload. Third, to investigate anomalies,
the manager may have to examine several printed reports and/or make ad hoc
queries on the database.
All told, ad hoc database queries, even with the help of SQL (Structured
Query Language) and other query languages, are often difficult or
impossible for most managers, so a time-consuming request has to be made
to skilled database staff or to the database administrator. The present
invention solves the problem by offering database-illiterate managers
simple, direct on-line access not only to their usual reports but also to
related data needed to investigate and rectify discrepancies.
SUMMARY OF THE INVENTION
A system of the present invention comprises a relational database
management system (RDBMS), where information is maintained in one or more
database tables for easy, efficient storage and retrieval. In addition to
database tables, the system provides "design documents"--forms and
reports--which allow a user to customize how his or her data are
presented, including formats which are not tabular. Design documents can
also link together different tables, so that information stored in
separate tables appears to the user to come from one place.
The system of the present invention includes a hypertext report writer
which can identify relations between reports which contain similar
information (i.e., are based on relatable database tables). Upon
identifying relations, the system may place appropriate hypertext links
which cross-reference information in one report to information in another,
related report. As one application of the present invention, the system
may automatically generate "drill-down" reports using cross-indexes which
are based on these relations.
A "hypertext report" is generally constructed by combining two or more
traditional reports. By automatically placing hypertext links or
cross-indexes between reports, the system ties together relatable
information into a single, cross-indexed hypertext report.
The present invention may be advantageously applied in any setting where
timely access is required to detailed information, particularly where it
is undesirable to place the report on paper, and where it is not practical
for the report reader to perform queries on the underlying database. For
instance, instead of having to review lengthy paper reports, a busy
executive could review summary information in hypertext format. The
executive could then drill-down, using hypertext navigation techniques, to
the detailed information which is of particular interest. Detailed
information which is not of interest is hidden, so the executive need not
waste time reviewing it. Moreover, since the hypertext report is generated
electronically, the entire process may be automated so that an electronic
copy of a hypertext report may be automatically generated and delivered on
a timely basis (e.g., daily). By placing report information in hypertext
format, the system of the present invention allows the reader to employ
other features of Hypertext, such as "Content" and "Search" generation,
Browse sequences, Topic breaks, and the like.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1A is a block diagram of a computer system in which the present
invention may be embodied.
FIG. 1B is a block diagram of a software system of the present invention,
which includes operating system, application software, relational database
management system, and user interface components.
FIG. 1C is a diagram illustrating the conceptual relation between a
database table and its index.
FIG. 2 is a bitmap screenshot illustrating the basic architecture and
functionality of a graphical user interface in which the present invention
may be embodied.
FIG. 3A is a bitmap screenshot illustrating a preferred Desktop or
application interface for the system of the present invention.
FIG. 3B is an enlarged view of a toolbar from the interface of FIG. 3A.
FIGS. 3C-E are bitmap screenshots illustrating use of the Desktop's client
area for displaying and manipulating major objects of the system,
including table objects, form objects, report objects, and the like.
FIG. 3F is a block diagram of a sample database system for tracking sales
orders.
FIGS. 3G-K are bitmap screenshots illustrating the structuring of
information tables for the system of FIG. 3F.
FIGS. 4A-E are bitmap screenshots illustrating use of a hypertext document,
including use of jump text (via hypertext links).
FIGS. 5A-B are bitmap screenshots illustrating creation of a simple
hypertext document, for use with Microsoft Windows.
FIGS. 6A-E are bitmap screenshots illustrating creation of a hypertext
report, using information from the tables of FIG. 3F.
FIG. 7A is a bitmap screenshot illustrating RTF hypertext code having
"hidden" identifiers for marking "topic" and "jump to" locations.
FIG. 7B is a hypertext jump diagram which illustrates how the report of
FIG. 6 are related (through hypertext links).
FIG. 8A-E are block diagrams illustrating underlying data models for the
hypertext reports of FIG. 7.
FIG. 9 is a block diagram illustrating an exemplary design layout (banded
approach) for the hypertext reports of FIG. 7.
GLOSSARY
alternate keys: Candidate keys (see below) which are not selected as the
primary key for a table.
alphanumeric field: A field containing letters, numbers, or a combination
of both.
binary field: A field used to store data the system cannot interpret
(without additional instructions). A common use of a binary field is to
store sound.
bind: To associate a form or report with one or more tables. The document
then takes its data from the table(s) to which it is bound.
blank field: A field that does not contain a value.
candidate keys: Keys comprising all sets of column combinations with unique
values for a table. One of these is selected as the primary key; the rest
remain alternate keys.
cascade: To use referential integrity to update child tables when a value
changes in the parent table.
command: a word on a menu or button that one chooses to perform an action.
composite key: A key comprised of two or more fields of a table which,
together, provide a unique value for each record of the table.
data: The information stored in a table.
data integrity: The assurance that the values in a table are protected from
corruption.
data type: The kind of data a field can contain. Data types include
alphanumeric, number, currency, date, short number, memo, formatted memo,
binary, graphic, and OLE.
database: An organized collection of information.
Database Management System (DBMS): System that controls the organization,
storage, and retrieval of information in a database.
default: What the system automatically does or looks like in the absence of
an overriding command.
design document: A form or report that one creates or modifies in a design
window.
design object: An object one can place in forms and reports. One creates
design objects using toolbar tools in a design window.
design window: The window where one creates or modifies the design of a
document. If one is viewing data in a Form or Report window, he or she can
select the Design button to open the corresponding design window for that
document.
Desktop: The main window in system. The Desktop is the highest level of
interaction with all system objects.
detail table: In multi-table relationships, the table whose records are
subordinate to those of the master table.
dialog box: A box that requests or provides information. Many dialog boxes
present options to choose among before one can perform an action. Other
dialog boxes display warnings or error messages.
domain: A set of permissible values (i.e., pool of values) for one or more
(shared) columns that have the same meaning.
field: A column of information in a table. A collection of related fields
makes up one record.
field type: The type of data a field can contain. Field types include
alphanumeric, number, currency, date, short number, memo, formatted memo,
binary, graphic, and OLE.
field value: The data contained in one field of a record. If no data is
present, the field is considered blank.
file: A collection of information stored under one name on a disk. For
example, the system tables are stored in files.
form: An alternate presentation or view of a table's data. A multi-table
form can display data from several tables at once.
group: (1) In a report or query, a set of records that either have the same
value in one or more fields; fall within a range of values; or are
displayed in a fixed number of records; and (2) to collectively identify
various objects as a single entity.
index: A file that determines an order in which the system can access the
records in a table. A system table's key establishes its primary index.
inspect: To view or change an object's properties. To inspect an object,
one would either right-click it or select it with the keyboard and press
F6. The object's menu appears. One selects from the menu the property he
or she wants to change.
key: A field or group of fields in a system table used to order records or
ensure referential integrity. Establishing a key has three effects: (1)
The table is prevented from containing duplicate records; (2) The records
are maintained in sorted order based on the key fields; and (3) A primary
index is created for the table.
link: To establish a relationship between tables by linking corresponding
fields.
logical value: A value (True or False) assigned to an expression when it is
evaluated.
lookup table: A table that assures that a value entered in one table
matches an existing value in another table.
Main menu: The menu bar across the top of the system Desktop.
master table: In a multi-table relationship, the primary table of a user's
data model. If one has only one table in his or her data model, that table
is the master table.
multi-record: Refers to an object that displays several records at once in
a form or report.
normalized data structure: An arrangement of data in tables in which each
record includes the fewest number of fields necessary to establish unique
categories. Rather than using a few redundant fields to provide all
possible information within a single table, normalized tables distribute
information over many tables using fewer fields. Normalized tables provide
more flexibility in terms of analysis.
object: A table, form, report, query, script, or library. All entities that
can be manipulated in the system are objects.
OLE: OLE stands for Microsoft Windows' Object Linking and Embedding. One
can use OLE to insert files from OLE servers into system tables or OLE
objects.
primary index: An index on the key fields of a system's table. A primary
index (1) Determines the location of records; (2) Lets one use the table
as the detail in a link; (3) Keeps records in sorted order; and (4) Speeds
up operations.
prompt: Instructions displayed on the screen. Prompts ask for information
or guide a user through an operation.
properties: The attributes of an object. One must right-click an object to
view or change its properties.
query: A question one asks the system about information in his or her
tables. The query can be a simple question about the information in a
single table or a complex question about information in several tables.
record: A horizontal row in a system table that contains a group of related
fields of data.
record number: A unique number that identifies each record in a system
table.
referential integrity: A way of ensuring that the ties between like data in
separate tables is maintained.
report: Information from tables printed on paper or previewed onscreen.
secondary index: An index used for linking, querying, and changing the view
order of tables.
set: A specific group of records (e.g., about which a user intends to ask
questions).
structure: The arrangement of fields in a table.
table: A structure made up of rows (records) and columns (fields) that
contains information.
toolbar: The set of buttons and tools for frequently performed tasks. The
toolbar is displayed under the menu bar and changes according to the
window one is using.
unique index: An index capable of uniquely identifying each record for
which a value is given in a table.
validity check: A constraint on the values one can enter in a field.
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
The following description will focus on the presently preferred embodiment
of the present invention, which is operative in the Microsoft.RTM. Windows
environment. The present invention, however, is not limited to any
particular one application or any particular windows environment. Instead,
those skilled in the art will find that the system and methods of the
present invention may be advantageously applied to a variety of system and
application software, including database management systems,
wordprocessors, spreadsheets, and the like. Moreover, the present
invention may be embodied on a variety of different platforms, including
Macintosh, UNIX, NeXTSTEP, and the like. Therefore, the description of the
exemplary embodiments which follows is for purposes of illustration and
not limitation.
System Hardware
The invention may be embodied on a computer system such as the system 100
of FIG. 1A, which comprises a central processor 101, a main memory 102, an
input/output controller 103, a keyboard 104, a pointing device 105 (e.g.,
mouse, track ball, pen device, or the like), a display device 106, and a
mass storage 107 (e.g., hard or fixed disk, optical disk, magneto-optical
disk, or flash memory). Processor 101 includes or is coupled to a cache
memory 109 for storing frequently accessed information; memory 109 may be
an onchip cache or external cache (as shown). Additional input/output
devices, such as a printing device 108, may be included in the system 100
as desired. As shown, the various components of the system 100 communicate
through a system bus 110 or similar architecture. In a preferred
embodiment, the system 100 includes an IBM PC-compatible personal
computer, available from a variety of vendors (including IBM of Armonk,
N.Y.).
System Software
A. Overview
Illustrated in FIG. 1B, a computer software system 150 is provided for
directing the operation of the computer system 100. Software system 150,
which is stored in system memory 102 and on disk memory 107, includes a
kernel or operating system (OS) 140 and a windows shell 145. One or more
application programs, such as application software 125 or one or more
windows application software 151, 153, 155, may be "loaded" (i.e.,
transferred from storage 107 into memory 102) for execution by the system
100. As shown, windows application software includes a Relational Database
Management System (RDBMS) 155 of the present invention.
System 150 includes a user interface (UI) 160, preferably a Graphical User
Interface (GUI), for receiving user commands and data. These inputs, in
turn, may be acted upon by the system 100 in accordance with instructions
from operating module 140, windows 145, and/or application modules 125,
| | |
