Systems and methods for representing and editing multi-dimensional data

[00002] This invention relates generally to real-time data structures for managing multi-dimensional data. More specifically, the present invention provides systems and methods for representing, editing, and operating on multi-dimensional data efficiently without requiring extensive user training.

[00003] The advent of the Internet and Information Technology (“IT”) has revolutionized the way business is conducted around the world. Business organizations have adopted these technologies to organize their structure, work flow and business relationships and to make their business processes increasingly more efficient. In particular, these technologies have become instrumental in enabling business organizations to manage the large amount of data transacted by them on a daily basis.

[00004] Efforts to optimize a wide variety of business processes have led business organizations to demand an increased granularity and complexity in the data that is input into their information systems. The data generated by a given business organization is typically stored in various databases across the business organization's information systems. A database is a collection of data that is organized so that its contents may be easily accessed, managed, and updated. The data stored in a database and the algorithms used to manipulate the data are represented in computer memory by a data structure, such as a queue, linked list, stack, heap, tree, or hash table, among others.

[00005] The most prevalent type of database is the relational database, organized as a set of formally-described tables from which data may be accessed or reassembled in many different ways without having to reorganize the tables. Each table, also referred to as a relation, contains one or more data categories in columns. Each row in the table contains a unique instance of data for the categories defined by the columns. For example, an electronic commerce web site such as Amazon.com, of Seattle, Calif., may have a relational database to describe customers' orders. The relational database may include a table to store customers' personal information with columns for the customers' name, address, and credit card, and another table to describe the order itself, with columns for the product bought, its price and quantity. The rows in the tables would contain the instance of information for a particular customer and customer's order.

[00006] Data may be queried from a database using a standard application program interface called Structured Query Language (“SQL”). SQL enables an user to select, insert, delete, update, and find out the location of data, among other data operations. The user may specify SQL statements to manipulate data in a database as part of a relational database management system (“RDBMS”), which is a technology platform, set of services, or application for creating, updating, and administering a relational database. Examples of commercially available RDBMSs include DB2, sold by IBM Corporation, of White Plains, N.Y., Oracle 9i Database, sold by Oracle Corporation, of Redwood Shores, Calif., and OpenIngres, sold by Computer Associates International, Inc., of Islandia, N.Y. Alternatively, business organizations may use spreadsheet software applications such as Excel, sold by Microsoft Corporation, of Redmond, Wash., to emulate a RDBMS.

[00007] Business organizations often use commercially available RDBMSs to manage databases storing their customer, supplier, and internal data such as accounting and financial information, employees' records, inventory, and legal records, among others. Additionally, business organizations in industries such as construction and manufacturing may require more specialized RDBMSs to manage activity-based costing data involving various business activities and the determination of costs and cost drivers for each activity. An example of activity-based costing data includes the material and labor costs of a construction unit or the costs generated by a given purchase order or machine use. Commercially-available activity-based costing RDBMSs include Prolog Manager and Prolog Scheduler, sold by Meridian Project Systems, Inc., of Folsom, Calif., and the OneWorld software package, sold by J. D. Edwards & Company, of Denver, Colo.

[00008] A primary function of these activity-based costing systems is to highlight variances between actual costs and budgeted costs on an ongoing basis. To ensure accurate and consistent calculation of actual costs, these systems implement database queries that require the consideration of a large number of variables. These variables can include resource identification and classification, project, phase and task references, cost code references, and date and time, among others. Transactions that drive the calculation of actual costs in these systems must accurately record each of these variables in order to generate the correct results.

