Системы управления базами данных. Лекция 1

1. Системы управления базами данных

Лекция 1

2. Методы организации внутримашинной информационной базы АИС

3. Методы организации внутримашинной информационной базы АИС

Недостатки традиционной организации данных
– многократное дублирование данных и
невозможность оперативного внесения изменений
в группы данных, дублированные в нескольких
файлах.
Недостатки метода единой информационной
базы – включение в АИС новой ПЗ, не
предусмотренной при проектировании
информационной базы, может привести к ее
изменению и к изменению программ
разработанных ПЗ.

4. Концепция базы данных

Базой данных (БД) называется совокупность
данных, организованная по определенным
правилам, предусматривающим общие принципы
описания, хранения и манипулирования данными,
независимая от прикладных программ.
Системой управления базами данных (СУБД)
называется совокупность программ и языковых
средств, предназначенных для управления
данными в БД, ведения БД и обеспечения
взаимодействия ее с прикладными программами.

5. Отличительные признаки базы данных

интеграция данных, используемых в различных
прикладных задачах (ПЗ);
учет взаимосвязей между данными;
минимальная избыточность данных;
независимость программ ПЗ и глобальной
логической организации данных от физической
организации данных (физическая независимость
данных);
независимость программ ПЗ от глобальной
логической организации данных (логическая
независимость данных).

6. Модели данных и схемы базы данных

Модель данных – это совокупность правил
порождения структур данных в БД, операций
над данными, а также ограничений
целостности, определяющих последовательность
изменения, допустимые связи и допустимые
значения данных.
Концепция БД предусматривает три уровня
описания данных: внешний, концептуальный и
внутренний. На каждом уровне используется
соответствующая модель данных.
Описание БД в контексте конкретной модели
данных называется схемой БД.

7. Модели данных и схемы базы данных

Внешние схемы БД применяется для описания
данных в виде, используемом программами ПЗ.
Концептуальная схема БД определяет
представление БД, единое для всех ПЗ и не
зависящее от используемого в СУБД
представления данных в среде хранения и путей
доступа к ним.
Внутренняя схема БД определяет представление
данных в среде хранения и пути доступа к ним.
Внешние и концептуальная схема относятся к
логической организации данных, а внутренняя
схема – к физической организации данных.

8. Модели данных и схемы базы данных

Внешние схемы БД применяется для описания
данных в виде, используемом программами ПЗ.
Концептуальная схема БД определяет
представление БД, единое для всех ПЗ и не
зависящее от используемого в СУБД
представления данных в среде хранения и путей
доступа к ним.
Внутренняя схема БД определяет представление
данных в среде хранения и пути доступа к ним.
Внешние и концептуальная схема относятся к
логической организации данных, а внутренняя
схема – к физической организации данных.

9. Языковые средства СУБД

При описании БД внешние,
концептуальная и внутренняя схемы БД
описываются на языке описания данных
(ЯОД), входящем в состав языковых средств
СУБД.
Каждая прикладная задача формирует
запросы на добавление, удаление,
обновление и поиск данных в БД в
соответствии со своей внешней схемой на
языке манипулирования данными (ЯМД).

10. Возможности СУБД

СУБД обеспечивают:
уменьшение избыточности хранимых
данных за счет минимизации дублирования
данных;
достоверность хранимых данных за счет
автоматической корректировки всех
дублируемых элементов данных;
стандартизацию данных в различных ПЗ;
совместное использование хранимых
данных различными ПЗ в
мультипрограммном режиме;

11. СУБД обеспечивают

физическую независимость данных,
заключающуюся в возможности
модификации внутренней схемы БД без
изменения концептуальной схемы БД,
внешних схем и программ ПЗ;
логическую независимость данных,
заключающуюся в возможности
модификации концептуальной схемы БД
без изменения внешних схем и программ
ПЗ;

12. СУБД обеспечивают

целостность данных за счет проверки
ограничений целостности при добавлении,
удалении и обновлении данных, связанных
изменений данных и механизма обработки
транзакций;
разграничение доступа к данным за счет
защиты данных СУБД и за счет описания во
внешней схеме каждой ПЗ только тех данных,
которые она использует;
сохранность данных при возникновении сбоев
и отказов сервера за счет средств резервного
копирования и восстановления БД.

13. Жизненный цикл базы данных

