A. 中心数据库设计
5.2.2.1 数据库
根据该系统的开发需求，按照数据库的功能和作用将其分为风险查询类、风险评价类、系统管理类三大类（萨师煊等，2000）。主要数据见表5.5。
表5.5 海外油气与金属矿产资源开发风险管理系统的主要数据表
续表
5.2.2.2 数据仓库
油价数据来源于美国能源部（DOE）下属的能源信息署（EIA）网站、中石油（CNPC）网站和《华尔街日报》（WSJ）网站提供的油价数据，油价序列本身就是一个不规则的时间序列，油价数据具有以下几个特点。
（1）数据的一致性差
油价数据格式多样，存在数据冗余，主要体现在：使用的数据格式均不相同，并且各个子系统相对独立。在网站单独作用的情况下，一般都没有问题，但要将这些不同系统或不同时期的数据集中起来综合利用，就可能出现数据不齐全、不一致或重复的现象。
（2）数据存放的分散
油价数据来源多，缺乏统一管理，没有一种相应的网页数据自动化抓取操作实现数据的本地化操作过程。
（3）数据资源开发不充分
大容量数据导致对数据资源的开发利用不充分，缺乏对获取的数据如各分析机构制定的期货合约元数据进行各种深层次分析、综合、提炼、挖掘和展现的应用，因此很难对丰富的统计数据资源进行二次开发利用。
根据油价数据中所包含的油气产品种类、油气产品合约制定日期、油气产品的价格类型、不同市场下油气产品价格的差异等，能够加深对油价走势的了解。油价的这种与时间相关性、不可修改性，以及集成的性质，使得我们采用多种角度对原始数据进行理解，并真实反映其特性，也让我们发现使用一种整合的技术对油价进行精确预测十分必要。
数据仓库的构建流程如图5.13所示由下至上逐步实现。
图5.13 数据仓库构建流程
1）数据源。
A.数据源的复杂性。数据分散在数据库管理系统、电子表格、电子邮件系统、电子文档甚至纸上。系统中要求采集的3个数据源中，EIA 网站存储在网页上的油价相关事件更新较慢，虽然提供了各市场日、周、月、年的油价数据下载，但是下载完成之后的表格字段格式时常发生变化，这为实现自动获取数据并下载到本地自动入库的要求增加了难度；中石油网站数据除上述只显示3条数据之外，网站上会将访问流量过大的IP地址列入黑名单使其不能继续下载到本地进行保存，为这些数据建立统一的模型将会耗费很大精力。
B.数据的有效性。由于存在经验局限，如何处理数据的空值、不同时间间隔时间字段格式，入库时应注意的问题等，如果应用程序没有检验数据的有效性，会对数据多维显示产生极大影响，因此也归结为数据源数据质量问题。
C.数据的完整性。数据源上的数据并不那么明显或者容易获得。油价是高度敏感的数据，因此各个网站虽然提供了各个油品交易市场的日、月或年数据，但是完整性并不能充分保证，根据企业政策的不同，有时对要获得的数据，需花费大量精力。为此，要对不同的数据源进行建库，以保证所获数据的完整性。
2）数据处理。
高效的多维数据集展示离不开底层数据源数据的精确获取，或者叫做数据理解和数据清洗。于是系统在基于元数据获取、加工、入库和多维数据集展示上实现预期的要求。
A.ETL。该功能是整个油价数据仓库的核心之一，主要功能是按照事先定义的数据表对应关系从相关系统表中抽取数据（Extraction），经过数据清洗和转换（Transform）,最终把正确的数据装载到数据仓库的源数据中（Load），作为以后应用的基础。
B.数据转换。该功能是在数据抽取过程中按照定义的规则转换数据，避免了数据在分析时的多样性，保证数据一致性。
C.数据集成。该功能主要是把油价信息数据仓库系统的源数据，按照事先定义的计算逻辑以主题的方式重新整合数据，并以新的数据结构形式存储。
3）数据存储。
星型模型（星型架构）是数据仓库开发中多维展现重要的逻辑结构，构成星型模型的几个重要特征是：维、度和属性，在实际应用中表示为事实表和维度表。在油价数据中，各市场的期现货价格表为数据仓库的事实表，油品类型、合约规定日期等为维度表。
油价数据仓库星型模型的设计方案如下：
A.事实表。数据库表中EIA的期现货价格表（包括日、周、月、年表）作为数据仓库中的事实表，根据不同时间维度构成多个星型模型，即星座模型。这些价格表中以市场编号、油气产品类型、期货合约日期、价格单位度量衡编号作为主键和外键与其他维度表相连，形成多维展示联动的基础，以油价数据和其他事实数据为记录数据，作为主要输出结果。
B.维度表。根据市场、油品、价格数据、度量衡和事件类型作为油气数据仓库中多维分析的角度和目标。
图5.14以EIA的日期货数据表作事实表为例，构建星型模型，其他不同时间维度的模型结构图与此图基本相同。
图5.14 以EIA数据为例的日期货价格星型模型
以星型模型设计为基础，完善数据存储中操作型数据存储（ODS）的原型设计，提供DB-DW之间中间层的数据环境，可实现操作型数据整合和各个系统之间的数据交换。
B. 什么是数据仓库 星型模式
（星形模式是一种多维的数据关系，它由一个事实表（Fact
Table）和一组维表（Dimension
Table）组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。事实表的非主键属性称为事实（Fact），它们一般都是数值或其他
可以进行计算的数据；而维大都是文字、时间等类型的数据，按这种方式组织好数据我们就可以按照不同的维（事实表主键的部分或全部）来对这些事实数据进行求
和（summary）、求平均（average）、计数（count）、百分比（percent）的聚集计算，甚至可以做20～80分析。这样就可以从不
同的角度数字来分析业务主题的情况。）
在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型还是雪花型模型进行组织。
当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型， 如图 2 。
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家
A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。
销售数据仓库中的星型模型
当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多
个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "
层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如图 2-3，将地域维表又分解为国家，省份，城市等维表。它的优点是 :
通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余
销售数据仓库中的雪花型模型
星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现
都比较简单。
雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数
据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。
C. 数据库系统是层次形的，还是星形的，还是还是网状的求告知
数据库系统
的发展是经历了好几个阶段，有层次型的，有网状的，但现在用的最多的是
关系型数据库
，即RDBMS(
关系型数据库管理系统
)。其他类型的数据库都用的比较少了。
另外，现在也不仅仅是数据库了，还有
数据仓库
等，如HBase。
D. 数据仓库数据建模的几种思路
数据仓库数据建模的几种思路主要分为一下几种
1. 星型模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：a. 维表只和事实表关联，维表之间没有关联；b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c. 以事实表为核心，维表围绕核心呈星形分布；
星座模型
E. 数据仓库的数据结构，到底是星型、雪花模型、还是三范式三范式和星型、雪花是什么关系是不是包含他们
首先，你说的数据结构设计包括了两种，一个是数据库设计，一个是数据仓库设计
针对数据库设计一般用的是三范式。因为数据库的数据会用于频繁的增删改查，因此出于减少系统压力考虑，会尽量减少冗余，从而提升系统频繁读写数据的效率。
而星型、雪花型则是数据仓库的设计模式。与数据库的使用目的不同，数据仓库更多的是存储历史数据，不会有频繁的读写。其主要是用于从历史数据中进行分析，进而获取指导性的生产指引，生成报表等等。而这时数据库设计中的范式拆表以提升效率的方法这时却会适得其反（因为历史数据的量相当庞大，而往往数据分析、BI等又需要从多个表中检索数据来进行，这时大表之间的频繁交互会使分析效率变得相当低，所以往往会考虑合并表的方法，故意制造冗余）。
当然，以我个人的经验，就算是数据库设计，也很少会把表设计到三范式。因为一旦表的数据量变得庞大时，表与表之间交互的时间代价会比冗余数据的代价大得多。
F. 数据仓库建模，星型模型大致了解，就是事实表对应许多维表；对雪花型模型就不是很理解了
详细和你说一下星型模型和雪花模型
星型模式 vs 雪花模型多维数据建模以直观的方式组织数据，并支持高性能的数据访问。每一个多维数据模型由多个多维数据模式表示，每一个多维数据模式都是由一个事实表和一组维表组成的。多维模型最常见的是星形模式。在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。在星型的基础上，发展出雪花模式，下面就二者的特点做比较。 星型模式位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。每个指标实体代表一系列相关事实，完成一项指定的功能。位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。每个维表有自己的属性，维表和事实表通过关键字相关联。星形模式虽然是一个关系模型，但是它不是一个规范化的模型。在星形模式中，维度表被故意地非规范化了，这是星形模式与OLTP系统中的关系模式的基本区别。使用星形模式主要有两方面的原因:提高查询的效率。采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。同时由于维表一般都很小,甚至可以放在高速缓存中,与事实表作连接时其速度较快;便于用户理解。对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。总结：非正规化；多维数据集中的每一个维度都与事实表连接（通过主键和外键）；不存在渐变维度；有冗余数据；查询效率可能会比较高；不用过多考虑正规化因素，设计维护较为简单。
雪花模式 在实际应用中，随着事实表和维表的增加和变化，星形模式会产生多种衍生模式，包括星系模式、星座模式、二级维表和雪花模式。雪花模式是对星形模式维表的进一步层次化，将某些维表扩展成事实表，这样既可以应付不同级别用户的查询，又可以将源数据通过层次间的联系向上综合，最大限度地减少数据存储量，因而提高了查询功能。雪花模式的维度表是基于范式理论的，因此是界于第三范式和星形模式之间的一种设计模式，通常是部分数据组织采用第三范式的规范结构，部分数据组织采用星形模式的事实表和维表结构。在某些情况下，雪花模式的形成是由于星形模式在组织数据时，为减少维表层次和处理多对多关系而对数据表进行规范化处理后形成的。雪花模式的优点是:在一定程度上减少了存储空间;规范化的结构更容易更新和维护。同样雪花模式也存在不少缺点:雪花模式比较复杂，用户不容易理解;浏览内容相对困难;额外的连接将使查询性能下降。在数据仓库中，通常不推荐“雪花化”。因为在数据仓库中，查询性能相对OLTP系统来说更加被重视，而雪花模式会降低数据仓库系统的性能。总结：正规化；数据冗余少；有些数据需要连接才能获取，可能效率较低；规范化操作较复杂，导致设计及后期维护复杂；实际应用中，可以采取上述两种模型的混合体：如：中间层使用雪花结构以降低数据冗余度，数据集市部分采用星型以方便数据提取及和分析。
有时候规范化和效率是一组矛盾。一般我们会采取牺牲空间（规范化）来换取好的性能，把尽可能多的维度信息存在一张“大表”里面是最快的。通常会视情况而定，采取折中的策略。
星型有时会造成数据大量冗余，并且很有可能将事实表变的及其臃肿（上百万条数据×上百个维度）。
每次遇到需要更新维度成员的情况时，都必须连事实表也同时更新。
而雪花型，有时只需要更新雪花维度中的一层即可，无需更改庞大的事实表。
具体问题具体分析，如时间维度，年，季就没必要做雪花，而涉及到产品和产品的分类，如果分类信息也是我们需要分析的信息，那么，我肯定是建关于分类的查找表，也就是采用雪花模式
雪花型结构是一种正规化结构，他取除了数据仓库中的冗余数据。比如有一张销售事实表，然后有一张产品维度表与之相连，然后有一张产品类别维度表与产品维度表连。这种结构就是雪花型结构。雪花型结构取除了数据冗余，所以有些统计就需要做连接才能产生，所以效率不一定有星型架构高。正规化也是一种比较复杂的过程，相应数据库结构设计、数据的ETL、以及后期的维护都要复杂一些。
星型架构是一种非正规化的结构，多维数据集中的每一个维度都与事实表相连接，不存在渐变维度，所以数据有一定的冗余，正因为数据的冗余所以很多统计查询不需要做外部的连接所以一般情况下效率比雪花型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。
虽然两种结构有一定差别，我个人认为没有好坏之分，最主要的还是看项目的需求，看业务逻辑。
G. 请问数据仓库都用什么建立
数据仓库是为了管理数据，主要是思想。
具体实施的工具就是为了解决问题而选取了
比如异构/不同源数据的数据抽取问题，要用到etl，可能会用工具 或者自己写程序，看情况而定‘
数据仓库的模型建设，要用到erwin等建模工具；
数据的存放一般是借助关系数据库来实现，那么会用到oracle之类。不过现在已经开始慢慢摒弃传统关系数据库了，借助一些No sql平台，比如hadoop上的hive之类。
不过无论用什么工具，一定要记住，数据仓库的思想是不变的，就是管理数据、把数据的价值通过有效地管理而展现出来，不经管理的数据就是一堆没有提炼的金矿，看着很值钱，直接狗屁用没有。
H. 数据仓库的数据模型
有别于一般联机交易处理(OLTP)系统，数据模型设计是一个数据仓库设计的地基，当前两大主流理论分别为采用正规方式(normalized approach)或多维方式(dimensional approach)进行数据模型设计。 数据模型可以分为逻辑与实体数据模型。逻辑数据模型陈述业务相关数据的关系，基本上是一种与数据库无关的结构设计，通常均会采用正规方式设计，主要精神是从企业业务领域的角度及高度订出subject area model，再逐步向下深入到entities、attributes，在设计时不会考虑未来采用的数据库管理系统，也不需考虑分析性能问题。而实体数据模型则与数据库管理系统有关，是建置在该系统上的数据架构，故设计时需考虑数据类型(data type)、空间及性能相关的议题。 实体数据模型设计，则较多有采用正规方式或多维方式的讨论，但从实务上来说，不执着于理论，能与业务需要有最好的搭配，才是企业在建置数据仓库时的正确考量。
数据仓库的建制不仅是资讯工具技术面的运用，在规划和执行方面更需对产业知识、行销管理、市场定位、策略规划等相关业务有深入的了解，才能真正发挥数据仓库以及后续分析工具的价值，提升组织竞争力。