集装箱码头数据仓库的设计与实现样本.doc

集装箱码头数据仓库设计与实现 摘要
随着信息技术迅猛发展，数据仓库技术在信息技术领域已经成为了研究热点，并且日益成熟，成为信息技术领域前沿技术。实践证明，数据仓库建立给公司带来丰厚收益，集装箱码头也盼望能通过数据仓库建立来提高公司核心竞争力。
本论文以集装箱码头数据仓库项目需求为基本，致力于研究集装箱码头数据仓库吞吐量主题设计办法与应用，通过对集装箱码头业务分析和整顿，选取适当技术路线和数据仓库架构，实现数据仓库建立。
ETL设计是数据仓库核心，在本论文中也不例外，论文使用大量篇幅简介了ETL设计办法。为了减少对源系统影响，设计适当ETL显得尤为重要。作者在充分分析集装箱码头业务和数据仓库技术基本上，设计了基于时间ETL方式。
项目中采用维度建模方式实现了集装箱码头吞吐量多维数据集，最后选取微软公司SQL Server作为数据仓库存储系统，对外提供吞吐量多维数据集进行查询与分析。

核心词：　数据仓库，集装箱码头，ETL，维度建模，吞吐量

Abstract
With the rapid development of information technology，data warehouse technology in the field of information technology has become a research focus，and more mature. Practice has proved that data warehouse bring the huge profits to the enterprise，through the container terminal is also expected to establish a data warehouse to improve the core competitiveness.
Though the data warehouse requements of the project at container terminal ,the author dedicated to the research the data warehouse design method and applications for container terminal on theme of container throughput,then choose the appropriate technology roadmap and data warehouse architecture to finish the establishment of the warehouse.
ETL is the most important part in data warehouse constructing,it's also in this paper,the author spend a large amount of space to describe the design method of ETL. In order to reduce the impact on the source systems，ETL design is particularly important.The requirements of Container terminal is fully analysis by author,and then study on the basis data warehouse technology,so the ETL based on time was choose.
Dimensional modeling was used to design the multi-dimension cube of container terminal throughput in this project. Finally,the source data were stored in Microsoft SQL Server ,and supply the multi-dimension cube to view and analysis.
Key Words：dw,container terminal,ETL，dimensional modeling，throughput

目录
摘要 i
Abstract ii
图目录 III
表目录 IV
第1章 绪论 1
1.1 课题背景 1
1.2 重要研究内容 2
1.3本章小结 3
第2章 数据仓库有关技术简介 4
2.1 数据仓库发展 4
2.2 数据仓库实现过程 5
2.3 新兴数据仓库解决方案 5
2.4 本章小结 8
第3章 业务整顿与项目规划 9
3.1 业务状况简介 9
3.1.1 信息系统应用状况 10
3.1.2 报表数据需求 10
3.1.3 其她需求 11
3.2 数据仓库系统阶段规划 11
3.3 预期产出成果 11
3.4 架构设计 12
3.5 本章小结 15
第4章 数据存储构造设计 16
4.1 数据定义统一 16
4.2 数据源构造描述 16
4.3 公司数据原则化 18
4.4 数据仓库数据构造 19
4.4.1 数据仓库表构造 19
4.4.2 目的数据与源数据相应关系 21
4.5 本章小结 22
第5章 面向集装箱操作时间ETL设计 23
5.1 ETL实现方式 23
5.2 吞吐量数据初始化 24
5.3 数据增量同步 27
5.3.1 流程总览 27
5.3.2 ETL增量同步详细实现 28
5.4 本章小结 31
第6章 吞吐量多维数据集设计 32
6.1 逻辑设计 32
6.1.1 拟定主题 32
6.1.2 粒度拟定 32
6.1.3 拟定维度表 33
6.1.4 拟定事实表 36
6.2 多维数据集实现 37
6.3 本章小结 39
第7章 数据展示与分析 41
7.1 办公网吞吐量展示 41
7.2 数据仓库报表 41
7.3 数据分析 42
7.4 本章小结 44
第8章 总结与展望 45
8.1 总结 45
8.2 展望 46
参照文献 47
作者简历 49
道谢 50

