PrIS

181

ERwin підтримує не тільки проектування сервера БД, але й автоматичне ґенерування клієнтського застосування в середовищі розроблення MS Visual Basic і Power Builder. Технологія ґенерування полягає в тому, що на етапі розроблення фізичної моделі даних кожній колонці присвоюються розширені атрибути, що містять інформацію про властивості об'єктів клієнтського застосування (у тому числі і візуальних), які відображають інформацію, що зберігається у відповідній колонці. Ця інформація записується у файлі моделі. На основі інформації, що міститься в розширених атрибутах, ґенеруються екранні форми. Отриманий код може відкомпілюватися і бути виконаний без додаткового ручного кодування.

Кожній колонці в моделі ERwin можна задати заздалегідь описані і іменовані властивості:

правила валідації (перевірка значень);

початкові значення, що встановлюються за замовчуванням;

стиль візуального об'єкту (наприклад, радіокнопка, поле введення та ін.);

формат зображення.

Для опису кожної властивості ERwin є відповідні редактори.

Створення звітів

Для ґенерування звітів в ERwin є інструмент – Report Browser. За замовчуванням Report Browser містить заздалегідь визначені звіти, що дозволяють наглядно подати інформацію про основні об'єкти моделі даних, – як логічної, так і фізичної.

Ґенерування словників

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

Переваги системи ERwin :

побудувавши один раз повноцінну модель бази даних, можна легко її розвивати, модифікувати і переносити з одного сервера бази даних на інший;

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

використовуючи стандарт IDEF1X, розроблений військовоповітряними силами США, ERwin дозволяє створювати складні документи у вигляді, простому для розуміння;

182

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

ERwin повністю підтримує можливості FRE (forward and reverse engineering) з використанням каталогів цільового сервера.

11.3.2. Стандарт IDEF1X

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

Ці поняття і є сутностями, що будуть моделюватися в системі. Скориставшись відповідним інструментом, треба створити сутності, що моделюються. Сутності на діаграмі зображаються прямокутниками (рис. 11.10).

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

Наступна дія полягає в заданні атрибутів для кожної сутності (рис. 11.11).

183

Рис. 11.10. Діаграма зі створеними сутностями.

Рис. 11.11. Діалог визначення атрибутів сутності.

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

184

При визначенні атрибутів можна використовувати для наочності логічні імена. Для кожного атрибута можна визначити, назву і тип, які він буде мати у фізичній базі даних. Крім поняття первинного ключа, в теорії існує поняття альтернативного ключа. Альтернативним ключем називається атрибут чи набір атрибутів, що однозначно ідентифікують екземпляр сутності, але з певних причин вони не використовуються як первинний ключ. Такою причиною може бути, наприклад, часта зміна цих атрибутів. Щоб позначити атрибут як ключовий, необхідно поставити поруч з назвою атрибута в дужках код – Акn (альтернативний ключ номер). Так само можна відзначити атрибут, що входить в індекс (код – IKn). На цьому опис логічної сутності зазвичай закінчується. Відразу ж можна виконати задання фізичних параметрів сутності, таких як імена полів у базі, їхні типи, значення за замовчуванням і правила перевірки

(рис. 11.12).

Рис. 11.12. Діалог задання фізичних параметрів сутності і її атрибутів.

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

185

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

Рис. 11.13. Діалог опису домена.

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

186

Рис. 11.14. Діаграма з визначеними зв'язками.

З поняттям зв'язку поязане поняття зовнішнього ключа. Зовнішній ключ (Foreign Key) ─ це атрибут, що може приймати тільки значення, описані в первинному ключі іншої таблиці. Щоб зв'язати дві таблиці, досить лише провести лінію від батьківської до дочірньої таблиці. При цьому первинний ключ батьківської таблиці буде автоматично доданий у список атрибутів дочірньої таблиці. Для кожного зв'язку можна задати такі параметри як кардинальність (тип відношення) і тип зв'язку (рис. 11.15).

187

Рис. 11.15. Діалог визначення параметрів зв'язку.

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

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

Версія 2.5 системи ERwin у порівнянні з попередніми версіями має більше можливостей для ґенерування баз даних. Розширена кількість дружніх серверів баз даних ─ ORACLE, INFORMIX, MS SQL Server, SYBASE Access та ін.

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

188

Рис. 11.16. Діалог опису процедурної цілісності зв'язку.

Рис. 11.17. Діалоги, які використовують для ґенерування БД.

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

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

Побудова звітів і друк діаграм.

189

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

11.4. Програмний засіб Visio

Для моделювання бізнес-процесів Visio 2003 пропонує бізнесаналітику шаблони для створення 7 видів діаграм:

Basic Flowchart;

Cross-Functional Flowchart (з вертикальним або горизонтальним розташуванням доріжок);

EPC (Event-driven Process Chain);

IDEF0;

DFD (Data Flow Diagrams) у двох нотаціях: Ґейна-Сарсона і Йорданаде Мазко;

WFD (Work Flow Diagram).

Нотація моделювання IDEF0 базується на методології структурного аналізу і проектування SADT.

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

11.3).

Таблиця 11.3. Типи стрілок нотації IDEF0.

190

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

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

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

Елементи для побудови IDEF0 подано на рис. 11.18.

Рис. 11.18. Елементи побудови діаграм у нотації IDEF0 у Visio 2003.

Для забезпечення навіґації по ієрархічних моделях бізнес-процесів Visio 2003 дозволяє створювати гіперпосилання з однієї діаграми на іншу.

Для опису бізнес-процесів нижнього (операційного) рівня можна використовувати нотацію EPC, розроблену Інститутом інформаційних систем Університету Саарланда (Німеччина) у співпраці з компанією SAP AG. Ключова особливість EPC - діаграм ─ опис бізнес-процесу як послідовності подій і функцій.

Основні графічні елементи діаграми EPC:

Функції;

Події;

організаційні одиниці, відповідальні за виконання функцій;

інформаційні або матеріальні об'єкти, які використовуються при виконанні функцій;

коннектори ( AND, OR, XOR).

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