Жизненный цикл базы данных включает этапы
планирования, проектирования и эксплуатации.
На каждом из этих этапов требуется решить ряд задач,
связанных с интеграцией пользовательских
представлений о данных, выбором программных и
технических средств ведения БД, проектированием
концептуальной, внутренней и внешних схем БД,
управлением средствами обеспечения целостности и
достоверности данных и средствами защиты данных,
улучшением эксплуатационных характеристик СУБД.
Решение этих задач производится группой
администрирования базы данных (АБД).

14. Классификация СУБД

По месту запуска ядра СУБД:
локальные (dBase, FoxPro, Paradox, Access);
клиент-серверные (Firebird, Interbase, DB2, SQL Server,
Sybase, Oracle, PostgreSQL, MySQL, Cache).
По месту хранения данных:
централизованные (локальные);
распределенные;
облачные.
По концептуальной модели данных:
иерархические и сетевые;
реляционные;
объектно-реляционные;
объектно-ориентированные;
многомерные.

15. Понятие предметной области

Под предметной областью
понимается совокупность объектов
(одушевленных и неодушевленных
предметов, групп предметов, явлений,
событий, процессов) реального мира,
значения свойств (характеристик,
атрибутов) которых будут храниться и
обрабатываться в базе данных.

16. Понятие модели данных

Модель данных – это совокупность правил порождения структур данных в
базе данных, операций над ними, а также ограничений целостности,
определяющих допустимые связи и значения данных, последовательность
их изменения [ГОСТ 20886-85].
Модель данных состоит из трёх частей:
1. Набор типов структур данных.
Здесь можно провести аналогию с языками программирования, в которых тоже
есть предопределённые типы структур данных, такие как скалярные
данные, векторы, массивы, структуры (например, тип struct в языке Си) и
т.д.
2. Набор операторов или правил вывода, которые могут быть применены к
любым правильным примерам типов данных, перечисленных в (1), чтобы
находить, выводить или преобразовывать информацию, содержащуюся в
любых частях этих структур в любых комбинациях.
3. Набор общих правил целостности, которые прямо или косвенно
определяют множество непротиворечивых состояний базы данных и/или
множество изменений её состояния.

17. Модели данных

Иерархическая модель данных (ИМД).
Сетевая модель данных (СМД).
}I поколение
Реляционная модель данных (РМД).
- II поколение
Объектно-реляционная модель данных (ОРМД).
- III поколение
Стандарт SQL-3 (SQL-2003). Oracle (с версии 8.0), DB2, Informix,
PostgreSQL, SQL Server 2008 и др.)
Объектно-ориентированная модель данных (ООМД). O2, GemStone,
Iris и др.
Стандарт ODMG 3.0 (Object Database Management Group).
Многомерные базы данных.
Потоковые базы данных.
...

18. Реляционная модель данных (РМД)

В 1970 г. американский математик Э.Ф.Кодд
опубликовал статью, с которой отсчитывается начало
существования РМД.
РМД основана на теории множеств.
Домен, D – множество значений, которые может
принимать элемент данных.
Декартово произведение доменов – множество всех
возможных комбинаций значений доменов:
D1×D2×... ×Dn = {(d1i , d2i , ..., dni)}, где dki Dk
Пример: D1 = (1, 2), D2 = (a, b, c).
D1×D2 = {(1,a), (1,b), (1,c), (2,a), (2,b), (2,c)}
Отношение – подмножество декартова произведения
доменов.

19. Пример таблицы реляционной БД

Табельный
номер
ФИО
сотрудника
Должность
Оклад
Год
рождения
Отдел
023
Волкова Елена
Павловна
секретарь
26000
1985
2
113
Белов Сергей
Юрьевич
инженер
39800
1980
1
101
Рогов Сергей
Михайлович
директор
62000
1972
2
056
Панина Анна
Алексеевна
инженерпрограммист
41800
1978
1
...
...
...
...
49200
1971
9
...
098
...
Фролов Юрий
Вадимович
начальник
отдела
Мощность отношения. Арность отношения.

20. Ключи отношения

Ключ – атрибут (группа атрибутов), которые позволяют
классифицировать кортеж (запись таблицы).
Потенциальный ключ (уникальный ключ) – атрибут
(группа атрибутов), которые позволяют идентифицировать
кортеж (запись таблицы).
Первичный ключ – обязательный уникальный ключ. Для
каждой таблицы может быть определен только один
первичный ключ.
Вторичный ключ – любой другой ключ, кроме
первичного. Может быть необязательным и неуникальным.
Внешний ключ – служит для организации связей между
таблицами.

21. Организация связей между таблицами

