Method for performing clustering in very large databases

Abstract

A method for performing cluster analysis inside a relational database management system. The method defines a plurality of tables for the storage of data points and Gaussian mixture parameters and executes a series of SQL statements implementing an Expectation-Maximization clustering algorithm to iteratively update the Gaussian mixture parameters stored within the tables.

Description

FIELD OF THE INVENTION

This invention relates in general to a relational database management system, and in particular, to an analytic algorithm implemented in SQL for performing cluster analysis in very large databases.

BACKGROUND OF THE INVENTION

Relational databases are the predominate form of database management systems used in computer systems. Relational database management systems are often used in so-called “data warehouse” applications where enormous amounts of data are stored and processed. In recent years, several trends have converged to create a new class of data warehousing applications known as data mining applications. Data mining is the process of identifying and interpreting patterns in databases, and can be generalized into three stages.

Stage one is the reporting stage, which analyzes the data to determine what happened. Generally, most data warehouse implementations start with a focused application in a specific functional area of the business. These applications usually focus on reporting historical snap shots of business information that was previously difficult or impossible to access. Examples include Sales Revenue Reporting, Production Reporting and Inventory Reporting to name a few.

Stage two is the analyzing stage, which analyzes the data to determine why it happened. As stage one end-users gain previously unseen views of their business, they quickly seek to understand why certain events occurred; for example a decline in sales revenue. After discovering a reported decline in sales, data warehouse users will then obviously ask, “Why did sales go down?” Learning the answer to this question typically involves probing the database through an iterative series of ad hoc or multidimensional queries until the root cause of the condition is discovered. Examples include Sales Analysis, Inventory Analysis or Production Analysis.

Stage three is the predicting stage, which tries to determine what will happen. As stage two users become more sophisticated, they begin to extend their analysis to include prediction of unknown events. For example, “Which end-users are likely to buy a particular product”, or “Who is at risk of leaving for the competition?” It is difficult for humans to see or interpret subtle relationships in data, hence as data warehouse users evolve to sophisticated predictive analysis they soon reach the limits of traditional query and reporting tools. Data mining helps end-users break through these limitations by leveraging intelligent software tools to shift some of the analysis burden from the human to the machine, enabling the discovery of relationships that were previously unknown.

Many data mining technologies are available, from single algorithm solutions to complete tool suites. Most of these technologies, however, are used in a desktop environment where little data is captured and maintained. Therefore, most data mining tools are used to analyze small data samples, which were gathered from various sources into proprietary data structures or flat files. On the other hand, organizations are beginning to amass very large databases and end-users are asking more complex questions requiring access to these large databases.

Unfortunately, most data mining technologies cannot be used with large volumes of data. Further, most analytical techniques used in data mining are algorithmic-based rather than data-driven, and as such, there are currently little synergy between data mining and data warehouses. Moreover, from a usability perspective, traditional data mining techniques are too complex for use by database administrators and application programmers, and are too difficult to change for a different industry or a different customer.

One analytic algorithm that performs the task of modeling multidimensional data is “cluster analysis.” Cluster analysis finds groupings in the data, and identifies homogenous ones of the groupings as clusters. If the database is large, then the cluster analysis must be scalable, so that it can be completed within a practical time limit.

In the prior art, cluster analysis typically does not work well with large databases due to memory limitations and the execution times required. Often, the solution to finding clusters from massive amounts of detailed data has been addressed by data reduction or sampling, because of the inability to handle large volumes of data. However, data reduction or sampling results in the potential loss of information.

Thus, there is a need in the art for data mining applications that directly operate against data warehouses, and that allow non-statisticians to benefit from advanced mathematical techniques available in a relational environment.

SUMMARY OF THE INVENTION

To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a method for performing cluster analysis in a relational database management system utilizing an analytic algorithm implemented in SQL. The method defines a plurality of tables for the storage of data points and Gaussian mixture parameters and executes a series of SQL statements implementing a clustering algorithm to update the Gaussian mixture parameters stored within the tables.

In the described embodiment, the method is applied to perform clustering within a relational database management system to group a set of n data points into a set of k clusters, each data point having a dimensionality p. A first table, C, having p columns and k rows, is established for the storage of means values, each column of C representing a cluster; a second table, R, having p columns and p rows, is established for the storage of covariance values; and a third table, W, having k columns and 1 row, is established for the storage of weight values; where n represents the number of data points, k is the number of clusters, and p represents the dimensionality of each data point. SQL commands implementing an Expectation-Maximization clustering algorithm are executed to iteratively update the means values, covariance values and weight values stored in the first, second and third tables.

