Project REAL分析服务技术探讨

数据库设计

项目REAL Data Warehouse在一系列的多维Analysis Services数据库中执行，这些多维数据库称为：

◆REAL_Warehouse_V（代表数据的data-masked版本）是几千兆数据库版本

◆REAL_Warehouse_Development_V是数据库的开发版。它包含维度成员的全部设置，但是每15个分区在5个存储器中。REAL开发小组使用它作为一个数据集(约15GB)，每一个都能轻易的构建和测试。这种小规模的数据集能够让地理上分散的开发团队更好的共享内容。

◆REAL_Warehouse_Development_V是数据库的一个样版。它包含了一个维度结构的子集和大量的真实信息。不管怎么说，它覆盖了很长的一段时间（52个星期长的数据），因此，它里面的所有数据是系统很好的一个Demo。它正是作为Project REAL系统的一部分，为外部发行而用的。这意味着你将有足够的结构化数据使得系统能够运转。他也是其它各种Project REAL的基础。

所有这些数据库有相同的对象和结构。每个数据库有单独的一个Cube，和11个维度以及4个度量组。

数据源和数据资源视图

数据源是你在Analysis Services建模活动的起点。对于REAL项目，我们将三个SQL Server 2005关系数据库整合成一个关系数据库管理系统，它被用于数据源，Cube和运用此系统的结构。

数据源

对于所有数据拥有单一的数据源是不够的。我们最终的目的是检测出Analysis Services和资源RDBMS之间的访问路径，当他们处于服务器的不同的域中时，或许他们直接还有防火墙隔着。因此，我们及早的做出了决定我们应该运用SQL Server标准安全而不是集成安全来访问RDBMS。

我们通了过Analysis Services创建了一个专用的SQL登录来进行访问。这个帐户姓名为REAL_User，密码为password。这并不能创建一个高安全性的环境，但是已经足够我们使用了。在SQL Server数据库中，这个注册用户仅被给予data reader权限。

如创建和使用此数据源部分一样，我们注意到一个有趣的SQL Server 2005 Analysis Services现象。这就是当数据源被创建时，数据源密码被内部加密（这就意味着密码没有以明文的形式存储）并被同时删除了。因此，无论何时我们制作一个数据库拷贝时（通过在SQL Management Studio中选择Scripting然后选择任务菜单的Create Script来完成），XMLA脚本中的数据源密码都被设置为空。实事上，我们无法利用执行脚本，拷贝粘贴或其他机制将密码拷贝到另一个对象中。不管我们怎样拷贝，系统总是提示密码丢失或错误的密码。

最佳实践：当在标准安全模式下工作时，记住你的密码。当移动对象时候，你将经常需要输入密码。

删除密码有优点也有缺点。它能防止盗窃密码行为。甚至管理员也无法通过拷贝对象来使用它。当第一次使用拷贝时，管理员必须重新输入密码。在第一次使用拷贝后，数据源上有个选项，用来提示密码被数据源内部存储（加密）并且每次必须重新输入密码数据源才能被打开。得到OLAP管理者权限的恶意的用户不能拷贝任意对象，在任意其他环境上下文中使用对象，也不能通过检查数据源来获得密码。

不幸的是，这将使得通过存储在资源控制系统中的脚本构建一个每晚或每周自动重启的系统变得很困难。这是因为存储在资源控制系统的对象没有包含有效的密码。如果你的开发工厂夜间运行，自动重启，那么数据源中构建的对象就不能被Analysis Services处理，直到你输入正确的密码。在你从资源控制系统中提取和重建好所有Analysis Services对象后，你必须在能够自动处理维度，属性，分区和其他对象前为数据源设置一个有效密码。这将承担了一个安全风险，因为，密码会被以明文形式设置。因此要小心如何设置密码以及如何控制需要读取这些程序用户的访问。

数据资源视图

我们为系统的用户创建了一个数据资源视图。数据资源视图是用于扩展对象的抽取层（关系表和视图），扩展的对象被数据源用于从被创建的Analysis Services对象中抽取对象集合。为了保持典型关系数据库的最佳做法，我们不在新表中创建任何对象，但是运用关系视图。

在数据资源视图中我们包含了全部的关系视图，这些视图用于创建维度，层和属性。我们没有为每个测量组实现包含关系视图－这对于每个测量组分区来说是最基本的。此模板没有包含任何数据－仅是分区表视图，查询绑定和其他对象如何恢复的定义。

最佳实践

如下将叙述多种最佳实践

◆在那些可能的地方，能够继续使用视图向分析服务（Analysis Services）提供一个高质量的星型/雪花(star / snowflake)模式

当数据资源视图允许DBA构建复杂结构时，他们不需要专用的空间为数据添加事务值。数据资源视图不能通过数据库，服务器，应用程序被共享，也不能通过SQL Server中BI组件（例如位于Analysis Services，整合服务，报告服务之间）被共享。如果你通过视图添加了事务消息，你最好通过所有的应用程序重新使用那项专门的技能。我们发现利用数据资源视图来扩展一个系统是两种情况下极好的决策。一种情况是当RDBMS不允许设计者创建或改变视图时，另一个是当事务消息与cube的多维属性有关并与关系对象无关并且重用也不重要时。

◆运用数据资源视图创建foreign key (FK)关系，此关系不存在于基础数据源中。

FK关系不存在于数据源中的原因有很多。例如，数据来源于数据仓库。对于数据仓库，缓解参考完整性约束这是很常见的甚至他们在数据模型中已知的情况下。这样做将加速大批量数据的处理，或者当运行在清除阶段时包含可疑数据。同样，如果数据源是个数据库产品，那么参考完成性约束将不会被公示，这是因为基本关系数据库不支持这些。例如，不同数据库中或是不同服务器中的表。数据库和服务器的参考完整性约束在SQL中不允许。然而，当Analysis Services 创建SQL命令从数据源中收集数据时，FK关系非常有用。幸运的是，数据资源视图被用于为Analysis Services添加FK关系，这超越了数据源本身的定义。

◆非常容易获得被携带离开的数据资源视图和创建过多的关系

如果你的数据已经包含在星型模式中，FK关系就不再需要了，认识到这点很重要。关系被典型的应用，因此Analysis Services知道如何构建基本SQL命令。关系不需要用于浏览和操作对象或查询中。在REAL项目数据库中，我们没有定义数据资源视图关系，我们的系统也构建的相当完善。

共20页: 3 下一页

【内容导航】

原文：Project REAL分析服务技术探讨(3)