Связь один-ко-многим: Отделы – Сотрудники
Таблица «Сотрудники»
Таблица «Отделы»
Табельный
номер
ФИО
сотрудника
Отдел
Номер
отдела
Название отдела
023
Волкова Елена
Павловна
2
1
Информационный отдел
2
Администрация
113
Белов Сергей
Юрьевич
1
3
Отдел кадров
101
Рогов Сергей
Михайлович
Панина Анна
Алексеевна
2
...
...
...
...
...
098
Фролов Юрий
Вадимович
9
056
1
9
Проектный отдел
«Номер отдела» - первичный
ключ в таблице «Отделы»
«Отдел» – внешний ключ в таблице «Сотрудники»

22. Организация связей между таблицами

Связь многие-ко-многим: Проекты – Сотрудники
Таблица «Проекты»
Таблица «Сотрудники»
ФИО
Номер
Шифр
Название проекта
Волкова Е.П.
023
23/Н
АИС "Налог"-2
Белов С.Ю.
113
18-К
ИПС "Жители"
Рогов С.М.
101
09/Р
ГИС "Город"
Панина А.А.
Таблица «Участие»
Участник
Роль
Проект
113
исполнитель
23/Н
056
101
руководитель
18-К
Фролов Ю.В.
098
056
исполнитель
18-К
101
консультант
09/Р
...
...
098
руководитель
23/Н
...
...
...
...
В таблице «Участие»:
«Участник» – внешний ключ к таблице «Сотрудники»
«Проект» – внешний ключ к таблице «Проекты»
...

23. Пример связи внутри таблицы

Табельный
номер
ФИО
сотрудника
Должность
Оклад
Начальник
023
Волкова Елена Павловна
секретарь
26000
101
113
Белов Сергей Юрьевич
инженер
39800
205
101
Рогов Сергей Михайлович
директор
62000
NULL
205
Махова Ольга Алексеевна
начальник
отдела
51300
101
...
...
...
...
...

24. Операции над данными в РМД

Операции применяются к кортежам отношений.
В РМД используются следующие операции:
• запомнить: внесение информации в БД (требует
формирования значений уникального ключа и обязательных
атрибутов кортежа);
• извлечь: чтение данных;
• обновить: модификация данных – изменение значений
атрибутов кортежей;
• удалить: физическое или логическое удаление данных
(кортежей).

25. Этапы планирования и проектирования базы данных

I. Информационно-логическое (инфологическое) проектирование
анализ предметной области;
построение модели предметной области;
определение границ информационной поддержки;
определение групп пользователей.
II. Определение требований к операционной обстановке:
• выбор аппаратной платформы;
• выбор операционной системы.
III. Выбор СУБД и других инструментальных программных средств.
• выбор СУБД;
• выбор версии СУБД и архитектуры, в которой она будет работать.
IV. Логическое проектирование БД (даталогическое):
• преобразование схемы предметной области в схему базы данных;
• нормализация и создание схем отношений.
V. Физическое проектирование БД:
• разработка физической структуры БД (внутренней схемы);
• реализация проекта на DDL-языке выбранной СУБД;
• создание дополнительных объектов БД (индексов, представлений,
триггеров и др.).

26. Методология проектирования базы данных

27. Модель данных «сущность-связь»

Для построения инфологической модели предметной
области используются диаграммы «сущность-связь» (ERдиаграммы).
Множество допустимых структурных компонентов модели
данных «сущность-связь»:
• сущность;
• связь между сущностями;
• атрибут сущности;
• первичный ключ сущности;
• уникальный ключ сущности;
• внешний ключ сущности;
• функциональные зависимости (ФЗ) между атрибутами
сущности;
• состав многозначного атрибута сущности;
• ФЗ между элементами многозначного атрибута сущности.

28. Сущности в модели данных «сущность-связь»

Сущность – это множество реальных или абстрактных объектов
(людей, предметов, документов и т.п.), обладающих общими
атрибутами или характеристиками. Любой объект системы может
быть представлен только одной сущностью, которая должна быть
уникально идентифицирована. Именование сущности
осуществляется с помощью существительного в единственном числе.
При этом имя сущности должно отражать тип или класс объекта, а
не его конкретный экземпляр.
Сущности не существуют отдельно друг от друга. Между ними
имеются отношения, которые должны быть отражены в
инфологической модели предметной области в виде связей.
Связь представляет собой соединение двух сущностей. Связь
описывается вербальными фразами в виде глаголов в двух
направлениях. Каждая связь должна иметь свое уникальное имя
связи.

