ОПИСАНИЕ УЧЕТА СТУДЕНТОВ В БОЛЬНИЦЕ

1 ОПИСАНИЕ УЧЕТА СТУДЕНТОВ В БОЛЬНИЦЕ

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

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

Каждый студент относится к определенному ВУЗу. В каждом ВУЗе есть много специальностей, а на каждой специальности несколько групп. Также учитывается то, что один студент не может числиться в базе больницы сразу в нескольких ВУЗах. Если студент учится в двух и более ВУЗах, в базе учитывается лишь один ВУЗ.

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

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

Каждый студент, независимо от места обучения, относится к студенческой больнице. Больница не выносится как отдельный объект. Каждый студент в больнице обращается к определенному врачу. О враче необходимо знать: ФИО, его специализацию и номер кабинета. Врач каждому студенту ставит диагноз.

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

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

2 ПОСТАНОВКА ЗАДАЧИ

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

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

В целом, база данных должна:

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

·                    обеспечивать возможность выполнять запрос, поиск, изменение и систематизацию данных БД;

·                    иметь удобный пользовательский интерфейс для работы с ней любого пользователя;

·                    иметь необходимые запросы и формы для обработки хранимой информации;

·                    предусматривать архивацию данных и сохранность хранимой в БД информации.

3 КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ СУБД 3.1 Разработка схемы объект-отношение

Схема модели «Объект-отношение» приведена на рисунке 3.1.

Было выбрано 6 объектов – студент, группа, ВУЗ, врач и диагноз и специализация. Объект студент имеет 4 свойства: ФИО, место жительства, год рождения, № зачетки. Объект группа имеет 2 свойства: год набора и букву. Объект ВУЗ имеет 6 свойств: адрес, полное название, аббревиатура, дата окончания, телефон учебной части и ФИО ректора. Объект врач представлен 2 свойствами: ФИО, № кабинета. Объект диагноз имеет одно свойство – название. Объект специализация так же имеет одно свойство – область специализации.

В данной схеме используются связи 1 ко многим, а также многие ко многим. Между объектами студент и группа выбрана связь многие к одному. Учитываем, что названия специальностей в ВУЗах уникальны и каждый студент учится лишь в одной группе; в одной группе могут учиться много студентов. Между объектами группа и ВУЗ представлена связь многие к одному: одному ВУЗу могут принадлежать несколько групп; каждая группа принадлежит одному ВУЗу. Между объектами студент и врач нет прямой связи. Объекты врач и диагноз представлены связью многие ко многим, – один врач может поставить несколько диагнозов; один диагноз может быть поставлен несколькими врачами. Между объектами студент и диагноз представлена связь многие ко многим: одному студенту могут быть поставлены несколько диагнозов; один диагноз может быть поставлен нескольким студентам. Между объектами Врачи и специализация представлена связь один-ко-многим: один врач числится в больнице по одной специализации; в одной больнице могут работать несколько врачей одинаковой специализации. К связи между объектами студент и диагноз добавлено 4 свойства – тип лечения, дата начала заболевания, дата окончания заболевания и комментарии.

Рисунок 3.1 – Схема объект-отношение

3.2 Обоснование выбора модели данных

3.2.1 Типы моделей данных

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

3.2.2 Иерархическая модель данных

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

Таким образом, иерархическая модель данных представляет собой упорядоченную совокупность экземпляров типа «дерево» (деревьев), содержащих экземпляры типа «запись» (записи).

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

учится ВУЗ #К.В. Название ВУЗа Адрес ВУЗа Аббревиатура ФИО ректора Телефон счет текст текст текст текст текст Студент   #К.С ФИО М.жит-ва Дата рожд № зач Дата окон счетч симв симв дата/вр текст д/вр учится Студент   #К.С ФИО М.жит-ва Дата рожд № зач счетч симв симв дата/вр текст Группа #К.Г Аббревиатура счет текст	имеет Врач #К.Вр. ФИО № кабинета счет текст текст Специализация # К.Сп Область спец-ии счет текст
Врач #К.Вр. ФИО № кабинета Специализация счет текст текст числ диагностируется Диагноз #К.Д Название Дата начала Дата окон счет текст д/вр д/вр	Диагноз #К.Д Название счет текст принадлежит Студент   #К.С ФИО М.жит-ва Дата рожд № зач ВУЗ Группа Дата нач Дата окон счетч симв симв дата/вр текст дл.цл дл.цл. д/вр д/вр
4 Диагноз #К.Д Название счет текст Врач #К.Вр. ФИО № кабинета Специализация Дата нач Дата окон счет текст текст числ д/вр	Студент #К.С ФИО М.жит-ва Дата рожд № зач ВУЗ Группа счетч симв симв дата/вр текст дл.цл дл.цл. Диагноз #К.Д Название Дата начала Дата окон счет текст д/вр д/вр

Рисунок 3.2 – Реализации иерархической модели данных

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

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