ФІЗИЧНЕ МОДЕЛЮВАННЯ

За підсумками вивчення матеріалу даного розділу студент повинен:

знати

• • підходи при моделюванні фізичної бази даних;
• • технології моделювання фізичної бази даних;
• • інструментальні засоби, що застосовуються при розробці моделей бази даних;

вміти

• • ідентифікувати об'єкти даних і структурні елементи;
• • будувати фізичну модель бази даних, грунтуючись на логічної моделі бази даних;
• • визначати потреби користувача і моделювати їх реалізацію;

володіти

• • способами застосування інструментальних засобів для побудови фізичної моделі бази даних;
• • навичками застосування інструментальних засобів для побудови моделей реалізації інформаційних потреб користувачів в поданні та обробці даних.

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

Особливості побудови фізичної моделі бази даних

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

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

Побудова фізичної моделі бази даних грунтується на раніше сформованої логічної моделі. Але якщо в логічної моделі розробник, як правило, застосовує найменування об'єктів на національній мові, то для фізичної моделі доцільно застосування латинського алфавіту. Пояснюється це тим, що СУБД орієнтовані на застосування мов програмування, включаючи мову 5 () Ц подаються латиницею. Складнощі в написанні і супроводі програмних кодів, які використовують кілька алфавітів, не дозволяють ефективно управляти базою даних. Тому для фізичної моделі бази даних, як і для її фізичної реалізації в СУБД, розробниками вибирається латинський алфавіт іменування об'єктів бази даних. Проте, потрібно пам'ятати, що сучасні СУБД в іменах об'єктів дозволяють застосовувати будь-які національні алфавіти спільно з латинським, а також спеціальні символи, включаючи пробіли, не перешкоджаючи функціональності телевізора програмного коду, але такі імена зазвичай обрамляются символами, відповідно до вимог СУБД. Наприклад, в рамках СУБД М5 5ЦБ-5егуег такими символами є квадратні дужки. В інших СУБД можуть використовуватися інші символи.

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

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

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

Таблиця 5.1

Угода імен бази даних

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

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

• • таблиця - table - об'єкт, асоційований з сутністю логічної моделі, де зберігаються дані, сформовані і використовуються користувачем;
• • поле (колонка) - field (column) - об'єкт, асоційований з атрибутом логічної моделі бази даних, що описує окреме властивість збережених примірників даних;
• • тип даних (домен) - datatype (domain) - об'єкт бази даних, який надається похідним типом даних, що визначаються на підставі типів, наявних в базі даних;

• • замовчування - default - об'єкт, ідентичний аналогічному об'єкту логічної моделі, що визначає значення, яке має бути збережено в поле (колонці), якщо інше не було визначено користувачем або командою внесення даних (insert, update);
• • обмеження - check - об'єкт, що описує логічне правило перевірки значення для поля (колонки) таблиці, що представляється зазвичай властивістю поля (колонки), а не самостійним об'єктом;
• • первинний ключ - primary key - об'єкт, що представляється властивістю таблиці, де міститься перелік полів (колонок), які використовуються для однозначної ідентифікації примірника даних;
• • зовнішній ключ - foreign key - об'єкт, що представляється властивістю таблиці, де міститься умова зв'язку між батьківської та дочірньої таблицями із зазначенням полів зв'язків;
• • уявлення (похідні таблиці) - view - об'єкт бази даних, який використовується для визначення правила статичної вибірки даних з таблиць, застосовуваний з метою обмежень доступу до екземплярів даних і реалізації стандартних інформаційних потреб;
• • збережена процедура - stored procedure - об'єкт бази даних, що представляється логічно закінченим програмним модулем на мові програмування СУБД, який виконується за викликом користувача або іншої процедури;
• • тригер - trigger - об'єкт бази даних, що представляється логічно закінченим програмним модулем на мові програмування СУБД, який виконується при настанні певних умов в результаті реалізації команд поновлення даних (insert, update, delete);
• • табличний простір - tablespace - об'єкт бази даних, де розміщуються таблиці з метою їх поділу факторингу ознаками і забезпечення високої швидкості обробки даних.

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

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

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

Розмірність = тах (РК) + / Кі (РК) / • КПІ, (5.1)

де та х (РК) - максимальне значення первинного ключа на момент формування бази даних; Кі (РК) - кількісна мінливість первинного ключа по модулю; КПІ - кількість елементів періодичності змін на термін життя інформаційної системи.

У підсумку виходить, що через п'ять років максимальне значення для первинного ключа "id 1" стане рівним 500 + 10 • (365 * 5) = 18 750, а для первинного ключа "id2" - 100 + 50 • (12 • 5) = 3100. Отримані значення дозволяють говорити про необхідність використання типу даних "integer", діапазон значень якого від 0 до 65 536 або, при використанні негативних значень, від -32 767 до 32 768.

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

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

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

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

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

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

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

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

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

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

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

Довгий час цей інструмент роботи з базою даних практично не застосовувався. Пояснювалося це тим, що технічні засоби, що працюють з базами даних, були сильно обмежені в ресурсах, і додаткове навантаження на виконання різних дій, не пов'язаних безпосередньо зі збереженням, видаленням або вибіркою даних, була недоцільною, що обмежує швидкісні характеристики бази даних. В цьому випадку процедури обробки даних переносилися на рівень програми (серверне або клієнтське) з реалізацією виконання тільки ви додали (insert), зміни (update), видалення (delete) і вибірки (select).

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

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

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

Виконання цього програмного коду реалізується в автоматичному режимі, коли користувачем або процедурою СУБД виконується яка-небудь операція по модифікації даних (insert, update, delete). При цьому виконання може бути обмежена додатковими умовами і реалізовано в різних режимах: до виконання команди, після виконання команди або замість ініціює команди.

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