Тема 5. Проектирование баз данных

МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
Тема 5. Проектирование баз данных
Цель: изучить процесс проектирования баз данных.
Задачи:
 изучить общие вопросы процесса проектирования БД и принципы системного
анализа, которые используются при проектировании баз данных;
 изучить процедуру нормализации при проектировании реляционной БД;
 изучить язык описания данных (DDL) и принципы задания ограничений
в реляционной модели данных.
Оглавление
5.1. Общие вопросы проектирования БД. Системный анализ................................. 1
5.1.1. Системный анализ предметной области ........................................................ 1
5.2. Понятие целостности БД, язык описания данных ............................................ 7
5.3. Язык описания данных (DDL). Операторы создания таблиц (CREATE TABLE) . 8
5.4. Инфологическое проектирование баз данных, модель «Сущность–связь» .. 10
5.5. Правила перехода от ER-модели к реляционной модели ............................... 11
5.6. Современное состояние процесса проектирования БД .................................. 12
Вопросы для самопроверки .................................................................................. 12
5.1. Общие вопросы проектирования БД. Системный
анализ
Процесс проектирования БД представляет собой последовательность переходов
от неформального словесного описания информационной структуры предметной
области к формализованному описанию объектов предметной области в терминах
некоторой формальной модели. В общем случае можно выделить следующие этапы
проектирования:
 словесное описание информационных объектов предметной области;
 проектирование инфологической модели предметной области —
частично
формализованное описание объектов предметной области в терминах некоторой
инфологической модели, например в терминах ER (Entity RelationShip)-модели;
 даталогическое или логическое проектирование БД, т. е. описание БД в терминах
принятой даталогической модели данных;
 физическое
проектирование
БД,
т. е. выбор
эффективного
размещения
БД на внешних носителях для обеспечения наиболее эффективной работы
приложения.
5.1.1. Системный анализ предметной области
Любому процессу проектирования всегда предшествует системный анализ, целью
которого является анализ собственно задачи и выбор адекватных методов
ее решения. При проектировании баз данных существует два диаметрально
противоположных подхода: функциональный и предметный.
Функциональный подход реализует принцип движения «от задач» и применяется
тогда, когда заранее известны функции некоторой группы лиц и (или комплексов)
задач, для обслуживания информационных потребностей которых создается
рассматриваемая БД.
1
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
Предметный подход применяется тогда, когда информационные потребности
будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными
и весьма динамичными. В предметной области в этом случае включаются такие
объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для
нее. БД, конструируемая при этом, называется предметной, т. е. она может быть
использована при решении множества разнообразных, заранее не определенных
задач. Конструирование предметной БД в некотором смысле кажется гораздо более
заманчивым,
однако
трудность
всеобщего
охвата
предметной
области
с невозможностью конкретизации конкретных потребностей пользователей может
привести к избыточно сложной схеме БД, которая для конкретных задач будет
неэффективной.
На практике чаще всего используется некоторый
объединяющий ранее рассмотренные подходы.
компромиссный
подход,
В любом случае результатом системного анализа будет первоначальное описание
набора объектов предметной области, пригодное для применения дальнейших шагов
проектирования. Одной из наиболее важных в процессе проектирования является
процедура
нормализации,
которая
может
быть
отнесена
как
к уровню
инфологического проектирования, так и к уровню даталогического проектирования
в рамках реляционной модели данных.
Нормализация в реляционных базах данных. В реляционных БД даталогическое
проектирование приводит к разработке схемы БД, т. е. совокупности схем отношений,
которые адекватно моделируют абстрактные объекты предметной области
и семантические связи между этими объектами. Основой анализа корректности схемы
являются так называемые функциональные зависимости между атрибутами
БД. Некоторые функциональные зависимости являются нежелательными из-за
побочных эффектов и аномалий, которые они вызывают при модификации
БД. Поэтому возникает вопрос о корректности схемы БД.
Корректной схемой БД называется схема БД, в которой отсутствуют нежелательные
функциональные зависимости.
Процесс разработки корректной схемы реляционной БД называется логическим
проектированием БД.
Проектирование схемы БД может быть выполнено двумя путями:
 путем
декомпозиции (разбиения), когда исходное множество отношений,
входящих в схему БД заменяется другим множеством отношений (число их при
этом возрастает), являющихся проекциями исходных отношений;
 путем синтеза, т. е. компоновки из заданных исходных элементарных
