强实体类型和弱实体类型的示例答案

【问题标题】：Example of a strong and weak entity types强实体类型和弱实体类型的示例
【发布时间】：2011-01-19 23:23:05
【问题描述】：

我试图在 Google 上找到关于weak和strong>strong entity type的合理解释，但我还没有完全理解它们。

谁能给我一个强弱实体类型的例子？

【问题讨论】：

标签： database weak-entity

【解决方案1】：

弱实体是只有在被另一个拥有时才能存在的实体。例如：一个ROOM只能存在于一个BUILDING中。另一方面，TIRE 可能被认为是一个强大的实体，因为它也可以在不附加到 CAR 的情况下存在。

【讨论】：

我不明白为什么会接受它，这完全是错误的。 @Paul 描述的应该使用存在依赖来建模。 Chen 在他 1976 年的论文中的定义是，如果一个实体集的实体不能根据其自身属性的值唯一标识，并且必须依赖相关实体集的（键）属性，则该实体集是弱的。另一个实体必须存在并拥有弱实体只是这个定义的逻辑含义，而不是相反。弱实体向实体添加有序数字的正确示例（即问题的答案编号）。

【解决方案2】：

只是为了玩它，问题是强实体类型，答案是弱的。问题总是存在的，但答案需要问题存在。

示例：Don't ask 'Why?' if Your Dad's a Chemistry Professor

【讨论】：

这是错误的，你可以使答案既强又弱。不同之处在于答案较弱，您可以为每个问题使用相同的编号（答案 1、2、3、...），但如果答案较弱，则必须为所有答案应用一个编号。这是因为如果你让答案变弱，你选择依赖 questionid 来创建答案的（复合）主键。通过确保存在存在依赖性（答案完全参与与问题的识别关系）来反映答案需要问题存在。即使它很强大，也可以这样做。
感谢@Warkst 的澄清。我想要一个更通用/日常生活的案例。

【解决方案3】：

弱实体是不能完全被自身属性识别的实体，以外键为属性（一般取主键关联的实体）。

示例

房间的存在完全取决于酒店的存在。所以房间可以被视为酒店的弱实体。
另一个例子是
如果该银行不存在，则该银行的银行帐户也就不存在。

【讨论】：

您对什么是弱实体的解释可能是这里最好的解释，但您并没有解释什么是强实体以及两种类型之间的区别。
@nbro，这是弱实体集的正确定义。强实体集正好相反，即：一个实体集，其实体可以根据实体集本身的属性值进行唯一标识。不同之处在于，您需要向弱实体集添加属性，以便能够通过添加代理键（在这种情况下它成为强实体）或向另一个（或多个其他）实体集（使其变弱，其他实体集为其标识符）。

【解决方案4】：

公司保险单为员工和任何受抚养人提供保险，如果没有员工，受抚养人就不能存在；也就是说，除非该人是员工的受抚养人，否则该人不能作为受抚养人获得保险。DEPENDENT 是“员工有受抚养人”关系中的弱实体

【讨论】：

我的 +1 为 Has word 。 “有”字更清楚。

【解决方案5】：

强大的实体

它可以在没有任何其他实体的情况下存在。

示例

Customer(customerid, name, surname)

弱实体

它依赖于一个主导实体，没有一个强大的实体就不可能存在。

示例

Address(addressid, addressName, customerid)

【讨论】：

解释为什么Customer和Address分别是强实体和弱实体。
地址持有customerId为FK，这意味着地址只对应于特定的customerId。地址实体将在没有任何客户的情况下进入完全无用状态。添加客户实体后，该值将添加到地址中。有错请指正。
这是一个不好的例子。一个地址可以在没有附加客户实体的情况下存在。一个更好的例子是有建筑物的公寓——没有建筑物，公寓就无法实际存在。您的示例更像是“轮胎”和“汽车”。虽然轮胎可能与汽车相关联，但不一定如此。

【解决方案6】：

弱实体的存在是为了解决多值属性问题。

有两种类型的多值属性。一个是对象的简单多值，例如作为学生属性的“爱好”。学生可以有许多不同的爱好。如果我们将爱好留在学生实体集中，“爱好”将不再是唯一的。我们创建一个单独的实体集作为爱好。然后我们根据需要将爱好和学生联系起来。爱好实体集现在是关联实体集。至于是否弱，我们需要检查每个实体是否有足够的唯一标识符来识别它。在许多人看来，一个爱好名称就足以识别它。

