Нормалізація Бази даних та інформаційні системи Лекції 10, 11, 12.

Презентация:



Advertisements
Похожие презентации
Нормализация таблиц реляционной базы данных © Панова И.В
Advertisements

БАЗЫ ДАННЫХ ЛЕКЦИЯ 8. тема: ТЕОРИЯ НОРМАЛЬНЫХ ФОРМ.
ЛЕКЦИЯ 2 ОСНОВЫ РЕЛЯЦИОННОЙ АЛГЕБРЫ Вопрос 1. Основные операции над отношениями в реляционных базах данных. Вопрос 2. Нормализация реляционных баз данных.
Нормализация отношений "Сложная система, спроектированная наспех, никогда не работает, и исправить её, чтобы заставить работать, невозможно". Законы Мерфи.
Проектирование БД. Нормальные формы В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм: первая нормальная.
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ (ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) КАФЕДРА ИКТ 1 Лекция 4. Проектирование БД. От и до. Курс: Базы Данных.
Реляционная модель – это особый метод рассмотрения данных, содержащий данные в виде таблиц, способов работы и манипуляции с ними в виде связей. структура,
1 БАЗЫ ДАННЫХ Функциональные зависимости и их использование в базах данных ЗАНЯТИЕ 4 ПУГАЧЁВ Ю.В. Учитель информатики Харьковская общеобразовательная школа.
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ (ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) КАФЕДРА ИКТ 1 Лекция 1 (окончание). О ключах и целостности. Курс:
Базы данных Лекция 9 Проектирование реляционных баз данных на основе принципов нормализации: дальнейшая нормализация.
Основы проектирования реляционных баз данных. База данных: общее понятие База данных: хранилище информации отражает объект реального мира имитирует деятельность.
Нормализация. Рассматриваемые вопросы: 1.Нормализация 2.Классы отношений 3.Первоя нормальная форма 4.Вторая нормальная форма 5.Третья нормальная форма.
Модуль 1. Математические основы баз данных и знаний 1.
1 БАЗЫ ДАННЫХ ЗАНЯТИЕ 5 ПУГАЧЁВ Ю.В. Учитель информатики Харьковская общеобразовательная школа І-ІІІ ступеней 60 Харьковского городского совета Харьковской.
Базы данных Учитель информатики гимназии 1 г. Жуковского Московской области Ю.В.Пашковская.
Информационная система « АВТОМАТИЗАЦИЯ ПРОКАТА ФИЛЬМОВ » Курсовая работа Работу выполнила: студент Z1243 Э группы факультета информатики и экономики Бареев.
Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет.
Нормализация данных В IDEF1X (дополнительный материал к лекции по информационному моделированию с использованием методологии IDEF1X)
Учебная дисциплина «Базы данных» для студентов специальности Бизнес-информатика (бакалавриат) ЛЕКЦИЯ 3 ВВЕДЕНИЕ В РЕЛЯЦИОННУЮ МОДЕЛЬ ДАННЫХ Вопрос.
Нормализация реляционной модели данных По учебнику Семакин Н.Г., Хеннер Е.К. Информационные системы и модели © 2006 Медведев Л.Н.
Транксрипт:

Нормалізація Бази даних та інформаційні системи Лекції 10, 11, 12

План лекции Введение. 1. Цель и варианты применения нормализации в проектировании РБД 2. Проблем, связанные с избыточностью данных 3. Способы оценки применимости или качества спроектированных отношений 4. Концепция функциональной зависимости 5. Использование функциональной зависимости для группирования атрибутов в отношения, 6. Способы проведения процесса нормализации 7. Нормальные формы: 1НФ, 2НФ, 3НФ, НФБК, 4НФ, 5НФ 8. Примеры приведения данных к 3НФ Заключение ХНУРЕ кафедра Інформатики доц. Яковлева О.В. 2

Цель лекции : ХНУРЕ кафедра Інформатики доц. Яковлева О.В. 3

Введение Классическая нормализация Нормальная форма свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение. Нормализация – процесс преобразования отношений базы данных (БД) к виду, отвечающему нормальным формам. Тип подхода к проектированию БД: ВОСХОДЯЩИЙ Базовая методология: ПОСТРОЕНИЕ ОТНОШЕНИЙ НА ОСНОВЕ АНАЛИЗА ФУКНЦИОНАЛЬНЫХ ЗАВИСИМОСТЕЙ Подход предложен Э.Ф. Коддом в 1972г. 1НФ, 2НФ, 3НФ г.; НФБК г.; 4НФ – 1977г.; 5НФ – 1979г. ХНУРЕ кафедра Інформатики доц. Яковлева О.В. 4