[00009] Using RDBMSs for such diverse purposes requires business organizations to invest a considerable amount of resources to train IT staff to manage the databases. Few of the RDBMSs available today allow an unsophisticated IT staff member to enter, view, and maintain multi-dimensional data efficiently and with a minimum of training. Multi-dimensional data consist of multiple data records that share a common field value. For example, in a customer database for an electronic commerce web site such as Amazon.com, of Seattle, Wash., the field “customer phone number” may be associated with multiple phone number records such as a home phone number, a work phone number, and a cellular phone number. While multi-dimensional data can be stored in a relational database, such data is more suitably stored in a multi-dimensional database that organizes the data according to their dimension. In the customer database example, a relational database would represent the different phone numbers by repeating the customer phone number field for each phone number record so that each phone number record would be in a different row in the table. In contrast, a multi-dimensional database would have a single row for the customer phone number field and multiple cells corresponding to the different phone number types, i.e., home, work, and cellular extending along a dimension that is logically orthogonal to the row/column dimensions of a standard table. Each multi-dimensional database is implemented to handle large amounts of data that are organized and queried in numerous ways, requiring the IT staff to create complex SQL programs to manipulate the data.

[00010] Additionally, the user interfaces provided with such RDBMSs are predominantly text based, have limited display areas, and require considerable training before an IT staff member can become proficient in their use. For example, activity-based costing RDBMSs become increasingly inefficient when the raw data contains many variables, or the resources are frequently applied to more than one activity within a recording period. The most efficient activity-based costing RDBMSs capture raw data in tables where each row represents one or more transactions and each column records or summarizes a different variable. Every time a variable changes value, either a new row is added to the table or another user interface screen is opened to show a details table wherein a new variable detail row is added.

[00011] To conserve display space, variable values are often represented using a shorthand code that is often numeric and non-descriptive, which leads to a cryptic display that is meaningless to IT staff members not familiar with the coding conventions. And despite this abbreviated representation technique, most solutions still require horizontal scrolling in the user interface to display all of the variables required by the transaction. Finally, given the repetitiveness of variables between rows, considerable time is spent entering repeated values and determining which variables are unique to a given row.

[00012] As a result of these difficulties with existing RDBMSs, several business organizations have elected to utilize expensive and specialized intermediaries to collect and transpose data into their information systems. The intermediaries function as applications service providers (“ASPs”) to enable the business organization to outsource its IT needs with the goal of minimizing the complications its own IT staff has to deal with when managing a RDBMS. Such an arrangement may be attractive for smaller organizations with limited IT resources or for larger organizations not interested in maintaining a large in-house IT staff. In both cases, however, the business organizations are still required to train employees to use the often cryptic and cumbersome user interfaces designed by the ASPs to manage the organizations' data. The same training and user interface difficulties found in commercially available RDBMSs are encountered with the solutions provided by ASPs. Furthermore, it may be more expensive for a business organization to outsource its IT database needs to an ASP than to purchase an off-the-shelf RDBMS due to the high consulting fees charged by the ASP to train a business organization's employee to use the ASP system.

[00013] Efficiently solving these database management difficulties requires building a RDBMS with a user interface that optimally uses a limited amount of display area to present information such that an IT staff member or other user is not required to navigate within or between large numbers of data entry screens to enter or view information. The interface should intuitively display information such that an unsophisticated user can be trained to use the RDBMS in a relatively short period of time. Additionally, to be as efficient as possible, the RDBMS must also recognize and capitalize upon opportunities to take advantage of as many data entry patterns as can be effectively automated.

[00014] In view of the foregoing, it would be desirable to provide systems and methods for representing, editing, and operating on multi-dimensional data efficiently without requiring extensive user training.

[00015] It further would be desirable to provide systems and methods for representing, editing, and operating on multi-dimensional data in a limited display area with graphical icons that identify different data units.

[00016] It also would be desirable to provide systems and methods for representing, editing, and operating on multi-dimensional data in a compact form by constraining data entered in a table to be within a given data context.

[00017] It also would be desirable to provide systems and methods for representing, editing, and operating on multi-dimensional data in a compact form so that there is no display repetition of multi-dimensional data in a given table.

[00018] In view of the foregoing, it is an object of the present invention to provide systems and methods for representing, editing, and operating on multi-dimensional data efficiently without requiring extensive user training.

[00019] It is a further object of the present invention to provide systems and methods for representing, editing, and operating on multi-dimensional data in a limited display area with graphical icons that identify different data units.

