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

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

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

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

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

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

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

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

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

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

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

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

Таблиці:

ЛЮДИНА		Типи Данних	Обмеження
ID ФАМІЛІЯ ІМЯ ОТЧЕСТВО ПАСПОРТ	PK. Идентификатор человека Фамилия человека Имя человека Отчество человека Паспорт человека	Number (8) Varchar2 (30) Varchar2 (30) Varchar2 (30) Varchar2 (15)	NOT NULL NOT NULL UNIQUE

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

ДІАГНОЗИ		Типи Данних	Обмеження
ID НАЗВА ОПИС	PK. Ідентификатор діагноза Повна назва Опис – симптоми, рекомендації і т.д.	Number (4) Varchar2 (50) Varchar2 (1700)	NOT NULL UNIQUE NOT NULL

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

ЛЕКАРСТВА		Типи Данних	Обмеження
ID НАЗВА ОПИС	PK. Ідентификатор ліків Повна назва препарату Опис – принцип дії, інструкція, рекомендації і т.д.	Number (5) Varchar2 (20) Varchar2 (1000)	NOT NULL UNIQUE NOT NULL

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

ЛІКИ_ДІАГНОЗИ		Типи Данних	Обмеження
ЛІКИ_ID ДІАГНОЗІВ_ID	PK. FK. Ідентификатор ліків PK. FK. Ідентификатор діагнозів	Number (5) Number (4)

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

ПРАЦІВНИК			Типи Данних		Обмеження
ID ЛЮДИНА_ID ПОСАДА_ID КОЛИ_ВЛАШТУВАВСЯ КОЛИ_ЗВІЛЬНИВСЯ КОНТАКТНИЙ_ТЕЛЕФОН	PK. Ідентификатор працівника FK. Ідентификатор людини FK. Ідентификатор посади Дата прийняття на роботу Дата звільнення з роботи Контактий телефон працівника	Number (4) Number (8) Number (2) Date Date Varchar2 (15)		NOT NULL

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

ПОСАДА		Типи Данних	Обмеження
ID НАЗВА ЗАРПЛАТА	PK. Ідентификатор посади Назва посади Щомісячна зарплатня працівнику з такою посадою	Number (4) Varchar2 (30) Number (6)	NOT NULL UNIQUE NOT NULL CHECK(ЗАРПЛАТА > 0)

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

ІСТОРІЯ_ХВОРОБИ		Типи Данних		Обмеження
ID ДІАГНОЗ_ID ПАЦІЄНТ_ID ДАТА_ПОСТУПЛЕННЯ ОГЛЯНУВШИЙ_ID ДАТА_СМЕРТІ	PK. Ідентификатор історії хвороби FK. Ідентификатор діагноза FK. Ідентификатор пацієнта (із ЛЮДИНА) Дата поступлення пацієнта в лікарню FK. Працівник, оглянувший пацієнта Дата смерти пациента		Number (9) Number (4) Number (8) Date Number (4) Date		NOT NULL

Містить опис історії хвороби.

ЛІКУВАННЯ		Типи Данних	Обмеження
ВРАЧ_ID ЛІКИ_ID ІСТОРІЯ_ID КОЛИ КІЛЬКІСТЬ	FK. Ідентификатор працівника FK. Ідентификатор ліків PK. FK. Ідентификатор історії хвороби PK. Дата виконання лікування Кількість використаних лікив	Number (4) Number (5) Number (9) Date Number	NOT NULL

Містить історію лікування.