Цель и варианты применения нормализации Варианты применения нормализации к проектированию РМД: Применение как восходящего подхода к проектированию, который начинается с установления связей между атрибутами. Использование для проектирования БД методологии нисходящего проектирования, где проектирование начинается с выявления основных сущностей и связей между ними, а нормализация используется лишь в качестве метода проверки корректности полученного решения. Цель нормализации – найти оптимальную группировку атрибутов для каждого отношения в схеме, что позволяет предотвратить возможное возникновение аномалий обновлений и минимизировать избыточность данных. Замечание! Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации, что достигается путем декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов). ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 5

Данный этап включает следующие шаги 1. Создание и проверка локальной логической модели данных для отдельных пользователей 1. Исключение особенностей, несовместимых с РМ: 1. Преобразование двухсторонних связей типа M:N 2. Преобразование связей с атрибутами 3. Преобразование сложных связей 4. Преобразование многозначных атрибутов 5. Преобразование рекурсивных связей M:N Дополнительный анализ: 1. Перепроверка связей типа 1:1 2. Анализ рекурсивных связей 1:1 3. Удаление избыточных связей 4. Анализ связей супер класс/подкласс 2. Формирование отношений на основе логической модели (раскрытие схемы) 3. Проверка отношений с использованием средств нормализации 4. Проверка применимости отношений для выполнения пользовательский транзакций 5. Определение ограничений целостности 6. Согласование локальной логической модели данных с пользователем 2. Создание и проверка глобальной логической модели данных ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 6 Логическое проектирование

Избыточность данных и аномалии обновлений Пример1 БП: 1. Сотрудник занимает только одну должность и работает только в одном отделении. 2. Зарплата сотрудника не зависит от должности, которую он занимает. 3. По одному адресу расположено только одно отделение, отделение расположено только по одному адресу Таблица Отношение Сотрудник Таблица 1.2 – Отношение Отделение Таблица 2 – Отношение Сотрудник_Отделение ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 7 СотрИНСотрФИОСотрДолжностьСотрЗарплатаОтдИН 1Петров И.И.Менеджер5000О5 2Сидоров А.А.Ассистент2000О3 3Вовк М.КСекретарь1500О3 4Абрамова И.Т.Ассистент2300О7 5Кисиленко Т.ВМенеджер5500О3 6Зайцева А.В.Ассистент3000О5 ОдтИНОтдАдрес О3г.Харьков, пр.Ленина, 15, оф.203 О5г.Донецк, площ. Восстания, 3а, оф.30 О7г.Киев, ул.Строителей, 43, оф 2 СотрИНСотрФИОСотрДолжностьСотрЗарплатаОтдИНОтдАдрес 1Петров И.И.Менеджер5000О5г.Донецк, площ. Восстания, 3а, оф.30 2Сидоров А.А.Ассистент2000О3г.Харьков, пр.Ленина, 15, оф.203 3Вовк М.КСекретарь1500О3г.Харьков, пр.Ленина, 15, оф.203 4Абрамова И.Т.Ассистент2300О7г.Киев, ул.Строителей, 43, оф 2 5Кисиленко Т.ВМенеджер5500О3г.Харьков, пр.Ленина, 15, оф.203 6Зайцева А.В.Ассистент3000О5г.Донецк, площ. Восстания, 3а, оф.30

Избыточность данных и аномалии обновлений Схема 1 Сотрудник_ Отделение (СотрИН, СотрФИО, СотрДолжность, СотрЗарплата, ОтдИН, ОтдАдрес) Схема 2 Сотрудник (СотрИН, СотрФИО, СотрДолжность, СотрЗарплата, ОтдИН) Отделение (ОтдИН, ОтдАдрес) Сравнение схем: Сотрудник_ Отделение – содержит избыточные данные: сведения о отделениях повторяются для каждого сотрудника Избыточность данных приводит к аномалиям обновления: аномалии вставки, аномалии удаления, аномалии модификации ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 8

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

ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 10 Свойства соединения без потерь и сохранения зависимости Процесс декомпозиции имеет 2 свойства: Соединение без потерь – позволяет восстановить любой кортеж исходного отношения, используя кортежи меньших отношений, полученные в результате декомпозиции. Сохранение зависимости – позволяет сохранить ограничения, наложенные на исходные отношения, посредством наложения некоторых ограничений на каждое из меньших отношений, полученных после декомпозиции.

