如何确定一个想法是不是应该被视为关系数据库中的表或属性？

Posted 2023-02-16

【中文标题】如何确定一个想法是不是应该被视为关系数据库中的表或属性？

【英文标题】：how to determine whether an idea should be treated as table or attribute in relational database?如何确定一个想法是否应该被视为关系数据库中的表或属性？

【发布时间】：2015-09-26 00:26:35

【问题描述】：

我是数据库初学者，我对实体关系感到困惑。我不知道什么时候应该将想法归类为属性（即字段）或表（即实体）。你能帮我理解这一点吗？谢谢。

【参考方案1】：

简答：

实体是我们描述的任何东西，由表键中的值表示。属性是描述，由值对表示的一对一关系。关系是值集之间的任何关联，属性是一种特殊的关系。列代表值集。表表示相关的值集，因此表示一种或多种关系。键代表实体。外键约束表示值集的子集。

长答案：

Peter Chen 将属性定义为从实体集或关系集映射到值集（或值集的笛卡尔积）的函数。他还解释说，实体存在于头脑中，并由数据库中的值表示。因此，实体是功能依赖的概念域，即在规范化数据库中，实体集是我们用键表示的。

属性不等于字段，而是映射，在表中由（键，值）对表示。例如，一个人的年龄是一个属性，物理上由一个人 ID 和年龄字段中的年数表示。 Age 列本身只是函数的图像（依赖端）。

从阅读 Chen 的论文中可以清楚地看出，实体在表格中不表示为行，这与普遍看法相反。实体由值表示，属性由值对表示。因此，关系实体表表示在由键表示的实体集上的关系，可以是一个或多个属性。这也意味着我们可以有任意数量的表来描述相同的实体集，从而允许我们根据需要将相关属性组合在一起。

要了解更多信息，我建议复习基本集合论，例如MathIsFun，然后阅读陈的论文：The Entity-Relationship Model - Toward a Unified View of Data（PDF 可在网络上获得）。该论文的参考书目参考了其他有用的论文。

实际上，查看Object-Role Modeling 可能会对您有所帮助。 ORM 是一种无属性的图表符号和规则，它允许人们设计逻辑模型而不必在实体和属性之间进行选择。该决定可以推迟到物理设计阶段，并且可以根据模型中的键和功能依赖关系而不是随意做出。

最后，Bill Kent 在他的书Data and Reality 中探讨了概念问题。这是对数据建模和关系概念主题的精彩介绍。

【讨论】：

根据 Chen 的说法，关于实体和表行之间的区别非常好。这是一个非常微妙的点，而将 ER 建模和关系建模视为做同一件事的不同方式的人们通常会忽略这一点。

当人们使用 ER 图来描述关系模型时，情况会变得更糟。

【参考方案2】：

术语问题可能会造成混淆。并且特别难以为您提供帮助，因为自关系模型于 1970 年推出以来，专家和作者之间并不总是一致。以下是我的学习方法。

在概念层面，人们关注的是数据库存储和管理的值如何与主题相关。主题被分析为实体和实体之间的关系（ER模型）。属性是可以用数据值描述的实体或关系的特征。数据库值是属性的实例。

在逻辑层面，人们关注数据的关系模型。关系数据模型中的关系非常类似于数学关系，因此可以假定关系数学成立。在概念级别发现的属性成为（命名的）关系属性。关系是一组具有共同属性的元组。元组由键标识并由外键在别处引用。对数据的约束强制执行某些业务规则。值存储在属性和元组的交集处。

在物理层面，我们关注由行和列组成的表。此外，还有可能是特定于 DBMS 的数据库对象，例如索引和表空间。表是关系的表示，其中行表示元组，列表示属性。值存储在行和列的交点处。

SQL Server 文档倾向于使用术语记录和字段，而我会使用术语行和列。

概念级别描述需求而不考虑实现。 逻辑级别特定于关系实现。 物理层特定于特定的 DBMS 产品，例如 Oracle 或 SQL 服务器。

在实践中，我用 SQL 术语表达逻辑级别，例如表、行和列，但我尽量使其不受 DBMS 依赖。

恐怕这个描述过于简洁了。有能力的作者可以用一百页的文字来充实我刚才所说的内容。但我希望它有所帮助。