29. Сущности в модели данных «сущность-связь»

Сущности:
базовые (наличие базовых сущностей не зависит от наличия или
отсутствия других сущностей).
зависимые (наличие зависимых сущностей зависит от наличия
или отсутствия других сущностей).
Обычно описание ПО выражается в терминах не отдельных сущностей
и связей между ними, а их типов, связанных с ними ограничений
целостности и тех процессов, которые приводят к переходу ПО из
одного состояния в другое. Такое описание может быть
представлено любым способом, допускающим однозначную
интерпретацию.
Выделяют понятия тип сущности и экземпляр сущности.
Тип позволяет выделить из всего множества сущностей ПрО группу
сущностей, однородных по структуре и поведению (относительно
рамок рассматриваемой ПрО).
Данные в БД представлены экземплярами сущностей.

30. Атрибуты сущностей

Атрибут сущности – свойство сущности, имеющее имя,
область допустимых значений (тип и формат) и признак
обязательности атрибута. Значением атрибута может быть
неделимый элемент данных, вектор из элементов
данных, структура из элементов данных,
повторяющаяся группа из элементов данных, векторов
или структур.
Сущность должна иметь обязательный атрибут или
комбинацию обязательных атрибутов, чьи значения
однозначно определяют каждый экземпляр сущности. Эти
атрибуты образуют первичный ключ сущности (Primary
Key, PK). Если сущность имеет несколько таких
подмножеств атрибутов, то одно из них объявляется
первичным ключом, а каждое из остальных объявляется
уникальным или альтернативным ключом.

31. Многозначные атрибуты сущностей

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

32. Классификация атрибутов сущностей

Атрибуты сущностей:
Идентифицирующие и описательные атрибуты. Идентифицирующие
позволяют отличить один экземпляр сущности от другого; описательные
заключают в себе интересующие нас свойства сущности.
Составные и простые атрибуты. Простой атрибут имеет неделимое
значение. Составной атрибут является комбинацией нескольких элементов,
возможно, принадлежащих разным типам данных (ФИО, адрес и др.).
Однозначные и многозначные атрибуты (могут иметь соответственно
одно или много значений для каждого экземпляра сущности). Например, дата
рождения – это однозначный атрибут, а номер телефона – многозначный.
Основные и производные атрибуты. Значение основного атрибута не
зависит от других атрибутов; значение производного атрибута вычисляется на
основе значений других атрибутов. Например, возраст вычисляется на основе
даты рождения и текущей даты.
Обязательные и необязательные (первые должны быть указаны при
размещении данных в БД, вторые могут не указываться).
Для каждого атрибута необходимо определить название, указать тип данных и
описать ограничения целостности – множество значений, которые может
принимать данный атрибут.

33. Связи между сущностями

Связи между сущностями:
Для связи указывается:
название,
тип (факультативная или обязательная),
кардинальность (1:1, 1:n или m:n),
степень (унарная, бинарная, тернарная или n-арная).
Различают тип связи и экземпляр связи.
Примеры обязательной и факультативной связей:
замещает
СОТРУДНИК
ДОЛЖНОСТЬ
замещается

34. Связи между сущностями

Кардинальность связей между сущностями:
один-к-одному (1:1);
один-ко-многим (1:n);
многие-ко-многим (m:n).
Примеры связей разной кардинальности:
ВРАЧ
N
КОЙКА
1
занимать
ПАЛАТА
лечить
1
M
1
ПАЦИЕНТ
N
находиться

35. Связи между сущностями

Степень связей между сущностями:
СОТРУДНИКИ
унарная – связь между разными
экземплярами сущностей одного типа:
1
руководить
N
бинарная – связь между двумя разными
типами сущностей:
ГРУППЫ
1
учатся
N
СТУДЕНТЫ
тернарная – связь между тремя разными
типами сущностей:
ПРЕПОДАВАТЕЛИ
K
ДИСЦИПЛИНЫ
N
экзаменовать
M
СТУДЕНТЫ

36. Внешние ключи сущностей

Если между двумя сущностями имеется связь «один к
одному» или «один ко многим» («многие к одному»), то
атрибуты первичного ключа родительской сущности
наследуются в качестве атрибутов подчиненной
сущности. Эти атрибуты называются внешним ключом
(Foreign Key, FK).
Если связь между сущностями идентифицирующая, то
атрибуты внешнего ключа входят в состав первичного
ключа подчиненной сущности, либо входят в состав
альтернативного ключа этой сущности.
Если связь между сущностями не идентифицирующая, то
атрибуты внешнего ключа входят в состав не ключевых
атрибутов подчиненной сущности.