В основу нормализации положена концепция функциональной зависимости (functional dependency). Функциональной зависимостью (ФЗ) атрибута в от атрибута а в отношении R – называется такая связь между атрибутами, когда каждое значение атрибута а однозначно определяет значение атрибута в (определяет только одно значение атрибута в), причем под атрибутом а может также пониматься и группа атрибутов Обозначение: Атрибут в функционально зависит от атрибута а: а в ФЗ определяется на основе ограничений ПрО (бизнес-правилами) Детерминант ФЗ - атрибут или группа атрибутов, от которого рассматривается зависимость ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 11 Функциональные зависимости

Примеры: БП: Сотрудник занимает только одну должность Каждую должность может занимать много сотрудников СотрИН СотрДолжность (1:1) ФЗ 2 Ассистент СотрИН – детерминант ФЗ СотрДолжность СотрИН (1:М) 2 Ассистент 4 6 ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 12 Функциональные зависимости

Замечание! 1. Пусть а в, тогда если две строки имеют одно и то же значение атрибута а, то они обязательно имеют одно и тоже значения атрибута в. Однако для заданного значения атрибута в может существовать несколько значений атрибута а. 2. Функциональная зависимость является свойством реляционной схемы, а не свойством конкретного экземпляра, т.е. должна выполняться для всех возможных значений, а не для тех, которые хранятся в атрибуте в определенный момент времени. Пример. В любой момент времени: СотрИН СотрФИО (1:1) ФЗ В определенный момент времени: СотрФИО СотрИН (1:1), но может измениться на (1:М), следовательно, ФЗ не является. 3. Тривиальные ФЗ, т.е. зависимости, когда в правой части определено подмножество множества, которое указано в левой части (детерминанте), справедливы всегда, но не представляют никакой дополнительной информации о возможных ограничениях. Примеры тривиальных зависимостей: СотрИН, СотрФИО СотрФИО СотрИН, СотрФИО СотрИН ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 13 Функциональные зависимости

Пример 1 Функциональные зависимости отношения СотрудникОтделение БП: 1. Сотрудник занимает только одну должность работает только в одном отделении. 2. Зарплата сотрудника зависит от должности, которую он занимает, и от отделения, в котором он работает. 3. По одному адресу расположено только одно отделение, отделение расположено только по одному адресу Функциональные зависимости: ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 14 Функциональные зависимости СотрИНСотрФИОСотрДолжностьСотрЗарплатаОтдИНОтдАдрес 1Петров И.И.Менеджер5000О5г.Донецк, площ. Восстания, 3а, оф.30 2Сидоров А.А.Ассистент2000О3г.Харьков, пр.Ленина, 15, оф.203 3Вовк М.КСекретарь1500О3г.Харьков, пр.Ленина, 15, оф.203 4Абрамова И.Т.Ассистент2300О7г.Киев, ул.Строителей, 43, оф 2 5Кисиленко Т.ВМенеджер5500О3г.Харьков, пр.Ленина, 15, оф.203 6Зайцева А.В.Ассистент3000О5г.Донецк, площ. Восстания, 3а, оф.30

Выявление первичного ключа отношения с использованием функциональных зависимостей 1.Для выявления потенциальных ключей необходимо найти атрибут (или группу атрибутов), однозначно идентифицирующий каждую строку в этом отношении 2. Если отношение обладает несколькими потенциальными ключами, необходимо выбрать первичный. Все атрибуты, которые не входят в состав первичного ключа, должны быть функционально зависимыми от этого ключа. Пример 1. Отношение Сотрудник_Отделение Единственным потенциальным ключом отношения Сотрудник_Отделение, а следовательно, и его первичным ключом, является атрибут СотрИН ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 15 Функциональные зависимости

Выводы: В процессе нормализации должны учитываться следующие основные характеристики зависимостей между атрибутами: - связь типа 1:1; - справедливость при любых условиях; - нетривиальность. ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 16 Функциональные зависимости

Нормализация – это формальный метод анализа отношений на основе их первичного ключа (или потенциальных ключей, как в случае НФБК) и существующих функциональных зависимостей. Описание. Процесс включает ряд правил, которые используются для поверки отдельных отношений таким образом, чтобы вся база данных могла быть нормализована до желаемой степени нормализации Если некоторое требование не удовлетворяется, то нарушающее данное требование отношение должно быть декомпозировано на отношения, каждое из которых удовлетворяет всем правилам нормализации. Для РМД обязательным является удовлетворение требованиям 1НФ. Все остальные НФ используются по желанию проектировщиков. Рекомендуется выполнять нормализацию до 3НФ. Ненормализованная форма (ННФ) – таблица, содержащая одну или несколько повторяющихся групп данных. ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 17 Нормализация

