2. Принципы обработки информации в информационно вычислительных сетях

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

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

Принятое в литературе разделение информационных комплексов на систе­мы реального времени (СРВ) и системы, к таковым не сводящиеся, достаточ­но условно, если принять за основу их определение (которое довольно точно отражает этот подход), то очевидным становится тот факт, что любой так на­зываемый «офисный» процесс полностью подчиняется закономерностям СРВ. Если синхронизировать момент ввода информации в систему с моментом старта ее обработчика и при этом до завершения обработки заблокировать возмож-1|ость следующего ввода новой информации, то эффективность системы по признаку временной разрешающей способности будет определяться лишь потребностью. Имея технический инструмент, каковым является, например, локальная сеть современных высокопроизводительных компьютеров, мож­но эффективно моделировать процесс полной обработки информации по фак­ту ее появления в системе.

Решаемую задачу можно сформулировать следующим образом: все про­весы, которые порождает символ на входе в среду ее обитания, должны быть немедленно воспроизведены (смоделированы), причем корректно и полно. |Реализовать идеологию реального времени в среде информационных задач и запросов значительно проще, чем в среде непрерывных управляемых и контролируемых процессов. Это возможно именно благодаря возможности бло­кировки ввода очередного объема информации до момента полного завершения обработки предыдущей. Таким образом, основным поставщиком информации (информационным «датчиком») становится работник данного информационного участка на своей рабочей станции. Рассмотрим схему линейного под­ключения станций в единую сеть с выделенным файловым диспетчером.

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

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

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

Количественным выразителем признака, объединяющего данные в груп­пу, является ее адрес. Будем называть адресом (активным адресом) числовое или строковое значение признака, непосредственно формирующего группу, а сам признак — активным признаком. Таковыми адресами могут выступать номер месяца либо его строковое наименование, номер года, наименование предприятия, подразделения, цеха, участка т.п.

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

Очевидно, что дополнительным признаком (дополнительным адре­сом) группы данных будет выступать строковая разность полного признака (адреса) и его активной части. Например, признак «день» является актив­ным по отношению к данным приходов-расходов некоего банка за день. Таких групп может быть множество. Адрес «день № 24» несколько сокра­тит это множество и «отфильтрует» группы, относящиеся только к 24-ым дням среди всех остальных. Достаточным же для отождествления единствен­ной (уникальной) группы данных может служить полный (суммарный) адрес вида: «год 1996 + месяц 10 (октябрь) + день № 24», то есть дата. В этой пос­ледовательности адрес «1996+10» является дополнительным адресом груп­пы с активным адресом «24-ый день».

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

Большое количество практических ошибок проектировщики допускаю! именно из-за формирования некорректных уровней. Рассмотрим для приме­ра уровень «бригада», активный адрес — «№ 29», дополнительный адрес «завод № 127 + цех № 17 + участок № 3». Данное вида «Иванов, слесарь», расположенное в одной группе с такими данными, как суммарный фонд за­работной платы бригады, суммарный фонд премии бригады, общее количество деталей, выпущенных бригадой за некий период и тому подобное, попали в нее по ошибке. Данное «Иванов, слесарь» имеет своим активным адре­сом списочный номер рабочего в списке бригады или строковое выраже­ние его фамилии, имени, отчества в этом списке. Данные вида «зарплата Иванова», «премия Иванова» имеют тот же активный адрес и располагают­ся в группе «работник» (на этом уровне) со следующим полным адресом: «завод №729 + цех №17 + участок №3 + бригада №29 + Иванов И.И.», при­чем данные с таким суммарным адресом могут быть полностью отождеств­лены. Если внести любые данные из уровня «работник» в уровень «бригада», то уровень «бригада» станет некорректным.

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

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

2. Строятся все реляционно-иерархические таблицы данных. При этом отслеживается корректность («неперенасыщенность») таблиц.

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

4. Все файлы проектируются структурно состоящими из двух частей — адресной (ключевой) с соответствующей индексацией (обработкой, ее за­ меняющей) и смысловой части. Причем необходимо, чтобы имена соот- ветствующих полей соответствовали по смыслу наименованиям признаков и данных в ПО. Очевидно, что ключевая часть каждого файла полностью соответствует суммарному адресу группы данных, которая формируется Моделируемым ИУ автоматизируемой ПО. Например, файл КVАRТАL(N_G, N М, Sum_deb, Sum_krd,...) отражает уровень (признак) «квартал», имею­щим в своей структуре полный признак в виде, соответственно, поименных ключевых полей N_G (номер года), N_К (номер квартала), а также смысловую итоговую поквартальную информацию — сумму дебета и сум­му кредита.

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

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

Формирование новых видов обработок (реализация новых ИП) обычно не влечет за собой большой переделки системы.

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

Описание методологии решения задач в сетях ЭВМ продолжим на ос­нове рассмотрения функционирования сетевых СУБД на примере системы ОRАСLЕ.

