Главная Партнеры Контакты  
Юридическая компания — «Основной закон», консультации и помощь в возвращении депозитов, защита по кредиту

ЮК
"ОСНОВНОЙ ЗАКОН"  

г. Киев, бул. Пушкина, 2а                
тел.: (044) 334-99-77                               
         (095) 407-407-3
         (096) 703-11-82

график работы: пн.- пт. с 9:00 до 18:00
          
                           

 












Рассматривается вопрос о предоставление нотариусам права выдачи извлечения из Реестра прав на недвижимое имущество.
Министерством юстиции был разработан проект Закона «О внесении изменений в некоторые Законы Украины относительно предоставления информации о государст...


Держреєстрація речових прав на нерухоме майно та їх обтяжень у 2014 році буде здійснюватись за новою - удосконаленою та спрощеною - процедурою.
Постанова Кабінету Міністрів "Про затвердження порядку державної реєстрації прав на нерухоме майно та їх обтяжень і Порядку надання інформації з Держа...




Система Orphus


Логічна схема бази даних

КАТЕГОРІЇ:

Автомобілі Астрономія Біологія Географія Будинок і сад Інші мови інше Інформатика Історія Культура література логіка Математика Медицина металургія механіка Освіта Охорона праці Педагогіка політика право Психологія релігія риторика Соціологія Спорт Будівництво технологія туризм фізика Філософія фінанси хімія Креслення Екологія Економіка електроніка


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

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

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

  1. Визначте класи вашої моделі, стан яких має зберігатися і після завершення роботи створив їх застосування.
  2. Створіть містить ці класи діаграму класів і характеризуйте їх як стійкі за допомогою стандартного поміченого значення persistent (стійкий). Для роботи зі специфічними деталями бази даних ви можете визначити і свої власні помічені значення.
  3. Розкрийте структурні особливості класів. У загальному випадку це означає, що треба детально уточняти їх атрибути і звернути особливу увагу на асоціації та їх кратності.
  4. Пошукайте типові структурні зразки, що ускладнюють проектування фізичної бази даних, наприклад циклічні асоціації, асоціації "один до одного" і n-арні асоціації. При необхідності створіть проміжні абстракції для спрощення логічної структури.
  5. Розгляньте поведінку цих класів, розкриваючи операції, важливі для доступу до даних і підтримки їх цілісності. У загальному випадку для кращого розподілу обов'язків бізнес-правила, що відповідають за маніпуляції на борами об'єктів, повинні бути вміщені в шарі, що знаходиться над цими стійкими класами.
  6. Намагайтеся використовувати в своїй роботі інструментальні засоби, що дозволяють перетворити логічний проект в фізичний.

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

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

Більш того, кожен студент може відвідувати будь-яку кількість курсів і на кожен курс може записатися будь-яке число студентів

Мал. 8.3. моделювання схеми

Всі шість класів на діаграмі позначені як стійкі (persistent), тобто їх екземпляри повинні міститися в базі даних або якомусь іншому сховищі. Наведено також атрибути всіх шести класів. Зверніть увагу, що всі атрибути є примітивними типами (див. Розділ 4). Моделюючи схему, відносини з непрімітівнимі типами найкраще представляти за допомогою явного агрегування (див. Глави 5 і 10), а не за допомогою атрибутів.

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

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

Дата додавання: 2015-01-01; переглядів: 12; Порушення авторських прав

Главная Партнеры Контакты    
Cистема управления сайта от студии «АртДизайн»