Концептуальне проектування реляційних баз даних з використанням мови UML, Різне, Бази даних, статті

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

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

Існують методики, чітко описують всі етапи такого перетворення.

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

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

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

Історія систем автоматизації проектування баз даних (CASE-засобів) починалася з автоматизації процесу малювання діаграм, перевірки їх формальної коректності, забезпечення засобів довготривалого зберігання діаграм та іншої проектної документації. Звичайно, комп’ютерна підтримка роботи з діаграмами дуже корисна для проектувальника БД. Наявність електронного архіву проектної документації допомагає при експлуатації, адмініструванні та супроводі бази даних. Але система, яка обмежується підтримкою малювання діаграм, перевіркою їх коректності та зберіганням, нагадує текстовий редактор, що підтримує введення, редагування та перевірку синтаксичної коректності конструкцій деякої мови програмування, але існуючий окремо від компілятора. Здається природним бажання розширити такий редактор функціями компілятора, і це дійсно можливо, оскільки відома техніка компіляції конструкцій мови програмування в коди цільового комп’ютера. Але якщо є чітка методика перетворення концептуальної схеми БД в реляційну схему, то чому б ні виконати програмну реалізацію відповідного “компілятора” і ні включити її до складу системи проектування баз даних?

Ця проста думка, природно, не могла не прийти в голови виробників CASE-засобів проектування БД. Переважна більшість подібних систем, представлених на ринку, забезпечує автоматизоване перетворення діаграмних концептуальних схем баз даних, представлених в тій чи іншій семантичної моделі даних, в реляційні схеми, представлені найчастіше на мові SQL. У читача може виникнути питання, чому в попередньому реченні йдеться про “автоматизоване”, а не про “автоматичне” перетворення? Вся справа в тому, що в типовій схемі SQL-орієнтованої БД можуть міститися визначення багатьох об’єктів (обмежень цілісності загального вигляду, тригерів і збережених процедур і т.д.), які неможливо згенерувати автоматично на основі концептуальної схеми. Тому на завершальному етапі проектування реляційної схеми знову потрібно ручна робота проектувальника.

Ще раз зверніть увагу на те, який хід міркувань привів нас до висновку про можливість автоматизації процесу перетворення концептуальної схеми БД в реляційну. Якщо творці семантичної моделі даних надають методику перетворення концептуальних схем в реляційні, достатню для її застосування людиною, то чому б ні реалізувати програму, яка виробляє ті ж перетворення, слідуючи тією ж методикою? Задамося тепер іншим, але, по суті, схожим питанням. Якщо творці семантичної моделі даних надають мова (наприклад, діаграмний), використовуючи який проектувальники БД можуть на основі вихідної інформації про предметну область сформувати концептуальну схему БД, то чому б ні реалізувати програму, яка сама генерує концептуальну схему БД у відповідній семантичної моделі, використовуючи вихідну інформацію про предметної області? Хоча мені невідомі комерційні CASE-засобу проектування БД, які підтримують такий підхід, експериментальні системи успішно існували. Вони представляли собою інтегровані системи проектування з автоматизованим створенням концептуальної схеми на основі інтерв’ю з експертами предметної області та подальшим перетворенням концептуальної схеми в реляційну.

Існує багато різних підходів до семантичного моделювання баз даних. В останні 10 років одним з найбільш популярних мов семантичного моделювання є UML. Проектування реляційних БД – Тільки одна і не надто велика область застосування цієї мови, його можливості набагато ширше, однак підмножина UML (діаграми класів) успішно застосовується саме для таких цілей.

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

Мові об’єктно-орієнтованого моделювання UML (Unified Modeling Language) присвячено безліч книг, багато з яких перекладено на російську мову (а деякі і написані російськими авторами). UML розроблений і розвивається консорціумом OMG (Object Management Group) і має багато спільного з об’єктними моделями, на яких заснована технологія розподілених об’єктних систем CORBA, і об’єктною моделлю ODMG (Object Data Management Group).

Основні поняття діаграм класів UML


Діаграмою класів в термінології UML називається діаграма, на якій зображений набір класів (І деяких інших сутностей, не мають явного відношення до проектування БД), а також зв’язків між цими класами (іноді термін relationship перекладається на російську мову не як “зв’язок”, а як “ставлення”). Крім того, діаграма класів може включати коментарі і обмеження. Обмеження можуть неформально задаватися на природній мові або ж можуть формулюватися мовою OCL (Object Constraints Language), який є частиною загальної специфікації UML, але, на відміну від інших частин мови, має не графічну, а лінійну нотацію. Ми торкнемося цю тему нижче трохи більш докладно.

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


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


