Повышение эффективности работы поликлиники за счет внедрения автоматизированной системы учета пациентов

/

РЕФЕРАТ

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

Рисунков - 18.

Таблиц - 40.

Литературных источников - 38.

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

ГЛАВА 1. ОБЗОР МЕДИЦИНСКИХ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1 Классификация медицинских автоматизированных информационных систем

1.1.1 Административно-хозяйственные медицинские системы

1.1.2 Системы информационного и библиографического поиска

1.1.3 Системы для лабораторных и диагностических исследований

1.1.4 Экспертные медицинские системы

1.1.5 Обучающие системы

1.1.6 Интегрированные системы

1.2 Обзор медицинских систем

1.3 Система управления госпиталем MedTrak

1.3.1 Обзор системы MedTrak

1.3.2 Основные особенности системы MedTrak

1.3.3 Электронная медицинская карта системы MedTrak

1.4 Техническое задание

ГЛАВА 2. АНАЛИЗ И МОДЕЛИРОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ «РЕГИСТРАТУРА

2.1 Выбор модели данных

2.2 Разработка структуры баз данных

2.3 Анализ и выбор инструментальных средств

2.3.1 Требования к составу и параметрам вычислительной системы

2.3.2 Требования к информационной программной совместимости

2.3.3 Обоснование выбора среды программирования

2.3.4 Обоснование выбора системы управления базами данных

ГЛАВА 3. ИСПЫТАНИЕ И ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ «РЕГИСТРАТУРА»

3.1 Испытание и тестирование АС «РЕГИСТРАТУРА

3.2 Инструкция пользователя

3.3 Экономическое обоснование эффективности внедрения АС 'Регистратура'

3.3.1 Описание характеристик продукта

3.3.2 Особенности товара

3.3.3 Система сервиса

3.3.4 Гарантии и защита потребительских прав

3.3.5 Исследование и анализ рынков сбыта

3.3.5.1 Маркетинговые исследования рынка сбыта АС «Регистратура»

3.3.5.2 Параметрическая сегментация рынка

3.3.5.3 Стратегия маркетинга

3.3.6 Оценка риска и страхование

3.3.7 Оценка затрат на разработку программного продукта

3.3.7.1 Определение потребности в материальных и трудовых ресурсах

3.3.7.2 Расчет себестоимости и договорной цены программного продукта

3.3.7.3 Разработка финансового плана

3.3.8 Безопасность жизнедеятельности. Характеристика ВЦ

3.3.9 Гражданская оборона

ЗАКЛЮЧЕНИЕ

АННОТАЦИЯ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

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

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

ГЛАВА 1. ОБЗОР МЕДИЦИНСКИХ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1 Классификация медицинских автоматизированных информационных систем

Административно-хозяйственные медицинские системы

Системы информационного и библиографического поиска

Системы для лабораторных и диагностических исследований

Экспертные системы

Обучающие системы

Интегрированные системы (учреждения)

1.1.1 Административно-хозяйственные медицинские системы

Назначение административно-хозяйственных медицинских систем или офисных:

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

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

К административно-хозяйственным медицинским системам относятся:

бухгалтерские системы;

системы учета лекарственных препаратов

системы регистрации пациентов;

системы регистрации медицинской документации;

системы автоматизации делопроизводства;

системы клинического обследования;

другие.

Каждая система предусматривает решение определенных задач.

Так, например, системы регистрации пациентов и медицинской документации направлены на решение задач:

ведение графика работы медицинского персонала всех уровней;

составление отчетов об использовании врачом рабочего времени;

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

Системы автоматизации делопроизводства направлены на решение задач:

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

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

подготовка отчетных документов.

1.1.2 Системы информационного и библиографического поиска

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

создание и ведение электронного каталога;

автоматическая идентификация изданий и читателей;

подготовка реферативной информации;

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

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

1.1.3 Системы для лабораторных и диагностических исследований

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

В связи с бурным развитием в последние годы коммуникационных технологий особенно распространенными среди диагностических систем становятся так называемые РАСS-системы (Рiсture Archiving and Control Systems - системы, предназначенные для обработки, хранения и получения удобного доступа к изображениям). Достижения электроники предоставляют врачам широкий спектр различного специализированного медицинского оборудования, разработанного для диагностики и мониторинга состояния пациента и данных биопсий. Это направление выделило науку «телепатологию».

Так, например, система лабораторных анализаторов решает задачи:

автоматической регистрации, хранения и анализа данных лабораторных и диагностических исследований;

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

1.1.4 Экспертные медицинские системы

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

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

1.1.5 Обучающие системы

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

гипертекстовая база данных, для развития знания обучающегося;

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

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

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

1.1.6 Интегрированные системы

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

задач административно-хозяйственного и финансового характера;

задач поддержки лечебно-диагностических мероприятий;

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

задач информационной поддержки оценки эффективности лечения;

задачи справочно-информационного и библиографического обслуживания медицинского персонала.

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

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

1.2 Обзор медицинских систем

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

Система управления госпиталем «MedTrak»[13];

Госпитальная информационная система «Авиценна»[14];

Программный комплекс «Управление поликлиникой»[15];

Медицинская информационная система «Амулет-клиника»[16];

Система «MedWork» компании Master Labs[17].

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

1.3 Система управления госпиталем MedTrak

1.3.1 Обзор системы MedTrak

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

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

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

Таблица 1.1

Подсистемы системы управления госпиталем MedTrak

* требует адаптации к украинским стандартам

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

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

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

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

Среда разработки, выбранная фирмой Trak Systems для продукта MedTrak, называется Cache'. Cache' - продукт фирмы InterSystems Corporation, США. Это постреляционная Система Управления Базами Данных, которая эволюционировала из М-технологии. Интересно заметить, что более 80% всех программных разработок для медицины было сделано на базе М-технологии.

1.3.2 Основные особенности системы MedTrak

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

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

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

1.3.3 Электронная медицинская карта системы MedTrak

Врачи, медсестры и другой персонал - все они заносят данные в электронную медицинскую карту(ЭМК). ЭМК состоит из различных разделов, вот основные из них:

Данные о госпитализации пациента

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

История болезни пациента

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

MedTrak поддерживает множество типов диагнозов для каждого обращения пациента - Диагноз при Госпитализации, Предполагаемый Диагноз, Конечный (Заключительный) Диагноз и т.д. Диагнозы могут быть основаны на ICD-9, ICD-10 (международный классификатор диагнозов) или каком-либо другом определенном пользователем справочнике.

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

Хирургические отчеты

Записи о хирургических вмешательствах, включая все хирургические процедуры, также вводятся в карту. Основой этих данных может служить ICD-9CM, ICD-10, CPT или другой определяемый пользователем справочник. Могут вводиться записи об использованных материалах и пост-операционном периоде.

Акушерские отчеты

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

Записи дантиста

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

Основные жалобы

Основные жалобы пациента могут быть зарегистрированы в ЭМК. Делается это путем выбора из списка сначала нужной части тела, а затем вида жалобы. Характер, начало и/или продолжительность жалобы также могут быть зарегистрированы. Врач может также делать примечания, касающиеся данной жалобы.

Текущее заболевание

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

Субъективные наблюдения

Субъективные наблюдения пациента могут быть зарегистрированы в ЭМК в свободной текстовой форме.

Анамнез

Секция анамнеза ЭМК фиксирует информацию о том, были ли у пациента операции, аллергии, о предыдущих видах лечения и заболеваниях (информация основывается на выбранном справочнике заболеваний, например, ICD9-CM или ICD-10) вместе с датой начала, продолжительностью и примечаниями в свободной текстовой форме.

Семейная история болезни

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

Социальная история

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

Физические измерения

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

Осмотр жизненных систем

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

Объективные результаты обследования

Отдел объективных результатов исследования в ЭМК позволяет пользователю вводить их в свободной текстовой форме.

Заметки о перемещениях

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

Результаты назначений

Все назначения, которые требуют результатов (например, анализы), отображены в этой секции ЭМК. Назначения перечислены с одной строкой для результатов. Если результаты уже получены, отображается отметка о выполнении. Выбрав из списка назначение с отметкой “результат получен”, Вы сможете просмотреть полный результат на экране.

Диагноз

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

Жизненные функции организма

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

Прием/отторжение

Здесь записываются и просматриваются данные о приеме/отторжении жидкостей и их баланс.

Перемещения

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

Отсутствие

По разным причинам пациентам позволяют временное отсутствие. Даты ухода и возвращения, время и причины отсутствия регистрируются в этой секции ЭМК.

Кровь

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

Примечания

Здесь медсестры могут осуществлять запись примечаний в ЭМК, основываясь на диагнозе врача.

Лечение

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

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

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

1.4Техническое задание

Основными задачами работы являются:

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

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

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

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

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

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

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

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

Просмотр и редактирование информации о пациенте.

Быстрый поиск данных о пациенте.

Хранение лечебно-диагностической информации полученной в результате осмотра пациента.

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

Иметь интуитивно-понятный интерфейс;

Защита информации от несанкционированного доступа;

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

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

Выводы по разделу

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

ГЛАВА 2. АНАЛИЗ И МОДЕЛИРОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ «РЕГИСТРАТУРА»

2.1 Выбор модели данных

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

Иерархические СУБД

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

Одной из наиболее популярных иерархических СУБД была Information Management System (IMS) компании IBM, появившаяся в 1968 году. Ниже перечислены преимущества IMS и реализованной в ней иерархической модели.

Простота модели. Принцип построения IMS был легок для понимания. Иерархия базы данных напоминала структуру компании или генеалогическое дерево.

Использование отношений предок/потомок. СУБД IMS позволяла легко представлять отношения предок/потомок, например: 'А является частью В' или 'А владеет В'.

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

СУБД IMS все ещё является одной из наиболее распространённых СУБД для больших ЭВМ компании IBM. Доля мэйнфреймов этой компании, на которых используется данная СУБД, превышает 25%

Сетевые базы данных

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

В связи с этим для таких приложений, как обработка заказов, была разработана новая сетевая модель данных. Она являлась улучшенной иерархической моделью, в которой одна запись могла участвовать в нескольких отношениях предок/потомок. В сетевой модели такие отношения назывались множествами. В 1971 году на конференции по языкам систем данных был опубликован официальный стандарт сетевых баз данных, который известен как модель CODASYL. Компания IBM не стала разрабатывать собственную сетевую СУБД и вместо этого продолжала наращивать возможность IMS. Но в 70-х годах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность.

Сетевые базы данных обладали рядом преимуществ:

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

Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.

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

Конечно, у сетевых баз данных были недостатки. Как и иерархические базы данных, сетевые базе данных были очень жесткими. Наборы отношений и структуру записей приходилось задавать наперёд. Изменение структуры базы данных обычно означало перестройку всей базы данных.

Как иерархическая, так и сетевая база данных были инструментами программистов. Чтобы получить ответ на вопрос типа 'Какой товар наиболее часто заказывает компания Acme Manufacturing?', программисту приходилось писать программу для навигации по базе данных. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.

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

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

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

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

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

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

Таблицы

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

Каждый вертикальный столбец таблицы представляет один элемент данных. На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных.

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

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

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

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

Первичные ключи

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

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

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

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) не была обеспечена явным образом их поддержка. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи, однако в самих СУБД не было возможности определить для таблицы первичный ключ. И только в СУБД DB2 Version 2, появившейся в апреле 1988 года, компания IBM реализовала поддержку первичных ключей. После этого подобная поддержка была добавлена в стандарт ANSI/ISO.