[00020] It is also an object of the present invention to provide systems and methods for representing, editing, and operating on multi-dimensional data in a compact form by constraining data entered in a table to be within a given data context.

[00021] It is also an object of the present invention to provide systems and methods for representing, editing, and operating on multi-dimensional data in a compact form by constraining data entered in a table so that there is no display repetition of multi-dimensional data in a given table.

[00022] These and other objects of the present invention are accomplished by providing systems and methods for representing, editing, and operating on multi-dimensional data efficiently, compactly, and in real time with an intuitive graphical user interface (“GUI”). The multi-dimensional data is stored in a multi-dimensional database (“MDB”) that is accessed by the GUI. Both the MDB and GUI are platform-independent and may be implemented using different programming languages, operating systems, and hardware. The MDB and GUI may be offered as a service by an ASP or as an off-the-shelf RDBMS.

[00023] In a preferred embodiment, multi-dimensional data is represented with a composite tree data structure. The tree root and fundamental data element that is input, managed, and rendered is referred to as an event. An event is used to describe the association of a specific context with a specific date, time, and quantity. The context of an event is described by assigning values into a fixed set of reference variables called dimensions. Context dimensions may consist of an item, class, work, reference, and unit, among others. Frequently used dimension values are organized into workgroups. Different combinations of item, class, work, reference, and unit can be saved and assigned a descriptive workgroup name so that they can be conveniently recalled by an user using a simple GUI navigational control. Additionally, easily recognizable graphical icons are used to represent different items to facilitate user's management of multi-dimensional data.

[00024] A business organization may use the composite data structure to record and manage data that are significant to various monitoring and control functions within one or more related business entities. For example, an event corresponding to a specific assembling task performed by a manufacturing employee might describe the time the employee spent to assemble a given quantity of auto parts. In this example, the specific employee and task references define the event's context, while the quantity of parts assembled represents the event's quantity. The context's item may indicate that the event refers to a labor component of the manufacturing process, the context's class may indicate that the labor component was part of the assembly team, the context's sub-item may indicate that the assembly team used a certain equipment to assemble the auto parts, the context's work may indicate that work was performed on the electrical components of a specific auto model, and the context's unit may indicate the quantity of parts that were assembled.

[00025] The functionality for rendering and recording event information is implemented in an Event Viewer Module (“EVM”) in the GUI. The EVM enables an user to add or remove values within contextual dimensions and enter or delete quantities associated with a context. The user may edit and review events for arbitrary periods of time using simple GUI navigational controls. Event edits may be automatically or manually saved into the MDB associated with the GUI.

[00026] Advantageously, the systems and methods of the present invention enable a business organization to represent, edit, and operate on multi-dimensional data efficiently, compactly, and in real-time without requiring extensive user training. In addition, the systems and methods of the present invention also enable a business organization to manipulate multi-dimensional data in a limited display area using an intuitive GUI. Users may manage a large amount of data by interacting with the EVM in the GUI without having to create complex SQL queries commonly used in prior art RDBMSs or without having to become proficient in the often cumbersome and cryptic text-based GUIs of an RDBMS solution provided by an ASP.

[00044] Referring to FIG. 1, a schematic diagram of the network environment in which the systems and methods of the present invention operate is described. Multidimensional database (“MDB”) 20 is a multi-dimensional database for storing multi-dimensional data having many variables or dimensions. As used herein, the multi-dimensional data consist of data transacted by a business, educational, non-profit, or governmental organization. In a preferred embodiment, MDB 20 contains a variety of tables, with each table containing one or more data categories or fields in its columns. Each row in the table contains multiple instances of data for the categories defined by the columns. For example, an automobile manufacturer such as Ford Motor Company, of Dearborn, Mich., may use MDB 20 to include a table to store employee information of Ford's SUV division, a table to store employee information of Ford's truck division, and a table to store SUV and truck inventory information on a quarterly basis.