Клас Людина із зазначеними іменами атрибутів

Імена атрибутів представляються в розділі класу, розташованому під ім’ям класу. Хоча UML не накладає обмежень на способи формування імен атрибутів (ім’я атрибута може бути довільною текстової рядком), на практиці рекомендується використовувати короткі прикметники та іменники, зміст яких відповідає змісту відповідного властивості класу. Перше слово в імені атрибута рекомендується писати з великої літери, а всі інші слова – з великої літери.

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

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


Для класу Людина ми визначили три операції. Операція “видатьВозраст” використовує значення атрибута “датаРожденія” і значення поточної дати. Операція “сохранітьТекущійДоход” дозволяє зафіксувати в стані об’єкта суму і дату надходження доходу даної людини. Операція “видатьОбщійДоход” видає сумарний дохід даної людини за вказаний час. Зауважимо, що стан об’єкта змінюється при виконанні тільки другої операції. Результати першої і третьої операцій формується на основі поточного стану об’єкта.

У діаграмі класів можуть брати участь зв’язку трьох різних категорій: залежність (dependency), узагальнення (Generalization) і ассоцірованіе (Association). Для проектування реляційних БД найбільш важливі друга і третя категорії зв’язків. Тому з приводу зв’язків-залежностей ми буде дуже короткі.

Зв’язки-залежності

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


Залежність показується переривчастою лінією зі стрілкою, спрямованої до класу, від якого є залежність. Легко бачити, що зв’язки-залежності істотні для об’єктно-орієнтованих систем (у тому числі і для ООБД). При проектуванні реляційних БД незрозуміло, що робити з залежностями (як скористатися цією інформацією в реляційної БД?).

Зв’язки-узагальнення

Зв’язком-узагальненням називається зв’язок між загальною сутністю, званої суперкласом, або батьком, і більш спеціалізованою різновидом цієї сутності, званої підкласом, або нащадком. Узагальнення іноді називають зв’язками “Is a”, маючи на увазі, що клас-нащадок є окремим випадком класу-предка. Клас-нащадок успадковує всі атрибути і операції класу-предка, але в ньому можуть бути визначені додаткові атрибути та операції.

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


Ієрархія одиночного наслідування класів

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


Приклад множинного успадкування класів

На цій діаграмі класи Студент і викладач породжені з одного суперкласу ЧеловекІзУніверсітета. Але як це часто трапляється, багато студентів уже в студентські роки починають викладати, так що можуть існувати такі два об’єкти класів Студент і викладач, яким відповідає один об’єкт класу ЧеловекІзУніверсітета. Отже, серед об’єктів класу Студент можуть бути викладачі, а деякі викладачі можуть бути студентами. Ми можемо визначити клас СтудентПреподаватель шляхом множинного успадкування від суперкласів Студент і викладач. Об’єкт класу СтудентПреподаватель має всі властивості та операціями класів Студент і викладач, і може бути використаний скрізь, де можуть використовуватися об’єкти цих класів. Так що поліморфізм по включенню продовжує працювати.

Але множинне спадкування, крім того, що не дуже часто потрібно на практиці, породжує ряд проблем, з яких однією з найбільш відомих є проблема іменування атрибутів і операцій в підкласі, отриманому шляхом множинного наслідування. Наприклад, припустимо, що при утворенні підкласів Студент і викладач в них обох був створений атрибут з ім’ям “номерКомнати”. Дуже ймовірно, що для об’єктів класу Студент значеннями цього атрибута будуть номери кімнат в студентському гуртожитку, а для об’єктів класу Викладач – номери службових кабінетів. Як бути з об’єктами класу СтудентПреподаватель, для яких істотні обидва однойменних атрибута? На практиці застосовується одне з таких рішень:


  1. заборонити освіта підкласу СтудентПреподаватель, поки в одному з суперкласів не буде вироблено перейменування атрибута “номерКомнати”;
  2. успадковувати це властивість лише від одного з суперкласів, так що, наприклад, значенням атрибута “номерКомнати” у об’єктів класу СтудентПреподаватель завжди будуть номери службових кабінетів;
  3. успадкувати в підкласі обидва властивості, але автоматично перейменувати обидва атрибута, щоб прояснити їх зміст; назвати їх, наприклад, “номерКомнатиСтудента” і “номерКомнатиПреподавателя”.

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

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

