如何使用一个(非复合)候选键和所有非主属性构建 SQL 表?

How to structure SQL tables with one (non-composite) candidate key and all non-primary attributes?

我对关系数据库不是很熟悉,但这是我的问题。

我有一些原始数据是通过客户调查收集的。对于参与的每个客户,只有一个记录,并且由 CustomerId 属性唯一标识。我认为所有其他属性都属于非主键描述,因为除了非复合候选键之外,没有其他属性依赖于另一个属性。此外,所有列都是原子的,例如,none 可以拆分为多个列。

例如,列有 CustomerId(非顺序)、Race、Weight、Height、Salary、EducationLevel、JobFunction、NumberOfCars、NumberOfChildren、MaritalStatus、GeneralHealth、MentalHealth,我总共有 100 多个这样的列.

因此,据我了解,我们不能谈论对此类数据集进行任何形式的规范化,对吗?

但是,鉴于列数过多,如果我想将这个庞大的 table 拆分为具有较少列的 table ,即基于某些列的分类,如人口统计、健康、就业等等,在文献中有这样一个 structure/approach 的具体名称吗?所有 table 仍将使用 CustomerId 作为它们的主键。

是的,这是任务的一部分,作为任务的一部分,需要将此数据集放入关系数据库,而不是文档数据库,我认为无论如何在这种情况下都不会获得任何好处。

因此,没有像我上面所说的那样直接的问题,但创建一个包含 100 多个列的 table 对我来说并不合适。因此,我想了解的是该理论如何处理此类斑点。一些概念名称或进一步调查的潜在想法将不胜感激,因为我什至不知道如何查找它。

在关系数据库中使用 table 中的所有信息并不是一个好的用法。 正如您提到的,在其他 table 中摸索一些列并将所有 table 与主 table 连接起来很好。在这种用法中,您还可以管理一对多、多对一和多对多关系。例如客户可能有多个地址或 phone 个号码。

另一种用法是使 table 类似于 customer_properities 并使用像 property_type 和 property_value 这样的列并按行存储数据。 但第一种用法更有效,也是最常见的用法

customer_id  property_type   properity_value
1            num_of_child     3
1            age              22
1            marial_status    Single
.
.
.