这个图书馆管理系统ER图正确吗？

Question

关于ER/EER图的快速问题。

我制作了这个实体关系图，但我的一个朋友告诉我，它有问题。有什么问题吗？

ER图是一个图书馆管理系统的设计，其中一个成员一次可以借5本书。系统的其余功能是一个正常的库如何工作的。

Library Management System EER

Answer 1

我不明白图书管理员和卡片之间的关系有什么用，我也不明白为什么书被分成两个实体。

我会做3个实体：

-member

-card

-book

每个会员有一张卡，每张卡属于一个会员，每个会员可以带多本书，每本书可以由多个会员带，

成员和图书之间的关系在逻辑架构中创建了另一个表: loans。在插入新贷款之前，您可以检查成员是否已有5个活动贷款(通过检查loans表中的active属性)。

Answer 2

你给出的上下文对我来说是不完整的。我看不到你的问题/情况的完整描述，所以我将根据假设和我在生活中的经验来回答。让我们看看..。

tino用户质疑标题和卷这两个实体的存在，这一点很重要。让我解释一下这一点，这将消除这一错误。以前(一段时间以前)我们有视频租赁商店(我不知道这是不是你住的地方的正确名称，英语不是我的母语)。想起来了吗？我们过去常去那里租录像带在家看。

我们租的不是电影，而是更多的拷贝。一部电影总是具有相同的演员、导演、标题等，但拷贝可以具有不同的属性/属性，例如媒体制造的年份、可用的语言、过期年份等。所以我们有两种截然不同的东西。

但尽管如此，我们必须考虑是否需要为持久性创建两个实体。如果我们需要持久化这些信息，我们必须记住。如果copy/midia没有属性，那么它的实体就不应该存在，用户真正租用的应该是电影标题。

在你的例子中，卷和标题之间的关系，我相信，是真正表达了这种差异。

让我们来谈谈图书管理员和标题之间的关系。图书管理员管理的是什么？它是管理永远不变的抽象事物的标题，还是管理库中存在的物理对象？:)

最后，让我们来讨论一下借入关系。当我们分解1-N (或N-1)关系时，我们总是将主键从1端传递到N端，将该关系解析为实体-关系图中物理模型的形成。

尽管这里的关系是0-5，但为了分解它，我们不会有确切的0-5关系。无论如何，我们必须将主键从两端传递到由该关系形成的表中。因此，在这里，我们最初有一个成员和体积之间的N-N关系。

N-N关系允许实体之间的可选关系。这意味着我们可以在这里有零边基数。要限制可以借出的图书数量，需要使用SQL或数据库中的任何过程语言实现限制/约束。在这种情况下，您可以实现before insert触发器。此触发器有责任验证此限制，以允许或denny作为一个整体完成操作。

需要明确的是，我并不是说你应该删除这个符号。你的概念模型应该表达它。但是当你分解的时候，你必须记住这一点。我觉得你应该改正它。

记住一条重要的规则:具有属性/属性(属性/属性)的关系只能存在于N-N关系中。如果您必须将属性/属性放在1-N (或N-1)关系中，它们(属性/属性)将始终处于N边。总而言之，关系中的属性不存在N-1 (或1-N)关系。只有N-N关系才能有特性/属性。所以要小心这一点。

任何问题或澄清，请提出意见，我将回答。

Answer 3

我看不出有什么理由去区分会员和卡片。Volume和Librarian没有主键。它们应该是弱实体吗？这对于Librarian和Volume来说是没有意义的，需要一个标识符来区分不同的副本。