Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Нотація UML

Безліч сучасних інформаційних систем будується на основі об'єктно-орієнтованої технології, і які використовуються в них бази даних найчастіше реалізуються гоже за цими принципами. Сучасні технології розробки та програмування дають досить великий набір інструментів для реалізації об'єктно-орієнтованих баз даних, а також реляційних баз даних, використовуючи нотацію і мова опису їм К. З метою розробки баз даних в 1ШЬ застосовується діаграма класів, яка, при необхідному розширенні, показує не тільки структуру бази даних з обмеженнями посилальної цілісності, а й опису механізмів обробки відповідних даних. Для опису структури бази даних в ИМБ застосовуються позначення, показані в табл. 2.17.

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

Таблиця 2.17

Опис елементів в нотації UML

№ п / п

позначення

опис

1

товар

  • - Артикул: char
  • - Найменування: char
  • - Ціна: double

Клас, що описує елемент бази даних з набором атрибутів

2

Асоціативний зв'язок між рівноправними класами

3

------------------------------ ►

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

4

----------------------------- про

агрегатна асоціація

5

• 1 (

Композитна агрегатна асоціація із заданою потужністю (кардинально)

6

------------------------------->

зв'язок узагальнення

7

..................................... ►

зв'язок залежності



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

image103

Мал. 2.63. Приклад подання класу в нотації UML


В нотації UML немає спеціального позначення для подання зв'язку багато - до - багатьох, але суть даного типу зв'язку фактично являє зв'язування рівноправних елементів, що в UML може бути представлено асоціативної зв'язком між рівноправними класами (рис. 2.64). Особливість цього позначення полягає в тому, що на кінцях лінії відсутні будь-які кінцеві елементи, а кардинальність, що вказується на асоціативних зв'язках, має верхньою межею значення - "*", що позначає можливість подання безлічі екземплярів відповідного класу.

image104

Мал. 2.64. Асоціативний зв'язок між рівноправними класами


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

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

image105

Мал. 2.65. Приклад асоціативного зв'язку з напрямком навігації


У представленому прикладі клієнт є елементом класу "Замовлення" і повинен в ньому обов'язково бути присутнім. Такий зв'язок проілюстрована наявністю кінцевий стрілки з боку класу "Замовлення". При цьому нижче зв'язку вказані позначення потужності (кардинальності) зв'язку, яка показує умова взаємодії примірників класів, позначаючи необхідність існування примірника клієнта до формування примірника замовлення і можливість вказівки одного і того ж клієнта в різних примірниках замовлень.

Оскільки для класів даних важливе розуміння ставлення один до одного і визначення його у вигляді "Ціле / частина", то в моделі класів потрібно показувати це відношення, що ілюструється наявністю кінцевого елемента "Ромб" в закрашенном або НЕ закрашенном вигляді (рис. 2.66).

image106

Мал. 2.66. Приклад агрегатної асоціації "Ціле / частина"


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

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

image107

Мал. 2.67. Приклад використання зв'язку залежності


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

Так само, як і в інших нотациях, з огляду на необхідність ілюстрації можливості поділу об'єктів на категорії з власним набором атрибутів, в нотації 1ШЬ використовують таку зв'язок, яка називається "Зв'язок узагальнення" (рис. 2.68).

У моделі класів розглядається не поділ елементів, а їх узагальнення, що показується відповідним зображенням зв'язку - лінія з кінцевими стрілкою в напрямку класу-спільності. Для розглянутого прикладу об'єкт "Клієнт" є спільністю для об'єктів "Фізична особа" і "Юридична особа", тому, позначаючи зв'язок, розробник буде її показувати у вигляді стрілки, спрямованої до класу "Клієнт". В результаті моделювання діаграми класів в нотації UML розробником буде представлена ​​модель, яка показана на рис. 2.69.

image108

Мал. 2.68. Приклад використання зв'язку узагальнення


image109

Мал. 2.69. Модель класів в нотації Ь Т МЬ


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

 
<<   ЗМІСТ   >>