第一章 数据库设计

1.数据库概述

数据库从字面上的理解是数据的仓库，我们平时说的数据库是指数据库管理系统(Database Management System)，它是一种操纵和管理数据库的大型软件，用于建立、使用和维护数据库，简称DBMS。严格来说数据库是数据库管理系统的实例，一个数据库管理系统可以有多个数据库实例。

2.数据库分类

2.1.关系数据库概述

关系型数据库：指采用了关系模型来组织数据的数据库。关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织

关系模型中常用概念：关系：一张二维表，每个关系都具有一个关系名，也就是表名 元组：二维表中的一行，在数据库中被称为记录 属性：二维表中的一列，在数据库中被称为字段 域：属性的取值范围，也就是数据库中某一列的取值限制 关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列组成 关系模式：指对关系的描述。其格式为：关系名(属性1，属性2， ... ... ，属性N)，在数据库中成为表结构。

数据库事务必须具备ACID特性，ACID分别是:Atomic原子性，Consistency一致性，Isolation隔离性，Durability持久性。

常见关系型数据库：Oracle、MySQL、Microsoft SQL Server、PostgreSQL、DB2， Microsoft Access、SQLite、Teradata、MariaDB(MySQL的一个分支)

关系型数据库优点：容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解。使用方便：通用的SQL语言使得操作关系型数据库非常方便。易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率。

关系型数据库缺点：高并发问题，硬盘I/O是瓶颈 2.查询大数据量效率低 3.在基于web的结构扩展不方便 4.性能欠佳。多表的关联查询、复杂SQL报表查询导致性能欠佳。

2.2.非关系数据库

非关系型数据库概念：NOSQL数据库，指非关系型的，分布式的且一般不保证遵循ACID原则的数据存储系统。

非关系型数据库结构：非关系型数据库以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，不局限于固定的结构，可以减少一些时间和空间的开销。

常见非关系型数据库：redis(持久化缓存)，mongodb(文档的数据库)、memcached （纯内存）

非关系型数据库优点：根据需要个性化添加所需字段 2-适用于SNS(Social Networking Services-社交网络服务)中，例如facebook，微博。非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。

非关系型数据库不足：只适合存储一些较为简单的数据对于需要进行较复杂查询的数据，关系型数据库显的更为合适。不适合持久存储海量数据

非关系型数据库分类：面向高性能并发读写的key-value数据库：Redis、Memcached。面向海量数据访问的面向文档数据库：MongoDB、CouchDB。面向搜索数据内容的搜索引擎：Elasticsearch、Solr、Splunk。面向可扩展性的分布式数据库：HBase、Cassandra。

3.数据库设计基本原则

把具有同一个主题的数据存储在一个数据表中，“一表一用”。一般要求数据库设计达到第三范式。多对多，最大限度消除了数据冗余、修改异常、插入异常、删除异常，基本满足关系规范化的要求。关系数据库中，各个数据表之间关系只能为一对一和一对多的关系。 对于多对多的关系必须转换为一对多的关系来处理。设计数据表结构时，应考虑表结构的动态适应性。

4.数据库设计的主要步骤

数据库设计的主要步骤：需求分析：分析用户的需求，包括数据、功能和性能需求。概念结构设计：主要采用E-R模型进行设计，包括画E-R图。逻辑结构设计：通过将E-R图转换成表，实现从E-R模型到关系模型的转换。物理结构设计：主要是为所设计的数据库选择合适的存储结构和存取路径。数据库实施：包括编程、测试和试运行。数据库的运行和维护：系统的运行与数据库的日常维护。

4.1.系统需求分析

任务：分析用户的需求和活动；收集和分析需求数据，确定系统边界的信息需求、功能需求、安全性和完整性需求；编写系统分析报告。主要形式：数据流图(Data Flow Diagram)、 数据字典 (Data Dictionary) 、判定表和判定树等。主要作用：用户交流的主要手段和依据 2-后续数据库设计的前提 3-数据流图--可以了解软件的结构，是软件设计的重要依据。步骤：用SA(自顶向下)方法分析SA(Structured Analysis)方法从最上层的系统组织结构入手，采用自顶向下，逐层分解的方式分析系统

用数据流图和数据字典描述系统：数据流图(DFD)：DFD(Data Flow Diagram)描述输入数据到输出数据的变换过程,通过系列符号及其组合来描述系统功能的输入、输出、处理或加工构造。设计工具为Microsoft Office Visio或Power Designer

数据流图示例

分层数据流图：当系统比较复杂时可采用分层描述的方法，分别画出各子系统的数据流图,继续细化形成若干层次的数据流图。

4.1.1.档案管理系统数据流程

业务流程：职工填写档案表，人事部门对档案表进行审核，合格的档案表加入档案册中。档案册可供查询和进行统计。人事部门有权对档案表进行修改和删除。

人事档案管理系统顶层图

分层顶层图

处理数据分解：对档案表进行审核，合格的档案表加入档案册中。档案册可供查询和进行统计

维护数据分解：维护数据包括增加，修改，删除，查询数据

利用数据分解：汇总数据，统计数据，分析数据，打印报表

4.1.2.数据字典（OD）概述

数据字典(Data Dictionary)是对系统中数据的详细描述，数据流图中出现的数据流，处理，文件等的说明 数据流图中的每个元素均与数据字典的一个条目相对应。

4.1.3.数据字典包含内容

数据项：数据的最小单位，包括数据项名、含义、类型、长度、范围与其他数据项的关系。

数据结构：有意义的数据项集合，包括数据结构名、含义组成的数据项名。

数据流：处理过程中数据在系统内的传输路径，包括数据流名、说明、流出、流入。

