Камери, въртящи се врати, асансьори, температурни сензори, аларми – всички тези устройства произвеждат голям брой взаимосвързани сигнали, които са свързани със събития, случващи се около нас. Сега си представете, че вие сте човекът, който трябва да проследява статусите, да изготвя отчети в реално време и да прави прогнози въз основа на всички тези сигнални данни. За да направите това, първо трябва да съхраните тези данни. Модел на данни, който поддържа такава обработка на сигнали, е темата на днешната статия.
Най-простият начин за съхраняване на входящи сигнали би бил просто да съхранявате текстово представяне на тях в един огромен списък. Този подход ще ни позволи да извършваме вмъквания бързо, но актуализациите биха били проблематични. Освен това такъв модел няма да бъде нормализиран и следователно няма да вървим в тази посока.
Ще създадем нормализиран модел на данни, който може да се използва за съхраняване на данните, генерирани от различни устройства, и също така да дефинираме как устройствата са свързани. Такъв модел би съхранил ефективно всичко, от което се нуждаем, и би могъл да се използва и за анализи и прогнозни анализи.
Модел на данни
Моделът на данни за обработка на сигнала
Моделът се състои от три предметни области:
ComplexesInstallations & DevicesSignals & Events
Ще опишем всяка от тези тематични области в реда, в който е изброен.
Комплекси
Докато създавах този модел на данни, отидох с предположението, че ще го използваме, за да проследим какво се случва в по-големи комплекси. Комплексите варират по размер от единична стая до търговски център. Важно е всеки комплекс да има поне едно устройство/сензор, но вероятно ще има много повече.
Преди да опишем комплексите, трябва да дефинираме таблиците, обработващи държави и градове. Те ще предоставят доста подробно описание на местоположението на всеки комплекс.
За всяка country , ще съхраним неговото УНИКАЛНО country_name; за всеки city , ще съхраняваме УНИКАЛНАТА комбинация от postal_code , city_name и country_id . Тук няма да навлизам в подробности и ще приемем, че всеки град има само един пощенски код. В действителност повечето градове ще имат повече от един пощенски код; в този случай можем да използваме основния код за всеки град.
complex е действителната сграда или местоположение, където са инсталирани устройства за генериране на данни. Както беше посочено по-горе, комплексите могат да варират от единична стая или измервателна станция до много по-големи места като паркинги, търговски центрове, кина и др. Те са обект на нашия анализ. Искаме да можем да проследяваме какво се случва на комплексно ниво в реално време и по-късно да изготвяме отчети и анализи. За всеки комплекс ще дефинираме:
complex_code– УНИКАЛЕН идентификатор за всеки комплекс. Докато имаме отделен атрибут на първичен ключ (id) за тази таблица можем да очакваме, че ще наследим друг идентификационен код за всеки комплекс от друга система.complex_name– Име, използвано за описване на този комплекс. В случай на търговски центрове и кина, това може да е тяхното действително и добре познато име; за измервателна станция бихме могли да използваме общо име.city_id– Препратка към града, в който се намира комплексът.address– Физическият адрес на този комплекс.position– Позицията на комплекса (т.е. географски координати), дефинирана в текстов формат.description– Текстово описание, което описва по-отблизо този комплекс.ts_inserted– Отпечатък за време, когато този запис е бил вмъкнат.is_active– Булева стойност, обозначаваща дали този комплекс все още е активен или не.
Инсталации и устройства
Сега се приближаваме до сърцето на нашия модел. Вероятно ще имаме инсталирани няколко устройства във всеки комплекс. Също така почти сигурно ще групираме тези устройства въз основа на предназначението им – напр. бихме могли да поставим камери, сензори за врати и мотор, използвани за отваряне и затваряне на врата в група, защото работят заедно.
В нашия модел устройствата, които работят заедно в един комплекс, са групирани в инсталации. Те могат да бъдат за входни врати, ескалатори, температурни сензори и др. За всяка инсталация ще съхраняваме следните подробности в installation таблица:
installation_code– УНИКАЛЕН код, използван за обозначаване на тази инсталация.installation type_id– Препратка къмinstallation_typeречник. Този речник съхранява само УНИКАЛНОtype_nameатрибут, който описва типа, напр. ескалатор, асансьор.complex_id– Препратка къмcomplexна която принадлежи инсталацията.position– Координатите, в текстов формат, на тази инсталация в комплекса.description– Текстово описание на тази инсталация.current_status_id– Препратка към текущото състояние (отinstallation_statusтаблица) на тази инсталация.ts_inserted– Отпечатък за време, когато този запис е бил вмъкнат в нашата система.
Вече споменахме статусите на инсталиране. Списък с всички възможни състояния се съхранява в installation_status речник. Всяко състояние е УНИКАЛНО дефинирано от неговото status_name . Освен това, ние ще съхраняваме флагове, обозначаващи дали това състояние, когато се използва, предполага, че инсталацията is_broken , is_inactive , is_maintenance , или is_active . В даден момент трябва да се задава само един от тези флагове.
Вече сме присвоили текущо състояние на инсталацията. Ако искаме да проследим какво се случва с устройството, ние също трябва да съхраняваме неговата история. За да направим това, ще използваме още една таблица, installation_status_history . За всеки запис тук ще съхраняваме препратки към свързаната инсталация и състояние, както и момента (ts_inserted ), когато този статус е бил присвоен.
Инсталациите са част от нашите комплекси. Въпреки че всяка инсталация е едно цяло, тя все пак може да бъде свързана с други инсталации. (Например видеосистемата на предния вход на търговския център очевидно е свързана с входните врати на мола – хората първо ще бъдат видени от камерата и след това вратите ще се отворят.) Ако искаме да следим тези връзки, ще ги съхраняваме в related_installation маса. Моля, обърнете внимание, че тази таблица съдържа само УНИКАЛНИ двойки от два ключа, като и двата се отнасят за installation маса.
Същата логика се използва за съхранение на устройства. Устройствата са отделни хардуерни части, които произвеждат сигналите, които ни интересуват. Докато инсталациите принадлежат на комплекси, устройствата принадлежат на инсталации. За всяко device , ние ще съхраняваме:
device_code– УНИКАЛЕН начин за обозначаване на всяко устройство.device_name– Име за това устройство.installation_id– Препратка към инсталацията, към която принадлежи това устройство.current_status_id– Текущото състояние на устройството.ts_inserted– Отпечатък за време, когато този запис е бил вмъкнат.
Състоянието се обработва по същия начин. Ще използваме device_status таблица за съхраняване на списък с всички възможни състояния на устройства. Тази таблица има същата структура като installation_status и атрибутите се използват по същия начин. Причината за наличието на двата отделни речника на състоянието е, че устройствата и техните инсталации могат да имат различни състояния – поне по име.
Текущото състояние се съхранява в device.current_status_id атрибут и историята на състоянието се съхранява в device_status_history маса. За всеки запис тук ще съхраняваме връзки с устройството и състоянието, както и момента, в който този запис е бил вмъкнат.
Последната таблица в тази тема е related_device маса. Въпреки че е почти очевидно, че всички устройства в една и съща инсталация са тясно свързани, искам да имам възможност да свържа всички две устройства, принадлежащи към всяка инсталация. Ще направим това, като съхраним техните два идентификатора на устройства в тази таблица.
Сигнали и събития
Сега сме готови за сърцето на целия модел.
Устройствата генерират сигнали. Всички сигнални данни се съхраняват в signal маса. За всеки сигнал ще съхраняваме:
device_id– Препратка към устройството, генерирало този сигнал.value– Числовата стойност на този сигнал.description– Текстова стойност, която може да съдържа всякакви допълнителни параметри (например тип на сигнала, стойности, използвана мерна единица), свързани с този единичен сигнал. Тези данни се съхраняват във формат, подобен на JSON.ts– Отпечатък за време, когато този сигнал е бил вмъкнат в таблицата.
Можем да очакваме, че тази таблица ще се използва изключително интензивно, с голям брой вмъквания, изпълнявани в секунда. Следователно поддръжката на базата данни трябва да се съсредоточи върху проследяването на размера на тази таблица.
Последното нещо, което искам да направя, е да добавя събития към нашия модел на данни. Събитията могат да бъдат генерирани автоматично чрез сигнал или вмъкнати ръчно. Едно автоматично генерирано събитие може да бъде „отворена врата за 5 минути“, докато ръчно въведено събитие може да бъде „устройството трябваше да бъде изключено поради този сигнал“. Цялата идея е да се съхраняват действия, възникнали в резултат на поведението на устройството. По-късно бихме могли да използваме тези събития, докато извършваме анализ на поведението на устройството.
Събитията ще бъдат гранулирани по event_type . Всеки тип е УНИКАЛНО дефиниран от своя type_name .
Всички автоматично генерирани или ръчно вмъкнати събития се записват в event маса. За всеки запис тук ще съхраняваме:
event_type_id– Препратка към съответния тип събитие.description– Текстово описание на това събитие.signal_id– Препратка към сигнала, ако има такъв, който е причинил събитието.inserted_manually– Флаг, обозначаващ дали този запис е бил вмъкнат ръчно или не.event_tsиts_inserted– Времеви печати, когато това събитие действително се е случило и кога е вмъкнат запис за него. Тези две може да се различават, особено когато записи за събития се вмъкват ръчно.
Последната таблица в нашия модел е event_device маса. Тази таблица се използва за свързване на събития с всички участващи устройства. За всеки запис ще съхраняваме УНИКАЛНАТА двойка event_id – device_id и времевата марка, когато записът е бил вмъкнат.
Какво мислите за нашия модел на данни за обработка на сигнали?
Днес анализирахме опростен модел на данни, който бихме могли да използваме за проследяване на сигнали от набор от устройства, инсталирани на различни места. Самият модел трябва да е достатъчен, за да съхраняваме всичко необходимо за проследяване на статуси и извършване на анализи. Все пак са възможни много подобрения. Какво бихме могли да добавим? Моля, кажете ни в коментарите по-долу.
