Домашнее задание
1. Ознакомится с теоретическими сведениями лекции №28.
2. Ответить на контрольные вопросы.
Контрольные вопросы
Определение приложения баз данных.
Структура данных при моделировании БД.
Модель "сущность-связь".
Определение сущности.
Определение связи.
Уровень абстракции при моделировании данных.
Лекция № 29 (2часа)
Тема: Построение концептуальной и логической модели.
Цель: Рассмотреть пример построения концептуальной и логической модели. Ознакомится с принципами реализации отношения "многие-ко-многим" для реляционных СУБД.
Литература:
Чен П.П. Модель “сущность-связь” – шаг к единому представлению данных. СУБД, N3, 1995 г.
Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. М., Финансы и статистика, 1998.
Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. М., Мир, 1999.
Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. 2-е изд. М., Издательство Бином, СПб., Невский диалект, 1999.
Буч Г., Рамбо Д., Джекобсон А. Язык UML: руководство пользователя. М., ДМК, 2000.
Содержание
Пример концептуальной модели
Рассмотрим схему данных для приложения, автоматизирующего работу факультетов университета. Фрагмент соответствующей концептуальной модели представлен на рисунке.
Рисунок 2.7.4 - Пример концептуальной модели
Анализируя эту предметную область, можно выделить следующие сущности - "Студент", "Преподаватель", "Кафедра", "Отделение" и "Факультет", а также их отношения и атрибуты; для отношений показывается множественность. Важно, что в концептуальной модели нет типов атрибутов, а также ключей и индексов, сущности не нормализуются (то есть допускается наличие сложных атрибутов, например "Адрес" и "ФИО"). Все это нужно для того, чтобы такую модель можно было легко обсуждать со специалистами в той предметной области, для которой создается данное приложение, - секретарем декана, заместителем декана по учебной части и пр. Если в концептуальную модель будет добавлена лишняя программистская информация, то, как показывает опыт, она сразу перестанет бать для них понятной. В каждом случае этот "порог" может быть своим; он зависит от IT-компетентности специалистов предметной области, соответственно, диапазон используемых модельных средств может варьироваться.
Реалиазация отношения "многие-ко-многим" для реляционных СУБД
Этот вид отношения задает связь одного множества объектов с объектами другого множества. На UML-диаграммах такими являются связи, у которых с обоих концов множественность больше единицы, как у связи, соединяющей сущности "Преподаватель" и "Кафедра". То есть на кафедре может работать много преподавателей, и один преподаватель может работать на многих кафедрах.
Отношение "многие-ко-многим", будучи удобным средством моделирования, не представимо напрямую в реляционной модели данных. Поэтому, рано или поздно, имея в виду, что наши модели схемы данных должны превратиться в структуру реляционных таблиц, это отношение нужно "раскрыть". Часто это целесообразно сделать при переходе от концептуальной модели к логической.
Рассмотрим пример.
Рисунок 2.7.5 - Пример реализации отношения "многие-ко-многим"
Слева на рис. 2.7.5 можно видеть пару сущностей из концептуальной модели - "Преподаватель" и "Кафедра", - которые связаны отношением "многие-ко-многим". Справа на этом же рисунке представлена диаграмма, где отношение "многие-ко-многим" раскрыто с помощью новой сущности и пары отношений "один-ко-многим".
В данном случае новой сущностью является "Ставка". При этом на кафедре может быть много ставок, но каждая ставка принадлежит ровно одной кафедре. И у одного преподавателя может быть много ставок, но одна ставка принадлежит только одному преподавателю. Очевидно, что диаграмма слева эквивалентна диаграмме справа. С одним исключением.
Можно заметить, что в этом примере новая сущность оказалась не фиктивной, а содержательной. В данной предметной области действительно есть такое понятие, как "ставка", и у этой ставки есть свои атрибуты - должность (профессор, доцент и т. д.) и величина ставки (полная, половина, одна треть и т. д.). Каждый преподаватель числится на определенной кафедре с определенными значениями этих атрибутов. Один и тот же преподаватель может работать на разных кафедрах, на разных должностях и на разных ставках1).
Таким образом, наличие в предметной области этой важной информации требует, чтобы это отношение "многие-ко-многим" было раскрыто раньше, чем в физической модели - например, при переходе от концептуальной модели к логической.
Тут следует отметить, что иногда такие отношения действительно лучше раскрывать при переходе к физической модели, если существенных атрибутов в новую сущность не добавляется. Ведь диаграммы, созданные с использованием отношения "многие-ко-многим", значительно компактнее тех, которые получаются после "раскрытия" этого отношения. Но очень часто такие атрибуты всё же находятся.
Пример логической модели
На рис. 2.7.6 показан тот же фрагмент предметной области, что и на первом рис., но "расписанный" в терминах логической модели.
Рисунок 2.7.6 - Пример логической модели
Рассмотрим отличия моделей представленнях на даннях рисунках. На первый взгляд видно, что появилось больше сущностей, а у атрибутов уже есть типы. Но это далеко не все.
При анализе типов атрибутов некоторые из них - например "Адрес" - были вынесены в отдельные сущности. Необходимо заметить, что типы атрибутов в логической модели могут не совпадать с типами целевой платформы, а нужны для того, чтобы уточнить схему данных: ведь, задумываясь о типах атрибутов, можно, например, создавать новые сущности для сложных типов. Типы также могут быть перечислимыми, т. е. состоять из списка предопределенных значений. Например, важно, что званий бывает два - доцент и преподаватель, курсов - всего шесть, с первого по шестой, ученых степеней всего две - к.ф.-м.н. и д.ф.-м.н. и т. д.
Использование наследования. В данном случае это оказалось следствием анализа атрибутов сущностей "Преподаватель" и "Студент". Часть их общих атрибутов была "вынесена" в общего предка - сущность "Персона". Но наследование может появляться и "сверху", когда несколько сущностей являются различными частными случаями одной исходной. В этом случае наследование может использоваться уже в концептуальной модели.
Уточнение связей - значений множественности, а также связанные с этим нюансы предметной области. Например, аналитик понял, что студенты только после второго курса распределяются по кафедрам, а до этого времени учатся все вместе. Но на определенное отделение факультета они поступают изначально. Поэтому сущность "Студент" будет агрегироваться не кафедрой, а отделением. А с кафедрой у него остается связь, причем ее множественность со стороны кафедры - 0..1.