Рисунок 2.5 Архитектурная модель части умного города, рассматриваемой в данной работе

Архитектурный подход описания информационных систем применяют в тех случаях, когда система охватывает множество сфер жизни, является многоуровневой и сложной. В рамках данной работы, как описано выше, были выбраны только некоторые из сфер жизни человека, но именно такие, для объединения которых потребуется реализация не просто базы данных какого-либо определенного типа, а именно цифровой двойник. Так как информация, обрабатываемая бизнес-сервисами, разнотипная, решить проблему её общего хранения и работы с ней может именно цифровой двойник: информация с датчиков будет обрабатываться с помощью базы данных временных рядов, так как она обновляется в режиме онлайн и имеет простую структуру, информация об объектах умного города должна храниться в структурированной базе с быстрым доступом к данным - подойдет реляционный тип базы данных. Информация из документов же или иная информация, не поддающаяся строгой типизации, может храниться в NoSql-базах данных. Необходимо оценить аналоги и выбрать наиболее подходящие инструменты для проектирования цифрового двойника.

Применение архитектурного метода описания проектируемой системы позволило понять детально, какие бизнес-сервисы необходимо реализовать в системе для полного и корректного функционирования глобальных бизнес-процессов умного города, а также какие функциональные модули нужны в системе для поддержки бизнес-процессов. На основе определенных функциональных модулей были выделены блоки данных, которые необходимы для хранения в проектируемом цифровом двойнике. После ограничения всей архитектурной модели системы умного города только выбранными в рамках данной выпускной квалификационной работы областями, количество блоков данных также сократилось, однако они недостаточно детализированы, чтобы не перегружать общую схему модели. Для детализации выделенных блоков данных необходимо более подробно проанализировать бизнес-процессы. Одним из самых удобных способов представления бизнес-процессов является их графическое описание с помощью диаграмм. Поэтому определенные выше бизнес-процессы были описаны с помощью диаграмм активности, чтобы на основе детализированного представления бизнес-процесса выделить объекты (сущности) и конкретную информацию о них, необходимую для хранения в цифровом двойнике. Логику применения архитектурного метода можно описать следующей схемой (см. рис. 2.6):



Рисунок 2.6 Логика применения архитектурного метода для проектирования цифрового двойника

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

2.2 Бизнес-процессы, протекающие в «умных городах»

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

К сфере развлечений можно отнести следующие бизнес-процессы:

1. Отображение информации о здании по запросу (рис. 2.7). Данный бизнес-процесс описывает считывание уникального маркера здания, а также поиск в базе данных информации о нём. Бизнес-процесс был описан с использованием диаграммы активности нотации UML.



Рисунок 2.7 Отображение информации о здании по запросу

2. Поиск и создание списка рекомендаций похожих зданий в ближайшем районе (см. рис. 2.8). Данный бизнес-процесс описывает поиск информации о зданиях, похожих на то, которое смотрит пользователь. Для того, чтобы поиск был удобнее, пользователю предлагается выбрать критерий «схожести» зданий. Также, чтобы показывались здания поблизости, пользователю необходимо включить отображение геолокации на телефоне (или устройстве, с которого он заходит в приложение).

Рисунок 2.8 Поиск похожих зданий поблизости

К сфере безопасности можно отнести следующие бизнес-процессы:

1. Считывание информации с датчиков с определенной периодичностью

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

Рисунок 2.9 Считывание информации с датчиков

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

Рисунок 2.10 Считывание информации с датчиков (последовательность)

На диаграмме выделено, что значения датчиков и основная информация о них должны храниться в разных базах данных, потому что информация различная по своей структуре. Подробнее о необходимых типах баз данных для цифрового двойника будет описано в работе далее. Также по данной диаграмме видно, что в базе данных необходимо хранить информацию о пользователях, чтобы ограничивать доступ к информации об объектах и датчиках.

