数据库设计

数据库设计
数据库设计

数据库设计实验

1 目的及要求

本实验的实验目的是了解数据库设计和系统开发的具体过程和方法,获取数据库设计和开发的初步经验。具体要求是:对一个具体应用问题实施需求分析、概念结构设计、逻辑结构设计、数据库物理设计、数据库实施、数据库运行与维护等步骤,设计和开发一个可以运行的数据库应用系统,提交一份设计实验报告(电子版),其中应包括整个数据库设计和开发过程的较详尽说明。

本实验的内容包括:

1)对一个具体应用领域进行调查分析,写出满足一定要求的需求分析文档,包括各层数据流图和数据字典;

2)按照一定的原则和步骤,从面向具体应用领域的需求分析文档导出数据库应用系统的概念结构——总E-R图,写出满足一定要求的概念结构设计文档;

3)按照一定的原则和步骤,从总E-R图导出关系数据库模式,根据关系数据库规范化理论进行优化,按各个具体应用的要求设计常用查询、创建视图,形成外模式;

4)设计数据库的存储结构和完整性。

5)按照逻辑数据库和物理数据库设计结果,创建具体数据库应用系统所涉及的各种数据对象并进行数据入库。

6)编制和调试具体数据库应用系统的各个应用程序。

7)通过对数据库应用系统的试运行进行调试和验收。

2 基本原理

数据库设计需要经历需求分析、概念结构设计、逻辑结构设计、数据库物理设计、数据库实施、数据库运行与维护等六个阶段。通过大量的数据库设计实践,人们已获取了这些阶段的一些成功经验和原则。在此对这六个步骤及其设计方法、原则和经验等进行简单介绍。要求实验小组尽量按照这些方法和原则进行数据库设计,已取得初步设计经验。

1.1 需求分析

需求分析的目的是为了明确用户需求,从而合理地确定数据库系统的功能。需求分析的主要任务包括通过调查,对用户需求(数据要求、业务处理流程和性能要求、完整性要求、安全性要求)进行收集和分析,并用易于理解的方式表达出来。

需求分析的步骤包括:1)调查与初步分析;2)分析和表达需求。

调查与初步分析的步骤包括:1)调查组织机构,包括部门组成、工作角色、职责和涉及的具体业务等;2)熟悉业务:即了解各具体业务所需数据及其来源、业务处理流程和结果去向等;3)明确需求,即取得用户认可;4)确定系统边界,即确定哪些任务由计算机完成,哪些任务由人工完成。

常用的调查方法包括:1)跟班作业,即亲自参与业务活动,了解业务活动情况;2)开会调查,与用户进行座谈;3)请业务专家介绍业务,向业务专家询问业务;4)问卷调查;5)查阅业务记录,对业务记录进行分析。

分析和表达需求的目的是用逐层细化的数据流图和数据字典逐层表达数据和处理,目

前常用自顶向下的结构化分析方法,其基本步骤包括:1)划分系统,即将系统按部门或工作角色划分为若干子系统(视图),得到最高层的数据流图;2)表达各个子系统(视图),即首先将子系统(视图)抽象成一个处理,然后将处理分解细化为若干个子处理,数据随之分解,接着继续分解子处理,从而得到多层数据流图和数据字典,直到把需求表达清楚为止。

1.2 概念结构设计

概念结构是对现实世界的抽象模拟,常以E-R模型为工具。概念结构设计是指将需求分析结果抽象为概念结构的过程。

概念结构设计常用的自底向上设计方法,这一方法包括下列步骤:1)数据抽象与局部视图设计;2)视图的集成;3)概念结构验证

数据抽象与局部视图设计的目的是根据需求分析结果设计各个局部视图(即分E-R 图),这些局部视图的设计步骤包括:1)选择局部应用:以中层数据流图作为设计分E-R 图的依据;2)逐一设计分E-R图:首先标定局部应用中的实体、实体的属性和码,然后确定实体之间的联系及其类型。

视图集成的目的是将各个局部视图(即分E-R图)进行集成,消除冲突和冗余,最终得到数据库的概念结构-基本E-R图。视图集成的步骤包括:1)合并分E-R图,生成初步E-R图,目的在于消除各个分E-R图之间的属性冲突、命名冲突和结构冲突;2)修改与重构,生成基本E-R图,目的在于消除冗余数据和冗余联系。

概念结构验证的目的是检查概念结构是否具有一致性(内部无矛盾)、准确性(能准确反映原来的视图结构,包括实体、属性、联系)并满足需求分析的要求(支持所需处理的实现)。若存在问题则作进一步的修改,直到满足要求为止。

1.3 逻辑结构设计

逻辑结构设计的目的是将基本E-R图按照具体DBMS所支持的数据模型(关系、网状、层次)的要求,转换成逻辑结构,以便在DBMS上进行实现。设计步骤为:1)将概念结构转换为一般数据模型(关系、网状、层次),目前常用关系模型;2)结合具体DBMS的特点和限制,将一般数据模型转换为具体DBMS支持的数据模型;3)对数据模型进行优化。

将E-R图转换为关系模型目前有7条原则,具体请参考课本或课程教案。一般数据模型到具体数据模型的转换则要视具体情况确定,在此不作介绍(一般而言,SQL Server支持的关系模型可以满足大多数实际应用的需求,但是其字段的最大长度仅为8000个字节,不能用于哪些具有长字段要求的实际应用)。

优化关系模型的步骤包括:1)确定各个关系模式所包含的数据依赖,其中绝大多数是函数依赖;2)对数据依赖进行极小化处理,即消除可由其他依赖推出的依赖;3)分析各关系模式,考查是否存在部分依赖、传递依赖、多值依赖等,确定关系模式所属的范式;4)分析关系模式是否适合具体应用环境,确定是否进行合并或分解;5)对关系模式进行必要的分解或合并。

1.4 数据库物理设计

数据库物理设计目的是选取适合应用环境的物理结构(存储结构、存取方法),以提高应用系统的时空效率,其设计步骤包括:1)确定数据库的物理结构;2)评价数据库的物理结构,重点是时空效率。

确定数据库的物理结构包括以下几个方面:1)确定各种数据库对象的存储结构,以满足存取时间、存储空间利用率和维护代价的要求;2)设计数据的存取路径,在关系模型的

情况下就是要确定如何建立索引,即确定在哪些域上建索引、建单码索引还是组合索引、建多少索引、是否建聚簇索引等等;3)确定数据的存放位置,就是要将数据划分为易变部分和稳定部分、经常存取的部分和不经常存取的部分等,将不同的部分分开存放,存入不同的文件组(表空间)和设备,目的在于提高运行效率,降低数据管理的代价;4)确定系统配置,就是要给出合适的存储分配参数值,进行物理优化。

