Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-04-04
2004-08-10
Metjahic, Safet (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
Reexamination Certificate
active
06775675
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to data analysis and presentation and more particularly to a system and method for analyzing, aggregating and presenting an unlimited amount of data as customizable and easily modified reports, generally used for business intelligence purposes.
2. Description of the Related Art
Vast amounts of data are available for corporations concerning their customers. A business has numerous contact points with customers including but not limited to the Internet, Interactive Voice Response (IVR) systems, private company databases, and Enterprise Resource Planning (ERP) systems. Each of these customer contact points contains data capable of being mined and presented for business intelligence purposes.
The Internet has allowed unlimited access for customers to a company's web site. This unlimited access creates a wealth of information in the form of web log files. Companies can use the web log files to extract information concerning the customers use of the web site.
An organization may have a phone system capable of Interactive Voice Response that customers routinely access. Data stored in the IVR data files can be presented to provide a profile of a customer's use of the IVR system. In addition, private company databases also contain data files that can be mined and presented for business intelligence purposes.
Typically a business will have in-house databases containing accounting, financial and sales data. These in-house databases are commonly referred to as ERP systems and are a valuable source of financial data.
It can be appreciated that there are a large number of sources containing data that can be aggregated by businesses to analyze customer interactions. The data contained in each of the above referenced databases consists of various data file types (i.e., varying data format). Even within the same database the file types may differ. Under current practices, the presentation of multi-dimensional data (e.g., cubes) from the various data files yields rigid reports incapable of being easily modified.
With the wealth of data available, it is necessary to create meaningful reports that integrate and parse the data in a manner that will reveal a coveted relationship. Because of the overwhelming amount of data available, it is necessary to manipulate the data so that the presentation of the data will capture the essence of a previously unknown relationship. Accordingly, the customer will need the capability to modify an interactive presentation so that the data is viewed from all angles in real-time.
Presentation of the data can take the form of a two dimensional report (e.g., using spreadsheets or tables) or a multi-dimensional report (e.g., using cubes). In a multi-dimensional presentation, a cube may be displayed. Under current practices, the cube is displayed from a defined data set through an online analytical processing (OLAP) system. An OLAP data cube can be presented as a multi-dimensional cube representing any number of descriptive categories or business metrics (dimensions) and quantitative values (measures). An example of a dimension could be a time dimension such as the number of visits to a sports web site in a day, week month or year time frame, while a measure could be the number of times a Uniform Resource Locator (URL) has been viewed (page-views), the number of times a URL has been used as an entry page (entrance) or the number of times a URL has been used as an exit page (exit). A dimension may further be defined as a sub-dimension or level. For example, a sports web site may be subdivided into a particular sport such as football or baseball.
Current OLAP systems demand that once the customer defines the dimensions of the cube, the required data be input into a relational data table, in a uniform format, as defined by a particular OLAP system. The building of the relational data table is a time consuming and expensive process. Furthermore, once the data table has been built the customer is limited to the dimensions defined above. In other words, once the dimensions are defined by the customer and the relational data tables are built, the dimensions are fixed. In order to add a dimension once the relational data table is built, the manager of the relational data table would need to modify its data structure. Such a modification is a monumental task, which is virtually impossible, as well as time consuming and prohibitively expensive. For example, to add a dimension where data from the previous year or two for a web site with high traffic would require a massive effort where literally billions of data would be required to be obtained, formatted and loaded.
FIG. 1
illustrates a block diagram
100
summarizing the current practice employed by the industry. In
FIG. 1
, the example may be considered as that of a newspaper's web site where the newspaper is interested in viewing the web site traffic through its various web pages. First, the customer (the newspaper organization) predefines the dimensions and views
102
that are to be measured and presented. Next, the data relevant to each dimension, depicted as
104
a
,
104
b
,
104
c
and
104
n
are input to a relational data table
106
. It can be appreciated that the dimensions can include any business metric capable of being captured and input into the relational data table
106
. For example, the dimensions may include the traffic data from various sections of a newspaper's web site such as sports, politics, real estate and financial sections and the data from these respective sections may be represented by
104
a
,
104
b
,
104
c
and
104
n
, respectively. The data for each dimension are converted to a uniform format and input into the relational data table
106
as data files DF
1
108
a
, DF
2
108
b
, DF
3
108
c
and DFn
108
n
. As shown in
FIG. 1
, any number of data files can be input into the relational data table
106
as represented by data files DF
1
110
a
, DF
2
110
b
, DF
3
n
110
c
and Dfnn
110
n
. A server
112
then aggregates the data and optimizes the storage of the data so that the data may be viewed according to the users predefined request
102
. An OLAP cube viewer
114
then takes the data from the server
112
and presents the cube as predefined by the user in operation
102
. It should be noted that the cube viewer
114
can be any of a number of commercially available cube viewers (e.g., cube viewers from MICROSOFT™, HYPERION™ or CUBULARITY™).
As noted above, the current method of viewing a multidimensional OLAP cube requires that the data structure, i.e., relational data table, exists prior to the cube viewer looking at the table. Because the relational data table must be predefined, the dimensions of the cube are fixed up-front since each dimension of the cube must be defined in a field of the relational data table. In addition, the data must be in a specified format for the cube viewer to recognize the data. Moreover, all the data predefined by the customer, is downloaded locally to the customer's computer or the entire cube must be viewed on a server through the Internet, even if the viewer only desires to view a subset of the data. As such, viewing of the cube may become a slow process as the cube size increases.
In a dynamic and fast paced business environment where change is constant, the rigidity and inflexibility of the current method of processing and viewing OLAP cubes fails to unleash the true potential of an OLAP system. Consumer buying habits or Internet viewing patterns can change in an instant by numerous external variables (i.e., fads, safety concerns, protests or boycotts). If a customer did not have the foresight to include a dimension capturing the data to monitor a change in the buying habits or viewing patterns, the data contained in the relational data table is rendered useless by the change in an external variable. If a customer wishes to modify or add a dimension, a new relational data table must be created assuming the data for the modified or new dime
Chaudhury Supratim Roy
Nwabueze E. Kenneth
Thirumaligai Appan
Venkataraman Siva
Alaubaidi Haythim J.
Martine & Penilla LLP
Metjahic Safet
SageMetrics Corporation
LandOfFree
Methods for abstracting data from various data structures... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods for abstracting data from various data structures..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods for abstracting data from various data structures... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3303800