线性数据库设计

Question

我有一个关于数据库关系的问题

我正在尝试建立一个具有以下规则的监控系统：

• Channels 属于一个 Sensor
• Sensors 属于一个 Device
• Devices 属于一个 Probe
• Probes 属于一个 Core

这是表格的预览

+-------------+    +-------------+
| Cores       |    | Probes      |
+-------------+    +-------------+
| id          |    | id          |
| fields ...  |    | fields ...  |
+-------------+    | core_id     |
                   +-------------+

+-------------+    +-------------+    +-------------+
| Devices     |    | Sensors     |    | Channels    |
+-------------+    +-------------+    +-------------+
| id          |    | id          |    | id          |
| fields ...  |    | fields ...  |    | fields ...  |
| probe_id    |    | device_id   |    | sensor_id   |
+-------------+    +-------------+    +-------------+

现在要获取特定channel 的core_id 或core 的channels 的完整列表，我需要加入所有五个表。

我的问题是，最好像下面的示例那样将所有表链接在一起，否则这是一个糟糕的数据库设计。

• 核心（ID、字段...）
• 探针（id、字段...、core_id）
• 设备（id、字段...、core_id、probe_id）
• 传感器（id、字段...、core_id、probe_id、device_id）
• 频道（id、字段...、core_id、probe_id、device_id、sensor_id）

Answer 1

需要考虑的一点是：“X 是否可以存在于 Y 的上下文之外？”。设计会根据答案而改变。根据您的问题和设计，以下是答案：

|            Question                 |Answer|
+-------------------------------------+------+
|Can a core exist independently?      | Yes  |
|Can a probe exist without a core?    | No   |
|Can a device exist without a probe?  | No   |
|Can a sensor exist without a device? | No   |
|Can a channel exist without a sensor?| No   |

根据这些答案，可行的逻辑设计可能是：

-- Core COR exists.
--
core {COR}
  PK {COR}

-- Probe number PRO_NO of core COR exists.
--
probe {COR, PRO_NO}
   PK {COR, PRO_NO}

FK {COR} REFERENCES core {COR}

-- Device number DEV_NO of probe number PRO_NO
-- of core COR exists.
--
device {COR, PRO_NO, DEV_NO}
    PK {COR, PRO_NO, DEV_NO}

   FK {COR, PRO_NO} REFERENCES
probe {COR, PRO_NO}

-- Sensor number SNS_NO of device number DEV_NO,
-- of probe number PRO_NO, of core COR exists.
--
sensor {COR, PRO_NO, DEV_NO, SNS_NO}
    PK {COR, PRO_NO, DEV_NO, SNS_NO}

    FK {COR, PRO_NO, DEV_NO} REFERENCES
device {COR, PRO_NO, DEV_NO}

-- Channel CHN_NO of sensor number SNS_NO,
-- of device number DEV_NO, of probe number PRO_NO,
-- of core COR exists.
--
channel {COR, PRO_NO, DEV_NO, SNS_NO, CHN_NO}
     PK {COR, PRO_NO, DEV_NO, SNS_NO, CHN_NO}

    FK {COR, PRO_NO, DEV_NO, SNS_NO} REFERENCES
sensor {COR, PRO_NO, DEV_NO, SNS_NO}

• 这是一个糟糕的设计吗？ 没有。
• 逻辑上合理吗？ 是的。
• 标准化呢？ 5NF（带有 ... 属性）.
• 物理实现可以吗？ 是的，也许，不，取决于。

---

说您正在考虑物理设计并且关心键的宽度和索引大小。此时，您决定遵循自然层次结构并为每个实体设置一个列标识符，即使它不能脱离另一个实体的上下文。

-- Core COR exists.
--
core {COR}
  PK {COR}

-- Probe PRO of core COR exists.
--
probe {PRO, COR}
   PK {PRO}

   FK {COR} REFERENCES core {COR}

-- Device DEV of probe PRO exists.
--
device {DEV, PRO}
    PK {DEV}

    FK {PRO} REFERENCES probe {PRO}

-- Sensor SNS of device DEV exists.
--
sensor {SNS, DEV}
    PK {SNS}

    FK {DEV} REFERENCES device {DEV}

-- Channel CHN of sensor SNS, exists.
--
channel {CHN, SNS}
     PK {CHN}

     FK {SNS} REFERENCES sensor {SNS}

这个符合你最初的设计。

• 这是一个糟糕的设计吗？ 没有。
• 逻辑上合理吗？ 是的。
• 标准化呢？ 5NF（带有 ... 属性）.
• 这样更好吗？ 是的，也许，不，取决于。

确保您不允许NULLs。允许NULLs 用于FKs 基本上会对所有“X 是否存在而不存在Y？”问题回答“是”，并导致完全不同的设计（架构）。

---

注意：

All attributes (columns) NOT NULL

PK = Primary Key
AK = Alternate Key (Unique)
FK = Foreign Key

Answer 2

重复额外的外键是非规范化的，会给你带来麻烦。

应该是这样的：

Cores(id, fields...)
Probes(id, fields..., core_id)
Devices(id, fields..., probe_id)
Sensors(id, fields..., device_id)
Channels(id, fields..., sensor_id)

也 - 风格点。您的表名应该是单数 - 定义一行内容。所以核心、探针、设备等。