评价物理结构的目的是从多种可能的物理结构方案中选择一个较优的可行方案。评价的重点是系统的时间效率、空间效率、维护代价等因素,这些因素往往是相互矛盾的,需要根据具体情况进行折衷。物理结构评价往往采用估算的方法,即根据应用特点、硬件环境、软件环境等因素,建立代价模型,画出代价曲线进行比较,从而选出较优的可行方案。

1.5 数据库实施

数据库实施的内容包括:1)定义数据库的结构,即创建表、视图、索引等;2)数据抽取、转换和装载,即从数据源(文本文件、Web、数据文件、原始凭证等)提取所需数据,将这些数据转换成符合数据库要求的格式,最后将它们装载到数据库中。数据量较小时也可用人工录入方式进行;3)编程、调试。本步骤可以使用模拟数据,和数据抽取、转换和装载同步进行;4)数据库试运行,即对数据库系统进行联合调试,测试各应用程序的功能(功能测试)和系统的性能指标(性能测试)。

1.6 数据库运行与维护

各项测试通过后,数据库就可以投入运行了。数据库的运行标志着维护工作的开始。数据库维护是长期的任务,代价很大,所以在签订合同时一定要明确维护的期限和内容,避免不必要的纠纷。数据库的日常维护工作由DBA完成,包括:1)定期进行数据库备份和恢复;2)进行安全性、完整性控制,即进行用户权限管理、约束修改等工作;3)进行性能监督、分析和改进,通过及时调整系统参数,改进系统性能;4)进行数据库的重组织和重构造,即解决碎片引起性能下降问题, 重新安排存储位置、回收垃圾、减少指针链。

3 实验报告提纲

1. 引言(企业简介;企业目前存在哪些问题,计算机能够解决哪些问题等)

21世纪,人类已全面进入数字信息化社会,现在信息技术的应用越来越普及,不但促进了社会的高速发展,也影响着人们的工作、学习、生活和娱乐的方式以及思想观念。随着科学技术的不断提高,计算机科学与技术日渐成熟,其强大的功能已为人们深刻认识,它已进入人类社会的各个领域,迅速地改变着人类社会的生产方式和生活方式,成为减轻人们体力与脑力劳动,帮助人们完成一些人们难以完成任务的有效工具。

随着电脑的普及与使用,现在的管理也提升了一个档次,渐渐实现了无纸化办公。高校是科研的阵地,后勤的公寓管理也应该一改传统的人工管理,更加信息化,时代化,节省人力物力,提高效率。基于这一点,开发此学生公寓管理系统。

2. 需求分析说明书

3.1.1学生公寓需求简介

学生公寓管理应考虑以下几方面的要求:

用户需求:可以对学生公寓进行有效的管理,包括公寓信息、寝室信息、学生住宿资料以及交费信息等。

学生方面:让学生感觉到学校的管理透明。

学校方面:可以查询每一个学生的相关信息。

来访人员方面:为防止公寓安全,所有来访人员必须提供学生住宿的公寓号和寝室号才可以进入公寓。

3.1.2功能性需求

软件需求分析是指对目标软件系统在功能、行为、性能、设计约束等方面的期望。需求分析是软件设计、实现测试直至维护的主要基础,良好的需求分析可以避免或尽早提出早期的错误,从而降低软件的开发成本,改进软件的质量。

本学生公寓管理系统应完成以下任务:

学生寝室基本信息管理:首先统一安排学生入住,如果有学生要更换寝室,可以方便查到哪个寝室还有空床,包括该寝室内已住学生的基本信息,安排入住。

学生公寓管理:可以添加新建公寓的信息,以及添加该公寓内的寝室信息,以及修改公寓和寝室的相关信息(公寓号和寝室号)。

寝室收费管理:收费以寝室为单位。

来访人员管理:对来访人员进行严格登记,包括来访时间,结束时间,来访人员的来访事由,能查询到每一条来访人员和被访人的信息。

2.1 调查与初步分析

1)调查组织机构,包括部门组成和工作角色等;

财务管理人员、寝室管理员、学生、外来访问人员

2)企业各部门的日常业务流程简介(业务流程描述,原始表单格式)

学生寝室按时交纳水电费;

宿管员记录每个寝室入住情况;

宿管员处可存放贵重物品;

宿管员对寝室卫生进行评比;

宿管员登记外来人员;

财务管理人员查看欠费和余额较少的寝室,并通知学生;

3)确定系统边界,即确定哪些任务由计算机完成,哪些任务由人工完成。

由计算机完成:缴费管理;外来人员登记;欠费通知;记录每个寝室入住情况;

其余由人工完成

2.2 分析和表达需求

1)划分系统,即将系统按部门或角色划分为若干子系统(视图),得到最高层的数据流图;

图3.1 组织结构图

公寓管理(记录公寓基本信息,使用者:宿管员)

学生管理(插入、修改、删除学生信息,寝室信息,使用者:宿管员)

外来人员登记(插入、删除外来人员信息,使用者:宿管员)

水费、电费(记录缴费种类,缴费信息,费用余额,是否欠费)

催促缴费(使用者:财务人员)

2)表达各个子系统(视图),即首先将子系统(视图)抽象成一个处理,然后将处理分解细化为若干个子处理,数据随之分解,接着继续分解子处理,从而得到多层数据流图和数据字典,直到把需求表达清楚为止。

图3.2 编辑信息胡DFD

图3.3 学生入住的DFD

图3.4 学生缴费的DFD

图3.5 学生离校DFD

图3.5 来访登记DFD

3. 概念结构设计说明书

3.1 设计各个子系统(视图)的分E-R图

1)选择中层数据流图作为设计分E-R图的依据;

2)逐一设计分E-R图:确定局部应用中的实体、实体的属性、码、实体之间的联系及其类型。

图3.7 公寓ER图

图3.8 寝室ER图

图3.9 来访人ER图

图3.10 缴费管理ER图

3.2 视图的集成

1)合并分E-R图,消除冲突,生成初步E-R图。

2)修改与重构,消除初步E-R图中的冗余数据和冗余联系,生成基本E-R图。

图3. 总ER图

3.3 概念结构验证

检查概念结构是否具有一致性(内部无矛盾)、准确性(能准确反映原来的视图结构,包括实体、属性、联系)并满足需求分析的要求(支持所需处理的实现)。若存在问题则作进一步的修改,直到满足要求为止。

4. 逻辑结构和物理结构设计说明书

4.1 将概念结构转换为关系模型

学生(学号,姓名,性别,出生日期,专业,班级,公寓号,寝室号,联系方式)

寝室(寝室号,公寓号,可住人数,住宿费用,电话,备注)

公寓(公寓号,管理员ID,楼层数,房间数,启用时间,备注)

操作员(操作员ID,姓名,密码,权限,备注)

4.2 对数据模型进行优化

4.3 设计用户子模式(将常用的查询定义为视图)

管理人员分:公寓管理人员和财务管理人员

