Проектування та розроблення бази даних для планування операцій в нейрохірургічному відділенні

Размещено на http://www.allbest.ru/

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ УКРАЇНИ

“КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ імені Ігоря Сікорського”

Факультет біомедичної інженерії

Кафедра біомедичної кібернетики

КУРСОВА РОБОТА

з навчальної дисципліни «Системи баз даних»

освітньо-кваліфікаційного рівня “бакалавр”

спеціалізація інформаційні технології в біології та медицині

На тему: проектування та розроблення БД для планування операцій в нейрохірургічному відділенні

Виконав студент 3-го курсу гр. БС-61

Коцюба Євген Васильович _________

Керівник курсової роботи

ст.викл. Сердаковський В.С. ________

Київ - 2018



ЗМІСТ

ВСТУП

ІНДИВІДУАЛЬНЕ ЗАВДАННЯ НА КУРСОВУ РОБОТУ

АНОТАЦІЯ

СПИСОК СКОРОЧЕНЬ

І. МОДЕЛЮВАННЯ ТА ПРОЕКТУВАННЯ БАЗИ ДАНИХ

1.1 Постановка задачі

1.2 Бізнес процеси та елементи даних

1.2.1 Перелік бізнес-процесів

1.2.2 Специфікація елементів даних

1.3 Залежності елементів даних

1.3.1 Функціональні залежності

1.3.2 Багатозначні залежності

1.4 Діаграми

1.4.1 Діаграма “Сутність -- Зв'язок”

1.4.2 Діаграма класів проектування

Висновки з розділу 1

ІІ. Створення та використання об'єктів бази даних

2.1 Таблиці

2.2 Обмеження цілісності

2.3 Тригери

2.4 Типові вибірки. Представлення

2.5 Індекси

2.6 Типові оператори модифікації даних

Висновки з розділу 2

ВИСНОВКИ

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ



ВСТУП

Актуальність роботи полягає у створенні бази даних, для того щоб лікарі працюючи в різних лікарнях могли переглядати дані про пацієнта, історію хвороби та прописані ліки. Для отримання даних про пацієнта необхідні прізвище ім'я та дату народження, якщо є кілька пацієнтів з однаковими такими даними можна використати також місце проживання, або його id в цій базі даних. Також в цій базі даних буде зберігатись інформація про лікаря який проводить лікування та лікарню де заходиться хворий.

Мета курсової роботи - розробка бази даних для зберігання інформації про хворих та їх лікування.

Основні завдання курсової роботи:

- Закріплення та поглиблення знань з предмету «Системи баз даних» набутих в ході лекцій та практичних занять.

- Створення моделі бази даних.

- Реалізація бази даних в системі керування базами даних.

Предметною областю даної курсової роботи є розробка бази даних для зберігання даних про пацієнтів лікарів та поведені операції.

Методологія виконання курсової роботи розділена на 3 етапи:

1. Концептуальне проектування

2. Логічне

3. Фізичне проектування

Виконана робота складається з двох частин. У першій частині під назвою «Моделювання та проектування бази даних» описуються типові бізнес-процеси, наводиться специфікація елементів даних, діаграма «сутність-зв'язок» та діаграма класів. У другій під назвою «Створення та використання об'єктів бази даних» представлений опис створених таблиць, тригерів, процедур та представлень, перелік створених індексів. Наводяться скрипти виконання типових запитів для перегляду та модифікації даних.



ІНДИВІДУАЛЬНЕ ЗАВДАННЯ НА КУРСОВУ РОБОТУ

Розробка бази даних для зберігання інформації про пацієнтів, лікарів та проведені операції.

База даних повинна зберігати інформацію про пацієнтів, лікарів, хворобу пацієнта та лікарню в якій знаходиться хворий.

Об'єкт пацієнта містить П.І.Б, дату народження, місце проживання, стать, id пацієнта, id лікарні в якій хворий знаходиться.

Об'єкт лікаря містить П.І.Б, посаду, id, id лікарні де він працює.

Об'єкт лікарня містить назву, населений пункт в якому знаходиться, id.

Об'єкт медична картка пацієнта містить id діагнозу, id пацієнта, дата звернення до лікарні, діагноз, лікування, результат.

База даних має містити необхідні представлення для полегшення роботи з даними.

В базі повинна бути максимальна кількість можливих запитів які організовані за допомогою тригерів, щоб користувачу не довелось створювати власні запити, що займає багато часу та збільшує імовірність виникання помилок.