Ненормализованная форма (ННФ) – таблица, содержащая одну или несколько повторяющихся групп данных. Повторяющейся группой называется группа, состоящая из одного и более атрибутов таблицы, в которой возможно наличие нескольких значений для единственного значения ключевого атрибута ненормализованной таблицы. Пример 2 Сведения об объектах недвижимости, арендованных клиентом Иванов И.И. Рисунок 1.1 – Исходные данные Таблица 0 - Ненормализованная таблица Клиент_Аренда_Объект_Владел ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 18 Нормализация стр1 Агентство Квартал Сведения об аренде объектов недвижимости Дата Номер клиента: К68 ФИО клиента: Иванов И.И. Номер объекта Адрес объектаДата начала аренды Дата оконч. аренды ПлатаНомер владельца Наименование владельца Кв4г.Харьков ул.Есенина 6, кв Васильченко В.А. Д5Харьковская область, пос. Русская Лозовая Филатов В.К. Номер Клиента ФИО Клиента Номер объекта Адрес объектаДата начала аренды Дата оконч. аренды ПлатаНомер владельца Наименование владельца К68Иванов И.И.Кв4г.Харьков ул.Есенина 6, кв Васильченко В.А. Д5Харьковская область, пос. Русская Лозовая Филатов В.К. К67Петров С.С.Д7Харьковская область, пос.Циркуны Соловьев К.К. Кв4г.Харьков ул.Есенина 6, кв Васильченко В.А.

Пример 2 (продолжение) БП: 1. Клиент может арендовать некоторый объект только 1 раз 2. Клиент не может арендовать одновременно несколько объектов 3. Объект недвижимости принадлежит только одному владельцу 4. Дата окончания аренды может быть изменена 5. Оплата зависит от объекта недвижимости Таблица 0 - Ненормализованная таблица Клиент_Аренда_Объект_Владел ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 19 Ненормализованная форма (ННФ) Номер Клиента ФИО Клиента Номер объекта Адрес объектаДата начала аренды Дата оконч. аренды ПлатаНомер владельца Наименование владельца К68Иванов И.И.Кв4г.Харьков ул.Есенина 6, кв Васильченко В.А. Д5Харьковская область, пос. Русская Лозовая Филатов В.К. К67Петров С.С.Д7Харьковская область, пос.Циркуны Соловьев К.К. Кв4г.Харьков ул.Есенина 6, кв Васильченко В.А.

Пример 2 (продолжение) Проектирование на основе построение ER - модели Сам.раб + доска ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 20

Определение: Первая нормальная форма (1НФ) – отношение, в котором на пересечении каждой строки и каждого столбца содержится только одно атомарное значение. Требование 1НФ: 1. Отсутствие повторяющихся групп. 2. Наличие первичного ключа. Действия для приведения к 1НФ: 1. Выбор ключевого атрибута ненормализованной таблицы. 2. Поиск повторяющихся групп. 3. Устранение повторяющихся групп. Для устранения повторяющихся групп существует 2 подхода: а) повторяющиеся группы устраняются путем ввода в пустые строки повторяющихся данных; Анализ: вносится некоторая избыточность данных, которая в результате дальнейшей нормализации будет устранена. б) повторяющиеся группы изымаются и помещаются в отдельное отношение вместе с копиями ключа исходной таблицы. Далее в новых отношениях устанавливаются первичные ключи. При наличии повторяющихся групп нескольких уровней данный прием применяется несколько до тех пор, пока повторяющихся групп не остается. Анализ: - данные обладают меньшей избыточностью - сложности связанные с выделением повторяющихся групп Замечание! При выборе подхода а полученное 1НФ - отношение декомпозируется в ходе дальнейшей нормализации на те же отношения, которые получаются при применения подхода б. ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 21 Первая нормальная форма (1НФ)

