教务系统数据库设计的几点感受
鉴于教务系统基础数据库的构建整整用了我们一个月时间，为了这一个月，也需要写篇博客总结一下。首先说一下教务系统现有部分，方便对下面内容的说明：教务系统包括四部分：基础系统、考试系统、评教系统、选课系统，其中基础系统用于对基础数据的维护，其它系统看只看系统名就可以知道其功能。
命名数据库设计的第一步就是怎么命名，第一版的命名规则是：
T_表示表类型，V_表示视图类型E_表示实体表，R_表示关系表K_表示考试系统表，B_表示基础系统表，C_表示选课系统表 于是一张表的命名就可以使T_E_K_ExamStudent，最开始会这种命名方法得意：数据库中，表可以按命名规则自动排序。但是问题出来了，这样命名，一条简答SQL语句就会成为：基础数据由基础系统维护，例如：学生信息、教师信息、班级信息等，负责对这些信息的增删改查。其它系统有自己的表，对于基础信息，其它表只有读取的权利，不能修改或是删除。
教务系统中的表设计如下图：
即实体表之间不能直接有关联，都是通过第三张关系表关联。这与以前的数据库设计有很大的区别，以前只有表数据为多对多时，才用第三张表关联；但现在是只要两张表有关系，不管是一对多还是多对多，都是通过第三张表关联。
这样设计的好处是，加入某个学院下不再有某个专业时，只需把关系表中的数据删除即可，两个实体表都不要改变，这样可以充分保证表之间的独立性和扩展性，而这正是基础数据最重要的因素。
讨论当初设计数据库时，分歧很大的一个问题是，基础数据库表字段丰富好还是精简好？例如，学生表要不要包含身份证号、邮箱等字段？
一种方案是，精简型，当需要额外添加字段时，这些字段添加到新建的关系表中；另外一张方案是丰富型，认为是应该把所有能用到或是暂时用不到的字段添加到实体表中。因为把实体字段存在于关系表中，造成的数据冗余大于在实体表中，所以经过讨论采用的是丰富型。
现在想想当初为什么会产生这个讨论，很大程度上是因为设计数据库时直接跨越到了逻辑设计阶段，忽视了概念设计阶段，由此产生了对实体属性的讨论。
补充到此阶段对教务系统基础数据库设计已经结束，在此需要再补充几点：
历史数据处理，不能删除数据，但是可以转移到历史表中，方便以后统计查询。子系统表、功能表，每个系统都是独立的子系统，所以需要有一张表，记录每个系统名称、logo、发布地址、发布时间、是否可用等字段，保证界面可以动态加载子系统。记录每个操作，对系统的每个操作，例如登录、增加记录、修改、删除等都应该记录时间、权限、用户、机器等信息。对每个实体的操作，只要权限足够，都能进行增删改查操作。同时因为一般用户不能修改数据库，只能通过系统间接修改数据，所以对每个实体的增删改查操作都要体现到界面上。 教务系统数据库就总结到这里，这次设计的感触很深的是：尽信书不如无书，站在已有的理论上很重要，但不要把自己绑在上面，因地制宜灵活运用才能切合实际使用。
