投递文章投递文章 投稿指南 RSS订阅RSS订阅

SQL Server 2005数据挖掘开发者指南

来源:Microsoft 发布时间:2008-01-06 收藏 投稿 字体:【

作者: Bogdan Crivat,微软公司
时间:2005年3月
适用于:
   微软 SQL Server 2005
   SQL Server 数据挖掘(SQL Server Data Mining)
摘要:介绍SQL Server 2005数据挖掘的新API以及几种常用的开发场景。


版权
在这篇文章中所包含的信息代表了从发布日起微软对所讨论的问题的当前观点。因为微软必须对市场的变换做出响应,它不应该被理解为微软所必须承担的任务的一部分,微软也不能保证在发布日之后所提出的信息的精确性。
这个白皮书仅仅是为了信息的目的,微软对本文中的信息不做任何授权、表示、暗含或规定。
依从所有可适用的版权法是用户的责任。没有限制权利在版权之下,这个文档的部分不允许被再生产,存放或介绍入检索系统, 或被以任何形式传送或通过任何手段(电子, 机械, 影印, 记录, 或其他) 或为任何目的,没有微软的明确书面允许。
微软对于在这篇文章中所包含的主题拥有专利、专利申请、商标、版权或其他的一些知识产权。除了微软明确提供的一些书面的特许契约,这个文档的并不提供给您任何专利、商标、版权或其他知识产权的执照。
版权所有2005 Microsoft Corporation。
Microsoft 和Visual Studio在美国或其他国家都有注册商标或微软的商标。
在这里的实际的公司和产品的名字可能是他们各自的商标。


QUOTE:
目录
 概述
 与 Microsoft Analysis Services 2005通讯
  数据定义语言(DDL) 和 数据挖掘扩展语言(DMX)
  数据挖掘任务
 通用API
  Adomd.NET 作为通用API
  OLE DB作为通用API
 Analysis Management Objects – AMO
 进度通知:使用跟踪对象
 无服务器的数据挖掘:本地挖掘模型
 扩展SQL Server 数据挖掘功能
  使用Adomd.NET Server 扩展DMX
  插件算法和内容查看器
 应用场景建议
  应用场景1:简单的数据挖掘预测
  应用场景2:Web应用——使用服务器上现有模型的规则
  应用场景3:为当前数据在服务器上创建和训练一个新的模型
 小结
 附录 1:Microsoft Analysis Services 2005服务器上的常用操作以及请求的协议格式
 附录 2:在Ado.NET 和 C++中使用 OLE DB
  非托管 C++
  ADO.NET
概述

随着微软SQL Server 2005的诞生,统计技术和机器学习算法的综合产物,也就是众所周知的数据挖掘,被带入了一个新的阶段。在SQL Server 2005中,数据挖掘最重要的转变是改变了它的目标用户。除了作为一个科学的实验工具,面向有限的专业人士,如今SQL Server 数据挖掘已广泛存在,成为开发者捶手可得的工具,并且已经做好了在更广阔的领域中应用的准备。从电子数据表格到网络游戏,从点到点通讯系统到应用服务器,绝大多数应用都有这样一个共同点:它们不得不进行数据处理。在进行数据处理的时候,它们使用特定的标准API来访问数据。在SQL Server 2005数据挖掘的数据处理系统中,这些API也同样可以被智能的嵌入到应用中。
这篇文章带你思考将SQL Server数据挖掘嵌入到应用中的契机。文章重点关注可编程内容,即通过写代码来使用数据挖掘技术和增强服务器特性。我们将给出一系列可以被数据挖掘引擎执行的常用任务,并针对它们展示微软SQL Server数据挖掘体系结构的解决方案。之后,我们将列举一些客户端产品(Adomd.NET 和 OLE DB)的可编程API。之后的一个章节专注于Analysis Management Objects所管理的API。随后,我们将展示服务器创建新的存储过程以及添加新的算法插件和查看器等扩展功能.
数据挖掘应用也可以结合联机分析处理(OLAP)、Reporting Services或者Integration Services来创建。然而,这篇文章不介绍这些内容,而是严格通过代码来介绍数据挖掘功能和如何增强数据挖掘功能。
数据挖掘和联机分析处理都是微软分析服务的组件。本篇文章中介绍的客户端API同时适用于这两种组件。但是,本文的介绍仅针对数据挖掘。其中的场景、代码实例、元数据对象都是针对数据挖掘的。

