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

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

6 голосов
/ 09 октября 2009

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

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

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

(png at ImageShack ~99KB)

Мнения

Ответы [ 3 ]

3 голосов
/ 09 октября 2009

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

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

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

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

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

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

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

1 голос
/ 09 октября 2009

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

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

0 голосов
/ 09 октября 2009

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

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

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

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

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

tblSensors
     SensorId   PK
     Name       clear text description of the sensor  ("Oil Temp.")
     LongName   longer description   ("Oil Temperarure, Sensor TH-B14 in crankshaft")
     SensorType enumeration  ("TEMP", "PRESSURE", "VELOCITY"...)
     SensorSubType   enumeration   ("OIL", "AIR"...)
     Location   enumeration  ("ENGINE", "GENERAL", "EXHAUST"...)
     OtherCrit  other crietrias which may be used to identify/seach for the sensor.


tblReads
     Readid   PK
     DateTime   
     SensorId   FK to tblSensors
     Measurment  INTeger value
     Measurement2    optional extra meassurement (maybe to handle say, all
                     of a GPS sensor read as one "value"
     Measurement3 ... also may have multiple columns for different types of 
              variables (real-valued ?)

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

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
...