【问题标题】:Optimal relational design for groups and subgroup relationships组和子组关系的最佳关系设计
【发布时间】:2018-03-01 22:40:06
【问题描述】:

我有一个介绍级的关系数据库设计问题。我正在从事一个项目,我从科学期刊文章中捕获信息并将其存储在 Postgres 数据库中。我的主要目标之一是定义一个足够灵活的架构,以涵盖我可能在大量论文中遇到的大多数案例。实际上,文章倾向于报告一组半标准的细节,但一旦你进入细节,肯定会有差异。这些东西是为人类而不是机器编写的。

在大多数情况下,定义架构非常简单,但我坚持的一件事是如何合理地构建一组表以捕获有关研究的主题组和主题子集的详细信息。

以一个简单的随机对照试验为例 - 您通常有一组被确定为合格的人,一组被确定为合格,一组被随机分配到对照组,一组被随机分配到治疗组。在每个组中,您可以以各种特定方式定义子组,但通常按某种间隔(例如 26-32 岁)或类别(例如怀孕/未怀孕)。

目前,我已经设置了这样一个Study 记录可以有许多Subject 记录,Subject 记录可以有许多Interval_Subgroup 记录和许多Categorical_Subgroup 记录。

Subject
-----------------------------------------
id | groupType  | measure | value | study
-----------------------------------------
13 |  treatment |  count  |  578  |  17
14 |   control  |  count  |  552  |  17

Interval_Subgroup
---------------------------------------------------------------
id | factor | factorMin | factorMax | measure | value | subject
---------------------------------------------------------------
41 |  age   |     18    |     24    |  count  |  125  |   13   
42 |  age   |     25    |     32    |  count  |  204  |   13   

Categorical_Subgroup
-----------------------------------------------------
id | factor | factorValue | measure | value | subject
-----------------------------------------------------
74 |  sex   |     male    |  count  |  251  |   13   
75 |  sex   |    female   |  count  |  327  |   13   

这似乎可行,但感觉很笨拙,因为我有两个表用于捕获相同类型的信息。它也是有限制的,因为它不允许我捕获像 18-24 岁男性这样的子组的任何组合。有些研究报告了这种细节,有些则没有,但我希望能够捕捉到论文提供的任何深度的亚组信息。

有什么比我上面描述的更灵活的方式来构建这些表格?我试图勾勒出我认为这应该如何工作,现在,我的主题组有很多子组和子组有很多子组定义。将只有一个表捕获有关子组的测量值,另一个表用于定义每个子组是什么。我不确定这是否朝着正确的方向发展。也许您可能知道一个更简单的解决方案。

感谢您抽出宝贵时间提供帮助 - 非常感谢!


编辑: 固定 id 在示例表中是唯一的。

【问题讨论】:

  • 为什么你不能用这个设置获得 18-24 岁的男性——我相信你可以——只需添加更多记录.. 其他选项只是一种或另一种组合方式标准放入一个记录集中(考虑将所有这些列放入一个表中)。
  • 事实上,我认为这两个子组表仅适用于单分量因子。将标准字段组合到一个表中可能会整理一下,但它不允许我将多个定义标准分配给单个子组。如果我想存储 TB+、女性和 18-24 岁的人数,此设置似乎不允许这样做。
  • 因此:您基本上是在重新发明 EAV 模型(在这种情况下还不错)您确实需要一个额外的约束层,这样一个人 (或组)不能属于两个年龄组等。
  • 谢谢@wildplasser,我需要阅读 EAV 模型。
  • 请意识到:这种东西(多源/多语义)很难/不可能建模。只是不要过度。

标签: postgresql database-design relational-database database-schema


【解决方案1】:

根据您的描述,factor 听起来是一个事物,每个subgroup 都有一个或多个factors。对我来说,这意味着factor 需要自己的表格。因子又可以是intervalcategorical 类型,这意味着single table inheritance 可能是有序的。

示例表可能如下所示:

subgroups
------------------------------
id | measure | value | subject
------------------------------
41 |  count  |  125  |   13   
42 |  count  |  204  |   13   

factors
id | type        | factor | category | interval_min | interval_max | subgroup
-----------------------------------------------------------------------------
68 | interval    | age    | NULL     | 18           | 24           | 13
69 | categorical | sex    | male     | NULL         | NULL         | 13

在此示例中,子组 41 有两个因素,年龄 18-24 岁和性别男性。

这也可能是 STI 在这里过于矫枉过正,在这种情况下,您可以将 factor 拆分为两个表,categorical_factorsinterval_factors,并且每个子组可以有零个或多个。

据我所知,使用 STI 的复杂性主要取决于您使用的 ORM。 Rails / ActiveRecord 有很好的支持,其他框架各不相同。

希望有帮助!

【讨论】:

  • 谢谢丹 - 这当然很有帮助。我认为 STI 实际上可能会简化 ORM 方面的事情。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-05
  • 2016-07-25
  • 2017-12-20
  • 2019-10-30
相关资源
最近更新 更多