我正在尝试就数据库架构（逻辑模型）做出一些决定。
这是一个监控系统，分为： 网站 - ＆gt;单位 - ＆gt;传感器
站点是物理建筑物，单位是被监视的东西，通常是冰箱/冷冻器的一些描述。
每个单元可以有一个或多个传感器。 1传感器可能是温度，另一个可能是湿度等。
每个传感器都连接到从站。 Slave是一个安装在Unit内部的设备，可以连接传感器。 Slave是系统与传输传感器数据的对话。
奴隶目前仅限于2个传感器，因此如果需要，可以在一个单位上安装一个以上的奴隶。
在以下情况下系统会发出警报：
警报可以由用户ONCE确认并执行。
到目前为止，我已经为此设计了2个型号（见附件）。 我现在主要使用自然键（其中一些是相当冗长的复合键）;我发现它有助于初始逻辑模型。他们是否会保持这种方式我不知道 - 我宁愿不把它变成关于自然或代理键的辩论......！这更多是关于实际的关系。
此处系统上可以存在从站，无论是已安装还是未安装。
安装时，它与一个单位有关。
我在这里遇到的一个问题是该模型允许一个Unit的Sensor与另一个Unit中安装的Slave相关。为了解决这个问题，我可以制作SlaveInstalled的主键（SlaveId，SiteCode，UnitNo），但是这意味着主键的子集也是唯一的，这违反了许多人的书中的规则。
我可以解决此问题的另一种方法是将Sensor直接与Slave本身相关联，因此Sensor关系中指定的SlaveId必须也与同一个单元相关。
我在这里遇到的另一个问题是除了代理键AlarmId之外没有其他候选键。现在，我不介意代理键，但在我的所有经验和研究中，最好的数据库设计者似乎总是声明代理键应始终是附加键，否则这种关系没有意义。另一方面，也许AlarmId不是代理，而是报警的自然序列号。
在本模型中，我介绍了UnitDevice的概念，它可以是Slave或Sensor。
我还更改了一旦安装在设备中后如何识别从设备，因此设备本身是主键的一部分，这消除了将传感器与未安装在设备中的从设备相关联的可能性。
我有兴趣从DBA了解哪个模型看起来更正确？还有什么我忽略的吗？
虽然我很欣赏所有的回复，但我对那些说“在每张桌子上粘贴ID并以这种方式联系”的回复不太感兴趣 - 我喜欢数据完整性和结构完整性，我不认为任意在每张桌子上贴一个ID都是不错的做法。
谢谢！
编辑：SiteCode是CHAR（8），AreaCode是CHAR（3）。
