Abstract:
A method of creating user-generated reports. The method begins with the step of receiving information related to consumer internet behavior. That information is then assembled into a database having facts and dimensions, in which the database resides on a server, the server being connected to a communications network. The method then provides a report generation system, including a report generation module resident on the server. The module generates a report, beginning with accepting user criteria for generating a report from a front end system resident on a client computer. It then generates from the database a dataset corresponding to the first report and forwards the same to the client computer, and it displays the report generated from the first dataset. The module then reiterates the report generation steps to generate a second report, the first report remaining resident on the client computer.

Description:
RELATED APPLICATION 
     This application is related to U.S. patent application Ser. No. 10/721,117, entitled “Database Structure and Front End,” naming Dominic Bennett and Dan Hu as inventors, filed on Nov. 25, 2003 (the “Bennett Disclosure”). That application is concurrently owned by the assignee hereof. 
     BACKGROUND OF THE INVENTION 
     The present invention relates to database employment and management. In particular, it relates to report generation and use in a client-server OLAP environment. 
     A problem with current database reporting systems is the inability of large-scale database systems to accommodate multiple reports on a client system. Reports in OLAP systems can be large and cumbersome, requiring considerable time to run, even on speedy systems, and considerable data storage resources when they are completed. Storage of multiple datasets used in the reporting process is generally not possible. 
     Further, as a corollary of that fact, users cannot run multiple reports simultaneously. That limitation poses particular problems to analysts who need to look at data from a number of viewpoints, requiring multiple reports. 
     The art has not approached these issues, creating a need that has remained unmet until the event of the invention claimed herein. 
     SUMMARY OF THE INVENTION 
     An aspect of the invention is a method of creating user-generated reports. The method begins with the step of receiving information related to consumer internet behavior. That information is then assembled into a database having facts and dimensions, in which the database resides on a server, the server being connected to a communications network. The method then provides a report generation system, including a report generation module resident on the server. The module generates a report, beginning with accepting user criteria for generating a report from a front end system resident on a client computer. It then generates from the database a dataset corresponding to the first report and forwards the same to the client computer, and it displays the report generated from the first dataset. The module then reiterates the report generation steps to generate a second report, the first report remaining resident on the client computer. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a client-server database environment as practiced in the art. 
         FIG. 2  depicts an embodiment of a client-server database environment according to the invention claimed herein. 
         FIG. 3  illustrates the detailed operation of an embodiment of a reporting module operating in accordance with the principles set out herein. 
         FIG. 4   a  illustrates a dataset model employed in an embodiment of the invention claimed herein. 
         FIG. 4   b  depicts report control windows as employed in an embodiment of the invention claimed herein. 
         FIG. 5  depicts another embodiment of a client-server database environment according to the invention claimed herein. 
         FIGS. 6   a - 6   c  depict report control windows as employed in an embodiment of the invention claimed herein. 
     
    
    
     DETAILED DESCRIPTION 
     The following detailed description is made with reference to the figures. Preferred embodiments are described to illustrate the present invention, not to limit its scope, which is defined by the claims. Those of ordinary skill in the art will recognize a variety of equivalent variations on the description that follows. 
     A client-server system for managing an OLAP database, including preparing reports based on the same, was presented in the Bennett Disclosure, cited above. The architecture taught there is summarized in  FIG. 1 , in which a client computer  100  is in communication with a server  110  using a communications channel  10 . In one embodiment, communication is established over a public communications network, such as the internet, but in other embodiments the communications path can be a dedicated local or wide area network, or a direct connection. 
     It will be understood that both the client and server computers operate a variety of software applications, such as operating systems, net browsers and various other programs. The present disclosure focuses on specific applications programs, and those are the only programs illustrated below. 
     The server  110  includes an OLAP database  12 , with a database management program  14  in operative communication with the same. The client system  100  includes a front end program  24 , devoted to interacting with the database manager  14 , as explained in the Bennett disclosure. One subsystem of the front end program is a reporter  26 , which accepts user commands and specifications related to report generation; receives a dataset  32  associated with the report; generates the report  34 , based on the dataset, user specific inputs, and preset user preferences; and displays the report to the user. 
       FIG. 2  contains a schematic diagram of an embodiment of a system according to the invention claimed herein. Here, in the interest of clarity, the client system and server system are not shown per se, but the components located on the client side are grouped under the bracket  100 , and those on the server side are grouped under bracket  110 . Generally, the server side contains an OLAP database  112  and database manager  104 , while the client aide includes, a front end program  114 . It is understood that both the server and client sides include a number of other software systems, many of which interact with the systems shown. For present purposes, understanding and clarity are promoted by focusing on the systems depicted. 
     One embodiment of the OLAP database  112  may comprise a set of hierarchy tables  120  (denoted here as  120 - 1 ,  120 - 2 , . . .  120 - n ), a dimension control table  122 , and a hierarchy control table  124 . Hierarchy tables  120  may comprise a database table configured to have dimensions and facts, with each fact being associated with a single dimension or combination of dimensions. Hierarchy tables  120  are arranged in a hierarchical topology, with the lowest level hierarchy table  120  having the most number of dimensions, the next higher level hierarchy table  120  having less dimensions than the lowest hierarchy table  120 , the next higher level hierarchy table  120  having less dimensions than the next hierarchy table  120 , and so on. That is, the hierarchy tables  120  may be configured as follows: 
     First Level (Lowest Level) Hierarchy Table:
         Dimension.sub. 1 , Dimension.sub. 2 , . . . Dimension.sub.n;   Fact.sub. 1 , Fact.sub. 2 , . . . Fact.sub.k.       

     Second Level Hierarchy Table:
         Dimension.sub. 1 , Dimension.sub. 2 , . . . Dimension.sub.n−1;   Fact.sub. 1 , Fact.sub. 2 , . . . Fact.sub.k.       

     Third Level Hierarchy Table:
         Dimension.sub. 1 , Dimension.sub. 2 , . . . Dimension.sub.n−2;   Fact.sub. 1 , Fact.sub. 2 , . . . Fact.sub.k
 
