一旦跟踪被创建，客户端应用程序就将订阅这个跟踪。订阅跟踪的功能与执行返回表型结果的服务器请求的功能非常相似。它将返回一个表，表中包含由select事件选出的列。与普通的服务器查询相比，订阅（Subscribe）语句将一行行的保存返回的事件，直到发送一个停止订阅（Unsubscribe）命令给服务器，订阅语句才终止执行。进度通知仅在操作未完成时有用；在所有的操作都执行完毕后，进度通知就没有什么用处了。这也就是为什么带进度通知的模型使用两个不同线程进行处理的原因。
第一个线程创建跟踪，然后通知第二个线程进行订阅。
第二个线程进行订阅，并确认它设置了所有访问响应信息表而需要的执行属性。只要有服务器端响应出现，它马上能一行一行的对表进行访问，而不需要等所有响应都发送回来后再进行操作。
之后，第一个线程发出处理命令，并等待处理完成。
同时，第二个线程收到进度通知，并在用户界面显示它们。
当处理操作进行完毕，不论成功还是失败，第一个线程必须停止订阅跟踪并将跟踪删除。
在删除跟踪之前，第二个进程将接收到表结束的通知，第二个进程结束。
在之前的章节中，我们已经知道了如何在OLE DB和Adomd.NET中提交语句。为了在传输结束前得到所需的行，即得到结束响应，执行命令应该接收一个特定的API标志。例如，在OLE DB中，DBPROP_CANFETCHBACKWARDS 和DBPROP_CANSCROLLBACKWARDS属性必须为否（FALSE）。在Adomd.NET中，ExecuteReader 函数有一个可选属性CommandBehavior，它应该被设置为只进（Forward only）执行模型SequentialAccess。
下面的代码是包含第二个线程的函数以及主线程的程序框架：
AdomdConnection  conn = new AdomdConnection();
conn.ConnectionString = "Data Source=localhost; " +
"Initial Catalog=MyCatalog";
conn.Open();

AdomdCommand cmd = new AdomdCommand();
cmd.Connection = conn;

cmd.CommandText = // 将创建跟踪的代码拷到这里!!
// 执行创建查询的语句
cmd.ExecuteNonQuery();
// 启动一个新的线程来读取跟踪
Thread traceThread = new Thread(new ThreadStart(TraceProc));
traceThread.Start();

// 继续进行处理操作
cmd.CommandText = // Processing statement,DDL or DMX, here

// 执行处理命令
try{
cmd.ExecuteNonQuery();
}
catch (System.Exception ex){
// 报错
    Console.WriteLine(ex.Message);
}
finally{
    // 不论处理结果是什么都删除跟踪
    cmd.CommandText =
"
"xmlns=\"http://schemas.microsoft.com/analysisservices/2003/engine\">"+
"  " +
"    DemoTrace" +
"  " +
"";
cmd.ExecuteNonQuery();
}

