数据库设计与实现ER转换为关系模式.ppt

2019年11月5日星期二,1,数据库系统概念-E-R,4从E-R 图到数据库模式设计,根据E-R建立数据库模式的步骤 1、E-R图转换为表并进行必要的合并 本步骤可以按照机械方法完成 一个良好的E-R图，完成本步转换和合并得到的结果，已经是比较理想的数据库模式 (尽管还有人工进一步优化的余地) 2、优化 本步无具体可行的机械方法 主要依靠设计人员的经验和能力,2019年11月5日星期二,2,数据库系统概念-E-R,4 4从E-R 图到数据库模式设计,本章主要内容 4.1E-R图到表的基本转化方法 暂时只考虑基本E-R图的转换，且只考虑简单、单值属性 4.2表合并方法讨论 讨论联系转化的表能否及如何与其它表合并 4.3E-R复杂要素转化为表的方法 复杂属性处理 弱实体处理 继承转化为表 聚集转化为表 4.4关于表模式进一步优化问题的讨论 4.5其它逻辑模式设计问题讨论,2019年11月5日星期二,3,数据库系统概念-E-R,4.1 E-R 到表的基本转化方法,实体转化为表 E-R图的每个实体转化成一个表 实体的属性转化为表的属性 (暂时只考虑简单、单值属性) 实体的主码转化为表的主码,2019年11月5日星期二,4,数据库系统概念-E-R,4.1 E-R 到表的基本转化方法,联系转化为表 每个联系转化成一个表 联系转化成表的属性 参与联系实体的主码并集pk(e1)pk(e2)以及联系的属性a1,a2共同构成表的属性 pk(e1)pk(e2)a1,a2 在联系转化成的表中,属性的非空限制： 实体主码形成的属性pk(e1)pk(e2) 均应not null 只有在联系转化成的表与其他表合并后，才可能允许null,2019年11月5日星期二,5,数据库系统概念-E-R,4.1 E-R 到表的基本转化方法,联系转化成的表的码： 参与联系实体的主码并集pk(e1)pk(e2) 是联系转化成的表的超码 多对一联系，上述超码去掉一个“一”端实体的主码后，是联系表的候选码 多对多联系，上述超码是联系表的候选码,2019年11月5日星期二,6,数据库系统概念-E-R,4.1 E-R到表的基本转化方法示例,E-R图： 实体转化成的表： Dept(dno,dname) Student(sno,sname) Course(cno,cname) 联系转化成的表： SD(sno,dno,time) /dno非空 SC(sno,cno,score),2019年11月5日星期二,7,数据库系统概念-E-R,4.1 练习,请将下述E-R转化为关系模式： 注意指明各表的主码,2019年11月5日星期二,8,数据库系统概念-E-R,4.1 练习,将E-R转化为关系模式参考答案 实体转化成的表 Teacher(tno,name) class(classno,classname) Course(cno,cname) 联系转化成的表 tc(tno,cno) tcc(classno,cno,tno),2019年11月5日星期二,9,数据库系统概念-E-R,4.2表的合并,主要讨论联系转化的表与相关实体转化的表的合并问题 按照联系类别分别讨论能否合并、如何合并 二元m:1联系 二元1:1联系 二元m:n联系 多元联系,2019年11月5日星期二,10,数据库系统概念-E-R,4.2表的合并,二元多对一联系： 联系转化的表可以和“多端” 实体转化成的表进行合并 示例： E-R图 转化成的表 Dept(dno,dname) Student(sno,sname) SD(sno,dno,time) /dno非空 表的合并 Student+SD Student(sno,sname,dno,time)/dno可以为空,2019年11月5日星期二,11,数据库系统概念-E-R,4.2表的合并,二元一对一联系： 联系转化的表可以任一端实体转化成的表进行合并 二元一对一联系不能导致相关实体转化成的表合并 示例： E-R图如右所示 转化成的表 Dept(dno,dname) President(pid,name) Manage(dno,pid) /dno,pid均可作主码，假设选dno作主码 表的合并 可以：Dept+Manage Dept(dno,dname,pid) 或者：President+ManagePresident(pid,name,dno) 不能进行下述合并： Dept+Manage+President ?(不能接受的合并),2019年11月5日星期二,12,数据库系统概念-E-R,4.2表的合并,二元m:n联系 联系转化的表和实体转化的表不能进行合并 示例： E-R图 转化成的表 Student(sno,sname) Course(cno,cname) SC(sno,cno,score) 无法进行表的合并,2019年11月5日星期二,13,数据库系统概念-E-R,4.2表的合并,多元联系 联系转化的表和实体转化的表不能进行合并 即便是m:n:1,其转化的表和也不能进行合并 示例： E-R图(省略了属性)： 转化成的表： Class(classno,classname) Teacher(tno,tname) Course(courseno,coursename) TCC(tno,classno,courseno) /P.K.=(classno,tno)或(classno,courseno) 无法进行表的合并,2019年11月5日星期二,14,数据库系统概念-E-R,4.2表的合并：总结,联系转化成的表，和实体转化成的表，可以机械地按照下述原则合并： 二元多对一联系： 联系转化的表可以和“多端” 实体转化成的表进行合并 二元一对一联系： 联系转化的表可以任一端实体转化成的表进行合并 二元一对一联系不能导致相关实体转化成的表合并 二元m:n联系： 联系转化的表和实体转化的表不能进行合并 多元联系： 联系转化的表和实体转化的表不能进行合并 即便是m:n:1,其转化的表和也不能进行合并 实体转化成的表，相互之间不能机械合并 联系转化成的表，相互之间不能机械合并,2019年11月5日星期二,15,数据库系统概念-E-R,4.2 E-R图表以及表的合并：示例,教务系统概念模型如下图所示 请将E-R图转化为表并进行必要的合并：,4.2 E-R图表以及表的合并：示例,将E-R图转化为表： 实体转化成表 d(dno,dname) c(cno,cname,property) s(sno,sname,age,sex) t(tno,tname,age,sex) 联系转化为表 sd(sno,dno) td(tno,dno) sc(sno,cno,score) tc(tno,cno,time),隶属,学生,学习,score,age,院系,隶属,教师,课程,讲授,dno,dname,tno,tname,cno,cname,sex,age,sno,sname,sex,property,16,4.2 E-R图表以及表的合并：示例,表的合并 s+sds(sno,sname,age,sex,dno) t +td t(tno, tname,age,sex,dno) 合并表后的关系模式 d(dno,dname) c(cno,cname,property) s(sno,sname,age,sex,dno) t(tno,tname,age,sex,dno) sc(sno,cno,score) tc(tno,cno) 关系模式图如图所示,17,4.2 E-R图表以及表的合并：示例,教务系统数据概念模型与逻辑模型对比 概念模型主要用E-R图刻画，用于需求分析 逻辑模型主要由关系模式图刻画，用于模式设计,18,2019年11月5日星期二,19,数据库系统概念-E-R,4.2 练习一,请将E-R图转化为表并进行必要的合并： 假设每个实体都有属性id和name 假设供应联系有属性quantity,其它联系无属性,2019年11月5日星期二,20,数据库系统概念-E-R,4.2 练习一：参考答案,E-R图转化为表 实体转化成表 project(pid,pname) employee(eid,ename) supplier(sid,sname) component(cid,cname) warehouse(wid,wname) 联系转化为表 participate(pid,eid) lead(eid,leid) /leid非空 supply(sid,pid,cid,quantity) produce(sid,cid) store(cid,wid) manager(eid,wid) 表的合并 employee+leademployee(eid,ename,leid)/leid可以为空,4.2 练习一：关系模型图,2019年11月5日星期二,21,数据库系统概念-E-R,2019年11月5日星期二,22,数据库系统概念-E-R,4.2 练习二,将如下E-R图转化为表并进行必要的合并，请给出： 1.结果关系模式 2.关系模式图,2019年11月5日星期二,23,数据库系统概念-E-R,4.3E-R图其它要素转化为表的方法,E-R图其它要素转化为表的方法 复杂属性处理 弱实体处理 继承转化为表 聚集转化为表,2019年11月5日星期二,24,数据库系统概念-E-R,4.3.1复杂属性表,多值属性 每个多值属性转化为一个表 表主码： 实体主码+多值属性分辨符 例如：S-telno(sno,tno) 复合属性 只保留叶节点属性 派生属性 一般表模式中不保留派生属性 S(sno,sname,birthday,city,street) 如果考虑使用频率、查询效率等因素，可以保留派生属性，尽管本质上派生属性是表的冗余属性,2019年11月5日星期二,25,数据库系统概念-E-R,4.3.1复杂属性表,示例，学生实体转化为表： 所有单值属性转化为一个表 S(sno,sname,birthday,city,street) 每个多值属性转化为一个表 S-telno(sno,tno) S-relative(sno,pid,relation,name) 思考： S-relative中，pid属性是否可以单独构成主码？ 不同多值属性转化的表可以合并吗？,2019年11月5日星期二,26,数据库系统概念-E-R,4.3.2弱实体表,弱实体转化为表 弱实体象普通实体一样向表转化，只是在弱实体转化的表中，增加属主实体的主码作为表属性 弱实体转化成表的主码： 属主实体的主码+弱实体的分辨符 标识性联系不转化成表，不作处理,4.3.2弱实体表：示例,示例： 请将如下所示银行帐户E-R图转化为表,4.3.2弱实体表：示例,将E-R图转化为表： 实体转化成表 acc(accno,accname) emp(eno,ename) 弱实体转化成表 trans(accno,lineno,date,dealnum) rual(accno,date,accrual) 标识性联系不转化成表 联系转化成表 tr(accno,lineno,date) te(accno,lineno,eno) 表合并 trans+tr+te =trans(accno,lineno,transdate,dealnum,rualdate,eno),4.3.2弱实体vs强实体,练习： 对上述银行账户，如果在E-R中不使用弱实体，而是通过给交易记录、利息记录增加标识属性是成为强实体，试给出相应E-R图 试将上述E-R图转化为表并进行必要的合并 体会、比较两种E-R图对应概念模型及逻辑模型的差异，你更喜欢哪一种？,4.3.2强实体&表：参考方案,将E-R图转化为表： 实体转化成表 acc(accno,accname) trans(tid,lineno,date,dealnum) rual(rid,date,accrual) emp(eno,ename) 联系转化成表 ta(tid,accno) ra(rid,accno) tr(tid,rid) te(tid,eno) 表合并 trans+ta+tr+te=trans(tid,accno,lineno,date,dealnum,rid,eno) rual+ra=rual(rid,accno,date,accrual),4.3.2弱实体vs强实体,弱实体方案转化的逻辑模式 acc(accno,accname) emp(eno,ename) trans(accno,lineno,transdate,dealnum,rualdate,eno) rual(accno,date,accrual) 强实体方案转化的逻辑模式： acc(accno,accname) emp(eno,ename) trans(tid,accno,lineno,date,dealnum,rid,eno) rual(rid,accno,date,accrual) 课堂练习： 请分别给出两种逻辑模式的模式图 试述你更喜欢哪种方案？,2019年11月5日星期二,32,数据库系统概念-E-R,4.3.3继承关系表,继承关系的三种处理方案 父类、子类分别建表 p(pid,name) s(pid,sno,dept) t(pid,tno,dept) 父类并入子类，只为子类建表 s(pid,name,sno,dept) t(pid,name,tno,dept) 子类并入父类，只为父类建表 p(pid,name,sno,s-dept,tno,t-dept) 比较： 三种方案各有优缺点，都可以接受 设计人员根据具体情况，综合评定选择确定最终方案 讨论：针对这个示例，你更愿意选择哪个方案？,4.3.3练习与讨论,学校系统概念模型如下E-R图所示： 请按照继承关系三种处理方案分别转化成表 比较各方案优缺点，你更喜欢哪种方案？,4.3.3练习与讨论：参考答案一,父类、子类分别建表 实体转化成表 person(pid,name,age) student(pid,sno) teacher(pid,tno) book(bno,bname) course(cno,cname) 联系转化成表 pb(pid,bno) tsc(t-pid,s-pid,cno) tc(pid,cno) 没有联系转化的表需要和实体转化的表合并,4.3.3练习与讨论：参考答案2-1,父类并入子类，只为子类建表2-1 实体转化成表 student(pid,sno,name,age) teacher(pid,tno,name,age) book(bno,bname) course(cno,cname) 联系转化成表 pb(pid,bno)/pid参照谁？ tsc(t-pid,s-pid,cno) tc(pid,cno) 没有联系转化的表需要和实体转化的表合并,4.3.3练习与讨论：参考答案2-2,父类并入子类，只为子类建表2-2 实体转化成表 student(pid,sno,name,age) teacher(pid,tno,name,age) book(bno,bname) course(cno,cname) 联系转化成表 sb(pid,bno) tb(pid,bno) tsc(t-pid,s-pid,cno) tc(pid,cno) 没有联系转化的表需要和实体转化的表合并,4.3.3练习与讨论：参考答案三,子类并入父类，只为父类建表 实体转化成表 person(pid,name,age,sno,tno) book(bno,bname) course(cno,cname) 联系转化成表 pb(pid,bno) tsc(t-pid,s-pid,cno) tc(pid,cno) 没有联系转化的表需要和实体转化的表合并,4.3.3练习与讨论,对学校系统： 比较继承关系几种处理方案优缺点 你更喜欢哪种方案？,2019年11月5日星期二,39,数据库系统概念-E-R,4.3.4聚集表,聚集的处理方案 联系及相关实体聚集成的高层实体，核心是被聚集的“联系” 聚集成的高层实体本身不转化成表 高层实体参与的联系进行正常的表转化，高层实体的主码使用聚集的“核心联系”的主码代替 示例，E-R图转化为表 custom(),bank(),project() order(cid,pid) guarantee(cid,pid,bid),2019年11月5日星期二,40,数据库系统概念-E-R,4.3.4聚集表,思考，对E-R图所示概念模型： 不使用聚集，如何绘制E-R图？ 相应E-R图如何转成模式? 最终得到的逻辑模式相同吗？哪个更好？,2019年11月5日星期二,41,数据库系统概念-E-R,4.3.4聚集表,方案二：联系实体化 custom(),bank(),project() order(oid,cid,pid,) guarantee(oid,bid ) 方案三：看作两种不同的联系 custom(),bank(),project() order(cid,pid) Guaranteed-order(cid,pid,bid) 思考：哪种方案更好？,4.3.4练习,2019年11月5日星期二,42,请建立排课系统E-R图，并转换成表：,4.3.4练习,参考方案(一)：使用聚集 Class(classno,) Course(cno,) Teacher(tno,) Givclass (tno,cno,classno,classroom) Givclass_time (tno,cno,classno,time) Assistant (assistanttno,tno,cno,classno),2019年11月5日星期二,43,4.3.4练习,2019年11月5日星期二,44,参考方案(二)：联系实体化 Class(classno,) Course(cno,) Teacher(tno,) Givclassitem (gno,teacher_tno,cno,classroom) /合并了讲授、关于两个联系 Givclassitem_time(gno,time) Givclass(gno,classno) Assistant(assistant_tno,gno),4.3.4练习,2019年11月5日星期二,45,参考方案(三)：看作两个不同的联系 Class(classno,) Course(cno,) Teacher(tno,) Givclass(tno,cno,classno,classroom) Givclass_time(tno,cno,classno,time) Givclasswithassistant (tno,cno,classno,assisttno,classroom) /独立于givclass联系 /需要有classroom属性 Givclasswithassistant_time (tno,cno,classno,assisttno,time) 试比较方案一二三，你认为哪种方案更合适？,2019年11月5日星期二,46,数据库系统概念-E-R,4.4关系模式优化,逻辑模型设计步骤 1、E-R图转换为表并进行必要合并 本步可以按照机械方法完成 2、逻辑模型优化 本步无具体可行的机械方法 主要依靠设计人员的经验和能力 逻辑模型优化 本章讨论几个优化示例 请通过示例，体会设计和优化的基本思路,2019年11月5日星期二,47,数据库系统概念-E-R,4.4关系模式优化：示例一,示例：请将E-R图转化为表并进行必要的合并 假设每个实体都有属性no和name 思考： 转化的结果还有进一步优化的余地吗？ 如果有优化余地，如何优化？利弊如何？,2019年11月5日星期二,48,数据库系统概念-E-R,4.4关系模式优化：示例一,E-R图转化为表： S(sno,sname) T(tno,tname) C(cno,cname) SCT(sno,cno,tno) TC(tno,cno)/cno：not null 合并 T+TC=T(tno,tname,cno)/cno可以为空 思考： 第一种改进思路 既然tno cno,则SCT必有冗余数据 能否将SCT(sno,cno,tno)简化为SCT(sno,tno)? 第二种改进思路 既然SCT已经包含TC关系 能否简单省略TC关系？,2019年11月5日星期二,49,数据库系统概念-E-R,4.4关系模式优化：示例一,请比较三种方案：(忽略了实体转化的表) E-R图转化成的关系模式： SCT(sno,cno,tno) TC(tno,cno) 将SCT简化为(sno,tno)： SCT(sno,tno) TC(tno,cno) 简单省略TC关系： SCT(sno,cno,tno) 思考： 哪个方案更合适？如果你是设计员，你会选择哪个方案？ 它的所有指标都是最好的吗？ 请体会：设计是在矛盾的指标中，评价选择最合适的方案,2019年11月5日星期二,50,数据库系统概念-E-R,4.4 关系模式优化,关系模式设计方案的评价标准 数据表示符合自然结构 清晰、简洁、易于理解 数据冗余小 数据访问效率高(查询效率、修改效率) 结构易于扩展 关系模式设计 设计方案的评价标准中，指标相互之间存在矛盾 设计是在矛盾的指标中，评价选择最合适的方案 工程思想和方法、设计人员的经验和能力：对模式设计都是重要的 E-R图转换为表 vs 模式优化设计 一个良好的E-R图，转换为表并进行必要的合并，得到的结果已经是比较理想的数据库模式 不排除还有人工进一步优化的余地 进一步的优化必须审慎，必须综合评价优化的优缺点,2019年11月5日星期二,51,数据库系统概念-E-R,4.4关系模式优化：示例二,针对E-R图表示的概念模型 请在不同设计方案中，评价选择最合适的方案 E-R图转化成的关系模式： S(sno,sname) C(cno,cname) SC(sno,cno,score) 合并为一个表： SC(sno,sname,cno,cname,score) 对SC扩展： S(sno,sname) C(cno,cname) SC(sno,sname,cno,cname,score) 思考： 比较各方案的优缺点 哪个方案更合适？如果你是设计员，你会选择哪个方案？ 没有标准答案、不能简单以对错进行评论,4.4关系模式优化：示例三,针对E-R图所示概念模型，父类子类分别建表： person(pid,name,age) student(pi