如何确定一个想法在关系数据库中应该被视为table还是属性？
how to determine whether an idea should be treated as table or attribute in relational database?
我是一名数据库初学者，我对实体关系感到困惑。我不知道什么时候应该将 idea 归类为属性（即字段）或 table（即实体）。你能帮我理解这一点吗？谢谢。
术语问题可能会造成混淆。并且特别难以帮助你，因为自从 1970 年关系模型推出以来，专家和作者并不总是彼此一致。这是我的学习方式。
在概念层面，人们关心数据库存储和管理的值如何与主题相关。主题被分析为实体和实体之间的关系（ER 模型）。属性是可以用数据值描述的实体或关系的特征。数据库值是属性的实例。
在逻辑层面，人们关注数据的关系模型。关系数据模型中的关系非常像数学关系，因此可以假定关系数学成立。在概念层面发现的属性成为关系的（命名的）属性。关系是具有共同属性的元组集。元组由键标识，并由外键在别处引用。对数据的约束强制执行某些业务规则。值存储在属性和元组的交集处。
在物理层面上，人们关注由行和列组成的 table。此外，还有一些数据库对象，例如索引和 table 可能是特定于 DBMS 的空间。 table 是关系的表示，其中行表示元组，列表示属性。值存储在行和列的交叉点。
SQL 服务器文档倾向于使用术语记录和字段，而我会使用术语行和列。
概念级别描述的是不考虑实施的要求。
逻辑级别特定于关系实现。
物理级别特定于特定的 DBMS 产品，例如 Oracle 或 SQL 服务器。
在实践中，我用SQL术语表达逻辑层次，例如table行和列，但我尽量不依赖于DBMS。
恐怕这个描述非常简洁。有能力的作者可以用一百页的文字来充实我刚才说的话。但我希望它有所帮助。
简答：
实体是我们描述的任何东西，由 table 的键中的值表示。属性是描述，由值对表示的一对一关系。关系是值集之间的任何关联，属性是一种特殊的关系。列代表值集。表表示关联的值集，因此表示一种或多种关系。键代表实体。外键约束表示值集的子集。
长答案：
Peter Chen 将属性定义为从实体集或关系集映射到值集（或值集的笛卡尔积）的函数。他还解释说，实体存在于头脑中，并由数据库中的值表示。因此，实体是函数依赖的概念域，即在规范化数据库中，实体集是我们用键表示的。
属性不等于字段，而是映射，在 table 中由（键，值）对表示。例如，一个人的年龄是一个属性，物理上由一个人的 ID 和 Age 字段中的年数表示。 Age 列本身只是函数的映像（从属端）。
通过阅读 Chen 的论文可以清楚地看出，实体在 table 中并未表示为行，这与普遍看法相反。实体由值表示，属性由值对表示。因此，一个关系实体table表示一个关系，它可以是一个或多个属性，在由键表示的实体集上。这也意味着我们可以有任意数量的 table 描述同一个实体集，允许我们根据需要将相关属性组合在一起。
有关更多信息，我建议复习基本的集合论，例如MathIsFun，然后阅读 Chen 的论文：The Entity-Relationship Model - Toward a Unified View of Data（PDF 可在网上找到）。该论文的参考书目引用了其他有用的论文。
实际上，它可能会帮助您查看 Object-Role Modeling。 ORM 是一种无属性的图表符号和规则，允许人们设计逻辑模型而不必在实体和属性之间进行选择。该决定可以推迟到物理设计阶段，并且可以根据模型中的键和功能依赖性而不是任意决定。
最后，Bill Kent 在他的书中探讨了概念问题 Data and Reality。这是对数据建模和关系概念主题的精彩介绍。
我是一名数据库初学者，我对实体关系感到困惑。我不知道什么时候应该将 idea 归类为属性（即字段）或 table（即实体）。你能帮我理解这一点吗？谢谢。
术语问题可能会造成混淆。并且特别难以帮助你，因为自从 1970 年关系模型推出以来，专家和作者并不总是彼此一致。这是我的学习方式。
在概念层面，人们关心数据库存储和管理的值如何与主题相关。主题被分析为实体和实体之间的关系（ER 模型）。属性是可以用数据值描述的实体或关系的特征。数据库值是属性的实例。
在逻辑层面，人们关注数据的关系模型。关系数据模型中的关系非常像数学关系，因此可以假定关系数学成立。在概念层面发现的属性成为关系的（命名的）属性。关系是具有共同属性的元组集。元组由键标识，并由外键在别处引用。对数据的约束强制执行某些业务规则。值存储在属性和元组的交集处。
在物理层面上，人们关注由行和列组成的 table。此外，还有一些数据库对象，例如索引和 table 可能是特定于 DBMS 的空间。 table 是关系的表示，其中行表示元组，列表示属性。值存储在行和列的交叉点。
SQL 服务器文档倾向于使用术语记录和字段，而我会使用术语行和列。
概念级别描述的是不考虑实施的要求。 逻辑级别特定于关系实现。 物理级别特定于特定的 DBMS 产品，例如 Oracle 或 SQL 服务器。
在实践中，我用SQL术语表达逻辑层次，例如table行和列，但我尽量不依赖于DBMS。
恐怕这个描述非常简洁。有能力的作者可以用一百页的文字来充实我刚才说的话。但我希望它有所帮助。
简答：
实体是我们描述的任何东西，由 table 的键中的值表示。属性是描述，由值对表示的一对一关系。关系是值集之间的任何关联，属性是一种特殊的关系。列代表值集。表表示关联的值集，因此表示一种或多种关系。键代表实体。外键约束表示值集的子集。
长答案：
Peter Chen 将属性定义为从实体集或关系集映射到值集（或值集的笛卡尔积）的函数。他还解释说，实体存在于头脑中，并由数据库中的值表示。因此，实体是函数依赖的概念域，即在规范化数据库中，实体集是我们用键表示的。
属性不等于字段，而是映射，在 table 中由（键，值）对表示。例如，一个人的年龄是一个属性，物理上由一个人的 ID 和 Age 字段中的年数表示。 Age 列本身只是函数的映像（从属端）。
通过阅读 Chen 的论文可以清楚地看出，实体在 table 中并未表示为行，这与普遍看法相反。实体由值表示，属性由值对表示。因此，一个关系实体table表示一个关系，它可以是一个或多个属性，在由键表示的实体集上。这也意味着我们可以有任意数量的 table 描述同一个实体集，允许我们根据需要将相关属性组合在一起。
有关更多信息，我建议复习基本的集合论，例如MathIsFun，然后阅读 Chen 的论文：The Entity-Relationship Model - Toward a Unified View of Data（PDF 可在网上找到）。该论文的参考书目引用了其他有用的论文。
实际上，它可能会帮助您查看 Object-Role Modeling。 ORM 是一种无属性的图表符号和规则，允许人们设计逻辑模型而不必在实体和属性之间进行选择。该决定可以推迟到物理设计阶段，并且可以根据模型中的键和功能依赖性而不是任意决定。
最后，Bill Kent 在他的书中探讨了概念问题 Data and Reality。这是对数据建模和关系概念主题的精彩介绍。