与 Microsoft Analysis Services 2005通讯

让我们从Microsoft Analysis Services 2005(与数据挖掘服务器之间)的通讯协议开始。客户端通过Analysis Services 2005来执行这个通讯协议(比如使用Microsoft OLE DB Provider for Analysis Services 9.0 或者 Adomd.NET),并且这个协议也必须被其它客户端执行。
Microsoft Analysis Services 2005 使用SOAP作为最外层的通讯层。(更多关于SOAP的内容请访问这个网页。)SOAP为应用程序定义了一系列可以通过XML消息来调用的方法。 这些方法由Microsoft Analysis Services 发布,使用XML for Analysis或者 XMLA来定义。
XMLA规范是由一个超过20家研究商业智能的龙头企业(包括微软公司、Hyperion和SAS 学会)组成的组织提出的,它是一个标准的OLAP和数据挖掘技术接口。 更多关于XMLA的信息,请点击这里。
XMLA定义了两种发送给服务器的请求,以及服务器进行响应返回的信息的格式。请求的类型是“发现(Discover)”和“执行(Execute)”。“发现”用来从服务器获取信息和元数据。例如, “发现”可以用来获取服务器上一系列挖掘模型以及它们的属性(列描述、算法等等)。“执行”用来执行对服务器的命令,如创建一个新的目录或者挖掘模型、训练一个模型、或者执行一个查询。

数据定义语言(DDL) 和 数据挖掘扩展语言(DMX)

XMLA的“执行”命令可应用于多种任务。这里有几个例子:
·         创建(Create)命令:这些命令在服务器上创建一个新的元数据对象,它们包含被创建的对象的全部或部分属性,例如名称、数据绑定、挖掘模型和挖掘结构中的列、挖掘模型的数据挖掘算法等等。
·         修改(Alter)命令:这些命令修改已存在的服务器元数据对象的属性。
·         删除(Drop)命令:这些命令用来从服务器上去掉元数据对象。
·         处理(Process)命令:这些命令用来初始化那些基于当前绑定的训练数据集定义的元数据对象上的训练序列。
·         语句 (查询语句)。
当一个XMLA“执行”请求描述一个对象(如创建Create或者修改Alter语句)或者将一个对象定义为一个动作的目标(如处理Process或删除Drop)时,命令的内容由Microsoft Analysis Services 数据定义语言(Data Definition Language —— DDL)组成。DDL是Analysis Services 2005中元数据以及元数据操作的内部表示方法。 服务器上的对象存储在DDL中,商业智能化项目由若干DDL片段组成。关于DDL的更多细节,请查看SQL Server 2005 在线文档中的“分析服务脚本语言(Analysis Services scripting language)”。
另一方面,在数据挖掘任务中,当XMLA请求是一个语句的时候,XMLA “执行”请求使用一种查询语言——DMX(数据挖掘扩展Data Mining eXtensions语言)作为它的请求的内容。DMX语言在针对数据挖掘的OLE DB 规范中定义,在这里可以使用。
Microsoft Analysis Service 2005 也可以使用另一种查询语言来执行语句——MDX。MDX语言是为OLAP组件所设计的。所以,这里我们只关注DMX。
区分DDL和DMX是非常重要的:DDL是一种由Analysis Services 2005使用的类XML语言,用来描述、管理和指定元数据。DDL可以很方便的扩展到XMLA。
而DMX是一种为数据挖掘而设计出的类SQL语言。DMX与SQL非常类似,DMX包含这样的结构,它们允许创建和操作元数据对象(想想SQL中的CREATE TABLE 或者INSERT INTO语句,DMX中有与其等价的CREATE MINING MODEL 和INSERT INTO 语句)。然而,对于管理元数据对象的任务来说,DMX的灵活性比DDL要差。DMX语句无法扩展到XMLA;但是它们可以被固定的XMLA结构所包括。
文章结尾处的附录1提供更多Microsoft Analysis Services 2005协议部署的细节内容。
SOAP相对来说比较容易操作;大多数开发工具都提供针对创建、传输、接收SOAP包的帮助。但是,选择使用DDL请求还是DMX请求,并把它按照适当的格式封装到XMLA语句中就不是一件那么容易的事情了。所以开发者需要比仅仅使用XML流作为通讯方法更好的工具。这也就是为什么如今可编程API存在的原因。这些API将XMLA请求的相关操作作业打包,分析XMLA的响应信息,并且向开发者提供一个更具逻辑性的通讯视图,用来操作内部细节。也有一小部分API可以被Microsoft SQL Server 数据挖掘应用。选择哪个API取决于客户端执行的请求的类型和客户端的开发环境。
下一节将分析典型的数据挖掘在客户端/服务器端通讯(C/S)时的客户端请求。之后的章节将从各种数据挖掘可编程API处理典型请求时的方法以及它们支持的客户端环境的角度,具体展示这些API以及它们之间的差别。