2. Проверка соответствия значений показателей норме (включает в себя отправку предупредительного сигнала.

Бизнес-процесс сверки значения, полученного с датчика, с нормативным значением, является основным бизнес-процессом в сфере безопасности (см. прил. А). Для каждого показателя, например, температура внутри помещения, существует закрепленное в нормативно-правовых актах нормативное значение. Чаще всего это значение определяется интервалом. Суть бизнес-процесса заключается в сверке значений датчика с нормативным значением, хранящимся в базе данных.

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

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

1. Цифровой двойник должен состоять из нескольких типов баз данных, так как информация, необходимая для хранения, разрозненная.

2. Уже на данном этапе можно выделить такие сущности будущей спроектированной базы данных как: пользователь, объект умного города (необходима детализация в соответствии с выбранной сферой жизни - развлечения), датчик.

Важно отметить, что сущность «объект умного города» должна присутствовать в базе данных для последующего масштабирования системы. Так как в рамках данной работы была выбрана только сфера развлечений, то более мелкие сущности (например, ресторан, кино, кафе и так далее) также должны быть добавлены (и разделены именно на разные сущности, так как набор полей существенно отличается). Однако у всех объектов умного города определенно будут и общие поля, которые некорректно будет дублировать во всех таблицах детализированных сущностей. При масштабировании системы будет удобно добавлять новые сущности в базу, объединяя их сущностью «объект умного города», - таким образом они будут логически правильно определены в базе, а не будут существовать отдельно от других объектов.

Таким образом, основываясь на архитектурном подходе к проектированию системы умного города, система была разобрана по уровням от более крупной концепции к более мелким - конкретным функциональным модулям. На основе выделенных модулей были выделены бизнес-процессы, функционал для осуществления которых будет спроектирован в рамках этой работы. Далее бизнес-процессы были детализированы, чтобы выявить основные сущности, необходимые для реализации этих бизнес-процессов. Следующим этапом в работе необходимо детализировать сущность «объект умного города», а также понять, какие поля должны быть в базе данных у выделенных сущностей и определить их типы данных.

2.3 Описание объектов умного города и определение данных для хранения в базе данных

В проекте такого масштаба как выпускная квалификационная работа сложно было бы уместить разработку требований для модели города целиком, включив все сферы жизни. Поэтому для данных ограничений по времени и трудоёмкости были определены следующие ограничения: затрагивается сфера развлечений (театры, концертные залы, музеи и так далее), а также сфера безопасности (датчики, установленные на жилых или «развлекательных» зданиях, должны контролировать уровень опасности нахождения в помещении, а также сообщать о неисправностях в работе сферы ЖКХ). Выше в работе уже была описана причина выбора именно этих сфер: на их примере можно показать выгодность проектирования именно цифрового двойника, позволяющего обрабатывать и хранить разрозненную информацию.

2.3.1 Сфера безопасности

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

ѕ подача воды (горячей и холодной);

ѕ загазованность помещений здания;

ѕ подача электроэнергии;

ѕ показатели температуры внутри помещений;

ѕ показатели датчиков движения;

ѕ показатели загазованности помещений.

ѕ запись камер видеонаблюдения.

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

В базу данных должна поступать следующая информация. Для начала была выделена отдельная таблица с описанием здания (табл. 2.1) - в неё вынесены все общие поля для зданий разных типов, которые будут описаны ниже.



Таблица 2.1

Информация, которая должна храниться в БД (общая информация о здании)

Наименование поля	Тип поля	Комментарий
ID	Int	Уникальный идентификатор, для пользователя не выводится в силу отсутствия необходимости
HistoricalAccount	String	Историческая справка, опционально
Picture	Image	Фотография здания
Latitude	Decimal	Широта
Longitude	Decimal	Долгота
Country	String	Страна
Region/Province/ Neighborhood	String	Регион, провинция или район
City	String	Город
Street	String	Улица
House/Building	String	Дом/строение/корпус
Organizations	List<Organization>	Организации в здании

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

Таблица 2.2

Информация, которая должна храниться в БД (сфера безопасности)

Наименование поля	Тип поля	Комментарий
ID	int
IDBuildingType	int	Тип здания (жилое/ административное/ развлекательная сфера/ и т.д.).
BuildingType	string	Описание типа здания (жилое/ административное/ развлекательная сфера/ и т.д.).
Sensors	List<Sensor>	Датчики
SensorDescription	string	Могут быть следующие датчики: подача воды, загазованность помещения, подача электроэнергии, температура воздуха внутри здания, показания датчиков движения, запись камер видеонаблюдения.
Indicator	List<Indicator>	От значения данного показателя зависит, включать ли сигнализацию и вызывать ли экстренные службы.
LegalAct		Нормативно-правовые акты нужны для отображения нормы значения показателей, измеряемых датчиками. Хранится в докуметоориентированной базе данных.

Как видно из таблицы 2.2, значения датчиков удобнее всего хранить в виде временных рядов. Остальную информацию о здании удобно было бы хранить в виде реляционной базы данных. Отдельно от основной информации о здании удобно хранить информацию о датчике (табл. 2.3).

Таблица 2.3

Информация, которая должна храниться в БД (датчик)

Наименование поля	Тип поля	Комментарий
IDSensor	int
SensorDescription	string	Могут быть следующие датчики: подача воды, загазованность помещения, подача электроэнергии, температура воздуха внутри здания, показания датчиков движения, запись камер видеонаблюдения.
SensorValue		Должно храниться как временной ряд (например, в influxDB).

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

2.3.2 Сфера развлечений

К объектам данной сферы относятся здания развлекательной индустрии: театры, музеи, исторические здания и так далее. На зданиях также будут расположены различные датчики, собирающие значения различных показателей. Но сфера развлечений в рамках данной работы будет рассмотрена не в качестве здания с датчиками (к этому больше относится описанная ранее сфера безопасности). В контексте данной работы «сфера развлечений» -- это здания, при просмотре информации о которых через специальное приложение, пользователю должна быть доступна информация о мероприятиях с данном здании, какие-то исторические факты о нём или другая информация развлекательного характера. Ниже в виде таблиц описаны информационные модели для различных объектов умного города в сфере развлечений (табл. 2.4 - 2.8). Данные таблицы связаны с общей таблицей, содержащей информацию о здании - объекте умного города (см. табл. 2.1) по ID здания.

Таблица 2.4

Информация, которая должна храниться в БД (ресторан)

Наименование поля	Тип поля	Комментарий
ID	Int
Rating	Double	Рейтинг ресторана
AverageCheck	Int	Берём целочисленное значение, для пользователя не имеют значения цифры после запятой
NumberOfEmptyTables		Количество свободных столов
FamousCooks	List<Person>	Опциональный список со ссылками на объекты человека или любой другой похожей модели
FanciestDishes	List<Dish>	Опциональный список с самыми необычными блюдами
MostPopularDishes	List<Dish>	Опциональный список с самыми популярными блюдами
Website	String
Picture	Image	Изображение ресторана

В таблице 2.4 описана информация о ресторанах, необходимая для хранения в базе данных. Данная информация позволит пользователю, например, найти ресторан поблизости, посмотреть его рейтинг, количество свободных мест, а также набор блюд. На основе этой информации пользователь сможет быстро подобрать для себя наиболее удобное и комфортное место для отдыха.



Таблица 2.5

Информация, которая должна храниться в БД (кинотеатр)

Наименование поля	Тип поля	Комментарий
ID	Int
Website	String
ComfortabilityRating	Double	Рейтинг кинотеатра
Movies	List<Movie>	Список фильмов в прокате
Picture	Image	Изображение здания кинотеатра

В таблице 2.5 показана информация о кинотеатре, она может пригодиться системе, чтобы подсказать пользователю оптимальный маршрут до кинотеатра. Отдельно была проработана информация о кино (о сеансе какого-либо фильма), эту информацию также может получить пользователь при поиске кинотеатра поблизости (табл. 2.6).

Таблица 2.6

Информация, которая должна храниться в БД (сеанс кино)

Наименование поля	Тип поля	Комментарий
ID	Int
Name	String	Название фильма
Description	String	Описание фильма
Rating	Double	Рейтинг фильма
ReleaseDate	Date	Дата выхода
EndDate	Date	Дата окончания проката
BoxOffice	Int	Кассовые сборы, опционально
Showings	List<Showing>	Сеансы
Poster	Image	Изображение официального постера

В таблице 2.7 описана информация про музей или выставочный центр. Данную информацию пользователь может использовать, чтобы посмотреть выставки неподалёку от его местоположения, а также посмотреть стоимость билетов.



Таблица 2.7

Информация, которая должна храниться в БД (музей)

Наименование поля	Тип поля	Комментарий
ID	Int
Exhibitions	List<Exhibition>	Выставки
Picture	Image	Изображение музея

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

Таблица 2.8

Информация, которая должна храниться в БД (выставка)

Наименование поля	Тип поля	Комментарий
ID	Int
Name	String
Description	String	Эта информация может храниться в докуметоориентированной базе данных (например, mongoDB).
TicketPrice	Int	Цена билета
StartDate	Date	Начало выставки
EndDate	Date	Конец выствки
BoxOffice	Int	Кассовые сборы, опционально
Showings	List<Showing>	Сеансы выставки
Poster	Image	Официальная афиша

Как видно из описанных выше таблиц, пользователь при желании просмотреть информацию об объекте сможет узнать афишу мероприятий, официальный сайт или контактный телефон, а также информацию о самом здании. Пример - дом Мешкова в Перми. Данное здание стало музеем не сразу и построено было не под музей, оно имеет интересные исторические корни, которые и могут быть описаны с помощью исторических статей, которые также должны стать доступны пользователю.

Также, так как пользователь будет регистрироваться в приложении, то необходимо хранить информацию о нём - ФИО, логин и пароль. Авторизация в приложении необходима для того, чтобы пользователь мог себе «пометить» какие-то здания, за которыми он хочет следить (например, свой дом и дом родителей, чтобы следить за возможностью возникновения ЧС и предпринять меры).

2.4 Обоснование выбора технологий

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

Ранее в работе была выявлена та информация, которая должна храниться и обрабатываться в базе данных. На основе полученной информации можно сделать вывод, что для успешной работы умного города всю информацию будет неэффективно хранить в базе данных какого-то определенного типа (например, в реляционной). Для основной части данных лучше всего подойдет реляционная база данных, однако для каких-то определенных полей (например, показания датчиков) лучше подойдет база данных типа временной ряд. Также важно учесть, что для такой сложной системы как “умный город” важным аспектом является юридическая составляющая обработки данных. Таким образом, работа с документами будет неотъемлемой частью работы с данными. Из этого можно сделать вывод, что нужна специализированная база данных, ориентированная именно на хранение и обработку документов, так как хранить их, например, в простой реляционной базе было бы крайне неэффективно и некорректно.

Если рассматривать проектируемую модель с точки зрения классификации цифровых двойников, то она скорее относится к двойнику-прототипу. Основной существующей классификацией считается разработанная в 2003 году Майклом Гривзом, он выделил 3 типа цифровых двойников: прототип, экземпляр и агрегатор. «Прототип» - это такая модель, которая содержит информационные наборы, необходимые для описания и создания физической версии исследуемого объекта. «Прототипы» не ограничиваются требованиями и спецификой процессов, но включают их. То есть данный тип наиболее абстрактный. «Экземпляр» - это описание конкретного физического объекта, причем данный тип двойника описывает полный жизненный цикл объекта. Он может включать в себя, например, 3D-модель конкретного объекта. На основе «прототипа» можно разработать несколько объектов, но каждый из них будет иметь собственный «экземпляр». Существует третий тип цифровых двойников в данной классификации - «агрегатор». Данный тип объединяет предыдущие два типа, может содержать все виртуальные прототипы

2.3.1 Выбор документо-ориентированной базы данных

Документо-ориентированная база данных отличается тем, что в ней хранятся иерархические структуры документов. Обычно хранение и обработка информации в таком типе базы данных происходит с помощью NoSQL. NoSQL -- это такой подход к реализации систем управления базами данных, в основе которого лежат такие принципы как [14]:

ѕ базовая доступность (данный термин обозначает гарантированную завершаемость запросов, причем они могут завершаться как успешно, так и с ошибками);

ѕ неструктурированность (то есть у объектов нет строго заданной и четко определенной структуры, например, в отдельной строке можно добавить новое поле без предварительного изменения структуры всей таблицы);

ѕ агрегаты (данные хранятся в виде агрегатов - объединённых сущностей, таким образом вся информация об объекте хранится в одном месте);

ѕ неограниченное горизонтальное масштабирование;

ѕ и другие.

ѕ У указанного типа баз данных существуют свои преимущества и недостатки. К преимуществам можно отнести:

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

ѕ Процесс масштабирования базы данных намного проще, чем, к примеру, для реляционных баз данных.

ѕ Несложный процесс “общения” с базой данных, обращения к ней - простая структура: ключ - значение.

ѕ К основным недостаткам можно отнести следующие характеристики:

ѕ Избыточность результатов запроса и как следствие нерациональность. Если выполнен запрос к какому-либо документу, то результатом запроса будет весь документ целиком. Если необходимо было получить, к примеру, значение какого-то одного поля, то результат в виде таблицы будет слишком избыточен.

ѕ Слабые зависимости между данными. Может возникнуть ситуация, когда нет никакой связи (и невозможно её построить) между каким-то документом и какой-то коллекцией.

К примерам документо-ориентированной базы данных относят следующие:

ѕ MongoDB;

ѕ CouchDB;

ѕ IBM Notes;

ѕ И другие.

Для того, чтобы выявить наиболее подходящую под данный проект базу, было проведено сравнение самых распространенных из перечисленных выше примеров. Результаты сравнения представлены в виде таблицы (табл. 2.9) [15].

Таблица 2.9

Сравнительная таблица документо-ориентированных БД

	MongoDB	CouchDB	IBM Notes
Структура БД	Документы в формате BSON без заранее определенной структуры.	Документы в формате JSON.	Документы хранятся без заранее определенной структуры, поля могут динамически добавляться.
Индексация	Может и не быть индексов, однако лучше их добавлять, так как это ускорит чтение информации из базы.	Аналогично SQL, создается один раз при создании документа и изменяется только при обновлении документа.	Аналогично MongoDB.
Синтаксис запроса (пример)	Все записи с ключом «Толстой»: db.mybooks.find ({автор: «Толстой»})	Все записи с ключом «Толстой»: curl -X GET http://127.0.0.1:5984/mybooks/_design/ application/_view/author?key= "Tolstoy "	Синтаксис похож на SQL запросы.
Поддержка языков программирования	Actionscript, C, C #, C ++, Clojure, ColdFusion, D, Dart, Delphi, Erlang, Go, Groovy, Haskell, Java, JavaScript, Lisp, Lua, MatLab, Perl, PHP, PowerShell Пролог, Python, R, Ruby, Scala и Smalltalk	C, C #, ColdFusion, Erlang, Haskell, Java, JavaScript, Lisp, Lua, Objective-C, OCaml, Perl, PHP, PL / SQL, Python, Ruby и Smalltalk	@-формулы, Lotus Script, Java, JavaScript
Кто изобрел	MongoDB, Inc	IBM	IBM
Масштабирование	Отличное	Хорошее	Нормальное

Таким образом, на основе данных в таблице 2.9 был сделан выбор в пользу MongoDB, так как важна масштабируемость, скорость и простота написания запросов, а также неструктурированность хранящихся в базе документов.

2.3.2 Выбор базы данных временных рядов

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

В качестве примеров наиболее распространенных баз данных временных рядов можно выбрать следующие:

ѕ Open TSDB;

ѕ InfluxDB;

ѕ MongoDB;

ѕ ClickHouse.

Далее выбранные примеры баз данных типа «временной ряд» сравнивались между собой с помощью ряда критериев, наиболее важных в исследовании (табл. 2.10) [16].



Таблица 2.10

Сравнительная таблица БД временных рядов

	InfluxDB	MongoDB	Open TSDB	ClickHouse
Пропускная способность на запись	0,9	0,36	0,55	1
Скорость запросов	1	0,13	0,83	0.67
Степень сжатия	1	0,15	0,18	0.56
Результат	2,9	0,64	1,56	2,23

В результате исследований ученых при проведении сравнения по выделенным критериям, больше всех баллов набрала InfluxDB. Это обозначает, что эта база данных временных рядов является самой оптимальной.

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

2.3.3 Выбор реляционной базы данных

Основой для разрабатываемого цифрового двойника будет реляционная база данных, так как данный тип баз данных предоставляет информацию в очень понятной форме: четко выделены сущности, определены связи между ними. Также в контексте разрабатываемой системы будет удобно, что основные сущности строго типизированы, что позволяют реализовать реляционные базы данных. Этим типом баз данных легко управлять, а также из-за своего длительного существования и наличия крупных популярных аналогов, данные базы стабильны и качественно поддерживаются. Для выбора наиболее подходящей СУБД (системы управления базами данных) были проанализированы следующие аналоги (самые распространенные и крупные):

ѕ Oracle;

ѕ MySQL.

Сравнительная таблица с выделенными критериями описана ниже (см. табл. 2.11).

Таблица 2.11

Сравнительная таблица РСУБД

	Oracle	MySQL
Исходный код	Коммерческая СУБД	Бесплатная СУБД с открытым исходным кодом
Специфика наименования	Много зарезервированных служебных слов, от которых нужно избавляться для корректной работы	Большинство из зарезервированных в Oracle слов можно использовать в SQL
Производительность	Из-за более сложной структуры данных показатели производительности ниже, чем у MySQL	Доступ по первичному ключу обеспечивает самую высокую производительность в сравнении с другими базами

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



3. Проектирование информационной модели умного города

На основе информации, проанализированной в предыдущих главах, необходимо спроектировать информационную модель. В контексте данной работы информационная модель - это база данных. Так как ранее в процессе описания объектов умного города, которые играют роль в выбранных бизнес-процессах, был сделан вывод о том, что будет 3 разных типа баз данных, каким-либо образом соединённых между собой, то результатом проектирования также будут 3 базы данных. В данной главе будут описаны способы соединения баз данных между собой.

3.1 Построение ER-диаграммы

В первую очередь необходимо понять, какие объекты будут в базе данных, а также как они будут взаимодействовать друг с другом. Для того, чтобы визуально представить на абстрактном уровне информационную модель умного города, была разработана ER-диаграмма. Entity-Relation диаграммы используются для обозначения сущностей и связей между ними, а также имеют удобную и интуитивно понятную логику. Для построения ER-диаграмм используются разные нотации. Одной из самых распространённых является нотация Баркера, именно в этой нотации была построена диаграмма (рис. 3.1) [19].



Рисунок 3.1 ER-диаграмма

Далее необходимо описать все используемые сущности и определенные между ними связи. Главной сущностью, которая была выделена на диаграмме, является объект умного города (Object). Под данной сущностью понимается любой объект умного города: здание, светофор, парк и т. д. Для того, чтобы все возможные объекты описать с помощью одной сущности, у неё должны были быть довольно абстрактные поля: тип объекта, широта и долгота, а также изображение объекта (опционально) и список необходимых для работы с этим объектом документов. Отдельно от основной сущности с объектом была выделена сущность здание (Building). Она является одним из типов объектов умного города, но вынесена в отдельную сущность, так как у здания должен быть уникальный набор полей - адрес. Для остальных объектов можно использовать просто широту и долготу. Также, как видно на диаграмме (см. рис. 3.1), выделена отдельная таблица «ObjectHasObject». Она нужна для описания связей между объектами умного города в случае, когда один их объектов является частью другого (пример - дом и квартира). Следующей важной сущностью, относящейся к сфере безопасности, является датчик (Sensor). Для датчика важны такие поля как: описание датчика, значение, а также документ, регламентирующий допустимые значения. Также было добавлено поле-индикатор, которое является бинарным и отвечает за необходимость вызова экстренных служб при достижении критического значения.

Была выделена отдельная сущность, отвечающая за типы организаций, существующие в здании - Organization. Данная сущность объединяет в себе все типы организаций, которые могут существовать в одном здании. Если типы организаций будут в будущем выделены в отдельные сущности, как в случае данной работы - ресторан и «арт-здание», эти сущность можно будет объединять с помощью сущности организация.

Ещё одна выделенная сущность - это ресторан (Restaurant). К данной сущности относятся все заведения общественного питания. Они выделены в отдельную сущность также потому, что у них присутствуют уникальные именно для этой сферы поля: рейтинг, средний чек, количество свободных мест, известные повара, работающие в ресторане, какие-либо выдающиеся блюда, по которым могут знать этот ресторан, самые популярные блюда. Также в данную сущность включены поля вебсайт, картинки (внутри, снаружи, фотографии меню или блюд) и часы работы.

Следующая выделенная сущность - здание, в котором показывают что-либо: спектакли, кино, выставки. Сущность была названа ArtBuilding. В эту сущность объединены кинотеатры, театры, выставочные центры, галереи, цирки и так далее. Для этой сущности были выделены следующие поля: рейтинг, вебсайт, картинки, рабочие часы. В отдельные сущности, связанными с ArtBuilding, были выделены мероприятия (Event) и представление (Performance). На примере кинотеатра связь этих сущностей можно определить следующим образом: кинотеатр, фильм, сеанс. Для мероприятия актуальны следующие поля: название, описание, рейтинг, кассовые сборы, картинки и вебсайт (бывает отдельный сайт для конкретного мероприятия, не привязанный к месту проведения). Для представления, как минимальной единицы мероприятия, выделены следующие поля: описание, дата начала и конца всего релиза (может отличаться в разных местах, поэтому выделено у представления, а не у мероприятия), а также дата и время самого представления, цена билета и количество свободных мест.

Ещё одной очень важной сущностью в базе данных является житель города, имеющий личный кабинет в системе (Citizen). Данная сущность связана с датчиками и со зданием. Для жителя города выделены следующие поля: логин и пароль от системы, фамилия, имя и отчество.

Как видно, на диаграмме (см. рис. 3.1) некоторые поля выделены цветами. В данном случае оранжевым цветом выделены поля, по которым должна быть связь с документо-ориентированной базой данных, а красным - связь с базой данных типа «временной ряд». В документо-ориентированной базе данных должны храниться необходимые для той или иной сущности документы. Например, это могут быть планировки квартир в строящемся доме - пользователь, который хочет купить в этом доме квартиру, может посмотреть эти планы и принять решение о покупке. Другим примером использования документо-ориентированной базы данных является определение критических значений датчиков, они также могут браться из нормативных актов, которые, в свою очередь, должны храниться в виде документов. Если же говорить о временных рядах, самым ярким примером будет значение датчика: значение этого показателя должно очень часто обновляться и передаваться в обработку. Ещё один пример - количество свободных мест, оно должно постоянно обновляться и также отправляться для анализа.

Далее необходимо описать отношения между сущностями. В первую очередь - связь между объектом города и зданием (см. рис. 3.2).



Рисунок 3.2 Отношение между объектом и зданием

Отношение между Building и Object видно на рисунке 3.2. Это отношение обозначает, что одному объекту может соответствовать одно или несколько зданий. Примером, когда одному объекту соответствует несколько зданий - торговый центр. Часто бывает, что торговый центр состоит из нескольких зданий с разными адресами, но они относятся к одному и тому же объекту. Также на рисунке 3.2 показана реализация связи двух объектов, в случае, когда один из них является составной частью другого (пример: дом - квартира). Связь аналогична связи «многие ко многим» и реализуется с помощью дополнительной таблицы «ObjectHasObject».



Рисунок 3.3 Связь объекта и датчика

На рисунке 3.3 показана связь объекта умного города с датчиком. Связь следующая: для одного объекта умного города обязательно существует хотя бы один датчик.

Рисунок 3.4 Связь объекта, датчика и жителя города

На рисунке 3.4 показана связь объекта, датчика и жителя города. Как видно, связь между жителем и объектом - многие ком многим, причем она необязательна. То есть каждому жителю может соответствовать от 0 до бесконечности объектов (житель может выбрать их для отслеживания показателей), а также каждому объекту может соответствовать от 0 до бесконечности жителей (за одним объектом может следить от 0 до бесконечности людей). Аналогично с датчиками: за одним датчиком может наблюдать от 0 до бесконечности людей, а один человек может наблюдать за любым количеством датчиков.



Рисунок 3.5 Связь здания и организации

На рисунке 3.5 показано, как связаны между собой здания и организации в них. Связь можно охарактеризовать как «одному зданию может соответствовать от 0 до бесконечности ресторанов). Связь между рестораном и поварами, интересными блюдами, а также самыми популярными блюдами - это связь один ко многим, причем необязательная.

