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