Використання UML і Rational Rose для моделювання даних

Зміст



Введення


Якщо інтереси читача збігаються з інтересами автора даної статті, то він, як і автор, повинен бути заінтригований виходом на ринок моделювання даних продукту компанії Rational. Компанія Rational розповсюдила свій продукт Rose на область моделювання даних з використанням нотації UML (Уніфікована мова моделювання) на відміну від традиційно використовуваних нотацій, таких як IDEF1X і Information Engineering (IE). Чи варто витрачати час на вивчення моделювання даних з використанням UML? Аналізуючи продукт компанії Rational – Rational Rose Data Modeler, заснований на UML, автор вивчив даний і пов'язані з ним питання.


Зустрічайте UML!


Але що ж робить UML більш підходящим для моделювання даних в порівнянні з традиційними нотаціями IDEF1X або IE? По-перше, більшість великих компаній має групу, що працює з базами даних, яка відокремлена від групи розробників. Подібна структура команди дозволяє оптимально використовувати час аналітиків даних (DA) та адміністраторів баз даних (DBA), але не підвищує ефективності роботи команди над проектом. Крім того, конкуруючі ідеї з приводу якості даних і ефективності програми реалізуються у вигляді засобів аналізу, які розробляються різними групами на основі різних case-засобів, із застосуванням різних нотацій. Автор спостерігав саме такий сценарій при роботі з попереднім клієнтом. Група супроводження бази даних мала у своєму складі аналітиків даних, обов'язком яких було моделювання даних і проектування бази даних. Аналітики даних для документування вимог до даних у вигляді логічних і фізичних моделей використовували, в основному, ERwin. Команди розробників додатків, з іншого боку, використовували Rational Rose для створення засобів аналізу і проектування. Для розробників були зрозумілі їхні діаграми класів, але вони виставляли на перший план діаграму зв'язку сутностей, після чого аналітики блідли. Засіб моделювання даних Rose призначено для вирішення цієї проблеми на основі побудови всіх моделей за допомогою нотації UML. Що стосується Rational, то при створенні програми і засобів проектування з використанням однієї і тієї ж нотації "взаємодія буде більш узгодженим, зникнуть бар'єри між групами розробників, що дозволить підвищити якість і знизити ризик появи помилок ".


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


Отже, з чого почав автор?


Почнемо із заяви про те, що всі аналітики даних повинні вивчити UML. Враховуючи велику кількість розроблюваних об'єктно-орієнтованих проектів, аналітики даних, які, не здатні працювати з UML, швидко опиняться не при справах. Специфікацію UML 1.3 можна завантажити з сайту Rational. Важливо пам'ятати, що UML був розроблений, маючи на увазі процеси і дані, а не тільки дані. Тому UML досить гнучкий і розширюємо, що дозволяє справлятися з моделюванням складних бізнес-процесів. Для моделювання даних необхідно тільки підмножина специфікації UML. На жаль, абсолютно неочевидно, що є зайвим, і що ні. Це зрозуміло з такого прикладу. При моделюванні даних використовуються два типи зв'язків, обидва відображають ясні бізнес-відносини:

 








Идентифицирующая зв'язок Сутність-нащадок залежить від породжує сутності і не може існувати без неї
Неидентифицирующей зв'язок Сутність-нащадок не залежить від породжує сутності.

У UML існує багато нюансів взаємозв'язків, які мають більше значення, ніж просто ідентифікація. Вони відображають залежність і дозволяють здійснювати управління. На наведеному малюнку 1 сутність CUSTOMER дозволяє управляти або посилатися на сутність ORDER. Стрілка вказує на управління.


Рис. 1. Фрагмент моделі класу

На рис. 2 показана модель даних, побудована прямим проектуванням.


Рис 2. Трансформована модель даних

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

Фрагмент моделі, наведений на рис. 3, відноситься до тієї ж самої моделі з сутністю ORDER, пов'язаної ставленням з сутністю CUSTOMER.


Рис 3. Фрагмент моделі класу

Як можна бачити в моделі даних, побудованої прямим конструюванням, напрям управління на трансформовану модель даних (рис. 4) впливу не надає. (І автор навіть не буде чіплятися до того, чому змінилася кількість елементів з 0 .. n в моделі класу на 0 ..* в моделі даних).


Рис. 4. Трансформована модель даних

Що ж, це зовсім непогано

Автор міг би змиритися з цією проблемою, так як вона не впливає на точність моделі даних. Але що ж щодо тих проблем, які істотні при роботі з даними, але неприпустимі при роботі з процесами. У наведеному нижче фрагменті моделі (рис. 5) показані дві нові сутності, AIRPLANE і SEAT.


Рис. 5. Фрагмент моделі класу з Composite Aggregation Relationship

У цьому випадку замість асоціації виникає складова агрегація. У термінах моделювання даних складова агрегація перетвориться в ідентифікує зв'язок. Так сталося, що автор ненавмисно помістив символ залежності не на тому кінці зв'язку. Це означає, що AIRPLANE представляється залежних від SEAT, в той час як SEAT залежить від AIRPLANE. Автор, однак, зумів правильно позначити зв'язок. Він зміг навіть додати напрям управління, але вже ясно, що це може дати! Не намагайтеся зобразити дану структуру в ERwin, так як це неможливо.

Автор перетворив модель класу Rose в модель даних. Результати наведені на рис. 6.


Рис. 6. Трансформована модель даних з ідентифікуючої зв'язком

Незважаючи на те, що елементи відносини свідчать, що сутність AIRPLANE є породжує, зворотне відношення залежності зумовлює міграцію первинного ключа сутності SEAT (T_SEAT_ID) "вниз" на ставлення сутності AIRPLANE. Для загострення ситуації компанія Rose вирішила змінити кількість елементів відносини SEAT з 0 .. n (0, 1, або більше) на 0 .. 1 (0 або 1). Може трапитися, що Rose розпізнає, той факт, що кількість елементів відносини, що перевищує одиницю, суперечить специфікації UML 1.3, або, можливо, це свідчить про те, що неможливо підтримувати відношення 0 .. n через зовнішній ключ. Залишилися питання щодо складеного первинного ключа для AIRPLANE, де один із стовпців (T_SEAT_ID) нульовий. Останній раз автор переконався, що Oracle не може реалізувати нульової стовпець зовнішнього ключа для первинного ключа.

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


Що далі


Продукт Rose є прекрасним засобом програмного моделювання. На жаль, коли справа доходить до моделювання даних, то виявляється, що він ще не зовсім готовий для цього. Багата специфікація UML з переваги фактично перетворюється в недолік, коли справа доходить до моделювання даних. Хоча Rose володіє деякими перевагами при моделюванні коду бази даних і підвищує ефективність корпоративної розробки, автор, тим не менш, рекомендує використовувати для побудови баз даних перевірені методики IDEF1X і IE. У даній статті автор лише торкнувся деяких проблем. У наступній статті буде дан більш глибокий аналіз відмінностей логічного і фізичного моделювання в Rose і ERwin. Пам'ятайте золоте правило: "Інформація – це капітал".


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


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

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

Ваш отзыв

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

*

*