database-design - 在数据库中建模是/否属性

Question

我有一个相当常见的场景，用户可以从一组属性中进行选择。 UI 中的属性由复选框表示。

例如:

组件:硬盘(y/n)、CPU(y/n)、显示器(y/n)、键盘(y/n)等......

过去，我通常对这种情况进行建模:

"PCs" 1:M "PC Components" M:1 "Components"

另一种选择是将“属性”作为“PC”表中的 y/n 字段。

例如

PCs (table)
-----------
PCId(PK)
Harddrive(y/n)
CPU(y/n)
etc...

在过去，我选择一个与另一个的理由是基于用户是否可以输入新属性。如果答案是肯定的，那么我会选择第一个选项，如果答案是否定的，那么我通常会选择 y/n 属性。

但是现在我有一个场景，其中大约有 20 个属性分为多个类别。创建 ERD 后，它看起来“错误”，并且该表的列数非常多。

我的问题是，是否有标准/正确的方法来建模？如果有，它有名字吗？

Answer 1

人们很想设计一个更“紧凑”的数据模型(每个属性不是一列)，因为属性具有兼容的数据类型(它们都是 y/n)。

如果每个属性都有不同的数据类型，例如，如果它们被限制为使用不同查找表的一组值，那么您必须为每个属性使用一列是显而易见的。

见 Domain-Key Normal Form .将 y/n 属性建模为行意味着无法表示强制性属性(必须具有 Y 或 N 值)。所以你会有一些限制，即 N 个属性必须有 N 行。对最小行数的约束既不是域约束也不是键约束，因此它没有通过 DKNF 测试。

没有必要每个表都必须符合 DKNF，但是如果您问什么术语描述了每个属性的列的设计，我建议“域/键范式”适合。