教务系统数据库设计的几点感受

        鉴于教务系统基础数据库的构建整整用了我们一个月时间，为了这一个月，也需要写篇博客总结一下。首先说一下教务系统现有部分，方便对下面内容的说明：教务系统包括四部分：基础系统、考试系统、评教系统、选课系统，其中基础系统用于对基础数据的维护，其它系统看只看系统名就可以知道其功能。

命名

        数据库设计的第一步就是怎么命名，第一版的命名规则是：

• T_表示表类型，V_表示视图类型
• E_表示实体表，R_表示关系表
• K_表示考试系统表，B_表示基础系统表，C_表示选课系统表

        于是一张表的命名就可以使T_E_K_ExamStudent，最开始会这种命名方法得意：数据库中，表可以按命名规则自动排序。但是问题出来了，这样命名，一条简答SQL语句就会成为：

SELECT * FROM T_E_K_ExamStudent

        如果再加上跨表查询，得多少个_，这不是为自己找罪受吗？再说K是考试拼音第一个字符，而B表示英语Basic的第一个字符，中英文混乱，修改后，最终的命名规则为：

• T表示表类型，V表示视图类型
• 实体表没有前缀，R表示关系表，H表示历史表
• E表示考试系统，A表示评教系统，C表示选课系统

        这时，一条SQL语句可以是

SELECT * FROM TE_ExamStudent

        这样的语句，清晰、易写、容易维护。

设计

        教务系统整体设计如下图：

        

        基础数据由基础系统维护，例如：学生信息、教师信息、班级信息等，负责对这些信息的增删改查。其它系统有自己的表，对于基础信息，其它表只有读取的权利，不能修改或是删除。

        教务系统中的表设计如下图：

        

        即实体表之间不能直接有关联，都是通过第三张关系表关联。这与以前的数据库设计有很大的区别，以前只有表数据为多对多时，才用第三张表关联；但现在是只要两张表有关系，不管是一对多还是多对多，都是通过第三张表关联。

        这样设计的好处是，加入某个学院下不再有某个专业时，只需把关系表中的数据删除即可，两个实体表都不要改变，这样可以充分保证表之间的独立性和扩展性，而这正是基础数据最重要的因素。

讨论

        当初设计数据库时，分歧很大的一个问题是，基础数据库表字段丰富好还是精简好？例如，学生表要不要包含身份证号、邮箱等字段？

        一种方案是，精简型，当需要额外添加字段时，这些字段添加到新建的关系表中；另外一张方案是丰富型，认为是应该把所有能用到或是暂时用不到的字段添加到实体表中。因为把实体字段存在于关系表中，造成的数据冗余大于在实体表中，所以经过讨论采用的是丰富型。

        现在想想当初为什么会产生这个讨论，很大程度上是因为设计数据库时直接跨越到了逻辑设计阶段，忽视了概念设计阶段，由此产生了对实体属性的讨论。        

补充

        到此阶段对教务系统基础数据库设计已经结束，在此需要再补充几点：

• 历史数据处理，不能删除数据，但是可以转移到历史表中，方便以后统计查询。
• 子系统表、功能表，每个系统都是独立的子系统，所以需要有一张表，记录每个系统名称、logo、发布地址、发布时间、是否可用等字段，保证界面可以动态加载子系统。
• 记录每个操作，对系统的每个操作，例如登录、增加记录、修改、删除等都应该记录时间、权限、用户、机器等信息。
• 对每个实体的操作，只要权限足够，都能进行增删改查操作。同时因为一般用户不能修改数据库，只能通过系统间接修改数据，所以对每个实体的增删改查操作都要体现到界面上。

        教务系统数据库就总结到这里，这次设计的感触很深的是：尽信书不如无书，站在已有的理论上很重要，但不要把自己绑在上面，因地制宜灵活运用才能切合实际使用。
        

1楼caozhangyingfei0109昨天 21:23

话说，好繁琐啊