数据仓库和多维数据库的区别在哪里

简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。

数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。

数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。

数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。

单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。

显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。

“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。

“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的当然，向数据仓库添加数据是允许的。

数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。

1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。

2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。

3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。

MySQL分库分表,一般只能按照一个维度进行查询.

以订单表为例, 按照用户ID mod 64 分成 64个数据库.

按照用户的维度查询很快,因为最终的查询落在一台服务器上.

但是如果按照商户的维度查询,则代价非常高.

需要查询全部64台服务器.

在分页的情况下,更加恶化.

比如某个商户查询第10页的数据(按照订单的创建时间).需要在每台数据库服务器上查询前100条数据,程序收到 64*100 条数据,然后按照订单的创建时间排序,截取排名90-100号的10条记录返回,然后抛弃其余的6390条记录.如果查询的是第100页,第1000页,则对数据库IO,网络,中间件CPU,都是不小的压力.

分库分表之后,为了应对多维度查询,很多情况下会引入冗余.

比如两个集群,一个按照用户ID分库分表,另外一个按照商户ID分库分表.

这样多维度查询的时候,各查各的.

但是有几个问题,一样不好解决.

比如,

每扩展一个维度,就需要引入一个集群.

集群间的数据,如何保证一致性.

冗余占用大量磁盘空间.

从朋友那里看到的订单表结构.做冗余会占用大量的磁盘空间.

create table TS_ORDER

(

ORDER_IDNUMBER(8) not null,

SN VARCHAR2(50),

MEMBER_ID NUMBER(8),

STATUS NUMBER(2),

PAY_STATUS NUMBER(2),

SHIP_STATUS NUMBER(2),

SHIPPING_ID NUMBER(8),

SHIPPING_TYPE VARCHAR2(255),

SHIPPING_AREA VARCHAR2(255),

PAYMENT_ID NUMBER(8),

PAYMENT_NAMEVARCHAR2(50),

PAYMENT_TYPEVARCHAR2(50),

一、用户可以根据自己的需要添加合适的纬度 由于企业个性的考虑，在做BI系统开发时，设计人员很难考虑到企业所需要的分析纬度。

 二、多维度分析时所采用的数据应该一致 在对数据进行多维度分析时，为了提高分析结果的准确性，最好其采用的数据是相同的。

 三、对于一些特殊事项的考虑 在对数据进行多纬度分析时，还需要考虑一些比较特殊的事项。具体的来说，主要是如下几个方面的内容。 一是分析的纬度是空值时该如何处理?如现在需要根据区域来进行汇总分析。可是在销售原始数据时，有一些纪录没有反应区域相关的信息。那么此时在对数据进行汇总分析时，对于这些纬度为空的值该如何进行考虑呢? 根据笔者的了解，不同的BI系统在这方面有不同的考虑。如上图所示，有些BI系统会在设置窗口中，让用户选择是否将空的值考虑进去。如果不考虑的是，则在数据汇总分析时会加入一个过滤条件，将空值的记录过滤掉。如果考虑的话，则会虚拟一个“其他”或者类似的纬度来汇总这些空值的记录。还有一些系统则拒绝采用含有空值的数据作为纬度。 如用户在自定义添加纬度或者在数据查询时，会先去判断用户所指定的纬度字段是否含有空值。如果含有空值的话，则系统就会报错，或者根本不允许用户指定这个字段作为数据分析的纬度。笔者认为这两种方法都是可行的。主要就是让用户知道有这么一回事。在数据分析时，需要考虑到空值对分析结果的影响。 二是数据结果的显示。在数据分析时，即可以在同一个结果中采用多个纬度。如现在用户需要知道每个客户不同年份的销售情况。此时采用的就是客户与年份两个纬度信息。此时主要需要注意的是纬度之间的顺序关系。即年份在前还是客户在前。这个顺序关系，虽然对最后的结果没有本质的影响，但是其前台的显示内容就有本质的变化。 在同一个显示图例中利用多个纬度时，其关键就是这个顺序的设计。在实际工作中，如果用户不知道该采用什么顺序时，笔者的绝招是根据不同的顺序像用户各自展示一遍。让客户看到最终的结果之后，再来进行选择。为了显示结果的一致性，一般情况下不建议用户可以在一个图例中自由调整纬度的顺序。也就是说，图例设计好之后，可以添加或者删除纬度，但是已有纬度的顺序一般不可以进行更改。否则的话，可能会引起用户感知的混乱。如果一定要进行更改，那么最好考虑采用不同的图例。 如现在需要有两个需要。用户即要知道每个客户每一年的销售增长情况。也需要知道每个客户每一年具体产品的购买记录。这两个需求虽然采用的基础数据相同，采用的纬度也类似，只是第二个需求多了一个纬度而已。但是显示的结果会有很大的不同。第一个需求的汇总度更加的高。 在实际工作中，笔者是建议将其放置在两个不同的图例中显示。因为从用户的角度看，这么设计更加的方便与他们的使用 。 横看成岭侧成峰。在BI系统的开发与部署中，这个观念无论是实施顾问还是企业用户，都要树立起来。在分析相关业务数据时，不能够片面的看。而需要养成多个角度看问题的习惯。

---