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

ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ

Филиал государственного образовательного учреждения

высшего профессионального образования

«Московский энергетический институт

(технический университет)»

в г. Смоленске

Кафедра Вычислительной техники

Расчетно-пояснительная записка к курсовому проекту по курсу

«Структура, алгоритмы, реализация баз данных»

Тема: «Информационная система медицинских организаций города»

Преподаватель: Малахов В.В.

Группа: АС - 06

Студент: Горянинов М.Г.

Смоленск 2011

АННОТАЦИЯ

Горянинов М. Г. Курсовая работа по дисциплине «Структура, алгоритмы, реализация баз данных» на тему «Информационная система медицинских организаций города».

Курсовая работа составляет: 45 стр., 24 ил., 2 приложения.

Целью работы является разработка информационной системы медицинских организаций города.

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

Информационная система была разработана с использованием приложений ER-Win 7.2, Microsoft Access 2003.

Пояснительная записка содержит описание разработки информационной системы, алгоритмы работы, экранные формы.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. ОБОСНОВАНИЕ РАЗРАБОТКИ СИСТЕМЫ

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

1.2 Обзор средств проектирования баз данных

1.3 Технологические платформы баз данных

ВЫВОДЫ ПО ГЛАВЕ

2. РАЗРАБОТКА СИСТЕМЫ

2.1 Анализ технического задания

2.2 Проектирование базы данных

2.2.1 Этапы проектирования

2.2.2 Разработка логической модели

2.2.3 Разработка физической модели

2.2.4 Генерация модели в MS Access 2003

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

ВЫВОДЫ ПО ГЛАВЕ

3. АНАЛИЗ РАЗРАБОТАННОЙ СИСТЕМЫ

3.1 Требования по установке

3.2 Тестирование системы

3.3 Безопасность системы

ВЫВОДЫ ПО ГЛАВЕ

ЗАКЛЮЧЕНИЕ

Использованная литература

ПРИЛОЖЕНИЕ 1 Схема базы данных «dbmed»

ПРИЛОЖЕНИЕ 2 ТАБЛИЦЫ ФИЗИЧЕСКОЙ МОДЕЛИ

Техническое задание

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

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

Виды запросов в информационной системе:

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

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

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

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

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

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

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

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

9. Получить общее число палат, коек указанной больницы в общем и по каждому отделению.

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

ВВЕДЕНИЕ

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

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

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

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

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

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

1. ОБОСНОВАНИЕ РАЗРАБОТКИ СИСТЕМЫ

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

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

Разработку системы предполагается произвести в несколько этапов:

· Разработка структуры информационной системы;

· Создание базы данных;

· Создание простейшего приложения для работы с базой данных;

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

1.2 Обзор средств проектирования баз данных

база данные запрос access

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

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

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

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

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

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

При этом, Erwin позволяет создавать базы данных следующих форматов: Advantage Ingres Enterprise Relational Database, Advantage CA-Clipper, DB2, dBASE, FoxPro, HiRDB, Informix, InterBase, Microsoft Access, Teradata, Microsoft SQL Server, ODBC 2.0, 3.0, Oracle, Paradox, Rdb, Red Brick Warehouse, SAS, SQL Anywhere, SQL Base, Sybase. Для каждой из перечисленных СУБД в ERwin предусмотрено присоединение по "родному" для этой СУБД протоколу и поддержка всех средств управления данными, присущих этой СУБД.

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

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

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

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

1.3 Технологические платформы баз данных

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

Рассмотрим параметры основных СУБД:

1. Microsoft SQL Server - это законченное предложение в области баз данных и анализа данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных. Оно позволяет значительно сократить время выхода этих решений на рынок, одновременно обеспечивая масштабируемость, отвечающую самым высоким требованиям. В SQL Server включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения. Кроме того, SQL Server полностью использует все возможности операционной системы Windows, включая поддержку до 32 процессоров и 64Гб RAM.