图目录
图1.1 项目所处公司信息化位置……………………………………………..……2
图2.1 十大数据仓库排名…………………………………………..…………………4
图2.2 Infobright Architecture…………………………………………..………..……..7
图3.1 数据仓库体系构造…………………………………………..………………..12
图3.2 OLAP多维数据集概念图…………………………………………..…………14
图3.3 数据仓库项目架构图…………………………………………..………..……15
图4.1 表构造范例…………………………………………..………………………..17
图4.2 数据仓库表构造（一）…………………………………………..…………..20
图4.3 数据仓库表构造（二）…………………………………………..…………..21
图5.1 “数据流源”属性设立…………………………………………..…………..25
图5.2 数据仓库初始化SSIS包构造…………………………………………..……26
图5.3 增量数据ETL流程…………………………………………..………..………28
图5.4 Import包抓取源数据…………………………………………..………..…….29
图5.5 导入增量数据…………………………………………..……………………..30
图5.6 ETL执行筹划…………………………………………..……………………...31
图6.1 吞吐量维度关系…………………………………………..…………………..38
图6.2 日期层次关系…………………………………………..…………………..38
图6.3 度量值转换…………………………………………..……………………..39
图7.1 通过MOSS展示吞吐量…………………………………………..………….41
图7.2 船舶作业报表…………………………………………..……………………..42
图7.3 集装箱吞吐量（一）…………………………………………..………..……43
图7.4 集装箱吞吐量（二）…………………………………………..………..……43

表目录
表2.1Infobright性能对比………………………………………………………….......8表3.1报表分类举例……………………………………………………………….......8
表4.1源系统吞吐量有关表构造…………………………………………….……....17
表6.1船期维度……………………………………………………………………….34
表6.2集装箱维度…………………………………………………………………….35
表6.3辅助作业维度………………………………………………………………….36
表6.4集装箱作业类型纬度………………………………………………………….36
表6.5作业设备纬度………………………………………………………………….36
表6.6操作员表纬度………………………………………………………………….36
表6.7集装箱吞吐量事实…………………………………………………………….37
表6.8辅助作业吞吐量事实………………………………………………………….37

第1章 绪论
1.1 课题背景
本课题来源于，宁波大榭招商国际码头（简称CMICT）。
宁波大榭招商国际码头有限公司成立于6月，公司是由香港招商局国际有限公司、宁波港集团、上海中信港口投资有限公司三方共同投资组建中外合资公司。 规划建设3个10万吨级、1个7万吨级集装箱专用泊位，码头全长1500米，水深-17米，整个港区建成后总面积163.5万平方米，设计年吞吐量达240万TEU[1]。公司从建立至今始终保持着高速发展，在受到金融危机影响，吞吐量依然保持近10%增长，到达119万TEU，吞吐量超过150万TEU。
随着公司发展，各业务系统上线使用，产生各种业务数据分布存储在不同系统中。例如：重要生产作业量数据存储在集装箱码头操作管理系统（TOS）中，电量数据在RCMS系统、电量自动化系统中有存储但是数据意义不同，费收数据当前存储在TOS系统中后来会存储在商务计费系统中，应收账款收款状况信息存储在财务系统中，设备加油数据存储在加油系统中，等等；当前数据分析多是运用独立业务数据进行数据提取分析，无法灵活实现综合性数据关联分析及钻取分析。如果需要对各种作业量及效率进行分析、对作业成本进行分析、对作业收入状况进行分析就需要建立一种适合记录分析、便于扩展、符合我司业务状况统一数据模型，从而将TOS系统中作业数据，商务费收数据，财务收款数据，电量数据，油耗数据等业务数据统一起来，为后续综合数据分析提供支持。
下图所示中橙色某些为本次项目实行在整体公司信息规划中所处位置，其中前端呈现某些筹划在公司统一信息平台中进行实现：

