一、数据库设计概述
数据库设计的定义：
数据库设计是指对于一个给定的应用环境，设计优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种应用需求，包括信息管理要求和数据操作要求。
数据库设计的特点
数据库设计的基本规律：
三分技术，七分管理，十二分基础数据。
对于“三分技术、七分管理、十二分基础数据”的理解(摘自网络)：
在这里面可以先不说软件提供商的那块，先说十二分数据这个吧，这个体现了你们公司的规模以及分工情况，ERP必须是在公司有一定规模，管理流程有较明确的分工的时候，才会体现出ERP的效果的。假如是一人身兼数职，那么，在使用过程当中就会造成混乱。这就是分工不明确，通常这种使用ERP还不如直接用excel处理来的有效。 另外很多公司上ERP就是为了整理数据，所以，在有一定规模的前提下，数据例如仓库物料 成品 等等这些，都要做好相关的处理，是否漏掉 是否编码重复。不过，不用担心，一般好的ERP公司，会有自己一套整理数据流程，你按照他们的安排，就算从无到有。在3万种物料之内的话，应该都没有问题的。
再来说三分软件，这块说明现在软件本身区别不会太大了。因为现在所有应用软件，都有自己的行业标准，通常这些软件都是按照标准来做了。不过不同行业，可能会有所调整，添加自己行业特色而已。
七分实施，我觉得是最终要的，一个实施顾问，他要体现他的顾问能力，是能够帮助公司解决问题的。而不是像很多代理，他们实施顾问，根本就没有从事过这个行业的工作，很多问题他还要问你们公司，那么，可以说这个软件是你们自己完成的，使用之后，不会跟使用之前有太大改变，因为所有东西都是按照你们说的来做，没有一点专业知识在里面。
在数据库领域中借用了这句话作为前半段，再加上十二分基础数据。其意义指在数据库设计时应该把握这样一个原则，即基础数据比数据库技术和数据库管理加在一起还要重要。因此这句话凸显了基础数据的重要性，提醒数据库的设计者，具体问题一定要具体分析，解决方案应该始终以基础数据为准则。
结构设计和行为设计
数据库设计应该与应用系统设计相结合。
数据库设计的基本步骤
数据库设计可分为以下六个阶段：
- 需求分析阶段：
准确了解与分析用户需求。 - 概念结构设计阶段：
对用户需求进行综合、归纳与抽象，形成一个独立于DBMS的概念模型。 - 逻辑结构设计阶段：
概念模型到某个特定的DBMS所支持的数据模型的转换。 - 物理结构设计阶段：
为逻辑数据结构选取一个最适合的应用环境。 - 数据库实施阶段：
运用DBMS提供的数据语言、工具及编程语言根据逻辑设计和物理设计的结果，编程实现数据库。 - 数据库运行和维护阶段
设计一个完善的数据库应用系统不可能是一簇而就的，它往往是上述6个阶段的不断反复。
| 设计阶段 | 设计描述 |
|---|---|
| 需求分析 | 建立数据字典 |
| 概念结构设计 | 概念模型（E-R图）、数据字典 |
| 逻辑结构设计 | 建立某种数据模型 |
| 物理结构设计 | 存储安排、存储方法、存储路径... |
| 数据库实施 | 创建数据库、装入数据、数据库试运行 |
| 数据库运维 | 性能监测、转储/恢复、数据库重组和重构 |
二、需求分析
需求分析的任务
需求分析的任务是通过详细的调查获得用户对数据库的如下要求：
- 信息要求
指用户现需要从数据库中获得的消息的内容与性质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。 - 处理要求
指用户要完成哪些数据处理的工作，对处理性能的要求。 - 安全性与完整性要求
确定用户的最终需求是非常困难的事情，因为双方都欠缺对方的知识背景，即用户缺少计算机知识，而设计人员也缺少用户的专业知识。因此设计人员必须不断深入地与用户交流，才能逐步确定用户的实际需求。
需求分析的方法
调查用户需求的具体步骤是：
- 调查组织机构的情况。
了解该组织的部门组成情况、各部门的职责等。 - 调查各部门的业务活动情况。
了解各部门输入和使用什么数据，如何加工数据，输出什么数据，输出结果的格式是什么样的。 - 在熟悉业务活动的基础上，协助用户明确对新系统的各种要求，包括信息要求、处理要求、安全性与完整性要求。
- 确定新系统的边界。
对前面的调查结果进行初步分析，确定哪些功能由计算机完成，哪些活动又人工完成。
数据字典
数据字典是进行详细的数据收集和数据分析所获得的主要成果。
数据字典是关于数据库中数据的描述，即元数据，而不是数据本身。
数据字典在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善。
数据项
数据项是不可再分的数据单位。对它的描述常包括如下内容：
- 数据项名
- 数据项含义说明
- 别名
- 数据类型
- 长度
- 取值范围
- 取值含义
- 与其他数据项的逻辑
- 数据项内的关系
数据结构
数据结构反应了数之间的组合关系。一个数据结构可由若干数据项组成或若干数据结构组成，也可由若干数项和数据结构混合组成。对它的描述常包括如下内容：
- 数据结构名
- 含义说明
- 组成：{数据项或数据结构}
数据流
数据流是数据结构再系统内传输的路径。对数据流的描述常包括如下内容：
- 数据流名
- 说明
- 数据流来源
- 数据流去向
- 组成：{数据结构}
- 平均流量：单位时间里传输的次数
- 高峰期流量：高峰时期的数据流量
数据存储
数存储时数据结构停留或保存的地方，即数据流的来源和去向之一。对数据存储的描述通常包括一下内容：
- 数据存储名
- 说明
- 编号
- 输入的数据流
- 输出的数据流
- 组成：{数据结构}
- 数据量
- 存取频度：指每小时、每天或每周存取次数及每次存取的数据量等信息。
- 存取方式：批处理还是联机处理，检索还是更新，顺序检索还是随机检索。
处理过程
处理过程的具体处理逻辑一般用判定表和判定树来描述。通常包括以下内容：
- 处理过程名
- 说明
- 输入：{数据流}
- 输出：{数据流}
- 处理：{简要说明}，主要说明处理功能与处理要求，处理要求指处理频度要求。
在需求分析阶段中，一定要强调用户参与。
三、概念结构设计
概念结构设计就是将从需求分析中获得的用户需求抽象为信息结构的过程。
概念模型
概念模型的特点：
- 能真实、充分地反映现实世界，包括事物之间的联系，能满足用户对数据的处理要求。
- 易于理解，可以使用它和不熟悉计算机的用户交换意见。
- 易于更改
- 易于向关系、网状、层次等各种数据模型转换。
E-R模型
E-R模型时用E-R图来描述现实世界的概念模型。它包括实体、属性、实体之间的联系等。
实体之间的联系
两个实体之间的联系：
- 一对一联系(1:1)
对于实体集A中的每一个实体，实体集B中至多有一个实体与之联系，反之亦然。 - 一对多联系(1:n)
对于实体集A中的每一个实体，实体集B中有(n)个实体((ngeq0))与之联系，反之，对于实体集B中每一个实体，实体集A中至多只有一个实体与之联系。 - 多对多联系(n:n)
对于实体集A中每一个实体，实体集B中有(n)个实体((ngeq0))与之联系，反之，对于实体B中的每一个实体，实体集A中有(m)个实体(mgeq0)与之联系。
除此外，还有多个实体之间的联系与单个实体内的联系。
一般地把参与联系的实体型的数目成为联系的度。两个实体型之间的联系称为二元联系；(N)个实体型之间的联系称为(N)元联系。
E-R图
E-R图提供了表示实体型、属性和联系的方法。
如图：
- 实体用矩形表示
- 属性用椭圆形表示
- 联系用棱形表示
概念结构的设计
概念结构设计的任务是根据需求分析收集来的数据，确定好实体、属性与联系。画出E-R图。
1. 实体与属性划分的原则
为简化E-R图的处置，现实世界中的事物作为属性对待的尽量作为属性对待。
那么问题来了，符合什么条件的事物可作为属性对待呢？下面给出了两条准则：
(1) 作为属性，该事物不能再具有需要描述的性质。即属性不可再分。
(2) 属性不能与其他实体具有联系。即E-R图中的联系是实体之间的联系。
2. E-R图的集成
在开发一个大型信息系统时，最经常使用的策略是自顶向下地进行需求分析，然后自底向上地设计概念结构。
E-R图的集成如下图所示，可以分为两步：合并、修改与重构
(1) 合并各分E-R图
合并阶段需要解决各分E-R图之间的冲突，将分E-R图合并成初步E-R图；
各子系统的E-R图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。
① 属性冲突
- 属性域冲突：即属性的类型、取值范围或取值集合不同。
- 属性取值单位冲突：计量单位冲突。
② 命名冲突
- 同名异意
- 异名同意
③ 结构冲突
- 同一对象在不同应用中具有不同的抽象：某一对象在某应用中为实体，而在另一应用中为属性。解决方法：统一向属性或实体转换。
- 同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同。解决方法：该实体的属性取各子系统的E-R图中属性的并集，再适当调整属性次序。
- 实体间的联系在不同的E-R图中为不同类型。
(2) 修改和重构。消除不必要的冗余，生成基本E-R图。
① 采用分析的方法
即以数据字典和数据流图为依据，根据字典中关于数据项之间逻辑关系的说明来消除冗余。
② 规范化理论的方法
其步骤如下：
- 确定分E-R图实体之间的数据依赖(F_L)
- 求(F_L)的最小覆盖范围(G_L)差集为(D=F_L-G_L)。逐一考察(D)中的函数依赖，确定是否是冗余的联系，若是便把它去掉。
注意：
- 冗余的联系一定在(D)中，而(D)中的联系不一定冗余。
- 当实体之间存在多种联系时，要将实体之间的联系在形式上加以区分。
四、逻辑结构设计
逻辑结构设计的目的是将设计好的基本E-R图转换为数据库管理系统支持的数据模型的逻辑结构。
E-R图向关系模式的转化
- 一个实体转换为一个关系模式
- 对于实体间的联系：
- 一个(1:1)的联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并；
- 一个(1:n)的联系可以转换为一个独立的关系模式，也可以与(n)端对应的关系模式合并；
- 一个(m:n)的联系转换为一个关系模式；
- 三个或三个以上实体间的一个多元联系可以转换为一个关系模式；
- 具有相同码的关系模式可以合并。
数据模型的优化
数据库逻辑设计的结果不是唯一的。
为了进一步提高数据库应用系统的性能，还需根据应用需求适当地修改、调整数据模型的结构，方法为：
- 确定数据依赖；
- 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余联系；
- 按照数据依赖的理论对关系模式逐一进行分析，确定各关系模式属于第几范式；
- 根据需求分析阶段得到的处理要求分析这些模式是否合适，确定是否需要对某些模式进行合并或分解。
设计用户子模式
在将概念模型转换为全局逻辑模型后，还应根据局部应用需求，结合具体的数据库系统的特点，设计用户子模式（view）。
定义全局模式主要是从系统的实现效率、空间效率、易维护角度出发。由于用户模式与模式是相对独立的，因此在定义用户模式时应考虑一下方面：
- 使用更符合用户习惯的别名；
- 可对不同级别的用户定义不同的视图，以确保安全性；
- 简化用户对系统的调用。
五、物理结构设计
物理结构设计的目的是为一个给定的逻辑数据结构选取一个适合的物理结构的过程。
物理结构设计分为两步：
- 确定数据库的物理结构；
- 对物理结构进行评价。
关系数据库的物理设计主要包括为关系模式选择存取方法，设计关系、索引等数据库文件的物理存储结构。
关系模式存取方式选择
存取方法是快速存取数据库中数据的技术。常用的存取方法为索引和聚簇方法。
- B+树索引存取方法的选择
- hash索引存取方法的选择
- 聚簇存取方法的选择
确定数据库的存储结构
- 确定数据的存放位置
- 确定系统配置
六、数据库系统的实施和维护
- 数据的载入和应用程序的调试
- 数据库的试运行
- 数据库的运行和维护