概述
主要采用RBAC设计模型进行设计，通过用户，角色，权限，实现对不同用户权限的分配。在表结构的设计中，因为用户表和角色表，角色表和权限表之间都是多对多的关系，我们可以在这两对关键表中分别设计一个中间表来确定这种关系。同时插入如下总结：（A:B=n:1 那么A表中就加入B表的数据作为外键，A:B=n:n那么A、B两表之间就需要一个中间表来决定这个多对多的关系）因此，我们可以大致的创建如下基本表：
- 用户表（sys_user{username(用户名也是唯一的), password, id(primary key),name, salt, sex, phone, emil, age, class,
course(针对于老师所教授的课程，老师和课程之间的关系是多对一，课程表中的id作为用户表中的外键)}）- 角色表（sys_role{id(primary key), name, datascope, createby, createtime, updatetime}）
- 权限表(sys_menu{id(primary key), name, fathered})。
- 中间表1（sys_user_role{user_id(用户表的id作为外键), role_id(角色表中的id作为外键)}user_id,role_id两个字段作为联合主键）
- 中间表2（sys_role_menu{role_id（角色表中的id作为外键），menu_id(菜单表中的id作为外键)}role_id,menu_id两个字段作为联合主键）
业务分析
在对系统的功能分析时候，我们发现，学生信息管理系统，管理的主要对象就是学生的信息，所以在分析需求时候也就着重的强调与学生有关的操作，像是：学生的班级，学生的课程。而学生的课程方面，又包含有学生的成绩……而这些属性字段，我们可以把其分为：课程表和班级表，但是由于该系统也不仅仅是学生使用，其中还会包括教师，教导主任，校长，而这些用户，对于班级表好像没有太大关系。所以我们可以提取每个用户的共同点，把这个班级表，设计成一个部门表，其中包括学生和教师的班级，年级主任的年级，校长的学校。同时，课程表与学生的关系是多对多的关系，因此两者之间需要有一个中间表，或者说课程表和用户表（学生表）之间需要有一个中间表来确定这种多对多的关系。
根据上述逻辑，我们设计出如下基本表：
- 课程表（sys_course{course_name, course_id, createtime, course_code）
- 班级表（部门表）（sys_class{calss_id（primary key）, class_name, calssfather, calsslist,
classteacher(这个字段只是针对于班级，而其他的像是年级，学校，在该字段上可以不用取值)}）- 中间表3（sys_user_course{user_id（用户表中的外键), course_id（课程表中的外键）, course_mark}(user_id和course_id为联合主键)）
权限分析
聊到权限，我们不仅仅是有菜单权限（用户可以进行什么操作）还需要有数据权限（用户进行了操作会拿到什么数据）。权限与角色的关系都是多对多的关系，因此我们需要在角色表和权限表中建立中间表，上面我们已经有建过权限表、角色表、中间表。
默认的数据权限
我们这里主要聊一聊数据权限，我们规定，默认的数据权限是用户可以拿到自己等级下的数据信息，和自己等级以下的数据信息。例如：超级管理员，自然是拥有所有的数据信息（一个学校的校长）；年级主任，拥有其自身的数据信息和其下所有老师，学生的数据信息；老师，拥有自身的数据信息和其下所有学生的数据信息，而学生仅仅是拥有自身的数据信息。这种默认的权限定义，在实现时，我们可以通过查询自身的等级号（班级号），通过班级号查询自身等级以下的等级号（班级号）。通过用户表对应的等级号（班级号），去查询用户的信息。拿年级主任举例，会先去查询主任所在的年级，通过年级查询到年级所有的班级，再查询到班级中的成员，包括学生和班主任。这种权限不需要再去额外建表，直接查询即可。
自定义数据权限
而对于想要自定义数据权限范围的需求我们应该怎么办呢？上面我们有聊到等级与数据权限的密切关系，可以通过等级来定义到数据的取值范围，因此我们需要另外去在等级（班级表）和角色（角色表）之间去建立一个中间表来记录这种由用户自定义的数据权限范围。为什么是角色呢，因为不同的角色权限不同，我们要设置新的数据权限，我们自然是需要定义一个新的角色，通过给目标用户分配这个新的角色什么，来做到自定义权限切实的分配给各个用户。这里我们建立一个自定义数据权限的中间表
- 中间表4（sys_role_class{role_id(角色表中的id), class_id(class表中的id)}(role_id和class_id作为联合主键)）
用户分析
上面我们有讲到过，学生信息管理系统是使用人群是学校的学生，教师，教导主任，校长。那么这些人群的关系应该怎么确定呢，可能会首先想到去放在角色表中，但是事实真的如此吗？角色表和权限表是有关联的，不同的角色，权限是不同的。我们抛开操作权限，和自定义数据权限，对于默认的数据权限，上面几个职位，实际上数据权限都是，用户可以拿到自己等级下的数据信息，和自己等级以下的数据信息。这些职位权限都是一样的，都应该是属于普通用户的权限。也就是说，学生，教师，教导主任都应该是普通用户这个角色（这里默认校长是超级管理员，拥有全部的数据权限）。因此为了把这些职位关系保存起来，我们选择再创建一个职位表，这时，我们应该分析职位表和用户之间的关系。每个人有不同的见解，因为难免会有学校身为教导主任，也会去教学。所以我们认为职位和用户之间应该是多对多的关系，因此，我们需要在用户表和职位表之间再次建立一个中间表来确定这种关系。（注意，这里的权限实际上都是相同的，权限范围都是本等级的内容和本等级以下的内容，所以整体上还是一个角色，而不是根据用户的职位去设计角色，当然角色和职位之间也是有一定的联系的，但是这并不代表不同的职位，角色就一定不同）建表如下：
- 职位表（sys_job{job_id, job_name, create_time, update_time}）
- 中间表5（sys_user_job{job_id(职位表的id作为外键), user_id（用户表的id作为外键）}（job_id和user_id作为联合主键））
总结
综上所述，我们大致的设计出起学生信息管理系统数据库中的一些关键的表。期间可能会有一些语言描述不当的情况，请多多包含，另外有不懂得地方也欢迎大家在评论区留言。上面表结构的创建，只是写出了大致的一些字段，可以通过具体的业务需求进行补充。同时，为了有良好的观感，选用了“引用”，但本片文章确实是本人自己学习时的所感所想，所以也可能会出错误，也希望各位同学在学习的过程中，发现我的错误可以及时指出。之后附上数据库的表结构：