37. Обозначения, используемые в ER-диаграммах

СОТРУДНИКИ
– базовая сущность
ЗАКАЗЫ
– зависимая сущность
иметь
– связь
N
1
– факультативная связь
– обязательная связь
(с указанием кардинальности связи)

38. Моделирование локальных представлений

Если ПрО содержит много сущностей (10 и более), то она разбивается на
ряд локальных областей (локальных представлений) по 6-7
сущностей.
Каждое локальное представление включает в себя информацию,
достаточную для обеспечения информационных потребностей одной
группы будущих пользователей или решения отдельной задачи.
Каждое локальное представление моделируется отдельно, а затем
выполняется их объединение (за 1 шаг попарно).
При объединении локальных представлений используют концепции:
Идентичность. Два или более элементов модели идентичны, если
они имеют одинаковое семантическое значение.
Агрегация. Позволяет рассматривать связь между элементами как
новый элемент.
Обобщение. Позволяет образовывать многоуровневую иерархию
обобщений.
На этапе объединения локальных представлений необходимо устранить
все противоречия.

39. Результаты инфологического проектирования

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

40. Выбор СУБД

Наиболее важные критерии выбора СУБД:
тип модели данных, которую поддерживает данная СУБД,
адекватность модели данных структуре рассматриваемой ПО;
характеристики производительности СУБД;
запас функциональных возможностей для дальнейшего развития
информационной системы;
степень оснащённости СУБД инструментарием для персонала
администрирования данными;
удобство и надежность СУБД в эксплуатации;
наличие специалистов по работе с конкретной СУБД;
стоимость СУБД и дополнительного программного обеспечения.
Также может выбираться дополнительное программное обеспечение
(например, CASE-средства: ERWin, BPWin и т.п.).

41. Преобразование ER-диаграммы в схему базы данных

Правила преобразования:
1. Каждый тип сущности преобразуется в таблицу БД. В таблицу
вносятся все атрибуты, относящиеся к данному типу сущности.
2. Бинарная связь 1:n (между сущностями разных типов)
реализуется с помощью внешнего ключа между двумя
таблицами
ГРУППЫ
1
GROUPS
(Группы)
учатся
IDG
N
STUDENTS
(Студенты)
СТУДЕНТЫ

42. Преобразование ER-диаграммы в схему базы данных

Правила преобразования:
3. Каждая связь со степенью больше двух и связь, имеющая
атрибуты, преобразуется в таблицу БД.
TEACHERS
(Преподаватели)
ПРЕПОДАВАТЕЛИ
K
экзаменовать
N
ДИСЦИПЛИНЫ
Оценка
M
СТУДЕНТЫ
IDP
EXAMS
(Экзамены)
IDD
SUBJECTS
(Дисциплины)
IDS
STUDENTS
(Студенты)

43. Преобразование ER-диаграммы в схему базы данных

Правила преобразования:
4. Связь 1:1 реализуется в рамках одной таблицы. Исключение из
этого правила составляют ситуации, когда связанные сущности
существуют независимо друг от друга.
5. Унарная связь 1:n (между сущностями одного типа)
реализуется с помощью внешнего ключа, определённого в той
же таблице, что и первичный ключ.
СОТРУДНИКИ
СОТРУДНИКИ
1
руководить
N

44. Преобразование ER-диаграммы в схему базы данных

Правила преобразования:
6. Бинарная связь типа n:m реализуется с помощью
промежуточной таблицы.
КНИГИ
K
написать
N
АВТОРЫ
BOOKS
(Книги)
IDB
BOOK_AUTH
(авторы книг)
IDA
AUTHORS
(Авторы)

45. Преобразование ER-диаграммы в схему базы данных

Правила преобразования:
7. Унарная связь n:m реализуется с помощью промежуточной
таблицы.
КЛЮЧЕВЫЕ
СЛОВА
KEYWORDS
(Ключевые слова)
M
ассоциируются
ID
ID
N
ASSOSIATIONS (Ассоциации)

46. Аномалии модификации данных