Пример 2 (продолжение) Таблица 0 - Ненормализованная таблица Клиент_Аренда_Объект_Владел Действия для приведения к 1НФ (пример): 1.Выбор ключевого атрибута ненормализованной таблицы. ПК:НомерК 2. Поиск повторяющихся групп. Структура повторяющейся группы: (НомерО, АдресО, ДатаН, ДатаО, Плата, НомерВ, НазвВ) ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 22 Первая нормальная форма (1НФ) Номер Клиента ФИО Клиента Номер объекта Адрес объектаДата начала аренды Дата оконч. аренды ПлатаНомер владельца Наименование владельца К68Иванов И.И.Кв4г.Харьков ул.Есенина 6, кв Васильченко В.А. Д5Харьковская область, пос. Русская Лозовая Филатов В.К. К67Петров С.С.Д7Харьковская область, пос.Циркуны Соловьев К.К. Кв4г.Харьков ул.Есенина 6, кв Васильченко В.А.

Пример 2 (продолжение) 3. Устранение повторяющихся групп. Подход а: - повторяющиеся группа устраняется с помощью ввода в каждую строку с описанием Объекта недвижимости соответствующих сведений о Клиенте Получаем отношение: Клиент_Аренда_Объект_Владелец(НомерК, НомерО, ФИОК, АдресО, ДатаН, ДатаО, Плата, НомерВ, НазвВ) Таблица 1 - Отношение Клиент_Аренда (1НФ) Потенциальные ключи: Первичный ключ: Вывод: Отношение Клиент_Аренда_Объект_Владелец находится в 1НФ. Анализ: Отношение подвержено аномалиям обновления ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 23 Первая нормальная форма (1НФ) Номер Клиента ФИО Клиента Номер объекта Адрес объектаДата начала аренды Дата оконч. аренды ПлатаНомер владельца Наименование владельца К68Иванов И.И.Кв4г.Харьков ул.Есенина 6, кв Васильченко В.А. К68Иванов И.И.Д5Харьковская область, пос. Русская Лозовая Филатов В.К. К67Петров С.С.Д7Харьковская область, пос.Циркуны Соловьев К.К. К67Петров С.С.Кв4г.Харьков ул.Есенина 6, кв Васильченко В.А.

Пример 2 (продолжение) 3. Устранение повторяющихся групп. Подход б: - повторяющиеся группа устраняется из ненормализованного отношения и помещается в другое отношение вместе с копией исходного ключевого атрибута (НомерК), затем для нового отношения выбирается собственный первичный ключ Получаем отношения: Клиент (НомерК, ФИОК) Аренда_Объект_Владелец (НомерК, НомерО, АдресО, ДатаН, ДатаО, Плата, НомерВ, НазвВ ) Вывод: Отношения Клиент, Аренда_Объект_Владелец находятся в 1НФ. Анализ: Отношение Объект_Аренда_Владелец также обладает избыточностью, следовательно, подвержено аномалиям обновлениям Внимание!!! Далее используем результат подхода а ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 24 Первая нормальная форма (1НФ)

2НФ – применяется к отношениям с составным ПК Основана на требовании полной функциональной зависимости от ПК Полная функциональная зависимость Полная ФЗ а b – ФЗ, при которой b функционально зависит от полного значения атрибута а и не зависит ни от какого подмножества полного значения атрибута а. Пример полной зависимости ФЗ: НомерК, НомерО ДатаН Пример частичной зависимости ФЗ: НомерК, НомерО Плата, т.к. по БП 4:Оплата зависит от объекта недвижимости При частичной зависимости возникают аномалии обновления. Например, при изменении значения Плата для объекта Кв4 необходимо обновить 2 строки. ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 25 Вторая нормальная форма (2НФ)

Определение: 2НФ – отношение находится в 1НФ и каждый атрибут, не входящий в состав первичного ключа характеризуется полной функциональной зависимостью от этого первичного ключа Требование 2НФ: 1. Отношение находится в 1НФ. 2. Отсутствие ЧФЗ от составного ключа. Действия для приведения к 2НФ: 1. Выявление ФЗ (полной, частичной). 2. Устранение ЧФЗ. Для устранения ЧФЗ: Частично зависимые атрибуты удаляются из исходного отношения и помещаются в новое отношение вместе с копией их детерминанта, оставшийся детерминант в исходном отношении будет выступать ВК ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 26 Вторая нормальная форма (2НФ)

Пример 2 (продолжение) Действия для приведения к 2НФ (пример): 1. Выписываем ФЗ отношения Клиент_Аренда_Объект_Владелец (полную ФЗ от ПК, частичные, транзитивные?). ФЗ0: НомерК, НомерО ФИОК, АдресО, ДатаН, ДатаО, Плата, НомерВ, НазвВ - ФЗ от ПК - Полная ФЗ от ПК - Частичная ФЗ от ПК - Транзитивная зависимость 2. Устранение ЧФЗ. ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 27 Вторая нормальная форма (2НФ) 2 НФ

