ИСС “Поликлиника”

 

 

 

 

 

 

 

 

 

 

 

 

Курсовая работа

ИСС “Поликлиника” 
Оглавление

 

Введение

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

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

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

Пояснительная записка сотавлена в таком порядке:

- ознакомление  с описанием предметной области;

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

Для отладки работы использована СУБД Microsoft Access.

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

- проведение нормализации;

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

- определение целостности БД;

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

 

1 Описание предметной области. Постановка задачи

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

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

2 Функциональная модель деятельности поликлиники

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

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

2. Основные элементы модели процесса.

Название проекта - Отдел регистратуры поликлиники.

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

Точка зрения - Регистратура.

Инструментарий - средства пакета MS Office, Bpwin 2-4.1.

Список данных:

Главным бизнес-процессом проектируемой системы является процесс автоматизации регистратуры поликлиники.

На вход поступают следующие данные:

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

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

• Сервер БД.

Механизмами исполнения процесса являются:

• Клиенты.
• Система.

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

• Номер заявки.
• Прайс лист
• Изменённая БД.

3. Дерево функций

4. Словарь:

Заявка – запрос записи на прием к врачу.

Клиент – пациент поликлиники.

Прайс-лист – список услуг, предоставляемых поликлиникой, и их цен.

5. Диаграммы процессов.

Для построения диаграммы потоков данных использована нотация Гейна-Сарсона.

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

Рис.1 Диаграмма потоков данных

Диаграмма верхнего уровня на основе методологии IDEF3 «Автоматизация регистратуры поликлиники» представлена на рисунке 2.

 

 

Рисунок 2 – Диаграмма верхнего уровня на основе методологии IDEF3 «Автоматизация регистратуры поликлиники»

Основными бизнес-функциями процесса «Автоматизации регистратуры поликлиники» будут:

1. Записаться на прием.
2. Редактировать заявку.
3. Отозвать заявку.
4. Таблица цен и услуг.
5. Внесение данных в БД.

Декомпозиция верхнего уровня на основе методологии IDEF3 «Автоматизация регистратуры поликлиники» представлена на рисунке 3.

 

Рисунок 3 – Декомпозиция верхнего уровня на основе методологии IDEF3 «Автоматизация регистратуры поликлиники»

Модель IDEF3

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

На рис.5 представлено отображение процесса проверки заявки на наличие ошибок с точки зрения OSTN диаграммы. На данной диаграмме рассматривается объект «заявка» и его трансформация в процессе составления записи на приём на основе проверки расписания врачей в оформленную заявку клиента.

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

 

 

 

 

Рис.5 Отображение процесса проверки заявки на наличие ошибок

3 Сценарии взаимодействия  объектов предметной области

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

Название варианта	Создание заявление клиента на прием к врачу
Цель Действующие лица Краткое описание     Тип варианта	Получение прайс-листа цен и услуг Регистратор Создание заявления на выбор услуги, на приём к врачу предполагает выбор клиента, проверка полученных данных, внесение изменений и печать результата Основной

 

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

 

 

Рис.6 Условные обозначения диаграмм вариантов использования

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

Диаграмма состояний

Диаграмма состояний показывает состояния объекта, возможные переходы, события или сообщения, вызывающие каждый переход.

Диаграмма состояний представлена на рис.7.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис.7 Диаграмма состояний

 

4 Построение информационно-логической (инфологической) модели

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

Основные объекты:

1. пациенты;
2. врачи.

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

Рис.8 Схема логической модели “Поликлиника ”

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

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

• Врачи.
• Пациенты.
• Учреждения.
• Врач в учреждении.
• Учет постуления, выписок.

5 Представление инфологической модели с использованием ER-диаграмм

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

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

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

Рассмотрим связи между сущностями и построим ER-диаграмму (рис. 9).

 Характеристическая сущность (характеристика) – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства.

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

К стержневым сущностям можно отнести:

1. Пациент (Номер медицинской карты, ФИО, Пол, дата рождения, Прививки) - Эта сущность отводится для хранения основных сведений о пациентах.
2. Врачи (Код врача, ФИО, Специальность, Стаж, Оклад, Совместительство) - Эта сущность отводится для хранения основных сведений о врачах.
3. Врач в учреждении (Название учреждения, Врач)
4. Учреждения (Код учреждения, Название учреждения, Адрес, Количество пациентов, Наличие карантина, Выявленные инфекционные заболевания)
5. Учет поступления, выписок (Номер записи, Номер медицинской карты, ФИО пациента, Заболевание, Дата поступления, Дата выписки)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис.9  ER диаграмма базы данных

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

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

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

Таблица 4 - Сущность «Пациенты»

№	Имя поля	Тип поля	Примечания
1	Код пациента	счетчик	Первичный ключ, для уникальности каждого пациента
2	ФИО пациента	текстовый
3	Пол	Текстовый
4	Дата рождения	Дата/Время
5	Прививки	Текстовый