数据挖掘任务

SQL Server数据挖掘服务器支持多种请求。对于每一种请求,我们将给出可用的DDL命令和等价的DMX:
·         元数据的发现:这些请求允许客户端应用根据一些属性,如挖掘模型的列、使用的算法、被训练的数据集,迭代服务器上已存在的元数据对象,并且从中选择一个或多个有用的元数据。XMLA规范为这类请求定义了发现(Discover)命令,没有与其直接对应的DMX或DDL。
·         元数据的定义:这些请求是一系列对服务器上的数据结构的定义。这些数据结构是挖掘结构和挖掘模型,它们由目录(数据库)组合在一起。针对这些请求的XMLA命令是执行(Execute),包括DDL用来创建和修改的Create 或 Alter 语句。也可以使用DMX的 CREATE语句,尽管它的灵活性要比DDL 的Create语句差。
·         模型的训练:这些请求为服务器端的数据挖掘模型执行训练处理。训练可以使用预先绑定的数据(在元数据定义时决定),也可以只描述当前正在处理的操作的数据集。XMLA命令还是 执行(Execute),包含一个DDL的处理(Process)语句。在DMX中,训练可以由插入(INSERT INTO)命令得到。
·         查询模型:这些请求包括(但不局限于)在数据挖掘中我们常说的记分(Scoring)和预测(Predicting)。 我们将查询定义为使用数据挖掘所建立的模型的过程。这些请求由发送到服务器端的DMX语句组成。
·         订阅进度通知:这些请求非常方便地显示一个进度条,这个进度条用来显示在执行一个很长的操作时或者在指定时间检查服务器状态时的实际进展情况。这类请求不能使用DMX创建。它们拥有跟踪的功能,作为带DDL订阅(Subscribe)语句的XMLA执行(Execute)命令来进行传输。
对这些任务有了基本概念后,我们可以正式开始列举可编程API及它们的特性了。上述任务中的最后一项,关于进度的通知,我们将单立一节的内容进行讲解,下面的API章节就不再讨论这个任务了。

通用API

我们将探讨两种常用的API:Adomd.NET和OLE DB。它们的差别在于它们的目标环境不同: OLEDB (OLE for Databases)主要针对非托管应用(尽管它也可以被用于托管应用);而Adomd.NET针对托管应用。下边我们将看到,这些API具有非常相似的结构。它们都基于非常有名的数据库访问范例。
 Adomd.NET 作为通用API

Adomd.NET是由Microsoft Analysis Services 2000提供的旧ADOMD库的托管版本。这个库专门为Microsoft Analysis Services 2005的客户端而设计。它执行ADO.NET数据访问范例(包括一系列标准接口,如IDbConnection、IDbCommand、IDataReader等等),并且使用Microsoft Analysis Services 2005提供的许多特性来扩展这些范例。
在.NET框架中,System.Data命名空间使你可以建立从多个数据源有效管理数据的组件。关于此点的更多内容请参考关于System.Data 命名空间的MSDN文档。System.Data拥有多种特性,它定义一系列可以被.NET数据提供程序执行的用来访问关系型数据库的接口。微软分析服务(Microsoft Analysis Services)是一个多维数据库,它比普通关系型数据库拥有更强大的功能。Adomd.NET是一个.NET数据提供程序,能执行提供给.NET数据提供程序的一系列标准System.Data接口,这些接口的功能在Analysis Services 2005中得以增强,也增加了很多在关系型数据库中不使用的新特性。
Adomd.NET作为SQL Server 2005连接组件的一部份被安装,也可以单独下载进行安装。在从应用程序使用它之前,必须在机器上安装Adomd.NET数据提供程序。
这一节的代码示例使用Visual Studio 2005的C# 2.0实现。经过一个简单的“翻译”过程,它们也可以被Visual Studio 套件的任意托管语言(如Visual Basic .NET或Visual C++ .NET)运转。
在应用程序中使用 Adomd.NET时,必须先添加一个Microsoft.AnalysisServices.AdomdClient.dll程序集,使用类似如下的代码进行添加:

