适当设计多个1到0..1关系

时间:2015-01-06 16:45:49

标签: sql sql-server database-design relational-database normalization

我目前正在开展一个有趣的项目。我已经开发了几个直接的数据库,但是这个当前的设置让我有点困惑,因为它有多个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

这是我目前的设计

Database Design

如图所示我有一个1:很多从Restraint到RestraintType然后从我的每个RestraintType表中得到0:1。有了这个设计,我想,我可以更新任何描述或添加新类型而无需编辑数据库。除非添加了具有子类别的新类型约束。

有没有更好的方法来设计此设置?在这个项目中有很多这样的关系,但是,如果我能够很好地掌握这个,其余的应该很容易。

修改

这是压缩TypeRestraint查找的第二个设计模式。它让我的正常化神经紧张,但它可能更有效率?

2nd Design Schema

修改

以下是对所需内容的更具体的看法。

发生克制。约束可以是物理约束,化学约束或机械约束。这些是政府报告规定的限制类型。

物理约束是以下之一:单人保持,双人保持,团队保持

化学抑制是以下之一:特定剂量的单一药物或特定剂量的一对药物。

机械约束是以下之一:手套,腰带,椅子,x点床约束(其中x可以是1-5的数字),吐痰护卫和其他定期添加和移除的东西。

物理克制很少发生变化,因为它非常直接。 随着新药的使用和旧的药物被逐步淘汰,化学制约发生了变化。 机械约束经常变化。

约束只能是一个类型/子类型

如果说有1人保持,2人保持,团队保持然后化学约束让他们平静下来。这将是4个单独的限制,但这将进入项目的其他要求。

1 个答案:

答案 0 :(得分:1)

好的,我看到以下内容:只有2个表,其中一个表具有自联接和层次结构)

**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

这确保每个约束仅允许使用一种类型。 并且对于所选择的每种类型,仅允许一种子类型用于物理,化学和机械。 它通过定义所有可用的点类型松散地满足#4。这可以管理 与使用另一个父子关系的数据不同,但我没有看到需要。 日期定义每个选项何时变为活动/非活动状态,以便保持历史值。

我相信这很简单,并且在维护时满足所有要求 第四种正常形式。

设计变得更加简单,因为您可以在树视图中显示选项,并允许更改新的叶子和元素,只需在幕后填充新的开始/结束日期。没有结束日期的活动开始,具有结束日期的那些日期不再可供选择。系统维护使用的限制历史,没有来自RestraintType的数据被清除。除非首先清除所有相关的约束。 (我不知道你必须遵守什么保留规则,但我怀疑有一些保留规则)

如果您没有完成很多分层查询,那么分层查询会变得有点棘手。

我们只需要存储LEAF结果,因为每个约束只能有一种类型,每种类型只能有一个子/类型。由于我们知道每种类型/子类型关系,我们只需要记录最低级别,并且如果需要,可以始终查找层次结构。

从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.

我认为你错了:

您创建的子表是所有不同类型的约束。它们都适合用于约束类型的单个表格!您只需要一个层次结构来定义它们彼此之间的关系。唯一的例外是“DOSE”,但由于剂量与限制事件相关,因此它既可以在单独的约束细节表上,也可以放在主表本身上。一个单独的表格将更加符合扩展解决方案;但要么适用于当前定义的要求。