Реферат: Разработка физической модели базы данных "Учёт затрат на медицинские услуги"

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

УХТИНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра ИСТ

Курсовой проект

Дисциплина: «Системы управления базами данных»

Тема:

«Разработка физической модели базы данных «Учёт затрат намедицинские услуги»

Выполнил                                                                  студент группы ИСТ-2-04

Петров М.В.

Проверила                                                           доцент кафедры ИСТ, к. т. н.

Николаева Н.А.

Ухта 2007

Содержание

 

Введение

Часть 1. Постановка задачи

1.1. Анализ существующих аналогов

1.2. Обоснование выбора бизнес-процесса

Часть 2. Технологическая часть

2.1. Выбор средств разработки

2.2. Основные методы и способы разработки

2.3. Модель жизненного цикла

Часть 3. Основная часть

3.1. Поддержание целостности БД

3.2. Поддержание бизнес-логики

3.3. Описание интерфейса пользователя

3.4. Формирование выходной документации и входных форм

3.5. Пользователи и права доступа

Заключение

Список используемой литературы

Приложения

Введение

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

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

·       Велики затраты времени и ручного труда на ведение всейнеобходимой документации. Наблюдается однотипность выполняемых операций.Ежедневно в филиал поступает около 100-150 статистических талонов, несколькодесятков карт выбывших больных; а также ежемесячно поступают приказы и извещенияоб оплате от каждого ЛПУ.

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

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

На предыдущих этапах работы былопроведено изучение и анализ предметной области, построены контекстная диаграммаи DFD 1-го уровня. Были составлены словарь данных инаписаны спецификации процессов. Затем были построены концептуальная илогическая модели базы данных, которые и послужили основой для созданияфизической модели, а также написаны запросы к базе данных на языке реляционнойалгебры, которые были преобразованы в запросы на языке T-SQL. Бизнес-правила нашли свое выражение в виде триггеров иограничений.

Курсовой проект состоит из трех частей.В первой части, производится постановка задачи, обоснование разработки,обоснование выбора автоматизируемого бизнес-процесса.

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

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

В заключении приводятся выводы иитоги проделанной работы.

Часть 1. Постановка задачи1.1. Анализ существующих аналогов

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

1.2. Обоснование выбора бизнес-процесса

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

Ø  Фиксировать полученную документацию;

Ø  Получить документацию;

Ø  Сформировать заявку;

Ø  Оформить платёжное поручение;

Ø  Получить извещение об оплате.

 В ходе разработке данногокурсового проекта были автоматизированы все подпроцессы, протекающие вКняжпогостском филиале ФОМС при учете затрат на медицинские услуги. Это былосделано, так как при отказе от автоматизации какого-либо подпроцесса станетневозможным формирование основного выходного документа — заявки нафинансирование. Автоматизация всех процессов сделало разрабатываемую системузаконченной и полной. Кроме того, правильный выбор средств разработки позволилв сжатые сроки создать полноценную систему.

Часть 2. Технологическая часть2.1. Выбор средств разработки

В качестве целевой СУБД былавыбрана Microsoft SQL Server2005. SQL Server2005 — это новейшая версия одной из систем управления базами данных, достигшаятого непревзойдённого уровня развития, к которому она постепенно приближаласьна протяжении двух десятилетий. Данная версия явилась результатом кореннойпереработки, которой подвергается этот программный продукт, начиная с версии7.0. Но в программном обеспечении SQL Server 2005 удалось значительно улучшить совместимостькомпонентов и расширить набор средств, обеспечивающих взаимодействие с языком XML, инфраструктурой .NET,определяемыми пользователем типами данных, а также многими другимидополнительными службами.

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

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

В версии SQL Server 2005 предусмотрено многоинструментальных средств проектирования, которые существенно изменились посравнению с предыдущими версиями. К сожалению, методология создания диаграмм,предусмотренная в этих программных средствах, не соответствует ни одному изобщепринятых стандартов формирования ER-диаграмм. Темне менее эти инструментальные средства формирования диаграмм обеспечиваютвыполнения всех «обязательных» операций; по крайней мере, с их помощью можноприступить к освоению соответствующих методов.

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

