OnDemand: 针对性能和用户满意度设计解决方案

内容：

简介

何为 OnDemand？

第一步：确定数据的检索方式

第二步：使数据检索有效率

第三步：针对性能和实用性设计文件夹

更多信息

关于作者

对本文的评价


订阅:

developerWorks 时事通讯




Eric Hann，Benjamin Boltz
Content Managers, OnDemand Support, IBM 公司
2003 年 7 月
本文是一篇 IBM Content Manager OnDemand 简介，文章给出了关于如何开发用户友好且高性能的 OnDemand 解决方案的各种情形。OnDemand 允许公司管理大量的书面输出，如报表、发票或综述。
您的公司已经决定购买 IBM Content Manager OnDemand （OnDemand）解决方案。他们让您负责此事。您去过 OnDemand 大学，参加过研讨班，而且还在OnDemand Web 支持网站上花了不少时间进行研究。
当您的上司问您：是否准备好设计性能优良且对用户友好的 OnDemand 解决方案时，您会怎么回答？
本文旨在帮助您肯定而自信地回答这一问题。目前有很多种可能的方法可以用来正确设计 OnDemand 解决方案，虽然我们不会予以逐一讨论，但我们将向您提供一种思想，您在创建您的解决方案时应该考虑这种思想。
大多数刚刚接触 OnDemand 的人都明白：OnDemand 存储文档，并允许您在 PC 上或使用 Web 浏览器检索这些文档。他们可能也明白个别组件的基本功能，或者也能够创建可以存储某一文档类型的应用程序。然而，大多数刚刚接触 OnDemand 的人，甚至一些使用 OnDemand 已有一段时间的人，都不清楚他们使用 OnDemand 解决方案的方式是否具备用户友好性，甚至也不清楚这一方案是否执行得很好。他们的最终用户已经逐步习惯了现状，没有人建议对这一解决方案进行改进。
为了帮助我们了解如何设计自己的 OnDemand 解决方案，首先需要理解何为 OnDemand。
OnDemand 允许最终用户在最短的时间内用最少的用户交互从存储中检索特定文档。为使解决方案性能优异且对用户友好，您必须考虑如何使用数据。
用非常简单的话来说，与本地图书馆要求您使用手工卡片目录系统相比，OnDemand 就是本地图书馆的电子版本。以下是本地图书馆与 OnDemand 之间的比较：
本地图书馆 OnDemand
书中的页文档的页
书中的章节存储对象中的文档
书存储对象
抽屉中的卡片数据库表中的行
卡片目录抽屉数据库表
卡片目录柜文件夹
在图书馆中，当您想研究某本书中的具体某一章时，您走向卡片目录柜，打开特定的卡片目录抽屉，找到那张告诉您那本书所在位置的特定卡片，然后去找到那本书，接下来翻到您想看的那一页。
使用 OnDemand 的 PC 或 Web 查看器，可以选择连接到某些数据库表的文件夹。接下来，输入您的搜索条件。当按 Enter 时，将获得符合搜索条件的文档列表，它是数据库表中某些特定行的副本。当选择其中一行时，也就检索了您感兴趣的文档。
回到我们的本地图书馆，我们知道自己想看什么书，但当我们走向卡片目录柜时，摆在我们面前有四个标签完全一样的卡片目录抽屉。为了搞清楚我们的书在哪儿，必须搜索全部四个抽屉。这样做显然比搜索一个卡片抽屉要慢得多。
OnDemand 也一样。如果搜索条件必须跨越多个应用程序组表，那么完成查询将花费更长时间。这意味着：系统执行查询将更费劲，而您的最终用户必须等待更长时间才能获取结果。
作为 OnDemand 解决方案设计人员，我们的任务是确定最有可能的应用程序设计方法，使我们不必在多个应用程序组表中进行搜索。多个应用程序组表可以来自同一个应用程序组，也可以来自多个应用程序组。
在开始设计应用程序之前，我们需要理解 OnDemand 应用程序的四个部分，它们对于我们的设计是最为重要的：
应用程序（Application）— OnDemand 应用程序用于建立索引。它从数据中获取向数据库中插入行所需的信息，以及正在装入的数据所需的资源。资源可以是徽标、特殊字体、页面定义、表单定义等任何东西。应用程序还包含用于查看和打印数据的信息。
应用程序组（Application Group）— 应用程序组是一个表构建器。它告诉我们在构建表时需要向表中添加哪些列。在装入期间，它确保应用程序向我们提供了正确的字段（列）信息，以便成功地插入行。
文件夹（Folder）— OnDemand 文件夹向最终用户提供了数据库的“视图”。它将向用户提供一种“填空（fill-in-the-blank）”方法来编写 SQL，它还确定将查询哪些数据库表。
存储（Storage）— 诸如 Tivoli? Storage Management (TSM) for UNIX? 或 Windows? 之类的高速缓存存储或光盘／磁带存储。我们的数据就驻留于此。当我们检索一篇文档时，我们将从高速缓存或长期存储介质那里获取该文档。
虽然在整个 OnDemand 解决方案中涉及的可变因素要比这多很多，但这四个却是成功的 OnDemand 解决方案设计最为关心的。
如果 OnDemand 仅仅用于单个报表类型，那么设计成功的解决方案将很容易。对于大多数客户而言，一般的 OnDemand 解决方案每天会有成千上万的人使用，而每个人会检索成百上千个数据类型。因此，为设计性能良好和对用户友好的解决方案，需要采取一种三步方法。
OnDemand 根据数据库中收集的信息查找文档。因此，了解人们的搜索方式很重要。当用户输入查询时，解决方案应该尽可能快地向用户返回有意义的信息。这意味着，我们将只搜索数量非常有限的数据库表，并且将只返回数量有限的与查询匹配的结果。最好的情况是，只有一个与查询匹配的结果。
当用户打开文件夹时，数据库查询已经启动了。选择文件夹限制了将要搜索的应用程序组表的数目。我们将在第三步中讨论这部分查询。
文件夹提供了一个允许最终用户查询数据库表的接口。文件夹字段对应于应用程序组字段，而应用程序组字段则对应于数据库索引字段和过滤器字段。应该可以使用一个能缩小表的搜索范围的分段字段。文件夹可能还有一个基于服务器的文本搜索字段。使用文本搜索字段是最慢的一种数据搜索方法，因为我们首先匹配其它查询字段，然后搜索匹配文档以找到匹配文本搜索的单词或短语。您应该避免为 OnDemand 用户提供文本搜索字段。您的最终用户会更喜欢查询字段的效率。
以下是请求查询时从高层次的角度看所发生的事情：
如果查询的一部分是分段字段，那么用它仅仅选择匹配这一条件的表。
如果索引字段是查询的一部分，那么搜索由分段搜索所选定表的索引以选择匹配的表行。
如果选择了过滤器字段，那么查看所选行，将行的范围缩小到只与过滤器字段匹配的行。
将匹配的查询行作为与搜索条件相符的列表形式返回给最终用户。
虽然将所有字段都变成索引字段很具吸引力，但也需要进行权衡。当创建一个索引时，您已采用已经存储在数据库表中的信息，您要使用数据库空间，将这些信息添加到单独的一个表中，您还要占用空间用于创建索引所涉及的开销。如果全部表字段都是索引，那么数据库将变得无谓的庞大，没有任何其它好处。
拥有太多的字段、索引或过滤器也不是一个好主意。告诉应用程序组为表创建的每一个数据库列都意味着数据库中需要额外的空间。应该只为需要搜索的内容创建字段（数据库列）。最起码应该提供一个索引字段。这个字段应该是数据中独一无二的值，如客户号（Customer Number）、社会保障号（Social Security Number）以及电话号码（Phone Number）等。它还应该是一个最终用户通常会对其进行搜索的字段。
这就是为什么必须了解客户打算如何搜索文档的原因了。如果客户将在一个字段上进行搜索，那么，显然只需要该字段。如果用户中 80% 的人将使用三个字段进行查询，而另外 20% 的人除此以外还需要其它字段，那么仅建立三个索引而让其它字段仅作为过滤器字段可能是最好的做法。
应用程序组表受它能够拥有的行的数目限制。您可以在应用程序组属性内设置这一项。缺省情况下，应用程序组可以有一千万行。一旦您已经存储了一千万行，那么 OnDemand 将关闭第一个表，然后打开第二个表。如果查询必须跨越两个表，那么这样做也只不过略微降低了一点性能。从一张表到两张表所引起的性能变化实在是微不足道，也不会引起人们注意。不过跨越 100 张表进行搜索则完全是另外一回事。与此同时，如果将行的上限设置得太高，那么性能也会打折扣，因为搜索那张表以匹配查询将会花费太多时间。
这就要引入分段字段。您应该总是指定一个分段值（通常是报表日期或结算日期）来改善性能。如果报表中没有分段值，那么总是可以在应用程序中指定装入日期来使用这一日期。这个值应该是按时间顺序排序的，以便提供最佳分段。分段字段将允许我们限制表（我们选择它们进行搜索）的数目。如果分段是“装入日期”而且我们每年对表填充四次，那么只要将月份和年份添加到我们的搜索中去，就可以将我们的搜索限定在单个表。一个月的数据最多会延续到第二张表中。不过，仅仅通过缩小要搜索的表的范围，我们就已成功地缩小了搜索范围。
既然我们理解了用户检索数据的方式，那么下一步就是确定它们检索数据的频率了。通常应该将检索过的数据一直放在高速缓存存储中，直到 90% 的用户不再使用它们为止。可以将不常检索的数据存储在长期存储介质中。高速缓存存储是将数据提供给最终用户的最快途径。一旦该数据不再具有高需求，那么就可以将数据从高速缓存中除去，其余用户仍然可以从长期存储介质中检索该数据。将光盘／磁带放入驱动器，然后让驱动器运行起来，接下来将数据提供给最终用户，这一过程所花的时间要比从高速缓存进行检索所花的时间长得多。如果有太多的人从长期存储介质中检索数据而驱动器目前又不可用于您的检索请求，那么情况要变得糟糕得多。
公司可能会在提供给您的高速缓存存储的容量方面有某些限制。不过，一般的经验法则是尽可能长地把数据保存在高速缓存中。一般而言，您不希望最终用户等待从长期存储介质中获得数据。
对于一个文件夹，可能会只有一个应用程序组被指派给它，也可能有几个应用程序组被指派给它。最好的情形是一个文件夹中只有一个应用程序组。然而，对于我们必须使用的数据而言，这种解决方案并非总是有用。
下面是一些对您会有帮助的基本 OnDemand 原则：
在下列情况下，数据对象应该使用同一个应用程序： 数据属于同一类型，
对于每个数据对象，字段信息都位于同一个地方，
您无需创建一个字段来标识报表或数据类型，以及
资源都是相同的。
在下列情况下，数据对象应该使用相同的应用程序组但使用不同的应用程序： 字段信息相同，但所在位置与第一个应用程序不同，
资源完全不同，
数据类型不同，以及
您可以简单地创建一个应用程序标识字段来确定数据来自哪个应用程序。
这意味着，只要编入索引的信息相同，那么 AFP?、JPG、LINE、PDF 和 TIFF 数据就可以驻留在同一个应用程序组中。
在设计应用程序组之前，应该考虑一下是否有可能向该组中装入多个应用程序。您能够对应用程序标识字段进行扩展以包括更多的应用程序。不过，如果不添加应用程序标识字段，以后您就不能回过头来添加该字段。
只要在每个应用程序组之内都有公共的搜索字段，应用程序组就可以驻留在同一个文件夹中。但是，如果最终用户对所有的应用程序组没有相同的访问权，而且您关心查询检索时间，或者期望每个应用程序组都有大量的表而分段搜索不会为您缩小表的搜索范围，那么您应该考虑为每个应用程序组分配一个文件夹。您可以使用用户许可权和组许可权来限制在文件夹中搜索的应用程序组的数目。
文件夹应该是第一个查询和第一个查询限制。最终用户应该只能看到包含应用程序组的文件夹，这些组带有他或她将要用到的信息。文件夹应该只包含应用程序组；或者非常类似的那部分应用程序组，如果将它们分开，会显得不合逻辑。用户应该只看到与其任务有关的文件夹。例如，库存文档不应该出现在工资文件夹中。您可以使用用户和组许可权来限制用户可以在文件夹列表中看到的文件夹数目。
需要努力实现下面几点：
应用程序 = 一到多个数据对象
应用程序组 = 一到多个应用程序
文件夹 = 一对一或少数几个应用程序组
这样，既然我们具备了基础知识，那么让我们研究一个并不复杂的方案并设计一个 OnDemand 解决方案。
公司希望将下面六个报表存储在 OnDemand 中：
资产负债表（Balance Sheet）— AFP 数据
销售详细报表（Sales Detail Report）— Line 数据
库存详细报表（Inventory Detail Report）— AFP 数据
交易详细报表（Transaction Detail Report）- Line 数据
损益表（Income Statement）— PDF
工资分类帐（Payroll Ledger）— AFP 数据
仅用上述信息，一个非常简单但差劲的设计如下所示：
为每个报表创建一个应用程序，为每个应用程序创建一个应用程序组。
使所有字段都为索引字段。
只创建一个文件夹，供所有用户访问，它包含全部六个应用程序组。任何时候当我们使用一个公共索引字段搜索这个文件夹时，会搜索全部六个应用程序组。如果没有分段字段，将搜索所有六个应用程序组中的所有表。使事情变得更糟的是，由于使所有字段都为索引字段，数据库比预期的要大得多。
通过对数据的使用方式多做一些研究，可以确定下面几点：
— AFP 数据主要查询帐号和日期
较少查询帐目描述
（供主管和会计使用）
- Line 数据主要查询帐号和日期
较少查询帐目描述
（供主管、会计和销售人员使用）
- AFP 数据主要查询产品号和日期
较少查询产品描述和交易类型
（供主管、会计、库存管理人员和销售人员使用）
— Line 数据主要查询帐号和日期
较少查询帐目描述和交易类型
（供会计使用）
— PDF 主要查询帐号和日期
较少查询帐目描述
（供主管和会计使用）
— AFP 数据主要查询雇员号、（姓名中的）姓、日期和社会保障号
较少查询（姓名中的）名和部门
（供会计和人力资源部使用）
一种更好的 OnDemand 设计使用了从这些报表中了解到的信息，它可能是这样的：
工资底帐是唯一一个由人力资源部使用的报表。因此，我们将创建下列内容：
文件夹“Payroll Ledger”
应用程序组“payledge” 分段字段：Date
索引字段：employeenum、lastname 和 ssn
过滤器字段：firstname 和 dept
应用程序“payledge”
接着，我们处理库存详细报表。这是唯一一个由库存管理部门查看的报表。
文件夹“Inventory Detail Report”
应用程序组“invreport” 分段字段：date
索引字段：prodnum
过滤器字段：proddescr 和 transtype
应用程序“invreport”
我们要处理的下一个报表是交易详细报表，需要创建的内容与上面的类似。不过，它还需要“transaction type”这一字段，而其它财务报表则不需要此字段。
文件夹“Transaction Detail Report”
应用程序组“transdtl” 分段字段：date
索引字段：acctnum
过滤器字段：desription 和 transtype
应用程序“transdtl”
最后，资产负债表、销售详细报表和损益计算书这三个报表具有完全不同的数据类型。它们都有完全相同的查询需求。唯一要注意的是：销售详细报表是唯一一个由销售部门使用的报表。但是，这些报表都极适合于单个应用程序组。
文件夹： “Executive Report”
“Sales Detail Report” 这将由应用程序标识进行限制
应用程序组：“execreport” 分段字段：date
索引字段：acctnum
过滤器字段：acctdescr 和应用程序标识
应用程序“balsheet”、“salesrpt”和“incomestmnt”
我们的解决方案需要六个应用程序、四个应用程序组和五个文件夹，访问由五个组控制。每个查询都至少会搜索一个表。大多数搜索将是索引扫描（索引字段）而不是表扫描（过滤器字段）。因为我们将 date 字段列为分段日期，所以如果按照日期顺序装入数据并要求用户输入日期，那么就极有可能将我们的查询限制在最少的几个可能的表上。
优秀的 OnDemand 解决方案设计并不就只有我们这个示例一种可能性。我们能够做很多事，如查询限制、用户组限制、应用程序组许可权等等。OnDemand 支持网站是一个优秀的参考资源，它可以帮助您尝试其它可能的设计。
作为 OnDemand 解决方案的设计人员，别人可能给您各种各样的报表要求归档。它们并非全是 Line 数据或 AFP 数据，而且它们都有各自不同的查询需求。为了实现最佳设计需要了解谁将使用这些报表以及将如何查询这些报表。在开始构建解决方案之前，详细的规划将有助于您完成一个在未来很多年内仍然保持高效率的设计。
全部 IBM 产品的支持
IBM Content portfolio
IBM Content Manager 产品
IBM Content Manager OnDemand Support
DB2DD OnDemand 文章：为 IBM Content Manager OnDemand 系统管理选择模型
DB2DD OnDemand 文章：定制 IBM Content Manager OnDemand 管理客户机
关于作者
Eric Hann于 1998 年加入 Content Manager Ondemand Support，他是位于科罗拉多州玻尔得（Boulder）的 Content Manager, OnDemand Support 团队的负责人。在最初设计和实现 IBM 的基于 Web 的 Content Manager 产品支持倡议过程中，Eric 扮演了关键角色。 Benjamin Boltz是一名 Content Manager OnDemand 开发人员，工作地点在科罗拉多州玻尔得。Ben 从 1996 年开始在 IBM 工作，作为一个服务产品的安装者，这个服务产品最终成为了 Content Manager OnDemand。可以通过ehann@us.ibm.com和boltz@us.ibm.com分别与 Eric 和 Ben 联系。





_xyz