[00045] Data stored in MDB 20 is represented in computer memory by a data structure such as a queue, linked list, stack, heap, tree, or hash table, among others. In a preferred embodiment, data stored in MDB 20 is represented by a composite tree data structure as described below. Data stored in MDB 20 is accessed by IT staff members or other users in a business, educational, non-profit, or governmental organization by using graphical user interfaces (“GUI”) 30a-d.

[00046] GUIs 30a-d access data in MDB 20 through server 25. Server 25 and MDB 20 may be a part of the organization's information systems or maintained by an external ASP. In the first case, the organization may pay for purchasing, licensing, and/or maintenance fees of the hardware and software required by MDB 20 and GUIs 30a-d. In the second case, the organization may pay for the installation, maintenance, and consulting fees charged by the ASP as well as for service fees accrued when the organization's IT staff members and users interact with GUIs 30a-d to enter, view, and maintain data on MDB 20.

[00047] Training for the organization's IT staff members and users is kept at a minimum as a result of the intuitive, efficient, and compact design of MDB 20 and GUIs 30a-d. Both MDB 20 and GUIs 30a-d are platform-independent and may be implemented using different programming languages, operating systems, and hardware. It should be understood by one skilled in the art that MDB 20 and server 25 may comprise additional MDBs and servers located within the business organization's information systems or in the ASP.

[00048] Referring now to FIG. 2, a schematic diagram of an alternative embodiment of a network environment in which the systems and methods of the present invention operate is described. In this alternative embodiment, GUI 45 is accessed directly on a server that connects to MDB 40. This alternative may be used in smaller organizations with lower IT budgets. It should be understood by one skilled in the art that GUI 45 may be installed on one or more computers that function as servers to enter and maintain data stored in MDB 40.

[00049] Referring now to FIG. 3, an exemplary composite tree data structure to represent multi-dimensional data in accordance with the principles of the present invention is described. Data structure 50 is an exemplary composite tree data structure used to represent multi-dimensional data pertaining to the allocation of labor, equipment, and material to project cost centers in business, educational, non-profit, and governmental organizations. Data structure 50 may be used, for example, by a construction contractor to track costs for various constructions projects, by a university to track costs for a research study, or by a local government to track costs for community projects.

[00050] The fundamental data element of data structure 50 that is input or entered in the MDB, manipulated by a user, and rendered or displayed in the GUI is event 55. Event 55 is the root of tree data structure 50, and is further represented by context 60, date 65, time 70, and quantity 73. Context 60 of event 55 is described by assigning values into a fixed set of reference variables called dimensions, date 65 is described by assigning a single value into a date variable, time 70 is described by assigning a single value into a time variable, and the quantity is described by assigning a single value into a numeric variable. Context 60 dimensions consist of five variables, namely: (1) item variable 75; (2) class variable 80; (3) work variable 85; (4) reference variable 90; and (5) unit variable 95.

[00051] In the construction contractor example above, event 55 may be used to describe the time an employee spent working on a house being renovated by the contractor. In this example, the specific employee and task define event 55's contextual dimensions while the value of time 70 represents event 55's quantity. Item variable 75 may represent the employee, class variable 80 may identify the employee as a painter, work variable 85 may specify work done on the exterior part of the house, reference variable 90 may identify the house with a reference code, and unit variable 95 may specify that the time spent by the employee on the particular task was during regular business hours.

[00052] Different combinations of item variable 75, class variable 80, work variable 85, reference variable 90, and unit variable 95 may be saved and assigned a descriptive workgroup name so that they can be conveniently recalled by an user using a simple GUI navigational control within the GUI. In the construction contractor example, a workgroup may be used to identify all the painters working for the contractor. Additionally, easily recognizable graphical icons are used to represent item variable 75 to facilitate user's management of multi-dimensional data.

[00053] The functionality for rendering and recording event information is implemented in an Event Viewer Module (“EVM”) in the GUI. The EVM enables an user to add or remove values within contextual dimensions and enter or delete quantities associated with context 60. The user may edit and review event 55 for arbitrary periods of time using simple GUI navigational controls. Edits on event 55 may be automatically or manually saved into the MDB associated with the GUI.

