8. Сопоставление концептуального и реляционного

моделирования данных

Начинающие разработчики БД, особенно имеющие некоторый опыт работы с реляционными СУБД, иногда спрашивают, зачем возиться с концептуальным моделирова­нием, если мы все равно в конце концов собираемся реализовывать базу данных в реляционной модели? Зачем вообще создавать концептуальную модель? Почему не создавать сразу реляционную модель данных и пользо­ваться теорией нормализации для исключения возможных аномалий? Разве это не позволит сберечь время и энергию? Это важные вопросы, и на них необходимо ответить. Возможно, вы тоже задавались такими вопросами.

Ответ на все эти вопросы сконцентрирован в одном слове: сложность. Чем сложнее становится модель базы данных, тем труднее разобраться в ней и правильно спроектировать. Эта сложность растет с добавлением объектных множеств, конкретизации, составных объектов и отношений. Поскольку главное назначение базы данных состоит в обеспечении точной информацией менеджеров и руководителей, жизненно важно, чтобы структура базы дан­ных была логичной и не имела изъянов. Так как человеку свойственно оши­баться, поэтому никакая методология моделирования не может полностью гарантировать точность модели данных, однако графический подход сильно повышает вероятность получения точных моделей по сравнению с текстовым подходом реляционного моделирования.

Мы проиллюстрируем это на примере. Рассмотрим реляционную модель счета консалтинговой фирмы, созданную выше на основе концептуальной модели рис. 13:

CLIENT (CLIENT-NAME, CLIENT-ADDRESS)

PROJECT (PROJECT-#, CLIENT-NAME/ PROJECT-TITLE,TOTAL-CHANGE, INVOICE-#, INVOICE-DATE)

Внешние ключи: CLIENT-NAME ссылается на CLIENT

CHANGE (CHANGE-#, PROJECT-# AMOUNT, DESCRIPTION)

Внешний ключ: PROJECT-# ссылается на PROJECT

CONSULTANT (CONSULTANT-NAME, RATE)

ENGAGED-IN-ACTIVITY-ON (CONSULTANT-NAME, ACTIVITY, PROJECT-#, HOURS, AMOUNT)

Внешние ключи:

CONSULTANT-NAME ссылается на CONSULTANT

PROJECT-# ссылается на PROJECT

Теперь предположим, что вы не имеете концептуальной модели рис. 13 и вообще ничего не знаете о концептуальном моделировании дан­ных. Если бы вы были пользователем, впервые взглянувшим на приведен­ную выше реляционную схему, насколько легко вам было бы понять смысл таблицы ENGAGED-IN-ACTIVITY-ON (ЗАНЯТ-В-ВИДЕ-ДЕЯТЕЛЬНОСТИ-ДЛЯ)? Пользуясь ссылками внешних ключей, вы сначала нашли бы реляци­онную схему таблицы CONSULTANT. Затем вы нашли бы реляционную схему таблицы PROJECT. Наконец, взглянув на имя таблицы ENGAGED-IN­ACTIVITY-ON и воспользовавшись тем фактом, что ACTIVITY (ВИД-ДЕЯТЕЛЬНОСТИ) является ключевым столбцом таблицы, вы бы проница­тельно заметили, что консультанты выполняют различные виды деятельно­сти в разных проектах, и эта таблица фиксирует затраченное время и сумму оплаты.

Теперь посмотрим на рис. 13. Сколько времени вам понадобится, чтобы вывести ту же самую информацию из рисунка? Очевидно, для этого требуется всего несколько секунд анализа, так как информация представ­лена в значительно более наглядном графическом виде. Этот естественный эффект выражается в естественном языке через использование существи­тельных (соответствующих объектным множествам) и глаголов (соответст­вующих отношениям). В концептуальной модели мы обозначаем су­ществительные прямоугольниками, а глаголы — отрезками-отношениями, соединяющими прямоугольники. Визуальное представление упрощает пони­мание структуры.

В реляционной же модели единственными средствами, которыми мы располагаем, являются реляционные таблицы и внешние ключи, так что все объектные множества и отношения моделируются одинаковым образом. С одного взгляда на реляционную схему не так-то просто понять, какие таб­лицы представляют существительные (или объекты), а какие — глаголы (или отношения). Без помощи графики мы должны сами производить разде­ление существительное-глагол. В самом деле: картинка стоит тысячи слов. Анализируя реляционную модель, вы мысленно рисуете для себя картинку, которая связывает таблицы примерно так же, как это делает рис. 13. Та­ким образом, Для того чтобы понять реляционную модель, мы мысленно выполняем ту же работу, которая уже проделана в концептуальной модели.

А теперь представьте себе, что реляционная модель состоит не из пяти таблиц, а из тридцати, сорока или пятидесяти; теперь вам ясно, как сложно будет в ней разобраться без помощи графики. При создании такой схемы базы данных важно, чтобы все тонкости, присущие реальной ситуации, были точно зафиксированы. Не пользуясь концептуальной моделью, проек­тировщик базы данных сильно рискует допустить в проекте серьезные ошибки.

Теперь обсудим другой вопрос: зачем заниматься преобразованием в ре­ляционную модель? Почему бы просто не реализовать концептуальную мо­дель? Ответ на этот вопрос состоит в том, что огромное большинство СУБД основано на реляционной (или более ранней) модели. Объектно-ориентиро­ванные СУБД, которые могли бы напрямую реализовать концептуальную схему, еще, по общему мнению, не достигли «промышленной мощности», необходимой для больших приложений, и, следовательно, пока не могут ис­пользоваться. Кроме, того, для простой базы данных напрямую создать ре­ляционную модель, возможно, не сложнее, чем создавать концептуальную модель. Таким образом, оба подхода вполне жизнеспособны и могут адек­ватно использоваться.