2. SQLBase - профессиональная, SQL-ориентированная СУБД. Среди ее достоинств: простота в администрировании, мобильность, компактность, невысокая стоимость, возможность создавать надежные и гибкие системы обработки данных, а также полная интеграция с MS Windows и Novell Netware и возможность поддержки Java-технологий.

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

4. MS Access 2003 обладает встроенными инструментами, поддерживающими стандарты объектно-ориентированного программирования. Удобные инструменты, например автоматическая проверка правописания, индивидуальная настройка меню и панелей инструментов, значительно облегчают работу. Система поддерживает функции совместной работы в режиме on-line с помощью программы NetMeeting: пользователь программы и ее разработчик могут напрямую общаться посредством Internet. Значительно облегчают участь программистов мощные инструменты ActiveX Data Objects (ADO). Access позволяет создавать хранимые процедуры, связывать Web-страницы с базами данных и легко масштабировать последние до уровня Microsoft SQL Server с помощью Microsoft Access Projects. Рассматриваемые в комплексе, все эти средства предоставляют возможности более быстрого создания качественных приложений для работы с базами данных, подготовки Web-ориентированных решений, масштабирования баз данных на платформу SQL Server, написания и переноса фрагментов объектно-ориентированного программного кода в среду других продуктов Microsoft Office, поддерживающих VBA.

ВЫВОДЫ ПО ГЛАВЕ

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

2. РАЗРАБОТКА СИСТЕМЫ

2.1 Анализ технического задания

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

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

1. Предоставление исчерпывающей информации о пациентах (место прохождения лечения, сроки, диагноз, лечащий врач).

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

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

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

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

Выходной информацией работы системы является информационная составляющая базы данных.

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

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

2.2 Проектирование базы данных

2.2.1 Этапы проектирования

Проектирование базы данных производилось в соответствии с описанной ниже методологией:

1. Представление каждой независимой сущности таблицей базы данных (базовой таблицей) и спецификация первичного ключа этой базовой таблицы.

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

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

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

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

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

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

8. Указание ограничений целостности проектируемой базы данных.

2.2.2 Разработка логической модели

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

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

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

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

- Сотрудники;

- Обслуживающий персонал;

- Врачи;

- Категории врачей;

- Персонал-учреждения;

- Врачи-отделения;

- Мед учреждения;

- Больницы;

- Поликлиники;

- Отделения;

- Палаты;

- Пациенты;

- Талоны посещения;

- Больные;

- Лечение;

- Операции.

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

Сущность «Сотрудники» хранит общую информацию о работниках медицинской сферы города:

- Код сотрудника (Ключевое поле)

- ФИО

- Стаж

- Должность

Сущность «Обслуживающий персонал» является дочерней для сущности «Сотрудники» и хранит информацию о штате обслуживающего персонала медицинских учреждений:

- Код сотрудника (Ключевое поле, Внешний ключ)

- Профиль

- Оклад

Сущность «Врачи» является дочерней для сущности «Сотрудники» и хранит информацию о штате врачей медицинских учреждений:

- Код врача (Ключевое поле, Внешний ключ)

- Код категории (Внешний ключ)

- Степень

- Звание

- Операции

- Летальные

- Успешные

Сущность «Категории» хранит данные о категориях врачей:

- Код категории (Ключевое поле)

- Категория

- Льготы

Сущность «Мед учреждения» хранит общие данные о медицинских организациях города:

- Код учреждения (Ключевое поле)

- Название

- Адрес

- Штат врачей

- Штат персонала

Сущность «Поликлиники» является дочерней для сущности «Мед учреждения» и содержит конкретную информацию о поликлиниках города:

- Код учреждения (Ключевое поле, Внешний ключ)

- Код поликлиники (Ключевое поле)

- Количество кабинетов

Сущность «Больницы» является дочерней для сущности «Мед учреждения» и содержит конкретную информацию о больницах города:

- Код учреждения (Ключевое поле, Внешний ключ)

- Код больницы (Ключевое поле)

- Количество корпусов

- Количество палат

- Количество коек

Сущность «Отделения» содержит информацию об отделениях больниц:

- Код отделения (Ключевое поле)

