Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

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

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

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

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

Інструментальне засіб СА ERWin Data Modeler

Виконання фізичного моделювання, засноване на раніше сформованої логічної моделі бази даних, проводиться на моделі, що отримується після відповідної трансформації. Як і в будь-якому іншому засобі моделювання, ERWin Data Modeler зберігає всі найменування у вихідному варіанті, як це представлено в логічної моделі бази даних, але замінює прогалини і спеціальні символи на певний в правилах трансформації символ. Зазвичай таким символом є "_" (знак підкреслення).

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

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

image317

Мал. 5.4. Результуюча модель після трансформації в фізичну модель


Припустимо, що розробником визначено угоду імен, як в попередньому розділі. При виконанні процедури перейменування у розробника в розглянутому прикладі моделі виникає протиріччя, яке полягає в тому, що в таблиці "епМу2" буде утворено два поля з однаковим найменуванням "16", що неприпустимо за правилами іменування об'єктів бази даних (рис. 5.5).

image318

Мал. 5.5. Модель бази даних відповідно до угоди імен


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

Таблиця 53

Коригування таблиці угоди імен

п / п

об'єкт

пре

фікс

ім'я

пост

фікс

опис

1

Таблиця

functional

name>

<#>

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

2

поле

(Колонка)

id

<#>

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



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

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

Визначаючи розмірності первинних ключів, раніше було виявлено, що поле "id 1" буде через п'ять років утримувати максимальне значення 18 750, а нулі "id2" - 3100. Оскільки для цих полів було визначено тип "Integer", який в якості максимального значення діапазону має число 32 767, що значно більше розрахованого значення для обох первинних ключів, а типу даних меншої розмірності, який дозволив би зберігати розраховані значення, не існує, то цей тип даних можна зберегти для фізичної моделі і її реалізації у фізичній базі даних.

image319

Мал. 5.6. Налаштування базових властивостей поля таблиці


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

Виконуючи налаштування полів відповідно до обраної базою даних (рис. 5.7), розробник може вказати не тільки тип даних поля, але і ряд додаткових характеристик, які застосовуються в базі даних:

  • • Generated (Генерований) - властивість визначає можливість заповнення поля згенерував значення відповідно до математичними або лінгвістичними правилами;
  • • Generation Expression (Обчислюване вираз) - властивість представляє математичне або лінгвістичне вираження, виконання якого повинно привести до формування деякого значення, причому значення полів для вираження повинні використовуватися тільки з того самого екземпляра тієї ж таблиці;
  • • Generated Identity (ідентифікує обчислення) - властивість визначає ознака необхідності формувати значення унікального характеру, що зазвичай забезпечується обчисленнями за правилом арифметичної прогресії і, як правило, застосовується для сурогатних ключів;
  • • Starting Value (Початкове значення) - властивість визначає значення, від якого буде відштовхуватися СУБД при обчисленні значення за правилами арифметичної прогресії;
  • • Increment By (Крок) - властивість визначає значення, яке має використовуватися при черговому обчисленні за правилами арифметичної прогресії.

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

image320

Мал. 5.7. Налаштування властивостей поля по обраної СУБД


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

Об'єкт "Табличний простір" (рис. 5.8), будучи виключно об'єктом бази даних, може бути відсутнім в описах фізичної моделі, якщо в якості СУБД обрана така, де цей об'єкт не присутній. Проте, якщо розподіл таблиць з табличних просторів можливий, то це бажано зробити, особливо якщо розробляється складна інформаційна система. Створення табличного простору виконується через пункт меню "Model / Target ... / Tablespeces ..." (Модель / Призначення ... / Табличні простору). Залежно від обраної СУБД пункт меню "Target ..." буде змінюватися назвою цієї СУБД. Також створити табличний простір можна через контекстного меню дерева моделі в лівій області робочого простору.

image321

Мал. 5.8. Область опису основних властивостей табличного простору