公寓(公寓号,管理员ID,楼层数,房间数,启用时间,备注)寝室(寝室号,公寓号,可住人数,住宿费用,电话,备注)

财务管理员_寝室(寝室号,公寓号,管理员ID,住宿费用)

4.4 数据存储位置、索引方面的考虑

表4-2:管理员信息

表4-5:学生信息

表4-6:来访信息

表4-7:交费信息

5. 数据库实施

5.1 创建表、视图、索引等

--创建和插入表

if exists(select * from sysobjects where name='管理员信息' and xtype='U')drop table 管理员信

if exists(select * from sysobjects where name='公寓信息' and xtype='U')drop table 公寓信息if exists(select * from sysobjects where name='寝室信息' and xtype='U')drop table 寝室信息if exists(select * from sysobjects where name='学生信息' and xtype='U')drop table 学生信息if exists(select * from sysobjects where name='来访信息' and xtype='U')drop table 来访信息if exists(select * from sysobjects where name='交费信息' and xtype='U')drop table 交费信息

GO

CREATE TABLE 管理员信息(

操作员ID varchar(10) primary key,

操作员姓名varchar(10),

密码varchar(10),

权限varchar(10),

管理公寓号varchar(10),

备注varchar(50),

)

CREATE TABLE 公寓信息(

公寓号varchar(10) primary key,

楼层数int ,

房间数int ,

启用时间smalldatetime ,

备注varchar(50),

)

CREATE TABLE 寝室信息(

寝室号varchar(10),

可住人数int ,

住宿费用float(8),

电话varchar(10),

公寓号varchar(10),

备注varchar(50),

primary key(寝室号,公寓号)

)

CREATE TABLE 学生信息(

学号varchar(30) primary key,

姓名varchar(20),

性别varchar(2),

出生日期smalldatetime ,

专业varchar(20),

班级varchar(20),

联系方式varchar(20),

公寓号varchar(10),

寝室号varchar(10),

备注varchar(50)

)

CREATE TABLE 来访信息(

来访人姓名varchar(10) not null,

人数int not null,

被访者姓名varchar(10) not null,

来访时间smalldatetime ,

结束时间smalldatetime ,

事由varchar(50) not null,

公寓号varchar(10) not null,

值班人varchar(10) not null

)

CREATE TABLE 交费信息(

公寓号varchar(10),

寝室号varchar(10),

交费时间smalldatetime ,

交费类型varchar(10),

金额float(8),

备注varchar(50),

primary key(寝室号,公寓号)

)

5.2 数据录入

insert 管理员信息values('HJ000001','黎明','123','普通管理员','1','无') insert 管理员信息values('HJ000002','小明','123','普通管理员','2','无') insert 管理员信息values('HJ000003','张帅','123','普通管理员','3','无')

insert 公寓信息values('1','5','200','2001-5-7','无')

insert 公寓信息values('2','5','200','2001-5-7','无')

insert 公寓信息values('3','5','200','2001-5-7','无')

insert 寝室信息values('101','4','1200','501101','1','无')

insert 寝室信息values('109','4','1200','501109','2','无')

insert 寝室信息values('111','4','1200','501171','3','无')

insert 学生信息values('0804200130','张新','男','1990-12-09','计算机','1班','501675','1','101','无')

insert 学生信息values('0807200135','李强','男','1989-2-09','会计','2班','501692','2','109','无') insert 学生信息values('0806200130','张风','男','1990-12-09','信息','1班','501675','3','111','无')

insert 来访信息values('名人','1','李辉','12:00','13:00','来看看','1','陈小芸')

insert 来访信息values('钱飞','1','王辉','11:00','15:00','来看看','1','陈小芸')

insert 来访信息values('朱晓晨','1','张飞','9:00','13:00','来看看','1','陈小芸')

insert 交费信息values('1','101','2010-10-01','电费','300','无')

insert 交费信息values('2','109','2010-9-01','水费','300','无')

insert 交费信息values('3','111','2010-12-21','电费','300','无')

5.3编程实现日常业务流程(设计和实现常用查询)

创建存储过程

学生入住及学生离校

if exists(select * from sysobjects where name='学生入住' and xtype='P')drop Proc 学生入住

if exists(select * from sysobjects where name='学生离校' and xtype='P')drop Proc 学生离校

GO

Create Proc 学生入住(

@学号varchar(30),

@姓名varchar(20),

@性别varchar(2),

@出生日期smalldatetime,

@专业varchar(20),

@班级varchar(20),

@联系方式varchar(20),

@公寓号varchar(10),

@寝室号varchar(10),

@备注varchar(50)

) AS BEGIN

--检查参数值的合法性

If LTrim(RTrim(@学号))='' OR @学号IS NULL return 1

If @出生日期IS NULL OR @出生日期<=0 return 2

--插入学生信息

INSERT 学生信息VALUES (@学号, @姓名, @性别, @出生日期, @专业, @班级, @联系方式, @公寓号, @寝室号, @备注)

return 0

End

GO

Create Proc 学生离校(

@学号varchar(30)

) AS BEGIN

--检查参数值的合法性

If NOT Exists(select * from 学生信息where 学号=@学号)

return 1 --删除的学生信息不存在

--删除学生信息

delete from 学生信息where 学号=@学号

return 0

End

GO

创建公寓1的视图并查询

--创建视图

if exists(select * from sysobjects where name='公寓1入住学生视图' and xtype='V')drop View 公寓1入住学生视图

GO

Create View 公寓1入住学生视图AS

SELECT 学号,姓名,联系方式,寝室号,备注

FROM 学生信息x

WHERE x.公寓号='1'

GO

select * from 公寓1入住学生视图

GO

5.4对数据库系统进行测试(功能测试)

select * from 公寓1入住学生视图

学生入住

EXEC 学生入住'0800200635','李蒙','男','1989-2-09','计算机','2班','501692','1','109','无' select * from 学生信息

select * from公寓1入住学生视图

GO

6. 使用手册

基于若干实例从启动到结束进行详细介绍,适当进行截图和文字说明。

7. 结论

关于用户权限的数据库设计

1 设计思路 为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。 1.1 用户 用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。 用户通常具有以下属性: 编号,在系统中唯一。 ü名称,在系统中唯一。 ü用户口令。 ü注释,描述用户或角色的信息。 1.2 角色 角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性: ü编号,在系统中唯一。 ü名称,在系统中唯一。 ü注释,描述角色信息 1.3 权限 权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、 修改和删除功能,通常具有以下属性: ü编号,在系统中唯一。 ü名称,在系统中唯一。 ü注释,描述权限信息 1.4 用户与角色的关系 一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如 l 用户(User): UserID UserName UserPwd 1 张三 xxxxxx 2 李四 xxxxxx …… l 角色(Role): RoleID RoleName RoleNote 01 系统管理员监控系统维护管理员 02 监控人员在线监控人员 03 调度人员调度工作人员 04 一般工作人员工作人员…… 从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。 1.5 权限与角色的关系 一个角色(Role)可以拥有多个权限(Permission),同样一个权限可分配给多个角色。例如: l 角色(Role): RoleID RoleName RoleNote 01 系统管理员监控系统维护管理员 02 监控人员在线监控人员

