WO1999033000A1

WO1999033000A1 - User interface for the specification of index groups over classes

Info

Publication number: WO1999033000A1
Application number: PCT/US1998/027241
Authority: WO
Inventors: Tony Chun Tung Ng; Rahul Sharma
Original assignee: Tony Chun Tung Ng; Rahul Sharma
Priority date: 1997-12-22
Filing date: 1998-12-21
Publication date: 1999-07-01
Also published as: AU1833799A; EP1008068A1

Abstract

A user interface permits a programmer or other person to manage index groups for classes. The programmer enters information through the user interface to define new index groups, update defined index groups, and delete index groups. The programmer manages the index groups in the classes, and an optional mapping tool maps the defined index groups when converting data between an object model and a relational model.

Description

USER INTERFACE FOR THE SPECIFICATION OF INDEX GROUPS OVER CLASSES

REFERENCE TO RELATED APPLICATIONS The following identified U.S. patent applications are relied upon and are incorporated in their entirety by reference in this application as if fully set forth.

Provisional U.S. Patent Application No. 60/068,415, entitled "System and Method for Mapping Between Objects .and Databases," filed on December 22, 1997.

U.S. Patent Application No. 09/106,186, entitled "Object Relational Mapping Tool That Processes Views," bearing attorney docket no.06502.0136-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/106,189, entitled "Evolution Of Object-Relational Mapping Through Source Code Merging," bearing attorney docket no. 06502.0137-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/105,957, entitled "Integrating Both Modifications to an Object Model and Modifications to a Database into Source Code by .an Object-Relational Mapping Tool," bearing attorney docket no. 06502.0138-00000, and filed on the same date herewith.

U.S. Patent Application No.09/106,212, entitled "User Interface forthe Specification of Lock Groups," bearing attorney docket no. 06502.0142-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/106,119, entitled "A Fine-Grained Consistency Mechanism for Optimistic Concurrency Control Using Lock Groups," bearing attorney docket no. 06502.0143-00000, and filed on the same date herewith.

U.S. Patent Application No.09/106,211, entitled "User Interface forthe Specification of Index Groups Over Classes," bearing attorney docket no.06502.0144-00000, and filed on the same date herewith. U.S. Patent Application No.09/106,188, entitled "Method and Apparatus for Creating

Indexes in a Relational Database Corresponding to Classes in an Object-Oriented Application," bearing attorney docket no. 06502.0145-00000, and filed on the same date herewith. U.S. Patent Application No.09/ 106, 190, entitled "Method and Apparatus for Loading Stored Procedures in a Database Corresponding to Object-Oriented Data Dependencies," bearing attorney docket no. 06502.0146-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/106,046, entitled "An Integrated Graphical User Interface Method and Apparatus for Mapping Between Objects and Databases," bearing attorney docket no. 06502.0147-00000, and filed on the same date herewith.

U.S. Patent Application No. 09/105,955, entitled "Methods and Apparatus for Efficiently Splitting Query Execution Across Client .and Server in an Object-Relational Mapping," bearing attorney docket no. 06502.0148-00000, and filed on the s.ame date herewith.

FIELD OF THE INVENTION The present invention relates to a user interface for specifying index groups for classes for data stored in a database.

BACKGROUND OF THE INVENTION Obj ect-relational mapping tools facilitate development of application programs that utilize a relational database. A relational database stores data in tables having rows (records) and columns (fields). The tables are usually interrelated, and thus, there is a logical structure imposed on the database. This logical structure is known as a schema. Each table has a primary key, comprising one or more columns that uniquely identify a row. For example, in a table with rows of customers, a column storing each customer's social security number may be used as the primary key because it uniquely identifies each customer in the table. A table may also have another key, known as a foreign key, associating a row in one table to one or more rows in another table. For example, where one table contains customer information and another table contains order information for the customers, a foreign key may exist to relate one customer (or row) in the customer table with one or more orders (or rows) in the order table.

