Берём в работу новую задачу или проект. Начинаем со сбора бизнес-требований. Затем переходим к проработке функциональных и нефункциональных требований. Потом архитектура системы и влияние требований на нее, БД, API, интеграции. И вот, в процессе разработки выясняется, что в требованиях опять что-то не учли. Что может быть хуже?

Может, коллеги! Когда через пол года вам же приходится возвращаться к задаче и вы понимаете, что требования к развитию системы по словам разработчиков нереализуемы. Или реализуемы, но они кривят лица: мы этого не ожидали, проще всё с нуля переделать, либо "костылями подопрем".

Меня, как начинающего системного аналитика, это выводило из себя. Как так?! Элементарная же задача! А потом мне показывают БД. И тут я всё понимаю. Да, действительно, пришло время делать выбор: дорого переделывать или "костыли" подойдут.

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

В этой статье:

1. Как в разработке систем возникают ситуации "костыли" или "переделываем", и почему обычно это связано с непродуманной структурой БД.

2. Как проектирование БД на ранних стадиях работы с проектом влияет на качество требований.

3. Дам пошаговый план проектирования БД.

4. SQL-запросы: почему нужно уметь читать.

"Костылями" подпираем или переделываем?

1. Рассмотрим ситуацию с хранением ФИО в системе.

Изначально было решено хранить ФИО одной строкой.

Прошло время. Появилась необходимость интегрироваться с системами электронного документооборота (ЭДО), в которых по единому информционному протоколу это всегда три отдельных поля: имя, отчество и фамилия.

Кажется, что всё просто. Но нет.

Это простое изменение породило множество сложностей:

1. Создание алгоритма деления строки на части, который не для всех случаев с отчеством "Гаджи оглы" хорошо отработают.

2. Модификация API-методов. Минимум 1, максимум - все, если данные ФИО этой роли в системе везде.

3. Изменение пользовательского интерфейса (UI) всех мобильных и веб-приложений, где есть ФИО, и доработка взаимодействия по API с сервером.

4. Доработка существующих интеграций.

Все эти изменения были нужны лишь из-за одной "маленькой" новой функции! Моя боль об этом записана в этом видео с конференции.

2. Еще один пример - думали, что у машины может быть только один владелец в автосервисе.

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

Структура БД меняется: для правильного поддержания процесса нужна связь "многие ко многим". И в одну задачу это изменение не сделать.

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

Простые изменения и требования? Да, если подумать логически, на верхнем уровне. Но из-за того, что "под капотом" системы огромный мир данных и механизмов по их хранению, получению и обработке, то иногда мы попадаем на серьезные работы по развитию.

Так и получается, что мы с разработчиками садимся обсуждать: проще сделать "костыли" или лучше переделать с нуля сейчас, чтобы через год опять не пожалеть о принятом решении.

Важно учиться искать баланс и на старте работ найти грань: не допустить овер-инжиниринга, и при этом сделать модель БД гибкой. Это нужно постигать.

База данных - фундамент системы

БД — это фундамент системы, который влияет на реализацию всех требований. Все бизнес-процессы и функции сводятся к одному – обработке данных.

Каждое действие, каждый клик — это запрос к базе данных. И в этой базе данных хранятся сведения, которые предстоит собирать и обрабатывать, чтобы обеспечиать выполнение бизнес-процессов и функций в ней.

Базовые определения и примеры, прежде чем читать далее

Сущности — реальные объекты этого мира. Например: стол, стул, машина, тарелка, цветок и другие.

Свойства (атрибуты) — характеристики сущностей, которые для каждого из объектов сущностей могут быть уникальны.

Например:- машина - сущность.- Tesla Model X 2023 г., Porsche 911 2023 г., Toyota Camry 2022 - конкретные объекты сущности "машина". - цвет, производитель, модель, год, объем двигателя - свойства (атрибуты) сущности "машина".

ER-диаграмма (Entity-Relationship) — графическое представление сущностей БД и связей. Нотация моделирования баз данных.

Пример про медицинскую систему

Рассмотрим медицинскую информационную систему для частной поликлиники.

1. Пациент хочет сделать запись на прием онлайн: система отображает пациенту данные о доступных услугах, врачей и время для записи.

2. Пациент записывается на прием: система обрабатывает информацию о пациенте, докторе, времени приема, кабинете.

3. Регистратура звонит пациенту и подтверждает запись на прием: система меняет в базе данных статус записи с "новая" на "подтверждена".

4. Когда пациент приходит на прием, то в регистратуре делают отметку о том, что пациент ожидает - опять смена статуса.

5. И это только начало! Процессов в поликлинике много, особенно связанных с приемом пациента :)

Мы, как аналитики, должны продумать все сценарии, связанные с записью пациента к врачу.

