Создание информационной системы "Деятельность больницы"

 

Сущность  5– Курс лечения;

• Id- врача
• Регистрационный номер приема
• Наименование заболевания
• Описание курса

 

Сущность 6 –  Специализация врача;

• Код специализации врача
• Название
• Id- врача

Сущность 7 – Id – Адрес пациента

• Индекс
• Город
• Улица
• Дом.

 

 

2.2.Нормализация отношений

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

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

внимание на те ограничения, которым должна удовлетворять БД в процессе создания, независимо от ее наполнения данными. Приведение структуры БД в соответствие этим ограничениям – это и есть нормализация.   

Приведение отношения  к 1НФ – довольно простая операция. Мы должны просмотреть схему отношения  и разделить составные атрибуты на различные строки/столбцы.

Определив каждую сущность, можно определить набор ее атрибутов.

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

• № страхового полиса пациента
• Id-пациента
• Фамилия пациента
• Имя пациента
• Отчество пациента
• Серия паспорта
• № паспорта пациента
• История болезни
• Группа крови
• Id_адрес
• Регистрационный номер приема

Каждый пациент зарегистрирован  по определённому месту жительства: Индекс

• Город
• Улица
• Дом.

Если пациент приходит  в больницу ему назначают приём, при этом указывая:

• Регистрационный номер приема
• Id- пациента
• Id- врача
• Дата приема
• № страхового полиса пациента

Врач имеет параметры:

• Id-врача
• Серия паспорта
• № паспорта
• Специализация
• Код специализации
• № лицензии
• Дата рождения
• Имя врача
• Фамилия врача
• Отчество врача

 При этом врач имеет специализацию, которая  обладает следующим набором сведений:

• Код специализации врача
• Название
• Id- врача

На данном этапе структура  отношений находится в первой нормальной форме (1NF),т.к. значения атрибутов  атомарные и все не ключевые атрибуты функционально зависят от ключа.

Попробуем привести отношения  ко второй нормальной форме (2NF).

Для этого выделим следующие  функциональные зависимости:

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

(Регистрационный номер приема, Id- пациента, Id- врача, дата приема, № страхового полиса пациента)

Первичным ключом отношения  может быть (Регистрационный номер приема, № страхового полиса пациента), который однозначно определяет каждую строку отношения. С другой стороны, атрибуты ФИО зависит только от части первичного ключа - ИНН пациента, следовательно, для приведения данного отношения ко второй нормальной форме следует разбить его на проекции.

Таким образом у нас определятся два следующие отношения:

(№ страхового полиса пациента, Фамилия, Имя, Отчество)

(Регистрационный номер приема, Id- пациента, Id- врача, Дата приема)

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

Теперь попробуем привести отношение к третьей  нормальной

форме (3NF).

Рассмотрим отношение, связывающее  врача с пациентом:

• (Фамилия пациента, Имя пациента, Отчество пациента, (№ страхового полиса пациента, дата приема, Id- пациента, Id- врача, Фамилия врача, Имя врача, Отчество врача, Код специализации, № лицензии)

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

№ страхового полиса пациента → Фамилия пациента, Имя пациента, Отчество пациента

№ страхового полиса пациента → Id- пациента

№ страхового полиса пациента → Id- врача

№ лицензии врача → Код специализации врача

№ лицензии врача → Фамилия врача, Имя врача, Отчество врача

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

(№ страхового полиса пациента, Фамилия пациента, Имя пациента, Отчество пациента, дата приема)

(Id- врача, № лицензии врача, Код специализации врача, Фамилия врача, Имя врача, Отчество врача)

(Регистрационный номер приема, № страхового полиса пациента, дата приема)

Первичные  ключи  отношений  выделены.

2.3. Разработка даталогической модели данных «Деятельность больницы»

Даталогическая модель была реализована через All Fusion ERWIN Data Modeler путем определения сущностей, связей и атрибутов (рис.10.).

В данной ER-модели присутствует 7 сущностей с различного рода атрибутами. («Пациент», «Врач», «Специализация», «Регистратура», «Приём», «Курс лечения», «Id-адрес»)

Рис.10. Даталогическая модель данных «Деятельность больницы»

 

2.4. Разработка физической модели данных «Деятельность больницы» для СУБД Access 2010

ERwin - CASE-средство проектирования баз данных от фирмы Computer Associates. ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД.

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

Рис.11. Физическая модель  данных, созданная All Fusion ERWIN Data Modeler для СУБД Access 2010

 Разработка физической модели данных «Деятельность больницы» для СУБД SQL Server 2010

Логическая архитектура выделяет, прежде всего, вопросы взаимодействия компонент системы, интерфейсы и используемые протоколы. Это представление позволяет эффективно организовать параллельную разработку. Физическая реализация, которая описывает привязку к конкретным узлам размещения, типам оборудования, характеристикам окружения, таким как, например, используемые операционные системы и т.п. Реализация данной модели осуществляется через Microsoft Office Access 2010 и SQL, таким образом, физическая модель приобретает некоторые изменения связанные со структурными изменениями атрибутов (рис.11.а).

Рис.11.а. Физическая модель данных, созданная с помощью CA ERwin data modeler  для СУБД SQL Server 2010

Листинг, представленный ниже реализован с помощью CA ERwin Data Modeler, подключение осуществлялось через ODBC/Generic (Приложение №1). Генерация кода осуществлялась через главное меню: Tools -> Forward Engineer ->Schema generation. Далее выбираем в окне кнопку Preview. И получаем итоговой листинг.

2.5.Архитектура информационной системы

Клиент - сервер – одна из наиболее динамично развивающихся  технологий построения многоуровневых ЭИС.

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

Клиент взаимодействует  с сервером по строго определенному  алгоритму:

·        установление связи с сервером;

·        запрос конкретного вида обслуживания;

·        получение от сервера результатов запроса через сервер приложения ;

·        разрыв связи с сервером.

Решение для компаний с  распределенной структурой.

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

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

WEB-сервер

Рис.12. Работа БД в трехзвенной модели

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

2.6.Публикация данных в Интернет в рамках ИС «Деятельность больницы»

С развитием Интернет - технологий практически все фирмы заинтересованы в своем присутствии в сети Интернет – это видно даже по тому, что почти в каждом телевизионном рекламном ролике указывается адрес компании в Internet .

Для публикации базы данных в Интернет, были определены два  способа:

• Осуществление доступа через WEB- интерфейс
• Осуществление по FTP протоколу, где будет осуществляться работа с базой данных напрямую

1. Публикация базы данных по FTP протоколу.

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

Программы, которые рекомендуются использовать для работы с сервером по протоколу FTP:

• Far Manager
• FTP Commander
• Total Commander
• Например, используем  Far Manager. Прежде всего нужно установить и запустить данную программу.
• После запуска программы нужно подвести указатель мыши к верхней части окна и в появившемся меню выбрать, например, «Right» -> «Change drive» (либо нажатьм Alt + F2) и в новом окне отметить пункт «FTP».
• Нажать Shift+F4 и создть новое подключение
• В свойствах соединения необходимо указываем адрес FTP-сервера, выданный при регистрации. Он будет выглядеть примерно так: uXXXX.ftp.masterhost.ru (где uXXXX — площадка пользователя)
• Необходимо отметить клавишей пробела [x] «спрашивать пароль» (ask password directly before connection) и [x] «пассивный режим» (Passive mode)
• Нажимаем [сохранить] (Save)
• Далее, чтобы подключиться, наводим курсор на созданное соединение uXXXX.ftp.masterhost.ru) и нажимаем «Enter»
• В появившемся окне необходимо ввести логин (вида uXXXXX) и пароль для FTP доступа, высланные при регистрации хостинга вашего домена
• Нажимаем «ОК» и ждем соединения с сервером. Если соединение пройдет успешно, вы окажетесь в своем каталоге на нашем сервере, где нужно будет перейти в каталог с именем зарегистрированного вами домена и далее в каталог с названием 'www'.
• Переходим в другую панель программы Far Manager (с помощью клавиши TAB) выбераем предназначенные для загрузки на сервер файлы и нажимаем кнопку F5 (копирование).