Object-relational mapping tools read a database and automatically generate source code from the database. This source code contains a number of classes whose interrelationships reflect the logical structure, or schema, of the database. A class, such as a Java™ class, is a data structure containing both data members that store data and function members (or methods) that act upon the data. The source code contains one class for each table in the database, and each class has a data member for each column in the corresponding table. Additionally, the classes contain function members that are used to both get and set the values for the data members and, eventually, update the database. By using an obj ect-relational mapping tool, a programmer can automatically generate source code to facilitate their database application development. After the source code is generated, the programmer writes code to interact with the classes in the source code. This helps to hide the complexities of interacting with the database from the programmer. This allows a programmer who is familiar with object-oriented programming to code against familiar classes and not unfamiliar, sometimes cumbersome to use, database query languages.

One type of database relationship defined by programmers are database indexes. An

"index" refers to data included within a particular database and is used to permit faster retrieval of information from the database. Data in a column of a table, for example, is typically stored in random order, and locating a particular data element requires a search through each data element in the column. By structuring the data in a particular way, such as by using a b-tree, a system can more quickly locate and retrieve particular data elements.

Conventional obj ect-relational mapping tools, however, do not enable users to specify indexes based on classes mapped from tables in a relational database. A need therefore exists for a mapping tool with this capability.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an implementation of the invention and, together with the description, serve to explain the advantages and principles of the invention. In the drawings, Figure 1 depicts a data processing system suitable for practicing methods and systems consistent with the present invention;

Figure 2 depicts a more detailed diagram of the database depicted in Figure 1; Figure 3 depicts a database data structure reflecting the schema of the database depicted in Figure 1 ; Figure 4 A depicts an object model containing information derived from the database data structure depicted in Figure 3;

Figure 4B depicts source code generated from the object model depicted in Figure 4A; Figure 5 is a diagram of an exemplary index group for a field in an object;

Figure 6 is .an ex-ample of a user interface for permitting a user to define index groups over classes;

Figure 7 is a block diagram of software modules for accessing and operating on data in a relational database using index groups; Figure 8 is a diagram of software modules for processing transactions using index groups; and

Figure 9 is a flow chart of an exemplary process associated with the user interface shown in Figure 6.

SUMMARY OF THE INVENTION Apparatus and methods consistent with the present invention include providing a user interface to allow a programmer or other person to view and enter information relating to index groups, potentially for use with a mapping tool that maps corresponding data between a relational model and an object model.

A method consistent with the present invention includes providing a user interface having information representing data in a database and storing a plurality of index groups associated with the data. Information representing one or more of the index groups is selectively displayed through the user interface.

Another method consistent with the present invention includes providing a user interface having information representing data in a database and receiving through the user interface information for defining an index group associated with the data. The defined index group is stored for use in processing associated with the data.

An apparatus consistent with the present invention provides a user interface having information representing data in a database and stores a plurality of index groups associated with the data. The apparatus selectively displays through the user interface information representing one or more of the index groups. Another apparatus consistent with the present invention provides a user interface having information representing data in a database and receives through the user interface information for defining an index group associated with the data. The apparatus stores the defined index group for use in processing associated with the data. DETAILED DESCRIPTION

Methods and systems consistent with the present invention provide a user interface for a user to specify index groups over classes of obj ects potentially mapped from a relational database. An "index group" refers to an identification data to be mapped to a database index. The interface may also be used to modify or delete existing index groups. An optional mapping tool maps the index groups during mapping of data between objects in .an object- oriented model and tables in a relational model and, therefore, a user's specified index groups are saved and need not be repeatedly recreated. Overview of Mapping Tool

In accordance with methods and systems consistent with the present invention, the improved object-relational mapping tool maps a database by first querying the database to determine its schema and then by creating an internal data structure (known as the "database data structure") representing that schema. From this data structure, the object-relational mapping tool creates an object model containing all of the information necessary to generate classes and then creates source code containing a number of Java classes that may be used by a programmer to interface with the database.

Implementation Details

Figure 1 depicts a data processing system 100 suitable for practicing methods and systems consistent with the present invention. Data processing system 100 includes computer 101 connected to network 102, such as the Internet. Computer 101 includes memory 104, secondary storage device 106, central processing unit (CPU) 108, input device

110, and video display 112. Memory 104 includes an object-relational mapping tool 114 (ORMT) in accordance with methods and systems consistent with the present invention. In turn, the object-relational mapping tool 114 includes object model 116 and database data structure 115, reflecting the schema of database 118, stored on secondary storage device 106. Also stored on secondary storage device 106 is source code 120, containing classes reflecting the schema of database 118 and containing any customizations of the programmer.