зависимостей схемы БД.
В теории реляционных баз данных выделяют 6 нормальных форм, которые имеют
специальные названия:






первая нормальная форма (1NF);
вторая нормальная форма (2NF);
третья нормальная форма (3NF);
нормальная форма Бойса–Кодда (BCNF);
четвертая нормальная форма (4NF);
пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).
Схемы БД называются эквивалентными, если содержание исходной БД может быть
получено путем естественного соединения отношений, входящих в результирующую
схему и при этом не появляется новых кортежей в исходной БД.
Приведем ряд основных определений.
2
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
Функциональной зависимостью набора атрибутов
атрибутов A того же отношения, обозначаемой как
В отношения
R от набора
R.A -> R.B или A -> B,
называется такое соотношение проекций R[A] и R[B], при котором в каждый момент
времени любому элементу проекции R[A] соответствует только один элемент
проекции
R[B],
входящий
вместе
с
ним
в
какой-либо
кортеж
отношения R. Функциональная зависимость R.A -> R.B называется полной, если набор
атрибутов B функционально зависит от A и не зависит функционально от любого
подмножества A, т. е. R.A -> R.B называется полной, если A1  A  R.A1  /  R.B,
что читается следующим образом: для любого A1, являющегося подмножеством А, R.B
функционально не зависит от R.A1, в противном случае зависимость R.A -> R.B
называется неполной.
Функциональная зависимость R.A -> R.B называется транзитивной, если существует
набор атрибутов С такой, что




