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

РЕФЕРАТ

Курсовой проект содержит 2 листа чертежей формата A3, пояснительную записку на 45 листах формата А4, включающую 45 рисунков, 14 таблиц, 7 литературных источников, 2 приложения.

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

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

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



СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• 1. Концептуальное проектирование
• 1.1 Описание предметной области
• 1.1.1Организационная структура студенческой поликлиники
• 1.1.2Организация работы студенческой поликлиники (СП)
• 1.1.3Связи с внешними организациями

1.1.4 Задачи разрабатываемой базы данных

• 1.2 Выделение и описание сущностей базы данных
• 1.2.1 Инфологическое проектирование
• 1.2.2 Определение связей сущностей
• 1.3 Справочник задач.
• 1.4 Построение концептуальной схемы
• 2. Логическое проектирование
• 2.1 Установление дополнительных логических связей
• 2.2 Отображение концептуально-логической модели на реляционную модель
• 2.3 Нормализация отношений
• 2.3.1 Первая нормальная форма
• 2.3.2 Вторая нормальная форма
• 2.3.3 Третья нормальная форма
• 2.3.4Построение итоговой логической модели базы данных
• 3. Физическое проектирование
• 3.1 Описание физической модели
• 3.1 Физическая схема базы данных
• 1.Описание базы данных с помощью средств СУБД
• 2.Описание SQL-запросов и результатов их выполнения
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
• ПРИЛОЖЕНИЕ А
• ПРИЛОЖЕНИЕ Б


ВВЕДЕНИЕ

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

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

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

Целью данной курсовой работы является создание базы данных студенческой поликлиники. Она предназначена для хранения информации о врачах, пациентах, вспомогательной информации о распорядке работы поликлиники (кабинеты, графики работы) и приеме больных, с возможностью внесения данных, выборки и изменения данных, вывода информации в необходимом формате.В качестве СУБД для реализации базы данных была использована настольная СУБД реляционного типа ? MicrosoftSQLServer.

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

1. Анализ предметной области «Студенческая поликлиника»

2. Проектирование БД в исследуемой предметной области

3.Создание запросов на выборку информации из БД.



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

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

Областью деятельности студенческой поликлиникиКГБУЗ «Городская клиническая больница № 10» является осу-ществление лечебных, оздоровительных, профилактических мероприятий, направленных на сохранение и укрепление физического и психического здо-ровья обучающихся, преподавателей и работников университета.

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

1.1.1 Организационная структура студенческой поликлиники

Студенческая поликлиника является структурным подразделени-ем университета.

Студенческая поликлиника имеет в своём распоряжении:

· лечебную базу, включающую дневной стационар;

· лечебные кабинеты;

· диагно-стические кабинеты;

· кабинеты врачей-специалистов;

· медицинское оборудование;

· медицинские из-делия;

· лекарственные средства;

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

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

1.1.2 Организация работы студенческой поликлиники(СП)

1. Работа студенческой поликлиники организуется по сменному графику, обеспечивающему оказание медицинской помощи в течение всего рабочего дня.

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

3. За получением медицинской помощи обучающиеся и работники самостоятельно обращаются в регистратуру студенческой поликлиники. На каждого обратившегося в студенческую поликлинику за медицинской помо-щью заводится медицинская карта амбулаторного больного и другие меди-цинские документы.

4. Обучающиеся университета безвозмездно получают доврачебную медицинскую помощь.

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

6. Безвозмездно для обучающихся осуществляется оздоровление и лечение в условиях дневного стационара студенческой поликлиники. На больного, находящегося в стационаре дневного пребывания, заводится меди-цинская документация с занесением в нее кратких сведений из анамнеза, ис-тории заболевания и проводимого обследования и лечения. Объем медицин-ской помощи при лечении в дневном стационаре включает: лабораторное, диагностическое обследование, медикаментозную терапию. Продолжитель-ность лечения в условиях дневного стационара составляет 7 дней, при необ-ходимости пролонгирование лечения осуществляется по решению врачебной комиссии. Лечебные мероприятия проводятся без отрыва от учебы, а также в период каникул и отпусков.

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

