Проектирование
базы данных
Карпова Т.С.
Проектирование БД
Процесс проектирования БД представляет
собой
последовательность переходов
от неформального словесного
описания информационной структуры
предметной области
к формализованному описанию
объектов предметной области в
терминах некоторой формальной
модели.
Этапы проектирования
Системный анализ,
Проектирование инфологической модели
результатом которого является словесное описание
предметной области –
информационных объектов предметной области
и связей между ними
даталогичеcкое
илиописание
логическое
частично
формализованное
объектов
проектирование
БД,некоторой
предметной
области в терминах
инфологической
физическое
проектирование
БД,
модели,
например
в терминах
ER - модели;
т.е.
описание
БД в терминах
принятой даталогической модели данных
т.е. выбор эффективного размещения БД на внешних
носителях для обеспечения наиболее
эффективной работы приложения.
Системный анализ
• существуют два подхода к выбору
состава и структуры предметной
области:
• Функциональный подход
• Предметный подход
Функциональный подход
реализует принцип движения
“ от задач”
и применяется тогда, когда заранее
известны функции некоторой
группы лиц и (или комплексов)
задач, для обслуживания
информационных потребностей
которых создается
рассматриваемая БД
Предметный подход:
Винформационные
предметной областипотребности
в этом случае
будущих
пользователей
БД
включаются такие объекты
жестко не фиксируются.
и взаимосвязи, которые наиболее
Они могут
быть и наиболее
характерны
многоаспектными
и
весьма
существенны для нее.
динамичными.
Проектирование схемы БД может
быть выполнено двумя путями:
• путем декомпозиции (разбиения),
когда исходное множество отношений,
входящих в схему БД заменяется другим
множеством отношений (число их при
этом возрастает), являющихся
проекциями исходных отношений;
• путем синтеза, т.е. путем компоновки
из заданных исходных элементарных
зависимостей схемы БД.
Процесс проектирования с
использованием декомпозиции
представляет собой процесс
последовательной нормализации
схем отношений, при этом каждая
последующая итерация
соответствует нормальной форме
более высокого уровня и обладает
лучшими свойствами по сравнению
с предыдущей.
Назначение нормализации
• Нормализация – это разбиение таблицы на
две или более, обладающих лучшими
свойствами при включении, изменении и
удалении данных.
• Окончательная цель нормализации
сводится к получению такого проекта базы
данных, в котором каждый факт
появляется лишь в одном месте, т.е.
исключена избыточность
информации.
• Это делается не с целью экономии
памяти, а для исключения возможной
противоречивости хранимых данных.
Нормализация
Каждой нормальной форме
соответствует некоторый
определенный набор
ограничений, и отношение
находится в некоторой нормальной
форме, если удовлетворяет
свойственному ей набору
ограничений.
Нормализация в процессе
проектирования БД
Процесс проектирования с
использованием декомпозиции
представляет собой
процесс последовательной
нормализации схем отношений,
при этом каждая последующая итерация
соответствует нормальной форме более
высокого уровня и обладает лучшими
свойствами по сравнению с предыдущей.
В теории реляционных БД обычно
выделяется следующая
последовательность нормальных форм:
•
•
•
•
•
•
первая нормальная форма (1NF);
вторая нормальная форма (2NF);
третья нормальная форма (3NF);
нормальная форма Бойса-Кодда
(BCNF);
четвертая нормальная форма
(4NF);
пятая нормальная форма или
форма проекции-соединения (5NF
или PJNF);
Основные свойства
нормальных форм:
• - каждая следующая нормальная
форма в некотором смысле
улучшает свойства предыдущей;
• - при переходе к следующей
нормальной форме свойства
предыдущих нормальных форм
сохраняются.
Основные понятия, используемые
при нормализации
• Возможным ключом отношения
называется набор атрибутов отношения,
который полностью и однозначно
(функционально полно) определяет
значения всех остальных атрибутов
отношения.
• Неключевым атрибутом называется
любой атрибут отношения, не входящий
в состав ни одного возможного ключа
отношения.
• Взаимно-независимые атрибуты это такие атрибуты, которые не зависят
функционально один от другого.
Основные понятия,
используемые при нормализации
• Среди всех возможных ключей
отношения обычно выбирают один,
который называют первичным
ключом отношения.
• Если в отношении существует
несколько функциональных
зависимостей, то каждый атрибут
или набор атрибутов, от которого
функционально зависит другой
атрибут называется
детерминантом отношения.
Первая нормальная форма
Отношение находится в первой
нормальной форме тогда и только
тогда, когда на пересечении любой
строки и любого столбца находятся
элементарные значения
атрибутов и ни одно из
значений атрибутов, входящих в
возможный ключ, не пусто
До нормализации
Преп.
Д.н
Группа
Ауд.
Дисц.
Т.зан
Карпова
П-к
18-21
Сб.
10-14
14-18
ПОПК-1
330
Лек.
ПОПК-1-1
ПОПК-1-2
215
БД и
СУБД
БД и
СУБД
БД и
СУБД
вт
18
Пт
ПОПК-2
324
ОС
Лек
Сети-1
322
Сети
Лек
Петров
215
Прак
Прак
После нормализации
Преп.
Д.н
Группа
Ауд.
Дисц.
Т.зан
Карпова
П-к
18-21
ПОПК-1
330
БД и
СУБД
Лек.
Карпова
Сб.
10-14
ПОПК-1-1
215
БД и
СУБД
Прак
Карпова
Сб14-18
ПОПК-1-2
215
БД и
СУБД
Прак
Петров
вт
18
ПОПК-2
324
ОС
Лек
Петров
Пт
18
Сети-1
322
Сети
Лек
Вторая нормальная форма
• Отношение находится во второй
нормальной форме тогда и только
тогда, когда оно находится в
первой нормальной форме и
неключевые атрибуты
функционально полно зависят от
атрибутов возможного ключа.
Определение:
• Атрибут функционально полно зависит
от некоторого набора атрибутов тогда,
когда он зависит от полного набора
атрибутов и A={A1,..,AN}
не зависит от любого
A->B – функционально полно
подмножества данного
набора
=>
атрибутов.
Ai A, Ai B
Исходное отношение
Преп.
Дол.
Уч.ст.
Группа Ауд.
Дисц.
Т.зан
Д. н.
Карпо
ва
доцент
К.т.н.
ПОПК1
330
БД и
СУБД
Лек.
П-к
18-21
Карпо
ва
доцент
К.т.н.
ПОПК1
215
БД и
СУБД
прак.
Сб.
10-14
Карпо
ва
доцент
К.т.н.
ПОПК1
215
БД и
СУБД
прак.
сб
14-18
Петров Проф.
Д.т.н.
ПОПК2
324
ОС
Лек
вт
18
БД во второй нормальной
форме
Преп.
Дол.
Уч.ст.
Преп.
Д.
н.
Гру
ппа
Карпова
доцент
К.т.н.
Карпова
Петров
Проф.
д.т.н.
П-к
1821
ПОП 33
К-1
0
БД и Лек.
СУБД
Карпова
Сб.
1014
ПОП 21
К-1- 5
1
БД и Пра
СУБД к
Карпова
Сб1
418
ПОП 21
К-1- 5
2
БД и Пра
СУБД к
Петров
вт
18
ПОП 32
К-2
4
ОС
Ау
д.
Дисц
.
Т.за
н
Лек
Третья нормальная форма
Отношение находится в третьей
нормальной форме тогда и
только тогда, когда оно
находится во второй нормальной
форме и
не содержит транзитивных
функциональных зависимостей
Определение
• Если A->B и
B->C и
С-/->A
ТО
A->C - транзитивно
Пример
• Есть отношение:
Дополнительные
функциональные зависимости:
№ЗК
ФИО Группа Факуль- Вып.
Группа->Факультет
тет
Каф.
Спец.
Группа-> Специальность
Есть Каф.->
основные
функциональные
Вып.
Факультет
зависимости -> Факультет
Специальность
• №ЗК -> ФИО
• №ЗК ->Группа
• №ЗКЕсть
->Факультет
транзитивные зависимости:
№ЗК->Группа->Факультет
• №ЗК ->Вып.каф.
• №ЗК№ЗК->Группа->Специальность
->Спец
Группа->Специальность->Факультет
БД в третьей нормальной
форме
R1
№ЗК
R2
R3
Группа
R4
ФИО
Группа
Специальность
№ЗК
Вып. каф.
Группа
Факультет
Нормальная форма БойсаКодда
Отношение находится в
нормальной форме Бойса-Кодда
тогда и только тогда, когда оно
находится в третьей нормальной
форме и каждый детерминант
отношения является
возможным ключом
Пример
Номер рейса
Тип самолета – является детерминантом,
Маршрут(начальный
пунктно
Не является
конечный
пункт)возможным ключом!!
Тип самолета
Количество мест
Наличные функциональные зависимости:
Номер рейса-> Маршрут
Номер рейса->
Тип самолета
Отношение
не находится
в форме БОЙСА-КОДДА
Номер рейса->Количество мест
Дополнительные
функциональные зависимости:
Тип самолета-> Количество мест
Многозначные зависимости
• A->>B зависит многозначно
Дисциплина->>Лаб.работы
Группа ->> Студент
Четвертая нормальная
форма
• Отношение находится в четвертой
нормальной форме тогда и только
тогда, когда у него присутствует
только одна многозначная
зависимость неключевых
атрибутов от атрибутов возможного
ключа, а все остальные
зависимости функциональные.
Пример
• <группа, Дисциплина,актив>
• Группа->> Дисциплина
• Группа ->> Актив
Пятая нормальная форма
• Отношение находится в 5-ой
нормальной форме, тогда и только
тогда, когда
любая имеющаяся зависимость
соединения является
тривиальной
Инфологическое
моделирование БД
• Для инфологического
моделирования используется
модель «Entity RelationShip » (ER) в русской интерпретации
«Сущность-связь»
• Инфологическая модель не зависит
от выбора конкретной СУБД
Базовые понятия ERмодели
• Класс однотипных объектов
моделируется некоторой
«Сущностью» (Entity)
• Каждая сущность имеет множество
свойств, называемых атрибутами
или характеристиками сущности
• Экземпляр сущности соответствует
некоторому одному объекту из
всего класса
Базовые понятия ERмодели
• Набор атрибутов, однозначно
характеризующий сущность
называется возможным ключом
сущности
• Среди всех возможных ключей
выбирается идентификатор или
первичный ключ сущности
Графическая
интерпретация
Студент
Номер зач_книжки
Фамилия
Имя
Отчес тво
Группа
<M>
пишет диплом по
Выделение сущностей
• Процесс в большей степени творческий
и интуитивный, чем формализованный.
• Однако есть несколько общих правил:
– Если атрибут сущности имеет ряд
повторяющихся значений для разных
экземпляров сущности и при этом этот ряд
может быть расширен в любое время – то
это признак выделения отдельной сущности
Пример
СКЛАД
Накладная номер <pi> <M>
Дата
название товара
марка товара
Поставщик
Производитель
количество
цена
Identifier_1 <pi>
Декомпозиция исходной
сущности
Товар
Идентификатор товара <pi> <M>
Название товара
Марка товара
Артикул товара
Документы
Номер накладной <pi>
Дата
количество
Identifier_1 <pi>
Identifier_1 <pi>
Поставщики
Идентификатор поставщика <pi> <M>
название поставщика
Адрес поставщика
телефон
Ответственное лицо
Банковские реквизиты
Identifier_1 <pi>
Производители
Идентификатор производителя <pi> <M>
название производителя
Страна
Identifier_1 <pi>
Дополнение сущностей
Товар
Идентификатор товара <pi> <M>
Название товара
Марка товара
Артикул товара
Документы
Номер накладной <pi>
Дата
количество
Identifier_1 <pi>
Identifier_1 <pi>
Операции
Идентификатор операции <pi> <M>
Название операции
Поставщики
Identifier_1 <pi>
Идентификатор поставщика <pi> <M>
название поставщика
Адрес поставщика
телефон
Ответственное лицо
Банковские реквизиты
Identifier_1 <pi>
Производители
Идентификатор производителя <pi> <M>
название производителя
Страна
Identifier_1 <pi>
Связи
• Между двумя сущностями могут
быть заданы в модели одна или
несколько связей.
• Связи определяют
информационное взаимодействие
экземпляров двух связываемых
сущностей.
Классификация связей
• По мощности связи бывают:
– 1:1 – «один к одному»
- 1:M - «один ко многим»
- M:M – «многие ко многим»
• По обязательности связи бывают:
– Обязательными
– Необязательными.
• По роли в первичном ключе:
– Ключевые
– Неключевые
Инфологическая модель
СКЛАД
Операции
Товар
Идентификатор товара <pi> <M>
Название товара
Марка товара
Артикул товара
Identifier_1 <pi>
Идентификатор операции <pi> <M>
Название операции
Identifier_1 <pi>
Relationship_2
Relationship_1
Документы
Номер накладной <pi>
Дата
количество
Поставщики
Идентификатор поставщика <pi>
название поставщика
Адрес поставщика
телефон
Ответственное лицо
Банковские реквизиты
Identifier_1 <pi>
Identifier_1 <pi>
Relationship_3
Relationship_4
Производители
Идентификатор производителя <pi> <M>
название производителя
Страна
Identifier_1 <pi>
Модификация модели
Операции
Идентификатор операции <pi> NO
Товар
Название операции
Идентификатор товара <pi> <UNDEF> <M>
Название товара
Марка товара
Артикул товара
<M>
<UNDEF>
Identifier_1 <pi>
<UNDEF>
<UNDEF>
<UNDEF>
Relationship_2
Identifier_1 <pi>
Relationship_1
Документы
Номер накладной <pi>
Контрагенты
Идентификатор поставщика <pi>
название поставщика
Адрес поставщика
телефон
Ответственное лицо
Банковские реквизиты
Relationship_3
Дата
количество
Identifier_1 <pi>
Relationship_4
Identifier_1 <pi>
Производители
Идентификатор производителя <pi> <UNDEF>
название производителя
Страна
Identifier_1 <pi>
<UNDEF>
<UNDEF>
Роли сущностей
Основная
(родитель
ская)
Ключевая связь
Подчиненн
ая
(дочерняя)
Правила перехода от ER-модели к
реляционной модели
Каждой сущности ставится в соответствие отношение
реляционной модели данных.
Каждый атрибут сущности становится атрибутом
соответствующего отношения. Для каждого атрибута
задается конкретный допустимый в СУБД тип данных
и обязательность или необязательность данного
атрибута (то есть допустимость или недопустимость
NULL значений для него).
Первичный ключ сущности становится PRIMARY KEY
соответствующего отношения. Атрибуты, входящие в
первичный ключ отношения, автоматически
получают свойство обязательности (NOT NULL).
Правила перехода от ER-модели к
реляционной модели (продолжение)
В каждое отношение, соответствующее подчиненной
сущности, добавляется набор атрибутов основной
сущности, являющийся первичным ключом основной
сущности. В отношении, соответствующем
подчиненной сущности, этот набор атрибутов
становится внешним ключом (FOREIGN KEY).
Для моделирования необязательного типа связи на
физическом уровне у атрибутов, соответствующих
внешнему ключу, устанавливается свойство
допустимости неопределенных значений (признак
NULL). При обязательном типе связи атрибуты
получают свойство отсутствия неопределенных
значений (признак NOT NULL).
Правила перехода от ER-модели к
реляционной модели (продолжение)
Для разрешения связей типа многие-ко-многим
вводится специальное дополнительное связующее
отношение, которое связано с каждым исходным
связью один-ко-многим, атрибутами этого
отношения являются первичные ключи
связываемых отношений.
Первичным ключом дополнительного отношения
становится совокупность первичных ключей
связываемых сущностей
Если связь ключевая, то внешний ключ становится
частью первичного ключа отношения,
соответствующего подчиненной сущности
Реляционная схема (физическая
модель данных)
Концептуальная модель БД
«Библиотека»
Conceptual Data Model
Model: Модель "Библиотека"
Package:
Diagram: LIBRARY
Author: Карпова Т.С. Date : 19.10.2006
Version : 02
Экземпляр
Инвентарный номер <pi> <M>
Присутствие
Книги
Дата взятия книги
в экземплярах
ISBN
<pi> <M>
Дата возврата книги
относятся к области знаний
Название книги
<M>
Год издания
<M>
Количество страниц
<M>
держит на руках
написали
Системный каталог
Читатель
Код области знаний
<pi> <M>
Наименование области знаний
Авторы
Идентификатор автора <pi> <M>
Фамилия
<M>
Имя
Отчество
Номер читательского билета <pi> <M>
Фамилия и инициалы читателя
Адрес
Домашний телефон
Рабочий телефон
Дата рождения
<M>
ER-модель «Библиотеки» с ключевой
связью
Conceptual Data Model
Model: Модель "Библиотека"
Package:
Diagram: LIBRARY
Author: Карпова Т.С. Date : 19.10.2006
Version : 02
Экземпляр
Инвентарный номер <pi> <M>
Присутствие
Книги
Дата взятия книги
в экземплярах
ISBN
<pi> <M>
Дата возврата книги
относятся к области знаний
Название книги
<M>
Год издания
<M>
Количество страниц
<M>
держит на руках
написали
Системный каталог
Читатель
Код области знаний
<pi> <M>
Наименование области знаний
Авторы
Идентификатор автора <pi> <M>
Фамилия
<M>
Имя
Отчество
Номер читательского билета <pi> <M>
Фамилия и инициалы читателя
Адрес
Домашний телефон
Рабочий телефон
Дата рождения
<M>
Физическая модель БД
(реляционная)
Physical Data Model
Model: Модель "Библиотека"
Package:
Diagram: LIBRARY
Author: Карпова Т.С. Date : 19.10.2006
Version : 02
относятся к области знаний
ISBN
varchar(16) <pk,fk1>
Код области знаний int
<pk,fk2>
Книги
Экземпляр
varchar(16) <pk>
Название книги
varchar(255)
Инвентарный номер
int
<pk>
Год издания
smallint
ISBN
varchar(16) <fk1>
FK_EXEMPLAR_BOOKS_EXE_BOOKS
Количество страниц smallint
Номер читательского билета int
<fk2>
Присутствие
char(1)
Дата взятия книги
datetime
Дата возврата книги
datetime
FK_BOOKS_CA_BOOKS_CAT_CATALOG
FK_RELATION_RELATION__BOOKS
FK_BOOKS_CA_BOOKS_CAT_BOOKS ISBN
написали
ISBN
varchar(16) <pk,fk1>
Идентификатор автора numeric
<pk,fk2>
Системный каталог
FK_EXEMPLAR_READER_EX_READER
Читатель
Код области знаний
int FK_RELATION_RELATION__AUTORS
<pk>
Наименование области знаний varchar(50)
Авторы
Идентификатор автора
Фамилия
Имя
Отчество
numeric <pk>
char(30)
char(30)
char(20)
Номер читательского билета
Фамилия и инициалы читателя
Адрес
Домашний телефон
Рабочий телефон
Дата рождения
int
<pk>
varchar(30)
varchar(40)
char(9)
char(9)
datetime
Physical Data Model
Model: Модель "Библиотека"2
Package:
Diagram: LIBRARY
Author: Карпова Т.С. Date : 19.10.2006
Version : 02
относятся к области знаний
Экземпляр
ISBN
varchar(16) <pk,fk1>
Код области знаний int
<pk,fk2>
ISBN
Инвентарный номер
Номер читательского билета
Присутствие
Книги
FK_EXEMPLAR_BOOKS_EXE_BOOKS
Дата взятия книги
ISBN
varchar(16) <pk>
FK_BOOKS_CA_BOOKS_CAT_BOOKS
Дата возврата книги
Название книги
varchar(255)
Год издания
smallint
Количество страниц smallint
FK_BOOKS_CA_BOOKS_CAT_CATALOG
FK_RELATION_RELATION__BOOKS
varchar(16) <pk,fk1>
int
<pk>
int
<fk2>
char(1)
datetime
datetime
FK_EXEMPLAR_READER_EX_READER
написали
ISBN
varchar(16) <pk,fk1>
Идентификатор автора numeric
<pk,fk2>
Системный каталог
FK_RELATION_RELATION__AUTORS
Код области знаний
int
<pk>
Наименование области знаний varchar(50)
Авторы
Идентификатор автора
Фамилия
Имя
Отчество
numeric <pk>
char(30)
char(30)
char(20)
Читатель
Номер читательского билета int
<pk>
Фамилия и инициалы читателя varchar(30)
Адрес
varchar(40)
Домашний телефон
char(9)
Рабочий телефон
char(9)
Дата рождения
datetime
Правила перехода от ER-модели к
реляционной модели (продолжение)
• Для отражения категоризации сущностей
при переходе к реляционной модели
возможны несколько вариантов
представления.
– Возможно создать только одно
отношение для всех подтипов одного
супертипа.
– При втором способе для каждого
подтипа и для супертипа создаются
свои отдельные отношения. Кроме
того, для возможности переходов к
подтипам от супертипа необходимо
в супертип включить идентификатор
связи.
