数据库设计

数据库设计

  • 一.数据库设计概述
    • 1.数据库设计的特点
    • 2.数据库设计方法
    • 3.数据库设计的基本步骤
    • 4.数据库设计过程中的各级模式
  • 二.需求分析
    • 1.需求分析的任务
    • 2.需求分析的方法
    • 3.数据字典
  • 三.概念结构设计
    • 1.概念模型
    • 2.E-R模型
    • 3.概念结构设计

一.数据库设计概述

①数据库设计是指对于一个给定的应用环境,构造(设计)优化的数据库逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效地存储和管理数据,满足各种用户的应用需求,包括信息管理要求和数据操作要求。
②信息管理要求:在数据库中应该存储和管理哪些数据对象。
③数据操作要求:对数据对象需要进行哪些操作,如增删改查、统计等操作。
④数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。
⑤高效率的运行环境:

  • 数据库数据的存取效率高;
  • 数据库存储空间的利用率高;
  • 数据库系统运行管理的效率高。

1.数据库设计的特点

(1)数据库建设的基本规律
①三分技术、七分管理、十二分基础数据。

②管理

  • 数据库建设项目管理;
  • 企业(即应用部门)的业务管理。

③基础数据

数据的收集、整理、组织和不断更新。

(2)结构(数据)设计和行为(处理)设计相结合

结构和行为分离的设计(早期):
a.传统的软件工程:重行为设计

  • 忽视对应用中数据语义的分析和抽象,只要有可能就尽量推迟数据结构设计的决策。

b.早期的数据库设计:重结构设计

  • 致力于数据模型和数据库建模方法研究,忽视了行为设计对结构设计的影响。

2.数据库设计方法

(1)大型数据库设计是涉及多学科的综合性技术,又是一项庞大的工程。

(2)它要求多方面的知识和技术,主要包括:

计算机的基础知识;
软件工程的原理和方法;
程序设计的方法和技巧;
数据库的基本知识;
数据库设计技术;
应用领域的知识。

(3)手工试凑法(早期)

  • 设计质量与设计人员的经验和水平有直接关系;
  • 缺乏科学理论和工程方法的支持,工程的质量难以保证;
  • 数据库运行一段时间后常常又不同程度地发现各种问题,增加了维护代价。

(4)规范设计法(现代)

①手工设计方法;
②基本思想:

  • 过程迭代和逐步求精。

③各种典型方法:

  • 新奥尔良New Orleans方法;
  • 基于E-R模型的数据库设计方法;
  • 3NF(第三范式)的设计方法;
  • 面向对象的数据库设计方法;
  • 统一建模语言(UML)方法。

3.数据库设计的基本步骤

(1)数据库设计分6个阶段

①需求分析

是否做得充分与准确,决定了构建数据库的速度和质量。

②概念结构设计

通过对用户需求进行综合、归纳与抽象,形成一个独立于具体数据库管理系统的概念模型。

③逻辑结构设计

将概念结构转换为某个数据库管理系统所支持的数据模型,并对其进行优化。

④物理结构设计

a.为逻辑数据结构选取一个最适合应用环境的物理结构;
b.包括存储结构和存取方法。

⑤数据库实施

a.根据逻辑设计和物理设计的结构构建数据库;
b.编写与调试应用程序;
c.组织数据入库并进行试运行。

⑥数据库运行和维护

a.经过试运行后即可投入正式运行;
b.在运行过程中必须不断对其进行评估、调整与修改。

(2)需求分析和概念设计独立于任何数据库管理系统。

(3)逻辑设计和物理设计与选用的数据库管理系统密切相关。
数据库设计_第1张图片
(4)参加数据库设计人员的选定

①系统分析人员和数据库设计人员

  • 自始至终参与数据库设计,其水平决定了数据库系统的质量;

②数据库管理员和用户代表

  • 主要参加需求分析与数据库的运行和维护;

③应用开发人员

  • 包括程序员和操作员;
  • 在实施阶段参与进来,分别负责编制程序和准备软硬件环境。

(5)设计一个完善的数据库应用系统,往往是上述六个阶段的不断反复。