К основным задачам студенческой поликлиники относятся:

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

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

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

Студенческая поликлиника организует и осуществляет:

- амбулаторно-поликлиническую, в том числе, в условиях дневного стационара, консультативно-диагностическую помощь обучающимся, препо-давателям и работникам университета;

- доврачебную и врачебную медицинскую помощь, в соответствии с имеющейся лицензией на медицинскую деятельность;

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

- медицинское сопровождение спортивных соревнований, проводимых на базе университета;

- профилактические, предварительные, периодические медицинские осмотры;

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

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

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

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

- противоэпидемические мероприятия, в том числе вакцинации;

- медицинское сопровождение культурно-массовых мероприятий, про-водимых университетом;

- мониторинг состояния здоровья обучающихся.

1.1.3Связи с внешними организациями

Студенческая поликлиника взаимодействует со сторонними орга-низациями:

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

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

1.1.4 Задачи разрабатываемой базы данных

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

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

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

· хранение информации о врачах поликлиники;

· ведение учета врачей;

- учет загруженности врачей(количество пациентов у врача);

· хранение информации о кабинетах поликлиники;

· хранение информации о пациентах;

· ведение учета медицинских карточек пациентов;

- учет факультета/института;

- дата обращения в студенческую поликлинику;

- учет даты выписки пациента;

- учет прививок и прохождения медицинской комиссии;

· хранение информации о приемах, в том числе диагнозах и лечении;

· обновление и добавление информации о пациентах, врачах;

· анализ информации по различным срезам (пациенты, кабинеты, врачи);

· выдача итоговой информации в виде отчетов.

1.2 Выделение и описание сущностей базы данных

1.2.1Инфологическое проектирование

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

1. «Пациент» - содержит общую информацию о пациенте.

2. «Врач»- содержит общую информацию о врачах.

3. «Должность»- информация о должности врача.

4. «График работы»- информация о графике работы врача.

5. «Кабинеты»- информация о всех кабинетах в студенческой поликлиники.

6. «Прием»- информация о дате первого обращения пациентом в поликлинику, а также о прохождении лечения.

Рассмотрим определение описательных атрибутов сущностей и ключей.

Описание атрибутов сущности «Пациент» приведено в таблице 1. «IDПациента» является ключевым, так как однозначно определяет экземпляр сущности.



Таблица 1 - Атрибуты сущности «Пациент»

Название атрибута	Описание атрибута	Тип значения	Пример
ID Пациента	Уникальный идентификатор	Счетчик	22
Номер карточки	Номер карточки пациента	Число	124366
Ф.И.О.	Фамилия, имя, отчество пациента	Текст	Миронов Виктор Юрьевич
Дата рождения	Дата рожденияпациента	Дата	03.04.1997
Адрес	Адрес места проживания пациента	Текст	г.Хабаровск, ул.Тихоокеанская, д.138, к. 312
Университет	Университет, в котором пациент обучается	Текст	Тихоокеанский государственный университет
Факультет/Институт	Информация о факультете/институте, на котором учиться пациент в данном университете.	Текст	Инженерно-строительный институт
Группа	Группа, в которой пациент обучается	Текст	СУЗ-41
Пол	Пол пациента	Текст	Женский/Мужской
Медицинская комиссия	Информация о прохождении пациентом медицинской комиссии	Логический	Да/Нет
Прививки	Информация о привиках	Текст	Реакция манту

Описание атрибутов сущности «Врач» приведено в таблице 2. «ID Врач» является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 2 - Атрибуты сущности «Врач»

Названиеатрибута	Описание атрибута	Тип значения	Пример
ID Врач	Уникальный идентификатор	Счетчик	55
Ф.И.О.	Ф.И.О. врача	Текст	ШевчукЕлена Владимировна
ID Должность	Уникальный идентификатор	Счетчик	55
Сертификат	Номер сертификата, подтверждающего квалификацию	Символы	0177040004567
Телефон	Номер телефона	Символы	46-17-55
Адрес	Адрес врача	Текст	г. Хабаровск, ул. Волачаевская, д.12, кв.40
Стаж работы	Период работы на определенной должности в годах	Символы	15 л.

