数据库课程设计饭卡充值系统.doc

摘要本报告是利用SQL语言设计的一个饭卡充值系统，其中包括学生，卡务中心，饭卡，卡的消费记录和卡的充值记录这五个实体，实现该系统的管理功能，即对相关信息的修改、查询和详细信息列表功能。报告首先分析了用户的需求，列出在饭卡充值系统中，除可以实现充值功能外，还有可以查询学生信息、消费信息和充值信息这些功能，将其进一步完善。然后设计出系统的功能结构图，再对系统进行了概念结构设计，设计出系统的数据结构即关系模式，根据这些模式创建了学生信息、饭卡信息、卡的消费信息和卡的充值信息五个基本表对象；同时，利用这些表对象，创建了满足用户需要的充值，查询对象；创建了用于信息编辑和浏览的用户窗体，其中包含如控制面板一样的主窗体；创建了供集中浏览的报表对象。最后，使用SQL语言创建了饭卡充值基本信息管理窗体。关键词：饭卡充值，管理系统，数据库，SQL语言 小组情况此次的数据库课程设计，我们小组在一起团结合作，这次课程设的内容是设计一个饭卡充值管理系统，主要实现的功能有：饭卡信息管理，持卡者信息管理，用户管理，饭卡历史记录管理。本系统是通过小组全体成员的共同努力，在过程中我们遇到了诸多的困难和问题，但从中也得到了一些重要而且很有意义的收获。经过详细、认真严谨的讨论后，分工具体情况如下：合作部分包括前期对整体框架的确定，整体流程的设想，需求分析，概念结构设计，逻辑结构设计和整个报告的撰写、修改分工部分在数据库系统的总体方案确定之后，经过全体组员的高度认可，小组成员开始着手具体的工作，独立完成不同的工作，具体分工如下：卢德华：系统概念与物理设计刘振华：系统数据字典，数据模式优化和代码设计伍泽标：数据处理陈 涛：系统数据字典廖益鹏：数据流图的设计，代码设计张国兴：数据的安全性和完整性设计目 录1前言12需求分析22.1系统功能22.2信息要求32.3数据流程图42.4数据字典62.4.1数据项62.4.2数据结构82.4.3数据流92.4.4数据存储132.4.5数据处理142.5安全性173概念结构设计183.1系统局部E-R图183.2实体之间的关系及E-R图203.3系统全局E-R图214逻辑结构设计224.1数据模型的优化225物理结构设计245.1确定数据库的物理结构245.2信息储存位置255.3系统配置256数据完整性约束277数据库设计297.1系统的安全性设计代码297.2数据库设计代码（包括完整性设计）308心得体会32参考文献331前言随着人们对资源的整理利用，数据库的应用越来越广泛。从小型的单项事务处理系统到大型复杂的信息系统都用先进的数据库技术来保持系统数据的整体性、完整性和共享性。数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。2需求分析 2.1系统功能饭卡充值管理系统是一套针对大学校园食堂饮食交费的信息管理系统，它是对学生在校园内使用饭卡的相关情况的存储，查询。就是说在充值的过程中，能够实现对学生信息管理，饭卡信息管理和饭卡历史记录管理、用户管理这四个功能。这样就方便对饭卡信息进行各项操作，定时进行数据的备份和更新，保持数据的一致性和准确性。另外，各方面的内容相互联系，最终产生各种查询统计表，以供持卡者进行检查。以下是对四项功能的详细说明学生信息管理：包括学生信息的注册，查询，修改饭卡信息管理：包括饭卡的消费，充值，加锁和解锁（挂失）饭卡历史记录管理：包括饭卡历史记录的查询，修改用户管理：包括管理员的登录，权限以上的需求分析可以总结为如图2.1所示的功能结构图图2.1 功能结构图2.2信息要求 饭卡充值管理系统需要体现学生的信息和饭卡的一些消费、充值情况，在经过详细的调查、仔细的分析后，得到以下信息： 学生基本信息包括：学号、姓名、学院、性别、年级等； 饭卡内基本信息包括：卡号、学号、余额 管理员基本信息包括：员工号、姓名、性别 卡的历史记录基本信息包括：卡号、时间、发生额2.3数据流程图管理员1.0核对信息修改充值/挂失消费饭饭卡管理系统卡信息管理系统4.0历史纪录管理2.0饭卡内信息管理3.0学生纪录管理消费纪录充值纪录消费充值挂失注册查询学生饭卡信息管理系统刷卡器学生信息管理员饭卡信息管理员系统信息管理员 图2.3.1顶层数据流程图图2.3.2第二层数据流程图：管理员登录图2.3.3第三层数据流程图：饭卡信息管理图2.3.4第四层数据流程图：学生信息管理图2.3.5第五层数据流程图：饭卡历史记录管理2.4数据字典2.4.1数据项数据项：学号含义说明：唯一标识学生别名：学生编号类型：字符型长度：10取值范围：00000000019999999999取值含义：前一位标识学生所在年级，后九位按顺编号。数据项：姓名含义说明：唯一标识学生称呼别名：学生姓名类型：字符型长度：8取值含义：以学生身份证的实际姓名输入数据项：学院含义说明：标识学生所在学院别名：学校分院类型：字符型长度：8取值含义：按学生实际就读的学校学院输入数据项：性别含义说明：个人身份证上的性别别名：个人性别类型：字符型长度：2取值范围：男、女取值含义：以学生身份证的实际性别输入数据项：年级含义说明：学生在校就读的年级别名：就读年级类型：字符型长度：1取值范围：16取值含义：仅代表一年级到六年级数据项：卡号含义说明：唯一标识每张卡别名：饭卡编号类型：字符型长度：10取值范围：00000000019999999999取值含义：按顺序排列数据项：余额含义说明：标识卡内实际可用金额别名：剩余金额类型：字符型长度：5取值范围：0.1999.9取值含义：按实际卡内所存在可用的金额数据项：员工号含义说明：为饭卡充值系统里的用户管理员工编号别名：用户员工编号类型：字符型长度：2取值范围：A1A9，S1S2,U1U9取值含义：前面的英语A为充值管理员编号，S为学生信息管理者编码，U为饭 卡信息管理者编号，三者后的数字按顺序编号数据项：时间含义说明：所发生的行为的具体年、月、日别名：发生行为时间类型：日期型取值范围：2012年1月1日开始取值含义：按照实际所发生的时间输入数据项：发生额含义说明：所发生的行为具体为充值行为还是消费行为别名：无类型：字符型长度：5取值范围：-999.9-0.1,0.1999.9取值含义：负数值为消费行为扣除的金额，正数值为充值行为增加的金额2.4.2数据结构“饭卡信息”是该系统中的一个核心数据结构数据结构：饭卡信息含义说明：是饭卡充值系统的主体数据结构，定义了一张饭卡的有关信息组成：卡号，学号，余额数据结构：学生含义说明：定义了一个在饭堂消费的学生的有关信息组成：学号，姓名，性别，学院，年级数据结构：管理员含义说明：定义了饭卡充值系统分配好的管理者组成：员工号，姓名，性别数据结构：卡的历史记录含义说明：定义了每张饭卡的操作行为、发生额和操作时间等信息记录组成：卡号，时间，发生额2.4.3数据流数据流：登记新消费学生信息说明：为新在饭堂消费的学生登记信息来源：申请去向：登记组成：学号、姓名、性别、学院、年级平均流量：2000峰值流量：20000数据流：查询学生信息说明：显示在饭堂消费的学生的有关信息来源：查询去向：批准组成：学号、姓名、性别、学院、年级平均流量：1000峰值流量：3000数据流：删除学生信息说明：为已经不在饭堂消费的学生删除信息来源：删除去向：批准组成：学号、姓名、性别、学院、年级平均流量：1000峰值流量：20000数据流：注册饭卡说明：获取一张新的饭卡来源：注册去向：批准组成：卡号、学号、姓名、余额平均流量：5000峰值流量：10000数据流：建立卡的历史记录说明：对新注册的饭卡建立只属于该卡的历史记录来源：申请去向：批准组成：卡号、时间、发生额平均流量：5000峰值流量：10000数据流：充值饭卡说明：对饭卡金额新充入新增加的数值来源：充值去向：更新记录组成：卡号、时间、发生额、余额平均流量：5000峰值流量：10000数据流：消费说明：学生在饭堂内进行的消费的有关信息来源：消费去向：扣除组成：卡号、时间、发生额、余额平均流量：30000峰值流量：50000数据流：查询历史记录说明：显示饭卡做进行过的行为的有关信息来源：查询去向：批准组成：卡号、时间、发生额平均流量：200峰值流量：1000数据流: 挂失饭卡说明：对丢失的饭卡进行加锁处理来源：挂失去向：批准组成：卡号、学号、姓名、余额平均流量：5000峰值流量：10000数据流：锁信息说明：显示卡是否上锁来源：挂失去向：饭卡信息数据组成：卡号、学号、姓名、余额平均流量：200峰值流量：10000数据流：查询饭卡信息说明：显示饭卡的基本信息来源：查询去向：批准组成：学号、学号、姓名、余额、时间、发生额平均流量：5000峰值流量：10000数据流：注销信息说明：学生申请注销饭卡来源：注销去向：批准组成：卡号、学号、姓名、余额平均流量：300峰值流量：10000数据流：登记管理者说明：把有一定权限管理系统的员工有关信息登记来源：登记去向：批准组成：员工号、姓名、性别数据流：删除管理者说明：把有一定权限管理系统的员工有关信息删除来源：删除去向：批准组成：员工号、姓名、性别数据流：查询管理者说明：显示有一定权限管理系统的员工的有关信息2.4.4数据存储数据存储：学生信息表说明：记录学生的基本情况流入数据流：登记学生信息，删除学生信息流出数据流：查询学生信息组成：学号、姓名、性别、学院、年级数据量：每年10000存取方式：随机存取数据存储：饭卡信息表说明：记录饭卡的基本情况流入数据流：注册饭卡，充值饭卡，注销饭卡流出数据流：查询饭卡信息组成：卡号、学号、姓名、余额数据量：每月200张存取方式：随机存取数据存储：锁信息说明：显示饭卡信息是否锁定流入数据流：挂失饭卡流出数据流：锁信息数据存储：卡的历史记录表说明：记录饭卡历史记录流入数据流：建立卡的历史记录，充值饭卡，消费流出数据流：查询卡的历史记录组成：卡号、时间、发生额数据量：每月20000张存取方式：随机存取数据存储：管理员说明：记录饭卡充值系统管理员的基本情况流入数据流：登记管理者，删除管理者流出数据流：查询管理者组成：员工号、姓名、学号存取方式：联机存取2.4.5数据处理处理过程：登记学生信息简要说明：把学生的相关信息进行登记并创建学生信息表输入：学生的相关信息输出：学生信息表处理：登记得到学生的相关信息后，为学生创建学生信息表，要求按照系统的数 据完整性登记，要求学生的信息必须与该学生在校的学生信息一致，学生 信息的登记时间不超过5分钟。处理过程：创建卡信息简要说明：根据学生的相关信息给其注册卡，建立卡信息输入：饭卡注册信息输出：饭卡信息表处理：学生申请饭卡，根据登记的学生的相关信息给其注册卡，建立卡信息和对 应关系，饭卡信息创建的时间不超过5分钟。处理过程：查询信息简要说明：查询学生的信息或卡信息输入：已知信息输出：相对应学生信息或饭卡信息处理：当需要查询学生信息或饭卡信息时，输入已知的某一项或某几项信息，在 学生信息或饭卡信息表中显示符合查询条件条件的全部信息，查询响应 时间不超过5秒。处理过程：修改信息简要说明：修改学生信息或饭卡信息输入：修改后的信息输出：修改后学生的信息表或饭卡信息表处理：当需要修改学生信息或饭卡信息时，在学生信息表或饭卡信息表中找到需 要修改的信息并加以修改，完成修改操作的时间不超过5分钟。处理过程：饭卡充值简要说明：给饭卡充值，对饭卡内的数据进行修改输入：充值额输出：余额处理：对饭卡进行充值，把饭卡信息表中的余额加上充值额，作为充值后的余额， 饭卡充值完成数据更新的时间不超过5秒钟。处理过程：消费简要说明：饭卡消费，对饭卡内的数据进行修改输入：消费额输出：余额处理：对饭卡内的数据进行修改，把饭卡信息表中的余额减去消费额，作为消费 后的余额，消费后完成数据更新的时间不超过5秒钟。处理过程：饭卡挂失简要说明：对饭卡信息进行加锁和解锁输入：饭卡挂失信息输出：锁信息处理：当学生符合合理条件并申请挂失时，对该学生对应的饭卡信息加锁，然后 补办一张新卡，因原来的饭卡信息与该学生信息相对应，故只需更改原来 的卡号为新卡卡号就可以，对饭卡挂失的时间不超过5分钟。处理过程：创建饭卡历史记录信息简要说明：根据学生和饭卡的信息创建饭卡历史记录表输入：学生和饭卡信息输出：饭卡历史记录表 处理：根据学生的信息和饭卡的一系列历史记录，记录保存下来，建立饭卡历史 记录表，记录学生的日常消费或充值等信息，记录为不断地实时增加，对 单个记录的登记时间不超过1分钟处理过程：饭卡历史记录查询简要说明：查询饭卡历史记录输入：学生相关信息或饭卡相关信息输出：相对应的饭卡消费（或充值、挂失）等历史记录处理：当需要查询饭卡的历史记录时，输入学生的相关信息或饭卡的相关信息， 找到饭卡信息表里面的对应信息，查询响应时间不超过5秒。处理过程：饭卡历史记录修改简要说明：对需要修改的饭卡历史记录进行修改输入：修改后的记录输出：修改后的的饭卡消费（或充值、挂失）等历史记录表 处理：当需要修改饭卡的历史记录时，在饭卡历史记录表中找到要修改的历史记 录后加以修改，完成修改操作的时间不超过5分钟。2.5安全性为了防止不合法的使用本系统，造成数据的泄露、更改或破坏。我们通过以下两个方面的安全措施加强本系统的安全性，以保障本系统和数据的安全。1用户标识与鉴别用户输入用户名（在本系统预先设定三个用户，分别为一名充值员A1，一名学生信息管理员U1，一名卡务中心管理员B1），系统比对内部记录的合法用户标识鉴别用户是否为合法用户。再通过输入口令进一步核实用户身份，通过则进入系统；否则，不能使用系统。2用户权限为了确保每个用户在授予的权限内使用系统，我们要预先在数据字典中登记每个用户的权限（具体用户权限定义会在下文用表体现）。用户发出存取数据库操作请求时，DBMS查找数据字典，核对操作是否在用户权限范围内，是则进行操作；否则拒绝执行此操作。用户权限定义授权用户名 被授权用户名 数据库对象名 允许的操作类型 能否转授权DBA U1 关系学生基本信息 All 不能DBA U1 关系饭卡内基本信息 Select 不能DBA B1 关系饭卡内基本信息 All 不能DBA B1 关系饭卡的历史记录 All 不能DBA B1 关系管理员基本信息 All 不能DBA B1 属性列学生基本信息.学号 All 不能DBA A1 关系饭卡 Select 能DBA A2 属性列饭卡.余额 Update 不能一名充值员A1 一名学生信息管理员U1 一名卡务中心管理员B13概念结构设计 概念结构是对现实世界的一种抽象，即对实际的人、物、事和概念进行人为处理，抽取人们关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述。概念模型不依赖于具体的计算机系统，是单纯反映信息需求的概念结构。概念模型设计阶段的目标是把需求分析阶段得到的需求抽象为数据库的概念结构。描述概念结构的有力工具是E-R图，采用自底向上法，即先从局部E-R图开始设计，最后由局部E-R图综合形成总体E-R图。根据该方法设计出“饭卡充值管理系统”数据库的局部E-R图，分为四个部分：学生实体、管理员实体、饭卡实体、卡的历史记录实体，最后将这些局部E-R图整理成总体E-R图。如图所示：3.1系统局部E-R图1、学生实体是由学号，姓名，性别，年级，学院组成。其中学号是标识学生的唯一信息，所以学生实体中定义学号为实体的主码，学生E-R图，如图3.1.1图3.1.1 学生E-R图2、饭卡实体是由卡号，学号，余额组成。其中卡号是标识饭卡的唯一信息，所以饭卡实体中定义卡号、学号为实体的主码，饭卡E-R图，如图3.1.2图3.1.2 饭卡E-R图3、管理员实体是由员工号，姓名，性别组成。其中员工号是标识管理员的唯一信息，所以管理员实体中定义员工号为实体的主码，管理员E-R图，如图3.1.3图3.1.3 管理员E-R图4、卡的历史记录实体是由卡号，时间，发生额组成。其中卡号、时间是标识卡的历史记录的信息，所以卡的历史记录实体中定义卡号、时间为实体的主码，卡的历史记录E-R图，如图3.1.4图3.1.4 卡的历史记录E-R图3.2实体之间的关系及E-R图1、饭卡与学生的关系：一张饭卡属于一个学生，一个学生只能拥有一张饭卡，所以饭卡与学生是一对一的关系。饭卡与学生的关系E-R图，如图3.2.1图3.2.1 饭卡与学生关系E-R图2、饭卡与卡的历史记录的关系：一张饭卡可以记录不同种类的卡的历史记录，不同类的卡的历史记录可以记录在一张饭卡上，所以饭卡与卡的历史记录是一对多的关系。饭卡与卡的历史记录的关系E-R图，如图3.2.2图3.2.2 饭卡与卡的历史记录关系E-R图3、管理员与饭卡的关系：不同的管理员可以对不同的饭卡进行操作，不同的饭卡可以由不同的管理员进行操作，所以管理员与饭卡是多对多的关系。管理员与饭卡的关系E-R图，如图3.2.3图3.2.3管理员与饭卡的关系E-R图3.3系统全局E-R图 将图3.2.1-3.2.3合并，同时对各个属性进行整合，就得到整个系统全局的E-R图。整体E-R图，如图3.3图3.3整体E-R图4逻辑结构设计 逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据库模型相符合的逻辑结构。将概念结构转换为一般的关系模型，需要明白如何将实体型和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码，在饭卡充值管理系统中只存在1:1和1：n的关系，因此只需要转换成独立的关系模式，标出主码。然后将转换来的关系模型向特定DBMS支持下的数据模型转换。当然数据库逻辑设计的结果是不唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用的实际需要适当的修改，调整数据模型的结构，使其进一步优化、完善。 学生（学号，姓名，性别，年级，学院） 饭卡（卡号，学号，余额） 管理员（员工号，姓名，性别） 卡的历史记录（卡号，时间，发生额）4.1数据模型的优化数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导。第一范式：关系模式 学生（学号，姓名，性别，年级，学院），饭卡（卡号，学号，余额），管理员（员工号，姓名，性别），卡的历史记录（卡号，时间，发生额）中的所有属性值都是不可再分的原子项，所以该关系模式已满足第一范式。第二范式：从关系模式中我们可以知道学生（学号，姓名，性别，年级，学院）的唯一候选关键字是学号，非主属性是姓名、性别、年级、学院，所存在的函数依赖有（学号姓名，学号性别，学号年级，学号学院），故满足第二范式。饭卡（卡号、学号、余额）的唯一候选关键字的卡号，非主属性是学号、余额，所存在的函数依赖有（卡号学号，卡号余额），故满足第二范式。卡的历史记录 （卡号、时间、发生额）的唯一候选关键字是（卡号，时间）非主属性是时间、发生额，所存在的函数依赖是（卡号，时间发生额），满足第二范式。管理员（员工号、姓名、性别）的唯一候选关键字是员工号，非主属性是姓名、性别，所存在的函数依赖是（员工号姓名，员工号性别），故满足第二范式。第三范式：关系模式学生（学号，姓名，性别，年级，学院）中非主属性（姓名，性别，年级，学院）不存在相互依赖，不存在非主属性对候选关键字的传递依赖，所以满足第三范式。饭卡（卡号，学号，余额）不存在传递依赖，满足第三范式。卡的历史记录（卡号，时间，发生额）不存在传递依赖，所以满足第三范式。管理员（员工号，姓名，性别）不存在传递依赖，满足第三范式。BCNF范式：学生（学号，姓名，性别，年级，学院）的依赖中不存在有依赖是不包含关键字学号的，所以满足了此关系模式满足BCNF。依此类推，我们可以得到优化后的关系模式为学生（学号，姓名，性别，年级，学院）饭卡（卡号，学号，余额）卡的历史记录（卡号，时间，发生额）管理员（员工号，姓名，性别）5物理结构设计数据库物理设计阶段的任务是根据具体计算机系统（DBMS和硬件等）的特点，为给定的数据库系统确定合理的存储结构和存取方法。所谓的“合理”主要有两个含义：一个是要使设计出的物理数据库占用较少的存储空间，另一个对数据库的操作具有尽可能高的速度。主要体现在后者。5.1确定数据库的物理结构物理结构可以说是存储结构，因此确定数据库的存储结构主要指确定数据的存放位置，包括确定关系、索引、日志、备份等的存储安排及存储结构，以及确定系统存储参数的配置。而在饭卡充值管理系统中我们将数据存放在不同的表上，使其存放有序，更易查找，连接方便。以下就是各个表所存放的信息：学生信息表字段名数据类型长度是否主键是否必填字段说明学号CHAR6是是学生的学号姓名CHAR6否是学生的姓名性别CHAR2否是学生的性别年级CHAR8否是学生所在年级学院CHAR8否是学生所在学院饭卡信息表字段名数据类型长度是否主键是否必填字段说明卡号CHAR6是是学生所持饭卡的卡号学号CHAR6否是学生的学号余额CHAR6否否学生饭卡上的余额管理员信息表字段名数据类型长度是否主键是否必填字段说明员工号CHAR6是是管理员的员工号姓名CHAR6否是管理员的姓名性别CHAR2否是管理员的性别卡的历史记录表字段名数据类型长度是否主键是否必填字段说明卡号CHAR6是是学生所持饭卡的卡号时间CHAR8是否学生使用饭卡进行消费或充值的时间发生额CHAR6否否学生使用饭卡消费的金额或充值金额5.2信息储存位置饭卡充值管理系统所建立的学生信息表、饭卡信息表、饭卡历史记录表等信息数据都存放在电脑D盘下；又饭卡充值管理系统所要面向的数据实时变化量大，其中的信息和数据每时每刻都可能会发生变化，故得设置好临时文件的储存位置，在这方面，本饭卡充值管理系统的临时文件也存放在D盘的一个文件夹。5.3系统配置饭卡充值管理系统对运行环境的要求：1、精度要求输入数据：查询最大查询范围一年内；饭卡信息的合理性。输出数据：余额以0123.45的形式最多小数点后两位，即到分为止显示。2、时间特性要求刷卡响应时间不超过1秒；查询响应时间不超过3秒。3、故障处理要求刷卡响应时间超过1秒后，自动提出警告，要求重新刷卡。查询超过3秒，要显示出查询时间过长的提示信息。防止被误认为死机。当计算机突然死机、重启、断电时自动存储备份数据。即便没有存上。也有备份数据库，供恢复。4、对硬件的要求为顺应当代信息化的快速发展，故对中央电脑做了一些基本要求：硬盘储存容量大，能满足大量数据的储存要求；CPU性能高效稳定，能够满足各类操作的快速响应需求；电源可靠稳定，能满足稳定的工作环境需求，并有后备电源。对刷卡器，要求读取ID敏捷，准确。并要求刷卡器和中央电脑有可靠稳定的连接，通信量要满足查询精度和速度的要求。且刷卡器上的功能键要求显示清楚明白，意思表达、精确准确。5、其他要求学生只能刷卡消费；系统管理员可以进入管理员界面；刷卡服务员可以操作刷卡器；系统界面要做到清晰、美观，操作简单、方便快捷；6数据完整性约束为了保证数据的正确性和包容性，防止数据库出现不符合语义、不正确的数据出现在数据库，我们需考虑到数据完整性。数据完整性包括：实体完整性、参照完整性、用户自定义完整性。为了维护数据完整性，本系统采取以下措施：1、根据实体完整性设置主码，检查主码是否唯一。不唯一则拒绝插入或修改。2、检查主码的各属性是否为空，只要有一个为空就拒绝插入或修改。3、根据参照完整性比对参照表和被参照表。不满足参照完整性时，不予与执行或进行级联操作。4、根据用户自定义的完整性约束条件进行比对，当操作不符合约束条件时，拒绝执行该操作。根据饭卡充值系统的关系模式设计系统的数据完整性约束：学生信息表列名完整性约束学号实体完整性：非空，主码；用户自定义完整性：非空，唯一性姓名用户自定义完整性：非空性别用户自定义完整性：只限填男或女学院用户自定义完整性：非空年级用户自定义完整性：取值（16），非空饭卡信息表列名完整性约束卡号实体完整性：非空，主码；用户自定义完整性：非空，唯一性学号参照完整性：非空，唯一性；被参照对象：学生信息（学号）余额用户自定义完整性：非空，取值>0.0 或<999.9卡的历史记录表列名完整性约束卡号参照完整性：非空，唯一性；被参照对象：饭卡信息（卡号）时间实体完整性：非空；用户自定义完整性：非空发生额用户自定义完整性：非空，取值>-999.9 或<999.9管理员信息表列名完整性约束员工号实体完整性：非空，主码；用户自定义完整性：非空，唯一性姓名用户自定义完整性：非空性别用户自定义完整性：只限填男或女7数据库设计7.1系统的安全性设计代码A1,A2：充值管理员U1：学生管理员B1：饭卡信息管理员Create role DBAGrant all privilegesOn table 学生信息表，饭卡信息表，卡的历史记录，管理员To DBA;Grant all privilegesOn table 学生信息表To U1Grant select On table 饭卡信息表To U1grant all privilegesOn table 饭卡信息表,卡的历史记录表To B1Grant selectOn table 学生信息表To B1Grant selectOn table 饭卡信息表To A1,A2Grant updateOn table 饭卡信息表To A1,A2Grant all privilegesOn table 卡的历史记录To A1,A27.2数据库设计代码（包括完整性设计）建立饭卡充值系统数据库use master go create database 饭卡充值系统on( name=饭卡充值系统, filename='D:cardsystem.mdf', size=10MB,maxsize=500MB, filegrowth=50MB )log on( name='饭卡充值',filename='D:cardsystem.ldf',size=25MB,maxsize=128MB,filegrowth=15MB )go建立学生信息表CREATE TABLE STUDENT( 学号 CHAR(10)not null, 姓名 CHAR(8) not null, 性别 CHAR (2)CHECK (性别 IN('男','女'), 学院 char(8) not null, 年级 char(1) check(年级>=1 and 年级<=6) PRIMARY KEY（学号）,) 建立卡务中心信息表create table Card( 卡号 char(10) not null, 学号 char(10 not null, 姓名 char(8) not null, 余额 char(5)check(余额>=0.0 and 余额<=999.9), primary key(卡号,学号), foreign key(学号) references student(学号)建立卡的历史记录表create table CE( 卡号 char(10) not null, 时间 datetime not null, primary key(卡号，时间) 发生额 char(6)check(发生额>= -999.9 and 发生额<=999.9) , foreign key(卡号)references Card(卡号)建立管理员信息表Create table user( 员工号 char(2) not null, 姓名char(8) not null, 性别 char(2) CHECK (性别 IN('男','女') primary key（员工号）,)8心得体会这次课程设的内容是设计一个饭卡充值管理系统，主要实现的功能有：饭卡信息管理，持卡者信息管理，饭卡消费，充值，挂失，饭卡历史记录的查询。在这次的课程设计中我们小组遇到了诸多的困难和问题，但从中也得到了一些重要而且很有意义的收获。首要的是我们对一个系统的制作过程有了更清晰的认识。从系统的需求分析到详细设计再到代码的实现最后到完成系统设计，每个环节的实现和过渡使得系统的设计变得清晰明朗易实现。在这次小型管理系统的设计的实践过程中，我们对制作系统的流程有了更深层次的理解和认识。我们不仅熟悉了实现软件的方法，在实现源代码的过程中，我们的编程能力和编程思想也有所提高。因此也提高了我们对软件编程的兴趣和刻苦钻研精神。其中，通过整个过程的设计我们了解到了团结合作的重要性。在全面的系统的体验了数据库课程设计的整个过程后，我们体会到了完成一项开发系统软件工程的艰辛。在好些细节上，我们花了很长的时间在一起讨论，正因如此，才得以顺利地解决一些之前个人无法解决的问题，在一起大家各自提出自己的看法，取长补短，互补遗漏，在整个数据库课程设计下来，为了做好设计我们浏览了好多相关资料，这在同时也加强了我们自主学习的能力。总而言之，这次的数据库课程设计让我们收获丰富，收益良多。参考文献1 王珊.萨师煊.数据库系统概论（第4版）M. 高等教育出版社 ，2006. 52 郑玲利. 数据库原理与应用案例教程M. 清华大学出版社， 2008.93 袁鹏飞.数据库应用开发技术M.人民邮出版社，1998.5