《数据库系统概论》 -- 7 数据库设计概述

最新推荐文章于 2021-09-14 10:04:55 发布

weixin_30611509

最新推荐文章于 2021-09-14 10:04:55 发布

阅读量332

点赞数

文章标签：数据库数据结构与算法人工智能

原文链接：http://www.cnblogs.com/yc913344706/p/7518296.html

版权

数据库设计概述

定义

数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并以此建立数据库及其应用系统，使之能够有效的存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。

信息管理要求：数据库中应存储和管理的数据对象

数据操作要求：对数据对象进行的操作，如增删改查。

特点

1. 三分技术、七分管理、十二分基础数据

2. 要把数据库结构设计和数据库应用系统设计密切结合

方法

新奥尔良方法、基于E-R模型的设计方法、3NF的设计方法、面向对象的数据库设计方法、UML方法等。

参与人员

系统分析人员、数据库设计人员、应用开发人员、数据库管理员和用户代表

步骤

步骤总览

需求分析

任务

通过详细调查现实世界要处理的对象，在用户的积极参与下，不断与用户交流充分了解原系统的工作概况，明确用户的各种需求，在此基础上考虑可扩展性来确定新系统的功能。

步骤

1. 调查用户需求

调查组织机构情况

了解该组织部门组成情况，各部门的职责等

调查各部门业务的活动情况

了解各部门输入与输出数据是什么，如何加工，从何输入，输出到哪，输出格式是什么等

明确用户对新系统的要求

信息要求用户需要从数据库中获得的信息的内容与性质。

处理要求用户要完成的数据处理功能、对处理性能的要求。

安全性与完整性要求

确定新系统的边界

确定哪些功能由计算机完成，哪些活动由人工完成

2. 分析和表达用户需求

分析方法众多，如结构化分析Structured Analysis

3. 提交分析结果

数据字典 是关于数据库中数据的描述，即元数据。

数据项

是不可再分的数据单位

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

数据结构

反映数据之间的组合关系

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

数据流

是数据结构在系统内传输的路径

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

数据存储

是数据结构停留停留或保存的地方，也是数据流的来源和去向之一。可以是手工文档，也可以是计算机文档。

数据存储描述={数据存储名，说明，编号，输入来源，输出的去向，组成：{数据结构}，数据量，存储频率，存取方式}

存取方式：是批处理还是联机处理，是检索还是更新，是顺序检索还是随机检索

处理过程

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

处理过程描述={处理过程名，说明，输入：{数据流}，输入：{数据流}，处理：{简要说明}}

简单说明：主要说明该处理过程的功能及处理要求。

功能：该处理过程用来做什么

处理要求：处理频度要求。如单位时间处理多少事务、多少数据量、响应时间要求等

概念结构设计

任务

将需求分析阶段得到的应用信息抽象为信息世界的结构

概念模型特点：

真实、充分反映现实世界

易于理解

易于更改

易于向关系、网状、层次等各种数据模型转换

比数据模型更独立于机器

方法

E-R模型（实体-关系模型）

实体型：学生（学号，姓名，年龄，...）

实体集：全体学生

实体间的联系：

单实体型内部的联系：一对一、一对多、多对多。

两个实体型之间的联系：一对一、一对多、多对多。

两个以上实体型之间的联系：一对一、一对多、多对多。

E-R图

实体型--矩形

属性--椭圆

联系--菱形

ISA联系--三角形

分类属性--三角形右侧加文字

根据分类属性将父实体型的实体分派到子实体型中

不相交约束--三角形内加×

父类中的一个实体不可以同时属于多个子类中的实体集

可重叠约束--默认

父类中的一个实体可以同时属于多个子类中的实体集

完备性约束--完全特化--双线

父类中的一个实体必须是子类中的实体

完备性约束--部分特化--单线

父类中的一个实体不必须是子类中的实体

基数约束 -- min..max

是一对一、一对多、多对多的细化。0<=min<=max

min=1，表示强制参与约束

min=0，表示非强制参与约束

Part-of联系

表明某个实体型是另外一个实体型的一部分。

非独占的Part-of联系--通过在整体实体处的基数约束min=0，表示一个部分实体可以不用整体实体参与

整体实体如果破坏，部分实体仍可独立存在。

独占的Part-of联系--用弱实体型和识别联系表示

强实体型--不依赖于其他实体型的存在

弱实体型--依赖于其他实体型而存在

识别联系--用双菱形表示

UML（略）

步骤

1.根据实体与属性的划分原则，对需求分析阶段收集到的数据进行分类、组织，确定实体、实体的属性、实体之间的联系类型，形成分E-R图

实体与属性的划分原则：

属性不能再有要描述的性质

属性不能与其他实体具有联系

2.分E-R图通过解决冲突，得到初步E-R图；初步E-R图通过消除冗余，得到基本E-R图

解决冲突（分E-R图-->初步E-R图）

属性冲突

