第三章 数据库设计

第一节 数据库设计概述

一，数据库的生命周期

• 数据库的生命周期分为两个阶段
  • 数据库分析与设计阶段
    • 包括需求分析，概念设计，逻辑设计和物理设计四个环节。
  • 数据库实现与操作阶段
    • 包括数据库的实现，操作与监督，修改与调整三个阶段。

二，数据库设计的目标

• 满足应用功能需求和良好的数据库性能。
  • 满足应用功能需求
    • 主要是指用户当前与可预知的将来应用所需要的数据及其联系，应全部准确地存储在数据库之中，从而可满足用户应用中所需要的对数据进行的存，取，删，改等操作。
  • 良好的数据库性能
    • 主要是指对数据的高效率存取和空间的节省，并具有良好的数据共享性，完整性，一致性及安全保密性。

三，数据库设计的内容

• 数据库结构设计
  • 针对给定的应用环境进行数据库的模式或子模式的设计，包括数据库的概念结构设计，逻辑结构设计和物理结构设计。
  • 是静态的，一经形成通常不会改变。
• 数据库行为设计
  • 确定数据库用户的行为和动作，用户的行为和动作是对数据库的操作，通常是通过应用程序来实现的。行为设计是动态的。

四，数据库设计的方法

• 该方法应具有足够的通用性和灵活性，适用于不同的应用领域。还应具有可再生的特征，即不同的人应用该方法于同一问题，应该得到同样的或相近的数据库结构。
• 数据库设计的方法分为三类，即直观设计法，规范设计法和计算机辅助设计法。
• 直观设计法
  • 最原始的数据库设计方法，利用设计者的经验和技巧来设计数据库模式，缺乏科学理论的指导，已不适应如今信息系统。
• 规范设计法
  • 较为普遍，常用的数据库设计方法。常见有以下几种。
    • 新奥尔良设计方法
      • 将数据库设计分为四个阶段，分别是需求分析，概念结构设计，逻辑结构设计和物理结构设计，注重数据库的结构设计，而不太考虑数据库的行为设计。
    • 基于E-R模型的数据库设计方法
      • 基本思想是在需求分析的基础上用E-R图构造一个反应现实世界实体之间联系的企业模式，然后将此模式转换成某一特定DBMS下的概念模式。
    • 基于第三范式的设计方法
      • 在需求分析的基础上首先确定数据库的模式，属性及属性间的依赖关系，然后将他们组织在一个单一的关系模式中，在分析模式中不符合第三范式的约束条件，进行模式分解，规范成若干个第三范式关系模式的集合。
• 计算机辅助设计法
  • 在数据库设计过程中，以领域专家的知识或经验为主导，模拟某一规范化设计的方法，通常通过人机交互的方式来完成设计的某些过程。

五，数据库设计的过程

• 分为五个阶段
  • 需求分析阶段
  • 结构设计阶段
    • 包括概念结构设计，逻辑结构设计和物理结构设计。
  • 行为设计阶段
    • 包括功能设计，事务设计和程序设计。
  • 数据库实施阶段
    • 包括加载数据库数据和调试运行应用程序。
  • 数据库运行与维护

第二节 数据库设计的基本步骤

一，需求分析

• 需求分析的目标是了解与分析用户的信息及应用处理的要求，并将结果按一定格式整理而形成需求分析报告。
• 需求分析可分为四个阶段
  • 确定数据库范围
    • 确定数据库应支持那些应用功能。
  • 应用过程分析
    • 指了解并分析数据与数据处理之间的关系。
    • 应用过程分析的结果是数据库结构设计的重要依据，因为从中可以初步导出那些数据要存入数据库中，哪些数据可以作为报告输出而不存入数据库中，同时也可看出对不同数据的不同使用权限和共享范围。
    • 数据应用过程可以借助数据流程图或其他信息及应用结构图形表示。
  • 收集与分析数据
    • 用于了解并分析数据的组成格式及操作特征，每个数据元素的语义及关系等，并将它们收集起来整理归档。
  • 编写需求分析报告
    • 准确地表达应用需求，要求可读性强，且无二义性，能为数据库的后续阶段设计提供全面，准确和详细的资料。

二，概念结构设计

• 概念结构设计的任务是在需求分析中产生的需求分析报告的基础上，按照特定的方法设计满足应用需求的用户信息结构，该信息结构通常称为概念模型。
• 概念模型独立于任何软件和硬件，其设计的主要目标是最大限度地满足应用需求。
• 概念模型设计的常用方法有实体分析法和属性综合法两种。

三，逻辑结构设计

• 逻辑结构设计的目标是将概念模型转化为等价的，并为特定DBMS所支持数据模型的结构。数据库逻辑模型一般由层次，网状，关系数据模型表示。

四，物理设计

• 物理设计是指对于一个给定的数据库逻辑结构，研究并构造物理结构的过程，具体任务主要是确定数据库在存储设备上的存储结构及存储方法，因DBMS的不同还可能包括建立索引和聚集，以及物理块大小，缓冲区个数和大小，数据压缩的选择等。

