- •Лекція 1
- •1. Інформаційні системи на транспорті
- •1.1. Класифікація аіс
- •1.2. Структура автоматизованих інформаційних систем
- •Позамашинне інформаційне забезпечення (на папері) складається з:
- •Комплекс технічних засобів аіс складається з
- •Лекція 2
- •Лекція 3
- •2. Моделі даних
- •2.1. Ієрархічна модель даних
- •2.2. Мережева модель даних
- •2.3. Реляційна модель даних
- •Тобто тут атрибути приймають значення з 4-х доменів.
- •Відношення навантаження:
- •Лекція 4
- •3. Реляційні бази даних
- •Таблиця 3 Відношення одержувач:
- •3.1. Первинний ключ (суперключ) відношення
- •3.2. Можливий (потенційний) ключ відношення
- •3.3. Чужий (зовнішній) ключ відношення
- •Лекція 5
- •4. Проектування реляційної бази даних
- •4.1. Цілі проектування рбд
- •4.2. Універсальне відношення
- •4.2.1. Поняття форми відношення. Перша нормальна форма.
- •4.2.2. Проблеми, що можуть виникнути при роботі з рбд
- •Лекція 6
- •4.3. Нормалізація відношення
- •4.3.1. Нормальна форма Бойса-Кодда
- •4.3.2. Функціональні залежності
- •Лекція 7
- •4.4. Er- метод нормалізації відношень
- •4.4.1. Поняття сутності та зв'язку
- •Лекція 8
- •4.4.3.2. Правило №2
- •4.4.3.3. Правило №3
- •4.4.3.4. Правило №4
- •4.4.3.5. Правило №5
- •4.4.3.6. Правило №6
- •4.5. Перевірка отриманих відношень.
- •Лекція 10
- •5. Основні поняття теорії інформації
- •5.1. Одиниці виміру ступеню невизначеності системи
- •5.2. Властивості ентропії
- •Лекція 11
- •5.3. Ентропія та інформація
- •5.4. Ентропія як міра кількості інформації
- •Лекція 12
- •5.5. Кодування дискретних повідомлень
- •5.5.1. Запис повідомлення за допомогою кодів
- •Лекція 13
- •5.5.2. Способи перетворювання кодів
- •Лекція 14
- •5.6. Класифікація (двійкових) кодів
- •5.6.1. Ненадлишкові коди
- •5.6.2. Надлишкові коди
- •5.6.2.1. Коди з виявленням помилок
- •5.6.2.2. Коди з виправленням помилок
- •Лекція 15
- •1.4. Позамашинне інформаційне забезпечення аіс.
- •1.4.1. Системи уніфікованої документації. Документообіг
- •1.4.2. Класифікація та (ідентифікаційне) кодування інформації
- •1.4.3. Методи (ідентифікаційного) кодування
- •Лекція 16
Лекція 6
4.3. Нормалізація відношення
Для ліквідації зазначених проблем виконують розбивку універсального відношення на 2 і більше відношень. Цей етап проектування РБД називається нормалізацією (чи декомпозицією) відношення.
Перед нормалізацією відношення повинно знаходитися в першій нормальній формі.
4.3.1. Нормальна форма Бойса-Кодда
Запитання: Чи можна, не аналізуючи проблем, що можуть виникнути при роботі з відношенням, визначити, чи потребує це відношення нормалізації?
Відповідь: Якщо відношення знаходиться в нормальній формі Бойса-Кодда (НФБК), то воно майже напевно не потребує декомпозиції і може застосовуватися в РБД, інакше потрібна його нормалізація.
Відношення знаходиться в НФБК, якщо і тільки якщо кожний детермінант відношення є можливим ключем відношення.
Що стосується можливих ключів універсального відношення НАВАНТАЖЕННЯ, то їх два й обидва вони складові:
<Код_одержувача, Код_вантажу>;
<Код_одержувача, Найм_вантажу>.
4.3.2. Функціональні залежності
Детермінант. Нехай дані 2 атрибути: А та В, то говорять, що атрибут В функціонально залежить від атрибуту А, якщо для кожного значення атрибуту А існує рівно одне пов'язане з ним значення атрибуту В (у будь-які моменти часу). Або навпаки, атрибут А є детермінантом атрибуту В. А й В можуть бути складовими, тобто кожний з них може бути складений з декількох атрибутів.
У конкретній ситуації функціональна залежність визначається шляхом деталізації властивостей всіх атрибутів у відношенні і обґрунтування висновку про те, як атрибути співвідносяться між собою. Функціональні залежності не можуть бути доведені шляхом простого перегляду окремого екземпляра відношення. На його основі може бути висунуте тільки припущення про наявність функціональної залежності між конкретними атрибутами. Але кожне таке припущення повинне бути перевірене на предмет того, чи може порушитися ця передбачувана функціональна залежність після додавання кортежів у відношення, або після зміни значень атрибутів у майбутньому.
У будь-якому випадку при визначенні функціональної залежності не слід відволікатися від смислу самих атрибутів, від їх взаємної смислової залежності, а також від обмежень, що накладаються на можливі значення цих атрибутів.
Візьмемо два атрибути <Назва_одержувача> та <Код_одержувача>.
Переглянувши екземпляр відношення можна установити, що одному значенню атрибута <Код_одержувача> відповідає одне значення атрибута <Назва_одержувача>. Отже, можна припустити, що атрибут <Назва_одержувача> функціонально залежить від атрибута <Код_одержувача>.
Тепер перевіримо за змістом це припущення. А чи може одержувач з певним кодом мати іншу назву?
Кожен одержувач має унікальний код, тобто немає і не може бути двох одержувачів з однаковими кодами. Отже, у відношення не може бути в принципі доданий кортеж, у якому повториться код одержувача з іншою назвою одержувача. Код одержувача може повторитися тільки з тією же самою назвою. З цього боку гіпотеза про існування функціональної залежності між атрибутами <Код_одержувача> і <Назва_одержувача> підтверджується.
З іншого боку, чи може той самий одержувач мати кілька різних назв? Очевидно, що ні, якщо інше не обговорено окремо чи спеціально. Якщо такого застереження нема, то можна зробити остаточний висновок про те, що між атрибутами <Код_одержувача> і <Назва_одержувача> дійсно існує функціональна залежність, причому атрибут <Код_одержувача> є детермінантом атрибута <Назва_одержувача>.
Необхідно перевірити, чи є зворотна функціональна залежність між цими атрибутами.
У представленому екземплярі відношення зустрічається значення атрибута <Назва_одержувача>, якому відповідають два значення атрибута <Код_одержувача>. Два одержувачі 1010 і 1425 мають однакові назви. Отже, зворотна функціональна залежність між цими атрибутами відсутня. Атрибут <Назва_одержувача> не є детермінантом атрибута <Код_одержувача>.
На схемі функціональних залежностей між атрибутами відношення сама залежність показується стрілочкою від детермінанта до залежного атрибута.
Якщо у відношенні є такі атрибути, що не залежать функціонально від жодного з інших атрибутів відношення, то необхідно перевірити їхню залежність від пар атрибутів. В число останніх, як правило, включаються знайдені раніше детермінанти.
Наприклад: атрибут <Маса_вантажу> функціонально не залежить від жодного атрибута відношення НАВАНТАЖЕННЯ. Пара атрибутів <Код_одержувача, Код_вантажу> є детермінантом для атрибута <Маса_вантажу>. Кожний з атрибутів пари є детермінантом: <Код_одержувача> для атрибутів <Назва_одержувача> і <Код_ЄСР>, <Код_вантажу> для атрибута <Найм_вантажу>.
На схемі функціональних залежностей атрибути обведені кружечком, а пари атрибутів об'єднані рамочкою. В правому нижньому куті приводиться список детермінантів.
В лівому нижньому куті схеми функціональних залежностей приводиться список можливих ключів.
Схема функціональних залежностей між атрибутами відношення НАВАНТАЖЕННЯ(Код_одержувача, Назва_одержувача, Код_ЄСР, Код_вантажу, Найменування_вантажу, Маса_вантажу) представлена на рисунку 7.

Висновок: не кожний детермінант є можливим ключем, а тільки 4-й та 5-й. Тому відношення НАВАНТАЖЕННЯ не знаходиться в НФБК, отже потрібна його декомпозиція.
На цьому закінчується другий етап проектування РБД.