The above and other objects, features, and advantages of the present invention will become apparent from the following description and the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numbers represent corresponding parts throughout:

FIG. 1 is a system diagram of the components of a computer system including a relational database management system (RDBMS) that could be used with one embodiment of the present invention;

FIG. 2 is a block diagram that illustrates an exemplary parallel processing computer hardware environment that could be used with the preferred embodiment of the present invention;

FIG. 3 is a table identifying matrices for the storage of Gaussian Mixture parameters in accordance with the present invention.

FIG. 4 is a table identifying the variables that establish the sizes for the matrices of identified in FIG. 3 .

FIG. 5 illustrates psuedo code for implementing an Expectation-Maximization clustering algorithm.

FIG. 6 identifies SQL tables utilized to implement a first, horizontal approach for performing clustering in very large databases in accordance with a first embodiment of the invention.

FIG. 7 illustrates SQL code for implementing a first, horizontal approach for performing clustering in very large databases in accordance with a first embodiment of the invention.

FIG. 8 identifies SQL tables utilized to implement a second, vertical approach for performing clustering in very large databases in accordance with a second embodiment of the invention.

FIG. 9 illustrates SQL code for implementing a second, vertical approach for performing clustering in very large databases in accordance with a second embodiment of the invention.

FIG. 10 identifies SQL tables utilized to implement a third, hybrid approach for performing clustering in very large databases in accordance with a preferred embodiment of the invention.

FIGS. 11 and 12 illustrates SQL code for implementing a third, hybrid approach for performing clustering in very large databases in accordance with a preferred embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the following description of the preferred embodiment, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration a specific embodiment in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

The present invention provides a relational database management system (RDBMS) that supports data mining operations of relational databases. In essence, advanced analytic processing capabilities for data mining applications are placed where they belong, i.e., close to the data. Moreover, the results of these analytic processing capabilities can be made to persist within the database or can be exported from the database.

A relational database management system is a software program that is used to create, maintain, update, modify and manipulate a relational database. Within a relational database data is stored in relations or tables. Within the table, data is organized in tuples, or records, and attributes, or fields. Each field in a table represents a characteristic of the subject of the table, and each record in the table represents a unique instance of the subject of the table. Each record in the table is composed of the complete set of fields, and is uniquely identified by a field identified as a primary key. Each attribute or field has a simple data type. Arrays, for instance, are not allowed.

Hardware Environment

The data comprising a database may reside within a single storage device, as shown in FIG. 1 , or may be distributed throughout a computer system or network, such as in the networked system illustrated in FIG. 2 . Referring to FIG. 1 , a computer system 100 is shown comprising one or more processors coupled to one or more fixed and/or removable electronic data storage units (DSUs) 102 , such as disk drives, that store one or more relational databases, along with other data and programs. The computer system 100 is connected to client systems, such as application or utility programs 104 and workstations 106 and 108 for application programmers, database administrators, and end users.

The computer system 100 executes RDBMS software 110 that acts as an interface between users and a relational database stored on the DSUs 102 . Operators of the computer system 100 use a terminal or workstation to transmit electrical signals to and from the computer system 100 that represent commands 112 for performing various search and retrieval functions, termed queries, and various data update functions. The RDBMS 110 then performs the desired data access 114 against the relational database, and data retrieved from the relational database is returned 114 to the users 102 , 104 , 106 .

FIG. 2 provides a block diagram of another computer hardware environment that could be used with the preferred embodiment of the present invention. In the exemplary computer hardware environment, a massively parallel processing (MPP) computer system 200 is comprised of one or more nodes 202 interconnected by a network 204 . Each of the nodes 102 is comprised of one or more processors, random access memory (RAM), read-only memory (ROM), and other components. It is envisioned that attached to the nodes 202 may be one or more fixed and/or removable data storage units (DSUs) 206 and one or more data communications units (DCUs) 208 .