Подавляющее большинство СУБД, таких, как Сliррег, dВаsе, Fох- Ваsе или позже FохРго, Рагаdох и других, изначально строились на идее функци­онально расширенной индивидуальной «записной книжки», а с появлением доступной сетевой операционной системы NetWаге стали приобретать каче­ства, необходимые для коллективной работы. Наряду с этим разрабатыва­лись СУБД, построенные на идеях коллективной работы с данными. В этом ряду можно назвать такие СУБД, как Informiх, 1ngгеss, Огас1е, Sуbаsе, АDАВАSи др.

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

Развитие программных и аппаратных средств, усиление требований к системе (то есть процесс ее эволюции) обязательно влечет за собой необхо­димость перехода на другие аппаратные и операционные платформы, и, сле­довательно, возникнет необходимость трансформирования данных и средств, позволяющих с ними работать. На рынке современных СУБД такой систем­ный подход реализован в СУБД производства Огас1е Согрогаtiоn. Перено­симость на все заметные на рынке аппаратные платформы — не самая 'выдающаяся черта СУБД Огас1е, хотя вряд ли какая-нибудь другая СУБД, в особенности класса персональных СУБД, обладает такой особенностью. Среди СУБД того же класса существует целый ряд имеющих такое преиму­щество, например Informiх. Переносимость приложений с одной операционной платформы на другую — более замечательное свойство. Это связано со сложившейся ориентацией на аппаратные платформы Intel, которые до не­давнего времени не могли конкурировать по производительности с плат­формами Sun, НР, 1ВМ и т.д. Архитектура ядра Огас1е оказалась готовой к практически безболезненному переходу на многопроцессорные платформы. Это явилось результатом сочетания разумного консерватизма, следования су­ществующим стандартам (а фирма Огас1е в результате своего лидирующего положения часто сама является инициатором принятия стандартов) и, навер­ное, дальновидности проектировщиков.

Другой особенностью Огас1е является поддержка большого разнообразия типов сетей и протоколов. Для каждого из протоколов имеется своя програм­ма, называемая сервером, которая обеспечивает работу с СУБД в клиент/сер­верной модели. Это позволило в новой версии СУБД Огас1е 7.0 реализовать полностью распределенную модель данных. Такой подход предоставляет воз­можность получать данные из СУБД других производителей независимо от способа их хранения, типа и так далее, так как извлечение этих данных производит «своя» система. Вся сложность такого процесса скрыта от пользо­вателя, требуемые данные ему предоставляет Огас1е.

Программа (или совокупность программ, которые выполняют всю эту сложную работу) называется ядром СУБД. По числу и разнообразию таких интерфейсов СУБД Огас1е стоит на одном из первых мест. К ним необходимо добавить огромное количество интерфей­сов, разработанных другими производителями, такими, как Microsoft Асcеs, Eхсе1, Wогd, Visuа1 Ваsic, Рагаdох, семейство продуктов фирмы РоwегSoft и т.д. Благодаря этому число приложений, разработанных средствами Огас1е на се­годняшний день, велико и продолжает стремительно расти. В качестве при­мера рассмотрим проект по автоматизации банка. В данном случае ключевыми являются три элемента: коммуникации, безопасность и надежность хранения данных. Остановимся более подробно на каждом из них.

Одним из самых основных условий для реализации проекта автоматиза­ции банка является наличие надежных коммуникационных линий. Для бан­ка, имеющего сеть филиалов и отделений, также необходим обмен данными, но структура таких данных неизмеримо сложнее. Кроме внутренних для бан­ка информационных потоков, существуют еще и внешние, например обмен с другими банками, клиринговыми центрами или получение биржевой инфор­мации о курсах валют и т.п. При наличии выделенных телефонных линий Огас1е предлагает достаточно полный набор инструментальных средств для их ис­пользования. В качестве примера можно привести Огас1е Маil и Огас1е Маil Х.400 Gаtеwaу для глобальных сетей и SQL*Nеt — для сетей локальных. Последний обеспечивает совместимость практически со всеми существую­щими на сегодня типами протоколов. Понятно, что в условиях локальной сети работа ведется только в реальном масштабе времени, а в остальном все зави­сит от надежности линий связи.

Следующее основное требование для банковской системы — это надеж­ная защита данных от несанкционированного доступа. Безопасность в СУБД Огас1е базируется на системе ролей, каждая из которых включает в себя на­бор «привилегий» на работу с данными. Роли создаются администратором (или администраторами) приложения (или приложений).

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

Спецификация такой системы безопасности принята комитетами 1SО и АNS1 в качестве базового стандарта для всех будущих реализаций безопасности в языке SQL (Structured Query Language — структурированный язык запросов, принятый также в качестве стандарта на языки манипулирования данными).

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

Если ранее этот вопрос был целиком на совести разработчика приложе­ния и можно себе представить проблемы при разработке проекта коллективом, то теперь вся ответственность при правильно описанной модели лежит на ядре СУБД.

К другим существенным особенностям СУБД Огасlе можно отнести поддержку практически всех европейских и азиатских национальных языков, автоматическое воспроизведение общих данных на множестве узлов в сети (имеются в виду узлы, на которых находится ядро Огас1е), полная интегра­ция с другими СУБД, в которых реализованы стандарты на обмен данными, высокая производительность и практически полное отсутствие ограничений на объем и типы хранимых или получаемых извне данных, поддержка одно­родных и неоднородных типов сетей.