Пример 2 (продолжение) Таблица 2.1 – Отношение Клиент (2 НФ ) Таблица Отношение Объект _ Владелец (2 НФ ) Таблица Отношение Аренда (2 НФ ) ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 28 Вторая нормальная форма (2НФ) Номер Клиента ФИО Клиента К68Иванов И.И. К68Иванов И.И. К67Петров С.С. К67Петров С.С. Номер объекта Адрес объектаПлатаНомер владельца Наименование владельца Кв4г.Харьков ул.Есенина 6, кв760045Васильченко В.А. Д5Харьковская область, пос. Русская Лозовая Филатов В.К. Д7Харьковская область, пос.Циркуны Соловьев К.К. Кв4г.Харьков ул.Есенина 6, кв Васильченко В.А. Номер Клиента Номер объекта Дата начала аренды Дата оконч. аренды К68Кв К68Д К67Д К67Кв

Транзитивная зависимость: Если для атрибутов а, b, c некоторого отношения существуют зависимости а b, b c, то говорят, что атрибут c транзитивно зависит от атрибута а через атрибут b (при условии, что атрибут а функционально не зависит ни от атрибута b, ни от атрибута с) Наличие транзитивных ФЗ приводит к аномалиям обновления Определение 3НФ: 3НФ – отношение находится в 2НФ и не содержит неключевых атрибутов, которые находились бы в транзитивной ФЗ от этого первичного ключа. Требование 3НФ: 1. Отношение находится в 2НФ. 2. Отсутствие ТФЗ от ПК. Действия для приведения к 3НФ: 1. Выявление ТФЗ. 2. Устранение ТФЗ. Для устранения ЧФЗ: Транзитивно зависимые атрибуты удаляются из исходного отношения и помещаются в новое отношение вместе с копией их детерминанта, оставшийся детерминант в исходном отношении будет выступать ВК ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 29 Третья нормальная форма (3НФ)

Пример 2 (продолжение) Действия для приведения к 3НФ (пример): 1. Выписываем ФЗ отношений Аренда (НомерК(ВК), НомерО(ВК),ДатаН, ДатаО) ФЗ1: НомерК, НомерО ДатаН, ДатаО; - Полная ФЗ от ПК Клиент (НомерК, ФИОК) ФЗ2: НомерК ФИОК; - Полная ФЗ от ПК Объект_Владелец (НомерО, АдресО, Плата, НомерВ, НазвВ) ФЗ3: НомерО АдресО, Плата, НомерВ, НазвВ; - Полная ФЗ от ПК ФЗ4: НомерВ НазвВ; - Транзитивная зависимость 2. Устранение ТФЗ. ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 30 Третья нормальная форма (3НФ) 3 НФ

Пример 2 (продолжение) Таблица 2.1 – Отношение Клиент (3 НФ ) Таблица Отношение Объект (3 НФ ) Таблица Отношение Владелец (3 НФ ) Таблица Отношение Аренда (3 НФ ) ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 31 Третья нормальная форма (3НФ) Номер Клиента ФИО Клиента К68Иванов И.И. К68Иванов И.И. К67Петров С.С. К67Петров С.С. Номер Клиента Номер объекта Дата начала аренды Дата оконч. аренды К68Кв К68Д К67Д К67Кв Номер объекта Адрес объектаПлатаНомер владельца Кв4г.Харьков ул.Есенина 6, кв Д5Харьковская область, пос. Русская Лозовая Д7Харьковская область, пос.Циркуны Кв4г.Харьков ул.Есенина 6, кв Номер владельца Наименование владельца 45Васильченко В.А. 67Филатов В.К. 36Соловьев К.К. 45Васильченко В.А.

Пример 2 (продолжение) Схема декомпозиции отношения Клиент_Аренда_Объект_Владелец (в 1НФ) на 4 отношения Клиент, Аренда, Объект, Владелец в 3НФ Клиент_Аренда_Объект_Владелец (1НФ) КлиентАрендаОбъект_Владелец (2НФ) Клиент Аренда ОбъектВладелец (3НФ) Замечания!!! 1) процесс нормализации заключается в декомпозиции исходного отношения посредством последовательного выполнения нескольких операций ПРОЕКЦИИ реляционной алгебры; 2) полученные в результате декомпозиции отношения обеспечивают формирование исходного отношения без потерь, путем использования операции ЕСТЕСТВЕННОГО СОЕДИНЕНИЯ ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 32 Третья нормальная форма (3НФ)

