|
|
|
在数据库系统方面，主要考查数据库的一些基本概念、SQL语言、E-R模型等。
|
|
|
|
|
|
|
|
|
|
概念模式（模式、逻辑模式）用以描述整个数据库中数据库的逻辑结构，描述现实世界中的实体及其性质与联系，定义记录、数据项、数据的完整性约束条件及记录之间的联系，是数据项值的框架。概念模式通常还包含有访问控制、保密定义、完整性检查等方面的内容，以及概念／物理之间的映射。
|
|
|
|
概念模式是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。一个数据库只有一个概念模式。
|
|
|
|
|
|
外模式（子模式、用户模式）用以描述用户看到或使用的那部分数据的逻辑结构，用户根据外模式用数据操作语句或应用程序去操作数据库中的数据。外模式主要描述组成用户视图的各个记录的组成、相互关系、数据项的特征、数据的安全性和完整性约束条件。
|
|
|
|
外模式是数据库用户（包括程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。一个数据库可以有多个外模式。一个应用程序只能使用一个外模式。
|
|
|
|
|
|
内模式是整个数据库的最低层表示，不同于物理层，它假设外存是一个无限的线性地址空间。内模式定义的是存储记录的类型、存储域的表示、存储记录的物理顺序，指引元、索引和存储路径等数据的存储组织。
|
|
|
|
内模式是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。一个数据库只有一个内模式。
|
|
|
|
|
|
|
|
|
|
（3）外模式面向具体的应用，独立于内模式和存储设备。
|
|
|
|
|
|
|
|
数据库系统两级独立性是指物理独立性和逻辑独立性。三级模式之间通过两级映射（外模式／模式映射，模式／内模式映射）进行相互转换，使得数据库的三级形成一个统一的整体。
|
|
|
|
（1）物理独立性。物理独立性是指用户的应用程序与存储在磁盘上的数据库中的数据是相互独立的。当数据的物理存储改变时，应用程序不需要改变。物理独立性存在于概念模式和内模式之间的映射转换，说明物理组织发生变化时应用程序的独立程度。
|
|
|
|
（2）逻辑独立性。逻辑独立性是指用户的应用程序与数据库中的逻辑结构是相互独立的。当数据的逻辑结构改变时，应用程序不需要改变。逻辑独立性存在于外模式和概念模式之间的映射转换，说明概念模式发生变化时应用程序的独立程度。
|
|
|
|
|
|
|
|
数据模型主要有两大类：概念数据模型（实体联系模型）和基本数据模型（结构数据模型）。
|
|
|
|
|
|
概念数据模型是按照用户的观点来对数据和信息建模，主要用于数据库设计。概念模型主要用实体联系方法表示，所以也称E-R模型。
|
|
|
|
|
|
基本数据模型是按照计算机系统的观点对数据和信息建模，主要用于DBMS的实现。基本数据模型是数据库系统的核心和基础。基本数据模型通常由数据结构、数据操作和完整性约束三部分组成。其中数据结构是对系统静态特性的描述，数据操作是对系统动态特性的描述，完整性约束是一组完整性规则的集合。
|
|
|
|
常用的基本数据模型有层次模型、网状模型、关系模型和面向对象模型。
|
|
|
|
层次模型用树型结构表示实体类型及实体间联系。层次模型的优点是记录之间的联系通过指针来实现，查询效率较高。层次模型的缺点是只能表示1:n联系，虽然有多种辅助手段实现m:n联系，但较复杂，用户不易掌握。由于层次顺序的严格和复杂，使得数据的查询和更新操作很复杂，应用程序的编写也比较复杂。
|
|
|
|
网状模型用有向图表示实体类型及实体间联系。网状模型的优点是记录之间的联系通过指针实现，m×n联系也容易实现，查询效率高。其缺点是编写应用程序比较复杂，程序员必须熟悉数据库的逻辑结构。
|
|
|
|
关系模型用表格结构表达实体集，用外键表示实体间联系，其优点有：
|
|
|
|
|
|
（2）概念单一（关系），结构简单、清晰，用户易懂易用。
|
|
|
|
（3）存取路径对用户透明，从而数据独立性、安全性好，简化数据库开发工作。
|
|
|
|
关系模型的缺点主要是由于存取路径透明，查询效率往往不如非关系数据模型。
|
|
|
|
|
|
关系中的每个元素是关系中的元组，通常用t表示。关系是笛卡儿积的子集，所以关系也是一个二维表，表的每行对应一个元组，表的每列对应一个域。由于域可以相同，为了加以区分，必须为每列起一个名字，称为属性。
|
|
|
|
派生属性是指可以由其他属性经过运算得到的属性，因而派生属性会产生冗余，通常不存储。例如，如果某关系中有年龄、出生日期这两个属性，则年龄就是派生属性，因为可用出生年月计算出年龄的值。
|
|
|
|
多值属性（组合属性）是指可同时由多个值表示的属性。例如，包含关于员工信息的关系可能包含关于员工兴趣的数据。一个员工可能有多个兴趣，例如运动、电影、投资、烹调等，并且这些值的任何一个或所有这些值可能同时是某一个员工的兴趣。
|
|
|
|
关系的度是指关系中属性的个数，关系的势是指关系中元组的个数。关系中的不同属性可以在相同的域中取值，属性的个数与域的个数并不相同。
|
|
|
|
关系可以有三种类型：基本关系（通常又称为基本表或基表）、查询表和视图表。基本表是实际存在的表，它是实际存储数据的逻辑表示。查询表是查询结果对应的表。视图表是由基本表或其他视图表导出的表，是虚表，不对应实际存储的数据。
|
|
|
|
|
|
（1）列是同质的，即每一列中的分量是同一类型的数据，来自同一个域。
|
|
|
|
（2）不同的列可出自同一个域，称其中的每一列为一个属性，不同的属性要给予不同的属性名。
|
|
|
|
|
|
（4）任意两个元组不能完全相同。但在大多数实际关系数据库产品中，例如Oracle等，如果用户没有定义有关的约束条件，它们都允许关系表中存在两个完全相同的元组。
|
|
|
|
|
|
（6）分量必须取原子值，即每一个分量都必须是不可分的数据项。
|
|
|
|
关系的描述称为关系模式。一个关系模式应当是一个五元组，它可以形式化地表示为R（U，D，DOM，F）。其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，DOM为属性向域的映像集合，F为属性间数据的依赖关系集合。关系模式通常可以简记为R（A1，A2，…，An）。其中R为关系名，A1，A2，…，An为属性名。
|
|
|
|
关系实际上就是关系模式在某一时刻的状态或内容。也就是说，关系模式是型，关系是它的值。关系模式是静态的、稳定的，而关系是动态的、随时间不断变化的，因为关系操作在不断地更新着数据库中的数据。但在实际当中，常常把关系模式和关系统称为关系，读者可以从上下文中加以区别。
|
|
|
|
在关系模型中，实体及实体间的联系都是用关系来表示的。在一个给定的现实世界领域中，相应于所有实体及实体之间的联系的关系集合构成一个关系数据库。
|
|
|
|
关系数据库也有型和值之分。关系数据库的型也称为关系数据库模式，是对关系数据库的描述，是关系模式的集合。关系数据库的值也称为关系数据库，是关系的集合。关系数据库模式与关系数据库通常统称为关系数据库。
|
|
|
|
|
|
SQL-86是第一个SQL标准，后续的有SQL-89、SQL-92（SQL2）和SQL-99（SQL3）等。但作为考试而言，所考查的是一些基本的语法知识。
|
|
|
|
|
|
SQL语言使用动词CREATE定义基本表，其具体语法格式如下：
|
|
|
|
|
|
在这个语句中，主要考查一些约束条件。有关这方面的知识请参考第7章的7.4.3节。
|
|
|
|
|
|
|
|
|
|
在这个语句中，主要考查各种条件，包括GROUP BY、HAVING等，以及考查IN和EXISTS的区别。另外，还要掌握有关集函数的应用。
|
|
|
|
|
|
|
|
.COUNT（[DISTINCT|ALL]*）：统计元组个数。
|
|
|
|
.COUNT（[DISTINCT|ALL]<列名>）：统计一列中值的个数。
|
|
|
|
.SUM（[DISTINCT|ALL]<列名>）：计算一列值的总和（必须是数值型）。
|
|
|
|
.AVG（[DISTINCT|ALL]<列名>）：计算一列值的平均值（必须是数值型）。
|
|
|
|
.MAX（[DISTINCT|ALL]<列名>）：求一列值中的最大值。
|
|
|
|
.MIN（[DISTINCT|ALL]<列名>）：求一列值中的最小值。
|
|
|
|
集函数只能在SELECT子句和HAVING子句中使用，其他子句中不能使用集函数。
|
|
|
|
|
|
GROUP BY指定用来放置输出行的组。如果SELECT子句“目标列表达式”中包含聚合函数，则GROUP BY将计算每组的汇总值。指定GROUP BY时，选择列表中任意非聚合表达式内的所有列都应包含在GROUP BY列表中，或者GROUP BY表达式必须与选择列表表达式完全匹配。
|
|
|
|
如果没有GROUP BY子句，则SQL列函数应用程序返回一行数据。当使用GROUP BY时，会对每个组运用函数，所以所返回的行数与分组数相同。
|
|
|
|
当使用GROUP BY子句时，SQL将选出的行按照是否符合表达式的值或者是否符合某一列或多列的值进行分组。接下来，SQL处理每一组，从而为每组生成一行结果。在GROUP BY子句中，可以指定一列或多列或者表达式来对行进行分组。在SELECT语句中指定的项具有由行组成的每一组的属性，而不具备表中或视图中单个行的属性。
|
|
|
|
例如，EMPLOYEE表有几组行，每一组中的这些行描述了某个特定部门的成员。为了查出每个部门中人员的平均薪水，可以写这样的SQL语句：
|
|
|
|
|
|
|
|
如果在GROUP BY子句中指定的列为空值，则会生成只有一行的结果，行中数据为空值。也可以将行按照多列或按照表达式进行分组。例如，使用CORPDATA.EMPLOYEE表编写一条查找每个部门男性员工和女性员工平均薪水的SELECT语句。为了实现这一点，可以这样做：
|
|
|
|
|
|
|
|
HAVING子句指定组或聚合应满足的搜索条件。当HAVING与GROUP BY ALL一起使用时，HAVING子句优于ALL。
|
|
|
|
HAVING子句对GROUP BY子句设置条件的方式与WHERE子句和SELECT语句交互的方式类似。WHERE子句搜索条件在进行分组操作之前应用，而HAVING子句搜索条件在进行分组操作之后应用。HAVING语法与WHERE语法类似，但HAVING子句可以包含聚合函数。HAVING子句可以引用选择列表中出现的任意项。
|
|
|
|
下面的查询得到本年度截止到目前的销售额超过40000的出版商：
|
|
|
|
|
|
HAVING子句用来从分组的结果中筛选行。对于可以在分组操作之前或之后应用的搜索条件，在WHERE子句中指定它们更有效。这样可以减少必须分组的行数。应当在HAVING子句中指定的搜索条件只是那些必须在执行分组操作之后应用的搜索条件。
|
|
|
|
|
|
在WHERE子句的条件表达式中可以使用算术比较运算符号，对于字符型数据，可以使用LIKE关键词以及通配符。例如，要查找姓李的学生的学号和姓名的SQL语句如下：
|
|
|
|
|
|
这里的“%”就是一个通配符，代表0个或多个字符。例如，要查找某个属性中包含“软考在线”的元组，则可以写成“…LIKE'%软考在线%'”。
|
|
|
|
还有一个通配符是“_”（下划线），这个通配符只代表1个字符。例如，要查找某个属性中第2个字和第3个字是“软考在线”，倒数第2个字和第3个字包含“教育”的元组，则可以写成“…LIKE'_软考在线%教育_'”。
|
|
|
|
|
|
视图不真正存在数据，只是把定义存于数据字典，在对视图进行查询时，才按视图的定义从基本表中将数据查出。若一个视图是从单个基本表导出的，并且只是去掉了基本表的某些行和某些列，但保留了码，则这个视图称为行列子集视图。
|
|
|
|
视图对应了数据库系统三级模式／两级映象中的外模式，重建视图即是修改外模式及外模式／模式映象，实现了数据的逻辑独立性。在DBMS中，视图的作用如下：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
其中With Check Option表示对视图进行Update、Insert和Delete操作时，要保证更新、插入或删除的行满足视图定义中的谓词条件。
|
|
|
|
|
|
|
|
因为视图没有真实数据，所以对视图的查询要转换为对相应表的查询，这个过程叫视图消解，视图消解过程由DBMS自动完成。
|
|
|
|
|
|
数据库的完整性是指数据的正确性和相容性。数据库是否具备完整性关系到数据库系统能否真实地反映现实世界，因此维护数据库的完整性是非常重要的。
|
|
|
|
数据库的完整性可分为实体完整性、参照完整性和用户定义的完整性。
|
|
|
|
|
|
实体完整性是基于主码的，一个主码由一个或多个属性组成。实体完整性要求主码中的任一属性（列）不能为空，所谓空值是“不知道”或“无意义”的值。之所以要保证实体完整性，主要是因为在关系中每一个元组的区分是依据主码值的不同，若主码值取空值，则不能标明该元组的存在。
|
|
|
|
|
|
参照完整性是基于外码的，若基本关系R中含有与另一基本关系S的主码PK相对应的属性组FK（FK称为R的外码），则参照完整性要求对R中的每个元组在FK上的值必须是S中某个元组的PK值，或者为空值。
|
|
|
|
参照完整性的合理性在于R中的外码只能引用S中的主码，不能是S中主码没有的值。如学生和选课表两关系，选课表中的学号是外码，它是学生表的主键，若选课表中出现了某个学生表中没有的学号，即某个学生还没有注册，却已有了选课记录，这显然是不合理的。
|
|
|
|
|
|
|
|
|
|
.级联删除：将参照关系中所有外码值与被参照关系中要删除元组主码值相同的元组一起删除。如果参照关系同时又是另一个关系的被参照关系，则这种删除操作会继续级联下去。
|
|
|
|
.受限删除（一般系统默认）：仅当参照关系中没有任何元组的外码值与被参照关系中要删除元组的主码值相同时，系统才可以执行删除操作，否则拒绝执行删除操作。
|
|
|
|
.置空删除：删除被参照关系的元组，并将参照关系中相应元组的外码值置为空值。
|
|
|
|
|
|
.受限插入：仅当被参照关系中存在相应的元组，其主码值与参照关系插入元组的外码值相同时，系统才执行插入操作，否则拒绝此操作。
|
|
|
|
.递归插入：首先向被参照关系中插入相应的元组，其主码值等于参照关系插入元组的外码值，然后向参照关系插入元组。
|
|
|
|
|
|
实体完整性和参照完整性适用于任何关系数据库系统。除此之外，不同的关系数据库系统根据其应用环境的不同，往往还需要一些特殊的约束条件。用户定义的完整性就是针对某一具体关系数据库的约束条件，它反映某一具体应用所涉及的数据必须满足的语义要求。
|
|
|
|
如果在一条语句执行完后立即检查，则称立即执行约束；如果在整个事务执行结束后再进行检查，则称延迟执行约束。
|
|
|
|
|
|
触发器（Trigger）是在关系数据库管理系统中应用得比较多的一种完整性保护措施。触发器的功能一般比完整性约束要强得多。一般而言，在完整性约束功能中，当系统检查出数据中有违反完整性约束条件时，仅给出必要提示以通知用户，仅此而已。而触发器的功能则不仅仅起提示作用，它还会引起系统内自动进行某些操作以消除违反完整性约束条件所引起的负面影响。
|
|
|
|
在目前数据库中事件一般表示为数据的插入、修改、删除等操作。触发器除了有完整性保护功能外，还有安全性保护功能。
|
|
|
|
|
|
非空是一个规则，是对声明了非空约束的字段限制其取值域不能为空。它不允许在对一列的数据插入或更新时取NULL值。在默认情况下，所有的列都是允许填充NULL值的，只有在列声明了NOT NULL的列值或其他已经包含了NOT NULL约束的列值时，系统强制要求任何时候都不能填充NULL值。非空约束通常会包含在相关的其他约束上，如主键约束、候选键约束等。因为索引是不对NULL值进行存储的，所以，如果希望使用索引进行表数据的查询，那么必须尽量地使某个要索引的列不包含NULL值。例如，下面语句对emp表的ename字段声明了非空约束。
|
|
|
|
|
|
对于表emp，如果已经有了数据，而且ename列中已存在NULL值，则该操作将被禁止。只要将空值替换或将对应的行删除，该语句还是可以被允许的。当然，对于不明确的列但又不能为空时，可以使用默认值（default）对列值做默认处理，这样也可以远离NULL值对列的影响。
|
|
|
|
|
|
相对于非空约束，CHECK约束能更灵活地限制某字段取值的值域。客观地说，非空约束只是CHECK约束的一个特例而已。CHECK约束需要设计一个表达式，某条记录的某（些）字段的值如果使这个表达式为假，则这条记录被禁止；反之则被允许。如果定义一个CHECK约束设计一个字段不为空的表达式，那么效果就跟非空约束一样了。CHECK约束设计的表达式具体应用到某条将要进行操作的记录的某（些）字段时，只有三个值——true、false、unknown，表达式值为false时将要进行的操作被禁止，其他的则允许。在CHECK约束的表达式中有如下要求：
|
|
|
|
（1）该表达式在使用数据插入或更新操作的值时，必须是可以做出逻辑判断的表达式。
|
|
|
|
|
|
|
|
|
|
（5）该表达式不可以使用DBMS的伪字段（比如Oracle中的rownum、level等）。
|
|
|
|
下面语句说明如何在创建表的语句中声明CHECK约束。
|
|
|
|
|
|
该语句为表Dept_tab中的Loc字段声明了名为Loc_check1的CHECK约束，这个约束要求Loc字段只能填写北京、上海、广州中的一个，否则操作将被禁止。
|
|
|
|
|
|
主键是能唯一标识元组的最小属性集，并且是在数据库中被标记为primary key的属性集。如果某个表的某（些）字段声明为主键，那么这些字段就要遵守如下两条规则。
|
|
|
|
（1）在这些作为主键的字段中任何字段任何行都不能为空。
|
|
|
|
（2）在这些作为主键的字段中任何两行之间的组合取值不能重复。
|
|
|
|
|
|
|
|
该语句在表dept中声明了字段deptno为该表的主键，这个主键约束并未命名，它的名称可以由系统自动产生。再看下面的语句：
|
|
|
|
|
|
该语句在表emp中声明了字段empno为主键，同时命名该主键约束为epk。
|
|
|
|
|
|
能唯一标识元组的最小属性集，但在数据库中未被标记为PRIMARY KEY，这样的属性集称为候选键。这里的候选键实质就是唯一性约束。它的规则要求与主键的规则要求一样，只是未被声明为主键而已。标准SQL并没有直接定义候选键，候选键取值不能为空和不取重复值的约束可以通过UNIQUE NOT NULL来实现，也可以通过UNIQUE KEY来实现，具体要根据不同的DBMS而定。下列语句在创建表中声明了候选键约束。
|
|
|
|
|
|
该语句为表emp的empno字段声明了一个叫euk的唯一性约束。
|
|
|
|
|
|
外键是指在关系模式R中作为候选键的属性集，但在关系模式T中不是候选键。则对于T来说，这些属性集称为相对于R的外键。通常外键在数据库中会被标记为FOREIGN KEY字样。在这里，称R为父模式，T为子模式。通俗地说，就是父表中的主键字段被子表中某个字段引用，那么子表的这个字段则应声明为外键，而父表的那个字段可以声明为主键，也可以声明为唯一键（候选键）。一旦子表的字段被声明为父表的外键，同样的一个字段在父表中称为引用的父键，在子表中称为引用的子键。子键的取值应遵守如下规则，否则将被禁止。
|
|
|
|
（1）每个子键的取值不能取父键中取值以外的值，但空除外。
|
|
|
|
（2）对于父键是组合字段的，子键也应是组合字段。父键要求能唯一地标识父表的每一条记录，而子键不要求能唯一标识子表的每一条记录。
|
|
|
|
（3）对于组合键，子键为空时，所有键的成员字段都为空，不允许部分为空。
|
|
|
|
一个子表可以有多个子键，每个子键可以对应不同父表的父键。如果是组合键，那么同一个字段可能作为不同外键的成员。当然，子表和父表是相对的，子表如果有唯一键被其他表引用，那么这时的子表对于其他表关于某键，它又是父表。外键的引入，主要是为了表示表间的一对多问题。下面的语句说明了两个表间的外键引用情况。
|
|
|
|
|
|
这两条语句创建了dept和emp两个表，其中dept表中的deptno是它的主键，它被表emp引用。在emp中也有个同样名字的deptno字段，这个字段被声明为引用dept.deptno字段的外键。那么dept表是父表，deptno构成了引用中父表的父键；emp表是子表，deptno构成了引用中子表的子键。
|
|
|
|
因为外键是引用父表父键的子表的子键，所以父表的数据是引用的基础。一旦父表数据被修改或删除，引用也会造成相关的影响，表现在子表和子键上，这就需要做出相应的规则来约定父表父键发生改动后子表子键如何来进行维护活动。根据这种活动，将子表的外键分为三大类。
|
|
|
|
（1）禁止更新和删除父键，许多DBMS默认为这一类外键约束。一旦父表的父键被某个子表的子键引用了，那么父表中已有的数据是禁止修改和删除的。
|
|
|
|
（2）删除或更新父表数据的同时删除或更新子表子键中对应父键取值的行。
|
|
|
|
（3）删除或更新父表数据的同时将子表中对应父键的子键的取值设置为NULL。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
本知识点主要考查E-R图的画法，各实体之间的关系，如何消除冲突，E-R图向关系模式的转换等。
|
|
|
|
|
|
E-R模型（实体联系模型）简称E-R图，它是描述概念世界，建立概念模型的实用工具。E-R图包括如下三个要素。
|
|
|
|
（1）实体（型）：用矩形框表示，框内标注实体名称。
|
|
|
|
（2）属性：用椭圆形表示，并用连线与实体连接起来。
|
|
|
|
（3）实体之间的联系：用菱形框表示，框内标注联系名称，并用连线将菱形框分别与有关实体相连，并在连线上注明联系类型。
|
|
|
|
例如，下图就是一个教学系统的E-R图（为了简单起见，省略了部分实体的属性和联系的属性）。
|
|
|
|
|
|
|
|
|
|
（1）一对一联系（1:1）。设A、B为两个实体集。若A中的每个实体至多和B中的一个实体有联系，反过来，B中的每个实体至多和A中的一个实体有联系，称A对B或B对A是1:1联系。注意，1:1联系不一定都是一一对应的关系，可能存在着无对应。例如，在上图中，一个班只有一个班主任，一个班主任不能同时在其他班再兼任班主任，由于老师紧缺，某个班的班主任也可能暂缺。
|
|
|
|
（2）一对多联系（1:n）。如果A实体集中的每个实体可以和B中的几个实体有联系，而B中的每个实体和A中的一个实体有联系，那么A对B属于1:n联系。例如，在上图中，一个班级有多个学生，而一个学生只能编排在一个班级，班级与学生属于一对多的联系。
|
|
|
|
（3）多对多联系（m:n）。若实体集A中的每个实体可以和B中的多个实体有联系，反过来，B中的每个实体也可以与A中的多个实体有联系，称A对B或B对A是m:n联系。例如，在上图中，一个学生可以选修多门课程，一门课程由多个学生选修，学生和课程间存在多对多的联系。
|
|
|
|
必须强调指出，有时联系也有属性，这类属性不属于任一实体，只能属于联系。
|
|
|
|
|
|
在数据库的概念结构设计过程中，先设计各子系统的局部E-R图，设计过程可分为以下几个步骤：
|
|
|
|
|
|
|
|
|
|
|
|
各子系统的局部E-R图设计好后，下一步就是将所有的分E-R图综合成一个系统的总体E-R图，一般称为视图的集成。视图集成通常有两种方式：
|
|
|
|
（1）多个局部E-R图一次集成。这种方式比较复杂，做起来难度较大。
|
|
|
|
（2）逐步集成，用累加的方式一次集成两个局部E-R图。这种方式每次只集成两个局部E-R图，可以降低复杂度。
|
|
|
|
由于各子系统应用所面临的问题不同，且通常是由不同的设计人员进行局部视图设计，这就导致各个局部E-R图之间必定会存在许多不一致的问题，称之为冲突。因此合并分E-R图时并不能简单地将各个局部E-R图画到一起，而是必须着力消除各个局部E-R图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。
|
|
|
|
|
|
（1）属性冲突。包括属性域冲突和属性取值冲突。属性冲突理论上好解决，只要换成相同的属性就可以了，但实际上需要各部门协商，解决起来并不简单。
|
|
|
|
（2）命名冲突。包括同名异义和异名同义。处理命名冲突通常也像处理属性冲突一样，通过讨论和协商等行政手段加以解决。
|
|
|
|
（3）结构冲突。包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。对于前者的解决办法是把属性变换为实体或实体变换为属性，使同一对象具有相同的抽象。对于后者的解决办法是使该实体的属性取各局部E-R图中属性的并集，再适当调整属性的次序。
|
|
|
|
另外，实体间的联系在不同的局部E-R图中可能为不同的类型，其解决方法是根据应用的语义对实体联系的类型进行综合或调整。
|
|
|
|
在初步的E-R图中，可能存在一些冗余的数据和实体间冗余的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，应当予以消除。消除冗余的主要方法为分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
|
|
|
|
|
|
|
|
（1）一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的码（关键字）就是关系的码。
|
|
|
|
（2）一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选键。如果与某一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
|
|
|
|
（3）一个1:n联系可以转换为一个独立的关系模式，也可以与任意n端对应的关系模式合并。如果转换为一个独立的模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。如果与n端实体对应的关系模式合并，则需要在该关系模式的属性中加入1端关系模式的码和联系本身的属性。
|
|
|
|
（4）一个m:n联系转换为一个独立的关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
|
|
|
|
（5）三个以上实体间的一个多元联系可以转换为一个独立的关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。
|
|
|
|
|
|
（1）多值属性的处理。如果E-R图中某实体具有一个多值属性，则应该进行优化，把该属性提升为一个实体。或者在转化为关系模式时，将实体的码与多值属性单独构成一个关系模式。
|
|
|
|
（2）BLOB型属性的处理。典型的BLOB是一张图片或一个声音文件，由于它们的容量比较大，必须使用特殊的方式来处理。处理BLOB的主要思想就是让文件处理器（如数据库管理器）不去理会文件是什么，而是关心如何去处理它。因此，从优化的角度考虑，应采用的设计方案是将BLOB字段与关系的码独立为一个关系模式。
|
|
|
|
（3）派生属性的处理。因为派生属性可由其他属性计算得到，因此，在转化成关系模式时，通常不转换派生属性。
|
|
|
|
（4）在对象-关系数据模型中，本章的“关系模式”就对应“类”，关系模式的属性就对应类的属性。
|
|
|