Створивши нове табличний простір, необхідно визначити основні його характеристики:

  • • Туре (Тип) - характеристика визначає правила роботи СУБД з табличним простором і виділяє п'ять основних типів:
    • - Regular (Базове) - в цьому табличному просторі визначаються всі таблиці бази даних, виключаючи дані великих розмірів, які описуються типами Text, CLOB, BLOB, Binary і т.д .;
    • - Large (Велике) - табличний простір орієнтоване на розміщення великих даних з відповідних атрибутів;
    • - System Temporary (Системне тимчасове) - використовується для зберігання тимчасових відомостей про базу даних та її об'єктах, що визначає його як недоступне для користувача;
    • - User Temporary (користувача тимчасове) - використовується для зберігання тимчасових таблиць, які формуються в результаті роботи користувача з уявленнями, збереженими процедурами і т.д .;
    • - Index (Індексне) - табличний простір орієнтоване на зберігання індексних таблиць, використовуваних при контролі унікальності значень, пошуку даних і сортування;
  • • Managed By Туре (Тип управління) - властивість визначає правила, за якими в СУБД буде контролюватися витрачання ресурсів комп'ютера і операційної системи, припускаючи наступні варіанти:
  • - System (Система) - управління ресурсами передається на рівень операційної системи;
  • - Database (База даних) - управлінням керуватиме СУБД;
  • - Automatic Storage (Автоматичне сховище) - управління ресурсами буде забезпечуватися тим методом, який, на думку СУБД, буде найкращим.

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

Реалізація процесів управління табличним простором грунтується на розподілі таблиць по екстенти і сторінок, що має бути визначено у додатку до основних налаштувань (рис. 5.9). Таким чином, в основній закладці "General" додаткових налаштувань табличного простору розробнику пропонується вказати розмір сторінки (Page Size), вибравши в списку один з чотирьох варіантів розмірності, величину екстента (Extent Size), вимірюваного в кількості сторінок, і інші характеристики, що визначають особливості фізичного розміщення таблиць і даних в табличному просторі.

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

• Use Auto Resize (Використовувати автоматичну зміну розміру) - визначається необхідність збільшення розміру табличного простору і файлу бази даних;


  • • Initial Size (Початковий розмір) зазначення розміру табличного простору, яке повинно бути позначено в момент створення бази даних;
  • • Increase Size By (Тип зміни розміру) - вказують варіант розрахунку для зміни розміру табличного простору, припускаючи точне кількісне вираження і процентне обчислення;
  • • Increase Size (Крок зміни розміру) - вказується кількісна величина, на яку змінюється розмір табличного простору при його збільшенні;
  • • Max Size (Максимальний розмір) - визначається величина максимального розміру табличного простору, більше якого воно не повинно збільшуватися.

image322


Puc. 5.9. Визначення правил управління табличним простором

В результаті вказівки даних параметрів і на підставі певного принципу управління табличним простором воно буде розміщувати закріплені в ньому таблиці і їх дані (рис. 5.10).

Вибираючи властивості таблиці в окремій закладці "Tablespace" (Табличний простір), можна вибрати табличні простору, де повинні бути розміщені дані з розглянутої таблиці, а також вказати у властивості "Index In Tablespace" (Індекси в табличному просторі) то табличний простір, як правило , це окреме табличний простір звичайного типу (Regular), де повинні зберігатися і розподілятися відомості про індексацію ключів і окремих сукупностей атрибутів, формуючи відповідні індексні таблиці. Вказавши це розміщення, у фізичній моделі бази даних визначають правила фізичного розподілу таблиць, індексів і великих даних, організовуючи ефективне управління даними на фізичному (технічному) рівні, оскільки ці настройки використовуються саме для організації роботи з файлом (ами) бази даних на магнітному носії .

image323

Мал. 5.10. Закріплення таблиці в табличний простір


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

image324

Мал. 5.11. Список встановлених замовчувань


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

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

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

Наступним елементом фізичної моделі бази даних, який необхідно уточнити і точно визначити, є обмеження посилальної цілісності, яке визначається через вказівку дій, які необхідно виконувати при настанні дії обробки (додавання, зміна, видалення) даних в батьківській або дочірньої таблиці. Налаштування обмежень посилальної цілісності виконують в настройках зв'язку між таблицями (рис. 5.12), використовуючи закладку "RI Actions".

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

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

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

image325

Мал. 5.12. Налаштування обмежень посилальної цілісності