[00054] Item 75 variable is categorized into four item types, namely, labor item 100, equipment item 105, material item 110, and expense item 115. In the construction contractor example, labor item 100 may represent an employee, equipment item 105 may represent an equipment used by the employee to perform a particular task, material item 110 may represent the material used by the employee in performing the task, and expense item 115 may represent subsistence expenses such as food, transportation, etc., allocated to the employee during a workday.

[00055] Class variable 80 is categorized into labor classification 120, equipment classification 125, material classification 130, and expense classification 135. Further, labor classification 120 may have optional sub-item 140 to indicate additional items such as equipment item 105, material item 110, or expense item 115 pertaining to labor classification 120. If the value of item variable 75 corresponds to labor item 100, then the value of class variable 80 may only correspond to labor classification 120. Similarly, if the value of item variable 75 corresponds to equipment item 105, material item 110, or expense item 115, then the value of class variable 80 may only correspond to equipment classification 125, material classification 130, or expense classification 135, respectively.

[00056] In the construction contractor example, labor classification 120 may indicate the type of construction work performed by an employee, such as painting, plumbing, and electrical, among others. Equipment classification 125 may indicate the type of equipment used, material classification 130 may indicate the type of material used, and expense classification 135 may indicate the class of expenses expense item 115 falls into.

[00057] It should be understood by one skilled in the art that tree data structure 50 may have other tree branches not shown in FIG. 3. For example, tree data structure 50 may have context dimensions that correspond to activity-based costing functions specific to business, educational, non-profit, or governmental organizations. Additionally, it should be understood by one skilled in the art that tree data structure 50 may represent its tree root by a fundamental data element other than event 55.

[00058] Referring now to FIG. 4, an exemplary view of a GUI screen shot showing the display of an EVM designed in accordance with the principles of the present invention is described. EVM display 145 implements the functionality for rendering and recording information about event 55. EVM display 145 shows a main screen that is divided into six discrete areas: (1) fixed area 150; (2) fixed header 170; (3) fixed footer 190; (4) vertically scrolling area 210; (5) vertically and horizontally scrollable area 215; and (6) vertically scrollable area 220. The design of EVM display 145 into these six discrete areas enables an IT staff member or other user to operate on multi-dimensional data in a limited display area efficiently, compactly, and in real-time without requiring extensive user training.

[00059] Fixed area 150 implements control 155 for navigating between date ranges, control 160 for selecting workgroups, and control 165 for selecting date view configurations. Below fixed area 150 is fixed header 170 that has nonscrolling area 175 on the left to display static dimension column labels, horizontally scrolling area 180 in the center that displays dynamic date column labels, and nonscrolling area 185 on the right that displays a static total column label.

[00060] At the bottom of the main screen is fixed footer 190 that has nonscrolling area 195 on the left that displays dynamic row labels, horizontally scrolling area 200 in the center that displays dynamic calculated totals for each date column and footer row, and nonscrolling area 205 on the right that displays dynamically calculated totals for the totals column and for each footer row.

[00061] At the left of the screen is vertically scrolling area 210 that displays the values of contextual variables and static rows for displaying subtotal row labels. In the center of the screen is vertically and horizontally scrollable area 215 that displays the values of quantity variables and dynamic calculated subtotal rows. Finally, at the right of the screen is vertically scrollable area 220 that displays dynamic calculated totals for each row of quantity variables in center area 215.

[00062] Context 60 dimensions item variable 75, class variable 80, work variable 85, reference variable 90, and unit variable 95 are respectively displayed in columns 225a-e entitled “Item”, “Class”, “Work”, “Reference”, and “Unit” in nonscrolling area 175. Each cell in item column 225a represents the value of item variable 75 using the combination of an icon and a textual description, such as icon 230 and textual description 235. The values of item variable 75 in item column 225a are constrained such that they may only contain references to labor item 100, equipment item 105, material item 110, or expense item 115 that respectively correspond to labor classification 120, equipment classification 125, material classification 130, or expense classification 135 that are entered in class column 225b. The values of item variable 75 are further constrained such that the same value cannot be repeated within item column 225a.

