Source: http://www.google.com/patents/US6161103?dq=6175559
Timestamp: 2013-12-13 22:25:48
Document Index: 23408339

Matched Legal Cases: ['art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150']

Patent US6161103 - Method and apparatus for creating aggregates for use in a datamart - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA method for automatically defining aggregates for use in a datamart is described. The datamart includes fact and dimension tables. The method comprises accessing a schema description and an aggregates description for the datamart. The schema description specifies a schema, which in turn, defines the...http://www.google.com/patents/US6161103?utm_source=gb-gplus-sharePatent US6161103 - Method and apparatus for creating aggregates for use in a datamartAdvanced Patent SearchPublication numberUS6161103 APublication typeGrantApplication numberUS 09/073,733Publication dateDec 12, 2000Filing dateMay 6, 1998Priority dateMay 6, 1998Fee statusPaidPublication number073733, 09073733, US 6161103 A, US 6161103A, US-A-6161103, US6161103 A, US6161103AInventorsJohn P. McCaskey, Jeremy A. Rassen, Allon Rauer, Gregory Vincent Walsh, Craig David WeissmanOriginal AssigneeEpiphany, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (6), Non-Patent Citations (46), Referenced by (118), Classifications (10), Legal Events (19) External Links: USPTO, USPTO Assignment, EspacenetMethod and apparatus for creating aggregates for use in a datamartUS 6161103 AAbstract A method for automatically defining aggregates for use in a datamart is described. The datamart includes fact and dimension tables. The method comprises accessing a schema description and an aggregates description for the datamart. The schema description specifies a schema, which in turn, defines the relationships between the fact tables and dimension tables of the datamart. The aggregates description specifies the aggregates, which define, from the schema definition, which aggregate tables are to be created from the fact tables and dimension tables in the datamart. The data in the aggregates correspond to the pre-computed results of specific types of queries. In response to a query, the aggregates can be searched to determine an appropriate aggregate to use in response to that query. The schema description is used to create a first set of commands to create and populate the fact and dimension tables. Additionally, a second set of commands to create, populate and access, the aggregates are also created from the aggregates description. Some of the commands of the first set of commands are executed causing the creation and population of the tables. Some of the commands of the second set of commands are executed causing the creation of the aggregate tables. Some of the remaining commands of the second set of commands are executed to populate the aggregate tables from the populated fact and dimension tables.
What is claimed is: 1. A method of generating a datamart having aggregates using a computer system, the method comprising:accessing a schema definition which describes a schema for the datamart; accessing a description of a set of aggregates to be generated in the datamart; generating a set of commands from the schema definition, including,generating a set of table creation commands, and generating a set of table access and manipulation commands, the set of table access and manipulation commands corresponding to the semantic meaning of the schema; generating a set of generate aggregates commands; and generating a set of aggregate tables using the set of generate aggregates commands. 2. The method of claim 1 further comprising accessing data in the datamart, the description of the schema, and the description of the set of aggregates to populate the set of aggregate tables.
3. The method of claim 1 wherein the description of the set of aggregates is stored in a set of aggregate description tables, and wherein the generating the set of aggregate commands includes performing a query on the set of aggregate description tables.
4. The method of claim 1 wherein the description of the set of aggregates defines a group of related aggregates.
5. The method of claim 1 wherein the description of the set of aggregates defines a set of fact tables that share an aggregate.
6. The method of claim 1 wherein the description of the set of aggregates defines an aggregate type for each dimension that corresponds to an aggregate.
7. A method of querying a datamart comprising:accessing a definition of a schema for the datamart and a definition of a set of aggregates for the datamart; generating the set of aggregates for the datamart from the definition of the schema and the definition of the aggregates; determining at least an aggregate of the set of aggregates that most closely corresponds to the query, the query corresponding to the schema definition; querying the datamart for the data corresponding to the aggregate. 8. The method of claim 7 wherein the definition of the set of aggregates is stored in a set of tables in a database, and wherein determining the aggregate includes performing a view on the set of tables to determine a possible set of aggregates that can be used to answer the query.
9. The method of claim 7 wherein determining the aggregate includes time navigation of the set of aggregates.
10. The method of claim 7 wherein the query corresponds to a backlog query and wherein determining the aggregate includes determining a subset of the aggregates that can be combined to generate a backlog result.
11. A system for generating a datamart having aggregates, the system comprising:a data store for storing a description of a schema for the datamart; a first program for accessing a description of a set of aggregates to be generated in the datamart, the first program further for generating a set of commands from the schema definition, the first program further for generating a set of table creation commands, and for generating a set of table access and manipulation commands, the set of table access and manipulation commands corresponding to the semantic meaning of the schema; a second program for generating a set of generate aggregates commands, and the second program for generating a set of aggregate tables using the set of generate aggregates commands. Description
CROSS REFERENCES TO RELATED APPLICATIONS This application relates to the following group of applications. Each application in the group relates to, and incorporates by reference, each other application in the group. The invention of each application is assigned to the assignee of this invention. The group of applications includes the following.
U.S. patent application Ser. No. 09/073,748, entitled "Method and Apparatus for Creating a Well-Formed Database System Using a Computer," filed May 6, 1998, and having inventors Craig David Weissman, Greg Vincent Walsh and Eliot Leonard Wegbreit.
U.S. patent application Ser. No. 09/073,752, entitled "Method and Apparatus for Creating and Populating a Datamart," filed May 6, 1998, and having inventors Craig David Weissman, Greg Vincent Walsh and Lynn Randolph Slater, Jr.
U.S. patent application Ser. No. 09/073,733, entitled "Method and Apparatus for Creating Aggregates for Use in a Datamart," filed May 6, 1998, and having inventors Allon Rauer, Gregory Vincent Walsh, John P. McCaskey, Craig David Weissman and Jeremy A. Rassen.
U.S. patent application Ser. No. 09/073,753, entitled "Method and Apparatus for Creating a Datamart and for Creating a Query Structure for the Datamart," filed May 6, 1998, and having inventors Jeremy A. Rassen, Emile Litvak, abhi a. shelat, John P. McCaskey and Allon Rauer.
The advantage of datamarts is that users can quickly access data that is important to their business decision making. To meet this goal, datamarts should have the following characteristics. First, datamarts should be consistent in that they give the same results for the same search. The datamart should also be consistent in the use of terms to describe fields in the datamart. For example, "sales" has a specific definition, that when fetched from a database, provides a consistent answer. Datamarts should also be able to separate and combine every possible measure in the business. Many of these issues are discussed in the following book, Ralph Kimball, The Data Warehouse Toolkit, John Whiley and Sons, Inc., New York, N.Y. (1996).
Present datamarts have a number of drawbacks that are now discussed. First, datamarts are typically difficult to build and maintain. This is because of the requirements that they be consistent and flexible. A related drawback of present day datamarts is that they do not allow the consultants of the datamart to make changes to the schema simply and easily. Because datamarts support very high level queries about the business processes in the business, they require a great deal of consistency in the use of data from the OLTP systems. Additionally, the datamarts need to be very flexible to address changes in the types of high level queries supported. Changing typical datamarts require the changing of hundreds, or potentially thousands, of lines of SQL code. For example, if a fact column is added to a fact table, the change propagates throughout the datamart. These changes are typically implemented by hand, a very time consuming and error prone process. As a result of the hand coding involved, it is quite possible to construct the database in an arbitrary fashion that does not conform to good rules for constructing datamarts. Thus, well-formed datamarts may not result.
A SUMMARY OF THE INVENTION One embodiment of the invention includes a method for automatically defining aggregates for use in a datamart. The datamart includes fact and dimension tables. The method comprises accessing a schema description and an aggregates description for the datamart. The schema description specifies a schema, which in turn, defines the relationships between the fact tables and dimension tables of the datamart. The aggregates description specifies the aggregates, which define, from the schema definition, which aggregate tables are to be created from the fact tables and dimension tables in the datamart. The data in the aggregates correspond to the pre-computed results of specific types of queries. In response to a query, the aggregates can be searched to determine an appropriate aggregate to use in response to that query. The schema description is used to create a first set of commands to create and populate the fact and dimension tables. Additionally, a second set of commands to create, populate and access, the aggregates are also created from the aggregates description. Some of the commands of the first set of commands are executed causing the creation and population of the tables. Some of the commands of the second set of commands are executed causing the creation of the aggregate tables. Some of the remaining commands of the second set of commands are executed to populate the aggregate tables from the populated fact and dimension tables.
In some embodiments, the aggregates description specifies a set of aggregate groups which define the aggregates to be created for one or more dimension tables.
INTRODUCTION TO THE DESCRIPTION
Cleansing Related Tables
Top Level Metadata Us
Extraction Metadata Descriptors
SQL Statement Relate Tables
Query Mechanism Schema List
End User Interface Definition and Example
Definitions Datamart or Data Warehouse--is a database.
Schema--is a description of the organization of data in a database. Often, the schema is defined using a data definition language provided by a database management system. More abstractly, the schema can be the logical definition of a data model for use in a database.
Metadata--is data that defines other data. This is not the actual data in the datamart, but is the data that defines the data in the datamart.
Constellation--a grouping of dimension definitions, fact definitions, like-structured facts (all facts in a constellation have the same dimensional foreign keys), or stars, and other metadata definitions. Often the grouping relates to a business process (e.g., sales).
Fact Table--the central table of a star schema. It stores the numeric measurements of the business that is supplying the information to the datamart.
Measurement--is a piece of data in a fact table, or an arithmetic combination of data.
Dimension--the tables that link to the fact table in a star schema. The tables store the descriptions of the dimensions of the business. Examples of dimensions are product and territory.
Attributes--are the fields of a dimension table (e.g., product name, country name).
User--any end user who would normally wish to query a datamart, but would not usually be concerned with the implementation or maintenance of the datamart.
Consultant--is a person responsible for the creation and maintenance of a datamart.
Source System--is any computer system that holds the raw data used by the system. Examples of such source systems are OLTP database systems.
Data Store--any data storage (physical or logical) from which data is received or to which data is stored. Examples of a data store are files, a database, etc,
Computer--is any computing device (e.g., PC compatible computer, Unix workstation, etc.). Generally, a computer includes a processor and a memory. A computer can include a network of computers.
Program--a sequence of instructions that can be executed by a computer. A program can include other programs. A program can include only one instruction.
Datamart System FIG. 1 illustrates a datamart system representing one embodiment of the invention. The system supports the creation of a well-formed datamart. This system allows consultants to use metadata to define schemas for a datamart. From the definition of the schema, the system can automatically generate the tables in the datamart. Further, the system can automatically extract the data from the source systems, perform conversions on that data and populate the datamart. The system supports the automatic creation and processing of aggregates from aggregate definitions. The system also supports the creation of the query mechanisms from query definitons.
The query/reporting program 104 supports the querying of the datamart 150 and presents results of those queries. The query and reporting process 104 uses the measurement information 168 and the query and reporting information 169, in addition to the schema definitions 161, to query the datamart 150 and provide that information to the web server 186. The query/reporting. information 169 includes filters and form definitions. The filters allow the user to filter different fields out of the datamart 150. The forms allow the users to indicate which fields a user is particularly interested in.
The metadata 160, although including many different types of definitional data, importantly includes the schema definition 161 and the semantic definitions 163. The enterprise manager 102 can use the schema definitions 161 to build the tables in the datamart 150. Through the combination of these two pieces of metadata 160, the enterprise manager 102 can take data from a source system 110, perform semantic conversions on that data and populate the datamart 150. Thus, in some embodiments of the invention, the system includes only the schema definitions 161 and the semantic definitions 163.
Example Method of Defining and Using the Datamart FIG. 2 illustrates an embodiment of a method of defining the datamart 150, loading the datamart 150, and then accessing the data in the datamart 150. This example can be broken into four subparts: a build datamart process 202, an extraction and loading process 204, a build aggregates process 205, and a query and reporting process 206. This example can be implemented using the system 100.
Top Level Metadata Schema As noted in the background, multi-dimensional datamarts use star schemas. The system 100 uses star schemas in a larger organization that allows for the sharing of dimension tables by sets of similar facts. This larger organization is called a constellation. FIG. 3 illustrates a schema for the schema definitions tables that support constellations. (The schema of FIG. 3 is labeled the schema for schema definitions 300.) That is, FIG. 3 illustrates a schema used in the system 100 to define schemas for the datamart. FIG. 3 also illustrates some of the aggregate information 167 schema.
The fact dimension cleanse table 316 has rows that indicate the dimension foreign keys in a fact that should be cleansed. The fact dimension cleanse table 316 includes a dimension role key, a fact dimension cleanse key, and a fact table key. The dimension role key indicates that this dimension role 320 is part of the "group by" set for cleansing a fact table without distorting trends in the data. The fact dimension cleanse key is the primary key for the fact dimension cleanse table 316. The fact table key is the fact table having its cleansing properties.
The dimension base 306 is the metadata 160 describing all the dimension tables that can be used in a given constellation 302. These dimension bases can then be used in multiple constellations. The dimension base 306 includes the following attributes: an aggregate key operator, a cleanse flag, a description, a dimension base key, dimension base name, a dimension base type, and a truncate stage flag. The aggregate key operator is an SQL operator used by the aggregate builder 170 to build aggregates from a dimension. The cleanse flag and description act similarly to those attributes in other tables. The dimension base key is the primary key for the dimension base 306. The dimension base name is the name of the base dimension used in constructing real tables in the datamart 150. The dimension base type indicates the type of a dimension base (either default or special (special includes "date" and "transaction type," which are used by the system 100). The truncate stage flag operates in the manner similar to other truncate stage flags.
The dimension column 329 defines the list of dimension attributes that are valid for a single base dimension 306 and inherited by a dimension usage. The dimension column 329 includes a cleanse label, a cleanse map key, a cleanse type, a description, a dimension base key, a dimension column key, a dimension column name, a dimension column number, a dimension number key, grouped by field, a physical type, a primary key, a time navigation field, and a default value. The cleanse label is a label presented to users after this column has been cleansed. The cleanse map key is for use when cleansing using value mapping. The cleanse map key indicates the mapping group to use. The cleanse type is the method for cleansing the dimension column 329. The description is for documenting the dimension column 329. The dimension base key is the numbered base in which the column resides. The dimension column key is the primary key for the dimension column 329. The dimension column name is the physical name of the column. The dimension column number is the count of the dimension columns (to prevent too many from being created in the datamart 150). The dimension node key is the aggregate hierarchy group in which the column resides. The "group by" field is used for special dimensions to indicate whether or not this column needs to be "grouped by" during the processing by the aggregate builder 170. The physical type is a logical database type for this dimension column 329. The primary key is used in special dimensions to indicate whether or not this column is the primary key. The time navigation field is for the date special dimension to indicate whether or not time navigation should use this field. The default value is the default value for the dimension column.
A special dimension base 391 provides details about special built-in dimensions in the system 100. The special dimension base includes an "always include an aggregate" field, a default aggregate dimension type, a dimension base key, a list order in fact, a physical type of key, an index flag, and a special dimension base key. The "always include an aggregate" field indicates whether or not this dimension table must always be included in all aggregates. The default aggregate dimension type is the default manner in which this dimension is included in aggregate groups. The dimension base key is the one to one relationship to a dimension base. The list order in fact is the order in fact tables that the foreign key to this table will be listed. The physical type of key is the logical database type that foreign keys in the fact tables that point to this special dimension will be. The index flag is used in indexing. The special dimension base key is the primary key for the special dimension base 391.
The cleanse type 323 is a look up table to indicate how to cleanse a dimension column.
The cleanse map 325 is a mapping table for mapping real names to cleanse names. The cleanse map 325 includes a cleanse map key, which is the primary key, and a cleanse map name, which is the name of a set of mapping pairs for the purpose of scrambling data.
The cleanse map definition 327 defines the details of what should be mapped to which fields. The cleanse map definition 327 includes cleanse map character ID, a cleanse integer ID, a cleanse map definition key, a cleanse map key, and a cleanse value. The cleanse character ID is a character value for indexing into this mapping group. The cleanse integer ID is a numeric value for indexing into this mapping group. The cleanse map definition key is the primary key for the cleanse map definition. The cleanse map key is the mapping set to which this particular cleanse map definition belongs. And the cleanse map value is the translation value after the mapping.
Generally, a consultant will create a new datamart 150 by defining instances of the dimension bases 306, and constellations 302. Each instance corresponds to a row in the dimensions bases 306 table or the constellation 302 table. The constellation instances are defined by defining aggregates, dimensions, facts, measures, and ticksheets. The following describes the definition of a schema using the metadata 160. This corresponds to block 210 of FIG. 2.
Extraction Metadata The following describes the metadata 160 used in the extraction process 204. This metadata, represented as extraction schema 400, is shown in FIG. 4. The extraction process focuses around the job and connector tables. In general, these tables define the various steps in extracting the source system data into the staging tables 130 and performing the desired semantic conversions on that data.
The job log 401 is the locations where the running job is logged. That is, the location of the output that will be provided to the consultant indicating what occurred during the extraction (e.g., what errors occurred). The job log 401 includes a data store key, a job key, a job log key, and a job store role. The data store key indicates the data store having a role defined within the job. The job key is a reference to the particular job, the job log key is the primary key for the job log 401. The job store role is the role being assigned to that particular job log 401. An example job store role is "&lt;working directory&gt;," indicating the path to the working director where job log files are store.
The connector store role 448 defines the usage of a data store for a particular connector. It indicates whether the data store is input or output. The connector store role points to the E lo connector and the data store. The connector store role also indicates the type of storage usage being defined for this connector (input or output).
The store type 450 defines the types of RDBMS's supported by the system 100.
The data store 440 defines a logical data source, or sink, used during the extraction. The data store 440 includes the following attributes: the data store key, a data store flag, a description, a name, a source system key, and a store type. The data store key is the primary key. The datamart flag indicates whether or not this data store is the special datamart store. Since the datamart 150 and the metadata 160 can reside in the same database or different, the data mark helps resolve the location of the datamart 150. The description is for documentation of the particular data store. The name is the logical name of the data store. The source system key points to the source system identifier to which this data store belongs. This allows live, and backup, source systems to share the same identifier. The store type indicates the store type of this data store.
The semantic instance represents the use of a single generic template on one fact or dimension table. The semantic type associated with the semantic instance is one of a number of pre-defined recognized data meanings within the system 100 (e.g., an "order"). The semantic types correspond to programs for converting the data in the staging tables 130 into data for use in the datamart 150. An example of a semantic type is a "slowly changing dimension" type.
The following describes the pre-parsed template and the post-parsed results in greater detail. Each token begins with a $$. In the example template, for the slowly changing dimension semantic type, a number of tokens begin with $$ DIM KEY. Similarly, tokens appear that begin with $$FSTGTBL[]. In the post-parsed template, the dimension key tokens have been changed to cost center keys, account key, subaccount keys, etc. Note any tokens, and their surrounding text, that are not replaced are removed from the post-parsed text. If more tokens need to be replaced then are available in the template, then an error flag will be set. In other embodiments of the invention, the templates are dynamically generated according to the number of columns defined in the schema definition 161. In other embodiments, templates are not used but the "post-parsed SQL" results are dynamically generated from the schema definitions 161 and the semantic instance types.
In some embodiments, the pre-parsed templates include additional tokens to deal with specific data stores. For example, the "select into" statement is a token in the pre-parsed version. This compensates for whether the data store is in Oracle database or an SQL server.
Another feature of the pre-parsed language is that "--#begin#" is used to break the pre-parsed version into adaptive template blocks.
Appendix A illustrates semantic types that may be supported and their corresponding adaptive template names. For example, the Pipelined semantic type is made up of, in this order, the map.sub.-- keys the pipe.sub.-- state and the index.sub.-- fact adaptive templates. The example pre-parsed and post parsed SQL adaptive templates are then provided.
Two types of templates not described in Appendix A are "team" templates and "denormalized" templates.
The team template is used to properly populate an "associative" dimension table. Such a table is used whenever there is a one-to-many relationship between an individual fact row and a dimension. For example, if multiple salespeople can split the credit for an order, one needs some way to represent this situation in the datamart. In a star schema, one normally associates a tuple of dimension values with a fact row (e.g. product, customer, salesrep dimensions for the fact row containing price, quantity etc.). Since there is only a single salesrep.sub.-- key, one could normally have only one salesrep associated with this transaction. There are two solutions. One is to introduce multiple fact rows for a transaction invovling one to many relationships. If there were three salesreps on a specific order, there would be three fact rows for this order stored in the database. This has the disadvantage of multiplying the data size by a factor of three and slows queries. Also queries that are concerned with the total number of transactions become more difficult to process since duplicate rows, due to the multiplication by the number of salesreps, must be eliminated.
Another solution is to introduce an associative table between the actual salesrep dimension table and the fact table. Conceptually, the associative table contains "teams" of salespeople. If salesreps A, B and C often sell products together, they will be associated with a unique team key. The team key will be stored in each fact row for orders sold by the A, B, C team. The associative table will associate the team key with the three rows for A, B and C in the salesrep table. The associative table will have 3 rows representing this team (A-key, team1-key), (B-key, team1-key) and (C-key, team1-key). If the team of A, B, D and Q also sold products together, the associative table would have four additional rows (A-key, team2-key), (B-key, team2-key), (D-key, team2-key), (Q-key, team2-key). The team template scans the staging table used to load the fact table and generates the appropriate rows for entry into the associative table, only for those teams THAT ACTUALLY OCCUR in the fact rows being loaded.
Another example is in a Sales Force Automation system where the fact rows correspond to a sales "opportunity".
An opportunity may be associated with the dimensions of Sales Lead Source, Product and Customer Contact. All of these may be one to many relations, amenable to the "team" concept.
"Team" template where instead of introducing the extra associative table between the dimension and fact tables, the dimension table is a combination of the associative table and the actual dimension table. This effectively flattens the data. In the above example the dimension table would contain rows like ("Greg Walsh", A-key, team1-key), ("Craig", B-key, team1-key), ("Ben", C-key" team1-key), ("Greg Walsh", A-key", team2-key) etc. Greg Walsh is a member of both teams 1 and 2 and his name (and other attributes) rather than just his key (A-key) is stored twice. Used judiciously this can result in faster queries than the associative table case but results in duplicate data being stored.
The actual table 502 corresponds to metadata 160 that describe which dimension base and fact tables "actually" exist in the datamart 150.
An important feature of some embodiments of the invention is the ability to compactly store and rapidly query "historical" backlog/balance/inventory quantities. By historical we mean the amount of backlog or inventory as it existed at a given point in time--not necessarily today. Note that backlog/balance/inventory quantities are different than transactional quantities. For example, your bank balance at the end of Q1 1997 is not the sum of your bank balances at the end of January, February and March. It is computed by adding all of the deposit transactions and subtracting all the withdrawals from the balance at the end of Q4 1996. One could compute balances by this method when a user queries the system but because this method requires rolling forward all of the appropriate transactions "from the beginning of time," the queries will likely be slow.
The traditional solution in datamarts is to store periodic "snapshots" of the balance. The snapshots are often stored at daily intervals for the recent historical past, and at greater intervals (e.g. weekly or monthly) for less recent history. This approach has two big disadvantages. The first is an enormous multiplication of data volume. If, for example, you are keeping track of inventory in a store you must store a snapshot for each product you hold in inventory for each day, even if you only sell a small fraction of all of your products on a given day. If you sell 10,000 different products but you only have 500 transactions a day, the "snapshot" datamart is 20 times larger than the transactional datamart. The second disadvantage relates to the most common solution for alleviating the first problem, namely storing snapshots at less frequent intervals for less recent history. This results in the inability to compare levels of inventory in corresponding time periods since the same level of detail is not present in earlier data. For example, in manufacturing companies it is often the case that much business is done near the end of fiscal quarters. If one wants to compare inventory levels between Q1 1995, Q1 1996 and Q1 1997, and focus on the most important changes which occur near quarter end, one cannot use the approach of storing the snapshots at coarser levels of detail since daily data would be required.
In some embodiments of the system, the aggregate tables are used to answer queries about backlog/balance/inventory quantities. In order to answer such queries, the previously described rolling forward from the beginning of time is done. However, this is performed efficiently through the accessing of the appropriate time aggregates. For example, assume the datamart 150 has five years of historical transaction data beginning in 1993. Assume that one desires the inventory of some specified products on May 10, 1996. This would be computed by querying all of the transactions in the 1993, 1994 and 1995 year aggregates, the 1996 Q1 quarter aggregate, the April 1996 month aggregate, the May 1996 week 1 aggregate and finally 3 days of actual May, 1996 daily transactions. These transactions (additions and subtractions from inventory) would be added to the known starting inventory in order to produce the inventory on May 10. Note that this "time navigation "hops" by successively smaller time intervals (year, quarter, month, week, day) in order to minimize the number of database accesses. What is important is the exploitation of aggregate tables, that already exist in the system in order to answer transactional queries rapidly (e.g. What were the total sales of product X in April 1996?). This avoids the need to build what is essentially a second data datamart with the balance/inventory/backlog snapshots.
FIG. 6 includes the following elements: the constellation 302, a ticksheet 602, a data set 606, a ticksheet column 608, a tip 601, an attribute role 603, an attribute 61 0, a ticksheet attribute 605, a ticksheet type 604, a measure 620, a measure term 630, a measure unit 624, a term operator 632, a transaction type 590, an RPN operator 636, the fact column 310, the fact table 304, a backlog 638, a measure mapping 622, a ticksheet column element 612, a dictionary 640, a filter block 650, a filter block type 652, a filter group 654, a filter element 656, a ticksheet type option 660, an option location 662, an option value 664, an option name 666, an option display type 668, an application type 691, the dimension role 320, the dimension column 329, and the dimension base 306.
Under the constellation 302, the ticksheet is a top level object for defining the user interface objects for user interaction. The ticksheet 602 table includes a data set key, a name, a ticksheet type, a constellation key, a label, label detail, a list order, a cleanse flag, and a description. The cleanse flag indicates whether or not to cleanse the filter data on this ticksheet. The constellation flag indicates the constellation in which the dimensions and measures for this ticksheet reside. The data set key indicates the page in which the end user makes report selections. The data set key represents a logical grouping of similar ticksheets. The description is for documentation purposes. The label is the string for the name of the ticksheet. The list order indicates the ticksheet list order. The name is the hidden name of the ticksheet. The ticksheet includes a primary key. The label detail allows for more verbose documentation. The ticksheet type indicates the type of application that interprets the selections made on this ticksheet.
The ticksheet column 608 defines a single column for displaying measure choices on a ticksheet. The ticksheet column table 608 includes the ticksheet column key, the list order, the ticksheet key, and the description. These columns and the ticksheet column table 608 operate in a manner similar to such columns in other tables in this metadata.
The following describes the measures used in the query mechanism schema 600. The measure table 620 defines a top level object for a logical business calculation. The measure table 620 includes a constellation key, a description, a measure key, a measure unit, and a name. The constellation key points to the constellation in which the measure resides. The description is for documentation purposes. The measure key is the primary key for the measure table 620. The measure unit is an indicator of the manner in which numbers are to be displayed. The name is the logical name of the measure.
The measure term table 630 indicates a single component of a measure. The measure term can be combined arithmetically to construct a measure. The measure term table 630 includes a backlog type, a fact column key, a fact table key, a list order, a measure key, a measure term key, an RPN operator, a term operator, and a transaction type key. The backlog type indicates the type of backlog operation to use for a particular term (e.g., "beginning of period" and "end of period"). This can possibly be none. The backlog types are defined in the backlog type table 638. The fact column key points to the particular numeric column to operate on in the fact table. The fact table key indicates the fact table being operated on. The list order is the order of this term in the measure 620. The measure key is the measure being defined. The measure term key is the primary key for this table. The RPN operator is for the measure terms that perform arithmetic operations on other terms. (The RPN operator table lists the valid arithmetic operations to use when constructing a measure.) The term operator is an SQL operator to use on a set of fact rows. (The term operator table 632 indicates the valid set of SQL operators to use on a measure term.) The transaction type is the transaction type values to filter on for the fact in question.
The filter element table 656 defines individual values for a dimension attribute within a filter block. The filter element table 656 includes a dictionary key, a filter element key, a filter group key, a label, a list order, a name, an SQL statement, and a value. The dictionary key points to the user help text for a particular filter element. The filter element key is the primary key. The filter group key points to the filter group to which this element belongs. The label is the user displayed string for the element. A list order is the order of this element within a filter group. The name is the hidden name of this element. The SQL statement is an SQL statement used to build the list of values for a dynamic list box filter group. The value is the database value that this element translates into in a SQL "WHERE" clause.
User Interface Example of Defining Metadata General Schema Definitions User Interface
FIG. 7 illustrates the enterprise manager interface 192. Multiple system 100's can be connected to through that interface. Many of the objects and tables in the system 100 are shown. The base dimensions definitions 710 correspond to the base dimensions available under the "epitest" datamart. The constellations 712 for this datamart include an expense constellation and a sales constellation 720. Thus, the sales constellation 720 would appear as a row in the constellation table 302. Under the sales constellation 720 appear the definitions for the sales aggregates 721, the sales dimensions 723, the sales degenerate dimensions 725, the sales facts 726, the sales measures 728, and the sales ticksheets 729. Also, the extraction definitions 740 and security definitions for the "epitest" datamart are accessible. The sales dimensions 723 define rows in the dimension role table 320. These rows include customer billed to, product, application, program, customer ship to, and territory.
FIG. 9 illustrates a base dimension window 900 showing the definition of the base dimension 810 named customer. In this case, the customer base dimension has a "slowly changing dimensions" dimension data semantic 910. In this example, the dimension base 810 customer has a number of dimension columns 920. L1 is an example of a dimension node.
FIG. 10 illustrates the dimension column window 1000 for the customer region code column 1010. The physical type is the type of data defining that dimension column. The VARCHAR.sub.-- 50 physical type is then mapped to an actual type through the physical type table 330. The translation is dependent on the store type.
FIG. 11 illustrates the base dimension window for the base dimension date (substantially un-editable). The user interface indicates that the date dimension is not an editable base dimension (shown as black circles under "Base Dimensions"), and grayed out in the base dimension window 900. The transtype (transaction type) is similarly not editable and is similarly shown in the user interface.
FIG. 12 shows the dimension column "date day quarter end". Note that column cannot be edited.
FIG. 14 illustrates a fact column window 1400 opened on the definition of the net.sub.-- price fact column 1410. Here the fact column 1410 has a physical type 1420 called FACTMONEY and an aggregate operation 1430 called a SUM.
The following describes the creation of the connectors 162. Once the schema definitions 161 re set, the consultant then defines the connectors 162 to the source systems 110. The connectors, as noted above, define how information is to be extracted from the source systems 110 and how that information is to be placed into the datamart 150.
FIG. 19 illustrates the All Semantics connector as defined in the connector definition window 1900. This connector includes the description and a definition of the input and output data stores. In this case, both of the data stores are the "epimart" (which is the datamart 150).
In this example, the base name, type code, type name, region code, region name and tier name corresponds to the column names within the customer dimension. The date modify is an additional field that is to be used to indicate when this field was last modified in the database. Additionally, there is a source system key that is automatically included in every dimension. The source system key helps ensure that the datainart 150 is well-formed.
1. Define the new dimension.
2. Define the connector steps, including the SQL Statement to extract the warehouse data from the source systems 110.
3. Add the warehouse information to the Open Order Stage SQL Statement.
4. Define a semantic transformation for the warehouse, e.g., slowing changing dimension.
5. Have the enterprise manager 102 update the datamart 150.
Thus, changing the schema definition of the datamart 150 is significantly simpler than previous systems.
FIG. 27 illustrates the interface used to define a user interface for the end user. FIG. 30 includes a user interface definition window 3000 which can be used to define measures and ticksheets. In this case, the measure definition window 3010 is shown.
__________________________________________________________________________*********************************************************************Query log*********************************************************************time  : &amp;lt;A Date Here&amp;gt;addr  : 192&#58067;0.210host  : 192&#58067;0.210user  :agent  : Mozilla/4.01 [en]  (WinNT; U)Datebase information: DRIVER={SQL SERVER}; SERVER=bigfoot;DATABASE=macromediaKeys and values coming in from the browser: file = fileDesc = queryaction = QUERY hidden.sub.-- queryaction = QUERY OK.sub.-- callback = NOK.sub.-- callback = ticksheet = Orders hidden.sub.-- ticksheet = Orders Rows = Customer hidden.sub.-- Rows = Customer Columns = Fiscal Year hidden.sub.-- Columns = Fiscal Year units = Price hidden.sub.-- units = Price facttype = Shipped hidden.sub.-- facttype = Shipped facttype2 = Gross hidden.sub.-- facttype2 = Gross stage = Orders hidden.sub.-- stage = Orders currencyunits = Thousands hidden.sub.-- currencyunits = Thousands rowtotal = yes hidden.sub.-- rowtotal = yes columntotal = yes hidden.sub.-- columntotal = yes percent = none hidden.sub.-- percent = none precision = 0 hidden.sub.-- precision = 0 charts = 3D hidden.sub.-- charts = 3D maxrows = 10 hidden.sub.-- maxrows = 10 rowsorttype = value hidden.sub.-- rowsorttype = value Fiscal.sub.-- Years = All hidden.sub.-- Fiscal.sub.-- Years = All Fiscal.sub.-- Quarters = All hidden.sub.-- Fiscal.sub.-- Quarters = All Calendar.sub.-- Months = All hidden.sub.-- Calendar.sub.-- Months = All Business.sub.-- Units = All hidden.sub.-- Business.sub.-- Units = All Product.sub.-- Lines = All hidden.sub.-- Product.sub.-- Lines = All Product.sub.-- Supergroups = All hidden.sub.-- Product.sub.-- Supergroups = All Platforms = All hidden.sub.-- Platforms = All Product.sub.-- Languages = All hidden.sub.-- Product.sub.-- Languages = All Product.sub.-- SKUs = All hidden.sub.-- Product.sub.-- SKUs = All Product.sub.-- SKU = Sales.sub.-- Reps = All hidden.sub.-- Sales.sub.-- Reps = All Channels = All hidden.sub.-- Channels = All Customer.sub.-- Types = All hidden.sub.-- Customer.sub.-- Types = All Customer.sub.-- Regions = All hidden.sub.-- Customer.sub.-- Regions = All Customers = All hidden.sub.-- Customers = All Customer = sqStyle = classic hidden.sub.-- sqstyle = classicContents of %FormData: Columns = Fiscal Year rowsorttype = value ticksheet = Orders Customers = All charts = 3D Customer Types = All Product SKUs = All Customer Regions = All Fiscal Quarters = All Rows = Customer Channels = All precision = 0 Product Supergroups = All percent = none maxrows = 10 Sales Reps = All columntotal = yes Calendar Months = All queryaction = QUERY sqStyle = classic Fiscal Years = All Product Languages = All Platforms = All Product Lines = All rowtotal = yes currencyunits = Thousands Business Units = AllThe colheaders are:The Cellitems are: Price Shipped Gross OrdersThe Cellitems abbreviated are: Dollar Amount Shipped Gross Orderspid is: 310spid is: 25The valid collheaders are:The invalid colheaders are:The valid cellitems are: Price Shipped Gross OrdersThe invalid cellitems are:The unitstack is: CURRENCYThe cellstack is:SUN (Order.net.sub.-- price)The selectstack is:SUM (Order.net.sub.-- price)The typestack is SHIPTranstypes "BEGIN.sub.-- RETURN" = 1007 "END.sub.-- GROSS" = 1004 "END.sub.-- SRBOTH" = 1018 "END.sub.-- SRADJ" = 1012 "BOOK" = 1 "BEGIN.sub.-- ANET" = 1013 "END.sub.-- IADJ" = 1024 "END.sub.-- ICDNP" = 1022 "BEGIN.sub.-- GROSS" = 1003 "BEGIN.sub.-- SRBDTH" = 1017 "END.sub.-- SBOTH" = 1016 "END" = 1002 "BEGIN.sub.-- SRADJ" = 1011 "END.sub.-- SADJ" = 1010 "BEGIN.sub.-- IADJ" = 1023 "BEGIN.sub.-- ICOMP" = 1021 "END.sub.-- NET" = 1006 "SHIP.sub.-- ADJUST" = 103 "LOST" = 3 "END.sub.-- SALL" = 1020 "BEGIN.sub.-- SBOTH" = 1015 "BEGIN" = 1001 "BEGIN.sub.-- SADJ" = 1009 "BOOK.sub.-- RETURN" = 2 "END.sub.-- FADJ" = 1026 "BEGIN.sub.-- NET" = 1005 "BEGIN.sub.-- SALL" = 1019 "GL" = 105 "SHIP.sub.-- RETURN" = 102 "SHIP.sub.-- RADJ" = 104 "SHIP" = 101 "END.sub.-- RETURN" = 1008 "INV.sub.-- ADJUST" = 201 "LEAD.sub.-- LOST" = 4 "BEGIN.sub.-- FADJ" = 1025 "FINV.sub.-- ADJUST" = 202 "END.sub.-- ANET" = 1014The facttable is: OrderThe limitvalues are:The access limitations are:The limitvalues are:The header took 261 milliseconds.Parsing took 160 milliseconds.Generating the header took 0 milliseconds.Building user limits took 0 milliseconds. Phase 0: Aggregate navigator initialization. Phase 1: Getting dimensions from SQL. (10) Phase 2: Getting fields available from SQL. (90) Phase 3: Getting degenerate fields from SQL. (0)Phase 0: Preparing for query building and execution.R2[0 &#8594; 0] =(SUM(Z0))R1[0] = SUM(Z0)The column router: Cell location 0 will be returned in column 0 when Type is SHIP.The result router: Result location 0 is (SUM(Z0)) 0The unique facttables are:OrderThe number of unique facttables are: 1The unique types are:SHIPTable to unique number lookup Order =&amp;gt; .sub.-- 0.sub.--Begin work on the query based on the facttable OrderPhase 1: Table Order creating table aliases (10)JOIN.sub.-- FIELD IS CUSTOMER.sub.-- BILLTO.sub.-- KEY FOR CustomerJOIN.sub.-- FIELD IS FOR Fiscal YearSQL table aliases: Order&#9633;: T3 Date&#9633;: T2 Customer&#9633;CUSTOMER.sub.-- BILLTO.sub.-- KEY : T1Table aliases: tablealiaslookup(T1) = Customer tablealiaslookup(T2) = Date tablealiaslookup(T3) = Orderselectalias: Customer: T1.base.sub.-- name Fiscal Year: T2.fy.sub.-- nameselectstackalias:SUM(Order.net.sub.-- price): -SUM(T3.net.sub.-- price)joinalias: Customer: T1.customer.sub.-- key = T3.customer.sub.-- billto.sub.-- keyPhase 2: Building SELECT clause (0)Phase 3: Building FROM clause (0)Phase 4: Building WHERE clause (0)Phase 5: Building GROUP BY clause (0)SQL before going through the aggregate navigator:SELECT Columns = T2.fy.sub.-- name, Type = T3.Transtype.sub.`3 key,SUM(T3.net.sub.-- price), Rows = T1.base name INTO #tmp.sub.-- 0.sub.--FROM Customer T1, Date T2, Order T3WHERE T1.customer.sub.-- key = T3.customer billto.sub.-- key and T2.date.sub.-- key = T3.date.sub.-- key and T3.Transtype.sub.-- key in (101)GROUP BY T1.base.sub.-- name, T2.fy.sub.-- name, T3.Transtype.sub.-- key*********************************************************************Selecting appropriate aggregate for the query.********************************************************************* Phase 0 Aggregate navigator. Preparing for query building andexecution. Phase 1 Spliting query into clauses. (0) Phase 2 Construction of aliases. (0) Phase 3 Extracting neededfields from where clause. (0) Phase 4 Extracting neededfields from group by clause. (0) Phase 5 Extracting neededfields from select clause. (0) Phase 6 Unaliasing. (0) Phase 7 Constructing the SQL to fetch smallest aggregate. (20) Phase 8 Running the big SQL. (20) Phase 9 Extracting results from the big SQL. (0) Phase 10 Adjusting input with aggregate information. (0)Phase 6: Aggregate Navigating (40)*********************************************************************Appropriate aggregate determined (CUSTOMER.sub.-- 0, DATE.sub.-- 4,ORDER.sub.-- 86), now select*********************************************************************SQL after going through the aggregate navigator:SELECT Columns = T2.fy.sub.-- name, Type = T3.Transtype.sub.-- key,SUM(T3.net.sub.-- price), Rows = T1.base.sub.-- name INTO #tmp.sub.-- 0.sub.--FROM CUSTOMER.sub.-- 0 T1, DATE.sub.-- 4 T2, Order.sub.-- 86 T3WHERE T1.customer.sub.-- key = T3.customer.sub.-- billto.sub.-- key and T2.date.sub.-- key = T3.date.sub.-- key and T3.Transtype.sub.-- key in (101) GROUP BY T1.base.sub.-- name, T2.fy.sub.-- name, T3.Transtype.sub.-- keyPhase 7: Building results table in sql (10435)Phase 15: Splitting tables bytype (needed = 0) (0)Phase 16: Merging results into one table (needed = 0) (0)GR.sub.-- COLS =C0 = SUM(C0)SQL: SELECT Rows INTO #tmpAllRows FROM #tmp.sub.-- 0.sub.--  GROUP BYRows ORDER BY SUM(C0) DESCSQL: SELECT count(Rows) FROM #tmpAllRowsPhase 17: Extracting rows and doing number of total records (10508/10498)(1022)SQL: set rowcount 10SELECT Rows INTO #tmpTopRows FROM #tmpAllRowsset rowcount 0Phase 19: Sorting, TOP (needed = 10498) (10)creating row totalsSELECT #tmp 0 .Rows, C0 = SUM(C0)INTO #tmpRowsFROM #tmp.sub.-- 0.sub.--, #tmpTopRowsWHERE #tmp.sub.-- 0.sub.--.Rows = #tmpTopRows.RowsGROUP BY #tmp.sub.-- 0.sub.--.Rowscreating col, grand totalsSELECT Columns, C0 = SUM(C0)INTO #tmpColumnsFROM #tmp.sub.-- DGROUP BY ColumnsChecking ADJ of GRANDSQL: SELECT C0 = SUM(C0) INTO #tmpGrand FROM #tmpColumnsfinal results tableSELECT #tmp.sub.-- 0.sub.--.Rows, Columns, C0INTO #tmpFinalResultsFROM #tmp.sub.-- 0.sub.--, #tmpTopRowsWHERE #tmp.sub.-- 0.sub.--.Rows = #tmpTopRows.RowsPhase 20: Filtering results (841)Phase 21: Reading Row Totals (10)Phase 22: Reading Column Totals (10)Phase 23: Reading Grand (10)SQL:calculate remaining columnsSELECTColumns = #tmpColumns.Columns,C0 = #tmpColumns.C0 - ISNULL(SUM(#tmpFinalResults.C0),0)INTO #tmpRemainingFROM #tmpFinalResults, #tmpColumnsWHERE #tmpColumns.Columns = #tmpFinalResults.ColumnsGROUP BY #tmpColumns.Columns, #tmpColumns.C0select C0 = SUM(C0) from #tmpRemainingPhase 24: Reading Remaining Column Totals (needed = 10498) (20)Phase 25: Final Results (30)Phase 26: Sorting columns by time (if necessary). (20)Phase 27: sorting rows by time or name (if necessary). (0)ERR FROMBUILD.sub.-- AND.sub.-- EXEC:0Getting results took 12658 milliseconds.Phase D: Beginning output generation.Phase 3: performing cumulative (if necessary). (0)Dollar Amount / Shipped / GrossThe columns are: 1994 1995 1996 1997 1998The rows are: ******* A number of customer names here *************The table headers are:The contents of the results array are: ***************** A number of customer name, value pairs *****************The contents of the rowtotal array are:&amp;lt; key:. ****.*Row totals*****&amp;lt;The contents of the coltotal array are: 1995: ******An amount****** 1996: ******An amount****** 1997: ******An amount****** 1998: ******An amount****** 1994: ******An amount******The contents of the grdtotal array are: Grand: *******A grand total amount*******Processing and formatting results took 220 milliseconds.Total time was 13299 milliseconds.Processing sylk took 81 milliseconds.__________________________________________________________________________
Alternative Embodiments The following describes alternative embodiments of the invention.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5386556 *Dec 23, 1992Jan 31, 1995International Business Machines CorporationNatural language analyzing apparatus and methodUS5550971 *Jun 2, 1995Aug 27, 1996U S West Technologies, Inc.Method and system for generating a user interface adaptable to various database management systemsUS5659724 *Nov 6, 1992Aug 19, 1997NcrInteractive data analysis apparatus employing a knowledge baseUS5675785 *Oct 4, 1994Oct 7, 1997Hewlett-Packard CompanyData warehouse which is accessed by a user using a schema of virtual tablesUS5806060 *Apr 23, 1997Sep 8, 1998Ncr CorporationInteractive data analysis employing a knowledge baseUS5995958 *Sep 8, 1997Nov 30, 1999Xu; Kevin HouzhiSystem and method for storing and managing functions* Cited by examinerNon-Patent CitationsReference1"Multiple Selection List Presentation Aids Complex Search", IBM Technical Disclosure Bulletin, vol. 36, No. 10, Oct. 1993, pp. 317-318.2Chawathe, S. et al., "Change Detection in Hierarchically Structured Information", SIGMOD Record, vol. 25, No. 2, Jun. 1996, pp. 493-504.3Chawathe, S. et al., "Meaningful Change Detection in Structured Data", Proceedings of the 1997 ACM SIGMOD International Conference, ACM Press, 1997, pp. 26-37.4 *Chawathe, S. et al., Change Detection in Hierarchically Structured Information , SIGMOD Record , vol. 25, No. 2, Jun. 1996, pp. 493 504.5 *Chawathe, S. et al., Meaningful Change Detection in Structured Data , Proceedings of the 1997 ACM SIGMOD International Conference , ACM Press, 1997, pp. 26 37.6Gupta, A. et al., "Aggregate-Query Processing in Data Warehousing Environments", Proceedings of the 21st VLDB Conference, Zurich, Switzerland, Sep. 1995, pp. 358-369.7 *Gupta, A. et al., Aggregate Query Processing in Data Warehousing Environments , Proceedings of the 21st VLDB Conference , Zurich, Switzerland, Sep. 1995, pp. 358 369.8Gupta, H. "Selection of Views to Materialize in a Data Warehouse", Database Theory--ICDT '97, Proceedings of the 6th International Conference, Delphi, Greece, Jan. 1997, pp. 98-112.9Gupta, H. et al., "Index Selection for OLAP", IEEE Paper No. 1063-6382/97, IEEE (1997), pp. 208-219.10 *Gupta, H. et al., Index Selection for OLAP , IEEE Paper No. 1063 6382/97, IEEE (1997), pp. 208 219.11 *Gupta, H. Selection of Views to Materialize in a Data Warehouse , Database Theory ICDT 97, Proceedings of the 6th International Conference , Delphi, Greece, Jan. 1997, pp. 98 112.12Harinarayan, V. et al., "Implementing Data Cubes Efficiently", SIGMOD Record, vol. 25, No. 2, Jun. 1996, pp. 205-216.13 *Harinarayan, V. et al., Implementing Data Cubes Efficiently , SIGMOD Record , vol. 25, No. 2, Jun. 1996, pp. 205 216.14Huyn, N., "Multiple-View Self-Maintenance in Data Warehousing Environments", Proceedings of the 23rd International Conference on Very Large Data Bases, IEEE, (1997), pp. 26-35.15 *Huyn, N., Multiple View Self Maintenance in Data Warehousing Environments , Proceedings of the 23rd International Conference on Very Large Data Bases , IEEE, (1997), pp. 26 35.16Kawaguchi, A. et al., "Concurrency Control Theory for Deferred Materialized Views", Database Theory-ICDT '97, Proceedings of the 6th International Conference, Delphi, Greece, Jan. 1997, pp. 306-320.17 *Kawaguchi, A. et al., Concurrency Control Theory for Deferred Materialized Views , Database Theory ICDT 97, Proceedings of the 6th International Conference , Delphi, Greece, Jan. 1997, pp. 306 320.18Kimball, R., "The Data Warehouse Toolkit", (1996) John-Wiley & Sons, Inc., 388 pages (includes CD ROM).19 *Kimball, R., The Data Warehouse Toolkit , (1996) John Wiley & Sons, Inc., 388 pages (includes CD ROM).20Labio, W. et al., "Efficient Snapshot Differential Algorithms for Data Warehousing", Department of Computer Science, Stanford University, (1996), pp. 1-13.21Labio, W. et al., "Physical Database Design for Data Warehouses", IEEE Paper No. 1063-6382/97, IEEE (1997), pp. 277-288.22 *Labio, W. et al., Efficient Snapshot Differential Algorithms for Data Warehousing , Department of Computer Science, Stanford University, (1996), pp. 1 13.23 *Labio, W. et al., Physical Database Design for Data Warehouses , IEEE Paper No. 1063 6382/97, IEEE (1997), pp. 277 288.24McAlpine, G. et al., "Integrated Information Retrieval in a Knowledge Worker Support System", Proc. of the Intl. Conf. on Research and Development in Information Retrieval (SIGIR), Cambridge, MA, Jun. 25-28, 1989, Conf. 12, pp. 48-57.25 *McAlpine, G. et al., Integrated Information Retrieval in a Knowledge Worker Support System , Proc. of the Intl. Conf. on Research and Development in Information Retrieval (SIGIR), Cambridge, MA, Jun. 25 28, 1989, Conf. 12, pp. 48 57.26 *Multiple Selection List Presentation Aids Complex Search , IBM Technical Disclosure Bulletin, vol. 36, No. 10, Oct. 1993, pp. 317 318.27Mumick, I. et al., "Maintenance of Data Cubes and Summary Tables in a Warehouse", Proceedings of the 1997 ACM SIGMOD International Conference, ACM Press, 1997, pp. 100-111.28 *Mumick, I. et al., Maintenance of Data Cubes and Summary Tables in a Warehouse , Proceedings of the 1997 ACM SIGMOD International Conference , ACM Press, 1997, pp. 100 111.29 *O Neill, P. et al., Improved Query Performance with Variant Indexes , Proceedings of the 1997 ACM SIGMOD International Conference , ACM Press, 1997, pp. 38 49.30O'Neill, P. et al., "Improved Query Performance with Variant Indexes", Proceedings of the 1997 ACM SIGMOD International Conference, ACM Press, 1997, pp. 38-49.31Quass, D. et al., "Making Views Self-Maintainable for Data Warehousing", Proceedings of the Fourth International Conference, on Parallel and Distributes Information Systems, IEEE, Dec. 1996, pp. 158-169.32 *Quass, D. et al., Making Views Self Maintainable for Data Warehousing , Proceedings of the Fourth International Conference , on Parallel and Distributes Information Systems, IEEE, Dec. 1996, pp. 158 169.33Quass, D., "Maintenance Expressions for Views with Aggregation", Proceedings of the 21st International Conference on Very Large Data Bases, IEEE, Zurich, Switzerland, (Sep. 1995), 9 pages.34 *Quass, D., Maintenance Expressions for Views with Aggregation , Proceedings of the 21st International Conference on Very Large Data Bases , IEEE, Zurich, Switzerland, (Sep. 1995), 9 pages.35Tsuda, K. et al., "IconicBrowser: An Iconic Retrieval System for Object-Oriented Databases", Proc. of the IEEE Workshop on Visual Languages, Oct. 4, 1989, pp. 130-137.36 *Tsuda, K. et al., IconicBrowser: An Iconic Retrieval System for Object Oriented Databases , Proc. of the IEEE Workshop on Visual Languages, Oct. 4, 1989, pp. 130 137.37Wiener, J. et al., "A System Prototype for Warehouse View Maintenance", The Workshop on Materialized Views, pp. 26-33, Montreal, Canada, Jun. 1996.38 *Wiener, J. et al., A System Prototype for Warehouse View Maintenance , The Workshop on Materialized Views , pp. 26 33, Montreal, Canada, Jun. 1996.39Wisdom, J. "Research Problems in Data Warehousing", Proc. of 4th Int'l Conference on Information and Knowledge Management (CIKM), Nov. 1995, 6 pages.40 *Wisdom, J. Research Problems in Data Warehousing , Proc. of 4th Int l Conference on Information and Knowledge Management ( CIKM ), Nov. 1995, 6 pages.41Yang, J. et al., "Maintaining Temporal Views Over Non-Historical Information Sources For Data Warehousing", Advances in Database Technology--EDBT '98, Proceedings of the 6th International Conference on Extending Database Technology, Valencia, Spain, Mar. 1998, pp. 389-403.42 *Yang, J. et al., Maintaining Temporal Views Over Non Historical Information Sources For Data Warehousing , Advances in Database Technology EDBT 98, Proceedings of the 6th International Conference on Extending Database Technology, Valencia, Spain, Mar. 1998, pp. 389 403.43Zhuge, Y. et al., "Consistency Algorithms for Multi-Source Warehouse View Maintenance", Distributed and Parallel Databases, vol. 6, pp. 7-40 (1998), Kluwer Academic Publishers.44Zhuge, Y. et al., "View Maintenance in a Warehousing Environment", SIGMOD Record, vol. 24, No. 2, Jun. 1995, pp. 316-327.45 *Zhuge, Y. et al., Consistency Algorithms for Multi Source Warehouse View Maintenance , Distributed and Parallel Databases , vol. 6, pp. 7 40 (1998), Kluwer Academic Publishers.46 *Zhuge, Y. et al., View Maintenance in a Warehousing Environment , SIGMOD Record , vol. 24, No. 2, Jun. 1995, pp. 316 327.* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS6334122 *Dec 23, 1998Dec 25, 2001Advanced Micro Devices, Inc.Method and apparatus for translating variable names to column names for accessing a databaseUS6385604Aug 9, 2000May 7, 2002Hyperroll, Israel LimitedRelational database management system having integrated non-relational multi-dimensional data store of aggregated data elementsUS6434544 *Feb 28, 2000Aug 13, 2002Hyperroll, Israel Ltd.Stand-alone cartridge-style data aggregation server providing data aggregation for OLAP analysesUS6442554 *Jan 29, 1999Aug 27, 2002I2 Technologies Us, Inc.System and method for generating dependent dataUS6477536 *Jun 22, 1999Nov 5, 2002Microsoft CorporationVirtual cubesUS6502088 *Jul 8, 1999Dec 31, 2002International Business Machines CorporationMethod and system for improved access to non-relational databasesUS6535872 *Apr 8, 1999Mar 18, 2003International Business Machines CorporationMethod and apparatus for dynamically representing aggregated and segmented data views using view element setsUS6611216Nov 8, 2001Aug 26, 2003Cisco Technology, Inc.Fast look-up table based scheme for NRZI encoding/decoding and zero insertion/removal in serial bit streamsUS6643638 *Mar 25, 2000Nov 4, 2003Kevin Houzhi XuSystem and method for storing and computing data and functionsUS6643649 *Jan 30, 2001Nov 4, 2003International Business Machines CorporationUtility for cross platform database queryUS6662174 *Apr 17, 2001Dec 9, 2003Brio Software, Inc.Analytical server including metrics engineUS6684216 *Sep 25, 2000Jan 27, 2004Katherine A. DulibaMethod and computer system for providing input, analysis, and output capability for multidimensional informationUS6687285 *Mar 19, 1999Feb 3, 2004Qualcomm IncorporatedMethod and apparatus for supervising the performance of a quick paging channel in a dual event slotted paging systemUS6704745 *Dec 11, 2000Mar 9, 2004Microsoft CorporationTransforming data between first organization in a data store and hierarchical organization in a datasetUS6732115Apr 27, 2001May 4, 2004Hyperion Solutions CorporationChameleon measure and metric calculationUS6735591 *Jan 26, 1999May 11, 2004Joseph M. KhanUniversal information warehouse system and methodUS6735601 *Dec 29, 2000May 11, 2004Vmware, Inc.System and method for remote file access by computerUS6748394Apr 27, 2001Jun 8, 2004Hyperion Solutions CorporationGraphical user interface for relational databaseUS6768995 *Sep 30, 2002Jul 27, 2004Adaytum, Inc.Real-time aggregation of data within an enterprise planning environmentUS6785666 *Jul 11, 2000Aug 31, 2004Revenue Science, Inc.Method and system for parsing navigation informationUS6839716 *Dec 11, 2000Jan 4, 2005Microsoft CorporationMethod and system for building a datasetUS6941311Apr 27, 2001Sep 6, 2005Hyperion Solutions CorporationAggregate navigation systemUS6954769 *Jul 15, 2003Oct 11, 2005Hitachi, Ltd.Storage sub-system having expanded data readUS7003504Nov 16, 1998Feb 21, 2006Kalido LimitedData processing systemUS7031953 *Dec 8, 2003Apr 18, 2006Hyperion Solutions CorporationAnalytical server including metrics engineUS7072822Sep 30, 2002Jul 4, 2006Cognos IncorporatedDeploying multiple enterprise planning models across clusters of application serversUS7072897Apr 27, 2001Jul 4, 2006Hyperion Solutions CorporationNon-additive measures and metric calculationUS7080090 *Apr 27, 2001Jul 18, 2006Hyperion Solutions CorporationAllocation measures and metric calculations in star schema multi-dimensional data warehouseUS7085757Jul 11, 2003Aug 1, 2006International Business Machines CorporationAbstract data linking and joining interfaceUS7111007May 27, 2004Sep 19, 2006Cognos IncorporatedReal-time aggregation of data within a transactional data area of an enterprise planning environmentUS7113951 *Jan 16, 2003Sep 26, 2006Hitachi, Ltd.Method and system for detecting tables to be modifiedUS7130822Jul 31, 2000Oct 31, 2006Cognos IncorporatedBudget planningUS7155398Feb 19, 2003Dec 26, 2006Cognos IncorporatedCascaded planning of an enterprise planning modelUS7167859 *Apr 27, 2001Jan 23, 2007Hyperion Solutions CorporationDatabase securityUS7181508 *Nov 9, 2000Feb 20, 2007Oki Data Americas, Inc.System and method for communicating, monitoring and configuring a device operatively connected to a networkUS7203678 *Mar 27, 2001Apr 10, 2007Bea Systems, Inc.Reconfigurable query generation system for web browsersUS7213199Oct 14, 2004May 1, 2007Cognos IncorporatedSpreadsheet user-interface for an enterprise planning system having multi-dimensional data storeUS7225196Dec 5, 2003May 29, 2007Hitachi, Ltd.Data conversion method and computer system thereforUS7233940Nov 5, 2001Jun 19, 2007Answers CorporationSystem for processing at least partially structured dataUS7233952 *Jan 13, 2000Jun 19, 2007Hon Hai Precision Industry, Ltd.Apparatus for visualizing information in a data warehousing environmentUS7257596 *Nov 9, 2000Aug 14, 2007Integrated Marketing TechnologySubscription membership marketing application for the internetUS7257612Sep 30, 2002Aug 14, 2007Cognos IncorporatedInline compression of a network communication within an enterprise planning environmentUS7313559 *Jul 19, 2002Dec 25, 2007Microsoft CorporationSystem and method for analytically modeling data organized according to a referenced attributeUS7315849Dec 9, 2002Jan 1, 2008Hyperroll Israel, Ltd.Enterprise-wide data-warehouse with integrated data aggregation engineUS7320001Jan 13, 2000Jan 15, 2008Hon Hai Precision Industry, Ltd.Method for visualizing information in a data warehousing environmentUS7333982Dec 9, 2002Feb 19, 2008Hyperroll Israel, Ltd.Information system having a mode of operation in which queries form one or more clients are serviced using aggregated data retrieved from a plurality of different types of data storage structures for improved query performanceUS7337200Mar 21, 2005Feb 26, 2008Hitachi, Ltd.Storage sub-system having expanded data readUS7392248Dec 9, 2002Jun 24, 2008Hyperroll Israel, Ltd.Data aggregation server supporting rapid query response with sparse multi-dimensional dataUS7461076Jul 25, 2000Dec 2, 2008Epiphany, Inc.Method and apparatus for creating a well-formed database system using a computerUS7467125 *Dec 12, 2002Dec 16, 2008International Business Machines CorporationMethods to manage the display of data entities and relational database structuresUS7475088 *Aug 2, 2004Jan 6, 2009Sap AgSystems and methods of providing data from a data source to a data sinkUS7480854Oct 2, 2001Jan 20, 2009International Business Machines CorporationData conversion system and methodUS7509301 *May 27, 2004Mar 24, 2009Sap AgSystems and methods for data processingUS7552145 *Feb 28, 2006Jun 23, 2009Sprint Communications Company L.P.Method and system of restating telecommunications data by a batch-driven integrated rules moduleUS7577680Aug 13, 2007Aug 18, 2009Integrated Marketing Technology, Inc.Web-enabled subscription marketing applicationUS7613734May 15, 2006Nov 3, 2009Xsprada CorporationSystems and methods for providing data sets using a store of albegraic relationsUS7620642 *Dec 13, 2005Nov 17, 2009Sap AgMapping data structuresUS7647354 *May 12, 2003Jan 12, 2010Oracle International CorporationHigh-performance change capture for data warehousingUS7657576 *May 24, 2001Feb 2, 2010Oracle International CorporationAsynchronous change capture for data warehousingUS7693737Oct 31, 2006Apr 6, 2010International Business Machines CorporationEnterprise planningUS7703028Dec 12, 2002Apr 20, 2010International Business Machines CorporationModifying the graphical display of data entities and relational database structuresUS7720806May 15, 2006May 18, 2010Algebraix Data CorporationSystems and methods for data manipulation using multiple storage formatsUS7720861Nov 3, 2006May 18, 2010Vasudevan Software Inc.Multimedia inspection database system (MIDaS) for dynamic run-time data evaluationUS7729945Oct 17, 2000Jun 1, 2010West CorporationSystems and methods that use geographic data to intelligently select goods and services to offer in telephonic and electronic commerceUS7739224May 6, 1998Jun 15, 2010Infor Global Solutions (Michigan), Inc.Method and system for creating a well-formed database using semantic definitionsUS7756739 *Feb 12, 2004Jul 13, 2010Microsoft CorporationSystem and method for aggregating a measure over a non-additive account dimensionUS7756901Feb 19, 2003Jul 13, 2010International Business Machines CorporationHorizontal enterprise planning in accordance with an enterprise planning modelUS7769754May 15, 2006Aug 3, 2010Algebraix Data CorporationSystems and methods for data storage and retrieval using algebraic optimizationUS7774371Aug 4, 2005Aug 10, 2010Kalido LimitedData processing systemUS7797319 *May 15, 2006Sep 14, 2010Algebraix Data CorporationSystems and methods for data model mappingUS7856431Oct 24, 2006Dec 21, 2010Merced Systems, Inc.Reporting on facts relative to a specified dimensional coordinate constraintUS7865503May 15, 2006Jan 4, 2011Algebraix Data CorporationSystems and methods for data storage and retrieval using virtual data setsUS7870148 *Apr 18, 2003Jan 11, 2011Unica CorporationScalable computation of dataUS7877370May 15, 2006Jan 25, 2011Algebraix Data CorporationSystems and methods for data storage and retrieval using algebraic relations composed from query language statementsUS7881999 *Dec 29, 2005Feb 1, 2011Sap AgSystem and method for generating a reimbursement requestUS7890546Feb 3, 2006Feb 15, 2011Hyperion Solutions CorporationAnalytical server including metrics engineUS7904415Oct 3, 2008Mar 8, 2011International Business Machines CorporationSystems and computer program products to manage the display of data entities and relational database structuresUS7962535Nov 10, 2010Jun 14, 2011Merced Systems, Inc.Reporting on facts relative to a specified dimensional coordinate constraintUS8005795 *Mar 4, 2005Aug 23, 2011Emc CorporationTechniques for recording file operations and consistency points for producing a consistent copyUS8032509Jan 14, 2011Oct 4, 2011Algebraix Data CorporationSystems and methods for data storage and retrieval using algebraic relations composed from query language statementsUS8051075Sep 24, 2007Nov 1, 2011Merced Systems, Inc.Temporally-aware evaluative scoreUS8065341 *Oct 1, 2008Nov 22, 2011Sap AgSystems and methods for efficient data transferUS8082268May 17, 2010Dec 20, 2011Vasudevan Software, Inc.Multimedia inspection database system (MIDAS) for dynamic run-time data evaluationUS8090730 *Dec 4, 2002Jan 3, 2012University Of Southern CaliforniaMethods for fast progressive evaluation of polynomial range-sum queries on real-time datacubesUS8099382 *Apr 10, 2008Jan 17, 2012International Business Machines CorporationMethod and system for mapping multi-dimensional model to data warehouse schemaUS8112387May 6, 2011Feb 7, 2012Merced Systems, Inc.Reporting on facts relative to a specified dimensional coordinate constraintUS8117239 *Mar 25, 2008Feb 14, 2012Microsoft CorporationAggregating schema data from multiple sourcesUS8166050Feb 8, 2011Apr 24, 2012Merced Systems, IncTemporally-aware evaluative scoreUS8229963Mar 25, 2008Jul 24, 2012Microsoft CorporationSchema for federated searchingUS8244667 *Oct 18, 2007Aug 14, 2012Google Inc.Querying multidimensional data with independent fact and dimension pipelines combined at query timeUS8280656 *Jul 15, 2011Oct 2, 2012Current Communications Services, LlcSystem and method for providing power distribution system informationUS8285500Jul 15, 2011Oct 9, 2012Current Communications Services, LlcSystem and method for providing power distribution system informationUS8290727 *Jul 15, 2011Oct 16, 2012Current Communications Services, LlcSystem and method for providing power distribution system informationUS8315904Jul 24, 2006Nov 20, 2012International Business Machines CorporationOrganization for promotion managementUS8352458 *May 7, 2008Jan 8, 2013Oracle International CorporationTechniques for transforming and loading data into a fact table in a data warehouseUS8355950Jan 20, 2012Jan 15, 2013HCD Software, LLCGenerating customer-specific vehicle proposals for vehicle service customersUS8359299Feb 26, 2010Jan 22, 2013Kalido LimitedData processing systemUS8380695Aug 19, 2011Feb 19, 2013Algebraix Data CorporationSystems and methods for data storage and retrieval using algebraic relations composed from query language statementsUS8392358Jun 29, 2006Mar 5, 2013Nice Systems Technologies Inc.Temporal extent considerations in reporting on facts organized as a dimensionally-modeled fact collectionUS8401990 *Jul 25, 2008Mar 19, 2013Ca, Inc.System and method for aggregating raw data into a star schemaUS8412671 *Aug 13, 2004Apr 2, 2013Hewlett-Packard Development Company, L.P.System and method for developing a star schemaUS8473343Jul 24, 2006Jun 25, 2013International Business Machines CorporationTracking responses to promotionsUS8473344Jul 24, 2006Jun 25, 2013International Business Machines CorporationContact history for promotion managementUS8495007 *Aug 28, 2008Jul 23, 2013Red Hat, Inc.Systems and methods for hierarchical aggregation of multi-dimensional data sourcesUS8510261 *May 29, 2012Aug 13, 2013Sap AgSystem and method of generating in-memory models from data warehouse modelsUS8521708 *Sep 23, 2003Aug 27, 2013Siemens Industry, Inc.System and method for developing and processing building system control solutionsUS8521786Jul 24, 2006Aug 27, 2013International Business Machines CorporationTechniques for assigning promotions to contact entitiesUS8527349Nov 11, 2011Sep 3, 2013HCD Software, LLCMethods, apparatus and computer program products for targeted and customized marketing of vehicle customersUS20110270454 *Jul 15, 2011Nov 3, 2011Kreiss David GSystem and Method for Providing Power Distribution System InformationUS20110270550 *Jul 15, 2011Nov 3, 2011Kreiss David GSystem and Method for Providing Power Distribution System InformationUS20120054249 *Aug 25, 2010Mar 1, 2012International Business Machines CorporationData warehouse data model adaptersCN101479697BMay 14, 2007May 25, 2011克斯普拉达公司Systems and methods for data storage and retrievalWO2001067303A1 *Feb 28, 2001Sep 13, 2001Hyperroll Israel LtdMulti-dimensional database and integrated aggregation serverWO2002052446A1 *Dec 18, 2001Jul 4, 2002Ge Financial Assurance HoldingSystem, method and software application for incorporating data from unintegrated applications within a central databaseWO2002075598A1 *Dec 14, 2001Sep 26, 2002Exie AsMethods and system for handling mulitple dimensions in relational databasesWO2007134278A2 *May 14, 2007Nov 22, 2007Christopher M PiedmonteSystems and methods for data storage and retrievalWO2008002827A1 *Jun 21, 2007Jan 3, 2008Dampier Todd OTemporal extent considerations in reporting on facts organized as a dimensionally-modeled fact collectionWO2008051912A2 *Oct 22, 2007May 2, 2008Todd O DampierReporting on facts relative to a specified dimensional coordinate constraint* Cited by examinerClassifications U.S. Classification1/1, 707/999.004, 707/999.001, 707/999.003International ClassificationG06Q30/00Cooperative ClassificationY10S707/99933, Y10S707/99934, Y10S707/99931, G06Q30/02European ClassificationG06Q30/02Legal EventsDateCodeEventDescriptionDec 12, 2012FPAYFee paymentYear of fee payment: 12Dec 12, 2012SULPSurcharge for late paymentYear of fee payment: 11Jul 23, 2012REMIMaintenance fee reminder mailedApr 19, 2012ASAssignmentFree format text: SECURITY AGREEMENT;ASSIGNOR:INFOR GLOBAL SOLUTIONS (MICHIGAN), INC.;REEL/FRAME:028078/0964Effective date: 20120405Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTHApr 17, 2012ASAssignmentOwner name: EXTENSITY, INC., MINNESOTAOwner name: INFOR GLOBAL SOLUTIONS (MASSACHUSETTS), INC., MINNOwner name: EXTENSITY (U.S.) SOFTWARE, INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Owner name: SSA GLOBAL TECHNOLOGIES, INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Owner name: E.PIPHANY, INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Owner name: PROFUSE GROUP B.V., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Effective date: 20120405Owner name: INFOR GLOBAL SOLUTIONS (MICHIGAN), INC., MINNESOTAEffective date: 20120405Free format text: RELEASE;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLAND BRANCH, AS ADMINISTRATIVE AGENT;REEL/FRAME:028060/0116Effective date: 20120405Owner name: INFOR GLOBAL SOLUTIONS (CHICAGO), INC., MINNESOTAEffective date: 20120405Owner name: INFINIUM SOFTWARE, INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Free format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Owner name: INVENSYS SYSTEMS INC., MINNESOTAEffective date: 20120405Feb 25, 2008FPAYFee paymentYear of fee payment: 8Nov 3, 2006ASAssignmentOwner name: E.PIPHANY, INC., CALIFORNIAFree format text: AFFIDAVIT OF JEFF HUDKINS RELATING TO CERTAIN LIENS HELD BY COMDISCO, INC. IN CERTAIN PATENTS AND TRADEMARKS OF SSA GLOBAL TECHNOLOGIES, INC.;ASSIGNOR:COMDISCO, INC.;REEL/FRAME:018480/0034Effective date: 20061103Oct 9, 2006ASAssignmentOwner name: JPMORGAN CHASE BANK, N.A. AS ADMINISTRATIVE AGENT,Free format text: SECURITY AGREEMENT;ASSIGNORS:SSA GLOBAL TECHNOLOGIES, INC.;E. PIPHANY, INC.;INFINIUM SOFTWARE, INC.;AND OTHERS;REEL/FRAME:018362/0557Effective date: 20060728Jul 28, 2006ASAssignmentOwner name: SSA GLOBAL TECHNOLOGIES, INC., ILLINOISFree format text: RELEASE BY SECURED PARTY;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:018015/0343Effective date: 20060728Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:18015/343Owner name: SSA GLOBAL TECHNOLOGIES, INC.,ILLINOISMay 5, 2006ASAssignmentOwner name: JP MORGAN CHASE BANK, N.A. AS COLLATERAL AGENT, NEFree format text: SECURITY AGREEMENT;ASSIGNOR:SSA GLOBAL TECHNOLOGIES, INC.;REEL/FRAME:017575/0153Effective date: 20060207Free format text: SECURITY AGREEMENT;ASSIGNOR:SSA GLOBAL TECHNOLOGIES, INC.;REEL/FRAME:17575/153Owner name: JP MORGAN CHASE BANK, N.A. AS COLLATERAL AGENT,NEWJul 20, 2004SULPSurcharge for late paymentJul 20, 2004FPAYFee paymentYear of fee payment: 4Jun 30, 2004REMIMaintenance fee reminder mailedJul 2, 2002ASAssignmentOwner name: EPIPHANY MARKETING SOFTWARE, INC., CALIFORNIAFree format text: RELEASE;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:013048/0056Effective date: 20020626Owner name: EPIPHANY MARKETING SOFTWARE, INC. 1900 SOUTH NORFOFree format text: RELEASE;ASSIGNOR:SILICON VALLEY BANK /AR;REEL/FRAME:013048/0056Owner name: EPIPHANY MARKETING SOFTWARE, INC.,CALIFORNIAFree format text: RELEASE;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:13048/56Oct 18, 2000ASAssignmentOwner name: COMDISCO, INC., ILLINOISFree format text: SECURITY INTEREST. RE-RECORD TO CORRECT THE NATURE OF CONVEYANCE ON A DOCUMENT PREVIOUSLY RECORDED AT REEL 010072 FRAME 0496.;ASSIGNOR:E.PIPHANY, INC.;REEL/FRAME:011039/0247Effective date: 19990602Owner name: COMDISCO, INC. LEGAL DEPT 6111 N. RIVER RD. ROSEMOOwner name: COMDISCO, INC.,ILLINOISFree format text: SECURITY INTEREST. RE-RECORD TO CORRECT THE NATURE OF CONVEYANCE ON A DOCUMENT PREVIOUSLY RECORDED AT REEL 010072 FRAME 0496;ASSIGNOR:E.PIPHANY, INC.;REEL/FRAME:11039/247Free format text: SECURITY INTEREST. RE-RECORD TO CORRECT THE NATURE OF CONVEYANCE ON A DOCUMENT PREVIOUSLY RECORDED AT REEL 010072 FRAME 0496;ASSIGNOR:E.PIPHANY, INC.;REEL/FRAME:011039/0247Jul 6, 1999ASAssignmentOwner name: COMDISCO, INC., ILLINOISFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:E.PIPHANY, INC.;REEL/FRAME:010072/0496Effective date: 19990602Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:E.PIPHANY, INC.;REEL/FRAME:10072/496Owner name: COMDISCO, INC.,ILLINOISMay 17, 1999ASAssignmentOwner name: E.PIPHANY, INC., CALIFORNIAFree format text: CHANGE OF NAME;ASSIGNOR:EPIPHANY MARKETING SOFTWARE, I NC.;REEL/FRAME:009961/0953Effective date: 19990406Free format text: CHANGE OF NAME;ASSIGNOR:EPIPHANY MARKETING SOFTWARE, I NC.;REEL/FRAME:9961/953Owner name: E.PIPHANY, INC.,CALIFORNIADec 21, 1998ASAssignmentOwner name: SILICON VALLEY BANK, CALIFORNIAFree format text: SECURITY INTEREST;ASSIGNOR:EPIPHANY MARKETING SOFTWARE, INC.;REEL/FRAME:009658/0439Effective date: 19981201Owner name: SILICON VALLEY BANK,CALIFORNIAFree format text: SECURITY INTEREST;ASSIGNOR:EPIPHANY MARKETING SOFTWARE, INC.;REEL/FRAME:9658/439May 6, 1998ASAssignmentOwner name: EPIPHANY, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RAUER, ALLON;WALSH, GREGORY VINCENT;MCCASKEY, JOHN P.;AND OTHERS;REEL/FRAME:009202/0619Effective date: 19980505RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google