За допомогою цієї системи можна дізнатись інформацію про пацієнта, його історію хвороб, лікаря який проводив лікування та про лікарню в якій це все відбувалось.



АНОТАЦІЯ

Курсова робота з навчальної дисципліни «Системи баз даних» є частиною циклу нормативних дисциплін ООП бакалавра з напряму підготовки 6.050101 «Комп'ютерні науки»

Загальний обсяг курсової роботи складає 1 кредит (ЕКТС), 30 годин. Період проведення курсової роботи в 5 семестрі 2018/2019 навчальних років.

Курсову роботу виконав Коцюба Євген Васильович, студент 3 курсу, групи БС-61, кафедри біомедичної кібернетики, факультету біомедичної інженерії НТУУ «КПІ ім. Ігоря Сікорського».

Тема курсової роботи: розробка бази даних для зберігання інформації про хворих.

Варіант №10.

Питання, розглянуті в курсовій роботі: створення інформаційно-логічної моделі даних, проектування фізичної моделі бази даних, розробка бази даних, проектування запитів.

Отримані результати курсової роботи: було отримано навички створення діаграм концептуального та логічного етапів проектування, створення таблиць, створення запитів для отримання необхідних даних, змінення даних, створення представлень, використання індексів для підвищення продуктивності виконання запитів. Створена база даних, що описує предметну область. Наведені приклади її використання для вирішення поставлених задач.

Структура і обсяг роботи: курсова робота складається із вступу, опису завдання, двох розділів, висновків, списку використаної літератури із 6 джерел. Загальний обсяг курсової роботи становить 30 сторінок, ілюстрацій - 2, таблиць - 3.



АННОТАЦИЯ

Курсовая работа по дисциплине «Системы баз данных» является частью цикла нормативных дисциплин ООП бакалавра по направлению подготовки 6.050101 «Компьютерные науки»

Общий объем курсовой работы составляет 1 кредит (ЕКТС), 30 часов. Период проведения курсовой работы в 5 семестре 2018/2019 учебного года.

Курсовую работу выполнил Коцюба Евгений Васильевич, студент 3 курса, группы БС-61, кафедры биомедицинской кибернетики, факультета биомедицинской инженерии НТУУ «КПИ им. Игоря Сикорского ».

Тема курсовой работы: разработка базы данных для хранения информации о больных.

Вариант №10.

Вопросы, рассмотренные в курсовой работе: создание информационно-логической модели данных, проектирования физической модели базы данных, разработка базы данных, проектирование запросов.

Полученные результаты курсовой работы: было получено навыки создания диаграмм концептуального и логического этапов проектирования, создания таблиц, создания запросов для получения необходимых данных, изменение данных, создания представлений, использование индексов для повышения производительности выполнения запросов. Созданная база данных, описывающая предметную область. Приведенные примеры ее использования для решения поставленных задач.

Структура и объем работы: курсовая работа состоит из введения, описания задачи, двух глав, заключения, списка использованной литературы из 6 источников. Общий объем курсовой работы составляет 30 страниц, иллюстраций - 2, таблиц - 3.



ANNOTATION

Course work in the discipline "Database Systems" is part of the cycle of normative disciplines of the Bachelor of Industrial Education in the direction of training 6.050101 "Computer Science"

The total amount of coursework is 1 credit (ECTS), 30 hours. The period of the course work in the 5 semester of the 2018/2019 school year.

Course work was performed by Evgeny V. Kotsyuba, a 3rd year student, BS-61 group, Department of Biomedical Cybernetics, Faculty of Biomedical Engineering, NTUU “KPI them. Igor Sikorsky.

Theme of the course work: the development of a database for storing information about patients.

Option number 10.

Issues considered in the course work: the creation of an information-logical data model, the design of a physical database model, database development, query design.

The results of the course work: skills of creating diagrams of conceptual and logical design stages, creating tables, creating queries to obtain the necessary data, changing data, creating views, using indexes to improve query performance were obtained. Created a database that describes the subject area. Examples of its use for solving problems.

Structure and scope of work: course work consists of introduction, description of the problem, two chapters, conclusion, list of references from 6 sources. The total amount of course work is 30 pages, illustrations - 2, tables - 3.



СПИСОК СКОРОЧЕНЬ

БД - база даних

