Материал: Разработка комплексной информационно-аналитической системы кожно-венерологического диспансера

          системы оперативной обработки транзакций (OLTP). Характеризуются тем, что к БД поступает интенсивный поток запросов на обновление данных, в то время как поток запросов на добавление больших объемов данных невелик. Типичным примером являются системы резервирования билетов на пассажирском транспорте, бронирования билетов в кинотеатрах;

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

          системы пакетной обработки (PP). Характеризуются способностью длительное время работать в автономном режиме с минимальным участием оператора. Как правило, БД здесь используется ограниченным числом прикладных программ. Типичный пример - системы управления технологическими процессами. (Разумеется, для классификации конкретной СБД может использоваться и комбинация представленных вариантов).

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

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

Таблица 1. Преимущества и недостатки СУБД

2.2 Описание инфологической модели

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

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

При построении инфологическ моделей используется язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь) и выбрана нотация Crow`s Foot ("воронья лапка") предложеная Гордоном Эверестом. Согласно ей, сущность изображается в виде прямоугольника, содержащем её имя, выражаемое существительным. Имя сущности должно быть уникальным в рамках одной модели. При этом имя сущности - это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется конкретный представитель данной сущности.

Рисунок 11. Пример отношения между сущностями согласно нотации Crow's Foot

Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде "вилки" на конце связи. Модальность связи так же изображается графически - необязательность связи помечается кружком на конце связи. Именование обычно выражается одним глаголомв изъявительном наклонении настоящего времени: "Имеет", "Принадлежит" и т.д.; или глаголом с поясняющими словами: "Включает в себя", и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого - под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится.

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

Рисунок 12. Пример инфологической модели базы данных

В инфологических моделях существует несколько видов связей между сущностями:

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

один ко многим - является наиболее часто используемым типом связи между таблицами. В отношении "один-ко-многим" каждой записи в таблице A могут соответствовать несколько записей в таблице B, но запись в таблице B не может иметь более одной соответствующей ей записи в таблице A;

многие ко многим - при отношении "многие-ко-многим" одной записи в таблице A могут соответствовать несколько записей в таблице B, а одной записи в таблице B несколько записей в таблице A. Этот тип связи возможен только с помощью третьей (связующей) таблицы.

.3 Основные функции СУБД

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

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

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

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

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

.4 Архитектура клиент-сервер

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

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

Характеристиками СУБД являются:

производительность;

обеспечение целостности данных на уровне баз данных;

обеспечение безопасности данных;

возможность работы в многопользовательских средах;

возможность импорта и экспорта данных;

обеспечение доступа к данным с помощью языка SQL;

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

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

Производительность СУБД оценивается:

временем выполнения запросов;

скоростью поиска информации;

временем импортирования баз данных из других форматов;

скоростью выполнения операций (таких как обновление, вставка, удаление);

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

Безопасность данных достигается:

шифрованием прикладных программ;

шифрованием данных;

защитой данных паролем;

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

Рисунок 13. Архитектура клиент-сервер

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

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

Данное программное обеспечение хорошо соответствует архитектуре клиент-сервер по двум причинам:

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

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

Глава 3. Программный комплекс "Учет обращений пациентов"

.1 Руководство программиста

.1.1 Общие сведения о программе

В ходе дипломного проектирования был разработан программный комплекс "Учет обращений пациентов", предназначенный для сбора, хранения и обработки информации о посещениях пациентами ГУЗ "Областной кожно-венерологический диспансер". Предполагается, что разработанная система будет использоваться сотрудником регистратуры для заполнения обращений пациентов, врачами для контроля обращений и заполнения ЭМК, а также руководством диспансера для анализа производительности и качества работы персонала.

Основные требования, предъявляемые к системе:

система должна обеспечивать автоматизированный сбор и статистический анализ информации о количестве общений пациентов в диспансер.

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

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

накопление информации и хранение информации;

ведение баз данных и знаний в предметной области и работа с ними;

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

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

Минимальная конфигурация ЭВМ, необходимая для работы программы:

процессор -Intel Pentium 3 и выше;

клавиатура, мышь;

операционная система - Windows XP,Vista,7,8;

свободный объем на жестком диске - не менее 100 Мб (без учета объема базы).

.1.2 Создание и реализация программы

Разработанная программа "Учет обращений пациентов" основана на принципах модульного программирования, которое открывает возможности для дальнейшего усовершенствования разработанного ПО. Модульная организация программы обеспечивает более простое и быстрое внесение изменений и дополнений в программу [16, с. 5].

Программа написана на языке программирования C++. Выбор этого языка обусловлен следующими факторами:

на сегодняшний день язык С++ является одним из самых популярных, гибких и удобных языков, с хорошо продуманным синтаксисом и богатыми возможностями;

С++ является на данный момент единственной средой быстрой разработки приложений (RAD), полностью поддерживающей все ведущие индустриальные стандарты: XML, SOAP, WSDL и XSL, а также появляющиеся платформы - Microsoft.NET и BizTalk, Sun Microsystems ONE, обеспечивая необходимую гибкость, надежность и масштабируемость;

большое количество визуальных компонент расширяют возможности разрабатываемых программ;

доступ к визуальным и не визуальным компонентам реализован на основе объектной библиотеки VCL (Visual Component Library), которая кроме того содержит большое количество сервисных функций.

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

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

Пользовательский интерфейс программы обеспечивает взаимодействие с базой данных. Он достаточно простой, ориентирован на неквалифицированного пользователя и представляет собой win32-приложение. Разработка проводилась в среде программирования Embercadero RAD Studio XE C++, которая поддерживает набор компонент ADO (ActiveX Database Objects) для работы с СУБД Microsoft SQL Server.