Post #30

Должен ли аналитик проектировать БД? В спорах про профессиональный стандарт системного аналитика самой жаркой темой оказалось знание программирования — вот уж где копий было сломано! Кто-то даже на Хабр статью написал. А я вот задумался про проектирование баз данных. Уже на нескольких проектах последних лет я сталкивался с тем, что эта тема оказывается пограничной — и программисты за неё не хотят браться, и аналитик останавливается на концептуальной модели. Аргументы с обоих сторон: у аналитика — я не специалист в тонкой настройке СУБД, и даже не знаю, какую вы выберете. А программисты либо боятся этой темы, потому что (моя гипотеза) — выросли из веб-разработки, может быть даже из фронтенда, и базы эти в глаза не видели, ведь всё сделает инструмент ORM автомагически. А какая там реляционная алгебра и как тюнить запросы — это всё очень сложно. Другой релевантный аргумент — ведь всё равно мы к тебе придём с вопросами, и тебе придется выяснять, так может ты сразу всё выяснишь и нам расскажешь. И действительно, резон в этом есть — чтобы хорошо спроектировать базу данных, нужно хорошо понимать про предметную область и про сценарии использования системы. А это область ответственности аналитика, если он есть на проекте. Итак, какие же вопросы нужно выяснить, чтобы качественно спроектировать БД? Во-первых, разбивку на сущности и атрибуты (ну или на классы объектов и их свойства, если вы работаете в объектной парадигме). Вопрос не такой простой, и часто возникает в том числе на тренингах. Мы нашли упоминание какого-то существительного в документах — это указание на объект или на атрибут? Простейший пример — адрес. Это сложный атрибут, или это самостоятельный объект? Вообще говоря, зависит от целей системы и сценариев использования. Я предлагаю следующие вопросы для проверки: 1) может ли этот "кандидат в объекты" существовать независимо от других объектов? Вот никаких клиентов нет, а адрес, как сущность, есть, и мы можем захотеть его заранее хранить, отдельно от всего? 2) (косвенный вопрос, связанный с предыдущим) существует ли потребность когда-нибудь выгружать, просматривать, передавать или наоборот — получать список всех возможных значений объекта, в отрыве от других объектов? Вот так, чтобы список всех имеющихся адресов посмотреть или куда-то передать? Интересный вопрос, между прочим, из него можно новую функциональность выявить, и даже смежные системы, о которых раньше не подумали. Если да — возможно, речь идет как минимум о справочнике, а может быть и о полновесном объекте. 3) Есть ли у этого предполагаемого объекта естественный идентификатор? Какой-нибудь номер или код? (у адреса такого, пожалуй, нет — адрес сам по себе такой идентификатор. Впрочем, сталкивались ли вы с домами, у которых есть несколько адресов?..). Для некоторых значений такой вопрос очевидно не имеет смысла, например, для фамилии, отчества или даты рождения. А в некоторых случаях не всё так очевидно. 4) Есть ли атрибуты у самого этого атрибута? Тогда, скорее всего, это отдельная сущность. Например, часто за атрибут принимают договор. Но у договора есть собственный номер, дата заключения, срок действия, состав услуг, и т.д. и т.п. Возможно, стоит рассмотреть его, как отдельную сущность.