IT的商业应用需要数据。它们产生了数据,它们也要使用数据。大多数机构所拥有的数据要比他们能够有效管理的多,而且,当用户需要什么东西的时候,它们似乎从来都不会在一起或者是以正确的格式在一起。
IT的商业应用需要数据。它们产生了数据,它们也要使用数据。大多数机构所拥有的数据要比他们能够有效管理的多,而且,当用户需要什么东西的时候,它们似乎从来都不会在一起或者是以正确的格式在一起。
在过去的十年里,IT开发机构已经在试图将这样的应用数据同商业用户拉得更进。这种潮流允许用户能够访问更新的信息,而且,在很多情况下,用户不需要通过IT机构就能够(直接)进行查询或者得到报告。但是,你需要决定同这些数据的保存有关的一些基础结构,以及如何根据不同的目的对它们进行优化。
交易数据仍然必须受到保护
交易数据是应用程序需要操作的有效数据。例如,应收款系统(accounts receivable system)全天都在由应收款用户进行更新。存货量也正在随着订单的收到和发货而更新。销售系统在一天中会因为订单的收到而更新。这些生产应用所需要的所有数据就是交易数据。
在把数据同用户拉得更近的努力中,IT机构仍然必须保护这些数据。允许商业用户访问更多的数据不能够牺牲信息的完整性,或者对生产应用产生负面冲击。下面的案例研究提出了一种方式,它将有效的生产数据同你的商业用户拉得更近。这个解决方案允许大多数用户以“即时(near-time)”的速度访问数据,同时仍然能够允许少部分用户以“实时的”速度直接访问数据。
案例研究
在我工作的上一家公司里,我们希望自己的商业用户能够访问到我们所有的商业应用数据。这包括财务数据、用户数据、发放许可证的收入、教育供给等等。我们为这些最终用户提供了可用的报告工具,这样他们就可以编写自己的查询和报告。所有的数据在当时都是可以被访问的,并被用在交易系统中,其中有一些在白天在线运行,而有一些只在夜间运行。问题是如何为用户访问这些数据提供最好的方法。
一种选择是允许用户从产品应用程序里直接访问这些数据。但这被否定了,有两个原因。第一,交易数据保存的方式是为计算机的应用程序而优化的。而这不是商业用户访问信息最直观的方法。例如,我们的一个应用程序,从外面看来,是将数据保存在两个或者三个数据库表格里的。但是,更进一步检查,却发现数据事实上被分割放进了几十个表格里,所有的数据都利用一组主关键字和外来关键字连接在一起。这种数据库结构对于应用程序来说可能是完美的。但是,如果我们就把这些表格扔给用户,他们绝对不可能理解这些表格里的数据和关系。如果他们可以编写能够访问数据的报告,那么也没有办法知道他们是否得到了他们所期望的报告结果。
不使用交易数据的第二个理由是一些与(资源)争用有关的问题。商业用户可以遍布美国各地。我们不希望他们在生产系统繁忙运行的时候访问交易数据。生成报告非常耗资源,尤其在访问多个数据库的时候。我们感觉到,如果多个用户正在利用同一个数据库同时生成报告,那么我们就正在冒风险显著地把生产处理过程的速度拖下来。如果人们使用应用程序完成其任务的话,这肯定是不可接受的。