Рисунок 3.6 Связь здания и ArtBuilding

Здание и ArtBuilding связаны между собой так же, как здание и ресторан (см. рим. 3.6). На данном рисунке также видна связь рисунков для всех объектов. Они все хранятся в одном месте, а объекты на них ссылаются необязательной связью один-ко-многим. Также на рисунке 3.6 видна связь ArtBuilding, мероприятия и представления. Можно увидеть, что с помощью таблицы Performance как бы реализована связь многие-ко-многим между ArtBuilding и Event. Одному ArtBuilding обязательно соответствует от 0 до бесконечности представлений и каждому мероприятию также соответствует хотя бы одно представление.

3.2 Проектирование базы данных

После построения ER-диаграммы и проанализировав её, необходимо спроектировать саму базу данных. В контексте данной работы база данных будет состоять из трёх баз: реляционной, документо-ориентированной и временных рядов. Основная часть данных будет храниться в реляционной базе данных. В качестве реляционной базы была выбрана самая популярная и распространённая база - SQL. В качестве базы данных временных рядов была выбрала InfluxDB, а в качестве документо-оринетированной - MongoDB.

3.2.1 Проектирование реляционной базы данных

Для построения реляционной базы данных использовался SQL Server и среда MS SQL Server Management Studio [19]. На основе описанной ранее ER-диаграммы были созданы таблицы для будущей базы данных (рис. 3.7).