五，数据库实施

• 数据库实施阶段需要完成的工作包括
  • 加载数据
    • 将符合要求的初始化数据装载到数据库中去。具体包括数据的收集，分类，整理校验和输入等过程，经此就可将数据按数据库定义准确地存储到数据库中。
  • 应用程序设计
    • 在需求分析阶段，通过需求分析报告，详尽地了解用户关于数据信息的处理需求，包括任务的分类，功能，处理流程及其与数据的联系。
    • 在逻辑设计阶段，根据产生的逻辑模型与子模型，具体划分应用程序的功能模块，进一步抽象并标明其名称，执行逻辑及其与数据库中数据的联系，从而基本确立应用程序的框架。
    • 在物理设计阶段，根据建立的物理模型，又进一步修改和完善程序设计说明。
  • 数据库试运行
    • 试运行是指在已建立的数据库上，按生产现场实际环境要求运行应用程序，进行对数据库的各种操作，检验其功能和性能，如有不当或错误，则应根据实际情况或修改应用程序，修改数据库物理模型，甚至修改逻辑模型。

六，数据库运行和维护

第三节 关系数据库设计方法

一，概念结构设计方法

• 关系数据库的概念结构设计通常采用自顶向下法。首先建立局部信息结构，然后将局部信息结构合成为全局信息结构并优化。使用E-R图作为概念模型的描述工具。

1，E-R图的表示方法

• E-R图提供了表示信息世界中实体，属性和联系的方法，如下

  • 实体性，用矩形表示，矩形框内写明实体的名称。
  • 属性，用椭圆形表示，并用无向边将其与相应的实体连接起来。
  • 联系，用菱形表示，菱形框内写明联系的名称，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型（1:1，1:N或M:N），如果一个联系具有属性，则这些属性也要用无向边与该联系连接起来。

• 实体之间的联系通常指不同实体型的实体集之间的关系，其常常表现为一下三种情形。

  • 两个实体型之间的联系

    • 设有两个实体集A，B，两个实体型之间的联系分为一对一，一对多，多对多三种类型。

      • 一对一联系（1:1）
        • 如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1:1。
      • 一对多联系（1:N）
        • 如果对于实体集A中的每一个实体，实体集B中有N个实体与之联系，反之，对于实体集B中的每一个实体，实体集A中至多有一个实体与之联系，则称实体集A与实体集B具有一对多联系，记为1:N。
      • 多对多联系（M:N）
        • 如果对于实体集A中的每一个实体，实体集B中有N个实体与之联系，反之，对于实体集B中的每一个实体，实体集A中也有M个实体与之联系，则称实体集A与实体集B具有多对多联系，记为M:N。

      

  • 两个以上的实体型之间的联系

    • 对于课程，教师和参考书三个实体型，如果一门课程可以有若干个教师讲授，使用若干本参考书，而每一个教师只讲授一门课程，每一本参考书只供一门课程使用，则课程与教师，参考书之间的联系是一对多的。

    

  • 单个实体型内的联系

    • 如职工实体型内部具有领导与被领导的联系，即一个职工（如系主任）“领导”若干名职工（如系里的教师），而一名职工仅被另外一名职工直接领导，则这种联系就是一对多的联系。

    

2，局部信息结构设计

• 根据需求分析报告中标明的不同用户视图范围所建立的满足该范围内用户需求的信息结构，称为局部信息结构。局部信息结构设计的步骤分为：确定局部范围；选择实体；选择实体关键字；确定实体间联系；确定实体的属性。

1，确定局部范围

• 局部范围主要依据需求分析报告中标明的用户视图范围来确定。

2，选择实体

• 在确定的局部范围内选择一些合适的信息单位作为局部信息结构的基本实体。
• 实体选择时的最大困难是如何区别实体与属性。在应用环境中，从不同的应用观点出发，同一个信息单位，有的视为实体，有的视为属性。此时，应根据应用的各不同需求，分清主次，灵活处理。

3，选择实体的关键字属性

• 实体的存在依赖于其关键字的存在。选择关键字属性除了考察其是否唯一标识实体之外，还应注意实际应用中的习惯。

4，确定实体间联系

• 数据间的联系必须在概念设计时确定。一种常用的分析实体间是否存在联系的方法是，将局部范围内的实体逐一取出来与该范围内的其他实体试行匹配，考察能否找到与两个参加试匹配的实体都有关的问题或同一任务同时使用到参与试匹配的两个实体。如若存在这种情况，则认为它们之间存在某种联系。

5，确定实体的属性

• 属性分为标识属性和说明属性
  • 标识属性用作实体的关键字。
  • 说明属性用作描述实体的一般特征。
• 说明属性的存在和使用通常依赖于标识属性。属性分配到某个实体是否合理，取决于该属性是否可通过其所在实体的关键字找到，并且它们之间在应用中具有某种联系。

​