Моделювання логічної схеми бази даних

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

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

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

Моделювання схеми проводиться таким чином:

1. ідентифікуйте класи вашої моделі, стан яких повинно зберігатися і після завершення роботи створив їх застосування;

2. створіть містить ці класи діаграму класів і характеризує їх як стійкі за допомогою стандартного поміченого значення persistent (стійкий). Для роботи зі специфічними деталями бази даних ви можете визначити і свої власні помічені значення;

3. розкрийте структурні особливості класів. У загальному випадку це означає, що треба детально специфікувати їх атрибути і звернути особливу увагу на асоціації і їх кратності;

4. пошукайте типові структурні зразки, що ускладнюють проектування фізичної бази даних, наприклад циклічні асоціації, асоціації «один до одного» і n-арні асоціації. При необхідності створіть проміжні абстракції для спрощення логічної структури;

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

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

На рисунку 4.29 показана сукупність класів, взятих з інформаційної системи вузу. Цей малюнок є розширенням наведеної раніше діаграми класів і містить достатню кількість деталей для конструювання фізичної бази даних. У лівій нижній частині діаграми розташовані класи «Студент», «Курс» та «Викладач». Між класами «Студент» і «Курс» є асоціація, що показує, що студенти можуть відвідувати курси. Більше того, кожен студент може відвідувати будь-яку кількість курсів і на кожен курс може записатися будь-яке число студентів.

Рисунок 4.29 - Моделювання схеми БД

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

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

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

Існує багато інших операцій, які варто було б розглянути при проектуванні цих та інших класів, наприклад, запит про необхідні попередніх знаннях перед зарахуванням студента на курс. Але це, скоріше, бізнес-правила, а не операції з підтримання цілісності даних, тому краще розташовувати їх на більш високому рівні абстракції.