С не является подмножеством А;
С не включает в себя В, существует функциональная зависимость R.A -> R.C;
не существует функциональной зависимости R.С -> R.А;
существует функциональная зависимость R.С -> R.В.
Возможным ключом отношения называется набор атрибутов отношения, который
полностью и однозначно (функционально полно) определяет значения всех
остальных атрибутов отношения.
Неключевым, или непервичным атрибутом, называется любой атрибут отношения,
не входящий в состав ни одного возможного ключа отношения.
Взаимнонезависимые атрибуты —
функционально один от другого.
это
такие
атрибуты,
которые
не зависят
Среди всех возможных ключей отношения обычно выбирают один, который
называют первичным ключом отношения.
Если в отношении существует несколько функциональных зависимостей, то каждый
атрибут или набор атрибутов, от которого зависит другой атрибут, называется
детерминантом отношения.
1. Отношение находится в 1-й нормальной форме тогда и только тогда, когда
на пересечении каждого столбца и каждой строки находятся только элементарные
значения атрибутов.
Соответственно ненормализованные отношения, могут интерпретироваться как
таблицы с неравномерным заполнением, например таблица «Расписание», которая
имеет следующий вид:
Расписание
Преподаватель День
недели
Петров В.И
Понед.
Вторник
Вторник
Киров В.А.
Понед.
Вторник
Вторник
Номер
пары
1
1
2
2
3
4
Название
дисциплины
Теор. выч. проц.
Комп. графика
Комп. графика
Теор.информ.
Пр-е на С++
Пр-е на С++
3
Тип занятий
Группа
Лекция
Лаб.раб
Лаб.раб
Лекция
Лаб.раб
Лаб.раб
4906
4907
4906
4906
4907
4906
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
Минин А.А.
Понед.
Среда
Четверг
3
3
4
Защита инф.
Пр-е на VB
Пр-е на VB
Лекция
Лаб.раб
Лаб.раб
4944
4942
4922
Для приведения отношения «Расписание» к 1-й нормальной форме необходимо
дополнить каждую строку фамилией преподавателя.
Расписание
Преподаватель День
недели
Петров В.И
Понед.
Петров В.И
Вторник
Петров В.И
Вторник
Киров В.А.
Понед.
Киров В.А.
Вторник
Киров В.А.
Вторник
Минин А.А.
Понед.
Минин А.А.
Среда
Минин А.А.
Четверг
Номер
пары
1
1
2
2
3
4
3
3
4
Название
дисциплины
Теор.выч. проц.
Комп. графика
Комп. графика
Теор.информ.
Пр-е на С++
Пр-е на С++
Защита инф.
Пр-е на VB
Пр-е на VB
Тип занятий
Группа
Лекция
Лаб.раб
Лаб.раб
Лекция
Лаб.раб
Лаб.раб
Лекция
Лаб.раб
Лаб.раб
4906
4907
4906
4906
4907
4906
4944
4942
4922
2. Отношение находится во 2-й нормальной форме тогда и только тогда, когда оно
находится в первой нормальной форме и не содержит неполных функциональных
зависимостей непервичных атрибутов от атрибутов первичного ключа.
Рассмотрим пример отношения, которое моделирует сдачу студентами сессионных
экзаменов. При этом предполагается, что в отношении находятся только
результирующие оценки по дисциплинам, которые будут включены в академическую
выписку как приложение к диплому.
R<ФИО, Номер зач.кн., Группа, Дисциплина, оценка>
Первичным ключом отношения является набор из двух атрибутов <Номер зачетной
книжки,
Дисциплина>.
Однако
если
мы проанализируем
функциональные
зависимости, то увидим, что такие атрибуты, как «ФИО», «Группа» зависят только
от части первичного ключа, а именно от атрибута «Номер зач. кн.». И в этом случае
мы имеем неполные функциональные зависимости
Номер зач. кн.-> Группа
Номер зач. кн.->ФИО
И в этом случае для приведения ко 2-й нормальной форме надо разбить исходное
отношение на 2 со следующими схемами:
R1<ФИО,Номер.зач.кн.,Группа>
R2<Номер зач.кн.,Дисциплина,Оценка>
3. Отношение находится в 3-й нормальной форме тогда и только тогда, когда оно
находится во 2-й нормальной форме и не содержит транзитивных зависимостей.
Рассмотрим отношение, соответствующее описанию студента в некотором вузе.
R<ФИО,Номер.зач.кн.,Группа,Факультет,Специальность,Выпускающая кафедра>.
Первичным ключом отношения является номер зачетной книжки, поэтому резонно
предположить, что существуют следующие функциональные зависимости:
Номер.зач.кн. -> ФИО
4
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
Номер.зач.кн. -> Группа
Номер.зач.кн. -> Факультет
Номер.зач.кн. -> Специальность
Номер.зач.кн. -> Выпускающая кафедра
Кроме того, из анализа реальных учебных заведений известно, что все студенты
одной группы учатся на одном факультете и по одной специальности. Кроме того,
можем предположить, что для группы существует одна выпускающая кафедра. В этом
случае мы имеем дополнительно следующие функциональные зависимости:
Группа -> Факультет
Группа -> Специальность
Группа -> Выпускающая кафедра
Выпускающая кафедра -> Факультет
И эти зависимости образуют транзитивные группы зависимостей. Чтобы избежать
этого, мы можем предложить следующий набор отношений:
R1<Номер.зач.кн.,ФИО,Специальность,Группа>
R2<Группа,Выпускающая кафедра)>
R3(Выпускащая кафедра,Факультет)
4. Отношение находится в нормальной форме Бойса–Кодда, если оно находится в 3й нормальной форме и каждый детерминант отношения является возможным
ключом отношения.
Отношение, которое моделирует сдачу текущей сессии имеет следующую структуру:
<ФИО, Номер зач.кн., Идентификатор студента, Дисциплина, Дата, Оценка>
Если считать, что «Номер зач. кн.» и «Идентификатор студента» однозначно
характеризуют его, то мы имеем два возможных ключа:
Идентификатор студента, Дисциплина
Номер зач.кн., Дисциплина
Кроме того, у нас существует 2 тривиальные функциональные зависимости:
Номер зач.кн.-> ФИО
Идентификатор-> ФИО
Значит это отношение находится в 3-й нормальной форме, но не находится в форме
Бойса–Кодда. Для того, чтобы привести это отношение к нормальной форме Бойса–
Кодда необходимо провести его декомпозицию следующим образом:
R1<Номер зач.кн.,ФИО>
R2<Идентификатор, Номер зач.кн.>
R3<Идентификатор, Дисциплина, Дата, Оценка>
Нормальные формы высших порядков связаны с наличием многозначных
зависимостей. Многозначные зависимости, обозначаемые как A->>B, — это
устойчивые соотношения между значениями атрибутов A и B, когда одному значению
атрибута A соответствует некоторое устойчивое множество значений атрибута B.
Рассмотрим следующий пример. Пусть требуется учитывать данные о сдаче
лабораторных работ по некоторому предмету группой студентов. Каждый студент
должен сдать все лабораторные работы по всем предметам, которые ему назначены.
5
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
При этом считаем, что существует некоторый учебный план, в котором дан перечень
предметов, которые группа должна проходить, а по каждому предмету необходимо
сдать заданный перечень лабораторных работ.
Имеем отношение «Планирование занятий»
Студент
Иванов
Иванов
Иванов
Иванов
Иванов
Петров
Петров
Петров
Петров
Группа
121
121
121
121
121
122
122
122
122
Предмет
БД
БД
Сети
Сети
Сети
БД
БД
ОС
ОС
Номер лабораторной
ЛР-1
ЛР-2
ЛР-1
ЛР-2
ЛР-2
ЛР-1
ЛР-2
ЛР-1
ЛР-2
В этом отношении 2 многозначных функциональных зависимости:
Группа ->> Предмет
Предмет->> Номер лабораторной работы.
При добавлении нового студента у нас возникают проблемы: мы должны добавить
ему полный перечень предметов и полный перечень лабораторных работ. Для
разрешения этих проблем необходимо провести декомпозицию данного отношения
на следующие проекции.
Группы
Студент Группа
Учебный план
Группа Предмет
Иванов 121
Петров 122
121
121
122
122
БД
Сети
БД
ОС
Практика
Предмет Номер
лабораторной
БД
ЛР-1
БД
ЛР-2
Сети
ЛР-1
Сети
ЛР-2
Сети
ЛР-3
ОС
ЛР-1
ОС
ЛР-2
Теперь в каждом отношении у нас присутствует только одна многозначная
зависимость, поэтому можно утверждать, что отношение находится в 4-й нормальной
форме.
Декомпозиция
отношения
R на проекции
R1=R[X,Y]
и R2=R[X,Z]
будет
декомпозицией без потерь тогда и только тогда, когда имеется многозначная
зависимость X->>Y|Z.
5. Отношение R находится в 4-й нормальной форме тогда и только тогда, когда
отношение
находится
в нормальной
форме
Бойса–Кодда
и не содержит
нетривиальных многозначных зависимостей.
Функциональные и многозначные зависимости позволяют произвести декомпозицию
исходного отношения без потерь на две проекции. Можно, однако, привести примеры
отношений, которые нельзя декомпозировать без потерь ни на какие две проекции.
Рассмотрим следующее отношение R.
6
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
R
R[X,Y]
R[X,Z]
R[Y,Z]
X
Y
Z
X
Y
X
Z
Y
Z
1
1
2
1
1
1
2
1
2
1
2
1
1
2
2
1
2
1
1
2
1
1
1
1
1
1
Как легко заметить, отношение R не восстанавливается ни по одному из попарных
соединений R1JOIN R2, R1JOIN R3 или R2JOIN R3. Действительно, соединение R1JOIN
R2 имеет следующий вид.
X
Y
Z
1
1
2
1
1
1
1
2
2
1
2
1
2
1
1
Можно предположить, что отношение R удовлетворяет следующей зависимости
соединения: *(XY,XZ,YZ).
6. Отношение R не находится в 5-й нормальной форме, если в отношении найдется
нетривиальная зависимость соединения.
Отношение R находится в 5-й нормальной форме тогда и только тогда, когда любая
имеющаяся зависимость соединения является тривиальной.
В нашем случае набор из трех проекций и соответствует 5-й нормальной форме
отношения R.
5.2. Понятие целостности БД, язык описания данных
Одним из основополагающих понятий в технологии баз данных является понятие
целостности. В общем случае это понятие связано с тем, что база данных отражает
в информационном виде некоторый объект реального мира или совокупность
взаимосвязанных объектов реального мира. В реляционной модели объекты
реального мира представлены в виде совокупности взаимосвязанных отношений. Под
целостностью будем понимать соответствие информационной модели предметной
области, хранимой в базе данных, объектам реального мира и их взаимосвязям
в каждый момент времени.
Любое изменение в предметной области, значимое для построенной модели, должно
отражаться в базе данных, и при этом должна сохраняться однозначная
интерпретация информационной модели в терминах предметной области.
Поддержка
целостности
в реляционной
понимании включает в себя 3 аспекта.
7
модели
данных
в ее классическом
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
Во-первых, это поддержка структурной целостности, которая заключается в том, что
реляционная СУБД должна допускать работу только с однородными структурами
данных типа «реляционное отношение». При этом понятие реляционного отношения
должно удовлетворять всем ограничениям, накладываемым на него в классической
теории реляционной БД (отсутствие дубликатов кортежей, обязательное наличие
первичного ключа, отсутствие упорядоченности кортежей).
Во-вторых, это поддержка языковой целостности, которая состоит в том, что
реляционная СУБД должна обеспечивать языки описания и манипулирования
данными не ниже стандарта SQL. Не должны быть доступны иные низкоуровневые
средства манипулирования данными, не соответствующие стандарту.
В-третьих, это поддержка ссылочной целостности (Declarative Referential Integrity,
DRI), что означает обеспечение одного из заданных принципов взаимосвязи между
экземплярами кортежей взаимосвязанных отношений:
 кортежи подчиненного отношения уничтожаются при удалении кортежа основного