- Код больницы (Внешний ключ)

- Номер корпуса

- Отделение

- Количество палат

- Количество коек

- Код учреждения (Внешний ключ)

Сущность «Палаты» содержит информацию о палатах, принадлежащих каждому отделению:

- Код палаты (Ключевое поле)

- Номер палаты

- Количество мест

- Код отделения (Внешний ключ)

Сущность «Персонал-учреждения» содержит информацию о принадлежности обслуживающего персонала к определенному учреждению:

- Код (Ключевое поле)

- Код сотрудника (Внешний ключ)

- Код отделения (Внешний ключ)

Сущность «Врачи-отделения» хранит информацию о принадлежности врачебного персонала к отделению определенного учреждения:

- Код (Ключевое поле)

- Код сотрудника(Внешний ключ)

- Код отделения (Внешний ключ)

Сущность «Пациенты» хранит информацию о гражданах города, имеющих медицинские полюса:

- Код пациента (Ключевое поле)

- ФИО

- Дата рождения

- Адрес

Сущность «Талоны посещения» хранит данные о посещениях пациентов определенных врачей:

- Код талона (Ключевое поле)

- Код пациента (Внешний ключ)

- Код врача (Внешний ключ)

- Время

- Кабинет

Сущность «Больные» содержит данные о пациентах, находящихся на стационарном лечении:

- Код больного (Ключевое поле)

- Код пациента (Внешний ключ)

- Дата поступления

- Код палаты (Внешний ключ)

Сущность «Лечение» несет информацию о прохождении лечения больного. Является дочерней для сущности «Больные»:

- Код больного (Ключевое поле, Внешний ключ)

- Код врача (Внешний ключ)

- Диагноз

- Срок лечения

Сущность «Операции» содержит статистику операций, проходящих в больницах города:

- Код операции (Ключевое поле)

- Дата проведения

- Код учреждения (Внешний ключ)

- Код больного (Внешний ключ)

- Код врача (Внешний ключ)

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

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

Рисунок 1 - Логическая модель базы данных

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

Выделяют три группы правил целостности:

- Целостность по сущностям.

- Целостность по ссылкам.

- Целостность, определяемая пользователем.

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

2.2.3 Разработка физической модели

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

Проектирование физической модели заключается в определении типов данных и целевого сервера базы данных или СУБД. Поэтому перед построением физической модели необходимо выбрать сервер (меню Server/Target Server). Выберем в качестве сервера Microsoft Access 2003, получив физическую модель, сгенерированную ERWin по умолчанию. В полученной модели необходимо скорректировать типы и размеры полей.

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

ь AutoNumber - числовой счетчик;

ь Text - текстовая строка;

ь Integer - длинное целое;

ь Date / Time - дата/время.

Физическая модель данных, разработанная в ERWin, изображена на рисунке 2.

Рассмотрим параметры таблиц физической модели в Приложении 2.

Рисунок 2 - Физическая модель базы данных

2.2.4 Генерация модели в MS Access 2003

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

Для генерации кода создания БД необходимо выбрать пункт меню Tools/Forward Engineer/Schema Generation. В ячейке «Datebase» указываем путь к предварительно созданной пустой базе данных в MS Access 2003 (dbmed.mdb).

В процессе генерации ER-win связывается с БД, выполняя SQL-скрипт. Если в процессе генерации возникают какие-либо ошибки, то она прекращается, открывается окно с сообщениями об ошибках. Диагностический отчет позволяет обнаружить в дизайне базы данных любые противоречия или отклонения от нормы. При генерации базы данных «dbmed» никаких ошибок не вывелось, генерация прошла успешно. Свидетельствует об этом сообщение «610 query succeeded» - «удачно создано 610 запроса/действий» (рисунок 3).

Рисунок 3 - Окно в ERWin сообщений о результатах генерации схемы данных

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

В результате проделанной работы была создана БД в Access 2003, список сгенерированных таблиц изображен на рисунке 4.

Рисунок 4 - Список таблиц сгенерированной БД

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



