数据库设计的典型案例
要点
?学生选课管理系统的数据库设计
学习目标
?学生选课管理系统的需求分析
?学生选课管理系统的ER图
?学生选课管理系统的关系数据库模式
?学生选课管理系统数据库的建立
在第7章里我们已经学习了有关数据库设计的基本理论和方法。本章通过学生选课管理系统数据库设计案例，实际讲授数据库的设计方法，加深对第七章的理解，提高我们的综合设计的能力。
1 案例的系统需求简介
1.1总体需求简单介绍
需求分析阶段是数据库应用系统开发的最重要阶段。需求分析要求应用系统的开发人员按照系统的思想，根据收集的资料，对系统目标进行分析，对业务的信息需求、功能需求以及管理中存在的问题等进行分析，抽取本质的、整体的需求，为设计一个结构良好的数据库应用系统的逻辑模型奠定坚实的基础。
高等学校的学生选课管理系统，在不同的学校会有不同的特点，因为作为教务工作部分它和学校本身的行政制度有关。本章的目的在于，作为数据库设计和应用开发的运用对象，对业务进行适度的简化，突出比较核心的成分，如院系算作一个级别的概念而且直接管理班(跳过专业一级的设置)，学生的免修重修等情况处理、教师的管理没有细化等。
1.2用户总体业务构造
学生选课管理业务，包括4个主要部分：学生的学籍及成绩管理、制定教学计划、学生选课管理以及教学调度。各部分具体的内容：
（1）学籍及成绩管理包括：各院系的教务员完成学生学籍注册、毕业、转学等处理，各授课教师完成所讲授课成绩的录入，然后教务员进行学生成绩的审核认可。（2）制定教学计划包括：由教务部门完成指导性教学计划、培养方案的确定，开设课程的注册和调整。
（3）学生选课包括：学生根据开设课程和培养计划(和自己的状况)选择自己本学期所选修课程，教务员对学生所选修课程的确认处理。(注意：一般的必修课程是由教务员统一处理，只有辅修的课程才经过学生的选择过程)
（4）执行教学调度包括：教务员根据本学期所开设的课程、教师上课的情况以及学生选课情况完成排课、调课等。
1.3其它要求
如安全性，系统环境要求(根据现有的设备情况进行系统运行)等，这些不是本章的核心内容，所以就不再进一步叙述。
2
3
1.4系统功能设想
这里的功能划分，是根据第一阶段需求调查基础上进行的初步划分。随着需求调查的深入，功能模块随着对需求了解的明确得到调整。
教务管理业务的4个主要部分，可以将系统应用程序划分为对应得4个子模块：包括学籍及成绩管理子系统、教学计划管理子系统、学生选课管理子系统以及教学调度子系统。根据各业务子系统所包括业务内容,还可以将各个子系统继续细化划分为更小的功能模块。划分的准则主要遵循模块的内聚性要求和模块间的低聚合性。如图所示表示一个教务管理系统功能模块结构图。
1.5业务流程分析
一个简化的选课系统业务流程如图2所示：
图 1选课管理系统功能结构图
图 2 选课管理系统业务流程
2 需求描述
本阶段的成果的内容形式主要包括数据流图(Data Flow Diagram)和数据字典(Data Dictionary)。数据流图和数据字典是描述用户需求的重要工具以及阶段成果表达形式。它作为需求分析的成果和用户交流的主要手段和依据，是后续数据库设计的前提。设计人员从数据流图中可以比较充分地了解软件的结构，所以也是软件设计的重要依据。
调查了解用户的需求后，需要进一步表达用户的需求，分析和表达用户需求的方法很多，目前最常用的还是结构化分析法。该方法是基于数据流的需求分析方法，它利用了图形的方式进行表达，容易学习和运用。
结构化分析法采用的是自顶向下、逐层分解的方式分析系统，即将系统的功能从宏
4
5
观层面逐渐细化，达到最终的结构化分析方法主要使用以下几个工具：数据流图(Data Flow Diagram 简称DFD)、数据字典(Data Dictionary 简称DD)、判定表和判定树等。
数据流图描述了数据的来源和去向，以及所经过的处理；而数据字典是对数据流图中的数据流、数据存储和处理的明细描述。判定树和判定表用来描述据加工的逻辑构造。
不同的应用环境，对数据描述的细化程度会有所不同，常常应实际情况而定。下面就使用这两种工具来描述本例的用户需求，体现他们在实际中的应用方法。
2.1 数据流图
数据流图是通过系列符号及其组合来描述系统功能的输入、输出、处理或加工构造。 数据流图中使用的符号在各种书籍和资料上表达不尽相同，目前许多常用的一些流行的数据库辅助设计工具如Microsoft Visio 、Sybase PowerDesigner 、Oracle Designer 、Rational Rose 、Erwin 等符号都不统一，我们这里以比较容易上手的Visio 工具为例，针对Gane-Sarson 模板中的符号作为参考：
，数据源点或终点 或者外部实体
数据存储
加工或处理数据流
注意：DFD 表示数据被加工或处理的过程，箭头只是表示数据流动的方向，不能有分支、循环的情况。 数据流图命名规则之一：数据流图的中加工、处理过程一般采用动词及其短语；数据源点或终点、数据存储(数据文件或表单形式)、数据流(一项或多项数据)等一般为名词或名词短语。
数据流图命名规则之二：流图中的命令所使用的语言要基本上反映实际的情况，在整个DFD 中必须要唯一，尽量避免含有像加工、处理、存储这样的元名称。
1。系统的全局数据流图
系统的全局数据流图，在具体的设计工具中往往也称为第0层或顶层数据流图，主要是从整体上描述系统的数据流，反映系统中数据的整体流向，是设计者针对用户和开发者表达出来的一个总体描述。
我们经过对教学管理业务的调查、数据的收集和信息流程分析处理，明确了该系统图 3 Gane-Sarson 模板中数据流图的基本元素
务部门对新入学的学生进行学籍注册，对毕业生办理学籍档案的归档工作，任课教师在期末时登记学生的考试成绩；学校教务部门根据教学计划进行课程安排、期末考试时间地点的安排等，如图所示。
图4简化的选课管理系统0层数据流图
2。系统局部数据流图
全局数据流图，从整体上描述了数据流向和加工处理过程。但是一个较为复杂的系统来讲，要清楚地描述系统数据的流向和加工处理的每一个细节，仅用全局数据流图难
6
7
以完成。因此需要在全局数据流图的基础上，对全局数据流图的某些局部单独放大，进一步细化，细化可以采用多级方式进行，便是所谓的分级数据流图来描述。这里以制定教学计划/学籍及成绩管理和选课等处理功能作细化的分析对象。
制定教学计划处理，主要分为4个子处理过程：教务员根据自己已有的课程信息，增补新开设的课程信息；调整课程信息；查询本学期的教学计划；制定新学期的教学计划。任课教师可以查询自己的教学计划。其处理过程如图5所示。
学籍及成绩管理相对比较复杂，教务员需要新生的学籍注册，毕业生的学籍和成绩的归档管理，任课教师输入学生的考试成绩后，需教务员审核并作认可处理，经确认的学生成绩不允许他人修改。其处理过程如图6所示。
图 5 0层P1的1层数据流图：制定教学计划
图6 0层P2的1层数据流图：学籍和成绩管理
选课管理中，学生根据学校对其专业制定的教学计划，录入本学期所选课程，教务员对学生选课记录进行审核，经审核得到的选课就为本学期的选课。其处理过程如图7所示。
8
9
0层P4的1层数据流图请读者自行描述。
我们可以使用许多的设计工具完成数据流图的创建，这些工具不但可以实现常用的数据流图的绘制，而且可以对多层的数据流图中的元素及其关系的正确性实现有效的检验，能帮助我们学习和理解数据流图的实现技术。本章有关的数据流图均使用Microsoft Visio 工具进行绘制，相关的工具还有Sybase 公司的Power Designer 以及Oracle 的Designer 等，有兴趣的可以参考相关的资料或者下载试用版。
图 7 0层P3的1层数据流图：选课管理
10
2.2 数据字典
数据流图表达了数据与处理的关系，数据流图作为直观的了解系统运行机理的手段，并没有具体描述各类数据的细节，只有通过数据字典进一步细化才能对系统的需求得到具体而确切的了解。数据字典用来说明数据流图中出现的所有元素的详细的定义和描述，包括数据流、加工处理、数据存储、数据的起点和终点或外部实体等。
数据字典包括的项目有：数据项、数据结构、数据流、数据存储、加工逻辑和外部实体。可使用一些符号来表示数据结构、数据流和数据存储的组成。
由于本实例涉及的数据字典项目较多，此处列举"P3选课管理"处理功能中包含的几个对象加以描述。
1。数据流
表 1 P3中数据流的描述
2。数据存储
表
2 P3中数据存储的描述
3。处理过程逻辑
表 3 P3中处理过程逻辑的描述
11
4。数据项
3 概念设计
上述的数据流图和数据字典共同构成了对用户需求的表达，它们是系统分析员(数据库管理员)在需求调查过程中和用户反复交互得到的。建设系统实际要处理的数据基本上已经在数据流图中得到体现，整个设计过程的后续步骤提供基础和依据。
一个独立于具体数据库管理系统的概念模型，主要的手段为ER 图。
在概念设计阶段，主要采用的设计手段目前还是实体联系模型(E-R Model)。绘制E-R 图的关键是确定E-R图的各种结构，包括实体、属性和联系。大部分的流行建模工具(Power Designer、Oracle Designer、ERwin等)也都包含了对E-R设计手段的支持。
3.1 实体
要建立系统的E-R模型的描述，需进一步从数据流图和数据字典中提取系统所有的实体及其属性。这种提出实体的指导原则如下：
①属性必须是不可分的数据项，即属性中不能包含其它的属性或实体
②E-R图中的关联必须是实体之间的关联，属性不能和其它实体之间有关联
由前面分析得到的数据流图和数据字典，可以抽象得到实体主要有5个：学生、教师、课程、院系、班级。
(1)学生实体属性有：学号、姓名、出生年月、性别、电话、系编号。
(2)教师实体属性有：教师编号、教师姓名、性别、职称、出生年月、电话、电子
邮件。
(3)课程实体属性有：课程编号、课程名称、课程学时、课程学分。
(4)院系实体属性有：系编号、系名称、负责人。
(5)班级实体属性有：班级编号、班级名称。
3.2 系统局部E-R图
在需求分析阶段我们采用的是自上而下的分析方法，那么要在其基础上进一步作概念设计我们面临的是细化的分析数据流图以及数据字典，分析得到实体及其属性后，进一步可分析各实体之间的联系。
学生实体和课程实体存在选修的联系，一个学生可以选修多门课程，而每门课也可以被多个学生选修，所以它们之间是多对多的联系(n:m),如图8。
教师实体和课程实体存在讲授的联系，一名教师可以讲授多门课程，而每门课也可以被多个教师讲授，所以它们之间是多对多的联系(n:m),如图9。
学生实体和班级实体存在归属的联系，一个学生只能属于一个班级，而每个班级可以包含多个学生，所以班级和学生之间是一对多的联系(1:n),如图10。
班级实体和系之间存在归属的联系，一个班级只能属于一个系，而每个系可以包含多个班级，所以班级和系之间是一对多的联系(1:n),如图11。
教师实体和系实体之间存在归属的联系，一个教师只能属于一个系，而每个系可以拥有多名教师，所以教师和系之间是一对多的联系(1:n),如图12，但是教师中会有一位充当该系的主任(正)，可见教师和系之间也存在一种一对一的领导关系(1:1),如图12。
12
13
图 8 “学生-课程” 选课关系
图 9 “教师-课程”实体间的关系
图 10 “学生-班级”的组成关系
图11 “班级-系”的属于关系
图12 “教师-系”实体间的关系
3.3 系统全局E-R图
系统的局部E-R图，仅反映系统局部实体之间的联系，但无法反映系统在整体上实体间的相互联系。而对于一个比较复杂的应用系统来说，这些局部的E-R图往往有多人各自分析完成的，只反映局部的独立应用的状况，在系统整体的运作需要时，他们之间有可能存在重复的部分或冲突的情况，如实体的划分、实体或属性的命名不一致等，属性的具体含义(包括数据类型以及取值范围等不一致)问题，都可能造成上述提到的现象。
为解决这些问题，必须理清系统在应用环境中的具体语义，进行综合统一，通过调整消除那些问题，得到系统的全局E-R图。
从实际的情况以及上述的局部E-R图我们可以得知，学生实际修学某门课时必须只能对应一位老师的该门课。因此，可以使用一个聚集来表达学生参加实际授课课程的学习关系，会更加切合实际。各局部E-R存在不少的重复的实体，经过上述聚集分析和合
14
15
并得到系统全局的E-R 图如图8-13所示。该全局E-R 图基本上不存在关系的冗余状况，因此它已经是一个优化的。
4 逻辑设计
逻辑设计就是把E-R 图转换成关系模式，并对其进行优化。
4.1 ER 图到关系模式的转换
在概念设计阶段得到的数据模型，是独立于具体DBMS 产品的信息模型。在逻辑设计阶段就是将这种模型进一步转化为某一种（某些类）DBMS 产品支持的数据模型。目前大部分的流行的数据库管理系统(SQL Server 、Sybase 、Oracle 、DB2等)于关系的数据模型，包括该系统将采用的SQL Server2000图 13 选课管理系统的全局ER 图
设计阶段的E-R图模型转化为关系数据模型。
首先，课程实体以及他们的联系。任课教师与课程之间的是多对多的联系类型，因此，将任课教师、课程以及讲授联系分别设计成如下的关系模式：
教师(教师编号,教师姓名,性别,职称,电话,系编号)
课程(课程编号,课程名称,课程学分,课时)
讲授(教师编号，课程编号，课程编号，开课年度，开课学期)
院系实体和班级之间是一对多的联系类型，所以只要两个关系模式就可表示，其中联系可以放到班级的实体中：
系(系编号、系名称、系主任)
班级(班级编号，班级名称，系编号)
班级实体和学生实体之间是一对多的联系类型，所以也可以只使用两个关系模式来表示。由于“班级”关系模式在上面已经给出，因此，只要再给出一个学生的关系模式，它们间的联系则被放在该关系模式中：
学生(学号，姓名，性别，出生年月，电话，班级编号)
学生实体与讲授是聚集方式的联系类型，它们之间的关系是多对多的关系，可以使用如下关系模式来表示：
学生选课(课程编号，学号，教师编号，开课年度，开课学期，成绩)
4.2 关系模式的规范及调整
在提出关系模式后，我们必须在规范化和实际要求进行优化，这实际上是一个权衡的过程。如果设计没有完全规范化，如可能用于决策支持(与需要大量更新的事务处理相对)的数据库(如数据仓库)则可能没有冗余更新，而且可能对查询更易于理解和更高效。不过，在数据库应用程序内，未规范化的数据在设计过程更需要注意。一般的策略是以规范化设计为出发点，然后出于特定因素有条件地非规范化某些表,以达到系统总体的优化目的。
首先，需要我们确定上面建立的关系模式中的函数依赖，一般在作需求分析时就了解到一些数据项的依赖关系，如教师的编号决定了教师的姓名和其它的数据项信息，而实体间的联系本身也是反映了一种函数依赖关系，但是这不是研究的对象，我们针对的是在一个关系模式中的函数依赖对象。
其次，对上一步确立的所有函数依赖进行检查，判别是否存在部分函数依赖以及传递函数依赖，针对有的依赖通过投影分解，消除在一个关系模式中存在的部分函数依赖和传递函数依赖。
大部分数据库系统只要满足第三关系范式就可以，这也是我们这里规范化的基本要求。由于需求分析阶段的方法得当，经过简单的分析可以看出，上述所有关系中每个数据项都是基本的，任何非主属性都不存在对主码的部分依赖，也不存在非主属性存在着对主码的传递依赖。可见，以上所有的关系模式都属于3NF。
16
17
在实际的应用中，关系模式的规范化程度并不是越高越好，因为在关系模式的规范化提升过程中，必须进行着将一个关系模式分解成为多个关系模式的过程。这样，在以后执行查询时，如果需要相关的信息，就必须作多个表的连接方能达到查询的目的，这无疑给系统增加一定的开销，特别存在很多用户同时访问或者关系中存在许多元组等因素其负担会越加明显。为了兼顾性能的需要，在适当的时候可能需要对相关程度比较高的一些关系模式进行合并处理，或者在关系模式中增加相关程度比较高的属性等。这是有可能选择第二范式甚至第一范式。
如果系统存在很多的元组数(记录数)，特别当记录达到百万甚至千万条记录时，系统的查询效率可能会受到明显的影响，分析关系模式的特点，可以根据某些关键属性不同将关系模式分解为多个关系模式，模式之间通过共同的主键一一对应起来。
前面设计出的教师、课程、班级、院系和学生等关系模式基本上是实际应用中事物的直接对应，一般不需要优化。
由于实际讲授安排都是后于学生选课行为之后进行的，因此“讲授”关系模式尽管是单独地放映了某一门课在某一个学期由某一个老师讲授，而一门课在一个学期也可以有多个老师主讲，关键还在于老师的讲课针对哪个(些)班级进行。“授课”关系的有关信息其实完全由课程学习关系模式中得到反映。所以可以合并“授课”到“课程学习”中去，实际上去除“授课” 关系模式便可。
对于“课程学习”关系模式，在上述需求分析阶段已经指出，选课后和成绩记录后都需经过教务员的审核确认方生效，对应需要增加审核信息属性。因此，对于“课程学习”关系模式修改为：课程学习(课程编号，学号，教师编号，开课年度，开课学期，成绩，课程审核，成绩审核)。
对于分析中提及的学生状态处理(转学、退学、休学或者毕业等的情况)，为了简单化，不妨给关系模式增加一个“状态”的属性，成为：学生(学号，姓名，性别，出生年月，电话，班级编号，状态)。
为了满足实际应用对系统的系统要求，必须对使用系统的用户如教师和学生增加登录的验证口令，因此需要在“教师”和“学生”的关系模式中增加口令属性。自然地，如果根据其它的安全应用要求，还可以设置学生的登录地点如通过增加IP 属性来达到目的等。
4.3 各个数据表的表结构设计
在上述经由E-R 模型得到关系模式并且得到适当的调整后，我们可以结合在需求表述中数据字典包含的数据项信息，得到数据库的表结构。我们应该根据4.1节的内容，具体设计各个数据表的表结构，包括表名，表中各列的字段名、数据类型、数据长度和表的主键和外键；还要考虑应该建立哪些索引以及索引的类型。
需要指出的是，考虑到系统的统一兼顾如对数据库管理员和后续软件开发中对数据以其缩写字母构成；同时要为各个表名和字段名作出完整的中文文档说明。
表1至表8给出了数据库中各个数据表的表结构。
表 5 数据库中表清单
表 6 学生信息表Student字段信息列表
表7 教师基本信息表Teacher字段信息列表
18
表8 系基本信息表Depart字段信息列表
表9 班级信息表Classes字段信息列表
表10 课程基本信息Course字段信息列表
表11学生选课信息表StuCourse字段信息列表
表12教学计划信息表Schedule字段信息列表
5 数据库的物理设计
数据库的物理设计任务，主要是将逻辑设计映射到存储介质上，利用可用的硬件和软件条件能可靠地、高效地对数据进行物理访问和维护。存储介质及其存储模式是任何关系数据库的关键组件。数据库的成功执行通常需要在工程的前期阶段精心设计。关系数据库的存储设计在此数据库设计过程中占了很大份量，其中主要考虑的内容：
①使用哪种类型的磁盘硬件，如RAID（独立磁盘冗余阵列）设备；
②数据在磁盘上如何放置即数据的分配策略；
③从访问性能的角度采用适当的索引技术和设计具体的索引项；
④以及基于特定数据库有关的参数配置以使数据库很好地运行。
5.1存储介质类型的选择
RAID（独立磁盘冗余阵列）是由多个磁盘驱动器（一个阵列）组成的磁盘系统，可提供更高的性能、可靠性、存储容量和更低的成本。容错阵列分为从0 到5 共 6 个RAID 等级。每个等级使用不同的算法实现容错。
SQL Server 一般使用RAID 等级0、1 和5(注:RAID仅在Windows NT 4.0 、Windows 2000 及Windows 2003等系统上配合使用)。
RAID0由于该等级使用数据分割技术(称为条带集)的磁盘文件系统，数据分成块并在阵列内的所有磁盘中按固定顺序展开。RAID 0 通过在多个磁盘内的独立而同时地数据的读/写操作,具备非常高的读写性能。但是这种组合方式和普通计算机上硬盘使用的模式一样没有任何容错机制，如果一个磁盘发生故障，则需要的所有数据将不可访问。因此关键数据不能安放在RAID0中。常用的关系数据库管理系统安装技术是在RAID 0 驱动器上配置数据库，然后将事务日志放置在镜像驱动器上(RAID 1)。通过镜像事务日志，可以为数据库获取最佳的磁盘I/O 性能并维护数据可恢复性（假定执行定期数据库备份）。
RAID1也称为镜像集的磁盘文件系统或称磁盘镜象系统。磁盘镜像提供选定磁盘的冗余的、完全一样的复本。所有写入主磁盘的数据均写入镜像磁盘。RAID 1提供容错能
20
数据库设计和编码规范 Version
目录
简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。
6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：
第八章数据库设计的典型案例 本章要点 ?学生选课管理系统的数据库设计 本章学习目标 ?学生选课管理系统的需求分析 ?学生选课管理系统的ER图 ?学生选课管理系统的关系数据库模式 ?学生选课管理系统数据库的建立
在第7章里我们已经学习了有关数据库设计的基本理论和方法。本章通过学生选课管理系统数据库设计案例，实际讲授数据库的设计方法，加深对第七章的理解，提高我们的综合设计的能力。 8.1 案例的系统需求简介 8.1.1总体需求简单介绍 需求分析阶段是数据库应用系统开发的最重要阶段。需求分析要求应用系统的开发人员按照系统的思想，根据收集的资料，对系统目标进行分析，对业务的信息需求、功能需求以及管理中存在的问题等进行分析，抽取本质的、整体的需求，为设计一个结构良好的数据库应用系统的逻辑模型奠定坚实的基础。 高等学校的学生选课管理系统，在不同的学校会有不同的特点，因为作为教务工作部分它和学校本身的行政制度有关。本章的目的在于，作为数据库设计和应用开发的运用对象，对业务进行适度的简化，突出比较核心的成分，如院系算作一个级别的概念而且直接管理班(跳过专业一级的设置)，学生的免修重修等情况处理、教师的管理没有细化等。 8.1.2用户总体业务构造 学生选课管理业务，包括4个主要部分：学生的学籍及成绩管理、制定教学计划、学生选课管理以及教学调度。各部分具体的容：
（1）学籍及成绩管理包括：各院系的教务员完成学生学籍注册、毕业、转学等处理，各授课教师完成所讲授课成绩的录入，然后教务员进行学生成绩的审核认可。（2）制定教学计划包括：由教务部门完成指导性教学计划、培养方案的确定，开设课程的注册和调整。 （3）学生选课包括：学生根据开设课程和培养计划(和自己的状况)选择自己本学期所选修课程，教务员对学生所选修课程的确认处理。(注意：一般的必修课程 是由教务员统一处理，只有辅修的课程才经过学生的选择过程) （4）执行教学调度包括：教务员根据本学期所开设的课程、教师上课的情况以及学生选课情况完成排课、调课等。 8.1.3其它要求 如安全性，系统环境要求(根据现有的设备情况进行系统运行)等，这些不是本章的核心容，所以就不再进一步叙述。 8.1.4系统功能设想 这里的功能划分，是根据第一阶段需求调查基础上进行的初步划分。随着需求调查的深入，功能模块随着对需求了解的明确得到调整。 教务管理业务的4个主要部分，可以将系统应用程序划分为对应得4个子模块：包括学籍及成绩管理子系统、教学计划管理子系统、学生选课管理子系统以及教学调
规范化－数据库设计原则 关系数据库设计的核心问题是关系模型的设计。本文将结合具体的实例，介绍数据库设计规范化的流程。摘要 关系型数据库是当前广泛使用的数据库类型，关系数据库设计是对数据进行组织化和结构化的过程，核心问题是关系模型的设计。对于数据库规模较小的情况，我们可以比较轻松的处理数据库中的表结构。然而，随着项目规模的不断增长，相应的数据库也变得更加复杂，关系模型表结构更为庞杂，这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的。更糟糕的是，由于表结构定义的不合理，会导致在更新数据时造成数据的不完整。因此，就有必要学习和掌握数据库的规范化流程，以指导我们更好的设计数据库的表结构，减少冗余的数据，借此可以提高数据库的存储效率，数据完整性和可扩展性。本文将结合具体的实例，介绍数据库规范化的流程。 序言 本文的目的就是通过详细的实例来阐述规范化的数据库设计原则。在DB2中，简洁、结构明晰的表结构对数据库的设计是相当重要的。规范化的表结构设计，在以后的数据维护中，不会发生插入（insert）、删除（delete）和更新（update）时的异常。反之，数据库表结构设计不合理，不仅会给数据库的使用和维护带来各种各样的问题，而且可能存储了大量不需要的冗余信息，浪费系统资源。 要设计规范化的数据库，就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。但是一些相关材料上提到的范式设计，往往是给出一大堆的公式，这给设计者的理解和运用造成了一定的困难。因此，本文将结合具体形象的例子，尽可能通俗化地描述三个范式，以及如何在实际工程中加以优化使用。规范化 在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化使用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是"数据库规范化"。后面我们将通过实例来说明具体的规范化的工程。关于什么是范式的定义，请参考附录文章1. 数据冗余 数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中，因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。 规范化实例 为了说明方便，我们在本文中将使用一个SAMPLE数据表，来一步一步分析规范化的过程。 首先，我们先来生成一个的最初始的表。 CREATE TABLE "SAMPLE" ( "PRJNUM" INTEGER NOT NULL, "PRJNAME" VARCHAR(200), "EMYNUM" INTEGER NOT NULL, "EMYNAME" VARCHAR(200), "SALCATEGORY" CHAR(1), "SALPACKAGE" INTEGER)
数据库课程设计题目16个经典实例 1、机票预定信息系统 系统功能得基本要求： 航班基本信息得录入,包括航班得编号、飞机名称、机舱等级等。机票信息，包括票价、折扣、当前预售状态及经手业务员等。客户基本信息，包括姓名、联系方式、证件及号码、付款情况等.按照一定条件查询、统计符合条件得航班、机票等;对结果打印输出. ２、长途汽车信息管理系统 系统功能得基本要求: 线路信息，包括出发地、目得地、出发时间、所需时间等.汽车信息：包括汽车得种类及相应得票价、最大载客量等.票价信息:包括售票情况、查询、打印相应得信息. 3、人事信息管理系统 系统功能基本要求： 员工各种信息:包括员工得基本信息,如编号、姓名、性别、学历、所属部门、毕业院校、健康情况、职称、职务、奖惩等;员工各种信息得修改;对转出、辞退、退休员工信息得删除；按照一定条件，查询、统计符合条件得员工信息;教师教学信息得录入：教师编号、姓名、课程编号、课程名称、课程时数、学分、课程性质等。科研信息得录入：教师编号、研究方向、课题研究情况、专利、论文及著作发表情况等.按条件查询、统计，结果打印输出. 4、超市会员管理系统 系统功能得基本要求: 加入会员得基本信息,包括:成为会员得基本条件、优惠政策、优惠时间等.会员得基本信息，包括姓名、性别、年龄、工作单位、联系方式等.会员购物信息：购买物品编号、物品名称、所属种类，数量,价格等。会员返利信息,包括会员积分得情况，享受优惠得等级等。对货物流量及消费人群进行统计输出。 5、客房管理系统 系统功能得基本要求： 客房各种信息，包括客房得类别、当前得状态、负责人等；客房信息得查询与修改，包括按房间号查询住宿情况、按客户信息查询房间状态等。以及退房、订房、换房等信息得修改。对查询、统计结果打印输出。 6、药品存销信息管理系统 系统功能基本要求 药品信息,包括药品编号、药品名称、生产厂家、生产日期、保质期、用途、价格、数量、经手人等；员工信息，包括员工编号、姓名、性别、年龄、学历、职务等;客户信息，包括客户编号、姓名、联系方式、购买时间、购买药品编号、名称、数量等。入库与出库信息，包括当前库存信息、药品存放位置、入库数量与出库数量得统计. ７、学生选课管理信息系统 系统功能基本要求 教师信息,包括教师编号、教师姓名、性别、年龄、学历、职称、毕业院校,健康状况等。学生信息，包括学号、姓名、所属院系、已选课情况等.教室信息,包括，可容纳人数、空闲时间等.选课信息，包括课程编号、课程名称、任课教师、选课得学生情况等。成绩信息,包括课程编号、课程名称、学分、成绩。按一定条件可以查询，并将结果打印输出。 8、图书管理系统
需求分析 (2) 1功能需求 (2) 2数据字典 (2) 3数据流图构建 (5) 系统数据库的逻辑结构设计 (6) 根据该网上书店的具体情况，调查管理业务流程是顺着系统信息流动的过程逐步地进行，内容包括各环节的业务处理、信息来源、处理方法、计算方法、信息流经去向、信息提供的时间和形态（报告、单据等）。本系统的最大特色，数据挖掘在业务流程中清晰可见。我们可以通过对数据库中用户购买信息的关联分析。进行数据挖掘。这是数据挖掘技术在网上书店中最有价值的体现之一。 系统业务流图描述如下： （1）用户在线更新购物车：用户在登陆成功后，通过图书查询，添加图书到购物车后，根据图书编号自动在数据仓库中的图书挖掘信息中寻找与图书关联的图书编号。 （2）用户在线下达图书订单：用户在添加购物车后，确定购物车的书籍及数量后，填写相应的订单信息，确定所填写的订单信息无误后，系统将产生此次订单的编号，完成在线下达订单。 （3）管理员订单处理：管理登陆成功后，会对未处理订单进行处理，处理成功后，向顾客发货。 （4）销售分析处理：通过对图书信息查询，统计图书销售情况。 （5）图书数据挖掘处理：通过对订单处理，创建图书数据仓库，进行图书数据挖掘找出图书之间的潜在关联。 本网站可分为前台管理和后台管理两部分：前台系统功能模块分为：商品展示模块、用户登录、购物车、自服务等模块。后台管理主要包括：商品管理、订单管理、会员管理、类别管理、用户留言管理，产品销售分析等。网上书店功能模块如图3-1所示： 图3-1网上书店功能模块图 前台各主模块的详细功能如下： （1）最新上架模块：展示出最新上市的图书供用户选择。 （2）特价书展示模块：展示出了一些特价图书。 （3）商品查询模块：包括模糊查询模块，和书的类别查询模块。 （4）用户登录\注册模块：用户登录、注册。 （5）商品详细信息展示模块：包括图书详细信息模块。 （6）购物车展示模块：包括已选购商品模块、推荐商品模块。当添加商品到购物车时，会在推荐商品模块中看到本系统为购物者推荐的商品。 （7）自服务展示模块：我的订单模块、个人信息模块。订单模块可以查看订单的状态，和订单的信息。通过个人信息模块可以修改自己信息。 （8）用户评论模块：用户对图书的评论。 后台主模块的功能如下： （1）类别管理：该模块对图书的类别进行添加、删除、修改 （2）商品管理：该模块主要对书籍进行增加、删除、修改管理 （3）订单管理：该模块对客户的订单进行管理，如出库订单。 （4）用户管理：该模块对会员信息进行增加、删除、修改。 （5）销售情况查询：该模块可以查询排行前十的图书信息。 （6）图书挖掘分析：通过对订单的分析，得出最优的匹配方案和相应的决
数据库设计实例分析 一、需求分析实例 现要开发高校图书管理系统。经过可行性分析和初步的需求调查，确定了系统的功能边界，该系统应能完成下面的功能： （1）读者注册。 （2）读者借书。 （3）读者还书。 （4）图书查询。 1、数据流图 顶层数据流图反映了图书管理系统与外界的接口，但未表明数据的加
工要求，需要进一步细化。根据前面图书管理系统功能边界的确定，再对图书管理系统顶层数据流图中的处理功能做进一步分解，可分解为读者注册、借书、还书和查询四个子功能，这样就得到了图书管理系统的第0层数据流图 从图书管理系统第0层数据流图中可以看出，在图书管理的不同业务中，借书、还书、查询这几个处理较为复杂，使用到不同的数据较多，因此有必要对其进行更深层次的分析，即构建这些处理的第1层数据流图。下面的图8-7分别给出了借书、还书、查询子功能的第1层数据流图
2、数据字典 2.1 数据项 数据项名称：借书证号 别名：卡号 含义说明：惟一标识一个借书证 类型：字符型 长度：20 …… 2.2 数据结构 （1）名称：读者类别 含义说明：定义了一个读者类别的有关信息 组成结构：类别代码+类别名称+可借阅数量+借阅天数+超期罚款额（2）名称：读者 含义说明：定义了一个读者的有关信息 组成结构：+性别+所在部门+读者类型 （3）名称：图书 含义说明：定义了一本图书的有关信息 组成结构：图书编号+图书名称+作者++价格 …… 2.3 数据流 （1）数据流名称：借书单 含义：读者借书时填写的单据 来源：读者 去向：审核借书 数据流量：250份/天
组成：借书证编号+借阅日期+图书编号 （2）数据流名称：还书单 含义：读者还书时填写的单据 来源：读者 去向：审核还书 数据流量：250份/天 组成：借书证编号+还书日期+图书编号 …… 2.4 数据存储 （1）数据存储名称：图书信息表 含义说明：存放图书有关信息 组成结构：图书+库存数量 说明：数量用来说明图书在仓库中的存放数 （2）数据存储名称：读者信息表 含义说明：存放读者的注册信息 组成结构：读者+卡号+卡状态+办卡日期 说明：卡状态是指借书证当前被锁定还是正常使用（3）数据存储名称：借书记录 含义说明：存放读者的借书、还书信息 组成结构：卡号+书号+借书日期+还书日期 说明：要求能立即查询并修改
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。 范式说明 1.1 第一范式（1NF）无重复的列 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。 说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 例如，如下的数据库表是符合第一范式的： 而这样的数据库表是不符合第一范式的：
数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。 1.2 第二范式（2NF）属性完全依赖于主键 [ 消除部分子函数依赖 ] 如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R 的某个候选键，则称为第二范式模式。 第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。 例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。 简而言之，第二范式（2NF）就是非主属性完全依赖于主关键字。 所谓完全依赖是指不能存在仅依赖主关键字一部分的属性（设有函数依赖 W→A，若存在XW，有X→A成立，那么称W→A是局部依赖，否则就称W→A 是完全函数依赖）。如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。 假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
超市POS管理系统 数据库设计 数据库在一个信息管理系统中占有非常重要的地位，数据库结构的设计好坏将直接对应用系统的效率以及实现的效果产生影响。数据库设计一般包括以下四个部分：数据库需求分析、数据库概念结构设计、数据库逻辑结构设计、数据库物理结构实现。 一、数据库需求分析 通过对超市管理工作过程的内容和数据流图分析，设计如下面的数据项和数据结构。 1、员工信息，包括的数据项有：员工编号，姓名，性别，职务，口令，权限级别、身份证号，所属部门编号等。 2、部门信息，包括的数据项有：部门编号，部门名称。 3、供应商信息，包括的数据项有：供应商编号，供应商名称，地址，邮政编码，电话号码，税号，银行帐号，开户银行，联系人，备注等。 4、会员信息，包括的数据项有：会员编号，姓名，性别，身份证号，消费总金额，积分等。 5、入库信息，包括的数据项有：入库编号，入库日期，商品编号，计量单位，入库价格，销售价格，数量，总金额，供应商编号，业务员编号等。 6、商品信息，包括的数据项有：商品编号，所属类别，数量，单价，商品名称等。 7、销售出货单主信息，包括的数据项有：销售日期，总金额，是否现金，是否会员，会员编号、收银号编号等。 8、销售出货单子信息，包括的数据项有：商品编号，数量，单价，折扣比例，金额等。 二、数据库概念结构设计 根据上面设计规划出的实体，我们对各个实体具体的描述E-R图如下：
图1 员工信息E-R图 图2 部门信息E-R图 图3 入库信息E-R图 图4 商品信息E-R图
图5 销售出货单主信息E-R图 图6 销售出货单子信息E-R图 图7 会员信息E-R图 图8 供应商信息E-R图
学生成绩管理系统 目录一：需求分析 二：系统功能描述 三：E-R图 四：数据库逻辑结构设计 五：数据库物理设计 六：代码设计 七：SQL代码 八：界面截图 一：需求分析： 随着学校的规模不断扩大，学生数量急剧增加，有关学生的各种信息量也成倍增长，对学生成绩信息的管理难度随之增大。面队如此庞大的信息量，这就需要学生成绩管理信息系统来提高学生管理工作的效率。通过这样的系统，做到信
息的规范管理、科学统计以及快速的查询和修改，从而减少管理方面的工作量。总体任务是要实现学生成绩信息关系的系统化、规范化和自动化。根据总体任务的要求进行需求分析得出，学生成绩管理信息系统需要完成的功能主要如下：学生基本信息的输入，其中包括学生学号、姓名、性别、所属学院，所属系别，所属班级、出生年月、籍贯、宿舍、联系方式等。 学校基本课程信息的输入，包括课程编号、课程名称、课程属性、课程描述以及完成该课程所得的学分。 教师基本信息的输入，其中包括教师编号，教师姓名，教师职称，所教课程，所教班级等情况 学生信息，教师信息，课程信息，学生考试成绩的插入，删除，修改、查询和统计。 识别每个用户的身份和密码，从而保证信息的安全性，防止信息的外泄和盗用。 还有，涉及到信息的增，删，改的，主要都是面向教务管理员，教师只能录入成绩，查询成绩，修改成绩，和查询个人信息，而学生只能登录查看自己的信息，查询成绩等。 二：系统功能描述 教务处（管理员） 教师学生
院
三：E-R图（概念结构建立）1）学生查询系统的分E-R图
2）教师查询更新系统的分E-R图 3）管理员分E－R图
数据库课程设计题目16个经典实例 1.机票预定信息系统 系统功能的基本要求： 航班基本信息的录入，包括航班的编号、飞机名称、机舱等级等。机票信息，包括票价、折扣、当前预售状态及经手业务员等。客户基本信息，包括姓名、联系方式、证件及号码、付款情况等。按照一定条件查询、统计符合条件的航班、机票等；对结果打印输出。 2.长途汽车信息管理系统 系统功能的基本要求： 线路信息，包括出发地、目的地、出发时间、所需时间等。汽车信息：包括汽车的种类及相应的票价、最大载客量等。票价信息：包括售票情况、查询、打印相应的信息。 3.人事信息管理系统 系统功能基本要求： 员工各种信息：包括员工的基本信息，如编号、姓名、性别、学历、所属部门、毕业院校、健康情况、职称、职务、奖惩等；员工各种信息的修改；对转出、辞退、退休员工信息的删除；按照一定条件，查询、统计符合条件的员工信息；教师教学信息的录入：教师编号、姓名、课程编号、课程名称、课程时数、学分、课程性质等。科研信息的录入：教师编号、研究方向、课题研究情况、专利、论文及著作发表情况等。按条件查询、统计，结果打印输出。 4.超市会员管理系统 系统功能的基本要求： 加入会员的基本信息，包括：成为会员的基本条件、优惠政策、优惠时间等。会员的基本信息，包括姓名、性别、年龄、工作单位、联系方式等。会员购物信息：购买物品编号、物品名称、所属种类，数量，价格等。会员返利信息,包括会员积分的情况，享受优惠的等级等。对货物流量及消费人群进行统计输出。 5.客房管理系统 系统功能的基本要求： 客房各种信息，包括客房的类别、当前的状态、负责人等；客房信息的查询和修改，包括按房间号查询住宿情况、按客户信息查询房间状态等。以及退房、订房、换房等信息的修改。对查询、统计结果打印输出。 6.药品存销信息管理系统 系统功能基本要求 药品信息，包括药品编号、药品名称、生产厂家、生产日期、保质期、用途、价格、数量、经手人等；员工信息，包括员工编号、姓名、性别、年龄、学历、职务等；客户信息，包括客户编号、姓名、联系方式、购买时间、购买药品编号、名称、数量等。入库和出库信息，包括当前库存信息、药品存放位置、入库数量和出库数量的统计。
（2008/2009学年第2学期第18-19 周）
数据库课程设计任务书 一、目的 1.掌握计算机管理信息系统设计的一般方法，主要包括系统分析、系统设计的组织 和实施。 2.关系型数据库管理系统的编程技术，并能独立完成一般小系统的程序设计、调试 运行等工作。 3.培养把所学知识运用到具体对象，并能求出解决方案的能力。 二、任务（任选其一） A.运用关系型数据库管理系统，实现本院图书馆管理信息系统。具体要求如下： —图书、资料的登记、注销和查询。 —借书证管理，包括申请、注销借书证，查询借书证持有人等。 —借还图书、资料的登记、超期处理，超期拒借等。 —图书、资料查询，借、还图书和资料情况查询。 —图书、资料借阅情况的统计分析，拒此作为图书馆图书、资料订够的依据之一。 （本项不作为基本要求） B.运用关系型数据库管理系统，实现服务电话管理系统 向客户现场派技术人员的服务公司可以用服务电话管理系统跟踪客户、员工、工作 订单、发票、付款等等。 要求： 数据库要存储以下信息： —客户信息 —客户工需单信息 —完成工需单所需人工 —完成工需单所需部件 —部件信息 —付款信息 —雇员信息 完成的功能： —输入/查看客户工需单信息 —输入/查看部件、雇员等其它信息 —付款 —打印发票等
三、结果形式 1．设计报告：含E-R图、数据字典、关系模式、关系实例、查询描述、关系代数、SQL 实现的查询语言及查询结果。 2．上机实现。 四、考核 1．课程设计态度（20分）。 2．递交的书面材料（40分）。 3．上机运行情况（40分）
目录 1.问题描述 (1) 1.1背景 (1) 1.2数据需求 (2) 1.3事物需求 (2) 1.4关系模式 (3) ２.方案图表设计 (3) 2.1E-R图 (3) 2.2数据流程图 (7) 2.3数据字典 (7) 2.4关系图： (9) 3.数据库源代码 (10) 3.1数据库建立 (10) 3.2数据初始化 (12) 4.结果数据处理 (14) 4.1单表查询 (14) 4.2超期处理 (16) 4.3还书操作 (17) 4.4借书操作 (19) 4.5书籍状态 (20) 4.6读者状态 (21) 5.结束语 (22) 5.1课程设计心得 (22) 1.问题描述 1.1背景 随着图书馆规模的不断扩大，图书数量也相应的增加，有关图书的各种信息量也成倍增加，
本文力图从企业运营和管理的角度，梳理出发掘大数据价值的一般规律: ?以数据驱动的决策，主要通过提高预测概率，来提高决策成功率； ?以数据驱动的流程，主要是形成营销闭环战略，提高销售漏斗的转化率； ?以数据驱动的产品，在产品设计阶段，强调个性化；在产品运营阶段，则强调迭代式创新。 从谷歌、亚马逊、Facebook、LinkedIn，到阿里、百度、腾讯，都因其拥有大量的用户注册和运营信息，成为天然的大数据公司。而像IBM、Oracle、EMC、惠普这类大型技术公司纷纷投身大数据，通过整合大数据的信息和应用，给其他公司提供“硬件+软件+数据”的整体解决方案。我们关注的重点是大数据的价值，第一类公司首当其冲。 下面就是这些天然大数据公司的挖掘价值的典型案例: 01 亚马逊的“信息公司” 如果全球哪家公司从大数据发掘出了最大价值，截至目前，答案可能非亚马逊莫属。亚马逊也要处理海量数据，这些交易数据的直接价值更大。作为一家“信息公司”，亚马逊不仅从每个用户的购买行为中获得信息，还将每个用户在其网站上的所有行为都记录下来：页面停留时间、用户是否查看评论、每个搜索的关键词、浏览的商品等等。这种对数据价值的高度敏感和重视，以及强大的挖掘能力，使得亚马逊早已远远超出了它的传统运营方式。 亚马逊CTO Werner Vogels在CeBIT上关于大数据的演讲，向与会者描述了亚马逊在大数据时代的商业蓝图。长期以来，亚马逊一直通过大数据分析，尝试定位客户和和获取客户反馈。“在此过程中，你会发现数据越大，结果越好。为什么有的企业在商业上不断犯错？那是因为他们没有足够的数据对运营和决策提供支持，”Vogels说，“一旦进入大数据的世界，企业的手中将握有无限可能。”从支撑新兴技术企业的基础设施到消费内容的移动设备，亚马逊的触角已触及到更为广阔的领域。 亚马逊推荐：亚马逊的各个业务环节都离不开“数据驱动”的身影。在亚马逊上买过东西的朋友可能对它的推荐功能都很熟悉，“买过X商品的人，也同
某大学图书管理系统的数据库分析与设计 （以下内容包括第3章介绍的数据库设计的几个阶段：需求分析，概念设计，逻辑设计与物理设计，通过阅读实例分析，请注意理解有关理论含义） 1．系统内部框架及数据字典（调查了解） 1.1信息分类及相互关系 某大学图书馆信息系统是围绕学校图书馆的各项业务活动而建立的，其中涉及的信息大体上可以分为四类：业务过程信息、读者信息、费用信息和管理信息。其中业务过程信息是指完成业务所产生的过程控制信息，如借阅信息、书刊出入库信息等，都是局部信息；读者信息是指在读者整个在校期间需要在整个系统范围内共享的信息，是基本信息；管理信息是由基本信息和业务过程信息加工得到的，如读者流动情况、书刊平均借阅天数、效率分析等，是派生信息。读者借阅活动和各类信息之间的关系 1.2贯穿系统的两条信息线 集成各局部系统的重要目标是确保整个系统不随着局部系统的改变而改变，不随着新系统的加入而发生大的变化。找出图书馆信息系统的内在联系，确立好各局部系统之间的接口，是实现这一目标的前提。 贯穿整个图书馆信息系统有两条信息线：读者信息线和费用信息线。以此为框架来构 ----------------------------精品word文档值得下载值得拥有 ----------------------------------------------
造和集成整个系统。 证件信息包括读者主索引、借阅记录等等；费用信息包括在各个环节发生的各类费用及消耗成本等。 这两条信息线在系统中体现为具体的数据结构，它独立于各局部系统而存在。从整体的、发展的角度来构筑好这一基础框架是本系统数据结构的核心。 2. 需求分析 （该阶段结果主要用数据流图和数据字典表示，该阶段是经过分析，抽象得到各子系统的数据流程图及数据字典） 2．1财务管理子系统 功能：负责全馆财务、物资采购及发放、安全保卫及卫生清洁等工作。其中财务管 理包括：全馆人员工资、奖金发放及经费管理。 凭证
一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求(现实世界的需求,在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式(信息世界模型,用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型,形成数据库逻辑模式。然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。 1.需求分析阶段 需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求。需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法:调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有:跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis,简称SA方法从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典 (Data Dictionary,简称DD来描述。
数据字典是各类数据描述的集合,它是关于数据库中数据的描述,即元数据,而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键。 数据项描述={数据项名,数据项含义说明,别名,数据类型,长度, 取值范围,取值含义,与其他数据项的逻辑关系} 数据结构描述={数据结构名,含义说明,组成:{数据项或数据结构}} 数据流描述={数据流名,说明,数据流来源,数据流去向, 组成:{数据结构},平均流量,高峰期流量} 数据存储描述={数据存储名,说明,编号,流入的数据流,流出的数据流, 组成:{数据结构},数据量,存取方式} 处理过程描述={处理过程名,说明,输入:{数据流},输出:{数据流}, 处理:{简要说明}} 2.概念结构设计阶段 通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点: (1具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识。
第10章图书管理系统数据库设计实例 通过前面章节对数据库基础知识的学习，本章将通过一个图书管理系统的数据库设计实例来重点讲述如何设计数据库。在设计数据库的过程中应该遵循哪些设计原则及技巧。通过本章的数据库实例设计，要求对数据库的整体过程有个概念性的理解，并能通过所学知识，在具体的开发环境下设计一个较优化数据库并实现设计过程。 10.1 数据库设计原则及技巧 10.1.1数据库设计原则 随着计算机技术越来越广泛地应用于国民经济的各个领域，在计算机硬件不断微型化的同时，应用系统向着复杂化、大型化的方向发展。数据库是整个系统的核心，它的设计直接关系系统执行的效率和系统的稳定性。因此在软件系统开发中，数据库设计应遵循必要的数据库范式理论，以减少冗余、保证数据的完整性与正确性。只有在合适的数据库产品上设计出合理的数据库模型，才能降低整个系统的编程和维护难度，提高系统的实际运行效率。虽然对于小项目或中等规模的项目，开发人员可以很容易地利用范式理论设计出一套符合要求的数据库，但对于一个包含大型数据库的软件项目，就必须有一套完整的设计原则与技巧。 1. 设计原则 在设计数据库时，至关重要的工作就是要理解为之建模的业务职能和表示这些业务职能的数据库概念及功能，并能准确地设计数据库，进而建立优化的业务模型。因为数据库的设计在整个系统中是至关重要的一步，一旦数据库设计完成，在进行修改及优化就需花费大量的时间。因此，再设计数据库时，应考虑以下事项： 1)规范命名。所有的库名、表名、域名必须遵循统一的命名规则，并进行必要说明，以方便设计、维护、查询。 2)控制字段的引用。在设计时，可以选择适当的数据库设计管理工具，以方便开发人员的分布式设计和数据小组的集中审核管理。采用统一的命名规则，如果设计的字段已经存在，可直接引用；否则，应重新设计。 3)库表重复控制。在设计过程中，如果发现大部分字段都已存在，开发人员应怀疑所设计的库表是否已存在。通过对字段所在库表及相应设计人员的查询，可以确认库表是否确实重复。 4)并发控制。设计中应进行并发控制，即对于同一个库表，在同一时间只有一个人有控制权，其他人只能进行查询。 5)必要的讨论。数据库设计完成后，数据小组应与相关人员进行讨论，通过讨论来熟悉数据库，从而对设计中存在的问题进行控制或从中获取数据库设计的必要信息。 6)数据小组的审核。库表的定版、修改最终都要通过数据小组的审核，以保证符合必要的要求。 7)头文件处理。每次数据修改后，数据小组要对相应的头文件进行修改（可由管理软件自动完成），并通知相关的开发人员，以便进行相应的程序修改。 2.设计技巧
1概述 1.1 目的 软件研发数据库设计规范作为数据库设计的操作规范， 详细描述了数据库设计过程及结果，用于指导系统设计人员 正确理解和开展数据库设计。 1.2 适用范围 1.3 术语定义 DBMS：数据库管理系统，常用的商业 DBMS有 Oracle, SQL Server, DB2 等。 数据库设计：数据库设计是在给定的应用场景下，构造 适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体- 关系 (Entity-RelationShip, 简称 E-R) 理论为基础，并对这一理论进 行了扩充。它从用户的观点出发对信息进行建模，主要 用于数据库概念级别的设计，独立于机器和各DBMS产品。可以用 Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产 品支持的数据模型，如关系模型，形成数据库逻辑模式。可
以用 Sybase PowerDesigner工具直接建立逻辑数据模型 （ LDM），或者通过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。可以用 Sybase PowerDesigner 工具直接建立物理数据模型（ PDM），或者通过 CDM / LDM 转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应 用系统的性能要求。 紧凑性：例如能用 char(10) 的就不要用 char(20) ，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容
数据库设计规范化的五个要求 通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表，二是宽表的数量是否足够的少。若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。 要求一：表中应该避免可为空的列。 虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。 所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。 一是通过设置默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段可能允许为空。因为不是每个人都可以记住自己的身份证号码。而在员工报到的时候，可能身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为0或者为N/A。以避免空字段的产生。 二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。而且，这些列在大部分情况下，都是可有可无的。若数据库管理员遇到这种情况，笔者建议另外建立一张副表，以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。 要求二：表不应该有重复的值或者列。 如现在有一个进销存管理系统，这个系统中有一张产品基本信息表中。这个产品开发有时候可以是一个人完成，而有时候又需要多个人合作才能够完成。所以，在产品基本信息表产品开发者这个字段中，有时候可能需要填入多个开发者的名字。 如进销存管理中，还需要对客户的联系人进行管理。有时候，企业可能只知道客户一个采购员的姓名。但是在必要的情况下，企业需要对客户的采购代表、仓库人员、财务人员共同进行管理。因为在订单上，可能需要填入采购代表的名字;可是在出货单上，则需要填入仓库管理人员的名字等等。 为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。 可是这么设计的话，会产生一系列的问题。如客户的采购员流动性比较大，在一年内换了六个采购员。此时，在系统中该如何管理呢?难道就建立六个联系人字段?这不但会导致空字段的增加，还需要频繁的更改数据库表结构。明显，这么做是不合理的。也有人说，可以
典型案例数据库设计 Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT
本科学生综合性实验报告 课程名称：数据库系统原理 电子商务数据库设计 项目组长学号 0061375 班级选课03班小组第12组 实验项目名称乐购电子商城销售系统设计 指导教师 开课学期 2008 至 2009 学年第一学期 完成时间 2008年 12 月 30 日 目录
1、需求分析 系统的功能描述 电子商城销售管理系统ESS用户分为三类： （1）商家管理员：此类客户可以取得商城管理员的权限，可以浏览所有客户信息，查找客户，给客户分配合理的权限，删除不合法客户等。 （2）商城游客：只可以浏览商城开放的业务和信息，不可以进行网上交 也不为该类客户提供个性化服务，该类客户无需注册。 （3）商城正式客户：必须在商城注册，登录本商城后，这类客户可以 览商城开放的业务和信息，可以进行网上交易，也可享受商城提供的个性化服务以及优惠服务等。 作为在线购物商城，前台销售系统提供以下功能：客户信息管理,商品信息管理,购物车管理，订单信息管理。 （1）客户信息管理 ①客户必须注册并登录本系统才能进行网上交易活动。一个客户只能拥有一个注册号（用户名），注册号可由客户根据自己的喜好自行定义，但必须唯一且在6-16位以内,且第一位必为字母C,其他只能由数字组成。 ②同一时间内一个注册号不能在多处登录。客户所填资料必须真实，其中注册号、密码、姓名、性别、地址、邮编为必填资料。 ③客户的积分将根据客户的订单金额逐次积累，即客户每购买一元的商品，则客户积分增加一分.其积分等级分为一钻,二钻,三钻,一钻客户为普通客户,积分为0-499分,不享受任何优惠;二钻客户积分为500-999分以内,所有商品九折优惠;三钻客户积分为1000分以上,所有商品八折优惠.当客户积分达到一定分数后,自动修改为相应等级。 ④客户注册成功以后，其注册信息将自动被加入客户表中。登录系统后，客户可以查询或修改个人信息。 （2）商品信息管理 ①客户登录本系统后，可以浏览本商城所展示的商品。 ②客户登录本系统后，可以查找自己所需要的商品。 ③客户登录本系统后，可以购买自己选中的商品。 （3）购物车管理