and so on. Note that a second level hierarchy table may have one less dimension than the first level hierarchy table, while a third level hierarchy table may have one less dimension than the second level hierarchy table. Further note that the number of facts in each hierarchy table does not necessarily have to be different.
       

     The hierarchical levels allow for faster data access in a level “n” compared to a level “n−1”. That is, data can be accessed faster in the higher levels. The idea is to minimize the number of rows by eliminating dimensions successively. The elimination of dimensions results in smaller tables, which results in faster data access. 
     In one embodiment, the dimensions and facts in hierarchy tables  120  relate to online advertising. The dimensions may include advertisements, campaigns, contracts, and other advertising data, and facts relate to specific exposures of advertising to consumers (“impressions”). As a further example, each advertisement may belong to one or more advertising campaigns, with each advertising campaign being associated with one or more contracts, and so on. The facts may include impressions (i.e., displaying of an advertisement) and clicks on impressions. Thus, for each particular value of advertisement, campaigns, contracts, or combinations thereof there may be a corresponding impressions value and clicks value. For example, a particular advertisement for a particular advertising campaign may have 2,000 impressions. As another example, a particular advertising campaign with an associated contract may have resulted in 4,000 impressions and 1,000 clicks on the impressions. Of course, the number and type of dimensions and facts, and their corresponding values, may vary to meet the needs of specific applications. 
     Each hierarchy table  120  may be structured with facts for a particular combination of dimensions. As a particular example, assume that an exhaustive list of dimensions consists of advertisement, advertising campaign, and contract, a first (lowest) level hierarchy table  120  will include facts (e.g., impressions, clicks, or both) for the dimensions advertisement, advertising campaign, contract, or combinations thereof. Then, a second level hierarchy table  120  will include facts for the dimensions advertisement, advertising campaign, or combinations thereof, and so on. That is, for a particular number of dimensions, a hierarchy table  120  exists, containing the corresponding facts. In one embodiment, hierarchy tables  120  are manually populated using data from a data warehouse (not shown). Hierarchy tables  120  may also be populated using a script, for example. As can be appreciated, extracting data from a hierarchy table is generally faster than extracting data from an entire database. Hierarchy tables  120  thus provide a database structure that advantageously allows for relatively fast data access. 
     It is important to understand that the front end  114  is “thought” about the exhaustive list of all dimensions and facts, the relationship between each dimension (i.e. the hierarchy), the table names of each level of aggregation and the dimensions available in each aggregate table, the type of each dimension i.e. free form, tree or list box by using control tables. Thus, the front end can be thought of in the nature of metadata concerning the contents of the OLAP database. 
     In one embodiment, a dimension in an OLAP database  112  may be one of three kinds of dimensions namely, “pull-down,” “tree,” or “free-form.” A pull-down dimension may have a value that is selectable from a pull-down menu. For example, assuming “advertisement” is a pull-down dimension, the values “Ad1” for a first advertisement or “Ad2” for a second advertisement may be selected in a pull-down menu for “advertisement.” A tree dimension may have a value that is selectable from a hierarchical tree structure. For example, assuming “category” is a tree dimension, the values “automotive” for web pages relating to automotives or “travel” for travel-related web pages may be selected in a tree structure for “category.” In the tree structure, the value “hotel” may be included as branching off the value “travel.” A free-form dimension may have a value that may be entered without choosing from available selections. For example, assuming “revenue” is a free-form dimension, allowing a user to enter any revenue amount for “revenue.” 
     As further shown in  FIG. 2 , the OLAP database  112  may include a dimensions control table  122 . A dimensions control table  122  may comprise an exhaustive list of all dimensions and facts in all hierarchy tables  120 , templates for constructing queries for each dimension, and a dimension look-up table. The dimension look-up table is employed in embodiments where the hierarchy tables  120  refer to dimensions using identifiers other than the dimensions&#39; actual names (e.g., using “d2345” in a hierarchy table  120  to refer to a dimension “advertisement”). The dimension look-up table allows for translation of an identifier to actual name, and vice versa. A dimensions control table  122  may also have information on the kind of each dimension (e.g., whether a dimension is a pull-down, tree, or free-form) and conditional operators that may be used for a particular dimension. 
     An OLAP database  112  may also include a hierarchy control table  124 . A hierarchy control table  124  may comprise information indicative of the data structure of the OLAP database  112 . In one embodiment, a hierarchy control table  124  identifies each hierarchy table  120 , the hierarchical order of the hierarchy tables  120 , and the dimensions included in each hierarchy table  120 . A hierarchy control table  124  may thus be consulted to identify the highest level hierarchy table  120  containing a particular set of dimensions and filters. Note that the highest level hierarchy table containing a particular set of dimensions and filters would advantageously have the least number of rows among hierarchy tables that also contain the set of dimensions and filters. 
     The general role of the front end is to optimally obtain that slice of the OLAP cube that contains all the data that the user is interested in viewing and displaying that slice of the OLAP cube in exactly the format that the user wishes to view. The filter page allows the user to slice the OLAP cube using criteria on the dimensions. The layout page allows the user to specify the format of the report. 
     Still referring to  FIG. 2 , a front end program  114  may comprise a user interface  130 , a scheduler  138 , and an alerts  139 . In one embodiment, a front end program  114  is implemented using the Microsoft Visual Basic For Applications™ (VBA) programming language. A user interface  130  may comprise computer-readable program code for allowing a user to enter selection criteria and generate a report in accordance with the selection criteria. The selection criteria may be values for dimensions and facts. A user interface  130  may comprise a layout screen  132 , a filter screen  134 , and a report screen  136 . 
     A layout screen  132  allows a user to select dimensions and facts of interest. The selected dimensions and facts will be the basis of a subsequently run report. Generally speaking, a layout screen  132  allows the user to specify the format of the report. 
     A filter screen  134  accepts dimensions that will be used as filters to the dimensions and facts selected in a layout screen  132 . The general role of a front end program  114  is to optimally obtain that slice of an OLAP cube that contains all the data that the user is interested in viewing, and displaying that slice of the OLAP cube in exactly the format that the user wishes to view. In that regard, a filter screen  134  allows the user to slice the OLAP cube using filters on the dimensions. 
     In one embodiment, a front end program  114  has minimal processing load to allow it to adapt to a changing OLAP database  112  and to allow it to be more portable to other databases. Accordingly, in one embodiment, a front end program  114  works in a client-server relationship with an OLAP database  112  and is driven by tables in the OLAP database  112 . This advantageously obviates the need for hard coding of available dimensions in the front end program  114  and offloads the processing burden to the OLAP database  112  (which may be running in a relatively fast server computer). For example, the front end program  114  may receive a dimensions control table  122  and display the exhaustive list of dimensions and facts in the dimensions control table  122  in a separate window. 
     A front end program that offloads the majority of processing to a server computer is especially important in online advertising. Unlike in mail order or catalog advertising applications, advertisement delivery over the Internet is essentially free in that an advertiser can send additional advertisements without incurring substantial additional cost. This results in a relatively large volume of impression data. A front end program  114  advantageously allows a client computer to access large amounts of data by using a back end server to do the “heavy lifting.” This will have the desirable effect of scalability by essentially scaling the back end as opposed to being reliant on client computer resources (which in many ways are outside the control of the programmer). This also allows for robust programming and the ability to retrieve data even with relatively old or low capacity client computers. 
     A reporter  136  provides a report based on the dimensions and facts selected by a user in a layout screen  132  as filtered by the dimensions the user selected in a filter screen  134 . The result may be viewed in a reporter  136 . The dimensions for the report may be further configured by specifying new dimensions. An OLAP database  112  may have to be re-queried if the saved view does not include the data for the new dimensions, or if the user elects to rerun the view. 
     In the reporting system of the prior art, shown in  FIG. 1 , the front end  24  includes a reporter module  26 , which interacts with the front end to structure queries to the database manager, to receive and temporarily store a dataset  32  in response to the query, and to organize and display a report  34  responsive to a user request. A weakness of the reporters of the prior art, however, is that they are able to work with only one report at a time. Only a single report is shown in  FIG. 1 , because when another report is desired, the existing report must be shut down and a new one initiated. 
       FIG. 3  illustrates the operation of the report generation system according to the invention claimed herein. First, in addition to the database manager  104  and the database  112  on the server, there is added an independent report manager  116 . This module interacts and communicates with the client report manager, as explained in detail below. On the client computer, the reporter module  136  is given the capability of generating multiple simultaneous reports, as illustrated by Report  1   152  and Report  2   154 , depicted as existing simultaneously. Each report is supported by and based on a dataset retrieved from the OLAP database, identified as datasets  162  and  164 , respectively. 
     Datasets  162  and  164  are preferably structured as shown in the data diagram  FIG. 4   a . In this embodiment, the dataset class  410  consists of a hierarchical structure with dataset collection  412  at the top, and in descending structures dataset item  414 , report collection  416 , report item  418  and filter  420 . Members of a dataset item are objects, so that specific instances of report items, such as background report  416   a  and scheduled report  416   b  are independent constructs that stand on their own. Such report items can be displayed as independent screen windows  460 , shown in  FIG. 4   b . Additional information concerning the object controls is set out below, but those in the art will understand that each of the windows can be viewed and manipulated separately. 
     Alternatively, it may be advantageous to run a report on the server rather than on the client computer. To provide for that eventuality, there is provided a remote report manager module  138 , a component of reporter  136 , shown in  FIG. 5 . As shown there, the remote report module communicates via the network to the report manager  116 , resident on the server. The report manager retrieves a first dataset  262 , which it then employs to structure a first report  252 . The report module has the capability to generate multiple reports, based on multiple datasets. Here, a second report  254 , based on a second dataset  264 , are shown, and it is understood that a multiplicity of such reports can be run. 
     Generation and display of reports can be controlled as shown in the screenshots of  FIGS. 6   a - 6   c . The displayed embodiment illustrates one method for embodying a screen control for datasets and reports. Here, it will be understood that the specific screen controls operate in a generally straightforward manner, common to such controls in general use. Thus, functionality of such controls will not be set out in detail herein. Further, it will also be understood that a variety of techniques exist for embodying such controls. User interface designers will each choose different specific arrangements of controls to accomplish the tasks set out herein, and except as set out, any of the arrangements known in the art will suffice. Operation of the system as a whole is the key to the present invention, rather than specific characteristics of screen controls. 
     A basic report control window  602  is shown in  FIG. 6   a . In this embodiment the window employs a tab control that allows different functionalities to be invoked from a single window. To configure a report, the Filter tab is selected, which allows the user to specify report contents and parameters, such as the date range, standard criteria sets and custom criteria. The latter information can be specified by specific field. The user can choose where the report is to be run, on the local computer, using the “Run Report” button, or on the server, via the “Background Rpt.” button. 
       FIG. 6   b  shows the same window in a different view, showing the Background tab. This button facilitates production of a single report, as shown. Management of all reports submitted can be accomplished in a separate window, shown in  FIG. 6   c . That figure illustrates the Background Process tab, which shows the status all reports in the server queue. Other buttons allow the user to examine other aspects of the reporting system, as shown. 
     While the present invention is disclosed by reference to the preferred embodiments and examples detailed above, it is understood that these examples are intended in an illustrative rather than in a limiting sense. It is contemplated that modifications and combinations will readily occur to those skilled in the art, which modifications and combinations will be within the spirit of the invention and the scope of the following claims.