3.3. Побудова концептуальної моделі роботи лікарні

На основі проведеного аналізу предметної області була побудована концептуальна модель з використанням мови ER–моделювання. Концептуальна модель наведена на наступному рисунку. Дамо декілька зауважень:

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

•По–друге, мова ER–моделювання не передбачає детального представлення інформаційно–довідкових задач. Ми припускаємо, що вони мають звичайний текстовий опис, який представлений на етапі аналізу.

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

4. Логічне та фізичне проектування бази даних

Завдання цього етапу полягає у проведенні логічного та фізичного проектування бази даних.

Логічне проектування — це розробка логічної структури системи баз даних без прив'язки до конкретної СКБД, структур збереження, методам доступу і т.д..

Фізичне проектування – це проект системи бази даних для конкретної СКБД. Під час виконання даного етапу модель сутностей і зв'язків перетворюється в схему бази даних і специфікації позамашинного збереження.

4.1. Логічне проектування

У якості логічній моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СКБД. Для перетворення концептуальної моделі, представленої у вигляді мови ER–моделювання, у реляційну модель, був використаний наступний алгоритм.

•Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім’я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.

•Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім’я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.

•Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.

Рис. Концептуальна ER-модель роботи лікарні

Сутність може унікально ідентифікуватися комбінацією атрибутів і/або зв'язків. При використанні в ідентифікаторі сутності зв'язку до складу первинного ключа включається зовнішній ключ, який посилається на ту таблицю, з якою пов’язаний той або інший зв’язок.

•Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в закінченні зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.

•Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL.

Таблиця 1. Відношення сутності Людина

^CHELOVEK

Ім’я стовпця	Тип	Дов- жина	Призначення	Обмеження цілісності стовпців
ID	ціле число	8	Ідентификатор людини	Первинний ключ
FAMILIJA	строка	30	Прізвище людини	Обов’язковий
IMJA	строка	30	Ім’я людини
OTCHESTVO	строка	30	По батькові людини
PASPORT	строка	15	Паспортні данні людини	Унікальний, обов’язковий

Містить данні про працівників та пацієнтів.

Таблиця 2. Відношення сутності Діагнози

^DIAGNOZY

Ім’я стовпця	Тип	Дов- жина	Призначення	Обмеження цілісності стовпців
ID	ціле число	4	Ідентификатор діагнозу	Первинний ключ
NAZVANIE	строка	50	Назва діагнозу	Унікальний, обов’язковий
OPISANIE	строка	1700	Докладний опис діагнозу	Обов’язковий

Містить данні про хвороби.

Таблиця 3. Відношення сутності Ліки

LEKARSTVA

Ім’я стовпця	Тип	Дов- жина	Призначення	Обмеження цілісності стовпців
ID	ціле число	5	Ідентификатор ліків	Первинний ключ
NAZVANIE	строка	20	Назва ліків	Унікальний, обов’язковий
OPISANIE	строка	1000	Докладний опис ліків	Обов’язковий

Місти данні про ліки.

Таблиця 4. Відношення сутності Ліки_Діагнози

LEKARSTVA_DIAGNOZY

Ім’я стовпця	Тип	Дов- жина	Призначення	Обмеження цілісності стовпців
LEKARSTVO_ID	ціле число	5	Ідентификатор ліків для відповідності	Зовнішній ключ, що посилається на первинний ключ відношення LEKARSTVA(ID)
DIAGNOZ_ID	ціле число	4	Ідентификатор діагнозів для відповідності	Зовнішній ключ, що посилається на первинний ключ відношення DIAGNOZY(ID)
Обмеження цілісності таблиці		Сукупність стовпців (LEKARSTVO_ID, DIAGNOZ_ID) мають первинний ключ.

Містить відповідність між ліками та діагнозами(хворобами) (одні ліки можуть лікувати декілька хвороб, одна хвороба може лікуватися декількома ліками)

Таблиця 5. Відношення сутності Працівник

SOTRUDNIK

Ім’я стовпця	Тип	Дов-жина	Призначення	Обмеження цілісності стовпців
ID	ціле число	4	Ідентификатор працівника	Первинний ключ
CHELOVEK_ID	ціле число	8	Зв’язок з людиною	Зовнішній ключ, що посилається на первинний ключ відношення CHELOVEK (ID)
DOLGNOST_ID	ціле число	2	Зв’язок з посадою	Зовнішній ключ, що посилається на первинний ключ відношення DOLGNOST (ID)
KOGDA_USTROILSJA	дата		Дата влаштування на роботу працівника	Обов’язковий
KOGDA_UVOLILSJA	дата		Дата звільнення працівника
KONTAKTNYJ_TELEFON	строка	15	Телефон працівника

Містить додаткові данні про працівників. При кожному влаштуванні працівника на роботу в цій таблиці створюється новий запис.

Таблиця 6. Відношення сутності Посада

DOLGNOST

Ім’я стовпця	Тип	Дов- жина	Призначення	Обмеження цілісності стовпців
ID	ціле число	2	Ідентификатор посади	Первинний ключ
NAZVANIE	строка	20	Назва ліків	Унікальний, обов’язковий
ZARPLATA	ціле число	6	Заробітьня плата для посади	Обов’язковий

Містить відомості про посади, які можуть буду призначені працівнику.

Таблиця 7. Відношення сутності ІСТОРІЯ_ХВОРОБИ