图1.1 项目所处公司信息化位置
如图1.1所示，通过几年信息化建设，公司信息化基本设施、基本业务操作系统已经建设完毕，当前信息化系统已经可以满足公司业务操作需求。但是，随着行业竞争加剧、公司发展对积累历史数据进行分析需要（例如：从各角度分析吞吐量状况、分析成本状况、分析收入状况），就需要在业务操作层基本上构建适合记录分析分析数据管理层，以便为公司各项数据整合分析、为后续更高层次商务智能分析打下基本。
基于以上因素，提出大榭招商码头数据仓库项目，本论文就是在数据仓库建设初期，探讨如何实现将码头生产操作数据导入数据仓库，并且以直观形式在公司内部展示吞吐量有关数据，提供公司业务有关人员便捷查看，并能供应业务人员对集装箱吞吐量数据进行多方面分析和钻取。
1.2 重要研究内容
本文针对宁波大榭招商国际集装箱码头业务特点和现状，重要对公司数据仓库项目吞吐量主题域建立进行研究。本文在对比了几种典型数据仓库设计架构之后，提出一种适合该码头数据仓库架构，使得公司分析数据统一无误，并能便捷提供应业务岗位进行分析，并解释设计阶段侧重点。
本文重要研究内容涉及：
一方面，分析招商国际码头业务需求，码头生产操作系统（TOS）中数据逻辑关系、吞吐量有关数据来源，并整顿与之有关维度关系，然后选取数据建模工具建立起吞吐量主题逻辑模型。
另一方面，依照招商国际码头业务系统特点，尝试以MS SQLSERVER作为目的数据库存储平台完毕物理设计，采用SSIS作为ETL工具，并设计ETL解决流程。
最后，通过结合招商国际集装箱码头公司信息平台特点完毕数据展示，供应业务人员通过报表查询分析操作数据。
1.3本章小结
本章简介了宁波大榭招商国际码头有限公司概况和公司信息化发展状况。由于面临提高精细化管理限度、建立自身竞争优势、向管理要红利和业务发展需要等一系列问题，为理解决这些问题而提出数据仓库项目，同步概括阐明了论文涉及项目重要内容和目。最后，阐述了作者在该项目中从事研究内容。下一章，将对数据仓库有关技术进行一种粗略阐述。
第2章 数据仓库有关技术简介
2.1 数据仓库发展
随着PC迅速普及，业务解决系统运营成本大大减少，极大地推动了信息解决技术发展。公司大型联机事务解决技术已经相称成熟，较好地解决了公司对于实时业务交易需求。与此同步，激烈得各行各业对于数据解决提出了更高规定。公司已经不满可以协助她们迅速地解决业务，并且需要从浩如烟海大量业务活动规律性，提炼出经营管理所必要核心信息，使自身业务运作以及整个市场有关行业态势进行分析，从决策。正是在这样背景下，数据仓库技术应运而生了[2]。
在刚开始时候，数据仓库市场比较混乱，数以百计数据仓库提供商提供了各自定义数据仓库产品，通过十近年发展，数据仓库市场已经成熟起来，徐徐形成了以Sybase、IBM、Oracle、Microsoft等几家IT巨头为首数据仓库提供商，她们为各大跨国公司提供TB级别数据仓库解决方案，从Oracle白皮书中截取十大数据仓库排名，如图2.1：

