Инструктивные и методические материалы

Основное назначение инструктивных и методических материалов по ИО АИС – регламентация выполнения технологических операций обработки информации АИС. Для графического обозначения операция используются графические символы (табл. 2).

Таблица 2

Наименование элемента	Графика	Наименование элемента	Графика
Место выполнения операции		Передача данных по каналу связи
Документы ручного заполнения		Любая операция обработки информации на компьютере
Ввод информации документа в компьютер		Документ на магнитном диске (файл базы данных)
Заполнение документа вручную		Сохранение документа в памяти компьютера
Печатный документ (листинг)		Документ на дисплее компьютера (видеограмма)
Ввод и вывод информации из компьютера		Условия для выбора и принятия решения
Линия потока		Пуск-останов
Группировка		Сортировка

Пример технологического процесса формирования массивов загрузки НСИ БД представлен на рис.8.

Рисунок 8

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

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

Рисунок 9

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

Внутримашинное информационное обеспечение аис

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

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

• Отделение данных от программ, использующих эти данные;

• Унификацию технологии создания и ведения БД; .

• Представление интегрированных и структурированных данных всей АИС.

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

Логическая и физическая структура БД оказывает непосредственное влияние на эксплуатационные характеристики приложений:

• время доступа к данным,

• время обработки данных приложения.

СУБД используют многоуровневую архитектуру представления БД (рис. 10).

Рисунок 10

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

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

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

СУБД поддерживает различные интерфейсы:

• пользовательский — интерфейс графического вида в виде панелей инструментов, меню, диалоговых окон команд (Graphics User Interface — GUI);

• программный — языки программирования, языки запросов, конструкторы форм, отчетов, приложений и др., модели объектов (Application Program Interface — API).

СУБД влияет как на организацию данных в АИС, так и на выбор инструментальных средств для разработки приложений. Наибольшую популярность для БД, реализованных для персональных компьютеров, получили СУБД реляционного типа, предоставляемые ими реляционные языки для определения и манипулирования данными (например, языки запросов высокого уровня QBE, SQL).

Существует большое многообразие организации БД АИС, которое определяется рядом факторов.

1. Количество физически изолированных фрагментов БД:

• локальная БД, представляется в виде одного фрагмента БД;

• распределенная БД, представляется в виде нескольких фрагментов БД.

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

2. Количество приложений (пользователей), одновременно работающих с БД:

• однопользовательская БД – рассчитана на отдельное приложение (находится на отдельном компьютере, компьютерная сеть не используется);

• многоопльзовательская БД – рассчитана на комплексное использование многими приложениями (чаще всего находится на сервере компьютерной сети).

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

3. Сетевая архитектура БД:

• несетевая архитектура;

• однораноговая сеть (нет выделенного сервера);.

• сеть с выделенным сервером, в том числе:

• «файловый сервер»

• «клиент-сервер»

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

Архитектура «клиент-сервер» предполагает использование сервера как среды хранения БД, так и среды обработки данных. Рабочая станция выдает запрос на получения требуемых данных, первичная обработка запроса выполняется на сервере; объектом обмена становится выборка, релевантная запросу. Всеобщей монополизации файлов БД не происходит, уменьшается объем сетевого трафика, БД становится доступной большему числу транзакций приложений.

Архитектура «клиент-сервер» может иметь различные варианты построения, в зависимости от числа и специализации серверов:

• «толстый» клиент – большая часть обработки данных выполняется на рабочей станции;

• «тонкий» клиент – большая часть обработки данных выполняется на сервере;

• «многоуровневый сервер» - серверы специализированы по видам функций обработки (сервер файлов, сервер БД, сервер приложений и др.).

4. Состав, структура и объем хранимых данных, для которых выбирается подходящий формат:

• БД простой структуры небольшого объема;

• БД простой структуры большого объема;

• БД сложной структуры небольшого объема;

• БД сложной структуры большого объема;

• БД очень сложной структуры большого объема.

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

5. Тип СУБД (функциональные возможности, информационные технологии обработки данных, окружение сервисное):

• настольные (desktop) СУБД

• серверные (server) СУБД.

Серверные СУБД обеспечивают файл-серверную или клиент-серверную архитектуру, поддерживают распределенные БД.

Комбинация рассмотренных выше факторов позволяет выделить типовые формы организации БД:

1. Централизованно хранимая локальная однопользовательская БД на отдельном компьютере.

2. Централизованно хранимая интегрированная многопользовательская БД в компьютерной сети архитектуры «файловый сервер».

3. Централизованно хранимая интегрированная многопользовательская БД в компьютерной сети архитектуры «клиент-сервер».

4. Распределенная по рабочим станциям интегрированная многопользовательская БД в одноранговой компьютерной сети.

5. Распределенная по серверам интегрированная многопользовательская БД в компьютерной сети архитектуры «многоуровневый клиент-сервер».

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

При проектировании структуры БД выполняется моделирование данных предметной области. Для приложений определяется входная и выходная информация (документы и массивы информации, используемые при решении задач), уточняется схема документооборота. На основе информационного анализа структуры данных разрабатывается информационно-логическая модель предметной области (ИЛМ) в виде диаграммы «сущность-связь» (Entity-Relationship).

Выбор СУБД продиктован многими факторами:

• характеристика структуры данных ИЛМ (состав, структурная сложность, фрагментарность);

• объемы хранимых данных;

• наличие типовых прикладных программ функционального назначения для СУБД;

• количество приложений, одновременно использующих БД;

• характеристики сети (архитектура, количество серверов и их специализация);

• стоимость СУБД и др.

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

• организационное и техническое сопровождение БД;

• поддержка системы защиты БД от несанкционированного доступа;

• контроль за текущим состоянием БД и эффективностью реализации приложений;

• создание страховой копии и восстановление БД после аварийных ситуаций;

• развитие структуры БД.