Source: http://www.google.com/patents/US7739224?dq=5537618&ei=urENT6-uEoHegQe698i5Bw
Timestamp: 2016-12-03 16:02:37
Document Index: 717578528

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', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150', 'art 150']

Patent US7739224 - Method and system for creating a well-formed database using semantic definitions - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA method of defining a well-formed database system by defining the organization of the data in the database, and by defining the operations for that data, is described. The definition can be used to automatically create and populate the well-formed database system. The well-formed database system conforms...http://www.google.com/patents/US7739224?utm_source=gb-gplus-sharePatent US7739224 - Method and system for creating a well-formed database using semantic definitionsAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS7739224 B1Publication typeGrantApplication numberUS 09/073,748Publication dateJun 15, 2010Filing dateMay 6, 1998Priority dateMay 6, 1998Fee statusPaidPublication number073748, 09073748, US 7739224 B1, US 7739224B1, US-B1-7739224, US7739224 B1, US7739224B1InventorsCraig David Weissman, Gregory Vincent Walsh, Eliot Leonard WegbreitOriginal AssigneeInfor Global Solutions (Michigan), Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (28), Non-Patent Citations (41), Referenced by (25), Classifications (8), Legal Events (17) External Links: USPTO, USPTO Assignment, EspacenetMethod and system for creating a well-formed database using semantic definitions
US 7739224 B1Abstract
1. A method of generating one or more database systems, the method comprising:
providing a metadata system that includes a metadata schema, a facility for entering instructions into the metadata schema, and a facility for manipulating the metadata schema;
receiving instructions for generating a database system for business from a user, the received instructions including semantic definitions, wherein the received instructions are entered into the metadata schema and are used to create the database system for business; and
generating the database system for business automatically using the semantic definitions included in the received instructions, whereby the database system for business is well-formed.
2. The method of claim 1, wherein automatically generating the database system for business further comprises:
generating tables automatically according to the received instructions.
building aggregate tables according to the received instructions.
receiving further instructions defining a query mechanism from a user; and
generating queries according to the received further instructions.
generating reports according to the received instructions.
receiving a modification of the metadata schema; and
adjusting the database system for business automatically according to the modification.
7. The method of claim 1, further comprising loading data into the database system for business according to the received instructions entered into the metadata schema.
8. The method of claim 7, further comprising operating on the database system for business according to the received instructions entered into the metadata schema.
9. A method of generating one or more database systems, the method comprising:
receiving instructions for generating a database system for business, the received instructions containing semantic definitions for the metadata schema; and
10. The method of claim 9, wherein automatically generating the database system for business further comprises:
12. The method of claim 9, wherein operating on the database system for business further comprises:
13. The method of claim 9, wherein operating on the database system for business further comprises:
15. The method of claim 9, further comprising loading data into the database system for business according to the received instructions.
16. The method of claim 15, further comprising operating on the database system for business according to the received instructions.
a computer program stored in the memory and executed by the processor, wherein the computer program includes computer instructions for:
18. The computer system of claim 17, wherein the computer program further includes computer instructions for:
19. The computer system of claim 17, wherein the computer program further includes computer instructions for:
20. The computer system of claim 17, wherein the computer program further includes computer instructions for:
21. The computer system of claim 17, wherein the computer program further includes computer instructions for:
22. The computer system of claim 17, wherein the computer program further includes computer instructions for:
23. The computer system of claim 17, wherein the computer program further includes computer instructions for loading data into the database system for business according to the received instructions entered into the metadata schema.
24. The computer system of claim 23, wherein the computer program further includes computer instructions for operating on the database system for business according to the received instructions entered into the metadata schema.
receiving instructions for generating a database system for business, the received instructions including semantic definitions for the metadata schema; and
26. The computer system of claim 25, wherein the computer program further includes computer instructions for:
27. The computer system of claim 25, wherein the computer program further includes computer instructions for:
28. The computer system of claim 25, wherein the computer program further includes computer instructions for:
29. The computer system of claim 25, wherein the computer program further includes computer instructions for:
30. The computer system of claim 25, wherein the computer program further includes computer instructions for:
31. The computer system of claim 25, wherein the computer program further includes computer instructions for:
loading data into the database system for business according to the received instructions.
32. The computer system of claim 31, wherein the computer program further includes computer instructions for:
operating on the database system for business according to the received instructions contained in the metadata schema.
33. A computer readable storage medium encoded with software instructions, wherein execution of the software instructions comprises:
34. The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises:
35. The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises:
36. The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises:
37. The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises:
38. The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises:
39. The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises loading data into the database system for business according to the received instructions entered into the metadata schema.
40. The computer readable storage medium of claim 39, wherein execution of the software instructions further comprises operating on the database system for business according to the received instructions entered into the metadata schema.
41. A computer readable storage medium encoded with software instructions, wherein execution of the software instructions comprises:
42. The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises:
43. The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises:
44. The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises:
45. The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises:
46. The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises:
47. The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises loading data into the database system for business according to the received instructions.
48. The computer readable storage medium of claim 47, wherein execution of the software instructions further comprises operating on the database system for business according to the received instructions.
49. A method of automatically generating a database system for business, the method comprising:
providing a metadata schema;
entering instructions for generating the database system into the metadata schema, the entered instructions having semantic definitions; and
generating the database system for business automatically using the semantic definitions of the entered instructions, whereby the database system for business is well-formed.
50. The method of claim 49, further comprising loading data into the automatically-generated database system for business according to the instructions entered into the metadata schema.
51. The method of claim 50, further comprising operating the database system for business according to the instructions entered into the metadata schema.
52. A method of automatically generating a database system for business, the method comprising:
receiving instructions for generating a database system for business, the received instructions having semantic definitions; and
generating the database system for business automatically using the semantic definitions of the received instructions, whereby the database system for business is well-formed.
53. The method of claim 52, further comprising loading data into the generated database system for business according to the received instructions.
54. The method of claim 53, further comprising operating the database system according to the received instructions.
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. (now U.S. Pat. No. 6,212,524).
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 (now U.S. Pat. No. 6,161,103).
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 (now U.S. Pat. No. 6,189,004).
The schema definitions 161 hold the definition of the schema for the datamart 150. Typically, a consultant, using the consultant computer 190, can interface with the enterprise manager 102 to define the schema definitions 161 for the datamart 150. In particular, the consultant can use the enterprise manager interface 192 to define a star schema for the datamart 150. This star schema is organized around the business processes of the business for which the datamart is being created. What is important is that the consultant can easily define a schema for the datamart 150 and that definition is kept in the schema definitions 161. From the schema definitions 161, not only can the tables in the datamart 150 be generated, but also the automatic extraction and conversion of the data from the source systems 110 can be performed, aggregates are set up, arid a query mechanism is generated.
The measurement information 168 and the query/reporting information 169 support the querying of the datamart 150. A measure is a piece of numeric data in the datamart 150 that is useful to a user. That is, individual fact columns from source systems can be very implementation specific. These columns may not correspond to what users would prefer to see. For example, a user may want to see a net price added with a total cost. However, the fact table may only include the net price or the total cost. The measurement information 168 allows the consultant to define the abstract notion of the calculation associated with the net price added to the total cost.
The enterprise manager 102 is a program that is responsible for supporting the definition of the schema, and the creation of the tables in the datamart 150 from the schema definitions 161. The enterprise manager 102 also controls the extraction program 120. (In some embodiments, is the extraction program 120 and the semantic template conversion program 140 are included in the enterprise manager 102). During the execution of the extraction program 120, the extraction program 120, the staging tables 130, the semantic template conversion 140, and the datamart 150 are all used. The extraction program 120 uses the connectors 162 and the source system information 164 to extract the information from the source systems 110. The extracted data is loaded into the staging tables 130.
The metadata 160, although including many different types of definitional data, importantly includes the schema definitions 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.
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 process 204, a build aggregates process 205, and a query and reporting process 206. This example can be implemented using the system 100.
FIG. 3 includes the following elements: a constellation 302, a fact table 304, a dimension base (dim_base 306), a semantic instance 308, a fact column (fact_col 310), a fact aggregate operator (fact_agg_operator 312), a fact column number (fact_col_nbr 314), a fact dimension cleansing (fact_dim_cleanse 316), a dimension role (dim_role 320), a degenerative number (degen_nbr 322), a dimension role number (dim_role_nbr 324), a dimension node (dim_node 326), a dimension column (dim_col 329), a dimension column number (dim_col_nbr 321), a cleanse type 323, a cleanse map definition (cleanse_map_def 327), a cleanse map 325, a physical type 330, a transaction string 332, a metacolumn (meta_col 334), an actual table type (actual_tbl_type 336), a dimension base type (dim_base_type 328), a special dimension base (special_dim_base 391), an aggregate key operator (agg_key_operator 392), an aggregate dimension type (agg_dim_type 393), an aggregate dimension (agg_dim 344), an aggregate group (agg_group 342), an aggregate fact (agg_fact 340), a aggregate dimension set (agg_dim_set 372), a dimension column set (dim_col_set 370), a dimension column set definition (dim_col_set_def 374), a fact index 380, a fact index definition (fact_index_def 384), and a fact index number (fact_index_nbr 382).
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 is truncate stage flags.
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. Beginning with the facts in a constellation, the consultant defines a fact table 304 row that will define the hub table in a star schema supported by the constellation. Again, it is important to remember that the fact tables in FIG. 3 are for definitional purposes, and are not the real fact tables in the datamart 150. A row in the fact column 310 holds the details of what columns will be created for place holders of actual values in a corresponding fact table. Thus, for each fact, the consultant defines the various fact columns.
The special dimensions are the transaction type table and date values that are included in s every fact table. Because this is included in every fact table, the system 100 can rely on the existence of the transaction type during the various stages of datamart 150 creation, modification, querying, and the like.
FIG. 4 includes the following elements: a job 402, a job step 404, a system call 405, a connector 406, a connector timestamp 407, a connector step 408, a connector column latch (connector_col_latch 409), and an extraction group 411, an extraction note 410, an SQL statement 420, and error handling type 413, an external table (external_tbl 422), an external column 424, the physical type 330, the fact table (fact_tbl 304), a debug level 415, the semantic instance 308, a semantic type 430, a dimension semantic type (dim_semantic_type 432), a fact semantic type 434, the actual table type (actual_tbl_type 336), a semantic type definition (semantic_type_def 436), an adaptive template 438, and adaptive template block 439, the dimension base (dim_base 306), a job log 401, a connector store role 448, a store role 446, a statement type enabled 428, a store role allow 444, a data store 440, a source system 442, a file store 441, and Oracle store 454, a store version 452, and SQL server store 456, and ODBC store 458, and a store type 450.
The job log 401 is the location 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 “<working directory>,” indicating the path to the working director where job log files are stored.
The SQL server store table 456 defines details about an SQL server system. The SQL server store includes the following attributes: a data store key, a database name, a password, a server, an SQL server store key, a user name, and a version. The data store key is a one to one relationship to a data store entry. The database name is an SQL server database name ($$DEFAULT means the database in which this role resides). The password is the SQL server password. $$ DEFAULT again means the password currently logged into to read this data. The server is the SQL server name. The SQL server store key is the primary key. The user name is the SQL server user name. The version is the vendor's version number of this SQL server. $$DEFAULT means use the default value for the current database being used. For example, the database name means the database in which this role resides.
The job defines the order of the execution of the connectors. The job also allows for the running of an external program, such as system call, between connector executions. Thus, each job step in a job can be a system call or a connector.
The following is an example illustrating the organization of a job. Assume that a consultant wants to extract information from a source system that provides a raw set of home addresses. A system call could be run as part of a job step. The system call would determine the zip codes associated with those addresses. The zip codes could then be included in the datamart 150.
Thus, during the extraction, the extraction node associated with a particular semantic type instance is processed. This causes the adaptive template blocks associated with the semantic instance to be processed. The dimension information associated with that semantic instance, or is the fact table information associated with the semantic instances, can then be used to replace the tokens with the specific information associated with that dimension or that fact.
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 definitions 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.
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_keys the pipe_state and the index fact adaptive templates. The example pre-parsed and post parsed SQL adaptive templates are then provided.
As mentioned above, the other type of template is the denormalized data template. This is a variant of the “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, team 1-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.
FIG. 5 illustrates the schema for the runtime environment within the system 100. The runtime schema 500 represents the schema description for the schema of the running datamart 150. That is, when the datamart 150 is created or modified, the schema definition is propagated into the runtime schema 500. Thus, the runtime schema 500 allows for the datamart 150 to be changed without having to rebuild all the tables and repopulate all of those tables. Additionally, the runtime schema 500 provides the support for aggregate navigation. Aggregate navigation involves determining which aggregate to use in response to a query. Schema modification and S aggregate navigation will now be explained in greater detail.
The aggregate navigation process determines which aggregate most closely suits a particular query. The runtime metadata 160 keeps track of the aggregates available in the datamart 150. The query and reporting program 104 initiates a view of the runtime schema 500 (in particular, the tables holding the aggregate tables definitions). The view results indicate which aggregates are available to answer the particular query. The view results are further examined to determine the best aggregate to use (the one that most closely corresponds to the query).
Importantly, the query machinery does not need to be aware of aggregates to be able to take advantage of them. Aggregates are simply presented to the query machinery as a solution to a, query.
The runtime schema 500 includes the following elements: an actual table (actual tbl 502), an actual column (actual_col 504), a fact aggregate table (fact_agg 512), a fact aggregate dimension (fact_agg_dim 514), a dimension base aggregate (dim_base_agg 516), a dimension base aggregate column dim_base_agg_col 518), a datamart letter 510, the dimension base (dim_base 306), the fact table (fact_tbl 304), the external table (external_tbl 442), an actual column (actual col 504), a physical type definition (physical_type_def 530), an actual table type (actual tbl_type 336), an actual column type (actual_col_type 540), the physical type 330, a database physical type 595, the translation string 332, a translation actual 539, a store type 450, a date (Date 0)_560, a business process (bus_process 570), an adaptive template profile 580, and a transaction type (transtype_0) 590.
The actual table 502 includes the following attributes: an actual table key, an actual table IS name, an actual table type, a dimension base key, an external table key, a fact table key, an index flag, a mirror flag, and a logical table name. The primary key is the actual table key. The actual table name corresponds to the physical name of this table in the database implementing the datamart 150. The actual table type is the logical type of this physical table. For example, if this is a dimension staging table or a fact staging table. The dimension base key points to the dimension base table definition that defined the corresponding physical table. The external table key points to the external table definition that defined the physical table. The fact table key points to the fact table definition that defined the corresponding physical table. The index flag and the mirror flag are used in indexing and mirroring, respectively. The logical table name defines the logical name for this table.
The actual column 504 is metadata describing a physical column in a physical table in the datamart 150. The actual column table latches this definition information when the physical tables are built in the datamart 150. The actual column 504 includes the following attributes: the actual column key, an actual column name, an actual column type, an actual table key, a dimension role name, a foreign table key, a group by field, a hierarchy, a list order, a parent hierarchy, a physical type, a primary key, and a time navigation field. The actual column name is the name of the physical column in the physical table in the datamart 150. The actual column type is the logical type of the column. The actual table key points to the actual table in which the actual column lives. The dimension role name is the logical role name of the dimension in the fact table for dimension foreign keys inside of a fact table. The foreign table key points to the actual dimension base tables in the actual tables 502 (the foreign table key is applicable to fact actual columns that are foreign keys to dimensions). The group by field, for dimension table, is true when this column should be included in an aggregate builder group. The hierarchy for dimension, for dimension columns, indicates that aggregate builder group to which this column belongs. The list order is the order of the column in the actual table 502. The parent hierarchy, for dimension columns, indicates the parent aggregate builder group to which this column belongs. The physical type is a logical data type of the column. The primary key, for dimension tables, is true when this column is the primary key of the actual table 502. The time navigation field, for the database dimension, is true if this field can be used by the time navigator. The fact aggregate table 512 includes a list of fact aggregates in the datamart 150. The fact aggregates includes attributes that point to the actual fact table in which this aggregate belongs.
The fact aggregate table 512 indicates which numbered aggregate represents the fact table in question, the number of rows in this aggregate, a datamart letter, and an enabled flag. The datamart letter indicates the mirrored datamart to which this fact aggregate belongs. Mirror is used to ensure that partially completed extractions from the source systems 110 do not cause the database to become inconsistent. The fact aggregate dimension 514 lists which aggregates contain which dimensions. The fact aggregate dimension includes the following attributes: an actual dimension role key, a dimension base aggregate key, a fact aggregate dimension key, and the fact aggregate key. The actual dimension role key is the dimension foreign key in this fact aggregate that is being defined. The dimension base aggregate key is the dimension aggregate that this fact aggregate points to for this foreign key. The fact aggregate dimension key is the primary key. The fact aggregate key points to the fact aggregate being defined.
The dimension base aggregate column 518 is a list of columns in a given dimensions aggregate. The dimension base aggregate column includes attributes which point to which column is included in this dimension aggregate, and a pointer to a dimension aggregate being defined.
The actual column type 540 is a logical description of the role a column plays in the system 100. The actual column type 540 includes attributes that define the default value to be used in a database for a column of this type.
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 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 s 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 (ticksheet_col 608), a tip 601, an attribute role 603, an attribute 610, 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 (fact_col 310), the fact table (fact tbl 304), a backlog type 638, a measure mapping 622, a ticksheet column element (ticksheet_col_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 options 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 (dim_role 320), the dimension column (dim_col 329), and the dimension base (dim_base 306).
The data set table 606 is a grouping mechanism for ticksheets into sets that describe their contents. The data set table 606 includes the following columns: a data set key, a data set name, S a label, a description, and a list order. The data set name is a logical name for top level user definition of like ticksheets across ticksheet types. The description is the description of the data set.
The attribute table 610 defines the dimension attribute choices within a ticksheet. These choices are tied to a single dimension column in the schema definition of the datamart 150. The attribute table 610 includes an abbreviation, an attribute key, a dictionary key, a dimension column key, a dimension role key, a hyperlink, a label, a list order, a name, and a ticksheet key.
The abbreviation is the shortened user string for the attribute. The attribute key is the primary key for this attribute. The dictionary key is a pointer to the dictionary 640 that includes help message for a particular attribute. The dimension column key is the dimension column in which this attribute refers. For degenerate dimensions this reference is null. The dimension usage, within a constellation, is defined by the dimension role key. The hyperlink is an html text for navigating return values for this attribute to other web sites, such as a company name look-ups etc. The label is what the user sees for a particular attribute. The list order defines a sort order on pop-up menus where one is the topmost in the list. The name is the internal name for the attribute. The ticksheet key indicates the ticksheet to which this attribute belongs.
The following describes the filtering tables. The filter block 650 is a top level grouping table for filter area within a ticksheet. The filter block 650 is tied to a particular dimension column in the schema definition. The filter block 650 includes columns, a description, a dictionary key, a dimension column key, a dimension role key, a filter block key, a filter block type, a label, a list order, a name, a plural, a mapping flag, and a ticksheet key. The columns field indicates the number of columns in this filter block. The description is for documentation. The dictionary key points to the help dictionary. The dimension column key points to the actual column name and the datamart to be filtered on. A null value here means degenerate dimension as determined by the dimension role key. The dimension role key points to the dimension role in the constellation of the ticksheet that is the form key to filter on for all facts in this constellation. A null value here means that a special dimension shared by all constellations is being used. The filter block key is the primary key for this table. The filter block type points to the filter block type table 652 which defines the ways in which this filter block is displayed to the user (e.g., a checkbox or a radio button). The label is the text that appears to the user for the filter block. The list order is the order that the filter block should appear in a list. The name is the name of the filter block. The plural field is the text that appears to the user for the filter block. The mapping flag is used in mapping. The ticksheet key points to the ticksheet that this filter block belongs.
FIG. 13 illustrates a fact table window 1300 that is open on the fact table 1310 definition. The fact data semantic 1320 is transactional/state like/force close/unjoined. The transactional/state like/force close/unjoined means that the invoice part of an order is transactional, the booking is state like, orders that are not otherwise dealt with, are closed out, and the data may become dirty and so it needs to be cleansed, thus, it is unjoined. This semantic type is described in detail in Appendix A. Note that the user can select from many different types of fact table semantics. The fact table window 1300 also shows the fact columns 1330 for the order fact table.
FIG. 15 illustrates how the consultant would select the semantic type for the fact table 1310.
In one embodiment of the invention, these names can be automatically propagated into the SQL field 2210 window via a template that is generated from the corresponding base dimension. This allows the consultant to more easily define the SQL selection statement.
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. Have the enterprise manager 102 update the datamart 150.
FIG. 28 illustrates the aggregate group window 2800, where aggregates can be defined. For a given aggregate group, the consultant can define which fact share the aggregate, and which type of aggregate (defined in the Aggregate Type List 2810) should be built for a given dimension in the aggregate. Additionally, dimensions can be added to, or removed from, an aggregate group.
FIG. 31 illustrates the ticksheet definition window 3400. The ticksheet definition window 3400 allows a consultant to define a ticksheet that will be used to generate a query form for a user. The consultant defines the attributes, the columns, and the filters for a ticksheet. FIG. 32 illustrates the query form 3200 generated from the ticksheet defined in FIG. 31.
FIG. 33 illustrates the measure mappings window 3300, that allows the consultant to map measure definitions to user friendly measure names. In the example of FIG. 33, the Price ShipGrossMonth measure is mapped to a combination of the dollar amount, gross, and sell-through being selected in the query form 3200.
FIG. 34 illustrates another query form 3200 generated from a different ticksheet definition. When the user selects the create report button, the query is issued against the datamart 150. FIG. 35 illustrates some sample results 3500 from such a query.
Datebase information: DRIVER=(SQL SERVER);SERVER=bigfoot;DATABASE=macromedia
hidden−facttype2 = Gross
charts = 30
hidden_charts = 30
The celistack is:
“END_SAIL” = 1020
Phase 0: Preparing for query building and execution.R2(0 -> 0)= (SUM(20))
R1(1) = SUM(20)
Customar□CUSTOMER_BILLTO_KEY : T1
-SUM(Order.net_price): -SUM(T3.net_price)
Phase 16: Merging results into one table (needed = 0) ( 0 )GR_COLS = CO = SUM(C0)
Phase 17: Extracting rows and doing number of total records (10508/10499) ( 1022 )
SELECT #tmp_O_.Rows, Columns, C0
C0 = #tmpColumns.C0 - ISNULL(SUM(#tmpFinalResults.C0),0)
Phase 26: Sorting columns by time (if necessary) . ( 20 )
Phase 27: sorting rows by time or name (if necessary). ( 0 ) ERR FROM BUILD_AND_EXEC:0
The rows are: ******* A number of customer names here ************
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5249300Nov 25, 1992Sep 28, 1993Bachman Information Systems, Inc.System and method of constructing models of complex business transactions using entity-set variables for ordered sets of references to user dataUS5272628Apr 16, 1990Dec 21, 1993Microsoft CorporationMethod and system for aggregating tables having dissimilar formatsUS5295256 *Dec 14, 1990Mar 15, 1994Racal-Datacom, Inc.Automatic storage of persistent objects in a relational schemaUS5386556 *Dec 23, 1992Jan 31, 1995International Business Machines CorporationNatural language analyzing apparatus and methodUS5428776 *Dec 22, 1993Jun 27, 1995Wang Laboratories, Inc.System for composing a graphical interface to a relational database which displays a network of query and source iconsUS5550971 *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 tablesUS5706495 *May 7, 1996Jan 6, 1998International Business Machines CorporationEncoded-vector indices for decision support and warehousingUS5721903 *Oct 12, 1995Feb 24, 1998Ncr CorporationSystem and method for generating reports from a computer databaseUS5806060 *Apr 23, 1997Sep 8, 1998Ncr CorporationInteractive data analysis employing a knowledge baseUS5832496 *Oct 31, 1996Nov 3, 1998Ncr CorporationSystem and method for performing intelligent analysis of a computer databaseUS5870746 *Oct 31, 1996Feb 9, 1999Ncr CorporationSystem and method for segmenting a database based upon data attributesUS5905985 *Jun 30, 1997May 18, 1999International Business Machines CorporationRelational database modifications based on multi-dimensional database modificationsUS5978811Jul 29, 1992Nov 2, 1999Texas Instruments IncorporatedInformation repository system and method for modeling dataUS5995958 *Sep 8, 1997Nov 30, 1999Xu; Kevin HouzhiSystem and method for storing and managing functionsUS6014670 *Nov 7, 1997Jan 11, 2000Informatica CorporationApparatus and method for performing data transformations in data warehousingUS6032158 *May 2, 1997Feb 29, 2000Informatica CorporationApparatus and method for capturing and propagating changes from an operational database to data martsUS6055541 *Sep 19, 1997Apr 25, 2000Sas Ip, Inc.Automatic report generating systemUS6085198Jun 5, 1998Jul 4, 2000Sun Microsystems, Inc.Integrated three-tier application framework with automated class and table generationUS6108004 *Oct 21, 1997Aug 22, 2000International Business Machines CorporationGUI guide for data miningUS6128624 *Nov 12, 1997Oct 3, 2000Ncr CorporationCollection and integration of internet and electronic commerce data in a database during web browsingUS6161103May 6, 1998Dec 12, 2000Epiphany, Inc.Method and apparatus for creating aggregates for use in a datamartUS6167405 *Apr 27, 1998Dec 26, 2000Bull Hn Information Systems Inc.Method and apparatus for automatically populating a data warehouse systemUS6189004May 6, 1998Feb 13, 2001E. Piphany, Inc.Method and apparatus for creating a datamart and for creating a query structure for the datamartUS6212524May 6, 1998Apr 3, 2001E.Piphany, Inc.Method and apparatus for creating and populating a datamartUS6263341Jun 7, 1995Jul 17, 2001Texas Instruments IncorporatedInformation repository system and method including data objects and a relationship objectUS6282544May 24, 1999Aug 28, 2001Computer Associates Think, Inc.Method and apparatus for populating multiple data marts in a single aggregation process* 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.2 *Brachman, Ronald J., Khabaza, Tom, Kloesgen, Willi, Piatetsky-Shapiro, Gregory, and Simoudis, Evangelos; "Mining Business Databases," vol. 39, issue 11; Nov. 1996; pp. 42-48.3 *Business Wire; "Hyperon Software Announces New Family of Multi-Dimensional Business Analysis Applications; Purpose-Built Applications Move Beyond Raw OLAP Tools and Technologies"; Mar. 2, 1998; pp. 1-5.4Chawathe, S. et al., "Change Detection in Hierarchically Structured Information", SIGMOD Record, vol. 25, No. 2, Jun. 1996, pp. 493-504.5Chawathe, S. et al., "Meaningful Change Detection in Structured Data", Proceedings of the 1997 ACM SIGMOD International Conference, ACM Press, 1997, pp. 26-37.6 *Diane Vint-Johnson and Deborah Henderson; "A Short Course on OLAP Tools"; Apr. 1998; pp. 15-17.7 *Friedland, Liam; "Accessing the Data Warehouse: Designing Tools to Facilitate Business Understanding"; vol. 5, issue 1; Jan. 1998; pp. 25-36.8Gupta, A. et al., "Aggregate-Query Processing in Data Warehousing Environments", Proceedings of the 21st VLDB Conference, Zurich, Switzerland, Sep. 1995, pp. 358-369.9Gupta, H. et al., "Index Selection for OLAP", IEEE Paper No. 1063-6382/97, IEEE (1997), pp. 208-219.10Gupta, 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.11Gupta, 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.13Huyn, 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.14Kawaguchi, 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.15Kawaguchi, 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.16Kimball, R., "The Data Warehouse Toolkit", (1996) John-Wiley & Sons, Inc., 388 pages (includes CD ROM).17Labio, W. et al., "Efficient Snapshot Differential Algorithms for Data Warehousing", Department of Computer Science, Stanford University, (1996), pp. 1-13.18Labio, W. et al., "Physical Database Design for Data Warehouses", IEEE Paper No. 1063-6382/97, IEEE (1997), pp. 277-288.19 *Matteo Golfarelli, Dario Maio, and Stefano Rizzi;"Conceptual Design of Data Warehouses from E/R Schema"; IEEE; Jan. 6-9, 1998; pp. 1-10.20McAlpine, 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.21 *Michael Krippendorf and Il-Yeol Song; "The Translation of Star Schema into Entity-Relationship Diagrams"; IEEE; Sep. 1-2, 1997; pp. 390-395.22Mike Feuche, "Index Interface Links CASE and IBM's DB2," Oct. 24, 1988, Index Technology Corp., Computer-aided Software Engineering, Product Announcement, MIS Week, V9, N43, p. 23(2).23Mumick, 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.24O'Neill, P. et al., "Improved Query Performance with Variant Indexes", Proceedings of the 1997 ACM SIGMOD International Conference, ACM Press, 1997, pp. 38-49.25 *PR Newswire; "Influence Software to Integrate Aperio With Silicon Graphics MineSet for Web-Based Data Mining/Data Warehouse Suite"; Apr. 14, 1998; pp. 1 and 2.26Quass, D. et al., "Making Views Self-Maintainable for Data Warehousing", Proceedings of the Fourth International Conference on Parallel and Distributed Information Systems, IEEE, Dec. 1996, pp. 158-169.27Quass, D. et al., "On-Line Warehouse View Maintenance", Proceedings of the 1997 ACM SIGMOD International Conference, ACM Press, 1997, pp. 393-404.28Quass, 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.29 *Ralph Kimball; "DBMS Online Data Warehouse Architect: Is Data Staging Relational? Or does it have more to do with sequentil processing?"; Apr. 1998; pp. 1-6.30 *Ralph Kimball; "DBMS online Data Warehouse Architect: Turbocharge Your Query Tools"; Sep. 1997; pp. 1-5.31 *Shawn Willet; "Beyond the Warehouse: IBM Banks on Channel to Restructure Now Corporations Organize, Store and Access Data Via Business Intelligence"; Mar. 16, 1998; pp. 111 and 113.32 *Star Schema; From Wikipedia, the free encyclopedia; http://en.wilipedia.org/wiki/Star-schema; Unknown date; pp. 1-4.33 *Star Schema; From Wikipedia, the free encyclopedia; http://en.wilipedia.org/wiki/Star—schema; Unknown date; pp. 1-4.34 *Tim Fielden; "Speedware's Media Makes OLAP Easy"; Mar. 23, 1998; p. 124.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.36Widom, J., "Research Problems in Data Warehousing", Proc. of 4th Int'l Conference on Information and Knowledge Management (CIKM), Nov. 1995, 6 pages.37Wiener, J. et al., "A System Prototype for Warehouse View Maintenance", The Workshop on Materialized Views, pp. 26-33, Montreal, Canada, Jun. 1996.38Yang, 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.39Yang, 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.40Zhuge, Y. et al., "Consistency Algorithms for Multi-Source Warehouse View Maintenance", Distributed and Parallel Databases, vol. 6, pp. 7-40 (1998), Kluwer Academic Publishers.41Zhuge, 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 dateApplicantTitleUS8055609 *Jan 22, 2008Nov 8, 2011International Business Machines CorporationEfficient update methods for large volume data updates in data warehousesUS8234240 *Apr 26, 2007Jul 31, 2012Microsoft CorporationFramework for providing metrics from any datasourceUS8352458 *May 7, 2008Jan 8, 2013Oracle International CorporationTechniques for transforming and loading data into a fact table in a data warehouseUS8429116 *May 31, 2008Apr 23, 2013International Business Machines CorporationEfficient update methods for large volume data updates in data warehousesUS8495007 *Aug 28, 2008Jul 23, 2013Red Hat, Inc.Systems and methods for hierarchical aggregation of multi-dimensional data sourcesUS8566345Jul 14, 2011Oct 22, 2013International Business Machines CorporationEnterprise intelligence (‘EI’) reporting in an EI frameworkUS8682936 *Dec 15, 2010Mar 25, 2014Microsoft CorporationInherited entity storage modelUS8983951 *Sep 6, 2007Mar 17, 2015International Business Machines CorporationTechniques for relating data in healthcare databasesUS20070299691 *Sep 6, 2007Dec 27, 2007Friedlander Robert RSystems and Computer Program Products for Relating Data in Healthcare DatabasesUS20080270369 *Apr 26, 2007Oct 30, 2008Microsoft CorporationFramework for providing metrics from any datasourceUS20080270469 *Apr 26, 2007Oct 30, 2008Microsoft CorporationBusiness metrics aggregated by custom hierarchyUS20090187582 *Jan 22, 2008Jul 23, 2009International Business Machines CorporationEfficient update methods for large volume data updates in data warehousesUS20090187602 *May 31, 2008Jul 23, 2009International Business Machines CorporationEfficient Update Methods For Large Volume Data Updates In Data WarehousesUS20090281985 *May 7, 2008Nov 12, 2009Oracle International CorporationTechniques for transforming and loading data into a fact table in a data warehouseUS20100057700 *Aug 28, 2008Mar 4, 2010Eric WilliamsonSystems and methods for hierarchical aggregation of multi-dimensional data sourcesUS20120041990 *Aug 10, 2010Feb 16, 2012Sap AgSystem and Method for Generating Dashboard Display in Software ApplicationsUS20120109888 *Dec 14, 2011May 3, 2012Beijing Borqs Software Technology Co., Ltd.Data partitioning method of distributed parallel database systemUS20120158757 *Dec 15, 2010Jun 21, 2012Microsoft CorporationInherited Entity Storage ModelUS20130219312 *Feb 22, 2012Aug 22, 2013Hanna Fouad Abi-SalehUser-configurable calculatorUS20140071272 *Jul 16, 2013Mar 13, 2014Digimarc CorporationSensor-based mobile search, related methods and systemsUS20140156643 *Dec 4, 2012Jun 5, 2014International Business Machines CorporationEnabling business intelligence applications to query semantic modelsUS20140201196 *Mar 14, 2014Jul 17, 2014International Business Machines CorporationEnabling business intelligence applications to query semantic modelsUS20150032687 *Jul 26, 2013Jan 29, 2015Honeywell International Inc.Methods and systems for providing intuitive direction for populating complex model content into a databaseWO2014178743A1 *Apr 29, 2013Nov 6, 2014Grigorev Evgeny AleksandrovichMethod for managing a relational databaseWO2016107497A1 *Dec 24, 2015Jul 7, 2016Huawei Technologies Co., Ltd.Method and apparatus for scalable sorting of data set* Cited by examinerClassifications U.S. Classification707/794, 709/201International ClassificationG06F17/30, G06F7/00, G06F15/16, G06F17/00Cooperative ClassificationG06F17/30592European ClassificationG06F17/30S8MLegal EventsDateCodeEventDescriptionMay 6, 1998ASAssignmentOwner name: EPIPHANY, INC.,CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WEISSMAN, CRAIG DAVID;WALSH, GREGORY VINCENT;WEGBREIT, ELIOT LEONARD;REEL/FRAME:009211/0234Effective date: 19980505Dec 21, 1998ASAssignmentOwner name: SILICON VALLEY BANK,CALIFORNIAFree format text: SECURITY INTEREST;ASSIGNOR:EPIPHANY MARKETING SOFTWARE, INC.;REEL/FRAME:009658/0439Effective date: 19981201May 17, 1999ASAssignmentOwner name: E.PIPHANY, INC.,CALIFORNIAFree format text: CHANGE OF NAME;ASSIGNOR:EPIPHANY MARKETING SOFTWARE, I NC.;REEL/FRAME:009961/0953Effective date: 19990406Jul 6, 1999ASAssignmentOwner name: COMDISCO, INC.,ILLINOISFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:E.PIPHANY, INC.;REEL/FRAME:010072/0496Effective date: 19990602Oct 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: 19990602Jul 2, 2002ASAssignmentOwner name: EPIPHANY MARKETING SOFTWARE, INC.,CALIFORNIAFree format text: RELEASE;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:013048/0056Effective date: 20020626May 5, 2006ASAssignmentOwner name: JP MORGAN CHASE BANK, N.A. AS COLLATERAL AGENT,NEWFree format text: SECURITY AGREEMENT;ASSIGNOR:SSA GLOBAL TECHNOLOGIES, INC.;REEL/FRAME:017575/0153Effective date: 20060207Jul 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: 20060728May 7, 2007ASAssignmentOwner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENTFree format text: SECURITY AGREEMENT;ASSIGNORS:E.PIPHANY, INC.;INFOR GLOBAL SOLUTIONS (CHICAGO), INC.;INFOR GLOBAL SOLUTIONS (MASSACHUSETTS), INC.;REEL/FRAME:019254/0202Effective date: 20070501May 8, 2007ASAssignmentOwner name: CREDIT SUISSE, CAYMAN ISLANDS BRANCH, AS SECOND LIFree format text: SECURITY AGREEMENT;ASSIGNORS:E. PIPHANY, INC.;INFOR GLOBAL SOLUTIONS (CHICAGO), INC.;INFOR GLOBAL SOLUTIONS (MASSACHUSETTS), INC.;REEL/FRAME:019260/0013Effective date: 20070302May 4, 2010ASAssignmentOwner name: INFOR GLOBAL SOLUTIONS (MICHIGAN), INC.,MICHIGANFree format text: MERGER;ASSIGNOR:E.PIPHANY, INC.;REEL/FRAME:024332/0398Effective date: 20070530Apr 17, 2012ASAssignmentOwner name: PROFUSE GROUP B.V., MINNESOTAFree format text: RELEASE;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLAND BRANCH, AS ADMINISTRATIVE AGENT;REEL/FRAME:028060/0116Effective date: 20120405Owner 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: SSA GLOBAL TECHNOLOGIES, INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Effective date: 20120405Owner name: E.PIPHANY, INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLAND BRANCH, AS ADMINISTRATIVE AGENT;REEL/FRAME:028060/0116Effective date: 20120405Owner name: INFOR GLOBAL SOLUTIONS (MASSACHUSETTS), INC., MINNFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Effective date: 20120405Owner name: E.PIPHANY, INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Effective date: 20120405Owner name: INVENSYS SYSTEMS INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Effective date: 20120405Owner name: EXTENSITY (U.S.) SOFTWARE, INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Effective date: 20120405Owner name: INFOR GLOBAL SOLUTIONS (MASSACHUSETTS), INC., MINNFree format text: RELEASE;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLAND BRANCH, AS ADMINISTRATIVE AGENT;REEL/FRAME:028060/0116Effective date: 20120405Owner name: INFOR GLOBAL SOLUTIONS (MICHIGAN), INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Effective date: 20120405Owner name: INFINIUM SOFTWARE, INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Effective date: 20120405Owner name: INFOR GLOBAL SOLUTIONS (CHICAGO), INC., 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., MINNESOTAFree 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., MINNESOTAFree format text: RELEASE;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLAND BRANCH, AS ADMINISTRATIVE AGENT;REEL/FRAME:028060/0116Effective date: 20120405Owner name: EXTENSITY, INC., MINNESOTAFree format text: RELEASE;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS ADMINSTRATIVE AGENT;REEL/FRAME:028060/0030Effective date: 20120405Apr 19, 2012ASAssignmentOwner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTHFree format text: SECURITY AGREEMENT;ASSIGNOR:INFOR GLOBAL SOLUTIONS (MICHIGAN), INC.;REEL/FRAME:028078/0964Effective date: 20120405Jan 15, 2014SULPSurcharge for late paymentJan 15, 2014FPAYFee paymentYear of fee payment: 4Aug 27, 2015ASAssignmentOwner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATEFree format text: SECURITY AGREEMENT;ASSIGNOR:INFOR (US), INC.;REEL/FRAME:036500/0896Effective date: 20150825Sep 10, 2015ASAssignmentOwner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATEFree format text: CORRECTIVE ASSIGNMENT TO REMOVE THE INCORRECT PATENT NUMBER 6617869 AND REPLACE PATENT NUMBER 6617969 PREVIOUSLY RECORDED AT REEL: 036500 FRAME: 0896. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT;ASSIGNOR:INFOR (US), INC.;REEL/FRAME:036585/0280Effective date: 20150825RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services