Визуальное моделирование баз данных

Пример концептуальной модели

В этом примере рассматривается схема данных для приложения, автоматизирующего работу факультетов университета. Фрагмент соответствующей концептуальной модели представлен на рис. 8.3.

Рис. 8.3. Пример концептуальной модели

Анализируя эту предметную область, можно выделить следующие сущности - "Студент", "Преподаватель", "Кафедра", "Отделение" и "Факультет", а также их отношения и атрибуты; для отношений показывается множественность. Важно, что в концептуальной модели нет типов атрибутов, а также ключей и индексов, сущности не нормализуются (то есть допускается наличие сложных атрибутов, например "Адрес" и "ФИО"). Все это нужно для того, чтобы такую модель можно было легко обсуждать со специалистами в той предметной области, для которой создается данное приложение, - секретарем декана, заместителем декана по учебной части и пр. Если в концептуальную модель будет добавлена лишняя программистская информация, то, как показывает опыт, она сразу перестанет быть понятной этим людям. В каждом случае этот "порог" может быть своим; он зависит от IT-компетентности специалистов предметной области, соответственно, диапазон используемых модельных средств может варьироваться.

Реалиазация отношения "многие-ко-многим" для реляционных СУБД

Этот вид отношения задает связь одного множества объектов с объектами другого множества. На UML-диаграммах такими являются связи, у которых с обоих концов множественность больше единицы - например, и там и там по звездочке, как у связи, соединяющей сущности "Преподаватель" и "Кафедра" на рис. 8.3. То есть на кафедре может работать много преподавателей, и один преподаватель может работать на многих кафедрах.

Отношение "многие-ко-многим", будучи удобным средством моделирования, не представимо напрямую в реляционной модели данных. Поэтому, рано или поздно, имея в виду, что наши модели схемы данных должны превратиться в структуру реляционных таблиц, это отношение нужно "раскрыть". Часто это целесообразно сделать при переходе от концептуальной модели к логической. И вот почему.

Рассмотрим пример. Слева на рис. 8.4 слева можно видеть пару сущностей из концептуальной модели - "Преподаватель" и "Кафедра", - которые связаны отношением "многие-ко-многим". Справа на этом же рисунке представлена диаграмма, где отношение "многие-ко-многим" раскрыто с помощью новой сущности и пары отношений "один-ко-многим".

Рис. 8.4. Пример реализации отношения "многие-ко-многим"

В данном случае новой сущностью является "Ставка". При этом на кафедре может быть много ставок, но каждая ставка принадлежит ровно одной кафедре. И у одного преподавателя может быть много ставок, но одна ставка принадлежит только одному преподавателю. Очевидно, что диаграмма слева эквивалентна диаграмме справа. С одним исключением.

Можно заметить, что в этом примере новая сущность оказалась не фиктивной, а содержательной. В данной предметной области действительно есть такое понятие, как "ставка", и у этой ставки есть свои атрибуты - должность (профессор, доцент и т. д.) и величина ставки (полная, половина, одна треть и т. д.). Каждый преподаватель числится на определенной кафедре с определенными значениями этих атрибутов. Один и тот же преподаватель может работать на разных кафедрах, на разных должностях и на разных ставках^{2В Санкт-Петербургском государственном университете есть правило, что общее количество ставок одного преподавателя не может превышать две.}.

Таким образом, наличие в предметной области этой важной информации требует, чтобы это отношение "многие-ко-многим" было раскрыто раньше, чем в физической модели - например, при переходе от концептуальной модели к логической.

Пример логической модели

На рис. 8.5 показан тот же фрагмент предметной области, что и на рис. 8.3, но "расписанный" в терминах логической модели.

Рис. 8.5. Пример логической модели

Каковы отличия моделей, представленных на рис. 8.3 и рис. 8.5? На первый взгляд видно, что появилось больше сущностей, а у атрибутов уже есть типы. Но это далеко не все.

1. При анализе типов атрибутов некоторые из них - например "Адрес" - были вынесены в отдельные сущности. Необходимо заметить, что типы атрибутов в логической модели могут не совпадать с типами целевой платформы, а нужны для того, чтобы уточнить схему данных: ведь, задумываясь о типах атрибутов, можно, например, создавать новые сущности для сложных типов. Типы также могут быть перечислимыми, т. е. состоять из списка предопределенных значений. Например, важно, что званий бывает два - доцент и преподаватель, курсов - всего шесть, с первого по шестой, ученых степеней всего две - к.ф.-м.н. и д.ф.-м.н. и т. д.
2. Использование наследования. В данном случае это оказалось следствием анализа атрибутов сущностей "Преподаватель" и "Студент". Часть их общих атрибутов была "вынесена" в общего предка - сущность "Персона". Но наследование может появляться и "сверху", когда несколько сущностей являются различными частными случаями одной исходной. В этом случае наследование может использоваться уже в концептуальной модели, но здесь нужно следить, чтобы оно было понятно тем, с кем программисты обсуждают эту модель.
3. Уточнение связей - значений множественности (не все они были точно обозначены в концептуальной модели), а также связанные с этим нюансы предметной области. Например, аналитик понял, что студенты только после второго курса распределяются по кафедрам, а до этого времени учатся все вместе. Но на определенное отделение факультета они поступают изначально. Поэтому сущность "Студент" будет агрегироваться не кафедрой, а отделением. А с кафедрой у него остается связь, причем ее множественность со стороны кафедры - 0..1 (этой связи может не быть, если студент учится на первом или втором курсе).
4. Раскрытие отношения "многие-ко-многим". Об этом уже было рассказано.

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