Comments 6
Фундамент любой системы это бизнес процессы, которые она автоматизирует
В несложных приложениях мб и можно аналитику проектировать бд, но это не его работа и у него нет квалификации.
Вариантов много, начиная от некорректного выбора самой СУБД, например у нас большое кол-во операций записи(или чтения), или требования к распределенному кластеру, или жесткий лимит по времени ответа на выполнения запроса. Но предположим ок, взяли СклСервер/ПГ и вроде даже норм, но теперь проблемы с перфомансом, схемы слишком нормалтхированны. Или монолитная БД теперь бьется на 1 бд на 1 сервис. Да и даже самый банальный кейс, что таблица в бд не равно бизнес сущности
Аналитик формализует бизнес требования, если много интеграций то мб описывает аналитику по входящим/исходящим данным.
Проблемы с тем, что в будущем доработка стоит слишком дорого решает этап проектирования, кто его будет делать(архитектор, техлид, сто, сеньор) выбор каждой компании/команды. И для успешной реализации этого этапа, нужны сформулированные и описанные бизнес кейсы, а не "схема БД"
Неправильно однозначно сопоставлять сущность и таблицу.
1. После завершения работы над описанием бизнес-процессов или требований, прочесть их и выделить по тексту список сущностей (таблиц БД) и свойств (полей таблиц).
На этом же этапе необходимо выполнить анализ на предмет деления сущности (entity) на шаблон (pattern) и экземпляр (instance). То есть одна сущность может потребовать и двух таблиц.
2. Спроектировать логическую модель данных - ER-диаграмма:
Все подпункты, описанные в пункте 2, должны быть размещены в пункте 1.
То есть в пункте 1 надо выделять не только сущности и атрибуты (и не надо называть их свойствами), но и связи/процессы.
В частности, проблема в том, что то, что внешне выглядит связью, запросто может оказаться самостоятельной сущностью.
Пример - делается система прав. Есть продукты, есть права, есть роли, и каждая роль имеет определённый набор прав на определённые продукты. Наивный подход - связующая таблица, хранящая три ссылки. Однако всё не так - связь между продуктом и правом, которое можно дать на этот продукт, на самом деле является скрытой самостоятельной сущностью, хранится соответственно в отдельной таблице, а таблица назначения прав ролям хранит ссылку на роль и ссылку на таблицу прав на продукты.
Сначала была связь "один ко многим", где у одной машины был один владелец, и у одного владельца много машин. Но со временем эксплуатации системы в продакшн оказалось нормальной ситуацией, что иногда два человека приезжают обслуживать одну машину
Какое отношение имеет сколько человек приехало обслуживать машину к количеству владельцев машины? Я не понял
Возможно, пропустил при чтении, но так и понял, где в статье таблетка для исключения фейлов из примеров?
Только знание, в т.ч. с помощью стейкхолдеров/консультантов, домена знаний. Ещё немного может помочь здравый смысл.
Как тут можно другим, волшебным образом "сделать модель БД гибкой" под эти примеры, тоже не понял. Вся модель БД - это ровно то, что предусмотрел аналитик после выявления всех (вымерших, текущих и будущих) сущностей и их зависимостей. Откуда тут какая-то другая "гибкость"?
у вас ссылка ютуб не рабочая - https://studio.youtube.com/video/cevBr_-ToiM/edit
SQL для системных аналитиков
Этот раздел, как мне кажется, очень спорный. Да, знать SQL полезно, но вот как SQL позволит в человеке развить логическое мышление, я не уловил. Да и логика вообще бывает у всех своя и сильно разная:)
Понимая, как устроен запрос и какие ресурсы он потребляет, можно заранее предусмотреть необходимые ограничения.
Почему-то в тексте во главу угла ставится именно запрос. Звучит так, словно предлагается не проработать решение задачи, а найти объяснение, почему что-то будет работать не в полной мере или не так, как хотелось заказчику.
В конце концов, мы же можем любой запрос переписать, индекс на таблицу навешать или ещё какие-то манипуляции на уровне БД произвести. А если пообщаться с архитектором, то может оказаться, что спектр вариантов решения бизнес-задачи ещё шире (например, СУБД стоит заменить, данные зарезервировать, шардировать, сделать кэш и пр.). Не SQL-ом единым, так сказать.
Позволяет с ходу оценивать реализуемость требований.
С ходу оценивать что-либо сложно. И знание SQL точно не будет ответом на все вопросы.
Проектирование БД и почему важен SQL для системного аналитика: гайд по улучшению качества требований