Рисунок 5 - Свойства связи

На рисунке 5 показано свойство связи между таблицами «Сотрудники» и «Врачи». Данная связь (как и все остальные) совпадают с созданными в ERWIN.

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



Рисунок 6 - Таблица в режиме конструктора

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

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

В соответствии с поставленными задачами получили запросы, рисунок 7.



Рисунок 7 - Список запросов проекта

Рисунок 8 - Список форм

Рисунок 9 - Главная форма



Рисунок 10 - Форма для работы с таблицами базы данных

Рисунок 11 - Форма для работы с запросами базы данных

Рассмотрим запросы подробнее:

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

Получаем перечень врачей категории «хирург» для всех медицинских учреждений города (рис. 12).



Рисунок 12 - Форма «Запрос 1»

SQL-код запроса представлен ниже:

SELECT Сотрудники.[Код сотрудника], Сотрудники.ФИО, Категории.Категория

FROM Категории INNER JOIN (Сотрудники INNER JOIN Врачи ON Сотрудники.[Код сотрудника] = Врачи.[Код сотрудника]) ON Категории.[Код категории] = Врачи.[Код категории]

WHERE (((Категории.Категория)="хирург"));

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

Получаем перечень обслуживающего персонала профиля «медбрат» для всех медицинских учреждений города (рис. 13).

Рисунок 13 - Форма «Запрос 2»

SQL код Запроса 2 представлен ниже:

SELECT Сотрудники.[Код сотрудника], Сотрудники.ФИО, [Обслуживающий персонал].Профиль

FROM Сотрудники INNER JOIN [Обслуживающий персонал] ON Сотрудники.[Код сотрудника]=[Обслуживающий персонал].[Код сотрудника]

WHERE ((([Обслуживающий персонал].Профиль)="медбрат"));

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

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

Рисунок 14 - Форма «Запрос 3»

SQL код Запроса 3 представлен ниже:

SELECT Сотрудники.[Код сотрудника], Сотрудники.ФИО, Категории.Категория, Врачи.Операции

FROM Категории INNER JOIN (Сотрудники INNER JOIN Врачи ON Сотрудники.[Код сотрудника]=Врачи.[Код сотрудника]) ON Категории.[Код категории]=Врачи.[Код категории]

WHERE (((Категории.Категория)="хирург") AND ((Врачи.Операции)>=10));

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

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



Рисунок 15 - Форма «Запрос 4»

SQL код Запроса 4 представлен ниже:

SELECT Сотрудники.[Код сотрудника], Сотрудники.ФИО, Сотрудники.Должность, Сотрудники.Стаж

FROM Сотрудники INNER JOIN Врачи ON Сотрудники.[Код сотрудника]=Врачи.[Код сотрудника]

WHERE (((Сотрудники.Должность)="врач") AND ((Сотрудники.Стаж)>=12));

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

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

Рисунок 16 - Форма «Запрос 5»

SQL код Запроса 5 представлен ниже:

SELECT Сотрудники.[Код сотрудника], Сотрудники.ФИО, Категории.Категория, Врачи.Степень, Врачи.Звание

FROM Категории INNER JOIN (Сотрудники INNER JOIN Врачи ON Сотрудники.[Код сотрудника]=Врачи.[Код сотрудника]) ON Категории.[Код категории]=Врачи.[Код категории]

WHERE (((Категории.Категория)="хирург") AND ((Врачи.Степень)="доктор м.н.") AND ((Врачи.Звание)="профессор"));

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

Получаем перечень пациентов «Областной больницы» отделения №2 (стоматология) с указанием даты поступления и лечащего врача.

Рисунок 17 - Форма «Запрос 6»

SQL код Запроса 6 представлен ниже:

SELECT Пациенты.[Код пациента], Пациенты.ФИО, [Мед учреждения].Название, Палаты.[Код отделения], Больные.[Дата поступления], Лечение.[Код сотрудника], Сотрудники.ФИО

