База данных "Автоматизация учета больных в студенческой больнице"

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - База данных "Автоматизация учета больных в студенческой больнице"

База данных "Автоматизация учета больных в студенческой больнице"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.3 Сетевая модель данных

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

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

Схема сетевой модели данных для данной БД показана на рисунке 3.3.

Рисунок 3.3 - Схема сетевой модели данных

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

3.2.4 Реляционная модель данных

Предпочтение было отдано реляционной модели по следующим причинам:

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

схема данных позволяет представить структуру в виде таблиц (после некоторых преобразований);

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

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

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

реляционная МД нагляднее представляет структуру данных.

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

Для проектируемой БД реляционная модель представлена на рисунке 3.4.

5 УРОВНИ ДОСТУПА К СУБД

Описание групп пользователей

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

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

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

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

Медсестра ВУЗа

Как сказано ранее, этот пользователь заходит в базу без пароля и не имеет в ней никаких прав на изменение данных - лишь их просмотр и печать на принтере. На всех формах кнопки «Добавить запись», «Сохранить запись» и «Удалить запись» недоступны. Кнопки «Добавить Студента» и «Архив» в форме «Вход» так же недоступны. Область действий - просмотр данных из базы и распечатка их на принтере.

Медсестра больницы

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

Врач

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

ВЫВОДЫ

За время создания курсового проекта и написания пояснительной записки была досконально изучена предметная область проекта; разработана концептуальная модель БД: объект-отношение; выбрана реляционная модель для создания эффективной БД; разработаны основные модели запросов для работы с данными БД.

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

Также была организована архивация данных.

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

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

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

Приложение А

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

А 1 Общие сведения

А.2 Этапы разработки и сроки выполнения

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

А 3 Назначение и цели создания проекта

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

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

А 3 Характеристика объекта автоматизации

А 3.1 Сведения об объекте автоматизации

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

А 3.2 Сведения об условиях эксплуатации КП

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

А 4 Требования к проекту

А 4.1 Требования к КП в целом

КП в целом должен :

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

обеспечить не избыточность, компактность, целостность хранимых данных.

А 4.2 Требования к задачам и функциям КП

Проектируемый программный продукт должен реализовывать следующие задачи:

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

- позволять получать информацию по определённым запросам пользователя. (запросы на выборку, на добавление и удаление записей в архиве, запросы для создания пользовательских форм и отчетов. Отчетов: «Заявка о начале учета в больнице», «Прием врачей», форм: больных студентов определенного врача, заболевания определенного студента), а так же:

хранить информацию о больных студентах;

хранить информацию о ВУЗах;

хранить информацию о группе;

хранить информацию о заболевании;

хранить информацию о лечащем враче;

хранить информацию о диагностике;

корректный выбор информации по какой-либо характеристике;

поиск по ключевым словам.

А 4.3 Требования к видам обеспечения

А 4.3.1 Требования к программному обеспечению

К программному обеспечению (ПО) предъявляются следующие требования:

-монитор типа SVGA;

-операционная система- Microsoft Windows 98 и выше;

- установленная прикладная программа Access 2003 из программного пакета Microsoft Office.

А 4.3.2 Требования к техническому обеспечению

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

-тип компьютера- INTEL 5x 86;

-объем памяти RAM 16Мб;

А 4.3.3 Требования к организационному обеспечению

К программной документации предъявляются следующие требования:

-наличие технического задания;

-пояснительной записки, включающей приложения.

Приложение Б

ЗАПОЛНЕННЫЕ ТАБЛИЦЫ

Приложение В

РУКОВОДСТВО ПОЛЬЗОВАТЕЛЮ

В.1 Инсталляция

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

В.2 Начало работы с программой

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

Михеева В., Харитонова И. Наиболее полное руководство Microsoft Access 2000 - СПб.: БВХ - Санкт-Петербург, 2000. - 1088с.:ил.