本月我努力学习数据仓库，致力于更好地为应急主题数据仓库与应急智能技术学习研究服务。在学习过程中，边学边遇到问题，边解决问题。下面就几个感悟较深的问题拙笔展开。

事务型数据处理中需要作数据库设计，而在分析型数据处理中则需作数据仓库设计，这两者在原理上是一致的。因此，数据库设计中的很多设计思想与方法都可在数据仓库中得到应用。但是由于事务型与分析型的数据处理的不一致，因此两者在设计中的很多方面也存在着差别。对数据库和数据仓库作比较：

数据仓库的设计过程中遵循的面向主题原则、数据驱动原则和原型法设计原则是依据其特点的，即面向主题的、集成的、不可更新的、随时间的变化而不断变化的，他们决定了数据仓库的系统设计不能采用同开发传统的OLTP数据库一样的设计方法。

数据仓库的设计是一个逐步求精的过程，用户的需求是在设计过程中不断细化明确的。同时，数据仓库系统的开发也是一个经过不断循环、反馈而使系统不断增长与完善的过程。在数据仓库开发的整个过程中，自始至终要求决策人员和开发者的共同参与和密切合作，不做或尽量少做无效工作或重复工作。

初学数据仓库是我以为数据仓库就是基于多维数据模型构建，用于OLAP的数据平台，通过深入学习，了解到数据仓库的应用可能远不止这些。但不得不承认多维数据模型是数据仓库的一大特点，也是数据仓库应用和实现的一个重要的方面，通过在数据的组织和存储上的优化，使其更适用于分析型的数据查询和获取。

通过多维数据模型的数据展示、查询和获取就是其作用的展现，但其真的作用的实现在于，通过数据仓库可以根据不同的数据需求建立起各类多维模型，并组成数据集市开放给不同的用户群体使用，也就是根据需求定制的各类数据商品摆放在数据集市中供不同的数据消费者进行采购。

深入学习，首先了解两个概念：事实表和维表。事实表是用来记录具体事件的，包含了每个事件的具体要素，以及具体发生的事情；维表则是对事实表中事件的要素的描述信息。比如一个事件会包含时间、地点、人物、事件，事实表记录了整个事件的信息，但对时间、地点和人物等要素只记录了一些关键标记，比如事件的主角叫“Michael”，那么Michael到底“长什么样”，就需要到相应的维表里面去查询“Michael”的具体描述信息了。基于事实表和维表就可以构建出多种多维模型，主要是星形模型和雪花模型。

1.星型架构：

2.雪花型架构：

星型模型和雪花模型，星型模型维表一般都很小,甚至可以放在高速缓存中，模式比较直观，不用过多考虑正规化因素，设计维护较为简单，但是会产生冗余数据。雪花模型数据冗余少，在一定程度上减少了存储空间;规范化的结构更容易更新和维护，但是雪花模式也存在不少缺点:雪花模式比较复杂，用户不容易理解而且设计及后期维护复杂;浏览内容相对困难;额外的连接将使查询性能下降。

在网上看到两个路人的发表，比较好：

路人甲说：在实际数据仓库应用中，可以采取上述两种模型的混合体：如：中间层使用雪花结构以降低数据冗余度，数据集市部分采用星型以方便数据提取及和分析。

路人乙说：在数据仓库中，通常不推荐“雪花化”。因为在数据仓库中，查询性能相对OLTP系统来说更加被重视，而雪花模式会降低数据仓库系统的性能。

最后，特别要提的是一个建设数据库的外键（Foreign Key）使用问题。

一个形象的例子使我从玄乎的概念中走出来：主表、从表和外键的定义：我把我的笔记本借给你用，可以把“我”当作是主表、“笔记本”当作外键、“你”当作从表，就是说“你”在使用（引用）“我”的“笔记本”；外键的作用就是：现在你想把我的笔记本卖了扔了送人（增加更新删除等），得看看我允许不允许，我想搬家走人，你不把笔记本还给我，我不能搬；建键原则：借之前首先咱得说好了，我只有这么一台笔记本，你也最好是也只借了我这台笔记本，避免你也借了别人的笔记本，不知道哪个是我的了。事件触发：我说你赶紧把笔记本还给我，你可以选择还给我，可以选择不搭理我等。总而言之，由于这笔记本，“你”和“我”关联起来，这台笔记本怎么样，不能一个人说了算。

随后，“图说东溪”数据库建设表与表之间有没有必要使用外键关联的问题扑面而来，关于这个问题，在网上看到几个路人的发表，比较有参考价值：

路人甲问：在做项目的时候，经常要建很多的表，有时候就要用到外键关联，用的时候就方便，但是有时候要改动表就很麻烦，因为有了外键就不可以随便动表了。到底是建外键好呢，还是不建好？

路人乙说：我觉得要保证数据的完整性,有引用关系的表与表之间建物理外键是非常重要的，而且一旦建了外键，以后维护系统时对这些表之间的关系也会比较清楚。可我们公司做的系统都不建外键，我提了多次都不管用,一个"建了外键不便于导数据"的理由就把我给堵回去了。我该如何说服他们使用外键？

路人丙说：当然是在不需要建的时候最好不要外键咯，用的好的话省事，用的不好的话 呵呵，整自己！做项目时用户的需求是不断的，因此表的改动也是挺频繁的，只要自己将整个业务的逻辑思维理清了，将关联到多张表的操作放在一个事务中去处理，效率还更高些。如果必须要建外键，那就没有办法了！ 话说，建外键后，改动数据确实挺麻烦的！
    路人丁说：我也觉得不引入外键好，虽然会增加额外的程序来检测外键约束，但一旦加了外键不单单是导入数据麻烦，特别是项目大了，牵一发而动全身会很难受。而且也会给测试带来很多不便，我以前做的项目都不用外键约束的。

通过学习，我得出总结：

1.要看看具体业务需求。不是任何情况都要用外键的。用了外键可以保证数据的一致性、完整性， 维护系统时有好处，但同时增加了数据库的附和，增加了项目过程中导入、改动数据的麻烦。
     2.在大型系统中（性能要求不高，安全要求高），使用外键；在大型系统中（性能要求高，安全自己控制），不用外键；小系统随便，最好用外键。
     3.用外键要适当，不能过分追求。
     4.不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后个个应用通过这个层来访问数据库。