Навігація
Головна
ПОСЛУГИ
Авторизація/Реєстрація
Реклама на сайті
Операції з даними в реляційній моделі-модель прогнозу ризику банкрутстваОсновні властивості простору й часу: субстанційна та реляційна...Моделі біоетикиЕволюційна модель.
НормалізаціяЗагальні заходи та засоби нормалізації параметрів мікрокліматуЗаходи щодо нормалізації мікрокліматуЛегалізація православної церкви. Нормалізація стосунків з державою....Які існують заходи нормалізації параметрів в умовах нагріваючого...
 
Головна arrow Банківська справа arrow Інформаційні системи і технології в банках
< Попередня   ЗМІСТ   Наступна >

Реляційна модель даних

Мережеві та ієрархічні моделі даних були розроблені в період виникнення СУБД. Наведений у підрозділі 2.4.1 (див. рис. 2 .17, 2.18) приклад організації даних навіть на основі двох типів записів підтверджують складність ієрархічної та мережевої моделей. Організація моделей даних на прикладі десятків, сотень таких типів записів значно ускладнюється. Удосконаленя цих моделей даних привели до появи нової моделі - реляційної. Реляційна модель спрямована на обробку не окремих типів записів, а на документ у цілому. Крім того, реляційна модель не вимагає від користувачів знань програмування, а лише знань основ інформаційної технології та вміння працювати з персональним комп'ютером.

Реляційні моделі даних також належать до моделей на основі записів, однак відрізняються від розглянутих вище мережевих та ієрархічних простотою структур даних, зручним для користувача табличним представленням і доступом до даних. В основі реляційної моделі даних лежить поняття відношення (relation) - двовимірна таблиця (табл. 2.4).

Таблиця 2.4

Приклад відношення

Прізвище та ініціали

Курс

Група

Спеціальність

Аверчук Л. Д

1

105

Банківська справа

<— Кортеж 1

Невойда0. М

1

105

Банківська справа

<— Кортеж 2

Співак П. Б

2

203

Банківська справа

<— Кортеж 3

Кожний рядок у таблиці містить певні дані, кожний стовпець таблиці описує атрибути даних. Інколи рядки називають кортежами, а стовпці - атрибутами. У практичній роботі буває й інша інтерпретація цих понять (табл. 2.5).

Таблиця 2.5

Еквівалентна термінологія реляційної моделі

Термінологія реляційної моделі

Термінологія програміста

Термінологія користувача

Відношення

Файл

Таблиця

Кортеж

Запис

Рядок

Атрибут

Поле

Стовпець

Щоб двовимірна таблиця була відношенням, вона має задовольняти певні обмеження. По-перше, значення в комірках таблиці мають бути одиночними. Усі записи у стовпці мають бути одного типу. Наприклад, якщо третій стовпець першого рядка таблиці містить номер групи, тоді і в інших рядках таблиці третій стовпець також має містити номер групи. Кожний стовпець повинен мати унікальне ім'я. Нарешті, у відношенні не може бути двох однакових рядків. Узагальнений формат відношення - Студент (Прізвище та ім'я, Курс, Група, Спеціальність) - називається структурою відношення.

Нормалізація даних

Для розуміння поняття "нормалізація" треба перш за все визначити два важливі терміни: функціональна залежність і ключ.

Функціональна залежність - це зв'язок між атрибутами. Припустімо, якщо нам відоме значення одного атрибута, тоді можемо знайти значення іншого атрибута. Наприклад, якщо нам відомий номер рахунку клієнта, тоді ми можемо визначити стан цього рахунку. У такому разі ми можемо сказати, що атрибут СтанРахункуКлієнта функціонально залежить від атрибута Номер Рахунку Клієнта. Іншими словами, якщо нам відоме значення X, ми можемо визначити значення Y. Функціональні залежності позначаються так: НомерСтудента -> Спеціальність.

Вираз читається так: атрибут НомерСтудента функціонально визначає атрибут Спеціальність, або атрибут Спеціальність залежить від атрибута НомерСтудента. Атрибути з правого боку від стрілки називаються детермінантами.

У функціональні залежності можуть бути включені групи атрибутів. Розглянемо відношення Оцінки (НомерСтудента, Дисципліна, Оцінка). Функціональна залежність (НомерСтудента, Дисципліна) -> Оцінка визначає оцінку студента з дисципліни.

