Моделювання даних з використанням модуля Rational Rose – Data Modeler

Моделювання даних є найважливішим процесом при проектуванні програмного забезпечення (ПЗ). З цієї причини, розробники CASE-засобів в своїх продуктах змушені приділяти моделюванню даних підвищений увагу. Будучи визнаним лідером в області об'єктних методологій, фірма Rational Software Corporation, тим не менше, до недавнього часу такого засобу не мала. Основною причиною цього, мабуть, є орієнтація на мову Unified Modeling Language (UML), як універсальний інструмент моделювання. UML повністю покриває потреби моделювання даних. Сформована протягом десятиліть технологія моделювання даних, традиції, система понять і колосальний досвід розроблювачів не могли далі ігноруватися. Важливу роль тут зіграла і необхідність формального контролю моделей даних, що є абсолютно необхідним при проектуванні мало-мальськи великих схем баз даних і що UML не забезпечує в достатній мірі. І, нарешті, останньою причиною, що спонукала фахівців Rational Software Corporation до створення власного засобу моделювання даних, є вимога побудови ефективних фізичних моделей, перш за все для конкретних СУБД – лідерів ринку.

На початку 2000 року фірма Rational Software Corpоration анонсувала появу власного засобу моделювання даних – Data Modeler, і в даний час воно є фахівцям, наприклад, використовують у своїй роботі Rational Rose 2000e.

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

Автори Data Modeler насамперед орієнтувалися на створення інструмента проектування фізичної моделі даних. При цьому не відбулося відмови від UML як від засобу моделювання даних, а деяким чином були зміщені акценти: тепер UML передбачається використовувати для побудови логічної моделі. По суті, логічна модель – це та ж об'єктна модель, що складається з об'єктів – сутностей. Перехід від логічної моделі до фізичної і навпаки в частині моделювання даних забезпечується Rational Rose автоматично. Для цього введено відповідність елементів моделей.
 

Таблиця 1. Відповідність елементів логічної і фізичної моделі































Логічна модель

Фізична модель

Class (Клас)

Table (Таблиця)

Operation (Операція)

Constraint (Обмеження)

Attribute (Атрибут)

Column (Колонка)

Package (Пакет)

Scheme (Схема)

Component (Компонент)

Database (База даних)

Association (Асоціація)

