概念结构设计重点在于信息结构的设计，而“处理”则由行为设计来考虑。概念结构设计使用集合概念，抽取现实业务系统的元素及其应用语义关联，最终形成E－R模型。图6—2自顶向下需求分析、自底向上概念结构设计图6—3自底向上的概念结构设计2.采用E－R模型的概念结构设计设计数据库概念结构的最著名、最常用的是E－R模型。数据抽象与局部E－R图设计概念结构是对现实世界的一种抽象。......
2023-11-24
数据库技术与应用教程-逻辑结构设计
【摘要】：逻辑结构设计一般包含三项工作。关系模型的逻辑结构是一组关系模式的集合。
逻辑结构设计的任务是把在概念结构设计产生的概念模型转换为具体的数据库管理系统支持的组织层数据模型，也就是导出特定的DBMS可以处理的数据库逻辑结构（数据库的模式和外模式），这些模式在功能、性能、完整性和一致性约束方面满足应用要求。
特定DBMS可以支持的组织层数据模型包括层次模型、网状模型、关系模型和面向对象模型等。下面仅讨论从E－R模型向关系模型的转换。
逻辑结构设计一般包含三项工作。
·将概念结构转换为关系数据模型。
·对关系数据模型进行优化。
·设计面向用户的外模式。
1.E－R模型向关系模型的转换
E－R模型向关系模型的转换要解决的问题，是如何将实体以及实体间的联系转换为关系模式，如何确定这些关系模式的属性和主码。
关系模型的逻辑结构是一组关系模式的集合。E－R模型由实体、实体的属性以及实体之间的联系三部分组成，因此将E－R模型转换为关系模型实际上就是将实体、实体的属性和实体间的联系转换为关系模式，转换的一般规则如下。
一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的主码。
对于实体间的联系有以下不同的情况。
（1）一个1∶1联系可以转换为一个独立的关系模式，也可以与任意一端所对应的关系模式合并。如果可以转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为此关系模式的属性，每个实体的码均是该关系模式的候选键。如果是与联系的任意一端实体所对应的关系模式合并，则需要在该关系模式的属性中加入另一个实体的码和联系本身的属性。
（2）一个1∶n联系可以转换为一个独立的关系模式，也可以与n端所对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为此关系模式的属性，且关系模式的码为n端实体的码。如果与n端对应的关系模式合并，则需要在该关系模式中加入1端实体的码以及联系本身的属性。
（3）一个m∶n联系必须转换为一个独立的关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为此关系模式的属性，且关系模式的主码包含各实体的码。
（4）三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为此关系模式的属性，而此关系模式的主码包含各实体的码。
（5）具有相同主码的关系模式可以合并。
【例6－1】有1∶1联系的E－R模型如图6－16所示，如果将联系与某一端的关系模式合并，则转换后的结果为如下两个关系模式。
图6—16 1∶1联系示例
部门（部门号，部门名，经理号），其中“部门号”为主码，“经理号”为引用“经理”关系模式的外码。
经理（经理号，经理名，电话），其中“经理号”为主码。
或者也可以转换为以下两个关系模式：
部门（部门号，部门名），其中“部门号”为主码。
经理（经理号，部门号，经理名，电话），“经理号”为主码，“部门号”为引用“部门”关系模式的外码。
如果将联系转换为一个独立的关系模式，则该E－R模型可以转换成三个关系模式：
部门（部门号，部门名），其中“部门号”为主码。
经理（经理号，经理名，电话），其中“经理号”为主码。
部门经理（经理号，部门号），其中“经理号”和“部门号”为候选键，同时也都为外码。
在1∶1联系中一般不将联系单独作为1个关系模式，因为这样转换出来的关系模式个数太多，相应的关系表也就越多。查询时涉及的表个数越多，查询效率就越低。
【例6－2】有l∶n联系的E－R模型如图6－17所示，如果与n端的关系模式合并，则可以转换成两个关系模式。
图6—17 l∶n联系示例
部门（部门号，部门名），其中“部门号”为主码。
职工（职工号，部门号，职工名，工资），其中“职工号”为主码，“部门号”为引用“部门”关系模式的“部门号”的外码。
如果将联系转换为一个独立的关系模式，则该E－R模型可以转换为以下三个关系模式：
部门（部门号，部门名），其中“部门号”为主码。
职工（职工号，职工名，工资），其中“职工号”为主码。
部门职工（部门号，职工号），其中“职工号”为主码，同时也为引用“职工”关系模式的“职工号”的外码，“部门号”为引用“部门”关系模式的“部门号”的外码。
同1∶1联系一样，在l∶n联系中，一般也不将联系转换为一张独立的关系模式。
【例6－3】有m∶n联系的E－R模型如图6－18所示，对于m∶n联系，必须将联系转换为一个独立的关系模式。转换后的结果为：
教师（教师号，教师名，职称），“教师号”为主码。
课程（课程号，课程名，学分），“课程号”为主码。(www.chuimin.cn)
授课（教师号，课程号，授课时数），（教师号，课程号）为主码，同时“教师号”为引用“教师”关系模式的教师号的外码，“课程号”为引用“课程”关系模式的课程号的外码。
图6—18 m∶n联系示例
【例6－4】设有如图6－19所示的含多个实体间联系的E－R图，这种联系一般情况下也被转换为一个独立的关系模式，而且在联系产生的关系模式中，其主码至少包含其关联实体所对应的关系模式的主码。图E－R图转换后的关系模式如下。
图6—19 含多个实体的E—R模型
营业员（职工号，姓名，出生日期），职工号为主码。
商品（商品编号，商品名称，单价），商品编号为主码。
顾客（身份证号，姓名，性别），身份证号为主码。
销售（职工号，商品编号，身份证号，销售数量，销售时间），（职工号，商品编号，身份证号，销售时间）为主码，职工号为引用“营业员”关系模式的外码，商品编号为引用“商品—关系”模式的外码，身份证号为引用“顾客”关系模式的外码。
2.数据模型的优化
逻辑结构设计的结果并不是唯一的，为了进一步提高数据库应用系统的性能，还应该根据应用的需要对逻辑数据模型进行适当的修改和调整，这就是数据模型的优化。关系数据模型的优化通常以关系规范化理论为指导.并考虑系统的性能。具体方法如下。
（1）确定各属性间的函数依赖关系，根据需求分析阶段得出的语义，分别写出每个关系模式的各属性之间的函数依赖以及不同关系模式中各属性之间的数据依赖关系。
（2）对各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。
（3）判断每个关系模式的范式，根据实际需要确定最合适的范式。
（4）根据需求分析阶段得到的处理要求，分析这些模式对于这样的应用环境是否合适，确定是否要对某些模式进行分解或合并。
注意：如果系统的查询操作比较多，而且对查询响应速度的要求也比较高，则可以适当地降低规范化的程度，即将几个表合并为一个表，以减少查询时的表的连接个数。甚至可以在表中适当增加冗余数据列，比如把一些经过计算得到的值作为表中的一个列也保存在表中。但这样做时要考虑可能引起的潜在的数据不一致的问题。
对于一个具体的应用来说，到底规范化到什么程度，需要权衡响应时间和潜在问题两者的利弊，做出最佳的决定。
（5）对关系模式进行必要的分解，以提高数据的操作效率和存储空间的利用率。常用的分解方法是水平分解和垂直分解。
水平分解是以时间、空间、类型等范畴属性取值为条件，满足相同条件的数据行为一个子表。分解的依据一般以范畴属性取值范围划分数据行。这样在操作同表数据时，时空范围相对集中，便于管理。水平分解过程如图6－20所示，其中K＃代表关系模式的主码。
图6—20 水平分解示意图
原表中的数据内容相当于分解后各表数据内容的并集。例如，对于管理学校学生情况的“学生”关系模式，可以将其分解为“历史学生”和“在册学生”两个关系模式。“历史学生”中存放已毕业学生的数据，“在册学生”存放目前在校学生的数据。因为经常需要了解当前在校学生的情况，而对已毕业学生的情况关心较少。因此，将历年学生的信息存放在两个关系模式中，可以提高对在校学生的处理速度。当一届学生毕业时，就将这些学生从“在册学生”关系中删除，同时插入“历史学生”关系中。
垂直分解是以非主属性所描述的数据特征为条件，描述一类相同特征的属性划分在一个子表中。这样操作同表数据时属性范围相对集中，便于管理。垂直分解过程如图6－21所示，其中K＃代表关系模式的主码。
图6—21 垂直分解示意图
垂直分解后原关系中的数据内容相当于分解各关系数据内容的连接。例如，可以将，“学生”关系模式垂直拆分为“学生基本信息”和“学生家庭信息”两个关系模式。
垂直分解方法还可以解决包含很多列或者列占用空间比较多的表创建问题。一般在数据库管理系统中，表中一行数据的大小（即各列所占的空间总和）都是有限制的（一般受数据页大小的限制），当表中一行数据的大小超过了数据页大小时，就可以使用垂直分解方法，将一个关系模式拆分为多个关系模式。
3.设计外模式
将概念模型转换为逻辑数据模型之后，还应该根据局部应用需求，并结合具体的数据库管理系统的特点，设计用户的外模式。
外模式概念对应关系数据库的视图，设计外模式是为了更好地满足各个用户的需求。
定义数据库的模式主要是从系统的时间效率、空间效率、易维护等角度出发。由于外模式与模式是相对独立的，因此在定义用户外模式时可以从满足每类用户的需求出发，同时考虑数据的安全和用户的操作方便。在定义外模式时应考虑如下问题。
（1）使用更符合用户习惯的别名
在概念模型设计阶段，当合并各E－R图时，曾进行了消除命名冲突的工作，以使数据库中的同一个关系和属性具有唯一的名字。这在设计数据库的全局模式时是非常必要的。但在修改了某些属性或关系的名字之后，可能会不符合某些用户的习惯，因此在设计用户模式时，可以利用视图的功能，对某些属性重新命名。将视图的名字命名成符合用户习惯的名字，使用户的操作更方便。
（2）对不同级别的用户定义不同的视图，以保证数据的安全
假设有关系模式：职工（职工号，姓名，工作部门，学历，专业，职称，联系电话，基本工资，浮动工资）。在这个关系模式上建立了两个视图：
职工1（职工号，姓名，工作部门，专业，联系电话）
职工2（职工号，姓名，学历，职称，联系电话，基本工资，浮动工资）
职工1视图中只包含一般职工可以查看的基本信息，职工2视图中包含允许领导查看的信息。这样就可以防止用户非法访问不允许他们访问的数据，从而在一定程度上保证了数据的安全。
（3）简化用户对系统的使用
如果某些局部应用经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为一个视图，这样用户每次只对定义好的视图查询，而不必再编写复杂的查询语句，从而简化了用户的使用。
有关数据库技术与应用教程的文章
- 详细阅读
-
数据库管理技术-数据库技术与应用教程详细阅读
从1.1.1节的介绍可以看到，在数据库管理系统出现之前，人们对数据的操作是直接针对数据文件编写应用程序实现的，这种模式会产生很多问题。对于1.1.1小节中列举的学生基本信息管理和学生选课管理两个子系统，如果使用数据库技术来管理，其实现方式如图1－4所示。保证数据的安全是通过数据库管理系统的安全控制机制实现的，保证数据的可靠是通过数据库管理系统的备份和恢复机制实现的。......
2023-11-24
-
数据库定义-数据库技术与应用教程详细阅读
如果要使用缺省参数创建一个学籍管理数据库StuData，可以使用如下命令：Create Database StuData如果希望为数据库或事务日志指定一个或者多个特定文件，增加一个On Primary子句，列出一个或者多个文件，并可为分配这个文件的空间指定一个可选值，其命令形式如下：Create Database StuDataOn Primary，；如果为了提高性能和可恢复性，则可以使用Log On子句来指定数据库的SQL Server事务日志将存储在一个与数据库对象不同的设备上，示例如下：Create Database StuDataOn Primary，Log On；GO......
2023-11-24
-
数据库修改技巧-数据库技术与应用教程详细阅读
关键字Modify File用以表示按后面的文件说明，在指定的数据库中修改相应数据库文件。下面的语句可在学籍管理数据库增加一个新数据库文件，同时要修改原数据库文件StuFile l的最大文件尺寸为2000 MB。Alter Database StuDataAdd FileModify File又如，如果要删除学籍管理数据库文件StuFile2，则可使用如下命令：Alter Database StuDataRemove File StuFile2......
2023-11-24
-
数据库查询语法-数据库技术与应用教程详细阅读
SQL的数据查询语句中包括SELECT，FROM，WHERE，GROUP BY和ORDER BY子句。SELECT语句具有数据查询、统计、分组和排序的功能，其语句表达能力非常强大。查询操作需要的数据源指基本表组，表间用“，”分割。当SELECT子句后的目标列中有统计函数，如果查询语句中有分组子句，则统计为分组统计，否则为对整个结果集统计。交查询操作，操作结果为取＜查询1＞和＜查询2＞共有的元组。......
2023-11-24
- 详细阅读
-
数据库设计方法-《数据库技术与应用教程》详细阅读
由于信息结构复杂，应用环境多样，在相当长的一段时期内数据库设计主要采用手工试凑法。人们经过探索提出了各种数据库设计方法，这些方法运用软件工程的思想和方法，提出了各种设计准则和规程，都属于规范设计法。工具在很大程度上依靠开发人员的经验来保证数据库模型能生成可行的设计方案和高性能的数据库。大多数的数据库设计方法都需要经历这三个步骤。根据所选择的设计方法按部就班地进行并最终获得一个实用的应用系统。......
2023-11-24
-
数据库查询规则-数据库技术与应用教程详细阅读
下面介绍的优化策略能提高查询的效率，但它们不一定是最优的策略，实际上“优化”一词并不是很确切，用“改进”或“改善”或许更恰当些。即使这样，使用预处理方法执行连接的时间一般仍大大减少。当查询视图时，定义视图的表达式就是公共子表达式的情况。......
2023-11-24
相关推荐