在我们的任务中,我们的教授给出了一个特定数量的实体,让我们说:
餐厅有20名员工。 那么,这是1:M还是一个是1 .. *?
餐厅有2名或更多员工? 再次,这是1:M还是一个是1 .. *?
我在网上搜索了这个,Why is a specific cardinality not allowed in the ERD?
我对这个例子感到困惑,那里有说明
航班和飞行员之间的关系,每个航班正好有2名飞行员在场,必须表示为:
|飞行| 0..N< ------> 1..N | pilot |
而不是
|飞行| 0..N< ------> 2 |飞行员|
不是上面的基数是1:M
谢谢!
答案 0 :(得分:1)
在ERD和一般的数据库设计中,我们很少关注" 1"和"很多"。
之所以这样,是因为,(a)至少当前数据库的工作方式,如果有一个特定的数字而不是简单的"很多"它通常不会改变结构。 (b)它们很少是1以外的固定数字。
首先采取(b):在你的问题中,你提到一个有20名员工的餐馆。但餐厅不太可能总共有20名员工而且总是会。如果他们今天有20个,也许明天有人退出,只有19个,那么主人在他的旺季雇用了5个人,所以现在有24个,然后他放下2个临时所以现在有22个,等等。
关于(a),请考虑如何设计表格。假设您有一个Restaurant表和一个Employee表。关系是1:M。因此,每个Employee记录都有一个已发布的外键到餐厅记录。无论餐厅有2名员工还是2000名员工,餐桌结构都是一样的。如果我们经常在餐馆之间洗牌员工 - 我想到这里的连锁店 - 可能还有M:M关系,所以我们需要一个新的餐桌,Restaurant_employee,带有restaurant_id和employee_id,以建立联系。但是,无论一个员工是在2家餐馆工作还是10家餐馆,都不会改变结构。
如果您需要强制执行特定的数字,例如我们有一条规则,即没有餐厅可以拥有超过49名员工(也许是因为如果这样做了,那么我们就不再有资格成为"小型企业&# 34;根据政府法规,因此有各种额外费用,或者其他任何),我们通常不会通过数据库结构强制执行,而是使用程序代码中的规则。
当存在特定数字但数量很少时,数据库设计人员有时会通过为指针而不是单独的表创建多个字段来将其硬编码到数据库设计中。就像在餐厅表中为#34;员工1","员工2","员工3"等创建列。这违反了规范化规则,几乎总是坏的这个想法有很多原因,但人们会这样做。
答案 1 :(得分:0)
通常,一般来说,> 1表示许多或M.一些较新的符号和UML和XSD使用*为许多。 在符号中使用实际数字是不常见的。