Клиентское приложение былоразработано в среде Microsoft Visual Studio2005. Эта среда использует технологию программирования .NET,которая вместе со связанной с ней средой .NET Framework, является одной из самыхважных технологий для разработчиков ПО за много лет. .NETспроектирована как новая среда, в рамках которой можно разработать практическилюбое приложение для Windows. Данная версия среды Visual Studioиспользует .NET Framework 2.0 — третья версия этой среды. Далее мы вкратцеперечислим преимущества технологии .NET перед другимитехнологиями разработки:

Ø Объектно-ориентированное программирование — и среда .NET Frameworkизначально полностью базировалась на объектно-ориентированных принципах.

Ø Хороший дизайн — библиотека базовых классов, котораяспроектирована «с нуля», исключительно интуитивно понятным образом.

Ø Независимость от языка — с .NET код всехязыков компилируется в общий язык промежуточного уровня — Intermediate Language. Это значит, что ранее всеэти языки обладают возможностями взаимодействия, как никогда ранее.

Ø Эффективный доступ к данным — набор компонентов .NET, известный под общим названием ADO.NET предоставляет эффективный доступ к реляционным базамданных и широкому разнообразию других источников данных. Также доступныкомпоненты, предоставляющие доступ к файловой системе и каталогам.

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

Ø C# — новый объектно-ориентированный язык,предназначенный для применения с .NET.

Заметим, что Visual Studio 2005 использует .NET Framework2.0. Эта среда также имеет некоторые преимущества по сравнению с предыдущимиверсиями .NET Framework,а именно:

Ø Интеграция с SQL Server. Для нас важно прежде всего то, что Visual Studio 2005, .NET Framework 2.0 и SQL Server 2005 тесно связаны междусобой в том смысле, что реализованы в сочетании.

Ø Поддержка 64-разрядных вычислений. Сегодня больше и большепредприятий переходят на современные 64-разрядный процессоры. А среда Visual Studio2005 может компилировать код так, чтобы он работал на любых процессорах.

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

2.2. Основные методы и способы разработки

После выбора средств разработкипоявилась необходимость выбора основных методов и способов разработки базыданных.  Надо сказать, что СУБД Microsoft SQL Server 2005 даёт нам два основных способа разработки — написание сценариев на языке T-SQLи визуальные средства разработки. В нашей работе использовалось оба метода, иэто позволило в достаточно сжатые сроки создать корректную и целостную базуданных.

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

В среду SQL Server 2005 включены также ивизуальные средства разработки базы данных. Они, как ясно из названия,предполагаю создание базы данных без написания сценариев, а при помощи нужныхпанелей инструментов. Теоретически всю работу по созданию базы данных можновыполнить, вообще не прикасаясь к клавиатуре! Но такой способ разработки чреватбольшим количеством ошибок, так как легко выбрать не тот пункт выпадающегосписка или совершить подобныю ошибку. Кроме того, создавать сложные запросы,представления, триггеры при помощи визуальных средств очень трудно и такжечревато большим количеством ошибок.

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

2.3. Модель жизненного цикла

Согласно RUP(Rational Unified Process) жизненный циклинформационной системы делится на следующие стадии:

Ø  Постановка задачи;

Ø  Анализ;

Ø  Проектирование;

Ø  Реализация (кодирование);

Ø  Отладка;

Ø  Тестирование;

Ø  Внедрение;

Ø  Эксплуатация.

Естественно, в ходе разработкинашей системы было сложно полностью провести все этапы жизненного цикла, нобольшинство стадий все-таки было проведено. Далее рассмотрим все пройденные впроцессе разработки этапы.

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

