
- •Оглавление
- •1. Введение. Представление данных в памяти компьютера 3
- •2. Модели представления данных 43
- •3. Проектирование реляционных бд 83
- •4 Реляционная алгебра 114
- •5. Case – технологии 127
- •6. Организация доступа прикладной программы 178
- •1. Введение. Представление данных в памяти компьютера
- •1.1 Предмет дисциплины и ее задачи
- •1.2 Основные понятия
- •1.3 Файловые системы, как первый шаг к субд
- •1.4 Структурная схема субд и основные функции
- •1.5 Преимущества и недостатки субд по сравнению с файловыми системами
- •1.6 Организация внешней памяти реляционной субд
- •1.7 Типы и структуры данных
- •1.8 Типы и структуры данных, применяемые в реляционных бд
- •1.9 Типы и структуры данных, применяемые в объектно-реляционных бд
- •1.10 Понятие модели данных
- •2. Модели представления данных
- •2.1 Иерархическая модель данных
- •2.2 Сетевая модель данных
- •2.3 Реляционная модель данных
- •2.4 Свойства отношений. Отличие отношений от таблиц.
- •2.5 Понятие целостности данных
- •2.6 Ограничения реляционных баз данных
- •2.7 Суть постреляционного объектно-ориентированного подхода
- •2.8 Объектно-ориентированные субд и стандарт odmg
- •2.9 Объектно-реляционные субд
- •2.10 No sql бд и субд
- •1. NoSql базы в-основном оупенсорсные и созданы в 21 столетии.
- •6. Распределенные системы
- •3. Проектирование реляционных бд
- •3.1 Этапы разработки базы данных
- •3.2 Критерии оценки качества логической модели данных
- •3.3 Проектирование баз данных на основе нормализации отношений
- •3.4 Первая нормальная форма
- •3.5 Аномалии обновления
- •3.6 Функциональные зависимости
- •3.7 Вторая нормальная форма
- •3.8 Третья нормальная форма
- •3.9 Алгоритм нормализации (приведение к 3nf)
- •3.10 Oltp и olap-системы
- •3.11 Корректность процедуры нормализации. Теорема Хеза
- •3.12 Нормальная Форма Бойса-Кодда (nfbk)
- •3.13 Четвертая Нормальная Форма
- •3.14 Пятая Нормальная Форма
- •3.15 Продолжение алгоритма нормализации (приведение к 5 nf)
- •4 Реляционная алгебра
- •4.1 Операции над отношениями: общие сведения
- •4.2 Синтаксис операторов реляционной алгебры
- •4.3 Оптимизация алгоритмов реализации запросов
- •5. Case – технологии
- •5.1 Общие вопросы проектирования ис, понятие case-технологии
- •5.2 Жизненный цикл по ис
- •5.3 Модели жизненного цикла по
- •5.4 Методология rad
- •5.5 Структурный подход к проектированию ис
- •5.6 Методология функционального моделирования sadt (idef0)
- •5.7 Моделирование потоков данных (методология Гейна-Сарсона)
- •5.8 Методы построения диаграмм «сущность-связь» (erd)
- •5.9 Моделирование данных case-методом Баркера
- •5.10 Методология idef1
- •6. Организация доступа прикладной программы к серверу базы данных
- •6.1 Общие сведения
- •6.2 Использование специализированных библиотек и встраиваемого sql
- •6.4 Odbc – открытый интерфейс к бд на платформе ms Windows
- •6.5 Jdbc - интерфейс к базам данных на платформе Java
- •6.6 Прикладные интерфейсы ole db и ado
- •Литература
3.6 Функциональные зависимости
Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ находится в 1 NF, но при этом, логическая модель данных не адекватна модели предметной области. Таким образом, первой нормальной формы недостаточно для правильного моделирования данных и для устранения указанных аномалий применяется метод нормализации отношений.
Нормализация основана на понятии функциональной зависимости атрибутов отношения.
Определение
функциональной зависимости: Пусть
отношение. Множество
атрибутов
функционально зависимо от множества
атрибутов
(
функционально определяет
)
тогда и только тогда, когда для любого
состояния отношения
для любых кортежей
из того, что
следует что
(т.е. во всех кортежах, имеющих одинаковые
значения атрибутов
,
значения атрибутов
также
совпадают в любом состоянии отношения
).
Символически функциональная зависимость
обозначается
.
Множество
атрибутов
называется детерминантом функциональной
зависимости, а множество атрибутов
называется зависимой частью.
Если атрибуты составляют потенциальный ключ отношения , то любой атрибут отношения функционально зависит от .
Пример. В отношении СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ можно привести следующие примеры функциональных зависимостей:
зависимость атрибутов от ключа отношения:
(Н_СОТР,
Н_ПРО)
ФАМ;
(Н_СОТР, Н_ПРО) Н_ОТД;
(Н_СОТР, Н_ПРО) ТЕЛ;
(Н_СОТР, Н_ПРО) ПРОЕКТ;
(Н_СОТР, Н_ПРО) Н_ЗАДАН;
зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника: Н_СОТР ФАМ; Н_СОТР Н_ОТД; Н_СОТР ТЕЛ;
зависимость наименования проекта от номера проекта: Н_ПРО ПРОЕК;
зависимость номера телефона от номера отдела: Н_ОТД ТЕЛ.
Таким образом, функциональная зависимость – семантическое понятие. Она возникает, когда по значениям одних данных в предметной области можно определить значения других данных. Например, зная табельный номер сотрудника, можно определить его фамилию, по номеру отдела можно определить телефона. Функциональная зависимость задает дополнительные ограничения на данные, которые могут храниться в отношениях. Для корректности БД (адекватности предметной области) необходимо при выполнении операций модификации БД проверять все ограничения, определенные функциональными зависимостями.
Функциональная зависимость атрибутов отношения напоминает понятие функциональной зависимости в математике. Но это не одно и то же.
Отличие
от математического понятия отношения
состоит в том, что, если рассматривать
математическое понятие функции, то для
фиксированного значения
соответствующее значение функции
всегда одно и то же. Например, если задана
функция
,
то для значения
соответствующее значение
всегда будет равно 4. В противоположность
этому в отношениях значение зависимого
атрибута может принимать различные
значения в различных состояниях БД.
Например, атрибут ФАМ функционально зависит от атрибута Н_СОТР. Предположим, что сейчас сотрудница с табельным номером 1 имеет фамилию Иванова, т.е. при значении детерминанта равного 1, значение зависимого аргумента равно «Иванова». Но сотрудница может сменить фамилию, например на Сидорова. Теперь при том же значении детерминанта, равного 1, значение зависимого аргумента равно «Сидорова».
Функциональная зависимость атрибутов утверждает лишь то, что для каждого конкретного состояния БД по значению одного атрибута (детерминанта) можно однозначно определить значение другого атрибута (зависимой части). Но конкретные значение зависимой части могут быть различны в различных состояниях БД.