using Microsoft.AnalysisServices.AdomdClient;

下一步,连接Microsoft Analysis Services 2005 服务器:
AdomdConnection  conn = new AdomdConnection();
conn.ConnectionString = "Data Source=localhost; " +
"Initial Catalog=MyCatalog";
conn.Open();

在数据挖掘任务列表中,第一个是元数据对象的发现。就像我们前边所说的一样,元数据的发现由XMLA发现(Discover)命令实现。Adomd.NET提供两种简单的方法来发现元数据。第一种与AMO非常相似:

foreach (MiningModel model in conn.MiningModels)
{
    Console.WriteLine(model.Name);
}

微软分析服务开发团队尽了很大的努力来确认常用的计划都已包含于Adomd.NET Connection类所发布的程序集中。你可以使用之前的这些代码来访问数据库中的挖掘结构集、一个结构中或者整个数据库中的挖掘模型列表、以及模型和结构中的列。Adomd.NET 拥有远超过AMO 的功能,它允许代码这样构成分级模型:

foreach (MiningContentNode node in model.Content)
{
    foreach( MiningContentNode in node.Children )
    {
       // 使用节点的属性
    }
}

对Microsoft Analysis Services 2005中的OLAP计划来说,Adomd.NET Connection 对象所发布的程序集比数据挖掘所提供的程序集更加适用。所以在Adomd.NET中你可以使用相同的方法来浏览立方体和维度。
发现服务器元数据的第二种方法与OLE DB的方法非常相似,也就是执行一个发现(Discovery)命令来传输一个GUID计划和一系列约束,然后返回一个可以被遍历的表型结果。 有些计划返回的是分级表型结果(嵌套表)。这也就是为什么在Adomd.NET 中,一个发现操作的返回值是一个数据集(DataSet);对比ADO.NET ,它返回的是一个数据表。数据集可以描述表之间的关系,所以数据集可以包含一些发现操作的嵌套表型结果。下边的一段代码片段发现了一个挖掘模型的内容,并且使用数据集得到了响应NODE_DISTRIBUTION嵌套表计划的嵌套行:
Guid modelContent = new Guid("{3ADD8A76-D8B9-11D2-8D2A-00E029154FDE}");
object[] arRestrictions = new object[3];
// 约束发现(Discovery)MyCatalog目录中DecisionTree1模型的内容。
// 第二个约束(MODEL_SCHEMA) 在这里忽略。
arRestrictions[0] = "MyCatalog";
arRestrictions[1] = null;
arRestrictions[2] = "DecisionTree1";
          
DataSet dsContent = conn.GetSchemaDataSet(
modelContent, arRestrictions);

// 一致性检查:确认关系值为1
Debug.Assert( dsContent.Relations.Count == 1);
DataRelation relation = dsContent.Relations[0];

DataTable topTable = relation.ParentTable;

foreach (DataRow row in topTable.Rows)
{
// 使用最上层表中的列
    Console.WriteLine("NODE_CAPTION=" + row["NODE_CAPTION"]);
    Console.WriteLine("NODE_UNIQUE_NAME" + row["NODE_UNIQUE_NAME"]);

// 根据关系描述,取得嵌套行
    DataRow[]  distRows = row.GetChildRows(relation);
    foreach (DataRow distRow in distRows)
    {
// 使用嵌套表中的列
Console.WriteLine(distRow["ATTRIBUTE_VALUE"]);
    }
}

与OLE DB非常相似,Adomd.NET提供发送请求到服务器的命令。这些请求可以是DDL或者DMX的;所以它们可以创建或者修改已经存在的、用来训练挖掘结构和挖掘模型的元数据对象(DDL和DMX),也可以查询已存在的模型(只支持DMX)。我们也就可以通过此点来区分元数据的创建、处理,和DMX的查询。它们的区别在于:DMX查询返回一个表型结果(分层的或者单层的),而元数据创建和处理语句只返回一个成功或者失败。Adomd.NET公开了一些执行(Execute)方法,其中两种对于返回成功/失败的请求和返回表格型数据的请求非常有用。
第一种:我们使用一个DDL处理语句作为示例,任何其它的DDL语句(如Alter、Create或者Drop)也可以使用相同的代码。

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