Рисунок 3.7 Таблицы реляционной базы данных

Как видно, были созданы таблицы для всех основных сущностей, а также вспомогательные таблицы для реализации связи многие-ко-многим. Далее были созданы связи между таблицами - построена диаграмма базы данных. На рисунке 3.8 представлена полная диаграмма. Далее будут подробнее описаны все таблицы, а также связи между ними.

Как видно по рисунку 3.8, таблицы Building, Object, Citizen, Sensors, Restaurant, ArtBuilding, Showing и Event построены на основе таблиц-сущностей, которые были выделены на этапе анализа и построения ER-диаграммы. Остальные таблицы нужны как вспомогательные таблицы для реализации связи многие-ко-многим.



Рисунок 3.8 Диаграмма базы данных

Изначально была создана локальная база данных, однако для удобства использования несколькими людьми и проектирования приложения было принято решение разместить базу данных в облаке. Одной из самых распространённых и удобных облачных платформ является MS Azure, к её преимуществам относится сравнительно небольшая цена за подписку, поддержка почти всех существующих языков программирования, а также понятный интерфейс. Также в контексте данной работы преимуществом может быть то, что база данных построена также в продукте Microsoft - MS SQL Server Management Studio, а продукты одной компании обычно легко интегрированы друг с другом. Локальная база данных была выложена в Azure (см. рис. 3.9).

