第7章 数据库设计
目录
7.1 数据库设计概述
7.1.1 数据库设计的特点
7.1.2 数据库设计方法
7.1.3 数据库设计的基本步骤
7.1.4 数据库设计过程中的各级模式
7.2 需求分析
7.2.1 需求分析的任务
7.2.2 需求分析的方法
7.2.3 数据字典
7.3 概念结构设计
7.3.1 概念模型
7.3.2 E-R模型
1.实体之间的联系
2.E-R图
3.一个实例
*7.3.3 扩展的E-R图
*7.3.4 UML
7.3.5 概念结构设计
7.4 逻辑结构设计
7.4.1 E-R图向关系模式的转换
7.4.2 数据模型的优化
7.4.3 设计用户子模式
7.5 物理结构设计
7.5.1 数据库物理设计的内容和方法
7.5.2 关系模式存取方法选择
7.5.3 确定数据库的存储位置
7.5.4 评价物理结构
7.6 数据库的实施和维护
7.6.1 数据的载入和应用程序的调试
7.6.2 数据库的试运行
7.6.3 数据库的运行和维护
7.7 小结
7.1 数据库设计概述
1.数据库设计定义
数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之可以有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。
2.信息管理要求
在数据库中应该存储和管理哪些数据对象。
ps：
数据对象：比如说 数据表、视图、索引、里面实际的数据等。
3.数据操作要求
对数据对象需要进行哪些数据操作，如查询、增、删、该、统计等操作。
4.数据库设计的目标
为用户和各种应用系统 提供一个信息基础设施 和 高效率的运行环境。
ps：
信息基础设施：要向数据库里面放信息、数据。
5.高效率的运行环境
①数据的存储效率高；
②数据存储空间的利用率高；
③数据库系统运行管理的效率高。
7.1.1 数据库设计的特点
1.数据库建设的基本规律
三分技术、七分管理、十二分基础数据。
ps：
举个例子，我们建了一个库房，这个库房用了最好的空调，最好的货架等等，用了最好的环境；但是管理库房的管理员没有做到尽职尽责，货物在存放的时候乱七八糟，那么也会使得数据库管理非常低下。
数据库在建立好了以后，它就静态的放在那个地方，而动态变化的是数据库里面存放的数据；也就是说，随着时间的变化，这些数据会不断的变化；因此，在更大的程度上，我们会把更多的精力放在数据上（收集、整理、组织、更新等等）。
管理：数据库建设项目管理 和 企业（应用部门）的业务管理。
基础结构：数据的收集、整理、组织和不断更新。
2.结构设计和行为设计相结合
ps：
结构设计：数据库是什么样的结构，应该怎样去设计它。
行为设计：这些数据怎么去处理。
换句话说，就是指数据库和应用程序 应该是同时相结合来设计的。
将 数据库设计和数据库处理设计 密切结合。
ps：
在过去中，我们通常是把 数据库的设计 和应用程序（软件）的设计 是割裂开来的。先设计软件、应用程序之后，再设计数据库。这样就会出现一个问题，在设计软件的过程当中，可能会出现有些数据、有些数据的结构 在数据库里面没有办法体现、在数据库存放的时候效率低下。
传统的软件工程：重在行为设计（说白了就是软件的开发）。忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟 数据结构设计的策略。
早期的数据库设计：重结构设计（说白了就是注重 数据库里面放哪些表、表里面放哪些数据、应该属于2NF还是3NF就可以了）。致力于数据模型和数据库建模方法研究，忽视了行为设计 对结构设计的影响。
ps：
7.1.2 数据库设计方法
大型数据库设计是涉及多学科的综合性技术，又是一项庞大的工程项目。它要求多方面的知识和技术。主要包括：
- 计算机的基础知识；
- 软件工程的原理和方法；
- 程序设计的方法和技巧；
- 数据库的基本知识；
- 数据库设计技术；
- 应用领域的知识。
（1）手工与经验结合的方法
存在的问题：
- 设计质量与设计人员的经验和水平有直接关系。
- 缺乏科学理论和工程方法的支持，工程的质量难以保证。
- 数据库运行一段时间后常常有不同程度的发现各种问题，增加了维护代价。
（2）规范设计法
①基本思想：过程迭代和逐步求精
②典型方法
- 新奥尔良方法
- 基于E-R模型的数据库设计方法
- 3NF的设计方法
- 面向对象的数据库设计方法
- 统一建模语言（UML）方法
ps：
新奥尔良方法：把数据库的设计分成4个阶段，需求分析（用户的需求）、概念设计（根据需求设计数据库大致长什么样）、逻辑设计（把概念设计的转换成实际的数据库）、物理设计（存储在什么位置、用什么样的方式来存）。
面向对象的数据库设计方法：把现实中存在的一个物体作为源头来进行设计的。
7.1.3 数据库设计的基本步骤
一、数据库设计分6个阶段
需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行和维护。
ps：
前面四个就是 新奥尔良方法。
【分析】
- 需求分析：要了解建立数据库的需求，想要把数据库建立成什么样。
- 概念结构设计：根据想要的要求，把数据库应该设计成什么样，用E-R图、UML语言等方法把数据库描述出来。
- 逻辑结构设计：描述出来以后，就把它转换成为实际的数据库。
- 物理逻辑设计：怎么去存储数据库，放在硬盘里以何种方式存放。
- 数据库实施：数据库建好了以后就开始用数据库。
- 数据库运行和维护：在用数据库的过程中，要进行运行与维护。
【说明】
- 需求分析和概念设计独立与任何数据库管理系统（相当于比如说 打字，用记事本可以、用WPS也可以、用word也可以，它是独立于这个软件的；这两个阶段到最后是用的哪一种关系都无所谓的）。
- 逻辑设计和物理设计与选用的数据库管理系统密切相关（对数据库的设计不同的软件对应的方法是不一样的）。
ps：
数据库设计的6个阶段不是直接就下来的。比如说 到了数据库实施的阶段，发现了一些小错误需要改正，那么要重新修改数据库，又要回到逻辑结构设计部分，就是说 它们相互之间还是有穿插的。
二、参加数据库设计的人员
1.系统分析人员和数据库设计人员：自始至终参与数据库设计，其水平决定了数据库系统的质量。
2.数据库管理员和用户代表：要参加需求分析和数据库的运行与维护。
3.应用开发人员：包括程序员和操作员，在实施阶段参与进来，分别负责编制程序和准备实施软硬件环境。
三、各阶段的主要任务
1.需求分析阶段：了解客户需求，该阶段是否做得充分与准确，决定了构建数据库的速度和质量。
2.概念结构设计阶段：对用户需求进行综合、归纳与抽象，形成一个独立于 具体 数据库管理系统的概念模型（E-R图之类的）。
3.逻辑结构设计阶段：将概念结构转化为 数据库管理系统 所支持的数据模型，并对其进行优化。
4.物理结构设计阶段：逻辑数据结构 选取一个最适合 应用环境的物理结构，包括存储结构和存取方法。
5.数据库实施阶段：根据逻辑设计和物理设计的结果构建数据库，编写与调试应用程序，组织数据入库 并进行试运行。
6.数据库运行和维护阶段：经过试运行后 即可投入正式运行，在运行过程中 必须不断对其进行评估、调整与修改。
【说明】
- 设计一个完善的数据库应用系统 往往是上述6各阶段的不断反复与迭代。
- 设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程（同步进行的）。
- 把数据库的设计和数据处理的设计紧密结合，将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行（软件开发和数据库的设计是同步进行的）。
四、各个阶段的数据设计描述
【简要说明】
1.需求分析阶段
综合各个用户的应用需求。
2.概念设计阶段
独立于机器特点，独立于各个数据库管理系统产品的概念模式（E-R图）。
3.逻辑设计阶段
首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。
然后根据用户处理的需求、安全性的考虑，在基本表的基础上，再建立必要的视图，形成数据的外模式。
4.物理设计阶段
根据数据库管理系统特点和处理的需要，进行存储的安排，建立索引，形成数据库内模式。
7.1.4 数据库设计过程中的各级模式
ps：
外模式：从应用程序的角度来看，数据库给其提供的是什么表，通常可以用视图来展示。
模式：最终的这个表在数据库里面是怎样来存的。
内模式：数据表在计算机硬盘里面怎么来存的。
7.2 需求分析
ps：
核心思想：如何准确地、充分地了解到甲方的需求。
7.2.1 需求分析的任务
- 详细调查现实世界要处理的对象、实体（组织、部门、企业、个人、领导、不同的角色等）。
- 充分了解原系统（手工系统或计算机系统）工作概况。
- 明确用户的需求。
- 确定新系统的功能，新系统必须充分考虑今后可能的扩充和改变。
ps：
2.如果是对原来的系统进行更新、重建，那么需要了解原来的系统有哪些数据，结构是什么样的；如果原来是纯手工的业务流程，或者是纯手工的数据存储的方式，那么也需要了解它的工作过程。当然还需要知道原有的系统有哪些不足的地方，还要与甲方进行沟通等。
【说明】需求分析调查的重点是 “数据” 和 “处理” ，获得用户对数据库在信息、处理、安全性与完整性的要求。
7.2.2 需求分析的方法
需求分析的目的：调查清楚用户的实际需求 并进行初步分析，最终与用户达成共识。
调查用户需求的步骤：
- 调查组织机构情况。
- 调查各部门的业务活动情况。
- 协助用户明确对新系统的各种要求，包括信息要求、处理要求、安全性与完整性要求。
- 确定新系统的边界。
ps：
1.可能涉及到数据的流向。
4.就是说各个表、模块 之间应该怎么去做，就可以开始设计数据库了。
常用的调查方法：
- 跟班作业。通过亲身参加业务工作了解业务活动的情况（这个方法的缺点就是太费时间了）。
- 开调研会。通过与用户座谈来了解业务活动情况及用户需求。
- 请专人介绍。
- 询问：对某些调查中的问题，可以找专人询问。
- 设计调查表请用户填写。调查表设计合理，则很有效。
- 查阅记录。查阅于原系统有关的数据记录。
结构化分析方法（简称SA方法），SA方法从最上层的 系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。
7.2.3 数据字典
ps：
数据字典就相当于新华字典一样，只不过新华字典解释的是每一个汉字，而数据字典解释的是每一个数据（每一个数据具有哪些属性，应该进行哪些操作），我们再建数据库的时候就要对照着数据字典，把每一个数据项和每一个要求都要给它实现。
数据字典 是关于数据库中数据的描述，即元数据，不是数据本身。数据字典是在需求分析阶段建立，是进行详细的数据收集和数据分析所获得的，并在数据库设计过程中不断修改、充实、完善。
ps：
元数据：不是数据本身，并不是说，假如 存的是张三，学号是001，并不是存这些信息；而是描述出学生的学号应该是三位的数字，最多是999，最少是001开始......元数据就是对它的属性的一个描述。
数据字典的内容：数据项、数据结构、数据流、数据存储、处理过程。
ps：
数据结构：这个数据的结构是什么样的，就是一个纯数字，还是 数字+字符 构成的。
数据流：数据的流向，是从部门A流向部门B......
数据存储：在计算机当中，是以二维表的形式存储，还是以B+树这样的数据结构来存储，还是以链式结构来存储等。
处理过程：在数据库当中需要对哪些数据进行处理，查询、删除等，这些处理可以被哪些用户所拥有。
当我们把数据字典设计好了以后，就相当于把一座大楼的设计图设计好了，剩下的就是按照设计图来建造大楼了，只不过在建的过程中有哪些地方需要更新的，有哪些地方需要修改的 等微小的地方进行修改就可以了。数据字典 就相当于 把整个数据库给规划出来了。
（1）数据项：数据项是不可再分的数据单位
数据项描述 = { 数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系 }
ps：
举个例子：
设置学生的学号（Student表）={Sno，记录学生的学号，在别的表里面他就叫 “学号”，字符型，3，001~999，001表示学号是001，SC（Sno，Cno）中外码的逻辑关系，函数依赖}。
【说明】
- “取值范围”、“与其他数据项的逻辑关系”定义了完整性约束条件（用户自定义、参照完整性），是设计数据检验功能的依据。
- 可以用关系规范化理论为指导，用数据依赖的 概念分析 和 表示 数据项之间的联系。
（2）数据结构：数据结构反映了数据之间的组合关系。
数据结构描述={ 数据结构名，含义说明，组成：{数据项或数据结构 } }
【说明】
一个数据结构可以由若干个数据项组成，也可由若干个数据结构组成，或由若干个数据项和数据结构混合组成。
（3）数据流：是数据结构在系统内传输的路径。
ps：
数据项是最小不可再分的单位，由数据项又构成了数据结构，那其实在业务流程里面，通常传输的不是单个数据，而是数据结构。
比如说 在学生的管理系统里面，想要给学生录入考试成绩，那传递给系统的需要 学生的学号，学生的选课等。那么{学生的学号，学生的选课}就是数据结构，数据结构就是由这两个数据项构成。
比如说 仓库管理员存一个物品，那么会添一个入库单，那么就可以把这个入库单看成数据结构，这个入库单上有好多信息（名字、单价、材质等），这个数据结构是由多个数据向来构成的。
数据流描述={ 数据流名，说明，数据流来源，数据流去向，组成{数据结构}，平均流量，高峰期流量 }
ps：
比如说 查学生的期末考试成绩。
在数据库里面，可以从学生的选课表里面，抽取出来，反馈给用户。
{成绩，用于显示学生XX课程的期末考试成绩，SC表，视图/应用程序，学生学号、学生姓名、学生成绩，平均有多少人次查询，高峰期有多少人次查询 } 。
【说明】
- 数据流来源：说明该数据流来在哪个过程。
- 数据流去向：说明该数据流将到哪个过程去。
- 平均流量：在单位时间（每天、每周、每月等）里的传输次数。
- 高峰期流量：在高峰时期的数据流量。
（4）数据存储：数据结构停留或保存的地方，也是数据流的来源和去向之一。
数据存储描述={ 数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式 }
【说明】
- 存取频度：每小时、每天或每周的存取次数，每次存取的数据量等信息。
- 存取方法：批处理/联机处理；检索/更新；顺序检索/随机检索。
- 输入的数据流：数据来源。
- 输出的数据流：数据去向。
（5）处理过程：处理过程的具体处理逻辑 一般用判定表或判定树来描述。数据字典中只需要描述 处理过程的说明性信息。
ps：
判定表：一张表；判定树：一棵树；
举个例子：
处理过程描述={处理过程名，说明，输入:{数据流}，输出：{数据流}，处理{简要说明} }
【说明】“简要说明”说明该处理过程的功能 及处理要求。其中功能是指该处理过程用来作什么。处理要求是指处理频度要求，如单位时间里处理多少事务、多少数据量、响应时间要求等。
需求分析小结
（1）需求分析和分析 作为数据库设计的第一阶段 是十分重要的。
（2）第一阶段收集的基础数据（用数据字典来表达）是下一步进行概念设计的基础。
（3）强调两点
- 设计人员应充分考虑到 可能的扩充和改变，使设计易于更改，系统易于扩充。
- 必须强调用户的参与。
7.3 概念结构设计
ps：
我们知道了需求分析，了解了需求以后，就需要数据库的设计人员 把现实生活当中的需求 抽象成我们的E-R图，这样我们拿着E-R图就可以非常好的捋顺各个业务、各个实体、各个数据整体之间的一个关系了。
7.3.1 概念模型
概念结构设计 是将需求分析 得到的用户需求 抽象为信息结构（即概念模型）的过程。
ps：
比如说 E-R图，比如说 UML。
概念模型的特点：
- 能真实、充分的反映世界，是现实世界的一个真实模型。
- 易于理解，可以用它和不熟悉计算机的用户交换意见（比如说 把E-R图拿给甲方的客户经理或部门主管看一下 这个部门的数据是不是像E-R图所描述的那样）。
- 易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
- 易于向关系、网状、层次的各种数据模型转换。
概念模型的描述工具：E-R图。
7.3.2 E-R模型
E-R模型 是用E-R图 来描述现实世界的概念模型。第一章 1.2.2节已经简单介绍实体、属性、实体之间的联系等。
1.实体之间的联系
（1）两个实体型之间的联系
一对一联系（1：1）、一对多联系（1：n）、多对多联系（m:n）。
①一对一联系（1:1）
如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1:1。
【例】学校里一个班级只有一个正班长，而一个班长只在一个班中任职，则班级与班长之间具有一对一联系。
②一对多联系（1：n）
如果对于实体集A中的每一个实体，实体集B中有n个实体（n>=0）与之联系；反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1：n。
ps：
记得多怕搞晕了吧，看我一个图解决此类问题：
A是1，B是n；若a：b=1：n并且当b=1时，则a=1/n。而1/n∈整数，至多为1。
【例】一个班级中由若干个学生，而每个学生只在一个班级中学习 ，则班级与学生之间局有一对多联系。
③多对多联系
如果对于实体集A中的每一个实体，实体集B中有n个实体（n>=0）与之联系；反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m>=0）与之联系，则实体集A与实体集B具有多对多联系，记为m:n。
ps：
这个没啥数学计算规律的，就直接记吧。
把A看做m,把B看做n；然后对于A中的每一个实体，就把A（m）看成1，B中有n个实体与之对应；相反，对于B中的每一个实体，就把B（n）看做1，A中有m个实体与之对应；然后A与B的关系是m:n，这个是记m与n的对应关系。
但是一般来说，不会考这么细，那么就可以直接这样记更好:
A与B、B与A之间都是一对多联系。
【例】一门课程同时有若干个学生选修，而一个学生可以同时选修多门课程，则课程与学生具有多对多联系。
两个实体之间的三类联系：
（2）两个以上的实体型之间的联系
一般地，两个以上的实体之间也存在着一对一、一对多、多对多联系。
【例】对于课程、教师、参考书3个实体型，如果一门课程可以由若干个教师讲授，使用若干本参考书，而每一个教师只讲授一门课程，每一本参考书只供一门课程使用，则课程与教师、参考书之间的联系是一对多的。
【例】有三个实体型：供应商、项目、零件，一个供应商可以供给多个项目多个零件，而每个项目可以使用多个供应商供应的零件，每种零件可由不同供应商供给，由此看出供应商、项目、零件三者之间是多对多的联系。
三个实体型之间的联系示例
（3）单个实体型内的联系
同一个实体集内的各实体之间 也可以存在一对一、一对多、多对多的联系。
【例】职工实体型内部 具有领导与被领导的联系，即某一职工（干部）“领导”若干名职工，而一个职工仅被另外一个职工直接领导，因此这是一对多的联系。
ps：
联系的度：参与联系的实体型的数目。
2个实体型之间的联系度为2，也称二元联系；
3个实体型之间的联系度为3，也称三元联系；
N个实体型之间的联系度为N，也称N元联系。
2.E-R图
E-R图提供了表示实体型、属性和联系的方法。
实体型：用矩形表示，矩形框内写明实体名。
属性：用椭圆表示，并用无向边将其与相应的实体型连接起来。
联系：用菱形来表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1:1，1：n，m：n）。联系也可以具有属性。
【例】学生实体具有学号、姓名、性别、出生年份、系、入学时间等属性，用E-R图如下。
【例】如果用“供应量”来描述联系“供应”的属性，表示某供应商供应了 多少数量的零件给某个项目，那么这三个实体及其之间联系的E-R图如下。
3.一个实例
下面用E-R图表示某个工厂物资管理的概念模型。
（1）物资管理涉及的实体有：
仓库：属性有 仓库号、面积、电话号码；
零件：属性有 零件号、名称、规格、单价、描述；
供应商：属性有 供应商号、姓名、地址、电话号码、账号；
项目：属性有 项目号、预算、开工日期；
职工：属性有 职工号、姓名、年龄、职称。
（2）这些实体之间的联系如下：
仓库和零件具有多对多的联系。一个仓库可以存放多种零件，一个零件可以存放在多个仓库中，用库存量来表示某种零件在某个仓库中的数量。
仓库和职工之间是一对多的联系。一个仓库有多个职工当仓库保管员，一个职工只能在一个仓库工作。
职工之间具有领导与被领导关系。即仓库主任领导若干保管员，因此职工实体型具有一对多的联系。
供应商、项目和零件三者具有多对多的联系。即一个供应商可以供给若干项目多种零件，每个项目可以使用不同供应商供应的零件，每种零件可由不同供应商供给。
（3）E-R图
*7.3.3 扩展的E-R图
E-R模型得到了广泛的应用，人们在基本E-R模型的基础上进行了某些方面的扩展，使其表示现实的能力更强。
1.ISA联系
ps：
在 “一对一联系”“一对多联系”“多对多联系”之后，又增加了“ISA联系”。
用E-R方法构建一个项目的模型时，经常会遇到某些实体型是某个实体型的子集。例如，研究生和本科生是学生的子类，学生是父类。这种 父类-子类 的联系称为ISA联系，表示“is a”的语义，如下图，研究生 is a 学生，本科生 is a 学生。ISA联系用三角形来表示。
【说明】ISA联系描述了一个实体型中实体的一种分类方法其一个重要的性质是子类继承了父类的所有属性，同时子类也可有自己的属性。
ps：
研究生除了有学生的所有属性，还有自己的属性——导师姓名、研究方向。
（1）分类属性
根据分类属性的值 把父实体型中的实体 分派到子实体中。
【例】下图中在ISA联系符号三角形的右边加一个分类属性“学生类别”，说明一个学生是研究生还是本科生由“学生类别”这个属性决定。
（2）不相交约束 与 可重叠约束
不相交约束：父类中的一个实体 不能同时属于 多个子类中的实体集，即一个父类中的实体最多属于一个子类实体集。用ISA联系三角形符号内加一个“X”来表示。
ps：
比如说 上述中 学生这个父实体分为了研究生和本科生这两个子实体，而一个学生不可能既是研究生又是本科生；只能要不是研究生，要不是本科生；这种情况叫做 不相交约束。
可重叠约束：父类中的一个实体 能同时属于多个子类中的实体集，三角形符号中没有“X”来表示。
（3）完备性约束
完备性约束：描述父类中一个实体是否必须是某一个子类中的实体。如果是，则为是完全特化。否则为部分特化。
ps：
也就是说，是不是学生这个实体 必须要分 研究生、必须要分本科生，还是说，这个实体不属于研究生和本科生当中的任何一个。如果必须要分研究生和本科生，没有其他的选项了，那么就叫做完全特化，用双线来连接；否则就叫做部分特化（也就是说，父类中只有一部分符合下面的子类），用单线来连接。
完全特化用双线来连接，部分特化用单线来连接。
2.基数约束
是对实体之间一对一、一对多和多对多联系的细化。约束用一数对min..max表示，0<=min<=max。
ps：
这个“多”到底是多多少，我们并没有给它细化，那么在设计数据库的时候，对其完备性约束会缺失（到底是最多不会超过30个，还是多少）。
而基数函数就是对这个“多”来进行细化。
【例】0..1、1..3、1..*（*代表无穷大）
min=1的约束叫做强制参与约束，即 被施加基数约束的实体型中的每个实体都要参与联系。
min=0的约束叫做非强制参与约束，即 被施加基数约束的实体型中的可以出现在联系中，也可以不出现在联系中。
【例】学生和学生证联系中，一个学生必须拥有一本学生证，一本学生证只能属于一个学生，因此都是1..1。
【例】学生和课程联系中，假设学生实体型的基数约束是20..30，课程的一个合理的基数约束是0..*。
ps：
学生旁边的0..*是对课程的约束；课程旁边的20..30是对学生的约束。
【例】班级和学生联系中，一个学生必须参加一个班，并只能参加一个班，因此1..1，一个班级最少30个学生，最多40个学生，因此是30..40。
3.Part-of联系
即部分联系，表明某个实体型是另外一个实体型的一部分。
【例】汽车和轮子是两个实体型，汽车是轮子的一部分，即Part-of实体型。
ps：
需要区分的是，ISA是属于实体与实体都属于某一类（如研究生与本科生都属于学生）；而Part-of是组成的关系。如果说，汽车又分为吉普车、商用车等，那么就是ISA的联系。
Part-of联系的分类：
（1）非独占的Part-of联系：整体实体如果被破坏，部分实体仍然可以独立存在。非独占的Part-of联系可以通过基数约束来表达。
【例】汽车实体型和轮子实体型之间，汽车车体被毁坏了，轮子还存在，可以拆下来独立使用。具体如下图：
（2）独占的Part-of联系:实体如果被破坏，部分实体不能存在。在E-R图中用弱实体类型和识别联系来表示独占联系。
如果一个实体型的存在依赖于其他实体型的存在，则这个实体型叫做弱实体型，否则叫做强实体型。
判断方法：如果不能从一个实体型属性中找出可以作为码的属性，这个实体型是弱实体型。
在E-R图中用双矩形表示弱实体型，用双菱形表示识别联系。
【例】用户从银行贷款购房，这笔贷款一次贷出，分期归还。还款就是一个弱实体，因为它只有还款序号、日期和金额三个属性，第一笔还款的序号为1，第二笔还款的序号为2，第三笔还款的序号为3，这些属性的组合都不能作为还款的码。还款的存在必须依赖于贷款实体。
【例】房间和楼房的联系。每座楼都有唯一的编号或名称，每个房间都有编号，如果房间号不包含楼号，则房间号不能作为码，所以房间是个弱实体。
*7.3.4 UML
UML是统一建模语言或标准建模语言，是始于1997年一个QMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括需求分析到规格，到构造和配置。也可以作为表示E-R图的一种方法。
UML表示E-R图的说明：
- 实体型：用类表示，矩形框上部写实体名，下面列出属性名。
- 实体的码：在类图中属性后面加“PK”。
- 联系：上面用类图之间的“关联”来表示（E-R图上面的菱形），下面要写它们的基数约束。
【例】学生、课程它们之间的联系以及基数约束的E-R图用UML表示。
ps：
当然平常还是用E-R图更多一些。
7.3.5 概念结构设计
概念设计的第一步 就是对需求分析阶段 收集到的数据 进行分类、组织，确定实体、实体属性、实体间联系类型，形成E-R图。
1.实体与属性的划分规则
为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。
两条准则：
（1）作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性（要满足1NF）。
（2）属性不能与其他实体具有联系，即E-R图中所表现的联系是实体之间的联系。
【例】职工是一个实体，职工号、姓名、年龄是职工的属性。
职工如果没有与工资、福利挂钩（支撑没有再分为工资、福利两个属性），根据准则（1）可以作为职工实体的属性。如果不同的职称有不同的工资、住房标准和不同的附加福利，则职称作为一个实体更恰当。
【例】在医院中，一个病人只能住在一个病房，病房号可以作为病人实体的一个属性；如果病房还要与医生实体发生联系，即一个医生负责几个病房的病人的医疗工作，根据准则（2）病房应作为一个实体。
【例】如果一种货物只存放在一个仓库，那么就可以把存放货物的仓库的仓库号 作为描述货物存放地点的属性。
如果一种货物可以存放在多个仓库中，或者仓库本身又用面积作为属性，或者仓库与职工发生管理上的联系，那么就应该把仓库作为一个实体。
【例】销售管理子系统E-R图的设计。
该子系统的主要功能是：
处理顾客与销售员的订单；工厂是根据货安排生产的；交出货物同时开出发票；收到顾客付款后，根据发票存根和信贷情况 进行应收款处理。
先进行E-R图如下：
参照需求分析和数据字典中的详尽描述，遵循前面给出的两个准则，进行如下调整：
- 订单与订单两个实体之间是1：n的联系。每张订单有订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照准则（2），订单就不能做订单的属性处理 而应该上升为实体。一张订单可以定若干实体。
- 原订单和产品之间的联系 实际上是 订单细节和产品的联系。每条订货细节对应一个产品描述，订单处理时从中获得当前单价、产品重量等信息。
- 增加一个“折扣规则”实体。工厂对大宗订货给予优惠。每种产品都规定了不同订货数量的折扣，应该增加一个“折扣规则”实体存放这些信息，而不应该把它们放在产品实体中。
最后得到的销售管理子系统E-R图如下 ：
对每个实体定义的属性如下：
顾客：{ 顾客号，顾客名，地址，电话，信贷情况，账目余额 }
订单：{ 订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点 }
订单细则：{ 订单号，细则号，零件号，订货数，金额 }
应收账款：{ 顾客号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额 }
产品：{ 产品号，产品名，单价，重量 }
折扣规则：{ 产品号，订货数量，折扣 }
2.E-R图的集成
E-R图的集成一般需要分两步：
第一步：合并。解决各分E-R图之间的冲突，将分E-R图合并起来生成初步E-R图。
ps：
合并的原则 以相同的实体为纽带，将其合并起来。
第二步：修改和重构。消除不必要的冗余，生成基本E-R图。
ps：
可能有重复的，也可能有冲突的（比如在这个关系中叫做学生，在那个关系叫做Student之类的）等等。
（1）合并E-R图，生成初步E-R图
各个局部应用所面向的问题不同，各个子系统的E-R图之间必定会存在许多不一致的地方，称之为冲突。
子系统E-R图之间的冲突主要有三类：属性冲突、命名冲突、结构冲突。
①属性冲突
属性域冲突，即属性值的类型、取值范围或取值集合不同。
ps：
例如：零件号，有的部门把它定义为整数，有的部门把它定义成字符型；
年龄，有些部门以出生日期形式表示职工的年龄，而另一部门用整数表示职工的年龄。
属性取值单位冲突。
ps：
例如：零件的重量有的以公斤为单位，有的以斤为单位，有的以克为单位。
②命名冲突
同名异义，即不同意义的对象 在不同的局部应用中具有相同的名字。
异名同义（一义多名），即同一意义的对象 在不同的局部应用中具有不同的名字。
ps：
比如说 在整个军校管理系统里面，可能有“班长”这个实体名，而这个“班长”可能是1班的班长，也可能是 炊事班的班长。
比如说 对科研项目，不同的部门叫法不一样，财务科称为项目，科研处称为课题，生产管理处称为工程。
命名冲突，可能发生在实体、联系一级上；也可能发生在属性一级上；通过讨论、协商等行政手段加以解决。
③结构冲突
同一对象在不同应用中具有不同的抽象（就是用不同的图例来表示的）。
ps：
例如，职工在某一局部应用中被当作实体，而在另一局部应用中被当做属性。职工在一座大厂里面被当作实体，但是如果对于大厂这个实体，可能就被当成大厂的属性了。
解决方法：把属性变换为实体 或 把实体变换为属性，使同一对象具有相同的抽象（但是如果把 属性变换为实体 可能会更可靠点） 。
同一实体在不同子系统的E-R图中包含的属性个数和属性排列次序不完全相同。
ps：
比如说 都是“学生”这一个属性，在宿舍关系的系统中学生属性可能有（床铺号，宿舍号），而在课程管理的系统中可能有（学号，课号，成绩），在学籍管理的系统中可能有（姓名，学籍，家庭住址）等。
解决方法：该实体的属性各取子系统的E-R图中属性的并集，再适当调整属性的次序。
ps：
学生（床铺号，宿舍号，学号，课号，成绩，姓名，学籍，家庭住址）
实体间的联系 在不同的E-R图中为不同的类型。
ps：
实体E1与E2在一个E-R图中是多对多联系，在另一个E-R图中是一对多联系。
解决方法：是根据应用的语义对实体联系的类型进行综合或调整。
ps：
其实吧，一对一，一对多，多对多是包含的关系，然后即可以往上面靠的设计。
【例】零件与产品之间存在多对多的联系“构成”。产品、零件和供应商三者之间还存在多对多的联系“供应”。
（2）消除不必要的冗余，设计基本E-R图
所谓冗余的数据是指 可由基本数据导出的数据，冗余的联系是指 可由其他联系导出的联系。
ps：
所谓冗余 简单的来说就是指 可以通到其他的关系或数据来导出这个关系或数据，那么就把导出来的关系或数据叫做冗余。
消除冗余主要采用分析方法，即以数据字典和数据流为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
消除冗余后的初步E-R图，称为基本E-R图。
【例】如下图，Q3=Q1×Q2，Q4=∑Q5 。所以Q3和Q4是冗余数据，可以消去。并且由于Q3消去，产品与材料间m：n也应消去（可以从 产品-零件-材料 方面导出）。
【说明】并不是所有的冗余数据与冗余联系都必须消除，有时为了提高效率，不得不以冗余信息为代价。
若果每次查询都要查询每个仓库中 此种材料的库存，在求和，就使得查询效率低下。因此应保留Q4，同时把Q4=∑Q5定义为Q4的完整性约束条件。每当Q5修改后，触发完整性检查。
用规范化理论来消除冗余：
①确定分E-R图实体间的数据依赖。
实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。
【例】如下图：
部门和职工之间 一对多的联系可表示为：职工号——>部门号。
职工和产品之间 多对多的联系可表示为：（职工号，产品号）——>工作天数等。
于是有函数依赖集Fl。
②求Fl的最小覆盖Gl，差集为D=Fl-Gl。
逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉。
注意下面两个问题：
- 冗余的联系一定在D中，而D中的联系不一定是冗余的；
- 当实体之间存在多种联系时，要将实体之间的联系在形式上加以区分。
ps：
某工厂管理信息系统的视图集成：
【注意】
集成过程中需要解决以下问题：
- 异名同义，项目和产品含义相同。
- 取消冗余联系。
7.4 逻辑结构设计
ps：
总结的来说，概念模式设计是在教我们怎么画出E-R图来；下面我们再来介绍，当E-R图合成以后，我们根据E-R图在数据库当中建立一张实际的二维表，这个就是逻辑结构设计。
逻辑结构设计的任务：把概念结构设计好的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。
7.4.1 E-R图向关系模式的转换
E-R图由实体型（矩形）、实体的属性（椭圆）和实体型之间的联系（菱形）三个要素组成。
E-R图像关系模型的转换就是将实体型、实体的属和实体型之间的联系转化为关系模式。
1.转化规则：一个实体型转换为一个关系模式。关系的属性（列）为实体的属性，关系的码为实体的码。
2.实体之间的联系有以下不同情况
（1）一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
ps：
即既可以把联系单独转化为一张表，也可以加入到另外一张表。
①转换为一个独立的关系模式（新建一张二维表，可能会冗余）
关系的属性：与该联系相连的各实体的码及联系本身的属性。
关系的候选码：每个实体的码均是该关系的候选码。
②与某一端实体对应的关系模式合并
合并后关系的属性：加入对应关系的码和联系本身的属性。
合并后关系的码：不变。
（2）一个1：n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
①转换为一个独立的关系模式
关系的属性：与该联系相连的各实体的码及联系本身的属性。
关系的候选码：n端实体的码。
②与n端对应的关系模式合并
合并后关系的属性：在n端关系中加入1端关系的码和联系本身的属性。
合并后的码：不变。
该方法可以减少系统中的关系个数，一般情况下更倾向于采用这种方法。
（3）一个m:n联系 转换为一个关系模式
关系的属性：与该联系相连的各实体的码及联系本身的属性。
关系的候选码：各实体码的组合。
【例】“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码：
选修（学号，课程号，成绩）
（4）三个或三个以上实体间的一个多元联系（多对多联系）转换为一个关系模式。
关系的属性：与该联系相连的各实体的码及联系本身的属性。
关系的候选码：各实体码的组合。
（5）具有相同码的关系模式可合并。
目的：减少系统中的关系个数。
合并方法：
第一步：将其中一个关系模式的全部属性 全部加入到另一个关系模式当中。
第二步：去掉其中的同义属性（可能同名也可能不同名）。
第三步：适当调整属性的次序。
7.4.2 数据模型的优化
数据库逻辑设计的结果不是唯一的。为了进一步提高数据库应用系统的性能，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。
优化数据模型的方法：
（1）确定数据依赖。按需求分析阶段所得到的语义，分别写出每个关系模式内部个属性值间的数据依赖以及不同关系模式属性值间的数据依赖。
（2）对于各个关系模式之间的数据依赖进行极小化处理，消除数据冗余的联系。
（3）按照数据依赖的理论 对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值函数依赖等，确定各关系模式分别属于第几范式。
（4）按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。
【说明】并不是规范化程度越高的关系就越优。
例如当查询经常涉及两个或多个关系模式的属性时，系统必须经常的进行连接运算，代价相当高，因此在这种情况下，第二范式甚至是第一范式也许是合适的。
（5）对关系模式进行必要分解，提高数据操作效率和存储空间的利用率。
常见分解方法有水平分解和垂直分解。
①水平（行）分解：把（基本）关系的元组分为若干子集合，定义每个子集合为一个子关系。
分解方法：
一是对符合80/20的，把经常使用的数据（约20%）水平分解出来，形成一个子关系。
二是使每个事物存取的数据对应一个子关系。
②垂直分解：把关系模式R的属性分解为若干子集合，形成若干子关系模式（第6章讲到过）。
分解原则：经常在一起使用的属性从R中分解出来形成一个子关系模式。
分解优点：可以提高某些事务的效率。
分解缺点：可能使另一些事务不得不执行连接操作，降低了效率。
适用范围：取决于分解后R上的所有事务的总效率是否得到了提高。
分解方法：
简单情况直观分解。
复杂情况用第6章中的模式分解算法。
垂直分解必须不损失 关系模式的语义（保持无损连接性和保持函数依赖）。
7.4.3 设计用户子模式
ps：
用户子模式指的是 数据库要给应用程序提供数据（各种管理系统就是不同的应用程序），对应的就是不同的用户，这些用户要访问数据库需要设立一个访问数据库的接口，通常使用视图、查询等等来建立对接。
定义数据库模式 主要是从 系统的时间效率、空间效率、易维护等角度出发。
定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：
（1）使用更符合用户习惯的别名
合并各分E-R图 曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。用视图机制可以在设计用户视图是重新定义某些属性名，使其与用户习惯一致，方便使用。
（2）针对不同级别的用户 定义不同的视图，以保证系统的安全性。
假设有关系模式产品（产品号，产品名，规格，单价，生产车间，生产负责人，产品成本，产品合格率，质量等级），可以在产品关系中建立两个视图：
为一般顾客建立视图：
产品1（产品号，产品名，规格，单价）
为产品销售部门建立视图：
产品2（产品号，产品名，规格，单价，车间，生产负责人）
（3）简化用户对系统的使用
如果某些局部应用中 经常要使用某些很复杂的查询，为了方便客户，可以将这些复杂查询定义为视图。
7.5 物理结构设计
ps：
物理结构设计 说白了就是 把创建出来的数据库选择一种合适的、合理的存储方式，读取的方式。
1.什么是数据库的物理设计
数据库在物理设备上的 存储结构 与 存取方法 称为数据库的物理结构，它依赖于选定的数据库管理系统（不同的数据库管理系统有不同的要求）。
为一个给定的逻辑数据模型 选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。
2.数据库物理设计的步骤
（1）确定数据库的物理结构
在关系数据库中主要存取方法和存储结构（顺序存取、链式存取等）。
（2）对物理结构进行评价
评价的重点是时间和空间效率。若评价结果满足原设计要求，则可进入到物理实施阶段；否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。
7.5.1 数据库物理设计的内容和方法
1.设计物理数据库结构的准备工作
（1）充分了解应用环境，详细分析要运行的事务以获得选择物理数据库设计所需参数。
（2）充分了解所用关系型数据库管理系统的内部特征（用的是哪些类型的数据库），特别是系统提供的存取方法和存储结构。
2.选择物理数据库设计所需参数
（1）对于数据库查询事务，需要得到以下信息：
①查询的关系。
②查询条件所涉及的属性。
③连接条件所涉及的属性。
④查询的投影属性。
（2）对于数据更新事务，需要得到以下信息：
①被更新的关系。
②每个关系上的更新操作条件所涉及的属性。
③修改操作要改变的属性值。
（3）每个事务（增删改查）在各关系上运行的频率和性能要求。
3.关系数据库物理设计的内容
为关系模式选择存取方法（建立存取路径）以及设计关系、索引等数据库文件的物理存储结构。
ps：
存取方法：怎么读取。
物理存储结构：怎么放。
7.5.2 关系模式存取方法选择
数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用需求。
物理结构设计的任务之一是 根据关系数据库系统 支持的存取方法 确定选择哪些存取方法。
数据库系统常用的存取方法：
- B+树索引存取方法。
- Hash索引存取方法。
- 聚簇存取方法。
（1）B+树存取方法的选择
选择索引存取方法 实际上就是根据应用要求确定对哪些属性列建立索引、对哪些属性列建立组合索引、对哪些索引要求设计唯一索引等。
ps：
索引：相当于一本书的目录，可以一下就找到对应存储的位置。如果没有索引的话，计算机就需要全盘检索。
选择索引存取方法的一般规则：
- 如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这组）属性上建立索引（或组合索引）。
- 如果一个属性经常作为最大值或最小值等聚焦函数的参数，则考虑在这个属性上建立索引（因为作为索引的前提会进行排序）。
- 如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或这组）属性上建立索引。
（2）Hash存取方法的选择
选择Hash存取方法的规则：如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一：
- 该关系的大小可知，而且不变。
- 该关系的大小动态改变，但所选用的数据库管理系统提供了动态Hash存取方法。
（3）聚簇存取方法的选择
聚簇是为了提高某个属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组 集中存放在连续的物理块中称为聚簇。
【说明】
- 聚簇对于某些类型的查询，可以提高查询效率。
- 在一个基本表上最多只能建立一个聚簇索引。
- 聚簇索引的适用条件，一是很少对基本表进行增删操作，二是很少对其中的变长列进行修改操作。
【例】假设学生关系按所在系建有索引，现在要查询信息系的所有学生名单。
信息系的500名学生分布在500个不同的物理块上时，至少要执行500次1/0操作。如果将同一系的学生 集中存放，则每读一个物理块可得到多个满足查询条件的元组，从而显著的减少了访问磁盘的次数。
选择聚簇存取方法：
（1）设计候选聚簇
- 常在一起进行连接操作的关系可以建立组合聚簇。
- 如果一个关系的一组属性 经常出现在相等比较条件中，则该单个关系可建立聚簇。
- 如果一个关系的一个（或一组）属性上的重复率较高，则此单个关系可建立聚簇。
（2）检查候选聚簇中的关系，取消其中不必要的关系
- 从聚簇中删除经常进行全表扫描的关系。
- 从聚簇中删除更新操作 远多于连接操作的关系。
- 从聚簇中删除重复出现的关系。当一个关系同时加入多个聚簇时，必须从这多个聚簇方案（包括不建立聚簇） 中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。
7.5.3 确定数据库的存储位置
确定数据库结构主要指 确定数据库的存放位置和存储结构。
包括：确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。
确定数据的存放位置和存储结构 要综合考虑存取时间、存储空间利用率和维护代价3个方面的因素。
1.确定数据的存放位置
根据应用情况 将易变部分与稳定部分分开存放、经常存取部分与存取频率较低部分分开存放。
【例】可以将比较大的表分别放在两个磁盘上，以加快存取进度，这在多用户环境下特别有效。
可以将日志文件与数据库对象（表、索引等）放在不同的磁盘上以改进系统的性能。
2.确定系统配置
数据库管理系统一般都提供了一些系统配置变量和存储分配参数，初始情况下，系统都为这些变量赋予了合理的缺省值，在进行物理设计时需要根据应用环境来确定这些参数值，使系统性能最佳。
7.5.4 评价物理结构
对数据库物理结构设计过程中产生的多种方案进行评价，从中选择一个较优的方案作为数据库的物理结构。
评价方法主要是定量估算各种方案的存储空间、存取时间、维护代价，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。
7.6 数据库的实施和维护
7.6.1 数据的载入和应用程序的调试
1.数据的载入
数据库建立好以后，就可以向数据库中装载数据了。组织数据入库是数据库实施阶段最主要的工作。
数据装载方法：人工方法、计算机辅助数据入库。
2.应用程序的调试
数据库应用程序的设计应该与数据设计并行进行，在组织入库的同时还要调试应用程序。
7.6.2 数据库的试运行
应用程序调试完成，并且已有一小部分数据入库后，就可以开始对数据库系统进行联合调试，也称数据库的试运行。
主要工作包括：
功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
性能测试：测量系统的性能指标，分析是否符合设计目标。
【说明】
- 数据的分期入库。
- 做好数据库的转存和恢复。
7.6.3 数据库的运行和维护
在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成。
主要工作包括：
1.数据库的转存和恢复
数据库管理员要针对不同的应用要求制定不同的转储计划，以保证一旦发生介质故障，尽快将数据库恢复到某种一致性状态。
2.数据库的安全性、完整性控制
当应用环境发生变化，对安全性的要求也会发生变化，同样数据库的完整性约束条件也会变化。
3.数据库性能的监督、分析和改进
在数据库运行过程中，数据库管理员必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。
4.数据库的重组织与重构造
（1）数据库的重组织
数据库运行一段时间后，由于记录的不断增、删、该，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据库的存储效率，使数据库的性能下降。
数据库的重组织不会改变原设计的数据逻辑结构和物理结构。
重组值的方法：按原设计要求重新安排存储位置、回收垃圾、减少指针链。
（2）数据库的重构造
数据库应用环境发生变化，会导致实体及实体间的联系也发生相应的变化，会使原有的数据库设计不能很好的满足新的需求。
数据库的重构造需根据新环境调整数据库的模式和内模式。
重构造的方法：增加或删除某些数据项、改变数据项的类型，增加或删除某个表、改变数据库的容量、增加或删除某些索引等。
若应用变化太大，已经无法通过重构数据库来满足新的需求，或重构的数据库的代价太大，应该重新设计新的数据库应用系统了。
7.7 小结
1.数据库设计的方法和步骤
2.数据库设计的6个阶段
重点是概念结构的设计和逻辑结构的设计。
3.概念结构的设计
概念结构的设计着重介绍了E-R模型的基本概念和图示方法。应重点掌握实体型、属性和联系的概念，理解实体型之间的一对一、一对多和多对多联系。掌握E-R模型的设计以及把E-R模型转换为关系模型的方法。
4.逻辑结构的设计
将概念模型转化为具体的数据模型。