FROM Сотрудники INNER JOIN (Врачи INNER JOIN ([Мед учреждения] INNER JOIN (Больницы INNER JOIN ((Отделения INNER JOIN (Палаты INNER JOIN (Пациенты INNER JOIN Больные ON Пациенты.[Код пациента]=Больные.[Код пациента]) ON Палаты.[Код палаты]=Больные.[Код палаты]) ON Отделения.[Код отделения]=Палаты.[Код отделения]) INNER JOIN Лечение ON Больные.[Код больного]=Лечение.[Код больного]) ON (Больницы.[Код больницы]=Отделения.[Код больницы]) AND (Больницы.[Код учреждения]=Отделения.[Код учреждения])) ON ([Мед учреждения].[Код учреждения]=Больницы.[Код учреждения]) AND (Отделения.[Код учреждения]=[Мед учреждения].[Код учреждения])) ON Врачи.[Код сотрудника]=Лечение.[Код сотрудника]) ON (Сотрудники.[Код сотрудника]=Врачи.[Код сотрудника]) AND (Лечение.[Код сотрудника]=Сотрудники.[Код сотрудника])

WHERE ((([Мед учреждения].Название)="Областная больница") AND ((Палаты.[Код отделения])=2));

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

Получаем перечень пациентов, прошедших стационарное лечение в Областной больнице с 07.01.2010 по 07.01.2011.

Рисунок 18 - Форма «Запрос 7»

SQL код Запроса 7 представлен ниже:

SELECT Пациенты.ФИО, [Мед учреждения].Название, Больные.[Дата поступления]

FROM [Мед учреждения] INNER JOIN (Пациенты INNER JOIN (Больницы INNER JOIN ((Отделения INNER JOIN Палаты ON Отделения.[Код отделения]=Палаты.[Код отделения]) INNER JOIN (Больные INNER JOIN Лечение ON Больные.[Код больного]=Лечение.[Код больного]) ON Палаты.[Код палаты]=Больные.[Код палаты]) ON (Больницы.[Код больницы]=Отделения.[Код больницы]) AND (Больницы.[Код учреждения]=Отделения.[Код учреждения])) ON Пациенты.[Код пациента]=Больные.[Код пациента]) ON ([Мед учреждения].[Код учреждения]=Больницы.[Код учреждения]) AND ([Мед учреждения].[Код учреждения]=Отделения.[Код учреждения])