Всі інші дії, як правило, розглядаються в СУБД на рівні програмно реалізованого триггерного дії, код якого інструментальним засобом, як правило, визначається автоматично, але може бути представлений і програмним кодом, визначеним розробником (рис. 5.13). Для створення власного критичного дії досить через контекстне меню папки "Triggers" (Тригери) дерева проекту створити його і перейти до його редагування.

image326


Puc. 5.13. Вибір для редагування триггерного дії

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

image327

Мал. 5.14. Визначення основних параметрів тригера


Оскільки тригерні дію виконується при настанні події по модифікації даних, то серед основних характеристик, які для нього потрібно визначити, є вказівка ​​дії над даними, які повинні цей тригер викликати, що в області основних параметрів відображено прапорцями по колонках "Insert", "Update" , "Delete". При цьому необхідно вказати час виконання триггерного дії: "After" (після виконання дії над даними) або "Before" (до виконання дії над даними). На додаток до основних характеристик розробниками вказуються правила доступу до даних, дії над якими привели до виконання цього тригера.

Налаштування базових параметрів виконується в закладці "General", де можна визначити доступність до модифікується даними (рис. 5.15):

  • • Scope (регіон) - правило доступності до модифікується даними, де вказується рівень рядки даних (Row) або таблиці з безліччю рядків (Table);
  • • New (Новий) - найменування тимчасової області даних, які подаються єдиною рядком даних, сформованої за результатами виконання операції над даними;
  • • Old (Старий) - найменування тимчасової області даних, які подаються єдиною рядком даних, що містить відомості до виконання операції над даними;
  • • New Table (Нова таблиця) - найменування тимчасової таблиці з безліччю рядків даних, одержуваних після виконання операції над даними;
  • • Old Table (Стара таблиця) - найменування тимчасової таблиці з безліччю рядків даних, одержуваних до виконання операції над даними;
  • • When Clause (Умова виконання) - вказівка ​​логічного виразу із застосуванням правил мови програмування СУБД, що визначає додаткові умови виконання триггерного дії.

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

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

image328

Puc. 5.15. Вказівка базових налаштувань тригера


Коли тригерні дію визначається на зміну (Update) даних таблиці, то можна ще вказати поля (колонки), дії над якими будуть ініціювати тригер, що може бути визначено в закладці "Update Columns" (Змінні колонки) налаштувань тригера (рис. 5.16).

image329


Puc. 5.16. Визначення колонок
для ініціювання тригера

До переліку доступних для вибору колонок потрапляють всі поля (колонки) таблиці, але, в даному випадку, найбільш цікаві колонки, які

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

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

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

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

image330

Мал. 5.17. Налаштування програмного коду тригера на макромові



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

image331

Puc. 5.18. Програмний код на мові СУБД


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

Тригерні дії, будучи програмними процедура, проте використовують не дуже часто. Найбільш часто застосовуються процедури, що зберігаються (рис. 5.19), програмним кодом яких можна управляти і отримувати доступ, включаючи запуск на виконання. Створення збереженої процедури виконується через контекстне меню папки "Stored procedures" (Збережені процедури) дерева проектів.

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

Parameter - найменування параметра, за яким потрібно буде його використовувати в програмному коді процедури;

  • • Туре - тип параметра, вибраний з двох варіантів (In - вхідний, Out - вихідний);
  • • Physical Data Type - тип даних, яким описуються допустимі значення для параметра;
  • • Default - значення за замовчуванням, яке повинно бути присвоєно параметру, якщо воно не визначено користувачем при виклику процедури.

image332

Мал. 5.19. Основні настройки збереженої процедури


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

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

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

image333

Puc. 5.20. Налаштування збереженої процедури


В рамках розглянутих базових налаштувань збереженої процедури найбільш важливими є дві:


  • • Specific Name (Найменування) - ім'я процедури, за якою вона буде викликатися для виконання обробки даних;
  • • SQL Data Access (Доступ до даних SQL) - тип виконуваної процедури з варіантами обробки даних (Modifies SQL Data) і вибірки даних (Reads SQL Data).

Крім основних налаштувань, які передбачають застосування стандартного мови SQL, інструментальним засобом надається можливість визначити деякі додаткові настройки (рис. 5.21), які вказуються в закладці "Other Options" (Інші настройки). Важливими настройками є:

  • - Language (Мова) - мова програмування, на базі якого буде сформований програмний код процедури, що;
  • - Coded Character Set Identifier (Кодування символів) - використання певної кодування символьних даних, які будуть записуватися в символьні змінні і параметри, що особливо важливо при використанні бази даних в інтернет-додатку, де кодування даних визначається в інтернет-сторінці;