Описание атрибутов сущности «Должность» приведено в таблице 3. «ID Должность» является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 3 - Атрибуты сущности «Должность»

Название атрибута	Описание атрибута	Тип значения	Пример
ID Должность	Уникальный идентификатор	Счетчик	55
Название должности	Название должности	Текст	Врач-терапевт
Оклад	Оклад в рублях	Символы	3861

Описание атрибутов сущности «График работы» приведено в таблице 4. «IDГрафика» является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 4 - Атрибуты сущности «График работы»

Название атрибута	Описание атрибута	Тип значения	Пример
ID Графика	Уникальный идентификатор	Счетчик	55
Пн	Время приема/работы в этот день	Текст	13:00-18:00
Вт	Время приема/работы в этот день	Текст	13:00-18:00
Ср	Время приема/работы в этот день	Текст	13:00-18:00
Чт	Время приема/работы в этот день	Текст	13:00-18:00
Пт	Время приема/работы в этот день	Текст	13:00-18:00
Сб	Время приема/работы в этот день	Текст	13:00-18:00
Примечание	Дополнительные сведения	Текст	В отпуске

Описание атрибутов сущности «Кабинеты» приведено в таблице 5. «Номер кабинета» является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 5 - Атрибуты сущности «Кабинеты»

Название атрибута	Описание атрибута	Тип значения	Пример
Номер кабинета	Уникальный идентификатор	Счетчик	15
Ответственный за кабинет	Лицо, отвечающее за пожарную безопасность в кабинете	Текст	Шевчук Елена Викторовна
Внутренний телефон	Номер телефона, находящегося внутри кабинета	Символы	43-09-32

Описание атрибутов сущности «Прием» приведено в таблице 6. «IDприема» является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 6 - Атрибуты сущности «Прием»

Название атрибута	Описание атрибута	Тип значеня	Пример
ID приема	Номер палаты	Счетчик	1
Дата и время	Дата и время обращения	Дата/Время	01.04.2015 15:00
Дата выписки	Дата выписки студенты	Дата	01.04.2015
ID Пациента	Уникальный идентификатор	Счетчик	22
ID Врач	Уникальный идентификатор	Счетчик	55
Номер кабинета	Номер кабинета	Символ	15
Диагноз	Диагноз, который ставит врач пациенту	Текст	Острый ларингит
Лечение	Лекарства и процедуры, прописанные пациенту	Текст	Физиопроцедуры, Граммидин
Примечание	Дополнительные сведения	Текст	Освобождение от физкультуры/Направление в студенческий санаторий-профилакторий



1.2.2 Определение связей сущностей

Определим связи, возникающие между сущностями.

1. «Врач» - «Должность». Одному экземпляру сущности «Должность» соответствует несколько экземпляров сущности «Врач», так как у одной должности может быть несколько врачей. Одному экземпляру сущности «Врач» соответствует определенный экземпляр сущности «Должность», так как у данного врача есть только одна должность. Следовательно, устанавливается связь «один-ко-многим».

Рисунок 1 - Связь «Врач» - «Должность»

2. «Врач» - «График работы». Одному экземпляру сущности «Врач» соответствует один экземпляр сущности «График работы», так как один врач имеет только один график работы. Одному экземпляру сущности «График работы» соответствует один экземпляр сущности «Врач», так как у каждого врача индивидуальный график работы. Следовательно, устанавливается связь «один-к-одному».

3. «Врач» - «Прием». Одному экземпляру сущности «Врач» соответствует несколько экземпляров сущности «Прием», так как один врачпроводит несколько приемов пациентов. Одному экземпляру сущности «Прием» соответствует определенный экземпляр сущности «Врач», так как прием пациента может провести только один врач. Следовательно, устанавливается связь «один - ко - многим».

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