Таблица 5 - Сущность «Врачи»

№	Имя поля	Тип поля	Примечания
1	Номер_врача	Счётчик	Первичный ключ, для уникальности каждого врача
2	ФИО врача	текстовый
3	Специальность	текстовый
4	Стаж	числовой
5	Оклад	числовой
6	Совместительство	текстовый

Таблица 6 - Сущность «Учреждения»

№	Имя поля	Тип поля	Примечания
1	Номер	счётчик	Первичный ключ, для уникальности каждого учреждения
2	Название учреждения	текстовый
3	Адрес	текстовый
4	количество пациентов	числовой
5	наличие карантина	логический

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

Таблица 7 - Учет поступления, выписок

№	Имя поля	Тип поля	Примечания
1	Номер медицинской карты	счетчик	Первичный ключ, для уникальности каждого пациента
2	номер записи	числовой
3	ФИО пациента	дата/время
4	Заболевание	текстовый
5	Дата поступления	дата/время
6	Дата выписки	дата/время

 

Таблица 8 - Врач в учреждении

№	Имя поля	Тип поля	Примечания
1	Название учреждения	числовой
2	Врач	числовой

 

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

Изобразим схему проектируемой базы данных «Салон красоты» (рис.10) в формате, в котором она выглядит в окне схемы данных приложения Microsoft Access.

Рис.10 Схема базы данных

 

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

Структура таблицы «Пациенты»:

Структура таблицы «Врачи»:

 

Структура таблицы «Учреждения»:

 

Структура таблицы «Врач в учреждении»:

 

 

Структура таблицы «Учет выписок»:

 

Таблицы с записями представлены на рисунках 11-15:

Рис.11 Таблица «Пациенты»

Рис.12 Таблица «Врачи»

Рис.13 Таблица «Врач в учреждении»

 

Рис.14 Таблица «Учреждения»

Рис.15 Таблица «Учет выписок»

Созданы запросы разного типа:

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

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

Таблица 9 - «Функции и выполняемые операции»

Функция	Выполняемая операция
Sum	Суммирование значений определенного поля
Avg	Вычисление среднего значения
Min	Вычисление минимального значения
Мах	Вычисление максимального значения
Count	Вычисление количества записей в определенном поле
First	Определяется первое значение в указанном поле
Last	Определяется последнее значение в указанном поле
StDev	Вычисляется стандартное отклонение значений данного поля
Var	Вычисляется вариация значений данного поля

 

Перечень запросов, применявшихся в данной базе данных приведен ниже.

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

SQL-запрос:

SELECT [Сведения о врачах].Фамилия, [Сведения  о врачах].Имя, [Сведения о врачах].Отчество, [Сведения о врачах].Специальность, [Учет поступления, выписок].[ФИО  пациента], [Учет поступления, выписок].[Дата  поступления], [Учет поступления, выписок].[Дата  выписки]

FROM ([Сведения о врачах] INNER JOIN [Сведения  о пациенте] ON [Сведения о врачах].[Код  врача] = [Сведения о пациенте].[Код  врача]) INNER JOIN [Учет поступления, выписок] ON [Сведения о пациенте].[Номер  медицинской карты] = [Учет поступления, выписок].[Номер медицинской карты]

WHERE ((([Сведения о врачах].Специальность)=[введите  специальность врача]));

Рис.16 Запрос «Врачи и их пациенты»

2. Запрос «Время пребывания в больнице» позволяет узнать продолжительность нахождения пациента на стационарном лечении.

SQL-запрос:

SELECT [Учет поступления, выписок].[ФИО  пациента], [Учет поступления, выписок]![Дата  выписки]-[Учет поступления, выписок]![Дата  поступления] AS [Врея пребывания  в больнице (дни)], [Учет поступления, выписок].[Дата поступления], [Учет  поступления, выписок].[Дата выписки]

FROM [Учет поступления, выписок];

Рис.17 Запрос «Время пребывания в больнице»

 

3. Запрос «Пациенты-женщины» отображает пациентов женского пола

SQL-запрос:

SELECT [Сведения о пациенте].Фамилия, [Сведения  о пациенте].Имя, [Сведения о пациенте].Отчество

FROM [Сведения о пациенте]

WHERE ((([Сведения о пациенте].Пол)="ж"));

Рис.18 Запрос «Пациенты-женщины»

4. Запрос «Учет пациентов» отображает  данные пациентов.

SQL-запрос:

SELECT [Сведения о пациенте].Фамилия, [Сведения  о пациенте].Имя, [Сведения о пациенте].Отчество, [Учет поступления, выписок].[Номер  медицинской карты], [Учет поступления, выписок].Заболевание, [Учет поступления, выписок].[Дата поступления], [Учет  поступления, выписок].[Дата выписки]

