도메인 구조화
관리 모델 구성
작은 정보
Blackboard는 대부분의 경우 도메인 대신 교육 기관의 계층 구조 기능을 사용할 것을 권장합니다. 기관 계층 구조를 사용하면 다른 Blackboard 기능을 더 효과적으로 활용할 수 있으며, 사용자 정의 규칙 기반의 로직이 필요하지 않습니다.
교육기관의 조직 요구 사항에 부합하는 관리 모델을 개발하는 것이 도메인 사용에서 가장 중요합니다. 이 주제는 교육 기관의 행정적 요구 사항을 고려하는 과정을 안내합니다. 각 단계마다 물어볼 질문과 간단한 예시가 포함되어 있습니다.
관리 모델에 대해 생각을 시작하는 데 도움이 되는 도구임을 기억하세요. 교육기관에 적합한 맞춤형 해결책을 위한 기회를 제공하는 도메인의 유연성과 무제한 시스템 역할.
캠퍼스 내에서 도메인 관리가 필요한 그룹은 무엇인가요?
위임된 관리 모델을 설정하는 첫 번째 단계는 해당 도메인에 제한된 권한을 가진 위임된 관리자가 지원할 수 있는 교육기관 그룹을 정의하는 것입니다. 도메인은 사용자, 강좌, 조직, 탭 및 모듈 조합을 포함할 수 있어 구조가 무제한적일 수 있다. 일부 교육 기관은 도메인을 사용하여 학생, 교직원, 졸업생, 교직원 간 사용자 관리를 분리하는 방식을 선택할 수 있습니다. 교육 기관 내에서 도메인을 활용해 학과별 과정 관리를 분리할 수 있습니다. 교육 기관에서 두 가지 모델을 동시에 적용할 수 있으며, 학과 도메인 관리자는 해당 부서 사용자를 관리할 수 있습니다. 각 부서를 별도의 도메인으로 구분할 수도 있습니다. 탭과 모듈 콘텐츠를 관리하는 도메인이 있고, 코스를 관리하는 다른 도메인 및 사용자를 처리하는 또 다른 도메인이 있습니다.
도메인 유연성은 도메인을 생성하고 관리 권한을 할당하기 전에 명확한 목표와 구조를 필요로 합니다. 도메인을 적절히 생성하고 정의하지 않으면, 관리하기 어려운 시스템이 될 가능성이 높습니다. 캠퍼스 내 필요한 도메인 그룹을 정의할 때 다음 질문을 고려하세요.
기관은 어떻게 조직되고 관리되는가? 기능 그룹별로 도메인을 만드는 것이 합리적인가요? 이 질문을 학과를 넘어 고려하며 학습 사명을 지원하는 캠퍼스 내 그룹에 대해 생각해 보십시오.
교육기관의 역할은 Blackboard 내에서 사용자를 어떻게 정의하는 데 사용됩니까? 예를 들어, 사용자는 전공, 위치, 학습 연도 및 기타 변수에 따라 조직되어 있는가?
기관에서 개인은 어떻게 관리되나요? 사용자 집합이 기능 그룹별로 다르게 관리되나요? 동문 관계를 처리하는 동창 사무소가 있나요? 예비 학생은 입학 부서에서 담당하나요?
콘텐츠가 탭 및 모듈에 표시될 때 책임을 지는 주체는 누구인가요? 교육기관 역할이 콘텐츠를 볼 수 있는 대상을 정의하는 데 어떻게 사용되나요?
다른 정보 시스템이 Blackboard와 데이터를 공유하고 있습니까?
캠퍼스 내 그룹에는 위임된 관리가 필요한 하위 그룹이 있을 가능성이 매우 높습니다. 하위 그룹은 도메인 내에서 중첩될 수는 없지만 도메인의 계층 구조를 만드는 데 장애가 되지는 않습니다. 도메인은 컬렉션으로 구성되며, 코스나 사용자와 같은 단위가 여러 컬렉션에 나타날 수 있기 때문에, 다른 도메인의 하위 그룹으로 구성된 도메인을 쉽게 정의할 수 있습니다. 도메인 간 통합을 위해 적절한 구조를 유지하려면 명명 규칙을 개발해야 합니다. 교양 학교에서는 여러 학과에 속한 하위 도메인이 있을 수 있다.
도메인은 다음과 같은 명명 규칙을 따를 수 있습니다.
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