Memory 104 also includes a runtime system 123, which includes a virtual machine (VM) 124. Secondary storage device 106 further contains a program 125 with source code .and various class files 126. An exemplary runtime system for purposes of implementing methods .and systems consistent with the principles of the present invention includes the Java™ runtime system included in the Java™ Development Kit from Sun Microsystems, Inc. The Java runtime system includes a Java VM. The Java VM is described in Lindholm and Yellin, The Java™ Virtual Machine Specification. Addison- Wesley (1997), which is incorporated herein by reference.

Although computer 101 is depicted with various components, one skilled in the art will appreciate that this computer can contain additional or different components. Additionally, although computer 101 is shown connected to network 102, computer 101 may be connected to other networks, including other wide area networks or local area networks. Furthermore, although aspects of the present invention are described as being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on or read from other types of computer program products or computer-readable media, such as secondary storage devices, including hard disks, floppy disks, or CD-ROM; a carrier wave from the Internet; or other forms of RAM or ROM. Still further, one skilled in the art will appreciate that database 118 and source code 120 may be stored on or distributed across other devices on network 102. In addition, the computer-readable media may include instructions for controlling a computer systems, such as computer 101, to perform a particular method.

Sun, Sun Microsystems, the Sun logo, Java™, and Java™-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Object-relational mapping tool 114 reads database 118 to examine its schema, constructs database data structure 115 to reflect this schema, generates an object model 116 based on database data structure 115, .and then creates source code 120 based on obj ect model 116. It should be noted that, at the time object model 116 is generated, the object-relational mapping tool allows the programmer to add customizations, and these customizations will be reflected in the source code 120. For example, the progr-ammer may add a new method, rename a field (and use it for a different purpose), ch-ange the attributes of a field (e.g., the type or whether it can accept a null value), or override the mapping of a field. When a field mapping is overridden, that field will not appear in the source code. Figure 2 depicts a more detailed diagram of an example of database 118, containing a customer table 202 and an order table 204. The customer table 202 includes a customer ID column 206, and a name column 208. The customer ID column 206 serves as the primary key for the customer table 202. The order table 204 includes order ID column 212, date column 214, .and customer ID column 216. The order ED column 212 serves as the primary key for the order table 204. Customer ED column 216 is the foreign key to customer ED column 206, meaning customer ID column 216 refers to the customer ID column 206 in one or more rows.

As previously stated, database data structure 115 represents the schema of database 118. Object-relational mapping tool 114 creates database data structure 115 by querying database 118 to identify its schema and by creating the data structure to reflect the schema.

This process is known as "importing" the database schema and is described in further detail below. Once created, database data structure 115 appears as shown in Figure 3 .and includes an object 302, reflecting the customer table 202, and an object 304, reflecting the order table 204. Object 302 contains a list 306 of foreign key objects, if any, each containing the name of the foreign key as well as an indication of the columns that comprise the foreign key.

Additionally, object 302 contains a list 308 of the indexes in the customer table 202, where each element of the list is an index object containing an indication of the type of index (e.g., primary, non-unique, .and unique) and a list of columns that comprise the index. Object 302 also contains a hash table 310, where each entry in the hash table is a column obj ect 312, 314 containing data for a particular field, including its name, type, .and length. Object 304 contains similar information, including a list of foreign keys 316, a list of indexes 318, and a hash table 320 with column objects 322-326 for each field or column.

Using the object-relational mapping tool, the programmer may customize the object model. For example, the programmer may rename the name field to SSN and may subsequently use this field to store the customer's social security number, in which case the customer's social security number will be stored in the name field 208 of the database 118. By making such a customization, it is reflected in the object model 116 shown in Figure 4A. Object model 116, generated by the object-relational mapping tool, contains the programmer's customization (e.g., the name field has been renamed to SSN). Object model 116 contains objects 400 and 401, representing an intermediate form of the information for a class before it is written as source code. Object 400 contains information for the customer table 202, including a list 402 of relationship objects 403, each containing information indicating a relationship (i.e., a foreign key). For example, relationship object 403 links a field in object 400 with a field in object 401. Additionally, object 400 contains a hash table 404 with an entry 406, 408 for each field in customer table 202, each entry containing the name and type of the field. Similarly, object 401 contains information for order table 204, including a list 410 of relationship objects 411 and a hash table 412 containing entries 414- 418 for each field in order table 204.

