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

1. Анализ предметной области

1.1 Описание предметной области

Объектом исследования является регистратура поликлиники.

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

Цель данной работы - реализовать программную подсистему «Личный кабинет врача».

Подсистема ориентирована на задачи медицинской сестры.

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

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

ПО должно выполнять следующие функции:

· управлять данными: вводить, просматривать, изменять и архивировать;

· формировать отчеты по стандартным формам и по запросам;

· импортировать заявки из документов формата Excel в БД;

· экспортировать заявки из БД в документы формата Excel;

· защищать данные: разграничивать права доступа к данным, обеспечивать целостность БД, резервировать БД;

· производить настройку приложения и БД (администрирование).

ПО должно выполнять операции на стороне сервера и на стороне клиента и вести обмен данными с другими программами, поэтому оно должно включать три части:

· серверная часть

· клиентская часть

· взаимодействие с внешними программами

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

· хранение сведений о врачах;

· хранение информации о пациентах для распределения ролей между ними и защиты данных от несанкционированного доступа;

· хранение запросов к БД;

· администрирование БД;

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

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

Следующие функции являются основными для клиентского приложения:

· редактирование данных;

· формирование вызова;

· настройка ПО: выбор сервера СУБД.

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

· преобразовывать данные из документов;

· преобразовывать данные из БД в документы.

2. Семантические сети и реляционные базы данных

2.1 Общие сведения

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

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

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

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

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

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

2.2 Семантические модели

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

При этом проявляется ограниченность реляционной модели данных в следующих аспектах:

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

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

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

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

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

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

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

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

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

2.2.1 Отсутствие кортежей-дубликатов

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

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

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

Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят «столбец таблицы», имея в виду «атрибут отношения». Когда мы перейдем к рассмотрению практических вопросов организации реляционных баз данных и средств управления, мы будем использовать эту житейскую терминологию. Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.

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

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

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

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

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

2.2.2 Отсутствие упорядоченности кортежей

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

2.2.3 Отсутствие упорядоченности атрибутов

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

2.2.4 Атомарность значений атрибутов

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

Номер записи	Врач
	Врач_номер	Врач_Ф.И.О.	Врач_запись
310	2934 2935	Иванов Петров	10-00 11-00
313	2937	Федоров	14-40
315	2938	Иванов	16-00

Можно сказать, что здесь мы имеем бинарное отношение, значениями атрибута ЗАПИСИ которого являются отношения. Заметим, что исходное отношение ВРАЧИ является нормализованным вариантом отношения ЗАПИСИ:

ВРАЧ_НОМЕР	ВРАЧ_Ф.И.О.	ВРАЧ_ЗАПИСЬ	ВРАЧ_НОМЕР ЗАПИСИ
2934	Иванов	10-00	310
2935	Петров	11-00	310
2936	Федоров	14-40	313
2937	Иванова	16-00	315

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

Если информация о сотрудниках представлена в виде отношения ВРАЧИ, оба оператора будут выполняться одинаково (вставить кортеж в отношение ВРАЧИ). Если же работать с ненормализованным отношением ЗАПИСЬ, то первый оператор выразится в занесение кортежа, а второй - в добавление информации о Иванове в множественное значение атрибута ЗАПИСЬ кортежа с первичным ключом 310.

2.3 Реляционная модель данных

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

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

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

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

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

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов «Номера пропусков» и «Номера групп» относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.

Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или «арность» схемы отношения - мощность этого множества. Степень отношения ВРАЧИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).

Схема БД (в структурном смысле) - это набор именованных схем отношений.

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

2.3.1 Общая характеристика

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

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

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

2.3.2 Целостность сущности и ссылок

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

Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что нам требуется представить в реляционной базе данных сущность ЗАПИСЬ с атрибутами ЗАПИСЬ_НОМЕР (номер записи), ЗАПИСЬ_ВРАЧ (количество записей к данному врачу) и ОТД_ВРАЧ (набор врачей отделения). Для каждого сотрудника нужно хранить ВРАЧ_НОМЕР (номер врача), ВРАЧ_Ф.И.О. (Ф.И.О. врача). Как мы вскоре увидим, при правильном проектировании соответствующей БД в ней появятся два отношения: ЗАПИСЬ (ЗАПИСЬ_НОМЕР, ЗАПИСЬ_КОЛ) (первичный ключ - ЗАВПИСЬ_НОМЕР) и ВРАЧИ (ВРАЧ_НОМЕР, ВРАЧ_Ф.И.О., ВРАЧ_ВРЕМЯ) (первичный ключ - ВРАЧ_НОМЕР).

