Курсовая БД. Реализация базы данных по автоматизации учёта пациентов в больнице

Название	Реализация базы данных по автоматизации учёта пациентов в больнице
Дата	28.10.2022
Размер	0.56 Mb.
Формат файла
Имя файла	Курсовая БД.docx
Тип	Реферат #760001

Содержание

Введение ................................................................................................................... 5

Описание предметной области ........................................................................... 6
Проектирование логической и физической схемы базы данных по

автоматизации учёта пациентов в больнице ........................................................ 7

Разработка концептуальной схемы ................................................................. 7
Разработка логической схемы базы данных ................................................... 9
Разработка физической схемы базы данных ................................................ 13

Реализация базы данных по автоматизации учёта пациентов в больнице ... 15
1. Скрипты создания базы данных .................................................................... 15
2. Скрипты заполнения таблиц .......................................................................... 17
Построение запросов к базе данных по автоматизации учёта пациентов в

больнице ................................................................................................................ 17

Реализация триггеров и процедур к базе данных по автоматизации учёта

пациентов в больнице ........................................................................................... 18

Разработка процедур ....................................................................................... 18
Разработка триггеров ...................................................................................... 20

Заключение ............................................................................................................ 22

Список литературы ............................................................................................... 23

Приложение А (обязательное) ............................................................................. 24

Приложение Б (обязательное) .............................................................................. 30

Приложение B (обязательное) ............................................................................. 34

Приложение Г (обязательное) .............................................................................. 36

Введение

Ежедневно человек работает с огромным массивом данных. Несистематизированная и неорганизованная информация может осложнить работу, снизить производительность, увеличить сроки работы. Роль распорядителей информации в современном мире чаще всего выполняют базы данных. База данных – это совокупность структур, предназначенных для хранения больших объемов информации и программных модулей, осуществляющих управление данными, их выборку, сортировку и другие функции. Для работы с базами данных существуют системы управления базами данных, или СУБД. Система управления базами данных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных. СУБД позволяет организовывать информацию качественно, эффективно и безопасно в целях дальнейшего поиска, редактирования и использования информации.

Целью данной курсовой работы является проектирование, создание и заполнение базы данных по автоматизации учёта пациентов в больнице. База данных должна быть удобна в использовании и обеспечивать пользователю быстрый доступ к необходимой информации.

Для достижения цели курсовой работы необходимо выполнить следующие задачи:

Провести анализ предметной области;
Разработать концептуальную схему базы данных;
Разработать логическую схему базы данных и нормализовать ее;
Разработать физическую схему базы данных;
Реализовать базу данных в конкретной СУБД (MySQL);
Создать запросы, триггеры и процедуры.

1 Описание предметной области

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

На пациента при поступлении в больницу заводится медицинская карта. В карту автоматически заносятся данные о том какое заболевание у человека, кто был врачом, направившим пациента на лечение и дату первичного осмотра. Также карта хранит в себе уникальный номер пациента, номер палаты, которая относится к определенному отделению, а также дату поступления в больницу. Кроме того, в медицинской карте больного указываются определенные назначения, необходимые для лечения, которые выписываются лечащем врачом пациента. В назначении указываются дата назначения, время назначения, лекарства например фенибут, и процедуры в зависимости от определенного заболевания, например МРТ или массаж, а также уникальный номер карты и кто является лечащем врачом. Любой пациент при поступлении на лечение указывает ФИО, мобильный телефон, паспортные данные, дату рождения, указывается группа крови, например 1+, а также указывается его пол.

Любой врач занимает определенную должность в больнице. Должность -обязанности по работе; полномочия, установленные должностной инструкцией, например главный врач. Также каждый врач закреплен за определенным отделением, например хирургия или неврология. В каждом отделении лечат определенные заболевания. По завершению лечения больного выписывают из больницы, указывая дату выписки в медицинской карте.

2 Проектирование логической и физической схемы базы данных по

автоматизации учёта пациентов в больнице

2.1 Разработка концептуальной схемы