数据库期末试题 附答案

《数据库原理》课程考试模拟题四 一、单项选择题(在每小题的四个备选答案中选出一个正确答案。本题共16分,每小题1分) 1. 在数据库中,下列说法()是不正确的。 A.数据库中没有数据冗余 B.数据库具有较高的数据独立性 C.数据库能为各种用户共享 D.数据库加强了数据保护 2. 按照传统的数据模型分类,数据库系统可以分为( )三种类型。 A.大型、中型和小型 B.西文、中文和兼容 C.层次、网状和关系 D.数据、图形和多媒体 3. 在数据库的三级模式结构中,( )是用户与数据库系统的接口,是用户用到的那部分数据的描述。 A.外模式 B.内模式 C.存储模式D.模式 4. 下面选项中不是关系的基本特征的是( )。 A. 不同的列应有不同的数据类型 B. 不同的列应有不同的列名 C. 没有行序和列序 D. 没有重复元组 5. SQL语言具有两种使用方式,分别称为交互式SQL和( )。 A.提示式SQL B.多用户SQL C.嵌入式SQL D.解释式SQL 6. 设关系模式R(ABCD),F是R上成立的FD集,F={A→B,B→C},则(BD)+为( )。 A.BCD B.BC C.ABC D.C 7. E-R图是数据库设计的工具之一,它适用于建立数据库的( )。 A.概念模型 B.逻辑模型 C.结构模型 D.物理模型 8. 若关系模式R(ABCD)已属于3NF,下列说法中( )是正确的。 A.它一定消除了插入和删除异常 B.仍存在一定的插入和删除异常C.一定属于BCNF D.A和C都是 9. 解决并发操作带来的数据不一致性普遍采用( )。 A.封锁技术 B.恢复技术 C.存取控制技术 D.协商 10. 数据库管理系统通常提供授权功能来控制不同用户访问数据的权限,这主要是为了实现数据库的( )。 A.可靠性 B.一致性 C.完整性 D.安全

关于用户权限的数据库设计

1设计思路 为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。 1.1用户 用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。 用户通常具有以下属性: 编号,在系统中唯一。 ü名称,在系统中唯一。 ü用户口令。 ü注释,描述用户或角色的信息。 1.2角色 角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性: ü编号,在系统中唯一。 ü名称,在系统中唯一。 ü注释,描述角色信息 1.3权限 权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、 修改和删除功能,通常具有以下属性: ü编号,在系统中唯一。 ü名称,在系统中唯一。 ü注释,描述权限信息 1.4用户与角色的关系 一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如l用户(User): UserID UserName UserPwd 1张三xxxxxx 2李四xxxxxx …… l角色(Role): RoleID RoleName RoleNote 01系统管理员监控系统维护管理员 02监控人员在线监控人员 03调度人员调度工作人员 04一般工作人员工作人员…… 从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。 1.5权限与角色的关系 一个角色(Role)可以拥有多个权限(Permission),同样一个权限可分配给多个角色。例如:l角色(Role): RoleID RoleName RoleNote 01系统管理员监控系统维护管理员 02监控人员在线监控人员

数据库期末试卷

浙江工业大学 《数据库原理及应用》 一、填空题 1、SELECT Name,Tele FROM Person 的作用是。 2、数据独立性是指数据与应用程序之间不存在相互依赖关系,分为 和。 3、用树型结构表示实体类型及实体间联系的数据模型称为层次模 型。 4、提供数据库定义、数据装入、数据操纵、数据控制和DB维护功能的软件称为 _ 数据管理系统 _。 5、在关系代数中专门的关系运算包括、、、除等。 6、关系数据库的第一范式保证列的原子 性。 7、一个数据库由若干个表组成,关系的元组称为,属性称为。 8 久性。 9、数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程5个部分。 10、并发操作带来的数据不一致性包括三类:丢失覆盖修改、 不可重复读、 读”脏数据。 11、管理信息系统的四种结构模式为:单机模式、、 和。 12、数据管理技术经历了:人工管理阶段、文件管理阶段以及数据库系统阶段 三个发展阶段。

14、实体之间的联系按照联系方式的不同可分为一对一或1:1 、 一对多或1:n 、___ 多对多或m:n 。 15、E-R图中包括__实体、____ 属性和联系三种基 本图素。 16、数据模型由三部分组成:模型结构、数据操作、数据约束条件 。 17、事务必须具有的四个性质是:原子性、一致性、隔离性和持久 性。 18、基本的封锁类型有排它锁和共享锁两种。 19、DB并发操作通常会带来三类问题,它们是丢失修改、不一致分析和读脏数据。 20、数据库系统可能发生的故障有:事务内部的故障系统故障、和介质故障等。计算机病毒 21、按转储时间来分,数据转储可分为静态转储和动态转储两种方式。 22、列举三种管理信息系统开发的方法:结构化开发方法、__原型方 法_ _____、 面向对象方法。 23、一个学生可以同时借阅多本图书,一本图书只能由一个学生借阅,学生和图书之间的联系为一对多联系。 二、判断题 1、关系中允许有重复的元组,但是不允许有重复的属性名。() 2、关系代数的运算对象是关系,但运算结果不是关系。() 3、连接操作可以多个表之间进行,也可以在一个表内进行。() 4、触发器是一种很有效的保证数据库完整性的手段。() 5、对于关系R、S,如果R-S的元组数是0,则说明R中包含了S的所有元组。 ()6、设关系R、S的元组数分别是20、30,则R和S连接的元组数不可能超过50。 () 7、数据库中的每一个基本表与外部存储器上一个物理文件对应。() 8、一个数据库可以有多个外模式和多个内模式。() 9、概念模型向关系模型转换时,实体间的n:m联系可以有两种转换方法,一

数据库设计词汇对照表

