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

Таблица 2.14

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата измерения
VES	NUMDER	8	Вес
ROST	NUMDER	8	Рост

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

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

Таблица 2.15

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата
NOTE	CHAR	254	Замечания
ID_VRACH	NUMDER	4	Код ФИО врача

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

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

Таблица 2.16

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата заболевания
EDATE	DATE	8	Дата выздоровления
ID_VRACH	NUMDER	4	Код ФИО врача

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

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

Таблица 2.17

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата выписки рецепта
NAME	CHAR	254	Наименование рецепта
ID_VRACH	NUMDER	4	Код ФИО врача

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

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

Таблица 2.18

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата заболевания
EDATE	DATE	8	Дата выздоровления
NAME	CHAR	254	Наименование травмы
ID_VRACH	NUMDER	4	Код ФИО врача

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

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

Таблица 2.19

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата заболевания
EDATE	DATE	8	Дата выздоровления
ID_DIAG	NUMDER	4	Код названия заболевания
ID_VRACH	NUMDER	4	Код ФИО врача

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

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

Таблица 2.20

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата
NAME	CHAR	254	Наименование прививки
REAKCIA	CHAR	200	Результат
ID_VRACH	NUMDER	4	Код ФИО медсестры

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

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

Таблица 2.21

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата
ID_DIAG	NUMDER	4	Код названия заболевания
NOTE	CHAR	254	Жалобы
ID_VRACH	NUMDER	4	Код ФИО врача

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

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

Таблица 2.22

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата
NAME	CHAR	254	Название вредной привычки
ID_VRACH	NUMDER	4	Код ФИО врача

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

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

Таблица 2.23

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата заболевания
EDATE	DATE	8	Дата выздоровления
ID_DIAG	NUMDER	4	Код названия заболевания
NAME	CHAR	254	Название санатория
ID_VRACH	NUMDER	4	Код ФИО врача

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

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

Таблица 2.24

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата
ID_DIAG	NUMDER	4	Код названия заболевания
ID_VRACH	NUMDER	4	Код ФИО врача

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

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

Таблица 2.25

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

Название	Тип	Размер	Описание
ID	NUMDER	4	Уникальный идентификатор
ID_KARTA	NUMDER	4	Код карточки пациента
PDATE	DATE	8	Дата заболевания
RODST	CHAR	100	Заболевший родственник
ID_DIAG	NUMDER	4	Код названия заболевания

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

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

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

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

Таблица2.26

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

Параметр	Значение
Тип отношения	один-ко-многим
Допустимость нулевых связей	Нет
Отношение идентифицирующее	Нет
Внешний ключ	ID_Karta

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

Таблица 2.27

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

Параметр	Значение
Тип отношения	один-ко-многим
Допустимость нулевых связей	Нет
Отношение идентифицирующее	Нет
Внешний ключ	ID_Vrach

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

Таблица 2.28

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

Параметр	Значение
Тип отношения	один-ко-многим
Допустимость нулевых связей	Нет
Отношение идентифицирующее	Нет
Внешний ключ	ID_Diag

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

Таблица 2.29

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

Параметр	Значение
Тип отношения	один-ко-многим
Допустимость нулевых связей	Нет
Отношение идентифицирующее	Нет
Внешний ключ	ID

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

Таблица 2.30

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

Параметр	Значение
Тип отношения	один-ко-многим
Допустимость нулевых связей	Нет
Отношение идентифицирующее	Нет
Внешний ключ	ID

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. Заключается в проверке работы системы защиты.

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

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