Зв’язки-асоціації

Асоціацією називається структурна зв’язок, що показує, що об’єкти одного класу певним чином пов’язані з об’єктами іншого або того ж самого класу. Допускається, щоб обидва кінці асоціації ставилися до одного класу. В асоціації можуть зв’язуватися два класи, і тоді вона називається бінарної . Допускається створення асоціацій, що пов’язують одразу n класів (вони називаються n-арнимі асоціаціями). Графічно асоціація зображується у вигляді лінії, що з’єднує клас сам із собою або з іншими класами.

З поняттям асоціації пов’язані чотири важливих додаткових поняття: ім’я , роль , кратність і агрегація . По-перше, асоціації може бути присвоєно ім’я , Що характеризує природу зв’язку. Сенс імені уточнюється чорним трикутником, розташовуваним над лінією зв’язку праворуч або ліворуч від імені асоціації. Цей трикутник вказує напрямок, в якому повинно читатися ім’я зв’язку. Приклад іменованої асоціації зображений на малюнку. Трикутник означає, що іменована асоціація повинна читатися як “Студент вчиться в Університеті”.


Приклад іменованої асоціації

Іншим способом іменування асоціації є вказівка ролі кожного класу, що бере участь в цій асоціації. Роль класу задається іменем, що поміщаються під лінією асоціації ближче до даного класу. На наступному малюнку показані дві асоціації між класами Людина і Університет, в яких ці класи грають різні ролі. Як ми бачимо, об’єкти класу Людина можуть виступати в ролі ПРАЦІВНИКІВ за участю в асоціації, в якій об’єкти класу Університет грають роль НАЙМАЧА. В іншій асоціації об’єкти класу Людина грають роль СТУДЕНТА, а об’єкти класу УНІВЕРСИТЕТ – в ролі учня.


Дві асоціації з різними ролями класів

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

Кратністю (Multiplicity) ролі асоціації називається характеристика, яка вказує, скільки об’єктів класу з даною роллю може або повинна брати участь у кожному примірнику асоціації (в UML примірник асоціації називається з’єднанням – link). Найбільш поширеним способом завдання кратності ролі асоціації є вказівка ​​конкретного числа або діапазону. Наприклад, вказівка ​​”1″ говорить про те, що всі об’єкти класу з даною роллю повинні брати участь в деякому примірнику даної асоціації, причому в кожному примірнику асоціації може брати участь рівно один об’єкт класу з даною роллю. Вказівка ​​діапазону “0 .. 1” говорить про те, що не всі об’єкти класу з даною роллю зобов’язані брати участь в будь-якому примірнику даної асоціації, але в кожному примірнику асоціації може брати участь тільки один об’єкт. Аналогічно, вказівка діапазону “1 .. *” каже, що всі об’єкти класу з даною роллю повинні брати участь в деякому примірнику даної асоціації, і в кожному примірнику асоціації повинен брати участь хоча б один об’єкт (верхня межа не задана). Тлумачення діапазону “0 .. *” є очевидним розширенням випадку “0 .. 1”.

У більш складних (але вкрай рідко зустрічаються на практиці) випадках визначення кратності можна використовувати списки діапазонів. Наприклад, список “2, 4 .. 6, 8 .. *” каже, що всі об’єкти класу з зазначеної роллю повинні брати участь в деякому примірнику даної асоціації, і в кожному примірнику асоціації повинні брати участь дві, від чотирьох до шести чи більше восьми об’єктів класу з даною роллю.


Асоціації із зазначеними кратностями ролей

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

Звичайна асоціація між двома класами характеризує зв’язок між рівноправними сутностями: обидва класи знаходяться на одному концептуальному рівні. Іноді в діаграмі класів потрібно відобразити той факт, що асоціація між двома класами має спеціальний вид “частина-ціле”. В цьому випадку клас “ціле” має більш високий концептуальний рівень, ніж клас “частина”. Асоціація такого роду називається агрегатної . Графічно агрегатні асоціації зображуються у вигляді простої асоціації з незакрашенним ромбом на стороні класу-“цілого”. Простий приклад агрегатної асоціації зображений на малюнку:


Приклад агрегатної асоціації

