R1 | |
Співробітник | Телефон |
Иванов | |
Петров | |
Сидоров | |
Егоров | |
Рис. 7.1. Ненадлишкове дублювання. |
Розрізняють просте (ненадлишкове) і надлишкове дублювання даних. Просте дублювання допускається в БД. Надлишкове дублювання даних може приводити до проблем при їхній обробці.
Приклад ненадлишкового дублювання даних приведений на рис. 7.1 в відношенні R1 з атрибутами Співробітник і Телефон. Для співробітників, що знаходяться в одному приміщенні, номера телефонів збігаються. Номер телефону 4004 зустрічається кілька разів, хоча для кожного співробітника номер телефону унікальний. Тому жоден з номерів не є надлишковим. При видаленні одного з номерів телефонів буде загублена інформація про те, по якому номеру можна додзвонитися до одного зі службовців.
Приклад надлишкового дублювання (надмірності) приведений на рис. 7.2 у відношення R2, що, доповнено атрибутом Н_кімн (номер кімнати співробітника). Природно припустити, що всі співробітники в одній кімнаті мають однаковий телефон. Отже, у відношенні мається надлишкове дублювання даних. Так, у зв'язку з тим, що Сідоров і Єгоров знаходяться в тій же кімнаті, що і Петров, їхнього номера можна довідатися з запису зі зведеннями про Петрова.
|
|
R2 | R3 | |||||
Співробітник | Телефон | Н_кімн | Співробітник | Телефон | Н_комн | |
Іванов | Іванов | |||||
Петров | Петров | |||||
Сідоров | Сідоров | - | ||||
Єгоров | Єгоров | - | ||||
Рис. 7.2. Надлишкове дублювання |
На рис. 7.2 приведений приклад невдалого відношення R3, у якому замість телефонів Сидорова й Єгорова поставлені прочерки (невизначені значення). По-перше, при програмуванні прийдеться передбачити механізм обробки інформації для прочерків у таблиці. По-друге, пам'ять усе рівно виділяється під значення поля з прочерками, хоча дублювання даних і виключено. По-третє, що важливо, при виключенні з колективу Петрова запис зі зведеннями про нього буде виключений з таблиці, і буде знищена інформація про телефон 111-й кімнати, що неприпустимо.
Вихід з цієї ситуації приведений на рис. 7.3, де показані два відношення R4 (містить інформацію про номери телефонів у кожній з кімнат) і R5 (містить інформацію про номери кімнат, у яких розташовуються співробітники). Ці відношення отримані шляхом декомпозиції вихідного відношення R3. Тепер, якщо Петрова звільнять і видалять інформацію про нього з БД, це не приведе до втрати інформації про номер телефону в 111-й кімнаті.
R4 | R5 | |||
Телефон | Н_кімн | Співробітник | Н_кімн | |
Іванов | ||||
Петров | ||||
Сідоров | ||||
Єгоров | ||||
Рис. 7.3. Виключення надлишкового дублювання |
Процедура декомпозиції одного відношення на два відношення - є основною процедурою нормалізації відношень при проектуванні БД.
|
|
Надлишкове дублювання даних створює проблеми при обробці полів відношення, які називають аномаліями відновлення відношень. Ці проблеми виникають при спробі вилучення, додавання чи редагування полів.
Аномаліями називається така ситуація в таблицях, що приводить до протиріч у БД або істотно ускладнює обробку даних.
Є три види аномалій: аномалії модифікації (чи редагування), аномалії вилучення й аномалії додавання.
Аномалії модифікації проявляються в тім, що зміна значення одного даного може викликати перегляд усієї таблиці і відповідну зміну деяких інших записів таблиці.
Наприклад, зміна номера телефону в кімнаті 111 потребує перегляду всієї таблиці R2 і зміни поля Телефон у записах, що відносяться до Петрова, Сідорова й Єгорова.
Аномалії вилучення полягають у тому, що при вилученні якого-небудь даного з таблиці може зникнути й інша інформація, що не зв'язана прямо з вилученим даним.
Наприклад у таблиці R2 вилучення запису про Іванова приводить до зникнення інформації про номер телефону в 109-й кімнаті.
Аномалії додавання виникають у випадках, коли інформацію в таблицю не можна помістити доти, поки вона неповна, або вставка нового запису вимагає додаткового перегляду таблиці.
Приклад, додавання нового співробітника в таблицю R2. Очевидно, буде протиприродним збереження даних у таблиці тільки про кімнату і номер телефону в ній, поки ніхто зі співробітників не поміщений у неї. Більш того, якщо в таблиці R2 поле Співробітник є ключовим, то збереження в ній неповних записів з відсутнім прізвищем службовця просто неприпустимо через невизначеність значення ключового поля.