Как видно, атрибуты появляются в отношении ВРАЧ не потому, что номер является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ЗАПИСЬ. Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.

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

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

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

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

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

3. Проектирование семантической сети для введения амбулаторных карт

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

К сожалению, не все отношения одинаково желательны. Таблица, отвечающая минимальному определению отношения, может иметь неэффективную или неподходящую структуру. Для некоторых отношений изменение данных может привести к нежелательным последствиям, называемых аномалиями модификации (modificationanomalies). Аномалии могут быть устранены путем разбиения исходного отношения на два или более новых отношения. В большинстве случаев нормализация является более предпочтительной [3].

3.1 Проектирование нормальных форм

3.1.1 Первая нормальная форма

Отношения, которые соответствуют всем свойствам отношений, находятся в первой нормальной форме:

On-LineКабинет (Ф.И.О. пациента, логин пациента, пароль, адрес электронной почты пациента, полный домашний адрес пациента, номер амбулаторной карты, контактный телефон пациента, дата приема, Ф.И.О. врача, логин врача, пароль врача, должность врача, адрес электронной почты врача, полный домашний адрес врача, процентная ставка к зарплате за прием, контактный телефон врача, диагноз, назначение анализа, дата приема, описание истории болезни.

3.1.2 Вторая нормальная форма

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

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

PK (Ф.И.О. пациента, Ф.И.О. врача, номер обращения, диагноз, номер назначенные анализы)

PK (Ф.И.О. пациента, логин пациента, пароль пациента, адрес электронной почты пациента, полный домашний адрес пациента, контактный телефон пациента).

PK (Ф.И.О. врача, логин врача, пароль врача, должность врача, адрес электронной почты врача, полный домашний адрес врача, контактный телефон врача).

PK (диагноз, анализ, назначенный анализ, дата анализа, место проведения, получение анализа, полный диагноз, назначенное лечение).

Декомпозиция:

Пациент (Ф.И.О. пациент (РК), логин пациента, пароль пациента, адрес электронной почты пациента, полный домашний адрес пациента, контактный телефон пациента.)

Врач (Ф.И.О. врача (РК), логин врача, пароль врача, должность врача, адрес электронной почты врача, полный домашний адрес врача, контактный телефон врача.)

Диагноз (диагноз (РК), анализ, назначенный анализ, дата анализа, место проведения, получение анализа, полный диагноз, назначенное лечение.)

3.1.3 Третья нормальная форма

Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и отсутствует транзитивная зависимость между атрибутами:

Врач > пациент

Диагноз > пациент

Диагноз > анализ

Время >прием

Врач пациент

Диагноз пациент

Диагноз анализ

Время прием

3.1.4 Четвертая нормальная форма

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

Врач > > пациент

Диагноз > > пациент

Диагноз > > анализ

Время > > прием

3.2 Описание основных сущностей и их атрибутов

Описание основных сущностей и их атрибутов приводится в таблице 3.1.

Таблица 3.1. Описание сущностей и атрибутов

Сущность	Описание сущности	Атрибут	Описание атрибута
Пациент	Содержит информацию о пациентах	Ф.И.О. пациента (РК)	Фамилия, имя, отчество пациента (первичный ключ)
		Логин пациента	Логин пациента для входа в информационную систему
		Пароль пациента	Пароль пациента для входа в информационную систему
		Адрес электронной почты пациента	Адрес электронной почты для обратной связи с пациента
		Полный домашний адрес пациента	Адрес места проживания пациента
		Контактный телефон пациента	Контактный телефон для обратной связи с пациентом
Сотрудники	Содержит информацию о сотрудниках	Ф.И.О. сотрудника (РК)	Фамилия, имя, отчество сотрудника (первичный ключ)
		Логин сотрудника	Логин сотрудника для входа в информационную систему
		Пароль сотрудника	Пароль сотрудника для входа в информационную систему
		Адрес электронной почты сотрудника	Адрес электронной почты для обратной связи с сотрудником
		Полный домашний адрес сотрудника	Адрес, где прописан сотрудник
		Должность сотрудника	Должность, занимаемая сотрудником
		Контактный телефон сотрудника	Контактный телефон для обратной связи с сотрудником
Запись	Содержит информацию о Записях пациентов	День недели (РК)	Номер счета (первичный ключ)
		Время	Дата, когда пациенту нужно придти на прием
		Ф.И.О. сотрудника (FК)	Фамилия, имя, отчество сотрудника (внешний ключ от сущности «Сотрудники»)
		Ф.И.О. пациента (FК)	Фамилия, имя, отчество покупателя (внешний ключ от сущности «Покупатели»)
Диагноз	Содержит информацию о диагнозах	Диагноз (РК)	Диагноз (первичный ключ)
		Дата постановки	Дата
		Название анализа (FК)	Название анализа (внешний ключ от сущности «Анализ»)
		Постановка диагноза (FK)	Номер счета (внешний ключ от сущности «Диагноз»)

3.3 Выявление связей между сущностями

В рассматриваемой предметной области можно выделить связи с соотношение один ко многим 1:М, приведенные в таблице 3.2.

Таблица 3.2. Связи сущностей

Родительская сущность	Дочерняя сущность	Описание связи	Мощность связи
Пациент	Амбулаторная карта	Пациенты имеют амбулаторную карту	1:M
Сотрудники	Амбулаторная карта	Сотрудники оформляют карта	1:M
Диагноз	Анализ	Диагноз можно поставить с помощью анализа	1:M
Анализ	Диагноз	Анализ выдается для установления диагноза	1:M
Пациент	Диагноз	Пациент знает свой диагноз	1:M

3.4 Концептуальная модель

В качестве СУБД была выбрана PostgreSQL по следующим причинам:

1. PostgreSQL является бесплатной СУБД.

2. Отличная интеграция с языком высокого уровня Java.

3. Как следствие предыдущего пункта, PostgreSQL - идеальное решение для реализации web-приложений, написанных на Java.

4. Поддержка БД практически неограниченного размера.

5. Мощные и надёжные механизмы транзакций и репликации (механизм синхронизации содержимого нескольких копий объекта (например, содержимого базы данных). Репликация - это процесс, под которым понимается копирование данных из одного источника на множество других и наоборот) [4].

6. Наследование.

7. Легкая расширяемость.

В дальнейшем в работе для создания концептуальной модели данных используется CASE-средство ERwin, которое позволяет быстро и наглядно спроектировать модель в виде диаграмм «сущность-связь», а затем сгенерировать SQL код базы данных. Так как ERwin 7.3 не поддерживает PostgreSQL, в качестве СУБД была выбрана MySql 5.x, потому что SQL синтаксис и основные типы данных в PostgreSQL и MySql совпадают.

3.4.1 Логический уровень модели данных

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

В логической модели данных отображаются сущности и атрибуты, ключевые атрибуты в модели представлены в сущности, над чертой. Внешние ключи (мигрирующие атрибуты из родительской сущности) обозначаются как (FK - ForeignKey) [2].Логический уровень означает прямое отображение фактов из реальной жизни. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц[2].

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

Главное достоинство суррогатного ключа состоит в том, что он никогда не изменяется, поскольку не является информативным полем таблицы (не несёт никакой информации об описываемом записью объекте) [4].

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

Введем суррогатные ключи для сущностей «Пациент», «Сотрудники», «Диагноз» и «Анализ», кроме того, атрибуты «Ф.И.О. пациента» и «Ф.И.О. врача» разделим на три атрибута («фамилия», «имя», «отчество») каждый и сгруппируем их в составные альтернативные ключи. Так же альтернативными ключами сделаем атрибуты «название поставщика» и «название игры». Альтернативные ключи (AK - AlternativeKey) служат для ускорения поиска по базе данных.

врач реляционный амбулаторный программный

3.5 Физический уровень модели данных

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

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



Рисунок 3.1 - Модель данных на физическом уровне

3.6 Проектирование представлений, последовательностей, триггеров, хранимых процедур

3.6.1 Последовательности

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

Список последовательностей:

id_accounts - последовательность для суррогатного ключа таблицы Accounts

id_vendor - последовательность для суррогатного ключа таблицы Vendor

id_reteil - последовательность для суррогатного ключа таблицы Reteil

id_consignment - последовательность для суррогатного ключа таблицы Consignment

3.6.2 Триггеры

Триггер - это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено наступлением определенного события (действием) - по сути добавлением INSERT или удалением DELETE строки в заданной таблице, или модификации UPDATE данных в определенном столбце заданной таблицы реляционной базы данных. Триггеры применяются для обеспечения целостности данных и реализации сложной бизнес-логики. Триггер запускается сервером автоматически при попытке изменения данных в таблице, с которой он связан. Все производимые им модификации данных рассматриваются как выполняемые в транзакции, в которой выполнено действие, вызвавшее срабатывание триггера [4].

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

Разработанные триггеры представлены в таблице 3.3.

Таблица 3.3. Описание разработанных триггеров

Название триггера	Соответствующая триггерная функция	Событие для срабатывания триггера	Описание
consigment_datе_check	cons_datе	До вставки или до изменения	Триггер для таблицы Сonsigment.
goods_date_check	goods_datecheck	До вставки или до изменения	Триггер для таблицы Goods.
reteil_date_check	ret_date_check	До вставки или до изменения	Триггер для таблицы Reteil.
goods_update_from_consig	goods_works	После вставки	Триггер для таблицы Goods.
reteil_dateSending	dateSending	После вставки	Триггер для таблицы Reteil.
reteil_update_count	reteil_works	До вставки	Триггер для таблицы Reteil.
user_summ_discount	user_sum_discount	После вставки	Триггер для таблицы Reteil.

3.6.3 Представления

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

Разработанные представления описаны в таблице 3.4.

Таблица 3.4. Описание разработанных представлений

Название	Описание задачи	Выходные параметры
	Вывод врачей, которые находятся на больничном	Name, count_at_storehouse date_of_last_reteil (

4. Результат разработки

4.1 Реализация функций ПО

Большинство функций приложения построено на объектной модели. В данной модели можно выделить несколько уровней:

· уровень данных

· уровень бизнес-логики

· уровень приложения

Для проектируемого ПО выбрана архитектура «клиент-сервер».

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

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

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

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

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

§ Модуль создания запроса

§ Модуль проверки запроса

§ Модуль включения ЛК

На рисунке 4.1 изображена модульная структура ПО.

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

4.2 Служебные функции

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

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

Формат строки соединения является списком разделенных точкой с запятой пар параметров «ключ-значение»: keyword1=value; keyword2=value;

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

4.3 Основные функции

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

Связь между приложением и БД обеспечивают адаптеры таблиц (TableAdapters). Точнее говоря, адаптер таблиц подключается к БД, выполняет запросы или хранимые процедуры и либо возвращает новую заполненную таблицу данных, либо заполняет существующую DataTable возвращаемыми данными. Адаптеры таблиц также используются для отправки обновленных данных из приложения обратно в БД. Для доступа к конкретному адаптеру таблиц из программы необходимо объявить новый экземпляр TableAdapter.

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

Адаптеры таблиц являются генерируемыми конструктором компонентами и обычно содержат методы Fill и Update. Начальный (основной) запрос адаптера Fill используется в качестве основы для создания схемы связанной таблицы данных, а также команд InsertCommand, UpdateCommand и DeleteCommand, связанных с методом TableAdapter. Update. Это означает, что вызов метода Update адаптера таблицы выполняет инструкции, созданные при первоначальной настройке адаптера, и ни один из дополнительных запросов не добавлен при помощи мастера настройки запросов адаптера таблиц.

Метод Fill принимает в качестве аргумента подлежащий заполнению набор данных DataSet, а также объект или имя объекта DataTable, который должен быть заполнен строками, возвращенными методом SelectCommand.

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

При проектировании в среде Visual Studio с помощью мастера конфигурации источника данных был создан типизированный набор данных «DoctorDataSet», заполненный таблицами БД «Doctor». Для каждой таблицы был создан и сконфигурирован адаптер. В процессе разработки набор «DoctorDataSet» редактировался с помощью конструктора наборов данных. В него добавлялись новые и изменялись существующие объекты, такие как: DataTable, TableAdapter (вместе с запросами), DataRelation и Constraint.

Диаграмма структуры программного приложения SSD (System Structure Diagram) задаёт взаимосвязь функций и программных модулей, которые их реализуют.

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

Ниже на рисунках представлены диаграммы структуры программного приложения для процесса проверки запроса.

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

Рисунок 4.2

4.3 Нагрузочное тестирование ПО

Для анализа работы ИС на различных уровнях нагрузки применяется нагрузочное тестирование.

Для проведения тестирования информационной системы, её исходные компоненты были размещены на одном из ЭВМ, размещённом на локальном сервере. При проведении испытания использовался localhost-сервер, то есть все тесты проводились на одной ЭВМ, которая выполняла роль сервера.

Аппаратное обеспечение тестовой ЭВМ:

· центральный процессор Intel Celeron 1,8 ГГц;

· объем оперативной памяти: 256Мб;

· видеокарта не ниже NVIDIA GeForce 4 MX 440 64 Мб;

· 17» монитор;

Программное обеспечение тестовой ЭВМ:

· операционная система Windows XP Professional;

Для тестирования системы проведём следующие действия, которые помогут оценить работоспособность и правильность выполнения операций:

· Регистрация пользователя

· Добавление нового запроса

· Проверка запроса;

· Внедрение запроса;

· Проверка логов.

Существует два основных принципа тестирования: функциональное тестирование (по принципу «черного ящика»), структурное тестирование (по принципу «белого ящика»).

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

Тестирование методом «белого ящика» предполагает обработку системы как «прозрачного объекта» и позволяет заглянуть внутрь, фокусируя внимание на использовании знаний о конкретном программном обеспечении для правильного подбора тестовых данных. Синонимами понятия метода «белого ящика» являются: структурное тестирование, метод прозрачного ящика, метод стеклянного ящика.

В отличие от метода «черного ящика» данный метод основан на использовании определенных знаний программного кода, необходимых для контроля корректности данных на выходе. Тест является правильным только в том случае, когда тестер знает, что конкретно должна делать программа. Таким образом, тестер может контролировать ожидаемый результат. Тестирование методом «белого ящика» не обрабатывает случайные ошибки, но наряду с этим весь видимый код должен быть удобочитаемым.

В качестве методики тестирования изберем комбинированный метод «черного» и «белого» ящика.

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

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

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

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

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

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

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

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

Основные факторы, влияющие на надежность функционирования комплексов программ:

· факторы, непосредственно вызывающие сбой или отказ при исполнении программы, причинами могут быть:

§ искажения исходной информации, поступающей от внешних источников;

§ самоустраняющиеся отказы или сбои в аппаратуре вычислительной системы;

§ не выявленные ошибки в комплексе программ.

· архитектура комплекса программ и структурное построение его компонент;

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

В подготовке и вводе исходных данных в заявках участвует человек - пациент поликлиники. Это приводит к тому, что соответствующая часть данных характеризуется невысокой достоверностью с вероятностью ошибки около 10^-4 на 1 байт. В автоматических устройствах подготовки и передачи информации вероятность ошибки может быть значительно ниже и достигать значения 10^-6-10^-7. Однако и при такой достоверности данные не всегда пригодны для обработки без проведения контроля и предварительной селекции и могут оставаться существенной причиной отказов или сбоев при их обработке. Повышение достоверности исходной информации может производиться за счет использования избыточности при подготовке первичных данных и при вводе их в ВС. Эта избыточность используется для обнаружения искажений и исключения ложных данных, а в отдельных случаях и для исправления ошибок.

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