仓库管理_集装箱码头数据仓库的设计与实现

集装箱码头数据仓库的设计与实现 摘要随着信息技术的迅猛发展，数据仓库技术在信息技术领域已经成为了研究的热点，并且日益成熟，成为信息技术领域的前沿技术。实践证明，数据仓库的建立给企业带来丰厚的收益，集装箱码头也期望能通过数据仓库的建立来提升企业的核心竞争力。本论文以集装箱码头数据仓库项目需求为基础，致力于研究集装箱码头数据仓库吞吐量主题的设计方法与应用，通过对集装箱码头业务的分析和整理，选择合适的技术路线和数据仓库架构，实现数据仓库的建立。ETL设计是数据仓库的核心，在本论文中也不例外，论文使用大量的篇幅介绍了ETL的设计方法。为了减少对源系统的影响，设计合适的ETL显得尤为重要。作者在充分分析集装箱码头业务和数据仓库技术的基础上，设计了基于时间的ETL方式。项目中采用维度建模的方式实现了集装箱码头吞吐量多维数据集，最后选择微软公司的SQL Server2008作为数据仓库存储系统，对外提供吞吐量多维数据集进行查询与分析。关键词：数据仓库，集装箱码头，ETL，维度建模，吞吐量我们总羡慕别人的幸福，却常常忽略自己生活中的美好。其实，幸福很平凡也很简单，它就藏在看似琐碎的生活中。幸福的人，并非拿到了世界上最好的东西，而是珍惜了生命中的点点滴滴，用感恩的心态看待生活，用乐观的态度闯过磨难。AbstractWith 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,its 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 Server2008 ,and supply the multi-dimension cube to view and analysis.Key Words：dw,container terminal,ETL, dimensional modeling, throughput 目录摘要iAbstractii图目录III表目录IV第1章 绪论11.1 课题背景11.2 主要的研究内容21.3本章小结3第2章 数据仓库相关技术介绍42.1 数据仓库的发展42.2 数据仓库的实现过程52.3 新兴数据仓库解决方案52.4 本章小结8第3章 业务整理与项目规划93.1 业务状况介绍93.1.1 信息系统应用状况103.1.2 报表数据的需求103.1.3 其他需求113.2 数据仓库系统阶段规划113.3 预期产出成果113.4 架构设计123.5 本章小结15第4章 数据存储结构设计164.1 数据定义的统一164.2 数据源结构描述164.3 企业数据标准化184.4 数据仓库数据结构194.4.1 数据仓库表结构194.4.2 目标数据与源数据的对应关系214.5 本章小结22第5章 面向集装箱操作时间的ETL设计235.1 ETL的实现方式235.2 吞吐量数据初始化245.3 数据增量同步275.3.1 流程总览275.3.2 ETL增量同步的具体实现285.4 本章小结31第6章 吞吐量的多维数据集设计326.1 逻辑设计326.1.1 确定主题326.1.2 粒度的确定326.1.3 确定维度表336.1.4 确定事实表366.2 多维数据集的实现376.3 本章小结39第7章 数据展示与分析417.1 办公网吞吐量展示417.2 数据仓库报表417.3 数据分析427.4 本章小结44第8章 总结与展望458.1 总结458.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）。宁波大榭招商国际码头有限公司成立于2003年6月，公司是由香港招商局国际有限公司、宁波港集团、上海中信港口投资有限公司三方共同投资组建的中外合资企业。 规划建设3个10万吨级、1个7万吨级集装箱专用泊位，码头全长1500米，水深-17米，整个港区建成后总面积163.5万平方米，设计年吞吐量达240万TEU1。公司从建立至今一直保持着高速发展，在受到金融危机影响的2009年，吞吐量仍然保持近10%的增长，到达119万TEU，2010年吞吐量超过150万TEU。随着公司的发展，各业务系统的上线使用，产生的各种业务数据分布存储在不同的系统中。例如：主要生产作业量数据存储在集装箱码头操作管理系统（TOS）中，电量数据在RCMS系统、电量自动化系统中有存储但是数据意义不同，费收数据目前存储在TOS系统中以后会存储在商务计费系统中，应收账款的收款情况信息存储在财务系统中，设备加油数据存储在加油系统中，等等；目前的数据分析多是利用独立的业务数据进行数据提取分析的，无法灵活实现综合性的数据关联分析及钻取分析。如果需要对各种作业量及效率进行分析、对作业的成本进行分析、对作业的收入情况进行分析就需要建立一个适合统计分析的、便于扩展的、符合我司业务情况的统一的数据模型，从而将TOS系统中的作业数据，商务费收数据，财务收款数据，电量数据，油耗数据等业务数据统一起来，为后续的综合数据分析提供支持。下图所示中橙色部分为本次项目实施在整体企业信息规划中所处的位置，其中前端展现部分计划在企业统一信息平台中进行实现：图1.1 项目所处企业信息化的位置如图1.1所示，经过几年的信息化建设，公司的信息化基础设施、基础业务操作系统已经建设完成，目前的信息化系统已经能够满足公司业务操作需求。但是，随着行业竞争的加剧、公司发展对积累的历史数据进行分析的需要（例如：从各角度分析吞吐量情况、分析成本情况、分析收入情况），就需要在业务操作层的基础上构建适合统计分析的分析数据管理层，以便为公司各项数据的整合分析、为后续更高层次的商务智能分析打下基础。基于以上因素，提出大榭招商码头数据仓库项目，本论文就是在数据仓库建设的初期，探讨如何实现将码头生产操作数据导入数据仓库，并且以直观的形式在公司内部展示吞吐量相关数据，提供公司业务相关人员便捷查看，并能供给业务人员对集装箱吞吐量数据进行多方面的分析和钻取。1.2 主要的研究内容本文针对宁波大榭招商国际集装箱码头业务的特点和现状，主要对企业数据仓库项目吞吐量主题域的建立进行研究。本文在对比了几种经典的数据仓库设计架构之后，提出一个适合该码头的数据仓库架构，使得企业的分析数据统一无误，并能便捷的提供给业务岗位进行分析，并解释设计阶段的侧重点。本文主要研究内容包括：首先，分析招商国际码头业务需求，码头生产操作系统（TOS）中数据的逻辑关系、吞吐量相关的数据来源，并整理与之相关维度的关系，然后选择数据建模工具建立起吞吐量主题的逻辑模型。其次，根据招商国际码头业务系统的特点，尝试以MS SQLSERVER2008作为目标数据库存储平台完成物理设计，采用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服务和快速开发报表的工具，这些厂商凭借其关系数据库系统用户量的优势，在数据仓库的发展初期，占有了较多的市场份额。然而，当今数据仓库的市场已经不再由传统供应商独领风骚,NOSQL的MongoDB采用键-值存储和方式，具有高性能和高度的伸缩性，MongoDB是面向文档的数据库，数据存储格式为BSON（可以认为是二进制的JSON），MongoDB中，一个数据库可以有多个Collection，每个Collection是Document的集合。Collection和Document和传统数据库的Table和Row并不对等。数据库和Collection都无需预先定义，随时可以创建。使用传统的RDBMS存储一些大尺寸、低价值的数据时会比较昂贵，在此之前，往往选择传统的文件进行存储，而MongoDB的存储方式很好的解决了这个问题，可以轻松实现PB级的存储；由于MongoDB的Schema Free特性，数据改动时不需要对数据库结构进行修改，省去传统关系数据库基于表结构的繁琐DDL操作，所以，非常适合事实的插入、更新数据。以互联网企业账户分析的业务场景为例，账户分析项目中需要存储账户，计划，单元，关键词多个层级的各种维度的数据指标提供给用户查询分析，数据总量往往都在上亿。这种数据规模巨大，每日需要从各种日志文件中汇总各种数据指标按不同层级统计处结果写入数据库，并且有大量的日常客户端从各种维度查询分析数据。MongoDB高性能的数据导入和查询功能非常友好的支持了这种业务需求，正如MongoDB文档里提到的它非常适合实时分析一样。在互联网浪潮下迅速崛起的MySQL数据库在数据仓库实现方面也有着非凡的表现。Infobright是开源的MySQL数据仓库解决方案，其中引入了列存储方案，对数据进行高强度的压缩，同时优化了统计计算(如sum/count/avg/group by之类),它已经是很多开源或商用BI系统的底层存储引擎。Infobright的引擎是采用列式存储，这不同于传统数据库的行式存储，列式存储的主要优势是减少了每次查询所读取的数据量，无论何时你从传统的数据库中读取数据时，都需要完成的读出每一行，不管在查询中你是不是对这些数据感兴趣。很可能你读了1000个字节的记录而仅仅为了检索10个字符的用户名，而基于列读取数据，你仅仅需要读取查询感兴趣的相关列。这在读取一条或者几条数据时可能体现不出来优势，但是很多的查询需要进行全表扫表，如果一个表有千万行，查询性能将相差非常巨大。列式存储的另外一个优点是每个列本身就是索引，每个列都可以索引化，这在夯实数据库中几乎不可能实现。除此之外，列式存储还有一个非常吸引人的优点，那就是列更容易被压缩，因为对不同的数据类型可以使用不同的算法。其官方给出的数据是，可以达到10-40倍甚至更高的压缩比。图2.2 Infobright ArchitectureInfobright的架构如图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性能对比对比项InfobrightSQL Server1000万记录22秒300秒1.5亿记录564秒无返回结果OLTP数据450GB10GB450GB正是由于Infobright这种海量数据处理能力，使得其在海量数据分析的数据仓库项目中得到迅猛发展。2.4 本章小结本章开始介绍了数据仓库的发展和实现技术，另外介绍了数据仓库的实现过程，由于数据仓库是来源与企业中各种不同应用系统的，把企业中面向事务型的源数据整合为统一的、面向分析的数据仓库中是一个长期反复的过程，在面临大量的数据时，如何进行管理和整合是数据仓库设计者所面临的重大问题。作者介绍了两种不同的数据仓库实现过程，两种方式各有优缺点，需要根据实际的业务需求进行具体的选择，针对不同的业务需求采用不同的方式来进行数据仓库的建模。除了传统的数据仓库解决方案之外，本章的最后详细介绍了当前热点的Infobright数据仓库解决方案，通过对其架构和处理方式的分析体现了其强大的查询和存储优势。第3章 业务整理与项目规划3.1 业务状况介绍宁波大榭招商国际码头有限公司（以下简称CMICT）是以集装箱装卸为主营业务的码头公司，同时也提供集装箱堆存和修箱服务。根据不同航线对内贸箱、外贸箱、中转箱、非中转箱、重箱、空箱提供码头装卸及堆存等服务，而收费主要按不同航线以及箱型作为收费基础。集装箱码头所有对外提供的服务业务，归结起来就是“为客户提供吊箱服务”这一核心内容。吊箱操作看似简单，但由于在生产操作过程中存在诸多外界约束条件和不确定的变数，使得集装箱码头的生产操作业务呈现出一系列独特的特点，如效率与成本的矛盾，高峰与低谷的平衡。船公司是与码头关系最为密切的对象之一，船公司最基本需求是“确保装卸船操作效率和安全”。假设一条船需要装卸1000个箱，同时开三条、四条还是五条作业路数，就是一个很大的问题。少开作业线，全船作业效率可能只能维持在90MPH，船舶的在港时间将延长。对于船公司来说，船舶只有在海上航行时才是创造效益的，在港口停泊时间越长，成本就越高。但少开作业线，码头需要安排出勤的机械就少，出勤人员也少，调度也更简单，平均单箱成本就会更少。多开作业线，则上述利益态势就会此消彼长。集装箱物流运输行业在一年的时间里，业务量是不均衡的，存在着旺季和淡季的区别，而相应的集装箱码头业务量，也存在着高峰与低谷的情况。即使是在一周的周一到周日，也由于航线安排的疏密程度不均匀，不同的时间段也存在着作业量的高低起伏。但作为需要持续经营的集装箱码头来说，却需要维持一支相对稳定的作业资源和人员队伍，那么以相对固定不变的作业资源，去应对起伏不定的业务变化状况，就需要高超的峰谷平衡管理技巧，而管理和平衡的好坏，恰恰反映在前述的效率与成本上。降低企业运行成本提高效率是公司目前正在攻关的重要课题，操作部也投入大量精力和核心骨干投入成本与效率的研发，而研发需要大量的数据进行多角度的分析，公司目前的数据主要是面向操作的，不适合进行多方面的分析和挖掘操作，所以期望通过数据仓库的建设为公司后期的生产技术研发，甚至公司的运营决策找到一条合适的道路。3.1.1 信息系统应用状况目前使用基于Oracle的TOS码头生产管理系统，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 2008 提供了一个完整的数据仓库解决方案平台，为数据仓库应用提供了一个快速、完整的解决方案，其中为用户提供了可用于构建典型和创新的分析应用程序所需的各种特性、工具和功能，其中包括：lSQL Server 2008（关系数据库引擎）lDTS（数据转换服务）lSQL Server Analysis Services (分析服务)lSQL Server Reporting Services （报表服务）lSQL Server Management Studio （数据库管理工具集）lBusiness Intelligence Development Studio（BI 应用程序开发工具集）SQL Server2008的RDBMS可以作为中小企业数据仓库的首选存储平台，而且可以通过链接数据库的方式访问其他数据源，而且SQL Server并非解决方案所必须的，同样的也可以采用Oracle作为存储平台。数据整合服务(Integration Services)，它的处理架构组件和在此之上的企业级提取、转换和装载(ETL)工具，通过SSIS配合DTS，能够设计出符合企业中大量的ETL。而另外一项关键的工具就是SQL Server 2008 Reporting Service(SSRS)7，其中包含的报表设计器提供了一个可视SSAS多维数据集查询设计器，减少了手动编写OLAP多维数据查询的需求，从而大大的方便了报表的快速创建。在SQL Server 2008 Analysis Services（SSAS）为数据仓库提供了存储和查询OLAP多维数据集数据的机制，它还提供了OLAP多维数据集供开发人员进行开发和管理。在经费有限的时候，还可以把SSAS与SQLServer2008安装在同一台物理服务器，虽然不推荐这么做。当源数据经过抽取转换并装载到数据仓库之后, 我们就可以通过各种方式来呈现数据仓库中的数据，SSAS我们可以为数据仓库建立一系列的多维数据集(CUBE), 多维数据集包含一组通常由数据仓库的子集构成的、并组织和汇总到由一组维度和度量值定义的多维结构中的数据，为了便于理解，请参见图3.2:图3.2 OLAP多维数据集概念图（来自SQL Server联机丛书）在对比当前流行的数据仓库解决方案之后，发现微软公司的商务智能解决方案最符合本项目的需求，同时公司内部已经采购了SQL Server系列产品，内部研发人员在使用SQL Server上也有也有比较充足的经验，所以最终确定采用微软公司提供的SQL Server2008套件作为数据仓库的技术路线，确定技术路线后的数据仓库项目架构如图3.3：图3.3 数据仓库项目架构图3.5 本章小结本章介绍了项目所处的业务环境、企业实际的业务情况、目前正在使用的信息系统，以及项目的需求和目标，同时也描述了期望达到的目标和在项目的过程当中附带的成果。最后介绍了项目的架构设计所需的不同支持工具，并选定微软的SQL Server2008套件作为项目的实现工具，确定了技术路线后的项目架构更加清晰明了。第4章 数据存储结构设计4.1 数据定义的统一统一数据的定义就是对元数据进行管理，在数据仓库的管理中首要关注的就是元数据，因为元数据是说明数据的数据,实际上元数据时在大多数数据库应用和信息处理中用于定义、关联和管理数据的环境。元数据对于数据仓库的设计、开发和运作至关重要，尤其是在数据获取、转换和存取方面8。只有统一了数据的定义，才能对企业内的不同应用系统进行集成，数据的不一致性定义是普遍存在的问题，尤其是在多信息应用系统的企业内部更是如此，本项目也期望通过此项目的进行能够整理出初步的元数据管理办法。建立中央数据库存储元数据，在日后业务的变更时先修改中央数据库的元数据，各种应用系统间的交互再通过中央数据库进行统一的转换，这是一种非常不过的解决方案，但是这种解决方案需要企业投入大量的精力和人员，在本项目中显得不是特别合适。当前期望能够通过业务需求的整理和分析，商讨统一各个系统间的数据定义，形成电子文档进行存档，提供公司内部进行查阅，这是在当前环境下比较现实的做法。4.2 数据源结构描述本项目进行的其中一个目标就是进行码头生产操作系统TOS主要数据表结构的整理，形成电子文档，提供给IT内部人员参考，在业务岗位或者关联单位有临时数据提取需求时能够快速准确的提供数据，而不必依赖于第三方软件开发商。在没有数据字典的情况去了解一个信息系统的数据库，简直是个灾难，根本无从下手，只有通过猜测和系统数据录入进行对比分析。但幸运的是，IT部有位老员工对TOS系统比较熟悉，对数据库的主要结构也比较了解，通过他细心的讲解，加上阅读公司内遗留的各种资料，才整理出TOS系统数据库主要表结构第一版，加上后期的修正在项目收尾的时候才形成了比较完整的生产系统主要表结构信息。具体的表结构此处不再详细描述，形成的文档格式如图4.1：图4.1 表结构范例其中有10张表是与吞吐量相关，这里仅给出表名以供数据仓库存储时相对应，具体如表4.1 ：表4.1 源系统吞吐量相关表结构编号表名称说明T01CONTAINERS集装箱表，存储集装箱相关信息T02CONTAINEREVENTS箱事件表，存储对箱做过的操作信息T03WORKITEM指令表，存储对集装箱的指令操作信息T04EIR设备交接表，存储一个集装箱的交接信息T05TERMINALDEVICE终端设备信息，存储终端的属性信息T06VESSELBERTHPLAN船舶靠泊计划，存储船期信息T07VESSELSHIFTOTHERWORK杂项记录表，存储所做的杂项记录信息T08VESSELSHIFTSETTLE船舶工班表，存储工班安排信息T09VESSELSHIFTDALLYTIME待工时间表，存储船舶待工时间和原因T10VESSELLINE航线表，存储船舶航线信息T11VESSELPORT港口表，存储往来网口信息T12EMPLOYEEINWORKGROUP员工工班表，存储员工工班安排T13TYPEOFWORK工种表，存储工种类型T14BGUEST客户表，存储与公司往来客户资料T15SUSER用户表，存储生产系统登录用户T16TERMINALDEVICE设备表，存储公司机械设备信息有了这些整理出来的表结构信息，就能够清楚的明白需要从源数据中抽取哪些数据，经过何种转换存储到数据仓库中了。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）； 货物皮重在统计时间范围内的船期的装船作业箱皮重+卸船作业箱皮重； 货物净重在统计时间范围内的装船作业货重+卸船作业货重； 倒箱在装船作业指令中箱子的进港类型为倒箱（R）的指令，即为了装某个箱子到船上或从船上卸某个箱子时，需要移动其他集装箱而进行的操作。倒箱的吞吐量统计按照操作的集装箱实际情况计算。 装销子箱是指在装船作业时，桥吊作业的装销子箱数量。装销子箱作业1次对应桥吊吊具操作1次,装1个销子箱一次即计为1UNIT。折算标准将销子箱作业自然量折算为标准箱量的规则为1UNIT销子箱折算为1UNIT20英尺普通集装箱，即折算为1TEU；折算重量为2300千克； 卸销子箱是指在卸船作业时，桥吊作业的卸销子箱数量。卸销子箱作业1次对应桥吊吊具操作1次, 卸1个销子箱一次即计为1UNIT。折算标准将销子箱作业自然量折算为标准箱量的规则为1UNIT销子箱折算为1UNIT20英尺普通集装箱，即折算为1TEU；折算重量为2300千克； 开舱盖板指在装卸船作业时，桥吊作业的开舱盖板数量；1块舱盖板开1次即计为1UNIT；折算标准将舱盖板作业自然量折算为标准箱规则为1UNIT舱盖板折算为1UNIT 40英尺普通集装箱，即折算为2TEU；折算重量为4000千克； 关舱盖板指在装卸船作业时，桥吊作业的关舱盖板数量；1块舱盖板关1次即计为1UNIT；折算标准将舱盖板作业自然量折算为标准箱规则为1UNIT舱盖板折算为1UNIT 40英尺普通集装箱，即折算为2TEU；折算重量为4000千克； 集装箱吞吐量在统计时间范围内的船期的装船集装箱作业量+卸船集装箱作业量； 辅助作业吞吐量在统计时间范围内的船期，进行倒箱+装销子箱+卸销子箱+开舱盖板+关舱盖板的作业量；明确了吞吐量的各种统计数据定义之后，就能对外提供一致的度量值供各业务岗位进行分析，不用再为不同的部门而定制不同的统计规则和单位了，这也将促进对公司日后的工作效率效率，便于部门间的沟通和交流。4.4 数据仓库数据结构从原系统中抓取数据存储到数据仓库中，是数据仓库建立的目标。项目采用SQL Server2008作为数据仓库数据的存储平台，在数据仓库中建立了对应源数据中的16张表结构，另外还建立了8张表为多维数据集的建立提供整合后的数据。4.4.1 数据仓库表结构对应源数据的16张表数据来自源数据，但是其中的数据时经过加工和整理的，不仅对历史数据进行了修正，更重要的是在新的表结构中添加了部分冗余的数据字段，为的是更方便的从数据仓库中提取需要的数据。新的表结构如图4.2，可以明显的发现16张表之间没有外键关联，但是超过100行记录的表都有主键。这是因为考虑到数据装载的速度而取消了外键，数据仓库中的数据来源于事务型的集装箱码头操作系统TOS，存储到数据仓库中的数据只提供查询和分析，并不会存在事务型数据库中的数据不完整，这样取消了外键的设计，大大提升了数据的载入速度。图4.2 数据仓库表结构（一）另外8张表是专门为后面的OLAP而建立的，如图4.3红线标识部分是另外建立的8张表结构，未被圈起的是已经包含在前面所讲的16张表中。整个图4.3所示的表结构将成为吞吐量多维数据集中的维度和事实，具体的数据来源和作用会在后面目标数据与数据源的对应关系中详细描述。图4.3 数据仓库表结构（二）4.4.2 目标数据与源数据的对应关系在图4.2中的16张表对应源数据中的16张数据表，但是在数据仓库中存储的表结构中包含了更多的冗余信息，方便后期对数据的查询，减少表关联，同时也剔除了一些无用的字段，为数据表“瘦身”。另外建立的8张表数据表（图4.3），有保存ETL时间配置的ETLCofnig表（图4.3圆圈圈住部分），有用作日期维度的CalendarDate，还有标识大小箱类型的ContainerSize表，保存作业类型的QuereType表，保存工班计划的ShiftSchedule表，还有保存辅助作业类型的MiscType表。另外两个大表中的数据是从源数据中经过切割和整合而形成的，其中QcWork表保存桥吊的装卸船记录状况，如设备、工班、吊具的起吊方式、设备编号、泊位编号、集装箱号、操作人员和发生时间信息，当查询集装箱吞吐量时就可以直接从该表中获取吞吐量事实；QcWorkMisc是保存桥吊为装卸船而进行过的辅助作业，同样的在查询辅助作业吞吐量时可以直接从该表中获取辅助作业吞吐量事实。4.5 本章小结数据仓库环境中一个重要方面是元数据。元数据是关于数据的数据，只要有程序和数据，元数据就是信息处理环境的一部分。但是在数据仓库中，元数据扮演一个新的重要角色。也正因为有了元数据，可以最有效地利用数据仓库。元数据使得最终用户能够探索各种可能性10。正是因为元数据在数据仓库中的特殊地位，作者在本章详细的介绍了数据仓库的源数据定义和数据仓库中的表结构，以及为了数据仓库的建立而进行的数据标准化定义数据，并以文档存档的方式进行保存。第5章 面向集装箱操作时间的ETL设计5.1 ETL的实现方式数据抽取、转换和装载(ETL)的处理过程主要包含四个方面：l 从数据源抽取数据l 清洗校验数据l 对数据进行转换l 导入数据到数据仓库ETL是整个数据仓库建立过程中最为关键的