Концептуальне проектування реляційних баз даних з використанням мови 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 допускається використання довільної комбінації літер, цифр і навіть розділових знаків. Однак на практиці рекомендується використовувати в якості імен класів короткі і осмислені прикметники та іменники, кожне з яких починається з великої літери. Приклади опису класів показані на малюнку:


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


Діаграма класів, використовувана для прикладів мовою 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>

*

*