При неправильно спроектированной схеме реляционной БД могут
возникнуть аномалии выполнения операций модификации данных.
Рассмотрим эти аномалии на примере следующего отношения:
ПОСТАВКИ (Номер поставки, Название товара, Цена товара, Количество,
Дата поставки, Название поставщика, Адрес поставщика)
Различают аномалии обновления, удаления и добавления.
Аномалия обновления может возникнуть в том случае, когда информация
дублируется. Другие аномалии возникают тогда, когда две и более
сущности объединены в одно отношение.
Например:
Аномалия обновления: изменился адрес поставщика. Если от него
было несколько поставок, то придется менять несколько записей.
Аномалия удаления: при удалении в архив записей обо всех поставках
определённого поставщика все данные об этом поставщике (название,
адрес) будут утеряны.
Аномалия добавления: нельзя добавить сведения о поставщике, пока
от него нет ни одной поставки.
Для решения проблемы аномалии модификации данных при
проектировании РБД проводится нормализация отношений.

47. Нормализация схемы отношения

Нормализация схемы отношения выполняется путём декомпозиции схемы.
Декомпозицией схемы отношения R называется замена её совокупностью
схем отношений Аi таких, что
R Ai
i
и не требуется, чтобы отношения Аi были непересекающимися.
Декомпозиция отношения не должна приводить к потере зависимостей
между атрибутами сущностей. Для декомпозиции должна существовать
операция реляционной алгебры, применение которой позволит
восстановить исходное отношение.
Покажем нормализацию на примере отношения КНИГИ :
Id
– идентификатор (первичный ключ),
Code
– шифр рубрики (по ББК – библиотечно-библиографической
классификации),
Theme – название рубрики (по ББК),
Title
– название книги,
Author
– автор(ы),
Editor
– редактор(ы),
Type
– тип издания (учебник, учебное пособие, сборник и.т.п.),
Year
– год издания,
Pg
– количество страниц.

48. Пример для демонстрации нормализации

В таблице приведен пример содержимого исходного отношения КНИГИ:

49. Первая нормальная форма

Введём понятие простого и сложного атрибута:
Простой атрибут – это атрибут, значения которого атомарны (т.е.
неделимы).
Сложный атрибут может иметь значение, представляющее собой
конкатенацию нескольких значений одного или разных доменов.
Аналогом сложного атрибута может быть агрегат или повторяющийся
агрегат данных.
Первая нормальная форма (1НФ).
Отношение приведено к 1НФ, если все его атрибуты простые.

50. Приведение к 1НФ

51. Вторая нормальная форма

Введём понятие функциональной зависимости. Пусть X и Y –
атрибуты (группы атрибутов) некоторого отношения. Говорят, что Y
функционально зависит от X, если в любой момент времени
каждому значению X=х соответствует единственное значение Y=y
(X Y). (При этом любому значению Y=y может соответствовать
несколько значений Х=(х1, х2,…)).
Атрибут X в функциональной зависимости X Y называется
детерминантом отношения.
Неключевой атрибут функционально полно зависит от составного ключа, если
он функционально зависит от ключа, но не находится в функциональной
зависимости ни от какой части составного ключа.
Вторая нормальная форма (2НФ).
Отношение находится во 2НФ, если оно приведено к 1НФ и каждый
неключевой атрибут функционально полно зависит от составного
ключа.
Для того чтобы привести отношение ко 2НФ, нужно:
1. построить его проекцию, исключив атрибуты, которые не находятся
в функционально полной зависимости от составного ключа;
2. построить дополнительные проекции на часть составного ключа и
атрибуты, функционально зависящие от этой части ключа.

52. Приведение к 2НФ

53. Третья нормальная форма

Рассмотрим понятие транзитивной зависимости.
Пусть X, Y, Z – атрибуты некоторого отношения. При этом X Y и Y Z,
но обратное соответствие отсутствует, т.е. Y не зависит от Z или X
не зависит от Y. Тогда говорят, что Z транзитивно зависит от X
(X Z).
Третья нормальная форма (3НФ).
Отношение находится в 3НФ, если оно находится во 2НФ и в нем
отсутствуют транзитивные зависимости.
Исключение:
если для атрибутов X,Y,Z есть транзитивная зависимость X Z, и
при этом Y X или Z Y, то такая зависимость не требует
декомпозиции отношения.
Например, для отношения АВТОМОБИЛИ с первичным ключом
Государственный номерной знак и полями № кузова и
№ двигателя очевидно, что номера кузова и двигателя зависят как
друг от друга, так и от первичного ключа. Но эта зависимость
взаимно однозначная, поэтому декомпозиция отношения не нужна.

54. Приведение к 3НФ

Отношения, находящиеся в 3НФ, свободны от аномалий модификации.