Commit Transaction On Return (Завершувати транзакцію при поверненні) - процедура, що зберігається, за своєю суттю, є єдиною транзакцією, тобто виконуваної повністю або не виконується взагалі, що вимагає фіксування результату виконання зазначених в процедурі команд.

image334

Мал. 5.21. Інші настройки збереженої процедури


В результаті вказівки всіх первинних параметрів процедури буде, як і в випадку з тригером, сформований програмний код на макромові інструментального кошти (рис. 5.22).

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


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



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


Puc. 5.23. Результат процедури, що
на мові СУБД

Щоб змінити СУБД, для якої реалізується модель бази даних, досить в меню "Actions / Target Database ..." (Дсйствія / База даних призначення ...) викликати відповідне діалогове вікно, де вказати потрібну СУБД і її версію (рис. 5.24) .

image337

Puc. 5.24. Зміна вибору СУБД


Інструментальне засіб IBM InfoSphere Data Architect

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

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

В процесі розробки моделей за прикладом електронного магазину при переході до фізичної моделі бази даних була обрана СУБД IBM DB2 (рис. 5.25). Особливий інтерес викликає трансформація первинних ключів сурогатного типу, при якій був змінений тип даних. Наприклад, по суті "Замовлення" первинний ключ "ІДФ замовлення" було визначено

типом "serial" і оголошений сурогатним ключем. Трансформація в таблицю "orders" сформований поле "id_order" придбало інший тип даних - Varchar (l) for bit data. Для обраної СУБД це спеціальний тип даних, який представляється символьним типом, але з процедурою обробки як числового атрибута, який передбачає зберігання числового значення, що генерується за правилами арифметичної прогресії.

image338

Мал. 5.25. Результат переходу до фізичної моделі бази даних


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

image339

Мал. 5.26. Налаштування сурогатного первинного ключа


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

  • • Start - початкове значення, від якого СУБД оттолкнется при створенні першого запису таблиці;
  • • Increment - крок зміни значень ключа при додаванні чергового запису таблиці, який вираховується, як прищепило, на основі спеціального об'єкта "Лічильник" (Sequence), що зберігає поточне значення, яке необхідно змінювати;
  • • Minimum - мінімальне значення, яке може приймати поле (колонка) даного первинного ключа, де, в разі зняття прапорця, умова не буде контролюватися;
  • • Maximum - максимальне значення, яке може приймати поле (колонка) первинного ключа, з огляду на раніше сформовані умови заповнення значеннями первинних ключів.

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

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

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

  • - Diagrams - діаграми моделі бази даних з відображенням таблиць і уявлень;
  • - SQL Statement - програмні моделі обробки бази даних, включаючи функції і процедури;
  • - Storage Diagrams - діаграми храпения і розміщення даних але табличних просторів і контейнерів, що визначає фізичне розміщення даних на магнітному носії;
  • - Schema - схема (роль) бази даних, групує безліч об'єктів представлення даних, включаючи таблиці, уявлення і тригери.

image340

Мал. 5.27. Дерево проекту фізичної моделі бази даних


Використовують контекстне меню області "Storage Diagrams" (Діаграми зберігання), створюють відповідну діаграму, де можна розмістити необхідні табличні простору (рис. 5.28), що подаються двома типами: Regular - стандартне табличний простір для использова-

ня з таблицями і індексами; Large - великий табличний простір для зберігання даних великих типів.

image341

Мал. 5.28. Перенесення таблиць в табличний простір


Створивши діаграму, на робочому просторі можна створити порожній табличний простір і в закладці "Tables" (Таблиці) області властивостей табличного простору вказати таблиці, індекси і таблиці з великими даними, які повинні бути розміщені в ньому (лисиць. 5.29).

image342

Мал. 5.29. Результат створення табличного простору з таблицями


В результаті па діаграмі і в дереві проекту буде представлено табличний простір зі списком закріплених за ним таблиць. Однак недостатньо закріпити таблиці в табличний простір. Потрібно правильно налаштувати це табличний простір, що робиться в закладці "General" (Основний) області властивостей табличного простору.