(6)这个设计步骤既是数据库设计的过程,也包括了数据库应用系统的设计过程。

(7)把数据库的设计和对数据库中数据处理的设计紧密结合起来,将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行,相互参照,相互补充,以完善两方面的设计。

4.数据库设计过程中的各级模式

数据库设计_第2张图片
(1)应用

需求分析阶段:综合各个用户的应用需求。

(2)概念模式

概念设计阶段:

  • 形成独立于机器特点,独立于各个数据库管理系统产品的概念模式(E-R图)。

(3)逻辑模式

逻辑设计阶段:

  • 首先将E-R图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式。
  • 然后根据用户处理的要求、安全性的考虑,在基本表的基础上再建立必要的视图(view),形成数据的外模式。

(4)内模式

物理设计阶段:

  • 根据数据库管理系统特点和处理的需要,进行物理存储安排,建立索引,形成数据库内模式。

二.需求分析

需求分析就是分析用户的要求:

  • 是设计数据库的起点;
  • 结果是否准确地反映了用户的实际要求,将直接影响到后面各个阶段的设计,并影响到设计结果是否合理和实用。

1.需求分析的任务

(1)详细调查现实世界要处理的对象(组织、部门、企业等)。

(2)充分了解原系统(手工系统或计算机系统)工作概况。

(3)明确用户的各种需求。

(4)在此基础上确定新系统的功能。

(5)新系统必须充分考虑今后可能的扩充和改变。

(6)调查的重点是“数据”和“处理”,获得用户对数据库的要求:

①信息要求:

  • 用户需要从数据库中获得信息的内容与性质;
  • 由信息要求可以导出数据要求,即在数据库中需要存储哪些数据。

②处理要求:

  • 用户要完成的处理功能;
  • 对处理性能的要求。

③安全性与完整性要求。

(7)确定用户最终需求的难点

  • 用户缺少计算机知识,不能准确地表达自己的需求,他们所提出的需求往往不断地变化。
  • 设计人员缺少用户的专业知识,不易理解用户的真正需求,甚至误解用户的需求。

(8)解决方法

设计人员必须不断深入地与用户进行交流,才能逐步确定用户的实际需求。

2.需求分析的方法

(1)调查清楚用户的实际需求并进行初步分析。
(2)与用户达成共识。
(3)分析与表达这些需求。
(4)调查用户需求的步骤

  • 调查组织机构情况;
  • 调查各部门的业务活动情况;
  • 协助用户明确对新系统的各种要求,包括信息要求、处理要求、完全性与完整性要求;
  • 确定新系统的边界。

(5)常用调查方法

①跟班作业。
②开调查会:

  • 通过与用户座谈来了解业务活动情况及用户需求;

③请专人介绍。
④询问。
⑤设计调查表请用户填写。
⑥查阅记录:

  • 查阅与原系统有关的数据记录。

(6)进一步分析和表达用户需求
①简单实用的分析方法:

结构化分析方法(Structured Analysis,SA)

  • SA方法从最上层的系统组织结构入手;
  • 采用自顶向下、逐层分解的方式分析系统。

②对用户需求进行分析与表达后,需求分析报告必须提交给用户,征得用户的认可。
数据库设计_第3张图片

3.数据字典

(1)数据字典是关于数据库中数据的描述,即元数据,不是数据本身。

(2)数据字典在需求分析阶段建立,在数据库设计过程中不断修改、充实、完善。

(3)数据字典是进行详细的数据收集和数据分析所获得的主要结果。

注意:和关系数据库管理系统中数据字典的区别和联系。

(4)数据字典的内容

  • 数据项
  • 数据结构
  • 数据流
  • 数据存储
  • 处理过程

(5)数据项数据的最小组成单位。

(6)若干个数据项可以组成一个数据结构。

(7)数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。

(8)数据项
①数据项是不可再分的数据单位。

②对数据项的描述

数据项描述=
{数据项名,
数据项含义说明,
别名,
数据类型,
长度,
取值范围,
取值含义,
与其他数据项的逻辑关系,
数据项之间的联系}

③“取值范围”、“与其他数据项的逻辑关系”定义了数据的完整性约束条件,是设计数据检验功能的依据。