5. «Врач» - «Кабинет». Одному экземпляру сущности «Врач» соответствует один экземпляр сущности «Кабинет», так как каждый врач работает в определенном кабинете. Одному экземпляру сущности «Кабинет» соответствует несколько экземпляров сущности «Врач», так как несколько врачей может значиться в одном кабинете. Следовательно, устанавливается связь «один - ко - многим».

1.3 Справочник задач

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

Таблица 7 - Справочник задач

№	Наименование задачи	Используемые сущности	Частота решения
1	Формирование данных о пациентах, которые выписаны	Прием, Пациент	1 раз в месяц
2	Формирование списка о занятости врача	Врач, Прием, Пациент	4раза в месяц
3	Расчет заработной платы работника	Врач, Должность	1 раз в месяц
4	Формирование списково количестве обратившихсяпациентов по университетам	Пациент, Прием	1 раз в месяц
5	Подготовка отчета по заболеваниям, наиболее часто встречающимся у студентов	Прием	1 раз в месяц
6	Формирование отчета о студентах направленных в студенческий санаторий-профилакторий и с каким диагнозом	Пациент, Прием	1 раз в месяц
7	Подготовка отчета о врачах, находящихся в отпуске	Врач, График работы	1 раз в месяц
8	Формирование списка врачей, имеющихстаж работы более 10 лет	Врач	1 раз в месяц
9	Подготовка отчета о студентах, прошедших медицинскую комиссию в каждом университете	Пациент	1 раз в месяц
10	Формирование списка студентов, прошедших вакцинацию против гриппа в каждом университете	Пациент	1 раз в месяц
11	Формирование расписания работы каждого врача	Врач, График работы, Кабинет	30 раз в месяц

2.4Построение концептуальной схемы

Исходя из приведенного описания связей, возникающих между сущностями, составим общую концептуальную схему (рисунок 6).

Рисунок 6 - Концептуальная схема



2. Логическое проектирование

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

2.1 Установление дополнительных логических связей

Составим таблицу совместного использования сущностей на основе справочника задач.

Таблица 9 - Частота совместного использования сущностей

№	Сущности	1	2	3	4	5	6
1	Врач	0	1	4	4	1	31
2	Должность	1	0
3	Пациент	4		0	7
4	Прием	4		7	0
5	Кабинет	1				0
6	График работы	31					0

Найдем среднее значение совместного использования сущностей по формуле:

,



где a_ij - частота совместного использования пары сущностей.

Получим:

Далее найдём пары сущностей, частота совместного использования которых больше R. Если прямой связи или связи через еще одну сущность таких сущностей не существует, то нужно ее создать.

Из анализа концептуальной схемы (рисунок 6) можно сказать, что дополнительные связи между сущностями устанавливать не нужно, так как сущности «Врач» и «График работы», частота совместного использования которых больше R, связаны.

2.2 Отображение концептуально-логической модели на реляционную модель

Рассмотрим сущности «Врач» и «Должность». Между ними установлена связь типа «один-ко-многим» (рисунок 1). Поскольку простая связь исходит от сущности «Врач», то согласно правилу отображения концептуальной модели на реляционную получаем отношения, представленные на рисунке 7.

Отношение «Врач»

ID Врач	Ф.И.О.	ID Должность	Сертификат	Телефон	Адрес	Стаж работы	Номер кабинета

Отношение«Должность»

ID Должность	Название должности	Оклад

Рисунок 7 - Отношения «Врач» и «Должность»



Рассмотрим сущности «Врач» и «График работы». Между ними установлена связь типа «один-к-одному» (рисунок 2).Поскольку простая связь исходит от обеих сущностей, то согласно правилу отображения концептуальной модели на реляционную получаем отношения, представленные на рисунке 8.

Отношение «Врач»

ID Врач	Ф.И.О.	ID Должность	Сертификат	Телефон	Адрес	Стаж работы	Номер кабинета

Отношение«График работы»

IDГрафика	Пн	Вт	Ср	Чт	Пт	Сб	Примечание

Рисунок 8 - Отношения «Врач» - «График работы»