Об’єктами класу Аудиторія є студентські аудиторії, в яких проходять заняття. У кожній аудиторії мають бути встановлені парти. Тому в певному сенсі клас Парта є “частиною” класу Аудиторія. Ми навмисне зробили роль класу Парта необов’язковою, оскільки можуть існувати аудиторії без парт (наприклад, клас для занять танцями), і деякі парти можуть перебувати на складі. Зверніть увагу, що хоча аудиторії, не оснащені партами, як правило, непридатні для занять, об’єкти класів Аудиторія і Парта існують незалежно. Якщо деяка аудиторія ліквідується, то що знаходяться в ній парти не знищуються, а переносяться на склад.

Бувають випадки, коли зв’язок “частини” та “цілого” настільки сильна, що знищення “цілого” призводить до знищення всіх його “частин”. Агрегатні асоціації, що володіють такою властивістю, називаються композитними , Або просто композиціями . При наявності композиції об’єкт-частина може бути частиною тільки одного об’єкта-цілого (композиту). При звичайній агрегатної асоціації “частина” може одночасно належати кільком “цілим”. Графічно композиція зображується у вигляді простої асоціації, доповненої зафарбовані ромбом з боку “цілого”. Приклад композитної агрегатної асоціації зображений на малюнку:


Приклад композитної агрегатної асоціації

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

Зауважимо, що в контексті проектування реляційних БД агрегатні і особливо композитні асоціації впливають тільки на спосіб підтримки посилальної цілісності. Зокрема, композитна зв’язок є явним зазначенням того, що посилальна цілісність між “цілим” і “частинами” повинна підтримуватися шляхом каскадного видалення частин при видаленні цілого. При наявності простий асоціацію між двома класами передбачається можливість навігації між об’єктами, що входять в один примірник асоціації. Якщо відомий конкретний об’єкт-студент, то повинна забезпечуватися можливість дізнатися відповідний об’єкт-університет. Якщо відомий конкретний об’єкт-університет, то повинна забезпечуватися можливість дізнатися всі відповідні об’єкти-студенти. Іншими словами, якщо не обумовлено протилежне, то навігація по асоціації може проводитися в обох напрямках. Однак бувають випадки, в яких бажано обмежити напрямок навігації для деяких асоціацій. У цьому випадку на лінії асоціації ставиться стрілка, що вказує напрямок навігації. Можливий приклад показаний на малюнку:


Асоціація з вказаним напрямком навігації

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

Обмеження і мова OCL

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


Обмеження, виражене на природній мові

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

Більш точний і лаконічний спосіб формулювання обмежень забезпечує мова OCL (Object Constraint Language). Наведемо його стислий опис.

До запозиченим з UML концепціям відносяться, в першу чергу, такі:


Істотними для розуміння мови OCL є певні в UML відмінності між об’єктом деякого класу і значенням деякого типу, звичайні для об’єктних моделей даних.


На додаток до скалярним типами даних, запозиченим з UML, в OCL зумовлені структурні типи, які є різновидами колекцій (collection):


В OCL елементами кожного з трьох типів колекцій можуть бути або об’єкти, або значення.

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

Під інваріантом класу в OCL розуміється умова, якому повинні задовольняти всі об’єкти даного класу. Більш точно, інваріант класу – це логічний вираз, обчислення якого повинно давати true при створенні кожного об’єкту даного класу і зберігати це значення протягом усього часу існування об’єкта. При визначенні інваріанта потрібно вказати ім’я класу і вираз, що визначає інваріант зазначеного класу. Синтаксично це виглядає наступним чином:

context <class_name> inv: 

де є ім’ям класу, для якого визначається інваріант, inv – ключове слово, яке говорить про те, що визначається саме інваріант, а не інший вид обмежень, і context – ключове слово, яке говорить про те, що контекстом наступного після двокрапки OCL-вирази є об’єкти класу , тобто OCL-вираз має приймати справжнє значення для всіх об’єктів цього класу.

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

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

Операції над значеннями визначених типів даних

Вважаючи очевидною семантику зумовлених скалярних типів даних і операцій над ними, обмежимося лише їх перерахуванням. OCL підтримує такі запозичені з визначення UML скалярні типи даних: Boolean, Integer, Real і String.

Операції над об’єктами

Над об’єктами в OCL визначено три операції: отримання значення атрибута, перехід по з’єднанню, виклик операції класу (остання операція несуттєва для цілей проектування реляційних БД). Для запису цих трьох операцій використовується “точкова нотація”.

Наприклад, результатом вирази виду:

<Об'єкт>. <Ім'я атрибута>

є поточне значення атрибута з ім’ям <ім'я атрибута>, якщо об’єкт має такий атрибут. В іншому випадку використання такого вираження призводить до виникнення помилки типу.

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

