Location [Table] - Id - Name - HasLogger - LoggerRFID - LoggerUpperLimit - LoggerLowerLimit Sensor [Table] - Id [PK] - LocationId [FK] - UpperLimit - LowerLimit SensorReading [Table] - Id [PK] - SensorId [FK] - Value LoggerReading [Table] - LocationId [FK] - Value Alert [Table] - Id [PK] AlertCorrectiveAction [Table] - AlertId [FK] - CorrectiveActionId [FK] - ByUserId [FK] AlertAcknowledgement [Table] - AlertId [FK] - ByUserId [FK] SensorAlertReading [Table] - AlertId [FK] - SensorReadingId [FK] LoggerAlertReading [Table] - AlertId [FK] - LoggerReadingId [FK]
现在这个选项的问题在于它允许来自多个传感器和多个位置的读数“链接”到单个警报.
为了扩展这个问题的原因,我将解释系统的工作原理：
一个位置可以包含许多“实时传感器”,但只有一个记录器.出于这个原因,我将记录器属性放入位置表(它是有效的1对1关系).记录器收集读数,直到稍后收集,实时传感器通过网络立即传达读数,并且它们具有额外的属性,如具有网络地址属性的网络从属设备……与记录器完全不同(我曾尝试将记录器作为传感器一次处理,没有运作良好).
当传感器或记录仪超出范围(由读数指示)时,系统会生成警报.警报仅针对该传感器,并且在该传感器(或记录器)的读数指示其返回范围之前被视为活动.在此之前,将传感器进一步超出范围的读数与相同的警报“链接”.
正如您所看到的,单个警报应该只有与其链接的相同传感器的读数,但是我的设计允许不同传感器和记录器的不同读数与相同的警报相关联 – 我是否应该为此烦恼？以某种方式约束？另一个问题是它允许在没有任何读数的情况下存在警报.
因此我的问题;应该在多大程度上采用约束或弯曲设计以适应这些约束？我喜欢上面的设计,因为它很简单 – 警报可以有传感器读数和记录器读数,因此链接它们是一个简单的关系.
我不禁想到我也错过了一个技巧 – 有没有更好的方法来做这个设计？我已经和它一起玩了很多年了,而且似乎总是有一个妥协(除非我重复所有不同阅读类型的警报表).
谢谢.
解决方法
should I be bothered that I haven’t constrained that somehow?
是.
你犯了两个基本错误.
>在所有移动的东西上粘贴白痴键.
这阻碍了您对数据进行建模的能力,如数据(不是没有意义的行,但具有人为强制的唯一性),并暴露了Identifers;和依赖关系(例如,传感器与位置相关).您正在使用包含数据的预设Row_Ids对电子表格进行建模.您需要将数据标准化为数据.
这导致了您已发现的问题,但也存在其他问题.
如果您对数据建模,则标识符将清除,并且Index和FK约束将阻止此操作.什么数据是独立的;什么数据属于(依赖于)其他数据;什么数据对其他数据做了什么,以及这些行动的基础.
然后(已经解决的主要问题),您只需要很小的限制来解决次要问题.
>否则你会被困在整个地方添加约束来尝试获得你想要的东西,但从来没有完全达到目的.你知道你需要它们,所以你正在寻找它们.
错误的地方.我们需要备份到(1).
我已经回答了你的另一个问题,包括一个▶Sensor Data Model◀.这并没有解决你在这里发现的不足之处.但是,我刚刚看到这个问题,我明天将更新DM并包含这些表和列.
07001 for anyone who is unfamiliar with the Standard for modelling Relational databases.
问题
>看起来您需要传感器的参考表,即货架项,以保持UpperLimit和LowerLimit;而不是为每个位置重复它.或者是为每个位置设置,本地化.>想想Logger是SensorNo零.>为什么传感器没有RFID？>在每个位置,Logger是可选的,是1 :: 0-1 ?,