Рассмотрим сущности «Врач» и «Прием». Между ними установлена связь типа «один-ко-многим» (рисунок 3). Поскольку простая связь исходит от сущности «Прием», то согласно правилу отображения концептуальной модели на реляционную получаем отношения, представленные на рисунке 9.

Отношение «Врач»

ID Врач	Ф.И.О.	ID Должность	Сертификат	Телефон	Адрес	Стаж работы	Номер кабинета

Отношение«Прием»

IDПриема	Дата и время обращения	Дата выписки	ID Пациента	ID Врач
Диагноз	Лечение	Примечание

Рисунок 9- Отношения «Врач» - «Прием»



Рассмотрим сущности «Пациент» и «Прием». Между ними установлена связь типа «один-ко-многим» (рисунок 4). Поскольку простая связь исходит от сущности «Прием», то согласно правилу отображения концептуальной модели на реляционную получаем отношения, представленные на рисунке 10.

Отношение «Пациент»

ID Пациента	Номер карточки	Ф.И.О.	Дата рождения	Адрес	Университет
Факультет/ Институт	Группа	Пол	Медицинская комиссия	Прививки

Отношение«Прием»

IDПриема	Дата и время обращения	Дата выписки	ID Пациента	ID Врач
Диагноз	Лечение	Примечание

Рисунок 10 - Отношения «Пациент» - «Прием»

Рассмотрим сущности «Врач» и «Кабинет». Между ними установлена связь типа «один-ко-многим» (рисунок 5). Поскольку простая связь исходит от сущности «Врач», то согласно правилу отображения концептуальной модели на реляционную получаем отношения, представленные на рисунке 11.

Отношение «Врач»

ID Врач	Ф.И.О.	ID Должность	Сертификат	Телефон	Адрес	Стаж работы	Номер кабинета



Отношение«Кабинет»

Номер кабинета	Ответственный за кабинет	Внутренний телефон

Рисунок 11 - Отношения «Врач» - «Кабинет»

2.3 Нормализация отношений

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

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

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

2.3.1 Первая нормальная форма

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

2.3.2 Вторая нормальная форма

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

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

Отношение «Должность» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «Кабинеты» (рисунок 13).

Номер кабинета
Ответственный за кабинет
Внутренний телефон

Рисунок 13 - Функциональные зависимости отношения «Кабинеты»

Отношение «Отделение» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «Врач» (рисунок 14).

ID Врач
Ф.И.О.
ID Должность
Сертификат
Адрес
Телефон
Стаж работы
Номер кабинета

Рисунок 14 - Функциональные зависимости отношения «Врач»

Отношение «Врач» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «Пациент» (рисунок 15).

IDПациента
Номер карточки
Ф.И.О.
Дата рождения
Адрес
Университет
Факультет/Институт
Группа
Пол
Телефон
Медицинская комиссия
Прививки

Рисунок 15 - Функциональные зависимости отношения «Пациент»

Отношение «Пациент» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «Прием» (рисунок 16).

IDПриема
Дата и время обращения
Дата выписки
ID Пациента
ID Врача
Диагноз
Лечение
Примечание

Рисунок 16 - Функциональные зависимости отношения «Прием»

Отношение «Прием» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «График работы» (рисунок 17)

IDГрафика
Пн
Вт
Ср
Чт
Пт
Сб
Примечание

Рисунок 17 - Функциональные зависимости отношения «График работы»

Отношение «График работы» находится во второй нормальной форме.

2.3.3 Третья нормальная форма

Анализируя зависимости между атрибутами, можно сделать вывод, что между ними нет транзитивных зависимостей (отсутствуют зависимости между не ключевыми атрибутами), и, следовательно, они удовлетворяют третьей нормальной форме.

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

На основе всех функциональных зависимостей, построенных выше, составим итоговую логическую модель базы данных. Результат построения приведен на рисунке А.1 (приложение А).



3. Физическое проектирование

3.1 Описание физической модели

На основе полученной логической модели описываются таблицы, которые будут реализованы всреде MicrosoftSQLServer.

