Лучший дизайн базы данных для "сенсорной системы"

Question

Я делаю школьную работу и..

Я должен сделать систему отслеживания транспортных средств. Я думал об этих трех проектах. Как вы думаете?

Мои схемы базы данных

Мнения?

Answer 1

• Если вы всегда измеряете и сохраняете все параметры в течение одного сеанса измерения, тогда переходите к проектированию 1,

  Перемещение атрибутов в отдельные таблицы имеет смысл, только если атрибуты редко сохраняются и / или редко нужны.

• Если у вас есть отдельные датчики для положения и температуры, а затем перейти к дизайну 3,

  Это наиболее вероятно, так как положение измеряется GPS Трекер и температура и уровень масла измеряются датчиками транспортного средства, которые являются отдельными устройствами, и измерения выполняются в разное время.

  Возможно, вам даже потребуется добавить отдельную таблицу для каждого датчика (т. Е. Если разные датчики измеряют газ и температуру в разное время, составьте для них две таблицы).

• перемещение liquid в отдельную таблицу (как в дизайне 2) имеет смысл, если список используемых вами жидкостей неизвестен во время разработки (т.е. какая-то третья жидкость, например, водород или гелий-3, или что бы они ни изобретали, будет использоваться транспортными средствами, и вам нужно будет отслеживать ее, не изменяя дизайн база данных).

  Конечно, это маловероятный сценарий.

Answer 2

Если вы одновременно читаете данные с датчиков, для меня второй дизайн выглядит излишним. Было бы целесообразно хранить информацию отдельно, только если вы читаете эту информацию в разное время.

Я бы предложил первый дизайн.

Answer 3

Ваше приложение должно иметь дело с двумя типами вещей

• Датчики = какой тип, где находится двигатель, и даже такие параметры, как частота опроса и тому подобное..
• Чтения = отдельные записи с метками времени с одного (или нескольких?) Датчиков.

Есть несколько вещей, о которых стоит подумать:
- Как мы можем найти способы абстрагирования концепции сенсора? Идея состоит в том, что мы могли бы затем идентифицировать и обрабатывать экземпляры датчиков через их свойства, а не знать, где они находятся в базе данных.
-Лучше всего сохранять все измерения для данной временной отметки в одной записи "Чтение" или иметь по одной записи на датчик для каждого считывания, даже если несколько измерений поставляются в наборах.

Быстрый ответ на последний вопрос заключается в том, что одно событие чтения для каждой записи кажется более гибким; мы сможем одинаково обрабатывать как группы измерений, которые систематически опрашиваются одновременно, так и другие измерения, которые асинхронны по отношению к первым. Даже если сейчас все измерения выполняются одновременно, привлекательна возможность легкого добавления датчиков без изменения схемы базы данных и их обработки.

Может быть, следующий дизайн будет ближе к тому, что вам нужно:

tblSensors
     SensorId PK
     Назовите открытым текстом описание датчика ("Масло темп.")
     LongName более длинное описание ("Температура масла, датчик TH-B14 в коленвале")
     Перечисление SensorType ("ТЕМП", "ДАВЛЕНИЕ", "СКОРОСТЬ"...)
     Перечисление SensorSubType ("НЕФТЬ", "ВОЗДУХ"...)
     Перечисление местоположения ("ДВИГАТЕЛЬ", "ОБЩИЕ", "ВЫПУСК"...)
     OtherCrit другие криетрии, которые могут быть использованы для идентификации / поиска датчика.


tblReads
     Readid PK
     DateTime   
     SensorId FK to tblSensors
     Значение измерения INTeger
     Measurement2 необязательное дополнительное измерение (возможно, чтобы справиться, скажем, все
                     датчика GPS читается как одно "значение"
     Measurement3 ... также может иметь несколько столбцов для разных типов 
              переменные (реальные?)

В дополнение к вышесказанному у вас есть несколько таблиц, в которых определены "перечисления" для различных типов датчиков, а привязка к логике приложения будет осуществляться с помощью мнемонических "ключей" этих перечислений., например.

SELECT S.Name, R.DateTime, R.Measurement
FROM tblReads R
JOIN tblSensors S ON S.SensorId = R.SensorID
WHERE S.SensorType IN ('Temp', 'Pres')
  AND S.Location = "ENG"
  AND R.DateTime > '04/07/2009'
ORDER BY R.DateTime

Это не помешает вам также вызывать датчики по их идентификатору и группировать показания в одной строке результатов. например.

SELECT R1.DateTime, R1.Measurement AS OilTemp, R2.Measurement AS OilPress,
       R3.Measurement AS MotorRpms
FROM  tblReads R1
LEFT OUTER JOIN tblReads R2  ON R1.DateTime = R2.DateTime
LEFT OUTER JOIN tblReads R3  ON R1.DateTime = R3.DateTime
WHERE R1.SensorId = 17 
  AND R2.SensorId = 11 
  AND R3.SensorId = 44 
  AND R1.DateTime > '04/07/2009' AND R1.DateTime < '04/08/2009'
ORDER BY R3.Measurement DESC -- Sorte by Speed, fastest first