// 跟踪读取线程进度
public static void TraceProc()
{
// 在相同服务器上开始一个新的联接AdomdConnection
    AdomdConnection conn = new AdomdConnection ();
    conn.ConnectionString = "Data Source=localhost; " +
"Initial Catalog=MyCatalog";
    conn.Open();
    AdomdCommand traceCmd = new AdomdCommand();
    traceCmd.Connection = conn;
// DDL订阅（Subscribe）命令
    traceCmd.CommandText =   "<Subscribe "+
"xmlns=\"http://schemas.microsoft.com/analysisservices/2003/engine\">"+
    "  <Object>" +
    "    <TraceID>DemoTrace</TraceID>" +
    "  </Object>" +
    "</Subscribe>";

// 得到一个前向Data Reader
AdomdDataReader traceRdr =
traceCmd.ExecuteReader(CommandBehavior.SequentialAccess);
try{
// 从跟踪程序中读取进度通知并显示
       while (traceRdr.Read()){
           string textData = traceRdr.GetString(3);
           if (textData != null)
              Console.WriteLine(textData);
       }
}
catch(System.Exception {
// 跟踪的异常情况：有可能是“服务器上的跟踪已经被删除（The trace was deleted
// on the server）”终止了跟踪
}
finally{
    // 关闭用户界面（UI）
       Console.WriteLine("Trace Completed");
}
}
向我们之前所说到一样，SQL Server 的分析器使用起来非常容易，创建跟踪也很容易。它提供了很多跟踪对象的高级功能，如行过滤器。

无服务器的数据挖掘：本地挖掘模型

Microsoft Analysis Services 2005 为进程内服务器提供有限的功能。它提供了一种可以将服务器代码装载到你的应用程序的内存空间中的方法，而不用真正打开一个到服务器的连接。这个功能可以在面向数据挖掘的文件“本地挖掘模型”或者面向OLAP的文件“本地立方体”中查询。在本文中，我们使用“本地服务器”。
本地服务器的目的是允许在脱机情况下进行与数据挖掘有关的操作。要用到这一特性的场景多为（但不限制于）嵌入式应用。
例如，我们可以在真正的服务器上设计并训练一个非常有用的挖掘模型，这个模型可以在集群上区分WEB请求，例如“小负荷的快速请求”、“小负荷的慢速请求”、“大负荷的慢速请求”。这样的一个挖掘模型可以用来解决基于集群的不同WEB服务器的平衡装载问题。但是，平衡装载解决方案也可能在分析服务器上执行请求，用来判断发送请求的集群是哪个，哪台机器存在潜在的时间消耗问题和可能出现安全问题（分析服务所在的机器应该在平衡装载方案所在的网络内，只不过它一般在防火墙以外）。而进程内服务器就是此种情况的解决方案。一旦训练模型从服务器上传输到具有装载平衡解决方案的机器上，这个模型就可以使用进程内服务器来执行请求。此时，请求的速度非常快（这些请求在同一个进程中，远强于通过网络进行传输），微软分析服务也是安全的被保护在防火墙内的。
微软分析服务保存所有的被调用的数据文件夹中的元数据（带挖掘结构和挖掘模型的数据库），这个文件夹是在运行安装程序时进行配置的。本地服务器在一个文件中保存所有的元数据，这个文件一般都使用扩展名.cub。一旦连接到本地服务器，应用程序就可以开始创建数据库、挖掘结构、挖掘模型了，并可以像在真正的服务器上一样使用它们。所有的元数据都将被创建和存储到.cub 文件中。如果应用程序被关闭了，当本地服务器被旧的.cub 文件重新初始化的时候，所有的已存在元数据将被保存和加载。
所有之前所提到的数据访问API都可以连接到本地服务器。开发者只需要使用.cub 文件的名字来代替之前的连接字符串中的服务器名（在代码示例中是“localhost”）即可。下面，给出一个Adomd.NET的例子：
AdomdConnection  conn = new AdomdConnection();
conn.ConnectionString = "Data Source=c:\\test.cub; ";
conn.Open();

Similar code for AMO looks like:
Microsoft.AnalysisServices.Server server = new Server();
server.Connect("c:\\test.cub");

我们需要记住的是，在执行创建之前，.cub 文件中并没有数据库。
所以，我们需要做的第一件事就是创建一个新的数据库。需要这样做的一个例外是DMX的CREATE语句。当使用CREATE语句在没有可用数据库的情况下创建新的挖掘模型或者新的挖掘结构时，.cub 文件中将自动生成一个新的目录。
在连接成功以后，本地服务器就可以像真正的服务器一样被访问了。但是，本地服务器所能提供的连接也具有一些局限性：
·         本地服务器不支持多个同步连接（所以，像在之前一节讨论的一样，我们无法收到进度通知）
·         本地服务器不支持数据库备份和存储。
·         本地服务器不支持DMX 导入（IMPORT）语句。但是它支持DMX导出（EXPORT）语句。
·         本地服务器只支持有限的数据挖掘算法（Microsoft_Decision_Trees 和 Microsoft_Clustering).