FROM [Сведения о пациенте] INNER JOIN [Учет  поступления, выписок] ON [Сведения о  пациенте].[Номер медицинской карты] = [Учет поступления, выписок].[Номер  медицинской карты];

Рис.19 Запрос «Учет пациентов»

5. Запрос «Пациенты, лежавшие неоднократно» выводит пациентов, которые лежали в больнице более одного раза.

SQL-запрос:

SELECT [Учет пациентов].[Номер медицинской  карты], [Учет пациентов].[Фамилия], [Учет  пациентов].[Имя], [Учет пациентов].[Отчество], [Учет пациентов].[Заболевание], [Учет  пациентов].[Дата поступления], [Учет  пациентов].[Дата выписки]

FROM [Учет пациентов]

WHERE ((([Учет пациентов].[Номер медицинской  карты]) In (SELECT [Номер медицинской  карты] FROM [Учет пациентов] As Tmp GROUP BY [Номер медицинской карты] HAVING Count(*)>1 )))

ORDER BY [Учет пациентов].[Номер медицинской  карты];

 

Рис.20 Запрос «Пациенты, лежавшие неоднократно»

6. Запрос «Пациенты-пенсионеры» отображает всех пациентов, достигших пенсионного возраста.

SQL-запрос:

SELECT [Сведения о пациенте].[Номер медицинской  карты], [Сведения о пациенте].Фамилия, [Сведения о пациенте].Имя, [Сведения  о пациенте].Отчество, [Сведения о  пациенте].Пол, [Сведения о пациенте].[Дата  рождения], [Сведения о пациенте].Прививки

FROM [Сведения о пациенте]

WHERE ((([Сведения о пациенте].[Дата рождения])<#12/31/1960#));

Рис.21 Запрос «Пациенты-пенсионеры»

7. Запрос «Врачи по спецальности» позволяет, путем ввода специальности при запуске запроса определить врачей.

SQL-запрос:

SELECT [Сведения о врачах].[Код врача], [Сведения о врачах].Фамилия, [Сведения  о врачах].Имя, [Сведения о врачах].Отчество, [Сведения о врачах].Специальность, [Сведения о врачах].Стаж, [Сведения  о врачах].Совместительство

FROM [Сведения о врачах]

WHERE ((([Сведения о врачах].Специальность)=[Введите  специальность врача]));

При выполнении запроса появляется окно для ввода параметра:

Рис.22 Окно для ввода параметра запроса

Рис.23 Запрос «Подбор врачей по специальности»

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

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

Любая форма строится на основе Access-таблицы или запроса. Имена полей извлекаются из спецификации таблицы, а поля в форме можно расположить по своему усмотрению. На основе одной таблицы можно построить несколько форм.

В Access 2007 существует несколько способов создания форм:

Таблица 10 - Способы создания форм

Автоформа	Автоматическое создание формы с использованием одного из стандартных шаблонов. Это наиболее простой и быстрый способ создания формы.
Мастер форм	Создание формы с помощью мастера; в зависимости от назначения формы мастер предлагает на выбор стандартные шаблоны и стили оформления.
Конструктор	Создание формы на основе пустого бланка при помощи инструментальных средств конструктора форм. Также предназначен для обработки готовых форм.
Сводная диаграмма	Создание формы с диаграммой на основе выбранных полей таблицы.
Сводная таблица	Создание сводной таблицы Microsoft Excel на основе таблиц или запросов Access XP

 

Существует несколько разновидностей автоформ:

Форма — создание формы для ввода данных по одной записи за раз

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

Несколько элементов — создание формы, в которой записи отображаются в виде таблицы, при этом каждая запись занимает отдельную строку

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

Перечень форм, применявшихся в данной работе приведен ниже:

Рис.24 Форма «История болезни»

Форма «История болезни» показывает данные больного, диагноз и дату поступления с данным диагнозом в больницу.

Рис.25 Форма «Сведения о врачах»

Форма «Сведения о врачах» представлена в ленточном виде и показывает ФИО врача и его специальность.

Рис.26 Форма «Сведения о пациенте»

Форма «Сведения о пациенте» представляет собой ленточный тип формы, показывающей данные о пациенте.

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

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

Использование отчетов имеет следующие достоинства:

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

Отчеты можно создавать двумя способами:

• при помощи мастеров отчетов/автоотчетов;
• «вручную».

Рис.27 Отчет «Врачи по специальности»

Отчет «Врачи по специальности» построен в виде макета «структура» с уровнем группировки по специальности врача и отображает всех врачей поликлиники по конкретной сепциальности.

Рис.28 Отчет «Пациенты-пенсионеры»

Отчет «Пациенты-пенсионеры» показывает всех пациентов пенсионного возраста.

Рис.29 Отчет «Учет поступления, выписок»