Пример1.Закрепление материала. «Чемпионат по автогонкам Формула-1» Рисунок - Дан фрагмент документа «Чемпионат по автогонкам Формула-1» БП: 1. В команде м.б. только несколько Гонщиков, Гонщик может быть только в одной команде 2. Кол_во кругов зависит от гонки 3. В одну дату на трассе проходит только 1 соревнование Шаг 1. Преобразование к 1 НФ : Чемпионат ( ИН _ Ком, НазвКом, ИН _ Трасса, Назв _ Трасса, Протяж, Кол _ во _ кругов, Место _ Гонщ, Дата _ гонки, ИН _ Гонщ, ФИО _ Гонщ, Страна _ Гонщ ) Шаг 2!!!. Первичный ключ 1 НФ : ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 33 Название командыНазвание трассы Протяжен ность, км Кол-во кругов в гонке Место гонщика Дата проведения гонки ГонщикСтрана гонщика Maclaren-MercedesLe-Man Култхард Д. Монтойя Х.П. Ирландия Колумбия Ferrari1414 Шумахер М. Барикелло Р. Германия Бразилия FerrariRoadX Шумахер М. Барикелло Р. Германия Бразилия …….. …………..……… Название команды Название трассы Протяжен ность, км Кол-во кругов в гонке Место гонщика Дата проведения гонки Гонщик Страна гонщика Maclaren-MercedesLe-Man Култхард Д.Ирландия Maclaren-MercedesLe-Man Монтойя Х.П.Колумбия FerrariLe-Man Шумахер М.Германия FerrariLe-Man Барикелло Р.Бразилия Ferrari RoadX Шумахер М.Германия Ferrari RoadX Барикелло Р.Бразилия …….. …………..………

ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 34

ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 35

БП: 1. Учебный план охватывает все группы 2. Преподаватель может ничего не преподавать в 2011/2012 году, каждый преподаватель закреплен за кафедрой 3. Дисциплина может не читаться в 2011/2012 году 4. Каждая группа закрепляется за факультетом, на факультете много групп. 5. На изучение одной и тот же дисциплины разным группам может выделяться разное количество часов. 6. Каждый преподаватель закреплен за кафедрой 7. Нагрузка преподавателя зависит от группы и дисциплины Доп. ПО «План дипломного проектирования на 2011/2012» БП: 8. Студенты 4,5 курсов кроме изучения плановых дисциплин занимаются написанием дипломной работы одного из типов: бакалаврская работа, дипломная работа специалиста, работа магистра 9. За каждым студентом 4,5 курса (бакалавром, специалистом, магистром) закрепляется руководитель (преподаватель), а также тема дипломной работы и назначается предприятие для прохождения преддипломной практики ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 36 Пример2. В-02 ПО «Учебный план на 2011/2012» Номер группы Кол-во студентовФакультетНазвание дисциплины Количество часов Ф.И.О. преподавателя КафедраНагрузка преподавателя ИФ ИФ Моделирование систем 60Петров П.П.АСУ60 ИФ Имит. моделирование60Сидоров Г.Л. Алексеев Д.Б ЭК ПМММаркетинг30Иванов В.К. Галкин П.П. Маркетинга10 20 ПМ ПМММоделирование систем 8080Петров П.П.АСУ80 ………..…….……..…….……………..

Пример3.Закрепление материала « Сведения о проектах 1 » Рисунок –Дан фрагмент документа « Сведения о проектах » БП: 1. На проекте д. работать хотя бы 1 исполнитель 2. Исполнитель участвует в нескольких проектах, но временно может не участвовать в проектах 3. Заказчик может заказывать более 1 проекта, у проекта только 1 заказчик 4. У исполнителя только 1 должность, которая не зависит от проекта 5.Оклад зависит от должности 6. Бюджет проекта назначается заказчиком и не зависит от количества и квалификации исполнителей ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 37 Название проектаДата начала выполнения Дата завершения проекта Ф.И.О. исполнителей ДолжностьОкладБюджет проекта Название предприятия - заказчика Адрес заказчика Голосовой набор текстов Иванов В.К. Сидоров Г.Л. Доцент Ассистент ЧП Прогресс пр. Свободы 32 Система распознавания графических образов Петров Л.И. Иванов В.К. Доцент Система навигации мобильного робота Яковлев С.А.Ассистент Зав. им. Малышева пер. Светлый ул.12 Система автоматизации бухгалтерского учета Сидоров Г.Л. Яковлев С.А. Ассистент Зав. им. Ленина ул. Пушкинская, 65