Relationship (Зв'язок)

Ні

Trigger (тригери)

Ні

Index (Індекс)

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

Таким чином, концептуально модуль Data Modeler не є заміною UML в деякому його підмножині (як же можна зазіхнути на святе!), А всього лише дає прихильникам об'єктних технологій потужний засіб ефективної побудови фізичних схем БД. З цієї точки зору він нас і буде надалі цікавити.

При створенні нового модуля фахівці Rational Software Corporation пішли за традиційною схемою розширення функціональних можливостей Rational Rose, а саме, створили підключається компонент (AddIns). Після установки Rational Rose у спеціальній редакції (Rational Rose Professional Data Modeler Edition) у розділі головного меню Tools з'являється новий розділ Data Modeler.
 





 

У розділі Data Modeler є два пункти: "Add Schema" і "Reverse Engeneer …". Пункт "Add Schema" використовується для створення нових схем БД, а пункт "Reverse Engeneer" – для побудови моделі на основі існуючої схеми БД.

Для того, щоб познайомитися з можливостями Data Modeler, ми скористалися пунктом "Reverse Engeneer" і імпортували в Rational Rose реальну схему БД (180 таблиць в Oracle 8). Ця схема БД була створена з використанням CASE-засоби ERWin. При її проектуванні застосовувалося більшість основних прийомів, використовуваних при моделюванні даних у структурних CASE-засобах. Утиліта імпорту схеми БД організована зручно у вигляді майстра (Wizard). Для імпорту нам потрібно було всього лише вказати дані для з'єднання з БД, все інше система зробила за нас автоматично.

Ось що у нас вийшло.
 





 

У розділі "Logical View" дерева проекту утворився пункт "Schemas" зі схемою "Poskeeper" і набором таблиць.

У контекстному меню схеми є можливість створити нову для Rational Rose діаграму – Data Model. Для демонстрації основних прийомів роботи Data Modeler ми створили таку діаграму і перенесли в неї кілька таблиць, в результаті отримали наступне.
 





 

Те, що вийшло, дуже нагадує уявлення схеми в традиційному CASE-засобі.

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

Діаграма Data Model надає наступні можливості:


  1. створення і редагування таблиць і їх елементів (колонок, обмежень, індексів, тригерів і т. п.);
  2. створення і редагування ідентифікують зв'язків між таблицями;
  3. створення і редагування не ідентифікують зв'язків.

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





 

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

Таблиця. 2. Специфікація таблиці БД

























Закладка

Опис

General

Вводиться загальна інформація про таблиці.

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

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

Check Constraints
Задаються вираження – інваріанти, які повинні виконуватися для всіх рядків таблиці.

Triggers
Містить список тригерів, який можна відредагувати, в тому числі додавши новий тригер.

Relationships
За наявності зв'язків між таблицями, закладка містить повний список зв'язків.

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

У будь-якій схемі БД найважливішу роль відіграють зв'язки між таблицями. Ми внесли на діаграму Data Model відсутні зв'язку. При цьому у нас вийшло наступне.
 





 

Між таблицями CURRENCY і HOLIDAYS існує ідентифікує зв'язок. Зверніть увагу, що на картинці для її подання використана нотація UML для асоціації типу "композиція"), між таблицями CURRENCY і CURRACCDEFAULT – Не ідентифікує, а для таблиці DICTIONARY визначена рекурсивна зв'язок. Кінці зв'язків позначені кардинальність (1, 0 ..*), а також ім'ям ролі.

У відповідних таблицях утворилися зовнішні ключі (поля, помічені червоним прапорцем "FK"). Там, де зовнішній ключ увійшов до складу первинного ключа (ідентифікує зв'язок), поле позначено двома прапорцями “PK”, “FK”.

Для редагування властивостей зв'язку потрібно увійти в пункт контекстного меню "Open specification".
Що з'явилося на екрані вікно має наступний вигляд.
 





 

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

Таблиця. 3. Специфікація зв'язку
















Закладка

Опис

General
Основні властивості зв'язку. Тут задаються:
ім'я зв'язку;
тип зв'язку;
найменування ролей (Parent, Child);
кардинальність для кожної ролі;

Migrated Key
Містить список зовнішніх ключів, що утворюються в результаті створення зв'язку.

RI
Завдання умов посилальної цілісності. Посилальна цілісність забезпечується двома способами:
на основі тригерів;
на основі декларативної посилальної цілісності (з використанням обмежень зовнішніх ключів).
Обидва способи реалізують найбільш популярні алгоритми, що задаються для кожної ролі (тільки для операцій update і delete, для insert ми не знайшли):
Restrict;
Cascade;
Set Null;
Set Default.

Наведені в табл. 3 можливості цілком покривають потреби моделювання даних, пов'язані з визначенням зв'язку.
Наступною необхідною функцією, яка є в будь-якому CASE-засобі, є функція генерації фізичної схеми БД (Froward Engineering). У Data Modeler вона присутня і викликається з контекстного меню подсхеми. Ми виконали генерацію схеми, представленої на рис. 5.
При генерації схеми нас, перш за все, цікавила правильність генерації умов посилальної цілісності. З задоволенням відзначимо, що Data Modeler чудово впорався з цим завданням в обох випадках (декларативної посилальної цілісності і посилальної цілісності, відслідковується тригерами). У результаті генерації схеми ми отримуємо скрипт, який тут же можемо і виконати. Особливо відзначимо, що Data Modeler забезпечує генерацію схеми БД для декількох популярних СУБД: Oracle, MS SQL, DB-2 та інших, а також у відповідності зі стандартом ANSI SQL 92.
Протягом життєвого циклу розробки ПЗ схема БД не є незмінною. З цієї причини бажано мати в CASE-засобі функцію порівняння існуючої БД і моделі, а також і функцію синхронізації БД і моделі. Функція синхронізації в існуючій версії Data Modeler поки відсутня, а от функцію порівняння нам вдалося випробувати. Ми порівняли модель на рис. 5 зі скриптом, отриманим в результаті генерації схеми. Результат був несподіваним: замість відсутність відмінностей ми отримали досить значний їх список. Основний висновок – функцією порівняння поки користуватися не слід.
І, нарешті, остання функція, на яку ми б хотіли звернути увагу – генерація об'єктної моделі на основі фізичної моделі даних (без реалізації цієї функції Data Modeler навряд чи побачив би світло).
Для схеми Poskeeper ми виконали генерацію об'єктної моделі. При цьому Data Modeler автоматично зіставив кожній таблиці об'єкт, а кожній зв'язку асоціацію. Усі знову створені об'єкти були поміщені в новий пакет. Назви об'єктів і асоціацій складаються з префікса "OM_", далі йде назва таблиці або асоціації, з якої він утворений. Об'єкти, відповідні таблиць на рис. 5, ми винесли на окрему діаграму класів. Ось що у нас вийшло.
 





 

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


  1. Data Modeler підтримує більшість можливостей структурних CASE-засобів в плані фізичного моделювання даних;
  2. Data Modeler забезпечує генерацію ефективної фізичної структури БД, що підтримує механізми забезпечення посилальної цілісності;
  3. Data Modeler тісно інтегрований з Rational Rose, а діаграма Data Model природним чином вписується в загальну технологію розробки ПЗ з використанням лінійки продуктів фірми Rational Software Corporation;
  4. Можна відмовитися від інтеграції Rational Rose з іншими засобами генерації фізичних моделей.
  5. Забезпечується концептуальне відповідність моделювання даних і об'єктних моделей, що дозволяє більш ефективно проектувати програмні засоби.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*