实例4：学生宿舍管理系统数据库设计
1. 系统需求分析阶段
1.1.2 需求分析阶段的任务
（1）处理对象：
系统要处理的对象包括宿舍楼基本信息、学生基本信息、宿舍基本信息、楼道工作人员基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息等七个方面，各个对象包括信息如下所示（详细的数据见于数据字典）：
1．宿舍楼基本信息(Dormitory)：包括宿舍楼编号、宿舍楼所在校区、宿舍楼再校区中区域、每一幢宿舍楼楼管处的电话、宿舍楼楼管员信息等方面，这样可以方便管理者对宿舍楼的管理，提高查询效率；
2．学生基本信息(Student)：包括学生编号、学生所在学院信息、学生姓名、学生性别、学生来自省份、学生出生日期、学生入学时间、学生所学专业、所在班级等方面的信息，可以方便学信息的查询和更新；
3．宿舍基本信息(Room，Fitment，FitmentDestruction，FitmentCompensate)：宿舍基本信息包括四个数据结构（宿舍信息(Room)，宿舍物品信息(Fitment)，宿舍物品损坏信息(FitmentDestruction),宿舍损坏物品赔偿信息）,每个数据结构中的数据项见数据字典；
4．楼道工作人员基本信息(Worker)：包括工作人员编号、工作人员姓名、工作类型、工资、性别、联系方式、工作时间等数据项，可以方便管理人员对宿舍楼道工人的任用、信息查询及更改；
5．宿舍保卫处基本信息(SafeGuard)：包括保卫处名称、人员数目、负责人信息、联系电话等四方面的信息；
6．宿舍事故基本信息(Acc ident，Acc identResearc h，Acc identCompensate)：事故信息包括三个数据结构（事故信息、事故处理信息、事故赔偿信息），具体的数据项见数据字典；物品出入基本信息(Artic alInOut)：包括出入物品的学生信息、出入的物品信息、出入物品时的负责人信息、出入物品时间，尽量减少宿舍事故的发生，保障学生宿舍财产的安全。
（2）处理功能要求
系统主要完成一下几个功能：
1．宿舍楼基本信息查询与修改；
2．学生基本信息查询与更新；
3．每一幢宿舍楼中宿舍信息的查询与信息更新；
4．宿舍保卫处基本信息的查询和修改；
5．宿舍事故基本信息及事故处理信息的查询和修改；
6．宿舍楼物品出入审批及记录；
（3）安全性和完整性要求
安全性先通过视图机制，不同的用户只能访问系统授权的视图，这样可提供系统数据一定程度上的安全性，再通过用户授权机制，欲用户登陆来识别用户级别，根据这个级别来分配用户权限，达到数据更高层次的安全保密功能。
完整性要求用于描述宿舍楼基本信息、学生基本信息、宿舍基本信息、楼道工作人员基本信息、宿舍保卫处基本信息、宿舍事故基本信息、物品出入基本信息中数据项能否为null，以及一些用户自定义完整性（符合实际要求），详细完整性要求见于系统的逻辑设计阶段。
1.1.3 需求分析阶段成果
（1）体会与收获
系统需求分析主要采取实地询问－记录和楼管处查询宿舍学生信息的方式，同时借鉴学长在做数据库开发这方面的经验。通过实地调查和询问，了解目前学生宿舍管理的现状，以及目前学生宿舍管理中一些问题，并对实际查询业务实地参与，了解了学生、楼管员、宿舍管理者、宿舍保卫人员对系统的信息处理要求，以及他（她）们对现存人工管理方式不能满足信息处理要求的苦恼。同时在调查中牵涉的许多的人际交流，恰当的询问方式，由于平时几乎没有做过这方面的调查，开始时有点胆怯和不知从何入手，但过了两三幢宿舍楼之后，开始的胆怯就感觉不到了。
（2）学生宿舍管理系统业务流程图
新生入住宿舍业务流程图：
查询业务流程图（查询宿舍学生信息、楼道工作人员信息、宿舍楼信息等）：
毕业生离宿业务流程图：
楼道工作人员任用业务流程图：
宿舍楼物品出入业务流程图：
宿舍事故处理业务流程图：
（3）数据流程图
顶层数据流程图：
第2层数据流程图：从学生角度出发
第2层数据流程图：从管理者角度出发
图2.3 从管理者角度出发的2层数据流程图
第3层数据流程图：从新生角度出发
第3层数据流程图：从毕业生角度出发
第3层数据流程图：从宿舍楼物品出入出发
第3层数据流程图：从宿舍事故角度出入出发
第3层数据流程图：从楼道工作人员的任用角度出发
第3层数据流程图：从管理者和外来访客的角度出发
（4）数据字典
（a）数据项：系统涉及的数据项有71项
表1.1 数据项列表
数据项编号数据项名数据项含义与其它数据项的关系存储结构别名
DI-1 StuNo 学生编号char(9) 学号
DI-2 DepName学生所在学院char(20) 学院
DI-3 StuName 学生姓名char(10) 姓名
DI-4 StuSex 学生性别char(2) 性别
DI-5 StuHome 学生来自省份char(10) 祖籍
DI-6 StuBorth 学生出生时间Date 出生日期DI-7 StuETime 学生入学时间Date 入学时间DI-8 StuPerfect 学生所在专业char(20) 专业
DI-9 StuClass 学生所在班级编号Int 编号
DI-10 WorNo 工作人员编号char(5) 编号
DI-11 WorName工作人员姓名char(10) 姓名
DI-12 WorType 工作类型char(8) 工作类型DI-13 WorWage 工作人员工资Int 月工资DI-14 WorSex 工作人员性别char(2) 性别
DI-15 WorPhNo工作人员联系方式char(12) 电话
DI-16 WorTime 工作人员工作时间char(30) 工作时间DI-17 RNo 宿舍编号char(6) 舍号
DI-18 RHeader 舍长信息等于StuName char(10) 舍长
DI-19 ROne 宿舍学生信息同上char(10) 舍员1 DI-20 RTwo 宿舍学生信息同上char(10) 舍员2 DI-21 RThree 宿舍学生信息同上char(10) 舍员3
DI-22 RFour 宿舍学生信息同上char(10) 舍员4 DI-23 RFive 宿舍学生信息同上char(10) 舍员5 DI-24 RSix 宿舍学生信息同上char(10) 舍员6 DI-25 RGrade 宿舍学生所属年级等于StuETime char(4) 年级
DI-26 RDepart 宿舍学生所在学院等于DepName char(20) 学院
DI-27 RPerfect 宿舍学生所学专业等于StuPerfect char(20) 专业
DI-28 RClass 学生所在班级编号等于StuClass char(2) 班级
DI-29 DorNo 宿舍楼编号smallint 宿舍楼号DI-30 DorCampus 宿舍楼所属校区char(4) 校区
DI-31 DorLocation宿舍楼在校区位置char(4) 宿舍区位DI-32 DorPhNo宿舍楼管处电话char(12) 电话
DI-33 DorAdminis t 宿舍楼楼管员信息等于WorNo char(10) 楼管员DI-34 SGName保卫处名称char(15) 名字
DI-35 SGWorNum保卫处人员总数Int 人员数目DI-36 SGHeader 保卫处负责人信息char(10) 负责人DI-37 SGPhone保卫处电话char(12) 电话
DI-38 FitName 宿舍物品名称char(16) 宿舍物品DI-39 FitPrice 宿舍物品价格Float 价格
DI-40 FitNum 每一种宿舍的数量Int 数量
DI-41 FDFitment 损坏物品信息等于FitName char(16) 物品名DI-42 FDStudent 损坏的学生信息等于StuNo char(9) 学生
DI-43 FDRoom 损坏物品宿舍信息等于RNo char(6) 舍号
DI-44 FDFitNum 损坏物品的数量Int 数量
DI-45 FCompFit 赔偿物品信息等于FitName char(16) 物品名DI-46 FCompStu 需赔偿学生信息等于StuNo char(9) 学生
DI-47 FCompMon赔偿价格Float 赔偿价格DI-48 FCompPrin赔偿负责人信息等于WorNo char(10) 负责人DI-49 FCompDate赔偿日期Date 日期
DI-50 FCompNum 赔偿物品数量Int 数量
DI-51 AcNo 事故编号int 编号
DI-52 AcType 事故类型char(10) 类型
DI-53 AcArtical事故损失物品char(30) 物品名DI-54 AcArNum 事故损失物品数量Int 数量
DI-55 AcStu 事故受害学生等于StuNo char(9) 学生
DI-56 AcDate 事故发生日期Date 日期
DI-57 AcPrin 事故负责人信息等于SGHeader char(15) 负责人DI-58 AcStuPh 受害人联系方式char(12) 学生电话DI-59 AcVerify 事故是否属实Bool 核查
DI-60 ARNo 事故调查编号char(4) 编号
DI-61 ARName 事故调查名称char(15) 调查
DI-62 ARPrin 事故调查负责人等于SGHeader char(10) 负责人DI-63 ARResult 事故调查结果Bool 结果
DI-64 ACStu 事故赔偿学生信息等于StuNo char(10) 学生
DI-65 ACArtical事故赔偿物品信息char(30) 物品名DI-66 ACDate 事故赔偿日期Date 日期
DI-67 ACPrin 事故赔偿负责单位等于SGHeader char(15) 负责单位DI-68 AIOStu 要求物品出入学生等于StuNo char(10) 学生
DI-69 AIOArtical出入物品信息char(20) 物品名DI-70 AIOPrin 出入物品审查人等于WorNo char(10) 负责人DI-71 AIODate出入物品日期Date 日期
DI-72 AIONo 物品出入序号Int 序号
（b）数据结构：
表1.2 数据结构列表
数据结构编号数据结构名
数据结构
含义
组成
DS-1 Student 宿舍学生信息StuNo,DepName,StuName,StuSex,StuHome, StuBorth,StuETime,StuPerfect,StuClass
DS-2 Worker 宿舍楼工作人员信息WorTime,WorName,WorType, WorWage,WorSex,WorPhNo,WorNo
DS-3 Room 宿舍信息RNo,RHeader,ROne, RClass, RThree,RFour,RFive,RSix,RGrade, RDepart,RPerfect,RTwo,
DS-4 Dormitory 宿舍楼信息DorNo,DorCampus,DorPhNo DorLocation,DorAdminist
DS-5 SafeGuard宿舍保卫处信息SGName,SGWorNum,SGHeader,SGPhone DS-6 Fitment 宿舍物品配备信息FitName,FitPrice,FitNum
DS-7 FitmentDes truction宿舍物品损坏信息FDFitment,FDStudent,FDRoom,FDFitNum
数据结构编号数据结构名
数据结构
含义
组成
DS-8 FitmentCompensate 宿舍损坏物品赔偿信
息
FCompFit,FCompStu,FCompPrin,
FCompDate,FCompNum
DS-9 Accident 宿舍事故注册信息AcNo,AcType, AcStu,AcDate, AcArtical,AcVerify,AcPrin, AcArNum,AcStuPh
DS-10 AccidentResearch宿舍事故调查信息ARNo,ARName,ARPrin,ARResult
DS-11 AccidentCompensate 事故损失物品赔偿信
息
ACStu,ACArtical,ACDate,ACPrin
DS-12 ArticalInOut 宿舍楼物品出入信息AIOStu,AIOArtical,AIOPrin,AIODate,AION o （5）处理逻辑描述（判定表或判定树）
表1.3 处理逻辑列表
2. 概念设计阶段
2.1 引言
概念设计阶段主要是将需求分析阶段得到的用户需求抽象为信息结构(概念模型)的过程,它是整个数据库设计的关键，包括概念模型设计和新系统流程两个阶段。
2.2 概念模型设计
（1）根据不同的对象，从第3层数据流程图（中层数据流程图）入手，分别画出分E－R 图：
（a）从数据流程图图2.4 与图 2.5 抽象出的分E－R图：
图3.1 分E－R图1
图3.2 分E－R图2
图3.3 分E－R图3
（b）从数据流程图图2.6与图2.8 抽象出的分E－R图：
图3.4 分E－R图4
（c）从数据流程图图2.7 抽象出的分E－R图：
图3.5 分E－R图5
（2）各分E－R图中每个实体的属性如下所示：
学生：Student(StuNo，DepName，StuName，StuSex，StuHome，StuBorth，StuETime，
StuPerfect，StuClass)；
宿舍：Room(RNo，RHeader，ROne，RClass，RThree，RFour，RFive，RSix，RGrade，RDepart，RPerfect，RTwo)；
宿舍楼：Dormitory(DorNo，DorCampus，DorLocation，DorPhNo，DorAdminist)；
宿舍物品：Fitment(FitName，FitPrice，FitNum)；
楼道工作人员：Worker(WorNo，WorName，WorType，WorWage，WorSex,
WorPhNo，WorTime)；
保卫处：SafeGuard(SGName，SGWorNum，SGHeader，SGPhone)；
各分E－R图中联系的属性如下所示：
物品出入：ArticalInOut(AIONo，AIOStu，AIOArtical，AIOPrin，AIODate)；
宿舍物品处理：包含物品损坏和物品赔偿两个数据结构(将在逻辑设计阶段给出)；
事故：包含宿舍事故注册、宿舍事故调查、事故损失物品赔偿三个数据结构(具体的结构将
在系统逻辑设计阶段给出)。
(注:为了节省篇幅，实体与属性的关系没有用图形表示，实体的标识码用下划线划出。)
（3）合并各分Ｅ－Ｒ图,消除属性冲突、命名冲突、结构冲突等三类冲突，得到初步E-R 图，
再消除不必要冗余，得到的基本E-R图如下所示：
2.3 新系统流程
新系统流程图：
3．逻辑设计阶段
3.1逻辑设计的任务和目标
以上的概念设计阶段是独立于任何一种数据模型的，但是逻辑设计阶段就与选用的DBMS产品发生关系了，系统逻辑设计的任务就是将概念设计阶段设计好的基本E-R图转换为选用DBMS产品所支持的数据模型相符合的逻辑结构。具体内容包括数据组织（将E-R图转换成关系模型、模型优化、数据库模式定义、用户子模式设计）、数据处理（画出系统功能模块图）两大任务
3.2数据组织
3.2.1将E-R图转换为关系模型
由于宿舍楼与楼道工人的联系方式是1:n（一对多），可以将其之间的联系与n端实体楼道工人合并，宿舍楼与宿舍之间的联系、宿舍与学生之间的联系方式也是1:n，同样也将其之间的联系与n端实体宿舍、学生合并，而宿舍物品与学生、学生与楼道工作人员之
间的联系方式则是n:m（多对多），这样要把它们之间的联系转化为独立的关系模式，保卫
处与学生之间的联系是1:n（一对多），但是它们之间的联系事故则包含数据结构，为了便于模型优化，将其联系也转化成独立的关系模式，具体的基本E-R图向关系模型的转化如下：
楼道工人：Worker（WorNo，WorName，WorType，WorWage，WorSex,
WorPhNo，WorTime，DorNo，DorCampus，DorLocation）；
宿舍楼：Dormitory（DorNo，DorCampus，DorLocation，DorPhNo，DorAdminist）；
宿舍：Room（RNo，RHeader，ROne，RClass，RThree，RFour，RFive，RSix，RGrade，RDepart，RPerfect，RTwo，DorNo，DorCampus，DorLocation）；宿舍物品：Fitment（FitName，FitPrice，FitNum，DorNo，DorCampus，DorLocation）；学生：Student（StuNo，DepName，StuName，StuSex，StuHome，StuBorth，StuETime，StuPerfect，StuClass，RNo，DorNo，DorCampus，DorLocation）；保卫处：SafeGuard(SGName，SGWorNum，SGHeader，SGPhone)；
物品出入：ArticalInOut(AIONo，StuNo，AIOArtical，AIOPrin，AIODate, DorNo，
DorCampus，DorLocation)；
宿舍物品处理包含两个数据结构（宿舍物品损坏信息，宿舍物品损坏赔偿信息），基于表的各个属性都是原子项的考虑，现将宿舍物品处理分解为：宿舍物品损坏、宿舍损坏物品赔偿，具体如下：
宿舍物品损坏：FitmentDestruction（FitName，StuNo，RNo，FDFitNum, DorNo，
DorCampus，DorLocation）；（消除命名冲突）
宿舍物品损坏赔偿：FitmentCompensate（FitName，StuNo，FCPrin，FCompDate，
FCompNum）；（消除命名冲突）
宿舍事故包含三个数据结构（宿舍事故注册信息、宿舍事故调查信息、宿舍事故损失物
品赔偿信息），同样基于表的原子性的考虑也将事故分解为：事故注册、事故调查、
事故赔偿，具体如下：
事故注册：Accident（AcNo，AcType，StuNo，AcDate，AcArtical，AcVerify，SGName，
AcArNum，AcStuPh）；
事故调查：AccidentResearch（AcNo，ARName，SGName，ARResult）；
事故赔偿：AccidentCompensate（AcNo，ACStu，AcArtical，ACDate，SGName）；（注：标有直线下划线的为主属性，标有波浪线下划线的是外键属性，主属性与外键属性一起构成主码）
3.2.2模型优化
关系模式Worker，Dormitory，Fitment，SafeGuard，ArticalInOut，FitmentDestruction，FitmentCompensate，Accident，AccidentResearch，AccidentCompensate不存在非主属性对主属性的部分函数依赖，也不存在传递函数依赖，已经达到了3NF，但是宿舍关系模式（Room）中存在着一些不应该有的数据冗余，现将模型优化为：
Room（R No，RHeader，RGrade，RDepart，RPerfect，DorNo，DorCampus，DorLocation）；虽然Room中还存在一些数据冗余，但可以提高查询效率。
3.2.3数据库模式定义
表2.1 数据库模式定义表
编号逻辑结构(基本表)定义完整性和安全性
T－１Worker（详见附录1－1）（详见附录1－1）
T－2 Dormitory（详见附录1－2）（详见附录1－2）
T－3 Room（详见附录1－3）（详见附录1－3）
T－4 Fitment（详见附录1－4）（详见附录1－4）
T－5 Student（详见附录1－5）（详见附录1－5）
T－6 SafeGuard（详见附录1－6）（详见附录1－6）
T－7 ArticalInOut（详见附录1－7）（详见附录1－7）
T－8 FitmentDes tructi on（详见附录1－8）（详见附录1－8）
T－9 FitmentCompensate（详见附录1－9）（详见附录1－9）
T－10 Accident（详见附录1－10）（详见附录1－10）
T－11 AccidentResearch（详见附录1－11）（详见附录1－11）
T－12 AccidentCompensate（详见附录1－12）（详见附录1－12）
3.2.4用户子模式设计
表2.2 用户子模式设计(View)列表
编号用户子模式
作用(共性：提供数据保密和安全保护机制) (View)
V－1 WorView 便于查询和修改楼道工人的基本信息
V－2 Dorm View方便宿舍楼的基本信息的查询、更新
V－3 Room View以便于宿舍的基本信息的查询和更新
V－4 FitView用于宿舍楼配备物品的基本信息的查询
V－5 StuView 便于查询和更改学生的基本信息
V－6 SGView 方便学生查询宿舍保卫处的基本信息
V－7 ArIOView以便于物品出入的管理和信息的查询、更改
V－8 FDView便于宿舍物品损坏的的登记及处理和信息的查询
V－9 FCView查询损坏物品赔偿的基本信息，便于宿舍物品的管理V－10 AccView方便学生事故的注册及保卫人员对事故注册的查询
V－11 ARView 便于学生查询宿舍事故调查的基本信息
V－12 ACView方便宿舍事故赔偿的信息查询和更新
3.3数据处理
系统功能模块图：
4．物理设计阶段
4.1物理设计阶段的目标与任务
数据库的物理设计就是为逻辑数据模型选取一个最合适应用要求的物理结构的过程，在这个阶段中要完成两大任务：
（1）确定数据库的物理结构，在关系数据库中主要是存取方法和存储结构；
（2）对物理结构进行评价，评价的重点是时间和空间效率。
4.2数据存储方面
为数据库中各基本表建立的索引如下：
1.由于基本表Room，Student的主码RNo，StuNo经常在查询条件和连接操作的连
接条件中出现，且它们的值唯一，考虑在两个属性上建立唯一性索引；
2.Dormitory的主码DorNo，DorCampus，DorLocation经常在查询条件中出现，且
它们的组合值唯一，考虑在它们之上建立组合索引；
3.基本表Student的一属性StuName，经常在查询条件中出现，且经常出现在相等
的比较条件中，考虑在其之上建立聚簇索引；
4.基本表Fitment、SafeGuard的属性值几乎不会有什么变化，更新率很低，可考虑
适当建立索引；
5.基本表Worker，ArticalInOut，FitmentDestruction，FitmentCompensate，
Accident，AccidentResearch，AccidentCompensate的属性值经常发生变化，权衡系统为维护索引付出的代价，可考虑不建立索引，也可以适当建立索引。
4.3系统功能模块
4.3.1 楼道工人基本的信息查询和更新模块
将实现对楼道工人基本信息的查询和更新（修改、插入、删除）操作，方便于楼道工人的任用和更换，具体的功能模块图如下：
图4.2 楼道工人基本信息的查询、更新功能模块图
(注：表示系统给用户的信息，以下与此相同)
4.3.2 宿舍楼基本信息的查询和更新模块
将完成对宿舍楼基本信息的查询、更新（修改、插入、删除）操作，便于宿舍的集中管理，具体的功能模块图如下所示：
图4.3 宿舍楼基本信息的查询、更新功能模块图
4.3.3 宿舍基本信息的查询和更新模块
将达到对宿舍基本信息的查询、更新（修改、插入、删除）操作的目的，具体的功能模块图如下所示：
图4.4 宿舍基本信息的查询、更新功能模块图
数据库课程设计题目16个经典实例 1、机票预定信息系统 系统功能得基本要求： 航班基本信息得录入,包括航班得编号、飞机名称、机舱等级等。机票信息，包括票价、折扣、当前预售状态及经手业务员等。客户基本信息，包括姓名、联系方式、证件及号码、付款情况等.按照一定条件查询、统计符合条件得航班、机票等;对结果打印输出. ２、长途汽车信息管理系统 系统功能得基本要求: 线路信息，包括出发地、目得地、出发时间、所需时间等.汽车信息：包括汽车得种类及相应得票价、最大载客量等.票价信息:包括售票情况、查询、打印相应得信息. 3、人事信息管理系统 系统功能基本要求： 员工各种信息:包括员工得基本信息,如编号、姓名、性别、学历、所属部门、毕业院校、健康情况、职称、职务、奖惩等;员工各种信息得修改;对转出、辞退、退休员工信息得删除；按照一定条件，查询、统计符合条件得员工信息;教师教学信息得录入：教师编号、姓名、课程编号、课程名称、课程时数、学分、课程性质等。科研信息得录入：教师编号、研究方向、课题研究情况、专利、论文及著作发表情况等.按条件查询、统计，结果打印输出. 4、超市会员管理系统 系统功能得基本要求: 加入会员得基本信息,包括:成为会员得基本条件、优惠政策、优惠时间等.会员得基本信息，包括姓名、性别、年龄、工作单位、联系方式等.会员购物信息：购买物品编号、物品名称、所属种类，数量,价格等。会员返利信息,包括会员积分得情况，享受优惠得等级等。对货物流量及消费人群进行统计输出。 5、客房管理系统 系统功能得基本要求： 客房各种信息，包括客房得类别、当前得状态、负责人等；客房信息得查询与修改，包括按房间号查询住宿情况、按客户信息查询房间状态等。以及退房、订房、换房等信息得修改。对查询、统计结果打印输出。 6、药品存销信息管理系统 系统功能基本要求 药品信息,包括药品编号、药品名称、生产厂家、生产日期、保质期、用途、价格、数量、经手人等；员工信息，包括员工编号、姓名、性别、年龄、学历、职务等;客户信息，包括客户编号、姓名、联系方式、购买时间、购买药品编号、名称、数量等。入库与出库信息，包括当前库存信息、药品存放位置、入库数量与出库数量得统计. ７、学生选课管理信息系统 系统功能基本要求 教师信息,包括教师编号、教师姓名、性别、年龄、学历、职称、毕业院校,健康状况等。学生信息，包括学号、姓名、所属院系、已选课情况等.教室信息,包括，可容纳人数、空闲时间等.选课信息，包括课程编号、课程名称、任课教师、选课得学生情况等。成绩信息,包括课程编号、课程名称、学分、成绩。按一定条件可以查询，并将结果打印输出。 8、图书管理系统
数据库的设计理论 第一节，关系模式的设计问题 一概念： 1. 关系模型：用二维表来表示实体集，用外键来表示实体间的联系，这样的数据模型，叫做关系数据模型。 关系模型包含内涵和外延两个方面： 外延：就是关系或实例、或当前值。它与时间有关，随时间的变化而变化。（主要是由于元组的插入、删除、修改等操作引起的） 内涵：内涵是与时间独立的，它包括关系属性、以及域的一些定义和说明。还有数据的各种完整性约束。 数据的完整性约束分为静态约束和动态约束。 静态约束包括数据之间的联系（称为数据依赖），主键的设计和各种限制。 动态约束主要定义如插入、删除和修改等操作的影响。 通常我们称内涵为关系模式。 2. 关系模式：是对一个关系的描述，二维表的表头那一行称为关系模式，又称为表的框架或记录类型。 关系模式的定义包括：模式名、属性名、值域名和模式的主键。关系模式仅仅是对数据特征的描述。 关系模式的一般形式为R ( U , D , DOM , F ) R 是关系名。 U 是全部属性的集合。 D 是属性域的集合。 DOM 是U 和D 之间的映射关系，关系运算的安全限制。 F 是属性间的各种约束关系，也称为数据依赖。
关系模式可以表示为： 关系模式（属性名1，属性名2 ，……，属性名n ） 示例：学生（学号，姓名，年龄，性别，籍贯）。 当且仅当U 上的一个关系r 满足 F 时，r 就称为关系模式R（U，F）上的一个关系，R是关系的型，r 是关系的值，每个值称为R 的一个关系。 关系数据库模式： 一个数据库是由多个关系构成的。 一个关系数据库对应多个不同的关系模式，关系数据库模式是一个数据库中所有的关系模式的集合。它规定了数据库的全局逻辑结构。 关系数据库模式可以表示为： S = { Ri < Ui , Di , DOM , Fi > | i = 1,2,…, n } 3. 关系子模式 关系子模式是用户所用到的那部分数据的描述。 外模式是关系子模式的集合。 4. 存储模式 存储模式及内模式。 关系数据库理论的主要内容： （1）数据依赖。数据依赖起着核心的作用。 （2）范式。 （3）模式的设计方法。 如何设计一个合理的数据库模式： （1）与实际问题相结合。 泛关系模式：把现实问题的所有属性组成一个关系模式 泛关系：泛关系模式的实例称为泛关系。 泛关系模式中存在的问题： a 数据冗余 b 更新异常， c 插入异常 d 删除异常。
第四章关系数据库设计理论练习题 一、选择题 1、关系规范化中的删除操作异常是指①A，插入操作异常是指②D A、不该删除的数据被删除. B、不该插入的数据被插入; C、应该删除的数据未被删除; D、应该插入的数据未被插入. 2、关系数据库规范化是为解决关系数据库中（）问题而引入的。 A、插入异常、删除异常和数据冗余； B、提高查询速度; C、减少数据操作的复杂性; D、保证数据的安全性和完整性。 3、假设关系模式R（A，B）属于3NF，下列说法中（）是正确的。 A、R一定消除了插入和删除异常； B、R仍可能存在一定的插入和删除异常; C、R一定属于BCNF； D、A和C都是. 4、关系模式的分解 A、唯一 B、不唯一. 5、设有关系W（工号，姓名，工种，定额），将其规范化到第三范式正确的答案是（） A、W1（工号，姓名），W2（工种，定额）； B、W1（工号，工种，定额），W2（工号，姓名）； C、W1（工号，姓名，工种），W2（工种，定额）; D、以上都不对. 6、设学生关系模式为：学生（学号，姓名，年龄，性别，平均成绩，专业），则该关系模式的主键是（） A、姓名； B、学号，姓名； C、学号; D、学号，姓名，年龄. 7根据数据库规范化理论，下面命题中正确的是（） A、若R∈2NF,则R∈3NF B、若R∈1NF,则R不属于BCNF C、若R∈3NF,则R∈BCNF D、若R∈BCNF,则R∈3NF 8、关系数据库设计理论中，起核心作用的是 A、范式； B、模式设计； C、函数依赖; D、数据完整性. 9、设计性能较优的关系模设称为规范化，规范化的主要理论依据是（） A、关系规范化理论; B、关系运算理论；
目录 一、设计目的....................................... 错误!未定义书签。 二、设计内容....................................... 错误!未定义书签。 三、设计过程....................................... 错误!未定义书签。 E-R模型设计............................................ 错误!未定义书签。 关系模型设计........................................... 错误!未定义书签。 数据库的实现........................................... 错误!未定义书签。 四、设计总结....................................... 错误!未定义书签。 五、参考文献....................................... 错误!未定义书签。
小区物业管理系统数据库设计与实现 一、设计目的 经过十几年的发展，中国房地产业逐步走向成熟，物业管理也由新生到发展再到深入，面临着蓬勃发展的局面。随着ISO9002等管理体系在物业管理中的引入，对原有的物业管理模式进行了一次深刻的变革，对物业管理公司朝着正规化、科学化、集团化的发展，起到有力的推动作用。 随着我国经济发展和城市开发，住宅小区越来越成为居住的主流，小区物业管理是针对当代社会这一市场需要应运而生的。本系统是为住宅小区物业管理部门日常管理工作信息化，规范化而开发的软件。它以物业管理部门为服务中心，以业主（住户）为服务对象。通过实施各种服务项目，全面地反映了在小区物业经营管理活动中，物业部门与业主之间各种业务往来。使各项业务的办理迅速、准确，极大的提高了小区物业管理的工作效率。 由于物业管理涉及的管理范围较为广泛，管理内容繁杂，加上政策性的变动因素，日常工作需要耗费大量人力和物力，而采取现代化电脑管理手段是一种行之有效的解决方法，用计算机操作的小区物业管理系统是为小区管理者和小区用户更好的维护各项物业管理业务处理工作而开发的管理软件。 数据库在一个管理系统中占有非常重要的地位，数据库结构设计的好坏将直接对应用系统的效率，以及实现的效果产生影响。合理的数据库结构设计可以提高数据存储的效率，保证数据的完整和一致。设计数据库系统时应该首先充分了解用户各个方面的需求，包括现有的及将来可能增加的需求。 二、设计内容 （1）E-R模型设计：对物业公司、业主等实体进行抽象，提取相关属性；并设计出E-R图； （2）关系模型设计：根据E-R模型图，将E-R模型转化为关系模型；要求关系模型符合3NF要求； （3）数据库的实现：在SQL Serve 2000中实现数据库及各数据表的建立。 三、设计过程 E-R模型设计 作为物业公司，主要是对物业公司员工进行管理，任务分配是由系统用户分配的，物业公司员工负责维护小区以及为业主服务，根据以上分析，可以大
目录 一Codd的RDBMS12法则——RDBMS的起源 二关系型数据库设计阶段 三设计原则 四命名规则 数据库设计，一个软件项目成功的基石。很多从业人员都认为，数据库设计其实不那么重要。现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。多数人使用数据库中的一部分，所以也会把数据库设计想的如此简单。其实不然，数据库设计也是门学问。 从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计（后期调优需要DBA）。根据笔者的项目经验，一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化，如果追其原因，笔者个人猜测是因为数据库的规范化，与OO的部分思想雷同（如内聚）。而DBA，设计的数据库的优势是能将DBMS的能力发挥到极致，能够使用SQL和DBMS实现很多程序实现的逻辑，与开发者相比，DBA优化过的数据库更为高效和稳定。如标题所示，本文旨在分享一名开发者的数据库设计经验，并不涉及复杂的SQL语句或DBMS使用，因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开发者能有所帮助，也希望读者能帮助笔者查漏补缺。 一 Codd的RDBMS12法则——RDBMS的起源 Edgar Frank Codd（埃德加·弗兰克·科德）被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年，Codd 博士发布了12条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。 1. 信息法则关系数据库中的所有信息都用唯一的一种方式表示——表中的值。 2. 保证访问法则依靠表名、主键值和列名的组合，保证能访问每个数据项。 3. 空值的系统化处理支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。 4. 基于关系模型的动态联机目录数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样 的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用 户可以访问的表中。 5. 统一的数据子语言法则一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少 有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规 则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是SQL) 6. 视图更新法则所有理论上可以更新的视图也可以由系统更新。 7. 高级的插入、更新和删除操作把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应 于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视 作集合。 8. 数据的物理独立性不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都 保持着逻辑上的不变性。 9. 数据的逻辑独立性当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑 上的不变性。 10. 数据完整性的独立性专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义，而且可以存储在数据目录中，而非程序中。
需求分析 (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．住宿管理部门 它也是酒店基本部门之一。住宿管理部门的主要职责有：A.给个房间布置各种设备、分类、编号、制定收费标准、分配服务人员。B.登记旅客信息，确认其身份，登记其入住、退房时间。C.统计各类房间的客满程度。D.对本部门的财务流动进行登记处理。以上信息处理可以通过计算机完成，其他不便于计算机操作的在此没有列出。 3．娱乐管理部门 娱乐是酒店非主流服务，它的存在除了赢利，更多的是为了吸引顾客食宿。娱乐部门的特点与饮食部门很相似，不便于使用计算机进行操作。可以用计算机完成并且有必要用计算机完成的有：A.制定收费标准，分配负责人.B.收入支出财务处理：编号、财务来源去处的摘要、数量、单价、数额、
[运网物流管理系统] 开发文档 [版本：2.0] 班级： 2003级计算机科学与技术3班开发小组组长: 邓彬（20034043180） 开发组成员：汪庆春（20034043179）、 邹奇（20034043181）、 黄键（20034043107）指导老师：何迎生 二〇二一年一月二十七日星期三
摘要 《运网物流管理系统》是一个基于https://www.doczj.com/doc/d21699902.html,开发的Web物流管理管理系统。作为B/S结构的web数据库管理系统，本系统具有所有B/S结果系统的优点，同时又具有https://www.doczj.com/doc/d21699902.html,的高效的优势。 从技术上说，本系统采用了C#编写，充分利用https://www.doczj.com/doc/d21699902.html,强大的组件DATAGRID，结合https://www.doczj.com/doc/d21699902.html, 对任务书中的物流管理的SQL Server2000数据库进行管理。通过本系统可以对数据库执行添加、删除、修改、查询等全面的操作。系统支持分页功能，能支持大量数据的存储。我利用具有高安全性的Cookie作为安全校验的依据，对用户的权限进行审核，提供系统的安全保障。 从功能上说，本系统主要分为2大模块：用户登陆模块和数据操作模块。通过用户登陆模块能对用户身份进行核实和验证，通过数据操作模块能对物流系统的相关信息进行操作，添加删除修改在一个页面内完成，直观简洁。 作为课程设计，本系统达到了设计任务的基本要求，并在其上才用了更先进的语言，提供了更强大的扩展能力和更好的执行效率，作为一个完善的系统的雏形，本系统只要进入软件开发的螺旋法则，不久之后就可以进化为一个成熟的，能让最终用户所接受的系统。 此次课程设计内容则是以c# 作为开发语言，编写https://www.doczj.com/doc/d21699902.html, 程序，c#是一门全新的语言，具有更强大的编辑和操作能力，在此过程中，我又开始了认真的从无到有的学习，通过锲而不舍的实践操作和对各种相关书籍的钻研，终于理解了c#的语言，并迅速开发出了本系统。 在学习和实践的过程中，我充分体会到了c#和.Net技术的强大，在学习的过程中，我认识了几个来自Microsoft 社区的MVP，在通过和他们交流和认真学习他们编写的经验文章后，我已经能更好的理解 .Net 平台的运行机制，从内核这个层次认识到了Microsoft 给作为程序员的我们带来了什么。 本文关于运网物流管理系统的设计是在何迎生老师的指导下完成的。经过一个学期的设计，我们基本完成了任务。设计过程中，何迎生老师给予了我们极大的帮助与鼓励，在此，我们对他的悉心指导表示衷心的感谢! 关键字：运网物流管理,C#,https://www.doczj.com/doc/d21699902.html,, B/S, Web 第一章绪论
图书销售 建立某中小型书店图书销售管理信息系统的数据库。 1. 基本需求分析 1）组织结构 对组织结构的分析有助于分析业务范围与业务流程。书店的组织结构如图三所示。 图三书店组织结构简图 其中，书库是保存图书的地方；购书/服务部负责采购计划、读者服务、图书预订等业务；售书部负责图书的销售。财务部负责资金管理；人事部负责员工管理与业务考核。 2）业务分析 对于信息处理系统来说，划分系统边界很重要，即哪些功能由计算机来完成，哪些工作在计算机外完成。这些要通过业务分析确定。同时，业务流程中涉及的相关数据也通过业务分析得到归类和明确。在业务分析的基础上，确定数据流图和数据字典。 本系统主要包含以下业务内容。 ①进书业务。事先采购员根据订书单采购图书。然后将图书入库，同时登记相应的图书入库数据。 本项业务涉及的数据单据和表格有：进书单（包括进书单编号、日期、金额、经手人等）和进书单细目（一个进书单可能有若干种图书。进书单的细目数据包括每种图书的信息、定价、进价或折扣，数量），以及书库账本（图书信息、库存数量、价格等）。 ②售书业务。售书员根据读者所购图书填写售书单（如图四所示）。同时，修改库存信息。
本项业务涉及和产生的数据表格有：售书单（包括售书单编号、售书日期、金额、员工）、售书细目（一个售书单可能有若干种图书。售书细目包括该次售书的书籍编号、售出数量、折扣、售出价格等），以及书库账本。 图四售书单样式 ③图书查询服务业务。根据读者要求，提供本书店特定的图书及库存信息。 本项业务涉及的主要数据是书库账本。 ④综合管理业务。包括进书信息、销售信息、库存信息的查询、汇总和报表输出。 本项业务涉及所有的进书数据、销售数据和库存数据等。 3）处理的数据 上面的分析将本系统的业务归纳为4项。在业务分析的基础上，应该画出系统的数据流图。整个系统的分层数据流图将揭示一个系统内全部的数据项、数据结构、数据存储以及对数据的加工处理功能。在此基础上就可以建立系统的数据字典。本书不讨论数据流图和完整的数据字典规范等内容，仅对最后建立数据库所需要的数据进行分析说明。 在上述4项业务中涉及到的业务数据包括：进书数据、库存数据、销售数据。在这些数据中又涉及到图书数据、员工数据等，而图书数据与出版社有关，员工与部门有关。 因此，将所有数据进行归类分析，书店销售管理信息系统要处理的数据应该包括：
第4章关系数据库设计理论 选择题答案： (1) A (2) B (3) B (4) A (5) D (6) B (7) C (8) B (9) B (10) C (11) D (12) A (13) D (14) D (15) B (16) B (17) D (20) C (21) C (23) A (26) B (27) B (28) B (29) B (30) B (31) D (33) B B D 一、选择题： 1. 为了设计出性能较优的关系模式，必须进行规范化，规范化主要的理论依据是（）。 A. 关系规范化理论 B. 关系代数理论C．数理逻辑 D. 关系运算理论 2. 规范化理论是关系数据库进行逻辑设计的理论依据，根据这个理论，关系数据库中的关系必须满足：每一个属性都是（）。 A. 长度不变的 B. 不可分解的 C．互相关联的 D. 互不相关的 3. 已知关系模式R（A，B，C，D，E）及其上的函数相关性集合F＝{A→D，B→C ，E→A }，该关系模式的候选关键字是（）。 A.AB B. BE C.CD D. DE 4. 设学生关系S（SNO，SNAME，SSEX，SAGE，SDPART）的主键为SNO，学生选课关系SC（SNO，CNO，SCORE）的主键为SNO和CNO， 则关系R（SNO，CNO，SSEX，SAGE，SDPART，SCORE）的主键为SNO和CNO，其满足（）。 A. 1NF B.2NF C. 3NF D. BCNF 5. 设有关系模式W（C，P，S，G，T，R），其中各属性的含义是：C表示课程，P表示教师，S表示学生，G表示成绩，T表示时间，R表示教室，根据语义有如下数据依赖集：D={ C→P，（S，C）→G，（T，R）→C，（T，P）→R，（T，S）→R }，关系模式W的一个关键字是（）。 A. （S，C） B. （T，R） C. （T，P） D. （T，S） 6. 关系模式中，满足2NF的模式（）。 A. 可能是1NF B. 必定是1NF C. 必定是3NF D. 必定是BCNF 7. 关系模式R中的属性全是主属性，则R的最高范式必定是（）。 A. 1NF B. 2NF C. 3NF D. BCNF 8. 消除了部分函数依赖的1NF的关系模式，必定是（）。 A. 1NF B. 2NF C. 3NF D. BCNF 9. 如果A－>B ,那么属性A和属性B的联系是（）。 A. 一对多 B. 多对一C．多对多 D. 以上都不是 10. 关系模式的候选关键字可以有1个或多个，而主关键字有（）。 A. 多个 B. 0个 C. 1个 D. 1个或多个 11. 候选关键字的属性可以有（）。 A. 多个 B. 0个 C. 1个 D. 1个或多个 12. 关系模式的任何属性（）。 A. 不可再分 B. 可以再分 C. 命名在关系模式上可以不唯一 D. 以上都不是 13. 设有关系模式W（C，P，S，G，T，R），其中各属性的含义是：C表示课程，P表示教师，S表示学生，G表示成绩，T表示时间，R表示教室，根据语义有如下数据依赖集：D={ C→P，（S，C）→G，（T，R）→C，（T，P）→R，（T，S）→R }，若将关系模式W分解为三个关系
学生成绩管理系统 目录一：需求分析 二：系统功能描述 三：E-R图 四：数据库逻辑结构设计 五：数据库物理设计 六：代码设计 七：SQL代码 八：界面截图 一：需求分析： 随着学校的规模不断扩大，学生数量急剧增加，有关学生的各种信息量也成倍增长，对学生成绩信息的管理难度随之增大。面队如此庞大的信息量，这就需要学生成绩管理信息系统来提高学生管理工作的效率。通过这样的系统，做到信
息的规范管理、科学统计以及快速的查询和修改，从而减少管理方面的工作量。总体任务是要实现学生成绩信息关系的系统化、规范化和自动化。根据总体任务的要求进行需求分析得出，学生成绩管理信息系统需要完成的功能主要如下：学生基本信息的输入，其中包括学生学号、姓名、性别、所属学院，所属系别，所属班级、出生年月、籍贯、宿舍、联系方式等。 学校基本课程信息的输入，包括课程编号、课程名称、课程属性、课程描述以及完成该课程所得的学分。 教师基本信息的输入，其中包括教师编号，教师姓名，教师职称，所教课程，所教班级等情况 学生信息，教师信息，课程信息，学生考试成绩的插入，删除，修改、查询和统计。 识别每个用户的身份和密码，从而保证信息的安全性，防止信息的外泄和盗用。 还有，涉及到信息的增，删，改的，主要都是面向教务管理员，教师只能录入成绩，查询成绩，修改成绩，和查询个人信息，而学生只能登录查看自己的信息，查询成绩等。 二：系统功能描述 教务处（管理员） 教师学生
院
三：E-R图（概念结构建立）1）学生查询系统的分E-R图
2）教师查询更新系统的分E-R图 3）管理员分E－R图
数据库课程设计题目16个经典实例 1.机票预定信息系统 系统功能的基本要求： 航班基本信息的录入，包括航班的编号、飞机名称、机舱等级等。机票信息，包括票价、折扣、当前预售状态及经手业务员等。客户基本信息，包括姓名、联系方式、证件及号码、付款情况等。按照一定条件查询、统计符合条件的航班、机票等；对结果打印输出。 2.长途汽车信息管理系统 系统功能的基本要求： 线路信息，包括出发地、目的地、出发时间、所需时间等。汽车信息：包括汽车的种类及相应的票价、最大载客量等。票价信息：包括售票情况、查询、打印相应的信息。 3.人事信息管理系统 系统功能基本要求： 员工各种信息：包括员工的基本信息，如编号、姓名、性别、学历、所属部门、毕业院校、健康情况、职称、职务、奖惩等；员工各种信息的修改；对转出、辞退、退休员工信息的删除；按照一定条件，查询、统计符合条件的员工信息；教师教学信息的录入：教师编号、姓名、课程编号、课程名称、课程时数、学分、课程性质等。科研信息的录入：教师编号、研究方向、课题研究情况、专利、论文及著作发表情况等。按条件查询、统计，结果打印输出。 4.超市会员管理系统 系统功能的基本要求： 加入会员的基本信息，包括：成为会员的基本条件、优惠政策、优惠时间等。会员的基本信息，包括姓名、性别、年龄、工作单位、联系方式等。会员购物信息：购买物品编号、物品名称、所属种类，数量，价格等。会员返利信息,包括会员积分的情况，享受优惠的等级等。对货物流量及消费人群进行统计输出。 5.客房管理系统 系统功能的基本要求： 客房各种信息，包括客房的类别、当前的状态、负责人等；客房信息的查询和修改，包括按房间号查询住宿情况、按客户信息查询房间状态等。以及退房、订房、换房等信息的修改。对查询、统计结果打印输出。 6.药品存销信息管理系统 系统功能基本要求 药品信息，包括药品编号、药品名称、生产厂家、生产日期、保质期、用途、价格、数量、经手人等；员工信息，包括员工编号、姓名、性别、年龄、学历、职务等；客户信息，包括客户编号、姓名、联系方式、购买时间、购买药品编号、名称、数量等。入库和出库信息，包括当前库存信息、药品存放位置、入库数量和出库数量的统计。
数据库设计实例 数据库设计是数据库应用系统设计的一个组成部分，其核心是针对于特定的应用环境，设计合理的数据模型，创建数据库及其应用系统，使之能够有效地存储和处理数据，以满足用户的应用需求。从实用角度出发，数据库设计可分为如下几个步骤： 第一步：创建概念数据模型 ◆确定实体和关系 ◆确定属性 ◆规化数据 第二步：生成物理数据模型 第三步：验证设计 为便于学习者理解和掌握，下面结合具体的实例来讲解和展示数据库设计的详细过程。假定我们要开发一个小型的ERP系统，以管理公司部资源，其应用业务场景描述如下： v512工作室由IT业界专业人士组成，在提供高端IT培训业务的同时，还自主制作并免费发布大量公益性学习资源，工作室以公司形式运营，目前共拥有18名员工，这些员工分属于4个部门，且员工之间存在上下级管理关系。计划将来根据业务的发展设立更多的部门，聘用更多的员工。为保证质量，工作室对其成员的各项专业技能进行了级别评定。 8.5.1 确定实体和关系 1. 确定高级别的活动 要确定本ERP系统数据库设计中的实体和实体间关系，首先应明确要基于该数据库执行的高级别活动，这里所谓的高级别活动是指从用户的视角出发，确定本数据库设计中系统所涉及到的业务活动。比如，存储和维护员工的个人信息等。 在前述的应用业务场景中，v512工作室需要考虑的高级别活动包括： -聘用新员工 -解雇现有员工 -维护员工的个人信息 -增设新部门 -裁撤现有部门 -维护部门信息 -维护工作室业务相关的技能信息 -维护各员工的业务技能掌握情况 2. 确定实体 接下来要确定的是，针对上述的高级别活动需要记录和维护有关哪些事物的信息，这些事物将被转换为实体。其中，员工相关信息可抽象为“Employee”实体、部门相关信息可抽象为“Department”实体、技能相关信息抽象为“Skill”实体，为规和方便起见，这些实体均采用英文命名，并尽量在名称中体现其含义。 3. 确定关系 进一步对上述高级活动进行分析，以确定实体间存在何种关系。具体包括： -Employee-Department实体之间存在隶属关系 员工必须且只能隶属于某一个特定的部门，一个部门可以包含0～多名员工，此为一对多关系。 这种从两个方向上对同一个关系的细化描述被称为关系的角色，每个关系都对应两种角色。
摘要 数据库技术是计算机科学技术发展最快，应用最为广泛的技术之一。其在计算机设计，人工智能，电子商务，企业管理，科学计算等诸多领域均得到了广泛的应用，已经成为计算机信息系统和应用的核心技术和重要基础。 随着信息技术的飞速发展,信息化的大环境给各成人高校提出了实现校际互联,国际互联,实现静态资源共享,动态信息发布的要求; 信息化对学生个人提出了驾驭和掌握最新信息技术的素质要求;信息技术提供了对教学进行重大革新的新手段;信息化也为提高教学质量,提高管理水平,工作效率创造了有效途径. 校园网信息系统建设的重要性越来越为成人高校所重视. 利用计算机支持教学高效率，完成教学管理的日常事务，是适应现代教学制度要求、推动教学管理走向科学化、规范化的必要条件；而教学管理是一项琐碎、复杂而又十分细致的工作，工资计算、发放、核算的工作量很大，不允许出错，如果实行手工操作，每月须手工填制大量的表格，这就会耗费工作人员大量的时间和精力，计算机进行教学管理工作，不仅能够保证各项准确无误、快速输出，而且还可以利用计算机对有关教学的各种信息进行统计，同时计算机具有手工管理所无法比拟的优点.例如:检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高员工工资管理的效率,也是教学的科学化、正规化管理，与世界接轨的件。在软件开发的过程中，随着面向对象程序设计和数据库系统的成熟，数据设计成为软件开发的核心，程序的设计要服从数据，因此教学管理系统的数据库设计尤其重要。 本文主要介绍教学管理系统的数据库方面的设计，从需求分析到数据库的运行与维护都进行详细的叙述。本系统利用IBM DB2企业版本开发出来的。DB2是IBM公司开发的关系关系数据库管理系统，它把SQL语言作为查询语言。 本文的分为5章。其中第1章主要是课题简介及设计的内容与目的。第2章是需求分析，此阶段是数据库设计的起点。第3章是概念设计，它是将需求分析的用户需求抽象为信息结构，这是整个数据库设计最困难的阶段。第4章是逻辑结构设计，它将概念模型转换为某个DBMS所支持的数据模型。第5章是数据库的实施与运行，它包括数据的载入及数据库的运行。 关键词：SQL语言；IBM DB2；数据库设计；教学管理系统 I
数据库课程设计报告 教学管理系统 数据库设计 课程设计题目教学管理系统学院软件学院 班级软件技术四班年级2013级 姓名彭超李新徐彤（2014 年11月）
用5行左右的文字对系统进行简要介绍 对教学管理信息统一规范整理，实现各种信息的自动管理。为便于信息的查询，找出各种信息的关联性，根据各种需求设计出合理的报表。 减轻教学日常信息管理的负担，方便学生、教师查询信息和学校对所有信息的管理。以简单便捷的操作获取详尽的信息。 一、数据需求分析 某学校设计学生教学管理系统。学生实体包括学号、姓名、性别、生日、民族、籍贯、简历、登记照，每名学生选择一个主修专业，专业包括专业编号、名称和类别，一个专业属于一个学院，一个学院可以有若干个专业。学院信息要存储学院号、学院名、院长。教学管理还要管理课程表和学生成绩。课程表包括课程号、课程名、学分，每门课程由一个学院开设。学生选修的每门课程获得一个成绩。另外，为了管理教师教学安排，教师包括编号、姓名、年龄、职称，一个教师只能属于一个学院，一名教师可以上若干门课程，一门课程可以有多名老师来上，每个教师所上的每门课都有一个课堂号和课时数。 本系统数据字典如下： 数据项表
数据流 数据流表 二、概念结构设计 1．首先确定系统中的实体 从以上数据需求可以看出，系统共包括5个实体：学生、专业、学院、教师、课程。
2．再确定系统中实体间的关系 根据数据需求描述推出：专业与学生是1对多关系；学生与课程是多对多关系；课程与老师是多对多关系；课程与学院是多对1关系；学院与专业是1对多关系；学院与教师是1对多关系。 3．转化成E-R图 图1 实体-属性图 图2 教学管理ER图 三、逻辑结构设计
1.前言 (2) 1.1选题的理由和实际意义 (2) 1.2国内外关于该课题的研究现状及趋势 (3) 2需求分析 (5) 2.1 用户对系统要求 (5) 2.2功能介绍 (5) 3 系统设计 (7) 3.1定义 (7) 3.2系统模块图 (7) 3.4 数据表的设计 (8) 3.5 用例列举 (11) 3.5.1建立数据表 (11) 3.5.2建立视图 (14) 3.5.3建立索引 (15) 3.5.4约束条件的增加、删除、修改 (15) 3.5.5查询语句 (15) 3.5.6建立存储过程，触发器 (17) 4 总结 (18)
1.前言（本部分要有因果关系，前后通顺）1.1选题的理由和实际意义 随着IT事业的发展，如今，我们已经全面跨入信息时代。计算机被广泛的应用于各个行业，人工战略已经转化为信息战略，如何在短时间内获取大量信息并整合信息，成为立足于时代的关键。 为了适应考生人数的急剧增长，当今社会各大高校都在进行扩招政策，学生数量的急剧增加带来信息量的成倍增长，由于信息管理的不善与疏忽，各大高校大小事故时有发生。进行正确的信息管理，对于信息及时处理和反应，能够最大程度的减少学校以及在校学生的损失，减小潜在危机。 学生宿舍是学生生活的基本单位，是同学休息与学习的地方，为了保障同学入住学生宿舍的安全性，信息的处理和管理极为重要。据了解，本校的宿舍信息管理仍然使用传统的手工方式，主要方式是基于文本、表格等纸介质的手工处理，用人工手抄对男女生信宿信息进行处理登记。数据信息处理工作量大，容易出错且不易修改；由于数据繁多，容易丢失，逐条查找记录的方式不易操作，浪费了大量的时间，效率极低。学校的宿舍管理缺乏系统，规范的信息管理手段。 建立学生宿舍管理系统，使宿舍管理工作系统化，规范化，便捷化，程序化，避免宿舍管理的随意性，提高信息处理的速度和准确性，能够及时、准确、有效的查询和修改宿舍情况。 随着高校规模的扩大,在校学生的基本情况随之层次化、多样化、复杂化，相应的，学生管理工作面临严峻的挑战。高校学生信息日渐庞大，相应的宿舍管理工作变得复杂而困难。传统的账本化工作模式，手工记录学生信息并存档，这样的人工管理方式费时、费事、费力，信息获取慢,更新滞后，查阅困难,容易出错。为了给学生提供一个安全舒适的工作、生活、学习环境，方便宿舍管理工作的同时为学生、教师提供准确实时的信息至关重要。 本校的宿舍信息管理，主要方式是基于文本、表格等纸介质的手工处理，用人工手抄对男女生信宿信息进行处理登记。数据信息处理工作量大，容易出错且不易修改；由于数据繁多，容易丢失，逐条查找记录的方式不易操作，浪费了大量的时间，效率极低。 以上的管理缺陷对学生宿舍管理造成了相当大的阻力，工作进展困难，问题
目录 一 Codd的RDBMS12法则——RDBMS的起源 二关系型数据库设计阶段 三设计原则 四命名规则 数据库设计，一个软件项目成功的基石。很多从业人员都认为，数据库设计其实不那么重要。现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。多数人使用数据库中的一部分，所以也会把数据库设计想的如此简单。其实不然，数据库设计也是门学问。 从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计（后期调优需要DBA）。根据笔者的项目经验，一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化，如果追其原因，笔者个人猜测是因为数据库的规范化，与OO的部分思想雷同（如内聚）。而DBA，设计的数据库的优势是能将DBMS的能力发挥到极致，能够使用SQL和DBMS实现很多程序实现的逻辑，与开发者相比，DBA优化过的数据库更为高效和稳定。如标题所示，本文旨在分享一名开发者的数据库设计经验，并不涉及复杂的SQL语句或DBMS使用，因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开发者能有所帮助，也希望读者能帮助笔者查漏补缺。 一?Codd的RDBMS12法则——RDBMS的起源 Edgar Frank Codd（埃德加·弗兰克·科德）被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年，Codd 博士发布了12条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。 1.信息法则?关系数据库中的所有信息都用唯一的一种方式表示——表中的值。 2.保证访问法则?依靠表名、主键值和列名的组合，保证能访问每个数据项。 3.空值的系统化处理?支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。 4.基于关系模型的动态联机目录?数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样 的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用 户可以访问的表中。 5.统一的数据子语言法则?一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少 有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规 则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是SQL) 6.视图更新法则?所有理论上可以更新的视图也可以由系统更新。 7.高级的插入、更新和删除操作?把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应 于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视 作集合。 8.数据的物理独立性?不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都 保持着逻辑上的不变性。 9.数据的逻辑独立性?当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑 上的不变性。 10.数据完整性的独立性?专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义，而且可以存储在数据目录中，而非程序中。
9.2 一个完整的数据库管理系统实例 很多人都有过到书屋租书的经历，我们往往会为老板的健忘以及业务的混乱恼火！那么我们就来建立图书租借系统为那些老板解忧吧！ 9.2.1 数据分析并创建表 书店的业务看似简单，其实也需要仔细分析才能理出头绪。下面列出了需要的数据。 ●与顾客相关的数据：顾客姓名，顾客编号，电话，是否会员，会员编号，地址。 ●与书籍相关的数据：图书编号，几册装，图书名称，作者编号，作者，类型编号， 类型，出版社编号，出版社名称，电话，一般价，会员价。 ●租借记录：顾客姓名，借阅日期，是否归还，归还日期，借阅图书。 ●会员缴款记录：缴款编号，缴款日期，客户编号，缴款金额。 以上列出了需要的数据，但是依照上述数据建立的表格会出现数据的重复及冗余。因此，我们要在分析的基础上建立表间的关联。很显然，与书籍有关的数据可以分拆成四个表，分别为： ●图书清单表：图书编号（索引），几册装，一般价，会员价，图书名称。 ●作者名单表：作者编号（索引），姓名。 ●图书类型表：类型编号（索引），类型。 ●图书名单表：图书编号（索引），图书名称。 ●出版社名单：出版社编号（索引），出版社名称，电话。 在表的分析基础上,我们可以设计出8个表,分别为“书籍清单”，“顾客名单”和“租借记录”3个主表，以及“书籍类型”、“书籍名单”、“作者名单”、“出版社名单”与“会员缴款记录”5个附表。建立的关系如图1-1所示。 图9-1 建立的表关系视图
接下来我们将分别建立这8个表。 （1）书籍清单表：首先鼠标单击任务窗格中【新建】|【空数据库】选项，打开如图9-2所示窗口。 图9-2 新建空数据库窗口 在上图中选择保存路径及名称，本例保存在E：/数据库实例文件夹下，命名为书籍租借管理系统。鼠标单击【创建】按钮。打开数据库窗口如图9-3所示。 图9-3 数据库窗口 在这个窗口里就可以利用以前学的知识建立表了，下面以顾客记录表为例，其它表大家自己创建。首先选择表对象，鼠标单击【新建】按钮，选择“设计视图”后，单击【确定】按钮，如图9-4所示。