Концептуальное проектирование начинается с анализа предметной области, включает анализ концептуальных требований и информационных потребностей, выявление информационных объектов и связей между ними, построение концептуальной модели данных. Главными элементами концептуальной модели данных являются объекты и отношения.

Объекты представляют собой любой конкретный (реальный) объект в рассматриваемой области. В каждый момент времени они характеризуются определенным состоянием, которое описывается набором свойств и отношений или связей с другими объектами.

Каждый объект предметной области характеризуется некоторым наборов атрибутов, отображающим свойства объекта. Атрибуты используются для определения того, какая информация должна быть собрана об объекте.

Концептуальная модель служит, средством общения между различными пользователями и поэтому разрабатывается без учета особенностей физического представления данных. Она отображает связи, атрибуты, и отношения проектируемой базы данных.

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

В нашем случае концептуальная модель будет представлять следующие отношения:

Лекарство с атрибутами: Код лекарства, название;
Назначение с атрибутами: Код назначения;
Врач с атрибутами: Код врача, ФИО;
Должность с атрибутами: Код должности, название;
Процедура с атрибутами: Код процедуры, название;
Карта с атрибутами: Код карты, дата осмотра, дата поступления, дата выписки;
Пациент с атрибутами: Код пациента, ФИО, номер телефона, паспортные данные, дата рождения, группа крови, пол;
Палата с атрибутами: Код палаты, места; 9) Отделение с атрибутами: код отделения, название; 10) Болезнь с атрибутами: код болезни, название.

После выделения необходимых отношений можно выделить связи между ними.

У одного пациента, может быть, множество карт и у одной карты может быть множество направлений. Одна болезнь может содержаться во множестве карт, и одна палата может содержаться во множестве карт. Одно отделение может специализироваться на множестве болезней и одно отделение может иметь множество палат. Один врач направляет пациентов во множество карт. В одном отделении работает множество врачей, и одна должность может принадлежать множеству врачей. У одного врача может быть множество назначений и у одного лекарства, так же, как и у одной процедуры может быть множество назначений. Множество болезней можно лечить множеством лекарств и множеством процедур.

Указанные типы связей: 1) M:N – многие ко многим; 2) 1:M – один ко многим.

На основании выделенных отношений и связей между ними была построена концептуальная схема базы данных, представленная на рисунке 1.

Рисунок 1 – Концептуальная схема базы данных

2.2 Разработка логической схемы базы данных

Логическая модель представляет собой модель базы данных, которая не привязана к конкретной СУБД. В ней выделяют основные объекты БД и определяют связи между этими объектами.

На этапе логического проектирования разрабатывается логическая структура БД. Для реляционной модели существуют формальные правила, которые позволяют преобразовать инфологическую модель в виде ERдиаграммы в логическую схему базы данных.

Некоторые правила реляционной модели данных:

Каждая строка данных в таблице идентифицируется уникальным “ключом”, который называется первичным ключом.
В проекте базы данных, которая создана с учетом правил реляционной модели данных, каждый кусочек информации хранится только в одном месте. Это позволяет устранить необходимость работы с данными в нескольких местах.
Необходимо определить, какой тип данных будет сохраняться в столбце. Также можно установить другие ограничения ввода, например, ограничить длину или принудительно указать на уникальность значения записей в данном столбце.

Для проектирования логической схемы была выбрана нотация IDEF1X.

На логической схеме также выделены связанные сущности, к которым относятся:

Лекарство_болезнь с атрибутами: код лекарство, код болезнь;
Процедура_болезнь с атрибутами: код процедура, код болезнь.

Все вышеперечисленные таблицы реализуют связь многие ко многим между сущностями, а именно:

Таблица «Лекарство_болезнь» связывает сущности «Лекарство» и «Болезнь»;
Таблица «Процедура_болезнь» связывает сущности

«Процедура» и «Болезнь».