As can be appreciated from this description of object model 116, it contains all of the information necessary to create the classes in the source code, an example of which is depicted in Figure 4B. Figure 4B depicts source code file 116 with the Java™ programming language representation of objects 400 and 401. Class 420 reflects customer table 202 and class 424 reflects order table 204. As such, class 420 contains a data member for customer ID, social security number, .and a collection of objects representing the orders associated with that particular customer, thus implementing the foreign key. Class 420 also contains a number of methods to both get -and set the value of the data members, including an iterator method to iterate through the order for this p.articular customer. Class 424 includes data members order ID and date and also includes various methods to both set and get the values for these data members. Additionally, class 424 contains a field, Customer_for_Order, implementing the foreign key with a reference to the particular customer object that placed that order.

When a foreign key is contained in the object model, the object-relational mapping tool typically creates a relationship in the source code between two classes to implement the foreign key. As stated above, with a foreign key, one or more records in one table (the referring table) refers to one record in another table (the referred table). This relationship is a one-to-many relationship, although it may be a one-to-one relationship. Additionally, instead of being bidirectional, the relationship may be unidirectional. To define this relationship in the Java™ programming language, the class representing the referring table is defined to have a member that is a collection of the class representing the referred table. A "collection" refers to a type indicating a grouping of instances of other classes. Then, in the class reflecting the referred table, a member is added providing a reference to the class that refers to it. For most cases, this is how a foreign key is implemented. However, when the foreign key for two tables overlaps with the primary key for those tables, it is more efficient to simply subclass the class reflecting the referred class from the class reflecting the referring class.

Index Groups

Figure 5 illustrates an example of an index group 502 for an object 500, which provides an example of an object for specifying information for customers. As shown in Figure 5, object 500 includes an identification field, a name field 501, and possibly other fields of data. Index group 502 corresponds to the entries within name field 501, and it provides an indication of data to be mapped to a database index for use in faster retrieval of information from the name field. In particular, the data elements in name field 501 are typically not stored in a particular order, meaning that each data element must be examined in order to locate a particular data element. Therefore, index group 502 provides a reference to a database index for faster data retrieval and more efficient data processing. Although this example illustrates an index group including one field, index groups may include a set of fields, as defined by a user. An example of a database index is a b-tree, which is known in the art. An implementation consistent with the present invention does not depend upon any particular type of database index and may be used with any index or ordered method of storing data for retrieval.

User Interface for Managing Index Groups

An implementation consistent with the present invention relates to a user interface for specifying and managing index groups over classes. A "user interface" refers to a mechanism to view a representation of information in a computer system, such as computer 101, .and to enter information into the computer system. The input information may include commands instructing the computer to perform a particular function.

Figure 6 illustrates an example of such a user interface 600. Video display 112 may present user interface 600 in order to permit a user to view information relating to index groups, and a user may use input device 110, such as a cursor-control device, to enter or modify information through user interface 600. Index groups defined through user interface 600 are typically stored in computer 101 such as in memory 104 or secondary storage 106. The appearance and structure of user interface 600 are only one such example of a user interface for accomplishing functions relating to index groups, and implementations consistent with the present invention include any mechanism to display and enter information relating to index groups.

When a user selects index group tab 613, the user may enter and define index groups for particular classes, shown in a section 601. A "section" refers to an area of a user interface in which a system presents information or receives information from a user. The act of selecting may include using a cursor-control device to "click on" or "double click on" a particular item in the user interface. User interface 600 includes section 601 in order to illustrate fields of a particular class representing data in a database. A user may select the boxes next to the classes in order to expand the listing and view information related to each class, including fields of the class and index groups defined for the class. For example, a class Customer 615 is shown as having a number of fields 616 and as associated with one or more index groups 602. In this example, one index group new_item 603 is defined for class Customer 615. When a user selects index group 603, a section 604 presents the corresponding index group and a section 606 presents the fields of class Customer 615. A user may select other classes in section 601 in a similar manner, and fields for those classes are also presented in section 606 when corresponding classes are selected.

