首先提到数据仓库，有几个重要概念，是大家必须了解的，如果不了解，几乎无法进行后续的学习。
首先说下OLTP系统，这里我们先拿出官方的概念看一下，On-Line Transaction Processing联机事务处理过程(OLTP)，也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。
针对以上概念，我们先画下重点： 面向交易, 前台接受数据，传送到计算中心进行处理，快速响应 。现在我们通过一个所有人可以理解的案例，我们这几个关键重点串联起来，让大家体会下这是怎么一个过程。
首先，我们模拟出一个我们打电话的过程来说明事务到底是什么，一个人拨打电话，然后信号通过基站->基站记录了该条话单信息->将话单信息入到产生系统数据库，整个这个过程我们称之为一个事务或者面向交易。面向交易可能换个例子大家更好体会一点，针对超市系统，我们付款结账刷二维码->账单录入->数据库INSERT一条POS销售流水等一系列操作瞬间完成，是不是有更好的体会了呢，说白了面向事务就是为了记录流水，记录发生了什么，至于发生这件事导致后续影响，蝴蝶效应等一律不管，只负责将发生每个细节一条不漏地记录下来。
上述整个过程瞬间完成，体现了上面概念中的“快速响应”，或者我们再用一个更容易理解的场景，我们去银行查询我们近期所有记录，营业厅员是不是输入卡号点击查询，瞬间所有结果出来了，这是快速响应的典型场景，上图中话单记录快速录入 ORALCE数据库（通讯行业大部分事务系统叫BOSS，数据库一般ORACLE居多），这个过程我们也可以理解为概念中的“送到计算中心进行处理”。好的，针对上述概念我们基本都了解了，还差一个关键点前台接收用户的数据，刚好这个例子中这点体现的不是很明显，OK 我们换一个场景，我们去运营商营业厅或者银行提供办理业务或查询我们当前实时信息，营业员操作就是OLTP事务系统，当录入完我们身份信息后，点击录入时，一张电话卡或银行就生效了，同时也瞬间把我们用户信息录入了运营商的OLTP事务数据库中，那么这个系统界面录入操作，我们其实可以理解为“前台接收”，也有些地方还特别描述了OLTP的用户使用范围：面向操作人员和底层管理人员，但我们很清楚，任何概念的定义可能都是居于时代科技发展的限制，很多概念其实随着互联网时代的发展，发生了重大变化。目前很多运营商APP，银行APP等直接就能够访问在线事务系统，随时查询到当前实时余额，当前实时交易等，并且保证实时反馈。因为各种APP产品很多打通了我们与事务系统数据库的桥梁，因此在一些行业或产品里，OLTP事务系统访问者早已不仅仅是操作员工了，而拓展到了所用使用服务的客户本人。
那么通过上图大家其实可以容易的理解OLTP事务系统每天是一个什么囧态，就像7*24不停歇干活的工人，基本两个工作，拼命地响应数不清的客户端操作造成对数据库的数据新增和修改操作，同时又要满足数不清的客户端提交的查询响应，而且每个客户都必须实时响应，有延迟客户就不满意了。整个系统不能停歇，一刻都不可以。如果生产系统我们只停5分钟，仅仅只是把服务器重启下，歇五分钟又能怎么样呢，五分钟无法想象针对负责大到省份，小到城市的一个事务系统，有多少人电话无法拨打，有多少人无法转账，或者淘宝事务系统仅仅停一分钟，几千万交易失败，损失惨重的可怕程度超乎想象。
那么现在我们基于前面所理解的事务系统的囧样，进一步脑补，OLTP我们可以把他理解为是火车售票员，每天窗口排着一望无际的队伍，而且每个顾客出票要快，一个接着一个，正当这个售票员累的歇斯底里的时候，领导过来亲切说：是小王吧，能不能把近两个月每天售票数量帮忙统计下，做个曲线图，哦，还有明天我给领导汇报，需要把这半年通往北上广的所有顾客的来源地分析下，绘制个饼图，明天早上要，辛苦了哦。如果你是售票员想必心中一万句”草泥马“。事务系统数据库虽然是高性能的软件加机器，但再好软件也要受到CPU，内存，存储等硬件因素的限制，如果事务系统过多的参与分析工作，而且很多分析工作的结果都是需要对很长周期的数据通过复杂计算，才能得出最终结论的，当这些工作压在事务系统上，就会发生刚才提到了，做着分析的活，本职的重要工作结果干砸了，硬件资源都被分析的复杂查询占用了，导致日常事务处理所需的资源不够，数不清的人打不了电话，交不了话费，银行APP无法瞬间转账成功，查询不了账户余额，因此OLAP系统油然而生，与OLTP系统进行职责互补，一个保证日常事务进行，一个对事务的结果进行分析。
以上信息基于我个人对决策系统的理解，但我的理解也受到我的项目经验与认知等各方面的影响与局限，欢迎大家把我理解有误的地方积极提出，你们对我的质疑与反驳，才是我真正获取知识点来源与动力，我们一起学习一起进步，欢迎大家点赞，第一次写，文笔不好，多多见谅。
