Хранение данных датчика для различных типов датчиков

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

Немного предыстории:

У меня два разных датчика.

Один блок (скажем, блок типа А) имеет встроенные датчики (температура, влажность и т. д.) и создает строку CSV длиной 12 в фиксированном порядке, где все 12 значений мне пригодятся.

Другой блок (блок типа B) — это блок, в который можно подключать датчики, зажимы для контроля энергии и т. д. Во всех случаях он создает строку CSV длиной 13, но если у вас подключены только две вещи, вы получаете полезную информацию только от два из 13 значений CSV. У нас есть две разные конфигурации этого устройства, которые мы будем использовать.

Все датчики имеют идентификатор (указанный в строке CSV), я буду связывать датчик по идентификатору с комнатой, которая уже находится в базе данных (SQL 2016) через веб-интерфейс (ASP.NET).

Типы запросов, которые я буду делать: «какова текущая температура в комнате а». Мне также нужно будет запрашивать тенденции, такие как «дайте мне все комнаты со средней высокой влажностью».

Мой вопрос

Учитывая, что на данный момент у меня будет около 250 датчиков, каждый из которых будет отправлять сообщения через веб-API примерно каждые 10 секунд или около того, и в настоящее время у меня есть два разных типа строк CSV (возможно, больше в будущем), и в одном случае строка CSV будет содержать полезную информацию в другой части строки CSV, что бы вы порекомендовали в качестве подходящей структуры таблицы для поддержки этого? в идеале на SQL-сервере (может быть, в 2016 году для поддержки JSON?), поскольку SQL Server — это то, с чем я больше знаком, однако, если это плохой выбор, конечно, я открыт для ваших идей.

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

Я подумал о том, чтобы мой API был отделен от моего веб-приложения, чтобы разместить в нем свои датчики и заставить API хранить CSV «как есть» в базе данных вместе с идентификатором «типа датчика». Затем я подумал, что смогу опубликовать обработку в пакетном режиме (какой-то сервис), используя хранимую процедуру для вставки в мою основную базу данных в пакетном режиме, поскольку я думал, что это может несколько снизить накладные расходы API.

Структура базы данных

В здании много комнат, в комнате много датчиков. Датчик имеет тип. Я буду следить за сопоставлением номеров и идентификаторов датчиков в таблице сопоставления.

Объяснение типов датчиков

Датчик типа А имеет следующую информацию:

  1. Дата (строка)
  2. Время (строка)
  3. ID сенсора (строка)
  4. Темп (десятичный)
  5. Влажность (десятичная)
  6. Количество PIR (целое число)

Датчик B поставляется в двух разных конфигурациях, в обоих случаях публикуется одна и та же строка CSV, разные значения будут использоваться из нее, но я хочу сохранить:

Конфигурация 1 (температура трубы)

  1. DateTime (метка времени unix)
  2. идентификатор датчика
  3. Температура трубы 1 (десятичное число)
  4. Температура трубы 2 (десятичное число)

Конфигурация 2 (мониторинг мощности)

  1. DateTime (метка времени unix)
  2. ID сенсора (строка)
  3. Степень 1 (десятичная)
  4. Степень 2 (десятичная)
  5. Степень 3 (десятичная)
  6. Степень 4 (десятичная)

Все датчики имеют одинаковые общие данные:

  1. ДатаВремя
  2. идентификатор датчика

Я полагаю, что одно из решений состоит в том, чтобы в комнате было много «датчиков типа A» и много датчиков типа b в конфигурации 1 и много датчиков типа b в конфигурации 2, при этом каждый тип датчика имеет свою собственную таблицу для своих данных, однако я думал, что это будет было бы здорово, если бы я мог просто иметь одну таблицу для всех датчиков в таблице датчиков и дать им тип из таблицы типов, так как это было бы более гибким при добавлении большего количества датчиков. Недостатком этого подхода является то, как я могу связать эти различные типы/формы данных датчика.

Спасибо


