1 / 66

第 7 章 数据库设计

第 7 章 数据库设计. 本章主要内容. 数据库设计 (Database Design, 简记为 DBD) 是指对于给定的软、硬件环境，针对现实问题，设计一个较优的数据模型，建立 DB 结构和 DB 应用系统。 本章主要讨论 DBD 的方法和步骤，详细介绍 DBD 的全过程。本章的重点有两个： 概念设计中的 ER 模型设计方法。设计 ER 模型是一件实用性很强的工作 ,ER 模型应该充分反映用户的需求。 逻辑设计中 ER 模型向关系模型转换的规则。. 本章主要内容 （ 续 ）. （ 1 ） DBS 生存期及其 7 个阶段的任务和工作， DBD 过程的输入和输出。

vic
Télécharger la présentation

第 7 章 数据库设计

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 第7章 数据库设计

  2. 本章主要内容 数据库设计(Database Design,简记为DBD)是指对于给定的软、硬件环境，针对现实问题，设计一个较优的数据模型，建立DB结构和DB应用系统。 本章主要讨论DBD的方法和步骤，详细介绍DBD的全过程。本章的重点有两个： • 概念设计中的ER模型设计方法。设计ER模型是一件实用性很强的工作,ER模型应该充分反映用户的需求。 • 逻辑设计中ER模型向关系模型转换的规则。

  3. 本章主要内容（续） （1）DBS生存期及其7个阶段的任务和工作，DBD过程的输入和输出。 （2）概念设计的重要性、主要步骤。逻辑设计阶段的主要步骤。 （3）ER模型的基本元素，属性的分类，联系的元数、连通词、基数。采用ER方法的概念设计步骤。 （4）ER模型到关系模型的转换规则。采用ER方法的逻辑设计步骤。

  4. 数据库设计 7.1 数据库设计概述 7.2 规划 7.3 需求分析 7.4 概念设计 7.5 数据库逻辑结构设计及优化 7.6 数据库的物理设计 7.7 数据库的实现 7.8 数据库的运行与维护工作 7.9 Power Designer辅助设计工具 本章小结

  5. 7.1 数据库设计概述 隶属关系 • 软件工程 人们认为，应该用科学知识、工程方面的规范指导软件开发的过程，以提高软件质量和开发效率，降低开发成本 。 • 软件生存期 从软件的规划、研制、实现、投入运行后的维护，直到它被新的软件所取代而停止使用的整个期间。 • 数据库系统生存期 数据库应用系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个期间。 • 数据库工程设计方法 • 数据库设计的输入输出

  6. 7.1.1 数据库系统生存期 规划 规划 需求分析 需求分析 数据库生存期 软件生存期 概念设计 系统设计 逻辑设计 程序编制 物理设计 调试 实现 运行维护 运行和维护

  7. 7.1.2 数据库设计方法 1）直观设计法 　直观设计法主要凭借设计者对整个系统的了解和认识，以及平时所积累的经验和设计技巧，完成对某一数据库系统的设计任务。 • 这样的方法具有周期短、效率高、操作简便、易于实现等优点。 • 这种方法主要是用于简单的小型系统。 2）规范化设计法 规范化设计法将数据库设计分为若干阶段，明确规定各阶段的任务，采用“自顶向下、分层实现、逐步求精”的设计原则，结合数据库理论和软件工程设计方法，实现设计过程的每一细节，最终完成整个设计任务。 常用的规范化设计方法主要有： • 基于实体联系的设计方法(常用方法) • 基于视图概念的数据库设计方法 • 基于3NF的数据库设计方法等。

  8. 3）计算机辅助设计法 　计算机辅助设计法是指在数据库设计的某些过程中，利用计算机和一些辅助设计工具，模拟某一规范设计方法，并以人的知识或经验为主导，通过人机交互方式实现设计中的某些部分。 例如在需求分析完成后，可以使用POWERDESIGNER、E-Rwin等辅助工具产生E-R图，并将E-R图转换为关系数据模型，生成数据库结构，再编制相应的应用程序，从而缩短数据库设计周期。 4）自动化设计法 设计人员只要熟悉某种MIS辅助设计软件的使用，通过人机会话，输入原始数据和有关要求，无须人工干预，就可以由计算机系统自动生成数据库结构及相应的应用程序。 由于该设计方法基于某一MIS辅助设计系统，从而受限于某种DBMS，使得最终产生的数据库及其软件系统带有一定的局限性。

  9. 7.1.3 数据库设计的基本步骤 总体信息需求 处理需求 第1步 规划 DBMS特征 第2步 需求描述和分析 需求说明书 第3步 概念设计 信息结构 （独立于硬件、软件） 第4步 逻辑设计 逻辑数据库结构 （DBMS能处理的） 应用程序说明书 硬件和 OS特征 第5步 物理设计 物理数据库结构

  10. 7.2 规划 • 目标 进行建立数据库的必要性及可行性分析，确定数据库系统在组织中和信息系统中的地位，以及各个数据库之间的联系。 • 规划阶段的三个步骤 • 系统调查： 对企业组织作全面的调查，画出组织层次图，以了解企业的组织结构。 • 可行性分析 从技术、经济、效益、法律等方面对建立数据库的可行性进行分析；写出可行性分析报告；组织专家进行讨论其可行性。 • 确定数据库系统的总目标和制定项目开发计划

  11. 子系统1 子系统2 … 子系统n 专用 数据库m 公用 数据库1 公用 数据库2 专用 数据库1 … 　分析企业的基本业务功能，确定数据库支持的范围，是建立一个综合的数据库，还是建立若干个专门的数据库。 • 在实际操作中，可以建立一个支持组织全部活动的包罗万象的综合数据库； • 也可以建立若干个范围不同的公用或专用数据库。

  12. 规划报告　 　数据库规划工作完成以后，应写出详尽的可行性分析报告和数据库系统规划纲要，内容包括： • 信息范围； • 信息来源； • 人力资源； • 设备资源； • 软件及支持工具资源； • 开发成本估算； • 开发进度计划； • 现行系统向新系统过渡计划等。

  13. 7.3 需求分析 • 目标 　　对系统的整个应用情况作全面的、详细的调查，确定企业组织的目标，收集支持系统总的设计目标的基础数据和对这些数据的要求，确定用户的需求，并把这些要求写成用户和数据库设计者都能够接受的文档。 • 需求分析工作 • 分析用户活动产生，产生业务流程图 • 确定系统范围，产生系统范围图 • 分析用户活动涉及的数据，产生数据流图 • 分析系统数据，产生数据字典

  14. 7.3.1 需求描述与分析 确定全部的用户需求是一件很困难的事情: • 第一，系统本身的需求是变化的，用户的需求必须不断调整，使之与这种变化一致。 • 第二，由于用户缺少计算机信息系统设计方面的专业知识，要表达他们的需求很困难。特别是很难说清楚某部分工作的功能与处理过程。 • 第三，要调动用户的积极性，使他们能积极参与系统的分析与设计工作相当困难。 • 我们设计人员必须首先认识到在整个需求分析以及系统设计过程中，用户参与的重要性。 • 需求分析中调查分析的方法很多，通常的办法是对不同层次的企业管理人员进行个人访问，内容包括业务处理和企业组织中的各种数据。 • 还应该考虑系统将来要发生的变化，充分考虑到系统可能的扩充和变动，以减少系统维护的代价。

  15. 7.3.2 需求分析阶段的输入和输出 总体信息需求 处理需求 第1步：需求分析 需求说明书

  16. 7.3.3 需求分析的步骤 1）需求信息的收集 （1）调查的目的 • 首先，要了解组织的机构设置，主要业务活动和职能。 • 其次，要确定组织的目标，大致工作流程和任务范围划分。 （2）调查的内容 • 外部要求 • 业务现状 • 组织机构等 （3）调查方式 • 开座谈会； • 跟班作业； • 请调查对象填写调查表； • 查看业务记录、票据； • 个别交谈。

  17. 2）需求信息的分析整理 （1）业务流程分析 　业务流程分析的目的是获得业务流程及业务与数据联系的形式描述。 　一般采用数据流分析法，分析结果以数据流图（data flow diagram，DFD）表示。 　一个DFD由数据流、处理过程、数据存储等部分组成。

  18. （2）分析结果的描述 　除了DFD以外，还要用一些规范表格进行补充描述。 为了清楚地描述需求分析的结果，需要整理出下列清单： • 数据项清单：列出每一个数据项的名称、含义、来源、类型和长度等。 • 业务活动清单：列出每一部门中最基本的工作任务，包括任务的定义、操作类型、执行频度、所属部门及涉及的数据项等。 • 完整性、一致性要求。 • 安全性要求。 • 响应时间要求。 • 预期变化的影响。 3）评审 　评审的目的在于确认某一阶段的任务是否全部完成，以避免重大的疏漏或错误。

  19. 7.3.4 数据字典 数据字典（data dictionary, DD）是对系统中数据的详尽描述，它提供对数据库数据描述的集中管理。 1）数据项 　包括数据项名、含义、别名、类型、长度、取值范围以及与其它数据项的逻辑关系。 数据项名：选课单号 说　　明：标识每张选课单 类　　型：CHAR(8) 长　　度：8 别　　名：选课单号 取值范围：00000001~99999999

  20. 2）数据结构 数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，或有若干个数据项和数据结构混合组成。 　它包括数据结构名、含义及组成该数据结构的数据项名或数据结构名。 数据结构名：考试课程 说　　　明：作为考场安排的组成部分，说明某门课程哪位老　　　　　　 师代，以及所选学生人数。 组　　　成：课程号 　　　教师号 选课人数

  21. 3）数据流 　数据流可以是数据项，也可以是数据结构，表示某一加工处理过程的输入或输出数据。 　对数据流的描述应包括数据流名、说明、流出的加工名、流入的加工名以及组成该数据流的数据结构或数据项。 数据流名：考场安排 说　　明：由各课程所选学生数，选定教室、时间，安排考场 来　　源：考试 去　　向：教师 数据结构：考场安排 ――考试课程 ――考试时间 ――教学楼 ――教室编号

  22. 4）数据存储 　数据存储是处理过程中要存储的数据，它可以是手工凭证、手工文档或计算机文档。 对数据存储的描述应包括：数据存储名、说明、输入数据流、输出数据流、数据量、存取频度和存取方式。 数据存储名：课程表 说　　　明：对每门课程的名称、学分、先行课程号和摘要描述 输出数据流：课程介绍 数据描述 ：课程号 课程名 学分数 先行课程号 摘要 数 量：每年500种 存 取 方 式 ：随机存取

  23. 5）处理进程 　对处理进程的描述包括处理进程名、说明、输入数据流、输出数据流，并简要说明处理工作、频度要求、数据量及响应时间等。 处理进程：选课 说　　明：对要选某门课程的每一个学生，根据已选修课程 确定其是否可选该课程。再根据学生选课的人数选择适当的教室，制定选课单 输　　入：学生选课 可选课程 已选课程 输　　出：选课单 程序提要：a. 对所选课程在选课表中查找其是否已选此课程 b. 若未选过此课程，则在选课表中查找是否已选此 课程的先行课程 c. 若a、b都满足，则在选课表中增加一条选课记录 d. 处理完全部学生的选课处理后，形成选课单

  24. 7.4 概念设计 目标 　概念设计的目标是产生反映企业组织信息需求的数据库概念结构，即概念模式。概念模式是独立于计算机硬件结构，独立于支持数据库的DBMS。 为什么需要概念设计 概念设计的主要步骤 进行数据抽象，设计局部概念模式 将局部概念模式综合成全局概念模式 评审

  25. 7.4.1 概念设计的必要性 　在概念设计阶段中，设计人员从用户的角度看待数据及处理要求和约束，产生一个反映用户观点的概念模式。 　然后再把概念模式转换成逻辑模式。 　将概念设计从设计过程中独立开来，至少有以下几个好处: 各阶段的任务相对单一化，设计复杂程度大大降低，便于组织管理。 不受特定的DBMS的限制，也独立于存储安排和效率方面的考虑，因而比逻辑模式更为稳定。 概念模式不含具体的DBMS所附加的技术细节，更容易为用户所理解，因而才有可能准确地反映用户的信息需求。

  26. 数据库的各级模式 应用1 应用1 应用2 应用3 概念要求 外模式1 外模式2 外模式3 映像 应用2 概念要求 概念模式 逻辑模式 映像 转换 应用3 内模式 概念要求 综合

  27. E-R图设计方法 (1)自顶向下 根据用户需求，先定义全局概念结构的框架，然后分层展开，逐步细化。 (2)自底向上 根据用户的每一具体需求，先定义各局部应用的概念结构，然后将它们集成，逐步抽象引最终产生全局概念结构。 (3)逐步扩张 先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至全局概念结构。 (4)混合方式 将自顶向下和自底向上相结合，先用自顶向下方式设计一个全局概念结构框架，再以它选基础，采用自底向上法集成各局部概念结构。

  28. 7.4.2 概念设计的主要步骤 1）进行数据抽象，设计局部概念模式 先从个别用户的需求出发，为每个用户建立一个相应的局部概念结构。 设计概念结构时，常用的数据抽象方法是“聚集”和“概括”。 2）将局部概念模式综合成全局概念模式 综合各局部概念结构就可得到反映所有用户需求的全局概念结构。 • 在综合过程中，主要处理各局部模式对各种对象定义的不一致问题。 • 在结构合并时，解决冗余问题，对信息需求的再调整与分析。 3）评审 消除了所有冲突后，就可把全局结构提交评审。 • 用户评审 • DBA及应用开发人员评审

  29. 7.4.3 采用ER方法的数据库概念设计 在设计数据库概念结构时，为了更好地模拟现实世界，一个有效的策略是“分而治之”，即先分别考虑各个用户的信息需求，形成局部概念结构，然后再综合成全局结构。 需求分析结果 确定局部结构范围 实体定义 联系定义 属性分配 还有局部 结构待分析 有 无 进入全局ER模式设计 1）设计局部ER模式

  30. （1）确定局部结构范围 一种是依据系统的当前用户进行自然划分。 例如，对一个企业的综合数据库，按决策部门、销售部门、生产部门、技术部门和供应部门分别设计各自的局部ER模式。 另一种是按用户要求数据库提供的服务归纳成几类，为每类应用设计一个局部ER模式。 例如，学校的教师数据库可以按提供的服务分为以下几类： 教师的档案信息的查询。 对教师的专业结构进行分析。 对教师的职称、工资变化的历史分析。 对教师的学术成果查询分析。 局部结构范围的确定要考虑下述因素： • 范围的划分要自然，易于管理。 • 范围之间的界面要清晰，相互影响要小。 • 范围的大小要适度。

  31. （2）确定实体 通常可依据下列两个基本规则来区分实体和属性： 实体与属性之间的联系只能是1：n的； 属性本身不再具有需要描述的信息或与其他事物具有联系。 现实世界中的事物能够作为属性对待的，应尽量作为属性处理，以简化E-R模型。 图(a)仓库作为物资实体的属性 图(b)仓库作为单独的实体 物资 编号 名称 规格 单价 仓库号 存放数量 存放 编号 仓库号 物资 仓库 名称 规格 单价 存放数量 地点 面积

  32. （3）联系设计 某商业集团中，商店、仓库、商品之间的进货联系 问题：运动员根据其得分来排定名次。在名次排列中，排在他前面只有一个人排在他后面也只有一个人 工厂的零件之间存在着组合关系，一种零件由许多种子零件组成，而一种零件也可以是其他零件的子零件 职工之间的上下级联系 学校里规定每学期学生至少选修1门课程，最多选修6门课程；每门课程至多有50人选修，最少可以没人选修 仓库号 仓库名 地址 仓库 数量 M 图7.13 联系的连通词和实体的基数 图7.10 一元联系中的1:N联系 图7.9 一元联系中的1:1联系 进货 图7.11 一元联系中的M:N联系 日期 图7.12 三元联系中的M:N:P联系 N P 商店 商品 1 1 商店号 商店名 商品号 商品名 规格 零件号 零件名 编号 姓名 性别 名次 零件 M N 运动员 组成 学生 M （1，6） 数量 顺序 选课 N （0，50） 课程 工号 姓名 年龄 性别 职工 1 N 领导 • 联系集 联系集是n（n≥2）个实体集上的数学关系，这些实体集不必互异。 • 联系的元数 一个联系涉及到的实体集个数。 • 联系的连通词 涉及到的实体集之间实体对应的方式 。 • 实体的基数 有两个实体集E1和E2，E1中每个实体与E2中有联系实体的数目的最小值min和最大值max，称为E1的基数，用（min，max）形式表示 。

  33. （4）属性分配 基本工资 奖金 家庭地址 门牌号码 姓名 房租 规格 进货价格 区 名 供应商 经销价格 实发工资 零件编码 工号 街 道 代销价格 零件名 批发价格 图7.5 多值属性的表示 零件编码 职 工 零售价格 图7.8 导出属性的表示 零 件 省（市）名 图7.6 多值属性的变换（1） 邮政编码 地 址 图7.4 地址属性的层次结构 供应商 零件名 规格 销售性质 售货价格 进货价格 零件编码 1 N 存在 零 件 销售价格 规格 供应商 进货价格 零件名 图7.7 多值属性的变换（2） 销售价格 零件编码 零 件 • 基本属性和复合属性（可否再分） • 单值属性和多值属性（对一个实体对象是否只能取一个值） • 多值属性的处理 • 将原来的多值属性用几个新的单值属性来表示。 • 将原来的多值属性用一个新的实体类型表示 • 导出属性 • 空值

  34. 局部ER模式设计综述 范围的划分要自然，易于管理； 采用人们习惯的划分； 避免冗余，在一个局部结构中，对一个对象只取一种抽象形式，不要重复； 依据用户的信息处理需求 确定属性的原则： 属性应该是不可再分解的语义单位；实体与属性之间的关系只能是1:N的；不同实体类型的属性之间应无直接关联关系。 范围之间的界面要清晰，相互影响要小 范围的大小要适度。太小了，会造成局部结构过多，设计过程繁琐，综合困难；太大了，则容易造成内部结构复杂，不便分析 属性分配的原则： 当多个实体类型用到同一属性时， 一般把属性分配给那些使用频率最高的实体类型，或分配给实体值少的实体类型。 有些属性不宜归属于任一实体类型，只说明实体之间联系的特性 需求分析结果 确定局部结构范围 实体定义 联系定义 属性分配 还有局部 结构待分析 有 无 进入全局ER模式设计 图7.18 局部ER模式设计

  35. 局部模式 现有的教学 管理系统 初步分析系统的对象 根据服务种类分析教师子模块 …… 局部ER图

  36. 其他局部模式 1 有 N 1 管理 1 系 班级 班主任 1 导师 组成 指导 1 N N N 归档 1 N 住宿 1 档案材料 学生 宿舍 M 参加 N 学会 图7.21 学籍管理局部应用的分E-R图 1 具有 N 社会关系 根据服务种类分析学生子模块 …… 现有的教学 管理系统 初步分析系统的对象 局部ER图

  37. 其它局部模式 1 开设 N 系 课程 M 1 上课 担任 1 N 选修 MN 学生 P N 教室 教科书 教师 图7.22 课程管理局部应用分E-R图 现有的教学 管理系统 初步分析系统的对象 …… 根据服务种类分析课程子模块 局部ER图

  38. ER模型的操作 教师 教师号 姓名 教师 出生日期 教师号 职务 工资 奖金 1 M M 主讲 辅导 主讲 教师不变信息 教师变动信息 N N （b） N 课程 课程 图7.15 实体类型的垂直分裂 （a） （b） 图7.16 联系类型的分裂 A B A B A-C B-C A-B-C 教师号 姓名 出生日期 职务 工资 奖金 C C 教师 (b) (a) （a） 图7.17 不合法的合并 包括实体类型、联系类型和属性的分裂、合并、增删等等

  39. 2）设计全局 ER模式 属性冲突 ：如，重量单位有的用公斤，有的用克。 结构冲突 ：同一对象在不同应用中的不同抽象 ；同一实体在不同局部ER图中属性的个数或次序不同 ；实体之间的联系在不同的局部ER图中呈现不同的类型 命名冲突 ：属性名、实体名、联系名之间存在同名异义或异名同义冲突 局部ER模式 确定公共实体类型 合并两个局部ER模式 检查并消除冲突 还有冲突吗 有 还有未合并的局部模式 有 无 图7.20全局ER模式设计

  40. 结构冲突解决方式1 学生 学号 姓名 性别 年龄 所在系 专业 编号 系名 系主任 所在地点 联系电话 系 1 属于 n ① 对于同一对象在不同的局部E-R模型中产生不同的抽象: 把属性变为实体或实体变为属性，使同一对象具有相同的抽象，变换后产生的结果仍然要遵守7.4.3节中所阐述的两个基本规则。（一是实体与属性之间的联系只能是1：n的；二是属性本身不再具有需要描述的信息或与其他事物具有联系。）

  41. 结构冲突解决方式2 学生 学生 图(a) E-R模型1 图(b) E-R模型2 学号 学号 姓名 姓名 性别 性别 年龄 年龄 所在系 所在系 专业 专业 图(c)合并后的E-R模型 学生 学号 籍贯 姓名 政治面貌 家庭住址 籍贯 家庭住址 政治面貌 ② 对于同一实体在不同E-R模型中属性组成不同： 取两个分E-R模型属性的并，作为合并后的该实体属性，然后对属性的先后次序作适当调整。

  42. 结构冲突解决方式3 产品 m m p 组成 供应 组成数量 供应商 n n 供应数量 零件 图7-14 (c) 合并后的E-R模型 产品 产品 m p 组成 数量 供应商 组成 数量 n n 零件 零件 图7-14 (b) 产品、零件和供应商的ER模型2 图7-14 (a) 产品与零件的ER模型1 ③ 对于实体间的相同联系呈现的不同的类型： 根据具体应用的语义，对实体间的联系作适当的综合或调整。

  43. 3）全局ER模式的优化 • 实体类型的合并 • 1:1联系的两个实体类型 • 具有相同键的实体类型 • 冗余属性的消除 • 冗余联系的消除 利用规范化理论中函数依赖的概念消除冗余联系

  44. 例子：三个局部ER图合并成一个ER图 教师 教师 教师 院长 院长 院长 1 1 1 主管 主管 主管 学院 学院 学院 1 1 1 1 1 1 1 1 1 管理 管理 管理 设置 设置 设置 N N N 1 1 1 项目 项目 项目 N N N 承接 承接 承接 1 1 1 1 1 1 有 有 有 N N N 系 系 系 班级 班级 班级 学会 学会 学会 1 1 1 1 1 1 M M M 1 1 1 管理 管理 管理 1 1 1 参加 参加 参加 开设 开设 开设 组成 组成 组成 参加 参加 参加 选修 选修 选修 聘用 聘用 聘用 N N N 1 1 1 N N N N N N M M M N N N N N N 担任 担任 担任 N N N 教师 教师 教师 课程 课程 课程 N N N 1 1 1 M M M N N N 住宿 住宿 住宿 学生 学生 学生 宿舍 宿舍 宿舍 1 1 1 P P P N N N 上课 上课 上课 1 1 1 教科书 教科书 教科书 1 1 1 评定 评定 评定 具有 具有 具有 归档 归档 归档 1 1 1 教室 教室 教室 1 1 1 N N N N N N 职称 职称 职称 社会关系 社会关系 社会关系 指导 指导 指导 档案材料 档案材料 档案材料 1 1 1 N N N 1 1 1 分配 分配 分配 1 1 1 工作量 工作量 工作量 图7.24 合并后的教学管理E-R图 图7.24 合并后的教学管理E-R图 图7.24 合并后的教学管理E-R图

  45. 7.5 数据库逻辑结构设计及优化 数 据 库 逻 辑 结 构 设 计 独立于DBMS的概念模式 DBMS可处理的模式和子模式 处理需求 应用程序设计指南 约束条件 物理设计指南 DBMS特征 7.5.1 逻辑设计环境

  46. 7.5.2 逻辑设计的步骤 返回到前面阶段 概念模式 导出初始DBMS模式说明 子模式设计 应用程序设计草图 模式评价 是 否 处理结束 是 模式需要修正 否 进入物理设计阶段 模式修正 • 目标 • 逻辑设计步骤

  47. 7.5.3 ER模型向关系模型的转换 1）转换的一些问题 （1）命名和属性域的处理 关系模式的命名，可以采用E-R图中原来的命名，也可以另行命名。 （2）非原子属性的处理 E-R数据模型中允许非原子属性，这不符合关系模型的第一范式的条件。 对集合属性纵向展开，对元组属性横向展开。

  48. 职工号 姓名 性别 年龄 与职工关系 （3）弱实体的处理 （a）E－R图 （b）关系模式 职工号 出生日期 姓名 职工 家属 1 姓名 职工－家属 年龄 性别 与职工关系 N

  49. 姓名 名称 地址 职称 任期 联系电话 （4）联系的转换 l：l 联系 名称 姓名 1 1 管理 学校 校长 地址 职称 联系电话 任期 k h 1 1 r E1 E2 b a s 可以一个关系模式： R（ k，a ， h，b，s ）

More Related