Надлишкове дублювання даних і аномалії

R1
Співробітник	Телефон
Иванов	3003
Петров	4004
Сидоров	4004
Егоров	4004
Рис. 7.1. Ненадлишкове дублювання .

Розрізняють просте (ненадлишкове) і надлишкове дублювання даних. Просте дублювання допускається в БД. Надлишкове дублювання даних може приводити до проблем при їхній обробці.

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

Приклад надлишкового дублювання (надмірності) приведений на рис. 7.2 у відношення R2, що, доповнено атрибутом Н_кімн (номер кімнати співробітника). Природно припустити, що всі співробітники в одній кімнаті мають однаковий телефон. Отже, у відношенні мається надлишкове дублювання даних. Так, у зв'язку з тим, що Сідоров і Єгоров знаходяться в тій же кімнаті, що і Петров, їхнього номера можна довідатися з запису зі зведеннями про Петрова.

R2				R3
Співробітник	Телефон	Н_кімн		Співробітник	Телефон	Н_комн
Іванов	3003	109		Іванов	3003	109
Петров	4004	111		Петров	4004	111
Сідоров	4004	111		Сідоров	-	111
Єгоров	4004	111		Єгоров	-	111
Рис. 7.2. Надлишкове дублювання

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

Вихід з цієї ситуації приведений на рис. 7.3, де показані два відношення R4 (містить інформацію про номери телефонів у кожній з кімнат) і R5 (містить інформацію про номери кімнат, у яких розташовуються співробітники). Ці відношення отримані шляхом декомпозиції вихідного відношення R3. Тепер, якщо Петрова звільнять і видалять інформацію про нього з БД, це не приведе до втрати інформації про номер телефону в 111-й кімнаті.

R4			R5
Телефон	Н_кімн		Співробітник	Н_кімн
3003	109		Іванов	109
4004	111		Петров	111
			Сідоров		111
			Єгоров		111
Рис. 7.3. Виключення надлишкового дублювання

Процедура декомпозиції одного відношення на два відношення - є основною процедурою нормалізації відношень при проектуванні БД.

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

Аномаліями називається така ситуація в таблицях, що приводить до протиріч у БД або істотно ускладнює обробку даних.

Є три види аномалій: аномалії модифікації (чи редагування), аномалії вилучення й аномалії додавання.

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

Наприклад, зміна номера телефону в кімнаті 111 потребує перегляду всієї таблиці R2 і зміни поля Телефон у записах, що відносяться до Петрова, Сідорова й Єгорова.

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

Наприклад у таблиці R2 вилучення запису про Іванова приводить до зникнення інформації про номер телефону в 109-й кімнаті.

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

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