[00063] Referring now to FIG. 5, an exemplary view of a GUI screen shot showing the display of an EVM with graphical icons for four different items is described. EVM display 240 shows four values of item variable 75 in item column 245. The four values are represented by distinct graphical icons to facilitate users' view and management of multi-dimensional data. Graphical icon 250 is used to identify item variable 75 as labor item 100, graphical icon 255 is used to identify item variable 75 as equipment item 105, graphical icon 260 is used to identify item variable 75 as material item 110, and graphical icon 265 is used to identify item variable 75 as expense item 115.

[00064] It should be understood by one skilled in the art that graphical icons 250, 255, 260, and 265 are used for the purposes of illustration only. Different graphical icons than the ones shown in FIG. 5 may be used to represent different item variables, and additional graphical icons may be used to facilitate users' view of multi-dimensional data in a given EVM display.

[00065] Referring back to FIG. 4, each cell in class column 225b represents the value of class variable 80 using a textual description, such as textual description 270. Textual description 270 may, for example, refer to a boilermaker (“BM”) and foreman (“FM”). The values of class variable 80 in class column 225b are constrained such that they may only contain references to labor classification 120, equipment classification 125, material classification 130, or expense classification 135. The values of class variable 80 are also constrained such that the same value cannot be repeated within the set of cells that is to the right of a cell in item column 225a.

[00066] As mentioned above, the values of class variable 80 are further constrained based on the values that are represented in item column 225a. If a cell in item column 225a contains labor item 100, then the corresponding cell in class column 225b may only contain labor classification 120. Similarly, if a cell in item column 225a contains equipment item 105, material item 110, or expense item 115, then the corresponding cell in class column 225b may only contain equipment classification 125, material classification 130, or expense classification 135, respectively.

[00067] As shown in area 275, there may be one or more cells representing labor classification 120 in class column 225b to the right of a cell in item column 225a containing labor item 100. Labor classification 120 may contain optional sub-item 140, such as sub-item 280. Each cell containing sub-item 140 represents the values of sub-item 140 with a graphical icon and a textual description. Cells containing optional sub-item 140 are constrained such that they may only contain references to equipment item 105, material item 110, or expense item 115. These cells are also constrained such that a value for a given sub-item is not repeated.

[00068] Further, cells containing optional sub-item 140 are only permitted inside of cells in class column 225b containing labor classification 120. There may be only one cell in class column 225b containing equipment classification 125, material classification 130, or expense classification 135 to the right of a cell containing equipment item 105, material item 110, or expense item 115, respectively.

[00069] Context 60 dimension work variable 85 is displayed to the immediate right of class column 225b at work column 225c. Each cell in work column 225c represents the value of work variable 85 using the combination of an icon and a textual description. The values of work variable 85 in work column 225c are constrained such that they may only contain references to work objects. The values of work variable 85 are also constrained such that the same value cannot be repeated within the set of cells that is to the right of a class or sub-item cell in class column 225b. Further, there may be one or more cells to represent work variable 85 to the right of every class or sub-item cell in class column 225b.

[00070] Finally, context 60 dimension reference variable 90 is displayed at reference column 225d to the immediate right of work column 225c and context 60 dimension unit variable 95 is displayed at unit column 225e to the immediate right of reference column 225d. Each cell in unit column 225e represents the value of unit variable 95 using a textual description. The value of unit variable 95 is constrained such that it may only contain references to unit objects. The value of unit variable 95 is also constrained such that the same value cannot be repeated within the set of cells that is to right of cells in work column 225c. As shown in unit column 225e, there can be one or more cells to the right of every cell in work column 225c.

[00071] At the bottom of contextual dimensions area 175 is fixed footer 195 that contains one row for each distinct item variable 75 that is referenced in item column 225a. These rows are labeled with a static item type, which can either be labor item 100, equipment item 105, material item 110, or expense item 115, and a dynamically calculated count of how many items of the specific type presently occupy cells within item column 225a.