处理过程：对系统中的处理进行描述，包括处理过程名、说明、输入数据流、输出数据流。

数据存储：系统中数据的存放，包括数据存储名、说明、输入数据流、输出数据流、数据项或数据结构、数据量、存储频度、存取方式等。

4.1.4.具体案例

选课管理系统功能结构图

选课系统业务流程分析

选课部分流图

数据流

数据存储

处理过程

数据项

4.2.概念结构设计

概述：通过对需求分析得到的用户需求数据抽象，设计系统概念模型，一般为E-R模型概念数据模型对应pd中的CDM模型。

概念模型特点：语义表达能力丰富、易于交流和理解、易于修改和扩充、易于向各种数据模型转移E-R模型是最著名、最实用的一种是概念模型。

方法：自顶向下、自底向上、逐步扩张、混合策略。

4.2.1.步骤

4.2.1.1.实体

要建立系统的E-R模型的描述，需进一步从数据流图和数据字典中抽取系统所有实体及其属性。

抽取实体指导原则

属性必须是不可分的数据项，即属性中不能包含其它的属性或实体 E-R图中的关联必须是实体之间的关联，属性不能

和其它实体之间有关联。

选课管理系统涉及到实体

总共5个：学生、教师、课程、院系、班级。 学生实体属性有：学号、姓名、出生年月、性别、电话、系编号。 教师实体属性有：教师编号、教师姓名、性别、职称、出生年月、电话、电子邮件。 课程实体属性有：课程编号、课程名称、课程学时、课程学分。 院系实体属性有：系编号、系名称、负责人。 班级实体属性有：班级编号、班级名称。

4.2.1.2.系统局部E-R图

需求分析阶段我们采用自上而下的分析方法，分析得到实体及其属性后，进一步可分析各实体之间的联系为此分别找出上述5个实体之间的一切联系。

学生实体和课程实体——选修联系 教师实体和课程实体——讲授联系 学生实体和班级实体——归属联系 班级实体和院系实体——归属联系 教师实体和院系实体——归属联系。

学生和课程

学生实体和课程实体存在选修的联系，一个学生可以选修多门课程，而每门课也可以被多个学生选修，所以它们之间是多对多的联系(n:m)如图：

教师和课程

教师实体和课程实体存在讲授的联系，一名教师可以讲授多门课程，而每门课也可以被多个教师讲授，所以它们之间是多对多的联系(n:m),如图。

学生和班级

学生实体和班级实体存在归属的联系，一个学生只能属于一个班级，而每个班级可以包含多个学生，所以班级和学生之间是一对多的联系(1:n),如图

班级和院系

班级实体和系之间存在归属的联系，一个班级只能属于一个系，而每个系可以包含多个班级，所以班级和系之间是一对多的联系(1:n),如图

教师和院系

教师实体和系实体之间存在归属的联系，一个教师只能属于一个系，而每个系可以拥有多名教师，所以教师和系之间是一对多的联系(1:n)，但教师中会有一位充当该系的主任(正)，可见教师和系之间也存在一种一对一的领导关系(1:1)

4.2.1.3.系统全局E-R图

局部的E-R图往往有多人各自分析完成的，只反映局部的独立应用的状况，在系统整体的运作需要时，这些局部E-R图之间有可能存在重复的部分或冲突的情况，如： 实体的划分、实体或属性的命名不一致 属性的具体含义(包括数据类型以及取值范围等不一致)问题等

4.3.逻辑结构设计

逻辑设计就是把E-R图转换成关系模式，并对其进行优化；只要包括ER图到关系模式的转换、关系模式的规范及调整、各个数据表的表结构设计

4.3.1.ER图到关系模式的转换

在概念设计阶段得到的数据模型，是独立于具体DBMS产品的信息模型。 在逻辑设计阶段就是将这种模型进一步转化为某一种（某些类）DBMS产品支持的数据模型。 目前流行的是基于关系模型的数据库管理系统，如MySql、SQL、Server、Oracle、DB2等，本文以MySQL数据库系统环境为例，将概念设计阶段的E-R图模型转化为关系数据模型，针对上述最终合成的E-R图 对E-R图中的每个实体分别转化为对应的一个关系，共有5个实体。

5个实体转化成对应的关系模式为:

教师(教师编号、教师姓名、性别、职称、电话、院系编号) 课程(课程编号、课程名称、课程学分、课时) 院系(系编号、系名称、系主任) 班级(班级编号、班级名称、系编号) 学生(学号、姓名、性别、出生年月、电话、班级编号)

全局的E-R图中共包含6个联系:

其中一对多的有3个 院系实体和班级之间是一对多的联系类型，所以只要两个关系模式就可表示，其中院系可以放到班级的实体中的连接属性(外键) 其它两个都按如此处理 一对一的有1个 和上述的一对多的处理模式类似 多对多的有2个学生实体与讲授是聚集方式的联系类型，它们之间的关系是多对多的关系，可以使用如下关系模式来表示： 学生选课(课程编号，学号，教师编号，开课年度，开课学期，成绩)

4.3.2.各个数据表的表结构设计

数据库中表清单

学生信息表

教师基本信息表

院系基本信息表

班级信息表

课程基本信息表

学生选课信息表

教学计划信息表

4.4.物理结构设计

物理数据模型对应pd中的PDM，物理设计主要任务是将逻辑设计映射到存储介质上，利用可用的硬件和软件条件能可靠地、高效地对数据进行物理访问和维护。

4.4.1.数据库系统实施及运行维护

组织数据入库、编制应用程序、试运行；系统投入运行，长期的维护工作。