ВКР. Целью работы является разработка проекта программного комплекса для автоматизации учета данных работы регистратуры поликлиники. Объектом исследования является автоматизация процесса работы регистратуры поликлиники
 Скачать 3.78 Mb.
|
|
Введение Целью работы является разработка проекта программного комплекса для автоматизации учета данных работы регистратуры поликлиники. Объектом исследования является автоматизация процесса работы регистратуры поликлиники. Предметом исследования является база данных предметной области для автоматизации процесса работы регистратуры поликлиники. В проекте приведены: анализ работы регистратуры поликлиники, анализ информационных технологий для ее автоматизации, приведены контекстная и общая структурно-функциональная схема, разработана логическая и физическая модель программного комплекса для автоматизации работы регистратуры поликлиники в составе UML диаграмм: диаграммы прецедентов, диаграммы классов, диаграммы последовательностей. В специальной части проекта описан процесс создания программного комплекса для автоматизации работы регистратуры поликлиники, приведено описание интерфейса, алгоритма, модулей, классов. Результатом работы программного комплекса для автоматизации работы регистратуры поликлиники является достижение снижения трудоемкости и расширение функциональных возможностей. Экономическая эффективность работы заключается в следующем: - увеличение числа обслуживаемых пациентов; сокращение времени на оформление медицинской документации; уменьшение числа возможных человеческих ошибок. ВВЕДЕНИЕ Актуальность создания информационной системы в поликлинике обусловлена сегодня необходимостью использования больших, и постоянно растущих, объемов информации при решении диагностических, терапевтических, статистических, управленческих и других задач . Ни для кого не секрет, что большая часть приема уходит не на решение клинических вопросов, а на сопроводительную и далеко не самую основную работу - оформление поликлинических талонов и другой отчетной документации, записей в амбулаторной карте или истории болезни, назначений консультаций или обследования и т.д. Уже не вызывает сомнений, что наиболее эффективным инструментов для облегчения труда медицинских сотрудников и повышения его эффективности являются компьютерные технологии. Автоматизация способна не просто облегчить работу, она должна освободить персонал от рутины и дать ему принципиально новый инструмент, который прямо или косвенно, но приведет к сокращению нецелевого расхода интеллектуального багажа, реализации желания работать и заниматься именно медициной. Первое знакомство посетителей с поликлиникой начинается в регистратуре. Она является основным структурным подразделением по реализации приема больных в поликлинике. От организации работы регистратуры зависит в значительной степени ритмичность работы всех подразделений поликлиники, обеспечение наиболее оптимального распределения потоков посетителей и уменьшение затрат времени больных на посещение поликлиники . Целью данной работы является разработка программного комплекса для поликлиники, позволяющего повысить эффективность работы регистратуры за счет сокращения временных и трудовых затрат, также повышения качества работы. Основная деятельность регистратуры заключается в выдаче талонов на прием к врачу и запись на различные процедуры. Основными задачами регистратуры поликлиники являются: - организация предварительной и текущей записи больных на прием к врачу; - обеспечение регулирования интенсивности потока населения для равномерной нагрузки врачей; - своевременный подбор и доставка медицинской документации в кабинеты врачей, правильное ведение и хранение картотеки. Объединение информации в общее хранилище данных гарантирует обеспечение целостности данных, возможность распределенного и одновременного доступа к ним. Также создание базы данных приведет к устойчивой формализации данных и уменьшению бумажного документооборота между отделами. Экономическая эффективность работы заключается в следующем: увеличение числа обслуживаемых пациентов; сокращение времени на оформление медицинской документации; уменьшение числа возможных человеческих ошибок. 1. ОБЩАЯ ЧАСТЬ 1.1 Анализ работы регистратуры поликлиники Предметной областью данного дипломного проекта является исследование работы регистратуры поликлиники. В функции регистратуры входит: регистрация первичных пациентов; организация предварительной и неотложной записи больных на прием к врачу; обеспечение регулирования интенсивности потока пациентов. Рациональная организация приема призвана сократить время ожидания больных на прием к врачам. Управление сложным потоком больных в поликлинике обеспечивается внедрением прогрессивных форм организации труда врачебного и среднего медицинского персонала, а также путем совершенствования существующих форм работы регистратуры с учетом установленных норм нагрузок . Основным медицинским документом, отражающим состояние больного и эффективность медицинского обслуживания, является медицинская карта амбулаторного больного, которая хранится в регистратуре поликлиники. В регистратуре должно быть табло позволяющее пациентам получить исчерпывающую информацию о графике работы врачей, номере приемных кабинетов . Выходной информацией в работе регистратуры поликлиники являются: списки пациентов; талон на прием; списки врачей данных отделений; график загруженности врачей; 1.2. Актуальность создания проекта программного комплекса для работы регистратуры поликлиники В настоящее время аналогами автоматизации работы регистратуры поликлиники являются сайты с электронными регистратурами. К сожалению, иногда происходят сбои на серверах медучреждений, и тогда на сайте появляется информация о том, что сервер временно не доступен. Решить эту проблему сложнее всего: для этого нужны федеральные целевые деньги на модернизацию системы здравоохранения. Это приводит к загруженности «бумажной» работой регистратора поликлиники, что сказывается на качестве его работы: возрастает вероятность возникновения ошибок в документах, сложность контроля. С учетом вышесказанного мы видим, что данный процесс имеет определенное количество трудностей: большие затраты по времени, так как одни и те же работы приходится выполнять по несколько раз; большое количество ошибок из-за монотонности работы; большой объем отчетной информации; большой объем оформления талонов; сложность контроля. При автоматизации работы регистратуры поликлиники следует решить определенные задачи: организация хранения информации об отделениях, врачах, пациентах поликлиники; ведение документации (талонов, списков). организация информации о загруженности врачей. Это привело к необходимости создания программного комплекса, который бы соответствовал всем современным требованиям к организации пользовательского интерфейса, доступ к данным и вывода отчетных данных. 1.2 Математическая модель работы регистратуры поликлиники Проведем совершенствование бизнес-процессов работы регистратуры поликлиники, используя теорию формальных языков и грамматик. Язык понимается как множество формальных объектов в последовательности символов алфавита. Эти последовательности называют цепочками. Формальный аппарат решения задачи оптимизации бизнес-процесса основан на введении специальной параллельной атрибутной порождающей грамматики для бизнес-процесса, назначение которой заключается в умении строить любые правильные цепочки выполнения бизнес-процесса, не генерируя при этом ни одной неправильной цепочки. Работник регистратуры осуществляет запись пациентов на прием в поликлинику. Создает базу клиентов, в которых указывается номер карточки клиента и записывает на прием к врачу. Врачи распределены в зависимости от отделений: реанимационное, глазное, инфекционное и т.д. Работник регистратуры может получать информацию о количестве пациентов, загруженности врачей, количестве пациентов у каждого врача. Существует списки врачей поликлиники, пациентов, отделений в которых записаны их данные. Программный комплекс позволяет хранить и удалять данные о пациенте, враче, отделении. Программный комплекс предусматривает контроль некорректных действий пользователей, уведомляет об ошибках. Выделим следующие задачи, которые будут автоматизироваться: получение данных о пациенте, загруженности врача, формирование талона на прием. В состав регистратуры поликлиники входят данные об отделениях, врачах и пациентах. Работник регистратуры просматривает информацию о загруженности врачей, отделениях поликлиники, графике приема. После просмотра информации о загруженности врачей работник регистратуры выбирает отделение, в которое нужно обратиться пациенту и после просмотра информации о врачах, их графике приема выбирает подходящего врача. После выбора данных работник регистратуры выдает талон на прием, в котором отображаются дата и время приема, выбранные отделение, врач, номер кабинета В настоящее время одним из механизмов развития сферы регионального здравоохранения является реализация инновационно-инвестиционных социальноэкономических проектов, направленных на поддержку малого предпринимательства в этой сфере. Современные медицинские организации производят и накапливают большие объемы информации, как о сотрудниках, так и о пациентах. Врачам нужно следить за посещением пациентов, а пациентам – иметь возможность записаться на прием, не прилагая значительных усилий. От того насколько эффективно эта информация используется врачами, руководителями, управляющими органами, зависит качество медицинской помощи, общий уровень жизни населения, уровень развития страны в целом и каждого ее территориального субъекта в частности. Поэтому необходимость использования больших, и при этом еще постоянно растущих, объемов информации при решении диагностических, терапевтических, статистических, управленческих и других задач обуславливает сегодня создание информационных систем в медицинских учреждениях. Существующие автоматизированные системы учета пациентов например ориентированы на крупные медицинские учреждения (больницы, поликлиники, санатории) и с точки зрения малого бизнеса обладают рядом недостатков, основным из которых является избыточность функций и, как следствие, сложность в освоении и высокая стоимость. Целью работы является разработка информационной системы (ИС) поддержки работы регистратуры малого предприятия сферы здравоохранения (частной поликлиники), оказывающего медицинские услуги населению. Проектирование информационной системы На основе анализа средств моделирования бизнес–процессов было решено использовать среду BpWin, т.к. она имеет понятный интерфейс и поддерживает три методологии моделирования: IDEF0, IDEF3, и DFD, которые было решено использовать для моделирования бизнес–процессов работы регистратуры. Сначала была создана контекстная диаграмма «Работа регистратуры поликлиники» в методологии IDEF0. В управление вошли: 1. Инструкции. 2. Федеральные законы. Механизмами осуществления процесса являются: 1. Пользователь. 2. Компьютер. Входными данными являются данные пользователя. Результатом работы системы будут: талоны и карточки.  Контекстная диаграмма IDEF0 После описания контекстной диаграммы проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема, при необходимости, разбивается на более мелкие и так далее до достижения нужной степени подробности. Контекстная диаграмма была разбита на 4 блока 1. Зарегистрироваться в системе. 2. Войти в систему. 3. Получить информацию. 4. Использовать функции системы.  Рисунок 2 – Декомпозиция контекстной диаграммы В свою очередь блок «Войти в систему» был декомпозирован в нотации IDEF3 на следующие работы 1. Ввести данные. 2. Проверить логин и пароль. 3. Определить полномочия. 4. Вывести ошибку. При декомпозиции процессы был использован один перекресток вида исключающее ИЛИ. После ввода логина и пароля, система проверяет его достоверность и в зависимости от этого либо определяет полномочия в системе, либо выводит ошибку и дает возможность заново ввести данные. Рисунок 3 – Декомпозиция блока «Войти в систему» На рисунке 4 представлена диаграмма декомпозиции блока «Получить информацию» в нотации DFD. Она содержит хранилище данных «БД», внешнюю сущность «Пользователь» и три блока: 1. Получение данных пользователя. 2. Формирование списка доступных услуг. 3. Вывод информации пользователю. С внешней сущностью «Пользователь» процесс связан исходящим сигналом «Информация об услугах». В хранилище «БД» поступают данные пользователя, а выходит список доступных услуг. На входе в процесс у нас информация о пользователе, а на выходе информация об услугах. Декомпозиция блока «Получить информацию» В свою очередь блок «Использовать функции системы» декомпозирован в нотации IDEF3. – Декомпозиция блока «Использовать функции системы» Диаграмма содержит работы: 1. Выбор функции. 2. Запись на прием. 3. Формирование талона. 4. Создание карточки. 5. Заполнение данных. 6. Просмотр расписания. 7. Запись в БД. 8. Завершение работы. Использовались три перекрестка вида исключающее ИЛИ. Они означают, что после завершения одного предыдущего процесса только один процесс запускается. Построенные модели бизнес–процессов работы регистратуры дают достаточную информацию для дальнейшего проектирования моделей базы данных, а так же выполнения программной реализации информационной системы 1.2 Проектирование структуры приложения Структура приложения «Регистратура поликлиники» представлена на рисунке 2. Пользовательский интерфейс будет обеспечивать информативность выводимой на экран информации и удобство ее вывода и обработки. База данных будет хранить все пользовательские данные: данные всех таблиц и справочников [6]. Структуру можно разделить на несколько взаимосвязанных объектов: блок авторизации обеспечивает защиту от несанкционированного доступа; главная форма позволяет попасть в блоки «Формы» и «Отчеты»; форма «Формы» позволяет попасть в формы «Талон», «График работы», «Карточка», «Справочники»; форма «Карточка» предназначена для заполнения карточки пациента поликлиники и перехода в форму «Карточки пациентов»; форма «Карточки пациентов» предназначена для отображения данных карточек всех пациентов; форма «Талон» предназначена для ввода данных талона на прием; форма «График работы» предназначена для просмотра и заполнения графика работы всех врачей поликлиники; форма «Справочники» предназначена для просмотра или заполнения данных всех справочников: «Врачи», «Часы приема», «Время приема», «Специализация», «Номер стеллажа», «Номер кабинета»; форма «Отчеты» позволяет выбрать нужный отчет: «Врачи», «Талоны», «Графики работы».  Рисунок 2. Структура приложения «Регистратура поликлиники»Назначение форм справочников: форма «Врачи» содержит данные на всех врачей поликлиники; форма «Часы приема» содержит данные о приемных часах врача; форма «Время приема» содержит данные о часах приема по дням недели; форма «Специализация» содержит данные о специальности врача; форма «Номер стеллажа» содержит данные о буквенном обозначении стеллажа, на котором хранится бумажная карточка пациента; форма «Номер кабинета» хранит данные о номерах кабинетов врачей. Следующий шаг проектирования – это разработка схемы алгоритма работы интерфейса приложения. Алгоритм представлен на рисунке 3. Алгоритм работы приложения можно разделить на пять отдельных алгоритмов по сфере деятельности: выбор производится на Главной форме, после авторизации. Алгоритм «Справочники» начинается с выбора справочника или возврата на Главную страницу. Если справочник выбран и просмотрен, то для каждого справочника нужно вновь осуществить выбор: возврат на Главную форму или редактирование справочника. После редактирования можно вернуться на Главную форму без сохранения или сохранить внесенные изменения. После сохранения можно вернуться на Главную форму или выйти из программы. Алгоритм «Карточка» начинается с выбора: заполнение новой карточки или просмотр всех карточек пациентов. При заполнении карточки нового пациента, выбирается форма «Карточка» и заполняются данные, затем можно выбрать: вернуться на Главную форму без сохранения или сохранить. После сохранения также осуществляется выбор: выход из алгоритма «Карточка» или просмотр новой карточки в списке всех карточек. Алгоритм «Талон» начинается с заполнения формы талона, затем можно выбрать: вернуться на Главную форму без сохранения или сохранить талон. После сохранения можно вернуться на Главную форму или выйти. Алгоритм «График работы» начинается с заполнения формы графика работы, затем можно выбрать: вернуться на Главную форму без сохранения или сохранить график. После сохранения можно вернуться на Главную форму или выйти из программы. Алгоритм «Отчеты» позволяет выбрать нужный отчет, просмотреть его и затем осуществить выбор: распечатать отчет, сохранить его в нужном формате или вернуться к выбору отчетов. После распечатки или сохранения нужного отчета можно вернуться на Главную форму или выйти из программы.  Рисунок 3. Схема алгоритма работы приложения После определения структуры приложения, можно приступать к проектированию структуры базы данных. 1.3 Проектирование структуры базы данных Концептуальная модель базы данных – это модель предметной области, не ориентированной на определенную СУБД, она отражает предметную область в виде совокупности информационных объектов и их структурных связей. Различают концептуальные модели двух видов: объектно-ориентированные и семантические модели. Семантические модели отображают значения реальных сущностей и их отношений. Одной из наиболее популярных семантических моделей данных является модель сущность-связь (ER-модель). Для моделирования структуры данных можно использовать ER-диаграммы. Основными понятиями ER-диаграммы являются сущность, связь и атрибут [9]. Сущность – это реальный или виртуальный объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. Каждая сущность должна иметь уникальный идентификатор и содержать один или несколько атрибутов, однозначно идентифицирующих каждый экземпляр сущности. В базе данных можно выделить следующие сущности: «Клиент», «Врач», «График работы», «Талон». Связь – это соединение двух сущностей, при котором каждый экземпляр одной сущности, может быть связан с произвольным количеством экземпляров другой сущности и наоборот. Различают три типа связей между сущностями: один к одному (каждой записи первой таблицы соответствует только одна запись другой таблицы, «1:1»); один ко многим (каждой записи первой таблицы соответствует несколько записей другой таблицы, «1:М»); многие ко многим (каждой записи обеих таблиц соответствует несколько записей других таблиц, «М:М»). В базе данных приложения используются связи двух видов: один ко многим («Клиент» – «Талон»; «Врач» – «Клиент»; «Врач» – «График работы») и многие ко многим («График работы» – «Талон»). Связь представляется в виде линии, связывающей две сущности, и указываются правила поддержания связи. Атрибут – это характеристика сущности, значимая для рассматриваемой предметной области. В ER-диаграмме список атрибутов сущности отображается в виде строк внутри прямоугольника, обозначающего сущность. Для базы данных приложения «Регистратура поликлиники» примерами атрибутов являются: фамилия, имя, отчество клиента. На рисунке 4 приводится ER-диаграмма базы данных, прямоугольниками показаны типы сущностей с атрибутами, линиями – связи, ромбами – типы связей между сущностями. Работает КЛИЕНТ Код клиента Ф.И.О Адрес Телефон Диагноз ВРАЧ Код врача Ф.И.О Специализация ТАЛОН Код талона Ф.И.О врача Специализация Дата/время приема Получает ГРАФИК РАБОТЫ Код графика Ф.И.О врача Специализация Дата/время приема Лечит М Относится Проанализируем связи между сущностями: «Клиент» наблюдается у одного участкового врача, но у данного врача может быть много клиентов, следовательно, используется связь: «один ко многим»; «Клиент» может получить несколько талонов к разным специалистам по направления участкового врача – связь «один ко многим»; «Врач» работает по определенному одному графику – связь «один ко многим»; согласно «Графика работы» может быть выдано множество талонов к одному узкому специалисту – связь «многие ко многим». Для генерации структуры базы данных необходимо преобразовать концептуальную модель в логическую модель, состоящая из множества экземпляров различных типов данных, структурированных в соответствии с требованиями СУБД [11]. Следовательно, следующим этапом разработки является выбор конкретной системы управления базами данных и среды программирования для разработки интерфейса приложения. ГЛАВА 2. ПРОЕКТИРОВАНИЕ ИС 2.1 Логическая модель БД Система хранит информацию о врачах, пациентах, заболеваниях, учреждениях. Информационная система должна предоставлять данные по отдельным запросам: - информацию о враче (фамилия, специализация, стаж, оклад, совместительство); - данные о больном ( фамилия, возраст, адрес, учреждение, место работы, хронические заболевания, прививки, последнее обращение к врачу); - данные о учреждении (наименование, адрес, количество детей, наличие карантина, выявленные инфекционные заболевания, дата последнего профилактического обследования). Кроме того, периодически должны выдаваться следующие ведомости: - список учреждений, в которых зафиксированы инфекционные заболевания; - статистический отчет по заболеваниям; - отчет по заболеваемости в учебных заведениях. ЭТАП 1. Анализ предметной области и формулирование информационных требований. Предметная область: информационные данные о поликлинике. Задание: Спроектировать базу данных для информационной системы " поликлиника". Описание постановки задачи Создается информационная система «поликлиника». Информационная система должна хранить информацию о врачах, пациентах, заболеваниях, наличии инфекции в учреждениях. Система должна представлять информацию по следующим запросам: - информация о враче; - информация о пациенте; - информация о учреждении. Система должна обеспечивать выдачу следующих выходных документов: - список учреждений, в которых зафиксированы инфекционные заболевания; - статистический отчет по заболеваниям; - отчет по заболеваемости в учебных заведениях. Формы выходных документов по данным информационным требованиям должны иметь следующий вид. Запрос 1: Запрос информации о враче
Запрос 2: Запрос информации о больном
Запрос 3: Запрос информации о учреждении
Документ 4: Отчёт по заболеваемости в учебных заведениях
Документ 5: Отчет по учреждениям, в которых зафиксированы инфекционные заболевания
Документ 6: Статистический отчет по заболеваниям.
ЭТАП 2. Инфологическое проектирование базы данных 1. Поэлементный состав каждого информационного требования в виде перечня идентификационных реквизитов. Информационное требование 1: ФИО__ВР - фамилия, имя, отчество врача; СПЕЦ - специализация врача; СТАЖ - стаж врача; ОКЛАД - оклад врача, СОВМЕСТ - совместительство врача. база модель больница Информационное требование 2: N_КАРТ - номер карточки пациента; ФИО_ПАЦ - ФИО пациента; ВОЗР - возраст пациента; АДР - адрес пациента; МЕСТ_РАБ_РОД - место работы родителей пациента; ХРОН_ЗАБОЛ - перенесенный пациентом хронические заболевания; ПРИВИВКИ, ПОСЛЕДН_ОБР - последнее обращение пациенты в поликлинику; КОД_УЧР - код учреждения. Информационное требование 3: КОД_УЧР, Н_УЧР - название учреждения, АДР_УЧР - адрес учреждения, КАРАНТИН - наличие карантина в данном лучреждении, ЗАКРЕПЛ_ВРАЧ - закрепленный за данным учреждением врач, ДАТА_ПОСЛЕД_ПРОФ_ОБСЛ - дата последнего профилактического обследования учреждения, КОЛ_ДЕТ - количество детей, обследуемых в учреждении. Информационное требование 4: КОД_УЧР, Н_УЧР, КОЛ_БОЛ - количество заболевших. Информационное требование 5: Н_УЧР, ИНФ_ЗАБОЛ - инфекционные заболевания. Информационное требование 6: Н_ЗАБОЛ - название заболевания, КОЛ_БОЛ. Перечень сущностей и их атрибутов с выделенными первичными ключами Проанализировав состав элементов данных по всем информационным требованиям, выделим среди них сущности, характеризующие предметную область: Врач - содержит информацию о врачах, работающих в данной поликлинике; КАРТА Пациента - объединяет сведения о детях, проходящих обследование в данной поликлинике; Больничный лист - содержит данные о заболеваниях, назначенном лечении и необходимых лекарствах, назначенных пациенту. Учреждение - объединяет данные о учреждениях, к которым относятся пациенты. Информационная структура взаимосвязей сущностей предметной области За каждым учреждением закреплен врач, причем один врач, может быть закреплен за несколькими учреждениями. Таким образом, между сущностями «врач» и «учреждение» устанавливается связь 1:N. Название связи - «Закрепленный врач». В одном учреждении числится много детей, которые потенциально могут стать пациентами. Поэтому между сущностями «учреждение» и «пациент» устанавливается связь 1:N. Название связи - «Место обучения или содержания». Сущность «Карта пациента» связана с сущностью «больничный лист» также отношением 1:N. Определенный пациент соответственно может болеть несколько раз. Связь «Карта лечения».
Таблица 1.Информационная структура взаимосвязей объектов предметной области "ПОЛИКЛИНИКА" 4. Концептуальная инфологическая модель предметной области «ПОЛИКЛИНИКА». C учетом описания элементного состава каждой из сущностей концептуальную модель рассматриваемой предметной области можно представить в следующем виде. Рисунок 1 - ER- диаграмма предметной области «поликлиника» ЭТАП 3. Логическое проектирование базы данных. Определим атрибуты каждой сущности и выделим ключевые атрибуты, которые будем обозначать выделением <>. ВРАЧ: <КОД_ВР>, ФИО__ВР, СПЕЦ, СТАЖ, ОКЛАД, СОВМЕСТ. КАРТА ПАЦИЕНТА: БОЛЬНИЧНЫЙ ЛИСТ: УЧРЕЖДЕНИЕ: <КОД_УЧР>, Н_УЧР, АДР_УЧР, КАРАНТИН, ЗАКРЕПЛ_ВРАЧ, ДАТА_ПОСЛЕД_ПРОФ_ОСМ, ВЫЯВЛ_ИНФ_ЗАБОЛ. Основным этапом логического проектирования концептуальной модели в реляционную является нормализация полученных на этапе инфологического проектирования отношений. Процесс нормализации отношений включает в себя процессы преобразования отношений в 1НФ, 2НФ и 3НФ. Сущность «врач» представлена следующим набором реквизитов: <код врача>, ФИО врача, специальность, оклад, совместительство. Это отношение соответствует 1НФ. Для приведения его ко 2НФ и 3НФ необходимо преобразовать это отношение, исключив неполные функциональные зависимости не ключевых реквизитов от ключа. Результатом нормализации отношения «Врач» будет следующий перечень отношений: ВРАЧ: <КОД_ВР>, ФИО__ВР, КОД_СПЕЦ, СТАЖ. Профиль врача: <код_спец>, СПЕЦ, ОКЛАД, СОВМЕСТ. Сущность «профиль врача» будет связана с сущностью «врач» отношением 1:?, поскольку один профиль могут иметь несколько врачей. Аналогично приведем отношение «больничный лист», находящееся в 1НФ, ко 2НФ и 3НФ. Сущность «больничный лист» имеет следующий набор атрибутов: <номер больничного листа>, № карточки, дата открытия, дата закрытия, название заболевания, инфекционное заболевание, лечение, лекарства. Результатом нормализации данного отношения будет следующий перечень отношений: БОЛЬНИЧНЫЙ ЛИСТ: Справочник заболеваний: <Код_забол>, НАЗВ_ЗАБОЛ, ИНФ_ЗАБОЛ, ЛЕЧЕНИЕ, ЛЕК_ВА. Сущность «Справочник заболеваний» будет связана с сущностью «больничный лист» отношением 1:?, поскольку несколько пациентов могут иметь одно и тоже заболевание . Сущности «пациент», «учреждение» с их набором реквизитов в концептуальной модели данных можно рассматривать как отношения в 3НФ с соответствующими ключами. Окончательный перечень нормализованных отношений в реляционной модели предметной области «больница» показан в таблице 2.
 Логическая модель БД поликлиники | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||