Each of the nodes 202 executes one or more computer programs, such as a Data Mining Application (APPL) 210 performing data mining operations, Advanced Analytic Processing Components (AAPC) 212 for providing advanced analytic processing capabilities for the data mining operations, and/or a Relational Database Management System (RDBMS) 214 for managing a relational database 216 stored on one or more of the DSUs 206 for use in the data mining applications, wherein various operations are performed in the APPL 210 , AAPC 212 , and/or RDBMS 214 in response to commands from one or more Clients 218 . In alternative embodiments, the APPL 210 may be executed in one or more of the Clients 218 , or on an application server on a different platform attached to the network 204 .

Generally, the computer programs are tangibly embodied in and/or retrieved from RAM, ROM, one or more of the DSUs 206 , and/or a remote device coupled to the computer system 200 via one or more of the DCUs 208 . The computer programs comprise instructions which, when read and executed by a node 202 , causes the node 202 to perform the steps necessary to execute the steps or elements of the present invention.

In the preferred embodiment of the present invention, the queries conform to the Structured Query Language (SQL) standard and the RDBMS software 210 comprises the Teradata® product offered by NCR Corporation. Those skilled in the art will recognize, however, that the present invention has application to any RDBMS software 210 that uses SQL, and that other alternative hardware environments may be used without departing from the scope of the present invention. The RDBMS software 210 performs the functions necessary to implement the RDBMS functions and SQL standards, i.e., definition, compilation, interpretation, optimization, database access control, database retrieval, and database update.

Structured Query Language (SQL) is a well-known standardized data manipulation language used in databases. SQL can save a considerable amount of programming and is effective to write high-level queries. However, SQL is neither efficient nor adequate to do linear algebra operations. The Expectation—Maximization (EM) clustering algorithm implementation described below addresses this problem by converting matrices to relational tables and using arithmetic operators (+−*/) and functions (exp(x), ln(x)) available in the DBMS, as well as the following SQL commands: CREATE TABLE, used to define a table and its corresponding primary index; DROP TABLE, used to delete tables; INSERT INTO [table] SELECT, used to add data rows to one table from a select expression; DELETE, used to delete a number of rows from a table; and UPDATE, used to set columns to different values.

Expectation—Maximization (EM) Cluster Analysis

Clustering is one of the most important tasks performed in Data Mining applications. Cluster analysis finds groupings in the data, and identifies homogenous ones of the groupings as clusters. Unfortunately, most known clustering algorithms do not work well with large databases due to memory limitations and the execution times required. Often, the solution to finding clusters from massive amounts of detailed data has been addressed by data reduction or sampling, because of the inability to handle large volumes of data. However, data reduction or sampling results in the potential loss of information.

The present invention, on the other hand, solves this problem by performing cluster analysis within the parallel RDBMS 214 . In the preferred embodiment, the cluster analysis is performed using a series of Extended ANSI SQL statements and/or a series of scripts comprising groups of statements. A key feature of the present invention is that high-intensity processing (i.e., data intensive aspects) may be performed directly within the RDBMS using Extended ANSI SQL.

There are two basic approaches to perform clustering: those based on distance and those based on density. Distance-based approaches identify those regions in which points are close to each other according to some distance function. On the other hand, density-based clustering finds those regions which are more highly populated than adjacent regions. The Expectation-Maximization (EM) algorithm is an algorithm based on distance computation. It can be seen as a generalization of clustering based on computing a mixture of probability distributions.

The EM algorithm assumes that the data can be fitted by a linear combination (mixture) of normal (Gaussian) distributions. The probability density function (pdf) for the normal distribution on one variable x is: $$ p ⁡ ( x ) = 1 2 ⁢ πσ 2 ⁢ exp ⁢   [ - ( x - μ ) 2 2 ⁢ σ 2 ] EQN ⁢   ⁢ 1

This pdf has expected values: E[X]=μ, E[(x−μ) 2 ]=σ 2 . The mean of the distribution is μ and its variance is σ 2 . Samples from points having this distribution tend to form a cluster around the mean. The points scatter around the mean is measured by σ 2 .

The multivariate normal probability density function for a p-dimensional space is a generalization of the previous function. The multivariate normal density for a p-dimensional vector x=x 1 , x 2 , . . . , x p is: $$ p ⁡ ( x ) = 1 ( 2 ⁢ π ) p / 2 ⁢ &LeftBracketingBar; Σ &RightBracketingBar; 1 / 2 ⁢ exp ⁢   [ - 1 2 ⁢ ( x - μ ) t ⁢ Σ - 1 ⁡ ( x - μ ) ] EQN ⁢   ⁢ 2