ПІБ - прізвище, ім'я, по-батькові

ID - ідентифікатор

Рис. - рисунок

СУБД - система управління базами даних

PK - primary key (первинний ключ)

FK - foreign key (зовнішній ключ)

NN - not null (не нульовий)



I. МОДЕЛЮВАННЯ ТА ПРОЕКТУВАННЯ БАЗИ ДАНИХ

1.1 Постановка задачі

Задача - розробити базу даних для зберігання інформації про пацієнтів та історію їх хвороб.

При розробці бази даних необхідно досягнути нижче зазначених цілей:

- задоволення особистих потреб чи потреб організації в періодичному чи регулярному одержанні інформації;

- усунення чи мінімізація дублювання даних;

- забезпечення групам користувачів швидкого доступу до окремих інформаційних елементів бази даних відповідно до їхніх прав і потреб;

- забезпечення можливості наступного розширення бази даних для задоволення постійно зростаючих потреб організації;

- підтримка цілісності бази даних.

Для побудови вказаної бази даних буде використано MySQL, для проектування - MS Visio.

1.2 Бізнес процеси та елементи даних

1.2.1 Перелік бізнес-процесів

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

Бізнес-процес - це відображення суб'єктивного бачення потоку робіт у вигляді формальної моделі, що складається з взаємопов'язаних операцій.

Коментарі:

1. Створена БД є тільки основою програмного додатку вона не може виконувати певну частину завдань. Таких як, можливість розрізняти користувачів та надавати їм необхідні права доступу та можливості.

2. Ця база даних повинна використовуватись насамперед лікарями для отримання інформації про пацієнтів.

3. База даних повинна містити всю інформацію про лікарів, пацієнтів, хвороби пацієнтів та назви лікарень.

4. База даних передбачає збереження поточних даних до архіву, де вони можуть зберігатись довгий час та накопичуватись.

Перелік бізнес-процесів наведений в таблиці табл. №1.

Таблиця 1. Перелік бізнес-процесів

Назва	Опис
Користувач реєструє пацієнта	Користувач заповнює екранну форму з інформацією про пацієнта
Користувач реєструє лікаря	Користувач заповнює екранну форму з інформацією про лікаря
Користувач реєструє відомості про лікарню	Користувач заповнює екранну форму з інформацією про лікарню
Користувач реєструє відомості про медичну карту	Користувач заповнює екранну форму з інформацією про медичну карту
Користувач виводить інформацію про лікаря та лкарню в якій він працює	Користувач знаходить інформацію про лікаря та лкарню в якій він працює
Користувач виводить інформацію про пацієнта та історію його хвороб	Користувач знаходить інформацію про пацієнта, та історію його хвороб.

1.2.2 Специфікація елементів даних

Специфікація елементів даних - опис сутностей, визначених у сутностях атрибутів, їх тип (текстовий, числовий, дата та ін.) та можливі обмеження (унікальність, не нульове значення).

Специфікація елементів даних наведена в таблиці табл. №2.



Таблиця 2. Специфікація елементів даних

Сутність	Елементи даних	Атрибут	Опис	Тип	Обмеження	Ключ
Пацієнт	Patient	p_id	ID пацієнта	INT(10)	NN, UQ	PK
		p_full_name	П.І.Б пацієнта	VARCHAR(80)	NN
		p_birth_dаte	Дата нарождення пацієнта	DATE	NN
		p_residence	Місце проживання	VARCHAR(80)	NN
		p_gender	Cтать пацієнта	VARCHAR(1)	NN
		h_id	ID лікарні в якій хворий знаходиться	INT(10)	NN
Лікар	Doctor	d_id	ID лікаря	INT(10)	NN,UQ	PK
		d_full_name	П.І.Б лікаря	VARCHAR(80)	NN
		d_position	Посада	VARCHAR(60)	NN
		h_id	ID лікарні в якій працює	INT(10)	NN
Лікарня	Hospital	h_id	ID лікарні	INT(10)	NN,UQ	PK
		h_name	Назва лікарні	VARCHAR(60)	NN
		h_residence	Населений пункт	VARCHAR(80)	NN
Медична карта	Medical_card	d_id	ID діагнозу	INT(10)	NN,UQ	PK
		doc_id	ID лікуючого лікаря	INT(10)	NN
		p_id	ID пацієнта якому вона належить	INT(10)	NN
		diagnosis	Діагноз	VARCHAR(100)	NN
		call_date	Дата звернення до лікарні	DATE	NN
		cure	Лікування	VARCHAR(200)	NN
		cure_ result	Результат	VARCHAR(60)	NN