④可以用关系规范化理论为指导,用数据依赖的概念分析和表示数据项之间的联系。

(9)数据结构
①数据结构反映了数据之间的组合关系。

②一个数据结构可以由若干个数据项组成,也可以由若干个数据结构组成,或由若干个数据项和数据结构混合组成。

③对数据结构的描述

数据结构描述={数据结构名,含义说明,组成:{数据项或数据结构}}

(10)数据流
①数据流是数据结构在系统内传输的路径。

②对数据流的描述:

数据流描述=
{数据流名,
说明,
数据流来源,
数据流去向,
组成:{数据结构},
平均流量,
高峰期流量}

③数据流来源:说明该数据流来自哪个过程。

④数据流去向:说明该数据流将到哪个过程去。

⑤平均流量:在单位时间(每天、每周、每月等)里的传输次数。

⑥高峰期流量:在高峰时期的数据流量。

(11)数据存储
①数据存储是数据结构停留或保存的地方,也是数据流的来源和去向之一。

②对数据存储的描述:

数据存储描述=
{数据存储名,
说明,
编号,
输入的数据流,
输出的数据流,
组成:{数据结构},
数据量,
存取频度,
存取方式}

③存取频度:每小时、每天或每周存取次数,每次存取的数据量等信息。

④存取方法:批处理/联机处理;检索/更新;顺序检索/随机检索。

⑤输入的数据流:数据来源。

⑥输出的数据流:数据去向。

(12)处理过程
①处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息。

②处理过程说明性信息的描述:

处理过程描述=
{处理过程名,
说明,
输入:{数据流},
输出:{数据流},
处理:{简要说明}}

③简要说明:说明该处理过程的功能及处理要求

  • 功能:该处理过程用来做什么;
  • 处理要求:处理频度要求,如单位时间内处理多少事务,多少数据量、响应时间要求等;
  • 处理要求是后面物理设计的输入及性能评价的标准。

三.概念结构设计

1.概念模型

(1)将需求分析得到的用户需求抽象为信息结构(即概念模型)的过程就是概念结构设计。

(2)概念模型的特点

  • 能真实、充分地反映现实世界,是现实世界的一个真实模型;
  • 易于理解,从而可以用它和不熟悉计算机的用户交换意见;
  • 易于更改,当应用环境和应用要求改变时,容易对概念模型修改和扩充;
  • 易于向关系、网状、层次等各种数据模型转换。

(3)描述概念模型的工具

E-R模型。

2.E-R模型

(1)实体之间的联系
①两个实体型之间的联系

a.一对一联系(1:1)

  • 如果对于实体集A中的每一个实体,实体集B中至多有一个(也可以没有)实体与之联系,反之亦然,则称实体集A与实体集B具有一对一联系。

b. 一对多联系(1:n)

  • 如果对于实体集A中的每一个实体,实体集B中有n个实体与之联系,反之,对于实体集B中的每一个实体,实体集A中至多只有一个实体与之联系,则称实体集A与实体集B有一对多联系。

c.多对多联系(m:n)

  • 如果对于实体集A中的每一个实体,实体集B中有n个实体与之联系,反之,对于实体集B中的每一个实体,实体集A中也有m个实体与之联系,则称实体集A与实体集B具有多对多联系。

数据库设计_第4张图片
②两个以上的实体型之间的联系

  • 一般地,两个以上的实体型之间也存在着一对一、一对多、多对多联系。

数据库设计_第5张图片
③单个实体型内的联系

  • 同一个实体集内的各实体之间也可以存在一对一、一对多、多对多的联系。

数据库设计_第6张图片

联系的度:参与联系的实体型的数目

  • 2个实体型之间的联系度为2,也称为二元联系;
  • 3个实体型之间的联系度为3,称为三元联系;
  • N个实体型之间的联系度为N,称为N元联系。

(2)E-R图
E-R图提供了表示实体型、属性和联系的方法:
①实体型

用矩形表示,矩形框内写明实体名。

②属性

用椭圆形表示,并用无向边将其与相应的实体型连接起来。

数据库设计_第7张图片
③联系