При проектировании таблиц и определении связей между ними используют способ нормализации. Этот способ позволяет разделить исходную, сплошную таблицу на ряд элементарных таблиц, между которыми устанавливаются связи, что, в свою очередь, предназначено для исключения избыточное дублирования данных, которое является причиной аномалий, возникших при добавлении, редактировании и удалении кортежей (строк таблицы).

Существует пять основных нормальных форм, однако также выделяют дополнительные нормальные форм. Первое требование всех нормальных форм заключается в том, чтобы таблица находилась в предыдущей нормальной форме. Список нормальных форм (NF):

Первая нормальная форма (1NF) предполагает, что в таблице не должно быть дублирующих строк, в каждой ячейке таблицы хранится атомарное значение (одно не составное значение), в столбце хранятся данные одного типа и отсутствуют массивы и списки в любом виде.
Вторая нормальная форма (2NF) предполагает, что таблица имеет ключ и все неключевые столбцы зависят от полного ключа (в случае если он составной).
Третья нормальная форма (3NF) предполагает, что в таблицах отсутствует транзитивная зависимость. Транзитивная зависимость – это зависимость неключевых столбцов от значений других неключевых столбцов.
Начальная форма Бойса-Кодда (NFBK) предполагает, что в таблицах ключевые атрибуты составного ключа не зависят от неключевых атрибутов.
Четвертая нормальная форма (4NF) предполагает, что в таблицах отсутствуют нетривиальные многозначные зависимости.
Пятая нормальная форма (5NF) предполагает, что в таблице каждая

нетривиальная зависимость соединения определяется потенциальным ключом этой таблицы.

Доменно-ключевая нормальная форма (DKNF) предполагает, что каждое наложенное ограничение на таблицу является логическим следствием ограничений доменов и ограничений ключей, которые накладываются на данную таблицу. Ограничение домена – это ограничение, предписывающее использование для определенного атрибута значений только из некоторого заданного домена (набора значений). Ограничение ключа – это ограничение, утверждающее, что некоторый атрибут или комбинация атрибутов представляет собой потенциальный ключ.

В базе данных по автоматизации учета пациентов больницы необходимо провести нормализацию до третьей нормальной формы (3NF).

Логическая схема проектируемой базы данных представлена на рисунке

2.

Рисунок 2 – Логическая схемы базы данных

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

Для базы данных по автоматизации учета пациентов в больнице можно выделить следующие бизнес-правила:

Номер телефона пациента начинается с 8;
Пол пациента может быть или мужской или женский;
Количество мест в палате не может быть больше 30.

2.3 Разработка физической схемы базы данных

На основе концептуальной и логической схем необходимо построить также физическую схему базы данных.

Этап физического проектирования заключается в определении схемы хранения, т.е. физической структуры БД. Схема хранения зависит от той физической структуры, которую поддерживает выбранная СУБД.

Физическая структура БД, с одной стороны, должна адекватно отражать логическую структуру БД, а с другой стороны, должна обеспечивать эффективное размещение данных и быстрый доступ к ним.

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

В проектируемой базе данных помимо первичных ключей в таблицах присутствуют ещё и внешние ключи.

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

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

В проектируемой таблице рассматриваются следующие типы данных:

INTEGER - целое число в диапазоне от -2147483648 до 2147483647;
VARCHAR(X) - cимвольные данные переменной длины. Под X обозначается количество символов.;
TINYINT() - целое число в диапазоне от -128 до 127;
DATE- дата в формате 'YYYY-MM-DD'. Поддерживается интервал от '1000-01-01' до '9999-12-31'.

Необязательные поля: karta: data_osmotra, data_vip.

Остальные поля во всех таблицах являются обязательными.

Поля с уникальными значениями: telefon и pasport в таблице pacient .

Физическая схема базы данных представлена на рисунке 3.

Рисунок 3 – Физическая схема базы данных

3 Реализация базы данных по автоматизации учёта пациентов в больнице

3.1 Скрипты создания базы данных

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

К примеру, скрипт создания таблицы «Пациент» выглядит следующим образом:

create table if not exists pacient ( id_pacient int not null auto_increment, fio varchar(40) not null, telefon varchar(11) not null unique, pasport varchar(10) not null unique, data_rozhdeniya date not null, gruppa_krovi varchar(2), pol varchar(1) not null, primary key(id_pacient)

);

Для создания таблицы применяется оператор CREATE TABLE с параметром IF NOT EXISTS, который проверяет наличие таблицы в базе данных.

После каждого атрибута стоит надпись «NOT NULL», которая обозначает то, что данный атрибут в таблице не может быть пустым.

После описания атрибута необходимо поставить символ «,». Это позволит скрипту корректно выполнится, а также при помощи него будут перечислены все необходимые атрибуты данной таблицы.

Последняя строка скрипта создания базы данных – PRIMARY KEY.

Данная команда предназначена для установки первичного ключа в таблице.

В нашем случае, для данной таблицы первичным ключом будет являться атрибут id_pacient.

Отдельное внимание при создании таблиц стоит уделить таким параметрам, как:

FOREIGN KEY () – указывается столбец таблицы, который будет представляет внешний ключ;
REFERENCES () – указывается имя связанной таблицы, а затем в скобках имя связанного столбца, на который будет указывать внешний ключ.

Скрипты создания таблиц представлены в приложении А.

3.2 Скрипты заполнения таблиц

4 Построение запросов к базе данных по автоматизации учёта пациентов в больнице

Язык SQL – декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных.

В языке SQL выделяют основным и самым мощным оператором является оператор SELECT – он позволяет выбирать определённые записи по определённым критериям.

В нашей базе данных один из запросов имеет следующий вид:

select fio, telefon, pol, data_rozhdeniya from pacient order by data_rozhdeniya;

Данный запрос выводит ФИО, номер телефона, пол пациента и его дату рождения, а также производит сортировку по дате рождения.

Результат его выполнения показан на рисунке 4.

Рисунок 4 – Результат выполнения запроса

В базе данных также будут рассмотрены следующие запросы:

Запрос, позволяющий подсчитать количество врачей из Кардиологии;
Запрос, позволяющий вывести ФИО врачей из Неврологического отделения;

Все вышеперечисленные запросы, необходимые больнице представлены и рассмотрены в приложении B.

5 Реализация триггеров и процедур к базе данных по автоматизации учёта

пациентов в больнице

4.1 Разработка процедур

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

Особенностью процедур является то, что есть возможность передавать аргументы, (так же как и функциям в других языка) и выводить различные данные в зависимости от аргумента. Также, процедура является сущностью

SQL, которую создают один раз, а затем вызывают, передавая аргументы.

delimiter // create procedure telefon (fio varchar(40)) begin select telefon from pacient where pacient.fio = fio; end;

//

Ключевое слово DELIMITER // позволяет изменить знак разделения.

Для создания процедуры необходимо воспользоваться оператором CREATE PROCEDURE. После этого следует имя данной процедуры, а затем непосредственно тело процедуры.

В круглых скобках после названия процедуры указываются параметры.

В данном случае это переменная fio с типом varchar(40).

Данная конструкция заканчивается оператором END с «;», который гласит об окончании процедуры. Процедура позволяющая найти номер телефона пациента, у которого ФИО, в данной процедуре, Конышев Станислав Алексеевич.

Для вызова процедуры существует оператор CALL. В данном случае он выглядит следующим образом:

call telefon("Конышев Станислав Алексеевич");

При вызове указывается имя процедуры, а также её параметры.

Результат процедуры представлен на рисунке 5

Рисунок 5 – Результат выполнения процедуры

Остальные процедуры рассмотрены в приложении Г.

4.2 Разработка триггеров

Триггеры в SQL создаются и хранятся отдельно до момента их удаления. Триггеры по своей сути представляют обработчики событий. Они выполняются при наступлении какого-либо простого действия в SQL. Такими действиями обычно являются: удаление, вставка и обновление данных.

То есть, триггер — это, по сути, ловушка, которая срабатывает при определенном действии. Триггер позволяет автоматизировать некоторые расчетные рутинные действия.

DELIMITER //