Ключ (key) - це група з одного або більше атрибутів, яка унікальним чином ідентифікує рядок. Розглянемо відношення Секція, яке має атрибути НомерСтудента, Секція, Плата (табл. 2.6).

Таблиця 2.6

Відношення Секція

НомерСтудента

Секція

Плата

10701

Боротьба

70

15002

Плавання

45

20003

Гімнастика

80

Рядок цього відношення містить інформацію про те, що студент відвідує певну секцію за певну плату. За умови, що студент одночасно не може відвідувати більше ніж одну секцію, значення атрибута НомерСтудента ідентифікує єдиний рядок, тому цей атрибут є ключем.

Ключі можуть також складатися з кількох атрибутів. Наприклад, якщо студентам дозволено відвідувати більше ніж одну секцію, тоді один і той самий номер студента може з'явитись у різних рядках таблиці і атрибут НомерСтудента не буде унікальним чином визначати рядок. У цьому разі ключем буде комбінація НомерСтудента, Секція. Слід зазначити, що кожне відношення має мінімум один ключ, оскільки будь-яке відношення не може мати однакових рядків.

Нормалізація - це процес аналізу відношень з метою виявлення і ліквідації аномалій модифікації. Аномалії можуть бути ліквідовані шляхом розбиття початкового відношення на два або більше нових відношень.

Для розуміння суті аномалії модифікації знову розглянемо відношення Секція (див. табл. 2.6). Якщо ми вилучимо рядок, в якому записані дані про студента з номером 10701, то не тільки втратимо інформацію про те, що студент з номером 10701 є борцем, а й той факт, що абонементу секцію боротьби коштує 70 грн. Це називається аномалією вилучення - тобто, вилучаючи факти щодо однієї сутності (студент із номером 10701 є борцем), ми вилучаємо факти щодо іншої сутності (плата за абонемент у секцію боротьби). Виконавши одну операцію вилучення, ми втрачаємо інформацію про дві сутності.

На прикладі того ж самого відношення можна продемонструвати аномалію вставки. Припустімо, ми хочемо записати в базу даних той факт, що абонемент у секцію тенісу коштує 120 грн, однак ми не можемо ввести ці дані у відношення Секція доти, доки хоча 6 один студент не запишеться до секції тенісу. Це обмеження видається безглуздим. Тобто, щоб указати вартість абонемента, слід чекати, поки хтось запишеться в секцію. Це обмеження називається аномалією вставки. Суть його в тому, що ми не можемо записати до таблиці певний факт про одну сутність, не вказавши додатково іншого факту про іншу сутність.

Ми можемо ліквідувати як аномалію вилучення, так і аномалію вставки, розділивши відношення Секція на два відношення, кожне з яких буде мати інформацію щодо певної теми. Наприклад, у перше відношення ми включимо атрибути НомерСтудента і Секція (назвемо це відношення Студент/Секція), а в інше - атрибути Секція і Плата (назвемо це відношення Секція/Плата). Ці два відношення з даними з нашого прикладу відображено в табл. 2.7,2.8.

Таблиця 2.7 Студент/Секція (НомерСтудента, Секція)

НомерСтудента

Секція

10701

Боротьба

15002

Плавання

20003

Гімнастика

Таблиця 2.8 Секція/Плата (Секція, Плата)

Секція

Плата

Боротьба

70

Гімнастика

80

Плавання

45

Тепер, якщо ми вилучимо запис про студента з номером 16002 із таблиці Студент/Секція, ми вже не втратимо того факту, що абонемент у секцію Плавання коштує 45 грн. Більш того, ми можемо додати в таблицю Секція/Плата секцію Теніс із зазначенням вартості абонемента, не чекаючи, поки хтось запишеться в цю секцію. Таким чином, аномалії вилучення і вставки ліквідовані.

Поділ одного відношення на два має, однак, один недолік - додавання даних до однієї таблиці треба супроводжувати додаванням відповідних даних до іншої таблиці. Цей недолік отримав назву обмеження цілісності за зовнішнім ключем. Тому щоразу за поділу відношення на два або більше нових слід обов'язково перевіряти наявність цілісності даних. Цього досягають за допомогою форм нормалізацій відношень.

