传感器网络计算特征-设计数据库
Sensor network calculating features - design database
您将如何为涉及传感器的系统建模
- 其中有一些空间数据，如纬度、经度、高度...
- 产生原始测量值，比方说距离、温度……
- 为了计算它们所在位置的“特征”，例如体积、温度
这是我对表格的想法
Sensor
- id
- model
- type
SensorMetadata
- sensorId
- timestamp // for time series to account for changing
- lat
- long
- alt
- metadata: json // some dynamic changeable data based on the domain lets say relative distance to something...
- unit
Measurements
- id
- timestamp
- sensorId
- value
Feature
- id
- type // complex features like volume
- value
- timestamp
- // relation to location (maybe sensorMetadata)
1 如果假设液体罐有问题，您会针对特定领域对其进行建模，还是会使用“特征”语言对其进行通用建模？
2 您将如何以及何时根据测量结果计算“特征”？很明显我在这里失踪了
我会考虑哪些传感器来计算位置的特征（假设他们在某些情况下使用多个传感器）
关于 Sensor，不要害怕使用像 SensorInstance 这样的东西 - 如果可以的话，歧义是应该避免的，特别是如果你可以这样做而不用很长的名字。在冗长的 运行 中，清晰（无歧义）的数据库设计通常优于简洁的数据库设计。
SensorMetadata - SensorState 是另一种选择。
Measurements - 尽量避免复数名称，单数（如 Sensor）通常更好。此页面有一些很好的指导：https://www.sqlshack.com/learn-sql-naming-conventions/
不过我能看到的大问题是 Measurements.value - 您如何解释该值？它是什么数据类型 - 即您的传感器产生的数据类型是什么？测量与传感器相关 - 传感器测量是否总是产生一个值（正如您的设计所暗示的那样）？
我不清楚 Feature table 的目的是什么。
对于这样的设计挑战，请查看现有的参考架构和设计 - 这家公司看起来可能有一些有用的白皮书：https://crate.io/use-cases/iot-sensor-data/ This might also be useful reading for you but won't provide a direct answer itself: https://hackernoon.com/ingesting-iot-and-sensor-data-at-scale-ee548e0f8b78
21 年 6 月 28 日更新
So Value column in Measurement would be interpreted based on SensorId it came from and since Sensor has its SensorMetadata which stores its Unit I would be able to interpret the Value if that's ok?
应该没问题。
对于功能 - 几种方法：
稍后计算 - 即仅收集原始数据，然后进行批量计算。例如，您可以对来自数据捕获系统的数据进行 ETL（由于 table 设计基本上是 OLTP data model) to a reporting system (OLAP 数据模型）。
现在计算它 - 即当它被输入数据库的应用程序或数据库中的 trigger/logic 捕获时。为此，您需要特征 table 和测量 and/or 传感器 table 之间的某种参考。这样你就可以测试计算 Feature.Value 的逻辑，因为如果你不能那样做 - 你能相信你的数据吗？如果您决定要更改计算公式，它还允许您计算新值。
我个人认为 #1 更灵活，一旦你有了原始数据，你就可以追溯添加你喜欢的任何新功能，但这可能不适合你需要的系统工作方式。
选项 2 很棘手。如果 Feature.Value 是根据不止一个 Measurement.Value （并且可能不止一个传感器）计算得出的，那么测量和传感器的数量也可能会因不同的特征而异 - 所以你需要一个多对-它们之间的许多关系（特征和测量）。
拥有多对多关系很好：连接 table 是常见的做法（一般来说），并且适合 OLTP 模型，这对事务（即数据收集）很有好处。不过，将其转换为对报告更友好的 OLAP 模型会更加复杂。
最后，关于您的问题 #2 - 我想我已经间接地部分回答了它。基本上取决于：需要多长时间才能获取要素数据？如果需要在 运行 时间向人员或系统提供即时信息，那么您需要尽快计算它。也许将其作为第二个问题提出来，并提供有关功能用例、解决方案上下文（谁在使用它，在什么情况下使用它）等信息。
您将如何为涉及传感器的系统建模
- 其中有一些空间数据，如纬度、经度、高度...
- 产生原始测量值，比方说距离、温度……
- 为了计算它们所在位置的“特征”，例如体积、温度
这是我对表格的想法
Sensor
- id
- model
- type
SensorMetadata
- sensorId
- timestamp // for time series to account for changing
- lat
- long
- alt
- metadata: json // some dynamic changeable data based on the domain lets say relative distance to something...
- unit
Measurements
- id
- timestamp
- sensorId
- value
Feature
- id
- type // complex features like volume
- value
- timestamp
- // relation to location (maybe sensorMetadata)
1 如果假设液体罐有问题，您会针对特定领域对其进行建模，还是会使用“特征”语言对其进行通用建模？
2 您将如何以及何时根据测量结果计算“特征”？很明显我在这里失踪了 我会考虑哪些传感器来计算位置的特征（假设他们在某些情况下使用多个传感器）
关于 Sensor，不要害怕使用像 SensorInstance 这样的东西 - 如果可以的话，歧义是应该避免的，特别是如果你可以这样做而不用很长的名字。在冗长的 运行 中，清晰（无歧义）的数据库设计通常优于简洁的数据库设计。
SensorMetadata - SensorState 是另一种选择。
Measurements - 尽量避免复数名称，单数（如 Sensor）通常更好。此页面有一些很好的指导：https://www.sqlshack.com/learn-sql-naming-conventions/
不过我能看到的大问题是 Measurements.value - 您如何解释该值？它是什么数据类型 - 即您的传感器产生的数据类型是什么？测量与传感器相关 - 传感器测量是否总是产生一个值（正如您的设计所暗示的那样）？
我不清楚 Feature table 的目的是什么。
对于这样的设计挑战，请查看现有的参考架构和设计 - 这家公司看起来可能有一些有用的白皮书：https://crate.io/use-cases/iot-sensor-data/ This might also be useful reading for you but won't provide a direct answer itself: https://hackernoon.com/ingesting-iot-and-sensor-data-at-scale-ee548e0f8b78
21 年 6 月 28 日更新
So Value column in Measurement would be interpreted based on SensorId it came from and since Sensor has its SensorMetadata which stores its Unit I would be able to interpret the Value if that's ok?
应该没问题。
对于功能 - 几种方法：
稍后计算 - 即仅收集原始数据，然后进行批量计算。例如，您可以对来自数据捕获系统的数据进行 ETL（由于 table 设计基本上是 OLTP data model) to a reporting system (OLAP 数据模型）。
现在计算它 - 即当它被输入数据库的应用程序或数据库中的 trigger/logic 捕获时。为此，您需要特征 table 和测量 and/or 传感器 table 之间的某种参考。这样你就可以测试计算 Feature.Value 的逻辑，因为如果你不能那样做 - 你能相信你的数据吗？如果您决定要更改计算公式，它还允许您计算新值。
我个人认为 #1 更灵活，一旦你有了原始数据，你就可以追溯添加你喜欢的任何新功能，但这可能不适合你需要的系统工作方式。
选项 2 很棘手。如果 Feature.Value 是根据不止一个 Measurement.Value （并且可能不止一个传感器）计算得出的，那么测量和传感器的数量也可能会因不同的特征而异 - 所以你需要一个多对-它们之间的许多关系（特征和测量）。
拥有多对多关系很好：连接 table 是常见的做法（一般来说），并且适合 OLTP 模型，这对事务（即数据收集）很有好处。不过，将其转换为对报告更友好的 OLAP 模型会更加复杂。
最后，关于您的问题 #2 - 我想我已经间接地部分回答了它。基本上取决于：需要多长时间才能获取要素数据？如果需要在 运行 时间向人员或系统提供即时信息，那么您需要尽快计算它。也许将其作为第二个问题提出来，并提供有关功能用例、解决方案上下文（谁在使用它，在什么情况下使用它）等信息。