database - 线性数据库设计

Question

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

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

• channel 属于一个传感器
• 传感器属于一个设备
• 设备属于一个探针
• 探针属于一个核心

这是表格的预览

+-------------+    +-------------+
| 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或核心的 channel 的完整列表，我需要加入所有五个表。

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

• 核心(id、字段...)
• 探针(id、字段...、core_id)
• 设备(id、字段...、core_id、probe_id)
• 传感器(id、字段...、core_id、probe_id、device_id)
• channel (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(具有...属性)。
• 这样更好吗？ 是的，也许，不，取决于。

确保不允许NULL。允许 FK 为 NULL 基本上会对所有“X 可以在没有 Y 的情况下存在吗？”回答"is"。 ”问题，并导致完全不同的设计(模式)。

---

注意:

All attributes (columns) NOT NULL

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