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

Question

Я занимаюсь школьным обучением и ...

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

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

мнения?

Answer 1

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

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

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

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

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

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

  Это не вероятный сценарий, конечно.

Answer 2

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

Я предлагаю первый дизайн.

Answer 3

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

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

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

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

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

 
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