where μ is the mean and Σ is the covariance matrix; μ is a p-dimensional vector and Σ is a p*p matrix. |Σ| is the determinant of Σ and the t superscript indicates transposition. The quantity δ 2 is called the squared Mahalanobis distance: δ 2 =(x−μ) t Σ −1 (x−μ). This formula forms the basic ingredient to implement EM in SQL.

The EM algorithm assumes the data is formed by the mixture of k multivariate normal distributions on p variables. The Gaussian (normal) mixture model probability function is given by: $$ p ⁡ ( x ) = ∑ i = 1 k ⁢   ⁢ ω i ⁢ p ⁡ ( x ∣ i ) EQN ⁢   ⁢ 3

where p(x|i) is the normal distribution for each cluster and ω i is the fraction (weight) that cluster i represents from the entire database. The present discussion focuses on the case that there are k different clusters, each having their corresponding vector μ, but all of them having the same covariance matrix Σ. However, this work may readily be extended to handle a different Σ for each cluster.

The EM clustering algorithm works by successively improving the solution found so far. The algorithm stops when the quality of the current solution becomes stable; as measured by a monotonically increasing statistical quantity called loglikelihood. The goal of the EM algorithm is to estimate the means C, the covariances R and the mixture weights W of the Gaussian mixture probability function described above. The parameters estimated by the EM algorithm are stored in the matrices illustrated in FIG. 3 whose sizes are shown in FIG. 4 .

The EM algorithm starts from an approximation to the solution. This solution can be randomly chosen, or set by the user when there is some idea about potential clusters. A common way to initialize the parameters is to set C←μ random( ), R←I and W←1/k; where μ is the global mean. It should be noted that this algorithm can get stuck in a locally optimal solution depending on the initial approximation, so one disadvantage of EM is that it is sensitive to the initial solution, and sometimes it cannot reach a global optimal solution. Nevertheless, EM offers many advantages in addition to being efficient and having a strong statistical basis. One of those advantages is that EM is robust to noisy data and missing information.

Pseudo code for the EM algorithm is shown in FIG. 5 . The EM algorithm has two major steps: an Expectation step and a Maximization step. The EM algorithm executes the Expectation step and the Maximization step as long as the change in global loglikelihood (referred to as llh inside the pseudo code) is greater than ε or as long as the maximum number of iterations has not been reached. The global loglikelihood is compute as llh=Σ i=1 n ln(sump i ). The variables δ, P, and X are x×k matrices storing Mahalanobis distances, normal probabilities and responsibilities, respectively, for each of the n points.

This is the basic framework of the EM algorithm and forms the basis for translation of the EM algorithm into SQL. There are several important observations, however:

C′, R′ and W′ are temporary matrices used in computations. Note that they are not the transpose of the corresponding matrices.

∥W∥=1, that is, Σ i=1 k ω i =1.

Each column of C is a cluster; C j is the jth column of C. y i is the ith data point.

R is a diagonal matrix in the context of this discussion (statistically meaning that covariances are independent), i.e., R ij =0 for i≠j. The diagonality of R is a key assumption to make linear gaussian models work with the EM algorithm. Therefore, the determinant and inverse of R can be computed in time O(p). Note that under these assumptions the EM algorithm has complexity O(kpn). The diagonality of R is a key assumption for the SQL implementation. Having a non-diagonal matrix would change the time complexity to O(kp 2 n).

The first important substep in the Expectation step is computing the Mahalanobis distances δij. With R assumed to be diagonal, the Mahalanobis distance of point y to cluster mean C having covariance R can be expressed by the following equation: $$ δ 2 = ( y - C ) t ⁢ ( y - C ) = ∑ i = 1 p ⁢ ( y i - C i ) 2 R i EQN ⁢   ⁢ 4

This is because R ij −1 =1/R ij . For a non-singular diagonal matrix, R −1 is easily computed by taking the multiplicative inverses of the elements in the diagonal. R −1 being a diagonal, all the products (y i −C i )R j −1 =0 when i≠j. A second observation is that R being diagonal can be stored as a vector saving space, but more importantly speeding up computations. Accordingly, R will be indexed with just one subscript in the discussion which follows. Since R does not change during the Expectation step its determinant can be computed only once, making probability computations (p ij ) faster. For the Maximization step, since R is diagonal the covariance computation is simplified. Elements off the diagonal in the computation (y i −C j )x ij (y i −C j ) t become zero. In simpler terms, R i =R i +x ij (y ij −C ij ) 2 is faster to compute. The remaining computations cannot be further optimized mathematically.

