BI技术方案.docx
《BI技术方案.docx》由会员分享，可在线阅读，更多相关《BI技术方案.docx（33页珍藏版）》请在冰豆网上搜索。
BI技术方案
BI技术方案
变更说明
日期
版本
变更位置
变更说明
作者
1前言
1.1目的
1.2读者对象
1.3定义、缩略语
1.4参考资料
2方案概述
2.1架构设计
系统整体架构采用以微软SQLServer2021为中心的技术架构，集成ETL技术、OLAP技术、报表技术、数据挖掘技术和门户技术，有效地保障了数据的时效性、准确性和易用性。
逻辑架构图如下：
系统架构图
产品架构图
2.2软件列表
1.数据仓库及ODS数据库：
SQLServer2021关系型数据库
效劳：
SQLServer2021的分析效劳〔AnalysisService〕
工具：
SQLServer2021的SSIS〔SQLServerIntegrationService〕
4.前端报表展现工具：
SQLServer2021的RS〔ReportingService〕、OWC和Office2003。
5.数据挖掘：
SQLServer2021的分析效劳〔AnalysisService〕
6.门户：
SharePointServer2021
2.3域控效劳
采用AD〔域控，下同〕为HISBI系统以及医院未来进一步信息建设提供强大的帐户以及权限统一管理的根底框架效劳。
HISBI系统采用AD的帐户集成存储管理的模式为报表权限，数据访问权限提供统一的管理模式。
大大简化了帐户及权限的管理设置。
为程序的扩展提供良好的根底。
结合AD,为MOSS平台提供文档管理权限控制。
MOSS平台可通过AD的帐户统一的管理权限，每个用户都可以自行控制其所属文件的访问权限。
2.4邮件效劳
采用开源免费的邮箱系统，该邮箱系统可结合AD效劳提供完善统一的邮箱帐户信息。
并且支持多种协议访问，可使用Foxmail,Outlook等免费或者收费软件访问邮箱系统。
该邮箱效劳产品是开源的，意味着可以通过院信息化平台开发人员自行拓展邮箱功能，也为邮箱的平安性提供进一步的支持。
该邮箱产品支持多种后台数据库产品，例如SQLServer,DB2,Oracle,MySQL.此项为数据库产品的选型提供更加灵活的方式。
2.5协同办公平台
基于上述域控管理和邮件效劳功能，安普莱软件的BI系统可以和海军总医院现有办公平台无缝集成，我们也可以帮助海军总医院搭建企业级的协同办公平台，为海军总医院提供完善的办公平台效劳，简化办公流程复杂度，提高办公协同的工作效率。
3数据仓库设计
SQLServer2021基于SQLServer2021的强大功能之上，提供了一个完整的数据管理和分析解决方案，它将会给不同规模的组织带来帮助：
1.构建、部署和管理企业应用程序，使其更加平安、伸缩性更强和更可靠。
2.降低开发和支持数据库应用程序的复杂性，实现了IT生产力的最大化。
3.能够在多个平台、应用程序和设备之间共享数据，更易于连接内部和外部系统。
4.在不牺牲性能、可用性、可伸缩性或平安性的前提下有效控制本钱。
数据仓库将依据于数据仓库的标准规那么创立，以确保其具有良好的可扩展性。
数据仓库在工程中起到了呈上启下的作用，对其它局部的影响很大，所以数据仓库设计非常重要。
3.1设计原那么
1. 第三范式
第三范式的根本特征是非主键属性只依赖于主键属性。
基于第三范式的数据库表设计具有很多优点：
1）消除了冗余数据，节省了磁盘存储空间；
2）有良好的数据完整性限制，即基于主外键的参照完整限制和基于主键的实体完整性限制，这使得数据容易维护，也容易移植和更新；
3）数据的可逆性好，在做连接〔Join〕查询或者合并表时不遗漏、也不重复；
4）因为消除了冗余数据〔冗余列〕，在查询〔Select〕时每个数据页存的数据行就多，这样就有效地减少了逻辑I/O，每个Cash存的页面就多，也减少物理I/O；
5）对大多数事务（Transaction）而言，运行性能好；
6）物理设计（PhysicalDesign）的机动性较大，能满足日益增长的用户需求。
第三范式也存在一定的缺点，在缺乏足够的技术力量和数据仓库建设经验的情况下，按照这种模型设计的系统建设过程长，周期长，难度大，风险大，容易失败。
由于采用了第三范式，数据存储冗余度低、数据组织结构性好、反映的业务主题能力强以及具有较好的业务扩展性等，但同时会存在大量的数据表，表之间的联系比拟多，也比拟复杂，跨表操作多，查询效率较低，对数据仓库系统的硬件性能要求高等问题。
另一方面，数据模式复杂，不容易理解，对于一般计算机用户来说，增加了理解数据表的困难。
2. 多维模型
多维模型在一定程度上降低了范式化，以分析主题为根本框架来组织数据。
以维模型开发分析主题，这样能够快速实施，迅速获得投资回报，在取得实际效果的根底上，再逐渐增加应用主题，循序渐进，积累经验，逐步建成企业级数据仓库。
这也可以说是采用总线型结构先建立数据集市，使所有的数据集市具有统一的维定义和一致的业务事实，这种方法融合了自下而上和自上而下两种设计方法的思想。
这种模型的优点是查询速度快，做报表也快;缺点是由于存在大量的预处理，其建模过程相对来说就比拟慢。
当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。
由于事实表的主码由所有维表的主码组成，所以这种维的变动将是非常复杂、非常耗时的。
而且信息不够全面、系统欠灵活、数据冗余多。
综述，在我们的数据仓库设计中，将结合两种设计思想，取长补短。
数据仓库的整体设计将主要依据于第三范式，以确保系统的伸缩性和可扩展性，同时在设计时也会参考多维模型的思想，使数据仓库更利于数据分析。
在数据集市中，我们将主要依据多维模型原那么进行建设，从而确保数据集市更易于理解以及更利于与OLAP系统集成。
3.2设计标准
1. 维度表设计标准
维度表包含内容：
1）主键：
整型，不可重复，唯一标识每一条记录，不包含任何商业信息
2）代理键：
传统意义的主键，包含相应的商业信息，如员工编号。
3）名称：
数据分析时显示的内容，如员工名称等；
4）排序键：
自定义序列
5）自定义汇总：
利用自定义表达式进行特定的数据运算；
6）父键：
父子维度中用来标识主键的上级；
7）一元运算符：
在父子维度中用来定义上下级的汇总关系；
8）属性：
属性包含有关维度的信息。
例如，Customer维度可以包含Name、PhoneNumber、Gender、City、State等属性。
属性通过属性层次结构显示出来。
维度中的属性层次结构同时包含可选的（All）级别和该属性的非重复成员。
例如，Customer维度可以包含具有两个级别的Name属性层次结构：
（All）级别以及为每个姓名包含一个成员的级别。
父子层次结构的处理方式有所不同。
属性不一定要具有属性层次结构。
如果未创立属性层次结构，多维数据集的空间将与属性无关。
例如，通常不会为PhoneNumber属性创立属性层次结构，因为通常不会按号码导航维度。
如果没有为属性创立属性层次结构，那么该属性可用作成员属性，但不能用作用户层次结构中的级别。
属性可以通过前端展示软件进行展现。
9）属性层次结构：
属性层次结构完全定义多维数据集的空间。
多维数据集是由多维数据集的属性层次结构的交集产生的多维空间。
10） 用户层次结构：
用户层次结构由多个属性层次结构构成，用于实现特的上下级关系，用户层次结构不会影响多维数据集的空间。
2. 事实表设计标准
事实表包含内容：
1）外键：
外键将与各维度表的主键相关联，从而确保数据的完整性和正确性。
2）量度：
量度是可以进行聚合的，一般为数值型字段。
所有的量度都需要对应唯一的聚合函数〔除Count和DistinctCount〕。
3）其他钻透用字段：
此类字段不参与聚合，只有特定的查询和钻透才会涉及此类字段。
3. 映射表设计标准
映射表包含内容：
1）主键：
主键唯一标识记录；
2）外键：
与其他表进行关联。
3.3设计阶段划分
数据仓库模型设计主要分三个阶段：
1、概念设计
2、逻辑设计
3、详细设计
并分别产生三类设计模型
1、主题域模型
2、业务数据模型
3、物理模型
数据仓库模型设计采用迭代式开发，这一点也符合数据仓库系统迭代开发的特点。
它具有较好的灵活性和易变性，适应于主题不明确或不确定的需求。
1.概念设计
数据仓库是面向主题来组织数据，一个数据仓库有假设干个主题，而每个主题又有一个数据集合体做支撑，这个数据集合称为主题域。
概念设计的中心工作是在需求分析根底上设计的主题域模型。
主体域模型是客观到主观之间的桥梁，是与硬件环境、软件选择无关的数据抽象模型，是为下一步建立业务数据模型、物理模型效劳的概念性工具。
主题域具有两个特性：
1）独立性，即主题域具有明确的边界与独立的内涵，虽然主题间可以有交叉，但不影响其独立性。
2）完备性，即每个主题的分析要求所需的数据均应能在主题域中得到。
采用概念数据模型设计就是要设计主题域的数据结构。
2.逻辑设计
逻辑设计的中心工作是设计业务数据模型，业务数据模型是用具体的软件结构来实现概念数据模型。
目前数据仓库一般是建立在关系数据库根底上，因此数据仓库的设计中采用的业务数据模型就是关系模型。
逻辑设计设计到的知识点包括：
1）业务数据模型设计的建模对象应包含实体、属性、关键字和联系。
2）业务数据模型设计应该遵守标准化准那么：
即第三范式设计准那么。
3）业务数据模型的ER图表示法。
3.详细设计
物理模型是从业务数据模型创立而来的，建立物理模型通过扩展业务数据模型，使模型中包含关键字和物理特性。
物理模型设计包括：
1）设计存储结构——构建表格
2）设计索引策略——选择粒度
3）设计存储策略——建立分区
3.4可伸缩性
数据仓库的可伸缩性是衡量数据仓库设计优劣的重要指标。
在数据仓库设计中主要依托于第三范式的设计原那么，对所有实体进行最小化细分，通过主、外键关系将各个实体连接在一起。
在这种设计中，将业务环境发生变化时，往往只需进行以下调整：
1.对主、外键关系进行调整；
2.增加新的实体；
3.增加已有实体的新的属性。
由于实体已经进行最小化细分，所以不需对实体进行重构，从而防止了对其他应用的影响。
元数据管理也是提高数据仓库可伸缩性的重要方法。
3.5数据集市
数据集市〔Datamarts〕是为满足已定义的用户组或业务领域对于特定业务信息的需求而创立的。
它们比数据仓库更小且更关注在数据中构建复杂的业务规那么来支持功能强大的分析。
数据仓库应该一次增加一个主题，并且当需要容易地访问多个主题时，应该创立以数据仓库为来源的数据集市。
多维数据集市的数据模型主要包括：
1）星形模型：
星型的中心是一个大的事实表，发散出来的是维度表，每一个维度表用一个PK-FK连接到事实表，维度表之间彼此并不关联。
一个事实表又包括一些度量值和维度。
2）雪花模型：
雪花模型通过标准维度表来减少冗余度，也就是说，维度表数据已经被分组成一个表而不是使用一个大表。
4ETL过程管理
数据集成是数据仓库中的关键过程。
ETL〔数据的提取、转换和加载〕过程的设计和实现是数据仓库解决方案中极其重要的一局部。
ETL过程用于从多个数据源提取业务数据，清理数据，然后集成这些数据，并将它们装入数据仓库中，为数据分析做准备。
MicrosoftSQLServer2021IntegrationServices（SSIS）是生成高性能数据集成解决方案〔包括数据仓库的提取、转换和加载（ETL）包〕的平台。
IntegrationServices包括用于生成和调试包的图形工具和向导；用于执行工作流函数〔如FTP操作〕、执行SQL语句或发送电子邮件的任务；用于提取和加载数据的数据源和目标；用于清理、聚合、合并和复制数据的转换；用于管理IntegrationServices的管理效劳IntegrationServices效劳；以及用于对IntegrationServices对象模型编程的应用程序编程接口（API）。
SQLServer2021IntegrationServices（SSIS）提供一系列支持业务应用程序开发的内置任务、容器、转换和数据适配器。
您无需编写一行代码，就可以创立SSIS解决方案来使用ETL和商业智能解决复杂的业务问题，管理SQLServer数据库以及在SQLServer实例之间复制SQLServer对象。
4.1开发
在上图ETL过程设计的最正确实践中，数据转换操作大致可以分为6步：
数据抽取、数据验证、数据清洗、数据集成、数据聚集和数据装载。
1.数据抽取过程设计
数据抽取是捕获源数据的过程。
有两种捕获数据的主要方法：
〔1〕完全刷新：
对移入中间数据库的数据进行完全复制。
该复制可能替换数据仓库中的内容，及时在新的时间点上添加完整的新副本，或者与目标数据进行比拟，以便在目标中生成一条修改记录。
〔2〕增量更新：
只捕获源数据中修改的数据，如何捕获数据修改与数据源本身是密切相关的，实际上是逐个实现的问题。
增量更新主要包括以下几种方法：
决策支持系统中，在ETL过程结束之后，和数据进入数据仓库之前，推荐参加了ODS层，来躲避源数据经ETL过程直接进入数据仓库给数据仓库带来的数据风险，并有效进行数据装载。
来自于数据源的数据，经过ETL过程，首先加载进入ODS，而后ODS中的数据再加载进入数据仓库。
2.数据验证过程设计
在工程的业务数据分析阶段，您产生了一组数据质量假设。
这些假设将指定客户和解决方案提供者双方在数据质量问题上的职责。
解决方案提供者通常关心数据清理和增强问题。
客户至少要关注仅仅可以在数据源本身中解决的问题，以及与解释数据含义相关的数据质量问题。
例如：
〔1〕丧失的数据恢复。
〔2〕模糊的数据转换。
〔3〕业务操作应用程序相关的数据问题——只能从应用程序本身解决的数据质量问题。
如果没有用正确的方法及时解决业务数据的质量问题，它可能严重影响工程时间表。
数据质量假设可能是与客户进行时间表协商的一个好根底。
数据验证包括：
〔1〕属性的有效值〔域检查〕。
〔2〕属性在剩余行的环境中是有效的。
〔3〕属性在该表或其他表中相关行的环境中是有效的。
〔4〕关系在该表和其他表中的行间是有效的〔如外键检查等〕。
3.数据清洗过程设计
数据清洗是清理有效数据，使之更精确更有意义的过程。
数据清洗主要包括以下任务：
〔1〕数据合并。
〔2〕数据类型和格式的转换。
〔3〕用于不同目标表的数据别离。
4.数据集成过程设计
数据集成是将多个数据源联合成一个统一数据接口来进行数据分析的过程。
数据集成是仓库数据转换过程中最重要的步骤，也是数据仓库设计中的关键概念。
数据集成可能极其复杂。
在该模块中，可以应用数据集成业务规那么以及数据转换逻辑和算法。
集成过程的源数据可以来自两个或更多数据源；它通常包含不同的连接操作。
源数据还可能来自单个数据源；该类型的数据集成通常包含域值的合并和转换。
集成结果通常生成新的数据实体或属性，易于终端用户进行访问和理解。
5.数据聚集过程设计
数据聚集是收集并以总结形式表达信息的过程。
数据聚集通常是数据仓库需求的一局部，它通常是以业务报表的形式出现的。
在多维模型中，数据聚集路径是维度表设计中的重要局部。
在数据存储库或数据仓库中，数据聚集的级别是逐个〔case-by-case〕确定的。
因为数据仓库几乎仍然都是关系数据模型类型的，所以最好是建议您的客户从数据集市构建业务报表。
6.数据装载过程设计
将数据移至中心数据仓库中的目标表通常是ETL过程的最后步骤。
装入数据的最正确方法取决于所执行操作的类型以及需要装入多少数据。
您可以通过两种根本方法在数据库表中插入和修改数据：
〔1〕SQLinsert/update/delete
〔2〕成批load实用程序
大多数应用程序使用SQLIUD操作，因为它们进行了日志记录并且是可恢复的。
但是，成批加载操作易于使用，并且在装入大量数据时速度极快。
使用哪种数据装入方法取决于业务环境。
4.2运行
ETL流程可以通过SQLServer2021Agent进行调用，Agent可以预先定义调用的时间〔如每天24点〕、周期及执行的命令，并且所有调用过程都将在SQLServer系统数据库中记录日志。
4.3预警
当ETL运行过程中出现异常时，IntegrationServices的事件管理系统将自动触发异常事件，并运行异常事件流程。
异常事件流程是预先定义的一种特殊的ETL流程，此流程可以捕获引发系统异常的数据或事件，并利用邮件或短信通知相应的联系人。
5OLAP设计
OLAP专门设计用于支持复杂的分析操作，侧重对分析人员和高层管理人员的决策支持，可以应分析人员的要求快速、灵活地进行人数据量的复杂查询处理，并且以一种直观易懂的形式将查询结果提供应决策制定者，以便他们准确掌握企业（公司）的经营状况。
了解市场需求，制定止确方案，以增加效益。
MicrosoftSQLServer2021AnalysisServices（SSAS）为商业智能应用程序提供联机分析处理（OLAP）和数据挖掘功能。
AnalysisServices允许您设计、创立和管理包含从其他数据源〔如关系数据库〕聚合的数据的多维结构，以实现对OLAP的支持。
对于数据挖掘应用程序，AnalysisServices允许您设计、创立和可视化处理那些通过使用各种行业标准数据挖掘算法，并根据其他数据源构造出来的数据挖掘模型。
OLAP构建流程图如下：
5.1最正确实践
OLAP模型一般构建在根据分析需求从数据仓库中抽象出的数据集市上的。
一般情况下，每个分析主题都需要构建一个OLAP。
1）ROLAP架构
ROLAP架构：
细节数据、聚合后的数据都保存在关系型的数据库中。
2）MOLAP架构
MOLAP架构：
将细节数据和聚合后的数据均保存在OLAP中。
3）HOLAP架构
HOLAP架构:
细节数据保存在关系型数据库的事实表中，但是聚合后的数据保存在OLAP中。
5.2向下兼容
SQLServer2021AnalysisServices具备很好的向下兼容性，利用SQLServer2021AnalysisServices或SQLServer2000AnalysisServices开发的数据库都可以平滑地迁移至SQLServer2021AnalysisServices。
数据库迁移主要包括两种方法：
1）在安装过程中通过升级AnalysisServices的现有实例来迁移现有AnalysisServices数据库；
2）在安装之后通过运行迁移向导进行迁移。
推荐通过使用迁移向导来迁移现有的AnalysisServices数据库，步骤如下：
1）从SQLServerManagementStudio的对象浏览器中的AnalysisServices效劳器节点启动迁移向导。
也可以通过在命令提示符处运行程序MigrationWizard.exe来启动该向导。
2）向导启动并显示“欢送使用AnalysisServices迁移向导〞页。
阅读介绍性消息，然后单击“下一步〞继续。
3）在“指定源和目标〞页上，标识源SQLServer2000AnalysisServices效劳器和实例名，然后标识目标SQLServer2021AnalysisServices效劳器和实例名。
如果不指定目标效劳器，还可以选择将数据库架构保存到一个脚本文件中，并在以后完成迁移。
可以使用SQLServer2021IntegrationServices（SSIS）包中的AnalysisServices执行DDL任务完成此操作。
4）在“选择要迁移的数据库〞页上，选中要迁移的数据库旁边的复选框。
如果愿意，可为目标数据库指定与源数据库不同的名称。
5）在“验证数据库〞页上，向导分析要迁移的数据库并报告所发现的任何问题。
6）在“迁移数据库〞页上，向导在执行数据库迁移时报告执行的进度。
7）在“完成向导〞页上，向导报告迁移的结果。
单击“完成〞即可完成向导。
8）迁移数据库之后，必须从原始数据源处理数据库，然后才能查询数据库。
9）迁移之后，您可能需要查看迁移考前须知〔AnalysisServices-多维数据〕，以了解AnalysisServices数据库不同版本间的差异。
5.3权限管理
系统为数据级的权限管理赋予了更强的生命力。
SQLServer2021AnalysisServices（SSAS）已经具备了数据级权限管理的能力，但用户界面及权限定制存在很多限制。
我们的系统SQLServer2021AnalysisServices（SSAS）根底上提供了更好的权限管理、定义、扩展和集成的能力，主要功能如下：
1）基于Web的用户、角色及权限定义
2）基于数据库的用户、角色及权限存储
3）与Windows用户、SharePoint用户及其他系统用户的集成
4）权限的下发〔即地区经理的权限可以由大区经理设定〕
5）支持所有的前端展现软件
5.4接口
OLAP模型提供标准的接口，任何类型的客户端〔包括Web和WinForm〕都可以轻松的通过接口获取数据模型中的数据。
接口驱动：
3）AMO
4）XML/A
接口查询语言：
MDX
6数据挖掘模型的开发及应用
数据挖掘〔DataMining〕，又称信息挖掘〔KnowledgeDiscovery〕，是建立在机器学习、概率论和数据库上的交叉技术，它是用自动或半自动化的方法在数据中找到潜在的、有价值的信息和规那么。
6.1过程及方法
一个数据挖掘工程的过程包括六步：
1）业务理解
2）数据理解
3）数据准备
4）建模
5）评估
6）部署
这六个阶段的顺序是不固定的，我们经常需要前后调整这些阶段。
这依赖每个阶段或是阶段中特定任务的产出物是否是下一个阶段必须的输入。
如图中箭头指出了最重要的和依赖度高的阶段关系。
如图的外圈象征数据挖掘自身的循环本质，即在一个解决方案发布之后一个数据挖掘的过程才可以继续。
在这个过程中得到的知识可以触发新的，经常是更聚焦的商业问题。
后续的过程可以从前一个过程得到益处。
数据挖掘数据流：
训练与评估数据流：
数据挖掘算法选择：
升级会员 