扩展SQL Server 数据挖掘功能

到目前为止，我们已经讨论了很多种数据访问API在服务器上执行语句的方法。无论是数据定义语言（DDL）还是DMX，这些语句都是数据挖掘的类SQL语言。在这一节中，我们将讨论扩展服务器功能的若干方法：
·         添加新的函数和存储过程。
·         添加新的服务器端算法。
·         添加新的模型查看器（客户端）。

使用Adomd.NET Server 扩展DMX

Adomd.NET服务器是一个托管库，它和Microsoft Analysis Services 2005服务器产品一起进行安装。所以，它可以被任何托管语言所使用（如C# 或Visual Basic .NET）。Adomd.NET服务器可以用来创建两类服务器扩展：函数和存储过程。
存储过程是一个单机执行单元。它可以通过DMX语句被自己调用，例如：
CALL TestAssembly.MyNamespace.MyClass.MyStoredProcedure()

存储过程可以像任何DMX请求一样返回表型返回值；或者只执行服务器端操作，返回成功或失败。
服务器函数是一个辅助执行单元，它参与常规DMX查询。查询可以是这样的：
SELECT Function1() FROM MyModel WHERE Function2()

在Microsoft Analysis Services 2005中，为了创建一个函数或者存储过程，我们需要创建一个托管类库（或程序集），然后在服务器上部署它。程序集可以让所有服务器可视（需要服务器管理许可），或者仅存在于数据库中（需要数据库管理许可）。程序集对象有一些安全特性，包括许可集（描述授权给.NET代码的许可）和模拟信息（当程序集中的代码被执行时，什么帐号将被模拟）。SQL Server 2005在线文档包含关于程序集的许可集以及模拟模式的细节信息。就本文的来说，我们将使用Safe许可集，并模拟当前用户。程序集中公共类的每个公共方法都可以用作服务器函数或者存储过程。它们之间的区别在于服务器函数应该有返回值（一个数值或者一个表型目录），而存储过程返回一个空值（表示执行成功）或者一个表型目录（DataTable对象或者被IDataReader接口执行的对象），存储过程不能返回一个数值（实际上它们可以返回数值，但是数值不能被调用者当作CALL DMX语句的返回值而返回）。
当引用托管存储过程或者服务器函数的时候，必须使用完整的限定名。完整的限定名的BNF格式如下所示：
<AssemblyName>[.<Namespace>]+[.<ClassName>].<MethodName>

AssemblyName 是程序集的名字，它在程序集被部署的时候定义。它是必须被提供的。<Namespace> 是简单（或嵌套）命名空间，包含目标类和方法。<ClassName> 是包含方法的类。<MethodName>是真正的方法。<MethodName> 也是必须被提供的。请注意<Namespace> 和 <ClassName> 并不是强制性必须提供的。当在一个程序集中的多个函数/存储过程相互之间不明确时，必须使用这两个字段。完整的限定名（包括Namespace和ClassName）可以被本章内所有的语句使用。
当创建服务器函数或者存储过程时，时刻注意这些对象可能被多个用户同时调用是非常重要的。 类实例不能被多个调用所共享。所以当一个存储过程或者函数被调用的时候，没有一个动作来改变类的状态。而是根据传输给方法的参数来重新初始化状态的。说到参数：它们只能是数值。服务器函数和存储过程不能使用表作为参数。
下面我们使用一个DMX查询例子来演示一个简单的服务器函数是如何丰富用户经验的。这个查询在挖掘模型Model1中使用，这个模型用来根据性别列的F值和M值预测性别。我们尝试将这个查询进行改进：
SELECT Gender FROM Model1 [PREDICTION JOIN ... AS T]

