Линейный дизайн базы данных

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

Теперь, чтобы получить core_id spécifi c channel или полный список core channels, мне нужно чтобы объединить все пять таблиц.

Мой вопрос: было бы лучше объединить все таблицы, как в следующем примере, или это плохой дизайн базы данных.

• Cores (id , поля ...)
• Датчики (id, fields ..., core_id)
• Устройства (id, fields ..., core_id, probe_id)
• Датчики ( id, fields ..., core_id, probe_id, device_id)
• Каналы (id, fields ..., 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)

также - точки стиля. имена вашей таблицы должны быть единичными - определить одну строку содержимого. так Core, Probe, Device et c.