Берём в работу новую задачу или проект. Начинаем со сбора бизнес-требований. Затем переходим к проработке функциональных и нефункциональных требований. Потом архитектура системы и влияние требований на нее, БД, API, интеграции. И вот, в процессе разработки выясняется, что в требованиях опять что-то не учли. Что может быть хуже? Может, коллеги! Когда через пол года вам же приходится возвращаться к задаче и вы понимаете, что требования к развитию системы по словам разработчиков нереализуемы. Или реализуемы, но они кривят лица: мы этого не ожидали, проще всё с нуля переделать, либо "костылями подопрем". Меня, как начинающего системного аналитика, это выводило из себя. Как так?! Элементарная же задача! А потом мне показывают БД. И тут я всё понимаю. Да, действительно, пришло время делать выбор: дорого переделывать или "костыли" подойдут. Один раз столкнувшись с такой ситуацией, больше не хочется оставлять без внимания базу данных. Даже если проектирование БД в компании находится в зоне ответственности разработчиков. В этой статье: Как в разработке систем возникают ситуации "костыли" или "переделываем", и почему обычно это связано с непродуманной структурой БД. Как проектирование БД на ранних стадиях работы с проектом влияет на качество требований. Дам пошаговый план проектирования БД. SQL-запросы: почему нужно уметь читать. Главное отличие системного аналитика от других участников проекта заключается в его способности смотреть широко. Работая над конкретной задачей, аналитик видит не только её, но и весь проект в целом, как он функционирует сейчас и как будет развиваться в будущем. 1. Рассмотрим ситуацию с хранением ФИО в системе.  Изначально было решено хранить ФИО одной строкой.  Прошло время. Появилась необходимость интегрироваться с системами электронного документооборота (ЭДО), в которых по единому информционному протоколу это всегда три отдельных поля: имя, отчество и фамилия.  Кажется, что всё просто. Но нет. Это простое изменение породило множество сложностей:  Создание алгоритма деления строки на части, который не для всех случаев с отчеством "Гаджи оглы" хорошо отработают.  Модификация API-методов. Минимум 1, максимум - все, если данные ФИО этой роли в системе везде.  Изменение пользовательского интерфейса (UI) всех мобильных и веб-приложений, где есть ФИО, и доработка взаимодействия по API с сервером. Доработка существующих интеграций.  Все эти изменения были нужны лишь из-за одной "маленькой" новой функции! Моя боль об этом записана в этом видео с конференции. 2. Еще один пример - думали, что у машины может быть только один владелец в автосервисе.  Проблемы со связями в базах данных. Сначала была связь "один ко многим", где у одной машины был один владелец, и у одного владельца много машин. Но со временем эксплуатации системы в продакшн оказалось нормальной ситуацией, что иногда два человека приезжают обслуживать одну машину. Иногда даже три.  Структура БД меняется: для правильного поддержания процесса нужна связь "многие ко многим". И в одну задачу это изменение не сделать.  Важно проработать цепочку задач, которые обеспечат совместимые изменения. Если хорошо не продумать порядок перехода к новой структуре хранения данных, то можно встретить огромное количество ошибок по функциональности всей системы, так как машина и клиент главные сущности в системе автосервиса. Простые изменения и требования? Да, если подумать логически, на верхнем уровне. Но из-за того, что "под капотом" системы огромный мир данных и механизмов по их хранению, получению и обработке, то иногда мы попадаем на серьезные работы по развитию. Так и получается, что мы с разработчиками садимся обсуждать: проще сделать "костыли" или лучше переделать с нуля сейчас, чтобы через год опять не пожалеть о принятом решении. Важно учиться искать баланс и на старте работ найти грань: не допустить овер-инжиниринга, и при этом сделать модель БД гибкой. Это нужно постигать. БД — это фундамент системы, который влияет на реализацию всех требований. Все бизнес-процессы и функции сводятся к одному – обработке данных. Каждое действие, каждый клик — это запрос к базе данных. И в этой базе данных хранятся сведения, которые предстоит собирать и обрабатывать, чтобы обеспечиать выполнение бизнес-процессов и функций в ней. Сущности — реальные объекты этого мира. Например: стол, стул, машина, тарелка, цветок и другие. Свойства (атрибуты) — характеристики сущностей, которые для каждого из объектов сущностей могут быть уникальны.  Например:- машина - сущность.- Tesla Model X  2023 г., Porsche 911 2023 г., Toyota Camry 2022 - конкретные объекты сущности "машина". - цвет, производитель, модель, год, объем двигателя - свойства (атрибуты) сущности "машина". ER-диаграмма (Entity-Relationship) — графическое представление сущностей БД и связей. Нотация моделирования баз данных.  Рассмотрим медицинскую информационную систему для частной поликлиники.  Пациент хочет сделать запись на прием онлайн: система отображает пациенту данные о доступных услугах, врачей и время для записи. Пациент записывается на прием: система обрабатывает информацию о пациенте, докторе, времени приема, кабинете.  Регистратура звонит пациенту и подтверждает запись на прием: система меняет в базе данных статус записи с "новая" на "подтверждена". Когда пациент приходит на прием, то в регистратуре делают отметку о том, что пациент ожидает - опять смена статуса. И это только начало! Процессов в поликлинике много, особенно связанных с приемом пациента :) Мы, как аналитики, должны продумать все сценарии, связанные с записью пациента к врачу.  Мне в этом плане особенно нравится устаревшая нотация моделирования IDEF0, потому что она не только отражает все шаги процесса, но и показывает какие входные и выходные данные нужны для реализации каждого их них.  В результате прочтения требований к медицинской системе, получаю список сущностей и свойств - основа для логической модели БД.  Прежде чем смотреть что получилось, попробуйте сами быстро выделить список сущностей и свойств. Совпадём? Пациент: Человек, который обращается в поликлинику для получения медицинской услуги. ФИО,  контактная информация,  история болезни,  и так далее. Услуга: Конкретное медицинское вмешательство или процедура, доступная для предоставления пациентам. название,  описание,  продолжительность,  стоимость. Врач: Медицинский специалист - сотрудник поликлиники, предоставляющий конкретные услуги. ФИО,  специализация,  график работы,  кабинет. Запись на прием: Информация о планируемом визите пациента к врачу. дата и время визита,  пациент,  врач, статус записи (новая, подтверждена, пациент ожидает и т.д.),  кабинет. Кабинет: Помещение, где врачи принимают пациентов. номер кабинета,  этаж,  врач(и), которые в нем принимают. Регистратура: Описание: Отдел или персонал поликлиники, ответственный за прием и регистрацию пациентов, а также подтверждение записей на прием. Атрибуты: Сотрудники регистратуры, контактная информация, график работы. Статус записи: Состояние, в котором находится запись на прием в данный момент. новая,  подтверждена,  пациент ожидает,  завершена, и т.д. Более подробный пример можно будет почитать в моем канале, начиная с этого поста. Заметили, что в тексте я выделила жирным отдельные слова? Это я, каждый раз работая с требованиями, повторяю одну и ту же процедуру: Выделяю слова в тексте, обычно двумя цветами: сущности и их свойства. Т.к. я за ускорение процесса, то выделяю слова мысленно и сразу же начинаю строить ER-модель базы данных на логическом уровне: создаю список таблиц (сущностей в базе данных) и добавляю в них свойства. После того, как таблицы созданы, проверяю, всё ли логично и всего ли хватает. Обычно, в процессе такой проверки, я понимаю, что половина данных в описании бизнес-процесса упущена, т.к. в их описании такой уровень детализации не требовался.  Глядя на список таблиц, дополняю их свойствами на основе вопросов к Google, ChatGPT с 2023 года и жизненного опыта. Всё, что вызывает вопросы, выношу на обсуждение с владельцем IT-продукта (заказчиком) о хранении информации про его бизнес сущности. Теперь можно строить связи и проставлять кратности (полезная картинка по кратностям). Т.к. требования я уже написала и прочитала (и выучила), то делаю это интуитивно.  Если вы будете пользоваться моей стратегией, то лучше читать требования еще раз и проставлять связи. На ER-диаграмме ищу связи "многие-ко-многим" и убираю их. Дополняю БД внешними ключами, где их нет. Довожу до состояния полноценной логической модели данных, иногда даже сразу до физической. Тестирую требования: беру каждую функцию в системе и проверяю, как она будет работать с моей базой данных на запись и получение данных.Если я могу простыми словами объяснить разработчику в какие таблицы писать данные или из каких забирать, то всё хорошо. А если нет, то плохо. Проверяю масштабируемость: смотрю на список запланированных задач на следующих этап разработки или придумываю потенциально возможные сценарии к реализации. Здесь важно не фантазировать о чём-то невозможном, а продумать, что в ближайшие 3-5 лет работы системы вообще возможно по функциональности и в целом может уже работает в отрасли в других системах, у конкурентов.Не всегда можно всё предугадать, но как правило, эта проверка на потенциальное будущее поднимает новые вопросы на обсуждение с владельцем IT-продукта (заказчиком) о потенциальном развитии проекта. Системный аналитик должен смотреть на систему в трех измерениях: - как работает сейчас (AS IS), - что просят сделать (текущие требования на разработку), - во что это может перерасти в будущем (потенциальное развитие).Это поможет сделать разработку качественной.Екатерина Ананьева :) Что получилось после чтения требований? Логическая модель базы данных, связанной с задачей. На её основе ставлю задачи на разработчиков Backend, а также разработчикам мобильных и десктоп приложений, когда нужно сделать локальную базу данных, например, на SQLite. Этот пример подхода был для проекта с нуля. Также можно работать с существующей базой данных в вашем проекте и смотреть, как новые требования повлияют на неё, какие задачи по её изменению поставите на разработчиков. Этот подход помогает не упускать из требований важные детали, и до передачи работ разработчикам сразу же собрать полные требования по системе, а иногда даже увидеть противоречивые.  Результат:  требования полные,  меньше вопросов от разработчиков,  система масштабируема и спроектирована с учетом потенциального развития.  Этап проектирования БД важен для системных и бизнес-аналитиков. Не игнорируйте его. После завершения работы над описанием бизнес-процессов или требований, прочесть их и выделить по тексту список сущностей (таблиц БД) и свойств (полей таблиц). Спроектировать логическую модель данных - ER-диаграмма: таблицы (сущности),  поля (свойства), связи между таблицами, кратности связей между таблицами. Связи типа "многие-ко-многим" убрать.*Дополнительно, перед логической, можно сделать концептуальную, но она не всегда имеет практическую ценность.  Прочесть требования еще раз и проверить, что всех данных хватает.Недостающие данные дополнить на основе Google, ChatGPT, доступных документов и вопросов заказчику. Дополнить логическую модель требованиями к типам данных, обязательности, уникальности, значениям по умолчанию и индексам свойств таблиц. Получена физическая модель БД. Ставить задачи на разработчиков по их созданию, выстраивая последовательность и зависимости. Часто задачи можно делать параллельно нескольким разработчикам. Для системного аналитика, владение SQL не просто "буквы для резюме", это ключевой навык, который: Усиливает логическое мышление. SQL требует строгого и последовательного подхода к структурированию данных. Такой подход улучшает логические навыки, что в свою очередь помогает быстрее и точнее анализировать требования. Позволяет понимать язык разработчиков и что "под капотом" системы. Когда аналитик знает, как устроена база данных, он может разрабатывать требования, учитывающие эту структуру, что уменьшает количество ошибок и доработок в дальнейшем. То же, что и с умением проектировать БД. Помогает обращать внимание на "узкие места" в системе, где важно продумать нефункциональные требования по нагрузке, ограничения.Понимая, как устроен запрос и какие ресурсы он потребляет, можно заранее предусмотреть необходимые ограничения.  Позволяет с ходу оценивать реализуемость требований. Зная SQL, аналитик может сразу определить, насколько реализуемы требования, которые предлагает заказчик, и как они повлияют на производительность и структуру БД. Знание SQL позволяет понимать, что происходит на встречах с разработчиками и какие технические детали они обсуждают. Даже знания базовых операторов как SELECT, WHERE, IF, JOIN уже многое дает. А когда речь идет о проектах с несколькими БД, то он лучше понимает последовательные цепочки запросов, обеспечивающие синхронизацию данных. Навык проектирования БД и понимание SQL-запросов выводит качество требований и постановок задач от аналитика на новый уровень. С его знанием аналитик точно осознает к каким техническим задачам ведет очередное бизнесовое требование. Кстати, для менеджеров проектов это тоже полезно. В итоге аналитик ставит не одну общую задачу на "поменяйте на форме одно поле на три", а одну на бэкенд-разработчика по изменению БД, еще одну на изменение одного API-метода, и еще одного API-метода, и существующей интеграции, использующей это поле, и мобильных приложений, и т.д. Из рекомендаций, что почитать и посмотреть по проектированию БД: Книга: Технологии проектирования баз данных. Д. Л. Осипов. Практический вебинар (видео): Проектирование БД: с чего начать.  Практический урок (видео): на проекте для автосервиса показывала, как сделать БД на логическом уровне. Гайд по проектированию БД и SQL с помощью ChatGPT. Полезно, когда хочешь сделать свой демо-проект для портфолио или устал писать SQL-запросы сам. Проект по проектированию БД Зоомагазина в моем канале - разбор с нуля, первое сообщение. По SQL: Бесплатный тренажер Stepic. Инструменты: DBeaver. Особенно, если надо подключиться к БД и посмотреть ER-диаграмму на существующей базе. БД - не сложно. Особенно, если на практике освоить все правила!  Основатель сообщества аналитиков GetAnalyst