Таблица 10 - Проект таблицы «Врачи»

Название поля	Тип данных	Индексирование
ID Врач	int	Да
Ф.И.О.	char(50)	Нет
ID_Должность	int	Нет
Сертификат	int	Нет
Телефон	char(20)	Нет
Адрес	text	Нет
Стаж работы	int	Нет
Номер_кабинета	int	Нет

Таблица 11 - Проект таблицы «Должность»

Название поля	Тип данных	Индексирование
ID Должность	int	Да
Название должности	char(30)	Нет
Оклад	money	Нет

Таблица 12- Проект таблицы «Пациенты»

Название поля	Тип данных	Индексирование
ID_Пациента	int	Да
Номер_карточки	int	Нет
Ф.И.О.	char(50)	Нет
Дата_рождения	date	Нет
Адрес	text	Нет
Университет	text	Нет
Факультет_Институт	text	Нет
Группа	text	Нет
Пол	char(10)	Нет
Телефон	char(20)	Нет
Медицинская_комиссия	char(50)	Нет
Прививки	text	Нет

Таблица 13 - Проект таблицы «График_работы»

Название поля	Тип данных	Индексирование
ID_Графика	int	Да
Пн	text	Нет
Вт	text	Нет
Ср	text	Нет
Чт	text	Нет
Пт	text	Нет
Сб	text	Нет
Примечание	char(15)	Нет

Таблица 14 - Проект таблицы «Прием»

Название поля	Тип данных	Индексирование
ID_Приема	int	Да
Дата_и_время_ обращения	char(30)	Нет
Дата_выписки	date	Нет
ID_Пациента	int	Нет
ID_Врач	int	Нет
Диагноз	text	Нет
Лечение	text	Нет
Примечание	char(50)	Нет

3.2Физическая схема базы данных

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



1. Описание базы данных с помощью средств СУБД

В этой главе будут представлены таблицы, заполненные данными.

Рисунок18 - Таблица «Врачи»

Рисунок 19 - Таблица «Должность»



Рисунок 20 - Таблица «Пациенты»

Рисунок21- Таблица «Прием»

Рисунок 22 - Таблица «График работы»

Рисунок 23 - Таблица «Кабинеты»

2. Описание SQL-запросов и результатов их выполнения

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

1) Запрос «Формирование данных о пациентах, которые выписаны»

SQL-код данного запроса представлен на рисунке24, а результат на рисунке 25.

Рисунок 24 - SQL-код запроса «Формирование данных о пациентах, которые выписаны»

Рисунок 25 - Результат выполнения SQLзапроса «Формирование данных о пациентах, которые выписаны»

2) Запрос «Формирование списка о занятости врача»

SQL-код данного запроса представлен на рисунке 26, а результат на рисунке27.

Рисунок 26 - SQL-код запроса «Формирование списка о занятости врача»

Рисунок 27 - Результат выполнения SQL запроса «Формирование списка о занятости врача»

3) Запрос «Расчет заработной платы работника».

SQL-код данного запроса представлен на рисунке 28, а результат на рисунке 29.

Рисунок28 - SQL-код запроса «Расчет заработной платы работника»



Рисунок 29 - Результат выполнения SQL запроса «Расчет заработной платы работника»

4) Запрос «Формирование списков о количестве обратившихся пациентов по университетам».

SQL-код данного запроса представлен на рисунке 30, а результат на рисунке 31.

Рисунок 30 - SQL-код запроса «Формирование списков о количестве обратившихся пациентов по университетам»

Рисунок 31 - Результат выполнения SQL запроса «Формирование списков о количестве обратившихся пациентов по университетам»

5) Запрос «Подготовка отчета по заболеваниям, наиболее часто встречающимся у студентов»

SQL-код данного запроса представлен на рисунке 32, а результат на рисунке 33.

Рисунок 32 - SQL-код запроса «Подготовка отчета по заболеваниям, наиболее часто встречающимся у студентов»