api sql database sql-server-2016 sensors
person nado    schedule 24.10.2017    source источник
comment
Сенсорный стол, возможно, является отвлекающим маневром, поскольку вас на самом деле интересуют не датчики, а комнаты, верно? (Хотя вам, вероятно, все равно понадобится сенсорный стол). Вы НЕ хотите сохранить в базе данных строку CSV, а скорее столбец для каждого обнаруженного элемента, некоторые из которых могут быть нулевыми. Кстати, что произойдет, если отдельный датчик на блоке типа А выйдет из строя? ? И на самом деле, веб-API или какой-то процесс перевода для загрузки в базу данных — отличная идея.   -  person Clockwork-Muse    schedule 24.10.2017
comment
Я понимаю вашу точку зрения о сохранении обнаруженного элемента, а не CSV, блок типа B может считывать температуру трубы (в этом случае мне нужны два значения из 13-длинной строки CSV), или он может быть настроен для считывания показаний мощности (4 показания на строку CSV, так как у него есть 4 мощных считывателя), и в этом случае я буду использовать 13-длинную строку CSV, но мне нужно только 4 вещи из нее. Я буду знать, как используется датчик (мощность или температура трубы), поэтому я буду знать, какие значения представляют интерес, должен ли я хранить интересующие значения в виде json? или как «датчик имеет один ко многим чтениям, чтение имеет тип чтения» (водопровод и т. д.).   -  person nado    schedule 25.10.2017
comment
Чтобы немного расширить структуру базы данных, в здании много комнат, в комнате много датчиков (разных типов), и тип датчика можно настроить по-разному (но способы известны). «Разные способы» просто означают, что разные значения из строки CSV становятся либо полезными, либо неинтересными. Я полагаю, что разные маски были бы одним из способов описать это.   -  person nado    schedule 25.10.2017
comment
Вы хотите получить какую-то серию с временными метками, с fk-ссылками на комнату и датчик. Вы также не хотите ничего хранить в формате JSON, если можете этого избежать; вместо этого вы должны переводить таблицы с такими столбцами, как temperature_in_celsius и т. д.   -  person Clockwork-Muse    schedule 25.10.2017
comment
Единственная проблема заключается в том, что датчик может быть типа a, и в этом случае требуемые столбцы (мощность 1, мощность 2..) будут сильно отличаться от столбца типа b (температура, влажность и т. д.), я полагаю, было бы нормально, если бы В таблице со значением считывания есть столбец для каждого возможного типа считывания для всех типов датчиков, является ли это приемлемым решением?   -  person nado    schedule 25.10.2017
comment
.... вам может понадобиться несколько таблиц. Почему бы вам не обновить свой вопрос, указав тип информации, которую дают вам датчики, и к чему они относятся (трубы, комнаты, что угодно)   -  person Clockwork-Muse    schedule 25.10.2017
comment
Хорошая идея, я добавил информацию о типе для вас.   -  person nado    schedule 25.10.2017

Ответы (1)


arrow_upward
2
arrow_downward

Ваши основные параметры обсуждаются в этом вопросе, но это интересно для работы пример.

Хорошо, давайте по порядку.

В здании много комнат

Итак, мы знаем, что у нас есть две таблицы:

Building

и

Room 
  --fk to Building

в комнате много датчиков.

Sensor
  --fk to Room

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

Sensor

Room_Sensor
  --fk to Room
  --fk to Sensor

Датчик имеет тип.

Sensor
  --type id of some sort (manufacturer?)

Датчик типа А имеет следующую информацию:

... и тут становится интересно. Потому что, хотя Type A генерирует эту информацию, это не состояние Type A; это состояние room.

И это важная часть этого: базы данных являются хранилищем состояния (здесь ряд состояний, учитывая, что у нас есть временные метки).

Есть и дополнительная проблема — что произойдет, если датчики будут перемещены или комнаты будут разделены («добавление» двух или более комнат, которых раньше не было)? Итак, давайте немного отступим:

Room
  --fk to building

Sensor
  --type id of some sort, manufacturer info?

Room_Sensor
  --pk
  --fk to room
  --fk to sensor
  --createdAt timestamp

Обратите внимание, что Room_Sensor может иметь несколько копий одного и того же отношения (Room, Sensor), меняющихся со временем (возможно, датчик перемещался по коридору в течение недели или что-то в этом роде).

А как насчет измеренных данных? На самом деле у вас есть несколько разных «вещей» здесь:

Environment
  --fk to Room_Sensor
  --occurredAt timestamp
  --temperatureInCelsius
  --humidityInBar (or whatever other unit)
  --PIR (particulate?  please label your units)

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

Pipe

Pipe_Temperature
  --fk to pipe
  --fk to Room_Sensor
  --occurredAt timestamp
  --temperatureInCelsius

И

Electrical_Drop

Electrical_Drop_Draw
  --fk to Electrical_Drop
  --fk to Room_Sensor
  --occurredAt timestamp
  --consumptionInWatts

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

Обратите внимание, что для этого вам потребуется API или какая-либо загрузочная программа, но вам, скорее всего, потребуется одна из них в любом случае.

person Clockwork-Muse    schedule 24.10.2017
comment
Это здорово, мне очень нравится, как вы моделируете окружающую среду, так как датчик типа A является единственным типом датчика, ответственным за это. Температуры труб более специфичны для здания, поэтому я полагаю, что мог бы справиться с этим, как указано выше, но с привязкой к зданию (которое состоит из набора комнат). Спасибо, я думаю, что теперь у меня есть четкое представление о том, куда идти. - person nado; 25.10.2017
comment
Это выглядит разумной структурой и ответом. однако я бы порекомендовал OP исследовать различные стандарты открытого строительства, такие как gbxml, cobie и стандарты, связанные с BIM, и т. д. Обычно следует проектирование: площадка, здание, этаж [этажи], зона, пространство, тип помещения, оборудование, устройство, протокол, данные . В этой последовательности. Изучение отраслевых стандартов позволит в будущем обеспечить устаревшую совместимость. - person Radio; 25.10.2017
comment
Хороший совет. Радио. Структура здания фактически будет соответствовать IFC. Я не включил эту информацию, так как меня интересовала сенсорная сторона вещей, и я не хотел отпугивать людей такими словами, как BIM и IFC, но это верная точка зрения. - person nado; 25.10.2017
comment
Для слоя REST API рассмотрите SlashDB. Он автоматически отображает вашу модель SQL в API для чтения и записи. Это особенно полезно, поскольку на данном этапе ваша модель сильно меняется, и необходимость кодировать слой API вручную для каждого изменения является большой проблемой. Раскрытие информации: SlashDB — это мое дело. slashdb.com - person Victor Olex; 15.11.2017