CREATE TRIGGER Phone BEFORE INSERT

ON pacient FOR EACH ROW BEGIN

set @x = LEFT(new.telefon, 1);

IF @x != '8' THEN set NEW.telefon = 'ERROR';

END IF;

END

//

Результат его выполнения показан на рисунке 6.

Рисунок 6 – Результат выполнения триггера

В данном случае этот триггер проверяет, чтобы номер телефона пациента начинался с 8.

Оператор CREATE TRIGGER позволяет создать триггер. Дальше идёт его название, в нашем случае – это Phone.

Ключевое слово BEFORE позволяет проверить условие перед выполнением запроса на добавление.

Строка FOR EACH ROW указывает на то, что триггер будет запускаться для каждой обрабатываемой командой строки.

Затем, при помощи операнда SET переменной @x присваивается

значение первого символа взятого слева и если оно не равно 8, то операндом set в NEW.telefon присваивается значение'ERROR'.

Остальные триггеры рассмотрены в приложении Г.

Заключение

В ходе работы, на основе теоретических знаний мы полностью спроектировали, а также реализовали базу данных.

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

Таким образом, все рассмотренные задачи, были достигнуты, а именно:

Проведен анализ предметной области;
Разработана концептуальная схема базы данных;
Разработана логическая схема базы данных и нормализована;
Разработана физическая схема базы данных;
Реализована база данных в конкретной СУБД (MySQL); 6) Созданы запросы, триггеры и процедуры.

В заключении можно сказать, что реализованная база данных полностью удовлетворяет требованиям, а также позволяет автоматизировать учет пациентов в больнице.

Список литературы

Документация MySQL [Электронный ресурс] – Режим доступа: https://dev.mysql.com/doc/(Дата обращения: 12.06.2022).
Сайт metanit.com [Электронный ресурс] – Режим доступа: https://metanit.com/sql/(Дата обращения: 30.05.2022).
НОУ ИНТУИТ | Базы данных [Электронный ресурс] – Режим доступа: https://intuit.ru/studies/courses/508/364/info(Дата обращения: 30.05.2022).
Сайт info-comp.ru [Электронный ресурс] – Режим доступа: https://infocomp.ru/database-normalization(Дата обращения: 7.06.2022).

Приложение А (обязательное)

Скрипты создания таблиц базы данных

create database if not exists bolnica; use bolnica; create table if not exists pacient ( id_pacient int not null auto_increment, fio varchar(40) not null, telefon varchar(11) not null unique, pasport varchar(10) not null unique, data_rozhdeniya date not null, gruppa_krovi varchar(2), pol varchar(1) not null, primary key(id_pacient)

);

create table if not exists naznachenie ( id_naznachenie int not null auto_increment, id_karta int not null, id_lekarstvo int not null, id_procedura int not null, id_vrach int not null, data_time_naznachenie datetime not null, primary key(id_naznachenie)

);

create table if not exists vrach ( id_vrach int not null auto_increment, fio varchar(40) not null, id_otdelenie int not null, id_dolzhnost int not null, primary key(id_vrach)

);

create table if not exists palata ( id_palata int not null auto_increment, id_otdelenie int not null, mesta tinyint not null, primary key(id_palata)

);

create table if not exists otdelenie ( id_otdelenie int not null auto_increment, nazvanie varchar(40) not null, primary key(id_otdelenie)

);

create table if not exists dolzhnost ( id_dolzhnost int not null auto_increment, nazvanie varchar(40) not null, primary key(id_dolzhnost)

);

create table if not exists bolezn ( id_bolezn int not null auto_increment, id_otdelenie int not null, nazvanie varchar(30) not null, primary key(id_bolezn)

);

create table if not exists karta ( id_karta int not null auto_increment, id_pacient int not null, id_bolezn int not null, id_vrach_napr int not null, id_palata int not null, data_osmotra date null,

data_post date not null, data_vip date, primary key (id_karta)

);

create table if not exists lekarstvo ( id_lekarstvo int not null auto_increment, nazvanie varchar(30) not null, primary key (id_lekarstvo)

);