In practice p ij =0 sometimes, as computed in the Expectation step. This may happen because exp[−½δ ij ]=0 when δ ij >600; that is, when the Mahalanobis distance is large. There is a simple and practical reason for this: the numeric precision available in the computer. In most data base management systems and current computers the maximum accuracy available for numeric computations is double precision which uses 8 bytes. For this precision the exp(x) mathematical function is zero when x<−1200.

A large Mahalanobis distance for one point can be the result of noisy data, poor cluster initialization, or the point belonging to an outlier. This problem needed to be solved in order to make SQLEM a practical solution. Again, this problem occurs because the computer cannot keep the required accuracy, and not because the EM algorithm is making a wrong computation. To address this problem, the following equation provides an alternative for δ ij when distances are large: $$ p ij = 1 / δ ij ∑ j = 1 k ⁢   ⁢ 1 / δ ij , j ∈ { 1 ⁢   ⁢ … ⁢   ⁢ k } EQN ⁢   ⁢ 5

Note that this computation produces a higher probability to points closer to cluster j and is never undefined as long as distances are not zero. Also, if some distance δ ij is zero then exp(δ ij )=exp(0) is indeed defined (being equal to 1) and thus it can be used without any problem.

In many cases the individual covariance for some dimensions (variables) becomes zero in some clusters, or more rarely, in all the clusters. This can happen for a number of reasons. Missing information, in general, leaves numerical values equal to zero. Clusters involving categorical attributes tend to have the same value on the corresponding column. As shown in FIG. 5 , the Expectation step computes p ij = $$ ω j ( 2 ⁢ π ) p / 2 ⁢ &LeftBracketingBar; R &RightBracketingBar; 1 / 2 ⁢ exp ⁢   [ - 0.5 ⁢   ⁢ δ ij ] ⁢   ⁢   ⁢ for ⁢   ⁢ i = 1 ⁢   ⁢ … ⁢   ⁢ n ,   ⁢ j = 1 ⁢   ⁢ … ⁢   ⁢ k .

As can be seen, the computation for p ij requires dividing by {square root over (|R|)} and computing R −1 for Mahalanobis distances δ ij . Therefore, the problem is really a division by zero problem, which is undefined, and computing R −1 , which is also undefined. But the EM algorithm implementation described herein uses only one global covariance matrix for all the clusters, and therefore R=Σ i=1 k R i , where R i is the corresponding covariance matrix for cluster i. This is clearly illustrated in the Maximization step of FIG. 5 . It has been found in practice that as k grows the chance of having R i =0 is very small; although still possible. Having only one global covariance matrix R solves this problem in part, but results in a small sacrifice in cluster description accuracy.

In the event that ∃i, s.t. i∈{1 . . . k} and R i =0, the following method is used to compute |R| and R −1 . To compute the Mahalanobis distances, variables whose covariance is zero are skipped and dividing by zero avoided (R i =0). Having a null covariance means all the points have zero distance between them in the corresponding dimensions and there is no affect on δ ij . In other words, R −1 is computed for the subspace in which covariances are not zero. An analogous process is utilized to compute |R|. Note that noise independence implies |R|=Π i=1 p R i and null covariances can be ignored. Therefore, |R|=Π i=1,R i ≠ 0 p R i . But again, there is a price to pay: loglikelihood computation is affected. Skipping null covariances solves the problem of undefined computations but loglikelihood decreases sometimes.

Implementation of the EM algorithm in SQL

Two basic strategies for implementing the EM clustering algorithm in SQL are described herein: a horizontal implementation and a vertical implementation. These two strategies represent two extreme points to implementing the EM algorithm in SQL and there are tradeoffs regarding performance, flexibility and functionality between the two strategies. Experimental evaluation and practical constraints lead to a third hybrid approach, which will also be described herein.

The first challenge in implementing the EM algorithm in SQL is to compute the k squared Mahalanobis distances for each point to each cluster. The next challenge is to compute the k probabilities and k responsibilities. These are computed by evaluating the normal density function with the corresponding distance for each cluster. After responsibilities are computed the mixture parameters are updated; this requires computing several relational aggregate functions. Updating C and R requires several matrix products that are expressed as aggregate SQL sums of arithmetic expressions. Updating W requires only doing a SUM on computed responsibilities.