WHERE ((([Мед учреждения].Название)="Областная больница") AND ((Больные.[Дата поступления])>#7/1/2010# And (Больные.[Дата поступления])<#7/1/2011#))

ORDER BY Больные.[Дата поступления] DESC;

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

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

Рисунок 19 - Форма «Запрос 8»

SQL код Запроса 8 представлен ниже:

SELECT Пациенты.ФИО, Категории.Категория, Сотрудники.ФИО, [Врачи-Отделения].[Код отделения], Отделения.Направление

FROM Сотрудники INNER JOIN (Отделения INNER JOIN (Пациенты INNER JOIN (Больные INNER JOIN ((Категории INNER JOIN (Врачи INNER JOIN Лечение ON Врачи.[Код сотрудника]=Лечение.[Код сотрудника]) ON Категории.[Код категории]=Врачи.[Код категории]) INNER JOIN [Врачи-Отделения] ON Врачи.[Код сотрудника]=[Врачи-Отделения].[Код сотрудника]) ON Больные.[Код больного]=Лечение.[Код больного]) ON Пациенты.[Код пациента]=Больные.[Код пациента]) ON Отделения.[Код отделения]=[Врачи-Отделения].[Код отделения]) ON (Сотрудники.[Код сотрудника]=Врачи.[Код сотрудника]) AND (Сотрудники.[Код сотрудника]=[Врачи-Отделения].[Код сотрудника]) AND (Лечение.[Код сотрудника]=Сотрудники.[Код сотрудника])

WHERE (((Категории.Категория)="хирург") AND (([Врачи-Отделения].[Код отделения])=8));

9. Получить общее число палат, коек указанной больницы в общем и по каждому отделению.

Получаем общее число палат и коек конкретной больнице (Областная больница) - рисунок 20 и число палат и коек по каждому отделению - рисунок 21.

Рисунок 20 - Форма «Запрос 9а»

Рисунок 21 - Форма «Запрос 9б»

SQL код Запроса 9а:

SELECT Больницы.[Код учреждения], [Мед учреждения].Название, Больницы.[Количество палат], Больницы.[Количество коек]

FROM [Мед учреждения] INNER JOIN Больницы ON [Мед учреждения].[Код учреждения] = Больницы.[Код учреждения];

SQL код Запроса 9б:

SELECT Отделения.[Код учреждения], [Мед учреждения].Название, Отделения.[Код отделения], Отделения.Направление, Отделения.[Количество палат], Отделения.[Количество коек]

FROM [Мед учреждения] INNER JOIN (Больницы INNER JOIN Отделения ON (Больницы.[Код учреждения] = Отделения.[Код учреждения]) AND (Больницы.[Код больницы] = Отделения.[Код больницы])) ON (Отделения.[Код учреждения] = [Мед учреждения].[Код учреждения]) AND ([Мед учреждения].[Код учреждения] = Больницы.[Код учреждения]);

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

Получаем перечень пациентов, перенесших операции у конкретного врача (хирурга Макарова О.В.) за период с 04.30.2011 по 05.02.2011.

Рисунок 22 - Форма «Запрос 10»

SQL код Запроса 10 представлен ниже:

SELECT Операции.[Код больного], Пациенты.ФИО, Операции.[Код врача], Сотрудники.ФИО, Категории.Категория, Операции.[Дата проведения]

FROM Категории INNER JOIN (Сотрудники INNER JOIN (Врачи INNER JOIN (Пациенты INNER JOIN (Операции INNER JOIN Больные ON Операции.[Код больного] = Больные.[Код больного]) ON Пациенты.[Код пациента] = Больные.[Код пациента]) ON Врачи.[Код сотрудника] = Операции.[Код врача]) ON Сотрудники.[Код сотрудника] = Врачи.[Код сотрудника]) ON Категории.[Код категории] = Врачи.[Код категории]

WHERE (((Операции.[Код врача])=10002) AND ((Операции.[Дата проведения])>=#4/30/2011# And (Операции.[Дата проведения])<=#5/2/2011#));

ВЫВОДЫ ПО ГЛАВЕ

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

3. АНАЛИЗ РАЗРАБОТАННОЙ СИСТЕМЫ

3.1 Требования по установке

Для установки информационной системы требуется скопировать файл dbmed.mdb на диск локального компьютера. Дополнительных действий при установке не требуется. Для правильного функционирования системы требуется наличие на локальном компьютере MS Office 2003 или выше.

3.2 Тестирование системы

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

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

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

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

3.3 Безопасность системы

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

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

Группа Admins обладает всеми правами администратора. То есть входящие в данную группу пользователи могут не только просматривать базу данных но и изменять и обновлять.

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

Рисунок 23 - Вход в систему

Были созданы два новых пользователя: Админ (состоящий в группе Admins) и Гость (состоящий в группе Users). Админ обладая правами администратора может изменять таблицы, формы, запросы и т д. Пользователь Гость имеет возможность лишь просматривать Запросы. При попытке совершить какую-либо операцию вне его полномочий появляется соответствующее сообщение (Рисунок 24).

Рисунок 24 - Запрет просмотра и редактирования форм для пользователей в группе Users

ВЫВОДЫ ПО ГЛАВЕ

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

ЗАКЛЮЧЕНИЕ

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

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

На втором этапе, проведенный анализ технического задания позволил выделить общие требования к системе, на основании которых было произведено проектирование базы данных. Была построена логическая и физическая модели базы данных, а так же произведен экспорт схемы данных в MS Access 2003.

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

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

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

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

Использованная литература

Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник для студентов вузов - М.: Финансы и статистика, 2006. - 352 с.: ил.

Руководство по программному пакету ERwin http://www.eManual.ru_ 1047/1047.html.

Карпова Т. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2005. - 304 с.: ил.

Крёнке Д. Теория и практика построения баз данных. 8-е изд. СПб.: Питер, 2004. - 800с.

ПРИЛОЖЕНИЕ 1

Схема базы данных «dbmed»

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

ПРИЛОЖЕНИЕ 2

ТАБЛИЦЫ ФИЗИЧЕСКОЙ МОДЕЛИ

Таблица «Сотрудники» хранит общую информацию о работниках медицинской сферы города:

- Код сотрудника (Ключевое поле)

- ФИО

- Стаж

- Должность

Таблица «Обслуживающий персонал» является дочерней для сущности «Сотрудники» и хранит информацию о штате обслуживающего персонала медицинских учреждений:

- Код сотрудника (Ключевое поле, Внешний ключ)

- Профиль

- Оклад

Таблица «Врачи» является дочерней для сущности «Сотрудники» и хранит информацию о штате врачей медицинских учреждений:



- Код врача (Ключевое поле, Внешний ключ)

- Код категории (Внешний ключ)

- Степень

- Звание

- Операции

- Летальные

- Успешные

Таблица «Категории» хранит данные о категориях врачей:

- Код категории (Ключевое поле)

- Категория

- Льготы

Таблица «Мед учреждения» хранит общие данные о медицинских организациях города:

- Код учреждения (Ключевое поле)

- Название

- Адрес

- Штат врачей

- Штат персонала

Таблица «Поликлиники» является дочерней для сущности «Мед учреждения» и содержит конкретную информацию о поликлиниках города:

- Код учреждения (Ключевое поле, Внешний ключ)

- Код поликлиники (Ключевое поле)

- Количество кабинетов

Таблица «Больницы» является дочерней для сущности «Мед учреждения» и содержит конкретную информацию о больницах города:

- Код учреждения (Ключевое поле, Внешний ключ)

- Код больницы (Ключевое поле)

- Количество корпусов

- Количество палат

- Количество коек

Таблица «Отделения» содержит информацию об отделениях больниц:



- Код отделения (Ключевое поле)

- Код больницы (Внешний ключ)

- Номер корпуса

- Отделение

- Количество палат

- Количество коек

- Код учреждения (Внешний ключ)

Таблица «Палаты» содержит информацию о палатах, принадлежащих каждому отделению:

- Код палаты (Ключевое поле)

- Номер палаты

- Количество мест

- Код отделения (Внешний ключ)

Таблица «Персонал-учреждения» содержит информацию о принадлежности обслуживающего персонала к определенному учреждению:

- Код (Ключевое поле)

- Код сотрудника (Внешний ключ)

- Код отделения (Внешний ключ)

Таблица «Врачи-отделения» хранит информацию о принадлежности врачебного персонала к отделению определенного учреждения:

- Код (Ключевое поле)

- Код сотрудника(Внешний ключ)

- Код отделения (Внешний ключ)

Таблица «Пациенты» хранит информацию о гражданах города, имеющих медицинские полюса:

- Код пациента (Ключевое поле)

- ФИО

- Дата рождения

- Адрес

Таблица «Талоны посещения» хранит данные о посещениях пациентов определенных врачей:

- Код талона (Ключевое поле)

- Код пациента (Внешний ключ)

- Код врача (Внешний ключ)

- Время

- Кабинет

Таблица «Больные» содержит данные о пациентах, находящихся на стационарном лечении:

- Код больного (Ключевое поле)

- Код пациента (Внешний ключ)

- Дата поступления

- Код палаты (Внешний ключ)

Таблица «Лечение» несет информацию о прохождении лечения больного. Является дочерней для сущности «Больные»:

- Код больного (Ключевое поле, Внешний ключ)

- Код врача (Внешний ключ)

- Диагноз

- Срок лечения

Таблица «Операции» содержит статистику операций, проходящих в больницах города:



- Код операции (Ключевое поле)

- Дата проведения

- Код учреждения (Внешний ключ)

- Код больного (Внешний ключ)

- Код врача (Внешний ключ)

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