【数据库学习笔记】Day08 - 数据库设计

原创已于 2022-03-22 22:05:41 修改 · 536 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #sql #database

于 2022-03-22 21:59:38 首次发布

数据库学习笔记专栏收录该内容

9 篇文章

订阅专栏

本文详细介绍了数据库设计的全过程，从需求分析到数据库的运行和维护。内容涵盖静态结构设计（概念、逻辑、物理结构）和动态行为设计（功能、事务），强调了结构设计与行为设计的分离。此外，还讨论了数据处理流图、E-R图在设计中的作用，以及数据的加载、调试和安全性。

1.1 数据库设计的特点

（1）综合性

涉及面广，需包含专业知识及业务系统专业知识。
要解决技术及非技术两方面的问题。

（2）静态结构设计与动态行为设计是分离的

静态结构设计是指数据库的模式框架设计，包括语义结构（概念）、数据结构（逻辑）、存储结构（物理）。
动态设计是指应用程序设计（动作操纵：功能组织、流程控制）。
数据库的静态结构设计在模式或外模式中定义。
数据库的动态行为设计在存取数据库的应用程序中设计和实现。
结构设计和行为设计是分离进行的。

1.2 数据库设计的方法

新奥尔良（New Orleans）方法：
需求分析：了解和分析用户需求。
概念结构设计：对用户需求进行抽象和归纳，形成一个独立于DBMS的概念模型（E-R图）。
逻辑结构设计：将概念结构转换为数据模型，通常为关系模型。
物理结构设计。为逻辑数据模型选取一个最适合存储结构和存取方法；数据库实施阶段。编写数据库，编写和调试应用程序；数据库运行和维护。正式投入运行。
数据库设计方法从本质上看仍然是手工设计方法，其基本思想是过程迭代和逐步求精。

1.3 数据库设计全过程

需求分析→结构设计→行为设计→数据库实施→数据库运行和维护
在这里插入图片描述

1.4 数据库需求分析

1.4.1 数据库需求分析的任务

需求分析阶段的主要任务是对现实世界要处理的对象（公司，部门，企业）进行详细调查，在了解现行系统的概况、确定新系统功能的过程中，收集支持系统目标的基础数据及其处理方法。
需求分析是在用户调查的基础上，通过分析，逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务处理需求。
用户调查的重点是“数据”和“处理”。
信息需求定义未来数据库系统用到的所有信息，明确用户将向数据库中输入什么样的数据，从数据库中要求获得哪些内容，将要输出哪些信息。同时还要描述数据间的联系等。
处理需求定义了系统数据处理的操作功能，描述操作的优先次序，包括操作的执行频率和场合，操作与数据间的联系。处理需求还要明确用户要完成哪些处理功能，每种处理的执行频度，用户需求的响应时间以及处理的方式，比如是联机处理还是批处理，等等。
安全性与完整性要求描述了系统中不同用户对数据库的使用和操作情况，完整性要求描述了数据之间的关联关系以及数据的取值范围要求。

1.4.2 数据处理流图

在需求分析中，通过自顶向下、逐步分解的方法分析系统。任何一个系统都可以抽象为数据流图的形式。
在这里插入图片描述

1.5 数据库结构设计

概念结构设计：形成DB概念模式，用语义层模型描述，如 E - R 图。
逻辑结构设计：形成DB逻辑模式与外模式，用结构层模型描述，如基本表、视图等。
物理结构设计：形成DB内模式，用文件级术语描述，如DB文件或目录、索引。

1.5.1 概念结构设计

概念结构设计的任务是产生反映企业组织信息需求的数据库概念结构，即概念模型。
概念模型的特点：
有丰富的语义表达能力、易于交流和理解、易于更改、易于向各种数据模型转换、易于导出与DBMS有关的逻辑模型。
概念结构设计的策略：
自底向上：先定义局部应用的概念结构，然后按一定的规则把它们集成起来，从而得到全局概念模型。
自顶向下：先定义全局概念模型，然后再逐步细化。
由里向外：先定义最重要的核心结构，然后再逐步向外扩展。
混合策略：将自顶向下和自底向上结合起来使用。
概念结构是对现实世界的一种抽象。
所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质细节，并把这些特性用各种概念准确的加以描述。
一般有三种抽象方法：
分类
概括
聚集

1.分类：
在相似的个体之间提取共性，建立“类”的概念（集合）。
个体与个体之间：具有相似的状态与行为，有相同的描述结构，相互用主码值区分。
个体与类之间：个体 Is a member of 类（子类有且仅有一个超类）。
2.概括：
在这里插入图片描述
3.聚集：