create table if not exists procedura ( id_procedura int not null auto_increment, nazvanie varchar(30) not null, primary key (id_procedura)

);

create table if not exists lek_bol ( id_lekarstvo int not null, id_bolezn int not null, primary key (id_lekarstvo, id_bolezn)

);

create table if not exists proc_bol ( id_procedura int not null, id_bolezn int not null, primary key (id_procedura, id_bolezn)

);

alter table naznachenie add foreign key (id_karta) references karta(id_karta), add foreign key (id_procedura) references procedura(id_procedura), add foreign key (id_vrach) references vrach(id_vrach), add foreign key (id_lekarstvo) references lekarstvo(id_lekarstvo);

alter table bolezn add foreign key (id_otdelenie) references otdelenie(id_otdelenie);

alter table vrach add foreign key (id_otdelenie) references otdelenie(id_otdelenie), add foreign key (id_dolzhnost) references dolzhnost(id_dolzhnost);

alter table palata add foreign key (id_otdelenie) references otdelenie(id_otdelenie); alter table karta add foreign key (id_pacient) references pacient(id_pacient), add foreign key (id_bolezn) references bolezn(id_bolezn), add foreign key (id_vrach_napr) references vrach(id_vrach), add foreign key (id_palata) references palata(id_palata);

alter table lek_bol add foreign key (id_lekarstvo) references lekarstvo(id_lekarstvo), add foreign key (id_bolezn) references bolezn(id_bolezn);

alter table proc_bol add foreign key (id_procedura) references procedura(id_procedura), add foreign key (id_bolezn) references bolezn(id_bolezn);

Приложение Б (обязательное)

Скрипты заполнения базы данных

insert into pacient values

(1,'Конышев Станислав Алексеевич','89536784565','5416789546','2002-10-20',

'1+', 'm'),

(2,'Удалов Александр Дмитриевич','89543456798','5416765123','2001-07-21',

'1+', 'm'),

(3,'Макогонюк Дмитрий Сергеевич','89533459874','5416987234','2002-05-15',

'4-', 'm'),

(4,'Филатов Алексей Николаевич','89531567634','5416169365','2002-05-23', null, 'm'),

(5,'Афончиков Даниил Степанович','89549873471','5416981243','2002-02-05',

'3+', 'm');

insert into otdelenie values

(1,'Хирургия'),

(2,'Неврология'),

(3,'Кардиология'),

(4,'Урология'),

(5,'Офтальмология');

insert into dolzhnost values

(1,'Главный врач'),

(2,'Заместитель руководителя'),

(3,'Врач специалист'),

(4,'Заведующий лаборатории'),

(5,'Санитар');

insert into vrach values

(1,'Морозов Родион Евгеньевич',1,1),

(2,'Анисимов Лука Пётрович',2,2),

(3,'Поляков Дмитрий Федосеевич',3,3),

(4,'Мясников Ефим Макарович',4,4),

(5,'Кудрявцев Вадим Валентинович',5,5),

(6,'Воробьёв Ростислав Ефимович',3,2),

(7,'Шарапов Аркадий Ярославович',2,3),

(8,'Семёнов Эльдар Федотович',3,3),

(9,'Быков Ермолай Юрьевич',2,4),

(10,'Марков Юрий Вениаминович',5,5);

insert into bolezn values

(1,1,'дифтерия'),

(2,2,'гипертония'),

(3,3,'ларингит'),

(4,4,'псориаз'),

(5,5,'флюороз');

insert into lekarstvo values

(1, 'Парацетамол'),

(2, 'Арбидол'), (3, 'Фенибут'),

(4, 'Ибупрофен'),

(5, 'Пенталгин');

insert into procedura values

(1, 'Массаж'),

(2, 'ЛФК'),

(3, 'УЗИ'),

(4, 'Блокада'),

(5, 'МРТ');

insert into palata values

(1, 1, 10),

(2, 2, 10),

(3, 3, 10),

(4, 4, 10),

(5, 5, 10);