这个查询将返回一列是M或F的值。
下面的服务器函数包含的代码将性别指示器转换为更加可读的字符串。它将M返回为Male ，将F返回为Female 。
namespace TestSP
{
public class StoredProc
{
       public string RecodeGender(string strGender)
       {
           if (strGender == "M") return "Male";
           if (strGender == "F") return "Female";
           return strGender;
       }
}
}

一旦类库包含了已经建立和部署了的类定义，服务器函数可以这样被调用：
SELECT TestSP.TestSP.StoredProc.RecodeGender(Gender) FROM Model1PREDICTION JOIN ... AS T

新的查询将返回包含Male 或 Female的列。
让我们现在来关注一下服务器函数的参数：列名。DMX分析引擎检测到Gender 是一个列名，它是一个可预知的列，这一列在服务器函数调用的时候被赋值。我们也可以使用PREDICTION JOIN 操作（类似于T.Gender）的输入数据中来传输列，用以代替这个可预知的列。这个函数可以被修改成多个参数，并且通过这些参数执行多个操作（比如串联字符串、带数字参数的算术运算符等等）。
简单的存储过程可以使用相同的方式来定义。在相同的类中，我们可以添加一个返回表型目录的新函数（在本例中是一个DataTable）。
public DataTable GetWeekDays()
{
    DataTable tbl = new DataTable();
    tbl.Columns.Add("Day", typeof(int));
    tbl.Columns.Add("Name", typeof(string));

    object[] row = new object[2];
    row[0] = 0;
    row[1] = "Sunday";
    tbl.Rows.Add(row);

    row[0] = 1;
    row[1] = "Monday";
    tbl.Rows.Add(row);
    ...
    row[0] = 6;
    row[1] = "Saturday";
    tbl.Rows.Add(row);

    return tbl;
}

存储过程可以被DMX语句调用：
CALL TestSP.TestSP.StoredProc.GetWeekDays()

现在让我们来看更加复杂的情况。使用[College Plans]挖掘模型，它根据父母的鼓励和IQ来预测学生的大学计划，我们需要将每个带说明的预测结果联系起来。我们可以使用之前的查询来获得预测结果。预测的原因可以在挖掘模型中每个节点的NODE_DESCRIPTION列中找到。预测节点可以通过通用DMX功能PredictNodeId 来判断。所以，这个查询可以修改成这样：
SELECT CollegePlans, PredictNodeId(CollegePlans) FROM [College Plans]
[PREDICTION JOIN ...]

作为本节的补充内容，我们可以忽略请求中的PREDICTION JOIN部分，因为它与服务器函数和存储过程的设计无关。
PredictNodeId 返回节点的唯一名字NODE_UNIQUE_NAME，这个名字决定了预测的内容。关于NODE_UNIQUE_NAME 的描述NODE_DESCRIPTION可以通过执行内容查询来判断。例如：
SELECT NODE_UNIQUE_NAME, NODE_DESCRIPTION FROM [College Plans].Content

现在，为了得到带预测描述的预测结果，我们需要将第一个查询的结果和使用了NODE_UNIQUE_NAME 的第二个查询的结果连接起来，使用它们二者的查询结果作为连接的关键字。但是，至少在当前版本中，DMX是不支持连接（JOIN）子句的。
此时，我们可以写一个返回节点描述的服务器函数，使用节点唯一的名字作为参数。假设我们已经定义了这样的一个函数，它的名字是GetNodeDescription，查询就变成了这样：
SELECT
CollegePlans,
TestSP.TestSP.StoredProc.GetNodeDescription(
PredictNodeId(CollegePlans) )
FROM [College Plans] PREDICTION JOIN ...

如我们之前所提到的一样，DMX执行引擎将在调用服务器函数之前执行PredictNodeId。因此，服务器函数将接收到参数——节点唯一的名字，此时它唯一需要做的就是去访问服务器当前的上下文、浏览挖掘模型的内容、以及确定各个节点的节点描述。
这时Adomd.NET服务器就显得非常有用了。为使用Adomd.NET服务器，类库必须包含一个特殊程序集的引用，它将服务器内部开放给存储过程和函数。这个程序集是msmgdsrv.dll，它在Microsoft Analysis Services 2005 服务器安装目录中。
在添加好引用以后，我们可以这样使用它：
using Microsoft.AnalysisServices.AdomdServer;