For the three approaches identified above, i.e., horizontal, vertical and hybrid, it is assumed that in general k≦p (for high-dimensional data) and p<<n. These assumptions are important for performance. In any case the solution described below will work well for large n as long as p<100, k≦100. The SQL code for the Expectation steps for the horizontal and vertical approaches are illustrated in FIGS. 7 and 9 , respectively. Since the hybrid approach is believed to be the best approach, it is analyzed in more detail and SQL code for both the Expectation and the Maximization steps are illustrated in FIGS. 11 and 12 , respectively. The SQL statements required to create and drop tables and their indexes, to delete rows, and to transpose C and R, are omitted for brevity.

Given a good initialization, the SQL Expectation-Maximization algorithm converges quickly. Clusters may be initialized to random values, or to parameters obtained from a sample, e.g. 5% for large data sets or 10% for medium sized data sets. To avoid making unnecessary computations, the maximum number of iterations is limited to some fixed number, such as ten iterations, possibly as high as twenty iterations.

The data points and the Gaussian mixture parameters must be stored in tables. Following the notation defined earlier, a few more conventions for naming columns in SQL are utilized in this discussion: column name i indicates the cluster number, i.e., i∈{1 . . . k}; column name ν indicates the variable number; that is, ν∈{1 . . . p}; val is the value of the corresponding column; w i indicates the ith cluster weight; and RID stands for row id which provides a unique identifier for each data point. Please refer to the tables shown in FIGS. 6 , 8 and 10 for a better understanding of these naming conventions.

All remaining parameters needed for computations are stored in a table called GMM (Gaussian Mixture Model). These parameters include all the matrix sizes p, k, and n; the constant needed in the density function computation twopipdiv2=(2π) p/2 ; the square root of the determinant of the covariance matrix sqrtdetR={square root over (|R|)} and number of iterations. The table YX stores the loglikelihood for each point as well as a score, which is the index of the cluster with highest membership probability for that point.

Horizontal Approach

Using the horizontal approach, the Mahalanobis distances are computed in k terms of a SELECT statement. Each of the k terms is a sum of squared distances divided by the corresponding covariance as seen in the previous section. This is very efficient since all k squared Mahalanobis distances (δ 2 ) are computed in one table scan, however since there are no arrays in SQL the sum has to be expanded to a long string to sum the p terms. For high dimensional data, the parser of the SQL interpreter may have difficulty handling such long statements. Even having user-defined functions does not solve this problem because of expression size. For this same reason many computations required by EM have to be broken down into several simpler SQL statements.

The time/space complexity for computing the k Mahalanobis distances for each of the n points is O(kp). This expression size can be a practical problem in almost any relational DBMS. For example, consider the difficulties computing parameters for 50 clusters for data having 100 σdimensions (k=50, p=100). One would need to compute squared differences on p terms, each being in the best case about 10 characters; add them p times, and then place k of those expressions into a single SQL statement. This would result in an expression having approximately 10×50×100≅50,000 characters. This length of an expression is beyond the capability of current database management systems.

The tables required to implement the horizontal approach in the most efficient manner are shown in FIG. 6 . It is important to note that C is stored in k tables, C 1 through C k , to avoid having k different select statements to compute distances. This avoids launching k statements in parallel, which would be slow, or doing the k selects sequentially. The SQL code for performing this operation is shown in FIG. 7 .

The process for updating the mixture parameters C, R and W will now be described. First of all, there is no need to create separate tables C′, W′ and R′ as seen in the pseudo code for the EM algorithm shown in FIG. 5 . All temporary results are stored in the corresponding tables C, R and W.

To update C it is necessary to execute k select statements updating C j , each statement computing the product y i x ij for j=1 . . . k, and then making a SUM over all n rows to update the cluster means from cluster j: table C j . Each of these k SELECT statements join tables Y and YX by the primary key RID, multiplying y i by x ij .

Updating weights in W′ is straightforward. The responsibilities and loglikelihood stored in YX are summed and then dividing by n. This is done through use of a single SELECT statement using the SQL aggregate function SUM. Having computed C′ and W′, C j is updated in accordance with C j =C′ j /W′ j . Having C updated, covariances R are computed by launching k SELECT statements, each statement computing R′=R′+(y i −C j )x ij (y−C j ) t with j=1 . . . k. Covariances R and weights W are updated in accordance with R=R′/n and W=W′/n. n is stored in the table GMM.