<Об'єкт>. <Ім'я протилежний по відношенню до об'єкта ролі асоціації>

Операції над множинами, мультимножинами і послідовностями

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

<Колекція> ® <ім'я операції> (<список фактичних параметрів>)

Операція select

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

Операція collect

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

Операції exists, forAll, size

В OCL визначено три однойменних операції exist над безліччю, мультімножество і послідовністю, додатковим параметром яких є логічне вираження. Результатом кожної операції є true, якщо і тільки якщо хоча б для одного елемента вхідний колекції значенням логічного виразу є true. Операції forAll відрізняється від операцій exist тим, що результатом кожної з них є true, якщо і тільки якщо для всіх елементів вхідний колекції результатом обчислення логічного виразу є true. Операція size застосовується до колекції і видає число елементів, які в ній містяться.

Операції union, intersect, symmetricDifference

Параметрами двомісних операцій union, intersect, symmetricDifference є дві колекції, причому в OCL операції визначені майже для всіх можливих комбінацій типів колекції. Не будемо розглядати всі визначення цих операцій і коротко згадаємо тільки дві з них. Результатом операції union, визначеної над безліччю і мультімножество, є мультімножество, тобто з результату об’єднання таких двох колекцій дублікати не виключаються. Результатом ж операції union, визначеної над двома множинами, є безліч, тобто в цьому випадку можливі дублікати повинні бути виключені.

На закінчення огляду мови OCL наведемо приклади чотирьох інваріантів, висловлених на цій мові. Будемо грунтуватися на діаграмі класів, показаної на малюнку:


Діаграма класів, використовувана для прикладів на мові OCL

Перший приклад:

context Співробітник inv: self.возраст> 18 and self.возраст <100

Цей інваріант вказує, що вік співробітників повинен бути більше 18 і менше 100, що виражається у вигляді обмежень на значення атрибута вік, визначеного в класі Співробітник.

Другий приклад:

Висловимо на OCL то обмеження, що відділах з номерами більше 5 повинні працювати співробітники старше 30 років.

context Відділ inv: self.номер Ј 5 or self.сотруднік ® select (вік Ј 30) ® size () = 0

Той же інваріант можна сформулювати в контексті класу Співробітник: context Співробітник inv: self.возраст Ј 30 or self.отдел.номер> 5

Третій приклад:

Третій інваріант визначає те обмеження, що у кожного відділу повинен бути менеджер (між класами Співробітник і Відділ є асоціація, в якій роль кінець класу Співробітник має ім’я співробітник), і що будь-який відділ повинен бути заснований не раніше підстави відповідної компанії (між класами Відділ і Компанія є асоціація, в якій роль класу Компанія має ім’я компанія):

context Відділ inv: self.сотруднікі ® exists (посада = “manager”) and  self.компанія.годОснованія Ј self.годОснованія

Тут посаду – атрибут класу Співробітники, а атрибути з ім’ям годОснованія є і у класу Відділ, і у класу Компанія.

Зверніть увагу на висловлювання self.отдел.номер у другому прикладі і self.компанія.годОснованія. Ім’я відділ є ім’ям ролі в асоціації класів Співробітник і Відділ, і компанія – ім’я ролі в асоціації класів Відділ і Компанія. Але в даному випадку в OCL допускається точкова нотація, оскільки кратність обох цих ролей дорівнює одиниці (кожен співробітник працює в одному і тільки одному відділі, і кожен відділ належить одній і тільки одній компанії), і результатом переходу по з’єднанню в цьому випадку буде не колекція, а в точності один об’єкт.

Четвертий приклад:

Четвертий інваріант обмежує максимально можливу кількість співробітників компанії числом 1000:

context Компанія inv: self.отдели ® collect (співробітники) ® size () <1000

Зрозумілі плюси і мінуси використання мови OCL при проектуванні реляційних БД. Мова дозволяє формально і однозначно (без двозначностей, властивих природним мовам) визначати обмеження цілісності БД в термінах її концептуальної схеми. Швидше за все, наявність проектної документації буде корисним для супроводу БД навіть якщо доведеться перетворювати інваріанти OCL в обмеження цілісності SQL вручну.