Рисунок 3.9 Свойства базы данных

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

3.2.2 Проектирование базы данных временных рядов

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

Рисунок 3.10 Начальная консоль для построения базы данных в InfluxDB

Для того, чтобы создать базу данных, необходимо использовать команду create database, а затем прописать имя для создаваемой базы. Так как в данном случае создается база для хранения значений датчиков, то название у неё будет «sensors» (рис. 3.11).

Рисунок 3.11 Создание базы данных sensors

Организация данных в InfluxDB отличается от структуры в реляционных базах данных. Данные в InfluxDB организованы в виде временного ряда, который содержит измеренные значения, например температура - “temperature”. Временной ряд содержит 0 или несколько точек, по одной на каждое значение измерения метрики. Каждая точка содержит время (timestamp), имя измерения или метрики (measurement), не менее одного поля (fields) в формате ключ-значения (например value=10), и 0 или несколько тегов (tags) в формате ключ-значение, которые содержат метаинформацию о собранном значении например, sensorID=”12345”). Соответственно, вся информация, которая будет храниться в виде временных рядов, будет загружена одновременно в одну и ту же базу данных, отличаться объекты будут набором тегов [20]. Для примеры были добавлены несколько значений температуры (рис. 3.12). По рисунку видно, что синтаксис очень важен, каждая запятая или пробел имеет значение, так как с их помощью база отличает элементы: measurement, fields, tags.