1.3 Залежності елементів даних

1.3.1 Функціональні залежності

Функціональна залежність (далі часто ФЗ) -- концепція, що лежить в основі багатьох питань, пов'язаних з реляційними базами даних, включаючи, зокрема, їхнє проектування. Математично являє собою бінарне відношення між множинами атрибутів даного відношення і є, по суті, зв'язком типу «один-до-багатьох». ФЗ забезпечує основу для наукового підходу до розв'язання деяких проблем, оскільки володіє багатим набором цікавих формальних властивостей. Поняття функціональної залежності визначається з розділенням функціональних залежностей на виконувані в деяких окремих випадках і виконувані завжди. ФЗ є обмеженнями цілісності і визначають семантику даних, що зберігаються. При кожному оновленні СКБД повинна перевіряти їхнє дотримання. Значить, наявність великої кількості ФЗ небажане, інакше це призводить до уповільнення роботи. Для спрощення задачі необхідно скоротити набір ФЗ до мінімально необхідного.

Функціональні залежності наводяться в таблиці табл. №3.

1.3.2 Багатозначні залежності

В теорії баз даних, багатозначна залежність -- повне обмеження між двома множинами атрибутів у відношенні. На відміну від функціональної залежності, багатозначна залежність вимагає наявність певних кортежів у відношенні. Отже, багатозначна залежність це особливий випадок кортеж-твірної залежності. Один атрибут таблиці багатозначно визначає інший атрибут тієї ж таблиці, якщо для кожного значення першого атрибута існує множина відповідних значень іншого атрибута. Наприклад, один пацієнт лікувався в багатьох лікарнях.



Таблиця 3. Функціональні залежності

Таблиця	Детермінант	Залежні атрибути	Словесне формулювання
Patient	p_id	p_full_name, p_birth_date, p_residence, p_gender, h_id	ID пацієнта визначає його П.І.Б, дату народження, місце проживання, стать та id лікарні в якій він знаходиться.
Doctor	d_id	d_full_name, d_position, h_id	ID лікаря визначає його П.І.Б, посаду та id лікарні в якій він працює
Hospital	h_id	h_name, h_residence	ID лікарні визначає її назву, та населений пункт в якому вона знаходиться.
Medical_card	d_id	doc_id, p_id, diagnosis, call_date, cure, cure_ result	ID діагнозу визначає id лікуючого лікаря, id пацієнта з цим діагнозом, діагноз, дату звернення до лікарні, лікування, результат лікування.

1.4 Діаграми

1.4.1 Діаграма "Сутність-Зв'язок"

Проектування бази даних - це ітераційний, багатоетапний процес прийняття аргументованих рішень під час аналізу інформаційної моделі предметної області, вимог до даних з боку прикладних програмістів і користувачів, синтезу логічних і фізичних структур даних, аналізу та обґрунтування вибору програмних та апаратних засобів.

Модель «сутність-зв'язок»-- модель даних, яка дозволяє описувати концептуальні схеми за допомогою узагальнених конструкцій блоків. Існує ряд моделей для представлення знань, але одним з найзручніших інструментів уніфікованого представлення даних, незалежного від програмного забезпечення що його реалізує, є модель «сутність-зв'язок». Важливим є той факт, що з моделі «сутність-зв'язок» можуть бути породжені всі існуючі моделі даних (ієрархічна, мережева, реляційна, об'єктна), тому вона є найзагальнішою. Модель сутність-зв'язок є результатом систематичного процесу, який описує та визначає деяку предметну область. Вона не визначає сам процес, а лише візуалізує його. Дані представлені у вигляді компонентів (сутностей), які пов'язані між собою певними зв'язками, які виражають залежності і вимоги між ними, такі як: одна будівля може бути розділена на нуль або більше квартир, але одна квартира може бути розташована лише в одній будівлі. Сутності можуть мати різні властивості (атрибути), які характеризують їх.

На рис. 1 представлена діаграма спроектованої бази даних для інформаційного забезпечення додатку для збереження інформації про хворих.

база таблиця вибірка індекс

Рис. 1. Діаграма "Сутність-Зв'язок"

1.4.2 Діаграма класів проектування