До негативних сторін використання OCL відноситься, насамперед, складність мови та неочевидність деяких його конструкцій. Крім того, строгість синтаксису і лінійна форма мови в деякому роді суперечать наочності і інтуїтивної ясності структурної частини UML. Так, в инвариантах OCL використовуються ті ж поняття й імена, що й у відповідній діаграмі класів, але використовуються зовсім в іншій манері. І останнє. Я не можу довести або спростувати ні те, що мовою OCL можна виразити будь-яке обмеження цілісності, яке можна визначити засобами SQL, ні те, що мовою OCL не можна виразити такою інваріант, для якого виявиться неможливим сформулювати еквівалентну обмеження цілісності на мові SQL. Мені невідомі роботи, в яких би порівнювалася виразна потужність цих мов у зв’язку з обмеженнями цілісності реляційних БД.

Отримання схеми реляційної бази даних з діаграм класів

Взагалі кажучи, перехід від діаграмного подання концептуальної схеми бази даних до її реляційної схемі не залежить від різновиду використовуваних діаграм. Зокрема, методика, розроблена для класичних діаграм «Сутність-Зв’язок» (Entity-Relationship), практично завжди придатна для діаграм класів UML. Ця методика широко відома, і ми не будемо повторювати її в цій статті. Проте, здається доцільним привести декілька рекомендацій, які тісно пов’язані зі специфікою діаграм класів.

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

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

Рекомендація 3. Для технології реляційних БД агрегатні і особливо композитні асоціації є неприродними. Подумайте про те, що ви хочете отримати в реляційної БД, оголосивши деяку асоціацію агрегатної. Швидше за все, нічого.

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

Рекомендація 5. Не зловживайте можливостями OCL.

Діаграми класів UML – це хороший і потужний інструмент для створення концептуальних схем баз даних, але, як відомо, все добре в міру.

6.4 Заключні зауваження


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


Хочу ще раз підкреслити, що в контексті проектування реляційних БД структурні методи проектування, засновані на використанні ER-діаграм, і об’єктно-орієнтовані методи, засновані на використанні мови UML, розрізняються, головним чином, лише термінологією. ER-модель концептуально простіше UML, в ній менше понять, термінів, варіантів використання. І це зрозуміло, оскільки різні варіанти ER-моделей розроблялися саме для підтримки проектування реляційних БД, і ER-моделі майже не містять можливостей, що виходять за межі реальних потреб проектувальника реляційної БД.

Мова UML належить об’єктному світу. Цей світ набагато складніше реляційного світу. Оскільки UML може використовуватися для уніфікованого об’єктно-орієнтованого моделювання все, що завгодно, в ньому міститься маса різних понять, термінів і варіантів використання, абсолютно надлишкових з точки зору проектування реляційних БД. Якщо виокремити з загального механізму діаграм класів те, що дійсно потрібно для проектування реляційних БД, то ми отримаємо в точності ER-діаграми з іншого нотацією і термінологією.

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

Рекомендована література



  1. Чен П.П. Модель “сутність-зв’язок” – крок до єдиної поданням даних. СУБД, N3, 1995 р.
    Я дуже рекомендую прочитати цю класичну статтю, видану вперше в 1976 р. Мені здається, що ця стаття в чому прояснює процес розвитку семантичних діаграмних моделей.
  2. Вендров А.М. CASE-технології. Сучасні методи і засоби проектування інформаційних систем. М., Фінанси і статистика, 1998.
  3. Вендров А.М. Проектування програмного забезпечення економічних інформаційних систем. М., Фінанси і статистика, 2000.
    У книгах А.М. Вендрова дається широкий огляд сучасних технологій проектування інформаційних систем. Автор керується власним практичним досвідом, і в його викладі згладжуються термінологічні і концесійні бар’єри між різними підходами. Крім того, ці книги спочатку написані російською мовою, а не переведені з англійської, тому читаються без утруднень.
  4. Фаулер М., Скотт К. UML в короткому викладі. Застосування стандартної мови об’єктного моделювання. М., Мир, 1999.
    Багато моїх колег вважають, що це краща книга про UML, перекладена на російську мову. Вона написана чітко, без повторів та філософських відхилень від теми. Звичайно, книга не може поліпшити мову, але вона допомагає зрозуміти його в тому вигляді, в якому він існує. До речі, перекладав книгу А.М. Вендров.
  5. Буч Г. Об’єктно-орієнтований аналіз та проектування з прикладами додатків на C + +. 2-е изд. М., Видавництво Біном, СПб., Невський діалект, 1999.
  6. Буч Г., Рамбо Д., Джекобсон А. Мова UML: керівництво користувача. М., ДМК, 2000.

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

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


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

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

Ваш отзыв

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

*

*