Отношения предок/потомок

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

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

Внешние ключи

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

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

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

Реляционная модель данных обладает всеми возможностями сетевой модели по части выражения сложных отношений.

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

Двенадцать правил Кодда

В статье, опубликованной в журнале 'Computer World', Тэд Кодд сформулировал двенадцать правил, которым должна соответствовать настоящая реляционная база данных. Двенадцать правил Кодда приведены в табл. 2.1. Они являются полуофициальным определением понятия реляционная база данных. Перечисленные правила основаны на теоретической работе Кодда, посвященной реляционной модели данных.

Таблица 2.1

Двенадцать правил Кодда, которым должна соответствовать реляционная СУБД

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

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

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

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

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

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

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

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

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

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

2.2 Разработка структуры баз данных

В данной главе будут выделены все сущности АС «Регистратура».

Сущность «Карта»(Karta)

Сущность «Карта» предназначена для хранения личных данных о пациенте, структура ее показана в табл. 2.2.

Таблица 2.2

Структура таблицы Karta

Сущность «Справочник врачей»(NsiVrach)

Сущность «Справочник врачей» содержит список всех врачей, структура показана в табл.2.3.

Таблица 2.3

Структура таблицы NsiVrach

Сущность «Справочник названия анализов»(NsiAnaliz)

Сущность «Справочник названия анализов» содержит названия анализов, структура показана в табл.2.4.

Таблица 2.4

Структура таблицы NsiAnaliz

Сущность «Справочник улиц»(NsiStreet)

Сущность «Справочник улиц» содержит названия улиц, на которых проживают пациенты, структура приведена в табл. 2.5.

Таблица 2.5

Структура таблицы NsiStreet

Сущность «Справочник сотрудников»(NsiPeople)

Сущность «Справочник сотрудников» содержит список всех сотрудников, которые работают с АС «Регистратура», структура показана в табл. 2.6.

Таблица 2.6

Структура таблицы NsiPeople

Сущность «Справочник болезней»

Сущность «Справочник болезней» представляет собой Международный классификатор болезней 10-го пересмотра, структура которого приведена в табл. 2.7.

Таблица 2.7

Структура таблицы MKB

Сущность «Периодический осмотр»(Periodosm)

Сущность «Периодический осмотр» хранит данные о периодических медицинских осмотрах, структура показана в табл. 2.8.

Таблица 2.8

Структура таблицы Periodosm

Сущность «Флюорография»(Flurka)

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

Таблица 2.9

Структура таблицы Flurka

Сущность «Жизненные функции организма»(Lifefun)

Сущность «Жизненные функции организма» содержит данные о температуре, давлении пациента, структура показана в табл. 2.10.

Таблица 2.10

Структура таблицы Lifefun

Сущность «Рентгеновские исследования»(Rengen)

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

Таблица 2.11

Структура таблицы Rengen

Сущность «Направления на анализы»(NaprAnaliz)

Сущность «Направления на анализы» хранит информацию о направлениях на анализы и их результатах, структура приведена в табл. 2.12.

Таблица 2.12

Структура таблицы NaprAnaliz

Сущность «Операции»(Operat)

Сущность «Операции» предназначена для фиксирования данных о перенесенных пациентом операций, структура показана в табл. 2.13.

Таблица 2.13

Структура таблицы Operat

Сущность «Данные физического развития»(VesRost)

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

Таблица 2.14

Структура таблицы VesRost

Сущность «Особые замечания»(Osob_Notes)

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

Таблица 2.15

Структура таблицы Osob_Notes

Сущность «Освобождения от работы»(OsvobWork)

Сущность «Освобождения от работы» предназначена для накопления информации о выданных пациенту больничных листах, структура приведена в табл. 2.16.

Таблица 2.16

Структура таблицы OsvobWork

Сущность «Рецепты»(Recept)

Сущность «Рецепты» предназначена для накопления информации о выданных пациенту рецептах, структура показана в табл. 2.17.

Таблица 2.17

Структура таблицы Recept

Сущность «Травмы»(Travmi)

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

Таблица 2.18

Структура таблицы Travmi

Сущность «Перенесенные заболевания»(Zabolevan)

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

Таблица 2.19

Структура таблицы Zabolevan

Сущность «Прививки»(Privivka)

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

Таблица 2.20

Структура таблицы Privivka

Сущность «История болезни»(History)

Сущность «История болезни» содержит информацию, касающуюся прошлой медицинской истории болезни пациентов, структура представлена в табл. 2.21.

Таблица 2.21

Структура таблицы History

Сущность «Вредные привычки»(Privichka)

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

Таблица 2.22

Структура таблицы Privichka

Сущность «Лечения в санаториях»(Sanator)

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

Таблица 2.23

Структура таблицы Sanator

Сущность «Заключительные диагнозы»(ZaklDiag)

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

Таблица 2.24

Структура таблицы ZaklDiag

Сущность «Наследственность»(Nasledst)

Сущность «Наследственность» предназначена для фиксирования данных о хронических заболеваниях родственников пациента, передающихся по наследству, структура представлена в табл. 2.25.

Таблица 2.25

Структура таблицы Nasledst

Проектирование отношений

Отношения в реляционной БД бывают трех типов [9]: один-к-одному, один-ко-многим, многие-ко-многим.

Также отношения бывают [9]: идентифицирующие (внешний ключ является первичным), не идентифицирующие (внешний ключ не является первичным).

Отношение «Карта- Периодический осмотр», отношение «Карта- Флюорография», отношение «Карта- Жизненные функции организма», отношение «Карта- Рентгеновские исследования», отношение «Карта- Направления на анализы», отношение «Карта- Операции», отношение «Карта- Данные физического развития», отношение «Карта- Особые замечания», отношение «Карта- Освобождения от работы», отношение «Карта- Рецепты», отношение «Карта- Травмы», отношение «Карта- Перенесенные заболевания», отношение «Карта- Прививки», отношение «Карта- История болезни», отношение «Карта- Вредные привычки», отношение «Карта- Лечения в санаториях», отношение «Карта- Заключительные диагнозы», отношение «Карта- Наследственность» приведены в табл.2.26.

Таблица2.26

Отношение таблиц базы с таблицей «Карта»

Отношение «Справочник врачей- Периодический осмотр», отношение «Справочник врачей-Направления на анализы», отношение «Справочник врачей-Операции», отношение «Справочник врачей-Особые замечания», отношение «Справочник врачей-Освобождения от работы», отношение «Справочник врачей-Рецепты», отношение «Справочник врачей-Травмы», отношение «Справочник врачей-Перенесенные заболевания», отношение «Справочник врачей-Прививки», отношение «Справочник врачей-История болезни», отношение «Справочник врачей-Вредные привычки», отношение «Справочник врачей-Лечения в санаториях», отношение «Справочник врачей-Заключительные диагнозы», приведены в табл. 2.27.

Таблица 2.27

Отношение таблиц базы с таблицей «Справочник врачей»

Отношение «Справочник болезней-Перенесенные заболевания», отношение «Справочник болезней-История болезни», отношение «Справочник болезней-Лечения в санаториях», отношение «Справочник болезней-Заключительные диагнозы», отношение «Справочник болезней-Наследственность» приведены в табл.2.28.

Таблица 2.28

Отношение таблиц базы с таблицей «Справочник болезней»

Отношение «Карта-Справочник улиц» приведено в табл.2.29.

Таблица 2.29

Отношение «Карта-Справочник улиц»

Отношение «Направления на анализы-Справочник названия анализов» приведено в табл.2.30.

Таблица 2.30

Отношение «Направления на анализы-Справочник названия анализов»

2.3. Анализ и выбор инструментальных средств

2.3.1 Требования к составу и параметрам вычислительной системы

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

Тип вычислительной системы. Для работы программного продукта необходима вычислительная система типа IBM РС АТ, с установленной операционной системой типа Windows 95/98/NT/2000.

Тип микропроцессора. Микропроцессор типа Intel 80486 или выше для ОС Windows 95/98, типа Pentium, Pentium II, Pentium III для ОС Windows NT/2000.

Размер ОЗУ. 16 Мб или выше для ОС Windows 95/98, 64 Мб или выше для ОС Windows NT/2000 .

Структура и размер ВЗУ. Используется НЖМД со свободным дисковым пространством порядка 10 Мб.

Необходимый шлейф внешних устройств. Монитор VGA с разрешением не менее 800х600. Также желательно наличие печатающего устройства и манипулятора “мышь”.

2.3.2 Требования к информационной программной совместимости

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

К информационной совместимости можно отнести такое требование, как возможность просмотра файлов-отчетов с помощью других приложений, например Notepad, Wordpad, Microsoft Word.

2.3.3 Обоснование выбора среды программирования

При выборе среды программирования для работы над данным проектом делался упор на возможность работы с большими объемами данных, в частности с базами данных. В настоящее время подобные возможности реализованы сразу несколькими языками, как, например, VisualBasic, Visual C++, Delphi. Но именно Delphi отвечает требованиям создания программного продукта в данном проекте. Приведем далее (в том числе и в сравнении) основные преимущества и достоинства Delphi.

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

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

Одно направление - объектно-ориентированный подход, хорошо структурирующий как саму задачу, так и ее решение в виде прикладной системы.

Другое направление, возникшее во многом благодаря объектной ориентации, - визуальные средства быстрой разработки приложений (RAD - Rapid Application Development), основанные на компонентной архитектуре.

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

Четвертая тенденция - возможность работы с базами данных универсальными методами. Если попытаться оценить процент систем, которые так или иначе требуют обработки структурированной информации (как для внутрикорпоративного использования, так и для коммерческого или иного распространения), то окажется, что цифра 60-70% может представлять лишь нижнюю границу. Важным свойством средств обеспечения доступа к базам данных является их масштабируемость, то есть возможность не только количественного, но и качественного роста системы. Например, обеспечение перехода от локальных, в том числе, файл-серверных данных, к архитектуре клиент-сервер или тем более к многоуровневой N-tier схеме.

Приведем небольшое сравнение, выявляющее преимущества Delphi перед другими средами программирования. Система Delphi - самое последнее достижение в области визуального программирования. Главным соперником Delphi является Visual Basic (VB).

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

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

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

В Delphi таких ограничений нет. Эта среда умеет не только использовать, но и создавать DLL, а ее программы могут, как инициировать, так и обрабатывать практически любые события Windows. Компоненты Delphi написаны в среде Delphi, поэтому не нужно выходить из системы, чтобы создавать новые компоненты или дорабатывать существующие. Более того, находясь в среде Delphi, можно даже использовать компоненты ActiveX, так как программы, созданные в Delphi, прекрасно работают с компонентами ActiveX. Пользователи Delphi имеют такие возможности настройки компонентов ActiveX, которые VB предоставить не в состоянии.

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

Delphi поддерживает объекты, которые создаются с помощью других языков (например, С++) на основе стандарта OCX.

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

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

Delphi всегда обладала мощным потенциалом в сфере создания баз данных. В версии 3 пересмотрена структура поддержки программирования баз данных и реализовано много новых возможностей. Delphi 3 вводит концепцию распределенного набора данных, который взаимодействует со всеми типами баз данных в режиме клиент/сервер, то есть приложение-клиент сохраняет локальную копию таблицы и просто пересылает модификацию на сервер. Благодаря этому упрощению программе требуется поддержка только одного объекта клиента, инкапсулированного в новый объект TMemoryDataSet. Весь остальной код остается в распоряжении BDE, которая используется параллельно работающими приложениями. При этом такие компоненты, как TTable, TQuery и другие, уже обновились, чтобы отразить новую структуру, и полностью совместимы с существующим кодом.