отношения, связанного с ними;
 кортежи основного отношения модифицируются при удалении кортежа основного
отношения, связанного с ними, при этом на месте ключа родительского отношения
ставится неопределенное Null значение.
Ссылочная целостность обеспечивает поддержку непротиворечивого состояния
БД в процессе модификации данных при выполнении операций добавления или
удаления.
Структурная, языковая и ссылочная целостность определяют правила работы СУБД
с реляционными структурами данных. Требования поддержки этих трех видов
целостности говорят о том, что каждая СУБД должна уметь это делать, а разработчики
должны это учитывать при построении баз данных с использованием реляционной
модели.
Кроме указанных ограничений целостности, которые в общем виде не определяют
семантику БД, вводится понятие семантической поддержки целостности. Методы
поддержки семантической целостности определяют возможность учета ограничений,
которые связаны непосредственно с содержанием БД.
Для реляционной
модели данных к методам поддержки семантической целостности относятся
декларативные
ограничения
на значения
атрибутов
некоторого
отношения
и ограничения на значения кортежей некоторого отношения. Кроме того, к методам
поддержки семантической целостности относятся методы анализа изменений,
вносимых в БД. Эти методы связаны с возможностью применения механизма
триггеров и будут рассмотрены далее.
5.3. Язык описания данных (DDL). Операторы создания
таблиц (CREATE TABLE)
Процесс создания таблицы включает следующие действия:



задать имя таблицы;
задать перечень столбцов с указанием типов данных;
для каждого столбца задать ограничения:
o принадлежность к первичному ключу,
o допустимость неопределенных значений,
o наличие некоторых ограничений на значения столбца,
o существование значений по умолчанию, т. е. тех, которые вводятся, если
в операторе ввода отсутствует конкретное значение,
o принадлежность к внешнему ключу.
8
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE

задать общие ограничения на таблицу.
Оператор создания таблицы:
CREATE TABLE <имя таблицы>
(<определение столбца1>[, <определение
на таблицу1>][,<ограничение на таблицу2>]...)
столбца2>,
...][,
<ограничение
<определение столбца>::= <имя столбца> <тип данных>
[<ограничение на обязательность >,][<ограничение уникальности>,]
[<ограничение значения по умолчанию>,][<ограничение на значение>]
[, <ограничение по ссылкам>]
<тип данных>::= integer | smallint | char(n)| varchar(n)| datatime | ...
<ограничение на обязательность>::= NOT NULL | NULL
Если значения в столбце необязательны, то необходимо указать признак NULL
допустимости неопределенных значений, в противном случае требуется указать NOT
NULL. По умолчанию используется свойство NULL для всех столбцов, кроме
возможных ключей.
<ограничение значения по умолчанию>::=DEFAULT { const | function() }
При задании значения по умолчанию разрешается задать некоторое константное
значение (const) или применить функцию, значение которой может быть определено
в любой момент времени.
<ограничение уникальности>::= UNIQUE | PRIMARY KEY
Ограничение уникальности не допускает повторения значений в данном столбце.
Если столбец является первичным ключом, то к нему автоматически применяется
свойство уникальности. Если же столбец является возможным ключом, то для
контроля неповторяемости значений необходимо ему задать свойство уникальности
UNIQUE.
<ограничение на значение>::= CHECK (<условие проверки>)
В качестве условия проверки используется логическое выражение, которое
принимает значение «истина» в случае ввода допустимого значения и «ложь»
в противном случае.
<Ограничение по ссылкам>::= FOREIGN KEY <имя родительской таблицы> (<имя
столбца в родительской таблице>)
Ограничение по ссылкам определяет моделирование связи между таблицами
Ограничения на таблицу задаются тогда, когда невозможно задать данное
ограничение на уровне одного столбца. Например, если первичный ключ состоит
из нескольких атрибутов, то невозможно определить это ограничение на уровне
одного столбца. В этом случае данное ограничение задается после описания всех
столбцов отдельным ограничением. Все ограничения на уровне таблицы могут иметь
тип и специальное имя. Тип ограничений на уровне таблицы: PRIMARY KEY, FOREIGN
KEY, CHECK,UNIQUE.
Синтаксис ограничения на уровне таблицы:
Constraint <имя ограничения> <тип ограничения> (выражение).
Например, если мы имеем ограничение типа первичный ключ, то это может быть
представлено следующим образом:
9
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
Constraint PK_EX PRIMARY KEY (ISBN,INV_NUM) — это означает, что у нас составной
первичный ключ, который имеет 2 атрибута с именами ISBN и INV_NUM.
5.4. Инфологическое проектирование баз данных, модель
«Сущность–связь»
Инфологическая модель иногда называется ER-моделью, что является сокращением
названия Entity RelationShip, принятого для именования данного типа инфологической
модели. Впервые эта модель была предложена американским математиком Ченом,
но в последние годы получила развитие и расширение.
Сущность описывает класс однотипных объектов
Графически сущность изображается в виде прямоугольника, в верхней части
которого записано имя сущности, а в середине размещены свойства или атрибуты
сущности (рис. 5.1).
Рис. 5.1. Сущность «Студент»
Экземпляр сущности — объект из данного класса.
Для различения отдельных экземпляров сущности они должны иметь уникальный
идентификатор — набор атрибутов или свойств сущности, который однозначно
определяет конкретный экземпляр. Этот набор свойств сущности называют
возможным ключом сущности (по аналогии с отношением). В общем случае
у сущности может быть несколько возможных ключей и один из них назначают
первичным ключом сущности. Графически первичный ключ выделяется либо жирным
шрифтом, либо подчеркиванием.
Между сущностями могут быть заданы связи. Связь графически обозначается
линией, соединяющей изображения сущностей. Связи в модели «Сущность–связь»
определяют принципы взаимосвязи отдельных экземпляров связываемых сущностей.
По типам
взаимосвязей
они
делятся
на обязательные
и необязательные,
а по мощности на связи типа «один к одному» (1:1), «один ко многим» (1:М)
и «многие ко многим» (М:М). Обязательность связи изображается вертикальной
чертой на противоположном конце связи и означает, что экземпляр рассматриваемой
сущности обязательно связан с одним или, может быть, несколькими экземплярами
сущности, находящейся на противоположном конце связи. Необязательная связь
обозначается пустым кружком на конце связи и означает, что экземпляр
рассматриваемой сущности может быть связан с «нулем» или одним или несколькими
экземплярами связываемой сущности.
Рассмотрим на примере связи сущности «Студент» и сущности «Сессия». Каждый
студент, сдавая сессию, получает определенные оценки по конкретным дисциплинам,
при этом если считать, что одну и ту же дисциплину студент может пересдавать
несколько раз, то первичным ключом экземпляра сущности «Сессия» будет набор
атрибутов «Дисциплина, Дата сдачи экзамена». Однако студенты первого курса еще
не сдавали в сессию ни одного экзамена, поэтому связь между сущностью «Студент»
и «Сессия» 1:М и необязательная со стороны «Студент», но обязательная со стороны
10
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
«Сессия», так как каждая оценка по конкретной дисциплине обязательно связана
с некоторым студентом (рис. 5.2).
Рис. 5.2. Связь 1:М между двумя сущностями
Между двумя сущностями может быть установлено сколько угодно связей. В общем
случае даже экземпляры одной сущности могут быть связаны друг с другом, в этом
случае связь называется рекурсивной.
5.5. Правила перехода от ER-модели к реляционной
модели
Каждой сущности ставится в соответствие отношение реляционной модели данных.
Имена отношений могут быть ограничены требованиями конкретной СУБД, чаще всего
эти имена являются идентификаторами в некотором базовом языке, они ограничены
по длине и не должны содержать пробелов и некоторых специальных символов.
Каждый атрибут сущности становится атрибутом соответствующего отношения.
Переименование атрибутов должно происходить в соответствии с теми же правилами,
что и переименование отношений. Для каждого атрибута задается конкретный
допустимый в СУБД тип данных и обязательность или необязательность данного
атрибута (т. е. допустимость или недопустимость NULL значений для него).
Первичный ключ сущности становится PRIMARY KEY соответствующего отношения.
Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство
обязательности (NOT NULL).
В каждое отношение, соответствующее подчиненной сущности, добавляется набор
атрибутов основной сущности, являющейся первичным ключом основной сущности.
В отношении, соответствующем подчиненной сущности, этот набор атрибутов
становится внешним ключом (FOREIGN KEY).
Для моделирования необязательного типа связи на физическом уровне у атрибутов,
соответствующих внешнему ключу, устанавливается свойство допустимости
неопределенных значений (признак NULL). При обязательном типе связи атрибуты
получают свойство отсутствия неопределенных значений (признак NOT NULL).
Для отражения категоризации сущностей при переходе к реляционной модели
возможны несколько вариантов представления. Возможно создать только одно
отношение для всех подтипов одного супертипа. При втором способе для каждого
подтипа и для супертипа создаются свои отдельные отношения. Кроме того, для
возможности переходов к подтипам от супертипа необходимо в супертип включить
идентификатор связи.
Разрешение
связей
типа
«многие
ко многим»:
введением
специального
дополнительного связующего отношения, которое связано с каждым исходным связью
«один ко многим». Атрибутами этого отношения являются первичные ключи
связываемых отношений.
11
МЕЖДУНАРОДНЫЙ БАНКОВСКИЙ ИНСТИТУТ
INTERNATIONAL BANKING INSTITUTE
5.6. Современное состояние процесса проектирования БД
Проектирование БД — это творческий процесс, и не существует полностью
формальных методов его выполнения. Он всегда связан с человеческим фактором,
опытом и логикой мышления.
В реальных проектах проект БД выполняется всегда с использованием CASE-систем
проектирования. Использование инструментария CASE-систем позволяет вести
описание проекта и обеспечить быстрый перенос на новую платформу (на новую
СУБД).
Проект БД всегда документируется.
Проект БД итерационный и может постепенно расширяться и дополняться.
Проект БД начинается с четкой формулировки целей проектируемой БД.
После формулировки целей выделяются основные информационные объекты,
которые оформляются как сущности в ER-модели.
При описании сущности:
рассматриваются неотъемлемые ее части;
выделяются характеристики, атрибуты;
определяется наличие первичного ключа;
в случае отсутствия явного первичного ключа рассматривается возможность ввода
суррогатного ключа или проверяется правильность выделения сущности как
класса однотипных объектов;
 проверяется зависимость неключевых атрибутов от атрибутов первичного ключа,
выясняется, есть ли неполные или транзитивные зависимости, и если они есть,
то сущность разбивается на несколько сущностей и выстраиваются связи между
ними;
 проверяется корректность модели только путем решения с использованием данной
БД возложенных на нее задач, т. е. путем моделирования основных алгоритмов
обработки данных.




Процедура нормализации, рассмотренная для реляционной модели справедлива
и для инфологической модели.
Вопросы для самопроверки
1. Зачем нужен процесс проектирования базы данных?
2. Почему проект базы данных может быть плохим?
3. Что необходимо анализировать при построении базы данных?
4. Дайте определение понятия «функциональная зависимость».
5. Может ли быть функциональная зависимость между двумя отношениями?
6. Может ли в одном отношении быть несколько функциональных зависимостей?
7. Могут ли функциональные зависимости изменяться с течением времени?
8. Могут ли
быть
транзитивные
функциональные
зависимости
в бинарных
отношениях?
9. Чем отличается функциональная зависимость от многозначной?
10. Повышает ли скорость обработки информации нормализация?
11. Каковы недостатки избыточности в базах данных?
12. Какие типы связей между сущностями допустимы в ER-модели?
12