Крім найменування табличного простору, розробнику необхідно визначити правила управління зберіганням на магнітному носії файлу бази даних і можливості відновлення таблиць при їх видаленні (рис. 5.30). Як і в інших інструментальних засобах, можливі настройки правил управління зберіганням визначаються відповідно до СУБД, що для IBM DB2 визначається варіантами: System, Database і Automatic Storage, - розглядають управління на рівнях операційної системи, СУБД або автоматичного визначення відповідно.

image343

Мал. 530. Налаштування основних властивостей табличного простору


Налаштувавши тип управління зберіганням, важливо вказати кількісні характеристики розмірності табличного простору і змін його розмірів при повному заповненні даними. Ці характеристики визначаються в закладці "Size" області властивостей табличного простору (рис. 5.31).

image344


Puc. 531. Налаштування розмірів табличного простору

Аналогічно іншим інструментальним кошти для табличного простору потрібно визначити розмір сторінки (Page size) і її початковий розмір (Initial size), вказавши одиницю виміру (КБ, Мб, Гб). Також вказують розмір екстента (Extent size), з огляду на розмірність сторінки.

Вказавши, що для фізичного місця табличного простору необхідно автоматично змінювати розмір (Autoresize), якщо воно повністю заповнене даними, потрібно додатково визначити наступні параметри:

  • • Increase size - величина зміни розміру із зазначенням принципу зміни (процентне або кількісне);
  • • Maximum size - максимальний розмір табличного простору, що указується в кількісному обсязі (КБ, Мб, Гб).

Таким чином, описавши всі табличні простору, можна перевірити коректність закріплення таблиць, особливо, якщо раніше таблиці були розміщені в табличні простору. Для виконання операції внесення таблиці в табличний простір нс тільки визначенням властивостей самого табличного простору можна звернутися до властивостей таблиці, де в закладці "Tablespace" можна вказати, яким чином потрібно розмістити дані таблиці.

Оскільки для таблиць, індексів і великих даних передбачається використання різних табличних просторів, то у властивостях таблиці розробнику пропонується вибрати, як розміщувати відповідні елементи. Виходячи з того, що стандартне табличний простір використовується для таблиць і індексів, у відповідних нолях (Regular, Index) можна вказати одне і теж табличний простір (рис. 5.32), по треба розуміти, що швидкість обробки при великих обсягах даних може бути істотно знижена , ніж при варіанті рознесення таблиць і індексів за різними табличних просторів.

image345

Puc. 5.32. Закріплення таблиці в табличні простору


Коли ж мова йде про великих даних, які подаються великими типами даних (Text, CLOB, BLOB, Binary і т.д.), то для зберігання цих даних потрібно використовувати спеціальне табличний простір (Large tablespace), яке, за замовчуванням, налаштоване на ефективну роботу з такими даними.

І нарешті, залишився останній набір властивостей опису таблиць, визначає правила управління зберіганням даних. Цей набір властивостей розміщується в закладці "Volumetries" (Вимірники) області властивостей таблиці (рис. 5.33). Важливим є, в першу чергу, зазначення відомостей про кількість записів, які можуть бути в таблиці:

- Initial number of rows (початкова кількість рядків) - це властивість показує, що при створенні таблиці туди необхідно розмістити якусь кількість записів;

Row growth per month (зміна рядків на місяць) - це властивість визначає кількість рядків (записів), яке буде додаватися в таблицю протягом місяця, визначаючи ступінь мінливості і збільшення розміру таблиці;

Maximum number of rows (максимальна кількість рядків) - цією властивістю обмежується кількість записів, яке може бути внесено в таблицю, забезпечуючи обмеження на можливості додавання нових записів, що дуже актуально для стандартних класифікаторів, мінливість яких прагне до нуля.

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

властивості "Projected in month" прогнозований розмір записи протягом місяця, з огляду на, що деякі поля (колонки) таблиці мають типом динамічного розміру рядка (varchar).

image346

Puc. 533. Налаштування вимірників таблиці

Аналогічні властивості вказуються для таблиці в цілому і індексів:

  • • Initial Size - базовий розмір запису таблиці чи відповідного індексу;
  • • Projected Size - прогнозований розмір;
  • • Maximum Size - максимальний розмір.

