- •Національний університет «Києво-Могилянська Академія»
- •"Організація баз даних та знань" Звіт до самостійної роботи
- •2. Опис предметної області.
- •2.1.1. Загальна інформація.
- •4.1.2.2. Спостереження за роботою.
- •4.1.2.3. Співбесіди.
- •3. Технічні вимоги.
- •4. Групи користувачів інформаційної системи та їх функціональні вимоги (представлення користувачів).
- •5.1. Вимоги до даних.
- •5.2. Вимоги до роботи з даними.
- •5. Специфікація вимог.
- •8.1. Назва, версія, адреса для завантаження.
- •8.3. Опис наявних обмежень.
- •11. Визначення обмежень цілісності.
- •11.1. Обмеження домену.
- •11.2. Цілісність сутностей.
- •11.3. Цілісність посилань (в т.Ч. Для всіх зовнішніх ключів вказати on update, on delete).
- •11.4. Корпоративні (семантичні) обмеження цілісності.
8.1. Назва, версія, адреса для завантаження.
Для розробки було обрано CASE-систему CA ERwin Data Modeler Standard Edition 9.5.
Засіб було завантажено з офіційного сайту http://erwin.com/
8.2. Опис позначень (всіх, що використовуються).
8.3. Опис наявних обмежень.
Для ER-моделі немає позначень атрибутів (обов'язковість).
Не підтримує складні, багатозначні та похідні атрибути.
Не можна вказати кратність зв'язку (n <= 3);
Не можна створити зв'язок, якщо його можна знайти через інші.
9. Побудова ER-моделі в обраній CASE-системі.
Зв'язки "Дільничний-Виклик" та "Вузький спеціаліст - Прийом" було замінено на зв'язок "Лікар - Реєстрація", а "Направлення - Прийом" та "Направлення - Процедура" - на "Направлення -Реєстрація", так як CASE-система обмежувала створення таких зв'язків. Виводилось підсвічування уже існуючого зв'язку через який можна доступитись до сутності.
Модель - див. додаток 2
10. Побудова та опис реляційної моделі (в ручному режимі).
Так як адреси дільниць, алергії, інфекційні захворювання, хронічні захворювання та щеплення багатозначні атрибути - вони були виділені в окремі відношення.
Через зв'язок 1:1 сутність пацієнт була об'єднана з карткою. Направлення - з прийомом та процедурою. Реєстрація - з прийомом, викликом та процедурою.
Так як ієрархія лікарів визначається як mandatory or - виділили по одному відношенню для кожного сполучення суперклас/підклас.
Модель - див. додаток 3
11. Визначення обмежень цілісності.
11.1. Обмеження домену.
На схемі задані типи та множина допустимих значень атрибутів.
На схемі вказано допустимість атрибутів - значення null/ not null.
11.2. Цілісність сутностей.
Кожна сутність має первинний ключ що не може бути null.
11.3. Цілісність посилань (в т.Ч. Для всіх зовнішніх ключів вказати on update, on delete).
Відношення |
Зовнішній ключ |
ON DELETE |
ON UPDATE |
Реєстрація на прийом |
номер картки пацієнта |
CASCADE |
CASCADE |
номер трудової книжки лікаря |
SET NULL |
CASCADE |
|
Реєстрація виклику |
номер картки пацієнта |
CASCADE |
CASCADE |
номер трудової книжки дільничного |
SET NULL |
CASCADE |
|
Реєстрація на процедури |
номер картки пацієнта |
CASCADE |
CASCADE |
Картка пацієнта |
номер дільниці |
SET NULL |
CASCADE |
Алергії |
номер картки пацієнта |
CASCADE |
CASCADE |
Інфекційні захворювання |
|||
Щеплення |
|||
Хронічні захворювання |
|||
Дільниця |
номер трудової книжки дільничного |
CASCADE |
CASCADE |
Адреси дільниць |
номер дільниці |
CASCADE |
CASCADE |
Запис в картці |
номер картки пацієнта |
CASCADE |
CASCADE |
номер трудової книжки лікаря |
NO ACTION |
NO ACTION |
|
номер направлення |
NO ACTION |
NO ACTION |
|
номер довідки |
NO ACTION |
NO ACTION |
|
Дільничний лікар |
номер дільниці |
SET NULL |
CASCADE |
