ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
Государственное образовательное учреждение
высшего профессионального образования
РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ ГУМАНИТАРНЫЙ УНИВЕРСИТЕТ
ИНСТИТУТ ИНФОРМАЦИОННЫХ НАУК И ТЕХНОЛОГИЙ БЕЗОПАСНОСТИ
Кафедра общей информатики
ГУБАРЕВ СЕРГЕЙ ВЛАДИМИРОВИЧ
КОНТРОЛЬНАЯ РАБОТА ПО ДИСЦИПЛИНЕ
«БАЗЫ ДАННЫХ»
ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
ЭКСТЕРНА 3 ГОДА ОБУЧЕНИЯ (4-Х ЛЕТНЕГО СРОКА ОБУЧЕНИЯ)
ГРУППА Б (информационная сфера)
Научный руководитель
преподаватель
Туляков С. П.
Москва
2005
ПЛАН
ВВЕДЕНИЕ 3
ОСНОВНАЯ ЧАСТЬ
1.Проектирование реляционных баз данных
сиспользованием нормализации 5
1.1.Вторая нормальная форма 7
1.2. Третьянормальная форма 9
1.3.Нормальная форма Бойса-Кодда 10
1.4.Четвертая нормальная форма 12
1.5. Пятаянормальная форма 13
2. Семантическоемоделирование данных, ER-диаграммы 15
2.1. Семантические модели данных 16
2.2. Основныепонятия модели Entity-Relationship
(Сущность-Связи) 17
2.3. Нормальные формы ER-схем 20
2.4. Более сложные элементы ER-модели 20
2.5. Получение реляционной схемы изER-схемы 23
ЗАКЛЮЧЕНИЕ 27
СПИСОК ЛИТЕРАТУРЫ 28
ВВЕДЕНИЕ
Управление информацией всегда было основной сферой применения компьютерови, надо думать, будет играть еще большую роль в будущем. Базы данных и системыуправления ими (СУБД, DBMS –Database Management System) на протяжении всего пути развития компьютернойтехники совершенствовались, поддерживая все более сложные уровни абстрактныхданных, заданных пользователем, и обеспечивая взаимодействие компонентов,распределенных в глобальных сетях и постепенно интегрирующихся стелекоммуникационными системами.
История развития компьютерной техники – это история непрерывного движенияот языка и уровня коммуникации машины к уровню пользователя. Если первые машинытребовали от пользователя оформления того, что ему нужно (то есть написанияпрограмм), в машинных кодах, то языки программирования четвертого уровня (4GLs) позволяли конечным пользователям,не являющимся профессиональными программистами, получать доступ к информациибез детального описания каждого шага, но только с встроенными предопределеннымитипами данных – например, таблицами.
В случае реляционных баз данных трудно представить какие-либообщие рецепты по части физического проектирования. Здесь слишком много зависитот используемой СУБД. Например, при работе с СУБД Ingres можно выбирать один изпредлагаемых способов физической организации отношений, при работе с System Rследовало бы прежде всего подумать о кластеризации отношений и требуемом набореиндексов и т.д. Поэтому я ограничусь вопросами логического проектированияреляционных баз данных, которые существенны при использовании любой реляционнойСУБД.
Более того, не буду касаться очень важного аспектапроектирования – определения ограничений целостности (за исключениемограничения первичного ключа). Дело в том, что при использовании СУБД сразвитыми механизмами ограничений целостности (например, SQL-ориентированныхсистем) трудно предложить какой-либо общий подход к определению ограниченийцелостности. Эти ограничения могут иметь очень общий вид, и их формулировкапока относится скорее к области искусства, чем инженерного мастерства. Самоебольшее, что предлагается по этому поводу в литературе, это автоматическаяпроверка непротиворечивости набора ограничений целостности.
1. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ СИСПОЛЬЗОВАНИЕМ НОРМАЛИЗАЦИИ
Сначала я рассмотрю классическийподход, при котором весь процесс проектирования производится в терминахреляционной модели данных методом последовательных приближений кудовлетворительному набору схем отношений. Исходной точкой являетсяпредставление предметной области в виде одного или нескольких отношений, и накаждом шаге проектирования производится некоторый набор схем отношений,обладающих лучшими свойствами. Процесс проектирования представляет собойпроцесс нормализации схем отношений, причем каждая следующая нормальная формаобладает свойствами лучшими, чем предыдущая.
Каждой нормальной формесоответствует некоторый определенный набор ограничений, и отношение находится внекоторой нормальной форме, если удовлетворяет свойственному ей наборуограничений. Примером набора ограничений является ограничение первой нормальнойформы – значения всех атрибутов отношения атомарны. Поскольку требование первойнормальной формы является базовым требованием классической реляционной моделиданных, мы будем считать, что исходный набор отношений уже соответствует этомутребованию.
В теории реляционных баз данных обычно выделяетсяследующая последовательность нормальных форм:
· первая нормальнаяформа (1NF);
· вторая нормальнаяформа (2NF);
· третья нормальнаяформа (3NF);
· нормальная формаБойса-Кодда (BCNF);
· четвертаянормальная форма (4NF);
· пятая нормальнаяформа, или нормальная форма проекции-соединения (5NF или PJ/NF).
Основные свойства нормальных форм:
· каждая следующаянормальная форма в некотором смысле лучше предыдущей;
· при переходе кследующей нормальной форме свойства предыдущих нормальных свойств сохраняются.
В основе процесса проектирования лежит методнормализации, декомпозиция отношения, находящегося в предыдущей нормальнойформе, в два или более отношения, удовлетворяющих требованиям следующейнормальной формы.
Наиболее важные на практике нормальные формы отношенийосновываются на фундаментальном в теории реляционных баз данных понятии функциональнойзависимости. Для дальнейшего изложения потребуется несколько определений.
Определение 1. Функциональная зависимость
В отношении R атрибут Y функционально зависит отатрибута X (X и Y могут быть составными) в том и только в том случае, есликаждому значению X соответствует в точности одно значение Y: R.X (r) R.Y.
Определение 2. Полная функциональная зависимость
Функциональная зависимость R.X (r) R.Y называетсяполной, если атрибут Y не зависит функционально от любого точного подмножестваX.
Определение 3. Транзитивная функциональная зависимость
Функциональная зависимость R.X (r) R.Y называетсятранзитивной, если существует такой атрибут Z, что имеются функциональныезависимости R.X (r) R.Z и R.Z (r) R.Y и отсутствует функциональная зависимостьR.Z --> R.X. (При отсутствии последнего требования мы имели бы«неинтересные» транзитивные зависимости в любом отношении, обладающемнесколькими ключами.)
Определение 4. Неключевой атрибут
Неключевым атрибутом называется любой атрибутотношения, не входящий в состав первичного ключа (в частности, первичного).
Определение 5. Взаимно независимые атрибуты
Два или более атрибута взаимно независимы, если ниодин из этих атрибутов не является функционально зависимым от других. 1.1. Вторая нормальная форма
Рассмотрим следующий пример схемы отношения:
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР (r) СОТР_ЗАРП
СОТР_НОМЕР (r) ОТД_НОМЕР
ОТД_НОМЕР (r) СОТР_ЗАРП
СОТР_НОМЕР, ПРО_НОМЕР (r) СОТР_ЗАДАН
Как видно, хотя первичным ключом является составнойатрибут СОТР_НОМЕР, ПРО_НОМЕР, атрибуты СОТР_ЗАРП и ОТД_НОМЕР функциональнозависят от части первичного ключа, атрибута СОТР_НОМЕР. В результате мы несможем вставить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ кортеж, описывающийсотрудника, который еще не выполняет никакого проекта (первичный ключ не можетсодержать неопределенное значение). При удалении кортежа мы не только разрушаемсвязь данного сотрудника с данным проектом, но утрачиваем информацию о том, чтоон работает в некотором отделе. При переводе сотрудника в другой отдел мы будемвынуждены модифицировать все кортежи, описывающие этого сотрудника, или получимнесогласованный результат. Такие неприятные явления называются аномалиями схемыотношения. Они устраняются путем нормализации.
Определение 6. Вторая нормальная форма (в этом определениипредполагается, что единственным ключом отношения является первичный ключ)
Отношение R находится во второй нормальной форме (2NF)в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибутполностью зависит от первичного ключа.
Можно произвести следующую декомпозицию отношенияСОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ иСОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)
Первичный ключ: СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР (r) СОТР_ЗАРП
СОТР_НОМЕР (r) ОТД_НОМЕР
ОТД_НОМЕР (r) СОТР_ЗАРП
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Первичный ключ: СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
Каждое из этих двух отношений находится в 2NF, и в нихустранены отмеченные выше аномалии (легко проверить, что все указанные операциивыполняются без проблем).
Если допустить наличие нескольких ключей, тоопределение 6 примет следующий вид:
Определение 6~
Отношение R находится во второй нормальной форме (2NF)в том и только в том случае, когда оно находится в 1NF, и каждый неключевойатрибут полностью зависит от каждого ключа R.
Здесь и далее мы не будем приводить примеры дляотношений с несколькими ключами. Они слишком громоздки и относятся к ситуациям,редко встречающимся на практике. 1.2. Третья нормальная форма
Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ,находящееся в 2NF. Заметим, что функциональная зависимость СОТР_НОМЕР (r)СОТР_ЗАРП является транзитивной; она является следствием функциональныхзависимостей СОТР_НОМЕР (r) ОТД_НОМЕР и ОТД_НОМЕР (r) СОТР_ЗАРП. Другимисловами, заработная плата сотрудника на самом деле является характеристикой несотрудника, а отдела, в котором он работает (это не очень естественноепредположение, но достаточное для примера).
В результате мы не сможем занести в базу данныхинформацию, характеризующую заработную плату отдела, до тех пор, пока в этомотделе не появится хотя бы один сотрудник (первичный ключ не может содержатьнеопределенное значение). При удалении кортежа, описывающего последнегосотрудника данного отдела, мы лишимся информации о заработной плате отдела.Чтобы согласованным образом изменить заработную плату отдела, мы будемвынуждены предварительно найти все кортежи, описывающие сотрудников этогоотдела. Т.е. в отношении СОТРУДИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Ихможно устранить путем дальнейшей нормализации.
Определение 7. Третья нормальная форма. (Снова определение дается впредположении существования единственного ключа.)
Отношение R находится в третьей нормальной форме (3NF)в том и только в том случае, если находится в 2NF и каждый неключевой атрибутнетранзитивно зависит от первичного ключа.
Можно произвести декомпозицию отношенияСОТРУДНИКИ-ОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:
СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)
Первичный ключ: СОТР_НОМЕР
Функциональные зависимости: СОТР_НОМЕР (r) ОТД_НОМЕР
ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП)
Первичный ключ: ОТД_НОМЕР
Функциональные зависимости: ОТД_НОМЕР (r) СОТР_ЗАРП
Каждое из этих двух отношений находится в 3NF исвободно от отмеченных аномалий.
Если отказаться от того ограничения, что отношениеобладает единственным ключом, то определение 3NF примет следующую форму:
Определение 7~
Отношение R находится в третьей нормальной форме (3NF)в том и только в том случае, если находится в 1NF, и каждый неключевой атрибутне является транзитивно зависимым от какого-либо ключа R.
На практике третья нормальная форма схем отношенийдостаточна в большинстве случаев, и приведением к третьей нормальной формепроцесс проектирования реляционной базы данных обычно заканчивается. Однакоиногда полезно продолжить процесс нормализации. 1.3. Нормальная форма Бойса-Кодда
Рассмотрим следующий пример схемы отношения:
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ИМЯ, ПРО_НОМЕР,СОТР_ЗАДАН)
Возможные ключи: СОТР_НОМЕР,ПРО_НОМЕР СОТР_ИМЯ, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР (r) CОТР_ИМЯ
СОТР_НОМЕР (r) ПРО_НОМЕР
СОТР_ИМЯ (r) CОТР_НОМЕР
СОТР_ИМЯ (r) ПРО_НОМЕР
СОТР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
СОТР_ИМЯ, ПРО_НОМЕР (r) CОТР_ЗАДАН
В этом примере предполагается, что личность сотрудникаполностью определяется как его номером, так и именем (это снова не оченьжизненное предположение, но достаточное для примера).
В соответствии с определением 7~ отношениеСОТРУДНИКИ-ПРОЕКТЫ находится в 3NF. Однако тот факт, что имеются функциональныезависимости атрибутов отношения от атрибута, являющегося частью первичногоключа, приводит к аномалиям. Например, для того, чтобы изменить имя сотрудника сданным номером согласованным образом, нам потребуется модифицировать всекортежи, включающие его номер.
Определение 8. Детерминант
Детерминант — любой атрибут, от которого полностьюфункционально зависит некоторый другой атрибут.
Определение 9. Нормальная форма Бойса-Кодда
Отношение R находится в нормальной форме Бойса-Кодда(BCNF) в том и только в том случае, если каждый детерминант является возможнымключом.
Очевидно, что это требование не выполнено дляотношения СОТРУДНИКИ-ПРОЕКТЫ. Можно произвести его декомпозицию к отношениямСОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ)
Возможные ключи: СОТР_НОМЕР, СОТР_ИМЯ
Функциональные зависимости:
СОТР_НОМЕР (r) CОТР_ИМЯ
СОТР_ИМЯ (r) СОТР_НОМЕР
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР,ПРО_НОМЕР, СОТР_ЗАДАН)
Возможный ключ: СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН
Возможна альтернативнаядекомпозиция, если выбрать за основу СОТР_ИМЯ. Получаемые отношения СОТРУДНИКИи СОТРУДНИКИ-ПРОЕКТЫ находятся в BCNF, и им не свойственны отмеченные аномалии. 1.4. Четвертая нормальная форма
Рассмотрим пример следующей схемы отношения:
ПРОЕКТЫ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН)
Отношение ПРОЕКТЫ содержит номера проектов, длякаждого проекта список сотрудников, которые могут выполнять проект, и списокзаданий, предусматриваемых проектом. Сотрудники могут участвовать в несколькихпроектах, и разные проекты могут включать одинаковые задания.
Каждый кортеж отношения связывает некоторый проект ссотрудником, участвующим в этом проекте, и заданием, который сотрудниквыполняет в рамках данного проекта (я предполагаю, что любой сотрудник,участвующий в проекте, выполняет все задания, предусмотренные этим проектом).По причине сформулированных выше условий единственным возможным ключемотношения является составной атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и нетникаких других детерминантов. Следовательно, отношение ПРОЕКТЫ находится вBCNF. Но при этом оно обладает недостатками: если, например, некоторыйсотрудник присоединяется к данному проекту, необходимо вставить в отношениеПРОЕКТЫ столько кортежей, сколько заданий в нем предусмотрено.
Определение 10. Многозначные зависимости
В отношении R (A, B, C)существует многозначная зависимость R.A (r) (r) R.B в том и только в томслучае, если множество значений B, соответствующее паре значений A и C, зависиттолько от A и не зависит от С. В отношении ПРОЕКТЫ существуют следующие двемногозначные зависимости:
ПРО_НОМЕР (r) (r) ПРО_СОТР и ПРО_НОМЕР (r) (r)ПРО_ЗАДАН
Легко показать, что в общем случае в отношении R (A,B, C) существует многозначная зависимость R.A (r) (r) R.B в том и только в томслучае, когда существует многозначная зависимость R.A (r) (r) R.C.
Дальнейшая нормализация отношений, подобных отношениюПРОЕКТЫ, основывается на следующей теореме:
Теорема Фейджина: отношение R (A, B, C) можноспроецировать без потерь в отношения R1 (A, B) и R2 (A, C) в том и только в томслучае, когда существует MVD A (r) (r) B | C.
Под проецированием без потерь понимается такой способдекомпозиции отношения, при котором исходное отношение полностью и безизбыточности восстанавливается путем естественного соединения полученныхотношений.
Определение 11. Четвертая нормальная форма
Отношение R находится в четвертой нормальной форме(4NF) в том и только в том случае, если в случае существования многозначнойзависимости A (r) (r) B все остальные атрибуты R функционально зависят от A.
В нашем примере можно произвестидекомпозицию отношения ПРОЕКТЫ в два отношения ПРОЕКТЫ-СОТРУДНИКИ иПРОЕКТЫ-ЗАДАНИЯ:
ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН)
Оба эти отношения находятся в 4NFи свободны от отмеченных аномалий. 1.5. Пятая нормальная форма
Во всех рассмотренных до этого момента нормализацияхпроизводилась декомпозиция одного отношения в два. Иногда это сделать неудается, но возможна декомпозиция в большее число отношений, каждое из которыхобладает лучшими свойствами.
Рассмотрим, например, отношение
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, ОТД_НОМЕР, ПРО_НОМЕР)
Предположим, что один и тот же сотрудник можетработать в нескольких отделах и работать в каждом отделе над несколькимипроектами. Первичным ключем этого отношения является полная совокупность его атрибутов,отсутствуют функциональные и многозначные зависимости.
Поэтому отношение находится в4NF. Однако в нем могут существовать аномалии, которые можно устранить путемдекомпозиции в три отношения.
Определение 12. Зависимость соединения
Отношение R (X, Y, ..., Z) удовлетворяет зависимостисоединения * (X, Y, ..., Z) в том и только в том случае, когда Rвосстанавливается без потерь путем соединения своих проекций на X, Y, ..., Z.
Определение 13. Пятая нормальная форма
Отношение R находится в пятой нормальной форме(нормальной форме проекции-соединения — PJ/NF) в том и только в том случае,когда любая зависимость соединения в R следует из существования некотороговозможного ключа в R.
Введем следующие имена составных атрибутов:
СО = {СОТР_НОМЕР, ОТД_НОМЕР}
СП = {СОТР_НОМЕР, ПРО_НОМЕР}
ОП = {ОТД_НОМЕР, ПРО_НОМЕР}
Предположим, что в отношении СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫсуществует зависимость соединения: * (СО, СП, ОП)
На примерах легко показать, что при вставках иудалениях кортежей могут возникнуть проблемы. Их можно устранить путемдекомпозиции исходного отношения в три новых отношения:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, ОТД_НОМЕР)
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР)
ОТДЕЛЫ-ПРОЕКТЫ (ОТД_НОМЕР, ПРО_НОМЕР)
Пятая нормальная форма — это последняя нормальнаяформа, которую можно получить путем декомпозиции. Ее условия достаточнонетривиальны, и на практике 5NF не используется. Заметим, что зависимостьсоединения является обобщением как многозначной зависимости, так ифункциональной зависимости.
2. СЕМАНТИЧЕСКОЕ МОДЕЛИРОВАНИЕ ДАННЫХ,ER-ДИАГРАММЫ
Широкое распространение реляционных СУБД и ихиспользование в самых разнообразных приложениях показывает, что реляционнаямодель данных достаточна для моделирования предметных областей. Однакопроектирование реляционной базы данных в терминах отношений на основе краткорассмотренного механизма нормализации часто представляет собой очень сложный инеудобный для проектировщика процесс.
При этом проявляется ограниченность реляционной моделиданных в следующих аспектах:
· Модель непредоставляет достаточных средств для представления смысла данных. Семантикареальной предметной области должна независимым от модели способомпредставляться в голове проектировщика. В частности, это относится к упоминавшейсянами проблеме представления ограничений целостности.
· Для многихприложений трудно моделировать предметную область на основе плоских таблиц. Вряде случаев на самой начальной стадии проектирования проектировщику приходитсяпроизводить насилие над собой, чтобы описать предметную область в виде одной(возможно, даже ненормализованной) таблицы.
· Хотя весь процесспроектирования происходит на основе учета зависимостей, реляционная модель непредоставляет каких-либо средств для представления этих зависимостей.
· Несмотря на то,что процесс проектирования начинается с выделения некоторых существенных дляприложения объектов предметной области («сущностей») и выявлениясвязей между этими сущностями, реляционная модель данных не предлагаеткакого-либо аппарата для разделения сущностей и связей.
2.1. Семантическиемодели данных
Потребности проектировщиков баз данных в более удобныхи мощных средствах моделирования предметной области вызвали к жизни направлениесемантических моделей данных. При том, что любая развитая семантическая модельданных, как и реляционная модель, включает структурную, манипуляционную ицелостную части, главным назначением семантических моделей является обеспечениевозможности выражения семантики данных.
Прежде, чем мы коротко рассмотрим особенности одной израспространенных семантических моделей, остановимся на их возможныхприменениях.
Наиболее часто на практике семантическое моделированиеиспользуется на первой стадии проектирования базы данных. При этом в терминахсемантической модели производится концептуальная схема базы данных, котораязатем вручную концептуальная схема преобразуется к реляционной (или какой-либодругой) схеме. Этот процесс выполняется под управлением методик, в которыхдостаточно четко оговорены все этапы такого преобразования.
Менее часто реализуется автоматизированная компиляцияконцептуальной схемы в реляционную. При этом известны два подхода: на основеявного представления концептуальной схемы как исходной информации длякомпилятора и построения интегрированных систем проектирования савтоматизированным созданием концептуальной схемы на основе интервью сэкспертами предметной области. И в том, и в другом случае в результатепроизводится реляционная схема базы данных в третьей нормальной форме (болееточно следовало бы сказать, что автору неизвестны системы, обеспечивающие болеевысокий уровень нормализации).
Наконец, третья возможность, которая еще не вышла (илитолько выходит) за пределы исследовательских и экспериментальных проектов, — это работа с базой данных в семантической модели, т.е. СУБД, основанные насемантических моделях данных. При этом снова рассматриваются два варианта:обеспечение пользовательского интерфейса на основе семантической модели данныхс автоматическим отображением конструкций в реляционную модель данных (этозадача примерно такого же уровня сложности, как автоматическая компиляцияконцептуальной схемы базы данных в реляционную схему) и прямая реализация СУБД,основанная на какой-либо семантической модели данных. Наиболее близко ковторому подходу находятся современные объектно-ориентированные СУБД, моделиданных которых по многим параметрам близки к семантическим моделям (хотя внекоторых аспектах они более мощны, а в некоторых — более слабы). 2.2. Основные понятия моделиEntity-Relationship (Сущность-Связи)
Далее мы кратко рассмотрим некоторые черты одной изнаиболее популярных семантических моделей данных — модель«Сущность-Связи» (часто ее называют кратко ER-моделью).
На использовании разновидностей ER-модели основанобольшинство современных подходов к проектированию баз данных (главным образом,реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделированиепредметной области базируется на использовании графических диаграмм, включающихнебольшое число разнородных компонентов. В связи с наглядностью представленияконцептуальных схем баз данных ER-модели получили широкое распространение всистемах CASE, поддерживающих автоматизированное проектирование реляционных базданных. Среди множества разновидностей ER-моделей одна из наиболее развитыхприменяется в системе CASE фирмы ORACLE. Ее мы и рассмотрим. Более точно, мысосредоточимся на структурной части этой модели.
Основными понятиями ER-модели являются сущность, связьи атрибут.
Сущность — это реальный или представляемый объект,информация о котором должна сохраняться и быть доступна. В диаграммах ER-моделисущность представляется в виде прямоугольника, содержащего имя сущности. Приэтом имя сущности — это имя типа, а не некоторого конкретного экземпляра этоготипа. Для большей выразительности и лучшего понимания имя сущности можетсопровождаться примерами конкретных объектов этого типа.
Ниже изображена сущность АЭРОПОРТ с примернымиобъектами Шереметьево и Хитроу:
/>
Каждый экземпляр сущности должен быть отличим отлюбого другого экземпляра той же сущности (это требование в некотором родеаналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах).
Связь — это графически изображаемая ассоциация,устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарнойи может существовать между двумя разными сущностями или между сущностью и ей жесамой (рекурсивная связь). В любой связи выделяются два конца (в соответствии ссуществующей парой связываемых сущностей), на каждом из которых указывается имяконца связи, степень конца связи (сколько экземпляров данной сущностисвязывается), обязательность связи (т.е. любой ли экземпляр данной сущностидолжен участвовать в данной связи).
Связь представляется в виде линии, связывающей двесущности или ведущей от сущности к ней же самой. При это в месте«стыковки» связи с сущностью используются трехточечный вход впрямоугольник сущности, если для этой сущности в связи могут использоватьсямного (many) экземпляров сущности, и одноточечный вход, если в связи можетучаствовать только один экземпляр сущности. Обязательный конец связиизображается сплошной линией, а необязательный — прерывистой линией.
Как и сущность, связь — это типовое понятие, всеэкземпляры обеих пар связываемых сущностей подчиняются правилам связывания.
В изображенном ниже примере связь между сущностямиБИЛЕТ и ПАССАЖИР связывает билеты и пассажиров. При том конец сущности с именем«для» позволяет связывать с одним пассажиром более одного билета,причем каждый билет должен быть связан с каким-либо пассажиром. Конец сущностис именем «имеет» означает, что каждый билет может принадлежать толькоодному пассажиру, причем пассажир не обязан иметь хотя бы один билет.
/>
Лаконичной устной трактовкой изображенной диаграммыявляется следующая:
· Каждый БИЛЕТпредназначен для одного и только одного ПАССАЖИРА;
· Каждый ПАССАЖИРможет иметь один или более БИЛЕТОВ.
На следующем примере изображена рекурсивная связь,связывающая сущность ЧЕЛОВЕК с ней же самой. Конец связи с именем«сын» определяет тот факт, что у одного отца может быть более чемодин сын. Конец связи с именем «отец» означает, что не у каждогочеловека могут быть сыновья.
/>
Лаконичной устной трактовкой изображенной диаграммыявляется следующая:
· Каждый ЧЕЛОВЕКявляется сыном одного и только одного ЧЕЛОВЕКА;
· Каждый ЧЕЛОВЕКможет являться отцом для одного или более ЛЮДЕЙ («ЧЕЛОВЕКОВ»).
Атрибутом сущности является любая деталь, котораяслужит для уточнения, идентификации, классификации, числовой характеристики иливыражения состояния сущности. Имена атрибутов заносятся в прямоугольник,изображающий сущность, под именем сущности и изображаются малыми буквами,возможно, с примерами.
Пример:
Уникальным идентификатором сущности является атрибут,комбинация атрибутов, комбинация связей или комбинация связей и атрибутов,уникально отличающая любой экземпляр сущности от других экземпляров сущноститого же типа. 2.3. Нормальные формы ER-схем
Как и в реляционных схемах баз данных, в ER-схемахвводится понятие нормальных форм, причем их смысл очень близко соответствуетсмыслу реляционных нормальных форм. Заметим, что формулировки нормальных форм ER-схемделают более понятным смысл нормализации реляционных схем. Мы приведем толькоочень краткие и неформальные определения трех первых нормальных форм.
В первой нормальной форме ER-схемы устраняютсяповторяющиеся атрибуты или группы атрибутов, т.е. производится выявлениенеявных сущностей, «замаскированных» под атрибуты.
Во второй нормальной форме устраняются атрибуты,зависящие только от части уникального идентификатора. Эта часть уникальногоидентификатора определяет отдельную сущность.
В третьей нормальной форме устраняются атрибуты,зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибутыявляются основой отдельной сущности.
2.4. Более сложные элементы ER-модели
Мы остановились только на самых основных и наиболееочевидных понятиях ER-модели данных. К числу более сложных элементов моделиотносятся следующие:
· Подтипы исупертипы сущностей. Как в языках программирования с развитыми типовымисистемами (например, в языках объектно-ориентированного программирования),вводится возможность наследования типа сущности, исходя из одного илинескольких супертипов. Интересные нюансы связаны с необходимостью графическогоизображения этого механизма.
· Связи«many-to-many». Иногда бывает необходимо связывать сущности такимобразом, что с обоих концов связи могут присутствовать несколько экземпляровсущности (например, все члены кооператива сообща владеют имуществомкооператива). Для этого вводится разновидность связи«многие-со-многими».
· Уточняемыестепени связи. Иногда бывает полезно определить возможное количествоэкземпляров сущности, участвующих в данной связи (например, служащемуразрешается участвовать не более, чем в трех проектах одновременно). Длявыражения этого семантического ограничения разрешается указывать на конце связиее максимальную или обязательную степень.
· Каскадныеудаления экземпляров сущностей. Некоторые связи бывают настолько сильными(конечно, в случае связи «один-ко-многим»), что при удалении опорногоэкземпляра сущности (соответствующего концу связи «один») нужноудалить и все экземпляры сущности, соответствующие концу связи«многие». Соответствующее требование «каскадного удаления»можно сформулировать при определении сущности.
· Домены. Как и вслучае реляционной модели данных бывает полезна возможность определенияпотенциально допустимого множества значений атрибута сущности (домена).
Эти и другие более сложные элементы модели данных«Сущность-Связи» делают ее существенно более мощной, но одновременнонесколько усложняют ее использование. Конечно, при реальном использованииER-диаграмм для проектирования баз данных необходимо ознакомиться со всемивозможностями.
Сущность может быть расщеплена на два или болеевзаимно исключающих подтипа, каждый из которых включает общие атрибуты и/илисвязи. Эти общие атрибуты и/или связи явно определяются один раз на болеевысоком уровне. В подтипах могут определяться собственные атрибуты и/или связи.В принципе подтипизация может продолжаться на более низких уровнях, но опытпоказывает, что в большинстве случаев оказывается достаточно двух-трех уровней.
Сущность, на основе которой определяются подтипы,называется супертипом. Подтипы должны образовывать полное множество, т.е. любойэкземпляр супертипа должен относиться к некоторому подтипу. Иногда для полнотыприходится определять дополнительный подтип ПРОЧИЕ.
Пример: Супертип ЛЕТАТЕЛЬНЫЙ АППАРАТ
/>
Как полагается это читать? От супертипа: ЛЕТАТЕЛЬНЫЙАППАРАТ, который должен быть АЭРОПЛАНОМ, ВЕРТОЛЕТОМ, ПТИЦЕЛЕТОМ или ДРУГИМЛЕТАТЕЛЬНЫМ АППАРАТОМ. От подтипа: ВЕРТОЛЕТ, который относится к типуЛЕТАТЕЛЬНОГО АППАРАТА. От подтипа, который является одновременно супертипа:АЭРОПЛАН, который относится к типу ЛЕТАТЕЛЬНОГО АППАРАТА и должен быть ПЛАНЕРОМили МОТОРНЫМ САМОЛЕТОМ.
Иногда удобно иметь два или более разных разбиениясущности на подтипы. Например, сущность ЧЕЛОВЕК может быть разбита на подтипыпо профессиональному признаку (ПРОГРАММИСТ, ДОЯРКА и т.д.), а может — пополовому признаку (МУЖЧИНА, ЖЕНЩИНА).
2.5. Получение реляционной схемы из ER-схемы
Шаг 1. Каждая простая сущность превращается в таблицу.Простая сущность — сущность, не являющаяся подтипом и не имеющая подтипов. Имясущности становится именем таблицы.
Шаг 2. Каждый атрибут становится возможным столбцом стем же именем; может выбираться более точный формат. Столбцы, соответствующиенеобязательным атрибутам, могут содержать неопределенные значения; столбцы,соответствующие обязательным атрибутам, — не могут.
Шаг 3. Компоненты уникального идентификатора сущностипревращаются в первичный ключ таблицы. Если имеется несколько возможныхуникальных идентификатора, выбирается наиболее используемый. Если в составуникального идентификатора входят связи, к числу столбцов первичного ключадобавляется копия уникального идентификатора сущности, находящейся на дальнемконце связи (этот процесс может продолжаться рекурсивно). Для именования этихстолбцов используются имена концов связей и/или имена сущностей.
Шаг 4. Связи многие-к-одному (и один-к-одному)становятся внешними ключами. Т.е. делается копия уникального идентификатора сконца связи «один», и соответствующие столбцы составляют внешнийключ. Необязательные связи соответствуют столбцам, допускающим неопределенныезначения; обязательные связи — столбцам, не допускающим неопределенныезначения.
Шаг 5. Индексы создаются для первичного ключа(уникальный индекс), внешних ключей и тех атрибутов, на которых предполагаетсяв основном базировать запросы.
Шаг 6. Если в концептуальной схеме присутствовалиподтипы, то возможны два способа:
· все подтипы водной таблице (а)
· для каждогоподтипа — отдельная таблица (б)
При применении способа (а) таблица создается длянаиболее внешнего супертипа, а для подтипов могут создаваться представления. Втаблицу добавляется по крайней мере один столбец, содержащий код ТИПА; онстановится частью первичного ключа.
При использовании метода (б) для каждого подтипапервого уровня (для более нижних — представления) супертип воссоздается спомощью представления UNION (из всех таблиц подтипов выбираются общие столбцы — столбцы супертипа).
Все в одной таблице
Таблица — на подтип
Преимущества
Все хранится вместе
Легкий доступ к супертипу и подтипам
Требуется меньше таблиц
Более ясны правила подтипов
Программы работают только с нужными таблицами
Недостатки
Слишком общее решение
Требуется дополнительная логика работы с разными наборами столбцов и разными ограничениями
Потенциальное узкое место (в связи с блокировками)
Столбцы подтипов должны быть необязательными
В некоторых СУБД для хранения неопределенных значений требуется дополнительная память
Слишком много таблиц
Смущающие столбцы в представлении UNION
Потенциальная потеря производительности при работе через UNION
Над супертипом невозможны модификации
Шаг 7. Имеется два способа работы при наличииисключающих связей:
· общий домен (а)
· явные внешние ключи(б)
Если остающиеся внешние ключи все в одном домене, т.е.имеют общий формат (способ (а)), то создаются два столбца: идентификатор связии идентификатор сущности. Столбец идентификатора связи используется дляразличения связей, покрываемых дугой исключения. Столбец идентификаторасущности используется для хранения значений уникального идентификатора сущностина дальнем конце соответствующей связи.
Если результирующие внешние ключи не относятся кодному домену, то для каждой связи, покрываемой дугой исключения, создаютсяявные столбцы внешних ключей; все эти столбцы могут содержать неопределенныезначения.
Общий домен
Явные внешние ключи
Преимущества Нужно только два столбца Условия соединения — явные
Недостатки Оба дополнительных атрибута должны использоваться в соединениях Слишком много столбцов
Альтернативные модели сущностей:
Вариант 1 (плохой)
/>
Вариант 2 (существенно лучше, если подтипыдействительно существуют)
/>
Вариант 3(годится при наличии осмысленного супертипа D).
/>
ЗАКЛЮЧЕНИЕ
При проектировании базы данных решаютсядве основных проблемы:
1. Каким образом отобразить объектыпредметной области в абстрактные объекты модели данных, чтобы это отображениене противоречило семантике предметной области и было по возможности лучшим(эффективным, удобным и т.д.)? Часто эту проблему называют проблемой логическогопроектирования баз данных.
2. Как обеспечить эффективность выполнения запросов кбазе данных, т.е. каким образом, имея в виду особенности конкретной системыуправления базами данных, расположить данные во внешней памяти, создание какихдополнительных структур (например, индексов) потребовать и т.д.? Эту проблемуназывают проблемой физического проектирования баз данных.
Проблема проектирования реляционной базы данныхсостоит в обоснованном принятии решений о том, из каких отношений должнасостоять база данных и какие атрибуты должны быть у этих отношений.
СПИСОКЛИТЕРАТУРЫ
1. ГончаровА. «Microsoft Access ХР». – СПб: Питер, 2003
2. ГоревА., Макашарипов С, Ахаян Р. Эффективная работа с СУБД. СПб, «Питер», 2002
3. ДжексонГ. Проектирование реляционнных баз данных для использования с ЭВМ: Перевод санглийского. М.: Мир, 1991,
4. КирийВ.Г. Информатика. Учебное пособие – Иркутск: ИрГТУ, 1998
5. КовалевскаяЕ.В., Волосков Н.И., Григоренко Г.П., Желнинский Г.С., Технология реализации наЭВМ регламентных задач АСУ — М.: 1983
6. ЛомтадзеВ.В., Шишкина Л.П. Информатика. Учебное пособие. Иркутск: ИрГТУ, 1999
7. ПодольскийВ.И., Григоренко Г.П., Щербакова Н.С., Дик В.В. Обработка учетной информации наПЭВМ — М.: МЭСИ, 1993
8. ПотапкинА.В. MS Visual Basic дляпакета Microsoft Office. М, «Эком», 2004
9. СимоновичС.В. и др. Информатика. Базовый курс – СПб: Издательство «Питер», 2003