数据库设计词汇对照表 1. Access method(访问方法):此步骤包括从文件中存储和检索记录。 2. Alias(别名):某属性的另一个名字。在SQL中,可以用别名替换表名。 3. Alternate keys(备用键,ER/关系模型):在实体/表中没有被选为主健的候选键。 4. Anomalies(异常)参见更新异常(update anomalies) 5. Application design(应用程序设计):数据库应用程序生命周期的一个阶段,包括设计用户界面以及使用和处理数据库的应用程序。 6. Attribute(属性)(关系模型):属性是关系中命名的列。 7. Attribute(属性)(ER模型):实体或关系中的一个性质。 8. Attribute inheritance(属性继承):子类成员可以拥有其特有的属性,并且继承那些与超类有关的属性的过程。 9. Base table(基本表):一个命名的表,其记录物理的存储在数据库中。 10. Binary relationship(二元关系):一个ER术语,用于描述两个实体间的关系。例如,panch Has Staff。 11. Bottom-up approach(自底向上方法):用于数据库设计,一种设计方法学,他从标识每个设计组建开始,然后将这些组件聚合成一个大的单元。在数据库设计中,可以从表示属性开始底层设计,然后将这些属性组合在一起构成代表实体和关系的表。 12. Business rules(业务规则):由用户或数据库的管理者指定的附加规则。 13. Candidate key(候选键,ER关系模型):仅包含唯一标识实体所必须得最小数量的属性/列的超键。 14. Cardinality(基数):描述每个参与实体的可能的关系数目。 15. Centralized approach(集中化方法,用于数据库设计):将每个用户试图的需求合并成新数据库应用程序的一个需求集合 16. Chasm trap(深坑陷阱):假设实体间存在一根,但某些实体间不存在通路。 17. Client(客户端):向一个或多个服务器请求服务的软件应用程序。 18. Clustering field(群集字段):记录总的任何用于群集(集合)航记录的非键字段,这些行在这个字段上有相同的值。 19. Clustering index(群集索引):在文件的群集字段上定义的索引。一个文件最多有一个主索引或一个群集索引。 20. Column(列):参加属性(attribute)。 21. Complex relationship(复杂关系):度数大于2的关系。 22. Composite attribute(复合属性):由多个简单组件组成的属性。 23. Composite key(复合键):包含多个列的主健。

员工管理数据库设计

EMS数据库设计 启明培训小组:陈虹屹 冯磊 张源 二零一一年一十二月

目录 1.数据库设计原理 (2) 1.1属性 (2) 1.2实体间的关系 (3) 1.3 E-R图 (3) 2.数据字典 (4) 2.1 Employee表 (4) 2.2 Department表 (4) 2.3 Wage_Files表 (4) 3.建表 (5) 3.1建立Wage_files (5) 3.2 建立Department表: (6) 3.3建立Employee表: (7) 4.数据库应用:网站功能分析 (8) 4.1系统模块功能说明 (8) 4.1.1登录模块 (8) 4.1. 2功能模块 (8) 4.1.3添加模块 (9) 1.数据库设计原理 1.1属性 每一个公司都有存在部门、员工以及要给每个员工发工资他们都存在他们各自的属性 部门:部门编号、部门名、部门经理、电话以及部门人数。 员工:编号、姓名、所在部门、性别、出身日期、政治面貌、婚姻状况、家庭住址、电话号码、银行卡帐号。 薪资:员工编号、员工姓名、基本工资、岗位工资、补贴、绩效工资、病假工资、事假工资、加班、其他加项、应发合计、扣养老金、扣失业保险、扣公积金、扣个税、扣其他、实发合计。

1.2实体间的关系 每一个部门都有多个员工,每一个员工都有一份工资档案,而每一个部门都会管理很多的工资档案。 存在关系: 部门与员工:1:n 员工与工资;1:1 部门和工资档案:1:m 1.3 E-R图 所以E-R关系图为:

图1 2.数据字典 2.1 Employee表 2.2 Department表 2.3 Wage_Files表

数据库设计关于图书馆管理系统的设计(有完整代码)[1]

(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) 2.方案图表设计 (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背景 随着图书馆规模的不断扩大,图书数量也相应的增加,有关图书的各种信息量也成倍增加,

数据库期末试题附答案

《数据库原理》课程考试模拟题四 、单项选择题(在每小题的四个备选答案中选出一个正确答案。本题共 )是不正确的。 B .数据库具有较高的数据独立性 D ?数据库加强了数据保护 2.按照传统的数据模型分类,数据库系统可以分为 ()三种类型 .西文、中文和兼容 .数据、图形和多媒体 是用户 与数据库系统的接口,是用户用到的那部 C .存储模式 D .模 ) ° B. 不同的列应有不同的列名 没有重复元组 SQL 和 ( ) ° C .嵌入式SQL D .解释式SQL 6. 设关系模 式 R (ABCD ) F 是R 上成立的FD 集,F={A ^B, B -C},则(BD )+为( ) 7. E-R 图是数据库设计的工具之一,它适用于建立数据库的 ( ) ° A .概念模型 B .逻辑模型 C .结构模型 D .物理模型 8. 若关系模式R (ABCD 已属于3NF,下列 说法中( ) 是正确的。 10. 数据库管理系统通常提供授权功能来控制不同用户访问数据的权限,这主要是为了实 现数据库的( ) ° 11. 一个事务一旦完成全部操作后,它对数据库的所有更新应永久地反映在数据库中,不 会丢失。这是指事务的( ) ° A.原子性 B. 一致性 C. 隔离性 D. 持久性 12. 在数据库中,软件错误属于() ° A.事务故障 B. 系统故障 C. 介质故障 D. 活锁 1.在数据库中,下列说法( A .数据库中没有数据冗余 C .数据库能为各种用户共享 A .大型、中型和小型 B C.层次、网状和关系 D 3. 在数据库的三级模式结构中,() 分数据的描述。 A .外模式 B .内模式 式 4. 下面选项中不是关系的基本特征的是 ( A.不同的列应有不同的数据类型 C.没有行序和列序 D. 5. SQL 语言具有两种使用方式,分别称为交互式 A.提示式SQL B .多用户SQL A . BCD B . BC C . ABC 16分,每小题1分) A .它一定消除了插入和删除异常 B C. 一定属于BCNF D 9. 解决并发操作带来的数据不一致性普遍采用 A .封锁技术 B .恢复技术 .仍存在一定的插入和删除异常 .A 和 C 都是 () ° C .存取控制技术 D .协商 A .可靠性 B . 一致性 C .完整性 D .安全性

职工考勤管理系统数据库设计

《数据库原理及应用》项目实训任务书 一、题目:职工考勤管理信息系统 二、目的与要求 1. 目的: 1)锻炼学生的分析解决实际问题的能力; 2)培养学生的数据库基础系统的分析、设计和开发能力 2. 基本要求 1)《数据库原理及应用》课程设计采用以“项目小组”为单位进行,项目小组根据选定的项目,按计划进度完成项目的分析与设计及实现任务。 2)每个班级分成两个大组,每组选出组长一名,负责考勤、作业的收集上交。 3)题目自定或采用附录中的参考题目,每人选择一个题目 4)数据库工具:Access 或者 SQLServer 5)程序开发工具可以根据所学自行选择,或者采用ACCESS实现开发 3. 创新要求 在基本要求达到后,可进行创新设计,如系统用户功能控制,对管理员级和一般级别的用户系统功能操作不同 三、信息描述 系统基本信息描述,如:职工、考勤等。 四、功能描述 系统功能基本要求 职工信息,包括职工编号、职工姓名、性别、年龄、职称等; 出勤记录信息,包括上班打卡时间,下班打卡时间,缺勤记录等; 出差信息,包括出差起始时间、结束时间、统计总共天数等; 请假信息,包括请假开始时间,结束时间,统计请假天数等; 加班信息,包括加班开始时间、结束时间、统计加班总时间。 五、解决方案 1.分析程序的功能要求,划分程序功能模块。 2.画出系统流程图。 3.重点是设计数据库(严格按照数据库设计步骤),完成系统功能。 4.完成项目实训报告书。 六、进度安排