insert into lek_bol values

(1,1),

(2,2),

(3,3),

(4,4),

(5,5);

insert into proc_bol values

(1,1),

(2,2),

(3,3),

(4,4),

(5,5);

insert into karta values

(1,1,1,1,1,'2022-01-20','2022-01-20','2022-02-02'),

(2,2,2,1,2,'2022-02-20','2022-02-20','2022-02-27'),

(3,3,3,3,3,'2022-03-15','2022-03-15','2022-03-25'), (4,4,4,3,4,'2022-03-20','2022-03-20','2022-03-29'),

(5,5,5,5,5,'2022-04-07','2022-04-07','2022-04-21');

insert into naznachenie values (1,1,1,1,6,'2022-01-21 23:59:59'),

(2,2,2,2,7,'2022-01-22 21:59:58'),

(3,3,3,3,8,'2022-01-23 15:59:57'),

(4,4,4,4,9,'2022-01-24 17:59:45'),

(5,5,5,5,10,'2022-01-25 13:59:51');

Приложение B (обязательное)

Реализация запросов к базе данных

Запрос, позволяющий вывести ФИО, номер телефона, пол пациента и его дату рождения, а также произвести сортировку по дате рождения

select fio, telefon, pol, data_rozhdeniya from pacient order by data_rozhdeniya;

Результат его выполнения показан на рисунке 7.

Рисунок 7 – Результат выполнения запроса 1

Вывести ФИО врачей, работающих в Неврологии

select fio, otdelenie.nazvanie as otdeleni from vrach join otdelenie on otdelenie.id_otdelenie = vrach.id_otdelenie

where otdelenie.nazvanie = 'Неврология';

Результат его выполнения показан на рисунке 8.

Рисунок 8 – Результат выполнения запроса 2

Запрос, позволяющий подсчитать количество врачей из Кардиологии select count(id_vrach) as kolvo_vrachey from vrach where id_otdelenie = 3;

Результат его выполнения показан на рисунке 9.

Рисунок 9 – Результат выполнения запроса 3

Приложение Г (обязательное)

Реализация триггеров и процедур

Процедура позволяющая вывести номер телефона пациента с ФИО

(Конышев Станислав Алексеевич)

delimiter // create procedure telefon (fio varchar(40)) begin select telefon from pacient where pacient.fio = fio; end;

//

Результат его выполнения показан на рисунке 10.

Рисунок 10 – Результат выполнения процедуры 1

Процедура позволяющая вывести ФИО и дату рождения пациентов и отсортировать по дате рождения

delimiter // create procedure sort_by_date_r() begin select fio, data_rozhdeniya from pacient order by data_rozhdeniya; end;

//

Результат его выполнения показан на рисунке 11.

Рисунок 11 – Результат выполнения процедуры 2

3) Процедура позволяющая вывести 1 лечащего врача

delimiter // create procedure vrach(id int) begin set @id_karta = (select id_karta from karta where karta.id_pacient = id); select vrach.fio from naznachenie join karta on naznachenie.id_karta = karta.id_karta join vrach on naznachenie.id_vrach = vrach.id_vrach where karta.id_karta =

@id_karta; end;

//

Результат его выполнения показан на рисунке 12.

Рисунок 12 – Результат выполнения процедуры 3

4) Триггер проверяющий, что номер телефона пациента начинается с

8

DELIMITER //

CREATE TRIGGER Phone BEFORE INSERT

ON pacient FOR EACH ROW BEGIN

set @x = LEFT(new.telefon, 1); IF @x != '8' THEN set NEW.telefon = 'ERROR';

END IF;

END

//

Триггер проверяющий пол пациента

DELIMITER //

create trigger pol before insert on pacient for each row begin if new.pol != 'm' and new.pol != 'f' then set new.pol = '0'; end if; end;

//

Триггер проверяющий, чтобы количество мест в палате не было больше 30 DELIMITER //

create trigger palata before insert on palata for each row begin if new.mesta >30 then set new.mesta = '0'; end if; end;

//