用菱形表示,菱形框内写明联系名,并用无向边分别与有关实体型连接起来,同时在无向边旁标上联系的类型。

  • 联系可以有属性。
    数据库设计_第8张图片

(3)举例说明:绘制仓库、零件、供应商、项目、职工的概念模型
①某个工厂物资管理的概念模型。物资管理涉及的实体有:

  • 仓库:属性有仓库号、面积、电话号码;
  • 零件:属性有零件号、名称、规格、单价、描述;
  • 供应商:属性有供应商号、姓名、地址、电话号码、账号;
  • 项目:属性有项目号、预算、开工日期;
  • 职工:属性有职工号、姓名、年龄、职称。

②实体间的联系有:

  • 一个仓库可以存放多种零件,一种零件可以存放在多个仓库中,因此仓库和零件具有多对多的联系。用库存量来表示某种零件在某仓库中的数量。
  • 一个仓库有多个职工当仓库保管员,一个职工只能在一个仓库工作,因此仓库和职工之间是一对多的联系。
  • 职工之间具有领导与被领导关系,即仓库主任领导若干保管员,因此职工实体型中具有一对多的联系。
  • 供应商、项目、零件三者之间具有多对多的联系。即一个供应商可以供给若干项目多种零件,每个项目可以使用不同供应商供应的零件,每种零件可由不同供应商供给。

③实体及属性图:
数据库设计_第9张图片

④实体及其联系图:
数据库设计_第10张图片
⑤完整的实体-联系图
数据库设计_第11张图片

3.概念结构设计

(1)实体与属性的划分原则
①为简化E-R图的处置,现实世界的事物能作为属性对待的,尽量作为属性对待。

②两条准则:

  • 作为属性,不能再具有需要描述的性质。属性必须是不可分的数据项,不能包含其他属性。
  • 属性不能与其他实体具有联系,即E-R图中所表示的联系是实体之间的联系。

(2)E-R图的集成
数据库设计_第12张图片

①第一步:合并。

解决各分E-R图之间的冲突,将分E-R图合并起来生成初步E-R图。

a.各个局部应用所面向的问题不同,各个子系统的E-R图之间必定会存在许多不一致的地方,称之为冲突。

b.子系统E-R图之间的冲突主要有三类:

属性冲突:

  • 属性域冲突,即属性值的类型、取值范围或取值集合不同。
  • 属性取值单位冲突。

命名冲突:

  • 同名异义,即不同意义的对象在不同的局部应用中具有相同的名字。
  • 异名同义(一义多名),即同一意义的对象在不同的局部应用中具有不同的名字。
  • 命名冲突:
    可能发生在实体、联系一级上;
    也可能发生在属性一级上;
    通过讨论、协商等手段加以解决。

结构冲突:

  • 同一对象在不同应用中具有不同的抽象。
    解决方法:把属性变换为实体或把实体变换为属性,使同一对象具有相同的抽象。
  • 同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。
    解决方法:使该实体的属性取各自子系统的E-R图中属性的并集,再适当调整属性的次序。
  • 实体间的联系在不同的E-R图中为不同的类型。
    解决方法:根据应用的语义对实体联系的类型进行综合或调整。

②第二步:修改和重构。

a.消除不必要的冗余,生产基本E-R图。

  • 所谓冗余的数据是指可由基本数据导出的数据,冗余的联系是指可由其他联系导出的联系。
  • 消除冗余主要采用分析方法,即以数据字典和数据流图为依据,根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
  • 并不是所有的冗余数据与冗余联系都必须加以消除,有时为了提高效率,不得不以冗余信息作为代价。

b.用规范化理论来消除冗余

确定分E-R图实体之间的数据依赖

  • 实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示,于是有了函数依赖集FL

求FL的最小覆盖GL,差集为D=FL-GL

  • 逐一考察D中的函数依赖,确定是否是冗余的联系,若是,就把它去掉。
  • 由于规范化理论受到泛关系假设的限制,应注意下面两个问题:
    冗余的联系一定在D中,而D中的联系不一定是冗余的;
    当实体之间存在多种联系时,要将实体之间的联系在形式上加以区分。

你可能感兴趣的:(数据库技术,数据库,sql)