3.1 数据库设计概述
3.1.1 数据库设计的基本概念
数据库设计是建立数据库及其应用系统的技术，是信息系统开发和建设中的核心技术。数据库设计就是如何利用数据库管理系统、系统软件和相关的硬件系统，将用户的要求转化成有效的数据结构，并使数据库结构易于适应用户新的要求的过程。
确切地说，数据库设计是指对于一个给定的应用环境，提供一个确定最优数据模型与处理模式的逻辑设计，以及一个确定数据库存储结构与存取方法的物理设计，建立起既能反映现实世界信息和信息联系，满足用户数据要求和加工要求，又能被某个数据库管理系统所接受，同时能实现系统目标，并有效存取数据的数据库。
3.1.2 数据库设计方法
由于数据库系统结构复杂，应用环境多样，在相当长的一个时期内，数据库设计主要采用手工试凑法。但这种方法与设计人员的经验和水平有关，缺乏科学的理论和工程原则支持，质量难以保证。所以人们通过努力，提出了各种数据库设计方法，这些方法运用软件工程的思想和方法，提出了各种设计准则和规程。
这些方法中最著名的是新奥尔良（New Orleans）设计方法，它将数据库设计分为四个阶段：需求分析、概念设计、逻辑设计和物理设计。
数据库设计的基本思想是“反复探寻，逐步求精"的过程。
3.1.3 数据库设计的步骤
（1）系统规划
系统规划是确定系统目标功能和性能；确定系统所需要的资源；估计系统开发的成本、进度；估算系统可能达到的效益；确定系统设计的原则和技术路线等。
（2）需求分析阶段
需求收集和分析，结果得到数据字典描述的数据需求和数据流图描述的处理需求。
（3）概念结构设计阶段
通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。
（4）逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型（例如关系模型），并对其进行优化。
（5）数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。
（6）数据库实施阶段
运用DBMS提供的数据语言（例如SQL）及其宿主语言（例如C），根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。
（7）数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。
3.2 系统规划
3.2.1 系统规划的任务
系统规划的任务包括确定系统的名称，范围；确定系统开发的目标功能和性能；确定系统所需要的资源（如人员、设备、资金等）；估计系统开发的成本；确定系统实施计划及进度；分析估算系统可能达到的效益；确定系统设计的原则和技术路线等。
3.2.2 系统规划的成果
该阶段的成果是系统的总体规划报告，其主要内容如下。
系统简述：概述系统名称，任务提出，系统范围等。
系统特性：包括以下三种特性。
复杂性（系统是否涉及多媒体、实时检索等复杂技术内容）。
连续性（系统与现行系统关系，投资保护，可扩展性等）。
移植性（不同计算机系统环境下的应用情况）。
系统目标：设计系统总目标、分目标（子目标），并逐层分解，以求目标明确具体。
系统所需资源：现有情况，系统需求和落实情况。
成本估算：分期估算是成本估算常采用的方法，其内容涉及各工期中的人力资源，包括不同水平的人员的所要花费的时间及应花费的费用；必要的物质资源消耗。即总的成本是人员投入成本和物资投入成本的总和。
效益评估：效益包括社会效益和经济效益。
可行性分析：包括以下两种可行性。
技术可行性，涉及硬软件问题和其他技术性问题；
系统开发和运行环境的可行性，包括需求的迫切性，领导与职工的支持，现行管理体制和管理水平能否保证系统顺利开发和实现。
设计原则：用户第一原则，系统开发的各个阶段尽可能吸收用户参加，倾听用户意见，及时交流问题以便统一认识，提高设计质量。
技术路线：尽可能采用较为成熟的先进技术和产品，尽可能采用国际和国家的标准代码，尽可能保护现有投资（包括信息投资），尽可能与周边环境相适应等。
系统开发的组织落实：各类人员比例，每一成员能投入的时间等。
系统开发计划及进度安排等。
3.3 需求分析
3.3.1 需求分析的任务
需求分析的任务是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。
需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。信息要求是指用户需要从数据库中获得信息的内容与性质。由用户的信息要求可以导出数据要求，即在数据库中需要存储哪些数据。处理要求是指用户要求完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理。新系统的功能必须能够满足用户的信息要求、处理要求、安全性与完整性要求。
3.3.2 需求分析的步骤
首先调查组织机构情况：包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
然后调查各部门的业务活动情况：包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
协助用户明确对新系统的各种要求：包括信息要求、处理要求、安全性与完整性要求。
确定新系统的边界：确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。
在需求分析中，通过自顶向下、逐步分解的方法分析系统。
产生阶段成果：需求分析的阶段成果是系统需求说明书，此说明书主要包括数据流图、数据字典、各类数据的表格、系统功能结构图和必要的说明。系统需求说明书将作为数据库设计全过程的重要依据文件。
3.3.3 需求分析常用的调查方法
需求分析常用的调查方法有以下几种。
跟班作业：通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。
开调查会：通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。
请专人介绍。
询问：对某些调查中的问题可以找专人询问。
设计调查表请用户填写：如果调查表设计得合理，这种方法很有效，也很容易为用户接受。
查阅记录：即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。
3.3.4 数据字典
对数据库设计来讲，数据字典是进行数据收集和数据分析所获得的主要成果。数据字典是各类数据描述的集合。
数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分。
数据项是数据的最小单位，包括项名、含义、别名、类型、长度、取值范围等。
数据结构是若干数据项的有序集合，包括数据结构名、含义、组成的成分等。
数据流可以是数据项，也可以是数据结构，表示某一加工的输入输出数据，包括数据流名、说明、流入的加工名、流出的加工名、组成的成分等。
数据存储说明加工中需要存储的数据，包括数据存储名、说明、输入数据流、输出数据流、组成的成分、数据量、存储方式、操作方式等。
处理过程包括处理名、处理的简要说明、输入输出数据流等。
3.4 概念结构设计
产生反映企业各组织信息需求的数据库概念结构，即概念模型。概念结构独立于数据库逻辑结构，也独立于支持数据库的DBMS，不依赖于计算机系统。
将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计，是整个数据库设计的关键所在。
3.4.1 概念模型及其设计方法
3.4.1.1 概念模型
概念模型是对现实世界的一种抽象，即对实际的人、物、事和概念进行人为处理，抽取人们关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述。概念模型应具备下列特点。
丰富的语义表达能力，能表达用户的各种需求，包括描述现实世界中各种对象及其复杂的联系，以及用户对数据库对象的处理要求等。
易于交流和理解。概念模型是数据库管理员、应用系统开发人员和用户之间的主要交流工具。
易于变动。概念模型要能灵活地加以改变，以反映用户需求和环境的变化。
易于向各种数据模型转换，易于从概念模型导出与DBMS有关的逻辑模型。
3.4.1.2 概念结构设计方法
概念结构的设计方法有以下几种。
自顶向下：即首先定义全局概念结构的框架，然后逐步细化。
自底向上：即首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构。
逐步扩张：首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构。
混合策略：即将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。
最常采用的策略是自底向上设计方法，即自顶向下地进行需求分析，然后再自底向上地设计概念结构。自底向上数据库概念设计方法的主要步骤包括：进行数据抽象，设计局部概念结构；将局部概念模式综合成全局概念结构；进行评审，改进。
3.4.1.3 E-R设计方法的介绍
概念设计方法最著名和最实用的是“实体-联系法”（Entity-Relationship Approach），即E-R 方法。这种方法将现实世界的信息结构统一用属性、实体及实体之间的联系来描述。
（1）E-R方法的基本术语
①实体与属性
实体（entity）与属性（attribute）都是客观存在并可相互区分的事物。而属性是用以描述实体的某一特征的。在某一特定的应用范围，属性必须是不可分的数据项，不能包含其他属性，不能再具有需要描述的性质。属性不能与其他实体具有联系，联系只发生在实体之间。实体必须采用一组表示其特征的属性来描述，同时确定哪个属性组成为该实体的键。
实体与属性是相对而言的，很难有截然划分的界限。在设计时可以归为属性的事物尽可能归为属性，以简化E-R图的处理。但也要根据应用环境而定，在有的环境中作为属性的事物可能在另一环境中作为实体。例如：工种通常作为职工的属性，但要涉及劳保部门时，它就成为一个实体。工种实体可用以下属性来表示：
工种号，工种名，工种类型，工种补贴，保健费……
又如仓库一般作为货物的属性，例如：货号，货名，型号，规格，价格，存放仓库，等等。但仓库也可以作为一个实体，它包括如下属性：
仓库号，仓库名，地点，容量，负责人……
②联系
联系（relationship）是指实体之间存在的对应关系，联系本身也具有属性。联系一般可分为三类：一对一的联系（1：1）、一对多的联系（1：n）、多对多的联系（m：n）。
（2）E-R图的表示
在E-R图中，用长方形表示实体，用椭圆表示属性，用菱形表示联系。在图形内标示它们的名字，它们之间用无向线联系，表示联系时在线上表明是哪种类型的联系。
3.4.2 采用E-R方法的概念设计步骤
采用E-R方法的数据库概念设计可分为三个步骤进行：设计局部E-R模型、设计全局E-R模型和优化全局E-R模型。概念设计后得到全局E-R图。
3.4.2.1 设计局部E-R模型
设计步骤
（1）选择局部应用
从需求分析阶段所产生的描述整个系统的多层数据流图中，选取中层数据流图作为设计局部E-R图的依据。因为中层数据流图能较好地反映系统中各局部应用的子系统组成。
（2）逐一设计局部应用的E-R图
每个局部应用都对应一组数据流图，局部应用涉及的数据都已经收集在数据字典中。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，标定局部应用中的实体、实体的属性、标识实体的键，确定实体之间的联系及其联系类型（如1：1，1：n或m：n）。
例3-1 以仓库管理为例，描述设计E-R图的步骤。
第一步，确定实体类型
本问题有材料、零件和产品三个实体类型。
第二步，确定联系类型
产品和零件之间是m：n联系，即一个产品需要多种零件，一种零件可用于多个产品中。材料和零件之间也是m：n联系，即一种零件可由多个材料组成，一个材料也可组成多种零件。
第三步，确定实体类型的属性
产品实体类型的属性：（产品号，产品名称，产品性能参数）。产品号为该实体的键。
零件实体类型的属性：（零件编号，零件名称，颜色，重量，价格）。其中零件编号为该实体的键。
材料实体类型的属性：（材料编号，材料性能，库存量）。材料编号为该实体的键。
第四步，确定联系类型的属性
联系类型的属性除了包括联系本身的属性外，还应包括与之联系的所有实体类型的键。产品与零件之间的联系类型包含属性：（产品编号，零件编号，需要的零件数量）。
材料与零件之间的联系类型包含属性：（零件号，材料号，材料使用量）。
第五步，根据实体类型和联系类型画出局部E-R图。
例3-2 以学生管理系统中学籍管理为例说明局部E-R模型的建立过程。
第一步，确定实体类型。应用中主要涉及的实体类型包括学生、宿舍、档案材料、班级、班主任。
第二步，确定联系类型。宿舍与学生之间是1：n的联系。由于一个宿舍可以住多个学生，而一个学生只能住在某一个宿舍中。班级与学生之间也是1：n的联系。由于一个班级往往有若干名学生，而一个学生只能属于一个班级。班主任与学生之间也是1：n的联系。由于班主任同时还要教课，因此班主任与学生之间存在指导联系，一个班主任要教多名学生，而一个学生只对应一个班主任。班级与班主任之间是1：1的联系，因为一个班级只有一个班主任。学生与档案材料之间是1：1的联系，因为一个学生只有一份档案材料。班级与教室之间是m：n的联系。因为一个班级的学生可以在多个教室上课，一个教室也可以由多个班级的学生上课。
第三步，确定实体类型的属性。各实体类型的属性分别为：
学生：｛学号，姓名，性别，年龄，所在系，年级，平均成绩｝
宿舍：｛宿舍编号，地址，人数｝
档案材料：｛档案号，学号……｝
班级：｛班级号，学生人数｝
班主任：｛职工号，姓名，性别，是否为优秀班主任｝
教室：｛教室编号，地址，容量｝
其中有下划线的属性为实体类型和联系类型的键。
第四步，确定联系类型的属性。
班主任与学生之间指导联系的属性有职工号和学生号。
班主任与班级之间管理联系的属性有职工号和班级号。
学生与宿舍之间住宿联系的属性有宿舍号和学号。
学生与档案材料之间归档联系的属性有学号和档案号。
班级与学生之间组成联系的属性有班级号和学号。
班级与教室之间上课联系的属性有班级号、教室号、课程号和时间。
第五步，画出局部的E-R图。
为节省篇幅，该E-R图中省略了各个实体的属性描述。
例3-3 以学生管理系统中课程管理应用为例画出局部E-R图。
与上述两个例子类似的步骤，可得到课程管理应用的局部E-R图。
除了学籍管理中的一些实体和联系外，还增加了课程、教师、教科书这三个实体类型及三个实体联系，分别是学生与课程之间的选修联系、教师与课程之间的讲授联系、教师与学生之间的教学联系。这三个实体类型的属性分别如下：
课程：｛课程号，课程名，学分｝
教师：｛职工号，姓名，性别，职称｝
教科书：｛书号，书名，价钱｝
其中有下划线的属性为实体类型和联系类型的键。
三个联系类型的属性分别如下：
学生-课程之间选修联系包含的属性有学号、课程号和成绩；
教师-学生之间教学联系包含的属性有职工号和学号；
教师-课程之间讲授联系包含的属性有职工号和课程号。
3.4.2.2 设计全局E-R模型
这一阶段是将所有局部的E-R图合并为全局的E-R图，即全局的概念模型。
具体步骤如下。
（1）合并
把局部E-R图合并为全局E-R图时，一般采用两两合并的方法，即：先将具有相同实体的两个E-R图，以该相同实体为基准进行合并，如果还有相同实体的E-R图，再次合并，这样一直下去，直到所有的具有相同实体的局部E-R图都被合并，从而得到全局的E-R图。
（2）解决冲突
当将局部的E-R图合并为全局的E-R图时，可能存在三类冲突：属性冲突、结构冲突和命名冲突。
属性冲突包括属性的数据类型，取值范围，取值单位的冲突。
结构冲突有三种情况。
同一对象在不同应用中具有不同的抽象。在某一局部应用中被当作实体的事物，而在另一局部应用中则被当作属性。
同一实体在不同局部应用中所包含的属性不完全相同。
实体之间的联系在不同局部应用中呈现不同的联系类型。即在一个应用中是1：n联系，而在另一应用中是m：n联系。
命名冲突包括实体类型名，联系类型名之间异名同义或异义同名等命名冲突。
例3-4 解决例3-2和例3-3两个局部E-R图在合并时的冲突。
例3-2和例3-3中介绍的学籍管理和课程管理两个局部的E-R图在合并时存在以下几个冲突。
①班主任实际上也属于教师，也就是说学籍管理中的班主任实体与课程管理中的教师实体在一定程度上属于异名同义，可以将学籍管理中的班主任实体与课程管理中的教师实体统一称为教师。统一后教师实体的属性如下：
教师：｛职工号，姓名，性别，职称，是否为班主任｝
②将班主任改为教师后，教师与学生之间的联系在两个局部应用中呈现两种不同的类型，一种是学籍管理中教师与学生之间的指导联系，另一种是课程管理中教师与学生之间的教学联系，由于指导联系实际上可以包含在教学联系之中，因此可以将这两种联系综合为教学联系。
③在两个局部E-R图中，学生实体属性组成及次序都存在差异，应将所有属性综合，并重新调整次序。假设调整后学生实体包含的属性如下：
学生：｛学号，姓名，出生日期，年龄，所在系，年级，平均成绩｝
3.4.2.3 全局E-R图模型的优化
一个好的全局E-R图除了能反映用户功能需求外，还应满足下列条件：实体类型个数尽可能少，实体类型所含属性尽可能少，实体类型间联系无冗余。优化就是要达到这三个目的。为此，要合并相关实体类型，一般把1：1联系的两个实体类型合并，合并具有相同键的实体类型，消除冗余属性（可由基本数据导出的数据）和冗余联系（可由其他联系导出的联系）。因为冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难。但有时为提高效率，根据具体情况可存在适当冗余。
学籍管理和课程管理的两个局部E-R图合并后存在着冗余数据和冗余联系。
①学生实体中的年龄属性可以由出生日期推算出来，属于冗余属性，应该去掉。这样不仅可以节省存储空间，而且当某个学生的出生日期有误，进行修改后，无须修改年龄，减少了产生数据不一致的机会。学生实体的属性包括如下：
｛学号，姓名，出生日期，所在系，年级，平均成绩｝
②教室与班级之间的上课联系可以由教室与课程之间的开设联系、课程与学生之间的选修联系、学生与班级之间的组成联系三者推导出来，因此属于冗余联系，可以消除。
③学生实体中的平均成绩可以从选修联系中的成绩属性推算出来，但如果应用中需要经常查询某个学生的平均成绩，每次都进行这种计算效率就会太低，因此为提高效率，可以考虑保留该冗余属性。但是为了维护数据一致性应该定义一个触发器来保证学生的平均成绩等于该学生各科成绩的平均值。任何一科成绩修改后，或该学生学习新的科目并有成绩后，就要触发该触发器去修改该学生的平均成绩属性值，否则会出现数据的不一致。
3.5 逻辑结构设计
逻辑结构设计的任务就是把概念结构设计阶段产生的全局E-R图转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构。逻辑结构包括数据库的模式和外模式。这些模式在功能、性能、完整性、一致性及可扩充性等方面都要满足用户的要求。
3.5.1 逻辑结构设计的步骤
3.5.1.1 逻辑结构设计的内容
设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。设计逻辑结构的内容包括以下几个方面。
模式设计：将E-R图的实体和联系类型转换成选定的DBMS支持的数据模型（如果是关系数据模型即转换成关系模式）。
子模式设计：子模式是应用程序与数据库的接口，简化用户对系统的使用，允许用户有效访问数据库而不破坏数据库的安全性。
对模式进行优化：逻辑设计的结果不是唯一的，为了提高系统性能，以规范化理论（参见3.5.3.2节）为指导，根据需要适当地修改、调整、分解模式结构，减少数据之间的依赖，消除冗余联系，提高操作效率和存储空间的利用率。
3.5.1.2 关系数据库逻辑设计的步骤
（1）导出初始关系模式
根据E-R图和DBMS特点按转换规则转换成初始关系模式。
（2）规范化处理
将初始关系模式进行规范化处理，即消除冗余，消除异常，改善完整性、一致性和存储效率，一般关系模式达到3NF（参见3.5.3.2节）就可以。
（3）模式评价
模式评价的目的是检查数据库模式是否满足用户的要求，它包括功能评价和性能评价。
（4）优化模式
如模式有疏漏要新增关系模式，如模式的性能不好则要采用合并，分解或选用另外结构等方式重新进行设计。并不是规范化程度越高的关系就越优。优化的方式有以下两种。
合并：对具有相同关键字的关系模式，如它们的处理主要是查询操作，经常在一起查询，可将这类关系模式合并。减少联结操作，提高查询效率。
分解：关系模式虽已达到规范化要求，但如果属性过多会造成空间的浪费和操作效率低下，可将它分解成两个或多个关系模式。这种属性分解称为垂直分解。要注意的是，垂直分解所得到的每一关系模式都应包含主键。
（5）建立子模式
根据实际应用在关系模式的基础上建立面向用户的子模式。子模式体现用户对数据库的不同观点，仅是用户的一个视图。应尽量考虑用户的习惯与方便，简化用户的使用，保证系统的安全性。
（6）形成逻辑设计说明书
逻辑设计说明书的内容包括以下方面。
应用设计指南：访问方式，查询路径，处理要求，约束条件等。
物理设计指南：数据访问量，传输量，存储量，递增量等。
模式及子模式的集合。模式和子模式可用DBMS语言描述，也可列表描述。。
3.5.2 E-R图转换为关系模型
3.5.2.1 关系模式的设计问题
首先，通过实例来评价关系模式设计的好坏。
例3-7 根据给出的E-R图设计并优化模式。
假设有一组实体和实体之间的联系。
供应者实体S（SNO，SNAME，STATUS，SCITY）：供应者提供各种零件，包括供应者编号、姓名、所在的州、所在的城市等属性。
零件实体P（PNO，PNAME，COLOR，WEIGHT）：包括零件的编号、零件的名称、颜色、重量等属性。
供应联系SP（SNO，PNO，QTY）：指出哪个供应者供应了哪种零件，并且供应了多少个零件。包括供应者编号、零件编号、供应零件的数量等属性。
针对上述E-R模型可能设计出以下两种关系模式。
（1）只产生一个关系模式
即将两个实体及实体之间的联系全部放到一个关系模式中。
S-SP-P（SP（SNO，SNAME，STATUS，SCITY，PNO，PNAME，COLOR，WEIGHT，QTY））
（2）使用三个关系模式
即S，P，SP分别表示供应者实体、零件实体和实体之间的联系。
S（SNO，SNAME，STATUS，SCITY）
P（PNO，PNAME，COLOR，WEIGHT）：
SP（SNO，PNO，QTY）
比较这两种设计方案，第一种设计可能存在如下问题。
①数据冗余。如果供应者提供多种零件时，则每提供一种零件必须存储一次供应者的细节，同样，当一种零件由多个供应者提供时，也必须重复存储该种零件的细节。
②修改异常。由于数据冗余，当修改某些数据项（如零件颜色）时，可能有一部分有关元组被修改，而另一部分有关元组却没有被修改。
③插入异常。当需要使用一种新的零件，而这种零件还没有被任何一个供应者供应，则该零件的细节将无法进入数据库中。因为在S-SP-P关系模式中，（SNO，PNO）是主键，此时SNO为空值，实体完整性约束不允许主键为空或部分主属性为空的元组在关系中出现，因此该零件的细节不能在数据库中出现。
④删除异常。如果某个供应者提供的零件都被删除，那么此供应者的细节也一起被删除。
第二种设计方法就不存在上述问题，数据冗余消除了，不仅如此，即使供应者现在不提供任何零件，它的细节也仍然包含在关系模式S中。所以采用第二种设计方法可以克服第一种设计方法存在的问题。但是第二种设计方法也有自己的缺陷，即效率太低，比如为找到“红色”零件的供应者姓名，则需进行三个关系模式的两两联结操作，代价很高。相比之下，采用第一种设计方法使用S-SP-P关系模式则直接选择、投影即可，显然代价较低。
那么，对于上述四类问题，如何在设计中完全消除？如何能找到一个好的关系模式？首先将E-R图转换为关系模式时必须遵循一定的规则，然后研究关系模式中数据之间的相互依赖，最后根据依赖关系进行模式分解使其规范化。后两步就是关系数据库设计理论所研究的内容，即关系模型的规范化。
3.5.2.2 E-R图转换为关系模型的原则
关系模型的逻辑结构是一组关系模式的集合，而E-R图则是由实体、属性和实体之间的联系三个要素组成的，所以将E-R图转换为关系模型要解决的问题是如何将实体和实体之间的联系转化为关系模式，如何确定这些关系模式的属性和主键。这种转换一般遵循如下原则。
①一个实体类型转换为一个关系模式。实体的属性就是关系的属性。实体的键就是关系的键。
例3-8 将学生实体和课程实体分别转换成两个关系模式。
学生关系模式{学号，姓名，性别，年龄……}，学号为关系的主键
课程关系模式{课程号，课程名称，学分……}，课程号为关系的主键
②一个m：n联系转换为一个关系模式。与该联系相连的各实体的键及联系本身的属性均转换为关系的属性。而关系的键为各实体的键的组合。
例3-9 将一个m：n联系转换为一个关系模式。
在前面的例子中，学生与课程间的“选修"联系是一个m：n联系，可以将它转换为如下关系模式：
选修关系模式{学号，课程号，成绩}，学号与课程号为关系的组合键
③一个1：n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并，只需要将联系本身的属性和1端实体的键加入到n端对应的关系模式中。如果转换为一个独立的关系模式，则与该联系相连的各实体的键，以及联系本身的属性均转换为关系的属性，而关系的键为n端实体的键。
例3-10 将一个1：n联系与n端对应的关系模式合并。
班级与学生之间的“组成”联系是一个1：n联系，可以将该联系与学生关系模式合并。需要将班级关系模式的键以及联系的属性加入到学生关系模式中。此时学生关系模式的属性如下：
学生关系模式：{学号，班级号，姓名，性别，年龄……}，学号为关系的主键，班级号为外键
④一个1：1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的键及联系本身的属性均转换为关系的属性，每个实体的键均是该关系的候选键。如果与某一端对应的关系模式合并，则需要在该关系模式的属性中加入另一端关系模式的键和联系本身的属性。
例3-11 将一个1：1联系与任一端对应的关系模式合并。
学生与档案材料之间的“归档”联系是1：1联系，可以将该联系与学生关系模式合并，需要将档案材料关系模式的键及此联系的属性加入到学生关系模式中。此时学生关系模式的属性如下：
学生关系模式：{学号，班级号，档案号，姓名，性别，年龄……}，学号为关系的主键，班级号和档案号为外键
3.5.3 关系模式的规范化
由E-R图转换成初始的关系模式后，通常以关系数据库设计理论为指导，修改、调整、规范化关系模式的结构，从而产生一个确定的、好的关系模式。
在数据库设计中，如何把现实世界表示成关系模式，一直是人们非常重视的问题。关系数据库设计理论所研究的问题就是指导产生一个好的关系模式。
关系数据库设计理论主要包括三方面的内容：函数依赖、范式（Normal Forms）、模式设计方法，其中函数依赖起核心的作用。
3.5.3.1 函数依赖
1.数据完整性约束条件
关系可以定义为笛卡尔积的一个子集，它可以模拟现实世界，但并非所有的子集都有意义。例如，一个职工登记表中，工龄为40而年龄为30的元组是不合理且无意义的，因此就要对关系的值作限制，这种限制称为数据完整性约束条件。约束条件一般可分为以下两类：
（1）依赖于值域元素语义的限制
如上所说的一个职工的工龄不可能大于年龄，或某人身高不可能大于4米，等等，这种检查主要由DBMS 的完整性子系统去完成，与数据库模式设计几乎无关。
（2）依赖于值的相等与否的限制
这类限制并不取决于某一元组的属性取什么值，而仅仅取决于两个元组的某些属性的值是否相等。这类限制统称为数据依赖，数据依赖分为函数依赖和多值依赖，函数依赖是其中最重要也是最基本的一种。
2.函数依赖的定义
函数依赖普遍地存在于现实生活中。例如：描述一个学生的关系，可以用学号（SNO）、姓名（SNAME）、年龄（AGE）等几个属性。由于一个学号只对应一个学生，一个学生只有一个姓名和一个年龄。因而当“学号”值确定之后，姓名和年龄的值也就被唯一地确定了。就如同自变量x确定之后，相应的函数值f（x）也就唯一确定了一样，所以说SNO函数决定SNAME和AGE，或者说SNAME、AGE 函数依赖于SNO，记为SNO→SNAME，SNO→AGE。
函数依赖是数据依赖的一种，它反映属性或属性组之间相互依存、相互制约的关系，反映现实世界的约束关系。
函数依赖的定义为：设R（U）是属性集U上的关系模式，X与Y是U的子集，若对于R（U）的任意一个关系r，如果对r中的任意两个元组t和s，都有t[X]≡s[X]，就必须有t[Y]≡s[Y]（即若两个元组它们在X上的属性值相等，则在Y上的属性值也一定相等），则称X函数决定Y或Y函数依赖于X，记作X→Y，并称X为决定因素（determinant）。
函数依赖和别的数据依赖一样，是语义范畴的概念。因此只能根据语义来确定一个函数依赖。例如：姓名→年龄这个函数依赖只有在没有同姓同名的条件下成立。如果允许有相同姓名，则年龄就不再依赖于姓名了。设计者也可以对现实世界作强制的规定。例如规定不允许同姓同名人出现，因而使姓名→年龄函数依赖成立。这样当插入某个元组时，这个元组上属性值必须满足规定的函数依赖，若发现有同姓同名人存在，则拒绝插入该元组。
注意：函数依赖不是指关系模式R的某个或某些关系满足的约束条件，而是指R的一切关系均要满足的约束条件。
3.关系数据库中函数依赖的分类
关系数据库中函数依赖主要有以下几类。
（1）平凡函数依赖和非平凡函数依赖
设有关系模式R（U），X→Y是R的一个函数依赖。若对于任何X、Y∈U，此函数依赖对R的任何一个值r都成立，且Y不包含于X，则称X→Y是一个非平凡函数依赖。
显然，如果Y包含于X，则X→Y就是一个平凡函数依赖。
若不特别说明，一般总是讨论非平凡函数依赖。
（2）完全函数依赖和部分函数依赖
设X→Y是一个函数依赖，且对X的任何一个真子集X′都不存在X′→Y，则称X→Y是一个完全函数依赖，即Y完全函数依赖于X，记为XFY。反之，如果X′→Y成立，则称X→Y是部分函数依赖，即Y部分函数依赖于X，记为XPY。
（3）传递函数依赖
设有关系模型R（ABC），若有两个函数依赖：A→B和B→C，若函数依赖A→C也成立，但它不是直接的函数依赖，而是通过传递而使A→C成立的，则称C传递函数依赖于A。
设有关系模式R（U），X，Y，Z∈U，如果X→Y，Y→Z，且Y不包含于X，Y不函数决定X，则有X→Z，称Z传递函数依赖于X。
3.5.3.2 关系模式的规范化理论
关系数据库中的关系要满足一定要求，满足不同程度的要求称为不同范式。满足最低要求的为第一范式，简称1NF。在第一范式中进一步满足一些要求的为第二范式，其余以此类推。E.F.Codd提出了规范化的问题，他系统地提出了1NF，2NF，3NF的概念。1974年他和Boyce又共同提出了一个新的范式概念，即BCNF（Boyce Codd Normal Form）。1976年，Fagin又提出了4NF，后来又有人提出了5NF。
R为第几范式就可以写成R∈xNF。
不是1NF的关系都是非规范化关系。数据库理论研究的关系都是规范化关系。1NF是关系数据库的关系模式应满足的最起码的条件。
一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化。其基本思想是逐步缩小关系模式中不合适的数据依赖，使模式达到某种程度的分离，即“一个关系表示一事或一物”。
各个范式的定义如下。
（1）第一范式
如果关系模式R的每一个属性都是不可分解的，则称R为第一范式的模式，记为R∈1NF。
（2）第二范式
如果关系模式R是第一范式，且每个非主属性都完全函数依赖于主属性，则称R为第二范式的模式，记为R∈2NF。
（3）第三范式
如果关系模式R是第二范式，且没有一个非主属性传递函数依赖于候选键，则称R为第三范式的模式，记为R∈3NF。
可以证明，若R∈3NF，则每一个非主属性既不部分依赖于主键也不传递依赖于主键。
（4）BCNF（扩充第三范式）
如果关系模式R是第三范式，且没有一个属性部分函数依赖或传递函数依赖于候选键，则称R为扩充第三范式的模式，记为R∈BCNF。
总的看来，关系模式有以下4个主要特点：
数据独立性高；
结构简单，实体及实体之间的联系都用表来表示；
集合处理能力强，有数学理论基础；
有功能强大的关系数据库语言SQL支持。
下面举例说明如何将一个关系模式进行分解，使得最终所有的关系模式都满足3NF。
例3-12 分析关系模式STUDENT（SNO，SNAME，SEX，AGE，DEPT，LOC，FAMILAY）达到几范式？
关系模式STUDENT（SNO，SNAME，SEX，AGE，DEPT，LOC，FAMILAY），由于属性FAMILAY（家庭成员）可以再分解，所以不满足1NF。
例3-13 将关系模式S-L-C（SNO，SDEPT，SLOC，CNO，G）进行分解，使其达到3NF。
第一步：确定函数依赖
关系模式S-L-C（SNO，SDEPT，SLOC，CNO，G），有5个属性：SNO为学生的学号；SDEPT为学生所在的系名；SLOC为学生的宿舍，并且每个系的学生住在同一个地方；CNO为课程的编号；G为某一学号的同学选修某一课程的成绩。这里（SNO，CNO）为该关系模式的主键。
由于每一同学选修某一课程才有该课程的成绩，所以存在一个（SNO，CNO）→G的函数依赖。根据学号能得出他所在的系名，所以又存在一个SNO→SDEPT的函数依赖。根据学号也能得出他所住的宿舍，所以又有一个SNO→SLOC的函数依赖。另外，根据学号和课程号也能得出该学生所在的系名和所住的宿舍，所以又有两个函数依赖，（SNO，CNO）→SDEPT，（SNO，CNO）→SLOC。
该关系模式的函数依赖有：（SNO，CNO）→G，SNO→SDEPT，（SNO，CNO）→SDEPT，
SNO→SLOC和（SNO，CNO）→SLOC。
第二步：进行模式分解使其达到2NF
分析上面的例子，可以发现有两种非主属性。一种是G，它对主键（SNO，CNO）是完全函数依赖。另一种是SDEPT、SLOC，对主键（SNO，CNO）不是完全函数依赖。所以S-L-C关系模式不是2NF。这就导致对上述关系模式进行插入、更新、删除时会产生冗余，以及插入删除的异常问题。
解决的办法是用投影把关系模式S-L-C分解为两个关系模式。一个是SC（SNO，CNO，G），包含主键（SNO，CNO）和完全函数依赖于主键的属性G。另一个是S-L（SNO，SDEPT，SLOC），包含非完全函数依赖于的主键的属性SDEPT，SLOC，以及它们部分依赖的主属性SNO。
关系模式SC的主键为（SNO，CNO），关系模式S-L的主键为SNO，这样就使得非主属性对主键都是完全函数依赖。这时关系模式SC和S-L都是2NF。
第三步：进行模式分解使其达到3NF
关系模式SC中主键是（SNO，CNO），函数依赖为（SNO，CNO）→G，所以没有传递依赖。
关系模式S-L中存在非主属性对主键的传递依赖。因为根据学号可知其所在的系，一个系的同学住在一起，所以根据系可知其宿舍，根据学号也能知道其宿舍，所以在关系模式S-L中有三个函数依赖SNO →SDEPT，SDEPT →SLOC和SNO →SLOC。根据SNO →SDEPT和SDEPT →SLOC函数依赖可得SNO →SLOC。因此SC∈3NF，而S-L 不是3NF。
此时对S-L关系模式进行操作，仍会产生插入异常、删除异常、冗余度大等问题。
解决的办法同样是将关系模式S-L分解为两个关系模式：一个是S-D（SNO，SDEPT），包含主键SNO和非主属性SDEPT；另一个是D-L（SDEPT，SLOC），包含主键SNO和非主属性SLOC。分解后的关系模式S-D与D-L中不再存在传递依赖。
这时关系模式SC（SNO，CNO，G）、S-D（SNO，SDEPT）和D-L（SNO，SLOC）都是3NF。
一般在进行模式分解实现规范化的过程中，关系模式达到3NF就可以不再分解。并不是范式越高越好，范式越高，模式分解得越小，对其进行插入删除时产生冗余的概率越小，但进行查询时往往要进行多表的联结，系统开销很大，效率较低。所以在性能和空间几个方面应该综合考虑，一般分解到3NF就可以。
3.6 数据库的物理设计
对于给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程称为数据库物理设计。物理设计的任务是为了有效地实现逻辑模型，确定所采取的存储策略。
3.6.1 物理设计的任务
数据库物理设计的主要任务是对数据库中数据，在物理设备上的存放结构和存取方法进行设计。物理设计常常包括某些操作约束，如响应时间与存储要求等设计。数据库物理结构依赖于给定的计算机系统，而且与具体选用的DBMS密切相关。
3.6.2 物理设计的步骤
物理设计可分为五个步骤，前三步为结构设计，后两步为约束和程序设计。
3.6.2.1 存储记录结构设计
对属性特征做分析，对存储记录结构进行分割，以便对数据进行压缩存储，以及便于应用程序设计。分割方法有垂直分割法和水平分割法两种。
对含有较多属性的关系，按其中属性的使用频率不同进行垂直分割，但要求分割后的子关系都包含原关系的主键。
对含有较多记录的关系，按某些条件进行水平分割。
把分割后的关系定义在相同或不同类型的物理设备上，或在同一设备不同区域上，从而使访问数据库的代价最小，提高数据库的性能。
3.6.2.2 存储方法设计
物理设计中最重要的一个考虑，是把存储记录在全范围内进行物理安排，存放的方式有以下4种。
顺序存放：记录顺序存放，平均查询比较次数为记录个数的二分之一。
HASH存放：记录存放位置和查询比较次数由HASH算法决定。
索引存放：建立索引可以加快查询速度，索引并不是越多越好，系统维护索引要付出代价，查找索引也要付出代价，所以必须确定在哪个属性上建何种索引，以及建多少个索引。
聚簇存放（cluster）：记录聚簇是指将不同类型的记录分配到相同的物理区域中去，即把不同关系的联结属性上具有相同值并经常在一起使用的元组存放在相同的物理块中，以减少物理I/O次数，从而提高访问速度。
3.6.2.3 数据物理存放位置设计
确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。一般将易变数据与稳定数据分开存储，将经常存取的数据和存取率较低的数据分开存储，将表数据和索引数据分开存储，将日志数据与数据库对象分开存储。各个DBMS对数据进行物理安排的手段、方法差异很大，因此必须仔细了解DBMS提供的方法和参数进行适当的物理安排。
3.6.2.4 完整性和安全性考虑
根据逻辑设计说明书中提供的数据库约束条件，以及具体的DBMS、操作系统的性能特征和硬件环境，设计数据库的完整性和安全性措施。数据完整性一般由DBMS提供定义和检验机制，不必在程序中加以定义。但不同的DBMS提供的完整性定义机制不同。安全性措施由数据库管理员人为地加以限制，对不同的用户授予不同的权限，以防数据被破坏。
3.6.2.5 应用程序设计
应用程序设计包括人机接口设计，如菜单、屏幕设计、I/O格式设计、代码设计、处理加工设计等。
3.6.2.6 形成物理设计说明书
在物理设计中，应充分注意数据的物理独立性。所谓数据的物理独立性，是指消除由于物理数据结构设计变动而引起对应用程序的修改。
物理设计的结果是物理设计说明书，其内容包括存储记录格式，存储位置分布及访问方法，操作需求，并给出对硬件和软件系统的约束。在设计过程中，只有在各种约束得到满足及确定方案可进行之后才能考虑效率问题。
3.6.3 物理设计的性能
在物理设计过程中，不能把单个性能作为唯一标准，而要对一组性能进行评价，在时间、空间、效率、维护开销和用户要求之间进行平衡。总的开销包括规划开销、设计开销、实施和测试开销、操作开销和运行维护开销。对物理设计者来说，操作开销是评价数据库设计好坏的重要标准之一。操作开销可分为如下几类。
查询和响应时间：响应时间定义为从查询开始到查询结果显示之间所经历的时间。它包括CPU服务时间、CPU队列等待时间、I/O队列等待时间、封锁延迟时间和通信延迟时间等。一个好的应用程序设计可以减少CPU服务时间和I/O服务时间。例如，如果有效地使用数据压缩技术，选择好访问路径和合理安排记录的存储等，都可以减少服务时间。
更新事务的开销：主要包括修改索引、重写物理块、校验等方面的开销。
报告生成的开销：主要包括检索、重组、排序和结果显示方面的开销。
主存储空间开销：包括程序和数据所占有的空间的开销。一般对数据库设计者来说，可以对缓冲区分配（包括缓冲区个数和大小）做适当的调整，以减少空间开销。
辅助存储空间开销：分为数据块和索引块两种空间。设计者可以控制索引块的大小，装载因子，数据冗余度等。
实际上，数据库设计者能有效地控制I/O服务和辅助空间；对封锁延迟时间，CPU时间和主存空间只能在一定范围内加以控制；而对CPU队列和I/O队列等待时间，数据通信延迟时间完全不能控制。
3.7 数据库的实施和维护
3.7.1 数据库的实施
根据逻辑设计和物理设计的结果在计算机上建立起实际数据库结构、装入数据、测试和运行的过程称为数据库的实施。这个阶段的主要工作所示。
（1）建立实际的数据库结构
用DBMS提供的数据定义语言编写建立在逻辑设计阶段产生的关系模式，用数据操纵语言和高级语言编写物理设计阶段产生的应用程序，执行程序后建立实际的数据库结构。
（2）试运行
装入试验数据对应用程序进行测试，以确认其功能和性能是否满足设计要求，并检查其空间的占用情况。
（3）装入实际数据
数据库中装入数据又称为数据库加载，建立起实际的数据库。在加载实际数据的过程中，还必须作好数据库的备份和恢复工作。
3.7.2 其他设计
其他设计工作包括数据库的安全性、完整性、并发性、一致性和可恢复性等的设计。这些设计总是以牺牲效率为代价的。设计人员的任务就是要在效率和尽可能多的功能之间进行合理权衡。
（1）故障恢复方案设计
数据库设计中考虑的故障恢复方案，一般都是基于DBMS系统提供的故障恢复手段。如果DBMS已提供了完善的软硬件故障恢复和存储介质的故障恢复手段，那么设计阶段的任务就简化为确定系统的物理参数，缓冲区大小，逻辑块的长度，物理设备等。否则，就要指定人工备份方案。
（2）安全性考虑
许多DBMS都有控制存取权限的机制。在设计时，根据对用户需求分析，规定相应的存取权限。子模式（视图）是实现安全性要求的一个重要手段。也可以在应用程序中设置密码，对不同的使用者给予一定的密码，以密码控制使用级别。
（3）事务控制
大多数DBMS都支持事务概念，以保证多用户环境下的数据完整性和一致性。事务控制有人工和系统两种控制方法：系统控制通常以数据操纵语言语句为单位，人工控制由程序员以事务的开始和结束语句显式实现。
（4）并发性控制
并发性控制有两种方法：一种是在应用程序中人工加以控制，另一种由DBMS系统提供的封锁机制加以控制。DBMS提供了封锁粒度的选择，封锁粒度一般有表级和行级。封锁粒度越大，控制越简单，并发性越差；封锁粒度越小，并发性越好。这些在设计中都要考虑。一般由DBMS提供的封锁机制进行并发性控制就可以。
3.7.3 运行与维护
数据库投入正式运行，标志着数据库设计和应用开发工作的结束和维护阶段的开始。本阶段的主要工作内容如下。
维护数据库的安全性和完整性：及时调整授权和修改密码。
检测并改善数据库性能：分析存储空间和响应时间，必要时进行再组织。
增加新的功能：对现有功能按用户需要进行扩充。
修改错误：发现错误，修改程序和数据的错误。
数据库的备份与恢复：数据库管理员要针对不同的应用要求制定不同的备份计划，以保证一旦发生故障尽可能快地将数据库恢复到一致的状态，减少对数据库的破坏。
数据库的再组织：数据库运行一段时间后，会降低数据的存取效率，数据库性能下降，这就要对数据库进行再组织。对数据库的概念结构、逻辑结构和物理结构的改变称为再组织（reorganization）。其中改变概念结构或逻辑结构又称为“再构造”（restructuring），改变物理结构称为“再格式化”（reformating）。再组织通常是由于环境需求的变化或性能原因而引起的。一般DBMS特别是RDBMS都提供数据库的再组织实用程序。
目前，随着DBMS功能和性能的提高，特别是在关系数据库系统中，物理设计的大部分功能和性能可由RDBMS来承担，所以选择一个合适的DBMS能使数据库物理设计变得十分简单。
小结
本章主要讨论数据库设计的方法和步骤，列举了许多实例；详细介绍数据库设计的各个阶段（包括系统规划、需求分析、概念设计、逻辑设计、物理设计、运行维护阶段）的目标、方法和应注意的事项。其中重点是概念结构设计和逻辑结构设计，这也是数据库设计过程中最重要的两个环节。
学习本章，要努力掌握书中讨论的基本方法，还要在实际工作中运用这些思想，设计出符合需求的数据库应用系统。
习题
1.数据库系统的设计分哪几个阶段？各个阶段完成的具体任务是什么？
2.数据库结构设计的任务是什么？分别形成的数据库模式是什么？
3.数据库设计过程的输入和输出内容有哪些？
4.数据库设计的规划阶段的主要任务是什么？
5.数据库设计的需求分析阶段的主要任务是什么？
6.数据字典的内容和作用是什么？
7.试述概念模型的特点和设计方法。
8.试述概念结构设计的步骤。
9.什么是E-R图？构成E-R图的基本要素是什么？
10.试述采用E-R方法进行数据库概念设计的三个过程。
11.逻辑结构设计的主要任务是什么？
12.关系数据库逻辑结构设计的主要步骤是什么？
13.将E-R图转换为关系模式的转换规则是什么？
14.试述数据库物理设计的主要任务和具体步骤。
15.试述数据库物理设计的主要任务。
16.解释下列术语。
函数依赖，部分函数依赖，完全函数依赖，传递函数依赖，1NF，2NF，3NF，BCNF。
17.建立关于系、学生、班级、社团等信息的一个关系数据库，一个系有若干个专业，每个专业每年只招一个班，每个班有若干学生，一个系的学生住在同一宿舍区，每个学生可以参加若干个社团，每个社团有若干学生。
描述学生的属性有：学号、姓名、出生年月、系名、班级号、宿舍区。
描述班级的属性有：班级号、专业名、系名、人数、入校年份。
描述系的属性有：系名、系号、系办公地点、人数。
描述社团的属性有：社团名、成立年份、地点、人数、学生参加某社团的年份。
请画出E-R图，并将E-R图转换成关系模式，写出每个关系模式的最小函数依赖集，指出是否存在传递函数依赖，讨论是完全函数依赖，还是部分函数依赖。指出各关系模式的主键和外键。
18.关系模式R（S#，C#，GRADE，TNAME，TADDR），其属性分别表示学生学号、选修课程的编号、成绩、任课教师姓名、教师地址等意义。
如果规定，每个学生每学一门课只有一个成绩；每门课只有一个教师任教；每个教师只有一个地址（不允许教师同姓同名）。完成以下操作。
（1）写出关系模式R基本的函数依赖和主键。
（2）试把R分解成2NF模式集，并说明理由。
（3）试把R分解成3NF模式集，并说明理由。
19.假定一个生产销售产品的数据库包括以下信息。
职工的信息：职工号、姓名、住址、所在部门名称。
部门的信息：部门名称、部门经理、销售的产品名称、销售数量。
产品的信息：产品名称、制造商名称、价格、型号、产品内部编号。
制造商的信息：制造商名称、地址、生产的产品名称。
其中，一个部门有若干职工，但一个职工只属于一个部门，一个部门可以销售多种产品，一个产品可以在多个部门销售，一个产品可以由多个制造商生产，一个制造商可以生产多种产品。
试画出该数据库的E-R图，并将E-R图转换成关系模式，指出各关系模式的主键和外键。
20.一个图书借阅管理数据库要求提供下述服务。
（1）可随时查询书库中现有书籍的品种、数量、存放位置，所有各类书籍均可由书号唯一标识。
（2）随时查询书籍借还情况，包括借书人单位、姓名、借书证号、借书日期、还书日期。
我们约定：任何人可借多种书，任何一种书可为多个人所借，借书证号具有唯一性。
（3）当需要时，可通过数据库中保存的出版社的电报编号、电话、邮编、地址等信息向有关书籍的出版社增购有关书籍。我们约定：一个出版社可出版多种书籍，同一本书仅由一个出版社出版，出版社名具有唯一性。
根据以上假设，画出满足需求的E-R图，并将E-R图转换成关系模式，指出各关系模式的主键和外键。