在使用程序集后，服务器上下文已经作为静态Context类可用了。
此时，程序集中的每种方法都可以使用Context 来访问服务器当前的上下文了。
使用Context类与在应用中使用动态Adomd.NET客户端库的 AdomdConnection 对象是一样的。在关于Adomd.NET 的章节中，我们已经讨论了使用Adomd.NET的类AMO方式公开服务器元数据的方法。在客户端API，元数据被发现（Discovery）方法重新得到；于此同时，在服务器端Adomd.NET库，它们直接访问服务器内存空间。
再回来看我们尝试编写的函数，Context 对象提供了所有我们需要的内容，如下：
public string GetNodeDescription(string nodeUniqueName)
{
MiningContentNode node =
Context.CurrentMiningModel.GetNodeFromUniqueName(nodeUniqueName);
return node.Description;
}
这时发生了什么：
·         Context “知道”哪个是CurrentMiningModel，因为函数调用发生在DMX语句执行的时候，这个DMX语句拥有当前的挖掘模型（在我们的例子中是[College Plans]模型）。
·         MiningModel 作为 CurrentMiningModel 公开的方法被返回， GetNodeFromUniqueName 根据节点的唯一名称返回 MiningContentNode节点。
·         MiningContentNode 有一个Description 属性，这个属性包含该节点的NODE_DESCRIPTION 值。
一旦程序集被部署完毕——被家长鼓励且智商在110以上的学生，用服务器函数进行查询得到的结果是这样的：
College Plans = Does not plan to attend
Node Description = "ParentEncouragement='Encouraged' and IQ >= 101"

我们的目标实现了；我们使用一个简单的查询得到了之前需要使用连接（JOIN）才能得到的结果， Analysis Services 2005并不支持JOIN。
Adomd.NET服务器库公开的Context 类包含所有关于发现（Discovery）的程序集，它使用客户端AdomdConection对象。所以，在服务器函数或者存储过程中，开发者可以遍历一个或多个挖掘模型的内容，或者OLAP对象如立方体和维度。服务器函数和存储过程的一个非常重要的区别在于CurrentMiningModel 只可以在服务器函数中使用。这是因为DMX分析引擎不能通过如下的语句来判断当前的挖掘模型：
CALL MyStoredProcedure()

即使存储过程将挖掘模型名称作为参数（一种常用的方法），也不存在简单的描述目标挖掘模型将哪些参数作为考虑对象的方式。除此以外，存储过程不能只支持当前挖掘模型这样的概念，因为有时候它不得不处理复杂的模型。
Microsoft Analysis Services 2005所提供的数据挖掘工具使用存储过程来减少服务器和客户端间的总通讯量。大多数挖掘模型查看器需要通过完全遍历来识别服务器提供的模式。不使用存储过程，整个挖掘模型不得不在客户端被全部下载，存储在内存中，并且需要对其进行遍历才能知道哪些模式是所感兴趣的。使用存储过程，内容遍历在服务器上进行（在服务器上模型的内容已经装载到内存中了），并且存储过程的结果只包括查看器需要的信息（例如在微软集群查看器中查看两台机器的区别，或者在微软相关规则查看器中查看含有指定内容的规则）。
与客户端Adomd.NET 库相似，在服务器端，我们也定义一个AdomdCommand 对象。可以通过在当前数据库上执行DMX查询来使用这个对象。与客户端命令的一个不同在于，服务器端命令只执行DMX语句（它不支持DDL或者OLAP MDX查询）。服务器端 AdomdCommand 与其客户端命令非常相似：它提供ExecuteReader 和 ExeuteNonQuery 两个方法，并且支持参数，也支持表型参数。
下面的代码段向我们展示了一个服务器端命令对象的例子，以及如何执行查询的方法：
public IDataReader ExecuteContentQuery(string strModel)
{
    AdomdCommand cmd = new AdomdCommand();
    cmd.CommandText = "SELECT NODE_UNIQUE_NAME, NODE_RULE " +
"FROM [" + strModel + "].CONTENT";
    return cmd.ExecuteReader();
}