对关系数据库，设计E - R图是概念结构设计的基本方法。先设计局部E - R图，再设计全局E - R图。
设计局部 E - R 图：
实体和属性是相对而言的，需要根据实际情况进行调整。
对关系数据库而言，其基本原则是：
实体具有描述信息，而属性没有，即属性是不可再分的数据项，不能包含其他属性。
设计全局 E - R 模型：
将局部 E - R 图集成全局的 E - R 图。
需要消除合并时产生的冲突：
属性冲突：属性域冲突、属性取值单位冲突。
命名冲突：同名异义和异名同义。
结构冲突：同一对象在不同应用中具有不同的抽象、同一实体在不同的局部E-R图中所包含的属性个数和属性的排列次序不完全相同。

1.5.2 逻辑结构设计

把概念结构设计阶段设计好的基本E-R模型转换为具体的数据库管理系统支持的数据模型，也就是导出特定的DBMS可以处理的数据库逻辑结构（数据库的模式和外模式），这些模式在功能、性能、完整性和一致性约束方面满足应用要求。

步骤：
将概念模型转换为某种组织层数据模型。
对数据模型进行优化。

E - R 模型向关系模型转换方法：

一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的标识符就是关系的码。
对于实体间的联系有以下不同的情况：
一个1：1联系可以转换为一个独立的关系模式，也可以与任意一端所对应的关系模式合并。
一个1：n联系可以转换为一个独立的关系模式，也可以与n端所对应的关系模式合并。
一个m：n联系转换为一个关系模式。
三个或三个以上实体间的一个多元联系可以转换为一个关系模式。
具有相同码的关系模式可以合并。

数据模型的优化：
关系数据模型的优化通常以规范化理论为指导，并考虑系统的性能。具体方法为：

确定各属性间的数据依赖。
消除冗余的联系。
确定最合适的范式。
确定是否要对某些模式进行分解或合并。
对关系模式进行必要的分解，以提高数据的操作效率和存储空间的利用率。

设计外模式：

将概念模型转换为逻辑数据模型之后，还应该根据局部应用需求，并结合具体的数据库管理系统的特点，设计用户的外模式。
外模式概念对应关系数据库的视图概念，设计外模式是为了更好地满足局部用户的需求。
定义数据库的模式主要是从系统的时间效率、空间效率、易维护等角度出发。
定义外模式，要注意：使用更符合用户习惯的别名。对不同级别的用户定义不同的视图，以保证数据的安全。简化用户对系统的使用。

1.5.3 物理结构设计

对已确定的逻辑数据结构，利用DBMS提供的方法、技术，以较优的存储结构、数据存取路径、合理的数据存储位置以及存储分配，设计出一个高效的、可实现的物理数据库结构。
数据库的物理设计通常分为两步：
确定数据库的物理结构；
对物理结构进行时间和空间效率的评价。

物理结构设计的内容和方法：

对于数据查询，需要得到如下信息：
查询所涉及的关系；
查询条件所涉及的属性；
连接条件所涉及的属性；
查询列表中涉及的属性。
对于更新数据的事务，需要得到如下信息：
更新所涉及的关系；
每个关系上的更新条件所涉及的属性；
更新操作所涉及的属性。

确定存取方法：

一般用户可以通过建立索引的方法来加快数据的查询效率。
建立索引的一般原则为：
在经常作为查询条件的属性上建立索引。
在经常作为连接条件的属性上建立索引。
在经常作为分组依据列的属性上建立索引。
对经常进行连接操作的表可以建立索引。
一个表可以建立多个索引，但只能建立一个聚簇索引。

物理结构设计的评价：

评价物理结构设计的方法完全依赖于具体的DBMS，主要考虑的是操作开销，即为使用户获得及时、准确的数据所需的开销和计算机的资源的开销。具体可分为如下几类：
查询和响应时间
更新事务的开销
生成报告的开销
主存储空间的开销
辅助存储空间的开销

1.6 数据库行为设计

1.6.1 功能需求分析

在进行需求分析时，实际上进行了两项工作:
1.“数据流”的调查分析，
2.“事务处理”过程的调查分析。
数据流的调查分析为数据库的信息结构提供了最原始的依据，事务处理的调查分析是行为设计的基础。
对行为特性要进行的分析：
标识所有的查询、报表、事务及动态特性，指出对数据库所要进行的各种处理；
指出对每个实体所进行的操作（增、删、改、查）；
给出每个操作的语义，包括结构约束和操作约束；
给出每个操作（针对某一对象）的频率；
给出每个操作（针对某一应用）的响应时间；
给出该系统总的目标。