关于询问关系数据库中识别和非识别关系的差异/解释有几个问题。
我的问题是，你能想出一个更简单的术语来形容这些行话吗？我知道技术术语必须是具体的和明确的。但是拥有一个“替代名称”可能会帮助学生更容易地理解背后的概念。
我们实际上想在我们自己的数据库建模工具中使用更通俗的术语，以便没有太多计算机科学背景的初学者可以更快地学习。
干杯！
问问题
2157 次
6 回答
4
我经常看到子表或从属表被用作外行术语。您可以将这些术语中的任何一个用于具有识别关系的表
然后说引用表是具有非标识关系的表。
例如，PhoneNumbers是 的孩子，Users因为电话号码与其用户具有识别关系（即 的主键PhoneNumbers包括 的主键的外键Users）。
而Users表有一个state列是表的外键States，使其成为非标识关系。所以你可以说Users references States，但它本身并不是它的孩子。
于 2009-10-22T06:04:09.120 回答
3
我认为属于将是识别关系的好名字。
一个“弱实体类型”没有自己的key，只有一个“partial key”，所以这个弱实体类型的每个实体实例都必须属于某个其他实体实例才能被识别，这就是“识别关系” ”。例如，房东可能有一个包含公寓和房间的数据库。房间可以称为厨房或浴室，虽然该名称在公寓内是唯一的，但数据库中将有许多房间名称为厨房，因此它只是部分键。要在数据库中唯一标识一个房间，您需要说它是这个特定公寓的厨房。换句话说，房间属于公寓。
于 2009-10-22T13:13:27.043 回答
1
我将推荐 ER 建模中的“弱实体”一词。
一些建模者将主题概念化为由实体和实体之间的关系组成。这产生了实体关系建模（ER 建模）。属性可以绑定到实体或关系，并且存储在数据库中的值是属性的实例。
如果你做 ER 建模，有一种实体叫做“弱实体”。弱实体的部分身份是弱实体所属的更强实体的身份。
一个示例可能是订单处理系统中的订单。订单由行项目组成，每个行项目包含一个产品 ID、一个单价和一个数量。但订单项并没有在所有订单中都有识别号。相反，行项目由 {item number, order number} 标识。换句话说，一个订单项不能存在，除非它是一个订单的一部分。项目编号 1 是它所属的任何顺序中的第一个项目，但您需要两个数字来标识一个项目。
将 ER 模型转换为关系模型很容易。对于数据专家但对数据库一无所知的人来说，习惯于他们所理解数据的 ER 模型也很容易。
还有其他建模者强烈反对 ER 建模的必要性。我不是其中之一。
于 2009-10-22T12:33:37.540 回答
1
没有，在那种遇到诸如“关系”（ER，我认为）之类的东西的建模中绝对没有什么是“技术性的”、“精确的”或“明确的”。也不可能。
A) ER 建模总是并且必然是非正式的，因为它永远不足以捕获/表达数据库的整个定义。
B) 那里有太多不同的 ER 方言，不可能所有人都使用完全相同的术语和完全相同的含义。最近，我什至发现一些教授 ER 建模的英国大学使用术语“实体子类型”来表示我一直用来命名“实体超类型”的相同事物，反之亦然！
于 2009-10-22T13:04:34.317 回答
0
一个可以使用connection.
您在两个表之间有连接，其中 ID 相同。
那种东西。
于 2009-10-22T05:43:14.107 回答
0
怎么样
- 协会
- 关联
- 相关性
于 2009-10-22T05:50:18.597 回答