数据库课程设计报告校友录系统设计.doc

1系统总体介绍及组内分工1.1系统总体介绍通过校友录这种联系方式，可以让很多因毕业而分离的同学还能经常聚首，相互嘘寒问暖，了解各自情况。我们的系统实现了校友之间的联系，并且具有创建学校，创建班级的功能，还包括加入班级成员，查看班级成员信息和校友信息的功能。系统主要包括班级管理员对功能的要求、班级成员对功能的要求。班级管理员可以浏览班级所有成员的信息，并审核要求成为班级成员的用户信息。班级用户找到所在班级后可申请假如此班级。并且可以注册、修改个人信息。用户可浏览班级所有用户的信息。系统功能包括用户注册、注册信息修改、用户登录、创建学校、创建班级、加入班级、审核班级新成员、查看班级成员列表等。只有注册为系统用户才能够在校友录中进行其他操作。当用户注册为班级用户后，所修改的信息包括用户的联系方式、家庭地址等。我们的系统为了区分用户的权限特意为用户添加了用户登录设置。校友录系统的结构如图1.1所示 校友录系统加入班级信息管理申请成为班级成员查看或修改成员信息查看或修改导员信息查看或修改学校信息查看或班级修改信息成员信息管理班级信息管理学校信息管理导员信息管理图1.1系统结构图1.2组内分工组内分工如表1-1所示。表1-1组内分工职称姓名组内分工成绩组长需求分析组员概念模型设计组员逻辑结构设计2数据库设计2.1需求分析2.1.1需求分析的设计思想用户可以通过校友录系统记录，关注好友状况，并可以随时是更改，当同学申请加入某个班级并成功加入后，他的一系列的信息将能通过校友录系统记录下来，当该同学的信息有所变化时也可以进行修改，在校友录系统中，我们以同学为目标，辅以添加，修改，查看等功能。在此系统中，用户不仅可以记录同学的状况，也可以记录与同学有关的人或事情的状况，比如该同学所在的班级以及班级的班主任。所以我们就把该系统分为若干个实体以及实体之间的联系，最终完成系统的设计。2.1.2数据流图数据流图(Data Flow Diagram，DFD)是用来描绘软件系统逻辑模型的图形工具，用于描绘信息在系统中的流动和处理情况。数据流图是结构系统分析的主要工具，它表示了系统内部信息的流向，并表示了系统的逻辑处理的功能，是一种功能模型。在数据流图中有四种基本符号，如表2-1所示。表2-1 数据流图基本符号的意义符号说明加工，输入数据在此进行变换产生输出数据，中间要注明加工的名字数据输入的源点和数据输出的终点，在其中要注明源泉点或终点的名字数据流，被加工的数据及数据流向，在箭头边要用名词或名词性短语给出数据流的名字数据存储文件，要用名词或名词性短语给出数据文件的名字校友录系统的数据流图如图2.1所示。 班主任信息记录班主任班主任信息登记 班主任信息 班主任信息 班主任 信息 辅导信息记录查询校友信息辅导信息登记 校友信息状况 学生信息记录 学生 信息 关注学生信息登记 校友学生 学生信息 读出 更改 信息 信息 申请 更改校友信息 准/不准 加入 加入班级 加入 入班有关信息 审核信息 准/不准 校友管理员 加入 信息变动 加入后有关信息记录 班级 班级信息登记 信息 调出 删除 删除班级 班级信息 信息 信息 不确定 校友信息 班级 信息 删除校友信息 隶属信息登记 班级信息记录 隶属 学校 信息 信息学校信息登记 隶属信息记录 学校 学校信息 学校信息记录图2.1校友录数据流图2.1.3数据字典数据字典则是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果。数据字典在数据库设计中占有很重要的地位。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分。其中数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构，数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。数据项以下为本系统的数据项。学生信息学生信息如表2-2所示。表2-2学生信息字段名称数据元素名称字段类型字段长度键值Sno学号Number4主键Cno班级编号Number4外键Tname班主任姓名Char10外键Sname姓名Char10Ssex性别Char2Sbirth生日DateSmphone手机号Number11Sphone家庭电话Number11Sadd家庭地址Char50Scod邮编Number6SE-mailE-mailChar30Sxuexing血型Char2Slike个人爱好Char40Entertime入班时间Date学校信息学校信息如表2-3所示。表2-3学校信息字段名称数据元素名称字段类型字段长度键值Schno学校编号Number4主键Schname学校名称Char30Schadd学校地址Char50Schweb学校网址Char50班级信息班级信息如表2-4所示。表2-4班级信息字段名称数据元素名称字段类型字段长度键值Cno班级编号Number4主键Cname班级名称Char20班主任信息班主任信息如表2-5所示表2-5班主任信息字段名称数据元素名称字段类型字段长度键值Tname班主任姓名Char10主键Tmphone班主任电话Number11管理信息管理信息如表2-6所示。表2-6管理信息字段名称数据元素名称字段类型字段长度键值Tname班主任姓名Number4外键Cno班级编号Number4外键Managetime管理时间Date数据结构数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。本系统中对数据结构的具体描述如下：学生含义说明：定义了用户的有关信息。组成：学号、姓名、性别、生日、手机号、家庭电话、家庭地址、邮编、E-mail、血型、个人爱好。学校含义说明：定义了学校的有关信息。组成：学校编号、学校名称、学校地址、学校网址。班级含义说明：定义了班级的有关信息。组成：班级编号、班级名称。班主任含义说明：学生所在班级的负责人。组成：班主任姓名，班主任电话。数据流数据流是数据结构在系统内传输的路径。本系统中对数据流的具体描述如下：数据流“学生信息”可描述如下：数据流：学生信息。说明：当有同学要加入某班级时向管理员输入信息申请，以便管理员的审核。数据流来源：学生。数据流去向：管理员。数据流“班主任信息”可描述如下：数据流：班主任信息。说明：对学生的班主任信息进行记录。数据流来源：班主任。数据流去向：管理员。数据流“学校信息”可描述如下：数据流：输入学校信息。说明：对班级所属的学校进行信息登记。数据流来源：学校。数据流去向：管理员。数据流“关注好友”可描述如下：说明：管理员对学生记录进行查询操作。数据流：关注好友。数据流来源：管理员。数据流去向：学生信息记录。数据流“校友信息变动”可描述如下：数据流：校友信息变动。说明：管理员对学生信息进行更改。数据流来源：管理员。数据流去向：学生信息记录。数据流“删除不确定校友信息”可描述如下：说明：管理员对学生信息进行删除操作。数据流来源：管理员。数据流去向：学生信息。数据流“班级信息”可描述如下：说明：学生所在的班级的有关信息：数据流来源：班级。数据流去向：管理员。数据存储用户说明：存储用户的基本信息。输入数据：用户的有关基本信息。输出数据：用户的有关基本信息。学校说明：存储学校的有关信息。输入数据：学校的基本信息。输出数据：学校的有关信息。班级说明：存储班级的有关信息。输入数据：班级的基本信息。输出数据：班级的基本信息。班主任说明：存储学生所在班级负责人的信息。输入数据：学生所在班级负责人的信息。输出数据：学生所在班级负责人的信息。处理过程处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息，具体描述如下：学生信息登记处理过程名：学生信息登记。说明：学生加入班级对学生的信息进行登记。输入：输入学生信息。 输出：学生信息。班主任信息登记处理过程名：班主任信息登记。说明：学生所在班级的辅导员的信息登记。输入：班主任信息。输出：班主任信息。班主任信息登记处理过程名：班主任信息登记。说明：学生所在班级的辅导员的信息登记。输入：班主任信息。输出：班主任信息。班级信息登记处理过程名：班级信息登记。说明：学生所在班级信息登记。输入：班级信息。输出：班级信息。学校信息登记处理过程名：学校信息登记说明：学生所在班级隶属的学校的信息登记输入：学校信息。输出：学校信息。查询校友信息处理过程名：查询校友信息说明：管理员对校友的信息进行查询输入：查询信息。输出：学生信息。更新校友信息处理过程名：查询校友信息。说明：管理员对校友的信息进行更改。输入：更改信息。输出：学生信息。删除校友信息处理过程名：删除校友信息。说明：管理员对校友的信息进行删除操作。输入：删除命令。输出：学生信息。2.2概念结构设计2.2.1局部概念模型设计局部概念模型的设计思想是根据需求分析的内容用E-R图分别表示出各个实体及其属性，以及各实体之间的联系。学校实体及其属性的E-R图如图2.2所示。学校学校编号学校名称学校网址学校地址图2.2学校实体及其属性学生实体及其属性的E-R图如图2.3所示。学生学号生日性别手机号家庭电话家庭地址Email姓名个人爱好邮编血型图2.3学生实体及其属性班级实体及其属性的E-R图如图2.4所示。班级班级名称班级编号图2.4班级实体及其属性班主任实体及其属性的E-R图如图2.5所示班主任班主任姓名班主任姓名图2.5班主任信息属性实体与实体之间的联系是两个或两个以上的实体类型之间有名称的联系。实体间的联系是用菱形表示的。学生实体和班主任之间的联系如图2.6所示。图2.6学生实体和班主任实体之间的联系班主任实体与班级实体之间的联系如图2.7所示。 图2.7班主任实体和班级实体之间的联系学校实体和班级实体之间的联系如图2.8所示 图2.8班级实体和学校实体之间的联系学生实体和班级实体之间的联系如图2.9所示图2.9学生实体和班级实体之间的联系2.2.2总体概要设计各子系统的分E-R图设计好以后，下一步就是将所有的分E-R图综合成一个总的E-R图。由于各个局部所面向的问题不同，这就导致各个分E-R图之间必定会存在许多不一致的问题，称之为冲突。因此合并分E-R图并不能简单地将各个分E-R图画到一起，而是必须合理消除各分E-R图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型，是合并E-R图的主要工作和关键。各E-R图之间的冲突主要有三种：属性冲突、命名冲突、结构冲突。在校友录系统设计过程中，有属性冲突和结构冲突。属性域冲突，即属性值的类型、取值范围或取值集合不同。如学生中的属性学号在不同的关系中都要定义成相同的属性值的类型为字符型并且字长相等，才能避免属性冲突。按照合成总体E-R图的规则，画出完整的E-R图，如图2.10所示。学生班级学校班主任辅导管理加入隶属班主任电话E-mail班级编号班级名称班主任姓名生日学号性别个人爱好血型姓名学校编号学校网址手机号学校地址学校名称家庭电话邮编入班时间管理时间图2.10总体E-R图2.2.3CDM模型打开“Powerdesigner”，选择“new”，弹出如图2.11所示窗口，选择“Conceptual Data Model”，单击“OK”。图2.11新建CDM模型在操作界面左方由如图2.12所示的工具栏，可以创建实体以及联系并为其添加属性。图2.12工具栏最终生成的CDM图如图2.13所示。图2.13设计的CDM图2.3 逻辑结构设计2.3.1逻辑结构设计的思想概念结构设计是独立于任何一种数据模型的信息结构。逻辑结构设计是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。所以逻辑结构设计一般分以下三个方面：(1) 将概念结构转换为一般的关系、网状、层次模型。(2) 将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换。(3) 对数据模型进行优化。针对校友录管理系统 ，逻辑结构设计采用概念结构转换关系模型，将E-R图依照规则转换为关系模型，为了进一步提高数据库应用系统的性能，再将转换后的关系模型进行优化，确定是否要对某些模式进行合并或分解，为物理设计提供最优的处理。2.3.2 E-R图向关系模型的转换E-R图向关系模型的转换要解决的问题是如何将实体和实体间的联系转换为关系模型，如何确定这些关系模式的属性和码。关系模型的逻辑结构是一组关系模式的集合。E-R图则是由实体、实体的发生和实体之间的联系三个要素组成的。所以将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转换为关系模式，这种转换一般遵循如下原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。对于实体间的联系则有以下不同的情况：一个1：1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。一个1：n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为n端实体的码。一个n：m联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性而关系的码为各实体码的组合。三个或三个以上实体间的一个多无联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性而关系的码为各实体码的组合。通过上述转换原则，可以将E-R图转换为关系模型，转换结果如下：学生(学号，姓名，性别，生日，手机号，家庭电话，家庭住址，邮编，E-mail，血型，个人爱好)此为学生实体对应的关系模型。根据转换原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。此为3NF。学校信息(学校编号，学校名称，学校地址，学校网址)此为学校信息实体对应的关系模型。根据转换原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。此为3NF。班级信息(班级编号，班级名称)此为学校信息实体对应的关系模式。根据转换原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。此为3NF。班主任信息(班主任姓名，班主任电话)此为班主任实体对应的关系模式。根据转换原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。此为3NF。管理(班主任姓名，班级编号，管理时间)此为联系“管理”所对应的关系模式。根据转换原则：一个1：1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。此为2NF。学生实体和班级实体为多对一的联系，将班级实体的班级编号传到学生中作为学生的属性，将关系中的加入时间也作为学生实体的属性。学校实体和班级实体为多对一的联系，将学校实体中的学校编号传递给班级作为班级实体的属性。学生实体和班主任实体为多对一的联系，将班主任实体的班主任姓名传递给学生实体作为学生实体的属性。2.3.3 PDM模型 由CDM模型生成的PDM模型如图2.14所示。图2.14生成的PDM模型结论总的来说这次的数据库课程设计对我们学习数据库是非常有用的。在这次的课设中我们把以前学过的知识运用在了实际操作上，使我们真正懂得了怎么去运用它。通过课程设计使我们进一步掌握数据库设计的有关知识，提高了运用数据库的能力，加深了对它的相关知识的理解。通过自己去查阅资料、阅读程序及动手编制E-R提高了我们的设计能力，使我在数据设计上有一定飞跃，能用数据库来解决一些实际问题。在紧张而充满学习气氛的环境中我度过了课程设计的这个星期，我发现了自己在学习数据库中的一些漏洞，在同学们的讨论中也学到了自己不会的知识。回顾起此次数据库课程设计，至今我仍感慨颇多，通过这次课程设计，我更加熟练的掌握了使用数据库的设计，加深了对数据库课程知识的理解。如果在开发前对整个开发工作做出全方位的规模化系统分析，开发过程就是事半功倍，否则就会遇到许多意想不到的问题，延缓开发进度。在这段时间里，我有了很多感受，多人分工合作注重的是组员之间得合作交流与沟通,对知识更是一个加深,从对某些知识的一知半解，到查看大量的相关资料和书籍，让自己头脑中模糊的概念逐渐清晰.通过这次课程设计使我懂得了如何将我们的系统知识串成串，按照我们的思想，运用知识去解决它，我们将得到很大的收获。从总体上来说，这次的课程设计对我们来说是非常难得的一次锻炼的机会。正像辅导教师说的那样，课程设计使得我们对开学以来所学的专业知识有了更深刻的认识，使知识得到了融会贯通。对于我们来说这不仅仅是一次课程设计，不仅仅是学会了一种开发工具，更重要的是在学习的过程中，有些问题要一个人面对，有的问题要想尽各种办法解决，克服困难，在解决这些困难的过程中提高了我们的学习能力、解决问题的能力和实际工作能力。致谢本次课程设计的选题，研究及论文的撰写均是在我们的指导教师费老师和史老师的悉心指导下进行的。设计中的每一个环节无不凝聚着费老师的心血。老师在数据库设计方面有很多的实践经验，在我们面对问题时对我们的悉心指导及其严谨的工作态度锐意创新的精神，使我们受益匪浅，在此特别向费老师和史老师表示深深的感谢和由衷的敬意。在系统的完善过程中,我们也遇到了这样或那样的技术问题,但经过自己的不懈努力及查阅大量的资料,最终还是完成了这次任务,虽然结果与老师的预期有一定的距离,但我们都尽了最大的努力.实训期间,同学们也给了我们许多有益的启示和帮助,使我们能够顺利完成.在报告的最后,我要再次感谢费老师,她是我们的授课教师,同时也是我们实训的指导老师.在上课时, 她会细心地为我们讲解课上知识,下课时,也会不遗余力地为我们解答疑难问题.在本次课程设计时她也非常的细心,每次有什么问题, 她都会细心地讲解与示范,直到我们明白为止.在这里,对您衷心地表示感谢。费老师、史老师和同学们的帮助都是我们在未来的最大财富.在最后,我们要再次感谢给予我们帮助的老师同学们.祝你们今后事事顺心.特别感谢费老师和史老师一直以来对我们的关怀与教导，再次祝您工作顺利，事事如意。参考文献王珊.数据库系统概论.北京：高等教育出版社，2000张龙祥.数据库原理与设计.北京：人民邮电出版社，2000李红.数据库原理与应用.北京：高等教育出版社，2002王能斌.数据库系统原理.北京：电子工业出版社，2002课程设计案例精编.北京：中国水电水利出版社，2006数据库开发与实例.北京：清华大学出版社，2006数据库系统原理学习指导.北京：清华大学出版社，2005附录A1.1脚本语句/*=*/* Database name: ConceptualDataModel_3 */* DBMS name: ORACLE Version 9i */* Created on: 2009-5-19 9:29:50 */*=*/alter table "Manage" drop constraint FK_MANAGE_MANAGE_TEACHER/alter table "Manage" drop constraint FK_MANAGE_MANAGE2_CLASS/alter table "Student" drop constraint FK_STUDENT_ENTER_CLASS/alter table "Student" drop constraint FK_STUDENT_TEACH_TEACHER/alter table "class" drop constraint FK_CLASS_BELONG_SCHOOL/drop index "Manage2_FK"/drop index "Manage_FK"/drop index "Enter_FK"/drop index "Teach_FK"/drop index "Belong_FK"/drop table "Manage" cascade constraints/drop table "School" cascade constraints/drop table "Student" cascade constraints/drop table "Teacher" cascade constraints/drop table "class" cascade constraints/*=*/* Table: "Manage" */*=*/create table "Manage" ( "Tname" CHAR(10) not null, "Cno" NUMBER(4) not null, "Mtime" DATE, constraint PK_MANAGE primary key ("Tname", "Cno")/*=*/* Index: "Manage_FK" */*=*/create index "Manage_FK" on "Manage" ( "Tname" ASC)/*=*/* Index: "Manage2_FK" */*=*/create index "Manage2_FK" on "Manage" ( "Cno" ASC)/*=*/* Table: "School" */*=*/create table "School" ( "Schno" NUMBER(4) not null, "Schname" CHAR(30), "Schadd" CHAR(50), "Schwed" CHAR(50), constraint PK_SCHOOL primary key ("Schno")/*=*/* Table: "Student" */*=*/create table "Student" ( "Sno" NUMBER(4) not null, "Cno" NUMBER(4) not null, "Tname" CHAR(10), "Sname" CHAR(10), "Ssex" CHAR(2), "Sbirth" DATE, "Smphone" NUMBER(11), "Sphone" NUMBER(11), "Sadd" CHAR(50), "Scod" NUMBER(6), "SE-mail" CHAR(30), "Sxuexing" CHAR(2), "Slike" CHAR(40), "Entertime" DATE, constraint PK_STUDENT primary key ("Sno")/*=*/* Index: "Enter_FK" */*=*/create index "Enter_FK" on "Student" ( "Cno" ASC)/*=*/* Index: "Teach_FK" */*=*/create index "Teach_FK" on "Student" ( "Tname" ASC)/*=*/* Table: "Teacher" */*=*/create table "Teacher" ( "Tname" CHAR(10) not null, "Tmphone"