Vertical Approach

In accordance with the vertical approach, the n points are copied into a table having pn rows. Mahalanobis distances are then computed using joins. The tables required to implement the vertical approach in the most efficient manner are shown in FIG. 8 . In this case C is stored in one table.

Note that separate inserts are performed to compute distances, probabilities and responsibilities because aggregate functions cannot be combined with non-aggregate expressions in a single SQL select statement. YSUMP.sump=Σ i=1 k p i and it is computed using the SUM(column) SQL aggregate function. The SQL code for performing this function is shown in FIG. 9 . Note that the first SELECT statement computes distances. Once distances are computed probabilities are obtained by evaluating the multivariate normal distribution on each distance. This is done in the 2nd SELECT statement shown. Finally, the 3rd SELECT statement shown computes responsibilities x ij by dividing p ij /sump for j=1 . . . k. These responsibilities are the basic ingredient to update mixture parameters C, R, and W.

Mixture parameters C, R, and W are updated as follows. The first challenge is to compute the product y i x i t . Each of the p coordinates for y i are stored in one row in table Y, and each of the k responsibilities are stored in a different row in table YX. Therefore, the matrix product y i x i t is computed by performing a JOIN between Y and YX only on RID, multiplying value by x. This JOIN will produce pk rows for each of the n points. The corresponding temporary table YYX will have kpn rows—in general a much bigger number than n. C′ is computed using the SUM function over all rows of YYX, grouping by RID and inserting the aggregated pk rows into table C.

To update weights, responsibilities are added in YX. To that end, a SUM is performed on x grouping by RID on table YX inserting results into W. With these two summations C j is easily computed as C j =C′ j /W′ j by joining tables C and W on column i, dividing value by w. Once means C are recomputed, covariances R are recomputed. A JOIN of Y and C on ν performing a substraction of their corresponding value columns, and squaring the difference, produces results on temp table YC. Once these squared differences are computed, a JOIN is performed with tables YC and YX on RID, multiplying the squared difference by x and then SUM over all rows. This will effectively recompute R. Finally, covariances R and weights W are updated in accordance with R=R′/n and W=W′/n. n is stored in the table GMM.

Hybrid Approach

The hybrid approach combines elements of both the horizontal and the vertical approaches. The horizontal approach is more efficient than the vertical approach since it minimizes I/O; while the vertical approach provides greater flexibility, but has higher overhead in the number of temporary tables created for joins. For each of the n points the hybrid solution computes the k distances vertically using SQL aggregate functions (SUM(column)) and computes probabilities, responsibilities and mixture parameters horizontally projecting expressions having p or k terms. The tables required for this approach are shown in FIG. 10 . The SQL code for the Expectation and Maximization steps is shown in FIGS. 11 and 12 , respectively.

Before each insertion (in general INSERT INTO table SELECT exp.) the tables C, R, CR, W, YD, YP and YX are left empty; that is, their respective rows are deleted. These drop/deletion SQL statements are not shown in the FIGS. to keep the SQL code shorter and easier to understand. The C and R matrices are transposed and copied into CR. This is accomplished by launching several UPDATE statements in parallel. W stores the cluster weights as well as the loglikelihood. The first SQL statement in the Expectation step shown in FIG. 11 computes |R|. The SQL code shown accommodates null probabilities by using the approximation $$ 1 / d suminvd

described earlier. Null covariances are handled by inserting a 1 instead of zero in the tables CR and R, but as mentioned earlier this has an impact in loglikelihood accuracy.

For this solution the computation of distances requires a join creating a temporary table with pn rows and k columns. The computation of probabilities and responsibilities requires joins with only n rows at any intermediate step. C and R are updated by inserting rows from k separate SELECT statements. This is necessary for two reasons: first, expression size could be a problem if all parameters are updated in one wide table; and second, high-dimensional data could easily exceed the maximum number of columns in the DBMS.

The query costs incurred by the hybrid approach are as follows. For each iteration, the computation of distances requires scanning a table having pn rows. The computation of probabilities and responsibilities each require one scan on n rows. Updating C and R require k table scans on n rows each. Updating W requires only one scan on n rows. All other computations involve only scans on tables having less than p or k rows. Overall, one iteration of the EM algorithm requires 2k+3 scans on tables having n rows, and one scan on a table having pn rows. The theoretical minimum of table scans on n rows required by the EM algorithm is only 4: two for the Expectation step and two for the Maximization step. The Expectation step reads the input points Y and writes the responsibilities X, and the Maximization step reads the input table Y as well as the responsibilities in the table X. This points out to several optimizations that can be made in the algorithm if scans can be synchronized and more computations are done in a single SELECT statement.