图2.1 十大数据仓库排名
2.2 数据仓库实现过程
数据仓库建立可以采用自顶向下设计办法，一方面对整个公司所有数据整合建模，按照老式关系概念模型建立原子单元中央数据仓库，然后依照不同应用来分别建立相应数据集市，数据集市中数据所有来自前面建立中央数据仓库。这种架构需要公司业务明确，公司内部具备精确详细数据模型定义，需要调动公司每个部门参加，这种方式需要项目实行人员有丰富实际经验，并且公司中定义了规范数据原则，这种方式风险较大，但是这种方式中所有应用数据都是来自中央数据库，可以极大保证数据一致性。
如果公司没有做好完善准备，也可以采用自底向上设计办法，按照某个有关主题需求，通过迭代方式来建立公司数据仓库。这种方式相对风险较小，实行也较容易。这种方式一方面通过某个详细业务需求进行分析，按照维度模型建立数据集市，然后通过增长维度和数据集市螺旋向上构建数据仓库，这种方式建立数据仓库仅仅是包括所有数据集市联合。在最初分析阶段建立数据集市就是实现数据仓库基本，与后期数据集市联合实现数据仓库，不同数据集市之间可以通过创立一种统一维度来进行集成，每当增长数据集市时，都把新维度整合进统一维度中去。
为了减少数据仓库建立复杂度，按照自底向上方式，依照不同需求分阶段完毕数据仓库建设，这种方式针对业务应用不是直接建立维度化数据集市，而是先建立合用于各种数据集市原子级数据仓库，数据集市建立在原子级数据仓库之上。
2.3 新兴数据仓库解决方案
老式数据库提供商提供了重要基于自身数据库产品解决方案，如Oracle公司和微软公司，她们都提供了一整套数据仓库解决方案，她们不但提供了存储数据DBMS，并且集成了可视化ETL设计工具，并对外提供OLAP服务和迅速开发报表工具，这些厂商凭借其关系数据库系统顾客量优势，在数据仓库发展初期，占有了较多市场份额。
然而，当今数据仓库市场已经不再由老式供应商独领风骚,NOSQLMongoDB采用键-值存储和方式，具备高性能和高度伸缩性，MongoDB是面向文档数据库，数据存储格式为BSON（可以以为是二进制JSON），MongoDB中，一种数据库可以有各种Collection，每个Collection是Document集合。Collection和Document和老式数据库Table和Row并不对等。数据库和Collection都无需预先定义，随时可以创立。
使用老式RDBMS存储某些大尺寸、低价值数据时会比较昂贵，在此之前，往往选取老式文献进行存储，而MongoDB存储方式较好解决了这个问题，可以轻松实现PB级存储；由于MongoDBSchema Free特性，数据改动时不需要对数据库构造进行修改，省去老式关系数据库基于表构造繁琐DDL操作，因此，非常适合事实插入、更新数据。
以互联网公司账户分析业务场景为例，账户分析项目中需要存储账户，筹划，单元，核心词各种层级各种维度数据指标提供应顾客查询分析，数据总量往往都在上亿。这种数据规模巨大，每日需要从各种日记文献中汇总各种数据指标按不同层级记录处成果写入数据库，并且有大量寻常客户端从各种维度查询分析数据。MongoDB高性能数据导入和查询功能非常和谐支持了这种业务需求，正如MongoDB文档里提到它非常适合实时分析同样。
在互联网浪潮下迅速崛起MySQL数据库在数据仓库实现方面也有着非凡体现。Infobright是开源MySQL数据仓库解决方案，其中引入了列存储方案，对数据进行高强度压缩，同步优化了记录计算(如sum/count/avg/group by之类),它已经是诸多开源或商用BI系统底层存储引擎。
Infobright引擎是采用列式存储，这不同于老式数据库行式存储，列式存储重要优势是减少了每次查询所读取数据量，无论何时你从老式数据库中读取数据时，都需要完毕读出每一行，不论在查询中你是不是对这些数据感兴趣。很也许你读了1000个字节记录而仅仅为了检索10个字符顾客名，而基于列读取数据，你仅仅需要读取查询感兴趣有关列。这在读取一条或者几条数据时也许体现不出来优势，但是诸多查询需要进行全表扫表，如果一种表有千万行，查询性能将相差非常巨大。
列式存储此外一种长处是每个列自身就是索引，每个列都可以索引化，这在夯实数据库中几乎不也许实现。除此之外，列式存储尚有一种非常吸引人长处，那就是列更容易被压缩，由于对不同数据类型可以使用不同算法。其官方给出数据是，可以达到10-40倍甚至更高压缩比。

图2.2 Infobright Architecture
Infobright架构如图2.2，通过Knowledge Grid来组织数据，将64K个单元（列元素）放到一种Data Pack（DP）中进行压缩，由于这些元素具备相似数据类型，InfoBright会选取对于此数据类型最优算法进行压缩，通过压缩数据，可以非常明显减少IO压力，减少磁盘空间消耗。 InfoBright还会依照查询SQL动态将所有DP分为三类：有关块、无关块和可疑块。通过对数据块进行分类，可以有效减少查询所检索数据量，提高查询效率。
在Infobright官方网站上简介Bango数据仓库案例中，清晰展示了其先进存储和查询能力。Bango是欧洲一家电信运营商，每月会产生1.5亿行数据，每月数据增长量450G。采用Infobright数据仓库其应用性能大大提高，对比其本来SQL Server架构，如表2.1：