cmd.CommandText = " 
"xmlns=\"http://schemas.microsoft.com/analysisservices/2003/engine\">"+"<Type>ProcessDefault</Type>" +
"    <Object>" +
"      <DatabaseID>MyCatalog</DatabaseID>" +
"      <MiningStructureID>Structure1</MiningStructureID>" +
"    </Object>" +
"  </Process>";

cmd.ExecuteNonQuery();

同样,ExecuteNonQuery也可以执行一个DMX语句来产生相同的结果:
"INSERT INTO MINING STRUCTURE Structure1"

当 ExecuteNonQuery被调用的时候,如果请求执行成功了,语句将返回;如果执行失败将报一个异常。在之后的例子中,将给出异常的具体信息,如服务器返回的错误信息。
第二种执行方法是ExecuteReader。这种方法应该在语句的返回值肯定是表型的时候被调用。就像我们前边所提到的一样,Microsoft Analysis Services 2005返回的结果有时会是分层表型结果。例如,让我们考虑这样的一个模型, Model1,它根据消费者的年龄、他/她汽车的颜色来预测消费者的性别和购买商品的清单。当然,这样的模型可能并没有现实意义,但是,它却是一个很容易使DMX语句返回分层表结构结果的例子。
下面的代码使用 AdomdCommand 来传输一个预测查询给服务器,并读取最上层返回值(预测的性别)和嵌套返回值(预测的商品列表):
cmd.CommandText = "SELECT Gender, Products FROM Model2 " +
           "NATURAL PREDICTION JOIN "  +
           "( SELECT 30 AS Age, 'Black' as CarColor) AS T";
AdomdDataReader rdr = cmd.ExecuteReader();

while (rdr.Read())
{
    // 使用上层结果,预测性别
    Console.WriteLine( rdr.GetString(0) );
   
    // 为第一列的嵌套内容获得一个nested reader
    AdomdDataReader nestedReader = rdr.GetDataReader(1);

    // 读嵌套内容并使用嵌套数据
    while (nestedReader.Read())
    {
       Console.WriteLine(nestedReader.GetString(0));
    }
    nestedReader.Close();
}

调用 GetDataReader 将返回一个新的实例AdomdDatareader 类,它被初始化后用来访问对列编号了的嵌套表。如果指定的列并不是一个被嵌套的表,“执行”方法将返回一个异常。我们可以使用类似如下代码的语言来判断Datareader中的列是不是一个嵌套表:
if (rdr.GetFieldType(1) == typeof(AdomdDataReader) )
{
    // 如果进入If循环,rdr的第一列是一个嵌套表
}

在现实生活中,最有可能根据用户的实际输入来进行预测。一个常见的Web应用场景是这样的,用户给出年龄和汽车的颜色,应用程序代码产生一个DMX请求来预测该客户购买商品的清单。当开发者对DMX和相关的数据类型有一个很好的理解的时候,查询可以使用将客户录入的所有字符串连接起来的方式进行创建。 然而,这样的方法具有潜在的威胁,它可能引起DMX嵌入错误或研发错误。一种更好的方式是使用参数来建立查询,将用户输入的内容作为参数的值。Adomd.NET对DMX的参数化查询提供了大量的支持,就像下面的例子一样。这段代码不包括读取返回值的内容,因为它与之前的代码片段是一样的。
cmd.CommandText = "SELECT Gender, Products FROM Model2 " +
           "NATURAL PREDICTION JOIN "  +
           "( SELECT @Age AS Age, @Color as CarColor) AS T";

AdomdParameter paramAge, paramColor;

paramAge = cmd.CreateParameter();
paramAge.Direction = ParameterDirection.Input;
paramAge.ParameterName = "Age";
cmd.Parameters.Add(paramAge);

paramColor = cmd.CreateParameter();
paramColor.Direction = ParameterDirection.Input;
paramColor.ParameterName = "Color";
cmd.Parameters.Add(paramColor);

cmd.Parameters["Age"].Value = 30; // 用户在这里输入
cmd.Parameters["Color"].Value = "Black"; // 用户在这里输入