Є п'ять основних форм нормалізації відношень (від 1NF до 5NF). Кожна наступна ліквідує один із видів надлишкових даних. На практиці нормальні форми 4NF і 5NF використовують украй рідко.

Перша нормальна форма (1NF) закладає основи реляційної системи. За першої нормальної форми всі атрибути відношення є простими. В 1NF на перетині рядка і стовпця значення не можуть повторюватись, тобто не можуть розташовуватись кілька значень. У табл. 2.9 Клієнти/Орендарі наведено базу даних без нормалізації, ключовим атрибутом якої є Код_клієнта. На перетині рядків і стовпців табл. 2.9 міститься кілька значень, а саме: два значення (РА4 і РА5) у комірці Код_ об'єкта; два значення в комірці Адреса тощо. Значеннями, що повторюються, називаються значення, які утворюються з одного і більше атрибутів таблиці і визначаються ключовим атрибутом таблиці. Таким чином, структура значень, що повторюються, для табл. 2.9 є. такою: Значення, що повторюються (Код_об'єкта, Адреса, Початкова_дата, Кінцева_дата, Сума_оренди, Код_власника, Ім'я^власника).

Таблиця 2.9 Ненормалізована таблиця Клієнти/Орендарі

Код клієнта

Ім'я клієнта

Код об'єкта нерухомості

Адреса об'єкта

Початкова дата

оренди

Кінцева

дата оренди

Орендна плата

Код власника

Ім'я власника

R76

Вовк Б. Вовк Б.

РА4 РА5

Львів, вул. Панча, 26 Стрий, вул. Коперника, 1

1.06.2002 1.08.2002

31.12.05 31.12.06

4000 5800

С040 С039

Леськів В. Ващук С.

Савчук Д.

PA 8

Львів, вул. Панча, 26

1.07.2002

15.07.2004

3900

С040

Леськів В.

R77

Савчук Д.

PA9

Стрий, вул. Стуса, 12

1.09.2002

31.08.2007

6700

С039

ВащукС.

Савчук Д.

РАЮ

Львів, вул. Зелена, 98

1.04.2002

31.05.2006

4700

С041

Мазур X.

Отже, щоб перетворити ненормалізовану таблицю в першу нормальну форму, треба досягти того, щоб на перетині кожного рядка і кожного стовпця стояло тільки одне значення. Цього можна досягнути двома шляхами:

• вилучення значень, що повторюються, за допомогою введення в кожний рядок відповідних відомостей про клієнта. Первинним ключем цього відношення виберемо групу (Код_клієнта і Код_ об'єкта) і розташуємо атрибути цього первинного ключа поруч, зліва у відношенні (табл. 2.10);

• вилучення значень, що повторюються, і переміщення їх в інше відношення разом із копією ключового атрибута Код_ клієнта (табл. 2.1 1, 2.12).

Таблиця 2.10

Перша нормальна форма таблиці Клієнти/Орендарі

Код клієнта

Код об'єкта нерухомості

Ім'я клієнта

Адреса об'єкта

Початкова дата

оренди

Кінцева дата оренди

Орендна плата

Код власника

Ім'я власника

R76

РА4

Вовк Б.

Львів, вул. Панча, 26

1.06.2002

31.12.05

4000

С040

Леськів В.

R76

РА5

Вовк Б.

Стрмй, вул. Коперника, 12

1.08.2002

31.12.06

5800

С039

Ващук С.

R77

РА8

Савчук Д.

Львів, вул. Панча, 26

1.07.2002

15.07.04

3900

С040

Леськів В.

R77

РА9

Савчук Д.

Стрий, вул. Коперника,12

1.09.2002

31.08.07

6700

С039

Ващук С.

R77 п.

РАЮ

Савчук Д.

Львів, вул. Зелена,98

1.04.2002

31.05.06

4700

С041

Мазур X.

Відношення Клієнти/Орендарі тепер міститься в першій нормальній формі, оскільки на перетині кожного рядка і кожного стовпця маємо одне значення. У той же час у цьому відношенні є дані про клієнтів, орендовані об'єкти нерухомості і їхніх власників, які кілька разів повторюються. Таким чином, відношення Клієнти/Орендарі характеризується значною надлишко-вістю даних. Для уникнення цього недоліку потрібно перетворити таблицю у другу нормальну форму.

Використовуючи другий підхід нормалізації, значення, що повторюються (відомості про орендовані об'єкти нерухомості), вилучають із відношення, що нормалізуються, і вносять в інше відношення разом із копією вхідного ключового атрибута (табл. 2.11). Залишок атрибутів вхідного відношення наведено в табл. 2.12. Первинними ключами для відношення Код_об'єкта/Орендар буде Код_клієнта і Код_об'єкта, а для відношення Клієнти - первинний ключ Код_клієнта

Таблиця 2.11

Альтернативне представлення першої нормальної форми -_відношення Код_ об'єкта/Орендар

Код клієнта

Код об'єкта

Адреса об'єкта

Початкова дата оренди

Кінцева дата оренди

Орендна плата

Код власника

Ім'я власника

R76

РА4

Львів, вул. Панча, 26

1.06.2002

31.12.2005

4000

С040

Леськів В.

R76

РА5

Стрий, вул. Коперника, 12

1.08.2002

31.12.2006

5800

С039

Ващук С.

R77

РА8

Львів, вул. Панча, 26

1.07.2002

15.07.2004

3900

С040

Леськів В.

R77

РА9

Стрий, вуя. Коперника, 12

1.09.2002

31.08.2007

6700

С039

Ващук С.

R77

РАЮ

Львів, вул. Зелена, 98

1.04.2002

J 31.05.2006

4700

С041

Мазур X.

Таблица 2.12

Альтернативне представлення першої нормальної форми - відношення Клієнти

Код_клієнта

Ім'я_клієнта

R76

Вовк Б.

R77

Савчук Д.

Обидва відношення - Код_об'єкта/Орендар і Клієнти - містяться в першій нормальній формі, оскільки на перетині кожного рядка і кожного стовпця стоїть єдине значення. Відношення Клієнти містить дані про клієнтів оренди, а відношення Код_об'єкта/Орендар - про орендовані об'єкти нерухомості та їхніх власників. Однак, як видно з табл. 2.11, відношення також характеризується певною надлишковістю.

Для демонстрації подальшого процесу нормалізації відношень з переходом від 1NF до 2NF будемо використовувати тільки відношення Клієнти/Орендарі (див. табл. 2.10).

Друга нормальна форма заснована на понятті повної функціональної залежності.

У будь-якому відношенні атрибут В називається повністю функціонально залежним від атрибута А, якщо атрибут В функціонально залежить від повного значення атрибута А і не залежить від жодної підмножини повного значення атрибута А.

У другій нормальній формі всі атрибути відношення є простими і кожен неключовий атрибут функціонально повно залежить від ключа. Для ілюстрації розглянемо таку функціональну залежність: Прізвище_студента. Предмет -> Оцінка. Тут кожна пара значень Прізвище_студента і

Предмет пов'язана з єдиним значенням Оцінка. Ця функціональна залежність є повною, оскільки Оцінка не може бути визначена окремо за Прізвищем або за Предметом. У функціональній залежності Код-співробітника, Ім'я співробітника -> Код_підрозділу кожна пара значень також пов'язана з єдиним значенням Код_підрозділу. Однак ця функціональна залежність не є повною, оскільки Код-пїдрозділу також функціонально залежить від атрибута Код_співробітника.

Друга нормальна форма застосовується до відношень зі складними ключами, тобто до таких відношень, первинний ключ яких складається з двох або більше атрибутів. Нормалізація iiVF-відношень з утворенням 2МР-відношень передбачає вилучення часткових функціональних залежностей.

На рис. 2.18 показано функціональні залежності для відношення Клієнти/Орендарі (див. табл. 2.10) із первинним ключем (Код_клієнта, Код_об'єкта). Лінія зі стрілкою вказує на функціоналну залежність вказаного реквізиту від реквізиту поміченого лінією без стрілки. Після виявлення функціональних залежностей процес нормалізації відношення Клієнти/Орендарі продовжується перевіркою його належності до другої нормальної форми. Для цього потрібно знайти принаймні один випадок часткової залежності від первинного ключа. Неважко помітити, що атрибут їм'я_клієнта частково залежить від первинного ключа, тобто він залежить тільки від атрибута Код_клієнта (ця залежність представлена як Ф32). Окрім того, атрибути об'єкта нерухомості (Адреса__об'єкта, Орендна_плата, Код__ власника, Ім'я_власника) також частково залежать від первинного ключа, але в цьому разі тільки від атрибута Код_об'єкта (ця залежність представлена як ФЗЗ).

Функціональні залежності відношення Клієнти/Орендарі

Рис. 2.18. Функціональні залежності відношення Клієнти/Орендарі

У свою чергу, атрибути орендованих об'єктів нерухомості (Початкова дата, Кінцева дата) повністю функціонально залежать від первинного ключа в цілому (ця залежність представлена як Ф31). Таким чином, відношенню Клієнти/Орендарі притаманні функціональні залежності Ф31-Ф36 (табл. 2.13).

Таблиця 2.13

Функціональні залежності відношення Клієнти/Орендарі

Функціональні залежності

Формат відношення

Залежність

ФЗІ

Код_кліента, Код_об'єкта -> Початкова дата оренди. Кінцева дата оренди

Первинний ключ

Ф32

Код_клієнта -> Ім'я клієнта

Часткова залежність

ФЗЗ

Код_об'єкта ->Адреса об'єкта, Орендна плата, Код власника, Ім'я власника

Часткова залежність

Ф34

Код власника -> Ім'я власника

Транзитивна залежність

Ф35

Код_клієнта, Початкова дата оренди -> Код об'єкта, Адреса об'єкта, Кінцева дата оренди, Орендна плата, Код власника, Ім'я власника

Потенційний КЛЮЧ

Ф36

Код_об'єкта, Початкова дата оренди -> Код клієнта, Ім'я клієнта, Кінцева дата оренди

Потенційний ключ

Виявлення часткових залежностей усередині відношення Клієнти/Орендарі означає, що відношення не міститься у другій нормальній формі. Для перетворення відношення Клієнти/Орендарі у 2NF слід створити нові відношення, причому так, щоб атрибути, які не входять до первинного ключа, були переміщені в них разом із копією частини первинного ключа, від якої вони функціонально залежать. Використання цього правила в нашому варіанті приведе до створення трьох нових відношень - Клієнти, Об'єкти_оренди, Орендарі, які представлені в табл. 2.14,2.15, 2.16 відповідно.

Таблиця 2.14

Відношення Клієнти

Код_клієнта

Ім'я_клієнта

R76

Вовк Б.

R77

Савчук Д.

Таблиця 2.15

Відношення Об'єкти_Оренди

Код клієнта

Код об'єкта

Початкова дата оренди

Кінцева дата оренди

R76

РА4

1.06.2002

31.12.2005

R76

РА5

1.08.2002

31.12.2006

R77

РА8

1.07.2002

15.07.2004

R77

РА9

1.09.2002

31.08.2007

R77

РАЮ

1.04.2002

31.05.2006

Таблиця 2.16

Відношення Орендарі

Код

об'єкта

Адреса

об'єкта

Орендна

плата

Код

власника

Ім'я

власника

РА4

Львів, вул. Панча, 26

4000

С040

Леськів В.

РА5

Стрий, вул. Коперника, 12

5800

С039

Ващук С.

РА8

Львів, вул. Панча, 26

3900

С040

Леськів В.

РА9

Стрий, вул. Коперника, 12

6700

С039

Ващук С.

РА10

Львів, вул. Зелена, 98

4700

С041

Мазур X.

Третя нормальна форма (ЗНФ) - відношення, яке міститься в першій і другій нормальних формах і не має атрибутів, які не входять до первинного ключа і які не перебувають у транзитивній функціональній залежності від цього первинного ключа.

У третій нормальній формі всі атрибути відношення є простими і кожен неключовий атрибут функціонально повно залежить від ключа, причому кожен неключовий атрибут нетранзитивно залежить від ключа. Хоча 2NF-eidHouteHHK) меншою мірою притаманна надлишковість даних, ніж lNF-відношенню, вони ще можуть страждати від аномалій поновлення. Так, під час спроби поновлення імені власника нерухомості, наприклад, Леськів С.В. з кодом С040, треба буде поновити два рядки відношення Орендарі (див. табл. 2.16). Якщо поновити тільки один із цих двох рядків, то база даних трапляє у протиріччя. Ця аномалія поновлення пояснюється транзитивною залежністю - якщо для атрибутів А, В і С деякого відношення існують залежності виду А->В і В->С, тоді кажуть, що атрибут С транзитивно залежить від атрибута А через атрибут В, за умови, що атрибут А функціонально не залежить ні від атрибута В, ні від атрибута С.

Транзитивна залежність може бути ліквідована шляхом приведення цього відношення до третьої нормальної форми.

Таким чином, нормалізація 2NF-eidnouienb з утворенням 3NF-eidno-шень передбачає вилучення транзитивних залежностей. Якщо у відношенні існує транзитивна залежність між атрибутами, транзитивно-залежні атрибути вилучаються з нього і переміщуються в нове відношення разом із копією їх детермінантів.

Для виконання таких дій спочатку розглянемо функціональні залежності у відношеннях Клієнти, Об'єкти)_оренди і Орендарі. Відношення Клієнти

Ф32 Код клієнта->Ім'я клієнта Відношення Об'єкти оренди

Ф31 Код клієнта, Код об'єкта->Початкова дата оренди, Кінцева дата оренди

Ф35 Код клієнта, Початкова дата оренди -> Код об'єкта. Адреса об'єкта, Кінцева дата оренди, Орендна плата, Код власника, Ім'я власника

Ф36 Код об'єкта, Початкова дата оренди -> Код клієнта, їм'я клієнта, Кінцева дата оренди Відношення Орендарі

ФЗЗ Код об'єкта -> Адреса об'єкта, Орендна плата, Код власника, Ім'я власника

Ф34 Код власника Ім'я власника

Усі атрибути, що не входять до первинного ключа відношень Клієнти і Об'єкти_оренди, функціонально залежні тільки від їх первинних ключів. Отже, відношення не мають транзитивних залежностей, а тому вони вже у третій нормальній формі.

Усі атрибути, що не входять до первинного ключа відношення Орендарі, функціонально залежать від первинного ключа, за винятком атрибута Ім'я власника, який також залежить і від атрибута Код власника. Це типовий приклад транзитивної залежності.

Для перетворення відношення Орендарі у третю нормальну форму потрібно перш за все вилучити транзитивну залежність шляхом створення двох нових відношень Довідник_об'єктів_оренди Довідник_Орендарі, які наведені в табл. 2.17, 2.18.

Таблиця 2.17

Довідник_ об'єктів_ оренди

Код об'єкта

Адреса об'єкта

Орендна плата

Код власника

РА4

Львів, вул. Панча, 26

4000

С040

РА5

Стрий, вул. Коперника,12

5800

С039

РА8

Львів, вул. Панча, 26

3900

С040

РА9

Стрий, вул. Коперника,12

6700

С039

РА10

Львів, вул. Зелена, 98

4700

С04І

Таблиця 2.18

Довідник_Орендарі

Код власника

Ім'я власника об'єкта

С040

Леськів В.

С039

Ващук С.

С041

Мазур X.

Таким чином, у результаті виконання нормалізації вхідне відношення (див. табл. 2.10) було перетворено в чотири окремі відношення (див. табл. 2.14, 2.15, 2.16,2.17), кожне з яких у третій нормальній формі. На рис. 2.19 наведено схему процесу перетворення, яка пояснює, як lNF-відношення було перетворено в чотири 3№-відношення.

Схема декомпозиції lNF-відношення Клієнти

Рис. 2.19. Схема декомпозиції lNF-відношення Клієнти/Орендарі на чотири відношення у третій нормальній формі

Подальша нормалізація відношень може привести до отримання нових відношень у четвертій і п'ятій нормальних формах.

 
Якщо Ви помітили помилку в тексті позначте слово та натисніть Shift + Enter
< Попередня   ЗМІСТ   Наступна >
 
Дисципліни
Агропромисловість
Банківська справа
БЖД
Бухоблік та Аудит
Географія
Документознавство
Екологія
Економіка
Етика та Естетика
Журналістика
Інвестування
Інформатика
Історія
Культурологія
Література
Логіка
Логістика
Маркетинг
Медицина
Менеджмент
Нерухомість
Педагогіка
Політологія
Політекономія
Право
Природознавство
Психологія
Релігієзнавство
Риторика
РПС
Соціологія
Статистика
Страхова справа
Техніка
Товарознавство
Туризм
Філософія
Фінанси