Пример4.Закрепление материала « Лечение в санаториях Украины » Рисунок –Дан фрагмент документа « Лечение в санаториях Украины » БП :1. Продолжительность процедуры зависит от только самой процедуры 2. Количество сеансов процедуры зависит от процедуры и клиента, в его конкретный заезд 3. Клиент в одну дату может заезжать только в один санаторий Шаг 1. Преобразование к 1 НФ : Чемпионат ( ИН _ Ком, НазвКом, ИН _ Трасса, Назв _ Трасса, Протяж, Кол _ во _ кругов, Место _ Гонщ, Дата _ гонки, ИН _ Гонщ, ФИО _ Гонщ, Страна _ Гонщ ) Шаг 2!!!. Первичный ключ 1 НФ : ИН _ Трасса, Дата _ гонки, ИН _ Гонщ ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 38 Назва- ние санато- рия Распол ожение сана- тория Средне- годовая темпера тура в городе Паспорт -ные данные пациент а Ф.И.О. пациента Адрес пациент а Дата заезда Срок (дн.) Лечебная процедура Продол- жительность процедуры (мни) Кол-во сеан- сов Код процедуры Название процедуры ВолгаЯлта+10ММ Иванов И.И. ул. Гагарина В-23Бассейн404 ММ Иванов С.И. 21В-23Бассейн4010 Ф-2Массаж3010 Э-22Электротер апия 157 ММ Иванова Н.И. 21Ф-2Массаж3010 В-23Бассейн4012 Ф-1Гимнастика458 ПК Иванова Е.К. 21В-23Бассейн408 Р-34Кислор. коктейль 4515 Э-22Электротер апия 155 КК Петров П.П. пр. Победы ДюльберМисхор+9ММ Сидоров С.С. Ул Ленина, В-21Душ Шарко 155

Код блюда Назва- ние блюда Вид блюда Код продук та Название продукта Энергетич еская ценность прод. (на 100г.) Вес (г.) Способ приго- товления Код автора Ф.И.О. автора рецепта Национальн ость автора 34Оливье салатО23 Б1 О3 О8 Б2 С4 картофель яйца огурцы горошек мясо майонез Измельчить и перемешать Ф55Оливье Л.француз 87Украин- ский борщ первое блюдо О23 О11 О12 О16 Б2 картофель капуста свекла томат мясо СваритьУ54Петренко С.М. украинец ………..…… …….………….. …….. ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 39 Домашняя самостоятельная работа на тему «Нормализация» Вариант1. Дан фрагмент документа «Книга рецептов» БП: 1.У блюда только может быть только один автор 2. Энергетическая ценность продукта зависит только от самого продукта 3. Код блюда уникален 4. Код продукта уникален 5. Способ приготовления зависит от блюда

ХНУРЕ кафедра Інформатики доц. Яковлева О. В. 40 Домашняя самостоятельная работа на тему «Нормализация» Вариант2. Дан фрагмент документа «Сведения о проектах 2» БП:1.Наше предприятие может выполнять одновременно несколько проектов 2.Сотрудники могут одновременно работать на нескольких проектах 3.Оплата зависит от конкретной работы 4.У проекта может быть только один заказчик, заказчик может заказывать много проектов 5.Номер этапа уникален только в рамках проекта Дата начала этапа Дата окончания этапа Номер проекта Название проекта Предприятие – заказчик, шифр, адрес Но мер эта па Код исполнителя Ф.И.О. исполнителей Должность Оплата за этап грн Разработка ИС для «Банк» З110, ЧП Прогресс, пр. Свободы Иванов В.К. Сидоров Г.Л. Доцент Ассистент Иванов В.К. Сидоров Г.Л. Петров Л.И. Доцент Ассистент Доцент Разработка ИС для «Торговое предприятие » З450, Зав. им. Ленина, ул. Пушкинская, Петров Л.И. Иванов В.К. Доцент Яковлев С.А. Иванов В.К. Ассистент Доцент Разработка сайта «Администр ация президента» З110, ЧП Прогресс, пр. Свободы Яковлев С.А. Иванов В.К. Ассистент Доцент Яковлев С.А. Петров Л.И. Иванов В.К. Ассистент Доцент ………..……… ……….……..