Practical Business Intelligence with SQL Server 2005

Data mining features are provided as part of the Analysis Services engine, so many of the usual management tasks are still applicable, but data mining also adds some new areas to be aware of.

Deployment

We are adding the visit information and customer-segmentation mining models to an existing BI solution, so the main deployment challenge that we face is for the product recommendations mining model. Because this model will be used on the live Internet site, we need to deploy an additional Analysis Server that can be accessed by the Web application servers.

Deploying the Mining Model to the Production Server

Because we built our mining model using an Analysis Services cube as the source, we need to find a way to get the processed cube and mining models onto the production server. The easiest way to do this is to back up the Analysis Services database and restore it in production.

If we had built our mining model using a relational database as the source rather than an Analysis Services cube, we could easily have deployed the mining model using DMX's EXPORT command, by running a DMX query in SQL Server Management Studio with the following syntax:

EXPORT MINING MODEL [Product Recommendations] TO 'C:\ProductRec.abf' WITH PASSWORD='MyPassword'

Remember that the path you specify is on the server, not on the client machine that you are running the DMX query from. The file will contain everything we need to make predictions, so we can copy it to the production server, create a new Analysis Services database, and import the model using a DMX query with the following syntax:

IMPORT FROM 'C:\ProductRec.abf' WITH PASSWORD='MyPassword'

Securing the Mining Model

Because we will be accessing the product recommendations mining model from a Web application, we need to set up the security correctly to allow the IIS user account to query the Analysis Server. We need to create a special role in the production Analysis Services database that has the IIS account (such as IUSR_machinename) as a member, and then enable Read and Read Definition permissions for the mining structure and model.

Maintenance

Any future changes that you make to the mining model definitions will need to be redeployed to the server and will also require processing the changed models. Mining structures can include more than one model on the same underlying data (for example, using different algorithms or even just different algorithm settings), so you might need to add new models to handle future business requirements.

Operations

Just like Analysis Services cubes, we need to reprocess mining models to train them with new input data. There is no "incremental process" option with mining models, however, so you need to reprocess using the full data set.

The product recommendations model probably needs to be reprocessed on a regular basis so that it is kept current with the latest products and sales trends. In our e-commerce solution, the model is reprocessed on a weekly basis and then copied from development into the Web production environment. The customer segmentation model will be used for marketing processes such as organizing marketing campaigns that take some time to complete, so the model will not be reprocessed often.

Tip: Reprocessing Mining Models Drops Cluster Names

Another reason that the customer segmentation model is not reprocessed often is that the carefully selected cluster names such as Defector and Newbie are replaced with the default Cluster 1 and Cluster 2 names during processing. This is also important to know during development when you are designing your model, because you will be losing any cluster names every time you need to change anything in the model.