概念模型向关系模型的转换

任务3概念模型向关系模型的转换学习目标：1.熟练掌握E-R图转换为关系模型的规则。2.熟练掌握E-R图转换为关系模型的方法任务3概念模型向关系模型的转换数据库设计的步骤：1.需求分析2.概念结构设计3.逻辑结构设计4.数据库的物理设计5.数据库实施6.数据库运行与维护任务3概念模型向关系模型的转换1.实体集的转换规则2.实体集间联系的转换规则3.关系合并规则任务3概念模型向关系模型的转换转换内容–E-R图由实体、实体的属性和实体之间的联系三个要素组成。–关系模型的逻辑结构是一组关系模式的集合。–将E-R图转换为关系模型：将实体、实体的属性和实体之间的联系转化为关系模式。任务3概念模型向关系模型的转换转换原则⒈一个实体型转换为一个关系模式。–关系的属性：实体型的属性–关系的码：实体型的码例，学生实体可以转换为如下关系模式：学生（学号，姓名，出生日期，所在系，年级，平均成绩）性别、宿舍、班级、档案材料、教师、课程、教室、教科书都分别转换为一个关系模式。任务3概念模型向关系模型的转换2.一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。–1)转换为一个独立的关系模式•关系的属性：与该联系相连的各实体的码以及联系本身的属性。•关系的候选码：每个实体的码均是该关系的候选码。任务3概念模型向关系模型的转换2.一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。–2)与某一端对应的关系模式合并•合并后关系的属性：加入对应关系的码和联系本身的属性•合并后关系的码：不变任务3概念模型向关系模型的转换注意：从理论上讲，1:1联系可以与任意一端对应的关系模式合并。但在一些情况下，与不同的关系模式合并效率会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。由于连接操作是最费时的操作，所以一般应以尽量减少连接操作为目标。new任务3概念模型向关系模型的转换负责1产品产品号产品名价格1职工职工号姓名年龄任务3概念模型向关系模型的转换方案1：联系形成的关系独立存在，转换后的关系模型为：职工（职工号，姓名，年龄）；产品（产品号，产品名，价格）；负责（职工号，产品号）.方案2：“负责”与“职工”两关系合并，转换后的关系模型为：职工（职工号，姓名，年龄，产品号）；产品（产品号，产品名，价格）；方案3：“负责”与“产品”两关系合并，转换后的关系模型为：职工（职工号，姓名，年龄）；产品（产品号，产品名，价格，职工号）任务3概念模型向关系模型的转换将上面的3种方案进行比较，不难发现：方案1中，由于关系多，增加了系统的复杂性；方案2中，由于并不是每个职工都负责产品，就会造成产品号属性的NULL值过多；相比较起来，方案3比较合理。任务3概念模型向关系模型的转换⒊一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。–1)转换为一个独立的关系模式•关系的属性：与该联系相连的各实体的码以及联系本身的属性•关系的码：n端实体的码任务3概念模型向关系模型的转换⒊一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。–2)与n端对应的关系模式合并•合并后关系的属性：在n端关系中加入1端关系的码和联系本身的属性•合并后关系的码：不变–可以减少系统中的关系个数，一般情况下更倾向于采用这种方法。任务3概念模型向关系模型的转换例3-2仓储n产品产品号产品名价格1仓库仓库号地点面积数量任务3概念模型向关系模型的转换方案1：1:n联系形成的关系独立存在。仓库（仓库号，地点，面积）；产品（产品号，产品名，价格）；仓储（仓库号，产品号，数量）。方案2：联系形成的关系与n端对象合并。仓库（仓库号，地点，面积）；产品（产品号，产品名，价格，仓库号，数量）。任务3概念模型向关系模型的转换比较以上两个转换方案可以发现：尽管方案1使用的关系多，但是对仓储变化大的场合比较适用；相反，方案2中关系少，它适应仓储变化较小的应用场合。任务3概念模型向关系模型的转换4.一个m:n联系转换为一个关系模式。–关系的属性：与该联系相连的各实体的码以及联系本身的属性–关系的码：各实体码的组合例，“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码：选修（学号，课程号，成绩）任务3概念模型向关系模型的转换学生学号姓名年龄性别课程课程号课程名学时数选修mn成绩任务3概念模型向关系模型的转换学生（学号，姓名，年龄，性别）；课程（课程号，课程名，学时数）；选修（学号，课程号，成绩）任务3概念模型向关系模型的转换⒍同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。领导1n职工职工号姓名年龄任务3概念模型向关系模型的转换方案1：转换为两个关系模式。职工（职工号，姓名，年龄）；领导（领导工号，职工号）.方案2：转换为一个关系模式。职工（职工号，姓名，年龄，领导工号）.其中，由于同一关系中不能有相同的属性名，故将领导的职工号改为领导工号。以上两种方案相比较，第2种方案的关系少，且能充分表达原有的数据联系，所以采用第2种方案会更好些。任务3概念模型向关系模型的转换零件（零件号，名称，价格）；组装（组装件号，零件号，数量）.其中，组装件号为组装后的复杂零件号。由于同一个关系中不允许存在同属性名，因而改为组装件号。零件零件号名称价格nm数量组装任务3概念模型向关系模型的转换7.三个或三个以上实体集间的多元联系的转换方法要将三个或三个以上实体集间的多元联系转换为关系模式，可根据以下两种情况采用不同的方法处理：（1）对于一对多的多元联系，转换为关系模型的方法是修改n端实体集对应的关系，即将与联系相关的1端实体集的码和联系自身的属性作为新属性加入到n端实体集中。（2）对于多对多的多元联系，转换为关系模型的方法是新建一个独立的关系，该关系的属性为多元联系相连的各实体的码以及联系本身的属性，码为各实体码的组合任务3概念模型向关系模型的转换供应商供应商号供应商名地址零件零件号零件名单价产品产品号产品名型号供应nmp数量任务3概念模型向关系模型的转换转换后的关系模式如下：供应商（供应商号，供应商名，地址）；零件（零件号，零件名，单价）；产品（产品号，产品名，型号）；供应（供应商号，零件号，产品号，数量）任务3概念模型向关系模型的转换8.具有相同码的关系模式可合并。–目的：减少系统中的关系个数。–合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序。任务4数据库逻辑结构设计逻辑结构设计的任务–概念结构是各种数据模型的共同基础。–为了能够用某一DBMS实现用户需求，还必须将概念结构进一步转化为相应的数据模型，这正是数据库逻辑结构设计所要完成的任务。任务4数据库逻辑结构设计逻辑结构设计的步骤–将概念结构转化为一般的关系、网状、层次模型。–将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换。–对数据模型进行优化。任务4数据库逻辑结构设计逻辑结构设计转化为一般数据模型转化为特定DBMS支持下的据模型优化模型概念结构设计数据库物理设计基本E-R图转换规则特定DBMS的特点与限制优化方法如规范化理论逻辑模型任务4数据库逻辑结构设计1.向特定DBMS规定的模型进行转换2.数据模型的优化3.设计用户子模式1.向特定DBMS规定的模型进行转换一般的数据模型还需要向特定DBMS规定的模型进行转换。转换的主要依据是所选用的DBMS的功能及限制，没有通用规则。对于关系模型来说，这种转换通常都比较简单。2.数据模型的优化数据库逻辑设计的结果不是唯一的。得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。关系数据模型的优化通常以规范化理论为指导。2.数据模型的优化优化数据模型的方法1）确定数据依赖–按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。2.数据模型的优化优化数据模型的方法2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。2.数据模型的优化优化数据模型的方法3）按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。2.数据模型的优化优化数据模型的方法4）按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。2.数据模型的优化并不是规范化程度越高的关系就越优。当一个应用的查询中经常涉及到两个或多个关系模式的属性时，系统必须经常地进行联接运算，而联系运算的代价是相当高的，可以说关系模型低效的主要原因就是做联接运算引起的，因此在这种情况下，第二范式甚至第一范式也许是最好的。2.数据模型的优化对于一个具体应用来说，到底规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊才能决定。一般说来，第三范式就足够了。2.数据模型的优化5）按照需求分析阶段得到的各种应用对数据处理的要求，对关系模式进行必要的分解或合并，以提高数据操作的效率和存储空间的利用率–常用分解方法•水平分解•垂直分解2.数据模型的优化–垂直分解•什么是垂直分解–把关系模式R的属性分解为若干子集合，形成若干子关系模式。•垂直分解的原则–经常在一起使用的属性从R中分解出来形成一个子关系模式。2.数据模型的优化•垂直分解的优点–可以提高某些事务的效率•垂直分解的缺点–可能使另一些事务不得不执行连接操作，从而降低了效率。2.数据模型的优化•垂直分解的适用范围–取决于分解后R上的所有事务的总效率是否得到了提高。•进行垂直分解的方法–简单情况：直观分解–复杂情况：用任务2中的模式分解算法–垂直分解必须不损失关系模式的语义(保持无损连接性和保持函数依赖)。3.设计用户子模式定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：3.设计用户子模式(1)使用更符合用户习惯的别名–合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。–但对于某些局部应用，由于改用了不符合用户习惯的属性名，可能会使他们感到不方便。3.设计用户子模式(1)使用更符合用户习惯的别名(续)–因此在设计用户的子模式时可以重新定义某些属性名，使其与用户习惯一致。–当然，为了应用的规范化，我们也不应该一味地迁就用户。例：负责学籍管理的用户习惯于称教师模式的职工号为教师编号。因此可以定义视图，在视图中职工号重定义为教师编号3.设计用户子模式(2)针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。由于视图能够对表中的行和列进行限制，所以它还具有保证系统安全性的作用。对不同级别的用户定义不同的子模式，可以保证系统的安全性。3.设计用户子模式(3)简化用户对系统的使用–如果某些局部应用中经常要使用某些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。4.数据库逻辑设计实例实例假如要为某基层单位建立一个“基层单位”数据库。通过调查得出，用户要求数据库中存储下列基本信息。部门：部门号，名称，领导人编号；职工：职工号，姓名，性别，工资，职称，照片，简历；工程：工程号，工程名，参加人数，预算，负责人；办公室：地点，编号，电话。这些信息的关联的语义为：每个部门有多个职工，每个职工只能在一个部门工作；每个部门只有一个领导人，领导人不能兼职；每个部门可以同时承担若干工程项目，数据库中应记录每个职工参加项目的日期；一个部门可有多个办公室；每个办公室只有一部电话；数据库中还应存放每个职工在所参加的工程项目中承担的具体职务。4.数据库逻辑设计实例实例1.概念模型的设计调查得到