Создание веб-приложения для IoT. Урок 2.
Здравствуйте, коллеги! Мы продолжаем уроки по созданию веб-приложения для IoT. В предыдущем уроке мы познакомились с понятием «веб-сервер», на котором и будет находиться наше веб-приложение, рассмотрели его структуру, основные компоненты и взаимодействие с клиентами.
Сегодня мы приступим к разработке архитектуры базы данных (БД) нашего (т.е. вашего) будущего веб-приложения, посмотрим, как представить данные, с которыми будет работать приложение, в виде связанных таблиц в БД.
Поехали!
Выбор сервера для веб-приложения
Для начала нужно определить место, где будет храниться веб-приложение.
В качестве такого места можно использовать обычный домашний компьютер, на который достаточно установить серверное ПО. Однако, у такого метода есть, как минимум, два недостатка. Во-первых, Вам нужно будет постоянно держать компьютер включённым (если Вы, конечно, хотите чтобы Ваше приложение было постоянно доступным). Ну и во-вторых, для этого Вам потребуется статический IP-адрес, чтобы приложение было доступно в глобальной сети.
Если выше описанные ограничения Вас не касаются и Вы нашли способ их исключить — тогда можете использовать ПК в качестве сервера. А мы сделаем веб-сервер на удалённом хостинге.
Выбор хостинга — личное дело каждого. Многие из них бесплатны или имеют бесплатный период. Мы используем хостинг beget. На нём так же доступен вариант бесплатного хостинга. Не сочтите за рекламу хостинга, но, возможно, кому-то будет удобно работать с интерфейсом, совпадающим с картинками в этой и последующих статьях.
Регистрация на хостинге
Для регистрации на бесплатном хостинге проходим по ссылке , вводим Ф.И.О., телефон и жмём «Зарегистрировать аккаунт».
Подтверждаем номер телефона кодом из СМС и хостинг Ваш. В дополнение Вам выдадут бесплатное доменное имя, по которому Ваше приложение будет доступно в сети.
Мне выдали имя «z925997t.beget.tech» — некрасиво, зато бесплатно!
При входе в аккаунт видим панель управление с множеством пунктов:
Отсюда нам понадобятся «Файловый менеджер», где будет храниться код приложения (скрипты и др. файлы), и «MySQL» — собственно база данных, настройке которой и посвящён этот урок.
Отсутствует модуль «Планировщик задач», о котором мы говорили в первом уроке — это ограничение бесплатного хостинга. Ничего страшного, на начальном этапе обойдёмся без него.
Архитектура БД приложения
Напомним, что в качестве учебного примера мы работаем с системой мониторинга температуры, под которую мы создали набор-конструктор и выпустили серию уроков.
Система состоит из передающего устройства, которое измеряет температуру и отсылает её на сервер. Также устройство оборудовано электромагнитным реле, с помощью которого можно управлять каким-то прибором, воздействующим на температуру (например, печь или вентилятор). Команды для управления реле устройство получает с сервера, а на сервер её передаёт пользователь нажимая на кнопку (например, «Включить печь») в веб-приложении.
Итак, давайте попробуем представить простейшую структуру базы данных для такого приложения:
На схеме мы видим таблицы БД и взаимосвязи между ними. Каждая таблица — сущность (или класс), т.е. некая структура, которая может иметь физическое представление или заслуживать выделения в отдельную таблицу исходя из других соображений.
Мы выделили сущность «Устройство» и создали для него таблицу «DEVICE_TABLE». Предполагается, что ваше приложение может управлять сразу несколькими устройствами. Для каждого из этих устройств мы сможем хранить свойства «LOGIN», «PASSWORD» для авторизации в приложении и «NAME» для того, чтобы его как-то назвать.
Также мы выделяем таблицы:
- TEMPERATURE_TABLE — для хранения температур, передаваемых всеми устройствами, с метками времени.
- OUT_STATE_TABLE — для хранения текущего состояния реле каждого из устройств с метками времени.
- COMMAND_TABLE — для хранения команд реле каждого из устройств, также с меткой времени.
Если Вы, например, захотите, чтобы устройство передавало ещё и влажность — добавьте ещё одну сущность. Вот так:
Вот то же самое, но в виде таблиц:
Поле DEVICE_ID является первичным ключом для всех таблиц, т.е. является уникальным индексом. Он позволяет найти данные для конкретного устройства во всех таблицах. Так реализуется связь данных.
Кроме того, первичный ключ обеспечивает непротиворечивость данных. БД не даст по ошибке или по злому умыслу добавить в таблицу устройство с одинаковым ID, или удалить устройство из таблицы DEVICE_TABLE до тех пор, пока другие таблицы содержат данные, относящиеся к этому устройству.
Таким образом, например, таблица TEMPERATURE_TABLE содержит одну строчку с температурой устройства с ID=1. Когда устройство присылает новые данные — эта строка перезаписывается.
Мы могли бы, например, объединить несколько таблиц в одну, например так:
Тут температура, влажность и состояние реле устройства хранятся в одной таблице. Такой подход возможен, но тогда, например, при изменении только влажности мы перезаписывали бы лишний раз состояние реле и температуру — поэтому это не лучший вариант.
Вообще, проектирование баз данных — процесс сложный и творческий. Часто в процессе разработки приложения приходится кардинально менять архитектуру БД. Но это , пожалуй, тема даже не отдельной статьи, а целого учебника. Поэтому, вернёмся к практике…
Создаём базу данных
Теперь перенесём все «умозаключения», сделанные выше, в реальную базу данных на нашем сервере.
Наш хостинг имеет базу данных MySQL — одна из самых популярных БД, нас полностью устраивает. Заходим в раздел MySQL, придумываем имя и пароль для БД и нажимаем «Добавить».
База данных создана и появляется в списке ниже:
Наживаем на значок РМА (PhpMyAdmin) и приступаем к редактированию БД.
Создаём таблицу DEVICE_TABLE:
Нажимаем «Вперёд» и приступаем к редактированию полей таблицы. Делаем всё как на картинке, всё, что осталось за кадром, оставляем по умолчанию и нажимаем сохранить:
Точно так же создаём остальные таблицы.
TEMPERATURE_TABLE
Обратите внимание, что для поля TEMPERATURE установлен атрибут NULL — это значит, что оно может принимать такие значения. Вам может понадобиться передавать значения NULL при обрывах датчика температуры.
OUT_STATE_TABLE
COMMAND_TABLE
Теперь нужно сделать поле DEVICE_ID первичным ключом в каждой из таблиц. Кликаем на таблицу DEVICE_TABLE и переходим на вкладку «Структура».
Нажимаем на кнопку «Первичный» напротив поля DEVICE_ID. Теперь это поле является первичным ключом.
То же самое проделываем для остальных таблиц.
Теперь переходим в графический дизайнер. Для этого нажимаем на название БД в каталоге справа и переходим на вкладку «Дизайнер».
В дизайнере устанавливаем связи между таблицами:
Для каждой из таблиц TEMPERATURE_TABLE, COMMAND_TABLE и OUT_STATE_TABLE указываем поле DEVICE_ID в качестве внешнего ключа, а одноимённое поле в таблице DEVICE_TABLE в качестве ссылочного ключа. Должно получиться следующее:
Теперь давайте создадим в БД одно устройство, с которым будем работать в следующих уроках. Для этого открываем таблицу DEVICE_TABLE.
Переходим на вкладку «Вставить», заполняем поля таблицы, как показано на картинке, и жмём «Вперёд».
Готово. У нас в таблице DEVICE_TABLE одно устройство с ID=1.
Теперь наша БД готова. Мы подготовили хранилище данных для нашего приложения, которое будем использовать во всех последующих уроках. Если на этом этапе остались вопросы — не беда, всё проясниться в следующих уроках. Как только мы разберёмся, как приложение работает с БД, Вы сможете добавить в базу другие таблицы, необходимые в Вашем приложении.
В следующем уроке будем создавать интерфейс приложения! Следите за обновлениями на LAZY SAMRT.
ошибка: функция связи отключена!
не могу никак разобраться на этом этапе — подскажите что нужно сделать??
В предложенной вами программе при создании связей между таблицами указывает, что «функция связи отключена». Где ее включить для варианта этой программы в браузере — так и не нашёл. Было бы здорово уточнить этот момент.