Method to document relations between objects using a graphical interface tree component

[00002] 1. Field of the Invention

[00003] The invention relates to the field of graphical interfaces, and in particular, to graphically displaying logical relationships between objects.

[00004] 2. Background Information

[00005] Even the earliest computer system included a rudimentary mechanism that allowed it to receive input from its users. These mechanism are often called user interfaces. The user interfaces of early computers often employed lights and switches that allowed the computer system user to communicate with the computer system in the system's native language. While this form of communication was effective, its use was essentially limited to scientists and engineers who were trained to understand the particulars of the computer system. For this reason, computer system providers moved to user interfaces that provided for entry of textual commands. While these command-based user interfaces were easier to use than their predecessors, they still typically involved a large number of commands that were often difficult for non-technical individuals to understand and remember. The shortcomings of command-based user interfaces led to the introduction of graphical user interfaces, which are often referred to as GUIs. Instead of requiring the user to have in-depth knowledge of the computer system, graphical user interfaces allow the every day user to communicate with the computer system via a pointing device such as a mouse. To use the computer system to perform various tasks, the user simply “points and clicks” on various GUI items such as icons and taskbars. These icons and taskbars are user friendly ways of activating different programs on the computer.

[00006] Data is typically organized in files, grouped in directories. Directories may be grouped together in other directories. Sometimes directories are displayed as folder icons, and the hierarchy of files within directories, and directories within directories, is displayed as a tree structure.

[00007] Modern graphical interfaces, such as are used in Windows-based programs, and the like, give access to objects, such as files and directories, by grouping and displaying icons representing objects of similar types in various levels of containers in a tree structure. Although this type of display grouping is useful in many circumstances, there are many situations when the container relationships do not give the user any indication of other relationships that may exist among the objects.

[00008] For example, consider a critical table in a database which has 30 indexes and 100 views created over it. The container model allows the user to “drill” down to the table level only, which does not give the user a full appreciation of the relationships between the table and the indexes and views.

[00009] In the example shown in FIG. 1, there is a typical view of how data may be grouped today in the SQL 7.0 product from Microsoft. Although SQL 7.0 is used for the example, there may be other data base products which provide a similar graphical interface. In this example, when opening the table container, a list of tables is displayed, but with no visual cues showing how other objects relate to any particular table. That is, there are no visible cues about relationships between the particular table, and the indexes and views. This implementation in FIG. 1 shows only containers in the tree (on left) and uses another window (on right) to list the contents of the container.

[00010] However, when dealing with a complex database, for example, the relationships between objects are very difficult to remember and understand, but they are very important to consider when making updates or changes to the database.

[00011] Therefore, a new model which would allow the user to see those views and indexes which are directly related to the table, but not contained within the table, i.e., where there is no physical connection, but there are logical connections (relations), would overcome the above-mentioned problems and make the computer systems more user friendly.

[00012] It is, therefore, a principle object of this invention to provide a method of documenting relations between objects using a graphical interface tree component.

[00013] It is another object of the invention to provide a method that solves the above mentioned problems so that a user is able to see those views and indexes which are directly related to the table, but not contained within the table, i.e., where there is no physical connection, but there are logical connections (relations).

[00014] These and other objects of the present invention are accomplished by the method disclosed herein.

[00015] According to an aspect of the invention, a tree structure is used to reflect the other logical relationships, which in the exemplary embodiment are database relationships.

[00016] According to an aspect of the invention, applied to a data base application, a user can easily see those views and indexes which are directly related to the table, but not contained within the table, i.e., logically related to the table.

[00017] According to an aspect of the invention, a user can now see which objects are related to one another, and with context menus, can make changes in place.

[00018] These and other aspects of the invention will become apparent from the detailed description set forth below.

[00023] The invention will now be described in more detail by way of example with reference to the embodiment(s) shown in the accompanying figures. It should be kept in mind that the following described embodiment(s) is/are only presented by way of example and should not be construed as limiting the inventive concept to any particular physical configuration.

[00024] As described in the Background section, FIG. 1 shows a typical view of how data is grouped today in the SQL 7.0 product form Microsoft. In this example when opening the table container on the left, a list of tables is displayed on the right, but with no visual cues showing how other objects relate to any particular table. Only containers are shown in the tree in the left window and another window on the right is used to list the contents of the container. However, as noted earlier, when dealing with a complex database the relationships between objects are very difficult to remember and understand, but they are very important when making updates/changes to the database. When making changes to a database, having an understanding of how each of the parts of the database relate to each other is critical to making the change correctly.

[00025] In the FIG. 1 example, there are sets of containers that hold like objects. A problem which the invention is directed to overcoming, is that what is not shown is the relationship(s) between objects in one container and objects in another container. For example, the views have relationships to one or more tables, but that cannot be seen using the container way of presenting data. When a user clicks on a container in the tree on the left, e.g., the TABLES container, the objects of that type of group are displayed in another window on the right.

[00026] FIGS. 2 to 6 depict an exemplary embodiment of the invention in which a user can see which objects are related to one another and with context menus can make changes in place. That is, the logical relationships between each of the parts of the database are laid out in the tree. This new model allows the user to easily see those views and indexes which are directly related to the table, but not contained within the table. With the context menus, any change can be made and the tree refreshed in place with that change. For example, a user may decide that an index is necessary. Right-clicking on the table to display the context menu, then clicking on the properties for the table, and doing the required data entry, the index is created and then shows up in the index category.