七、撰写项目实训报告及总结 项目实训报告要求: 包括需求分析、概念结构设计、逻辑结构设计、编码(详细写出编程步骤)、测试的步骤和内容、项目总结、参考资料等,不符合以上要求者,则本次设计以不及格记。 八、参考资料 《数据库原理及应用》 《ACCESS数据库与程序设计》 《ACCESS项目案例导航》 数据库教研室 2014.05.20 图1 系统结构图 1.2.1 模块管理 (1)用户管理模块 增加一名系统使用用户,同时设置密码和权限,当此用户要更改密码时,可以在修改密码模块中进行。必须具有一定权限才能进行此项操作。而当某些职工离职或者因某中缘故,不能再使用考勤系统,可以将该用户删除。可以更改拥护权限,使其具有访问某些模块的权限或者剥夺其访问某些模块的权限。所有系统使用用户都可能在此修改密码,以保障系统安全。 (2)基本资料管理模块 设置的时间有上午上、下班时间,下午上、下班时间,这个模块与上下班时间表相对应,以方便考勤操作。增加和删除请假类型,修改请假类型内容,并将操作结果存在请假类型表内。增加和删除外出类型,修改外出类型内容,并将操作结果存在外出类型表内。增加、删除和修改员工基本资料。

关系数据库设计

目录 一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. 数据完整性的独立性专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义,而且可以存储在数据目录中,而非程序中。

数据库期末作品设计报告

数据库期末作品设 计报告 1 2020年4月19日

《数据库应用基础》 作品设计报告 设计作品题目:图书管理系统的设计与实现学院名称:电子与信息工程学院 专业:电气工程及其自动化 班级:电气101 姓名:李盛标学号 指导教师:邱雪娜 完成日期:年 11 月 15 日

引言 数据库技术,已经成为先进信息技术的重要组成部分,是现代计算机信息系统和计算机应用系统的基础和核心。数据库从诞生到现在,在不到半个世纪的世纪的时间里,形成了坚实的理论基础、成熟的商业产品和广泛的应用领域,吸引了越来越多的研究者加入。 数据库的诞生和发展给计算机信息管理带来了一场巨大的革命。 计算机技术不断地应用到各行各业,大量的企业把数据存放在数据库中,而且经过T相关的代码语句来进行快速查询,获取比传统方式更高的效率。 为了进一步加深和巩固我们所学的专业课程《PowerBuilder数据库开发技术》的基本理论知识,使我们所学的理论能够更好的和实际的专业联系起来,进一步培养学生的综合分析问题和解决问题的能力。使学生的得到收集、处理、应用资料信息的实践训练,同时全面的考核学生所掌握的基本理论知识及其实际的专业能力,从而达到提高学生素质的最终目的。学校安排了为期一个星期的实训课程,在这一个星期的时间里,希望学生能够利用所学到的知识创立一个图书馆的数据系统,来达到图书管理的需要。 3 2020年4月19日

5月28日 目录 1 数据库设计 (3) 1.1 需求分析 (3) 1.2 数据库设计内容 (3) 1.3 概念设计 (4) 1.4 逻辑设计 (5) 1.5 窗口界面设计以及控件添加 (6) 1.6 表的设计以及数据的添加 (9) 2 数据库编程 (10) 2.1 数据库链接变成 (10) 2.2 操作界面代码 (10) 2.3 数据显示窗口编程 (12) 2.4 窗口按钮编程 (16) 2.5 图书类型窗口编程 (18) 4 2020年4月19日

数据库表结构设计参考

数据库表结构设计参考

表名外部单位表(DeptOut) 列名数据类型(精度范围)空/非空约束条件 外部单位ID 变长字符串(50) N 主键 类型变长字符串(50) N 单位名称变长字符串(255) N 单位简称变长字符串(50) 单位全称变长字符串(255) 交换类型变长字符串(50) N 交换、市机、直送、邮局单位邮编变长字符串(6) 单位标识(英文) 变长字符串(50) 排序号整型(4) 交换号变长字符串(50) 单位领导变长字符串(50) 单位电话变长字符串(50) 所属城市变长字符串(50) 单位地址变长字符串(255) 备注变长字符串(255) 补充说明该表记录数约3000条左右,一般不做修改。初始化记录。 表名外部单位子表(DeptOutSub) 列名数据类型(精度范围)空/非空约束条件 外部子单位ID 变长字符串(50) N 父ID 变长字符串(50) N 外键 单位名称变长字符串(255) N 单位编码变长字符串(50) 补充说明该表记录数一般很少 表名内部单位表(DeptIn) 列名数据类型(精度范围)空/非空约束条件 内部单位ID 变长字符串(50) N 主键 类型变长字符串(50) N 单位名称变长字符串(255) N 单位简称变长字符串(50) 单位全称变长字符串(255) 工作职责 排序号整型(4) 单位领导变长字符串(50) 单位电话(分机)变长字符串(50) 备注变长字符串(255)

补充说明该表记录数较小(100条以内),一般不做修改。维护一次后很少修改 表名内部单位子表(DeptInSub) 列名数据类型(精度范围)空/非空约束条件内部子单位ID 变长字符串(50) N 父ID 变长字符串(50) N 外键 单位名称变长字符串(255) N 单位编码变长字符串(50) 单位类型变长字符串(50) 领导、部门 排序号Int 补充说明该表记录数一般很少 表名省、直辖市表(Province) 列名数据类型(精度范围)空/非空约束条件ID 变长字符串(50) N 名称变长字符串(50) N 外键 投递号变长字符串(255) N 补充说明该表记录数固定 表名急件电话语音记录表(TelCall) 列名数据类型(精度范围)空/非空约束条件ID 变长字符串(50) N 发送部门变长字符串(50) N 接收部门变长字符串(50) N 拨打电话号码变长字符串(50) 拨打内容变长字符串(50) 呼叫次数Int 呼叫时间Datetime 补充说明该表对应功能不完善,最后考虑此表 表名摄像头图像记录表(ScreenShot) 列名数据类型(精度范围)空/非空约束条件ID 变长字符串(50) N 拍照时间Datetime N 取件人所属部门变长字符串(50) N 取件人用户名变长字符串(50) 取件人卡号变长字符串(50) 图片文件BLOB/Image

工资管理系统数据库设计

