Abstract: The cost of running a query (having a query range) on a multidimensional database may be estimated using a process factors criteria beyond merely the number of affected records. First, a materialized view of the database may be represented as a container of tuples, sorted by key. Then keys may be stepped through, each key representing a mapping of a combination of tuples from the container. At each step, the process may request the next smallest key in the query range greater than or equal to the key of the current step, which results in the tuple in the database whose key is the smallest, greater than or equal to the requested key, and determine if the resulting is in the query range. The cost of the query may then be estimated as the number of tuples upon which the range check was performed.

Abstract: Selection of certain views of a multidimensional database to materialize may be accomplished using an efficient and effective solution. A set of all potential views may be stored in a structure. A path in the structure may then be traversed in an indicated direction through the structure, the path including two or more potential views and beginning at an indicated view. Then two or more immaterialized views in the path may be compared to each other to determine which immaterialized view is the optimum choice for maximizing benefit if selected to be materialized. Then the traversing and comparing may be continually iterated through, each iteration utilizing an indicated direction different than the last, each iteration also utilizing an indicated view set at the optimum choice determined by the last iteration, the iterating continuing until it converges on a single view. That single view may then be selected for materialization.

Abstract: The cost of running a query (having a query range) on a multidimensional database may be estimated using a process factors criteria beyond merely the number of affected records. First, a materialized view of the database may be represented as a container of tuples, sorted by key. Then keys may be stepped through, each key representing a mapping of a combination of tuples from the container. At each step, the process may request the next smallest key in the query range greater than or equal to the key of the current step, which results in the tuple in the database whose key is the smallest, greater than or equal to the requested key, and determine if the resulting is in the query range. The cost of the query may then be estimated as the number of tuples upon which the range check was performed.

Abstract: The cost of running a query (having a query range) on a multidimensional database may be estimated using a process factors criteria beyond merely the number of affected records. First, a materialized view of the database may be represented as a container of tuples, sorted by key. Then keys may be stepped through, each key representing a mapping of a combination of tuples from the container. At each step, the process may request the next smallest key in the query range greater than or equal to the key of the current step, which results in the tuple in the database whose key is the smallest, greater than or equal to the requested key, and determine if the resulting tuple is in the query range. The cost of the query may then be estimated as the number of tuples upon which the range check was performed.

Abstract: A framework is provided that enables data mining algorithms to be plugged into it without any change to algorithm software implementations, while still providing all the standard data mining tasks. It may be implemented by the data source provider. It also then allows for the complete separation of data storage and algorithms. When the user initiates a mining session and picks an algorithm for build task or a model for an apply or test task, the framework may become responsible for preparing a set of “prompts” to the user asking him to provide some expression which is specific to the particular kind of data the user is working with.

Abstract: The method of the present invention which employs conflation is based on pairing chains of arcs in order to determine the matching intersections between them. The chains are formed a priori in each map by using both attributes and geometric properties of the arcs. The intersections of chains are treated as relations, stored in a simple external custom relational database. The matching procedure is a set of the standard operations on RDBMS, as well as the sieving out of all possible ambiguous identifications. As a result, both maps become partitioned by the chains into much smaller pairwise matched areas called wards. The positional and semantic information from the matched chains is mapped onto the merged map. The mapping is performed by a general nonlinear transformation function. The transformation is then extended to the mapping of the unmatched content of wards onto the ultimate map.