Delphi содержит множество компонентов работы с данными, превращая программирование баз данных почти в тривиальную задачу. И все это достигается благодаря системе доступа к базам данных фирмы Borland (Borland Database Engine, или BDE).

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

2.3.4 Обоснование выбора системы управления базами данных

Как утверждалось в первой главе, т.к. проектируемая система является распределённой, то целесообразно использовать клиент/серверную систему управления базами данных (СУБД). В настоящее время наиболее распространенными являются следующие СУБД: Oracle, Informix, InterBase, MySQL. Каждая из них имеет свои преимущества и недостатки.

На этапе проектирования было принято решение о использовании в качестве СУБД программный продукт Oracle8.0. Рассмотрим свойства и структуру этой СУБД.

Свойства СУБД ORACLE

В настоящее время ORACLE Corporation предлагает СУБД программное обеспечение, которой обладает следующими свойствами:

Переносимо (portable) - программное обеспечение ORACLE может работать под управлением различных операционных систем;

Совместимо (compatible) - программное обеспечение ORACLE совместимо с большинством промышленных стандартов операционных систем, поэтому приложение, разработанное для ORACLE, может без модификации работать в любой операционной системе;

Подключаемо (connectable) - программное обеспечение ORACLE позволяет различным типам компьютеров и операционных систем разделять информацию, в режиме реального времени.

ORACLE реализует следующие принципы построения СУБД

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

гибкостью и легкостью доступа ко всем данным;

высокую степень гибкости на этапе проектирования БД;

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

независимость физической организации данных от логической структуры БД.

Архитектура СУБД - “Клиент-Сервер”. Начиная с версии 5.0 все средства ORACLE ориентированны на архитектуру типа “Клиент-Сервер”. В этой архитектуре прикладная система разделена на две части: переднего плана (front-end) - узел “Клиент” (или обслуживаемый узел) и заднего плана (back-end) - узел “Сервер” (или обслужиавющий узел). В узле “Клиент” выполняются прикладные программы (средства), которые запрашивают необходимую информацию из БД (расположенной в узле “Сервер”) и обеспечивают интерактивное взаимодействие с пользователем через клавиатуру, экран и мышь. В узле “Сервер” выполняются системные программы СУБД ORACLE, и обеспечивается организация совместного доступа пользователей (из узлов “Клиент”) к БД ORACLE. Хотя “Клиент” и “Сервер” могут выполняться на одном и том же компьютере, часто более эффективно, когда эти узлы разнесены по машинам, связанным в единую сеть.

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

Распределенная обработка данных (Distributed Processing).
В типичной сети, “Клиент” и “Сервер” размещаются на различных компьютерах, что обеспечивает возможность наиболее эффективно разделить работу между различными машинами. “Сервер” должен иметь достаточно большую оперативную память и дисковое пространство, необходимое для реализации и администрирования БД. “Клиент” нуждается только в памяти, достаточной для выполнения пользовательского приложения (или инструментального средства), которое обеспечивает доступ к БД в узле “Сервер”. Такое разделение обработки данных, называется распределенной обработкой данных. К основным достоинствам такой архитектуры следует отнести:

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

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

запрос на данные в узел “Сервер”, посылается в виде набора SQL утверждений, из узла “Клиент”. Однажды поступив, эти SQL утверждения в дальнейшем будут обрабатываться в узле “Сервер”. При этом в узле “Клиент” не возникает необходимости, передавать какую-либо дополнительную информацию через сеть. Таким образом, количество информации передаваемой через сеть, минимизируется.

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

ORACLE Server специально разрабатывался таким образом, чтобы наиболее полно использовать особенности (связанные с обеспечением многозадачности и разделением памяти) операционной системы, установленной в узле “Сервер”.

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

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

Поддержка национальных языков. ORACLE Corporation осознает что большинство пользователей предпочло бы обращаться с компьютером на своём собственном национальном языке. Однако, некоторые языковые компоненты средств общения пользователя с компьютером определяются общепризнанными стандартами, такими как ISO(Internetional Standards Organization) или ANSI(American National Standards Institute), и не могут быть адаптированы к национальным языкам. ORACLE обеспечивает поддержку национальных языков по трем основным направлениям: сообщения об ошибках, тексты подсказов и последовательность сортировки символьных данных. Все сообщения об ошибках хранятся в наборе, внешнем по отношению к программному обеспечению ORACLE. Поэтому, каждая система ORACLE Server , может быть настроена на требуемый язык. ORACLE также может формировать и вычислять даты в нескольких вариантах, согласно стандартам ISO и другим соглашением. Сортировка символьных данных выполняется в соответствии с соглашениями, принятыми в соответствующем национальном языке.

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

Объекты пользовательских баз данных.

Базы данных (Databases).

База данных ORACLE - это совокупность данных, которая трактуется как единое целое. На физическом уровне база данных состоит из трех различных типов объектов: файлов баз данных (Database Files), файлов регистрационного журнала (Redo Log Files) и управляющих файлов (Control Files).

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

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

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

В большинстве случаев ORACLE Server работает с одной БД. Однако, он может работать и с несколькими БД.

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

