请教关于 ER 图

[weishao666]

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

表结构：
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 友能帮忙指点下，上学时候就没搞明白，在谷歌看了一圈更懵逼了

[Licsber]

不太清楚对不对 仅供参考
贴一下我整理的笔记：
概念结构设计的方法、实体属性划分原则、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]

ER 图的线，只有两端有多重性和约束，中间是没有东西的。（有些图，会用线去表示关系，那么线中间就是关系的描述，但 ER 图是用菱形的框表示关系，线只是用来连图的，不是关系）。双框菱形代表的是识别关系不是弱实体，弱实体要用双框矩形表示。

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

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

ER 图是概念模型，数据库表设计是逻辑模型或物理模型，两者之间不是一码事。你这个图上面，Contain （包含关系）是多对一关系，对应到逻辑模型中，可能是独立的表，也可能是 Ingredient 表的 cakeId、qty 两个列，具体哪个取决于设计者。Order 是多对多关系，对应到逻辑模型中就必然是独立的表。另外，如果 ER 图中把 Order 换成实体，逻辑模型设计是不变的。

[passerbytiny]

关于 ER 建模，我建议你系统的看下这个博客系列： https://www.cnblogs.com/muchen/category/794749.html

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

还有，一些博客，以及一些画图工具、建模工具，尤其是一些数据库工具，会把 ER 模型跟数据库设计一同看待，那是认识上的一瓶不满半瓶咣当或者商业需要，千万不要上当。