在过去的十年里，IT开发机构已经在试图将这样的应用数据同商业用户拉得更进。这种潮流允许用户能够访问更新的信息，而且，在很多情况下，用户不需要通过IT机构就能够（直接）进行查询或者得到报告。但是，你需要决定同这些数据的保存有关的一些基础结构，以及如何根据不同的目的对它们进行优化。

交易数据仍然必须受到保护

交易数据是应用程序需要操作的有效数据。例如，应收款系统（accounts receivable system）全天都在由应收款用户进行更新。存货量也正在随着订单的收到和发货而更新。销售系统在一天中会因为订单的收到而更新。这些生产应用所需要的所有数据就是交易数据。

在把数据同用户拉得更近的努力中，IT机构仍然必须保护这些数据。允许商业用户访问更多的数据不能够牺牲信息的完整性，或者对生产应用产生负面冲击。下面的案例研究提出了一种方式，它将有效的生产数据同你的商业用户拉得更近。这个解决方案允许大多数用户以“即时（near-time）”的速度访问数据，同时仍然能够允许少部分用户以“实时的”速度直接访问数据。

案例研究

在我工作的上一家公司里，我们希望自己的商业用户能够访问到我们所有的商业应用数据。这包括财务数据、用户数据、发放许可证的收入、教育供给等等。我们为这些最终用户提供了可用的报告工具，这样他们就可以编写自己的查询和报告。所有的数据在当时都是可以被访问的，并被用在交易系统中，其中有一些在白天在线运行，而有一些只在夜间运行。问题是如何为用户访问这些数据提供最好的方法。

一种选择是允许用户从产品应用程序里直接访问这些数据。但这被否定了，有两个原因。第一，交易数据保存的方式是为计算机的应用程序而优化的。而这不是商业用户访问信息最直观的方法。例如，我们的一个应用程序，从外面看来，是将数据保存在两个或者三个数据库表格里的。但是，更进一步检查，却发现数据事实上被分割放进了几十个表格里，所有的数据都利用一组主关键字和外来关键字连接在一起。这种数据库结构对于应用程序来说可能是完美的。但是，如果我们就把这些表格扔给用户，他们绝对不可能理解这些表格里的数据和关系。如果他们可以编写能够访问数据的报告，那么也没有办法知道他们是否得到了他们所期望的报告结果。

不使用交易数据的第二个理由是一些与（资源）争用有关的问题。商业用户可以遍布美国各地。我们不希望他们在生产系统繁忙运行的时候访问交易数据。生成报告非常耗资源，尤其在访问多个数据库的时候。我们感觉到，如果多个用户正在利用同一个数据库同时生成报告，那么我们就正在冒风险显著地把生产处理过程的速度拖下来。如果人们使用应用程序完成其任务的话，这肯定是不可接受的。

在不需要即时访问的时候使用报告数据中心

我们很快就意识到，我们不能够让商业用户直接从交易系统访问所有的数据。然而，我要看一种使用数据中心的方法。由于商业用户所需要的大多数相关数据都是和客户有关的，所有我们提出创建一个客户数据中心（Customer Data mart）。我们之所以把它叫做数据中心，而不是数据仓（data warehouse），是因为我们的数据没有占用很大的空间，而且我们没有使用典型的数据仓技术或者工具。数据中心是一个更小的实体，它通常创建自数据仓，用来生成报告和进行查询。我们虽然没有从一个典型的数据仓开始，但是最终的结果是，我们仍然允许最终用户生成报告和进行查询。

每天晚上，我们都会将相关的交易数据库表格备份放入客户数据中心。客户数据中心的结构经过优化，专门用于轻轻松松地生成报告，而且它是同生产系统脱离的。这就允许我们向商业用户提供他们所感兴趣的、用于报告的所有数据，而它们的格式是一种从人的角度来讲更易理解的格式。

创建冗余数据存储器的一些考虑

这种方法有两个考虑。第一个是，你必须创建冗余的数据存储（redundant data store）。换句话说，生产交易表格里的相同数据也会被放在用户数据中心里。为什么要考虑冗余系统？就我们所操作的表格的大小而言，它真的和额外的磁盘空间没有关系，因为现在存储设备的价格已经很低了。考虑它的原因是为了保持多个数据存储的同步。

例如，如果我们的交易系统显示上个月我们的收入是二千万美元，我们也需要在用户数据中心里反映同样的数字。如果我们的数据存储的一个副本由于某种原因产生了不同的结果，那么支持人员就需要花很多时间来弄清楚产生差异的原因。另一个考虑是，如果交易数据的结构发生了改变，你就必须更改数据中心的结构。一旦数据结构发生变化，这就会花费两倍的工夫（来保持数据的一致）。

对于第一个保持数据同步冗余的问题，我们可以每天晚上重新加载最近版本的交易数据。换句话说，我们今天可以加载今年的销售数据，然后明天可以加载今年销售数据的一个全新版本，后天晚上再加载一个新版本。这种方法要比处理添加／更改／删除等过程更加轻松明了。但是，由于我们的数据库表格足够小，所以这是一种可行的解决方案。如果你的数据存储太大，这就不总是一个有效的选择了。

创建单独用户数据中心的第二个考虑是及时性。很显然，如果你每天晚上才更新你的报告数据，那么数据（的更新）就有一天的落后。这个一个不太大的考虑，事实上在我的单位每天晚上更新已经足够了。但是，如果你需要报告数据能够保持实时更新（或者很接近于实时），那么你就需要一天多次更新数据了。

有些商业用户仍然需要实时的访问

这个解决方案最后一部分涉及允许某些用户真正地访问有效的生产数据。例如，我们的财务分析师每个月在进行出清存货处理（closeout process）的时候需要进行实时的访问。他们需要为管理层创建财务报告，并要保证所有的东西都被正确地抛售和平衡了。有的时候，这需要在白天多次进行系统更新以及手动的输入。他们需要能够运行系统更新，然后立即查询数据。如果数据不是正确的，他们可以先进行其他的更新，然后再回来纠正，并让一切正常运行。这些人都被授权实时地访问生产数据。对于他们来说，能够访问昨天晚上的数据还不够好。但是，这种层次的访问被限制到最小的程度，因此不太会对生产应用程序的性能产生负面的影响。

总结

用户需要对你生产数据进行实时或者接近实时的访问。他们还希望自己来掌握数据，而不需要每次自定义报告的时候都跑到IT部门去。但是，你的IT人员担心也是合理的，他们需要知道这些实时的查询会对你生产商业应用程序的顺利运行产生怎样的影响。

本专栏的目的就是要说明这些合理的商业需求如何能够用合适的方法来满足：

1. 为报告的生成和查询的进行建立单独的数据存储。根据生成报告的需要以及用户数量的差异，你需要多个这样的数据中心，它们专门为特定的报告类型和查询优化过。这些数据中心能够迅速地被创建，而不需要耗钱耗精力的、复杂的全功能数据仓。这些数据是“接近实时的”，这就意味着对它们的访问很接近于实时，并且离这些最终用户对信息的需要十分接近了。
2. 只允许很少量的最终用户对生产数据进行受控的直接访问。这就为更少的一些人提供了真正的实时访问，而将潜在的争用问题减到最小（但是无法消除这一问题）。

这种方法需要你复制数据，这在二十年前是个问题，而现在很少成问题了。但是现在，出于生成报告和分析的目的而将数据隔离在单独的数据存储里，这一点的意义更大——利用实现冗余的（更少）费用来换取商业用户对数据直接访问的更高价值。