构建管理模型
Blackboard 建议在大多数情况下使用机构层次结构功能来代替机构管理。机构层次结构允许更充分地利用其他 Learn 功能，且无需基于自定义规则的逻辑。
使用“机构管理”时最重要的是开发符合机构组织需求的“管理”模型。这一主题贯穿于考虑机构管理需求的整个过程。其中包括要在每个阶段提出的问题和一个小的示例。
请记住，这是一个帮助您开始考虑管理模型的工具。机构管理的灵活性和无限的“系统角色”使得每个机构都可有与之匹配的唯一解决方案。
什么是需要机构管理的校园内的分组？
设置委派的管理模型的第一个步骤是在机构中定义组，拥有限制在该机构管理中权限的委派管理员可以支持该机构。由于机构管理可包括用户、课程、组织、标签和模块的任意组合，所以不同机构管理的结构是不受限制的。一些机构可能会选择使用机构管理将学生、教师、校友和教师间的用户管理分开。相同的机构可使用机构管理将两个系之间的课程管理分开。相同的机构甚至可以应用两种模型，允许系的机构管理管理员控制各自系中的用户。进而，每个系都可被分为多个单独的机构管理。可用一个机构管理来管理标签和模块内容，一个机构管理来管理课程，另一个机构管理则用来控制用户。
在创建机构管理和指定管理权限之前，机构管理的灵活性要求目标和组织都应该清清楚楚。否则，很可能会根据需要来创建机构管理，从而导致系统难以进行定义和监督。在定义需要机构管理的校园内的小组时，请考虑以下问题：
- 机构是如何组织和管理的？为每个功能组创建机构管理是否有意义？不只在各系内考虑此问题，考虑支持学习使命的校园内的组。
- 如何使用机构角色在 Blackboard Learn 中定义用户？例如，用户是按专业、位置、学习年份还是其他变量来组织？
- 如何管理机构中的人员？不同的用户集是否由不同的功能组来管理？例如，是否有处理校友关系的校友办公室？招生部门是否对预期的学生负责？
- 谁对标签和模块中出现的内容负责？哪些机构角色用于定义可以查看内容的人员？
- 是否有不同的信息系统负责与 Blackboard Learn 共享的数据？
校园的分组很可能会有同样需要委派管理的子分组。子分组不能作为机构管理嵌套在机构管理中，但是这并不妨碍创建机构管理的层次结构。由于机构管理是由集合及单位（如课程或用户）组成，并可显示在多个集合中，所以定义包含另一个机构管理的子分组的机构管理将会非常简单。要保持正确的组织，请为合并到大型机构管理中的机构管理制定命名约定。例如，文学院的系可能会有几个子机构管理。
机构管理可以遵循以下命名约定：
SLA - 文学院
SLA_HISTORY - 文学院历史系
SLA_ANTHRO - 文学院人类学系
SLA_LANGUAGES - 文学院语言系
SLA_LANGUAGES_FRENCH - 文学院语言系法语课程
如何定义各个域？
各个机构管理是通过指定创建用户集、课程集、组织集、标签集和模块集的标准进行定义的。每个集都称为一个集合。一个机构管理可以包括一个或多个集合。机构管理结构被定义后，诸如用户和课程之类的项目即会在机构管理内被分组到集合中。添加集合便是一个以此类方式定义集合的过程，该集合包含每一个应包括的项目。当诸如用户或课程之类的新项目被添加到系统中时，它们会自动成为它们符合其集合标准的任何机构管理的一部分。因此，在定义使用标准的集合以及确定属于该集合的项目的规则时，确保新项目在创建时即被添加到集合是非常重要的。有一个单独添加项目的选项。单独添加项目的功能对于定义受限制的静态机构管理非常有用，可确保其他项目不会成为机构管理的一部分。
如果先分别为“机构角色”、“课程类别”和“组织类别”设置了模型，则定义机构管理便会变得更加容易。这些变量是完全可以定制的，并可用作在机构管理内定义集合的最灵活准确的方法。那些使用快照并使用来自其他系统的数据填充 Blackboard 数据库的这些机构也可以使用数据源密钥来定义集合。
最后，机构管理中的用户与课程和组织之间不存在任何关系。即，注册了课程的用户不会自动包含在机构管理中。在机构管理内，注册是由课程控制的。因此，拥有编辑用户权限的机构管理管理员不能更改用户在课程中的注册。但是，拥有编辑课程注册权限的机构管理管理员可以将用户包括在课程中，也可以将用户从课程中排除。
在定义集合时，请注意以下问题：
课程和组织
- 在该机构管理中定义课程和组织时可以使用哪些类别？
- 或者，除了类别以外，可以使用哪些数据源密钥在该机构管理中定义课程和组织？
- 机构管理是否应包括不可用的课程和组织？机构管理是否应包括禁用的课程和组织？考虑这一点非常重要，因为不可用的和已禁用的状态经常用来标记完整的、预计要进行存档的课程和组织。
- 机构管理中的课程和组织是否应受注册选项的限制（例如，学生可自行注册的课程）？
- 即使类别被嵌套在已经包括在机构管理中的类别内，课程和组织类别也必须单独添加。
用户
- 在该机构管理中，哪些机构角色可用于定义用户？
- 或者，除了机构角色以外，哪些数据源密钥可用于在该机构管理中定义用户？
- 用户也可以通过系统角色进行定义。但是定制的系统角色更可能会以权限为基础，因而它们通常不是在机构管理中定义用户的适合模型。使用“访客”或“旁听者”角色时，作为属性，“系统角色”极其有用。
- 机构管理是否应包括不可用的用户？机构管理是否应包括禁用的用户？考虑这一点非常重要，因为不可用的和已禁用的状态经常被用于标记要进行存档或删除的用户记录。
- 机构管理中的用户是否应受“保密选项”的限制？在用户目录之外选择的用户可从机构管理中排除。
标签和模块
- 机构管理中是否应包括不可用的标签和模块？这种方式允许用户创建标签和模块，但是它们被发布后，便不能再对其进行编辑。或者，一个机构管理只能包括可用资料。在这种情况下，生产中的不可用资料便不能被机构管理管理员编辑。
- 可对要包括在机构管理中的标签和模块进行单独选择。
例如，考虑使用课程和用户的集合填充 SLA_LANGUAGES 机构管理（其中包括系中所提供的所有课程以及在系里工作或将语言列为其研究专业的所有用户）。在这种情况下，课程集合可定义为：
类别：LANG、LANG_FR、LANG_DE、LANG_ES、LANG_JP、LANG_NL
可用性：忽略
已启用：仅启用
用户集合可定义为：
机构角色：DEPT_LANG、MAJOR_LANG
可用性：仅可用
已启用：仅启用
机构管理管理员需要哪些管理员任务？
定义集合后，便可以有把握地给系统角色分配适当的权限。机构管理管理员将被根据仅应用于该机构管理的系统角色授予权限。实质上，用户和系统角色被结合在一起来创建机构管理的委派管理员，而该管理员的权限是通过“系统角色”定义的。用户和系统角色的这种结合仅应用于该机构管理。
可以为每一个机构管理创建系统角色，但是基于可在每个机构管理中应用到管理员的权限来创建系统角色将会更加高效。由于系统角色是附加在机构管理中的，所以可以完全基于任务来创建系统角色模型，然后使用这些任务的组合将个性化的权限授予特定的委派管理员。
在创建系统角色时，请考虑以下事项：
- 机构管理管理员将使用何种管理任务？
- 完成这些任务需要哪些权限？
- 这些权限如何分组才能使各权限集完成一个或多个目标？集中是否有一些不总是适用的权限？
- “系统角色”如何命名？命名约定应该易于识别，并可定义权限集。
例如，创建一个名为 USER_MANAGER 的系统角色，该角色拥有管理用户帐户的完全权限。该系统角色便可用来在机构管理中授予机构管理管理员管理机构管理中所有用户帐户的能力。另一个系统角色 USER_PASSWORD 可被授予机构管理管理员，以允许该用户更改用户的密码，但是不能编辑关于用户记录的任何其他详细信息。
在 SLA_LANGUAGE 机构管理中，系主任可被授予 USER_MANAGER 角色，而助理则会被在机构管理中指定给 USER_PASSWORD 这一系统角色以回应更换丢失的密码的请求。
请记住，系统角色是附加的。如果用户已有一个 USER_PASSWORD 系统角色，之后又被授予另一个系统角色（该角色有编辑用户帐户某些方面的能力），则这两个角色都可用。也就是说，用户拥有被指定的所有系统角色的全部权限的总和。此外，如果用户的系统角色拥有在默认机构管理中指定的管理权限，则这些权限可应用于所有机构管理及系统中的所有数据。
被指定管理机构管理的用户有哪些？
机构管理不会被限制为拥有一个系统角色的一个管理员。相反，每个机构管理都可以有无限个管理员，而这些管理员又可拥有无限个系统角色。在一个机构管理中，不同的管理员被指定给不同的职责和任务。
以机构管理管理员的身份指定用户时，请考虑以下事项：
- 机构管理的哪些方面需要机构管理管理员？
- 在不引进额外的不必要权限或有潜在风险的权限的情况下，是否有特定的系统角色授予完成这些任务的权限。如果没有，请考虑修订系统角色的结构或创建新的系统角色来处理异常情况。
- 需要的任务是如何形成机构管理管理员的职责的？是否需要一个管理员来管理用户，而另一个则指定给课程？
- 应将谁指定到不同的机构管理管理员位置？
确定了充当机构管理管理员的人员和将要授予适当权限的系统角色之后，最后的步骤是将信息一起放置到机构管理中。例如：
机构管理：SLA_LANGUAGE
用户：系主任
系统角色：USER_MANAGER、COURSE_MANAGER、MODULE_CREATE、MODULE_MODIFY