这个机制也可以包含DXM查询语句，修改后的语句如下：
CALL TestSP.testSP.StoredProc.ExecuteContentQuery( "College Plans" )

请注意，当前的服务器并不支持返回嵌套表的存储过程。但是，存储过程可以返回表型结构（例如，DataTable 或者IDataReader对象），这些表型结构可以是服务器端连续发出的普通表型查询响应。这条规则有一个例外：存储过程也可以返回一个DataSet 对象。此时，DataSet 对象被完全串联成一个字符串。不论DataSet 的结构是什么样子的，服务器响应都包含一条线和一列值，列中存储着DataSet 的串联字符串。服务器端负责存储新DataSet 对象中的串联字符串。客户端 Adomd.NET API会自动进行存储。
由服务器端AdomdCommand 对象执行的DMX语句不一定非要被查询。例如CREATE MINING MODEL 或者INSERT INTO语句都可以在这里使用。如果一个挖掘模型在存储过程中被创建或者删除，Context类公开的关系型数据模型集合就需要被更新（通过调用这些集合中的Refresh方法来实现）。
存储过程和服务器函数是DMX框架最有力的扩展。它们可以增强内容查看器的性能，并且用一个全新的方式来展示训练挖掘模型的一系列规则。并且，它们也增强了DMX查询的功能和DMX语言的灵活性。

插件算法和内容查看器

Microsoft Analysis Services 2005 提供一系列强大的算法，这些算法可以用来解决很大范围内的商业问题。但是，一些特殊问题所需要的数据挖掘模型算法并不在常用的模型集合中。这也就是为什么服务器要提供插件控件来扩展算法的原因。新的算法必须是COM服务器，它执行一系列指定的接口，并且使用另外一些由服务器提供的接口。这样的插件算法将自动使用新数据挖掘模型平台所提供的很多特性：
·         元数据定义和管理
·         粒度访问许可模型
·         具有高可扩展性的查询
·         训练和预测事例集标记
·         DMX查询语言及分析
·         对存储过程和服务器功能的支持
基本上，新的算法只需要关心如何在训练集中查找模式以及如何得到一个输入事例，而不需要关心这两个动作以外的事情。“SQL Server数据挖掘：插件算法”白皮书提供书写插件算法的具体内容。
在客户端，数据挖掘尝试着提供了一些通用的算法查看器。不管当前要处理的商业问题是什么，这些查看器都可以显示每个算法有用的可视信息。用来解决具体问题的数据挖掘应用程序则需要特定的查看器，这些特定的查看器可以更好的解决具体的问题。插件算法也可能并不公开被内置查看器所管理的内容。这也就是为什么数据挖掘工具提供了一种习惯模型查看器插件的原因。关于这个插件的具体内容，请看《建立插件查看器指南》。

应用场景建议

这一章试图为开发者提供一些数据挖掘应用常见场景的快速开发建议。这些建议并不是全面的，而且有些建议可能具有一定的局限性。但是，它们是数据挖掘开发团队在使用Microsoft Analysis Services 2005开发具体应用程序时的经验之谈。
先给出一个基本的建议：因为数据挖掘OLE DE规范包含DMX的所有内容，所以充分理解DMX是使用Microsoft Analysis Services的数据挖掘进行开发最快的方式。

应用场景1：简单的数据挖掘预测