表2.1 Infobright性能对比
对比项
Infobright
SQL Server
1000万记录
22秒
300秒
1.5亿记录
564秒
无返回成果
OLTP数据450GB
10GB
450GB
正是由于Infobright这种海量数据解决能力，使得其在海量数据分析数据仓库项目中得到迅猛发展。
2.4 本章小结
本章开始简介了数据仓库发展和实现技术，此外简介了数据仓库实现过程，由于数据仓库是来源与公司中各种不同应用系统，把公司中面向事务型源数据整合为统一、面向分析数据仓库中是一种长期重复过程，在面临大量数据时，如何进行管理和整合是数据仓库设计者所面临重大问题。作者简介了两种不同数据仓库实现过程，两种方式各有优缺陷，需要依照实际业务需求进行详细选取，针对不同业务需求采用不同方式来进行数据仓库建模。
除了老式数据仓库解决方案之外，本章最后详细简介了当前热点Infobright数据仓库解决方案，通过对其架构和解决方式分析体现了其强大查询和存储优势。

第3章 业务整顿与项目规划
3.1 业务状况简介
宁波大榭招商国际码头有限公司（如下简称CMICT）是以集装箱装卸为主营业务码头公司，同步也提供集装箱堆存和修箱服务。依照不同航线对内贸箱、外贸箱、中转箱、非中转箱、重箱、空箱提供码头装卸及堆存等服务，而收费重要按不同航线以及箱型作为收费基本。
集装箱码头所有对外提供服务业务，归结起来就是“为客户提供吊箱服务”这一核心内容。吊箱操作看似简朴，但由于在生产操作过程中存在诸多外界约束条件和不拟定变数，使得集装箱码头生产操作业务呈现出一系列独特特点，如效率与成本矛盾，高峰与低谷平衡。
船公司是与码头关系最为密切对象之一，船公司最基本需求是“保证装卸船操作效率和安全”。假设一条船需要装卸1000个箱，同步开三条、四条还是五条作业路数，就是一种很大问题。少开作业线，全船作业效率也许只能维持在90MPH，船舶在港时间将延长。对于船公司来说，船舶只有在海上航行时才是创造效益，在港口停泊时间越长，成本就越高。但少开作业线，码头需要安排出勤机械就少，出勤人员也少，调度也更简朴，平均单箱成本就会更少。多开作业线，则上述利益态势就会此消彼长。
集装箱物流运送行业在一年时间里，业务量是不均衡，存在着旺季和淡季区别，而相应集装箱码头业务量，也存在着高峰与低谷状况。虽然是在一周周一到周日，也由于航线安排疏密限度不均匀，不同步间段也存在着作业量高低起伏。但作为需要持续经营集装箱码头来说，却需要维持一支相对稳定作业资源和人员队伍，那么以相对固定不变作业资源，去应对起伏不定业务变化状况，就需要高超峰谷平衡管理技巧，而管理和平衡好坏，恰恰反映在前述效率与成本上。
减少公司运营成本提高效率是公司当前正在攻关重要课题，操作部也投入大量精力和核心骨干投入成本与效率研发，而研发需要大量数据进行多角度分析，公司当前数据重要是面向操作，不适合进行多方面分析和挖掘操作，因此盼望通过数据仓库建设为公司后期生产技术研发，甚至公司运营决策找到一条适当道路。
3.1.1 信息系统应用状况
当前使用基于OracleTOS码头生产管理系统，TOS系统重要模块涉及码头生产操作系统、商务计费系统等，此后将有越来越多模块将整合到TOS系统中去。除了生产最核心码头生产管理系统外，码头还在应用有各种信息系统：
l 公司办公信息系统
l Exchange邮件系统
l K3财务系统
l 商务计费系统（当前集成在TOS系统，独立计费系统即将开发完毕）
l IBM Maximo EAM资产管理系统
l Microsoft AD域控管理系统
l 短信系统
l 加油管理系统
l 电力管理系统
l EDI报文传播、港务局信息交互系统、监控系统、海关交互系统等等
众多信息系统间数据定义不统一，系统间交互十分困难，与外部口岸单位之间传播数据就更加困难，从不同系统内查询出数据都要通过不同规则转换再发到外部，公司内部数据统一和原则化规定就显得十分迫切。
3.1.2 报表数据需求
在公司内部生产技术研发、对外部单位提供数据，最直观和以便就是报表展示，因此各部门提出了各种各样报表需求抽取某些需求如表3.1：
表3.1报表分类举例
报表类型
报表名称
吞吐量
单航线箱量
吞吐量
各航线箱量对比登记表
吞吐量
航线及港口箱量
吞吐量
航线类型箱主箱量登记表
吞吐量
装卸货港箱量记录
可以清晰发现，报表都是为了满足前面所述公司核心业务岗位迫切需求，除了吞吐量有关数据外，还需要较多效率和考核类数据，这些数据所有都是基于集装箱吞吐量。因此，集装箱吞吐量有关业务数据都要需要进行清晰统一定义，通过清洗后导入到数据仓库中，再查询出有关数据提供应不同部门和单位。
3.1.3 其她需求
如果仅仅提供报表展示给最后顾客，则不能提供适当渠道给生产技术研发人员进行数据挖掘和分析，以找到生产中存在问题和提高生产效率办法，因此，项目还应提供便捷数据挖掘办法，供应生产研发人员进行数据分析；此外，公司其她部门人员对集装箱吞吐量变化十分关怀，但愿能在办公网首页上可以直观查看到集装箱吞吐量变化状况，最佳是以图形形式展示，可以对比去年和前年同期吞吐量状况。
3.2 数据仓库系统阶段规划
综合分析了项目需求后，基本上就拟定了数据仓库应用主题，由于数据仓库建设是一种长期和迭代过程，而本项目进行也是数据仓库一种探路石，在与顾客沟通和交流过之后发现她们当前对其她主题需求不是特别强烈，或者她们还不明确她们需求，而吞吐量主题有关需求就显得十分迫切，因此，当前项目先建立吞吐量有关主题，关于财务、成本、收入等等主题待后期进行。
3.3 预期产出成果
充分分析了顾客需求，总结预期项目目的如下：
l 建立公司数据仓库，保存统一干净操作数据
l 提供报表供应业务岗位查询
l 建立OLAP吞吐量数据集，并提供工具进行数据挖掘和分析
l 在办公网图形化显示吞吐量数据，并展示与前两年同期对比状况
l 整顿集装箱生产操作系统TOS数据库中重要表构造，为各种暂时提取数据提供参照根据
l 统一公司内部各系统数据定义和记录原则，形成吞吐量有关原则化文档，在公司内部统一数据原则，规范记录数据规则
l 为日后公司运营决策系统摸索道路，盼望日后在此基本上建立完善公司数据仓库系统
3.4 架构设计
架构在软件工程领域被提及次数非常频繁，这是由于好架构可以更容易实现业务需求，好架构能提供更先进服务性能，架构也决定着项目灵活性和开发效率。架构重要性我就不在此赘述，相信人们都明白架构对项目重要性了。
数据仓库重要工作就是从不同数据源中抽取数据，通过清洗、修正，再导入到数据仓库存储中，最后再以不同形式展示给顾客。图3.1可以清晰表达项目基本架构：
图3.1数据仓库体系构造
从图中可以看出项目需要采用不同架构来实现所需功能，图中功能大体分为三个某些：
第一某些，从数据源导入数据，解决之后导入数据仓库中存储；源数据已经是客观存在了，无需也无法选取数据源存储方式。而导入数据到数据仓库中过程咱们普通称作ETL，这个过程需要高速稳定技术架构支持。
第二某些，数据仓库存储数据方式固然是整个项目重中之重了，此外需要从数据仓库中抽取维度和事实形成OLAP数据集，多维存储方式会得到更高性能，建立OLAP对外提供服务也需要稳定迅速架构支持。
第三某些，数据前端展示。本项目中规定数据不但要在办公网中图形化显示，并且需要展示独立报表，还需要支持OLAP分析工具进行数据钻取和分析，数据展示灵活，老式报表开发工作量巨大，适合非专业人员使用OLAP分析工具更是不多，并且要支持数据在MOSS搭建办公网中图形化显示，前段展示架构更加复杂。
IT领域技术熟悉万变，选取没有服务保障技术架构往往使项目风险倍增。在过去几年间，数家IT巨子宣布被收购，就连鼎鼎大名Sun公司也免不了被收购命运，因此选取一家实例雄厚，可以提供支持本项目公司尤为核心，最佳可以提供符合本项目状况整套解决方案。
微软公司近期在大力推广其数据仓库解决方案，其Microsoft SQL Server 提供了一种完整数据仓库解决方案平台，为数据仓库应用提供了一种迅速、完整解决方案，其中为顾客提供了可用于构建典型和创新分析应用程序所需各种特性、工具和功能，其中涉及：
l SQL Server （关系数据库引擎）
l DTS （数据转换服务）
l SQL Server Analysis Services (分析服务)
l SQL Server Reporting Services （报表服务）
l SQL Server Management Studio （数据库管理工具集）
l Business Intelligence Development Studio（BI 应用程序开发工具集）
SQL ServerRDBMS可以作为中小公司数据仓库首选存储平台，并且可以通过链接数据库方式访问其她数据源，并且SQL Server并非解决方案所必要，同样也可以采用Oracle作为存储平台。
数据整合服务(Integration Services)，它解决架构组件和在此之上公司级提取、转换和装载(ETL)工具，通过SSIS配合DTS，可以设计出符合公司中大量ETL。
而此外一项核心工具就是SQL Server Reporting Service(SSRS)[7]，其中包括报表设计器提供了一种可视SSAS多维数据集查询设计器，减少了手动编写OLAP多维数据查询需求，从而大大以便了报表迅速创立。
在SQL Server Analysis Services（SSAS）为数据仓库提供了存储和查询OLAP多维数据集数据机制，它还提供了OLAP多维数据集供开发人员进行开发和管理。在经费有限时候，还可以把SSAS与SQLServer安装在同一台物理服务器，虽然不推荐这样做。
当源数据通过抽取转换并装载到数据仓库之后，咱们就可以通过各种方式来呈现数据仓库中数据，SSAS咱们可觉得数据仓库建立一系列多维数据集(CUBE)，多维数据集包括一组普通由数据仓库子集构成、并组织和汇总到由一组维度和度量值定义多维构造中数据，为了便于理解，请参见图3.2:

图3.2 OLAP多维数据集概念图（来自SQL Server联机丛书）
在对比当前流行数据仓库解决方案之后，发现微软公司商务智能解决方案最符合本项目需求，同步公司内部已经采购了SQL Server系列产品，内部研发人员在使用SQL Server上也有也有比较充分经验，因此最后拟定采用微软公司提供SQL Server套件作为数据仓库技术路线，拟定技术路线后数据仓库项目架构如图3.3：
图3.3 数据仓库项目架构图
3.5 本章小结
本章简介了项目所处业务环境、公司实际业务状况、当前正在使用信息系统，以及项目需求和目的，同步也描述了盼望达到目的和在项目过程当中附带成果。最后简介了项目架构设计所需不同支持工具，并选定微软SQL Server套件作为项目实现工具，拟定了技术路线后项目架构更加清晰明了。

第4章 数据存储构造设计
4.1 数据定义统一
统一数据定义就是对元数据进行管理，在数据仓库管理中首要关注就是元数据，由于元数据是阐明数据数据,事实上元数据时在大多数数据库应用和信息解决中用于定义、关联和管理数据环境。元数据对于数据仓库设计、开发和运作至关重要，特别是在数据获取、转换和存取方面[8]。
只有统一了数据定义，才干对公司内不同应用系统进行集成，数据不一致性定义是普遍存在问题，特别是在多信息应用系统公司内部更是如此，本项目也盼望通过此项目进行可以整顿出初步元数据管理办法。建立中央数据库存储元数据，在日后业务变更时先修改中央数据库元数据，各种应用系统间交互再通过中央数据库进行统一转换，这是一种非常但是解决方案，但是这种解决方案需要公司投入大量精力和人员，在本项目中显得不是特别适当。当前盼望可以通过业务需求整顿和分析，商讨统一各个系统间数据定义，形成电子文档进行存档，提供公司内部进行查阅，这是在当前环境下比较现实做法。
4.2 数据源构造描述
本项目进行其中一种目的就是进行码头生产操作系统TOS重要数据表构造整顿，形成电子文档，提供应IT内部人员参照，在业务岗位或者关联单位有暂时数据提取需求时可以迅速精确提供数据，而不必依赖于第三方软件开发商。在没有数据字典状况去理解一种信息系统数据库，简直是个劫难，主线无从下手，只有通过猜测和系统数据录入进行对比分析。但幸运是，IT部有位老员工对TOS系统比较熟悉，对数据库重要构造也比较理解，通过她细心解说，加上阅读公司内遗留各种资料，才整顿出《TOS系统数据库重要表构造》第一版，加上后期修正在项目收尾时候才形成了比较完整生产系统重要表构造信息。详细表构造此处不再详细描述，形成文档格式如图4.1：