Given current practical constraints found in the Teradata DBMS, it is expected that the hybrid implementation described herein is useful for clustering problems having n≦1.0E+8, p≦100, k≦100 and pk≦1000. These numbers clearly represent large problem sizes.

Several optimizations are utilized to make the SQL code effective. The most important optimizations are as follows.

Updates are slower than inserts. The reason for this is that updates involve 2 I/Os for each data block and inserts only one. Whenever there are two or more tables in one statement the access plan requires joins, even if some of the tables have only one row. This is particularly troublesome to compute distances because if Y is one table and C is stored in k tables with only one row, joins are performed anyway. To reduce the overhead of joins, only one intermediate join produces pn rows—the SELECT statement to compute distances. All the remaining joins always produce intermediate tables having only n rows.

As stated earlier, the Teradata DBMS returns rows in a normal query in an unpredictable order unless the user specifies that rows should be ordered by primary key. This happens because queries are executed in parallel in several processors, and the results are assembled together in one processor. However, the solution described herein does not require ordering results in any SELECT statements; this is crucial to keep the time complexity of the EM algorithm unchanged. This is accomplished this by always joining tables using the column RID.

For a large table, that is, a table storing n rows, it is faster to drop and create a table than deleting all the records. This is not true if the table is small (C, R and W) since the overhead to drop and create a table is greater than just deleting a few rows. As mentioned earlier, the DBMS used executes queries in parallel. One way to speedup the process is to make data block size smaller. In this way there is a finer grain for parallelism, and the optimizer can better balance load among processors.

CONCLUSION

This concludes the description of the preferred embodiment of the invention.

The foregoing description of the preferred embodiment of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto.

Claims

1. A method for performing clustering within a relational database management system, the method comprising the steps of:establishing at least one table for the storage of Gaussian mixture parameters; and executing a series of SQL commands to update the Gaussian mixture parameters within said at least one table.

2. The method for performing clustering within a relational database management system in accordance with claim 1, wherein said SQL statements implement an Expectation-Maximization clustering algorithm.

3. A method for performing clustering within a relational database management system to group a set of n data points into a set of k clusters, each data point having a dimensionality p, the method comprising the steps of:establishing a first table, C, having p columns and k rows, for the storage of means values; establishing a second table, R, having p columns and p rows, for the storage of covariance values; establishing a third table, W, having k columns and 1 row, for the storage of weight values; and executing a series of SQL commands implementing an Expectation-Maximization clustering algorithm to iteratively update the means values, covariance values and weight values stored in said first, second and third tables.

4. The method for performing clustering within a relational database management system in accordance with claim 3, wherein said step of executing a series of SQL commands implementing an Expectation-Maximization clustering algorithm to iteratively update the means values, covariance values and weight values stored in said first, second and third tables continues until a specified number of iterations has been performed.

5. The method for performing clustering within a relational database management system in accordance with claim 3, wherein said first, second and third tables represents matrices.

6. The method for performing clustering within a relational database management system in accordance with claim 5, wherein said third table, R, represents a diagonal matrix.

7. The method for performing clustering within a relational database management system in accordance with claim 3, wherein:k≦p; and p<<n.

8. The method for performing clustering within a relational database management system in accordance with claim 7, wherein:p≦100, and k≦100.

9. The method for performing clustering within a relational database management system in accordance with claim 3, further comprising the steps of:establishing a fourth table, Z, having p column and n rows, for the storage of dimensionality values p for each data point n; and establishing a fifth table, Y, having 1 column and p*n rows, for the vertical storage of data points and dimensionality values; and wherein said step of executing a series of SQL commands implementing an Expectation-Maximization clustering algorithm to iteratively update the means values, covariance values and weight values stored in said first, second and third tables includes the steps of: for each of said n data points, calculating Mahalanobis distances using a vertical approach wherein said Mahalanobis distances are calculated by using SQL aggregate functions joining tables Y, C and R; and for each of said n data points, calculating means values, covariance values and weight values using a horizontal approach.