4、4数据库设计 4、1数据库分析 通过系统管理,能够增强员工之间得沟通,更好地协调员工之间得协作关系;对员工基础信息管理与薪资管理更加科学;能够全程跟踪员工得培训,通过信息得记录,更好地作出员工培训方案.在设计工资管理信息系统时,主要从模块组成、数据连接、功能实现、应用意义等方面着手。模块组成主要包括该工资管理信息系统得主要组成模块以及每个模块所要达到得功能。每个模块基本上脱离不了数据,所以在数据库设计时,要充分考虑数据得高效性,减少数据冗余,保证系统运行速度。 4、2数据库概念设计 根据以上各节对系统所做得需求分析与系统设计,规划出本系统中使用得数据库实体分别为管理员实体、招聘人员实体、员工信息管理实体、薪资管理实体、培训信息实体及部门信息实体。系统总体ER图如图所示: 下面将介绍几个关键实体得E-R图. 1、管理员实体 管理员实体包括管理员帐号、管理员密码及管理员级别属性.其中管理员级别信息中,1代表系统管理员,0代表普通管理员。

图 5-1 管理员实体 2、员工信息管理实体 员工信息管理实体包括员工编号、员工姓名、员工年龄、员工性别、出生日期、员工身份证号、民族、婚姻状况、政治面貌、籍贯、联系电话、家庭住址、员工毕业学校、员工所学专业、文化程度、上岗时间、部门名称、部门工种、登记人、登记时间及备注信息属性。 3、薪资管理实体 薪资管理实体包括员工编号、工资发放时间、基本工资、加班次数、工龄、全勤奖、旷工费及保险费等属性。 4、3数据库逻辑结构 数据得概念结构设计完之后,可以将上面得数据库概念结构转化为某种数据库系统所支持得实际数据模型,也就就是数据库得逻辑结构.系统数据库中各表得详细SQL语句。 CREATE TABLE`dep` ( //部门表 `id` int(10) unsigned NOTNULL auto_increment MENT ’自动编号’, `dep_id` varchar(16) defaultNULL MENT '部门编号', `dep_name` varchar(16)defaultNULL MENT '部门名称',`dep_info` varchar(512) default NULL MENT ’部门简介’,

数据库课后题答案 第7章 数据库设计

第7章数据库设计 1.试述数据库设计过程。 答:这里只概要列出数据库设计过程的六个阶段:( l )需求分析;( 2 )概念结构设计;( 3 )逻辑结构设计;( 4 )数据库物理设计;( 5 )数据库实施;( 6 )数据库运行和维护。这是一个完整的实际数据库及其应用系统的设计过程。不仅包括设计数据库本身,还包括数据库的实施、运行和维护。设计一个完善的数据库应用系统往往是上述六个阶段的不断反复。 2 .试述数据库设计过程各个阶段上的设计描述。 答:各阶段的设计要点如下:( l )需求分析:准确了解与分析用户需求(包括数据与处理)。( 2 )概念结构设计:通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS 的概念模型。( 3 )逻辑结构设计:将概念结构转换为某个DBMS 所支持的数据模型,并对其进行优化。( 4 )数据库物理设计:为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。( 5 )数据库实施:设计人员运用DBMS 提供的数据语言、工具及宿主语言,根据逻辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。( 6 )数据库运行和维护:在数据库系统运行过程中对其进行评价、调整与修改。 3 .试述数据库设计过程中结构设计部分形成的数据库模式。 答:数据库结构设计的不同阶段形成数据库的各级模式,即:( l )在概念设计阶段形成独立于机器特点,独立于各个DBMS 产品的概念模式,在本篇中就是 E 一R 图;( 2 )在逻辑设计阶段将 E 一R 图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式,然后在基本表的基础上再建立必要的视图( Vi 娜),形成数据的外模式;( 3 )在物理设计阶段,根据DBMS 特点和处理的需要,进行物理存储安排,建立索引,形成数据库内模式。 4 .试述数据库设计的特点。 答:数据库设计既是一项涉及多学科的综合性技术又是一项庞大的工程项目。其主要特点有:( l )数据库建设是硬件、软件和干件(技术与管理的界面)的结合。( 2 )从软件设计的技术角度看,数据库设计应该和应用系统设计相结合,也就是说,整个设计过程中要把结构(数据)设计和行为(处理)设计密切结合起来。 5 .需求分析阶段的设计目标是什么?调查的内容是什么? 答:需求分析阶段的设计目标是通过详细调查现实世界要处理的对象(组织、部门、企业等),充分了解原系统(手工系统或计算机系统)工作概况,明确用户的各种需求,然后在此基础上确定新系统的功能。调查的内容是“数据’夕和“处理”,即获得用户对数据库的如下要求:( l )信息要求,指用户需要从数据库中获得信息的内容与性质,由信息要求可以导出数据要求,即在数据库中需要存储哪些数据;( 2 )处理要求,指用户要完成什么处理功能,对处理的响应时间有什么要求,处理方式是批处理还是联机处理;( 3 )安全性与完整性要求。 6 .数据字典的内容和作用是什么? 答:数据字典是系统中各类数据描述的集合。数据字典的内容通常包括:( l )数据项;( 2 )数据结构;( 3 )数据流;( 4 )数据存储;( 5 )处理过程五个部分。其中数据项是数

数据库期末试卷和答案

数据库程序设计试题 1一、判断题(每题1分,共10分) 1、DB、DBMS、DBS三者之间的关系是DBS包括DB和DBMS。( ) 2、数据库的概念结构与支持其的DB的DBMS有关。( ) 3、下列式子R∩S=R—(R—S)成立。( ) 4、数据存储结构改变时逻辑结构不变,相应的程序也不变,这是数据库系统的逻辑独立 性。() 5、关系数据库基本结构是三维表。( ) 6、在嵌入式SQL语句中,主语句向SQL语句提供参数,主要用游标来实现。( ) 7、规范化的投影分解是唯一的。( ) 8、不包含在任何一个候选码中的属性叫做非主属性。( ) 9、在 Transact-SQL 语句的WHERE子句中,完全可以用IN子查询来代替OR逻辑表达式。 ( ) 10、封锁粒度越大,可以同时进行的并发操作越大,系统的并发程度越高。() 二、填空题(每空0.5分,共10分) 1、两个实体间的联系有联系,联系和联系。 2、select命令中,表达条件表达式用where子句,分组用子句,排序用 子句。 3、数据库运行过程中可能发生的故障有、和三类。 4、在“学生-选课-课程”数据库中的三个关系如下: S(S#,SNAME,SEX,AGE),SC(S#,C#,GRADE),C(C#,CNAME,TEACHER)。 现要查找选修“数据库技术”这门课程的学生姓名和成绩,可使用如下的SQL语句:SELECT SNAME,GRADE FROM S,SC,C WHERE CNAME= 数据库技术AND S.S#=SC.S# AND。 5、管理、开发和使用数据库系统的用户主要有、、 。 6、关系模型中可以有三类完整性约束:、 和。 7、并发操作带来数据不一致性包括三类:丢失修改、和。 8、事务应该具有四个属性:原子性、、隔离性和持续性。 9、数据库运行过程中可能发生的故障有事务故障、和三类。 10、在“学生-选课-课程”数据库中的三个关系如下:S(S#,SNAME,SEX,AGE),SC(S#,C#,GRADE),C(C#,CNAME,TEACHER)。 现要查找选修“数据库技术”这门课程的学生姓名和成绩,可使用如下的SQL语句:SELECT SNAME,GRADE FROM S,SC,C WHERE CNAME= ‘数据库技术’AND S.S#=SC.S# AND。 11、数据库设计包括、、逻辑结构设计、物理结构设计、数据库实施、数据库运行和维护。 12、MS SQL Server提供多个图形化工具,其中用来启动、停止和暂停SQL Server的图形 化工具称为_________。 13 、SELECT语句中进行查询 , 若希望查询的结果不出现重复元组 , 应在SELECT子 句中使用____________保留字。 14、如果一个关系不满足2NF,则该关系一定也不满足__________(在1NF、2NF、3NF 范围内)。 15、数据库的物理设计主要考虑三方面的问题:______、分配存储空间、实现存取路径。 三、单选题(每题1分,共20 分) 1、在SQL中,关系模式称为() A、视图 B、对象 C、关系表 D、存储文件 2、要保证数据库逻辑数据独立性,需要修改的是( )

数据库设计的基本步骤

数据库设计的基本步骤 一、数据库设计的生存期 按照规范设计的方法,考虑到数据库及其应用系统开发的全过程,将数据库设计分为六个阶段。如下图。 ①需求分析 需求收集和分析,得到用数据字典描述的数据需求,用数据流图描述的处理需求。 ②概念结构设计 对需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型(用E-R图表示)。 ③逻辑结构设计 将概念结构转换为某个DBMS所支持的数据模型(例如关系模型),并对其 进行优化。 ④物理结构设计 为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。 ⑤数据库实施

运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C),根据逻 辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。 ⑥数据库运行和维护 数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。 说明:设计一个完善的数据库应用系统是不可能一蹴而就的,它往往是上述六个阶段的不断反复。 二、数据库设计阶段的内容 设计步骤既是数据库设计的过程,也包括了数据库应用系统的设计过程。下面针对各阶段的设计内容给出各阶段的设计描述。如下图。 三、数据库设计阶段的模式 数据库结构设计的不同阶段形成数据库的各级模式,如下图。 需求分析阶段:综合各个用户的应用需求;

概念设计阶段:形成独立于机器特点,独立于各个DBMS产品的概念模式,即E-R图; 逻辑设计阶段:将E-R图转换成具体的数据库产品支持的数据模型,如关 系模型,形成数据库逻辑模式;然后根据用户处理的要求、安全性的考虑,在基本表的基础上再建立必要的视图,形成数据的外模式; 物理设计阶段:根据DBMS特点和处理的需要,进行物理存储安排,建立索引,形成数据库内模式。

数据库期末作业

一、概述 1、数据库设计的目的和意义 本系统是针对高等院校的学生信息管理,因此信息管理系统的用户包括系统管理员、教师和学生。主要涉及院系信息、学生信息、课程信息、选课记录、成绩信息、宿舍信息等多种数据信息。 系统应具体实现的功能 用户信息实现——学生或老师输入自己的账号和密码进入该系统。 基本信息实现——系统管理员负责对各种基本信息的录入、修改、删除等操作。 信息查询实现——学生可以查询基本信息:所在院系、所在宿舍、各科的考试成绩 等,系统管理员负责把老师提交的学生成绩进行管理,计算总成绩和平均成绩,统计不及格学生信息和获得奖学金学生的信息,最后再输出所有的信息。 2、适用的软件和工具 SQL server 2008、Power Designer、E-R图 二、数据库部分 1、E-R图 (1)、数据流程图 (

(2)、功能模块图 (3)、E-R图 分E-R图

3、表结构 数据项描述

课程表结构: 选课表结构: 学院表结构: 宿舍表结构: 4、索引设计 (1)、单表索引设计 为学生表创建一个以student_id为索引的关键字的唯一聚簇索引 1)展开数据库中的表右键学生表,单击所有任务弹出的索引管理。 2)在窗体点新建索引名称为student_id_index,点击复选框“聚簇索引”、“惟一值” 同理为课程表创建一个以course_cno 为索引的关键字的唯一聚簇索引; 同理为选课表创建以student_id、course_cno为索引的关键字的聚簇索引; 同理为学院表创建一个以department_ deno 为索引的关键字的唯一聚簇索引; 同理为宿舍表创建一个以dormitry_dono为索引的关键字的唯一聚簇索引;