图4.1 表构造范例
其中有10张表是与吞吐量有关，这里仅给出表名以供数据仓库存储时相相应，详细如表4.1 ：
表4.1 源系统吞吐量有关表构造
编号
表名称
阐明
T01
CONTAINERS
集装箱表，存储集装箱有关信息
T02
CONTAINEREVENTS
箱事件表，存储对箱做过操作信息
T03
WORKITEM
指令表，存储对集装箱指令操作信息
T04
EIR
设备交接表，存储一种集装箱交接信息
T05
TERMINALDEVICE
终端设备信息，存储终端属性信息
T06
VESSELBERTHPLAN
船舶靠泊筹划，存储船期信息
T07
VESSELSHIFTOTHERWORK
杂项登记表，存储所做杂项记录信息
T08
VESSELSHIFTSETTLE
船舶工班表，存储工班安排信息
T09
VESSELSHIFTDALLYTIME
待工时间表，存储船舶待工时间和因素
T10
VESSELLINE
航线表，存储船舶航线信息
T11
VESSELPORT
港口表，存储往来网口信息
T12
EMPLOYEEINWORKGROUP
员工工班表，存储员工工班安排
T13
TYPEOFWORK
工种表，存储工种类型
T14
BGUEST
客户表，存储与公司往来客户资料
T15
SUSER
顾客表，存储生产系统登录顾客
T16
TERMINALDEVICE
设备表，存储公司机械设备信息
有了这些整顿出来表构造信息，就可以清晰明白需要从源数据中抽取哪些数据，通过何种转换存储到数据仓库中了。
4.3 公司数据原则化
前面讲到公司内部有众多信息系统在运营，系统内各种数据定义不一致，同种数据定义值单位也有区别，不同部门间记录数据方式也有差别，如吞吐量，可以按照自然日(24:00截止)记录，操作部按照每天18点截止记录；吞吐量有些地方包括辅助作业量有些地方又不包括辅助作业量；因此，进行数据原则化工作是十分有必要，这也是数据仓库建立基本工作之一。
在吞吐量主题建立上，一方面需要明确各种基本数据定义。
Ø 自然箱量
单位UNIT，1条作业指令即相应1个集装箱装船操作，也即为1UNIT。
Ø 原则箱量
单位TEU，依照作业指令相应集装箱尺寸折算为原则TEU，折算规则为：1个20英尺集装箱记录为1TEU，1个40英尺集装箱记录为2TEU，1个45英尺集装箱记录为2.25TEU；
Ø 吞吐量记录时间截点
按照船舶实际离泊时间来记录，时间点是18：00，月度数据记录时间是上月最后一天18：00（不含：18：00）到当月最后一天18：00（含18：00）；
Ø 货品皮重
在记录时间范畴内船期装船作业箱皮重+卸船作业箱皮重；