Рисунок 3.12 Некорректный и корректный пример ввода данных в базу

После ввода нескольких значений можно посмотреть, что именно содержится в базе (рис. 3.13). Для этого используется SQL-подобный язык запросов.



Рисунок 3.13 Просмотр существующих в базе значений

Как видно, поле time заполняется автоматически (см. рис. 3.12), оно не было введено при заполнении базы. Если провести аналогию с реляционными базами - данное поле является уникальным ключом. Если попробовать сейчас ввести какое-то значение для сенсора с уже имеющимся ID, то значение не перезапишется, так как ID сенсора никак нельзя задать ключевым (рис. 3.14). Ключевым всегда является дата-время, чтобы запись большого потока в базу была намного быстрее.

Рисунок 3.14 Добавление новой записи

Данное свойство временных рядов очень удобно, например, для отслеживания статистики. Например, измеряется температура окружающей среды. Для статистики необходимо посчитать среднее значение за весь день, для этого достаточно сделать запрос по нужному ID датчика, а также преобразовать timestamp и ограничить нужной датой и временем.

Были выделены следующие типы датчиков, значения которых должны храниться в базе (табл. 3.1). Перечисленные типы в базе данных будут отражены как measurement.

Таблица 3.1

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

Тип датчика	Measurement в БД	Описание
Температура окружающей среды	TempOutside	Температура окружающей среды (может быть использована приложениями для отображения погоды).
Температура помещения	TempInside	Температура помещения (может использоваться для проверки условий труда в офисах или просто для регулирования в умных домах).
Загазованность помещения	GasContamination	Загазованность помещения (может использоваться для предотвращения утечек газа в жилых домах или офисных помещениях).
Давление воздуха	AirPressure	Давление окружающей среды (для приложений погоды, а также для предупреждения метеозависимых людей).
Скорость ветра	WindSpeed	Скорость ветра (может использоваться для предотвращения или своевременной подготовки к катаклизмам, а также для предупреждения жителей).
Потребление электричества	ElectConsumption	Потребление электричества (может быть использовано для автоматического заполнения счетов, а также просто для отслеживания жителями).
Загрязнение воздуха	AirPollution	Уровень загрязнения воздуха (для своевременного реагирования и регулирования ситуации с точки зрения экологии).
Потребление воды	WaterConsumption	Потребление воды (может быть использовано для автоматического заполнения счетов, а также просто для отслеживания жителями).
Освещение рабочего места	WorkplaceLighting	Освещение рабочего места (должно регулироваться в соответствии с трудовым законодательством).
Шум вокруг	Noise	Шум на рабочем месте (также должен регулироваться в соответствии с трудовым законодательством). Также сюда может быть отнесён шум в жилых домах для автоматического реагирования правоохранительных органов.
Влажность воздуха	HumidityOutside	Влажность воздуха (может быть использована приложениями погоды).
Влажность помещения	HumidityInside	Влажность внутри помещения (должна регулироваться трудовым законодательством для офисов, а также может быть важна при своевременном реагировании на потопы в жилых зданиях).

