Етап 4.3. Реалізація обмежень предметної області

Ціль Розробка обмежень предметної області для цільової СКБД.

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

Етап 5. Проектування фізичного представлення бази даних

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

- Продуктивність виконання транзакцій. Цей показник являє собою кількість транзакцій, які можуть бути оброблені за заданий інтервал часу. У деяких системах, наприклад у службах резервування авіаквитків, забезпечення високої продуктивності виконання транзакцій є вирішальним чинником успішної експлуатації всієї системи.

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

- Дискова пам'ять. Цей показник являє собою обсяг дискового простору, необхідного для розміщення файлів бази даних. Розроблювач повинен прагнути мінімізувати обсяг використовуваної дискової пам'яті.

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

Взявши до уваги все вищесказане, приступимо до обговорення тих дій, які повинні бути виконані на п'ятому етапі розробки бази даних.

1.Аналіз транзакцій.

2.Вибір файлової структури.

3.Визначення індексів.

4.Визначення вимог до дискової пам'яті.

Етап 5.1. Аналіз транзакцій

Ціль Визначення функціональних характеристик транзакцій, які будуть виконуватися в проектованій базі даних, і виділення найбільш важливих

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

- транзакції, виконувані найбільше часто і які найістотніше впливають на продуктивність;

- транзакції, найбільш важливі для роботи організації;

- періоди часу протягом доби/тижнів, у які навантаження бази даних зростає до максимуму (називані періодами пікового навантаження).

Етап 5.2 Вибір файлової структури

Ціль Визначення найбільш ефективного файлового подання для кожного з основних відношень.

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

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

Послідовні файли.

- Хешовані файли.

- Індексно-послідовні файли (ISAM - Indexed Sequential Access Method).

- Удосконалені збалансовані дерева (В+-Tree).

- Кластери.

Якщо цільова СКБД не дозволяє вибрати певну файлову організацію, цей етап може бути пропущений.

Етап 5.3. Визначення індексів

Ціль Визначення того, чи буде додавання індексів сприяти підвищенню продуктивності системи.

Один з варіантів вибору підходящої файлової структури для відношення полягає в тому, що рядки залишаються неупорядкованими й створюється будь-яка необхідна кількість додаткових індексів. Для вибору атрибута, по якому виконується впорядкування або рядків, застосовуються наступні критерії:

- вибирається атрибут, найбільше часто застосовуваний в операціях з'єднання, оскільки саме він дозволяє підвищити ефективність таких операцій;

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

Якщо обраний атрибут, по якому відбувається впорядкування, є ключем відношення, то створюваний індекс служить як первинний індекс, а якщо атрибут, по якому відбувається впорядкування, не є ключем, те створюваний індекс служить кластеризуючим індексом. Варто враховувати, що в кожнім відношенні повинен застосовуватися або первинний, або кластеризуючий індекс.

Вибір додаткових індексів

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

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

- Ввід індексного запису в кожен додатковий індекс при вставці рядка у відношення.

- Оновлення додаткового індексу при оновленні відповідного рядка у відношенні.

- Збільшення потреби в дисковому просторі у зв'язку з необхідністю зберігання додаткового індексу.

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

Етап 5.4. Оцінка потреби в дисковому просторі

Ціль. Визначити обсяг дискового простору, що потрібно для бази даних.

Етап 6. Проектування представлень користувача (переглядів, поданнів).

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

В автономної СКБД на персональному комп'ютері представлення звичайно застосовуються тільки для зручності, оскільки вони часто дозволяють спростити запити до бази даних. Але в багатокористувацьких СКБД такі представлення відіграють головну роль при визначенні структури бази даних і дотриманні правил захисту.

Етап 7. Проектування засобів захисту

Ціль Проектування засобів захисту для бази даних у відповідності до вимог користувачів.

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

- захист системи;

- захист даних.

Засоби захисту системи регламентують доступ й експлуатацію бази даних на рівні системи; до них, зокрема, належить аутентифікація користувача за іменем та паролем. Засоби захисту даних регламентують доступ і використання об'єктів бази даних (таких як відношення й представлення), а також дії, які можуть бути виконані користувачами з конкретними об'єктами. І в цьому випадку проект реалізації правил доступу залежить від цільової СКБД, оскільки можливості реалізації правил доступу залежать від системи.