很多人对这两个名词有一定的概念，然而也就停留在了概念的阶段。网络上对这两个名词的区别其实讲的很多，但我觉得都不好理解。这里我们不涉及技术，只讲故事，非常适合非相关专业的读者朋友阅读。
首先我们来讲一下你可能觉得不需要讲的东西，那就是数据库，不讲数据库，也无法讲数据仓库。什么是数据库？
有的读者朋友们可能会说：卧槽？！数据库你还要讲？没错（手动滑稽，麻蛋简书你什么时候可以出一套表情包）
学过计算机发展史的朋友们都知道，我们现在所有的计算机都是基于冯诺依曼体系结构的。冯诺依曼这家伙其实不是什么计算机学家，这货是个数学家，但他之所以被称之为”计算机之父“，就是因为他第一个明确了数据这个抽象的东西在计算机内部的组织形式，也就是我们现在知道的二进制。现在的很多小学生因为接触计算机很早，很多也都知道，数据在计算机内部都是0和1两种形态存在。
至于为什么计算机采用二进制而不是用我们生活中熟悉的十进制，大家有兴趣可以自行百度。
数据库顾名思义就是用来存放数据库的（很显然数据仓库自然也是存放数据的），大约在20世纪60年代时候数据库已经在计算机中应用，但这个阶段的数据库结构主要是网状或者层级的（感兴趣的读者们可以翻阅计算机发展史），这些结构非常复杂多变。我们知道计算机上层都是软件，软件包括数据和程序，而此时的数据库在这方面区分的很不好，所以那个年代软件中的数据和程序之间你中有我，我中有你，彼此具备非常强的依赖性。
尽管计算机科学家一直在努力研究数据在计算机中的最佳组织形式，但直到1970年（人类第一台计算机出现在1946年，就是我们中学历史书上看得不想再看的那张在美国费城占据了整个房间的那台庞大的电子管计算机），IBM的研究员埃德加 科德发明了关系型数据库（这就是我们现在通常说的数据库），才真正彻底把软件中的数据和程序分开来，可能他自己也没想到关系型数据库的诞生成为了软件发展历史上一个跨越的里程碑。（这里要强调一下，层次型数据库和网状数据库并没有就此消失，在特定的应用场景下依然具有不可替代的使用性）科德后来也拿到了1981年的图灵奖。
那么什么是关系型数据库呢？关系数据库本质上是一个二元关系，说的简单一些，就是一个二维表格，对普通人来说，最简单的理解就是一个Excel表格。这种数据库类型，具有结构化程度高，独立性强，冗余度低等等优点，一下子就促进了计算机的发展。
这里不妨说个题外话，为什么后来Oracle成为了数据库的第一巨头，IBM落寞了呢？看过吴军博士《浪潮之巅》的朋友们应该知道，IBM在巅峰的时候，确实在计算机等IT领域一手遮天，但是很遗憾，组织一旦庞大，内部之间对技术或者产品的路线就开始分歧，而且官僚气息越来越严重，以及包括IBM重视理论对产品较为保守等等各种原因，使得IBM不仅在数据库，也在其他很多领域错失了一系列巨大的黄金机会，感兴趣的同学可以阅读《浪潮之巅》并了解一下Oracle的发展历史。
好，打住，关于数据库，知道这些就足够了，其他东西讲多了就没意义了，也不容易接受。看到这里，我觉得读者朋友们基本上都能看的很明白。
现在我们可以来讲数据仓库了。
从哲学上讲，任何事物都是为了解决下一个问题而诞生的。所以从历史的角度来看，数据仓库就是为了解决数据库不能解决的问题而提出的。（我们甚至可以意淫一下，以后保不齐还会冒出一个“数据工厂”或者“数据库存”等等这样的概念去解决数据仓库不能解决的问题→_→）
那么数据库无法解决什么样的问题呢？这个我们得先说说什么是OLAP和OLTP（喂，你们不要一看到英文概念就关闭页面啊，我会讲的很简单又清楚的=。=)
OLTP（On-Line Transaction Processing 联机事务处理） 。对有相关专业知识的读者们，说简单一些，就是数据库的增删查改。举个例子，你到银行，去取一笔钱出来，或者转账，或者只是想查一下你还有多少存款，这些都是面向“事务”类型的操作。这样的操作有几个显著的特点，首先要求速度很快，基本上都是高可靠的在线操作（比如银行），还有这些操作涉及的数据内容不会特别大（否则速度也就相应的降低），最后，“事务”型的操作往往都要求是精准操作，比如你去银行取款，必须要求一个具体的数字，你是不可能对着柜台员工说我大概想取400到500快之间吧，那样人家会一脸懵逼。
很简单吧，东西方技术的互相交融，造成一些名称的英文翻译容易让人知难而退，殊不知，技术的真理往往都是非常简单清晰的。下面我们来看OLAP。
OLAP（On-Line Analytical Processing 联机分析处理）。这个东西又是上面发明关系型数据库的科德发明的。OLAP略有复杂，但这里我举一个简单的例子，大家就很容易理解了。
比如说，沃尔玛超市的数据库里有很多张表格，记录着各个商品的交易记录。超市里销售一种运动饮料，我们不妨称之为红牛。数据库钟有一张表A，记录了红牛在一年的各个月份的销售额；还有一张表B，记录了红牛每个月在美国各个州的销售额：；甚至还有一张表C，记录了这家饮料公司在每个州对红牛饮料的宣传资金投入；甚至后来沃尔玛又从国家气象局拿到了美国各个州的一年365天每天的天气表。
好，最后问题来了，请根据以上数据分析红牛在宣传资金不超过三百万的情况下，什么季节，什么天气，美国哪个州最好卖？
凭借我们的经验，可能会得出，夏季的晴天，在美国的佛罗里达，最好卖，而且宣传资金投入越高销售额应该也会高。可能这样的结论是正确的，但决策者想要看到的是确凿的数据结论，而不是“可能”这样的字眼。
科学是不相信直觉的，如果我们人工进行手动分析，会发现这个要考虑的维度实在太多了，根本无法下手，何况这才四五个维度，要是更多了怎么办？OLAP就是为了解决这样的问题诞生的，但糟糕的是，传统数据库是无法满足OLAP所需要的数据信息的。
现在我们可以回过头来看数据仓库了。
数据库的大规模应用，使得信息行业的数据爆炸式的增长，为了研究数据之间的关系，挖掘数据隐藏的价值，人们越来越多的需要使用OLAP来为决策者进行分析，探究一些深层次的关系和信息。但很显然，不同的数据库之间根本做不到数据共享，就算同一家数据库公司，数据库之间的集成也存在非常大的挑战（最主要的问题是庞大的数据如何有效合并、存储）。
1988年，为解决企业的数据集成问题，IBM（卧槽，又是IBM）的两位研究员（Barry Devlin和Paul Murphy）创造性地提出了一个新的术语：数据仓库（Data Warehouse）。
看到这里读者朋友们可能要问了，然后呢？然后......然后就没然后了。就在这个创世纪的术语诞生了之后，IBM就哑火了，只是将这个名词作为市场宣传的花哨概念，并没有在技术领域有什么实质性的研究和突破（可悲我大IBM=。=）。
然而，尽管IBM不为所动，其他企业却在加紧对数据仓库的研究和开发，大家都想在这个领域寻找到第一桶金。终于，到了1992年，后来被誉为“数据仓库之父”的比尔 恩门（Bill Inmon）给出了数据仓库的定义，二十多年后的今天他的定义依然没有被时代淘汰。我们来看看他是怎么定义的：“数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理中的决策制定。”
我们可以不用管这个定义，简单的理解，其实就是我们为了进行OLAP，把分布在各个散落独立的数据库孤岛整合在了一个数据结构里面，称之为数据仓库。这个数据仓库在技术上是怎么建立的读者朋友们并不需要关心，但是我们要知道，原来各个数据孤岛中的数据，可能会在物理位置（比如沃尔玛在各个州可能都有自己的数据中心）、存储格式（比如月份是数值类型，但但天气可能是字符类型）、商业平台（不同数据库可能用的是Oracle数据库，有的是微软SQL Server数据库）、编写的语言（Java或者Scale等）等等各个方面完全不同，数据仓库要做的工作就是将他们按照所需要的格式提取出来，再进行必要的转换（统一数据格式）、清洗（去掉无效或者不需要的数据）等，最后装载进数据仓库（我们所说的ETL工具就是用来干这个的）。这样，拿我们上面红牛的例子来说，所有的信息就统一放在了数据仓库中了。
自从数据仓库出现之后，信息产业就开始从以关系型数据库为基础的运营式系统慢慢向决策支持系统发展。这个决策支持系统，其实就是我们现在说的商务智能（Business Intelligence）。可以这么说，数据仓库为OLAP解决了数据来源问题，数据仓库和OLAP互相促进发展，进一步驱动了商务智能的成熟，但真正将商务智能赋予“智能”的，正是我们现在热谈的下一代技术：数据挖掘。
讲完，收工。
