使用 Web 存储系统设计知识管理设计方案

1 使用 储系统设计知识管理设计方案 储系统用作开发平台 储系统是 体现它的“不受限制的知识工作者”理念而宣布的四项创意之一。这些创意的主要目的是消除当今知识工作者面临的妨碍相互协作的障碍。 储系统将文件系统、 及协作服务器的功能组合到一个位置，以便存储、访问、管理信息以及建立和运行应用程序。 储系统中的每一项都是可用 址的，并且完全支持半结构化数据，如文档、联系人、消息、报告、 件以及 储系统提供与 000 的高性能集成。它为信息管理（包括一致搜索和数据分类）建立了一个平台。 图 1 阐释了 储系统的编程模型。从图中可看出它支持不同的协议、数据访问方式和事件模型。对 储系统的数据访问包括对 B 和 的支持。 储系统还提供通过 议进行访问的功能。 范 （英文）增强了这一功能，使它可支持另一组协议命令。此外，该存储系统本身还支持可扩展标记语言 ( 储系统还包括一些新的功能，如 问、 储系统窗体、事件、工作流、内容索引、搜索文件夹以及即时消息传送。这些功能为开发人员建立 决方案带来了很大的灵活性，也更容易实现。有关 储系统的详细资料，请参见 000 及 发人员中心 （英文）。 图 1. 储系统编程模型 建立 决方案 2 对企业中的每一个业务问题，知识管理 (通过选择解决问题的正确模块而不断更新。根据不同的组织方式和技术，每一 模块都有自己的特性。下面列出了一些典型特性： 扩充客户 /合作伙伴 /雇员的知识 快速学习并重复利用知识 提高知识产权的价值 为产品和服务提供特别的附加值 建立新知识 共享工作过程和质量革新的知识 图 2. 用模块 有两项技术是所有 统的基础：完全 消息传送及 协作。这些技术构建的基础结构支持对信息进行有效传输、架构、访问和协同管理。 其余的 用模块把这一基础结构扩展成一个复杂的 统，该系统包含各种服务（如内容管理、各种信息传递以及数据分析等）。其它服务（如数据跟踪、工作流过程）也包含在该系统和这些模块中。 实现 用模块可以是即插即用的。虽然某些模块得益于先前某一模块的实现，仍可按与要开发的特定业务案例之间的相对顺序选择它们。例如，象视频会议这样的实时协作服务，可以很容易地包含在必备技术的上层，但要通过内容管理模块中提供的元数据服务才能得 以增强。 3 图 3. 可能的知识管理平台分层结构 前的 台是 系列。它提供的服务能够：建立 决条件（消息传送及协作和完全 通过实现所有的 用模块（内容管理、团体和组、入口和搜索、数据分析以及实时协作 ）将它们扩展成 决方案。除了这些服务， 提供与先前信息或知识源集成和连接的接口。 在未来的几个月内， 发布 包含 2000、 000、 000、 000、 000 及 000。设计这些组件的目的是通过它们的紧密协作来建立下一代的 用程序。本文的重点是 储系统，它是 000 以及 来产品的基础存储技术。 储系统是建立和提供以下关键知识服务所需的一个开发平台： 搜索与传递 协作 文档管理 跟踪和工作流 有关详细信息，请参考 建立知识管理解决方案白皮书 （英文）。 决方案框架：基于服务的应用程序模型 为了奠定一个基础，以便您掌握下面关于如何设计 决方案的讨论，我们将根据 决方案框架 (白皮书，简要概括 基于服务的应用程序模型。有关详细信息，请参考 决方案框架白皮书 （英文）。 4 倡使用基于服务的应用程序模型来设计和实现分布式组件和业务 解决方案。“基于服务的应用程序模型”是指应用程序的功能定义为一组服务集合。按照 观点，一个应用程序是由服务的使用者与提供者组成的逻辑网络构成的。在这一模型中，使用者可以是一个用户或另一个服务组件。这些服务可以跨越物理和功能的边界，满足各种不同应用程序的需求。 什么是 服务 ？服务就是一组应用程序逻辑，它针对对象实现操作、功能或转换。服务可以执行业务规则，计算或管理数据，提供输入、检索、查看或修改信息等功能。 为进一步精确说明服务网络的分布特性， 用程序模型定义了组成一个应用程序的三类服务： 1. 用户服务 是提供应用程序接口的应用程序逻辑单元。应用程序的用户可以是一个用户或另一个应用程序。 因此，应用程序的接口可以是图形用户界面 (和 /或应用程序编程接口 ( 2. 业务服务 这种应用程序逻辑单元用于控制业务规则的先后顺序和执行，并且可以保证所执行操作的事务完整性。通过应用恰当的业务规则，业务服务可将数据转换成信息。 3. 数据服务 是提供最低提取可见级别的应用程序逻辑单元，用于操作数据。数据服务维护作为公司资产的永久和非永久数据的可用性和完整性。它们提供创建、读取、更新和删除服务，这样业务服 务（数据服务的使用者）就不需要了解数据的位置、实现方式和访问方式了。 计过程 设计业务解决方案的过程可与设计建造一座建筑物相比。好的建筑师只有了解了客户的需求才真正了解了客户。在系统设计中，可有多个视角描述最终产品，这与建筑是一样的。每一个视角都是为不同的受众准备的，它们的详细程度也不尽相同。 决方案的设计也是这样 应用程序有不同的重点和技巧。设计人员专注于用户界面、业务过程或数据库问题，我们需要为他们提供一种途径来协调和同步他们的工作，使他们能高效地、有组织地利用他们的专业技能完 成全面平衡的设计。 计过程分三个阶段： 1. 概念设计 2. 逻辑设计 3. 物理设计 概念设计 概念设计 是指确切了解要解决的问题，然后以管理方和用户都能理解的方式构架出问题的解决方案。与单纯收集需求相比，它的范围要广得多。这个阶段还需要根据具体环境来处理这些需求，从而合理决策。 概念设计提取出要执行业务活动所需的本质任务和信息，从而按照既紧密围绕过程，又以用户为中心的方式看待解决方案。 5 在 ,方案 是概念设计过程的关键结果。一个方案描述在某种业务环境中用户执行的与行为相关的一系列任务或事务。方 案必须根据负责这项工作的用户的需要（以用户为中心）来提取业务解决方案的需求（围绕过程）。 逻辑设计 逻辑设计 是指通过定义系统各部分及它们间相互作用的方式来描述解决方案的过程。这一过程组织新系统的逻辑结构并阐释该系统的组成方式以及它与外部世界的接口。 在逻辑设计过程中，必须加深项目组对系统的认识。这是确定设计的详细程度的主要考虑因素。逻辑设计提供的组织和结构规则必须满足各个独立的组成员同时高效工作的要求，还要奠定与外部项目和构架进行协作的基础。 逻辑设计提供了评价各种物理设计选项的基础。通过不同的物理设计都 可能实现对逻辑元素的组织。在一个反复的过程中，进行逻辑设计会与进行物理设计有部分相重叠。这样整个小组才能够逐步优化系统。 逻辑设计旨在列出系统中的各部分、描述它们的相互联系并定义使用这些部分可以达到什么目的。请记住概念设计与逻辑设计是紧密相关的。逻辑设计描述系统如何配合每一个概念设计方案。 设计组可以从定义系统的主要模块开始逻辑设计过程。模块表示协同工作完成某项任务的一些过程的集合。设计组必须确定每一个元素、每个元素的职能以及每个元素如何与其它元素相互作用。这个阶段的结果包括： 核心的功能区域或元素 这 些区域的活动或功能 区域间联系 物理设计 物理设计 是从开发小组的角度描述解决方案的组件、服务以及技术的过程。物理设计旨在根据现实的技术局限性分析逻辑模型，包括实现情况和性能方面的考虑。 物理设计过程的结果是一组组件、特定平台的用户界面设计以及物理数据库设计。物理设计为功能规格提供基础。开发小组、测试小组以及部署小组都可使用这一功能规格作为质量保证的基础。 物理设计过程包含几个步骤：研究、分析、合理化以及规范化： 物理设计的 研究 步骤包括确定基本结构的物理局限性以及解决方案的物理需求，并处理物理局限性与 需求之间可能产生的冲突。 物理设计的 分析 步骤包括选择备选的实现技术并草拟由网络、数据、组件拓扑结构组成的初步部署模型。 物理设计的 合理化 步骤包含确定打包方式和分布策略、将对象分解成基于服务的组件、在拓扑结构中分布组件以及进一步改进打包和分布方式。 6 物理设计的 规范化 步骤包括确定编程模型、指定组件接口和了解组件结构的考虑因素。 决方案设计模型 到此，我们已经分析了建立 决方案、 用程序模型和设计过程的关键概念。现在该将它们综合起来集中学习如何按照 计过程设计 决方案了。 我们将使用 于服务的应用程序模型作为以下论述的基本方针。设计典型的 决方案时，我们必须仔细考虑以下问题： 我们设计的目的是什么？ 我们是否定义了获取用户和业务需求的方案？ 我们是否有足够的信息来定义一组服务以及它们的接口？ 一旦我们确定了实现技术，基本结构和技术方面将存在哪些局限性？ 我们是否定义了对象模型？ 下表阐释了一个 决方案设计模型的示例，它是基于一个虚构的 000 示例应用程序的。 表 1. 知识管理解决方案设计模型 服务 层次 概念设计 （方案） 逻辑设计 （对象 /服务） 物理设计 （组件 /技术） 用户服务 示例方案：建立社区论坛，通过动态地、根据需要添加论坛来实现它的灵活性。 一个基于 虚拟社区，包括以下服务： 业界新闻 协作 最佳方法 共享联系人 易于查找的信息 一个基于 000 的数字版面，它包含不同的 件，与逻辑设计中定义的服务相对应。 业务服务 示例方案：要求引导 (文档综述和批准过程。 生成 务 在 架的基础上将 换成 生成并验证 属性的事件接收器 使用工作流引擎实现 7 档 准过程 准过程 使用 现 换过程 数据服务 示例方案： 一个中央信息库，用来容纳所有相关项目文档以及与工程组织相关的设计文档。 允许小组成员通过适当的安全模型共享或查看文档。 以下对象的逻辑架构设计： 项目 文档 小组成员 基于 储系统的物理架构设计： 文件夹结构 架构文件夹 自定义内容类及属性 安全 述符模板 以下是适用于 计模型的一般最佳方法或建议。在下面的部分我们将讨论具体的主题。 在概念设计阶段，重点是定义能把握业务过程和需求的 方案 。方案的定义应当根据业务问题范围内的环境来进行，而不是根据解决方案范围内的环境来进行。 在从概念设计到逻辑设计的 过渡阶段 中，开发小组可审核整套方案以应用适当的面向对象 (的设计技术（例如用户案例分析），来确定备选服务和 /或对象。这些备选服务 /对象奠定了逻辑设计模型的基础。这通常是个反复的过程，即需要往复几次才能完成。图 6 是一个基于 2000 联机文档的示例用户案例关系图。本关系图源自 )（英文）公司的 写的面向对象的分析和设计材料。 8 图 4. 用户案例关系图示例 在逻辑设计阶段， 小组应专注于设计业务和对象，而不考虑技术和平台的因素。对多数开发人员来说，做到这一点比较困难。一些开发小组可能倾向于干脆跳过逻辑设计阶段而直接进行物理设计。这绝对不是一个好办法。逻辑设计模型有许多优点，如： 为各个单独的小组成员同时高效工作提供必需的组织和结构规则。 充当与外部项目和设计人员协作的基础。 降低复杂性。 提供根据用户需求（即方案）优化设计的机会。 在从逻辑设计到物理设计的 过渡阶段 中，开发小组可以使用逻辑设计阶段定义的服务和对象草稿开始物理设计。所有小组成员和该项目涉及的其他人员都应当 首先了解解决方案和整个系统结构的情况，包括系统中各部分之间的相互联系。使用统一建模语言 (中定义的相互作用关系图（顺序关系图）来获取系统的动态相互作用关系是一个较好的方法。图 7 是一个示例顺序关系图，摘自 000 联机文档。本关系图源自 )（英文）公司的 写的面向对象的分析和设计材料。 在物理设计阶段，开发小组应专注于能优化或改进设计模型的设计因素。本文其 余部分将集中讨论适用于使用 储系统进行设计需要注意的最佳方法。 9 图 5. 顺序关系图示例 用户服务设计的最佳方法 正如上文所述，用户服务是提供应用程序界面的应用程序逻辑单元。其设计活动的中心通常是图形用户界面 (和 /或应用程序编程接口 (以下是使用 储系统设 计用户服务的一组最佳方法： 通过考察关键使用方案确定一般用户服务 在逻辑设计阶段，小组要考察各种使用方案，尤其是与用户（或 的“操作者”）相互作用的情况。多数情况下，从方案中确定用户服务会非常容易。但是，要找到可重复利用的用户服务就需要额外的精力和经验了。 示例：在设计雇员 口 点时，内容搜索用户服务和分类选择用户服务可能会在整个 点中重复利用。 使用新的数字仪表板框架 数字仪表板概述：数字仪表板是知识工作者的自定义解决方案，它将个人、小组、公司以及外部的信息综合在 一起，并很容易使用分析和协作工具。使用 数字仪表板资源工具包 (文），公司很快就能够建立并部署自定义的数字仪表板解决方案。 包含所有必需的工具和文档、示例仪表板以及可立即用于各种数字仪表板的组件。 10 数字仪表板由 件 （可重复使用的组件，包含任何形式基于 信息）组成。 生成 件很容易；最终用户可在仪表板中创建简单的 件。开发人员使用 件生成器可以创建更加复杂的 件。 通常数字仪表板应用程序有一个增强的用户界面，它将常见的 能与易用的 览器风格的控件相结合。用户只需点击一下，就可使用简便的工具来自定义数字仪表板、创建新的 件或者从 本地 的 件库中导入 件。图 8 显示一个名为 虚构的公司的数字仪表板。这个数字仪表板包含的 件显示用户收件箱、 历以及有关该公司的关键信息。 图 6. 数字仪表板示例 实现用作 件的一般用户服务 数字仪表板的核心是 件。 件是可以重复使用的组件，它包括 基于 内容（如 脚本，还包括一组标准属性，用于控制 件在数字仪表板中的显示方式。这些属性使 件和仪表板成为中立的存储空间并且完全可以重复使用。 因为 件遵守一般标准，您可以把它们存储在库中，从这个库中您可以提取 件来组成您的组织中的所有数字仪表板。许多 件和仪表板都具有用户专用的属性，但如果您是管理员，可以控制用户能够更改 件或仪表板的程度。 11 通过 计指南定义一致的外观 定义一组 计指南是个好方法。 这样能够保证 决方案有一致的外观。例如，为了使用户对您的 口 点更加满意，就要为一般 户服务设计一致的 些服务包括： 导航服务 内容搜索服务 分类选择服务 内容表示服务 尽量使用 只需要重复使用 的某些部分，您就可创建自定义的 面。这些部分可以嵌入到 面中。可使用表、框架和 安排 各个部分。 每天的任务提供了默认视图 例如，查看收件箱和发件箱。 通过指定其它参数可以操作默认视图。例如， 面可以包含用户的收件箱和组日历。在页面的一角可以显示一个商标或公司标识，在另一角有当前新闻和与内部工具的链接。因为使用 以在很大程度上减轻您的开发工作，您应当尽可能地使用它。 为自定义的内容类和属性使用 储系统窗体 如果已经设计了自定义的内容类和属性，您应当考虑使用 储系统窗体。 储系统窗体是一种基于 窗体技术，它建立在 准之上。 储系统窗体是在 储系统中注册的 面。注册本身就是 储系统数据存储区中的一条记录。 储系统窗体被设计为能够与符合 准的浏览器一同工作。支持那些功能的浏览器包括 更高版本以及 或更高版本。 储系统窗体有什么特殊之处呢？ 储系统窗体具有以下特点： 以数据为中 心 ：浏览器请求存储区中某一项的 储区执行与所请求的项相对应的窗体。 适应性强 ：窗体只需要了解如何处理某一特定语言、浏览器或操作。存储区能够与请求相适应以保证执行正确的窗体。 究竟什么是窗体？它是一个相当宽泛的词汇，通常与通过 议与存储区中数据绑定的 面相关。根据 品组的编程经理 说法，更正式的定义为“一个过程，它使用 信，可通过 用户进行交互并操作数据，从而响应用户的操作。” 了解 储系统窗体如何工作是必要的。 储系统中的所有内容都是可用 址的。从 行访问时， 储系统中的所有项提供默认的显示方式。窗体注册表允许开发人员覆盖 的默认显示方式。 12 收到来自用户浏览器的 求后，该请求即被传送给 务 ( 用 与 储系统用来处 理所有 求所使用的 同。查窗体注册表的窗体注册。窗体注册提供一组针对窗体的属性，如内容类、用户操作、语言、浏览器类型、项状态和两个重要属性： 执行 行该 显示窗体。它可能是一个 选器（例如：/一个 面（例如： 窗体 在处理或显示的窗体或模板的 前 表示的项（例如： 处理从 求报头读取的信息，并与存储在 浏览器的信息相比较，就可以得到浏览器的功能信息。 用与窗体注册表信息最佳匹配的比较来确定显示哪一个窗体。 有关 储系统窗体的详细信息，请参考 000 设计业务服务的最佳方法 正如上文所述，业务服务是一个应用程序逻辑单元，它控制执行业务规则的先后顺序，保证所执行操作的事务完整性。以下是一组使用 储系统设计业务服务的最佳方法： 通过使用方案 确定关键业务过程 在逻辑设计阶段，开发小组应检查他们在概念设计阶段收集的方案以确定业务过程，如文档批准过程或内容变换过程。 确定实现机制 在物理设计阶段，开发小组需要确定这些业务过程最合适的实现机制。有四个基本选项：工作流引擎、事件接收器、 组件和脚本（客户端或服务器端脚本）。使用脚本的方法会造成一些困难，如代码不易维护以及脚本的局限性。因此，我们建议采用前三种方法。以下是确定实现方法的一组指南： 如果业务过程符合以下情况，则使用工作流： 涉及多用户和多资源。 具有复杂过程，如批准或业务 验证过程。 如果出现以下情况，则使用事件接收器： 只涉及少量的用户或资源。 验证过程简单。 具有整个存储区范围内的事件。 具有定时器事件。 13 如果使用 储系统进行的大多是读取操作而不是更新操作，且不涉及工作流，则使用 组件。 设计数据服务架构的最佳方法 正如上文所述，数据服务是提供最低提取可见级别的应用程序逻辑单元，用于操作数据。数据服务维护作为公司资产的永久和非永久数据的可用性和完整性。这一部分我们将讨论 储系统架构设计，下一部分讨论文件夹结构。 首先，什么是 架构 ？对于建立在 储系统技术基础上的整个物理设计模型来说，为什么 架构设计 至关重要？ 架构 一词指的是一种定义和组织数据（有时称为 元数据 ）的方法。在结构化查询语言 (关系型数据库中，架构包括所有的表定义和列定义，以及其它信息（如索引和触发器）。对于存储区，我们将架构设计的重心放在内容类及与其相关联的属性集方面。架构设计对整个 决方案是否成功有直接影响，尤其是在性能和可扩展性方面。架构设计通常是定义数据服务模型的第一步。许多设计的考虑因素和决策都要依赖架构设计。下面一段是对 储 系统架构的简要介绍。 储系统可用于为您的应用程序定义架构。 储系统架构是以 内容类 为中心的。内容类为存储区中的项 /实例定义架构类，是属性集的逻辑容器。为您的应用程序创建架构定义时，要定义自定义内容类及相关的属性。 储系统含有大量预定义的内容类和属性。定义自己的自定义内容类时，您可以使用或扩展（子类）某一预定义内容类。其中包括（但不仅限于）表 2. 所列的内容类。 表 2. 内容类 内容类 说明 存储区中各项的基类 消息的基类 议请求和响应的基类 约会的基类 联系人项的基类 件夹的基类 档的基类 储系统架构的一个 长处是它们为 架构感知 的应用程序和工具提供了一种方法，可用来查找出适用于某一特定应用程序的内容类和属性的名称。 与某一特定应用程序相关的架构信息是通过文件夹的 架构范围 来控制的。文件夹的架构范围是一组按某特定顺序遍历的文件夹，它们包含架构定义项。通过在 储系统（其中存储您的架构信息）中定义文件 14 夹的列表，你可以逐个文件夹地扩展架构。范围可以很简单，只包含全局架构文件夹；也可以比较复杂，包含一个很大的文件夹 列表。 还需要查看以下两个属性来定义架构范围，这两个属性对整体架构设计 尤其是文件夹 结构 也很重要，我们将在下一部分讨论这一主题。 这一属性是一个文件夹的 在该文件夹中查找内容类和属性定义。这是搜索架构定义项的第一个文件夹，并且总是文件夹架构范围中的第一个文件夹。如果未设置这个属性，则默认为存储区的 件夹，其中包含 储系统的默认架构定义项。 一属性是个多值字符串，包含一个或多个文件夹的 过确定包含架构定义项的其它文件夹，可以扩 展某文件夹的架构范围。 除了定义自定义内容类之外，定义 自定义属性 是架构设计的另一个重要方面。虽然 储系统提供许多预定义的属性，您可以为每一项存储任意数量的其它属性；这些属性就称为自定义属性。您还可以对每一项定义一组不同的自定义属性。 自定义属性与它的关联项一起保存。检查项时可以按名称发出请求。如果使用 B 提供程序或 接绑定到项上，或通过 议发出一个 0 深度的 令， 储系统将返回该项的所有自定义属性。对 于所有深度为 1 的项属性，自定义属性对 ”语句或 令都是不可见的，除非这些属性被定义为项的内容类的一部分。因此，要使架构感知的应用程序能识别您的属性，必须把属性和内容类的定义添加到应用程序文件夹的架构范围中。 下面我们对一些通用的架构设计指南作一总结。如果您不熟悉 些词，在继续之前建议您看一看下面的定义。 统一资源标识符 (就是一个采用一定格式的字符串，它可用来唯一地标识一个资源。 以是一个统一资源定位符 (或一个统一资源名称 ( 定位所标识资源所需的底层协议进行编码。 而 与位置无关，而且与定位所标识资源要使用的协议或机制也毫无关系。 头带有一个标识协议的前缀，接着是一个针对协议的字符串。对于 法如下： : ? 是服务器的 址， 是服务器侦听的 口号， 是在 求中作为请求 递的绝对 选的 对应于查询字符串后缀，即用 & 分隔的关键字 /值对的列表。只有 主机部分是必须的。如果未指定端口，默认为端口 80；如果未指定路径，请求 为“ /”。 15 建立现代的、适宜 应用程序是至关重要的，但人们对它还远远不够熟悉。目前还没有一种通用的方式来间接访问 查找它所标识的资源。 语法结构保证了 多个组织的唯一性。其语法如下所示： : 是命名空间标识符， 是命名空间特定的字符串。如果要标识与位置无关的内容，建议您使用 制。对于还需要包含位置信息的标识符，则建议使用 制。 架构设计指南 架构设计指南的内容如下： 使用和定义命名空间 ( 使用命名空间定义属性和内容类是一种好办法。命名空间的作用包括： 有助于确保属性和类的名称是全局唯一的；即，解决识别和冲突的问题。如果您有多个应用程序在同一时间部署，或者独立软件开发商 (在一个大型组织中部署他们的应 用程序时，这一点都是特别重要的。 指示“拥有”属性或类定义的个体或组织。 在随 000 提供的预定义属性和类中，您会发现有许多不同类型的命名空间： ，目的是为了增 强各种架构感知应用程序间的互操作性。 接下来的两个是专用 果您希望为您的应用程序创建一个类似的命名空间，您可以创建 第二个和第三个命名空间的差别就在于：第二个命名空间的结尾有一个命名空间分隔符而第三个命名空间没有。如果命名空间以分隔符“ :”或“ /”结尾，将创建属性或内容类名称，且属性名附于命名空间后。例如，第二个命名空间中的一个属性是 如果命名空间不以分隔符结尾（如第三个示例），则该命名空间中将创建属性名，命名空间与属性名之间有一个符号“ #”。例如，第三个命名空间中的一个属性是 16 最后一个命名空间示例显示如何将 作命名空间。您应当从您拥有或已注册的 选择基于 命名空间。这将有助于保证命名空间的唯一性。 作命名空间时，最后一个分隔符为字符“ /”。 不应向您不拥有的命名空间中 添加属性或内容类。例如，向 ，而应当为您的内容类和属性创建自己的命名空间。 进行属性定义 储系统本身对属性名称中可使用哪些字符没有特殊的限制。但是，最好还是遵守以下一些约定： 应当使用命名空间来创建属性并加上一个标识符（如上文所述）。例如， 属性应当是格式正确的 属性名称中不应有空格，因为 支持在元素名称中使用空格，因此 不支持。 定义自定义内容类 在定义了这些自定义属性之后，下一步就是定义您的自定义内容类。首先，您需要为应用程序选择一个文件夹，用来存储架构信息。您可以将这些信息存储在您的应用程序数据所在的同一文件夹中，但我们强烈建议您使用一个不同的子文件夹，我们称之为架构文件夹。如果您在正定义的架构不是针对某一个应用程序的，您可以在相关的公共存储区里的高层架构文件夹中定义它。 存储架构定义的位置和组织架构定义的方式由您决定。但是，在下一部分中，我们将推荐一 组方式，指导您如何组织文件夹结构以及如何确定对一组特定应用程序数据应用哪一个架构定义。 下面的关系图阐释了使用一个 000 具（即： 储系统架构设计器）来自定义内容类的一个示例。我们建议您使用该工具或类似工具来定义自定义内容类的定义和属性定义。 图 7. 示例：架构设 计 17 考虑内容类的继承性 您当然可以从头开始定义一个全新的内容类。不过，多数内容类都可以扩展（“继承”）现存的内容类。扩展内容类意味着 已扩展的 （派生的）内容类实例的所有属性也存在于 扩展中的 （基本的）内容类实例中。这一概念与 C+ 这样的面向对象 (的编程语言中类继承的概念相似。 图 10 显示一个简单的继承方案。扩展 文档 类意味着任何可在文档类实例上执行的代码或操作都可以在 实例上执行。 图 8. 简单内容类继承 图 9. 带有多个继承关系的内容类 内容类也可扩展为多个内容类。在图 11 中，我们还能看到一个 ，它具有 种属性。但在这一方案中我们希望有作为文档的一个特定类的费用报告和作为消息的一个特定类的费用报告。因此，我们创建一个 来扩展该类。然后创建一个 和一个 ，它们自己没有其它属性。 展了 展了 在，理解 的应用程序就可以理解 的一些属性，而把其余属性当作自定义属性。理解 的应用程序就可以理解 的一些属性。 18 有关架构设计的详细信息，请参考 000 及白皮书“ 储系统架构：使用和最佳方法指南。” 储系统文件夹结构的最佳方法 储系统为设计文件夹结构提供了很大的灵活性。架构定义项可置于特定存储区内的任一文件夹中，并用于为您的应用程序定义架构。通过合理设置 不同文件夹的 性，您可以将这些定义引入到范围中来。 为了避免设计和管理应用程序架构太过复杂，应规划并组织好您的架构信息。例如，可以选择在您指定为架构文件夹的应用程序文件夹的顶层下创建文件夹。设计文件夹结构有许多种方式。以下步骤概述了这一过程。 考虑以下各项： 逻辑模型的复杂程度：正如上文所述，设计存储区的架构有许多方式。在作出最终设计决定前应当考察所有相关的信息和设计选项。 物理模型的复杂程度：您应当考虑到维护复杂文件夹结构的困难程 度。 性能影响：将在以后的部分中讨论。 重复使用和共享架构。 将架构文件夹与其它类型的文件夹区分开来，例如： 应用程序文件夹：包括 面、 面、 储系统窗体等等。 数据（内容）文件夹：包括数据项或文档。 窗体注册文件夹：包括窗体注册项。 通常，特定应用程序的架构定义将置于它们自己的文件夹中。将应用程序文件夹和数据文件夹分开也是一种好方法。正如上文所述，特定文件夹的 和 性确定架构范围。设计 文件夹结构有许多灵活的方式。 文件夹结构的示例如下： 一个简单的应用程序可以有一个包含应用程序文件（ 面）和数据项的文件夹，以及一个架构文件夹。 稍微复杂点的应用程序可以分别有单独的应用程序文件夹、数据文件夹和架构文件夹。 架构文件夹可以有不同的级别，如顶级架构文件夹包含在同一根下运行的所有应用程序。也可以采用一系列架构文件夹，每个架构文件夹通过 用另一个架构文件夹。 定义架构文件夹。 19 定义常用的内容类和属性定义。 定义窗体注册。（这可能在一个单独的窗体注册文件夹中。） 创建架构文件夹时，您必须确定这些文件夹的范围。即，某一给定的架构文件夹适用于哪些数据文件夹？任意数量的数据文件夹可以使用一个架构文件夹。反之，在多个架构文件夹中定义的架构可以应用于一个数据文件夹。 正如上文所述， 一个可在数据文件夹上设置的属性，用来指示在查找相关属性和内容类定义时应首先搜索哪个架构文件夹。 性则形成一个架构文件夹的树形结构来搜索架构定义。在这个架构文件夹的逻辑树中，每个节点都可有许多子节点。这个架构文件夹的逻辑树可以（并且通常会）与存储区中文件夹的物理布局不同。相对于给定的数据文件夹， 性指示搜索始于哪个架构文件夹。 定义应用程序和数据文件夹。 如果需要，将 属性指向架构文件夹。 使用 储系统 这一部分我们考察 系型数据库和 储系统间的主要差别；讨论何时使用 及何时使用 储系统；并 提供一套指南，用于从已有的 据库向 储系统移植数据。 表 3 阐释了 据库与 储系统的不同之处。注意 据库与基于 储系统的 品（如 000）有一组相同的服务。 表 3. 据库和 储系统 据库 储系统 关系型数据库 类似于对象数据库 结构化数据 半结构化数据 表 文件夹（以及内容类） 列 内容类和属性 固定行 不固定行 集中于业务智能 协作 以事务为中 心 以文档为中心 数据完整性：主键 /外键 无主键 /外键 20 矩形数据 非矩形 触发器 事件接收 存储过程 无可比实体（与之类似的是事件） 如果现有的 决方案正在从 系型数据库中读取数据，而这些数据是典型的非矩形半结构化数据，您最好考虑将这些数据从 植到 储系统。 请参照以下指南，将数据从 植到 储系统： 首先，将 映射到属性，将 映射到文件夹和内容类。 确定表的主键和外键。根据逻辑设计模型查找与之对应的内容类。 通过 确定一组能生成项的唯一实例的属性来模拟主键。 考虑内容类的继承性。 物理设计考虑因素 到此，我们已经讨论了设计用户服务、业务服务和数据服务的最佳方法。这一部分我们将集中讨论物理设计阶段针对 储系统的设计考虑因素。 对每个设计考虑因素主题，我们都将介绍一些重要的概念、讨论一些您可以采取的折衷措施，并列出一张清单，供您在考虑各种选项时参考。 安全模型 这一部分中概述了 储系统安全模型。除了使用 户程序（如 件系统 控制安 全设置外，您还可以使用基于 安全描述符来控制对某一项及其属性的访问。使用 储系统安全描述符，您可以： 既可将对某一项及其属性的访问权授予受托者（具有凭证、正在访问该项的人），也可以拒绝该受托者进行访问。 使用 安全标识符 (标识受托者。 设置、检索和修改 式的描述符。 使用 B (提供程序和 式的 议访问描述符。 每一项 的安全描述符都通过该项的 。这个属性是项的 式的描述符。该描述符以 000 有的二进制格式进行 21 物理存储和复制，这种格式内部是基于标准的 000 描述符格式的。如果文件夹中的某项没有特定的安全描述符，其父文件夹中指定的默认权限将被应用于该项。 安全描述符是一种数据结构，它包含以下内容（以及其它未列出的内容）： 一个所有者字 段，其中包含对象所有者的安全标识符 (该对象与安全描述符相关联。 一个任意访问控制列表 (字段，指定谁对该对象字段具有访问权。 一个系统访问控制列表 (指定系统可以审计哪些操作。 访问控制列表 (包含一个或多个访问控制项 (每个 安全负责人 指定访问权限。 000 中的安全负责人可以是一个用户或一组用户。 000 定义了一个新的安全负责人，叫做 角色 。角色是一个具有名称的安全负责人（用户或组）的集合，它可在 的 引用。角色与 000 组之间主要的区别在于 全角色是针对对象本身定义和存储的。也就是说不需要进行具备特权的目录服务操作，就可以创建这些角色，并填入成员。 对于不需要具备特定 000 组就可以部署的应用程序，这一功能是非常重要的。安全角色在 储系