AdomdDataReader rdr = cmd.ExecuteReader();

请注意,参数不一定非是数值。请考虑这样的DMX语句:
INSERT INTO MyModel(Col1, Col2)
OPENQUERY(DataSource, "SELECT ColA, ColB FROM Table") AS T

或者是:
SELECT PREDICT(Products, 5) FROM MyModel NATURAL PREDICTION JOIN
OPENQUERY(DataSource, "SELECT ColA, ColB FROM Table") AS T

这两个语句都用了一个OPENQUERY 函数来描述执行时被服务器使用的表型内容(训练挖据模型,分别进行预测)。使用Adomd.NET,我们可以使用一个参数来取代OPENQUERY函数,并且向服务器传输一些表型内容。查询可能是这样的:
INSERT INTO MyModel(Col1, Col2)
@MyTabularContent AS T

或者是:
SELECT PREDICT(Products, 5) FROM MyModel NATURAL PREDICTION JOIN
@MyTabularContent AS T

在这些例子中, 参数MyTabularContent可以是一个数据表(DataTable)或者执行一个IDataReader .NET接口。相比来说,数据表更容易使用,IDataReader接口具有不需要将所有数据保存在内存中的优势。IDataReader执行的一个例子是客户端应用执行的SQL查询所返回的SqlDatareader。当然,一个SQL查询请求也可以在OPENQUERY 功能中被提交,但是这种请求的前提是服务器已经访问到了SQL数据库。表型参数为两种情况所设计:
·         数据库中的数据是客户端可见但是服务器端不可见的(这种情况应该使用IDataReader)
·         数据在客户端应用程序所占用的内存中(DataTable可以在这种情况时使用)
Adomd.NET 一个独有的特点是可以使用XML返回选定的列。Microsoft Analysis Services 2005为指定的查询返回这样的列。例如:
SELECT * FROM MyModel.PMML

这个语句将返回PMML 2.1格式下MyModel 模型的内容(即被支持PMML的MyModel使用的数据挖掘算法)。除了例如模型名称、PMML缓冲区大小这类元信息外,这个语句的返回值还包括指定的列和包含PMML的MODEL_PMML(一种被数据挖掘团队设计出来的XML格式,用来描述挖掘模型的内容)。
这个XML的内容可以以字符串方式被访问,但是Adomd.NET拥有分析XML列的能力(基于服务器端发来的指定的列类型来判断) 并且将它们发布为一个System.Xml.XmlReader对象。这些列也可以作为字符串被读取。以下的示例代码使用这一特性来访问带XML目录的列,同时使用字符串和XmlReader两种方法。
cmd.CommandText = "SELECT * from [MyModel].PMML";
AdomdDataReader rdr = cmd.ExecuteReader();
// 遍历响应结果,读取第5列,MODEL_PMML
while (rdr.Read())
{
// 取得列值
    object objXMLValue = rdr.GetValue(5);
    if (objXMLValue is System.Xml.XmlReader)
    {
//使用一个XML reader
System.Xml.XmlReader pmmlReader =
(System.Xml.XmlReader)objXMLValue;
       //在这里读PMML
    }

// 使用字符串来获取这列
    string strPMMLAsString = rdr.GetString(5);
}

Adomd.NET 的另一个特性是连续访问服务器响应,将在 进度通知:使用跟踪对象 一节中具体阐述。
Adomd.NET是Microsoft Analysis Services 2005中最具灵活性,最容易使用的客户端API。在编写以微软分析服务为目标的.NET应用操作时也同样推荐使用它。它提供了类AMO访问服务器元数据的大量特性,它允许执行DDL和DMX语句,并且它对DMX语句的参数也有很好的支持。


OLE DB作为通用API

