Створення фізичних моделей в erwin
Створення фізичних моделей вERwin
Вивчаються особливості роботи з пакетом ERwin 3.5 в процесі створення інформаційних фізичних моделей складних систем.
Призначені для студентів спеціальності 22 02.
Модель, колонка, валідація, індекс, тригер, збережена процедура, уявлення
Друкується за рішенням методичної ради Рязанської державної радіотехнічної академії.
Створення інформаційної системи підприємства - досить складний ітераційний процес містить фази розробки логічної і фізичної моделі даних [1].
На логічному рівні об'єктів моделі (сутностей і атрибутів) даються імена зрозумілі широкому колу фахівців, в тому числі і на кирилиці.
На фізичному рівні об'єкти бази даних (таблиці, колонки і т.д.) повинні називатися, як цього вимагають обмеження обраної системи управління базою даних (СКБД). Фізична модель залежить від конкретної СУБД, тому однією і тією ж логічної моделі можуть відповідати кілька фізичних моделей.
Таке дворівневе опис дозволяє, з одного боку, досить вільно обговорювати структуру даних з експертами предметної області, а з іншого боку - краще пристосувати модель до вимог зберігання і обробки даних.
На основі розробленої фізичної моделі можна згенерувати системний каталог СУБД або відповідний SQL-скрипт. Цей процес називається прямим проектуванням (Forward Engineering). Тим самим досягається масштабованість проекту - створивши одну логічну модель даних, можна згенерувати фізичні моделі під будь-яку підтримувану СУБД. З іншого боку, можна по вмісту системного каталогу або SQL-сріпту відтворити фізичну і логічну модель даних (Reverse Engineering). На основі отриманої логічної моделі даних інструментальне засіб проектування здатне згенерувати фізичну модель для іншої СУБД, а потім згенерувати її системний каталог. У такій послідовності може бути вирішена задача перенесення структури даних з одного сервера на інший.
Методичні вказівки призначені для студентів знайомих з ER - методом і мають навички роботи з ERwin на етапі створення інформаційної логічної моделі [2].
Створення фізичної моделі даних
Припустимо, що логічна модель деякої інформаційної системи створена, тобто визначені сутності та їх атрибути, організовані зв'язки між сутностями, задані первинні і альтернативні ключі, модель приведена до необхідному рівню нормальної форми. Після завершення логічного етапу проектування розробник переходить до створення фізичної моделі. Нижче наведено опис основних процедур цього процесу.
Палітра інструментів. На фізичному рівні палітра інструментів (рис.2) дещо відрізняється від палітри інструментів на логічному рівні:
- кнопка зв'язку «багато до багатьох» (третя кнопка зліва в нижньому ряду) замінена на кнопку зв'язків уявлень.
- Default InterBase Datatype. Показує тип даних, який за замовчуванням присвоюється кожному стовпчику таблиці.
- Table Name Macro. Шаблон генерації за замовчуванням імені таблиці.
- Index Name Macro. Шаблон генерації за замовчуванням імені індексу.
- Default Non-Key Null Option. Дозволяє дозволити або заборонити значення NULL для не ключовим колонок.
- Trigger Delimiter. Роздільник для коду тригера.
Кнопка Reset Names викликає діалог, що дозволяє замінити імена (таблиць, колонок, індексів і т.д.), задані вручну на значення за замовчуванням.
Кнопка RI Defaults викликає діалог, який дозволяє присвоїти кожній зв'язку між таблицями значення посилальної цілісності за замовчуванням.
Створення нової таблиці. Для внесення нової таблиці в модель на фізичному рівні служить кнопка на палітрі інструментів. Зв'язки між таблицями створюються так само, як на логічному рівні.
Вікна Name і Owner (рис.4) використовуються для введення імені таблиці і імені власника таблиці, що відрізняється від імені користувача, що виробляє генерацію БД.
Діалог Table Editor містить ряд закладок, які можуть бути використані на наступних етапах проектування.
Для редагування використовуються наступні кнопки:
New, Rename, Delete. Служать відповідно для створення, перейменування і видалення колонки.
Reset. Викликає діалог який дозволяє змінити властивості колонки, задані вручну, на значення за замовчуванням.
Migrate. Дозволяє визначити, які характеристики мігрувала колонки будуть збережені в дочірній таблиці.
DBSync. Служить для запуску процесу синхронізації моделі з системним каталогом БД.
Кнопки. Призначені для переміщення виділеної колонки в списку на позицію вгору або вниз.
General. Дозволяє присвоїти колонку таблиці певного домену (String, Number і т.д.), створити колонку тільки на фізичному рівні (вікно Physical Only) і включити її до складу первинного ключа (вікно Primary Key).
Закладка, відповідна обраної СУБД (на рис.5 - InterBase). Ім'я закладки встановлюється автоматично і відповідає обраної СУБД. Дозволяє задати тип даних, опцію NULL, правила валідації і значення за замовчуванням. Правила валідації і значення за замовчуванням повинні бути попередньо описані і іменовані відповідно в діалогах Validation Rule і Default / Initial Editor. Для виклику цих діалогів служать кнопки праворуч від відповідних списків, що розкриваються.
UDP. Завдання властивостей, які визначаються користувачем.
Index. Використовується для включення колонки до складу індексів.
Для створення нової колонки необхідно клацнути по кнопці New, потім ввести в діалозі New Column ім'я атрибута і ім'я відповідної йому колонки, а після цього вказати домен.
Правила валідації. ERwin підтримує правила валідації, які визначають діапазон зміни, список допустимих значень або будь-які інші обмеження, яким повинні задовольняти значення конкретної колонки.
Наприклад, значення вводиться в колонку Age, має бути більше 18, але менше 40. Для опису цієї умови можна було б безпосередньо створити правило валідації з ім'ям «Перевірка віку», яке повинно містити вираз: Age BETWEEN 18 AND 40. Однак, при використанні ERwin цей процес спрощується.
вибрати в списку Column потрібну колонку;
клацнути по кнопці праворуч від вікна Valid;
ввести значення нижньої (вікно Min) і верхньої (вікно Max) межі діапазону і вибрати. наприклад, опцію Server.
Інша можливість перевірки достовірності інформації, що вводиться пов'язана зі створенням списку всіх допустимих значень, які можна зберігати в колонці.
Щоб автоматично укласти кожне значення списку в тексті правила валідації в одинарні лапки, потрібно включити опцію Quote. Опція Not дозволяє згенерувати правило валідації в інверсному вигляді.
Значення за замовчуванням - значення, яке потрібно ввести в колонку, якщо ніяке інше значення не задано явно під час введення даних. Іноді найбільш часто зустрічаються (найбільш ймовірне) в колонці значення присвоюється цій колонці в якості значення за замовчуванням. Наприклад, в колонці «вік призовника» за замовчуванням може бути вказано 18.
- клацнути по кнопці New, ввести ім'я правила в поле Name діалогу New Default і клацнути по кнопці ОК;
- ввести у вікні Server Value значення (вираз) за замовчуванням.
Індекси інфляції. Щоб ефективно вирішити проблему пошуку даних, СУБД використовує особливий об'єкт, званий індексом. Індекс містить відсортовану по колонці або декільком колонкам інформацію і вказує на рядки, в яких зберігається конкретне значення колонки.
ERwin автоматично створює окремий індекс на основі первинного ключа кожної таблиці, а також на основі всіх альтернативних ключів, зовнішніх ключів і інверсних входів.
Ім'я індексу - рядок символів, що є об'єднанням трьох складових:
ІМ'Я ІНДЕКСУ = Х + ІМ'Я КЛЮЧА + ІМ'Я ТАБЛИЦІ,
де Х - перший символ рядка імені індексу;
ІМ'Я ТАБЛИЦІ - фізичне ім'я таблиці.
На певному етапі проектування можна відмовитися від генерації індексів за замовчуванням і для підвищення ефективності інформаційної системи створити власні індекси.
ERwin створює індекси, які можуть мати або унікальні, або повторювані значення. При створенні нового унікального індексу (діалог New Index) слід включити опцію Unique. Якщо колонка увійшла до складу унікального індексу, то при спробі вставити запис з неунікальним (повторюваним значенням) сервер видасть помилку і значення НЕ буде вставлено.
Іноді необхідно дозволити повторювані значення, якщо передбачається, що індексована колонка з великою ймовірністю буде містити повторювану інформацію.
Слід звернути увагу на те, що при створенні нового індексу автоматично створюється альтернативний ключ для унікального і інверсний вхід для неунікального індексу.
Тригери. Тригером називається процедура, яка виконується автоматично як реакція на подію. Тригер посилальної цілісності (RI - тригер) - особливий вид тригера, який використовується для підтримки цілісності між двома таблицями, які пов'язані між собою. Якщо в даній таблиці виконується ВСТАВКА (Insert), ЗМІНА (Update) або ВИДАЛЕННЯ (Delete), то тригер посилальної цілісності повідомляє СУБД, що потрібно робити з тими рядками у інших таблиць, у яких значення зовнішнього ключа збігаються зі значеннями первинного ключа вставляється, змінною або видаляється рядка.
Коли тригер зв'язується з таблицею, то він автоматично налаштовується так, щоб підтримувати одне з правил посилальної цілісності, в залежності від типу зв'язку (ідентифікує, що не ідентифікує) і ролі сутності (батько, нащадок) у зв'язку. Нижче наведено опис типових правил посилальної цілісності.
RESTRUCT. Забороняє СУБД виробляти необхідну зміну (INSERT, UPDATE або DELETE). Наприклад, при наявності ідентифікує зв'язку між сутностями КОМАНДА і ГРАВЕЦЬ це правило забороняє видалення назви команди (Parent Delete) до тих по, поки в ній значитися хоча б один гравець.
CASCADE. Виробляє необхідну зміну в першій таблиці і поширює його на пов'язані з нею таблиці (разом з назвою команди видаляються всі її гравці). Використовувати правило видалення каскадом слід з великою обережністю.
SET NULL. Виробляє необхідні зміни в першій таблиці і встановлює нульові (порожні) значення зовнішнього ключа в пов'язаних з нею таблицях. Це правило часто використовується при наявності неидентифицирующей зв'язку між таблицями. Наприклад, при видаленні відділу співробітник залишається працювати в організації не будучи приписаний до якогось відділу і інформація про нього зберігається.
SET DEFAULT. Працює як SET NULL, з тією різницею, що замість нульового значення присвоює зовнішньому ключу значення за замовчуванням.
NONE. Нічого не робить (ERwin не посилює кількість посилань цілісність). Це правило використовується, наприклад, при вставці значень в батьківську таблицю (Parent Insert).
Для генерації за замовчуванням коду тригера на мові SQL використовуються вбудовані шаблони посилальної цілісності, які автоматично присвоюються кожному зв'язку. Якщо вбудовані шаблони не задовольняють бізнес - правил, можна змінити коди, що генеруються на основі вбудованих шаблонів. ERwin дозволяє змінити шаблон і вказати, що при генерації модифікована версія повинна замінити вбудований шаблон.
Для редагування тригера слід натиснути правою кнопкою миші по зображенню таблиці фізичної моделі і вибрати у спливаючому меню пункт InterBase Trigger. З'являється діалог Table Trigger Viewer, в нижній частині якого є дві колонки, які викликають діалоги, призначені для створення і редагування тригерів.
Збережені процедури - іменовані набори попередньо відкомпільованих команд SQL, які можуть викликатися з клієнтського застосування або інших процедур, що зберігаються. На відміну від тригера збережена процедура не виконується у відповідь на якусь подію, а викликається з іншої програми, яка передає на сервер ім'я процедури.
Для створення або редагування збереженої процедури слід натиснути правою кнопкою миші по таблиці і вибрати в каскадному меню пункт Table Editor / Stored Procedure. З'являється закладка Stored Procedure діалогу Table Editor, яка містить всі елементи, необхідні для введення, відображення, редагування коду збереженої процедури і зв'язування її з таблицею.
Уявлення (view) - похідні таблиці, дані в яких не зберігаються постійно, як в основних таблицях, а формуються динамічно при зверненні до подання. Представлення даних це «вікно», через яке видно частину бази даних. Подання не може існувати саме по собі, а визначається тільки в термінах однієї або декількох таблиць. Застосування уявлень дозволяє розробнику забезпечити кожному користувачеві або групі користувачів свій погляд на дані, що вирішує проблеми простоти використання і безпеки даних. Уявлення даних корисні для підтримки конфіденційності шляхом обмеження доступу до певних частин бази даних. Наприклад, для того щоб зберегти конфіденційність, ми можемо створити уявлення даних, що показує всю інформацію про співробітника крім його окладу.
ERwin має спеціальні інструменти для створення і редагування уявлень. Для внесення подання в модель потрібно клацнути по кнопці в палітрі інструментів (рис.2), потім по вільному місцю діаграми. За замовчуванням уявлення отримує номер V_n, де n - унікальний порядковий номер подання. Для встановлення зв'язку потрібно клацнути по кнопці. потім по батьківській таблиці і, нарешті, за поданням (зв'язок показується пунктирною лінією (рис.8)). Для редагування уявлення служить діалог View Editor (рис.9). Для його виклику слід натиснути правою кнопкою миші по наданню й вибрати в меню пункт View Editor.
Список, що розкривається View дозволяє вибрати для редагування будь-яке представлення моделі. Вікно Name служить для редагування імені, а Owner - власника уявлення.
Діалог View Editor має наступні закладки:
Select (рис.9). Має два списки: в правом відображаються колонки уявлення, в лівому - колонки доступні для включення в уявлення. Кнопка New Expression дозволяє задати вираз в якості вихідного стовпця.
From. Дозволяє вибрати батьківські таблиці уявлення. Кожній таблиці можна задати синонім (поле Alias), який буде використовуватися при створенні SQL-команди створення вистави.
Where. Закладка містить три поля - Where, Group By і Having. На основі цієї інформації ERwin генерує SQL-команду створення вистави.
SQL. Закладка містить поле, в якому відображається SQL-запит створення вистави.
StoredProcedure. Дозволяє зв'язати з поданням збережені процедури.
Більш докладні відомості стосуються різних особливостей процесу створення фізичних моделей реляційних баз даних Новомосковсктелі можуть знайти в підручнику [3].