Критерії якості логічних моделей БД
Проектування реляційних БД. Основи нормалізації БД
Коли ми говоримо про проектування реляційних БД, мова йде у першу чергу про логічне проектування, оскільки саме при переході до етапу логічного проектування фіксується базова модель даних, у даному випадку – реляційна. Проблема логічного проектування реляційної бази даних полягає в обґрунтованому прийнятті рішень про те, з яких відношень повинна складатися база даних і які атрибути повинні бути в цих відношень, щоб відбиття об'єктів не суперечило предметній галузі, відповідало всім вимогам реляційної моделі і критеріям якості БД та забезпечувало можливості ефективної реалізації запитів для БД певного типу при дотриманні обмежень цілісності. Ефективна логічна модель повинна забезпечувати формування такої фізичної моделі БД, яка б відповідала основним критеріям якості БД: адекватність БД предметній області; легкість розробки і супроводження БД; швидкість виконання операцій оновлення (вставка, модифікація, видалення кортежів) та вибірки даних.
Адекватність бази даних предметній області. База даних повинна адекватно відбивати предметну область. Це означає, що повинні виконуватися наступні умови:
1. Стан бази даних у кожен момент часу повинне відповідати стану предметної області.
2. Зміна стану предметної області повинно приводити до відповідного зміні стану бази даних
3. Обмеження предметної області, відбиті в моделі предметної області, повинні певним чином відбиватися і враховуватися у базі даних.
|
|
|
Легкість розробки і супроводження бази даних. Практично будь-яка база даних, за винятком зовсім елементарних, містить деяку кількість програмного коду у вигляді тригерів і збережених процедур.
Збережені процедури - це процедури і функції, що зберігаються безпосередньо в базі даних у відкомпільованому виді і які можуть запускатися користувачами чи додатками, що працюють з базою даних. Збережені процедури звичайно пишуться або на спеціальному процедурному розширенні мови SQL (наприклад, PL/SQL для ORACLE чи Transact-SQL для MS SQL Server), чи на деякій універсальній мові програмування, наприклад, C++, із включенням у код операторів SQL у відповідності зі спеціальними правилами такого включення. Основне призначення збережених процедур - реалізація бізнесів-процесів предметної області.
Тригери - це збережені процедури, пов'язані з деякими подіями, що відбуваються під час роботи бази даних. Як такі події, виступають операції вставки, відновлення і видалення рядків таблиць. Якщо в базі даних визначений деякий тригер, то він запускається автоматично завжди при виникненні події, з яким цей тригер зв'язаний. Дуже важливим є те, що користувач не може обійти тригер. Тригер спрацьовує незалежно від того, хто з користувачів і яким способом ініціював подію, що викликала запуск тригера. Таким чином, основне призначення тригерів - автоматична підтримка цілісності бази даних. Тригери можуть бути як досить простими, наприклад, такі, що підтримують посилальну цілісність, так і досить складними, реалізуючі які-небудь складні обмеження предметної області чи складні дії, що повинні відбутися при настанні деяких подій. Наприклад, з операцією вставки нового товару в накладну може бути зв'язаний тригер, що виконує наступні дії - перевіряє, чи є необхідна кількість товару, при наявності товару додає його в накладну і зменшує дані про наявність товару на складі, при відсутності товару формує замовлення на постачання відсутнього товару і відразу посилає замовлення по електронній пошті постачальнику.
|
|
|
Очевидно, що чим більше програмного коду у вигляді тригерів і збережених процедур містить база даних, тим складніше її розробка і подальше супроводження.
Швидкість операцій оновлення даних (вставка, відновлення, видалення). На рівні логічного моделювання ми визначаємо реляційні відношення й атрибути цих відношень. На цьому рівні ми не можемо визначати будь-які фізичні структури збереження (індекси, хешування і т.п.). Єдине, чим ми можемо керувати - це розподілом атрибутів по різним відношенням. Можна описати мало відношень з великою кількістю атрибутів, чи багато відношень, кожне з який містить мало атрибутів. Таким чином, необхідно спробувати відповісти на питання - чи впливає кількість відношень і кількість атрибутів у відношеннях на швидкість виконання операцій оновлення даних. Таке питання, звичайно, не є досить коректним, тому що швидкість виконання операцій з базою даних сильно залежить від фізичної реалізації бази даних. Проте, спробуємо якісно оцінити цей вплив при однакових підходах до фізичного моделювання.
|
|
|
Основними операціями, що змінюють стан бази даних, є операції вставки, оновлення і видалення записів. У базах даних, що вимагають постійних змін (складський облік, системи продажів квитків і т.п.) продуктивність визначається швидкістю виконання великої кількості невеликих операцій вставки, оновлення і видалення.
Розглянемо операцію вставки запису в таблицю. Вставка запису здійснюється в одну з вільних сторінок пам'яті, виділеної для даної таблиці. СУБД постійно зберігає інформацію про наявність і розташування вільних сторінок. Якщо для таблиці не створені індекси, то операція вставки виконується фактично з однаковою швидкістю незалежно від розміру таблиці і від кількості атрибутів у таблиці. Якщо в таблиці є індекси, то при виконанні операції вставки запису індекси повинні бути перебудовані. Таким чином, швидкість виконання операції вставки зменшується при збільшенні кількості індексів у таблиці і мало залежить від числа рядків у таблиці.
|
|
|
Розглянемо операції відновлення і видалення записів з таблиці. Перш, ніж обновити чи видалити запис, його необхідно знайти. Якщо таблиця не індексована, то єдиним способом пошуку є послідовне сканування таблиці в пошуку потрібного запису. У цьому випадку, швидкість операцій оновлення і видалення істотно збільшується зі збільшенням кількостізаписів у таблиці і не залежить від кількості атрибутів. Але насправді неіндексовані таблиці практично ніколи не використовуються. Для кожної таблиці звичайно оголошується один чи кілька індексів, що відповідає потенційним ключам. За допомогою цих індексів пошук запису провадиться дуже швидко і практично не залежить від кількості рядків і атрибутів у таблиці (хоча, звичайно, деяка залежність є). Якщо для таблиці оголошено кілька індексів, то при виконанні операцій відновлення і видалення ці індекси повинні бути перебудовані, на що витрачається додатковий час. Таким чином, швидкість виконання операцій відновлення і видалення також зменшується при збільшенні кількості індексів у таблиці і мало залежить від кількості рядків у таблиці.
Можна припустити, що чим більше атрибутів має таблиця, тим більше для неї буде оголошено індексів. Ця залежність, звичайно, не пряма, але при однакових підходах до фізичного моделювання звичайно так і відбувається. Таким чином, можна прийняти допущення, що чим більше атрибутів мають відношення, розроблені в ході логічного моделювання, тим повільніше будуть виконуватися операції оновлення даних, за рахунок витрати часу на перебудову більшої кількості індексів.
Додаткові міркування на користь приведеної тези про уповільнення виконання операцій відновлення даних (вплив журналізації, довжини рядків таблиць) приведені в роботі А.Прохорова [27].
Швидкість операцій вибірки даних. Одне з призначень бази даних - надання інформації користувачам. Інформація витягається з реляційної бази даних за допомогою оператора SQL - SELECT. Однією з найбільш дорогих операцій при виконанні оператора SELECT є операція з'єднання таблиць. Таким чином, чим більше взаємозалежних відношень було створено в ході логічного моделювання, тим більше імовірність того, що при виконанні запитів ці відношення будуть з'єднуватися, і, отже, тим повільніше будуть виконуватися запити. Таким чином, збільшення кількості відношень приводить до уповільнення виконання операцій вибірки даних, особливо, якщо запити заздалегідь невідомі.
Таким чином, здатність БД задовольняти цим критеріям якості залежить від ступеня надмірності інформації у ній, яка проявляється у збереженні тої самої інформації (даних про ті самі властивості тих самих об’єктів) у кількох різних таблицях, що може породжувати аномалії і суперечливості даних. Ймовірність таких аномалій, тобто ймовірність неадекватності предметної галузі, без розробки спеціальних програмних кодів зростає зі збільшенням ступеня надмірності. Для його зменшення у проектуванні реляційних БД застосовують апарат нормалізації відношень.
Дата добавления: 2016-01-05; просмотров: 20; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!