冲突类型

属性域冲突（属性的取值范围或取值集合不同）

属性取值单位冲突（公斤与斤）

解决：各部门协商解决

命名冲突

冲突类型

同名异义（不同意义的对象在不同局部应用中有相同的名字）

异名同义（相同意义的对象在不同局部应用中有不同的名字）

解决：各部门协商解决

结构冲突

冲突类型

①同一对象在不同应用中具有不同的抽象（职工有的当作属性，有的当作实体）

②同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不同

③实体间的联系在不同的E-R图中为不同的类型

解决

①遵循实体与属性的划分原则，把属性变为实体，或实体变为属性

②取所有属性的并集，再调整次序

③

消除冗余（初步E-R图-->基本E-R图）

冗余类型

冗余数据：可由基本表导出的数据

冗余联系：可由其他联系导出的联系

方法

①以数据字典和数据流图为依据，分析数据项之间的逻辑关系来消除冗余

②并不是所有的冗余数据与冗余联系都必须加以消除。如果人为保留一些冗余数据，则应把数据字典中数据关联的说明作为完整性约束条件。

③确定分E-R图实体之间的数据依赖，逐一考察函数依赖，确定是否是冗余的联系，如果是就把它去掉

逻辑结构设计

任务

把概念结构设计好的E-R图转换为与选用DBMS所支持的数据模型相符合的逻辑结构。

步骤

1. E-R转换为关系模型

实体型

一个实体型转换为一个关系模式

1：1联系

可以转换为一个独立的关系模式（每个实体的码均是候选码）

也可以与任意一端对应的关系模式合并

1：n联系

可以转换为一个独立的关系模式（码为n端关系的码）

也可以与n端对应的关系模式合并

m：n联系

转换为一个关系模式（各实体的码组成关系的码或关系码的一部分）

m：n：p联系

转换为一个关系模式（各实体的码组成关系的码或关系码的一部分）

注：具有相同码的关系模式可以合并

2. 数据模型优化

①确定数据依赖，并进行冗余依赖去除，方法同概念模型（初步E-R图-->基本E-R图）

②确定各关系模式分别属于第几范式，并不是规范化越高的关系越优，需要权衡响应时间和潜在问题两者的利弊决定。

③水平分解关系模式：把关系的元组分为若干子集合，根据“80/20原则”，把经常被使用的数据（通常占20%）分解出来，形成一个子关系；还可根据事务来划分，使每个事务存取的数据对应一个关系

④垂直分解关系模式：把经常在一起使用的属性分解出来形成一个子关系模式，但需确保无损连接性和保持函数依赖。

3. 设计用户子模式

视图使用注意点

使用更符合用户习惯的命名（视图名、属性名等）

对不同级别的用户定义不同的视图

简化用户的使用

物理结构设计

目的

通过对要运行的事务进行详细分析（获得物理数据库设计所需要的参数），充分了解所用的RDBMS的内部特征（特别是RDBMS所提供的存取方法和存储结构），为关系模式选择适宜的存储方法，同时设计关系、索引等数据库文件的物理存储结构。

存取方法选择

常用的存取方法为索引方法和聚簇方法。

索引方法

B+树索引

一个（组）属性经常在查询条件中出现

或一个（组）属性经常作为最大（最小）值等聚集函数的参数

或一个（组）属性进场在连接操作的连接条件中出现

hash索引

一个属性经常出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下面两个条件之一：

一个关系的大小可预知，而且不变

关系的大小动态改变，但DBMS提供了动态hash存取方法

聚簇方法

概念

聚簇是指将一些相关的数据存储在同一个物理块上。

利用聚簇，一个块可以包含多个表的数据

原则

一个数据库可以建立多个聚簇，一个关系只能加入一个聚簇。

特点

对已有关系建立聚簇将导致关系中元组移动其物理存储位置，并使次关系上原来建立的所有索引无效，必须重建

举例

员工表和部门表，这两个表存在不同的segment上，甚至可能存储在不同的tablespace中，所以它们各自的数据肯定不在同一个block中。而同时我们又经常查询员工表.部门号=部门表.部门号，由于查询主要是对block进行操作，查询的block越多，系统IO就越大，效率就越慢，我们把这两个表的数据聚集在少量的物理相邻的block中，查询效率会大幅提高。

候选聚簇的选择原则

经常在一起进行连接操作的关系

经常出现在相等比较条件中

属性（组）上的值重复率很高

候选聚簇的反选原则

经常进行全表扫描的关系

删除远多于连接的关系

多个聚簇时，选择在此聚簇上运行各种事务的总代价最小的聚簇

聚簇的使用原则：

当通过聚簇码进行访问，是该关系的主要应用，与聚簇码无关的其他访问时很少或者是次要的，就可以使用聚簇

存储结构策略制定

根据应用情况将数据的易变部分和稳定部分、经常存取部分和存取频率较低部分、日志与数据等分开存放；