5.1 概念结构
概述：
具体地说，对于一个给定的应用环境，构造出最优的数据库逻辑模式和物理模式，并建立数据库及其应用系统，使之能够有效地存储和管理数据，满足用户的信息要求和处理要求。
数据库设计的六个阶段
上述概念了解即可，下面开始切入正题。
5.2 概念结构设计
5.2.1 概念结构
什么是概念结构？
将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计
实体联系方法（E-R方法）
关于ER方法简单看一下下面三个了解即可 ER方法也被叫做ER模型
下面是ER模型的详细讲解，有兴趣可以了解一下。
ER模型_shendeguang的专栏-CSDN博客_er模型
举个例子：
方框内的是实体，类似JAVA中的对象，可以包含不同属性，例如班级实体可以包含班级名称，班级人数等属性 菱形内的是关系 单个实体之间也可以存在于自己的联系，如下图
联系的属性
联系本身也是一种实体型，也 可以有属性。如果一个联系具有属性，则这些属性也要用无向边与该联系连接起来 。
如下图
综合实例
用E-R图表示某个工厂物资管理的概念模型实体仓库：
仓库号、面积、电话号码零件 ：零件号、名称、规格、单价、描述供应商：供应商号、姓名、地址、电话号码、帐号项目：项目号、预算、开工日期职工：职工号、姓名、年龄、职称实体之间的联系如下：(1)一个仓库可以存放多种零件，一种零件可以存放在多个仓库中。仓库和零件具有多对多的联系。用库存量来表示某种零件在某个仓库中的数量。(2)一个仓库有多个职工当仓库保管员，一个职工只能在一个仓库工作，仓库和职工之间是一对多的联系。(3)职工之间具有领导-被领导关系，即仓库主任领导若干保管员。职工实体型中具有一对多的联系(4)供应商、项目和零件三者之间具有多对多的联系
根据上述关系和属性可以得出如下的联系图
实现起来很简单
- 先把所有实体之间的联系写出
- 再把实体的属性以及联系的属性写上即可
5.2.2 概念结构设计的方法与局部视图设计
设计分E-R图的步骤：
- 选择局部应用
- 逐一设计分E-R图
举个例子一下就懂
某学院“教学管理”数据库模型的设计
系和教师关系：①该学院下设四个系：管理工程系、会计系、市场营销系和信息管理系。每个系有一个系主任主管该系工作。②该学院聘请了一定数量的专职教师，分配到各系。学生和课程关系：①学院每年招收新生，分配到各个系。②学院制定了教学计划，设置多项课程。③学生根据每个系的专业要求，每年学习多门课程，每门课程则被多个学生选读。学生必须参加考试，获取成绩。教师与课程关系：一个教师可以上多门课程；一门课程可以由多个教师讲授。教师讲授任务完成后将被学生与院方评估。
注意：这里的模型设计只给出了关系但是没有给出实体对应的属性。 所以需要我们自己给出相应的实体对应的属性 如下：
- 先设计系和教师之间的关系视图
其中带有下划线的属性，被称作为主关键词
- 同理再设计学生与课程的关系视图
- 最后是教师与课程关系的视图
- 三张图结合在一起并将同名的实体可得
注意：这里为了清晰把实体的属性去除了，实际画图的过程中需要写上实体的属性。
5.2.3 视图的集成
采用上述方法，将模型分块使用ER方法，由于各个局部应用所面向的问题不同，且由不同的设计人员进行设计，那么各个分E-R图之间必定会存在许多不一致的地方，也就是说会产生冲突。
冲突的种类
- 属性冲突
两类属性冲突：
- 属性域冲突：属性值的类型、取值范围或取值集合不同。
- 属性取值单位冲突。
第一种冲突：比如学号可以定义为整形，也可以定义为字符型 第二种冲突：身高的单位可以是m，也可以是cm 解决方法：讨论协商。
- 命名冲突
两类命名冲突
同名异义：不同意义的对象在不同的局部应用中具有相同的名字
例:局部应用A中将教室称为房间 局部应用B中将学生宿舍称为房间
异名同义（一义多名）：同一意义的对象在不同的局部应用中具有不同的名字
例:有的部门把教科书称为课本
有的部门则把教科书称为教材
解决方法：协商讨论
- 结构冲突
三类结构冲突
同一对象在不同应用中具有不同的抽象
例:“课程”在某一局部应用中被当作实体 在另一局部应用中则被当作属性 解决方法：通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象。
同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。
例如：学生实体在局部A中有属性学号、性别、年龄属性。 在局部B中只有学号，选课号，成绩属性。 产生原因：不同的局部应用关心的是该实体的不同侧面。 解决方法：使该实体的属性取各分E-R图中属性的并集，再适当设计属性的次序。 就比如上面那个例子学生的属性为：学号、性别、年龄、选课号、成绩
同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。
产生原因：不同的局部应用关心的是该实体的不同侧面。 解决方法：使该实体的属性取各分E-R图中属性的并集，再适当设计属性的次序。 这个了解即可
修改与重构
消除冗余的方法
- 分析方法：
- 以数据字典和数据流图为依据
- 根据数据字典中关于数据项之间的逻辑关系的说明来消除冗余。
举个例子：如下图所示
标红的地方可以看出，产品和材料之间的联系，可以由零件消耗材料和零件构成产品推导出来，所以产品使用材料的关系可以去除。
同时材料的存放量Q4也是冗余的，因为可以由每个仓库的存放*仓库的总数得出。
- 规范化理论：
- 函数依赖的概念提供了消除冗余联系的形式化工具
方法：
- 确定分E-R图实体之间的数据依赖 ，并用实体码之间的函数依赖表示。集合为FL
- 求FL的最小覆盖GL，差集为D = FL-GL。逐一考察D中的函数依赖，确定是否是冗余的联系（具体要看实际情况），若是，就把它去掉。
(1) 冗余的联系一定在D中，而D中的联系不一定是冗余的； (2) 当实体之间存在多种联系时要将实体之间的联系在形式上加以区分。
举个例子：
这里不难看出实体之间可以存在多种联系
首先这里的职工其实是两种的
- 部门经理
- 下属工作人员
不难得出其中包含了两种函数依赖
- 职工号->部门号（针对下属工作人员）（多对一的关系）
- 职工号->部门号，部门号->职工号(针对部门经理）（一对一的关系）
所以根据两个关系可以得出函数依赖F**L**={职工号->部门号，职工号->部门号，部门号->职工号}
最小函数依赖G**L**={职工号->部门号，部门号->职工号}
D={职工号->部门号}
考察D中的函数依赖发现这个函数依赖并不是冗余的，因为函数依赖对应的实体联系不同，并且不能用其他函数依赖间接表示。
最后来一个综合实例
下面已经给出了三个视图，请将三个视图集成。
- 首先要消除冲突
红框内三个实体表示的是同一个含义，所以这里统一名称为产品
- 去除冗余数据和关系
篮框之中的关系是冗余的，因为仓库属于一个部门，所以仓库和职工的关系被部门和职工的关系包含了。 绿框之中职工与职工的领导关系可以归并到职工和部门的关系之中，如下图所示。
上面就是三张视图的集成
小结
5.2.4 逻辑结构的设计
重点：设置逻辑结构的时候根据数据库类型来设计数据模型。 比如关系数据库就设计关系数据模型
E-R图向关系模型的转换
转换内容
将E-R图转换为关系模型：
将实体、实体的属性转换为关系模式。（直接转）
实体的关键词转换为关系的主码 关系名转换为关系的表名 实体属性转换为关系的属性
实体之间的联系转换为关系模式。（多种策略）
实体之间的联系有下面不同的情况
(1)一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
这里不建议转换为一个独立的关系模式，因为这样会导致表过多，数据库性能下降。
- 转换为一个独立的关系模式
- 与某一端实体对应的关系模式合并
例如：下图中领导这一层关系，是针对经理的，所以在部门的属性里面增加经理的职工号这一属性
部门（部门号，部门名，经理的职工号）
或者在职工的属性里面增加领导的部门号这一属性 职工（职工号，职工名，领导的部门号）
这样的的话就无需额外创立一个部门与经理的关系表。
(2)一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
举个例子：还是这张图
属于这个关系可以归并到n端，也就是职工实体中，在职工实体中加入属性部门号
职工（职工号，职工名，部门号，职工名）
(3) 一个m:n联系转换为一个关系模式。
例如，“选修”联系是一个m:n联系，可以将它转换为如下关系模式
其中学号与课程号为关系的组合码： 选修（学号，课程号，成绩）
注意：这里的关系表的名字就是原图中关系的名字。
(4)三个或三个以上实体间的一个多元联系转换为一个关系模式。
例，“讲授”联系是一个三元联系，可以将它转换为如下关系模式
其中课程号、职工号和书号为关系的组合码： 讲授（课程号，职工号，书号）
(5)具有相同码的关系模式可合并
这个比较简单就不举例子了。
来看一到综合实例 ：根据下面的E-R图写出关系模式
- 首先写出实体的关系模式
把三个实体转化成一张关系表
- 接着看两个关系
一个是1：m，还有一个是m：n，根据上面的方法可以化成如下关系模式：
属于这个关系中，把队编号添加到多端也就是队员中 比赛这个关系是多对多的关系，所以单独成一个表，名字就是比赛，属性是两个关键词：姓名，项目名
数据模型的优化
方法：
- 确定数据依赖
- 消除冗余的联系
- 确定所属范式
- 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适
一般来说吧一个关系分解到三范式就够了。
水平分解
什么是水平分解
把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率
水平分解的适用范围:
- 满足“80/20原则”的应用
- 并发事务经常存取不相交的数据
80/20原则就是，20%及以下的数据被高频访问，剩下80%及以上的数据是低频访问 所以我们把20的数据单独做一个表，80的也做一个表
例如：
学生表中有毕业学生和在校本科生，在校生的访问频率肯定比毕业生高，所以我们单独把在校本科生单独做一张表。
垂直分解
什么是垂直分解
把关系模式R的属性分解为若干子集合，形成若干子关系模式
垂直分解的适用范围
取决于分解后R上的所有事务的总效率是否得到了提高
例如：Student(sno, name, classno, dept, sex, birth, address, phone, email, roomNo )
由于前五个属性经常被访问，所以这里把前五个属性提出来单独作为一个表。
设计用户子模式
设计数据库表的时候需要考虑针对用户的模式设计
包括三个方面：
(1) 使用更符合用户习惯的别名
(2) 针对不同级别的用户定义不同的View ，以满足系统对安全性的要求。
(3) 简化用户对系统的使用
例如：
关系模式产品（产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级），可以在产品关系上建立两个视图：
为一般顾客建立视图：
产品1（产品号，产品名，规格，单价）
为产品销售部门建立视图：
产品2（产品号，产品名，规格，单价，车间，生产负责人）
- 顾客视图中只包含允许顾客查询的属性
- 销售部门视图中只包含允许销售部门查询的属性
- 生产领导部门则可以查询全部产品数据
- 可以防止用户非法访问不允许他们查询的数据，保证系统的安全性
5.2.5 数据库的物理设计
两个指标：
- 空间效率
- 时间效率
一般来讲时间效率更重要
存取方法和选择
建立索引表
左侧是已经建立索引，右侧没有。
对比一下在7000w条数据下查找数据的的差距
记录组织
文件中组织记录的常用方法有：堆文件组织、顺序文件组织、多表聚集文件组织、B+树文件组织和散列（hashing）文件组织等。
这里只需要知道前三种即可。
- 堆文件组织
简单的来讲就是有内存就在空内存里面存储数据。
所以这种组织在存储数据的时候十分快速。
缺点就是难以查找，因为存储的数据都是无序的。
- 顺序文件组织
简单的来讲就是按照某一顺序进行数据的存储。
例如学生表按照姓名或者学号排序之类。
优点很明显就是查询数据很快，但是存储数据性能较低。
- 多表聚集文件组织
多表聚集文件组织是一种在每一个块中存储两个或多个关系的相关记录的文件结构。
为什么会有多表聚集文件？
两个关系中作连接运算时，最坏的情况下，每个相匹配的记录都处在不同的磁盘块中，这将导致为获取所需的每一条记录都要读取一个磁盘块。
举个例子：
这样做的目的是为了方便多表连接的查询
顺序索引
几个基本概念
首先要知道的索引是通过指针把索引表和主表连接起来的。
- 主索引（聚集索引）
如果索引文件中的记录按照某个搜索码值指定的顺序物理存储，那么该搜索码对应的索引就称为主索引
简单来说文件表按照哪一个属性排序，哪个属性的索引就是主索引
举个例子：
右边的表是按照姓名的拼音顺序排列，左边索引也是，所以左边的索引是一个主索引
- 辅助索引（非聚集索引）
与此相反，搜索码值顺序与索引文件中记录的物理顺序不同的那些索引称为辅助索引(secondary index)
就是不是搜索码的索引。 例如在上图中用学号作为索引
由于辅助索引对应每一个值，在主表中可能有多条记录（详情看下图），所以辅助索引一般用的是指针桶
比如上图中名字叫王红的记录就有两条，那么王红的索引也有两条。 注意：辅助索引不能是稀疏索引，也不能在辅助索引上面建立稀疏索引 稀疏索引的概念后面会讲到
- 稠密索引
稠密索引。对应索引文件中搜索码的每一个值在索引中都有一个索引记录(或称为索引项)。
如下图所示
- 稀疏索引
稀疏索引只为索引文件中搜索码的某些值建立索引记录(或称为索引项)。
如下图所示
这里需要讲一下稀疏索引的原理：
稀疏索引表中的每个索引可以查询到一行或者多行数据
比如李宏冰的索引可以查询前三行（1-3行）刘方晨的索引可以查询第四行(4行）王红的索引可以查询后三行(5-7行)
在索引表中的数据可以通过指针直接查询到。
比如李宏冰直接查询到自己的数据李小勇就需要通过李宏冰，先查询到李宏冰的数据，对比发现不符合再往下查询，直到符合。
为什么会产生稀疏索引？（了解即可） 因为数据量很大的时候，稠密索引的文件也会很大，所以不能一次存入主存中，这样就需要不断频繁访问磁盘，这样效率就很低，所以需要建立稀疏索引。 但有的时候稀疏索引的文件还是很大，下面就引入了多级索引 也就是给索引建立索引
- 多级索引
若有收获，就点个赞吧
0 人点赞