Рисунок 33 - Результат выполнения SQL запроса «Подготовка отчета по заболеваниям, наиболее часто встречающимся у студентов»

6) Запрос «Формирование отчета о студентах направленных в студенческий санаторий-профилакторий и с каким диагнозом»

SQL-код данного запроса представлен на рисунке 34, а результат на рисунке 35.

Рисунок 34 - SQL-код запроса «Формирование отчета о студентах направленных в студенческий санаторий-профилакторий и с каким диагнозом»

Рисунок 35 - Результат выполнения запроса «Формирование отчета о студентах направленных в студенческий санаторий-профилакторий и с каким диагнозом»

7) Запрос «Подготовка отчета о врачах, находящихся в отпуске»

SQL-код данного запроса представлен на рисунке 36, а результат на рисунке 37.

Рисунок 36 - SQL-код запроса «Подготовка отчета о врачах, находящихся в отпуске»



Рисунок 37 - Результат выполнения запроса «Подготовка отчета о врачах, находящихся в отпуске»

8) Запрос «Формирование списка врачей, имеющих стаж работы более 10 лет»

SQL-код данного запроса представлен на рисунке 38, а результат на рисунке 39.

Рисунок 38 - SQL-код запроса «Формирование списка врачей, имеющих стаж работы более 10 лет»

Рисунок 39 - Результат выполнения запроса «Формирование списка врачей, имеющих стаж работы более 10 лет»

9) Запрос «Подготовка отчета о студентах, прошедших медицинскую комиссию в каждом университете»

SQL-код данного запроса представлен на рисунке 40, а результат на рисунке 41.

Рисунок 40 - SQL-код запроса «Подготовка отчета о студентах, прошедших медицинскую комиссию в каждом университете»

Рисунок 41 - Результат выполнения запроса «Подготовка отчета о студентах, прошедших медицинскую комиссию в каждом университете»

10) Запрос «Формирование списка студентов, прошедших вакцинацию против гриппа в каждом университете»

SQL-код данного запроса представлен на рисунке 42, а результат на рисунке 43.

Рисунок 42 - SQL-код запроса «Формирование списка студентов, прошедших вакцинацию против гриппа в каждом университете»

Рисунок 43 - Результат выполнения запроса «Формирование списка студентов, прошедших вакцинацию против гриппа в каждом университете»

11) Запрос «Формирование расписания работы каждого врача»

SQL-код данного запроса представлен на рисунке 44, а результат на рисунке 45.

Рисунок 44 - SQL-код запроса «Формирование расписания работы каждого врача»

Рисунок 45 - Результат выполнения запроса «Формирование расписания работы каждого врача»



ЗАКЛЮЧЕНИЕ

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

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

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

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



СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1) Андон Ф. Язык запросов SQL. Учебный курс / Андон Ф., Резниченко В. - СПб. : Питер, 2006. - 579 с.

2) Бен-Ган, Ицик. Microsoft SQL Server 2012. Основы T-SQL/ Ицик Бен-Ган ; [пер. с англ. М.А. Райтмана]. - Москва :Эксмо, 2015. - 400с. - (Мировой компьютерный бестселлер).

3) Бьюли А. Изучаем SQL. - Пер. с англ. - СПб: Символ-Плюс, 2007.-312с.,ил.

4) Кириллов, В. В. Введение в реляционные базы данных / В. В. Кириллов, Г. Ю. Громов. --СПб.: БХВ-Петербург, 2009. -- 464 с.: ил. (Учебная литература для вузов)

5) Молинаро Э. SQL. Сборник рецептов / Молинаро Э. - М. : Символ-Плюс, 2008. - 460 с.

6) Ульман Л. MySQL. Руководство по изучению языка. Пер. с англ. А.А. Слинкина. -- М.: ДМК Пресс; СПб.: Питер, 2004. -- 352 с.: ил.

7) SQL.ru - все про SQL, базы данных, программирование и разработку информационных систем [Электронный ресурс] :Сибелев А. - 2000-2015. URL: http://www.sql.ru (Дата обращения : 01.05.2015).

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