如何在 SQL Server 中存储类图数据？答案

【问题标题】：How to Store Graph-Like Data in SQL Server?如何在 SQL Server 中存储类图数据？
【发布时间】：2014-07-16 16:29:39
【问题描述】：

这是一个有点复杂的问题，甚至试图仔细考虑也有点令人困惑。

基本上，我必须设计一系列表格，其中包含有关许多不同电气设备的信息。这种设备的布置相当复杂，而且变化很大。

不同类型的设备如下：

RDC - Remote Distribution Center
EBD - Electrical Bus Duct
UPB - Upright Panel Board
PDU - Power Distribution Unit

现在这些单元一起工作的方式也有点令人困惑。

PDU - Powers RDC's, EBD's, and UPB's. They are often redundant, and have a secondary 
      unit that powers the same equipment in the event of a power failure.
      Can also contain breakers and power equipment directly.
RDC - Powers nearly all the equipment on the data center floors, are usually redundant.
      They have two units side by side, being powered by a PDU. In the event of a 
      failure, the second RDC is activated and resumes operations.
EBD - Nearly identical to the RDC, being phased out, but still needs to be tracked in a
      similar fashion.
UPB - Similar to an RDC, however, they are not redundant.

现在我想做的是找出最简单的方法来跟踪所有不同项目之间的这种疯狂关系？

我需要跟踪所有可能的硬件的冗余来源，以及每个单元的电源。这可能相当复杂，因为如果两个 PDU 为一组两个 RDC 供电，我们需要能够准确地跟踪到哪里去。

知道从哪里开始吗？

编辑这是我所追求的视觉表示。所接触的对象是多余的，因此必须记录在案。此外，必须对连接到每个设备的不同硬件进行分类。

【问题讨论】：

标签： sql sql-server database-design normalization database-normalization

【解决方案1】：

为设备设置一个表，为电源设置一个表，然后为设备与其电源匹配的第三个表。

【讨论】：

【解决方案2】：

这听起来像是实体关系模型的工作。你可以在这里了解更多信息：enter link description here

但是，为了回答您的问题，我将按照以下方式进行设置。我相信我了解实体之间的关系。我的速记遵循这种模式：表 [TableName] ([columns])。我试着给它们命名，这样它们的关系就很明显了。

Table RDC (id)
Table PDU (id)
Table UPB (id, PduId) // Many-to-one relationship between UPBs and Pdus
Table PDU (id)
Table PDU_RDC (PduId, RdcId) // represents many-to-many relationship between PDUs and RDCs
Table PDU_EBD (PduId, EbdId) // represents many-to-many relationship between PDUs and EBDs

祝你好运！

【讨论】：

这与我所追求的有点相似，但恐怕它可能会更复杂一些。这是关系的样子：imgur.com/EV4k7DL.jpg
...我明白了。您是否可以通过为 PDU 集群、RDC 集群等引入额外的表，然后创建集群之间的关系而不是实体本身来完成分组约束？
或者您可以通过向 PDU 表添加一列来表示耦合的 PDU、EBD 和 RDC，该列是对该表 ID 的外键引用，类似于“PduPartnerId”（和在 RDC 和 EBD 表上重复）
我正在考虑制作一个包含 3 列、ID、Hardware_ID 和 Hardware_Type 的超类表。然后使用它来建立所有关系。这样，如果需要，我可以将所有内容追溯到适当的表，但我也有办法强制执行所有不同的关系。不知道效果如何。

【解决方案3】：

与其关注“实体”，不如关注基本事实。每个都提供一个表格或视图。

一些基本事实只涉及实体；其他是关于实体的（id）：

RDC(id) // id identifies a remote distribution center
powers(pid,rid) // PDU pid powers RDC rid
backup(rid1,rid2) // RDC rid1 is backed up by RDC rid2
active(rid) // RDC is active

在您提供足够的您想要做出/使用的陈述之前，我们只能用猜测或原则来回答您；给出声明和业务规则，我们可以提出替代方案和重新安排。

当您在已有的两个语句之间获得 AND 时，带有该语句的表可以表示为两个语句表的 JOIN。

您可以引入诸如硬件类型之类的概念，但这种方式的表/语句将涉及更简单的语句（您可能已经定义了表）。前者的表/语句是后者的连接，后者是前者的投影。这意味着您可以根据另一种方式编写任何一种方式的视图。两者都不是更复杂。你有更少的东西有更多的部分或更简单的东西。涉及给定语句的查询会更简单——但使用适当的视图也不会更复杂。但是，每种方式都有相应版本的约束，SQL 可能会使某些约束难以以声明方式表达。稍后调查联接性能，作为非过早的优化。

当一列是一组列的函数时，从集合到列有一个 FD。当所有其他列都是它的函数但不是子集时，列集形成一个键。 FDs和keys是一种约束。

存在某些限制，即源表的投影始终是目标表的投影的子集（可能相同）。那是一个IND。非正式地它意味着某事（c1，...）暗示其他东西（c1，...）。形式上，EXISTS x1,... t1(c1,...,x1,...) 暗示 EXISTS y1,... t2(c1,...,y1,...)。如果目标投影的列在其表中形成一个键，那么还有一个 FK。 SQL FK [原文如此] 声明实际上声明了 IND。

会有其他限制。

为一张桌子提供任何东西只是它的一个属性。不是 0-or-more-to-0-or-more 意味着相应的 FD 或 IND 成立。人们谈论实体类型或表之间的“a”“1-to-n”“关系”，但这只是对某些约束的草率不清楚的表达。确保您准确了解表和约束的含义。

了解 ORM2（或 NIAM 或 FCO-IM），因为它基于关系原则（尽管可能更多）。

【讨论】：