[00027] The examples viewed sequentially from FIGS. 2-6 show how a user can find the logical relationships that exist between objects according to an exemplary embodiment of the invention. It will be understood by a person skilled in the art that these logical relationships may be accessed from the target application, e.g., a data base application, to be used for the graphical interface display according to the invention.

[00028] When a user expands a container in the tree, e.g., the Tables container, the objects of that type of group are displayed in another area of the window below it. In FIG. 2, the Library Tree tab at the top of the window has been selected, and the Tables container in TESTLIB has been expanded to show that it has three table objects therein, and TABLE2 is selected (highlighted). The TESTLIB container also has an Indexes container and a Views container under it in the tree, which are not expanded in FIG. 2, but will be shown expanded in FIG. 6.

[00029] In FIG. 3, the TABLE2 object has been expanded by clicking on the “+” sign, and below it in the tree are two objects: Indexes and Views. These objects represent the logical relationship of indexes and views to the table. That is, they are not contained in TABEL2, but have logical relationships to TABLE2. This advantageous display of these relationships is not provided by the graphical interface in the SQL 7.0 product or other known products, described above.

[00030] In FIG. 4, the Indexes object related to TABLE2 has been expanded in the tree and has three indexes logically related to TABLE2 displayed below it. These are: INDEX2, INDEX3, and INDEX4. The tree thus graphically shows that there is a logical relationship between the table TABLE2 and the three indexes INDEX2, INDEX3 and INDEX4, in accordance with the invention.

[00031] In FIG. 5, the Views object related to TABLE2 has been expanded to show that there is one view, VIEW1 logically related to TABLE2, by virtue of the way VIEW1 is shown in the tree. The tree thus graphically shows that there is a logical relationship between the table TABLE2 and the view VIEW1. FIG. 6 shows the additional expansion of the Indexes and Views containers under TESTLIB which contain the respective indexes INDEXOVERTESTTABLE, INDEX2, INDEX3 and INDEX4, and the view VIEW1.

[00032] As one skilled in the art would recognize, there are a number of modifications and variations possible within the spirit and scope of the invention. For example, some of these that are considered applicable for implementation of the invention include:

• • [00033] 1. Expanding a table node the user would see Indexes, Views, Referential Constraints, Check Constraints, Unique Keys, Primary Keys, Triggers, Journals, Aliases.
  • [00034] 2. Expanding a view node the user would see the Tables the view was created over and Aliases.

[00035] 3. Expanding a referential constraint node the user would see the Tables created between.

[00036] 4. Expanding a index node the user would see the Table which it was created.

[00037] 5. Expanding a journal node the user would see all the Tables, Views or Indexes being journaled and the Journal Receivers.

[00038] FIG. 7 is a flow chart illustrating an exemplary embodiment of a computer based method according to the invention. Initially, a graphical tree structure of objects grouped by type is displayed (701). Then the user can select an object in the tree to be expanded (702). When the selected object is expanded, objects having a logical relationship or connection to the object that is expanded are displayed in the graphical tree structure, grouped by type (703). If changes are to be made to an object in place (704), then next, the user selects the object in the graphical tree structure to be changed (705), right-clicks on the selected object (706) and a context menu is displayed (707). The user then selects the properties item in the context menu (708), and enters data according to the desired change (709). Then the user closes the context menu (710) and the graphical tree structure is refreshed to show the change (711).

[00039] FIG. 8 is a block diagram of a basic computer system 800 in which a graphical user interface can be implemented according to an exemplary embodiment of the invention. The basic computer system 800 includes processing means 801, storage means 802 in which a program implementing a graphical user interface 803 as described above is disposed, an input device 804, e.g., mouse and/or keyboard, and a display means 805.

[00040] Database objects were used in the above exemplary embodiment to demonstrate the concept of the invention. However, the concept can be applied to any set of objects that have some sort of relations between them. For example, it could be applied to a family tree or a network of pictures. Such applications are considered to be within the spirit and scope of the invention.

[00041] The invention may be embodied as a computer program product. A computer program product includes a recording medium, such as a floppy disk, a high-capacity read only memory in the form of an optically read compact disc or CD-ROM, a tape, a transmission type media, such as a digital or analog communications link, or a similar computer program product.

[00042] It will be apparent to one skilled in the art that the manner of making and using the claimed invention has been adequately disclosed in the above-written description of the preferred embodiment(s) taken together with the drawings.

[00043] It will be understood that the above described preferred embodiment(s) of the present invention are susceptible to various modifications, changes, and adaptations, and the same are intended to be comprehended within the meaning and range of equivalents of the appended claims.

[00044] Further, although a number of equivalent components may have been mentioned herein which could be used in place of the components illustrated and described with reference to the preferred embodiment(s), this is not meant to be an exhaustive treatment of all the possible equivalents, nor to limit the invention defined by the claims to any particular equivalent or combination thereof. A person skilled in the art would realize that there may be other equivalent components presently known, or to be developed, which could be used within the spirit and scope of the invention defined by the claims.