Мне в этом плане особенно нравится устаревшая нотация моделирования IDEF0, потому что она не только отражает все шаги процесса, но и показывает какие входные и выходные данные нужны для реализации каждого их них.

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

Прежде чем смотреть что получилось, попробуйте сами быстро выделить список сущностей и свойств. Совпадём?

Проверка требований на полноту и непротиворечивость с помощью проектирования БД

Заметили, что в тексте я выделила жирным отдельные слова? Это я, каждый раз работая с требованиями, повторяю одну и ту же процедуру:

• Выделяю слова в тексте, обычно двумя цветами: сущности и их свойства.

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

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

  Глядя на список таблиц, дополняю их свойствами на основе вопросов к Google, ChatGPT с 2023 года и жизненного опыта. Всё, что вызывает вопросы, выношу на обсуждение с владельцем IT-продукта (заказчиком) о хранении информации про его бизнес сущности.

• Теперь можно строить связи и проставлять кратности (полезная картинка по кратностям). Т.к. требования я уже написала и прочитала (и выучила), то делаю это интуитивно.

  Если вы будете пользоваться моей стратегией, то лучше читать требования еще раз и проставлять связи.

• На ER-диаграмме ищу связи "многие-ко-многим" и убираю их. Дополняю БД внешними ключами, где их нет. Довожу до состояния полноценной логической модели данных, иногда даже сразу до физической.

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

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

Системный аналитик должен смотреть на систему в трех измерениях:
- как работает сейчас (AS IS),
- что просят сделать (текущие требования на разработку),
- во что это может перерасти в будущем (потенциальное развитие).
Это поможет сделать разработку качественной.

Екатерина Ананьева :)

Что получилось после чтения требований? Логическая модель базы данных, связанной с задачей. На её основе ставлю задачи на разработчиков Backend, а также разработчикам мобильных и десктоп приложений, когда нужно сделать локальную базу данных, например, на SQLite.

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

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

Результат:

• требования полные,

• меньше вопросов от разработчиков,

• система масштабируема и спроектирована с учетом потенциального развития.

Этап проектирования БД важен для системных и бизнес-аналитиков. Не игнорируйте его.

Пошаговый план проектирования БД

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

2. Спроектировать логическую модель данных - ER-диаграмма:

   1. таблицы (сущности),

   2. поля (свойства),

   3. связи между таблицами,

   4. кратности связей между таблицами.

   Связи типа "многие-ко-многим" убрать.
   *Дополнительно, перед логической, можно сделать концептуальную, но она не всегда имеет практическую ценность.

3. Прочесть требования еще раз и проверить, что всех данных хватает.
   Недостающие данные дополнить на основе Google, ChatGPT, доступных документов и вопросов заказчику.

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

5. Ставить задачи на разработчиков по их созданию, выстраивая последовательность и зависимости. Часто задачи можно делать параллельно нескольким разработчикам.

SQL для системных аналитиков

Для системного аналитика, владение SQL не просто "буквы для резюме", это ключевой навык, который:

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

2. Позволяет понимать язык разработчиков и что "под капотом" системы.
   Когда аналитик знает, как устроена база данных, он может разрабатывать требования, учитывающие эту структуру, что уменьшает количество ошибок и доработок в дальнейшем. То же, что и с умением проектировать БД.

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

4. Позволяет с ходу оценивать реализуемость требований.
   Зная SQL, аналитик может сразу определить, насколько реализуемы требования, которые предлагает заказчик, и как они повлияют на производительность и структуру БД.

Знание SQL позволяет понимать, что происходит на встречах с разработчиками и какие технические детали они обсуждают. Даже знания базовых операторов как SELECT, WHERE, IF, JOIN уже многое дает. А когда речь идет о проектах с несколькими БД, то он лучше понимает последовательные цепочки запросов, обеспечивающие синхронизацию данных.

Заключение

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

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

Из рекомендаций, что почитать и посмотреть по проектированию БД:

1. Книга: Технологии проектирования баз данных. Д. Л. Осипов.

2. Практический вебинар (видео): Проектирование БД: с чего начать.

3. Практический урок (видео): на проекте для автосервиса показывала, как сделать БД на логическом уровне.

4. Гайд по проектированию БД и SQL с помощью ChatGPT. Полезно, когда хочешь сделать свой демо-проект для портфолио или устал писать SQL-запросы сам.

5. Проект по проектированию БД Зоомагазина в моем канале - разбор с нуля, первое сообщение.

По SQL:

1. Бесплатный тренажер Stepic.

Инструменты:

1. DBeaver. Особенно, если надо подключиться к БД и посмотреть ER-диаграмму на существующей базе.

БД - не сложно. Особенно, если на практике освоить все правила!