线性数据库设计

本文介绍了线性数据库设计的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我对数据库关系有疑问

我正在尝试使用以下规则构建监视系统：

通道属于一个 Sensor

传感器属于一个 Device

设备属于一个 Probe

Probes 属于一个 Core

这是表格的预览

  + ------------- + + ------------- + 
 |核心| |探针
 + ------------- + + ------------- + 
 | id | | id | 
 |领域... | |领域... | 
 + ------------- + | core_id | 
 + ------------- + 
 
 + ------------- + + ------- ------ + + ------------- + 
 |设备| |传感器| |频道| 
 + ------------- + + ------------- + + ------------- + 
 | id | | id | | id | 
 |领域... | |领域... | |领域... | 
 | probe_id | | device_id | | sensor_id | 
 + ------------- + + ------------- + + ------------- +

现在可以获取特定的 core_id 频道或核心的频道的完整列表，我需要将所有五个表都连接起来。

我的问题是，像下面的示例那样将所有表链接在一起会更好，还是数据库设计不好？ / p>

核心（id，字段...）

Probes（id，字段...， core_id）

设备（id，字段...，core_id，probe_id）

传感器（id，字段...，core_id，probe_id， device_id）

通道（id，字段...，core_id，probe_id，device_id，sensor_id）

解决方案

要考虑的一件事是： 可以在的上下文之外存在 X Y ？。设计根据答案进行更改。根据您的问题和设计，这些是答案：

  |问题|答案| 
 + ------------------------------------- + ------ + 
 |核心可以独立存在吗？ |是的
 |是否存在没有核心的探针？ |没有
 |是否可以存在没有探测器的设备？ |没有
 |没有设备就可以存在传感器吗？ |没有
 |是否存在没有传感器的通道？没有

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

 -核心COR存在。 
-
核心{COR} 
 PK {COR}

 -核心COR的探针号PRO_NO存在。 
-
探针{COR，PRO_NO} 
 PK {COR，PRO_NO} 
 
 FK {COR}参考核心{COR}

 -探测号为PRO_NO $ b $的设备号DEV_NO b-核心COR存在。 
-
设备{COR，PRO_NO，DEV_NO} 
 PK {COR，PRO_NO，DEV_NO} 
 
 FK {COR，PRO_NO}参考
探针{COR，PRO_NO}

  -存在核心COR的设备编号DEV_NO的传感器编号SNS_NO，
-探针编号PRO_NO。 
-
传感器{COR，PRO_NO，DEV_NO，SNS_NO} 
 PK {COR，PRO_NO，DEV_NO，SNS_NO} 
 
 FK {COR，PRO_NO，DEV_NO}参考
设备{COR，PRO_NO，DEV_NO}

 -存在核心COR的传感器编号为SNS_NO的通道CHN_NO，设备编号为DEV_NO的
，探测编号为PRO_NO的探测器编号，
。 
-
通道{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}参考
传感器{COR，PRO_NO，DEV_NO，SNS_NO}

这是一个不好的设计吗？否。

逻辑上合理吗？是。

规范化如何？ 5NF（具有...属性）。

物理实现可以吗？是，也许不是，要看情况。

说，您正在考虑物理设计，并且担心键的宽度和索引大小。此时，您决定遵循自然层次结构，并且即使每个实体都不能存在于另一个实体的上下文中，也要为每个实体使用单个列标识符。

 -核心COR存在。 
-
核心{COR} 
 PK {COR}

 -核心COR的探针PRO存在。 
-
探针{PRO，COR} 
 PK {PRO} 
 
 FK {COR}参考核心{COR}

 -探针PRO的设备DEV存在。 
-
设备{DEV，PRO} 
 PK {DEV} 
 
 FK {PRO}参考调查{PRO}

 -设备DEV的传感器SNS存在。 
-
传感器{SNS，DEV} 
 PK {SNS} 
 
 FK {DEV}参考设备{DEV}

 -传感器SNS的通道CHN存在。 
-
渠道{CHN，SNS} 
 PK {CHN} 
 
 FK {SNS}参考传感器{SNS}

这与您的初始设计相符。

是这个设计不好吗？否。

逻辑上合理吗？是。

规范化如何？ 5NF（具有...属性）。

这样更好吗？ 是，也许不是，要看情况。

请确保您不允许 NULL 。对于 FK 允许 NULLs 基本上对所有 可以 X回答是。 存在而没有 Y ？问题，并导致完全不同的设计（架构）。

注意：

 所有属性（列）非空
 
 PK =主键
 AK =备用键（唯一）
 FK =外键

I have a question about database relationship

I am trying to build a monitoring system with the following rules :

Channels belongs to one Sensor
Sensors belongs to one Device
Devices belongs to one Probe
Probes belongs to one Core

Here is a preview of the tables

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

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

Now to get the core_id of a spécific channel or the full list of a core's channels, I need to join all the five tables.

My question is, would it be better to have all tables linked together like the following example or it's a bad database design.

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

解决方案

One thing to consider is: "can X exist out of the context of Y?". Design changes depending on the answer. Based on your question, and design, these are the answers:

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

As per these answers, a viable logical design may be:

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

Is this a bad design? No.
Is it logically sound? Yes.
What about normalization? 5NF (with ... attributes).
Is it OK for a physical implementation? Yes, maybe, no, depends.

Say that you are considering physical design and are concerned about width of keys and index sizes. At this point you decide to follow the natural hierarchy and have a single column identifier for each entity, even if it can not exist out of the context of another one.

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

This one matches your initial design.

Is this a bad design? No.
Is it logically sound? Yes.
What about normalization? 5NF (with ... attributes).
Is this better? Yes, maybe, no, depends.

Make sure you do not allow NULLs. Allowing NULLs for FKs would basically answer "yes" to all "can X exist withoutY?" questions, and lead to completely different design (schema).

Note:

All attributes (columns) NOT NULL

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

这篇关于线性数据库设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！