Діаграма класів-- статичне представлення структури моделі. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів, також, може містити позначення для пакетів та може містити позначення для вкладених пакетів.

Діаграма класів служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. На цій діаграмі показують класи, інтерфейси, об'єкти й кооперації, а також їхні відносини. Дана діаграма має велике значення у проектуванні бази даних та подальшій її розробці.

Клас у мові UML служить для позначення множини об'єктів, що мають однакову структуру, поводження і відносини з об'єктами з інших класів. Графічно клас зображується у вигляді прямокутника, що додатково може бути розділений горизонтальними лініями на розділи або секції. У цих розділах можуть вказуватися ім'я класу, атрибути і операції.

На рис. 2 представлена діаграма класів, на якій показані такі класи, як Пацієнт, Лікар, Лікарня, Медична карта їх зміст та відношення один до одного.



Рис. 2. Діаграма класів проектування

Висновки з розділу 1

Було спроектовано базу даних за темою «Розробка бази даних для зберігання даних про хворих». Для цього, було визначено бізнес-процеси, які є обов'язковими для створення бази даних. Була визначена структура бази даних, потім встановлено зв'язки між елементами, нормалізовано та визначено функціональні і багатозначні залежності. Також було побудовано дві діаграми : діаграму типу «Сутність - Зв'язок» та діаграму класів, на яких продемонстровані, сутності, зв'язки, ключові поля та всі елементи БД.



ІІ. СТВОРЕННЯ ТА ВИКОРИСТАННЯ ОБ'ЄКТІВ БАЗИ ДАНИХ

2.1 Таблиці

Таблиця - це набір елементів даних (значень), які організовані з використанням моделі вертикальних стовпчиків (з різними іменами) і горизонтальних рядків. Таблиця має визначену кількість стовпчиків, в той час як кількість рядків може різнитися в різні моменти. Кожен рядок ідентифікується особливим набором колонок який називається потенційним ключем.

Таблиці складають основу бази даних - саме в них зберігаються всі дані. Перед усім, повинна бути спланована структура кожної таблиці. При плануванні таблиць необхідно уникати повторення колонок в різних таблицях, тільки якщо вони не слугують для визначення зв'язків між ними.

Таблиця складається з записів (рядків), кожний з яких описує одну сутність. Кожна колонка таблиці - це поле. Поле містить однотипну інформацію, яка визначає тип даних. Тип даних визначає вид і межі допустимих значень, які можуть бути введені в поле, а також об'єм пам'яті, який виділяється для цього поля, що важливо при проектуванні великих БД.

Нормалізація - покроковий процес розбиття одного відношення відповідно до алгоритму нормалізації на декілька відношень на базі функціональних залежностей. Одна з головних задач при розробці реляційної БД - об'єднання в одному відношенні тих атрибутів, які зв'язані між собою (між якими є функціональні залежності). Нормалізація являє собою поетапний процес заміни сукупності відношень іншою сукупністю (схемою), в якій відношення мають просту і регулярну структуру. Результатом нормалізації є логічна модель БД.

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

У базі даних для зберігання інформації про хворих, створюємо наступні таблиці:

Таблиця Patient:

- p_id - id пацієнта

- p_full_name - П.І.Б пацієнта

- p_birth_date - дата народження

- p_residense - місце проживання пацієнта

- p_gender - стать пацієнта

- h_id - id лікарні в якій знаходиться хворий

Таблиця Doctor:

- d_id - id діагнозу

- doc_id - id лікаря

- d_full_name - П.І.Б лікаря

- d_position - посада лікаря

- h_id - id лікарні, в якій працює лікар

Таблиця Hospital:

- h_id - id лікарні

- h_name - назва лікарні

- h_residence - населений пункт, в якому знаходиться лікарня

Таблиця Medical_card:

- d_id - id діагнозу

- doc_id - id лікаря що лікує хворого

- p_id - id пацієнта якому належить картка

- diagnosis - діагноз

- call_date - дата звернення до лікарні

- cure - лікування

- cure_result - результат лікування



2.2 Обмеження цілісності

Обмеження цілісності -- це правила, які обмежують усі можливі стани бази даних, а також переходи з одного стану в інший. Таким чином, обмеження цілісності визначають множину «допустимих» станів і переходів між ними. База даних перебуває в цілісному стані, якщо вона відповідає всім визначеним для неї вимогам цілісності.