[00072] Quantities that are recorded for item variable 75 in item column 225a are shown in horizontally scrolling area 180. Each column in area 180 represents a specific date. Dates are statically labeled at the top of each column and arranged from left to right in consecutive order. Each cell in these columns represents a single event by displaying a quantity and intersecting a specific context, as defined by the contextual cells that are adjacent and to the immediate left, and a specific date. Subtotals are automatically calculated for each row and displayed on the right hand side of EVM display 145. Subtotals are also calculated for each column for each distinct item type and displayed at the bottom of EVM display 145. Finally, subtotals are calculated within each column once for each distinct cell in item column 225a.

[00073] It should be understood by one skilled in the art that the above mentioned constraints prevent values from being unnecessarily repeated between rows. Where a value is constant between rows, the cell containing the value is expanded vertically to span across all of the rows sharing the common value. In addition to preventing the redundant display of information, this functionality also uses the extra vertical display space to display an extended textual description enhancing the overall legibility of the display. It will be further appreciated that the nested sub-item behavior also contributes to the overall conservation of display space by using a single column to represent multiple contextual dimensions.

[00074] Referring now to FIG. 6, an exemplary view of EVM navigational controls for selecting dates is described. Navigational controls 285 at the top of EVM display 190 enable users to set the first date of the column range by either typing in a specific date or selecting a date from a calendar. Navigational controls 285 also enable an user to page through consecutive sets of dates in either forward or reverse order.

[00075] Referring now to FIG. 7, an exemplary view of EVM navigational controls for selecting different views for dates is described. Navigational controls 295 at the top of EVM display 300 enables an user to switch between alternate view configurations. To support different usage patterns, certain parameters in EVM display screen 300 such as view configurations for dates may be configurable by the user via an external screen. The number of days to be displayed can range between one and seven. When an user selects seven days, they can also select which day of the week, Sunday through Saturday, the user wishes to always see as the leftmost day column. Different configurations of these parameters can be saved in the MDB and assigned a descriptive name so that they can be conveniently recalled by an user using a simple navigational control.

[00076] Referring now to FIG. 8, an exemplary view of EVM navigational controls for selecting workgroups is described. Navigational controls 305 of EVM display 310 enable users to select a workgroup based on a descriptive name, such as “Crew 1” and “Crew 2”. Users may select a workgroup to edit and review events for arbitrary periods in time.

[00077] Referring now to FIG. 9, a flow chart for editing data saved in the MDB by selecting a workgroup is described. The editing process begins at step 320 with the user using navigational controls 305 to select a workgroup to edit. Once a workgroup is selected, its contextual variables are examined at step 325 and used to prepare a query to retrieve event data with. At step 330, the user uses navigational controls 285 (FIG. 6) and 295 (FIG. 7) to select a data range for editing the contextual variables in the selected workgroup for a particular date.

[00078] Specifically, the values of item variable 75 of the selected workgroup are used in conjunction with the date range selected by the user to form a query that retrieves from the MDB (step 335) all events that reference any of the items in item variable 75 of the selected workgroup and reference a date within the selected date range. The retrieved events are sorted and rendered such that they conform to the dimension constraints previously described. Next, any combination of contextual values that is stored in the selected workgroup, but returned no events are also merged into the display. At step 340, the contextual values are displayed in the EVM. Once the values are displayed, the user may edit the values at step 345.

[00079] For example, if an user selects the workgroup referred to as “crew 1” shown in FIG. 8, EVM display 305 will first be erased and then the values of item variable 75 corresponding to crew 1 will populate EVM display 305 for a date selected for display by the user. Once the workgroup and date have been set and the MDB query has executed, returned and rendered on EVM display 305, the user may edit the values shown in EVM display 305. Editing operations include adding or removing values within contextual dimensions and entering or deleting quantities.

