外行人的任期于识别关系

Question

有的夫妇的问题，询问对于差异/解释上的识别和不确定的关系在关系数据库。

我的问题是，你能想到一个简单的术语为这些术语?我的理解是，技术条款必须具体和明确的。但具有一种'替代的名字，可能会帮助学生涉及更容易地这一概念背后。

实际上，我们希望使用更多的外行人的期限在我们自己的数据库建模工具，因此，第一次用户没有多大的计算机科学背景可以学得更快。

干杯！

Answer 1

我经常看到子表或依赖表用作非专业术语。您可以将这些术语中的任何一个用于具有标识关系的表

然后说引用表是一个具有非标识关系的表。

例如， PhoneNumbers 是 Users 的子，因为电话号码与其用户具有识别关系（即主键 PhoneNumbers 包含 Users 主键的外键。

Users 表具有 state 列，该列是 States 表的外键，使其成为非标识关系。所以你可以说 Users references States ，但它本身并不是它的孩子。

Answer 2

我认为属于对于识别关系来说是个好名字。

“弱实体类型”不具有其自己的密钥，仅具有“部分密钥”，因此该弱实体类型的每个实体实例必须属于某个其他实体实例，因此可以识别它，并且这是“识别关系”。例如，房东可以拥有一个包含公寓和房间的数据库。 房间可以被称为厨房或浴室，虽然该名称在公寓内是唯一的，但数据库中将有许多房间，名称厨房，因此它只是一个部分密钥。要唯一标识数据库中的房间，您需要说明这个特定公寓中的厨房。换句话说，房间属于公寓。

Answer 3

我打算推荐“弱实体”一词。来自ER建模。

某些建模者将主题概念化为由实体之间的实体和关系组成。这产生了实体 - 关系建模（ER建模）。属性可以绑定到实体或关系，存储在数据库中的值是属性的实例。

如果您进行ER建模，则会有一种称为“弱实体”的实体。弱实体的部分身份是弱实体所属的强实体的身份。

示例可能是订单处理系统中的订单。订单由订单项组成，每个订单项包含产品ID，单价和数量。但订单项在所有订单中没有标识号。相反，订单项由{商品编号，订单编号}标识。换句话说，订单项不能存在，除非它只是一个订单的一部分。项目编号1是它所属的任何顺序的第一个项目，但您需要两个数字来标识项目。

将ER模型转换为关系模型很容易。对数据专家但对数据库一无所知的人也很容易习惯他们理解的数据的ER模型。

还有其他建模者强烈反对ER建模的需要。我不是其中之一。

Answer 4

没有什么，在人们遇到诸如“关系”等事物之类的建模中绝对没有任何意义。 （ER，我推测）是“技术”，“精确”和“技术”。或“明确的”。它也不可能。

A）ER建模总是并且必然是非正式的，因为它永远不足以捕获/表达数据库的整个定义。

B）那里有许多不同的ER方言，所有人都不可能完全使用完全相同的术语。最近，我甚至发现一些教授ER建模的英国大学使用术语“实体子类型”。对于我一直用来命名“实体超类型”的相同的东西，反之亦然！

Answer 5

可以使用 connection 。

两个表之间有连接，其中ID相同。

那种事情。

Answer 6

怎么样

• 协会
• 链接
• 相关性