数据组织：科目、教师、班级、课表

Omniscol区分两个组织层级：一是由管理模块承载的学校基础数据（科目、用户、学年等），它长期描述您的学校；二是课表，它从基础数据中取用部分元素，在特定时期内构建一份连贯的安排。理解这种二元结构，是从容应对各种变更（重命名科目、调整教师、归档课表）而不破坏历史记录的关键。

总览：两个层级，两套逻辑

学校层级：一套全局的、长期有效的基础数据，在管理模块中管理。它包含与具体课表无关、对学校始终成立的内容——学年日历、科目目录（全国通用科目加学校自定义科目），以及用户名录（含角色）。

课表层级：某一时期内连贯的排课安排。每份课表都有自己的教师、班级、小组、挂在班级下的科目以及课时的列表。这些对象并不是对学校基础数据的简单引用，而是本地副本，可以在不修改基础数据的情况下进一步补充信息。反过来，学校层级的基础数据也可以变化（删除科目、教师），而不会破坏过去的课表。

下文逐一详述各类关联。

学年：时间框架

学年定义了一个 开始日期 → 结束日期 的范围以及假期列表（参见学年）。它并不直接“包含”课表：课表是铺展在属于某个学年的若干周（周课表 / 周期课表模式）或若干日期（日历课表模式）之上的。

这使得多种配置成为可能：

• 每个学年一份课表（标准情形）：课表覆盖学年中所有工作周。
• 同一学年内先后多份课表：例如每个教学阶段一份，在切换日期接力。
• 同一时期并行多份课表（Premium功能已包含；部分Standard账户在合适的合同框架下可以启用），例如：
  • 一份用于重复出现的公共基础课的课表
  • 一份用于大师课的日历课表，查看时合并显示。

参见同时发布多份课表。

因此，学年始终是一个框架，而不是容器。修改它的起止日期或假期，会更新与之关联的课表所使用的日历，但不会改变课表的内容。

科目：从学校目录到班级的课时

第一级——管理模块中的目录

在学校层级，有两种来源并存：

• 通用科目：Omniscol为所配置国家提供的基础数据（官方代码、规范名称）。该目录对学校是只读的。
• 已创建科目：学校自己创建的科目，在科目管理（官方科目与自定义科目）页面中管理。每个自定义科目有名称、代码（简短），还可以选填：简称、专属颜色、上级科目、科目族。

这个目录并不说明哪些班级教授这些科目——它只说明这些科目存在。

科目族既可以来自按国家共享的只读基础数据，也可以来自学校本地的自定义基础数据。

第二级——分配给班级（含或不含类型）

在课表中把一个科目分配给班级时，系统会在该班级内创建该科目的一份本地副本，并补充排课专用的字段（目标小时数、教学比重、不兼容、默认教师、教室专业类型……）。

如果分配科目时带有课时类型（讲授课、习题课、实验课、考试——参见课时类型），每种类型都会在班级中创建一个独立的条目：

这是有意设计的：每个变体（数学讲授课、数学习题课）都是独立的本地副本，拥有各自的小时数、教师和不兼容。与目录的关联并非强依赖：只要该科目仍存在于目录中，本地副本就会保留其来源。如果该科目从目录中被删除，各课表中的本地副本仍然有效。

第三级——从课程参数到课时

在Omniscol中，通常所说的课程，一般是指分配给某个班级的科目，可选地带有课时类型（讲授课、习题课、实验课……），再补充排课信息：小时数、教师、小组、排布约束、教室或资源。

这一定义说明了需要安排什么。课时则是真正落在课表上的具体实例，对应某一周或某一天。

例如：班级科目**数学 [习题课]**可以定义小时数、教师、小组、排布约束和教室偏好，随后课时便根据这一定义创建。参见课程、课时、课时类型。

教师：学校基础数据 → 课表中补充信息的副本

学校层级的教师

在学校层级，教师是拥有 teacher 角色的用户（同一用户可以兼有多个角色——参见用户与角色）。教师在教师管理页面中管理，保存着长期有效的标识信息：姓名、登录名、邮箱、编号，以及他的全局可用时间（重复性的）和参考服务时间。

分配到课表的教师

将该教师分配到某份课表时，Omniscol会在课表中创建一份补充信息的部分副本。副本只取基础数据中的部分字段，并加上排课专用字段：

这种二元结构很重要：同一位教师在不同的排课范围内可以有不同的服务时间，或在某个时期有不同的首选教室（例如因临时残疾）。

对于可用时间，处理逻辑取决于排课模式：

• 重复模式下，教师填写的可用时间需经过管理部门的审核。可以在课表中进行本地调整，例如把严格的不可用改为不希望安排的时段；
• 日历模式下，教师的可用时间被视为唯一的数据来源，对外聘教师尤其如此。可以在用户详情中，或在该教师所分配的任何日历课表中查看和修改。

两种情形下，某些参数都仍然属于课表专属，可以在本地补充这些可用时间。

虚拟教师

还有一种变体：可以在课表中创建虚拟教师——一个待招聘的岗位，背后没有真实用户（“未来的数学教师”）。他在学校层级没有对应项。招聘到人之后，您可以用一位真实的教师用户替换这位虚拟教师（参见第3步——分配教师）。

本地副本原则小结

班级中的科目和课表中的教师遵循同样的逻辑：分配时创建一份本地副本，由这份本地副本承载课表专属的字段。

这样设计的原因：

• 时间上的独立性。 去年已结束的课表，不应因为今年重命名了某个科目或教师而改变。本地副本保证了历史完整性：当时怎么排的，就保持原样。
• 结合情境的补充。 教师在不同的排课范围内，可用时间和服务时间不同；科目在不同的班级中，教学比重和不兼容也不同。本地副本是承载这些差异的天然位置。
• 清理而不出错。 在学校层级删除或重组某个科目，不会抹掉使用过它的课表——它们的本地副本仍然有效。

作为代价，学校层级的重命名不会悄无声息地传播到各处。这正是下一节的内容。

实际影响：重命名、删除、历史记录

当您修改学校层级的某个实体时，Omniscol遵循明确的传播规则：

“过去”与“进行中或未来”的区分以当天日期为准：一份已发布的课表，如果最后一个已发布的周早于今天，就被视为过去，不再受重命名影响。

何时需要手动同步

自动传播有意保持范围很窄：科目的名称、代码和颜色；教师的姓名和标识符。本地复制的科目，其名称和代码不会在课表中修改；只有颜色可以在本地重新设置。其他字段（不兼容、教学比重、服务时间、各课表的可用时间……）不会同步，因为它们本质上属于课表专属。

如果某项更深入的变更需要应用到多份现有课表（例如：在所有已发布的课表中调整某位教师的服务时间，或在各处新增一条科目不兼容），就必须逐份课表操作。对于批量操作，最快的工具仍然是在每份课表的相应页面上从电子表格复制粘贴导入。