Без юскейсов не построить физическую модель данных.
Про связь юскейсов и модели данных почему-то никто не пишет. Ну, максимум -- как вытащить сущности из описания процессов (которым могут быть юскейсы, а могут и не быть, может быть какой-то другой текст с описанием). Для построения концептуальной модели этого достаточно -- нам нужно просто понять, что вообще есть в мире, и как разные концепции друг с другом связаны. Это вообще не про ИТ-систему, может, мы потом будем какой-нибудь там контролируемый словарь составлять или управлять знаниями. Или вообще хотим онтологию предметной области построить, вдруг пригодится.
На логическом уровне про сценарии использования тоже особо никто не задумывается. Развлекаться нарезкой отношений на всё более и более нормальные формы можно, совершенно не задумываясь о том, как это будет потом использоваться. Основная мотивация в этом процессе -- устранить принципиальную возможность дублирования и возможную потерю данных. Это всё очень технические случаи: аномалии при вставке данных, аномалии при обновлении, аномалии при удалении.
А вот когда мы переходим на физический уровень моделирования, нам нужно не просто разложить эти отношения по таблицам выбранной СУБД, а ещё и подумать про типовые кейсы их изменения и извлечения. Например, в реальной жизни почти всегда лучше использовать суррогатные ключи, а не надеяться на уникальность и неизменность каких-то естественных признаков. Например, данные извлекаются не произвольно, а исходя из потребностей пользователя (трейдер обычно смотрит на список сегодняших сделок, причем только своих, а не всех сделок вообще), причем пользователи могут иметь разные потребности (а отличие от трейдера, сотрудник миддл-офиса смотрит на сегодняшние сделки всех трейдеров, а риск-аналитик -- на все сделки за большой период). Не понимая потребности пользователей и их типовые запросы, мы, как минимум, не сможем построить индексы на таблицах, сформировать представления (view и materialized view), а где-то может, и денормализовать таблицы для большей скорости. Получается парадокс -- системные аналитики обычно проектированием физической модели данных не занимаются, а проектировщики БД, если они есть, не читают юскейсов. И отладка производительности БД начинается уже хорошо если на стейдже, а то и вообще в бою.
В Event Storming этой связке уделено специальное понятие: модель чтения. Помните -- результатом ES является "Картинка, которая объясняет всё". Это тот самый ответ на вопрос "какие данные нужны для того, чтобы пользователь принял решение и отдал команду, в результате исполнения которой произойдет событие". И, подумав о модели чтения, можно выбрать и подходящую форму хранения (может, вам вообще не реляционная база нужна, а графовая), и физическую модель определить.
Про связь юскейсов и модели данных почему-то никто не пишет. Ну, максимум -- как вытащить сущности из описания процессов (которым могут быть юскейсы, а могут и не быть, может быть какой-то другой текст с описанием). Для построения концептуальной модели этого достаточно -- нам нужно просто понять, что вообще есть в мире, и как разные концепции друг с другом связаны. Это вообще не про ИТ-систему, может, мы потом будем какой-нибудь там контролируемый словарь составлять или управлять знаниями. Или вообще хотим онтологию предметной области построить, вдруг пригодится.
На логическом уровне про сценарии использования тоже особо никто не задумывается. Развлекаться нарезкой отношений на всё более и более нормальные формы можно, совершенно не задумываясь о том, как это будет потом использоваться. Основная мотивация в этом процессе -- устранить принципиальную возможность дублирования и возможную потерю данных. Это всё очень технические случаи: аномалии при вставке данных, аномалии при обновлении, аномалии при удалении.
А вот когда мы переходим на физический уровень моделирования, нам нужно не просто разложить эти отношения по таблицам выбранной СУБД, а ещё и подумать про типовые кейсы их изменения и извлечения. Например, в реальной жизни почти всегда лучше использовать суррогатные ключи, а не надеяться на уникальность и неизменность каких-то естественных признаков. Например, данные извлекаются не произвольно, а исходя из потребностей пользователя (трейдер обычно смотрит на список сегодняших сделок, причем только своих, а не всех сделок вообще), причем пользователи могут иметь разные потребности (а отличие от трейдера, сотрудник миддл-офиса смотрит на сегодняшние сделки всех трейдеров, а риск-аналитик -- на все сделки за большой период). Не понимая потребности пользователей и их типовые запросы, мы, как минимум, не сможем построить индексы на таблицах, сформировать представления (view и materialized view), а где-то может, и денормализовать таблицы для большей скорости. Получается парадокс -- системные аналитики обычно проектированием физической модели данных не занимаются, а проектировщики БД, если они есть, не читают юскейсов. И отладка производительности БД начинается уже хорошо если на стейдже, а то и вообще в бою.
В Event Storming этой связке уделено специальное понятие: модель чтения. Помните -- результатом ES является "Картинка, которая объясняет всё". Это тот самый ответ на вопрос "какие данные нужны для того, чтобы пользователь принял решение и отдал команду, в результате исполнения которой произойдет событие". И, подумав о модели чтения, можно выбрать и подходящую форму хранения (может, вам вообще не реляционная база нужна, а графовая), и физическую модель определить.