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

 

 

 

 

 

 

 

 

 

 

 

 

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

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

 

Введение

Цель курсовой работы - практическое освоение основных приемов и правил методологии при информационном моделировании 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	наличие карантина	логический