数据库课程设计心得【1】
本文写作的背景：
1、数据库课设做到一部分以后，感觉对需求的分析不够明确，
2、在后台数据库的存储过程，视图，触发器等等都没有做好，导致了在编写代码时临时改后台数据库，导致混乱。
3、并没有做到对系统的了然于胸，也就是思考不够，分析不够
本文主要目的是：
1、整理思路，重新分析整个系统的各个功能模块划分及其功能详细介绍
1、 系统管理员
Ø 用户管理模块：
用户管理模块主要是对用户的属性和权限进行管理，是系统的基础模块，功能由图3可见。由管理员添加的用户默认密码和用户名相同，修改密码只能由本人或者在数据库中修改完成。
Ø 课程管理模块：
管理员可以对课程进行增，删，查，改等操作。
Ø 教室管理模块：
管理员可以对教室信息进行增，删，查，改等操作。
2、 用户
Ø 用户管理模块：
学生可以查询自己的个人信息以及对自己的密码进行修改，丢失密码后可以找系统管理员获取密码。
Ø 课程管理模块：
学生可以查询任意一门课程的详细信息，包括：课程号、课程名称、讲授门课的老师。
Ø 教师管理模块：
学生可以查询任意一名老师的信息，包括：姓名、性别、职称、开课信息。
Ø 教室管理模块：
教室信息查询：学生可以查询某一教学楼某一教室的信息以及该教室在每一天任意时段的使用情况（有课、有讲座、有活动等等）。
借用教室：学生可以借教室，即获得教室在某段时间的使用权，办讲座，开办社团活动等，如果申请的教室有冲突，请给出提示。
我要上自习：学生可以查询当天某一时段或者多个时段的空闲教室，然后去上自习
2、构造概念结构图（E-R图的绘制）
3、根据E-R图构建表结构
转换的原则：
（1）、每一个实体都要单独建表
（2）、对于一对多联系的处理，在n端实体的表里面加上一个字段（1端实体的主码）作为外码
（3）、对于多对多联系的处理，要单独建表
（4）、对于一对一联系的处理，将一个1端实体的码加入到另一个1端实体的表里面作为外码
4、修改数据库
问题：数据库的完整性如何体现，实体完整性，参照完整性各是什么含义？外码是否可以为空？
如何确定某个字段是否允许空值？
解答：
数据库的完整性是指数据的正确性和相容性；
数据库的完整性通过实体完整性和参照完整性体现；
实体完整性：主码的各个属性不能为空和主码值唯一
参照完整性：当更新、删除、插入一个表中的数据时，通过参照引用相互关联的另一个表中的数据，来检查对表的数据操作是否正确。 简单的说就是表间主键外键的关系。
外码有时可可以取空值，因此，为了稳妥，在设计数据库时我选择所有的外码都不许为空。以下蓝色字体为我找的比较有效的资料，感谢提供资源的大神~~~~
DBMS的完整性控制机制应具有三个方面的功能：
⑴ 定义功能，提供定义完整性约束条件的机制。
⑵ 检查功能，检查用户发出的操作请求是否违背了完整性约束条件。
⑶ 保护功能，如果发现用户的操作请求使数据违背了完整性约束条件，则采取一定的动作来保证数据的完整性。
完整性约束条件包括有六大类，约束条件可能非常简单，也可能极为复杂。一个完善的完整性控制机制应该允许用户定义所有这六类完整性约束条件。
检查是否违背完整性约束的时机通常是在一条语句执行完后立即检查，我们称这类约束为立即执行约束（Immediate Constraints）。有时完整性检查需要延迟到整个事务执行结束后再进行，检查正确方可提交，我们称这类约束为延迟执行约束（Deferred Constraints）。如银行数据库中“借贷总金额平衡”就是延时执行约束。从帐号A转帐到帐号B是一个事务，从帐号A转出后帐不平衡，必须等到转入帐号B后才能平衡，这时才能进行完整性检查。如果违背了完整性约束条件，系统将拒绝操作，对于延迟执行约束，系统将拒绝整个事务，把数据库恢复到事务前的状态。
关系系统中，最重要的完整性约束是实体完整性和参照完整性，其他完整性约束条件则可以归入用户定义的完整性。
实体完整性：基本关系的所有主属性都不能取空值，以便唯一地标识实体。
参照完整性：若属性或属性组F是基本关系R的外码，它与基本关系S的主码K相对应，则对于R中的每个元组在F上的值必须为空值或等于S中某个元组的主码值。其中S和R可以是同一关系。参照完整性定义了外码和主码之间的引用规则。
用户定义完整性：除了实体完整性和参照完整性外，针对某一具体的关系数据库，如果需要一些特殊的约束条件，用户可以自行定义其约束条件。
目前DBMS系统中，提供了定义和检查实体完整性、参照完整性和用户定义完整性的功能。对于违反实体完整性和用户定义完整性的操作，一般拒绝执行，而对于违反参照完整性的操作，不是简单的拒绝，而是根据语义执行一些附加操作，以保证数据库的正确性。
下面详细讨论实现参照完整性要考虑的几个问题。
1. 外码能否为空值问题
例如：学生-班级关系中，学生关系student和班级关系class,其中class关系的主码为班级号cno,student关系的主码为学生号sno,外码为班级号cno,称class为被参照关系,student为参照关系。student关系中某一元组的cno列值若为空值，表示这个学生还没有分配到任何班级。这个和应用环境的语意是相符的，因此student的cno列可以取空值。
在客户-订单关系中，包含客户关系client和订单关系order，client关系为被参照关系，其主码为客户编号cno。order为参照关系，主码为订单编号ono，外码为订单客户编号cno。若order中元组的cno为空值的话，则表明存在没有客户的订单。这与实际的应用环境是不相符合的，因此order的cno列不能取空值。
因此在实现参照完整性时，系统除了提供定义外码的机制外，还应提供定义外码是否允许空值的机制。
2. 在被参照关系中删除元组的问题
当删除被参照关系的某个元组时，而参照关系存在若干元组，且其外码值与被参照关系中删除元组的主码值相同。如：员工和部门关系，部门dept关系中，部门编号dno是主码；员工employ关系中，员工编号eno是主码，员工所在部门dno是外码，对应dept中的主键。删除dept部门编号dno=9999的部门，而employ中存在dno=9999的8名员工。这时可有三种不同的删除策略：
(1)级联删除(CASCADES)
将参照关系外码值与被参照关系中要删除元组主码值相同的元组一起删除。如上例中，删除关系dept中dno=9999的部门，同时删除employ中8名dno=9999的员工。
(2)受限删除（RESTRICTED）
仅当参照关系中没有任何元组的外码值与被参照关系中要删除元组的主码值相同时，系统才执行删除操作，否则拒绝此删除操作。如上例中，删除关系dept中dno=9999的部门时，检查employ中是否有dno=9999的员工，如果有则不能删除，只有先删除employ中dno=9999的8名员工，然后才能删除关系dept中dno=9999的部门。
(3)置空值删除（NULLIFIES）
删除被参照关系的元组，并将参照关系中相应元组的外码值置空值。如上例中，删除关系dept中dno=9999的部门时，检查employ中是否有dno=9999的员工，如果有将employ中dno=9999员工的dno设置为NULL。
3. 在参照关系中插入元组时的问题
当参照关系插入某个元组，而被参照关系不存在相应的元组。如向关系employ中插入部门编号dno=9999,员工编号eno=1968的元组(1968，9999)，而关系dept中没有dno=9999的部门。这时可有以下两种插入策略：
(1)受限插入
仅当被参照关系中存在相应的元组，其主码值与参照关系插入元组的外码值相同时，系统才允许插入，否则拒绝插入。在上例中，系统拒绝插入employ元组(1968，9999)，因为被参照关系dept中没有dno=9999的元组。
(2)递归插入
首先向被参照关系中插入相应的元组，其主码值等于参照关系插入元组的外码值，然后向参照关系插入元组。在上例中，系统先在dept中插入dno=9999的元组，然后在关系employ中插入元组(1968，9999)。
4. 修改关系中主码的问题
(1)不允许修改主码
在有些RDBMS中，不允许修改关系主码。如上例中不能修改dept关系中的部门编号dno。如果要修改，只能先删除，然后再增加。
(2)允许修改主码
在有些RDBMS中，允许修改关系主码，但必须保证主码的唯一性和非空，否则拒绝修改。当修改的关系是被参照关系时，还必须检查参照关系。如上例中修改dept中的dno=9999为dno=8888,检查employ关系中是否有dno=9999的元组，如果存在，则与删除策略相同。当修改的关系是参照关系时，要检查被参照关系。如学生-选课关系中，选课关系elective中的学生号sno和课程号cno联合为主码，sno也是外码，对应student中的学生编号sno。如果选课elective关系中的(90211111,20,90)改为（90212222，20，90），检查student关系中是否存在sno=90212222的主码值，否则与插入策略相同。
从上面的讨论我们看到DBMS在实现参照完整性时，除了要提供定义主码、外码的机制外，还需要提供不同的策略供用户选择。选择哪种策略，都要根据应用环境的要求确定。