Цілісність досягається забезпеченням відповідності даних певним додатковим обмеженням, крім тих, які накладаються схемою бази на структуру даних та їхні типи.

Поняття обмеження використовується в багатьох операторах визначення даних. Є декілька видів обмежень цілісності даних.

Доменна цілісність забезпечується:

- типами даних

- забороною порожніх значень

- тригерами

При розробці бази даних було використано такі обмеження цілісності даних, як Primary Key, Not null, Unique.

2.3 Тригери

Тригер (англ. trigger) -- це збережена процедура особливого типу, яку користувач не викликає явно, а використання якої обумовлено настанням визначеної події (дії) у реляційній базі даниx. Види тригерів:

1) за типом події:

- INSERT

- UPDATE

- DELETE

2) час спрацьовування:

- BEFORE

- AFTER

3) за об'єктом БД:

- для таблиці на рівні таблиці

- для таблиці на рівні рядка

- для уявлення view

- для всієї БД

4) за транзакціями:

- в тій же транзакції

- автономна транзакція

Тригери використовуються для перевірки складних обмежень цілісності, автоматизації обробки даних, аудиті дій користувачів та для встановлення значень за умовчуванням для деяких рядків таблиці.

1. Тригер «SavePatient» - при спробі видалення рядка з таблиці «Пацієнт» якого не вилікували, виведеться повідомлення «Unable to delete»

create trigger SavePatient

before delete on Patient

for each row

begin

select raise_application_error(200000,"Unable to delete")

where Medical_card.cure_result!="Вилікувано";

end

2. Тригер «CurePatients» - коли видаляють пацієнта якого вже вилікували, дані про нього заносяться в архів.

create trigger CurePatients

before delete on Patient

for each row

begin

insert into Cure_patients

values (p_id, p_full_name, p_residence, p_gender, diagnosis, cure);

end

3. Тригер «TodaysDate» - при додаванні запису в табличку «Медична карта», автоматично вставляє коректну дату в поле «Дата зверненя до лікарні».

create trigger TodaysDate

after insert on Medical_card

begin

update Medical_card

set call_date=date()

where _rovid_=last_insert_rowid();

end

2.4 Типові вибірки. Представлення

Представлення - це збережений результатний набір запиту. Він доступний як віртуальна таблиця, що складається з результатів запиту. На відміну від звичайних таблиць в реляційній БД, представлення не є частиною схеми даних: це динамічна, віртуальна таблиця що є результатом обробки даних з бази. Зміна даних в таблицях бази даних змінює їх у відповідних представленнях.

При цьому результати виконання запиту подаються в зручному вигляді -- у формі таблиці. запит можна будувати з використанням тимчасової таблиці, створеної за допомогою іншого запиту.

1. «doctors_in_hospital» - показує назву лікарні та id, П.І.Б і посади лікарів які в ній працюють.

create view doctors_in_hospital as

select h_name, d_id, d_full_name, d_position

from Doctor inner join Hospital on h_id

order by h_name

2. «sick_patients» - показує П.І.Б, діагноз та дату звернення до лікарні хворих пацієнтів в центральній лікарні Львова.

create view sick_patients as

select p_full_name, diagnosis, call_date

from Patient inner join Medical_card on Patient.p_id=Medical_card.p_id

where cure_result!="Вилікуваний"

and h_id=(select h_id

from Hospital

where h_name=="Центральна міська лікарня міста Львів")

3. «n_y_present» - показує П.І.Б та діагнози пацієнтів які прибули в лікарню першого січня 2019р.

create view n_y_present as

select p_full_name, diagnosis

from Patient inner join Medical_card on Patient.p_id=Medical_card.p_id

where call_date=="2019-01-01"

4. «p_diagnosis» - показує П.І.Б і посади лікарів які в працюють в центральній лікарні Львова.

create view doctors_list as

select d_full_name, d_position

from Doctor inner join Hospital on Doctor.h_id=Hospital.h_id

where h_name="Центральна міська лікарня міста Львів"

2.5 Індекси

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

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

У БД вже створено кілька індексів які представлені унікальними ключами.

1. Індекс «position» для атрибута посада в таблиці Doctor.

create index position on Doctor(d_position)

2. Індекс «residens» для атрибута місце проживання в таблиці Patient.

create index residence on Patient(p_residence)

2.6 Типові оператори модифікації даних

