6.2.1. Аномалії вставки

Існує два основних типи аномалій вставки, що ілюструються за допомогою відносини Staff_Branch, показаного в табл. 6.3.

• При вставці зведень про нових співробітників у відношення Staff_Branch необхідно вказати і зведення про відділення компанії, у якому ці співробітники працюють. Наприклад, при вставці зведень про нового співробітника відділення 'У7' буде потрібно ввести зведення про саме відділення 'У7', що повинні відповідати зведенням про це ж відділення в інших рядках відносини Staff_Branch. Відносини, показані в табл. 6.1 і 6.2, не можуть постраждати від такої потенційної невідповідності даних, оскільки для кожного співробітника у відношення Staff буде потрібно ввести тільки відповідний номер відділення компанії. Крім того, зведення про відділення компанії з номером 'У7' Заносяться в базу даних однократно, у виді єдиного рядка відносини Branch.

• Для вставки зведень про нове відділення компанії, що ще не має власних співробітників, буде потрібно привласнити значення NULL всім атрибутам опису персоналу відносини Staff_Branch, включаючи й особистий номер співробітника Staff_No. Однак, оскільки атрибут Staff_No є первинним ключем відносини Staff_Branch, те спроба ввести значення NULL в атрибут Stuff_No викликає порушення цілісності сутностей (див. роздягнув 3.3) і тому буде відхилена. Отже, у відношення Staff_Branch неможливо ввести рядок про нове відділення компанії, що містить визначник NULL в атрибуті Staff_No. Структура відносин, представлених у табл. 6.1 і 6.2, дозволяє уникнути виникнення цієї проблеми, оскільки зведення про відділення компанії вводяться у відношення Branch незалежно від уведення зведень про співробітників. Зведення про співробітників, що будуть працювати в новому відділенні компанії, можуть бути введені у відношення Staff пізніше.

6.2.2. Аномалій видалення

При видаленні з відношення Staff_Branch рядка з інформацією про останнього співробітника деякого відділення компанії, зведення про це відділення будуть цілком вилучені з бази даних. Наприклад, після видалення з відношення Staff_Branch рядка для співробітника 'Mary Howe' з особистим номером 'SA9' з бази даних неявно будуть вилучені всі зведення про відділення з номером 'У7'. Однак структура відносин, показаних у табл. 6.1 і 6.2, дозволяє уникнути виникнення цієї проблеми, оскільки рядка зі зведеннями про відділення компанії зберігаються окремо від рядків зі зведеннями про співробітників. Зв'язує цих двоє відносин тільки загальний атрибут Branch_No. При видаленні з відношення Staff рядка з номером співробітника 'SA9' зведення про відділення 'У7' у відношенні Branch залишаться недоторканими.

6.2.3. Аномалії відновлення

При спробі зміни значення одного з атрибутів для деякого відділення компанії у відношенні Staff_Branch (наприклад, номера телефону відділення 'ВЗ') необхідно обновити відповідні значення в рядках для всіх співробітників цього відділення. Якщо такої модифікації будуть піддані не всі необхідні рядки відносини Staff_Branch, то в цьому випадку база даних буде містити суперечливі зведення. Зокрема, у нашому прикладі для відділення компанії з номером 'ВЗ' у рядках, що відносяться до різних співробітників, помилково можуть бути зазначені різні значення номера телефону цього відділення.

Усі приведені вище приклади ілюструють те, що представлені в табл. 6.1 і 6.2 відносини Staff і Branch мають більш прийнятні властивості, чим відношення Staff_Branch, представлене в табл. 6.3. Нижче в цій главі розглядаються способи застосування процесу нормалізації для одержання правильно спроектованих відносин. Однак спочатку варто познайомитися з концепцією функціональної залежності, що покладена в основу всього процесу нормалізації.