24. Аномалії додавання, вилучення і обновлення баз даних.
Основна мета проектування реляційної бази даних полягає в групуванні атрибутів у відношень таким чином, щоб мінімізувати надлишковість даних і тим самим скоротити обсяг пам'яті, необхідний для фізичного зберігання відношень, представлених у вигляді таблиць.
Аномалії вставки
Існують два основних типи аномалій вставки, які ілюструються за допомогою відношення Staff Branch.
• При вставці відомостей про нових співробітників у відношення Staff Branch, необхідно вказати і відомості про відділення компанії, в якому ці співробітники працюють. Наприклад, при вставці відомостей про новою співробітника відділення 'В007' потрібно ввести відомості про сам відділенні 'В007', які повинні відповідати відомостям про це ж відділенні в інших рядках відношення Staf fBranch. Відношення, показані в табл. 1 і 2, не схильні до впливу цієї потенційної несумісності даних, оскільки для кожного співробітника в відношенні Staff потрібно ввести тільки відповідний номер відділення компанії. Крім того, відомості про відділення компанії з номером 'В007' заносяться в базу даних одноразово, у вигляді єдиного рядка відношення Branch.
• Дія вставки відомостей про нове відділення компанії, яке ще не має власних співробітників, потрібно присвоїти значення NULL всім атрибутам опису персоналу відношення StaffBranch. включаючи і табельний номер співробітника staffNo. Але оскільки атрибут staffNo є первинним ключем відношення StaffBranch, то спроба ввести значення NULL в атрибут staffNo викличе порушення цілісності сутностей і гаму буде відхилена. Отже, у відношення SiaffBranch неможливо ввести рядок про нове відділення компанії, який містить значення NULL в атрибуті staffNo. Структура відношення, представлених в табл. 1 і 2, дозволяє уникнути виникнення цієї проблеми, оскільки відомості про відділення компанії вводяться в відношенні Branch незалежності введення відомостей про співробітників. Відомості про співробітників, які працюватимуть у новому відділенні компанії, можуть бути введені в ставлення Staff пізніше.
Аномалії вилучення
При видаленні з відношення SialT Branch рядка з інформацією про останнього співробітника деякого відділення компанії відомості про це відділенні будуть повністю видалені з бази даних. Наприклад, після видалення з відношення Staff Branch рядка для співробітника Mary Howe з табельним номером SA9 з бази даних неявно будуть видалені всі відомості про відділення з номером В007. Проте структура відношення, показаних в табл. 1 і 2, дозволяє уникнути виникнення цієї проблеми, оскільки рядки з відомостями про відділення компанії зберігаються окремо від рядків з відомостями про співробітників. Пов'язує ці два відношення тільки загальний атрибут branchNo. При видаленні з відношення Staff рядки з номером співробітника SA9 відомості про відділення ВО07 щодо Branch залишаться недоторканими.
Аномалії поновлення
При спробі зміни значення одного з атрибутів для деякого відділення компанії відношення Staff Branch (наприклад, адреси відділення ВООЗ) необхідно оновити відповідні значення в рядках для всіх співробітників цього відділення. Якщо такій модифікації будуть піддані не всі необхідні рядки відношення Staff Branch., база даних буде містити суперечливі відомості. Зокрема, в нашому прикладі для відділення компанії з номером ВООЗ в рядках, що відносяться до різних співробітникам, помилково можуть бути вказані різні значення адреси цього відділення.
Всі наведені вище приклади ілюструють те, що представлені в табл. 1 і 2 відношення Staff і Branch мають більш прийнятні властивості, ніж відношення Staff Branch, представлене в табл. 3. Це доводить, що відношення Staff Branch схильне аномалії оновлення, але цих аномалій можна уникнути шляхом декомиозиції початковою відношення на відношення Staff і Branch. З декомпозицією великих відношень на більш дрібні пов'язані два важливих властивості. По-перше, властивість з'єднання без втрат гарантує, що будь-який екземпляр первісною відношення може бути визначений за допомогою відповідних примірників дрібніших відносин. По-друге, властивість збереження залежностей гарантує, що обмеження на початкове відношення можна підтримувати, просто застосовуючи такі ж обмеження до кожного з більш дрібних відношень. Іншими словами, для перевірки того, чи не порушується обмеження, яке поширювалося на початкове відношення, немає необхідності виконувати операції з'єднання на більш дрібних відносинах.
- Передумови виникнення програмної інженерії.
- Основні принципи програмної інженерії.
- Життєвий цикл програмного забезпечення.
- Роль і місце інформаційної інженерії у програмній.
- Призначення і основні компоненти середовища бази даних.
- 7. Системи управління базами даних (субд).
- 8. Реляційна модель даних
- 9. Мова маніпулювання даними для реляційної моделі.
- 10.Умови і обмеження, які накладаються на відношення реляційною
- 11. Переваги реляційної бази даних
- 12. Життєвий цикл інформаційної системи
- Життєвий цикл програмного забезпечення баз даних
- 13. Мета і задачі проектування
- 14. Проектування реляційної бази даних
- Етапи проектування бази даних
- 15. Формулювання та аналіз вимог
- 16.Концептуальне проектування.
- 17.Модель "сутність-зв'язок".
- 18.Критерії вибору первинного ключа.
- 19.Логічне проектування.
- 20.Індексація в базах даних.
- 21.Методи доступу до файлів і хешування.
- 22.Цілісність і схоронність баз даних.
- 23.Нормалізація відношень. Необхідність нормалізації.
- 24. Аномалії додавання, вилучення і обновлення баз даних.
- 25.Явна і неявна надлишковість даних. Декомпозиція відношень.
- 26.Поняття нормальної форми. 1-а, 2-а, 3-я, 4-а нормальні форми. Нормальна форма Бойса-Кодда.
- 27.Реляційна алгебра. Основні і додаткові операції реляційної алгебри.
- 28.Представлення в базах даних.
- 29.Привілеї в базах даних.
- 30.Ієрархічна модель даних.
- 31.Мережева модель даних.
- 32. Багатовимірна модель даних. Olap.
- 33.Case-засоби проектування баз даних. Можливості проектування баз