人事工资管理系统数据库设计

人事工资管理系统 1问题描述 设计目的 本系统的设计目标是能够对该公司的员工的基本信息和工资信息进行添加和修改,根据个人信息将工资分为职务工资,职称工资和其他工资。能够调整工资标准和员工信息,也能够调整其他工资项目,根据需要对教职员工基本信息和工资信息的查询,系统应该包括系统用户数据的添加,修改和删除。系统应该具有简单,易用,小巧,经典的特色,应该能够对高校工资管理进行优化,使其系统化,高效化,智能化。并保证工资管理的准确性,简易性,为公司财务人员提供便利。 设计背景 随着市场经济的快速发展,公司规模越来越大,员工的数量也越来越多,员工工资管理更加的复杂,而工资管理是一项琐碎、复杂而又十分细致的工作,工资计算、发放、核算的工作量很大,一般不允许出错,如果实行手工操作,每月发放工资须手工填制大量的表格,这就会耗费工作人员大量的时间和精力,计算机进行工资发放工作,不仅能够保证工资核算准确无误、快速输出,而且还可以利用计算机对有关工资的各种信息进行统计,服务于财务部门其他方面的核算和财务处理,同时计算机具有着手工管理所无法比拟的优点.例如:检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高人事工资资管理的效率,也是企业的科学化、正规化管理,与世界接轨的重要条件。这就对人事工资管理提出了新的要求,用计算机管理系统来管理高校工资已经成为目前的趋势,使用计算机可以高速,快捷地完成以上工作。在计算机联网后,数据在网上传递,可以实现数据共享,避免重复劳动,规范数据管理行为,从而提高了管理效率和水平。人事工资管理系统便是以计算机为工具,通过对工资管理所需的信息管理,不仅把管理人员从繁琐的数据计算处理中解脱出来,而且优化了管理体系,使其高效化,简易化,智能化,也提高了透明度和互动性。

关系数据库设计

目录 一 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.数据完整性的独立性?专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义,而且可以存储在数据目录中,而非程序中。

相关文档
最新文档