Source: http://www.docstoc.com/docs/58010366/Method-And-System-For-Creating-A-Well-formed-Database-Using-Semantic-Definitions---Patent-7739224
Timestamp: 2014-07-30 08:47:52
Document Index: 93484209

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']

Method And System For Creating A Well-formed Database Using Semantic Definitions - Patent 7739224
United States Patent: 7739224
7,739,224
Method and system for creating a well-formed database using semantic
A 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 to rules of correctness and produces results
that conform to the rules. The organization is defined by a data
organization definition that specifies tables, their columns, and the
relationships between tables. The operations define procedures that
operate on the tables and the table columns. Importantly, the operations
are defined along with the tables, columns, and relationships, so that
the resulting system is well-formed.
Weissman; Craig David (Belmont, CA), Walsh; Gregory Vincent (Cupertino, CA), Wegbreit; Eliot Leonard (Palo Alto, CA)
(Bingham Farms,
09/073,748
707/794  ; 709/201
G06F 7/00&amp;nbsp(20060101); G06F 15/16&amp;nbsp(20060101); G06F 17/00&amp;nbsp(20060101); G06F 17/30&amp;nbsp(20060101)
707/1-10,100-104,200-206,104.1 717/5,116,102,104,105,12,13 705/10,36 345/741,700,781,764 715/203,205,738,751 706/45 709/201
Brachman, Ronald J., Khabaza, Tom, Kloesgen, Willi, Piatetsky-Shapiro, Gregory, and Simoudis, Evangelos; &quot;Mining Business Databases,&quot; vol. 39,
issue 11; Nov. 1996; pp. 42-48. cited by examiner
Friedland, Liam; &quot;Accessing the Data Warehouse: Designing Tools to Facilitate Business Understanding&quot;; vol. 5, issue 1; Jan. 1998; pp. 25-36. cited by examiner
Michael Krippendorf and Il-Yeol Song; &quot;The Translation of Star Schema into Entity-Relationship Diagrams&quot;; IEEE; Sep. 1-2, 1997; pp. 390-395. cited by examiner
Matteo Golfarelli, Dario Maio, and Stefano Rizzi;&quot;Conceptual Design of Data Warehouses from E/R Schema&quot;; IEEE; Jan. 6-9, 1998; pp. 1-10. cited by examiner
Ralph Kimball; &quot;DBMS Online Data Warehouse Architect: Is Data Staging Relational? Or does it have more to do with sequentil processing?&quot;; Apr. 1998; pp. 1-6. cited by examiner
Ralph Kimball; &quot;DBMS online Data Warehouse Architect: Turbocharge Your Query Tools&quot;; Sep. 1997; pp. 1-5. cited by examiner
Star Schema; From Wikipedia, the free encyclopedia; http://en.wilipedia.org/wiki/Star.sub.--schema; Unknown date; pp. 1-4. cited by examiner
PR Newswire; &quot;Influence Software to Integrate Aperio With Silicon Graphics MineSet for Web-Based Data Mining/Data Warehouse Suite&quot;; Apr. 14, 1998; pp. 1 and 2. cited by examiner
Diane Vint-Johnson and Deborah Henderson; &quot;A Short Course on OLAP Tools&quot;; Apr. 1998; pp. 15-17. cited by examiner
Tim Fielden; &quot;Speedware&#39;s Media Makes OLAP Easy&quot;; Mar. 23, 1998; p. 124. cited by examiner
Shawn Willet; &quot;Beyond the Warehouse: IBM Banks on Channel to Restructure Now Corporations Organize, Store and Access Data Via Business Intelligence&quot;; Mar. 16, 1998; pp. 111 and 113. cited by examiner
Business Wire; &quot;Hyperon Software Announces New Family of Multi-Dimensional Business Analysis Applications; Purpose-Built Applications Move Beyond Raw OLAP Tools and Technologies&quot;; Mar. 2, 1998; pp. 1-5. cited by examiner
Kimball, R., &quot;The Data Warehouse Toolkit&quot;, (1996) John-Wiley &amp; Sons, Inc., 388 pages (includes CD ROM). cited by other
Chawathe, S. et al., &quot;Change Detection in Hierarchically Structured Information&quot;, SIGMOD Record, vol. 25, No. 2, Jun. 1996, pp. 493-504. cited by other
Chawathe, S. et al., &quot;Meaningful Change Detection in Structured Data&quot;, Proceedings of the 1997 ACM SIGMOD International Conference, ACM Press, 1997, pp. 26-37. cited by other
Labio, W. et al., &quot;Efficient Snapshot Differential Algorithms for Data Warehousing&quot;, Department of Computer Science, Stanford University, (1996), pp. 1-13. cited by other
Wiener, J. et al., &quot;A System Prototype for Warehouse View Maintenance&quot;, The Workshop on Materialized Views, pp. 26-33, Montreal, Canada, Jun. 1996. cited by other
Kawaguchi, A. et al., &quot;Concurrency Control Theory for Deferred Materialized Views&quot;, Database Theory--ICDT &#39;97, Proceedings of the 6th International Conference, Delphi, Greece, Jan. 1997, pp. 306-320. cited by other
Zhuge, Y. et al., &quot;Consistency Algorithms for Multi-Source Warehouse View Maintenance&quot;, Distributed and Parallel Databases, vol. 6, pp. 7-40 (1998), Kluwer Academic Publishers. cited by other
Zhuge, Y. et al., &quot;View Maintenance in a Warehousing Environment&quot;, SIGMOD Record, vol. 24, No. 2, Jun. 1995, pp. 316-327. cited by other
Widom, J., &quot;Research Problems in Data Warehousing&quot;, Proc. of 4th Int&#39;l Conference on Information and Knowledge Management (CIKM), Nov. 1995, 6 pages. cited by other
Mar. 1998, pp. 389-403. cited by other
Quass, D., &quot;Maintenance Expressions for Views with Aggregation&quot;, Proceedings of the 21st International Conference on Very Large Data Bases, IEEE, Zurich, Switzerland, (Sep. 1995), 9 pages. cited by other
Mumick, I. et al., &quot;Maintenance of Data Cubes and Summary Tables in a Warehouse&quot;, Proceedings of the 1997 ACM SIGMOD International Conference, ACM Press, 1997, pp. 100-111. cited by other
Huyn, N., &quot;Multiple-View Self-Maintenance in Data Warehousing Environments&quot;, Proceedings of the 23rd International Conference on Very Large Data Bases, IEEE, (1997), pp. 26-35. cited by other
Quass, D. et al., &quot;Making Views Self-Maintainable for Data Warehousing&quot;, Proceedings of the Fourth International Conference on Parallel and Distributed Information Systems, IEEE, Dec. 1996, pp. 158-169. cited by other
Quass, D. et al., &quot;On-Line Warehouse View Maintenance&quot;, Proceedings of the 1997 ACM SIGMOD International Conference, ACM Press, 1997, pp. 393-404. cited by other
Gupta, H., &quot;Selection of Views to Materialize in a Data Warehouse&quot;, Database Theory--ICDT &#39;97, Proceedings of the 6th International Conference, Delphi, Greece, Jan. 1997, pp. 98-112. cited by other
Harinarayan, V. et al., &quot;Implementing Data Cubes Efficiently&quot;, SIGMOD Record, vol. 25, No. 2, Jun. 1996, pp. 205-216. cited by other
Gupta, H. et al., &quot;Index Selection for OLAP&quot;, IEEE Paper No. 1063-6382/97, IEEE (1997), pp. 208-219. cited by other
Labio, W. et al., &quot;Physical Database Design for Data Warehouses&quot;, IEEE Paper No. 1063-6382/97, IEEE (1997), pp. 277-288. cited by other
Gupta, A. et al., &quot;Aggregate-Query Processing in Data Warehousing Environments&quot;, Proceedings of the 21st VLDB Conference, Zurich, Switzerland, Sep. 1995, pp. 358-369. cited by other
O&#39;Neill, P. et al., &quot;Improved Query Performance with Variant Indexes&quot;, Proceedings of the 1997 ACM SIGMOD International Conference, ACM Press, 1997, pp. 38-49. cited by other
McAlpine, G. et al., &quot;Integrated Information Retrieval in a Knowledge Worker Support System&quot;, Proc. of the Intl. Conf. on Research and Development in Information Retrieval (SIGIR), Cambridge, MA, Jun. 25-28, 1989, Conf. 12, pp. 48-57. cited by other
Tsuda, K. et al., &quot;IconicBrowser: An Iconic Retrieval System for Object-Oriented Databases&quot;, Proc. of the IEEE Workshop on Visual Languages, Oct. 4, 1989, pp. 130-137. cited by other
&quot;Multiple Selection List Presentation Aids Complex Search&quot;, IBM Technical Disclosure Bulletin, vol. 36, No. 10, Oct. 1993, pp. 317-318. cited by other
Mike Feuche, &quot;Index Interface Links CASE and IBM&#39;s DB2,&quot; Oct. 24, 1988, Index Technology Corp., Computer-aided Software Engineering, Product Announcement, MIS Week, V9, N43, p. 23(2). cited by other.
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.
3.  The method of claim 1, further comprising: building aggregate tables according to the received instructions.
4.  The method of claim 1, further comprising: receiving further instructions defining a query mechanism from a user;  and generating queries according to the received further instructions.
5.  The method of claim 1, further comprising: generating reports according to the received instructions.
6.  The method of claim 1, further comprising: 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: 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, the received instructions containing semantic definitions for the metadata schema;  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.
10.  The method of claim 9, wherein automatically generating the database system for business further comprises: generating tables automatically according to the received instructions.
11.  The method of claim 9, further comprising: building aggregate tables according to the received instructions.
12.  The method of claim 9, wherein operating on the database system for business further comprises: receiving further instructions defining a query mechanism from a user;  and generating queries according to the received further instructions.
13.  The method of claim 9, wherein operating on the database system for business further comprises: generating reports according to the received instructions.
14.  The method of claim 9, further comprising: receiving a modification of the metadata schema;  and adjusting the database system for business automatically according to the modification.
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.
17.  A computer system, comprising: a computer including a processor and a memory;  a computer program stored in the memory and executed by the processor, wherein the computer program includes computer instructions for: 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
18.  The computer system of claim 17, wherein the computer program further includes computer instructions for: generating tables automatically according to the received instructions.
19.  The computer system of claim 17, wherein the computer program further includes computer instructions for: building aggregate tables according to the received instructions.
20.  The computer system of claim 17, wherein the computer program further includes computer instructions for: receiving further instructions defining a query mechanism from a user;  and generating queries according to the received further
21.  The computer system of claim 17, wherein the computer program further includes computer instructions for: generating reports according to the received instructions.
22.  The computer system of claim 17, wherein the computer program further includes computer instructions for: receiving a modification of the metadata schema;  and adjusting the database system for business automatically according to the
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.
25.  A computer system, comprising: a computer including a processor and a memory;  a computer program stored in the memory and executed by the processor, wherein the computer program includes computer instructions for: 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, the received instructions
including semantic definitions for the metadata schema;  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.
26.  The computer system of claim 25, wherein the computer program further includes computer instructions for: generating tables automatically according to the received instructions.
27.  The computer system of claim 25, wherein the computer program further includes computer instructions for: building aggregate tables according to the received instructions.
28.  The computer system of claim 25, wherein the computer program further includes computer instructions for: receiving further instructions defining a query mechanism from a user;  and generating queries according to the received further
29.  The computer system of claim 25, wherein the computer program further includes computer instructions for: generating reports according to the received instructions.
30.  The computer system of claim 25, wherein the computer program further includes computer instructions for: receiving a modification of the metadata schema;  and adjusting the database system for business automatically according to the
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: 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.
34.  The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises: generating tables automatically according to the received instructions.
35.  The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises: building aggregate tables according to the received instructions.
36.  The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises: receiving further instructions defining a query mechanism from a user;  and generating queries according to the received
37.  The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises: generating reports according to the received instructions.
38.  The computer readable storage medium of claim 33, wherein execution of the software instructions further comprises: receiving a modification of the metadata schema;  and adjusting the database system for business automatically according to
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: 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, the received instructions containing semantic definitions for the metadata schema;  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.
42.  The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises: generating tables automatically according to the received instructions.
43.  The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises: building aggregate tables according to the received instructions.
44.  The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises: receiving further instructions defining a query mechanism from a user;  and generating queries according to the received
45.  The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises: generating reports according to the received instructions.
46.  The computer readable storage medium of claim 41, wherein execution of the software instructions further comprises: receiving a modification of the metadata schema;  and adjusting the database system for business automatically according to
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.  Description
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,752, entitled &quot;Method and Apparatus for Creating and Populating a Datamart,&quot; 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 &quot;Method and Apparatus for Creating Aggregates for Use in a Datamart,&quot; 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 &quot;Method and Apparatus for Creating a Datamart and for Creating a Query Structure for the Datamart,&quot; 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).
One embodiment of the invention includes a 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.  The definition can then be used to automatically
create and populate the well-formed database system.  The well-formed database system conforms to rules of correctness and produces results that conform to the rules.  The organization is defined by a data organization definition that specifies tables,
their columns, and the relationships between tables.  The operations define procedures that operate on the tables and the table columns.  Importantly, the operations are defined along with the tables, columns, and relationships, so that the resulting
system is well-formed.  Without this invention, database systems can be constructed in an arbitrary and inconsistent fashion which can result in an incorrectly constructed database system.
In some embodiments, when the database system is created, it automatically includes the following capabilities: foreign key tracking, automatic indexing, time and date information inclusion.  By including some or all of such capabilities in the
database system, the system will operate to comply with the rules of correctness.
The following are aspects of various embodiments of the invention.  The constructed well-formed database system can automatically guarantee the following.  (1) Two columns related by a relational join will be from the same domain.  (2) If table A
has a many-to-one relationship to table B, then table A has a foreign key that corresponds to table B. (3) A many-to-many relationship, between two tables A and B, is always expressed by an associative table that is created in a uniform way.  For each
unique many-to-many relationship, a unique value is created in the associative table and reused whenever that many-to-many relationship occurs.  Denormalization is always done correctly.  (4) Pulling information from one table to be put into another
table, for access efficiency, is done correctly.
In some embodiments of the invention, the data organization definition includes a schema description for a datamart.  The datamart automatically includes the inclusion of transaction type information and the mapping of source system keys.  In
these embodiments, the operation definitions define one or more of the following sets of operations: datamart population operations, aggregate creation and maintenance operations, query and result interface operations.
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.
automatic creation and processing of aggregates from aggregate definitions.  The system also supports the creation of the query mechanisms from query definitions.
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
extraction and conversion of the data from the source systems 110 can be performed, aggregates are set up, arid a query mechanism is generated.
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.
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
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
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).
constructing real tables in the datamart 150.  The dimension base type indicates the type of a dimension base, either default or special (special includes &quot;date&quot; and &quot;transaction type,&quot; which are used by the system 100).  The truncate stage flag operates
in the manner similar to other is truncate stage flags.
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 &quot;&amp;lt;working directory&amp;gt;,&quot; indicating the path to the working director where job log files are stored.
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 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&#39;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 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&#39;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
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.
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
defined in the schema definitions 161.  In other embodiments, templates are not used but the &quot;post-parsed SQL&quot; 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.
price, quantity etc.).  Since there is only a single salesrep_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 involving 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.
As mentioned above, the other type of template is the denormalized data template.  This is a variant of the &quot;Team&quot; 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 (&quot;Greg Walsh&quot;, A-key, team 1-key), (&quot;Craig&quot;, B-key, team1-key), (&quot;Ben&quot;, C-key&quot;
team1-key), (&quot;Greg Walsh&quot;, A-key&quot;, 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.
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.
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
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
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
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.
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 &quot;snapshot&quot; 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&#39; 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.
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 &quot;hops&quot; 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
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.
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.
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
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_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. 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. 14 illustrates a fact column window 1400 opened on the definition of the net_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 are set, the consultant then defines the connectors 162 to the source systems 110.  The connectors, as noted above, define how information is to be
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 datamart 150 is well-formed.
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
16.  To achieve these results, the consultant need only perform the following steps: 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.
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
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
TABLE-US-00001 ********************************************************************* Query log ********************************************************************* time : &amp;lt;A Date Here&amp;gt; addr : 192.0.0.210 host : 192.0.0.210 user : agent :
Mozilla/4.01 [en] (WinNT; U) Datebase information: DRIVER=(SQL SERVER);SERVER=bigfoot;DATABASE=macromedia Keys and values coming in from the browser: file = fileDesc = queryaction = QUERY hidden_queryaction = QUERY OK_callback = NOK_callback = ticksheet
= Orders hidden_ticksheet = Orders Rows = Customer hidden_Rows = Customer Columns = Fiscal Year hidden_Columns = Fiscal Year units = Price hidden_units = Price facttype = Shipped hidden_facttype = Shipped facttype2 = Gross hidden.sub.-facttype2 = Gross
stage = Orders hidden_stage = Orders currencyunits = Thousands hidden_currencyunits = Thousands rowtotal = yes hidden_rowtotal = yes columntotal = yes hidden_columntotal = yes percent = none hidden_percent = none precision = 0 hidden_precision = 0 charts
= 30 hidden_charts = 30 maxrows = 10 hidden_maxrows = 10 rowsorttype = value hidden_rowsorttype = value Fiscal_Years = All hidden_Fiscal_Years = All Fiscal_Quarters = All hidden_Fiscal_Quarters = All Calendar_Months = All hidden_Calendar_Months = All
Business_Units = All hidden_Business_Units = All Product_Lines = All hidden_Product_Lines = All Product_Supergroups = All hidden_Product_Supergroups = All Platforms = All hidden_Platforms = All Product_Languages = All hidden_Product_Languages = All
Product_SKUs = All hidden_Product_SKUs = All Product_SKU = Sales_Reps = All hidden_Sales_Reps = All Channels = All hidden_Channels = All Customer_Types = All hidden_Customer_Types = All Customer_Regions = All hidden_Customer_Regions = All Customers = All
hidden_Customers = All Customer = sqStyle = classic hidden_sqStyle = classic Contents 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 = All The colheaders are: The Cellitems are:  Price Shipped Gross Orders The Cellitems abreviated are: Dollar Amount Shipped Gross Orders pid is: 310 spid is:
25 The valid collheaders are: The invalid colheaders are: The valid cellitems are: Price Shipped Gross Orders The invalid cellitems are: The unitstack is: CURRENCY The celistack is: -SUM (Order.net_price) The selectstack is: -SUM (Order.net_price) The
typestack is: SHIP Transtypes are: &quot;BEGIN_RETURN&quot; = 1007 &quot;END_GROSS&quot; = 1004 &quot;END_SRBOTH&quot; = 1018 &quot;END_SRADJ&quot; = 1012 &quot;BOOK&quot; = 1 &quot;BEGIN_ANET&quot; = 1013 &quot;END_IADJ&quot; = 1024 &quot;END_ICOMP&quot; = 1022 &quot;BEGIN_GROSS&quot; = 1003 &quot;BEGIN_SRBOTH&quot; = 1017 &quot;END_SBOTH&quot; = 1016 &quot;END&quot; =
1002 &quot;BEGIN_SRADJ&quot; = 1011 &quot;END_SADJ&quot; = 1010 &quot;BEGIN_IADJ&quot; = 1023 &quot;BEGIN_ICOMP&quot; = 1021 &quot;END_NET&quot; = 1006 &quot;SHIP_ADJUST&quot; = 103 &quot;LOST&quot; = 3 &quot;END_SAIL&quot; = 1020 &quot;BEGIN_SBOTH&quot; = 1015 &quot;BEGIN&quot; = 1001 &quot;BEGIN_SADJ&quot; = 1009 &quot;BOOK_RETURN&quot; = 2 &quot;END_FADJ&quot; = 1026 &quot;BEGIN_NET&quot;
= 1005 &quot;BEGIN_SALL&quot; = 1019 &quot;GL&quot; = 105 &quot;SHIP_RETURN&quot; = 102 &quot;SHIP_RADJ&quot; = 104 &quot;SHIP&quot; = 101 &quot;END_RETURN&quot; = 1008 &quot;INV_ADJUST&quot; = 201 &quot;LEAD_LOST&quot; = 4 &quot;BEGIN_FADJ&quot; = 1025 &quot;FINV_ADJUST&quot; = 202 &quot;END_ANET&quot; = 1014 The facttable is: Order The 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 -&amp;gt; 0)= (SUM(20)) R1(1) = SUM(20) 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)) 0 The unique facttables are:Order The number of unique facttables are: 1 The unique types are:SHIP Table to unique number lookup Order
=&amp;gt; _0_ Begin work on the query based on the facttable Order Phase 1: Table Order.  Creating table aliases ( 10 ) JOIN_FIELD IS CUSTOMER_BILLTO_KEY FOR Customer JOIN_FIELD IS FOR Fiscal Year SQL table aliases: Order.quadrature.  : T3 Date.quadrature.
: T2 Customar.quadrature.CUSTOMER_BILLTO_KEY : T1 Table aliases: tablealiaslookup(T1) = Customer tablealiaslookup(T2) = Date tablealiaslookup(T3) = Order selectalias: Customer: T1.base_name Fiscal Year: T2.fy_name selectstackalias: -SUM(Order.net_price):
-SUM(T3.net_price) joinalias: Customer: T1.customer_key = T3.customer_billto_key Phase 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_name, Type = T3.Transtype_key, C0 = -SUM(T3.net_price), Rows = T1.base_name INTO #tmp_0_ FROM Customer T1, Date T2, Order T3 WHERE T1.customer_key = T3.customer_billto_key and T2.date_key =
T3.date_key and T3.Transtype_key in (101) GROUP BY T1.base_name, T2.fy_name, T3.Transtype_key ********************************************************************* Selecting appropriate aggregate for the query.
********************************************************************* Phase 0: Aggregate navigator.  Preparing for query building and execution.  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_0, DATE_4, ORDER_86), now select ********************************************************************* SQL after going through the aggregate navigator: SELECT Columns = T2.fy_name, Type =
T3.Transtype_key, C0 = -SUM(T3.net_price), Rows = T1.base_name INTO #tmp_0_ FROM CUSTOMER_0 T1, DATE_4 T2, Order_86 T3 WHERE T1.customer_key = T3.customer_billto_key and T2.date_key = T3.date_key and T3.Transtype_key in (101) GROUP BY T1.base_name,
T2.fy_name, T3.Transtype_key Phase 7: Building results table in sql ( 10435 ) Phase 15: splitting tables by type (needed = 0) ( 0 ) Phase 16: Merging results into one table (needed = 0) ( 0 )GR_COLS = CO = SUM(C0) SQL: SELECT Rows INTO #tmpAllRows FROM
#tmp_0_ GROUP BY Rows ORDER BY SUM(C0) DESC SQL: SELECT count(Rows) FROM #tmpAllRows Phase 17: Extracting rows and doing number of total records (10508/10499) ( 1022 ) SQL: set rowcount 10 SELECT Rows INTO #tmpTopRows FROM #tmpAllRows set rowcount 0
Phase 19: Sorting, Top (needed = 10498) ( 10 ) -- creating row totals SELECT #tmp_0_.Rows, C0 = SUM(C0) INTO #tmpRows FROM #tmp_0_, #tmpTopRows WHERE #tmp_0_.Rows = #tmpTopRows.Rows GROUP BY #tmp_0_.Rows -- creating col, grand totals SELECT Columns, C0 =
SUM(C0) INTO #tmpColumns FROM #tmp_0_ GROUP BY Columns Checking ADJ of GRAND SQL: SELECT C0 = SUM(C0) INTO #tmpGrand FROM #tmpColumns -- final results table SELECT #tmp_O_.Rows, Columns, C0 INTO #tmpFinalResults FROM #tmp_0_, #tmpTopRows WHERE
#tmp_0_.Rows = #tmpTopRows.Rows Phase 20: Filtering results ( 841 ) Phase 21: Reading Row Totals ( 10 ) Phase 22: Reading Column Totals ( 10 ) Phase 23: Reading Grand ( 10 ) SQL: -- calculate remaining columns SELECT Columns = #tmpColumns.Columns, C0 =
#tmpColumns.C0 - ISNULL(SUM(#tmpFinalResults.C0),0) INTO #tmpRemaining FROM #tmpFinalResults, #tmpColumns WHERE #tmpColumns.Columns *= #tmpFinalResults.Columns GROUP BY #tmpColumns.Columns, #tmpColumns.C0 select C0 = SUM(C0) from #tmpRemaining Phase 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 FROM BUILD_AND_EXEC:0 Getting results
took 12658 milliseconds.  Phase 0: Begining output generation.  Phase 3: performing cumulative (if necessary).  ( 0 ) Dollar Amount / Shipped / Gross The columns are: 1994 1995 1996 1997 1998 The 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.
Method and system for creating a well-formed database using semantic definitions, Weissman, et al., Craig David Weissman, Gregory Vincent Walsh, Eliot Leonard Wegbreit, Application number 09 073-748, Data Processing:Database And File Management Or Data Structures, Electrical Computers And Digital Processing Systems: Multicomputer Data Transferring, Issue date, Google Scholar, computer program, file system, user interface, data object, computer system, Patent Number, present invention provides
CROSS REFERENCES TO RELATED APPLICATIONSThis 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 thisinvention. The group of applications includes the following.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 andJeremy 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).COPYRIGHT NOTICEA portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent disclosure, as it appears in the Patentand Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.THE FIELD OF THE INVENTIONThis invention relates to the field of databases. In particular, the invention relates to creating databases, and loading and accessing data in the databases.BACKGROUND OF THE INVENTIONMany different types of databases have been developed. On line transaction processing (OLTP) databases are examples of typical databases used today. OLTP databases are concerned with the transaction oriented process
well-formed requirements - Dots & Boxes
PROPERTIES OF PLASMINOGEN ACTIVATORS FORMED BY OTHER DOCS BY Patents-77