INSERT -- оператор мови SQL, котрий додає рядки в таблицю або view. В реляційній СКБД можна визначити два варіанти оператора INSERT.

Однорядковий оператор INSERT дозволяє додавати в таблицю один новий рядок. Він широко використовується в повсякденних аплікаціях, наприклад програмах введення даних.

Багаторядковий оператор INSERT забезпечує витягування даних з однієї частини бази даних, їх трансформацію і додавання в іншу частину. Використовується зазвичай при пакетній обробці і створенні нових даних.

UPDATE -- оператор мови SQL, що дозволяє оновити значення в заданих стовпцях таблиці. Даний оператор не додає нові записи, а замінює існуючі дані на нові. Етапи виконання змiнення даних: обробка оператора WHERE (за наявності) та другий етап : заміна значень стовпців вибраної таблиці.

DELETE -- у мовах, подібних SQL, DML-операція видалення записів з таблиці. Критерій відбору записів для видалення визначається виразом where. У разі, якщо критерій відбору не визначений, виконується видалення всіх записів.

1. Реєстрація даних про нового пацієнта

insert into Patient(p_id, p_full_name, p_birth_dаte, p_residence, p_gender, hospital_id)

values(125648,"Коцюба Євген Васильович",1999-03-08,"м.Львів Україна","М",1023);

2. Зміна поля результат лікування в пацієнта

update Medical_card

set cure_result="Вилікувано"

where d_id=1234

3. Видалення відомостей про лікарів Жидачівської лікарні

delete from Doctor

where h_id=(select h_id

from Hospital

where h_recidens="м.Жидачів Львівська обл. Україна")

4. Пацієнтам із запаленням легень назначити Володимира Івановича Федука лікарем

update Medical_card

set doc_id=(select d_id

from Doctor

where d_full_name="Федук Володимир Іванович")

where diagnosis="Запалення легень"

Висновки з розділу 2

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

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

Якщо структури таблиць відповідають поставленим вимогам, то можна вводити всі дані.

Під час розробки бази даних було створено 4 таблиці, у кожній з таблиць містяться атрибути, одним з яких первинний ключ. Для реалізацій бізнес-процесів було створено тригери. Також здійснено реалізацію найтиповіших вибірок та створено представлення. Для налаштування запитів, створено індекси. Таблиці були заповнені даними, виконано запити та створено представлення. Крім цього було створено кілька запитів з типовими операторами модифікації даних, щоб полегшити модифікацію таблиць.



ВИСНОВКИ

В процесі виконання курсової роботи з розробки бази даних інформаційного забезпечення додатку для збереження інформації про хворих, було реалізовано базу даних, у якій ведеться облік пацієнтів, лікарів, інформація про хвороби пацієнтів та інформація про лікарні.

Результати:

· Створено 4 таблиць, реалізовано зв'язки між ними.

· Виконано нормалізацію.

· Побудовано 2 діаграми: ERD-діаграма, що містить 4 сутності, UML-діаграма, на якій відображені об'єкти бази даних.

За допомогою створеної бази даних лікарі можуть отримати доступ до інформації про пацієнтів, а пацієнти можуть переглянути свою медичну книгу. Використання цієї БД може спростити процедуру збереження та отримання потрібної інформації.

В ході виконання завдань курсової роботи, було закріплено навички проектування бази даних, визначення функціональних та багатозначних залежностей, нормалізації БД, створення таблиць, запитів, представлень, тригерів, індексів та використання типових операторів модифікації даних.

Підсумки роботи над курсовим проектом:

- Отримано та закріплено навики з дисципліни «Системи баз даних»

- Отримано результати з розробки інформаційно - логічної (концептуальної) моделі бази, конструювання структури об'єктів, їх створення, тестування.

- Проведено реалізацію в системі керування базами даних MySQL.



СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Електронний рекурс: «Інструкція до моделювання даних» посилання: https://its.utexas.edu/redirect/windows/database/datamodeling/index.html

2. І.О.Завадський, Основи бази даних 2011.

3. Електронний рекурс: «qaru» посилання: http://qaru.site/questions/108199/how-to-get-last-record-from-sqlite

4. Бен Форта, «SQL за 10 минут» 2014, Вильямс 2014.

5. Рік Ф. Ленц, The SQL Guide to SQLite Paperback - 2009

6. Кузнецов М. Самоучитель MySQL, 2006.

Размещено на Allbest.ru