以下应用程序的目的是进行简单的预测。
·         要编写执行数据挖掘查询操作（包含预测）的代码，最简单的方式是使用Adomd.NET。Adomd.NET一节包含的代码可以直接复制到你的应用中，根据应用程序的具体情况修改后即可使用。
·         一个非常常见的场景是根据一个单一的实例进行预测（单一预测）。如果数据来自客户的输入，强烈建议你使用参数化语句，从而可以避免畸形DMX语句、用户插入的DMX等语句。
·         如果应用程序进行预测以外的动作（允许客户选择模型、列之类的），使用Adomd.NET 公开的程序集是最简单的发现服务器元数据的方法。

应用场景2：Web应用——使用服务器上现有模型的规则

除了上述场景外，WEB应用也应该可以将所有的用户输入作为查询的参数进行传输。WEB应用除了有可能在执行DMX语句时报错，也可能是被恶意用户发布的。这些恶意用户最可能将一些DMX代码加入到你的语句中。尽管DMX语句在设计时尽量注意缩小被感染后的危害（很多语句不许使用；SELECT语句不能随意的连接到DELETE 或DROP语句），恶意用户仍然可以连接到钻取（drill through）结果，或者至少可以产生一段畸形查询，这段畸形查询潜在的使你的应用变慢甚至摧毁你的应用。
WEB应用应该在明确定义的用户帐号下运行。不允许公共WEB应用模拟远程用户。所以，我们应该小心的挑选运行这类应用的用户，并且给这类账号很小的权限。
当微软分析服务器持续运行的时候，WEB应用的性能将增强。这与其它请求创建新连接时的情况完全不同，它们可能引起连接池中的连接被终止。在执行其它请求的时候，想从连接池中返回请求必须先确定该连接活跃可用。
Microsoft Analysis Services 2005提供一系列WEB控制（在进行安装的时候可以方便的选择它们的例子），它们可以使用丰富的图表来演示挖掘模型的内容，类似于数据挖掘查看器中的图表。这些控制可以从图表中看到。
对于联合预测——常见的WEB数据挖掘应用类型——来说，DMX中新的语法要素明显增强了性能（仅在Microsoft Analysis Services 2005中可用）。一个典型的例子是：Microsoft Analysis Service 2000中执行联合预测使用TopCount 函数，用它来根据预测概率挑选预测的结果（例如，可能被当前用户所购买的商品的列表）。而在Microsoft Analysis Service 2005中不再需要TopCount 。如下的查询语句将更快的提供相同的结果：
SELECT Predict([Products], 5) FROM Model PREDICTION JOIN 

应用场景3：为当前数据在服务器上创建和训练一个新的模型

在服务器上部署一个数据模型需要拥有数据库管理许可。挖掘模型会话不需要管理许可（如果服务器管理员允许这个特性的话）。会话并不会使用无用的元数据来增加服务器的负荷，所以在可能的情况下都可以使用会话。
如果训练集是客户端应用可用的，这里有两种训练挖掘模型的方法：
·         关系型数据库上的数据可以同时被服务器端（读）和客户端应用（写）看到。一旦数据进入到数据库中，就执行指向刚进入数据库的数据的绑定（DDL中的）来训练模型，或者通过执行带OPENQUERY 的INSERT INTO 语句来训练模型，其中OPENQUERY 指向刚进入数据库的那些数据。相比来说INSERT INTO语句更容易执行，但是它的性能比DDL绑定的处理性能要差些。 这是因为DDL绑定允许平行关系的查询语句并联处理模型的列集；而带OPENQUERY的执行语句只能处理一次，它将数据存储到临时存储区后，一列列的进行处理。在数据集不是很大的时候，二者性能的差异并不明显。
·         数据可以作为表型参数传给INSERT INTO语句。Adomd.NET为此提供了强大的支持功能，数据可以由内存中的表中或者通过执行IDataReader 接口传给INSERT INTO语句。此时，使用DDL绑定进行处理的性能优势就失去了，但是语句更容易被执行了。有时，客户端和服务器端不在同一个网段内，这个网段内有它们都可以看到的那个关系型数据库，这时候对数据库的置入操作就无法完成。