设计类别结构时，必须确定类别的主题区域，以及必须在类别中创建，使用和查看监管工件的人员。
必需的许可权
您必须具有 管理监管类别 用户许可权 才能创建顶级类别。
类别的属性
类别具有一些类似于监管工件的属性的标准属性。
| 属性或行为 | 支持? | 说明 |
|---|---|---|
| 必须具有唯一名称? | 是 | 类别路径与其名称的组合必须是唯一的。 类别名称不能包含 >> 字符。 为类别分配一个足以包含其所有工件和子类别的通用名称。 |
| 描述? | 是 | 可选。 包含帮助创建监管工件的用户知道要添加到此类别的内容的描述。 |
| 是否将关系添加到其他类别? | 类别与其子类别及其更高级别的类别具有分层关系。 子类别从其更高级别的类别继承合作者。 具有不同顶级类别的类别不能相互具有关系。 | |
| 将关系添加到监管工件? | 是 | 大多数类型的监管工件按类别进行组织。 监管工件可以具有主类别和辅助类别。 |
| 要向资产添加关系吗? | 是 | 请参阅 目录中的资产关系。 |
| 要添加定制属性吗? | 是 | 请参阅 监管工件和目录资产的定制属性和关系。 |
| 添加定制关系? | 是 | 请参阅 监管工件和目录资产的定制属性和关系。 |
| 添加定制角色? | 是 | 您可以为类别创建定制角色。 请参阅 定制角色。 |
| 从文件导入? | 是 | 请参阅 导入和导出类别。 |
| 从 Knowledge Accelerator 导入? | 是 | 所有 Knowledge Accelerators 都包含多个类别。 请参阅 Knowledge Accelerators。 |
| 导出到文件? | 是 | 请参阅 导入和导出类别。 |
| 由工作流程管理? | False | 类别创建和管理不受工作流程约束。 但是，类别作为工作流程定义的一部分包含在内。 请参阅 类别和工作流程。 |
| 指定有效的开始日期和结束日期? | False | 类别没有开始日期和结束日期。 |
| 要分配管理员吗? | False | 类别具有所有者或管理者。 |
| 添加标记作为属性? | 是 | 请参阅 标记 (Tags)。 |
| 要分配给资产吗? | False | 类别仅分配给监管工件。 |
| 预定义类别? | 是 | [uncategory] 类别是预定义的，包含预定义的监管工件。 请参阅 预定义的类别 (Predefined categories)。 |
类别体系结构
设计类别体系结构的一些常见策略包括通过以下方式划分高级类别:
- 按业务单位 (例如，硬件，软件和服务) ，然后按部门 (例如，市场营销，财务和人力资源)。
- 按主题区域（如客户和产品）。
您可以根据需要创建任意数量的顶级类别和子类别。 您可以创建类别以组织没有任何工件的子类别。 例如， Knowledge Accelerator for Financial Services 的类别结构的一个部分如下所示:
Knowledge Accelerator for Financial Services
Business scopes (0 governance artifacts, 29 subcategories)
Custom Insight (0 governance artifacts, 4 subcategories)
Customer Insight - Contact Center Optimization (271 business terms)
Customer Insight - Customer Lifetime Value (258 business terms)
Customer Insight - Optimize Offers And Cross Sell (307 business terms)
Individual Customer Profile Analysis (110 business terms)
尝试设计类别结构，以使类别不重叠，即使监管工件可以适合多个类别也是如此。 例如，在 Knowledge Accelerator for Financial Services中，业务术语 电子邮件地址 属于以下主类别和 6 辅助类别:
类别合作者
用户必须是类别中的合作者，才能查看该类别中监管工件的详细信息，或者在该类别中创建监管工件。
类别合作者具有用于控制其可在类别中执行的操作的角色：
- 所有者：管理类别、其工件及其合作者。 所有者可以将任何类别角色（包括“所有者”角色）分配给其他类别合作者。
- 管理: 管理类别，其工件及其非所有者合作者。 管理员可以将任何类别角色（“所有者”角色除外）分配给其他类别合作者。
- 编辑者：查看该类别，以及管理它的已发布工件和草稿工件。
- 复审人：查看该类别以及它的已发布工件和草稿工件。
- 查看者: 查看类别及其已发布工件的详细信息。
- 定制角色: 您可以创建具有一组定制许可权的定制角色，以控制合作者可以在类别中执行哪些操作。 请参阅 定制角色。
可以为类别合作者分配多个角色。 子类别从所有父类别和更高级别类别继承类别合作者及其相应角色。 子类别中的合作者具有在该子类别中分配给其的角色，以及在所有更高级别的类别中分配给其的角色。 请参阅 类别层次结构中的多个角色。
通常，在类别层次结构的较高级别为用户提供最低许可权。 添加对特定子类别具有更多许可权的角色。
缺省情况下，顶级类别自动将 公共访问权 组作为具有 查看者 许可权的合作者。 但是，只有同时具有 访问监管工件 或 管理监管类别 许可权的用户才会包含在该组中。
类别合作者分为两个主要组:
- 使用数据资产并需要查看监管工件的目录成员。
- 需要创建或分配监管工件的监管团队成员。
使用资产的目录成员
Cloud Pak for Data as a Service 的所有用户都具有以下许可权:
- 查看分配给目录或项目中的资产的监管工件的名称。
- 向目录或项目中的资产分配监管工件 (如果这些工件在目录或项目中具有 编辑者 或 管理员 角色)。
但是，要查看监管工件的详细信息，目录成员必须具有类别中的 访问监管工件 用户许可权和 查看者 角色。
使用数据资产并需要查看详细信息监管工件的目录成员可以包括数据研究员，数据工程师，业务分析员和机器学习工程师。 这些用户使用数据资产来准备数据，分析数据或构建模型。 通常，您希望所有目录合作者都能够查看分配给目录中资产的监管工件。
用户从 公共访问权 组继承的 查看者 的缺省类别角色足以供目录合作者使用。
治理团队成员
监管团队包括通过导入和扩充元数据来组织数据的人员以及创建监管工件的人员。
下表汇总了每种监管目标类型的最低类别合作者角色。
| 治理目标 | 对监管工件的操作 | 类别角色 |
|---|---|---|
| 将扩充数据资产添加到目录中 | 将监管工件分配给资产 | 查看者 |
| 实施治理框架 | 创建监管工件 | 编辑者 |
| 审查治理框架 | 将监管工件作为工作流程的一部分进行复审 | 复审者 |
| 管理治理框架 | 创建子类别并添加合作者 | 管理员 或 所有者 |
为这些用户授予包含 访问监管工件 许可权的 用户角色 ，以便这些用户包含在 公共访问权 组中。 缺省情况下，这些用户在所有类别中都具有 查看者 角色。 您可以在相应的子类别中为这些角色提供更多许可权。
对于执行元数据扩充的用户，请在包含与其元数据扩充任务相关的工件的子类别中为其分配 查看者 角色。 查看者 角色足以查看工件详细信息并将工件分配给资产。
对于创建监管工件的用户，请在他们需要在其中创建工件的子类别中为他们分配 编辑者 角色。 如果用户还需要创建子类别，请为其分配 管理员 角色。
复审者 角色对于识别负责复审工作流程中的监管工件的用户很有用。
与监管工件的主类别和辅助类别关系
类别可以包含以下类型的监管工件:
数据保护规则未包含在类别中。
类别及其包含的监管工件具有两种类型的关系:
- 主要
- 必需。 类别拥有工件并确定谁可以管理该工件。 每个监管工件都有一个在创建工件时分配的主类别。
- 辅助
- 可选。 类别包括工件。 一个工件可以包含在任意数量的辅助类别中。 辅助类别是对工件进行分组和发现的替代方法。
类别可以同时具有主工件和辅助工件。
用户必须在工件的主类别中具有许可权才能查看或管理工件。
类别和工作流程
可以通过使用工作流程组合类别来配置对监管工件的细颗粒度控制。 工作流程会强制实施基于任务的流程，以控制监管工件的创建、更新和删除。 您指定工作流程中的步骤数量以及谁可以执行每个步骤的任务。 每个工作流程控制类别、工件类型和操作的组合。 被委派者必须执行对应于工作流程中某个步骤的监管工件任务时，会收到通知。 工作流程步骤的受让人可以取消类别角色提供的许可权。
例如，如果工作流程步骤指定用于创建工件的复审者必须在类别中具有 管理员 角色，那么只有具有 管理员 角色的合作者才是该任务的受让人，并且可以创建工件。 具有 所有者 角色 (而不是 管理员 角色) 的合作者不是受让人，并且无法创建工件，即使 所有者 角色包含创建工件的许可权也是如此。
了解更多信息
父主题: 类别