Моделирование данных: что это и зачем нужно

Информационные системы собирают, обрабатывают и хранят разные данные. Например, с помощью ПО для кадрового документооборота сотрудники могут создавать запросы вроде заявок на отпуск, кадровые специалисты — обрабатывать эти запросы и формировать кадровые приказы, руководители подразделений — согласовывать и подписывать их. Пользователи, запросы, порядок их обработки, документы и действия с ними — всё это данные системы.

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

Моделирование данных проводят не только перед стартом нового проекта по разработке ПО. Если нужно улучшить существующую систему, например, изменить этапы обработки данных или добавить новую таблицу в базу, где они хранятся, — тоже строят модель. Чем сложнее структура системы или базы, тем важнее построить модель данных до начала работы с ней.

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

Моделирование в системном анализе — неотъемлемая часть работы с данными. Вот чем могут помочь правильно составленные модели данных:

✔️Определить структуру информационной системы
С помощью моделирования данных можно понять, как именно должна работать будущая система. Например, выяснить, какие типы данных будут поступать в систему и на каких этапах, а потом передать в разработку нужную для их обработки функциональность.

✔️Взаимодействовать с коллегами и заказчиками
Моделирование данных помогает системному аналитику перевести требования бизнеса на язык разработки. Разработчики видят чёткую схему, какую систему нужно создать. Это ускоряет процесс работы и уменьшает количество ошибок. При этом модели данных обычно понятны и заказчикам со стороны бизнеса. С их помощью можно наглядно показать, как будет работать система, что упрощает согласование технических требований.

✔️Улучшить работу системы
Моделирование данных помогает системному аналитику находить проблемные участки в работе системы. Например, руководителям подразделений приходится распечатывать листы согласований приказов на отпуск, ставить подпись и загружать скриншот документа в программу для кадрового документооборота. Это затягивает процесс и каждый раз создаёт в системе лишний артефакт.

При анализе модели можно найти проблему и передать в разработку требование доработать систему. К примеру, добавить в интерфейс программы кнопку «Согласовать», чтобы ускорить обработку запросов сотрудников и повысить производительность системы.

✔️Стандартизировать работу с данными в компании
Готовые модели данных можно использовать для создания инструкций для пользователей по работе с новым ПО или базой данных.

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

1. Концептуальный
Это первый уровень моделирования данных с абстрактным представлением будущей системы. Системный аналитик определяет предметную область системы и её основные элементы — сущности. Например, в сервисе для записи к врачу будут элементы: «Пациент», «Поликлиника», «Отделение», «Врач», «Дата приёма».

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

На этом уровне системный аналитик работает в команде с разработчиком или архитектором ПО.

3. Физический
Физическая модель данных показывает, как будет организована работа с данными: как они будут собираться, где и в каком виде храниться и как обрабатываться. На этом уровне определяют архитектуру ПО, тип и структуру базы данных, систему для управления ею.

Проектирование физической модели данных тоже находится в зоне ответственности системного аналитика. На этом этапе он работает совместно с разработчиками и архитектором ПО.

Модели разных уровней нужны для разных целей.

Кроме уровней есть разные виды моделей данных. Их очень много. Системные аналитики выбирают вид модели в зависимости от целей и задач бизнеса и требований к системе. Разберём несколько моделей, которые часто применяют на практике:

● Иерархическая модель данных представляет систему с данными как иерархию элементов: наверху — элемент первого уровня, ему «подчинены» элементы второго уровня, элементам второго — элементы третьего и так далее. При этом элементы одного уровня не связаны между собой.

Пример подобной иерархии — оргструктура компании, где элемент первого уровня — руководитель, элементы второго уровня — его заместители, третьего — начальники курируемых ими отделов, четвертого — сотрудники. Данные могут быть представлены в виде иерархической модели, например, в файловой системе.

Иерархическая модель данных похожа на перевёрнутое дерево

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

Сущности и связи между ними визуально выглядят как сеть, отсюда и название вида моделей

● Реляционная модель данных представляет данные в виде связанных между собой таблиц. В таблицах есть строки, или записи, и столбцы, или поля. На их пересечении — значения данных. Например, база данных для кадрового учёта компании может состоять из нескольких таблиц. В одной собраны персональные данные сотрудников, во второй — данные о занимаемых позициях, в третьей — об использованных отпусках.

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

Моделирование данных можно провести в пять этапов:

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

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

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

4. Проверить модель
Аналитик нормализует модель данных — убирает составные данные и дубликаты, проверяет, нет ли косвенных связей, и добавляет уникальные ключи для идентификации записей в базе.

5. Подготовить техническую документацию
Прежде чем передать модель данных дальше в разработку, системный аналитик документирует её структуру и логику. Это пригодится не только на этапе создания ПО, но и в дальнейшем: на основе документации можно дорабатывать и улучшать систему.

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

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

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

● Erwin Data Modeler — программа для проектирования баз данных и создания ER-диаграмм. Инструмент поддерживает работу со многими популярными системами управления базами данных, например, MySQL и PostgreSQL. После создания модели данных можно подключиться к базе и автоматически создать нужные таблицы. У программы есть бесплатная версия с ограниченной функциональностью — ERwin Data Modeler Community Edition.

● ER/Studio Data Architect — приложение для проектирования и визуального моделирования баз и хранилищ данных. С помощью приложения можно создавать ER-диаграммы в разных нотациях для графического представления баз данных разных типов, в том числе реляционных. Приложение поддерживает интеграцию метаданных из хранилищ данных и BI-платформ.

● Enterprise Architect — платформа для моделирования бизнес-процессов, организационной структуры компании и информационных систем. На платформе есть набор UML-инструментов. UML (от англ. Unified Modeling Language) — это стандартизированный язык для визуализации сложных структур и процессов. Например, с помощью UML можно графически представить последовательность этапов обработки данных системой. UML знают многие IT-специалисты, поэтому чаще всего разработчики без труда поймут модель.