На стадии анализа происходитизучение и анализ предметной области, построение контекстной диаграммы и DFD нижних уровней. Разрабатываются прецеденты, диаграммыпрецедентов, последовательностей, взаимодействия и другие. Стадия анализаописана в курсовых проектах по дисциплинам «Информационные технологии» и«Теория информации».

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

Стадия реализации иликодирования характеризуется непосредственным созданием компонентов системы. Внашем случае стадия реализации заключалась в создании базы данных, хранимыхпроцедур и триггеров, а также в создании клиентского приложения для управленияданными. Эта стадия была самой трудоёмкой и долгой, так как необходимо былоизучить различные технологии для реализации (язык запросов SQL,технологию доступа к данным ADO.NET,язык C#).

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

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

Часть 3. Основная часть3.1. Поддержание целостности БД

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

Все меры по поддержкецелостности базы данных можно разделить на 2 большие группы:

1.     Декларативная целостность (ограничения);

2.     Процедурная целостность (триггеры, правила и т.д.).

 Ограничения (CONSTRAINTS) представляют собой некоторые условия,налагаемые на столбцы, таблицы и гарантирующие, что ваша информация будетподчиняться определённым правилам целостности данных. Надо отметить, чтоимеется 2 типа реакции на попытку нарушения целостности — отказ и выполнение«компенсирующих» действий. Для данного проекта были использованы ограниченияотказа, то есть запрещения выполнения некорректных действий. Существуетнесколько классификаций для ограничений целостности, но для нас наиболее удобноклассифицировать их по области действия.

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

1.     Ограничения атрибута;

2.     Ограничения домена;

3.     Ограничения кортежа;

4.     Ограничения отношения.

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

Ограничения атрибутаимеютбольшое значение при организации бизнес-логики системы. Одним из видовограничения атрибутов является ограничение уникальности (UNIQUE constraints).Еще одно название данного вида ограничения — альтернативный ключ (alternate key).В данном проекте этот вид ограничений широко использовался для поддержкицелостности БД. Например, при анализе предметной области было выявлено, чтоназвание ЛПУ должно быть уникально. Поэтому при создании таблицы LPU был написан следующий сценарий.

CREATE TABLELPU

(IDLPU INTIDENTITY PRIMARY KEY,

NameLPUvarchar(50) UNIQUE,

MestoLPUvarchar(30))

Создав данное отношение, мыустановили, что название ЛПУ должно быть уникально. Таким образом, при попыткенарушить это ограничение пользователь получит сообщение об ошибке.

Ограничение UNIQUEбыло установлено в отношениях LPU, Vrach,Pacient, Type, Diagnos и других для обозначения потенциальных ключей отношений.

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

CREATE TABLEType

(IDType INTIDENTITY PRIMARY KEY,

NameTypevarchar(40) UNIQUE NOT NULL,

TarifType MONEY)

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

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

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

ALTER TABLE Isveshenie

WITH CHECK

ADD CONSTRAINTChekDateBegin

CHECK(Isveshenie.BeginPer<GETDATE())

Ограничение CHECKбыло установлено для проверки правильности ввода дат в отношениях Prikas, Isveshenie, Karta.

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

CREATE TABLEDiagnos

(IDDiagnos INTIDENTITY PRIMARY KEY,

NameDiagnosvarchar(50),

ShifrDiagnosvarchar(20),

Norma INT )

Здесь можно добавить, чтопервичным ключом отношения Diagnos является атрибут IDDiagnos, таким образом он идентифицирует любой кортежотношения.

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

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

CREATE TABLEOtdel

(IDOtdel INTIDENTITY PRIMARY KEY,

Namevarchar(30),

IDLPU INT,

TarifOtdelMONEY,

CONSTRAINTOtdelLPUforeign FOREIGN KEY(IDLPU) REFERENCES LPU)

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

Ограничения внешнего ключа мыустановили в отношениях, которые являются ссылающимися (см. Приложение 1).

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

CREATE TRIGGEROsnovDiagnTalon

ON DiagnTalon

FOR INSERT,UPDATE

AS

IF ((SELECTCOUNT(D.Type) FROM DiagnTalon D

     INNER JOININSERTED I

     ONI.IDTalon=D.IDTalon

     WHERED.Type = 'основной' AND D.IDTalon=I.IDTalon

     GROUPBY D.IDTalon)<>1)

BEGIN

RAISERROR('Нельзя иметь большеодного основного диагноза в талоне!',16,1)

ROLLBACK TRAN

END

Теперь мы при добавлении илиредактировании отношения DiagnTalon (Диагноз в талоне) SQL Serverбудет следить за тем, чтобы основной диагноз для определённого талона былтолько один. Точно так же реализовано правило, согласно которому в картевыбывшего больного должен быть только один основной диагноз.

При создании базы данных мыстолкнулись также со следующей проблемой. Отношение Talon(Статистический талон) имеет атрибуты IDLPU, IDVrach, IDPacient, IDType,которые представляют собой внешние ключи на отношения LPU,Vrach, Type. Мы можем внести вбазу данных информацию, согласно которой, например, врач А лечил в ЛПУ B в качестве специалиста C, но приэтом врач А может не быть врачом ЛПУ B, и не бытьобладать специальностью C. Чтобы исправить данный недостаток,были написаны соответствующие триггеры, приведём пример одного из них.

ALTER TRIGGERTalonVrachLPU

ON Talon

FOR INSERT,UPDATE

AS

IF(EXISTS(SELECT 'true' FROM INSERTED

     WHEREINSERTED.IDVrach NOT IN (SELECT IDVrach FROM

                                   Vrach

WHEREIDLPU=INSERTED.IDLPU)

   ))

BEGIN

RAISERROR('Такого врача нет ввыбранном ЛПУ!',16,1)

ROLLBACK TRAN

END

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

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

CREATE TRIGGER StopSmert

ON Talon

FOR INSERT

AS

IF (EXISTS(SELECT 'true' FROM INSERTED

    WHERE INSERTED.IDPacient IN (SELECT DISTINCT IDPacient FROM

                                 Talon T

                                 INNER JOIN DiagnTalon DT

                                 ON T.IDTalon=DT.IDTalon

                                 WHERE DT.Ishod='Смерть'

                                 UNION

                                 SELECT DISTINCT IDPacient FROM

                                 Karta K

                                 INNER JOIN DiagnKarta DK

                                 ON K.IDKarta=DK.IDKarta

                                 WHERE DK.Ishod='Смерть')

   ))

BEGIN

RAISERROR(‘Пациент умер!',16,1)

ROLLBACKTRAN

END

Аналогично написан триггер,запрещающий ввод информации по умершему в отношение Karta(Карта выбывшего больного).

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

CREATETRIGGER StopDelTalon

ON Talon

FOR DELETE

AS

IF (EXISTS(SELECT 'true' FROM DELETED

   WHEREDELETED.Date BETWEEN (SELECT MAX(BeginPer) FROM Prikas WHEREBeginPer<DELETED.Date AND IDLPU=DELETED.IDLPU)

    AND (SELECTMAX(BeginPer) FROM Prikas

   WHEREEndPer>DELETED.Date AND IDLPU=DELETED.IDLPU)))

BEGIN

RAISERROR('Нельзя удалить талон,так как оплата по нему уже производилась!',16,1)

ROLLBACK TRAN

END

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

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

3.2. Поддержаниебизнес-логики

Поддержание бизнес-логикиявляется еще одной задачей при разработке базы данных. Бизнес-логика — логикавыполнения бизнес-процесса по определённым правилам, называемым ещебизнес-правилами. Так, при анализе предметной области из главного процесса«Учесть затраты на оказанные медицинские услуги» было выделено 5 подпроцессов:

Ø  Фиксировать полученную документацию;

Ø  Получить документацию;

Ø  Сформировать заявку;

Ø  Оформить платёжное поручение;

Ø  Получить извещение об оплате.

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

При рассмотрении первогоподпроцесса (Фиксировать полученную документацию) появилась необходимостьсоздания отношений, соответствующих входным потокам данных. Так появилисьотношения Talon и Karta сатрибутами, входящими в словарь данных (Курсовой проект по дисциплине ИТ).Создание отношения Talon осуществлялось следующимобразом:

CREATE TABLE Talon

(Number INT PRIMARY KEY NOT NULL,

Date DATETIME,

Typevarchar(30),

IDLPU INT,

IDVrach INT,

IDPacient INT,

IDType INT,

CONSTRAINTTalonLPUforeign FOREIGN KEY(IDLPU) REFERENCES LPU,

CONSTRAINTTalonVrachforeign FOREIGN KEY(IDVrach) REFERENCES Vrach,

CONSTRAINTTalonTypeforeign FOREIGN KEY(IDType) REFERENCES Type,

CONSTRAINTTalonPacientforeign FOREIGN KEY(IDPacient) REFERENCES Pacient)

Зесь следует отметить, чтокаждый статистический талон может содержать несколько диагнозов, таким образомпоявилось отношение DiagnTalon (Диагноз в талоне):

CREATE TABLEDiagnTalon

(IDTalon INT,

IDDiagnos INT,

Ishodvarchar(30),

Typevarchar(30),

CONSTRAINTPK_Foreign PRIMARY KEY(IDTalon,IDDiagnos),

CONSTRAINTTalonDiagnforeign FOREIGN KEY(IDTalon) REFERENCES Talon ON DELETE CASCADE,

CONSTRAINTDiagnTalonforeign FOREIGN KEY(IDDiagnos) REFERENCES Diagnos)

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

Аналогичным образом были созданыотношения Karta, Prikas и Isveshenie, которые предназначены для хранения информации извходной следующей документации — карта выбывшего больного, приказ и извещениеоб оплате. Входной поток информации Нормы на лечение материализовался ввиде отношения Diagnos, где стала храниться информацияо диагнозах и сроках их лечения. Создание отношения Diagnos:

CREATE TABLEDiagnos

(IDDiagnos INTIDENTITY PRIMARY KEY,

NameDiagnosvarchar(50),

ShifrDiagnosvarchar(20),

Norma INT )

Документ Прейскурант цен намедицинские услуги нашел свое выражение в отношениях Type(Специальность врача) и Otdel (Отделение), в которые вкачестве атрибутов вошли тарифы по определённой специальности и отделению.

CREATE TABLEOtdel

(IDOtdel INTIDENTITY PRIMARY KEY,

Namevarchar(30),

IDLPU INT,

TarifOtdel MONEY,

CONSTRAINTOtdelLPUforeign FOREIGN KEY(IDLPU) REFERENCES OtdelLPU)

Выходной документ Платежноепоручение формируется с помощью хранимой процедуры на основанииопределённого приказа об оплате. Входными параметрами для процедуры являются NameLPU (Наименование ЛПУ) и Date(Дата приказа об оплате).

CREATE PROC Poruchenie

@NameLPUvarchar(50),

@Date DateTime

AS

SELECTNameLPU,MestoLPU,Date,BeginPer,EndPer,Summa

FROM Prikas

INNER JOIN LPU

ONPrikas.IDLPU=LPU.IDLPU

WHERELPU.NameLPU=@NameLPU AND Prikas.Date=@Date

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

CREATE PROC GetZayavka

@BeginDateTime,

@End DateTime

AS

SELECTLPU.NameLPU,LPU.MestoLPU,SUM(TarifType)+Stacionar.Summa[Summa]

FROM Talon

INNER JOIN Type

ONTalon.IDType=Type.IDType

INNER JOIN LPU

ONTalon.IDLPU=LPU.IDLPU

INNER JOIN(SELECT LPU.IDLPU,SUM(TarifOtdel*(Norma*1.15))[Summa]

            FROMKarta

           INNER JOIN LPU

            ONKarta.IDLPU=LPU.IDLPU

           INNER JOIN OtdelLPU

            ONOtdelLPU.IDLPU=LPU.IDLPU

           INNER JOIN Otdel

            ONOtdel.IDOtdel=OtdelLPU.IDOtdel

           INNER JOIN DiagnKarta

            ONKarta.IDKarta=DiagnKarta.IDKarta

           INNER JOIN Diagnos

            ONDiagnos.IDDiagnos=DiagnKarta.IDDiagnos

           WHERE Karta.DateEnd BETWEEN @Begin AND @End AND DiagnKarta.Type='основной'

           GROUP BY LPU.IDLPU) Stacionar

ONLPU.IDLPU=Stacionar.IDLPU

WHERETalon.Date BETWEEN @Begin AND @End

GROUP BYLPU.NameLPU,LPU.MestoLPU,Stacionar.Summa

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

CREATE PROCPacientLPU

@NameLPUvarchar(50),

@BeginDateTime,

@End DateTime

AS

SELECTFam,Im,Otch

FROM Pacient

INNER JOINKarta

ON Pacient.IDPacient=Karta.IDPacient

INNER JOIN LPU

ONKarta.IDLPU=LPU.IDLPU

WHERELPU.NameLPU=@NameLPU AND Karta.DateEnd BETWEEN @Begin AND @End

UNION

SELECTFam,Im,Otch

FROM Pacient

INNER JOINKarta

ONPacient.IDPacient=Karta.IDPacient

INNER JOIN LPU

ON Karta.IDLPU=LPU.IDLPU

WHERELPU.NameLPU=@NameLPU AND Karta.DateBegin BETWEEN @Begin AND @End

UNION

SELECTFam,Im,Otch

FROM Pacient

INNER JOINTalon

ONPacient.IDPacient=Talon.IDPacient

INNER JOIN LPU

ONTalon.IDLPU=LPU.IDLPU

WHERELPU.NameLPU=@NameLPU AND Talon.Date BETWEEN @Begin AND @End

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

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

3.3. Описание интерфейса пользователя

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

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

/>

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

/>

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

/>

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

/>

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

/>

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

Привыборе пункта главного меню «Справочники» мы увидим выпадающий список всехсправочников системы:

/>

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

/>

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

/>

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

/>

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

/>

Перейдемк элементу главному меню «Отчеты». Как мы видим, возможен выбор 2 отчетов — заявки на финансирование и платёжного поручения. При выборе одного из этихпунктов происходит вызов окна, в котором нужно указать требуемые данные,например:

/>

В этомслучае следует выбрать наименование ЛПУ и указать дату нужного приказа обоплате, а затем нажать кнопку «Сформировать поручение». Нажатие кнопки «Отмена»закрывает окно.

/>

После формирования порученияпользователю доступны функции экспорта отчета в файлы с расширением *.doc, *.xls, *.pdfи другие. Экспорт отчета происходит с помощью стандартного окна сохраненияфайла, в котором можно указать путь сохранения, имя и тип файла.

/>

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

Третий элемент главного меню — статистика. В него входят запросы, которые нет необходимости выводить на печать(в виде отчетов), но которые могут понадобиться пользователю. Описывать всепункты не имеет смысла, так как их интерфейс в большинстве своёмпредусматривает выбор или ввод каких-то значений и нажатие на кнопку  длявывода результатов запроса. Рассмотрим запрос, выдающий пациентов за период.При выборе этого пункта меню происходит вызов окна, состоящего из 2 логическихчастей — блока ввода информации и блока вывода. Блок ввода состоит из двухкомпонентов выбора дат — начала и конца периода, и двух выпадающих списков — для выбора ЛПУ и отделения. Надо отметить, что система предусматриваетвозможность оставлять списки пустыми, при этом отсев информации посоответствующему условию производиться не будет.

/>

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

/>

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

3.4. Формирование выходной документации и входныхформ

Формирование выходнойдокументации и входных форм является задачей, которая обеспечивает соблюдениефункциональных требований к системе. Выходная документация представляет собойотчеты, которые пользователь может как выводить на печать, так и экспортироватьв файл с расширениями *.doc, *.xls,*.pdf и другие. В нашей системе отчеты были созданы всистеме отчетов Crystal Reports. Эта система позволяет довольно легко создаватькрасивые и наглядные отчеты, в которые можно вставить диаграммы, графики,таблицы, формулы, и другие элементы.

В нашей системе выходнаядокументация представляет собой два документа — платёжное поручение и заявка нафинансирование. Информация, включаемая в отчет, выбирается из базы данныхпосредством хранимых процедур, их листинги приведены в разделе «Поддержаниебизнес-логики», отметим лишь, что генерируемые системой отчеты полностьюидентичны подлинным документам Княжпогостского филиала ФОМС.

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

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

3.5. Пользователи и правадоступа

В СУБД Microsoft SQL Server 2005 пользователи в значительной степени эквивалентныучётным записям. Иными словами, объект пользователя представляет собойидентификатор для некоторого лица, желающего войти в систему для работы. Любой,кто пожелает зарегистрироваться для работы с SQL Server 2005, должен быть представленс помощью объекта пользователя. Пользователи, в свою очередь, могутпринадлежать к одной или нескольким ролям. Права на выполнение определённыхдействий в СУБД SQL Server 2005 могут быть предоставлены непосредственнопользователю или роли, к которой могут относиться несколько пользователей.

В нашей базе данных несодержится каких-либо секретных данных, поэтому вполне достаточно дляограничения доступа к данным по сети использовать аутентификацию Windows, и создать соответствующего пользователя в качествевладельца базы данных. Надо сказать, что Microsoft SQL Server 2005 позволяет легко управлять пользователями и ихправами, так что в случае необходимости администратор баз данных может легковнести изменения в существующую схему доступа к данным.

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

Заключение

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

В ходе выполнения данногокурсового проекта была разработана физическая модель базы данных, причём вкачестве целевой СУБД была выбрана Microsoft SQL Server 2005. С помощью наложенных на отношения ограничений итриггеров осуществлена поддержка декларативной целостности базы данных, а припомощи создания хранимых процедур были реализованы бизнес-правила. Реализациязапросов к базе данных и создание хранимых процедур на языке T-SQL позволили автоматизировать процесс формирования выходнойдокументации. Анализ входной документации позволил правильно создать входныеформы для управления данными системы.

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

Список используемой литературы

1.        

2.        Роберт Вьейра. SQL Server 2000. Программирование в 2 ч.: Пер. с англ.; Под ред.С.М. Молявко. – М.: БИНОМ. Лаборатория знаний, 2004. – 735 с.: ил.

3.        Роберт Вьейра. Программирование баз данных Microsoft SQL Server 2005. Базовый курс.: Пер. с англ. — М.: ООО «И.Д.Вильямс», 2007. — 832 стр.: ил.

4.        Коннолли Томас, Бегг Каролин. Базы данных: проектирование, реализация исопровождение. Теория и практика, 3-е изд.: Пер. с англ. – М.: Издательский дом«Вильямс», 2003. – 1440 с.: ил. – Парал. тит. англ.;

5.        Гектор Гарсиа-Молина, Джеффери Ульман, Дженнифер Уидом. Системы базданных. Полный курс: Пер. с англ. – М.: Издательский дом “Вильямс”, 2004

6.        Нейгел Кристиан, Ивьен Билл, Глин Джей и др. C#2005 для профессионалов.: Пер с англ. — М.: ООО «И.Д. Вильямс», 2006. — 1376с.

7.        Николаева Н.А. Язык структурированных запросов. Лабораторные работы:учебное пособие / Н.А. Николаева, Т.Ю. Калинина. – Ухта: УГТУ, 2006. –  124 с.ил.