另一种类型的多值属性问题确实需要一个弱实体来解决它。假设在杂货库存系统中设置了一个项目实体。该项目是类别项目还是实际项目？这是一个很重要的问题，因为客户可以在同一时间以一定的数量购买相同的商品，但他也可以在不同的时间以不同的数量购买相同的商品。你能看到它是同一个项目，但不同的对象。该项目现在是一个多值属性。我们首先将类别项目与实际项目分开来解决它。两者现在是不同的实体集。类别item具有item的描述性属性，就像您通常想到的item一样。实际项目不能再具有描述性属性，因为我们不能有多余的问题。实际项目只能有项目的日期时间和数量。您可以根据需要链接它们。现在，让我们谈谈一个是否是另一个的弱实体。描述性属性足以识别类别项目实体集中的每个实体。实际项目只有日期时间和金额。即使我们抽出记录中的所有属性，我们仍然无法识别实体。想想这只是时间和数量。实际的项目实体集是一个弱实体集。我们借助类别项目实体集中的重复主键来识别集合中的每个实体。

【讨论】：

【解决方案7】：

./Database/DataModels/RelationalDataModel/WeakEntity

大概可以写成两个因素：

依赖：取决于识别实体集的存在（完全的，一对多的关系）。
标识：没有主键。它有一个部分密钥（或鉴别器）。它需要使用另一个表的主键来识别。

如果我们考虑一个包含问题和答案的数据库，那么问题将是强实体，答案将是弱实体。因此，Question (id, text) 和 Answer (number, question_id, text) 将是我们的表格。但是为什么Answer的表是一个弱实体呢？

对问题表的依赖性。 每个答案都与一个问题（假设）相关联，因此它不能单独存在。这就是为什么我们有人提出一个问题并自己回答，这样他们就可以帮助其他人并获得一些额外的喜欢。
从问题的主键识别。人们将无法识别答案（假设其 id 是数字标识符），因为一个问题可能由其标识符也可能存在于其他问题中的答案来回答。答案表的主键：(number, question_id)。

【讨论】：

【解决方案8】：

弱实体也称为依赖实体，因为它的存在依赖于其他实体。此类实体在 E-R 图中由双轮廓矩形表示。

强实体也称为独立实体。

【讨论】：

【解决方案9】：

在浏览搜索引擎几个小时后，我发现了一个网站，这里有一个很好的 ERD 示例：http://www.exploredatabase.com/2016/07/description-about-weak-entity-sets-in-DBMS.html

我重新创建了 ERD。不幸的是，他们没有指定弱实体的主键。

如果建筑物只能有一套公寓，那么似乎不会创建部分鉴别器房间号（即丢弃）。

【讨论】：

公寓是一个弱实体，因为如果没有它的识别所有者建筑物实体的存在，它就无法存在。不给弱实体提供主键。相反，部分标识符（由 DoorNo（门号）属性下的虚线表示）与 BNo 组合。来自 Buliding 实体的主键属性，以形成每个公寓实例的唯一标识。

【解决方案10】：

弱实体类型：一个实体如果不与其他实体的实例链接就不能退出，称为弱实体类型。它不能独立存在。例如：我们的电脑依赖于我们，它不会自己打开或关闭。

强实体类型：链接到任何其他实体类型的实例的实体称为强实体类型。它可以独立退出。例如：一个人可以做任何事情可以去任何地方和使用任何东西

【讨论】：

【解决方案11】：

可以存在而不依赖于另一个数据对象的存在的数据对象称为强数据对象。

【讨论】：

强数据对象是什么意思？

【解决方案12】：

ARC 中引入了第一个强/弱引用类型。在非 ARC 分配/保留中正在使用。强引用意味着您想“拥有”您使用此属性/变量引用的对象。只要您使用强引用指向它，编译器就会注意您分配给此属性的任何对象都不会被破坏。只有将属性设置为 nil 后，对象才会被销毁。

弱引用表示您不想控制对象的生命周期或不想“拥有”对象。您弱引用的对象仅存在，因为至少有一个其他对象持有对它的强引用。一旦不再是这种情况，对象就会被销毁，并且你的弱属性将自动设置为 nil。 iOS 中最常见的弱引用用例是 IBOutlets、Delegates 等。

【讨论】：

问题是关于数据库中的实体，而不是作为编程语言结构的强/弱引用。