A field 607 permits the user to enter a name or update a name for an index group, and a field 608 provides another section 609 permitting a user to select an identification of the index group as unique or non-unique. A unique index group is one in which no duplicate values may exist among the data elements in the index data structure, .and a non-unique index group is one which permits duplicate values. If a unique index group is defined over multiple columns or fields, no duplicates may exist in the combination; in other words, the combination of data elements in the selected columns or fields must be unique. A section 614 includes both section 604 for listing index group names and section 605 for identifying whether corresponding index groups are unique or non-unique. Sections 606 and 614 include scroll bars so that a user may scroll through index groups or fields if there is insufficient room to illustrate all the index groups or fields within the corresponding section.

A user may perform functions on index groups by selecting buttons 610-612. In particular, by selecting update button 610, a user may update a defined index group, and by selecting new button 611 , a user may define and enter a new index group. In order to update an index group or define a new index group, a user selects the boxes next to the particular fields in section 606 in order to select or deselect those fields to include within the index group shown in section 604. When a user selects or "clicks on" a field or the box next to it, a check mark appears in the box next to the field in section 606 to indicate its selection. When a user "clicks on" the field again, or the box next to it, to deselect the field, the check mark disappears, indicating deselection of the corresponding field. Other types of indicators are possible for showing selection of a field, such as highlighting the field, displaying the field within a box or in a different color, or displaying some other type of icon next to the field. The user may also select a button within section 609 to identify the type of index group .as unique or non-unique, .and section 605 displays the selected type. In section 607, a user may enter a name of a new index group or modify the name of a defined index group, and the entered name is shown in section 604. When a user selects update button 610, the system saves the new index group or updates an index group according to the user's selections, and the new or updated index group is saved in the system .and presented within section 601 for the corresponding class. By selecting delete button 612, a user may delete a defined index group. In particular, a user first selects an index group in section 601 and then selects delete button 612, after which the system deletes that defined index group and removes it from section 601. Index Group Modules

Figure 7 is a block diagram of software modules for implementing the exemplary user interface shown in Figure 6. These modules may operate within the hardware elements shown in Figure 1. In system 700, user interface 600 is typically part of a mapping tool 701 such as ORMT 114. Mapping tool 701 includes a relational model 702, an obj ect model 704, and a mapping engine 703 for converting data between the relational model and the object model. Relational model 702 stores a representation of data from database 707 in tables, and object model 704 stores a representation of the data in objects. Relational model 702 may correspond to database data structure 115, and object model 704 may correspond to object model 116. Mapping tool 701 interacts with VM 705, which may correspond to VM 124. System 700 is connected to a database 707 or storing data in relational form, and database 707 may correspond to database 118. A user operating with user interface 600 interacts with mapping tool 701 in order to enter and define the index groups. Mapping engine 703 converts data between relational model 702 and object model 704, and may perform the mapping using the exemplary mapping tool described above. In performing the conversions, mapping engine 703 uses index groups defined through user interface 600 in order to map the index groups between the relational and obj ect models. The user-entered definitions of index groups may be saved, such as in memory 104 or secondary storage 106, and the system may associated the saved index groups with the corresponding classes according to known methods. Furthermore, user interface 600 need not necessarily be used with a mapping tool and may, alternatively, be used in general to specify index groups on a database. Figure 8 is a block diagram of software modules including a runtime illustrating the operation of applications on data within a database. These modules may operate within the hardware elements shown in Figure 1. System 800 includes one or more applications 801 performing transactions on data within database 707. Application 801 interacts with a Java runtime 802, which includes a runtime cache 803 storing one or more objects 804 and 805 and a transaction manager 806. Runtime 802 also interacts with VM 705. System 800 may also accesses data in database 707.

Objects are generated in runtime cache 803 as required by application 801, which accesses and operates on data within the objects. Transaction manager 806 tracks values to determine conflicts, as described, for example, in copending application of Tony Chun Tung Ng, filed on even date herewith, and entitled "User Interface for the Specification of Lock Groups." Deteπnming conflicts does not necessarily involve use of index groups. As application 801 requests data from database 707, system 800 determines if an index group exists for the requested data and, if so, it uses the index group to access an index for locating and retrieving the data. Index Group Processing

