1、数据库的设计第3章教学目标了解关系数据库设计的过程掌握关系数据库设计的方法掌握范式和函数依赖的概念掌握关系模式规范化设计方法3.1关系数据库设计概述通常把使用数据库的各类信息系统都称为数据库应用系统，如：网络购物系统、工资管理系统、票务系统、银行系统、人脸识别系统等。数据库设计从广义上来说，是数据库及其应用系统的设计，即设计整个数据库应用系统。从狭义上来说，是设计数据库本身，即设计数据库的各级模式并建立数据库，是数据库应用系统设计的一部分。本书讲解侧重广义的数据库设计。以网路购物系统为例讲解数据库及应用系统的设计。3.1关系数据库设计概述良好的数据库设计表现在以下几个方面：l 访问效率高，使用
2、方便，维护简单。l 数据冗余度低，存储空间小，便于进一步扩展。l 应用程序易于开发。l 基于有效安全机制的数据安全可以得到保障。l 数据的备份和恢复容易实现。低劣的数据库设计往往表现在以下几个方面：l 数据访问效率低下。l 大量的数据冗余造成存储空间浪费。l 数据的插入和删除出现异常等问题。3.1关系数据库设计概述早期的数据库设计工作，都是依赖于设计人员的自身经验，缺乏成熟的科学理论和工程方法的支持，因此设计质量难以保证，常常数据库运行一段时间后又会发现不同程度的问题，需要不断修改甚至重新设计，大大地增加了系统维护成本。经过多年来不断地探索，人们提出了各种数据库设计方法。其中，新奥尔良（New
3、 Orleans）方法是一种比较著名的数据库设计方法，它通过分步设计，遵循自顶向下、逐步求精的原则，将数据库设计过程分解为若干相互独立又相互依存的阶段，每一阶段采用不同的辅助工具，解决不同的问题，从而将问题局部化，减少局部问题对整体设计的影响。3.1.1数据库设计方法和步骤3.1关系数据库设计概述3.1.1数据库设计方法和步骤物理物理结构设计结构设计需求需求分析分析概念概念结构设计结构设计逻辑逻辑结构设计结构设计需求说明书需求说明书E-RE-R模型模型关系模型关系模型新奥尔良方法数据库设计步骤新奥尔良方法数据库设计步骤3.1关系数据库设计概述目前公认的比较权威的方法是将数据库系统设计分为6个阶
4、段：需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施和数据库运行及维护。另外，我们在相关的文献或者资料中也会看到一些其他的数据库设计方法比如：基于E-R模型的设计方法、基于3NF（第三范式）的设计方法、基于抽象语法规范的设计方法等，这些都是针对不同数据库设计阶段使用的具体技术和方法。3.1.1数据库设计方法和步骤3.1关系数据库设计概述考虑到数据库开发的全过程，按照结构化设计的方法，将数据库设计分为六个阶段。1）需求分析 收集和分析用户需求，包括数据与处理。2）概念结构设计 对用户需求进行归纳和抽象，形成概念模型（例如E-R模型）。3）逻辑结构设计 将概念模型转换为某个数据库管理
5、系统所支持的数据模型（例如关系模型），并对其进行优化。3.1.2 数据库设计过程3.1关系数据库设计概述4）物理结构设计 为数据模型选取一个最合适应用环境的物理结构（包括存储结构和存取方法）。5）数据库实施根据逻辑设计和物理设计的结果建立数据库，组织数据入库并进行试运行。6）数据库运行和维护 在数据库系统运行过程中不断地对其进行调整、评价与修改。设计一个完善的数据库系统是不可能一蹴而就的，它往往是上述六个阶段的不断反复、逐步求精的过程。3.1.2 数据库设计过程3.2 关系数据库的设计关系数据库设计主要包括需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施与维护6个阶段。每个阶段都
6、有不同的内容和任务，具体如下：3.2 关系数据库的设计需求分析是设计数据库的起点。需求分析是设计人员通过与用户交流和调查等，分析并逐步明确用户对系统的需求，包括数据需求、业务处理需求、安全性及完整性要求等。需求分析的结果是否准确将直接影响后面各个阶段的设计，并影响到设计结果是否合理和实用，因此需求分析是整个设计工作最基础也是最耗时的部分。需求分析重点是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的如下要求：1）数据要求。即用户对需要处理的数据内容及性质的要求。2）处理要求。指用户要求数据库需要具备的数据处理功能，用户对处理性能的要求。3）安全性与完整性要求。3.2.1 需求分析3
7、.2 关系数据库的设计调查用户需求的具体步骤如下：1）调查组织机构情况和各部门的业务活动情况。2）在熟悉业务活动的基础上，协助用户明确对新系统的各种要求，包括数据要求、处理要求、安全性与完整性要求。3）确定新系统的边界。基于前面的调查和分析，明确哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。3.2.1 需求分析3.2 关系数据库的设计常用调查方法如下：1）跟班作业和业务咨询。通过亲身参加业务工作或者与客户进行座谈、请专人介绍等来了解业务活动的情况。2）组织用户填写问卷调查。3）查阅记录。查阅与原系统有关的数据记录。3.2.1 需求分
8、析3.2 关系数据库的设计【例3.1】对网络购物系统进行需求分析。3.2.1 需求分析1）数据要求系统存储客户和商品的基本信息，详细记录客户的订单信息。3.2 关系数据库的设计3.2.1 需求分析2）处理要求l 客户可以查看自己的信息；可以查看不同商品信息；能够下单购买商品；可以查询自己的订单情况。l 系统能够对商品的情况进行统计；能够对订单情况进行统计。l 系统可以加入新的客户信息；加入新的商品信息。l 系统可以删除过期商品信息。l 系统可以更新订单情况。l 系统可以查询客户及商品信息；可以查询订单情况；可以对商品和客户的购买情况进行分类统计。3.2 关系数据库的设计3.2.1需求分析3）数
9、据库安全性与完整性需求。为保证数据库的安全，需要给不同用户设置不同的权限。顾客对自己所购买商品有选择和查询的权限，可以查看自己的订单，但是对其它顾客的订单无查看权限，也没有修改权限。为了防止不符合规范的数据进入数据库，确保数据库中存储的数据正确、有效、相容，关系数据库必须满足关系的完整性约束条件。精确的需求分析，可以帮助我们在接下来的概念结构和逻辑结构设计阶段，准确设定关系表的主键、外键以及各个属性值的类型和取值范围，从而在实体完整性、参照完整性和用户定义完整性三个方面满足数据库的完整性需求。3.2 关系数据库的设计明确了用户的需求之后，接下来就要对用户需要处理的数据以及操作进行归纳和抽象，形
10、成概念模型，这个过程就是概念结构设计。概念结构设计是设计人员从用户的视角，对信息进行抽象和描述，因此概念模型应该具备真实、客观反映现实世界和易于理解的特点。目前最经常使用的概念模型是E-R模型。在前面2.1.1章节，我们介绍了概念模型的相关概念：实体、实体型、实体集、属性、联系，大家对概念模型有了初步的了解，下面来深入了解实体之间的联系。3.2.2 概念结构设计3.2 关系数据库的设计实体之间的联系通常指不同实体集之间的联系。实体集之间的联系类型有如下三种：1）一对一（1:1）：如果实体集A中的每个实体，在实体集B中至多有一个（也可以没有）实体与之关联，反之亦然。则实体集A与实体集B为一对一联
11、系，记为1：1。例如班长与班级之间的联系：一个班长管理一个班级，每一个班级有一个班长，因此班长与班级之间的联系类型为1：1，实体集之间的联系可以用图表示。2）一对多（1:n）:实体集A中的每个实体在实体集B中有n个（n0）实体与之关联，而实体集B中的每个实体在实体集A中最多只有1个实体与之关联，则实体集A与实体集B为一对多联系，记为1：n。例如客户与订单之间的联系：一个客户可以下单多次，而每个订单只涉及一个客户，所以客户与订单之间的联系类型为1：n。3.2.2 概念结构设计3.2 关系数据库的设计3）多对多（m:n）:实体集A中的每个实体在实体集B中有 n个（n0）实体与之关联，实体集B中的每
12、个实体在实体集A中有 m个（m0）实体与之关联，则实体集A与实体集B为多对多联系，记为m：n。例如订单与商品之间的联系：一个订单会涉及多个商品，而每种商品会被多个订单包含，因此订单与商品之间的联系类型就是m：n。3.2.2 概念结构设计班长管理班级11客户产生订单m1订单包含商品mn3.2 关系数据库的设计E-R图是E-R模型图形化表示方法，它提供了实体集、属性和实体集之间联系表示方法：l 用矩形表示实体集，矩形框内标注实体集名称。l 用椭圆形表示属性，椭圆形框内标注属性名字，并用无向边将其与相应的实体连接起来。l 用菱形表示实体集之间的联系，菱形框内标注联系名称，并用无向边将其与所联系的实体
13、集连接起来。3.2.2 概念结构设计3.2 关系数据库的设计例：用E-R图来表示网络购物系统概念模型。1）实体集网络购物系统所涉及的实体集有：客户、商品和订单。2）属性l 客户实体的属性有：编号、姓名、性别、注册日期、电话等。l 商品实体属性有：商品的名称、编号、类别、库存、是否上架、定价、售价等属性刻画。l 订单实体属性有：订单号、客户编号、商品编号、订单日期、发货日期、送货地址、城市等。3.2.2 概念结构设计3.2 关系数据库的设计3）联系l 每个客户会下多个订单，而每个订单只能对应一个客户，因此客户和订单是1：m联系。l 每个订单可以涉及多种商品，而每种商品也可以包含在多个订单中，因此
14、订单与商品之间是m：n的联系。下图为网络购物系统E-R模型图。3.2.2 概念结构设计3.2 关系数据库的设计逻辑结构设计是将概念结构设计阶段完成的E-R模型，转换成被选定的数据库管理系统支持的数据模型。由于目前的数据库应用系统大多采用支持关系模型的关系数据库管理系统，因此，这里主要讲E-R模型转换为关系模型的方法。E-R模型包含实体集、属性、实体集之间的联系三部分内容。关系模型通过关系即二维表表示实体集以及实体集之间的联系。因此，将E-R模型转换成关系模型，实际上就是将实体集以及实体集之间的联系转换为一个个关系。转换规则如下：3.2.2 逻辑结构设计3.2 关系数据库的设计1）实体集的转换：
15、一个实体集转换成一个关系，实体的属性即为关系的属性，实体的码即为关系的码。2）联系的转换：根据不同的联系类型做不同的处理：l 一对一的联系，可以转换为一个独立的关系，也可以与任意一端的关系合并。如果转换为一个独立的关系，则与该联系相连的各个实体的码以及该联系本身的属性作为关系的属性；如果与任意一端的关系合并，则需要加入另外一个实体的码和联系本身的属性作为此关系的属性。l 一对多的联系，可以转换为一个独立的关系，也可以与多端的关系合并。如果转化为一个独立的关系，则与该联系相连的各实体的码以及联系本身的属性作为此关系的属性。若与多端的关系合并，需加入一端实体的码和联系的属性作为此关系的属性。3.2
16、.2 逻辑结构设计3.2 关系数据库的设计l 多对多的联系，转换为一个独立的关系，其属性为多端实体的码加上联系本身的属性，关系的主键包括各实体的码。3个或3个以上的实体集间的一个多元联系，不管是何种联系类型，总是将多元联系类型转换成一个关系，其属性为与该联系相连的各实体的码及联系本身的属性。3.2.2 逻辑结构设计3.2 关系数据库的设计例：将网络购物系统E-R图转化为关系模型3.2.2 逻辑结构设计客户实体集转换为客户表：customers（customer_id，name，gender，registration_date，phone）商品实体集转换为商品表：items（item_id，it
17、em_name，category，cost，price，inventory，is_online）订单实体集转换为订单表：orders（order_id，order_date，address，city，shipping_date）客户与订单的联系与多端（订单实体集端）合并后新的订单表：orders（order_id，customer_id，order_date，address，city，shipping_date）订单与商品之间的联系转换为订单明细表:order_details（order_id，item_id，discount，quantity）3.2 关系数据库的设计 数据库在物理设备上的存
18、储结构与存取方法称为数据库的物理结构。针对已经确定的数据库逻辑结构，选取一个最适合应用需求的物理结构的过程，就是数据库的物理结构设计，它依赖于选定的数据库管理系统。系统会根据数据的具体情况确定存储结构和存取方法。物理结构设计过程中要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计者必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。如果评价结构满足原设计要求，则可进入到物理实施阶段，否则，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。3.2.4 物理结构设计3.2 关系数据库的设计 数据库实施阶段，设计人员根
19、据逻辑设计和物理设计的结果建立数据库，加载数据，并进行试运行。试运行阶段要重视数据库的校验工作。试运行过程中要测试各个功能是否满足设计的要求，对数据库的性能指标进行测试，分析其是否达到设计目标，未达到目标时需要针对数据库设计的各个阶段进行修改和调整，以满足用户的需求。数据库系统经过试运行后，即可投入正式运行，在数据库系统运行过程中必须不断地对其进行评价、调整、修改。数据库设计的优劣是相对的，不能保证数据库应用系统始终处于良好状态，为了保证良好的应用效果，需要在运行过程中不断的对数据库进行优化和维护。3.2.5 数据库实施与维护3.3 关系模型规范化设计数据库设计的逻辑结构设计过程中，针对一个具
20、体的应用，怎样才能构造一个合适的数据库模式，即应该构造几个关系模式，每个关系应该有哪些属性组成等，这需要一定的衡量标准，关系模型的规范化理论就是一个数据库设计指导理论和衡量标准，它可以帮助我们设计出良好的关系模式并避免后续数据库操作过程中可能出现的问题。这里涉及到范式的概念，不同的范式表示关系模式需要遵守的不同规则，在学习范式之前需要先了解函数依赖和关系模式中的键。3.3 关系模型规范化设计设关系模式a_schema（customer_id，name，gender，address，city，item_id，order_date，shipping_date），（customer_id，item_
21、id）为主键，表3.1中是关系模式某一时刻的数据表：3.3.1 函数依赖customer_idnamegenderaddresscityitem_idorder_dateshipping_date101薛为民薛为民男男海淀区西三旗育新花园小区海淀区西三旗育新花园小区0号楼号楼302北京市北京市b0012019-12-312020-1-1101薛为民薛为民男男海淀区西三旗育新花园小区海淀区西三旗育新花园小区0号楼号楼302北京市北京市f0022019-12-312020-1-1101薛为民薛为民男男海淀区西三旗育新花园小区海淀区西三旗育新花园小区0号楼号楼302北京市北京市b0022019-12
22、-312020-1-1105Adrian男男武清区巴孔闸路武清区巴孔闸路22号号0号楼号楼201天津市天津市c0032020-5-62020-5-7105Adrian男男武清区巴孔闸路武清区巴孔闸路22号号0号楼号楼201天津市天津市b0022020-5-62020-5-7105Adrian男男武清区巴孔闸路武清区巴孔闸路22号号0号楼号楼201天津市天津市f0012018-9-82018-9-10106孙丽娜孙丽娜女女莱西市姜山镇北口村莱西市姜山镇北口村0号号101青岛市青岛市f0012021-3-32021-3-33.3 关系模型规范化设计1）数据冗余问题：这个关系中，顾客的基本信息（包括
23、姓名、性别）以及顾客购物的地址和订单日期有冗余。一个顾客每个订单买多少种不同的商品，这个顾客对应的姓名、性别基本信息以及购物的地址、城市以及订单日期这些信息就会重复多少遍。2）数据更新问题：如果一个顾客的一个基本信息发生了变化，那么该顾客购买了几种商品我们就需要更改多少条顾客基本信息，从而使修改变得繁琐，这样还会造成信息不一致。3）数据插入问题：如果购物平台有了新的顾客加入，即已经有了顾客基本信息，但是我们也不能把该顾客加入到这个表中，因为顾客没有购物，它的item_id是空的，而作为主键的item_id，是不允许为空的。4）数据删除问题：如果一个顾客只购买了一种商品，后来又不买了，在删掉该顾
24、客的购买记录的同时，这个顾客基本信息也被删除掉了。3.3.1 函数依赖3.3 关系模型规范化设计 基于以上种种问题，我们可以看出，该关系模式不是一个好的关系模式，究其原因则是因为这个关系模式中某些属性存在“不良”函数依赖关系，下面我们来介绍函数依赖概念。函数依赖定义：设R(U)是属性集U上的关系模式，X、Y是U的子集。若对于R(U)的任意一个可能的关系r，如果r中两个元组在X上的属性值相等，在Y上的属性值也一定相等，则称X函数确定Y或Y函数依赖于X，记作XY。其中X叫做决定因素，Y叫做依赖因素。3.3.1 函数依赖3.3 关系模型规范化设计跟函数依赖相关的一些术语和记号：1）XY，但Y X（Y
25、不包含于X），则称XY是非平凡的函数依赖。2）XY，但Y X（Y包含于X），则称XY是平凡的函数依赖。若不特别声明，本书后面提到的函数依赖，都指非平凡的函数依赖。1）若XY，YX，则记作X Y。2）若Y不函数依赖于X，则记作XY。3）如果XY，并且对于X的任何一个真子集X，都有XY，则称Y对X完全函数依赖，记作XY。3.3.1 函数依赖F3.3 关系模型规范化设计4）若XY，如果存在X的某一真子集X，使XY，则称Y对X部分函数依赖，记作XY。5）如果XY （非平凡函数依赖，且YX），YZ，则称Z传递函数依赖于X，记作XZ。例：关系模式customers（customer_id，name，gen
26、der，phone），主键为customer_id，则存在以下函数依赖关系：customer_idname 客户姓名函数依赖于客户编号（customer_id，gender）name 客户姓名部分函数依赖于客户编号和性别3.3.1 函数依赖p传递3.3 关系模型规范化设计【例3.5】关系模式order_details（order_id，item_id，discount，quantity），主键为（order_id，item_id），存在以下函数依赖关系：（order_id，item_id）discount 商品折扣完全函数依赖于订单编号和商品编号3.3.1 函数依赖F设关系模式c_schema
27、（customer_id，city，province），主键为customer_id，存在函数依赖：customer_idcity 城市函数依赖于顾客编号cityprovince 所在省份函数依赖于城市 所以有：customer_idprovince 省份通过城市传递函数依赖于顾客编号传递3.3 关系模型规范化设计键（码）是关系模式中一个很重要的概念，前面第二章已经给出了键的若干定义，这里用函数依赖的概念来定义键。设U表示关系模式R的属性全集，即U=RA1，A2，A3，An，F表示关系模式R上的函数依赖集，则关系模式可以表示为R（U，F）。1）候选键 设K为关系模式R（U，F）的属性或属性组，
28、若KU，则K为R的候选键。2）主键 如果关系模式R（U，F）中有多个候选键，选其中的一个作为主键。3）全键 如果候选键为整个属性组则称为全键。3.3.2关系模式中的键3.3 关系模型规范化设计关系模式R（U，F）中，包含在任一候选键中的属性称为主属性，不包含在任一候选键中的属性称为非主属性。4）外键一个关系模式R（U，F）中的某个属性（组）不是R的主键，但它是另外一个关系的主键，则该属性（组）称为关系R的外键。例如关系模式order_details（order_id，item_id，discount，quantity）中，order_id不是主键，但它是关系模式orders（order_id，
29、customer_id，order_date，address，city，shipping_date）的主键，因此order_id是order_details的外键，同理，item_id也是order_details的外键。3.3.2关系模式中的键3.3 关系模型规范化设计【例3.7】关系模式customers（customer_id，name，gender，phone），设不同的顾客手机号码不同，则该关系模式中：候选键：customer_id，phone主键：customer_id，或者phone主属性：customer_id，phone非主属性：name，gender3.3.2关系模式中的键
30、3.3 关系模型规范化设计例3.8】关系模式order_details（order_id，item_id，discount，quantity），则该关系模式中：候选键：（order_id，item_id）主键：（order_id，item_id）主属性：order_id，item_id非主属性：discount，quantity外键：order_id，item_id3.3.2关系模式中的键3.3 关系模型规范化设计例3.9】设有关系模式order_schema（customer_id，item_id，order_date），如果规定每一个顾客同一种商品可以多次购买，order_date中的数据
31、包括日期和时间，则该关系模式中：候选键：（customer_id，item_id，order_date）主键：也就是该候选键主属性：customer_id，item_id，order_date非主属性：无外键：customer_id，item_id这种候选键为全部属性的表称为全键表3.3.2关系模式中的键3.3 关系模型规范化设计 关系数据库中的关系模式需要满足一定的要求，不同的要求对应不同范式。关系模式按其规范化程度从低到高可分为5级范式。满足最低要求的关系模式称为第一范式，简称1NF。在第一范式中又满足一些要求的称为第二范式，简称2NF，以此类推，还有3NF、BCNF、4NF、5NF。所有
32、范式中，只要关系模式满足第一范式，他就是合法的、允许的。后来，人们发现某些关系模式存在插入、删除异常，以及冗余度高、修改复杂等问题，因此开始研究关系模式的规范化问题。E.F.Codd在1971-1972年提出1NF、2NF、3NF的概念，1974年Codd和Boyce共同提出了新的范式BCNF，后来又有研究人员相继提出了4NF、5NF。规范化程度较高者必是较低者的子集。各种范式之间的关系如下：5NF4NFBCNF3NF2NF1NF3.3.3 范式3.3 关系模型规范化设计1第一范式定义：每个属性均不能再分解的关系模式。它是关系模式最基本的规范形式。如果关系模式R为第一范式则记作R1NF。第一范
33、式要求每个属性必须是不可分的数据项。图3.4这个表中“订单情况”不是基本数据项，它是由两个基本数据项“订单日期”和“发货日期”组成的一个复合数据项。因此这个关系模式不是第一范式。非第一范式的关系转换成第一范式关系只需要将所有数据项都表示为不可分的最小数据项即可，如图所示。3.3.3 范式顾客编号顾客编号订单情况订单情况订单日期订单日期发货日期发货日期1012019-12-312020-1-11022021-3-52021-3-61032020-1-22020-1-3顾客编号顾客编号订单日期订单日期发货日期发货日期1012019-12-312020-1-11022021-3-52021-3-61
34、032020-1-22020-1-3不符合第一范式符合第一范式3.3 关系模型规范化设计2第二范式定义：如果关系模式R（U，F）1NF，且R中的每个非主属性完全函数依赖于R的候选键，则R为第二范式，记作R 2NF。例如关系模式c_schema（order_id，item_id，order_date，quantity），候选键为（order_id，item_id）。该关系模式存在以下函数依赖关系：order_idorder_date（订单日期函数依赖于订单编号）所以存在部分函数依赖关系：（order_id，item_id）order_date（订单日期部分函数依赖于候选键）因此，该关系模式不满足
35、2NF。关系模式不满足2NF就会产生插入和删除异常以及修改复杂的问题。3.3.3 范式3.3 关系模型规范化设计可以通过模式分解将低一级范式的关系模式转换为高一级范式的关系模式集合。我们可以将关系模式c_schema分解为c_schema（order_id，item_id，quantity）和d_schema（order_id，order_date）两个关系模式。分解后的这两个关系模式都符合2NF了。3.3.3 范式3.3 关系模型规范化设计 3 第三范式定义：如果关系模式R（U，F）2NF，且每个非主属性都不传递函数依赖于候选键属性，则R满足第三范式，记作R 3NF。例如关系模式e_sche
36、ma（order_id，city，province），候选键为order_id，存在如下函数依赖关系：order_idcity（收货城市函数依赖于订单编号）cityprovince（省份函数依赖于城市）所以有以下传递函数依赖关系：order_idprovince3.3.3 范式传递3.3 关系模型规范化设计 因此，该关系模式不满足3NF，从而也会导致数据插入、删除操作异常，以及修改复杂的问题。可以将此关系模式分解为e_schema（order_id，city）和f_schema（city，province），分解后的两个关系均不存在非主属性对候选键属性的传递函数依赖，满足第三范式。3.3.3
37、范式3.3 关系模型规范化设计对于规范化程度低的关系模式，可以将其分解为若干个规范化程度高的关系模式，以此提高关系模式规范化程度。分解后的关系模式从语义上来说，每个关系只能描述一个主题，如果描述了多个主题，这个关系还要进行进一步分解。分解后的模式应该与原来的模式等价，不能在规范化过程中消除了一个问题同时又产生了其他问题，因此模式分解必须遵守以下两个原则：l 模式分解具有无损连接性。l 模式分解保持函数依赖。无损连接是指分解后的关系模式通过自然连接能够恢复到原来的关系，恢复后既不会增加信息也不会减少信息。保持函数依赖是指分解过程中，原来关系模式中的函数依赖不能丢失，也就是分解前后关系模式的语义应
38、该保持一致。3.3.4 关系模式的规范化3.3 关系模型规范化设计 【例3.8】关系模式h_schema（order_id，item_id，customer_id，name，discount，address，city，order_date），某个时刻数据表如表3.2所示，对其进行规范化处理。3.3.4 关系模式的规范化order_iditem_idcustomer_idnamediscountaddresscityorder_date1sm01105Adrian_Smith0.85海淀区西三旗幸福小区60号楼6单元606北京市2018-5-6 12:10:203b001107林琳0.80武清区
39、流星花园6-6-66天津市2018-6-18 18:00:023b002107林琳0.85武清区流星花园6-6-66天津市2018-6-18 18:00:023sm01107林琳0.90武清区流星花园6-6-66天津市2018-6-18 18:00:024f001106孙丽娜0.80道里区和谐家园66-66-666哈尔滨市2018-11-11 17:10:214sm01106孙丽娜0.90道里区和谐家园66-66-666哈尔滨市2018-11-11 17:10:214sm02106孙丽娜0.90道里区和谐家园66-66-666哈尔滨市2018-11-11 17:10:215m001103Gra
40、ce_Brown0.90市北区幸福北里88号院青岛市2019-2-1 17:51:015sm01103Grace_Brown0.90市北区幸福北里88号院青岛市2019-2-1 17:51:016s002104赵文博0.90海淀区清河小营东路12号学9公寓北京市2019-6-18 19:01:323.3 关系模型规范化设计 【例3.8】关系模式h_schema（order_id，item_id，customer_id，name，discount，address，city，order_date），某个时刻数据表如表3.2所示，对其进行规范化处理。从关系模式各个属性来看，每个属性都是最小的数据项，
41、不可以再分解，因此该关系模式符合1NF。关系模式的候选键为有order_id和（customer_id，item_id，order_date），由于客户编号不同，一般客户的姓名也不同（即使客户姓名相同也是不同的两个人，重名现象），因此存在函数依赖关系：customer_id name存在部分函数依赖关系：（customer_id，item_id，order_date）name3.3.4 关系模式的规范化3.3 关系模型规范化设计 因此，该关系模式不符合2NF。通过表中数据也可以看出，表中有大量冗余信息。例如name、address、city等属性值中存在冗余，可以通过模式分解进行规范化处理。通
42、过分析，可以看出该关系模式既包含了对客户的描述（customer_id，name），也包含了对订单的描述（order_id，customer_id，address，city，item_id，discount，order_date），根据每个关系模式尽量描述一个实体或实体之间的联系的原则，对其进行模式分解。可以分解为以下两个关系模式：customers（customer_id，name）orders（order_id，customer_id，order_date，item_id，discount，address，city）3.3.4 关系模式的规范化3.3 关系模型规范化设计 分解后的custo
43、mers关系模式候选键为customers_id，不存在部分函数依赖关系，符合2NF。而在orders关系模式中，（customer_id，item_id，order_date）是其中的一个候选键，由于商品折扣取决于商品编号和订单号，因此该关系模式存在部分函数依赖关系：（customer_id，item_id，order_date）discount需要将orders关系模式继续分解。可以将orders关系模式中涉及到的每个订单的详细信息分离出来，形成order_details关系模式。因此，将orders关系模式分解为以下两个关系模式：orders（order_id，customer_id，o
44、rder_date，address，city）order_details（order_id，item_id，discount）分解之后的两个关系模式不再存在部分函数依赖关系。3.3.4 关系模式的规范化3.3 关系模型规范化设计 分解之后的orders、order_details两个关系模式中不存在传递函数依赖关系，因此，都属于3NF。而关系模式order_details中，由于收货城市取决于收货地址，即：address city因此，orders关系模式存在以下传递依赖关系：order_idcity所以，orders不符合3NF。但是考虑到实际需求，购买商品后续处理过程中需要同时兼顾地址和城市，因此，关系模式不需要再接着进行分解，可以通过设置用户自定义完整性来解决传递函数依赖带来的问题。3.3.4 关系模式的规范化传递知识点小结关系数据库设计内容主要包括需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施和数据库运行及维护。关系模型的规范化理论是数据库设计指导理论和衡量标准，有助于设计出良好的关系模式并避免后续数据库操作过程中可能出现的问题。不同的范式表示关系模式需要遵守的不同规则，具体数据库设计需要满足第几范式应该根据实际情况确定，以高效、便捷和错误几率低作为标准。谢 谢 观 看Thanks for watching