Визначившись з таблицями, полями (колонками) і табличними просторами, розробнику необхідно встановити коректні правила посилальної цілісності, але зв'язків між таблицями (рис. 5.34), що виконується через закладку "Referential Integrity" (посилальна цілісність) області властивостей зв'язку.

image347

Мал. 534. Налаштування посилальної цілісності


Дане інструментальне засіб, на відміну від багатьох інших, орієнтується тільки на ті правила посилальної цілісності, які визначені в обраній СУБД, надаючи можливість розробнику вказати особливості контролю зв'язку між таблицями тільки по двом діям - зміни і видалення даних. В тому числі, серед доступних дій, також існують обмеження СУБД, які відтворюються в інструментальному засобі. Наприклад, для дії Update інструментально засіб пропонує тільки три варіанти контролю посилальної цілісності: No Action, Restrict і Cascade. Пояснюється це тим, що даний засіб моделювання реалізує тригерні операції тільки за вказівкою розробника і не формує їх в автоматичному режимі, як це, наприклад, передбачено в ERWin.

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

У базових властивостях тригера (рис. 5.35), як і в інших інструментальних засобах, визначаються характеристики часу виконання тригера і дію над даними, яке повинно його ініціювати. Так, розробнику пропонується вказати:

  • - Name - найменування об'єкта тригера, щоб до нього можна було звернутися через команди управління структурою бази даних;
  • - Schema - схему (роль), за якою закріплюється тригер, де, за замовчуванням, визначається схема таблиці;
  • - Action time - час, коли повинен виконатися тригер при його ініціювання дією над даних, пропонуючи три варіанти на вибір: after (після), before (до), instead of (замість);
  • - Granularity - розглядаються області даних для використання в тригерних діях: statement - для кожного елемента запису (поля, колонки), row - для всієї записи цілком;
  • - Trigger event - події, які ініціюють тригер, до яких відносяться додавання (insert), зміна (update) і видалення (delete), де, якщо вибрано ініціює дію у вигляді зміни даних, можна вибрати поля (колонки), зміна яких призведе до запуску тригерана виконання.

image348

Puc. 535. Визначення базових властивостей тригера


Переходячи до наступного етапу опису тригера, розробник повинен визначити умови програмної логіки і сам програмний код. Налаштування програмного коду виконується в закладці "Details" (Деталі) області властивостей тригера (рис. 5.36), де потрібно визначити рівень роботи з даними:

  • • Temporary table names for transition tables - визначення імен тимчасових таблиць, де будуть зберігатися дані до (Old) і після (New) виконання операції, але модифікації даних;
  • • Correlation names for transition rows - визначення імен доступу до єдиної модифікується записи даних, характеризуючи дані до (Old) і після (New) виконання операції по модифікації даних.

image349

Мал. 5/30. Область програмування тригера


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

Далі розробник вказує в поле "When" логічне вираз, яке буде перевірятися перед виконанням тригерана факт доцільності проведення записаних в ньому операцій. В поле "Action" розробник вказує сам програмний код на мові SQL, який необхідно виконати при запуску тригера.

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

image350


Мал. Ї.37. Результат створення уявлення

Реалізація уявлення виконується через контекстне меню дерева проектів, де в властивості розробник вказує команду вибірки мовою

5 () Ц використовуючи закладку "5 () Ь", на підставі якої будуть визначені набори полів (колонок), що формуються поданням (рис. 5.38).

image351

Мал. 5.38. Вираз для подання


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

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

image352

Мал. 5.39. Основні настройки збереженої процедури


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

image353

Мал. 5.40. Визначення параметрів процедури


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

Вибір варіанту застосування (рис. 5.41), а саме типу повертається результату, здійснюється в закладці "Options" властивостей збереженої процедури, де:

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

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

image354

Мал. 5.41. Налаштування варіантів використання збереженої процедури


При використанні варіанту процедури, як параметричного уявлення (Reads SQL Data) програмний код реалізується у вигляді єдиної команди вибірки. Сам програмний код формується розробником в рамках закладки "Source" області властивостей збереженої процедури.

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

 
<<   ЗМІСТ   >>