V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
weishao666
V2EX  ›  问与答

请教关于 ER 图

  •  
  •   weishao666 · 2020-03-16 13:08:53 +08:00 · 1603 次点击
    这是一个创建于 1702 天前的主题,其中的信息可能已经有所发展或是发生改变。

    场景: 面包店提供不同类型的蛋糕,蛋糕表包括蛋糕的名称,当前价格和每个蛋糕的份数。客户需要提前一天或更长时间下订单,然后在约定的日期提货。每个蛋糕都包含制作蛋糕所需的多种配料(例如面粉,糖,鸡蛋)。包含表说明每个蛋糕需要多少每种配料,而配料表存储每种配料的每磅成本和可用磅数。

    表结构:
    Customer (custid, custname, ccn, cphoneno, address, city, zip);
    Cake (cakeid, cakename, slices, status, price);
    Ingredient (ingredid, iname, price, available);
    Contain (cakeid, ingredid, qty);
    Orders (custid, cakeid, ordertime, pickuptime, pricepaid);

    这是我根据自己的理解画的 ER 图,123 处应该是有问题的,现在脑子很乱。首先 1 处,这个连线上到底是应该标注*还是 1-*呢? 2 处的弱实体是否应该用菱形表示呢,他是原料和蛋糕的关联表,这是属于实体还是关系呀,是不是有的关系会转换成数据库表,有的不会? 3 处蛋糕和客户之间是多对多的关系,但弱实体与强实体之间的对应关系只能是 1-1 或者*-1,这里该如何表示呢?正确的 ER 图应该是啥样的呢? ER 图

    有没有哪位 V 友能帮忙指点下,上学时候就没搞明白,在谷歌看了一圈更懵逼了

    3 条回复    2020-03-16 14:42:07 +08:00
    Licsber
        1
    Licsber  
       2020-03-16 13:25:06 +08:00
    ![8GXDYt.png]( https://s1.ax1x.com/2020/03/16/8GXDYt.png)
    不太清楚对不对 仅供参考
    贴一下我整理的笔记:
    概念结构设计的方法、实体属性划分原则、E-R 图集成的步骤和合并时的三种冲突问题: (掌握)
    E-R 模型是用 E-R 图来描述现实世界的概念模型,包括实体、属性、实体之间的联系。1. 实体之间的联系
    1. 两个实体型之间的联系 1. 一对一联系(1:1) 2. 一对多联系(1:n) 3. 多对多联系(m:n)
    2. 两个以上的实体型之间的联系
    3. 单个实体型内的联系
    2. E-R 图 提供了表示实体型、属性和联系的方法
    1. 实体型用矩形表示
    2. 属性用椭圆形表示
    3. 联系用菱形表示
    实体属性划分原则: 为了简化 E-R 图的处置,现实世界的事物能作为属性对待的尽量作为属性对待。
    1. 作为属性,不能再具有需要描述的性质
    2. 属性不能与其他实体具有联系
    E-R 图的集成:
    各子系统的 E-R 图之间的冲突主要有三类:
    1. 属性冲突:属性域冲突(属性值的类型、取值范围或取值集合不同)、属性取值单位
    冲突
    2. 命名冲突:同名异义、异名同义
    3. 结构冲突:同一对象在不同应用中具有不同的抽象、同一实体在不同子系统的 E-R 图
    中所包含的属性个数和属性排列次序不完全相同、实体间的联系在不同的 E-R 图中为不
    同的类型
    消除不必要的冗余,设计基本 E-R 图: 在初步 E-R 图中可能存在一些冗余的数据和实体间冗余的联系。
    逻辑结构设计中 E-R 图向关系模型转换的方法:(掌握)
    逻辑结构设计的任务就是把概念结构设计阶段设计好的基本 E-R 图转换为与选用数据库关 系产品所支持的数据模型相符合的逻辑结构。
    一个实体型转换为一个关系模式:
    1. 一个 1:1 联系可以转换为一个􏰀立的关系模式,也可与任一端对应的关系模式合并; 2. 一个 1:n 联系可以转换为一个􏰀立的关系模式,也可以与 n 端对应的关系模式合并; 3. 一个 m:n 联系转换为一个关系模式;
    4. 三个或三个以上实体间的一个多元联系可以转换为一个关系模式;
    5. 具有相同码的关系模式可合并。
    passerbytiny
        2
    passerbytiny  
       2020-03-16 14:31:44 +08:00
    ER 图的线,只有两端有多重性和约束,中间是没有东西的。(有些图,会用线去表示关系,那么线中间就是关系的描述,但 ER 图是用菱形的框表示关系,线只是用来连图的,不是关系)。双框菱形代表的是识别关系不是弱实体,弱实体要用双框矩形表示。

    你的 1、2、3 是关系的两端,并不是线的中间,代表的是多重性和约束。“蛋糕—配料”关系是一对多的关系,所以 1 那里是“*”(即 0..*,或者非强制、可多个),2 是这个关系的定义和描述,再右下是“1”(即 1..1,或者强制、单个),双框菱形表示 2 是识别关系,它额外点名了“配料”实体从属于“蛋糕”实体( ER 图的关系是没有方向的,需要自行判断)。上面虽然配料属于蛋糕,但配料本身不一定是弱实体,取决于你想不想让他独立,图上用得强实体,那么配料虽然属于蛋糕,但也是独立的。弱图上配料用了双框矩形点名时弱实体,那么配料就不是独立的,从而不会有 ingredid 这个属性。

    “蛋糕—顾客”关系是名为“订单”的识别关系,图中没有“订单”实体。“蛋糕—顾客”的多重性是多对多,即两端都是“*”(非强制、可多个),3 就表示的这个。这个图是严格学术性情况下才这么画,现实中不会将订单这么严格的定义为关系,而是直接定义成实体,此时订单将换成矩形,同时订单—蛋糕、订单—客户之间分别多出两个多对一的菱形。

    ER 图是概念模型,数据库表设计是逻辑模型或物理模型,两者之间不是一码事。你这个图上面,Contain (包含关系)是多对一关系,对应到逻辑模型中,可能是独立的表,也可能是 Ingredient 表的 cakeId、qty 两个列,具体哪个取决于设计者。Order 是多对多关系,对应到逻辑模型中就必然是独立的表。另外,如果 ER 图中把 Order 换成实体,逻辑模型设计是不变的。
    passerbytiny
        3
    passerbytiny  
       2020-03-16 14:42:07 +08:00
    关于 ER 建模,我建议你系统的看下这个博客系列: https://www.cnblogs.com/muchen/category/794749.html

    另外 ER 图是一种表示法,一般都不会采用原始的陈氏表示法。你这个图上实体的属性在矩形内书写,还有*、1 这些,就与原始表示法不相同。上面那个博客上面用乌鸦脚表示多重性,也与原始表示法不相同。关于原始的陈氏表示法,你可以看这里: https://www.vertabelo.com/blog/chen-erd-notation/

    还有,一些博客,以及一些画图工具、建模工具,尤其是一些数据库工具,会把 ER 模型跟数据库设计一同看待,那是认识上的一瓶不满半瓶咣当或者商业需要,千万不要上当。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1051 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 20:10 · PVG 04:10 · LAX 12:10 · JFK 15:10
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.