数据库原理及应用.docx
《数据库原理及应用.docx》由会员分享，可在线阅读，更多相关《数据库原理及应用.docx（28页珍藏版）》请在冰点文库上搜索。
数据库原理及应用
《数据库原理及应用》
总结报告
姓名：
张雪
学号：
2
班级：
文自1022
分数：
__________________
一、数据库的作用、意义及发展趋势：
作用：
数据库是长期储存在计算机内，有组织的、可共享的大量数据集合。
对于企业来说，数据库能够完全整合现有的业务系统，保护已有的投资，并能在应用程序的配合下充分的分析数据，为决策提供支持。
所有数据库最主要的作用就是对众多的业务提供数据支撑。
此外数据库的作用还有：
1、完善地管理各种数据库对象，具有强大的数据组织、用户管理、安全检查等功能：
2、可以方便地生成各种数据对象，利用存储的数据建立窗体和报表，可视性好；3、作为Office套件的一部分，可以与Office集成，实现无缝连接；4、能够利用Web检索和发布数据，实现与Internet的连接。
其中Access主要适用于中小型应用系统，或作为客户机/服务器系统中的客户端数据库。
意义：
数据库管理系统是一个复杂、较大的程式，它好比是一个图书管理系统，不仅可以储存和取得数据，并且可以定义数据格式。
数据库则是一群经过整合的数据，以一种共同的格式储存，以达到数
据共享、减少数据重复的目的。
数据库包含了多个表以及表中各种属性的特性，是一种工作环境能减少数据的冗余并提高数据的完整性。
发展趋势：
数据库信息量的使用频度已经成为衡量一个国家信息化程度的重要标志。
在我国70年代——数据库技术引入我国，80年代——数据库技术广泛普及，90年代——我国数据库建设飞速发展。
当前数据库发展还有两股重大的势头：
1、数据库用户急剧增多；2、数据库无论是逻辑级、物理级还是整个结构级，其技术发展都很快。
市场对数据库的需要量猛增，促进了数据库科研工作的发展，并不断研究出来越来越好的数据库技术。
主要发展趋势为：
1、信息特性和来源的变化；2、应用领域的变化；3、相关技术的发展；4、当前若干研究热点，包括文本、数据、代码、数据流的集成。
二、例举现实生活中的几个数据库应用实例：
1、客户订购登记管理
现有一个公司希望为其客户订购行为建立一个数据库。
如果一个客户可以有一份或多份订单，每份订单可以订购一种或多种商品。
每份订单有一张发票，发票可以通过多种方式来支付购买款，如支票、信用卡或者现金。
处理这个客户订购等级的职工的名字要被记录下来。
部门工作人员负责整理订单并根据库存情况处理订单。
如果库存中有订单上的产品，就可以直接发货，发货方式也有多种；如果库存中没有订单上的产品，就不需要登记或者订购其他产品。
需求分析
根据数据库设计步骤，在进行数据库设计之前应该先进行用户需求分析，主要是搞清楚用户的数据需求和处理需求。
如图9.1所示是客户订购登记数据流图。
产品发货台账发票
客户信息订单
图9.1客户订购登记数据流图
经过分析，了解到公司主要是对客户的订购行为进行管理，客户订购登记过程涉及到的数据有以下几种（数据需求）：
●订单数据
●客户数据
●职工数据
●发票数据
●发货数据
●产品数据
本例的处理需求有以下几种：
●查询每种产品的订购情况
●查询订单上产品的发货情况
●查询开出去的发票情况
●查询每份订单的执行情况
概念设计
1．局部视图设计
（1）确定局部视图的设计范
（2）确定实体及实体的主键（主标识符）。
产品：
存放所有可以订购的产品信息。
主键为“产品编号”。
订单：
存放所有与客户签订的订单，主键为“订单编号”。
发票：
存放所有开出的发票，主键为“发票编号”。
职工：
存放职工基本信息，主键为“职工编号”。
发货：
存放订购产品的发货情况，主键为“发货编号”。
客户：
存放客户基本信息，主键为“客户编号”。
发票：
实体中的付款方式是多值的，主键是“付款方式编号”。
发货：
实体中发货方式也是多值的，主键是“发货方式编号”。
订单：
主键为“订单编号”。
（3）定义实体间的联系，所涉及到的联系一般有以下几种。
①“客户”和“订单”通过提交发生联系。
图9.2
②“产品”实体和“订单细节”实体通过订购产品发生联系。
图9.3
③“订单细节”是“订单”实体的组成部分，故必存在联系。
一份订单可以订购多种产品，也就是可以有多个订单细节，而每个订单细节只对应一份订单。
因此，二者是“一对多”联系。
图9.4
④“职工”实体通过处理订单和“订单”实体发生联系。
每个职工可以处理多份订单，而每份订单只能由一个职工处理。
因此，二者存在“一对多联系。
图9.5
⑤付款方式是发票的组成部分，故必存在联系。
每张发票对应一种付款方式，而每种付款方式可以用于不同的发票中。
因此，“付款方式”实体和“发票”实体之间是一对多联系。
图9.6
⑥“发货”实体与“订单细节”实体通过发货打包发生联系。
每个订单细节可能对应多次发货，而每次发货只对应一个订单细节。
因此，“发货”实体和“订单细节”实体之间是一对多联系。
图9.7
⑦发货方式是发货的组成部分，故必存在联系。
图9.8
⑧“订单”实体和“发票”实体通过开发票发生联系。
，每份订单开一张发票，而每张发票只对应一份订单。
因此，“订单”实体和“发票”实体之间是一对一联系。
图9.9
（4）给实体及联系加上描述属性，实体和联系的属性应该根据具体应用进行识别。
同一个实体，在不同的应用场合可能拥有属性不同。
凡是应用中需要用到的属性都必须考虑，而应用中不会用到的属性则不必考虑。
●“客户”实体：
客户编号、客户名称、邮编、电话号、传真号、银行账号、Email
●“产品”实体：
产品编号、产品名、型号、规格、单价、重量、现有库存量
●“订单”实体：
订单编号、客户编号、订货日期、交货日期、发货方式编号、职工编号、执行状态
●“订单细节”实体：
订单编号、产品编号、单价、订货数量
●“发票”实体：
发票编号、开票日期、付款日期、订单编号、客户编号、金额、付款方式编号
●“发货”实体：
发货编号、数量、发货日期、订单编号、产品编号、发货方式编号、完成状态、职工编号
●“职工”实体：
职工编号、姓名、性别、出生年月、地址、办公电话、住宅电话、E-mail、职务、职称
●“付款方式”实体：
付款方式编号、付款方式
●“发货方式”实体：
发货方式编号、发货方式
2．视图集成
集成策略为：
采用两两集成策略，即每次只集成两个局部视图。
（1）局部视图9.3和图9.4中的“订单细节”实体是同一个实体。
在集成时只需保留一个。
另外，“产品”实体和“订单”实体是完全不同的两个实体，不存在域的相关性，集成视图中全部保留，集成后如图9.10所示。
图9.10局部视图9.3和图9.4的集成
（2）局部视图9.7和图9.10中的“订单细节”实体是同一个实体，集成后如图9.11所示。
（3）局部视图9.8和图9.11中的“发货”实体是同一个实体，集成后如图9.12所示。
（4）局部视图9.2和图局部视图9.12中的“订单”实体为同一个实体，集成后如图9.13所示。
（5）局部视图9.5与图9.13中的“订单”实体为同一个实体，集成后如图9.14所示。
（6）局部视图9.9与图9.14中“订单”实体为同一个实体，集成后如图9.15所示。
（7）局部视图9.6与图9.15中“发票”实体为同一实体，集成后如图9.16所示
产品编号
产品
订单
明细
订购
订单编号
（1：
N）
（1:
1）
产品编号
订单
订单编号
有
（1：
N）
（1:
1）
发货
打包
（1:
1）
（1：
N）
图9.16局部视图9.6和图9.15的集成
发货
发货方式
（1:
1）
（1:
N））
发货方式编号
客户
客户编号
提交
（1:
1）
（1：
N）
职工
处理
（1:
1）
（0:
N）
产品编号
发票
开出
（1:
1）
（1:
1）
发票编号
付款方式
付款
（1：
N）
（1:
1）
9.1.3逻辑设计
逻辑设计是将概念设计得到的E-R模型映射为DBMS的逻辑模型。
对于关系型数据库设计来说，符合E-R图的数据可以用表的集合来表示。
根据前面概念设计得到的集成视图9.16，并利用实体到关系模式以及联系到关系模式的映射规则，可以得到以下一组关系模式集，然后利用关系规范化理论判断关系属于第几范式，如果需要，则可再对关系模式进行优化处理。
1.客户（客户编号，客户名称，邮编，电话号，传真号，银行账号，E-mail）
主键：
客户编号
候选键：
电话号、传真号、银行账号、E-mail
函数依赖集F：
客户编号→{客户名称，邮编，电话号，传真号，银行账号，E-mail}，
电话号→{客户编号，客户名称，邮编，传真号，银行账号，E-mail}，
传真号→{客户编号，客户名称，邮编，电话号，银行账号，E-mail}，
银行账号→{客户编号，客户名称，邮编，电话号，传真号，E-mail}，
E-mail→{客户编号，客户名称，邮编，电话号，传真号，银行账号}。
虽然客户编号→电话号，电话号→传真号，但由于电话号→客户编号也成立，所以客户编号→传真号不是传递依赖。
客户关系中不存在非主属性与候选键之间的传递依赖关系，所以“客户”关系满足第三范式。
2．产品（产品编号，产品名，型号，规格，单价，重量，现有库存量）
主键：
产品编号
函数依赖集F：
产品编号→{产品名，型号，规格，单价，重量，现有库存量}。
显然，“产品”关系满足第三范式。
3.订单（订单编号，客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态）
主键：
订单编号
外键：
客户编号，引用了“客户关系”中的客户编号；
发货方式编号，引用了“发货方式”关系中的发货方式编号；
职工编号，引用了“职工”关系中的职工编号。
函数依赖集F：
订单编号→{客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态}
“订单”关系满足第三范式。
注意：
订单中的“执行状态”用来表示订单是否已执行完毕，即产品全部发出且钱也已全部到款。
4．订单细节（订单编号，产品编号，单价，订货数量）
主键：
订单编号+产品编号
函数依赖集F：
{订单编号+产品编号}→{单价，订货数量}
“订单细节”关系满足第三范式。
5．发票（发票编号，开票日期，付款日期，订单编号，客户编号，金额，付款方式编号）
主键：
发票编号
候选键：
订单编号
外键：
订单编号、客户编号、付款方式编号
函数依赖集F：
（略）
“发票”关系满足第三范式。
注：
由于发票与订单之间是1:
1联系，且都是强制参与，所以发票文件也可以与订单文件合并。
即，
订单（订单编号，客户编号，订货日期，交货日期，发货方式编号，职工编号，执行状态，发票编号，开票日期，付款日期，金额，付款方式编号）
主键：
订单编号
候选键：
发票编号
6．发货（发货编号，数量，发货日期，订单编号，产品编号，发货方式编号，完成状态，职工编号）
主键：
发货编号
外键：
订单编号、产品编号、发货方式编号
函数依赖集（略）
“发货”关系满足第三范式。
7．职工（职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，E-mail，职务，职称）
主键：
职工编号
候选键：
E-mail
函数依赖集F（略）
“职工”满足第三范式。
8．付款方式（付款方式编号，付款方式）
主键：
付款方式编号
函数依赖集F（略）
满足第三范式
9.发货方式（发货方式编号，发货方式）
主键：
发货方式编号
函数依赖集F（略）
满足第三范式
至此，所有关系都满足较高的范式要求，故客户订购登记管理的数据库设计是合理的。
下面验证数据库的设计是否满足处理需求：
（1）要查询每种产品的订购情况，只需对“订单明细”关系进行统计；
（2）要查询每份订单订购产品的发货情况，只需查询“发货”关系；
（3）要查询已开出去的发票情况，只需查询“发票”关系；
（4）要查询每份订单的执行情况，只需查询“订单”关系。
其他查询，若查询某份订单是哪个客户签订的，则只需对“订单”和“客户”关系作连接操作即可；若要查询某份订单上具体订购了哪些具体的产品，则只需对“订单细节”关系和“产品”关系进行连接操作查询即可；因此，上述数据库的设计是能够满足用户的数据需求和处理需求的。
2/工资管理部门希望建立一个数据库来管理职工的工资。
要计算职工的工资，就需要考虑不在休假日期以内的假期、工作期间的病假时间、奖金和扣除的部分。
系统必须指明给每个职工发薪水的方式，随着时间的推移，发薪水的方式可能会发生改变。
大多数的职工是通过银行卡来结算工资的，但是也有一部分人使用现金或支票。
如果是通过银行卡，就需要知道账号和银行地址。
付款方式只可能是一种方式。
另外，还有几种原因需要扣除工资。
例如，个人所得税、养老保险、医疗保险、公积金等。
试根据工资管理的要求，进行数据库的概念设计和逻辑设计。
9.3.1需求分析
工资管理主要根据每个职工每个月的考勤情况来计算工资发放。
工资管理系统的部分数据流图如图9.28所示。
图9.28工资管理系统的顶层数据流图
工资管理过程中涉及到的数据有如下几种：
●职工数据
●奖金数据
●假期数据
●病假数据
●扣除数据
●工资历史数据
●工资细节数据
工资管理的处理需求主要有以下几种情况。
●查询每个职工的所有工资情况。
●查询职工的支付方式或银行编号
●查询职工的奖金、假期、病假以及扣除情况。
●查询职工的历史数据。
9.3.2概念设计
1.局部视图设计
（1）确定局部视图的设计范围。
该应用主要是计算每个职工的工资，因此数据库设计涉及到职工的病假、假期、奖金等。
（2）确定实体及实体主键。
每个职工都会又多次的假期、病假、奖金以及其它扣除。
其中“其他扣除”包括了个人所得税、国家税、医疗保险、养老保险或者预付款等几种扣除类型；工资的支付方式分银行卡、现金、或者支票几种支付类型；奖金也分为不同类型，所以工资管理中涉及到的实体有如下几种。
●职工存放职工的基本信息，主键为“职工编号”。
●奖金：
存放职工每月获得的奖金，主键为“职工编号+日期+奖金类型编号”。
●假期：
存放职工的请假情况，主键为“职工编号+假期起始日期”。
●病假：
存放职工的病假情况，主键为“职工编号+病假起始日期”。
●扣除：
存放职工每个月的扣除情况，主键为“职工编号+扣除日期+扣除类型编号”。
●工资细节：
存放职工工资的账户、支付方式以及银行信息，主键为“职工编号”。
●工资历史：
存放每个职工工资的发放历史记录，主键为“职工号+日期”。
●奖金类型：
存放不同的奖金类型，主键为“奖金类型编号”。
●支付类型：
存放不同的支付方式，主键为“支付类型编号”。
●扣除类型：
存放不同的扣除类型，主键是“扣除类型编号”
（3）定义实体间的联系。
图9.29“职工”实体与“假期”实体之间的一对多联系
图9.30“职工”实体与“病假”实体之间的一对多联系
图9.31“职工”实体和“扣除”实体间的一对多联系
图9.32“职工”实体和“奖金”实体间的一对多联系
图9.33“职工”实体和“工资”实体、“工资细节”实体间的一对多联系
图9.34“奖金”实体和“奖金类型”实体间的一对多联系
图9.35“扣除类型”实体和“扣除”实体间的一对多联系
图9.36“支付方式”实体和“工资”实体之间的一对多关系
（4）给实体及联系加上描述属性。
●职工：
职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，E-mail，职务，部门。
●奖金：
职工编号，日期，奖金数，奖金类型。
●假期：
职工编号，假期起始时间，假期结束时间，请假原因
●病假：
职工编号，病假起始时间，病假结束时间，病假原因
●扣除：
职工编号，扣除日期，扣除类型编号，扣除数量。
●工资历史：
职工编号，日期，工资额。
●工资细节：
职工编号，开始日期，账号，支付方式编号，银行名称，银行地址。
●支付方式：
支付方式编号，支付方式。
●奖金类型：
奖金类型编号，奖金类型。
●扣除类型：
扣除类型编号，扣除类型。
2．视图集成
集成时仍采用两两集成策略。
集成后E-R图如图9.37所示。
图9.37工资管理系统总体E-R图
9.3.3逻辑设计
1.职工（职工编号，姓名，性别，出生年月，地址，办公电话，住宅电话，E-mail，职务，部门）
2.奖金（职工编号，日期，奖金数，奖金类型）
3.假期（职工编号，假期起始时间，假期结束时间，请假原因）
4.病假（职工编号，病假起始时间，病假结束时间，病假原因）
5.扣除（职工编号，扣除日期，扣除类型编号，扣除数量）
6.工资历史（职工编号，日期，工资额）
7.工资细节（职工编号，日期，账号，支付方式编号，银行名称，银行地址）
8.支付方式（支付方式编号，支付方式）
9.奖金类型（奖金类型编号，奖金类型）
10.扣除类型（扣除类型编号，扣除类型）
三、数据库的各方面的知识总结：
第一节：
信息，数据与数据处理
一、信息与数据：
1、信息：
是现实世界事物的存在方式或运动状态的反映。
或认为，信息是一种已经被加工为特定形式的数据。
信息的主要特征是：
信息的传递需要物质载体，信息的获取和传递要消费能量；信息可以感知；信息可以存储、压缩、加工、传递、共享、扩散、再生和增值
2、数据：
数据是信息的载体和具体表现形式，信息不随着数据形式的变化而变化。
数据有文字、数字、图形、声音等表现形式。
3、数据与信息的关系：
一般情况下将数据与信息作为一个概念而不加区分。
二、数据处理与数据管理技术：
1、数据处理：
数据处理是对各种形式的数据进行收集、存储、加工和传输等活动的总称。
2、数据管理：
数据收集、分类、组织、编码、存储、检索、传输和维护等环节是数据处理的基本操作，称为数据管理。
数据管理是数据处理的核心问题。
3、数据库技术所研究的问题不是如何科学的进行数据管理。
4、数据管理技术的三个阶段：
人工管理，文件管理和数据库系统。
第二节：
数据库技术的发展
一、数据库的发展：
数据库的发展经历了三个阶段：
1、层次型和网状型：
代表产品是1969年IBM公司研制的层次模型数据库管理系统IMS。
2、关系型数据型库：
目前大部分数据库采用的是关系型数据库。
1970年IBM公司的研究员E．F．Codd提出了关系模型。
其代表产品为sysemR和Inges。
3、第三代数据库将为更加丰富的数据模型和更强大的数据管理功能为特征，以提供传统数据库系统难以支持的新应用。
它必须支持面向对象，具有开放性，能够在多个平台上使用。
二、数据库技术的发展趋势：
1、面向对象的方法和技术对数据库发展的影响：
数据库研究人员借鉴和吸收了面向对旬的方法和技术，提出了面向对象数据模型。
2、数据库技术与多学科技术的有机组合：
3、面向专门应用领域的数据库技术
三、数据库系统的组成：
数据库系统（DBS）是一个采用数据库技术，具有管理数据库功能，由硬件、软件、数据库及各类人员组成的计算机系统。
1、数据库（DB）：
数据库是以一定的组织方式存放于计算机外存储器中相互关联的数据集合，它是数据库系统的核心和管理对象，其数据是集成的、共享的以及冗余最小的。
2、数据库管理系统（DBMS）：
数据库管理系统是维护和管理数据库的软件，是数据库与用户之间的界面。
作为数据库的核心软件，提供建立、操作、维护数据库的命令和方法。
3、应用程序：
对数据库中数据进行各种处理的程序，由用户编写。
4、计算机软件：
5、计算机硬件：
包括CPU、内存、磁盘等。
要求有足够大的内存来存放操作系统、数据库管理系统的核心模块以及数据库缓冲；足够大的磁盘能够直接存取和备份数据；比较主的通道能力；支持联网，实现数据共享。
6、各类人员。
四、数据库系统的特点：
1、数据共享：
2、面向全组织的数据结构化：
数据不再从属于一个特定应用，而是按照某种模型组织成为一个结构化的整。
它描述数据要身的特性，也描述数据与数据之间的种种联系。
3、数据独立性：
4、可控数据冗余度：
5、统一数据控制功能：
数据安全性控制：
指采取一定的安全保密措施确保数据库中的数据不被非法用户存取而造成数据的泄密和破坏；
数据完整性控制：
是指数据的正确性、有效性与相容性。
并发控制：
多个用户对数据进行存取时，采取必要的措施进行数据保护；
数据恢复：
系统能进行应急处理，把数据恢复到正确状态。
第三节：
数据模型
一、数据组织：
关系型数据库中的数据层次如下：
1、数据项（field）：
又称字段，用于描述实体的一个属性，是数据库的基本单位。
一般用属性名作项名；
2、记录（Record）：
又称为结点，由若干个数据项组成，用于描述一个对象；
3、文件（File）：
由若干个记录组成；
4、数据库（DataBase）：
由逻辑相关的文件组成。
二、数据模型：
数据的组织形式称为数据模型，它决定数据（主要是结点）之间联系的表达方式。
主要包括层次型、网状型、关系型和面向对象型四种。
层次型和网状型是早期的数据模型，又称为格式化数据系统数模型。
以上四种模型决定了四种类型的数据库：
层次数据库系统，网状数据库系统，关系型数据库系统以及面向对象数据库系统。
目前微机上使用的主要是关系型数据库。
1、层次型：
是以记录为结点的有向树；图如教材P7图1--2
2、网状型：
树的集合，它的表示能力以及精巧怀强于层次型，但独立性下降。
3、关系型：
在关系型中，数据被组织成若干张二维表，每张表称为一个关系。
一张表格中的一列称为一个“属性”，相当于记录中的一个数据项（或称为字段），属性的取值范围称为域。
表格中的一行称为一个“元组”，相当于记录值。
可用一个或若干个属性集合的值标识这些元组，称为“关键字”。
每一行对应的属性值叫做一个分量。
表格的框架相当于记录型，一个表格数据相当于一个同质文件。
所有关系由关系的框架和若干元组构成，或者说关系是一张二维表。
关系型的特点：
描述的一致性；可直接表示多对多关系；关系必须是规范化的；关系模型建立在数学概念基础上。
4、面向对象型：
主要采用对象和灯的概念。
第四节：
关系型数据库
一、关系型数据库的发展：
1、数据库产品种类繁多：
像dBASE，FoxBASE，Clipper，Paradox，Acess等。
2、采用SQL语言：
SQL（StructuredQueryLanguage）“结构化查询语言”，是通用的关系型数据库操作语言，可以查询、定义、操纵和控制数据库。
它是一种非过程化语言。
3、支持面向对象的程序设计：
4、提供良好的图形界面和窗口；
5、支持开放的客户机/服务器和分布式处理；
6、提供新一代的数据库管理系统开发工具：
支持GUI（图形界面）、ODBC（开放数据库连接）、OLE（对象的链接与嵌入）、DLL（动态链接）等。
二、关系型数据库管理系统（RDBMS）及其产品：
主要著名的关系型数据库产品有Oracle、Sybase、Informix、DB2、Inges、Paradox
升级会员 