[00080] Referring now to FIG. 10, a flow chart for adding a new contextual dimension value to the MDB through the EVM is described. To add a value to a contextual dimension, the user must first select a target dimension cell at step 360 using either the mouse or the keyboard. Once a cell has been selected, the user can either enter a new value into the selected cell, or insert a new cell either above or below the existing cell using the keyboard (step 365). If a new cell is inserted such as cell 370 in EVM display 375 shown in FIG. 11, the cell to the immediate left is expanded at step 380 such that it vertically spans all the cells it spanned prior to the insertion plus the newly inserted cell. A new row of dimension and quantity cells is then created to the right of the newly inserted cell at step 385. For example, cell 390 (FIG. 8) is expanded to cell 395 to the left of inserted cell 370 and row 400 is added to the right of inserted cell 370 (FIG. 11).

[00081] When entering values into contextual dimensions using the keyboard, the user has the option of either entering a specific object code or a search string to locate the object of interest. That is, the user has the option to search the MDB for the values to be added (step 405). Alternatively, once the new cell has been inserted and selected, a new value can be entered into the cell using the keyboard at step 410.

[00082] If the user enters a specific object code at step 405, a MDB query is performed at step 415 to determine whether the object exists in the MDB or not (step 420). If the object exists, the cell is populated with a reference to its value and the display is updated at step 435. If the object does not exist an error message is displayed to the user at step 425. If the user enters a search string to locate the object at step 405, a MDB query is performed at step 415 to find all objects that match the search string. If a single object is returned by the query, the cell is populated with a reference to its value and the display is updated at step 435.

[00083] If more than one object is returned by the query (step 430), the user is presented with a new window at step 440 that displays a scrollable list of all the objects for the user to select from. An example of such a window is window 445 in EVM display 450 shown in FIG. 12. Once a selection is made (step 455), if the MDB query (step 415) doesn't return a match, an error message is displayed to the user at step 425. Otherwise, the cell is populated with a reference to its value and the display is updated at step 435.

[00084] It should be understood by one skilled in the art that alternate methods such as drag and drop could be implemented to add objects to contextual dimensions within a given EVM display.

[00085] Referring now to FIG. 13, a flow chart for removing a contextual dimension value from an EVM display is described. To remove a value, the user selects the cell to be removed at step 470 and presses an appropriate key on the keyboard. The user is next prompted to confirm their intention to delete the value (step 475). Once the user has confirmed their intention to delete the value, the cell is removed from the display at step 480 along with all cells to the right of the selected cell. If the cell being removed is not an item cell and is the last cell in the set of cells to the right of another dimension cell (step 485), a new row of empty dimension cells and quantity cells is created and displayed at step 490.

[00086] Referring now to FIG. 14, an exemplary view of an EVM display for removing a contextual dimension value is described. EVM display 495 shows that the values in cell 500 (FIG. 8) and in all the cells to the right of cell 500 have been removed. New row 505 has been created to contain empty dimension and quantity cells.

[00087] Referring now to FIG. 15, a flow chart for entering a new quantity in an EVM display is described. Once contextual dimensions have been assigned values by the user, quantities are then populated under specific intersections of context and date. To enter a quantity, such as quantity 510 in EVM display 515 shown in FIG. 16, the user selects a cell at step 525 that is to the right of the desired context and below the desired date. Once the cell has been selected, the user then enters a quantity using the keyboard (step 530). After a quantity has been entered or edited, all row totals, item sub-totals and column totals are automatically updated at step 535 to reflect the changes. After context and quantities have been entered, the user saves the event edits to the MDB at step 540 by selecting a command from a menu, by changing the workgroup selection or by changing the date selection.

[00088] Although particular embodiments of the present invention have been described above in detail, it will be understood that this description is merely for purposes of illustration. Specific features of the invention are shown in some drawings and not in others, for purposes of convenience only, and any feature may be combined with other features in accordance with the invention. Steps of the described processes may be reordered or combined, and other steps may be included. Further variations will be apparent to one skilled in the art in light of this disclosure and such variations are intended to fall within the scope of the appended claims.