在微软Windows操作系统中,OLE DB是进行数据访问最常用的API。OLE DB是针对OLE对象的规范。这些OLE对象有一系列标准接口。这些接口的标准化使得一个编程模型几乎可以访问所有类型的数据源。微软SQL Server数据挖掘有一个OLE DB提供程序。这个提供程序能将OLE DB编程模型翻译成数据挖掘所需要的内容。
关于 OLE DB的更多内容,请访问MSDN OLE DB页。
OLE DB可以被很多种编程语言直接使用。在本机(非托管)C++中,可以创建OLE DB对象,并且可以直接调用OLE DB的方法。ALT使用者模版(ALT Consumer Templates)也为OLE DB使用者应用程序提供了一系列有用的类。在Visual Basic或者VBA中,OLE DB提供程序可以在ADO(ActiveX Data Objects,ActiveX数据对象)中使用。在托管语言中,我们可以使用ADO.NET 库来调用OLE DB提供程序。
OLEDB编程模型以如下对象为中心。首先,数据源必须由服务器端初始化和控制。其次,在这个数据源上必须初始化一个通讯对话。OLE DB架构的第三个重要组成部分就是命令,它们将服务器请求打包。每个服务器请求都是对话的一部分。OLE DB架构的第四个组成部分是服务器响应。大多数数据挖掘任务可以被OLE DB命令所执行。例如,可以使用一个命令来传输DMX语句,也可以传输一个DDL语句来创建一个新的元数据。但是命令并不能传输一个发现元数据语句(Discovery)。所以针对此点,OLE DB定义了一个可以被对话执行的IDBSchemaRowset接口。这里我们需要注意的是,ADO和ADO.NET有一个封装了数据源和OLE DB对话的连接对象(Connection)。这两种标准的OLE DE对象(数据源和OLE DB对话)公开的功能在ADO和ADO.NET的连接对象中可用。
所有的OLE DB对象(数据源、对话、命令和响应)经常在COM组件中执行来调用OLE提供程序。
下面的图1给出了一个OLE DB解决方案的框架:

如图中所示,首先,各个客户端上安装的OLE DB提供程序使用OLE DB来连接服务器。Microsoft Analysis Services 2005的OLE DB提供程序是在安装SQL Server 2005的连接组件时安装的。
OLEDB连接经常通过连接字符串的方法来初始化。连接字符串包含一系列有分号分隔开的“名字-值”字符对,即属性。这些属性描述了OLE DB连接初始化时的各个参数。所有的OLE DB包(如ATL使用者模版、ADO、或者ADO.NET)都根据连接字符串来进行初始化。这里给出一个用来连接Microsoft Analysis Services 2005的OLE DB连接字符串的例子:
"Provider=MSOLAP; Data Source=localhost; "

第一个属性 Provider描述示例中指定的提供程序。
"MSOLAP" 是微软分析服务中OLE DB提供程序的名字。请注意这个名字是依赖版本的。如果一台机器上安装了多个分析服务OLE DB提供程序(如一个来自Analysis Services 2005,一个来自Analysis Services 2000),就需要使用更加准确的名字来区分版本:Analysis Services 2000使用“MSOLAP.2”,Analysis Services 2005使用“MSOLAP.3”。第二个属性“Data Source”表示要连接的数据源。它一般都是一个机器名,但是也可以是其它表达方式。例如,它可以是一个文件名,或者是一个网络URL,如我们将在下文“HTTP Pump”章所见到的一样。关于分析服务OLE DB提供程序属性的更多信息,你可以从SQL Server在线信息中得到。
下面这段代码是一个VBA应用程序中使用OLE DB的例子,它使用了ADO。具有相似功能的C#代码(使用ADO.NET)和非托管C++代码在附录2中。
为使用ADO,需要为你的Visual Basic (或者VBA)工程添加一个指向Microsoft ActiveX Data Object库(你机器中最新版本的库)的引用。以下的代码片段是在2.8版本上进行测试的:
1 Dim Conn As ADODB.Connection
2
3 Set Conn = New ADODB.Connection
4 Conn.Open ("Provider=MSOLAP.3; Data Source=localhost;" _
5 & "Initial Catalog=MyCatalog")

在第一行和第三行创建并初始化了一个ADODB连接对象。在第四行,就像我们前边所说的,ADO连接对象封装了两种OLE DB对象:数据源和对话。在连接字符串中,你将看到一个之前没有讨论过的属性:“Initial Catalog”。它定义服务器上将被这个连接使用的数据库。让我们使用这个连接对象来完成我们之前列举的数据挖掘任务。

顶一下
(2)
100%
踩一下
(0)
0%
本文Tags:
  • 表情:
  •    
  • 评价:
用户名: 密码: 匿名 注册
最新评论 查看所有评论
About iTtang - 联系我们  - 专题列表 - 友情链接  -  高级搜索  -  帮助中心  -  您的意见