У якості логічній моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СУБД. Для перетворення концептуальної моделі, представленої у вигляді мови 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. Ідентификатор ліків
Повна назва препарату
Опис – принцип дії, інструкція, рекомендації і т.д.
Містить відповідність між ліками та діагнозами(хворобами) (одні ліки можуть лікувати декілька хвороб, одна хвороба може лікуватися декількома ліками)
ПРАЦІВНИК
Типи Данних
Обмеження
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
Містить історію лікування.
4.2.Фізичне проектування
База даних спроектована для її збереження у СКБД Oracle, яка підтримує реляційну модель даних і є об’єкто-реляційною СКБД. Ця СКБД має дуже розвинені можливості по створенню та супроводу баз даних, оскільки володіє найбільш розвиненою системою типів даних, можливостями індексування полів, що дозволяє одержувати доступ до даних за мінімальний час, а також функціями по забезпеченню підтримки цілісності даних між реляційними таблицями, що
дозволяє розробнику мінімізувати тимчасові витрати на створення бази даних, а кінцевому користувачеві витрати на підтримку цілісності збережених даних і одержання даних з бази даних.
Робота з базою даних підтримується за допомогою реляційної мови запитів SQL.
Логічна модель бази даних легко відображається в реляційну фізичну модель, оскільки логічна модель була побудована з використанням реляційної структури даних. Крім того, логічна модель була приведена у третю нормальну форму, тому усі відношення представляються у
фізичній моделі окремими таблицями. Ніякі злиття відношень в одну таблицю для підвищення ефективності виконання окремих класів запитів не виконуються у зв’язку з тим, що такі класи запитів не були знайдені. У результаті отримано вісім таблиць реляційної бази даних, де кожне відношення прямо відповідає окремій таблиці, атрибути кожного відношення стають полями цієї таблиці, а первинні ключі відношень стають первинними ключами таблиць.
