关于ER / EER图的快速问题。
我已经制作了这个实体关系图，但有人告诉我，朋友说它有问题。它有什么问题吗？
ER图是图书馆管理系统的设计，成员可以一次借5本书。系统的其余功能是普通库的功能。
答案 0 :(得分：0)
我不了解图书管理员与卡片之间关系的实用性，我也不明白为什么这些图书会分成两个实体。
我会做3个实体：
-member
-card
-book
每个会员都有一张卡，每张卡都是一张卡; 每个成员都可以拿很多书，每本书都可以被许多成员带走，
成员和书籍之间的关系在逻辑架构中创建另一个表：贷款。在插入新贷款之前，您可以检查该成员是否有5个活跃贷款（通过检查贷款表中的活动属性）。
答案 1 :(得分：0)
您的上下文对我来说不完整。我没有看到你的问题/情况的完整描述，所以我将基于假设和我一生中的经历来回答。所以，让我们看看......
tino用户质疑两个实体（标题和卷）的存在，这是重要的事情。让我解释一下，这将消除这个错误。以前（前一段时间）我们有视频租赁店（我不知道你的居住地是否正确，英语不是我的母语）。记得？我们曾经去那里租VHS录像带在家观看。
我们租来的不是电影，而是更多的副本/ midia。电影将始终具有相同的演员，导演，头衔等，但副本可能具有不同的属性/属性，例如媒体制作年份，可用语言，到期年份等。所以我们有两个截然不同的东西。
但是尽管如此，我们还是要考虑是否需要为持久性创建两个实体。我们必须记住是否需要保留这些信息。如果副本/ midia没有属性，那么它的实体就不应该存在，而用户真正租用的是电影标题。
在你的情况下，我相信卷和标题之间的关系确实表达了这种差异。
让我们谈谈图书管理员和头衔之间的关系。图书管理员管理的是什么？它是否管理永不改变的标题，是抽象的东西，还是库中存在的物理对象？ ：）
最后，我们来谈谈借款关系。当我们分解1-N（或N-1）关系时，我们总是将主键从1侧传递到N侧，解决了与实体 - 关系图中物理模型形成的关系。
尽管这里的关系是0-5，为了解析它，我们不会有完全的0-5关系。无论如何，我们都会将主键从两侧传递到由这种关系形成的表格。因此，这里我们最初在成员和数量之间存在N-N关系。
N-N关系允许实体之间的可选关系。这意味着我们可以在这里获得零边基数。要限制可以租借的书籍数量，您需要使用SQL或数据库中的任何过程语言实现限制/约束。在这种情况下，您可以实现before insert触发器。此触发器有责任验证此限制以允许或拒绝整个操作的完成。
很明显，我并不是说你应该删除这种表示法。你的概念模型应该表达它。但是当你分解时，你必须记住这一点。我想你应该纠正它。
记住一条重要规则：具有属性/属性（属性/属性）的关系只能存在于N-N关系中。如果必须将属性/属性放在1-N（或N-1）关系中，则它们（属性/属性）将始终位于N侧。总之，关系中的属性没有N-1（或1-N）关系。只有N-N关系可以具有属性/属性。所以要小心。
如有任何问题或澄清，请发表评论，我会回答。
答案 2 :(得分：0)
我认为没有理由区分会员和卡。卷和图书馆员没有主键。它们应该是弱实体吗？对于图书管理员来说这没有意义，而Volume需要一个标识符来区分不同的副本。