Figure 9 is a flowchart of an exemplary process associated with user interface 600 shown in Figure 6. This processing may be implemented by the modules shown in Figure 7 operating within the hardware shown in Figure 1. In process 900, a user selects index group button 613 in order to view the appropriate information on user interface 700 (state 901). The user selects a class and optionally selects an index group from section 601 (state

902) and then selects one of the buttons 610-612 (state 903). If the user selected new button 611, the user enters .an index group name in field 607 and selects one or more fields for the index group from section 606 (state 904). The user also selects whether the index group is unique or non-unique by selecting a button in section 609 (state 905). When the user selects update button 610 (state 906), the system determines if at least one field is selected in section

606 (state 907). If no field was selected, the system typically provides an error message (state 908), which may include presenting a section with a message indicating that at least one field must be selected. Otherwise, the system enters and stores the index group definition and adds it to the class listing in section 601 (state 909). A user may also update and delete index groups. To update an index group, a user selects fields for the index group using section 606 (state 910). When the user selects the update button, the index group is updated in accordance with the field selection and the selection concerning whether the index group is unique or non-unique, if at least one field was selected (states 905-909). If the user selected delete button 612 in state 903, the system deletes the definition for the selected index group .and removes it from the class listing in section 601 (state 911).

While the present invention has been described in connection with a preferred embodiment, many modifications will be readily apparent to those skilled in the art, and this application is intended to cover any adaptations or variations thereof. For example, other types of user interfaces and hardware for presenting the user interfaces, and other types of programming languages for implementing an embodiment consistent with the present invention, may be used without departing from the scope of the invention. This invention should be limited only by the claims and equivalents thereof.

Claims

WHAT IS CLAIMED IS:

1. A method of permitting a user to view index groups for a class structure corresponding to data stored in a database, comprising: providing a user interface having information representing the index groups; and selectively displaying information representing one or more of the index groups.

2. A method of defining .an index group for a class structure corresponding to data stored in a database, comprising: providing a user interface having information representing the data in the datab-ase; and receiving information for defining an index group associated with the data.

3. The method of claim 2 wherein receiving information for defining an index group includes receiving a request to update the defined index group.

4. The method of claim 2 wherein receiving information for defining an index group includes receiving a request to delete the defined index group.

5. The method of claim 2 wherein receiving information for defining .an index group includes receiving a request to classify the defined index group as a unique index.

6. An apparatus, comprising: a memory having program instructions for permitting a user to view index groups for a class structure corresponding to data stored in a database; and a processor, responsive to the progr.am instructions, to provide a user interface having information representing the index groups, and selectively display information representing one or more of the index groups.

7. An apparatus, comprising: a memory having program instructions for defining an index group for a class structure corresponding to data stored in a database; and a processor, responsive to the program instructions, to provide a user interface having information representing the data in the database, and receive information for defining .an index group associated with the data.

8. The apparatus of claim 7 wherein the processor is further configured to receive a request to update the defined index group.

9. The apparatus of claim 7 wherein the processor is further configured to receive a request to delete the defined index group.

10. The apparatus of claim 7 wherein the processor is further configured to receive a request to classify the defined index group as a unique index.

11. A computer-readable medium containing instructions for use in permitting a user to browse index groups for a class structure corresponding to data stored in a database, the method comprising: providing a user interface having information representing the index groups; and selectively displaying information representing one or more of the index groups.

12. A computer-readable medium containing instructions for use in defining -an index group for a class structure corresponding to data stored in a database, the method comprising: providing a user interface having information representing the data in the database; and receiving information for defining an index group associated with the data.

13. The computer-readable medium of claim 12 wherein receiving information for defining an index group includes receiving a request to update the defined index group.

14. The computer program product of claim 12 wherein receiving information for defining an index group includes receiving a request to delete the defined index group.

15. The computer program product of claim 12 wherein receiving information for defining an index group includes receiving a request to classify the defined index group as a unique index.

16. An apparatus for permitting a user to browse index groups for a class structure corresponding to data stored in a database, comprising: means for providing a user interface having information representing the index groups; and means for selectively displaying through the user interface information representing one or more of the index groups.