多个 1 到 0..1 关系的正确设计
Proper Design for multiple 1 to 0..1 Relationships
我目前正在从事一个有趣的项目。我已经开发了几个直接的数据库，但是这个当前的设置让我有点困惑，因为它有多个 0:1 关系，我不完全确定我是否正确地设计了表和关系。我读过几个 SO 问题 How to Create Multiple one to one's。然而，这些问题中的大多数都只是一种深层次的关系，尽管我认为基础仍然是相同的。
我的规格如下：
I. Restraint has Type
II. Type: Physical, Chemical, Mechanical
a. Physical has type
i. various Holds
b. Chemical has type
i. various Medicines
c. Mechanical has Type
i. Point has Type
1. various numbers
ii. Various devices
限制：
1. Only one type per restraint
2. Only one type per Physical Restraint
3. Only one type per Chemical Restraint
4. Only one type per mechanical Restraint
i. If mechanical restraint type is Point only one Point Type per mechanical retraint
这是我目前的设计
如图所示，我有一个从 Restraint 到 RestraintType 的 1:Many，然后是我的每个 RestraintType 表中的一个 0:1。有了这个设计，我想，我可以更新任何描述或添加新类型，而无需编辑数据库。除非添加具有子类别的新约束类型。
有没有更好的方法来设计这个设置？这个项目还有很多这样的关系，但是，如果我能很好地掌握这一点，剩下的应该很容易。
编辑
这是压缩 TypeRestraint 查找的第二个设计模式。它让我的正常化神经发麻，但它可能更有效？
编辑
这里是需要什么的更具体的视图。
约束发生。约束可以是物理约束、化学约束或机械约束。这些是政府报告规定的限制类型。
物理约束是以下之一：1 人控制、2 人控制、团队控制
化学限制是以下之一：特定剂量的单一药物或特定剂量的一对药物。
机械约束装置是以下之一：手套、腰带、椅子、x Point Bed Restraint（其中 x 可以是 1 - 5 之间的数字）、防吐器和其他定期添加和删除的东西。
身体约束很少改变，因为它相当简单。
随着新药的使用和旧药的淘汰，化学限制会发生变化。
机械约束经常变化。
一个约束只能是一个Type/Sub-Type
如果说有 1 人控制、2 人控制，Team-Hold 然后是化学约束来让他们平静下来。那将是 4 个独立的约束，但这会影响项目的其他要求。
好的，我看到以下内容：只有 2 tables，但是有一个自连接和层次结构）
**Restraint**
RestraintID (PK)
RestraintTypeID (FK)
Description
Dose - only populated if RestraintTypeId is chemical
unsure if multiple chemicals are used if we need one for each or
if there is only a single "Dose" because the mixture is static.
**RestraintType** (Basically a hierarchical look-up)
(use recursive Common table expressions to query sub-levels if needed)
RestraintTypeID (PK)
ParentID (FK) to RestraintType.RestraintTypeId
Description
Active (Date)
Inactive (date)
RestraintType 中的数据看起来像...
1 NULL Physical
2 NULL Chemical
3 NULL Mechanical
4 1 1-Person Hold
5 1 2-Person Hold
6 1 Team Hold
7 2 Medicine Name
8 2 Medicine Name 2
9 2 Medicine Name 3
10 2 Medicine A & B
11 2 Medicine C & D
12 2 Medicine A & D
13 3 Gloves
14 3 Belt
15 3 Chair
16 3 1-Point Bed Restraint
17 3 2-Point Bed Restraint
18 3 3-Point Bed Restraint
19 3 4-Point Bed Restraint
20 3 5-Point Bed Restraint
这确保每个约束只允许使用一种类型。
并且对于每个类型 selected，只允许物理、化学和机械的一个子类型。
它通过定义所有可用的点类型来大致满足#4。这可以管理
与使用另一个父子关系的数据不同，但我认为没有必要。
日期定义了每个选项何时变为 active/inactive，以便可以维护历史值。
我相信这很简单，并且在维护的同时满足了所有要求
第 4 范式。
设计变得更加简单，因为您可以在树视图中显示选项并允许更改新的叶子和元素，只需在幕后填充新的 start/end 日期。开始 w/o 结束日期的活动有效，select 不再提供有结束日期的活动。系统维护使用限制的历史，没有来自 RestraintType 的数据被清除。除非首先清除所有相关的约束。 （我不知道你必须遵守什么保留规则，但我怀疑有一些）
如果您没有做过很多分层查询，那么分层查询可能会有点棘手。
我们只需要存储 LEAF 结果，因为每个约束只能有一种类型，并且每种类型只能有一种 sub/type。由于我们知道每个 type/sub 类型关系，我们只需要记录最低级别，并且可以在需要时随时查找层次结构。
从UI的角度考虑
约束信息
基本信息....
Restraint Used
(User selects from LOV of top level)
(System queries for next level list) and lets user select from a second LOV
(system queries for next level list) if exists, lets user select from a 3rd level (etc)
We store the last level Id of the Restraint used.
IF the restraint is a chemical as the top most node, then
the user must also define a "Dose" field that becomes active.
我认为你哪里出错了：
您创建的子 table 都是不同类型的约束。对于约束类型，它们都适合一个 table！您只需要一个层次结构来定义它们如何相互关联。唯一的例外是 "DOSE" 但由于剂量与约束事件有关，因此它属于单独的约束细节 table 或可以放在主要 table 本身上。单独的 table 会更符合缩放解决方案；但两者都适用于当前定义的要求。
我目前正在从事一个有趣的项目。我已经开发了几个直接的数据库，但是这个当前的设置让我有点困惑，因为它有多个 0:1 关系，我不完全确定我是否正确地设计了表和关系。我读过几个 SO 问题 How to Create Multiple one to one's。然而，这些问题中的大多数都只是一种深层次的关系，尽管我认为基础仍然是相同的。
我的规格如下：
I. Restraint has Type
II. Type: Physical, Chemical, Mechanical
a. Physical has type
i. various Holds
b. Chemical has type
i. various Medicines
c. Mechanical has Type
i. Point has Type
1. various numbers
ii. Various devices
限制：
1. Only one type per restraint
2. Only one type per Physical Restraint
3. Only one type per Chemical Restraint
4. Only one type per mechanical Restraint
i. If mechanical restraint type is Point only one Point Type per mechanical retraint
这是我目前的设计
如图所示，我有一个从 Restraint 到 RestraintType 的 1:Many，然后是我的每个 RestraintType 表中的一个 0:1。有了这个设计，我想，我可以更新任何描述或添加新类型，而无需编辑数据库。除非添加具有子类别的新约束类型。
有没有更好的方法来设计这个设置？这个项目还有很多这样的关系，但是，如果我能很好地掌握这一点，剩下的应该很容易。
编辑
这是压缩 TypeRestraint 查找的第二个设计模式。它让我的正常化神经发麻，但它可能更有效？
编辑
这里是需要什么的更具体的视图。
约束发生。约束可以是物理约束、化学约束或机械约束。这些是政府报告规定的限制类型。
物理约束是以下之一：1 人控制、2 人控制、团队控制
化学限制是以下之一：特定剂量的单一药物或特定剂量的一对药物。
机械约束装置是以下之一：手套、腰带、椅子、x Point Bed Restraint（其中 x 可以是 1 - 5 之间的数字）、防吐器和其他定期添加和删除的东西。
身体约束很少改变，因为它相当简单。 随着新药的使用和旧药的淘汰，化学限制会发生变化。 机械约束经常变化。
一个约束只能是一个Type/Sub-Type
如果说有 1 人控制、2 人控制，Team-Hold 然后是化学约束来让他们平静下来。那将是 4 个独立的约束，但这会影响项目的其他要求。
好的，我看到以下内容：只有 2 tables，但是有一个自连接和层次结构）
**Restraint**
RestraintID (PK)
RestraintTypeID (FK)
Description
Dose - only populated if RestraintTypeId is chemical
unsure if multiple chemicals are used if we need one for each or
if there is only a single "Dose" because the mixture is static.
**RestraintType** (Basically a hierarchical look-up)
(use recursive Common table expressions to query sub-levels if needed)
RestraintTypeID (PK)
ParentID (FK) to RestraintType.RestraintTypeId
Description
Active (Date)
Inactive (date)
RestraintType 中的数据看起来像...
1 NULL Physical
2 NULL Chemical
3 NULL Mechanical
4 1 1-Person Hold
5 1 2-Person Hold
6 1 Team Hold
7 2 Medicine Name
8 2 Medicine Name 2
9 2 Medicine Name 3
10 2 Medicine A & B
11 2 Medicine C & D
12 2 Medicine A & D
13 3 Gloves
14 3 Belt
15 3 Chair
16 3 1-Point Bed Restraint
17 3 2-Point Bed Restraint
18 3 3-Point Bed Restraint
19 3 4-Point Bed Restraint
20 3 5-Point Bed Restraint
这确保每个约束只允许使用一种类型。 并且对于每个类型 selected，只允许物理、化学和机械的一个子类型。 它通过定义所有可用的点类型来大致满足#4。这可以管理 与使用另一个父子关系的数据不同，但我认为没有必要。 日期定义了每个选项何时变为 active/inactive，以便可以维护历史值。
我相信这很简单，并且在维护的同时满足了所有要求 第 4 范式。
设计变得更加简单，因为您可以在树视图中显示选项并允许更改新的叶子和元素，只需在幕后填充新的 start/end 日期。开始 w/o 结束日期的活动有效，select 不再提供有结束日期的活动。系统维护使用限制的历史，没有来自 RestraintType 的数据被清除。除非首先清除所有相关的约束。 （我不知道你必须遵守什么保留规则，但我怀疑有一些）
如果您没有做过很多分层查询，那么分层查询可能会有点棘手。
我们只需要存储 LEAF 结果，因为每个约束只能有一种类型，并且每种类型只能有一种 sub/type。由于我们知道每个 type/sub 类型关系，我们只需要记录最低级别，并且可以在需要时随时查找层次结构。
从UI的角度考虑
约束信息 基本信息....
Restraint Used
(User selects from LOV of top level)
(System queries for next level list) and lets user select from a second LOV
(system queries for next level list) if exists, lets user select from a 3rd level (etc)
We store the last level Id of the Restraint used.
IF the restraint is a chemical as the top most node, then
the user must also define a "Dose" field that becomes active.
我认为你哪里出错了：
您创建的子 table 都是不同类型的约束。对于约束类型，它们都适合一个 table！您只需要一个层次结构来定义它们如何相互关联。唯一的例外是 "DOSE" 但由于剂量与约束事件有关，因此它属于单独的约束细节 table 或可以放在主要 table 本身上。单独的 table 会更符合缩放解决方案；但两者都适用于当前定义的要求。