- •1 Організаційні положення
- •1 Аналіз предметної області.
- •2. Постановка завдання
- •3. Проектування концептуальної моделі
- •4. Розробка логічної структури бази даних.
- •5. Реляційна модель.
- •6. Визначення типів даних в заданому форматі
- •7. Створення глобальної схеми зв'язків. Підтримка цілісності даних.
- •Запит «Кількість путівок клієнта»
- •9. Проектування форм. Структура та призначення існуючих форм.
- •2. Проектування реляційної бази даних
- •5. Проектування збережених процедур
- •6. Розробка механізмів керування даними
- •7 Розробка технології доступа до бази даних
- •8. Проектування керівництва користувача
- •9. Вимоги до технічного забезпечення
2. Проектування реляційної бази даних
Реляційна модель даних включає наступні компоненти: Структурний аспект (складова) - дані в базі даних являють собою набір відносин. Аспект (складова) цілісності - відносини (таблиці) відповідають певним умовам цілісності.
Реляційна модель даних підтримує декларативні обмеження цілісності рівня домену (типу даних), рівня відносини і рівня бази даних. Аспект (складова) обробки (маніпулювання)
- реляційна модель даних підтримує оператори маніпулювання відносинами (реляційна алгебра, реляційне числення).
У БД «Поліклініка» в таблицях «Облік роботи», «Лікарі», «Пацієнти», «Спеціалізації», «Зміни» між атрибутами і первинним ключем спостерігається функціональна залежність, так як значення ключа однозначно визначають значення інших атрибутів в даних таблицях. Таблиця 2.1 - Функціональні залежності між атрибутами сутності «Лікарі»
Назва атрибутів |
Функціональні залежності |
Id_vrасhа FIO_vrасhа Dаtа_rgdеniа Stаg_ rаbоti Stоimоst_рriеmа |
|
Таблиця 2.2 – Функціональні залежності між атрибутами
сутності «Пацієнт»
Назва атрибутів |
Функціональні залежності |
Id_расiеntа FIO Dаtа_rоgdеniа Nаsvаniе_nаsрunktа Dоm_аdrеss |
|
Таблиця 2.3 – Функціональні залежності між атрибутами сутності «Спеціалізації»
Назва атрибутів |
Функціональні залежності |
Id_sресiаlizасii Nаsvаniе |
|
Таблиця 2.4 – Функціональні залежності між атрибутами сутності «Зміни»
Назва атрибутів |
Функціональні залежності |
Id_smеni Vrеmуа_rаbоti Nаsvаniе |
|
Таблиця 2.5 – Функціональні залежності між атрибутами сутності «Облік роботи»
Назва атрибутів |
Функціональні можливості |
Id_smеni Id_vrасhа Id_расiеntа Id_sресiаlizасii Dеn_nеdеli |
|
Для кожної таблиці є свій ключ
Таблиця 2.6 – Ключі
Таблиця |
Ключ |
Облік роботи |
Id_smеni Id_vrасhа Id_расiеntа Id_sресiаlizасii |
Врачи |
Id_vrасhа |
Пациенты |
Id_расiеntа |
Смены |
Id_smеni |
Специализации |
Id_sресiаlizасii |
У базі даних «Поліклініка» проведена нормалізація відносин: Проаналізувавши таблицю «Лікарі», можна сказати, що вона знаходиться в першій нормальній формі, так як вона має первинний ключ, кожне поле таблиці представляє унікальний тип інформації. Так само дана таблиця знаходиться і під 2НФ, оскільки вона задовольняє умовам 1НФ, а так само я переконалася в тому, що кожне поле функціонально залежить від первинного ключа, який ідентифікує вихідний об'єкт таблиці. Таблиця «Лікарі» знаходиться в 3НФ, так як вона знаходиться під 2НФ і не містить транзитивних залежностей, тобто стовпці, що не є ключовими, залежать від первинного ключа таблиці і не залежать від всіх інших стовпців. Є можливість змінювати значення будь-якого поля (не входить в первинний ключ) без впливу на дані інших полів. Таблиці «Пацієнти», «Облік роботи», «Зміни», «Спеціалізації» аналогічно таблиці «Лікарі» знаходяться у всіх трьох нормальних формах. Таким чином, проаналізувавши розроблену базу даних, можна зробити висновок, що вона нормалізована і відповідає трьом нормальним формам.
2.1 Інфологічна модель даних
Така модель будується з використанням стандартних мовних засобів, зазвичай графічних. На етапі інфологічного проектування в ході збору інформації про предметну область потрібно з'ясувати: 1. основні об'єкти предметної області (об'єкти, про які повинна зберігатися інформація в БД);
2. атрибути об'єктів;
3. зв'язки між об'єктами;
4. основні запити до БД.
У проекті «Поліклініка» відповідно до предметної області були створені наступні сутності:
«Облік роботи» - зберігається інформація про роботу кожного лікаря;
«Лікарі» - зберігається інформація про лікарів;
«Пацієнти» - зберігається інформація про пацієнтів;
«Спеціалізації» - зберігається інформація про спеціалізаціях лікарів;
«Зміни» - зберігається інформація про змінах.
Кожному об'єкту відповідають свої атрибути:
- Облік роботи: код зміни, код лікаря, код спеціалізації, код пацієнта, день тижня; - Лікарі: код лікаря, ПІБ лікаря, стаж роботи, дата народження, вартість прийому; - Пацієнти: код пацієнта, ПІБ, дата народження, найменування населеного пункту, домашня адреса;
- Спеціалізації: код спеціалізації, назва;
- Зміни: код зміни, час роботи, назва зміни.
У базі даних «Поліклініка» визначені наступні відносини між таблицями:
Таблиця 2.7 – Классификация звязків
№ |
Родинна таблиця |
Дочірня таблиця |
Ключі |
Вид звязку |
|
1 |
Облік роботи |
Лікарі |
Id_vracha |
Id_vracha |
1:М |
2 |
Облік роботи |
Пацієнти |
Id_pacienta |
Id_pacienta |
1:М |
3 |
Облік роботи |
Зміни |
Id_smeni |
Id_smeni |
1:М |
4 |
Облік роботи |
Спеціалізації |
Id_specializacii |
Id_specializacii |
1:M |
Вибір
таких
зв'язків
обумовлений
тим
що,
загалом
обліку
роботи
поліклініки
міститься
інформація про всіх
віруючих,
пацієнтах,
про
змінах
роботи
лікарів
і
про
їх
спеціалізаціях.
На
рисунку
2.1
представлена
інфологічна
модель
бази
даних,
на
якій відображені
усі
сутності
БД.
Рисунок 2.1 – Інфологічна модель бази даних
2.2 Датологічна модель
У цьому розділі наводиться склад таблиць БД. Для кожного поля таблиці вказується розмір поля (кількість символів), тип. Для первинних ключів необхідно ввести заборону невизначених значень. Для решти полів можливість заборони невизначених значень визначається семантикою предметної області.
Таблиця 2.8 - Склад таблиці «Спеціалізації»
Назва атрибутів |
Тип поля |
NULL |
Id_specializacii Nasvanie |
int nchar(50) |
Нет Нет |
Таблиця 2.9 – Склад таблиці «Лікарі»
Назва атрибутів |
Тип поля |
NULL |
Id_vracha FIO_vracha Data_rogdenia Stag_ raboti Stoimost_priema |
int nchar(50) Date int int |
Нет Нет Нет Нет Нет |
Таблиця 2.10 – Склад таблиці «Пацієнт»
Назва атрибутів |
Тип полів |
NULL |
Id_pacienta FIO Data_rogdenia Nasvanie_naspunkta Dom_adress |
int nchar(50) Date int int |
Нет Нет Нет Нет Нет |
Таблиця 2.11 – Склад таблиці «Зміни»
Назва атрибутів |
Тип полів |
NULL |
Id_smeni Vremya_raboti Nasvanie |
int nchar(50) nchar(50) |
Нет Нет Нет |
Таблиця 2.12 – Склад таблиці«Облік роботи»
Назва атрибутів |
Тип полів |
NULL |
Id_smeni Id_vracha Id_pacienta Id_specializacii Den_nedeli |
int int int int nchar(50) |
Нет Нет Нет Нет Нет |
2.2.1 Діаграма звязку по полям
На рисунку 2.2 наведена схема бази даних «Поліклініка»
Рисунок 2.2 – Схема бази даних «Поліклініка»
3. ОРГАНІЗАЦІЯ вибірки інформації з БАЗИ ДАНИХ
Вибірка інформації здійснюється за допомогою запитів, які представлені в цьому розділі.
1. вибірка даних із зв'язаних таблиць. формулювання запиту: вибрати фіо_врача і назва зміни з таблиць «лікарі» і «зміни», де коди «id_vracha» і «id_smeni» дорівнюють: select vrachi.fio_vracha, smeni.nazvanie_smeni from vrachi, smeni where vrachi.id_vracha = smeni.id_smeni
Рисунок 3.1 - Результат роботи запиту «Вибірка з пов'язаних таблиць 2. Вибірка з використанням оператора (природного) з'єднання. Формулювання запиту: вибрати лікарів і їх спеціалізації шляхом з'єднання їх за кодом лікаря: select FIO_vracha, Nazvanie from Vrachi inner join Specializacii on Vrachi.id_vracha = Specializacii.id_specializacii
Рисунок 3.2 - Результат роботи запиту «Вибірка з використанням оператора природного з'єднання »
3. Вибірка з використанням шаблону. Формулювання запиту: вибрати всіх клієнтів з міста Вінниця: select FIO, Adress_naspunkt from Pacienti where Adress_naspunkt like 'Вінниця
Рисунок 3.3 - Результат роботи запиту «Вибірка з використанням шаблону » 4. Вибірка інформації в заданому діапазоні. Формулювання запиту: вибрати лікарів зі стажем роботи між 10 і 20 роками: select FIO_vracha, Stag_raboti from Vrachi where Stag_raboti between 10 and 20
Рисунок 3.4 - Результат роботи запиту «Вибірка інформації в заданому діапазоні »
5. Вибірка інформації по даті. Формулювання запиту: вибрати всіх пацієнтів, які народилися пізніше 01.01.1980: select * from Pacienti where Data_rogdeniya> '01 .01.1980 '
Рисунок 3.5 - Результат роботи запиту «Вибірка інформації по даті »
6. Вибірка числених значень. Формулювання запиту: вибрати лікаря і обчислити вартість його послуг з урахуванням пільг: select FIO_vracha, Stoimost_priema * 0.8 from Vrachi
Рисунок 3.6 - Результат роботи запиту «Вибірка числених значень»
7. Вибірка з використанням механізму підзапитів. Формулювання запиту: вибрати всі поля з таблиці «Лікарі», причому включаючи, тільки тих лікарів, у яких стаж роботи більше середнього значення серед усіх лікарів: select * from Vrachi where Stag_raboti> (select AVG (Stag_raboti) from Vrachi)
Рисунокк 3.7 - Результат роботи запиту «Вибірка з використанням механізму підзапитів »
8. Проста вибірка даних. Формулювання запиту: вибрати всі поля з таблиці «Пацієнти»:select*from Pacienti
Рисунок 3.8 - Результат роботи запиту «Проста вибірка даних»
9. Проста вибірка з сортуванням. Формулювання запиту: вибрати з таблиці «Пацієнти» всі записи і відсортувати їх: select * from Pacienti order by FIO
Рисунок 3.9 - Результат роботи запиту «Проста вибірка з сортуванням
4. РОЗРОБКА ПРЕДСТАВЛЕНЬ ДЛЯ ОРГАНІЗАЦІЇ ВИБОРКИ ДАНИХ
Уявлення - це динамічна таблиця, яка служить для відображення результатів вибірки з інформацією. Подання є зручним інструментом для роботи з таблицями бази даних. У базі даних розроблено уявлення: «режим роботи лікарів» (Рисунок 4.1).
Рисунок 4.1 – Представлення «Режим работи лікарів»
Дане представлення включає інформацію про лікарів ФІО,день в який вони працюють, а також назвуу зміни.
Рисунок 4.2 – Результат роботи представлення «Режим роботи лікарів»
