7.数据库设计_数据库概念设计7结构实验-CSDN博客

本文链接：https://blog.csdn.net/weixin_60771065/article/details/128973525

文章详细阐述了数据库设计的全过程，从概述、需求分析建立数据字典，到概念结构设计中的E-R图，再到逻辑结构设计和物理结构设计，最后涵盖数据库的实施和维护。重点讨论了E-R图向关系模型的转换、数据模型优化及视图设计，强调了数据库设计的目标是满足用户需求并提供高效运行环境。

摘要由CSDN通过智能技术生成

1.数据库实施（数据的载入和应用程序的编码和调试）

2.数据库的试运行

3.数据库的运行和维护

一、数据库设计概述

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

数据库设计的目标是为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。

1.数据库设计的特点

结构设计和行为设计相结合。

2.数据库设计方法

感觉不考

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

二、需求分析（建立数据字典）

需求分析就是分析用户的要求，是设计数据库的起点（第一阶段）。

第一阶段收集的基础数据(用数据字典来表达)是下一步进行概念设计的基础。

1.需求分析任务

2.需求分析方法

3.数据字典

数据数据字典是进行详细的数据收集和数据分析所获得的主要结果。
字典是关于数据库中数据的描述，即元数据，不是数据本身。
在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善。
在数据库设计占有很重要的地位

数据字典的内容

数据项(data item) 是不可再分的数据单位，是数据的最小组成单位。
数据结构反映了数据之间的组合关系。
一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。
数据流数据结构在系统内传输的路径。
数据存储数据结构停留或保存的地方，也是数据流的来源和去向之一。
处理过程处理过程的具体处理逻辑一般用判定表或判定树来描述。

三、概念结构设计（概念模型-E-R图）

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

1.概念模型

概念模型用E-R模型来描述

2.E-R图

两个实体型之间、两个以上实体型之间、单个实体型内都存在 1:1联系；1:n联系；m:n联系的联系（一对一、一对多、多对多）

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

实体型用矩形表示
属性用椭圆表示
联系用菱形表示

3.概念结构设计过程

1. 形成E-R图

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

在现实世界中具体的应用环境已对实体和属性作了自然的大体划分。
为简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。

实体与属性的划分原则(两条准则)：

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

2. E-R图的集成

自顶向下进行需求分析；再自底向上设计概念结构

设计各子系统的分E-R图 ⇒ 集成分E-R图 ⇒ 得到全局E-R图

①合并E-R图，解决冲突，生成初步E-R图

1. 属性冲突：

属性域冲突，即属性值的类型、取值范围或取值集合不同。如，零件号：字符型或整数
属性取值单位冲突，如，重量：公斤或磅或斤或吨或克

2. 命名冲突：

同名异义，即不同意义的对象在不同的局部应用中具有相同的名字
异名同义(一义多名)，即同一意义的对象在不同的局部应用中具有不同的名字，如，科研项目/课题,

3. 结构冲突：

同一对象在不同应用中具有不同的抽象。如，职工在一个局部应用中是实体，在另外一个应用中是属性
同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。⇒合并属性，调整次序
实体间的联系在不同的E-R图中为不同的类型。⇒根据语义对联系的类型进行综合或调整

②消除不必要的冗余，设计基本E-R图

1. 冗余的数据是指可由基本数据导出的数据

2. 冗余的联系是指可由其他联系导出的联系

四、逻辑结构设计（关系模型）

把概念结构设计阶段设计好的基本E-R图转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构（E-R图 => 关系数据模型）

1. E-R图向关系模型的转换

转换原则

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

关系的属性：实体的属性
关系的码：实体的码

1:1联系

将联系转换为一个独立的关系模式

关系的属性：与该联系相连的各实体的码以及联系本身的属性
关系的候选码：每个实体的码

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

合并后关系的属性：加入对应关系的码和联系本身的属性
合并后关系的码：不变 合并后原本关系模式的都码不变！！！！！！！

1:N联系

将联系转换为一个独立的关系模式

关系的属性：与该联系相连的各实体的码以及联系本身的属性
关系的码：n端实体的码

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

合并后关系的属性：在n端关系中加入1端关系的码和联系本身的属性
合并后关系的码：不变

注：可以减少系统中的关系个数，一般情况下更倾向于采用这种方法

m:n联系

将联系转换为一个独立的关系模式

关系的属性：与该联系相连的各实体的码以及联系本身的属性
关系的码：各实体码的组合

三个或三个以上实体间的一个多元联系

只能将联系转换为一个独立的关系模式

关系的属性：与该多元联系相连的各实体的码以及联系本身的属性
关系的码：各实体码的组合

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

目的：减少系统中的关系个数

合并方法：

将其中一个关系模式的全部属性加入到另一个关系模式中
去掉其中的同义属性（可能同名也可能不同名）
适当调整属性的次序

2. 数据模型的优化

得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。

关系数据模型的优化通常以规范化理论为指导。

数据模型的优化过程

确定数据依赖
对各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系
按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式
根据需要分析阶段得到的处理要求分析对于这样的应用环境这些模式是否合适，确定是否要对某些模式进行那个合并或分解
对关系模式进行必要分解，提高数据操作效率和存储空间的利用率
水平分解遵循 “80/20原则”、
垂直分解确保“无损连接性和保持函数依赖”

3.设计用户子模式（视图）

将概念模式转换为全局逻辑模型之后，还应该根据局部应用需求，结合具体RDBMS的特点设计用户的外模式。

视图被用于实现设计用户子模式。

定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发，而定义用户外模式时应该更注重考虑用户的习惯与方便。

使用更符合用户习惯的别名
定义视图时重新定义某些属性名，使其与用户习惯一致，以方便使用
针对不同级别的用户定义不同的视图，以保证系统的安全性
如，顾客视图只包含允许顾客查询的属性；销售视图只包含允许销售部门查询的属性
简化用户对系统的使用
可以将某些局部应用中要经常使用的复杂查询定义为视图

五、物理结构设计

数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统。

为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。

确定数据库物理结构主要指确定数据的存放位置和存储结构。

1.数据库管理系统常用存取方法

B+树索引存取方法
Hash索引存取方法
聚簇存取方法

        聚簇功能可以大大提高按聚簇码进行查询的效率

        聚簇功能不但适用于单个关系，也适用于经常进行连接操作的多个关系

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

        聚簇只能提高某些特定应用的性能

        建立与维护聚簇的开销相当大