В виде временных рядов хранится не только информация по значению датчиков. На ER-диаграмме видно, что так же должны храниться количество свободных мест в ресторанах и количество оставшихся билетов на то или иное мероприятие. Поэтому были выделены также следующие measurements (табл. 3.2).

Таблица 3.2

Другие показатели, необходимые для хранения в виде временных рядов

Поле	Measurement в БД	Описание
Количество билетов	NumberOfTickets	Количество купленных билетов на мероприятие.
Количество свободных мест	EmptyTables	Количество свободных мест в ресторане или кафе.

Чтобы заполнить InfluxDB, существуют разные способы. Например, можно использовать загрузку из csv-файла или из сторонней системы.

3.2.3 Проектирование документо-ориентированной базы данных

На ER-диаграмме (см. рис. 3.1) видно, что помимо реляционной базы данных и базы данных временных рядов, для построения полной модели обмена данными внутри умного города необходимо также использовать базу документо-ориентированную базу данных. Ранее в данной работе был проведён сравнительный анализ разных инструментов для работы с этим типом баз данных. На основе выбранных критериев была определена используемая в работе база - MongoDB.

Для того, чтобы начать работать с этой базой данных, необходимо было скачать с официального сайта архив и установить его [21]. После чего, чтобы начать работу с самой базой данных нужно выполнить следующие шаги:

1. Создать на диске C папку «data», а в ней - ещё одну папку «db».

2. Запустить в командной строке файл mongod.exe и не закрывать это окно командной строки до конца работы с базой.

3. Запустить в командной строке файл mongo.exe и не закрывать это окно командной строки до конца работы с базой. Именно в этом окне командной строки будет происходить работа по созданию, редактированию и наполнению базы данных.

Однако помимо создания базы данных через командную строку существует более удобный и понятный пользователю способ. Работать с MongoDB удобно через приложение MongoDB Compass Community. Для того, чтобы создать базу, необходимо открыть приложение и добавить новую базу данных (рис. 3.15):

Рисунок 3.15 Создание базы данных через MongoDB Compass Community

В отличие от реляционной базы данных, в MongoDB данные хранятся не в виде табличек. Для каждого объекта, информацию о котором необходимо хранить в базе данных, создается коллекция. Как следует из рисунка 3.1, в данной базе необходимо хранение следующих объектов: Pictures (рисунки, фотографии, изображения, которые будут использоваться для предоставления пользователю дополнительную информацию о том или ином объекте), Documents (необходимые для более полного представления об объекте документы, в данном случае отличие от рисунков в том, что к Documents будут относиться более формальные документы: например, нормативно-правовые акты), а также - LegalActs для датчиков (нормативно-правовые акты, содержащие в себе информацию о нормах значений датчиков). Исходя из представленной выше информации, для базы данных были созданы 3 коллекции (рис. 3.16).

Рисунок 3.16 Созданные коллекции в MongoDB

Добавление документов в коллекции

Для примера, в базу был добавлен документ. Как видно на рисунке 3.17, объект был добавлен в коллекцию Documents и содержит 2 поля: имя и адрес. В данном примере в документе содержится информация о каком-либо жителе.



Рисунок 3.17 Добавление документа в коллекцию Documents

В результате работы кода в базе данных SmartCity в коллекции Documents появляется документ с 3 полями (рис. 3.18): имя, адрес и id (автоматически генерируемый уникальный ключ).

Рисунок 3.18 Добавлен новый документ в коллекцию Documents

Описанным выше образом в коллекции Documents и LegalActs могут быть записаны данные. Однако третья созданная коллекция (Pictures) отличается от этих двух коллекций, так как в ней хранятся исключительно изображения. Для работы с изображениями в MongoDB существует специальный инструмент.

Для MongoDB существуют различные спецификации, которые позволяют более гибко использовать данный инструмент и удобнее хранить разную информацию. Применимо к разрабатываемой базе данных, можно использовать спецификацию GridFS, которая поможет работать с изображениями. GridFS позволяет хранить большие файлы изображений, размер которых превышает предельный размер документа BSON - 16 Мегабайт. Удобство данного инструмента в том, что вместо того, чтобы хранить файл в одном документе, GridFS делит файл на части или части и сохраняет каждый фрагмент как отдельный документ. По умолчанию GridFS использует размер фрагмента 255 КБ, то есть GridFS делит файл на фрагменты размером 255 КБ, за исключением последнего фрагмента. Последний кусок только настолько большой, насколько это необходимо [21]. Использовать GridFS можно двумя способами: с помощью драйвера MingoDB и с помощью инструмента mongofiles командной строки mongo в оболочке. Записать данные в MongoDB можно разными способами, используя разные языки программирования, например, Python. Ниже на рисунке 3.19 показан код добавления в созданную базу SmartCity в коллекцию Pictures элемент cinema_perm.jpg. Для примера файл был импортирован с локального компьютера.



Рисунок 3.19 Добавление картинки как элемент коллекции Pictures

В результате в базе создались 2 файла, один из которых отвечает за метаданные файлов, а другой - за само содержание файлов (рис. 3.20).

Рисунок 3.20 Созданные файлы в MongoDB

Как было описано выше, особенность GridFS в том, что этот инструмент делит файлы на несколько частей. Поэтому несмотря на то, что был загружен только один файл, в папке Pictures.files созданы 2 объекта (рис. 3.21).



Рисунок 3.21 Объекты в Pictures.files

ID объектов формируется автоматически при попадании файла в базу. Однако этот ID можно задат...