В процессе создания БД, необходимо также указать объем дискового пространства, которое будет занимать данная база. При этом ORACLE становится `собственником' этого пространства, и никакие другие файлы операционной системы не могут быть в нем размещены.

Если в процессе работы оказывается, что для хранения БД требуется больший объем памяти, то первоначально заданный объем может быть расширен.

Таблицы (Tables).

Таблицы являются основной единицей хранения информации в БД ORACLE. Информация хранится в строках и колонках. Каждая таблица имеет свое собственное уникальное имя. Каждая колонка в таблице также имеет свое собственное имя и характеризуется типом данных, хранимых в данной колонке (CHAR, DATE, NUMBER, ...), а также шириной колонки (в ряде случаев ширина колонки может быть предопределена типом данных, например для типа Date).

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

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

Представления (Views).

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

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

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

Наиболее часто представление используется для того, чтобы:

обеспечить дополнительный уровень секретности за счет ограничения доступа к заранее определенному множеству строк и/или колонок из базовой таблицы;

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

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

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

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

Индексы (Indexes).

Индексы - это не обязательные структуры, которые могут быть связаны с таблицами и кластерами. Они могут быть созданы по следующим причинам:

1.Индексы увеличивают скорость выполнения запросов.

Индексы ORACLE обеспечивают быстрый поиск пути доступа к данным в БД ORACLE. При правильном использовании индексы являются основным средством, позволяющим уменьшить количество обращений к диску при поиске данных.

2.Индексы могут обеспечить уникальность.

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

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

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

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

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

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

Генератор последовательностей (Sequence Generator).

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

Когда последовательность создается в первый раз, необходимо специфицировать “определение последовательности” (Sequense Definition). Определение последовательности создается с помощью SQL утверждений, которые специфицируют такие опции, как: имя последовательности, верхняя и нижняя границы, возрастающая или убывающая последовательность, шаг, допускается ли повторное использование чисел. Так как последовательности чисел генерируются независимо от таблиц, одна и та же последовательность может быть использована для одной или нескольких таблиц. После того, как она создана, последовательность может быть доступна различным пользователям.

Типы данных ORACLE.

В ORACLE при определении колонок таблиц баз данных используются следующие типы данных:

- типы данных CHAR и VARCNAR,

- тип данных NUMDER,

- тип данных DATE,

- тип данных LONG,

- тип данных RAW,

- тип данных LONGRAW.

Типы данных СHAR и VARCHAR.

Типы данных CHAR и VARCHAR эквивалентны. Эти типы используются для хранения алфавитно-цифровой информации. При описании типа колонки вы можете с одинаковым эффектом использовать любые из этих ключевых слов.

Данные хранятся в виде строк переменной длинны в ASCII(American Standard Code for Information Interchange) или EBCDIC(Extended Binary Coded Decimal Inchange Code) кодах, в зависимости от того, какой код используется в ORACLE Server. Использование нестандартного кода может привести к потере совместимости при использовании машин с различной архитектурой в распределенной сети.

Максимальное количество символов, которое может храниться в типе CHAR (VARCHAR)-255. Максимальная длинна колонки задается при создании таблицы и может быть изменена в дальнейшем.

Оба типа хранят только то количество символов, которое было фактически введено. Например, предположим, что колонке присвоен тип CHAR с максимальной длинной 50 символов. Если только 10 символов введено в отдельную позицию колонки, то на диске будет храниться 10, а не 50 символов.

До версии 6.0 типы CHAR и VARCHAR эквивалентны. В последующих версиях CHAR будет соответствовать строкам фиксированной длины, а VARCHAR будет использоваться для строк переменной длины.

Тип данных NUMBER.

Тип NUMBER используется для хранения чисел с плавающей или фиксированной точкой. Могут быть представлены числа с точностью до 38 цифр. Максимальное значение хранимого числа 9.99х10 в 99 степени, или 1 за которой следует 100 нулей.

Для числовых колонок вы можете просто описать колонку как NUMBER, а также при необходимости указать точность (Precision) - общее количество цифр в числе и масштаб (Scale) - количество цифр справа от десятичной точки (см. пример на рис. 3-1).

Значение шкалы не может быть больше 38. Вы можете задать шкалу и не задавать точность.

Тип данных DATE.

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

ORACLE позволяет хранить даты в диапазоне от 1 января 14719 г. до нашей эры (ВС) до 31 декабря 4712 года нашей эры (АС). Если спецификация “ВС” не используется, подразумевается “АС”.

Время хранится в 24-часовом формате HH:MM:SS. По умолчанию, если время не вводится, то время в поле дата устанавливается в 12:00:00 ночи (полночь). При вводе только времени, дата устанавливается равной системой дате компьютера.

Тип данных LONG.

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

Тип данных RAW и LONG RAW.

Типы RAW и LONG RAW используются для хранения данных, которые не должны преобразовываться ORACLE, при передаче данных между различными системами. Эти типы предназначены для хранения двоичных данных и могут использоваться для хранения графических образов.

Тип RAW эквивалентен типу CHAR , а тип LONG RAW эквивалентен типу LONG, за исключением тех случаев, когда они передаются через SQL*Net. В этих случаях значения типа CHAR и LONG преобразуются в соответствии с используемой кодировкой символов, для RAW и LONG RAW такие преобразования не выполняются.

Представление неопределенных значений (Null Valuees).

Неопределенное значение обозначает отсутствие значения в колонке. Это значение в буквальном смысле означает “ничего” и обычно используется для того, чтобы идентифицировать ошибочные, неизвестные или непригодные данные. Неопределенное значение не следует использовать для представления, каких либо других значений, например нуля. Если при определении колонки таблицы не было специфицированно NOT NULL , неопределенные значения в колонке будут разрешены. Если же колонка специфицирована как NOT NULL, ни одна строка не может быть введена в таблицу, если значение в этой колонке не определено.

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

Словарь данных (DATA DICTIONARY).

Множество справочных таблиц общих для каждой БД ORACLE, называемых словарем данных.

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

пользовательские имена пользователей ORACLE;

права (привилегии), которые представлены пользователями;

имена всех объектов БД (таблицы, представления, индексы и т.д.);

информацию о первичных и внешних ключах;

значения для колонок по умолчанию;

ограничения, определенные для таблиц;

количество дискового пространства, которое было затребовано и которое фактически используется для пользовательских объектов в БД;

контрольную информацию о доступе и обновлении объектов БД;

другую информацию о БД.

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

Словарь данных создается одновременно с созданием базы данных. Для того, чтобы адекватно отражать состояние базы данных в каждый момент времени, словарь автоматически обновляется средствами ORACLE Server при выполнении каждого SQL утверждения. В каждый момент времени, словарь данных доступен в качестве справочника для любого пользователя, вне зависимости от того, создал или нет, этот пользователь какой либо объект базы данных.

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

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

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

Выводы по разделу

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

ГЛАВА 3. ИСПЫТАНИЕ И ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ «РЕГИСТРАТУРА»

3.1 Испытание и тестирование АС «РЕГИСТРАТУРА»

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

Тестирование (testing), процесс выполнения программы или части программы, с намерением или целью найти ошибки;

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

Контроль (verification), попытка найти ошибки в тестовой, или моделируемой, среде;

Испытание (validation), попытка найти ошибки, выполняя программу в заданной реальной среде;

Аттестация (certification), авторитетное подтверждение правильности программы, аналогичное аттестации электротехнического оборудования Underwrites Laboratories. При тестировании с целью аттестации выполняется сравнение с некоторыми заранее определённым стандартом;

Отладка (debugging), не является разновидностью тестирования. Хотя «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование - деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки. Эти два вида деятельности связаны - результаты тестирования являются исходными данными для отладки.

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

Тестирование модуля, или автономное тестирование (module testing, unit testing) - контроль отдельного программного модуля, обычно в изолированной среде (т.е. изолированно от всех остальных модулей). Тестирование модуля иногда также включает математическое доказательство.

Тестирование сопряжений (integration testing) - контроль сопряжений между частями системы (модулями, компонентами подсистемами).

Тестирование внешних функций (external function testing) - контроль внешнего поведения системы, определённого внешними спецификаторами.

Комплексное тестирование (system testing) - контроль и/или испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в среде реальной, жизненной.

Тестирование приемлемости (acceptance testing) - проверка соответствия программы требованиям пользователя.

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

Верификацию, тестирование и испытания разрабатываемой АС «Регистратура» будем производить в соответствии со стандартами ES-PSS-05 by European Space Agency (ESA).

Верификация обозначает:

действие по проверке, инспекции, тестированию, контролю элементов, процессов и устройств, определённых требованиями
ANSI - 78

процесс определения удовлетворяют ли продукты данной фазы ЖЦ ПО требованиям, сформулированным на протяжении предыдущих фаз;

формальное доказательство корректности программы.

верификация необходима для гарантии качества продукта.

Процесс верификации включает в себя:

технические проверки, сквозные контроли и инспекции ПО;

проверки того, что требования к ПО соответствуют требованиям заказчика;

проверки того, что требования к проекту являются соответствующими требованиям ПО;

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

автономное тестирование;

системное тестирование;

приёмочное тестирование;

ревизии.

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

Объект испытаний

Объектом испытаний является система 'Регистратура', в виде исполняемого модуля Registrat.exe и файлов базы данных, написанного под операционные системы Windows 9x или Windows NT v.4.0.

Цель испытаний

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

Требования к программной документации

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

техническое задание;

техническое предложение;

техническое описание продукта;

руководство системного программиста;

руководство пользователя.

Средства и порядок испытаний

Для тестирования необходима ПЭВМ типа IBM, с процессором не ниже Pentium 200MHz, оперативной памятью не менее 32 Мb, наличием жесткого диска со свободным объемом не менее 1 Гбайт, с установленной операционной системой Windows 9x или Windows NT v.4.0 Service Pack 4.0 или выше.

Тестирование системы должно содержать следующие стадии:

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

тестирование алгоритмов части «диагностика» системы;

тестирование всей системы в целом.

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

тестирование функций;

тестирование защиты от несанкционированного доступа;

тестирование корректности обработки исключительных ситуаций;

тестирование сохранения целостности данных при аварийном завершении работы системы.

Тестирование системы

Используемые методы

Первоначально при кодировании алгоритмов выполняем верификацию программы [19]. Потом тестируем всю систему с помощью методов черного ящика [20] для обнаружения ошибок.

Тестирование модулей в основном ориентировано на принципе белого ящика [21].

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

Исследуем две возможные стратегии тестирования: восходящее и нисходящее [21].

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

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

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

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

Преимущества нисходящего тестирования. По мере того как “скелет” программы “обрастает” новыми модулями, должны добавляться и новые тестовые данные, объем которых увеличивается постепенно, одновременно с разрастанием программы. В результате появляется возможность накапливать тестовые данные вместо раздельного их формирования для каждого модуля.

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

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

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

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

Тестирование функций

Тесты, приведенные в данном пункте, позволяют оценить соответствие функций, реализованных в АС “Регистратура” и функций, описанных в ТЗ.

Тест 1. Пользователю предоставляется возможность просмотра, добавления, изменения, удаления и выдачи на печать информации о:

пациентах;

диагнозах;

оперативных вмешательствах;

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

В результате тестирования выяснилось, что вышеперечисленные функции в АС «Регистратура» работают корректно.

Тестирование защиты от несанкционированного доступа

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

Тест 2.Попытка входа в систему незарегистрированного в СУБД пользователя.

Чтобы проверить функцию входа в систему незарегистрированного пользователя в окне идентификации введем «123» (предполагается, что пользователя с именем «123» не существует). В результате этих действий было выдано сообщение «invalid username/password; logon denied», что свидетельствует о том, что данная система не позволяет использование своих данных пользователям незарегистрированного в СУБД.

Тест 3. Заключается в проверке работы системы защиты.

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

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

Тестирование сохранения целостности данных при аварийном завершении работы системы

Хорошо построенная система гарантирует сохранение если не всех внесенных данных, то, как минимум, целостности данных при аварийном завершении. Применим следующий тест:

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

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

Анализ результатов тестирования

В результате проведения испытания сделаны следующие выводы:

в первой версии системы реализованы практически все описанные в ТЗ функций;

система обрабатывает все исключительные ситуации, которые можно обработать;

система способна работать на машине с указанной минимальной конфигурацией;

3.2 Инструкция пользователя

Запуск системы

Запуск системы осуществляется вызовом исполнимого модуля Registrat.exe при помощи кнопки Пуск/Выполнить, либо при помощи иконки с рабочего стола Windows. При запуске система запрашивает ввод имени пользователя и его пароля (рис.3.1 ).

Рис. 3.1. Диалог входа в систему

При вводе неправильного пароля доступ пользователя к системе запрещается. После правильного ввода пароля открывается окно, показанное на рис. 3.2.

Рис. 3.2. Главная экранная форма регистратура

Эта форма содержит такие справочники как: анкеты больных, профессии, анализы, города, врачи, улицы, болезни (Международный классификатор болезней 10-го пересмотра показанный на рис. 3.3),сотрудники.

Рис. 3.3. Международный классификатор болезней

Далее при нажатии левой кнопки мыши на «Список пациентов» в форме «Регистратура» открывается список пациентов показанный на рис. 3.4.

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

Рис. 3.4. Список пациентов зарегистрированных в поликлинике.

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

Рис. 3.5. Экранная форма «Список пациентов» содержащая вспомогательное меню.

При добавлении улицы открывается форма «справочник улиц» показанная на рис. 3.6 в которую вводится нужная улица.

Рис. 3.6. Справочник улиц

При осуществлении операции «удаление улицы» открывается окно показанное на рис. 3.7

Рис. 3.7. Ошибка

Поиск пациентов

При осуществлении поиска пациентов делаем щелчок левой кнопки мыши, и открывается окно, показанное на рис. 3.8 в котором осуществляется поиск по: ФИО, №амбулаторной карты, дате последнего посещения. После нахождения нужной информации нажимаем на кнопку выход и в дереве пациентов выделяется тот пациент, которого мы искали (рис. 3.9).

Рис. 3.8 Поиск пациентов

Рис. 3.9. Список пациентов

Печать амбулаторной карточки пациента

При выполнении печати электронной карточки пациентов осуществляется связь с текстовым редактором Microsoft Word где стандартными средствами офиса осуществляется печать (рис. 3.10).

Рис. 3.10. Печать амбулаторной карты пациента

Запуск электронной карточки пациента

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

Рис. 3.11. Электронная медицинская карта пациента

Рис. 3.12. Раздел электронной медицинской карты пациента«История болезни»

Рис. 3.13. Добавление новой истории болезни

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

Добавление нового сотрудника и присваивание ему пароля для работы с АС «Регистратура»

Для того, что бы добавить нового сотрудника необходимо в форме «Регистратура» (рис. 3.2) зайти в меню справочники и выбрать раздел «сотрудники» после чего откроется окно показанное на рис. 3.14. В эту форму необходимо ввести следующую информацию: ФИО, логин, пароль, группа пользователей к которой относится данный сотрудник(врач, медсестра, оператор и т.д.) после чего произойдет добавление нового сотрудника.

Рис. 3.14. Справочник сотрудников

Если пароль или логин введены неправильно, то откроется окно изображенное на рис. 3.15

Рис. 3.15. Ошибка ввода

3.3. Экономическое обоснование эффективности внедрения АС 'Регистратура'

3.3.1 Описание характеристик продукта

Характеристика товара

Наименование товара --'Автоматизированная система “Регистратура”.

АС “Регистратура” обеспечивает на базе использования ПЭВМ учет пациентов в регистратуре поликлиники.

АС “Регистратура” выполняет следующие задачи:

Регистрация пациентов. Включает создание новой амбулаторной карточки и заполнение ее данными о пациенте (личные данные, медицинская информация);

Просмотр и редактирование информации о пациенте.

Быстрый поиск данных о пациенте.

Хранение лечебно-диагностической информации полученной в результате осмотра пациента.

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

Иметь интуитивно-понятный интерфейс;

Защита информации от несанкционированного доступа.

Таблица 3.1.

Характеристика товара

В табл. 3.1 приведены характеристики АС 'Регистратура'

3.3.2 Особенности товара

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

Установка АС 'Регистратура' позволит повысить эффективность работы медицинского персонала и качества оказания медицинской помощи.

3.3.3 Система сервиса

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

3.3.4 Гарантии и защита потребительских прав

Гарантируется получение в обусловленные договором сроки надежного, эффективного и простого в эксплуатации ПО ('Автоматизированная система 'Регистратура').

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

3.3.5 Исследование и анализ рынков сбыта

3.3.5.1 Маркетинговые исследования рынка сбыта АС «Регистратура»

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

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

, (3.1)

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

, (3.2)

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

Сегментирование и расчеты емкости рынка представлены в табл. 3.2.

Таблица 3.2

Сегментирование и расчеты емкости рынка

По таблице 3.2. определили, что полная потребность рынка составляет 54 копии.

3.3.5.2 Параметрическая сегментация рынка

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

Таким образом, для параметрического анализа ограничимся следующими характеристиками продукта:

требования к ресурсам;

набор функций;

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

надежность;

скорость обработки данных;

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

3.3.5.3 Стратегия маркетинга

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

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

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

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

Организуется послепродажное обслуживание (сопровождение):

Покупатель становится зарегистрированным пользователем;

Сообщение об обнаруженных ошибках в документации и программном продукте, бесплатный обмен старой версии программы на новую исправленную версию;

Обучение зарегистрированных пользователей эксплуатации данного программного продукта;

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

3.3.6 Оценка риска и страхование

Наиболее вероятными рисками могут быть:

несанкционированное копирование с целью дальнейшего использования;

несанкционированное копирование с целью продаж.

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

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

3.3.7 Оценка затрат на разработку программного продукта

3.3.7.1 Определение потребности в материальных и трудовых ресурсах. Для разработки программного продукта требуется два инженера-программиста, оплата труда которых составляет 215 грн./мес. (22 рабочих дня в месяце). После определения общих затрат, связанных со всей разработкой проекта, оцениваем затраты для всего проекта. Просуммировав общие и долевые затраты, определим стоимость всей разработки программного продукта. Рассчитаем общие затраты на разработку проекта.

Расходы на материалы представлены в табл. 3.3.

Таблица 3.3

Расходы на материалы

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

3.3.7.2 Расчет себестоимости и договорной цены программного продукта

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

Трудоемкость работ по алгоритмизации и программированию:

, (3.3)

где - трудоемкость изучения описания задачи и формулировки её постановки (чел. - дни);

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

- трудоемкость построения схем алгоритмов (чел. - дни);

- трудоемкость непосредственного кодирования программы (чел. - дни);

- трудоемкость отладки программы (чел. - дни);

- трудоемкость оформления документации.

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

В общем виде

, (3.4)

где q - предполагаемое число команд программы (q=5000);

k - коэффициент сложности программы (k=1.3);

n - количество коррекций в программе (n=3 с коррекцией 0.05, n=1 с коррекцией 0.07);

- коэффициент коррекции программы.

Согласно вышеприведенным данным получаем условное количество операторов программы Q = 7930.

Трудозатраты на изучение описания задачи рассчитываются по формуле

, (3.5)

где V - производительность исполнителя (команд/час), данные приведены в таблице 3.4;

- коэффициент квалификации исполнителя, = 1.2 (т.к. стаж работы исполнителя до 5 лет);

- коэффициент, учитывающий качество описания задачи (=1.2).

Величины трудозатрат рассчитываются по формуле

, (3.6)

где j - вид работ;

Vj- производительность исполнителя для j-го вида работы (таблица 3.4).

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

Таблица 3.4

Данные о производительности исполнителя

Результаты расчета трудоемкости представлены в таблице 3.5

Таблица 3.5

Результат расчета трудоемкости

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

Фонд основной заработной платы можно определить по формуле:

, (3.7)

где Т - трудоемкость работы, в нашем случае Т = 138 чел./дня;

- среднедневная заработная плата определяется по формуле

, (3.8)

где =215 грн. - месячная заработная плата;

Ф - количество рабочих дней в месяце при пятидневной рабочей недели Ф = 22.

Согласно (3.7) и (3.8) получаем 9,77 грн., = 1348,26 грн.

Дополнительная заработная плата составляет 10..20 % от основной заработной платы (пусть Здоп составляет 10 %).

Получаем дополнительную заработную плату Здоп=134,83 грн.

Фонд заработной платы составляет Зос+Здоп =1483,09 грн.

Прочие прямые расходы составляют эксплуатационные расходы и амортизационные отчисления.

Эксплуатационные расходы рассчитаем по формуле

, (3.9)

где - время кодирования и отладки программного продукта на ЭВМ

; (3.10)

- стоимость машинного времени (= 2 грн/час);

m - средние затраты машинного времени на кодирование и отладку одной условной команды (m = 10 мин). Тмв=1101,39.

Эксплуатационные расходы составляют

Зэр = 2202,78 грн.

АМО - 25 % от стоимости основных фондов. Стоимость основных фондов определяется исходя из количества используемых ПЭВМ на момент проектирования по рыночным ценам.

Накладные расходы составляют 50 % от заработной платы.

Командировочные расходы составляют 15 % от заработной платы.

Сметная калькуляция на разработку программного продукта представлена в таблице 3.6

Себестоимость разработки по комплексному дипломному проекту составляют сумму затрат на разработку программного продукта и затрат на материалы 6079,54 грн.

Цена разработки рассчитывается по формуле

= 7903,4 грн., (3.11)

где П - плановая прибыль.

, (3.12)

- коэффициент рентабельности (%), принимается в размере 30%.

Налог на прибыль (30% от П):

Пн=547,16 грн.

Чистая прибыль

= 1276,70 грн. (3.13)

Таблица 3.6

Сметная калькуляция на разработку программного продукта

Вычислим минимальную цену программного продукта

, (3.14)

где - затраты на тиражирование

= 38 грн, (3.15)

где - стоимость одного машинного часа (2 грн/час);

- время кодирования системы (1 час);

- стоимость одной дискеты (1,55 грн);

Зм - затраты на документацию (500 листов А4 - 18,50 грн);

- заработная плата исполнителя за время кодирования (1 час);

Nпродаж - число предполагаемых продаж;

Nпродаж = 54 копии;

- затраты на адаптацию;

= 303,98 грн; (3.16)

Цразр - цена разработки;

Цразр = 9484,08 грн.

= 517,61 грн. = 9826,06 грн.

Установим цену одной копии = 599 грн.

3.3.7.3 Разработка финансового плана

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

Точку безубыточности рассчитаем по формуле:

Цx +x, (3.17)

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

- условно-переменные затраты - тиражирование и адаптация одной проданной копии = 341,98 грн.

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

График достижения безубыточности разработки программного продукта представлен на рис. 3.16.

Рис. 3.16. График достижения безубыточности разработки

3.8 Безопасность жизнедеятельности. Характеристика ВЦ

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

Производственным помещением является вычислительный центр (ВЦ).

В помещении вредных веществ нет.

Рис. 3.17. Вычислительный центр

1 - щит общего пользования, 2 - розетка,

3 - компьютер, 4 - принтер,

5 - сканер, 6 - ксерокс

Выявление и анализ вредных и опасных факторов действующих в условиях ВЦ

Согласно ГОСТ 12.0.003-74 для машинного зала опасными и вредными факторами, негативно воздействующие на здоровье рабочего персонала ВЦ, являются:

а) физические факторы;

б) психофизические факторы.

К физическим факторам относятся:

повышенный уровень электромагнитного излучения;

недостаточная освещённость рабочего места;

высокий уровень статического электричества;

повышенный уровень шума;

повышенная/пониженная влажность воздуха;

повышенная/пониженная температуру воздуха;

повышенная/пониженная подвижность воздуха.

К психофизическим факторам относятся:

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

монотонность труда;

эмоциональные перегрузки.

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

Разработка мероприятий по снижению или исключению опасных факторов и их нормирование

Шум

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

Допустимые уровни звукового давления в октавных полосах частот, уровни звука и эквивалентные уровни звука в дБА на рабочих местах (ГОСТ 112.1.003-76) приведены в (табл. 3.7.).

Таблица 3.7

Уровни звука

Защита от шума: звукопоглощающие материалы, наушники.

Пожарная безопасность

1. В помещении около 100 м должен находиться огнетушитель (углекислотный) переносной ТУ У 13 485 476.003 96 ОУ-2.

2. Должна быть установлена противопожарная сигнализация.

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

В ГОСТ 12.1.005-88 указано, что при легкой (1а) категории выполняемых работ, должны обеспечиваться:

температура воздуха в помещениях машинного зала для холодного периода 22-24С, для теплого периода 23-25С;

относительная влажность воздуха 40-60%;

скорость движения воздуха не более 0,1 м/с.

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

Для предотвращения поражения человека электрическим током принимают следующие меры:

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

ремонтные и профилактические работы на ЭВМ может производить специалист, имеющий квалификационную группу по технике безопасности не ниже третьей по работе с электрооборудованием до 1000 В;

запрещается эксплуатация ЭВМ в помещениях с химически агрессивной средой, а также при снятых деталях корпуса;

ремонтные и профилактические работы на электроустановках, установка и снятие корпусов ЭВМ допускается только при отключенном электропитании;

корпуса электроустройств должны быть надежно заземлены, сопротивление заземляющего устройства должно быть не более 4 Ом, при напряжении свыше 1000 В - не более 10 Ом;

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

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

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

Для защиты персонала ВЦ от статического электричества необходимо использовать нейтрализаторы, полы иметь антистатическое покрытие. Допустимый уровень напряженности электростатического поля составляет 20 кВ/м за 1 час (ГОСТ 12.1045-84).

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

располагают монитор на расстоянии более 30 см от глаз;

устанавливают защитные экраны на монитор;

применение мониторов с пониженными показателями ионизирующего излучения.

Следует также делать частые перерывы (в 1 час работы - 10-15 минут отдыха). Людям особо чувствительным следует сократить время работы с компьютером до минимума.

Уровень шумов не должен превышать 75 дБ. Уровень шума IBM-совместимого компьютера составляет 25 дБ. При использовании такого рода техники мероприятия по снижению шума не проводят.

Расчет вентиляции ВЦ

Расчет типа вентиляции

Произведем расчет количества воздуха для борьбы с избыточным теплом по формуле:

, (3.18)

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

С = 1000 Дж/(кг?К) - средняя удельная теплоемкость воздуха;

г = 1.215 кг/ - удельная масса воздуха, поступающего в помещение при температуре Т = 290 К;

ТП = 295 К - температура удаляемого из помещения воздуха;

ТН = 290 К - температура при которой воздух поступает в помещение.

Определяем избыточное количество тепла, которое складывается из тепла, выделяемого одновременно всеми источниками в производственном помещении, минус потери тепла через внешние ограждения и оконные проемы:

, (3.19)

где - количество тепла, выделяемого одновременно всеми источниками в производственном помещении;

- потери тепла через внешние ограждения и оконные проемы.

Расчитаем количество тепла, выделяемого одновременно всеми источниками в производственном помещении:

, (3.20)

где -тепловыделения от оборудования;

-тепловыделения от людей;

-тепловыделения от искусственного освещения;

-тепловыделения от солнечной радиации.

Определим тепловыделения от оборудования по формуле:

= (3.21)

Вт ,

где = 100 Вт - номинальная мощность единицы оборудования;

= 6 шт. - количество единиц оборудования.

Определим тепловыделения тепловыделения от людей по формуле:

Вт , (3.22)

где = 5 человек - количество людей, работающих в ВЦ.

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

Вт , (3.23)

где = 250 Вт - мощность одной лампы накаливания;

m = 15 шт. - количество ламп накаливания.

Определим тепловыделения от солнечной радиации по формуле:

Вт , (3.24)

где F = 15 - площадь световых проемов;

q = 144 ккал/(ч·) - количество теплоты, вносимой радиацией через световые проемы, так как фонарей нет, то тепловыделения через фонари не учитывается.

Найденные данные подставляем и получаем результат:

Вт

Рассчитаем потери тепла через внешние ограждения и оконные проемы:

, (3.25)

где - потери тепла через внешние ограждения;

- потери тепла через оконные проемы.

Теплопотери через внешние ограждения будут равны нулю, так как внешних ограждений нет, т. е. = 0 Вт.

Определим теплопотери через оконные проемы по формуле:

(3.26)

Вт ,

где F = 15 - площадь световых проемов;

к = 2.6 ккал/(ч·) - коэффициент теплопередачи оконных проемов;

ТП = 295 К - температура удаляемого из помещения воздуха;

ТН = 290 К - температура при которой воздух поступает в помещение.

Найденные данные подставляем и получаем результат:

Вт .

Найденные данные подставляем и получаем результат:

Вт

Найденные данные подставляем и получаем, что количество воздуха для борьбы с избыточным теплом равно:

.

Произведем расчет кратности воздухообмена, по формуле:

, (3.27)

где L = 4006 - количество воздуха для борьбы с избыточным теплом;

= 60 - объем помещения.

Так как кратность воздухообмена больше 30, то необходимо рассчитать механическую вентиляцию.

Выбор вентилятора

Вентилятор центробежный типа Ц4-70 №10.

Производительность вентилятора: L = 5000

Полное давление: P = 200 Па.

Окружная скорость колеса: 20 м/с.

Количество оборотов в минуту: 300 об/мин.

Определим потребную мощность на валу электродвигателя N в кВт при перемещении чистого воздуха для стандартных условий:

(3.28)

кВт ,

где L = 5000 - производительность вентилятора;

P=200 Па - полное давление;

=0.6 - КПД вентилятора;

= 1.0 - КПД передачи, вентилятор насажен на вал электродвигателя.

Определим установленную мощность электродвигателя Nу с учетом запаса в кВт:

кВт . (3.29)

где Кз = 1.15 - коэффициент запаса мощности;

N = 4.5 кВт - потребная мощность на валу электродвигателя.

3.3.9 Гражданская оборона

Анализ чрезвычайной ситуации

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

Общими признаками ЧС являются:

гибель или угроза гибели людей либо серьезное нарушение условий их жизнедеятельности;

наличие экономических убытков;

существенное ухудшение условий окружающей среды.

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

Согласно причинам возникновения ЧС, которые могут возникнуть на территории Украины, они делятся:

ЧС природного характера;

ЧС социально-политического характера;

ЧС военного характера;

ЧС техногенного характера.

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

Причинами возникновения ЧС техногенного характера могут служить следующие:

значительное количество технически отсталых производств;

использование в производстве потенциально опасных веществ;

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

возрастание количества случаев нарушения техники безопасности;

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

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

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

региональный;

местный;

объектный.

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

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

Аварии на тепловых сетях (система подачи горячей воды) в холодное время года.

Разрушение зданий и сооружений.

Оценка ожидаемой пожарной обстановки

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

Выделяют три зоны пожара на объекте:

зона отдельных пожаров;

зона сплошных пожаров;

зона горения и тления в завалах.

Исходные данные для проведения анализа и оценки пожарной обстановки приведены в таблице 3.8.

Таблица 3.8

Данные для проведения анализа и оценки пожарной обстановки

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

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

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

Величина радиусов внешних границ зон отдельных пожаров и зон сплошных пожаров определяется последующим формулам:

(3.30)

(3.31)

где - удельная теплоемкость горючего вещества;

Q - масса горючего вещества.

Удельная теплоемкость бензина [Дж/кг].

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

(3.32)

где - величина плотности энергии инфракрасного излучения от пожара,[Дж/м];

- удельная теплоемкость горючего вещества, [Дж/кг].

Q - масса горючего вещества, [кг].

R - расстояние от центра пожара к конкретному объекту.

.

Величина радиуса огня пожара при разливе и возгорании бензина определяют по следующей формуле:

, (3.33)

где - удельный вес бензина, [т/м], .

.

Схема расположения ВЦ относительно источника пожара приведена на рис. 3.18.

/

Рис. 3.18. Схема расположения ВЦ относительно источника пожара:

1 - зона горения ;

2 - зона сплошных пожаров;

3 - зона отдельных пожаров.

По таблице определим устойчивость объекта к инфракрасного импульса.

Таблица 3.9

Данные для определения устойчивости объекта к инфракрасного импульса

Выводы по разделу

В результате разработки элементов бизнес-плана были получены следующие результаты:

затраты на разработку - 9484,08 грн.;

затраты на тиражирование и адаптацию -341,98 грн.;

цена одной копии программного продукта - 599 грн.

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

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

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

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

Потерь производственных фондов нет, так - как инфракрасный импульс, возникший вследствие пожара не вызовет пожара в помещении.

Мероприятия, которые можно провести по повышению огнеустойчивости:

регулярное очищение зоны от временных завалов;

повышение огнеустойчивости кровли (замена толи рубероидом);

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

АННОТАЦИЯ

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

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

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

Методы исследования: Для написания программного обеспечения использовалась реляционная модель данных, среда программирования Delphi, СУБД Oracle.

Проведен обзор медицинских автоматизированных информационных систем, на основе анализа проведено моделирование автоматизированной системы «Регистратура»; проведены испытания и экономическое обоснование АС «Регистратура»

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

автоматизированная система учет

Закон Украины №2801-XII от 19.09.1992 г. «Основы законодательства Украины про охрану здоровья»

Медична облікова документація, що використовується в поліклініках (амбулаторіях) МОЗ України, Київ, 1999 р.

Медична облікова документація, що використовується в сиационарах МОЗ України, Київ, 1999 р.

Методические указания по дипломному проектированию для студентов дневной формы обучения по специальности 7.080401 'Информационные управляющие системы и технологии'

Единая система программной документации. -М: Издательство стандартов, 1988.

Гради Буч. Объектно-ориентированный анализ и проектирование. -М.: Издательство Бином

Бойко В.В., Савинков В.М. Проектирование информационной базы автоматизированной системы на основе СУБД. - М.: Финансы и статистика, 1982.

Джексон Г. Проектирование реляционных баз данных для использования с микро-ЭВМ. - М.: Финансы и статистика, 1991.

Маклаков С.В. BPWin и ERWin CASE-средства разработки информационных систем. - М.: ДИАЛОГ МИФИ, 2000.

Грин Д., Кнут Д. Математические методы анализа алгоритмов. - М. Мир, Овсяникова М.В., Федин В.А. Функциональные зависимости и нормализация реляционных БД. Методическое пособие. -М: Моск. Энерг. Инст., 1987.

Гудман С. Введение в разработку и анализ алгоритмов. - М.: Мир, 1981.

Ульман Дж. Основы систем баз данных. - М.: Финансы и статистика, 1983.

Система управления госпиталем «MedTrak». Адрес в Интернете www.sparm.com/medtrak

Госпитальная информационная система «Авиценна». Адрес в Интернете www.medmail.ru/medstat

Программный комплекс «Управление поликлиникой». Адрес в Интернете www.medik.ru/polik

Медицинская информационная система «Амулет-клиника». Адрес в Интернете www.klinika.com/amylet

Система «MedWork» компании Master Labs. Адрес в Интернете www.medwork.ru

Фаронов В.В. Delphi3 Учебный курс- М: Издательство 'Нолидж',1998.

Баас.Р.,Фервай М., Гюнтер Х. Delphi 4 Для пользователя, BHV Киев, 1999.

Урман С. Oracle 8. Программирование на языке PL/SQL. - М.: Лори, 1999.

Дейт К. Дж. Введение в системы баз данных. - М: Вильямс, 1999.

Борзов Ю.В. Методы тестирования и отладки программ ЭВМ. - Рига, ЛГУ им. П. Стучки, 1980.

Майерс Г.Д. Надёжность программного обеспечения. - М.: Мир, 1980.

Майерс Г.Д. Искусство тестирования программ. - М.: Финансы и статистика, 1982.

Г.Майерс “Надежность программного обеспечения”./пер. с англ. под ред. Б.А.Позина - М.:Финансы и статистика 1982 - 176 стр.

Липаев В.В. “Качество программного обеспечения”.М.:Мир, 1983.

Боэм Б. и др. “Характеристики качества программного обеспечения”. М.:Мир, 1981.

К.Г.Гусев “Основы теории надежности”.Харьков ХАИ 1975.

С. Канер, Д.Фолк, Е.К.Нгуен “Тестирование программного обеспечения ” /Пер. на русский язык. Издательство “ДиаСофт”, 2000г.

Пелих А.С. Бизнес план или как организовать собственный бизнес.-М.: Ось-89, 1997.

Тони Скоун . Управленческий учёт .-М.: Аудит,Юнити,1997.

Закон Украины об охране окружающей природной среды от 25.06.91г.

Закон Украины об охране труда от 25.11.92г.

Долин П.А. Справочник по технике безопасности.-М.:Энергоатомиздат, 1984.

ОНТП 10-90. Общесоюзные нормы технологического проектирования. Определение категорий зданий и сооружений по взрывопожарной и пожарной опасности.-М.: Стройиздат, 1991.

СНиП 2.01.02-85. Строительные нормы и правила. Противопожарные нормы проектирования зданий и сооружений.-М.:Стройиздат, 1986.

ГОСТ 12.0.003-74. 1ССБТ. Опасные и вредные производственные факторы. Классификация. - Введ. 01.01.76.

ГОСТ 12.1.004-91 СББТ. Пожарная безопасность. Общие требования.-Введ.01.01.87.

ПРИЛОЖЕНИЕ

Листинг программного обеспечения

unit Main;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,Constants,

StdCtrls, ComCtrls;

type

TMainForm = class(TForm)

StatusBar1: TStatusBar;

procedure FormActivate(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

MainForm: TMainForm;

implementation

uses Module;

{$R *.DFM}

procedure TMainForm.FormActivate(Sender: TObject);

var S:String;

begin

//if Date >StrToDateTime('12.06.2002') then Close;

case People_DTYPE of

0:S:

1:S:=

2:S:=' врач ';

3:S:='

end;

StatusBar1.Panels[0].Text:=' '+S+People_F+' '+People_I+' '+People_O;

DM.QRengen.DataBaseName:=g_NSILocation;

DM.QRengen1.DataBaseName:=g_NSILocation;

DM.QFlurka.DataBaseName:=g_NSILocation;

DM.QFlurka1.DataBaseName:=g_NSILocation;

DM.QLifeFun.DataBaseName:=g_NSILocation;

DM.QLifeFun1.DataBaseName:=g_NSILocation;

DM.QKartaUpdate.DataBaseName:=g_NSILocation;

DM.QKarta.DataBaseName:=g_NSILocation;

DM.QKartaSt.DataBaseName:=g_NSILocation;

DM.QVesRost.DataBaseName:=g_NSILocation;

DM.QHistory.DataBaseName:=g_NSILocation;

DM.QZabolevan.DataBaseName:=g_NSILocation;

DM.QTravmi.DataBaseName:=g_NSILocation;

DM.QOperat.DataBaseName:=g_NSILocation;

DM.QSanator.DataBaseName:=g_NSILocation;

DM.QNasledst.DataBaseName:=g_NSILocation;

DM.QPrivivka.DataBaseName:=g_NSILocation;

DM.QPrivichka.DataBaseName:=g_NSILocation;

DM.QOsob_notes.DataBaseName:=g_NSILocation;

DM.QPeriodOsm.DataBaseName:=g_NSILocation;

DM.QZaklDiag.DataBaseName:=g_NSILocation;

DM.QNaprAnaliz.DataBaseName:=g_NSILocation;

DM.QRecept.DataBaseName:=g_NSILocation;

DM.QOsvobWork.DataBaseName:=g_NSILocation;

DM.QHistoryDate.DataBaseName:=g_NSILocation;

DM.QKarta.Open;

end;

end.

unit PeopleList;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

Grids, Wwdbigrd, Wwdbgrid, ExtCtrls, ComCtrls,NsiTypes;

type

TPeopleListForm = class(TForm)

TV: TTreeView;

Splitter1: TSplitter;

wwDBGrid1: TwwDBGrid;

procedure FormActivate(Sender: TObject);

procedure TVExpanding(Sender: TObject; Node: TTreeNode;

var AllowExpansion: Boolean);

procedure TVChange(Sender: TObject; Node: TTreeNode);

procedure TVDblClick(Sender: TObject);

procedure wwDBGrid1DblClick(Sender: TObject);

procedure AddKarta(Sender: TObject);

procedure RebuildTree;

procedure ExpandLevel( Node : TTreeNode);

private

{ Private declarations }

public

{ Public declarations }

end;

var

PeopleListForm: TPeopleListForm;

implementation

uses Module, People;

{$R *.DFM}

{ TPeopleListForm }

procedure TPeopleListForm.RebuildTree;

begin

//LastNode:=nil;

TV.Tag:=1;

TV.Items.BeginUpdate;

TV.Items.Clear;

TV.Items.EndUpdate;

TV.Tag:=0;

ExpandLevel(nil);

if TV.Items.Count>0 then

begin

TV.Selected:=TV.Items[0];

// LastNode:=TV.Items[0];

end;

end;

procedure TPeopleListForm.ExpandLevel(Node: TTreeNode);

Var ID , i : Integer;

TreeNode : TTreeNode;

fio:String;

N1:TNSI;

Old_ID:Word;

begin

try

IF Node = nil Then ID:=0 Else ID:=Integer(Node.Data);

TV.Items.BeginUpdate;

if ID = 0 then

begin

N1:=TLineNSI.Create(nil,nil,nil,'NsiStreet','');

N1.RefreshHead;

For i:=1 To N1.HeadData.RecordCount Do

Begin

{ fio:=DM.QKarta.FieldByName('NUMKART').AsString+' '+

DM.QKarta.FieldByName('F').AsString+' '+

Copy(DM.QKarta.FieldByName('I').AsString,1,1)+'.'+

Copy(DM.QKarta.FieldByName('O').AsString,1,1)+'.';}

TreeNode:=TV.Items.AddChildObject(Node ,N1.HeadData.FieldByName('NAME').AsString,

Pointer(N1.HeadData.FieldByName('KOD').AsInteger));

TV.Items.AddChildObject(TreeNode,'', nil);

N1.HeadData.Next;

End;

end else

begin

if Node.Level = 0 then

begin

Old_ID:=DM.QKartaSt.ParamByName('ID_ST').asInteger;

DM.QKartaSt.Close;

DM.QKartaSt.ParamByName('ID_ST').asInteger:=Integer(Node.Data);

DM.QKartaSt.Open;

while not DM.QKartaSt.Eof do

begin

fio:=DM.QKartaSt.FieldByName('NUMKART').AsString+' '+

DM.QKartaSt.FieldByName('F').AsString+' '+

Copy(DM.QKartaSt.FieldByName('I').AsString,1,1)+'.'+

Copy(DM.QKartaSt.FieldByName('O').AsString,1,1)+'.';

TreeNode:=TV.Items.AddChildObject(Node ,fio,

Pointer(DM.QKartaSt.FieldByName('ID').AsInteger));

TreeNode.ImageIndex:=1;

TreeNode.SelectedIndex:=2;

DM.QKartaSt.Next;

end;

DM.QKartaSt.Close;

DM.QKartaSt.ParamByName('ID_ST').asInteger:=Old_ID;

DM.QKartaSt.Open;

if TV.Selected<>nil

then DM.QKartaSt.Locate('ID',Integer(TV.Selected.Data),[]);

end;

end;

finally

N1.Free;

TV.Items.EndUpdate;

end;

end;

procedure TPeopleListForm.FormActivate(Sender: TObject);

begin

RebuildTree;

end;

procedure TPeopleListForm.TVExpanding(Sender: TObject; Node: TTreeNode;

var AllowExpansion: Boolean);

begin

IF Node = nil Then Exit;

IF Node.getFirstChild.Data = nil

Then Begin

Node.DeleteChildren;

ExpandLevel(Node);

End;

end;

procedure TPeopleForm.ShowFlurkaTable(ID:Word);

var Col:TColumn;

begin

VisiblePanel(Panel6);

with DM.QFlurka do

begin

if not Active then

begin

Close;

ParamByName('ID_KARTA').asInteger:=DM.QKarta.FieldByName('ID').asInteger;

Open;

end;

DBGrid1.Columns.Clear;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='PDATE';

Col.Width:=64;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='RES';

Col.Width:=522;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

if ID<>0 then Locate('ID',ID,[]) else First;

DM.DataSource2.DataSet:=DM.QFlurka;

end;

end;

procedure TPeopleForm.TVDblClick(Sender: TObject);

begin

if TV.Selected<>nil then

begin

case TV.Selected.Level of

0:begin end;

1:begin

case TV.Selected.Parent.Index of

1:try

EditHistoryForm:=TEditHistoryForm.Create(Self);

RefreshDataAfterEdit1(EditHistoryForm,DM.QHistory,ShowHistoryTable);

finally

EditHistoryForm.Free;

end;

3:try

EditLifeFunForm:=TEditLifeFunForm.Create(Self);

RefreshDataAfterEdit1(EditLifeFunForm,DM.QLifeFun,ShowLifeFunTable);

finally

EditLifeFunForm.Free;

end;

4:try

EditVesRostForm:=TEditVesRostForm.Create(Self);

RefreshDataAfterEdit1(EditVesRostForm,DM.QVesRost,ShowVesRostTable);

finally

EditVesRostForm.Free;

end;

5:try

EditPeriodOsmForm:=TEditPeriodOsmForm.Create(Self);

RefreshDataAfterEdit1(EditPeriodOsmForm,DM.QPeriodOsm,ShowPeriodOsmTable);

finally

EditPeriodOsmForm.Free;

end;

6:try

EditZaklDiagForm:=TEditZaklDiagForm.Create(Self);

RefreshDataAfterEdit1(EditZaklDiagForm,DM.QZaklDiag,ShowZaklDiagTable);

finally

EditZaklDiagForm.Free;

end;

7:try

EditNaprAnalizForm:=TEditNaprAnalizForm.Create(Self);

RefreshDataAfterEdit1(EditNaprAnalizForm,DM.QNaprAnaliz,ShowNaprAnalizTable);

finally

EditNaprAnalizForm.Free;

end;

8:try

EditReceptForm:=TEditReceptForm.Create(Self);

RefreshDataAfterEdit1(EditReceptForm,DM.QRecept,ShowReceptTable);

finally

EditReceptForm.Free;

end;

9:try

EditRengenForm:=TEditRengenForm.Create(Self);

RefreshDataAfterEdit1(EditRengenForm,DM.QRengen,ShowRengenTable);

finally

EditRengenForm.Free;

end;

10:try

EditFlurkaForm:=TEditFlurkaForm.Create(Self);

RefreshDataAfterEdit1(EditFlurkaForm,DM.QFlurka,ShowFlurkaTable);

finally

EditFlurkaForm.Free;

end;

11:try

EditOsvobWorkForm:=TEditOsvobWorkForm.Create(Self);

RefreshDataAfterEdit1(EditOsvobWorkForm,DM.QOsvobWork,ShowOsvobWorkTable);

finally

EditOsvobWorkForm.Free;

end;

end;{case}

end;

2:if TV.Selected.Parent.Parent.Index=2 then//Анамнез

begin

case TV.Selected.Parent.Index of

0:try

EditZabolevanForm:=TEditZabolevanForm.Create(Self);

RefreshDataAfterEdit1(EditZabolevanForm,DM.QZabolevan,ShowZabolevanTable);

finally

EditZabolevanForm.Free;

end;

1:try

EditTravmiForm:=TEditTravmiForm.Create(Self);

RefreshDataAfterEdit1(EditTravmiForm,DM.QTravmi,ShowTravmiTable);

finally

EditTravmiForm.Free;

end;

2:try

EditOperatForm:=TEditOperatForm.Create(Self);

RefreshDataAfterEdit1(EditOperatForm,DM.QOperat,ShowOperatTable);

finally

EditOperatForm.Free;

end;

3:try

EditSanatorForm:=TEditSanatorForm.Create(Self);

RefreshDataAfterEdit1(EditSanatorForm,DM.QSanator,ShowSanatorTable);

finally

EditSanatorForm.Free;

end;

4:try

EditNasledstForm:=TEditNasledstForm.Create(Self);

RefreshDataAfterEdit1(EditNasledstForm,DM.QNasledst,ShowNasledstTable);

finally

EditNasledstForm.Free;

end;

5:try

EditPrivivkaForm:=TEditPrivivkaForm.Create(Self);

RefreshDataAfterEdit1(EditPrivivkaForm,DM.QPrivivka,ShowPrivivkaTable);

finally

EditPrivivkaForm.Free;

end;

6:try

EditPrivichkaForm:=TEditPrivichkaForm.Create(Self);

RefreshDataAfterEdit1(EditPrivichkaForm,DM.QPrivichka,ShowPrivichkaTable);

finally

EditPrivichkaForm.Free;

end;

7:try

EditOsob_notesForm:=TEditOsob_notesForm.Create(Self);

RefreshDataAfterEdit1(EditOsob_notesForm,DM.QOsob_notes,ShowOsob_notesTable);

finally

EditOsob_notesForm.Free;

end;

end;{case}

end;

end ;{case}

end;

end;

procedure TPeopleForm.DBGrid1DblClick(Sender: TObject);

begin

if LastNode<>nil then

begin

case LastNode.Level of

0:begin

case LastNode.Index of

1:try

EditHistoryForm:=TEditHistoryForm.Create(Self);

RefreshDataAfterEdit(EditHistoryForm,DM.QHistory,ShowHistoryTable);

finally

EditHistoryForm.Free;

end;

3:try

EditLifeFunForm:=TEditLifeFunForm.Create(Self);

RefreshDataAfterEdit(EditLifeFunForm,DM.QLifeFun,ShowLifeFunTable);

finally

EditLifeFunForm.Free;

end;

4:try

EditVesRostForm:=TEditVesRostForm.Create(Self);

RefreshDataAfterEdit(EditVesRostForm,DM.QVesRost,ShowVesRostTable);

finally

EditVesRostForm.Free;

end;

5:try

EditPeriodOsmForm:=TEditPeriodOsmForm.Create(Self);

RefreshDataAfterEdit(EditPeriodOsmForm,DM.QPeriodOsm,ShowPeriodOsmTable);

finally

EditPeriodOsmForm.Free;

end;

6:try

EditZaklDiagForm:=TEditZaklDiagForm.Create(Self);

RefreshDataAfterEdit(EditZaklDiagForm,DM.QZaklDiag,ShowZaklDiagTable);

finally

EditZaklDiagForm.Free;

end;

7:try

EditNaprAnalizForm:=TEditNaprAnalizForm.Create(Self);

RefreshDataAfterEdit(EditNaprAnalizForm,DM.QNaprAnaliz,ShowNaprAnalizTable);

finally

EditNaprAnalizForm.Free;

end;

8:try

EditReceptForm:=TEditReceptForm.Create(Self);

RefreshDataAfterEdit(EditReceptForm,DM.QRecept,ShowReceptTable);

finally

EditReceptForm.Free;

end;

9:try

EditRengenForm:=TEditRengenForm.Create(Self);

RefreshDataAfterEdit(EditRengenForm,DM.QRengen,ShowRengenTable);

finally

EditRengenForm.Free;

end;

10:try

EditFlurkaForm:=TEditFlurkaForm.Create(Self);

RefreshDataAfterEdit(EditFlurkaForm,DM.QFlurka,ShowFlurkaTable);

finally

EditFlurkaForm.Free;

end;

11:try

EditOsvobWorkForm:=TEditOsvobWorkForm.Create(Self);

RefreshDataAfterEdit(EditOsvobWorkForm,DM.QOsvobWork,ShowOsvobWorkTable);

finally

EditOsvobWorkForm.Free;

end;

end;{case }

end;

1:begin

case TV.Selected.Parent.Index of

1:try

EditHistoryForm:=TEditHistoryForm.Create(Self);

RefreshDataAfterEdit(EditHistoryForm,DM.QHistory,ShowHistoryTable);

finally

EditHistoryForm.Free;

end;

case TV.Selected.Index of

0:try

EditZabolevanForm:=TEditZabolevanForm.Create(Self);

RefreshDataAfterEdit(EditZabolevanForm,DM.QZabolevan,ShowZabolevanTable);

finally

EditZabolevanForm.Free;

end;

1:try

EditTravmiForm:=TEditTravmiForm.Create(Self);

RefreshDataAfterEdit(EditTravmiForm,DM.QTravmi,ShowTravmiTable);

finally

EditTravmiForm.Free;

end;

2:try

EditOperatForm:=TEditOperatForm.Create(Self);

RefreshDataAfterEdit(EditOperatForm,DM.QOperat,ShowOperatTable);

finally

EditOperatForm.Free;

end;

3:try

EditSanatorForm:=TEditSanatorForm.Create(Self);

RefreshDataAfterEdit(EditSanatorForm,DM.QSanator,ShowSanatorTable);

finally

EditSanatorForm.Free;

end;

4:try

EditNasledstForm:=TEditNasledstForm.Create(Self);

RefreshDataAfterEdit(EditNasledstForm,DM.QNasledst,ShowNasledstTable);

finally

EditNasledstForm.Free;

end;

5:try

EditPrivivkaForm:=TEditPrivivkaForm.Create(Self);

RefreshDataAfterEdit(EditPrivivkaForm,DM.QPrivivka,ShowPrivivkaTable);

finally

EditPrivivkaForm.Free;

end;

6:try

EditPrivichkaForm:=TEditPrivichkaForm.Create(Self);

RefreshDataAfterEdit(EditPrivichkaForm,DM.QPrivichka,ShowPrivichkaTable);

finally

EditPrivichkaForm.Free;

end;

7:try

EditOsob_notesForm:=TEditOsob_notesForm.Create(Self);

RefreshDataAfterEdit(EditOsob_notesForm,DM.QOsob_notes,ShowOsob_notesTable);

finally

EditOsob_notesForm.Free;

end;

end;{case}

end;

3:try

EditLifeFunForm:=TEditLifeFunForm.Create(Self);

RefreshDataAfterEdit(EditLifeFunForm,DM.QLifeFun,ShowLifeFunTable);

finally

EditLifeFunForm.Free;

end;

4:try

EditVesRostForm:=TEditVesRostForm.Create(Self);

RefreshDataAfterEdit(EditVesRostForm,DM.QVesRost,ShowVesRostTable);

finally

EditVesRostForm.Free;

end;

5:try

EditPeriodOsmForm:=TEditPeriodOsmForm.Create(Self);

RefreshDataAfterEdit(EditPeriodOsmForm,DM.QPeriodOsm,ShowPeriodOsmTable);

finally

EditPeriodOsmForm.Free;

end;

6:try

EditZaklDiagForm:=TEditZaklDiagForm.Create(Self);

RefreshDataAfterEdit(EditZaklDiagForm,DM.QZaklDiag,ShowZaklDiagTable);

finally

EditZaklDiagForm.Free;

end;

7:try

EditNaprAnalizForm:=TEditNaprAnalizForm.Create(Self);

RefreshDataAfterEdit(EditNaprAnalizForm,DM.QNaprAnaliz,ShowNaprAnalizTable);

finally

EditNaprAnalizForm.Free;

end;

8:try

EditReceptForm:=TEditReceptForm.Create(Self);

RefreshDataAfterEdit(EditReceptForm,DM.QRecept,ShowReceptTable);

finally

EditReceptForm.Free;

end;

9:try

EditRengenForm:=TEditRengenForm.Create(Self);

RefreshDataAfterEdit(EditRengenForm,DM.QRengen,ShowRengenTable);

finally

EditRengenForm.Free;

end;

10:try

EditFlurkaForm:=TEditFlurkaForm.Create(Self);

RefreshDataAfterEdit(EditFlurkaForm,DM.QFlurka,ShowFlurkaTable);

finally

EditFlurkaForm.Free;

end;

11:try

EditOsvobWorkForm:=TEditOsvobWorkForm.Create(Self);

RefreshDataAfterEdit(EditOsvobWorkForm,DM.QOsvobWork,ShowOsvobWorkTable);

finally

EditOsvobWorkForm.Free;

end;

end;{case}

end;

2:if TV.Selected.Parent.Parent.Index=2 then

begin

case TV.Selected.Parent.Index of

0:try

EditZabolevanForm:=TEditZabolevanForm.Create(Self);

RefreshDataAfterEdit(EditZabolevanForm,DM.QZabolevan,ShowZabolevanTable);

finally

EditZabolevanForm.Free;

end;

1:try

EditTravmiForm:=TEditTravmiForm.Create(Self);

RefreshDataAfterEdit(EditTravmiForm,DM.QTravmi,ShowTravmiTable);

finally

EditTravmiForm.Free;

end;

2:try

EditOperatForm:=TEditOperatForm.Create(Self);

RefreshDataAfterEdit(EditOperatForm,DM.QOperat,ShowOperatTable);

finally

EditOperatForm.Free;

end;

3:try

EditSanatorForm:=TEditSanatorForm.Create(Self);

RefreshDataAfterEdit(EditSanatorForm,DM.QSanator,ShowSanatorTable);

finally

EditSanatorForm.Free;

end;

4:try

EditNasledstForm:=TEditNasledstForm.Create(Self);

RefreshDataAfterEdit(EditNasledstForm,DM.QNasledst,ShowNasledstTable);

finally

EditNasledstForm.Free;

end;

5:try

EditPrivivkaForm:=TEditPrivivkaForm.Create(Self);

RefreshDataAfterEdit(EditPrivivkaForm,DM.QPrivivka,ShowPrivivkaTable);

finally

EditPrivivkaForm.Free;

end;

6:try

EditPrivichkaForm:=TEditPrivichkaForm.Create(Self);

RefreshDataAfterEdit(EditPrivichkaForm,DM.QPrivichka,ShowPrivichkaTable);

finally

EditPrivichkaForm.Free;

end;

7:try

EditOsob_notesForm:=TEditOsob_notesForm.Create(Self);

RefreshDataAfterEdit(EditOsob_notesForm,DM.QOsob_notes,ShowOsob_notesTable);

finally

EditOsob_notesForm.Free;

end;

end;{case}

end;

end ;{case}

end;

end;

procedure TPeopleForm.ShowLifeFunTable(ID: Word);

var Col:TColumn;

begin

VisiblePanel(Panel6);

with DM.QLifeFun do

begin

if not Active then

begin

Close;

ParamByName('ID_KARTA').asInteger:=DM.QKarta.FieldByName('ID').asInteger;

Open;

end;

DBGrid1.Columns.Clear;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='PDATE';

Col.Width:=64;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='TEMPER';

Col.Width:=76;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='AD_S';

Col.Width:=140;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='AD_D';

Col.Width:=148;

Col.Title.Caption:=

Col.Alignment:=taLeftJustify;

if ID<>0 then Locate('ID',ID,[]) else First;

DM.DataSource2.DataSet:=DM.QLifeFun;

end;

end;

procedure TPeopleForm.ShowVesRostTable(ID: Word);

var Col:TColumn;

begin

VisiblePanel(Panel6);

with DM.QVesRost do

begin

if not Active then

begin

Close;

ParamByName('ID_KARTA').asInteger:=DM.QKarta.FieldByName('ID').asInteger;

Open;

end;

DBGrid1.Columns.Clear;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='PDATE';

Col.Width:=64;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='VES';

Col.Width:=87;

Col.Title.Caption

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='ROST';

Col.Width:=97;

Col.Title.Caption:=

Col.Alignment:=taLeftJustify;

if ID<>0 then Locate('ID',ID,[]) else First;

DM.DataSource2.DataSet:=DM.QVesRost;

end;

end;

procedure TPeopleForm.ShowHistoryTable(ID: Word);

var Col:TColumn;

begin

VisiblePanel(Panel6);

with DM.QHistory do

begin

if not Active then

begin

Close;

ParamByName('ID_KARTA').asInteger:=DM.QKarta.FieldByName('ID').asInteger;

Open;

end;

DBGrid1.Columns.Clear;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='PDATE';

Col.Width:=64;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='DNAME';

Col.Width:=241;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='FIO';

Col.Width:=200;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='NOTE';

Col.Width:=100;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

if ID<>0 then Locate('ID',ID,[]) else First;

DM.DataSource2.DataSet:=DM.QHistory;

end;

end;

procedure TPeopleForm.ShowNasledstTable(ID: Word);

var Col:TColumn;

begin

VisiblePanel(Panel6);

with DM.QNasledst do

begin

if not Active then

begin

Close;

ParamByName('ID_KARTA').asInteger:=DM.QKarta.FieldByName('ID').asInteger;

Open;

end;

DBGrid1.Columns.Clear;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='PDATE';

Col.Width:=64;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='RODST';

Col.Width:=200;

Col.Title.Caption

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='DNAME';

Col.Width:=334;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

if ID<>0 then Locate('ID',ID,[]) else First;

DM.DataSource2.DataSet:=DM.QNasledst;

end;

end;

procedure TPeopleForm.ShowOperatTable(ID: Word);

var Col:TColumn;

begin

VisiblePanel(Panel6);

with DM.QOperat do

begin

if not Active then

begin

Close;

ParamByName('ID_KARTA').asInteger:=DM.QKarta.FieldByName('ID').asInteger;

Open;

end;

DBGrid1.Columns.Clear;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='PDATE';

Col.Width:=64;

Col.Title.Caption:=

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='EDATE';

Col.Width:=64;

Col.Title.Caption:='Конец';

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='NAME';

Col.Width:=276;

Col.Title.Caption

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='FIO';

Col.Width:=200;

Col.Title.Caption

Col.Alignment:=taLeftJustify;

if ID<>0 then Locate('ID',ID,[]) else First;

DM.DataSource2.DataSet:=DM.QOperat;

end;

end;

procedure TPeopleForm.ShowOsob_NotesTable(ID: Word);

var Col:TColumn;

begin

VisiblePanel(Panel6);

with DM.QOsob_Notes do

begin

if not Active then

begin

Close;

ParamByName('ID_KARTA').asInteger:=DM.QKarta.FieldByName('ID').asInteger;

Open;

end;

DBGrid1.Columns.Clear;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='PDATE';

Col.Width:=64;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='NOTE';

Col.Width:=340;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

Col:=DBGrid1.Columns.Add;

Col.FieldName:='FIO';

Col.Width:=200;

Col.Title.Caption:

Col.Alignment:=taLeftJustify;

if ID<>0 then Locate('ID',ID,[]) else First;

DM.DataSource2.DataSet:=DM.QOsob_Notes;

end;

end;

1.