Короткі теоретичні відомості

⇐ ПредыдущаяСтр 15 из 19Следующая ⇒

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

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

- Перенесення глобальної логічної моделі даних в середовище цільової СУБД.

- Проектування основних таблиць.

- Розробка способів одержання похідних даних.

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

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

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

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

- Розробка механізмів захисту

Обговорювана нами методологія фізичного проектування баз даних включає шість основних етапів. Концептуальне і логічне проектування охоплює три перші етапи розробки баз даних, а фізичне проектування — етапи 4-9.

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

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

6-й етап включає прийняття рішення про те, як має бути реалізоване кожне призначене для користувача представлення.

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

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

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

2 Перенесення глобальної логічної моделі даних в середовище цільової СУД (4-й етап).Головним завданням на етапі фізичного проектування баз даних є перетворення відношень, створених на основі логічної моделі даних, в форму, яка може бути реалізована в середовищі СУБД. Перша частина цього процесу передбачає перевірку інформації, зібраної на етапі логічного проектування бази даних і поміщеної в словник даних. Друга частина процесу полягає у використанні цієї інформації для розробки структури основних таблиць.

На етапі 4 розробки баз даних виконуються наступні дії.

- Проектування основних таблиць.

- Розробка способів одержання похідних даних.

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

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

- ім'я таблиці;

- список простих полів

- визначення первинного ключа і (якщо такі існують) альтернативних (АК) і зовнішніх (FK) ключів;

- список обчислювальних полів і опис способів їх обчислення;

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

Для кожного поля має бути присутня наступна інформація:

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

- значення атрибуту, що набуває за замовчуванням (необов'язково);

- допустимість значення NULL для даного атрибуту.

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

4 Розробка способів одержання похідних даних. Похідними, або розрахунковими називаються атрибути, значення яких можна визначити з використанням значень інших атрибутів. Наприклад, похідними є всі перераховані нижче атрибути:

- кількість співробітників, що працюють в конкретному відділенні;

- загальна сума щомісячної зарплати всіх співробітників;

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

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

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

- витрати на обчислення похідних даних, якщо їх обчислення виконується в міру необхідності.

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

Спосіб здобуття похідних даних має бути повністю описаний в документації з вказівкою причин вибору запропонованого проекту.

5 Проектування фізичного представлення бази даних (5 етап).Важливим завданням фізичного проектування бази даних є організація ефективного зберігання даних. Вона включає:

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

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

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

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

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

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

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

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

- Файли операційної системи мають бути відокремлені від файлів бази даних.

- Основні файли бази даних мають бути відокремлені від індексних файлів.

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

⇐ Предыдущая 10 11 12 13 141516 17 18 19 Следующая ⇒

Последнее изменение этой страницы: 2018-05-29; просмотров: 163.

stydopedya.ru не претендует на авторское право материалов, которые вылажены, но предоставляет бесплатный доступ к ним. В случае нарушения авторского права или персональных данных напишите сюда...