Информационное и лингвистическое обеспечение автоматизированных систем

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего образования «УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» Г.П. Токмаков ИНФОРМАЦИОННОЕ И ЛИНГВИСТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ ЛОКАЛЬНЫХ И РАСПРЕДЕЛЕННЫХ АВТОМАТИЗИРОВАННЫХ СИСТЕМ Учебное пособие Ульяновск УлГТУ 2016 ОГЛАВЛЕНИЕ ВВЕДЕНИЕ ......................................................................................... 8 ГЛАВА 1. ОСНОВНЫЕ ПОНЯТИЯ ИНФОРМАЦИОННОГО И ЛИНГВИСТИЧЕСКОГО ОБЕСПЕЧЕНИЯ .............................................................................. 12 1.1 ИНФОРМАЦИЯ КАК ОСНОВА УПРАВЛЕНИЯ..................... 12 1.1.1 Информация и изготовление продукции ................................. 13 1.1.2 Понятие и виды информационной системы ............................ 16 1.1.3 Автоматизированные информационные системы для управления сложными системами ..................................................... 19 1.2 ИНФОРМАЦИОННОЕ И ЛИНГВИСТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ АС .......................................................................... 21 1.2.1 Информационное обеспечение АС........................................... 22 1.2.2 Лингвистическое обеспечение АС ........................................... 25 1.2.3 Информационно-лингвистическое обеспечение АС ............... 27 1.3 ФОРМАЛИЗАЦИЯ СТРУКТУРЫ ИНФОРМАЦИИ УПРАВЛЕНИЯ................................................................................... 28 1.3.1 Реквизиты .................................................................................. 29 1.3.2 Показатели ................................................................................. 31 1.3.3 Документы ................................................................................. 35 1.3.4 Информационно-логическая модель документа...................... 44 КОНТРОЛЬНЫЕ ВОПРОСЫ ............................................................ 48 ЧАСТЬ I. ИНФОРМАЦИОННО-ЛИНГВИСТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ АВТОНОМНЫХ АС ........................................ 50 ГЛАВА 2. ВНЕМАШИННОЕ ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ АС........................................................................ 52 2.1 УНИФИЦИРОВАННЫЕ СИСТЕМЫ ДОКУМЕНТАЦИИ ...... 53 2.1.1 Основные цели унификации системы документов ................. 54 2.1.2 Унифицированная система документации России .................. 55 2.1.3 Унифицированная система документации АС ........................ 57 2.1.4 Недостатки существующих систем документации ................. 61 2 2.2 СИСТЕМА КЛАССИФИКАЦИИ И КОДИРОВАНИЯ ИНФОРМАЦИИ АС .......................................................................... 62 2.2.1 Основные понятия СККИ ......................................................... 62 2.2.2 Классификаторы и их виды ...................................................... 63 2.2.3 Классификация информации .................................................... 64 2.2.4 Кодирование информации ........................................................ 70 2.2.5 Выбор методов классификации и кодирования ....................... 74 2.3 НОРМАТИВНО-СПРАВОЧНАЯ ИНФОРМАЦИЯ .................. 74 2.4 ПРИМЕР РАЗРАБОТКИ ВНЕМАШИННОГО ИО ................... 76 2.4.1 Методология разработки ИО АС ............................................. 77 2.4.2 Описание предметной области «Учебный процесс» .............. 78 2.4.3 Определение УСД внемашинного ИО ..................................... 79 2.4.4 Разработка словарей и классификаторов ................................. 90 2.4.5 Определение НСИ ..................................................................... 95 КОНТРОЛЬНЫЕ ВОПРОСЫ ............................................................ 96 ГЛАВА 3. ВНУТРИМАШИННОЕ ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ АС ............................. 97 3.1 ОСНОВНЫЕ ПОНЯТИЯ ВНУТРИМАШИННОГО ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ ...................................... 97 3.1.1 Назначение и требования к внутримашинному ИО ................ 98 3.1.2 Способы организации внутримашинного ИО ......................... 98 3.1.3 Локальные и распределенные БД ............................................. 99 3.2 ОСНОВЫ ОРГАНИЗАЦИИ ВНУТРИМАШИННОГО ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ .................................... 100 3.2.1 Информационная база, организованная на основе файлов ... 100 3.2.2 Информационная база, организованная на основе БД .......... 104 3.3 ОПИСАНИЕ СУБД ................................................................... 109 3.3.1 Трехуровневая архитектура ANSI-SPARC ............................ 109 3.3.2 Схемы БД и отображения ....................................................... 113 3.3.3 Системный каталог ................................................................. 115 3.3.4 Независимость данных ........................................................... 116 3 3.4 ИСПОЛЬЗОВАНИЕ СУБД В АС И ЕЕ ВЛИЯНИЕ НА АРХИТЕКТУРУ АС......................................................................... 118 3.4.1 Выделение СУБД в отдельный компонент АС...................... 119 3.4.2 Архитектура «файл-сервер» ................................................... 121 3.4.3 Архитектура «клиент-сервер» ................................................ 123 3.4.4 Трехзвенная архитектура «клиент-сервер»............................ 124 3.5 ПРИМЕР РАЗРАБОТКИ ВНУТРИМАШИННОГО ИО ......... 125 3.5.1 Особенности представления компонентов внемашинного ИО во внутримашинной ИБ АС ............................. 126 3.5.2 Определение функциональных зависимостей между объектами документов ..................................................................... 129 3.5.3 Концептуальная схема БД ПрО .............................................. 137 КОНТРОЛЬНЫЕ ВОПРОСЫ .......................................................... 141 ГЛАВА 4. ЛИНГВИСТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ АС ....... 142 4.1 ВЗАИМОДЕЙСТВИЕ ЧЕЛОВЕКА И МАШИНЫ .................. 142 4.1.1 Виды взаимодействия человека и машины ............................ 142 4.1.2 Документ как единица обмена информацией в АС ............... 145 4.1.3 ЛО АС как средство формирования формализованных сообщений......................................................................................... 148 4.2 ОСНОВНЫЕ ПОНЯТИЯ ЛО АС.............................................. 154 4.2.1 Определение, назначение, цели ЛО АС ................................. 154 4.2.2 Требования к ЛО ..................................................................... 155 4.2.3 Состав ЛО АС.......................................................................... 156 4.3 СРЕДСТВА ФОРМАЛИЗАЦИИ ЕСТЕСТВЕННОГО ЯЗЫКА.............................................................................................. 157 4.3.1 Система словарей терминов ................................................... 157 4.3.2 Правила формализации информации ..................................... 159 4.3.3 Методы и способы выделения, представления содержания информационных сообщений .......................................................... 160 4.4 ИНФОРМАЦИОННЫЕ ЯЗЫКИ .............................................. 161 4.4.1 Язык описания данных – DDL................................................ 162 4.4.2 Язык манипулирования данными – DML .............................. 163 4 4.4.3 Языки проектирования и программирования ........................ 163 4.4.4 Языки управления функционированием АС ......................... 164 4.5 ПРИМЕР РАЗРАБОТКИ ЛИНГВИСТИЧЕСКОГО ОБЕСПЕЧЕНИЯ ДЛЯ АВТОНОМНОЙ АС .................................. 169 4.5.1 Система словарей терминов и понятий.................................. 169 4.5.2 Правила формализации естественного языка в АС «Учебный процесс»................................................................. 174 4.5.3 Информационный язык АС «Учебный процесс» .................. 175 4.5.4 Реализация методов и способов выделения информационных сообщений на экранных формах АС «Учебный процесс» ................................................................... 178 4.5.5 Возможности ЛО АС (пользовательского интерфейса) ........ 181 КОНТРОЛЬНЫЕ ВОПРОСЫ .......................................................... 183 ЧАСТЬ II. ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ РАСПРЕДЕЛЕННЫХ АС ............................................................. 185 ГЛАВА 5. ОСНОВНЫЕ ПОНЯТИЯ РАСПРЕДЕЛЕННЫХ СУБД……. ....................................................................................... 188 5.1 ОСНОВНЫЕ ПОНЯТИЯ РАСПРЕДЕЛЕННЫХ БД ............... 188 5.1.1 Требования к АС в условиях работы с распределенными данными .......................................................... 188 5.1.2 Распределенная база данных .................................................. 189 5.1.3 Функции и архитектура распределенной СУБД.................... 191 5.1.4 Глобальный системный каталог ............................................. 194 5.2 ОСНОВНЫЕ ПРИНЦИПЫ РЕАЛИЗАЦИИ РАСПРЕДЕЛЕННЫХ БД ................................................................ 196 5.2.1 Прозрачность размещения ...................................................... 197 5.2.2 Прозрачность именования ...................................................... 198 5.2.3 Прозрачность использования СУБД ...................................... 200 5.3 РАСПРЕДЕЛЕННЫЕ СИСТЕМЫ НА ОСНОВЕ РЕПЛИКАЦИИ ДАННЫХ .............................................................. 200 5.3.1 Синхронная и асинхронная репликация ................................ 201 5.3.2 Функциональные средства репликации ................................. 202 5 5.3.3 Схема владения данными ....................................................... 202 5.4 ПРЕИМУЩЕСТВА И НЕДОСТАТКИ РАСПРЕДЕЛЕННЫХ СУБД ........................................................... 204 КОНТРОЛЬНЫЕ ВОПРОСЫ .......................................................... 207 ГЛАВА 6. WEB-ТЕХНОЛОГИИ И ТЕХНОЛОГИЯ БД ......... 209 6.1 ОСНОВНЫЕ ПОНЯТИЯ WEB-СРЕДЫ .................................. 210 6.1.1 Инфраструктура Web-технологий и протоколы .................... 211 6.1.2 Язык HTML и протокол HTTP ............................................... 211 6.1.3 Механизм публикации данных в Web-среде ......................... 213 6.2 АРХИТЕКТУРЫ, ОБЕСПЕЧИВАЮЩИЕ ИНТЕГРАЦИЮ СУБД В WEB-СРЕДУ.......................................... 215 6.3 МЕХАНИЗМЫ ИНТЕГРАЦИИ СУБД В WEB-СРЕДУ ....... 219 6.3.1 Общий шлюзовой интерфейс ................................................. 221 6.3.2 Сервлеты Java .......................................................................... 224 6.3.3 Серверные страницы Java ....................................................... 227 6.4 ПРЕИМУЩЕСТВА И НЕДОСТАТКИ ИНТЕГРАЦИИ СУБД В СРЕДУ WEB ...................................................................... 230 6.4.1 Преимущества ......................................................................... 230 6.4.2 Недостатки............................................................................... 232 КОНТРОЛЬНЫЕ ВОПРОСЫ .......................................................... 234 ГЛАВА 7. ИЛО РАСПРЕДЕЛЕННОЙ АС НА ОСНОВЕ XML-ТЕХНОЛОГИЙ .......................................... 235 7.1 XML-ПЛАТФОРМА КАК ОСНОВА ДЛЯ ФОРМАЛИЗАЦИИ ИЛО РАСПРЕДЕЛЕННЫХ СИСТЕМ .......... 236 7.1.1 Традиционная технология формирования ИЛО АС и проблема формального описания документов ............................. 236 7.1.2 Использование языков разметки XML-платформы для формального представления данных документов ........................... 240 7.1.3 Языки разметки и реляционные базы данных как взаимодополняющие технологии представления данных ............. 245 7.1.4 Состав ИЛО распределенных АС ........................................... 247 6 7.1.5 Операции, выполняемые инфраструктурными компонентами распределенной системы ........................................ 255 7.2 ТЕХНОЛОГИЧЕСКАЯ ЛИНИЯ РАЗРАБОТКИ ИЛО АС ... 267 7.2.2 Средства для разработки схемы базы данных ....................... 270 7.2.3 XML редакторы для разработки XML-схемы ....................... 270 7.2.4 Редакторы XSLT-файлов для разработки таблиц стилей...... 271 7.2.5 xForms-редакторы ................................................................... 272 7.2.6 SOAP-процессор...................................................................... 273 7.3 ПРИМЕР РАЗРАБОТКИ ИЛО НА ОСНОВЕ ИНТЕГРАЦИИ XML-ТЕХНОЛОГИЙ И ТЕХНОЛОГИИ БД....... 273 7.3.1 Разработка УСД средствами XSD .......................................... 275 7.3.2 Генерирование шаблонов XML-документов ......................... 285 7.3.3 Создание системы словарей АС средствами XSD................. 288 7.3.4 Создание концептуальной схемы ПрО .................................. 292 7.3.5 Генерирование постоянного хранилища данных .................. 294 7.3.6 Создание пользовательского интерфейса .............................. 296 7.3.7 Отображение «XML-схема  Схема БД» ............................. 303 КОНТРОЛЬНЫЕ ВОПРОСЫ .......................................................... 310 СПИСОК ИСТОЧНИКОВ ............................................................ 311 ГЛОССАРИЙ .................................................................................. 315 ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ..................................................... 328 7 Информационное обеспечение (ИО) любой социальной системы представляет собой систему сбора и переработки информации, необходимой для принятия обоснованных управленческих решений. Функционирование этой системы складывается из решения ряда частных задач, таких как сбор первичной информации, ее хранение, распределение между структурными подразделениями организации и их работниками, обработка и предоставление органу управления в обработанном, т.е. удобном для принятия решений, виде. По мере развития общества объем информации, циркулирующей в рамках отдельных социальных систем, а также используемой при их взаимодействии, постоянно увеличивается и ее качественная и своевременная обработка без использования автоматизированных средств становится практически невозможной. Основная цель автоматизации обработки управленческой информации – получение посредством переработки первичных данных информации нового качества, обеспечивающей выработку оптимальных управленческих решений. Это достигается за счет: – использования современных технических средств для внедрения и функционирования качественно новых форм информационной поддержки деятельности аппарата управления; – интеграции информации, поступающей из различных источников и имеющей различные форматы представления; – обеспечения ее актуальности и непротиворечивости. 8 Достижение этой цели было осуществлено в несколько этапов. 1. Первые попытки автоматизации управленческой деятельности были предприняты еще в 60-х годах прошлого столетия, на основе созданных к тому времени ЭВМ. Основные усилия при этом были направлены на обеспечение непрерывной (в реальном масштабе времени) передачи от управляемых объектов и обработки на ЭВМ самой разнообразной информации с целью принятия своевременных и обоснованных решений. Для этого этапа была характерна слабая оснащённость низовых уровней системы управления персональной вычислительной техникой, низкая надежность вычислительной техники и отсутствие автоматизированной связи между иерархическими уровнями управления. 2. Исключительно важную роль для автоматизации управленческой деятельности сыграли работы по созданию систем комплексной обработки информации на ЭВМ, выполненные в 70-е годы. Именно в эти годы были заложены теоретические и методологические основы для создания человеко-машинных АС, где при централизованной обработке в условиях вычислительных центров роль человека-оператора оказывалась не менее существенной, чем технических устройств. На этом этапе развития автоматизированных информационных систем разрозненные, расположенные на различных уровнях управления, технические средства были объединены в локальную вычислительную сеть, что открыло возможности по: – реализации автоматизированной связи между техническими средствами различных уровней управления, обеспечивающей их совместную работу; – организации потоков вычислительных ресурсов как по горизонтали, так и по вертикали управления с целью исключения «узких» мест в процессах информационного обслуживания пользователей и принятия управленческих решений; – объединению всех информационных ресурсов, используемых для выработки управленческих решений, в единой базе данных. 9 3. Резкое усложнение производственных процессов в последние десятилетия привело к тому, что отдельные предприятия стали объединяться в более крупные образования, такие как концерны и корпорации. Этот процесс укрупнения социальных систем сопровождается созданием распределенных АС путем интеграции вычислительных и информационных ресурсов автономных АС объединяемых предприятий через глобальную компьютерную сеть. Рассматривая информацию как центральное звено и основной ресурс АС, используемый для принятия управленческих решений, необходимо иметь в виду достаточно широкий комплекс ее аспектов. Здесь имеется в виду, что при функционировании АС используется не только информация об объекте управления (т.е. об экономической деятельности социальной системы), но и сведения о ее внешней среде функционирования, об организационной структуре, а также о сотрудниках и клиентах. Перечисленные аспекты информации, отражающие течение процессов производства или иного вида деятельности, используются для эффективного управления процессами и технологическим оборудованием, и определяются как ИО АС. Способы организации информации АС в ходе ее эволюции также претерпели определенные изменения и на сегодняшний день, т.е. на этапе создания распределенных АС, основной задачей является интеграция информационных ресурсов объединяемых автономных АС в едином информационном пространстве. Перспективным подходом решения этой задачи является использование Web-среды, обеспечивающей объединение в единую систему различных локальных сетей и баз данных. Основным достоинством Web-среды является ее развитая сетевая инфраструктура, открывающая новые возможности по интеграции автономных АС в единой распределенной системе. Но за несколько лет бурного развития Web-технологий выявились серьезные недостатки, вызванные особенностями языка HTML, являющегося системообразующим компонентом Web-среды. Основными недостатками этого языка являются отсутствие: 10 – поддержки метаданных, что ограничивает поисковые операции только техникой контекстного поиска, а поиск документов с учетом свойств их структурных компонентов при этом невозможен; – отсутствие средств расширения функциональности HTML-документов ограничивает возможности структурирования документов, адекватного потребностям пользователей. Выявленные недостатки послужили стимулом дальнейшего развития среды Web, путем добавления в нее технологий, основанных на современных методах моделирования данных, прошедших испытание временем в технологиях баз данных и поисковых системах. Эти методы используют модели данных, основанные на явном представлении и поддержке метаданных, обеспечивающих возможности структурирования документов, адекватных используемым в языках программирования и СУБД. Новые технологии Web-среды базируются на открытом для расширения комплексе стандартов, составляющих XML-платформу и определяющих коммуникативные возможности для доступа к распределенным информационным ресурсам Web-среды. Таким образом, на сегодняшний день, наряду с традиционными методами организации ИО АС, выработанными на втором этапе развития средств автоматизации информационных систем, созданы условия для организации ИО распределенных АС В данном учебном пособии изложены теоретические и методологические аспекты разработки ИО: – автономных АС, опирающихся на традиционные технологии моделирования предметной области (ПрО) и их внутримашинного представления в реляционных базах данных; – распределенных АС, использующих наряду с реляционными моделями коммуникативные возможности языков разметки, предоставляемых стандартами XML-платформы. Пособие предназначено для студентов специальностей 09.04.01, 09.04.02, 09.04.03, 09.04.04, а также может использоваться студентами других специальностей в области информационных технологий. 11 Обеспечение АС информацией, т.е. формирование ее данных, используемых для информационной поддержки процессов управления, является важной составной частью работ по созданию АС. Вводимая при этом информация является важнейшим элементом системы, без которой невозможно функционирование математического, программного и лингвистического видов обеспечений АС. Поэтому информация, выявленная в ходе анализа документооборота и хранимая в системе, – это основа основ современных АС. Именно от информации, ее качества, зависит быстрота и точность оценки ситуации, подготовки и принятия управленческих решений, направленных на получение максимального эффекта (при минимальных издержках) от деятельности системы управления. 1.1 ИНФОРМАЦИЯ КАК ОСНОВА УПРАВЛЕНИЯ С позиции кибернетики как науки об общих принципах управления «процесс управления всегда и в любом случае сводится к передаче и обработке информации», а процесс управления системой, в том числе предприятием или организацией, представляется как информационный процесс. Этот процесс должен обеспечивать выполнение системой решение поставленных перед ней задач при соблюдении условий ее существования [1]. 12 1.1.1 ИНФОРМАЦИЯ И ИЗГОТОВЛЕНИЕ ПРОДУКЦИИ Рассмотрим процесс производства продукции на предприятии и определим, каким образом в ходе управления производством используется информация. С функциональной точки зрения предприятие – это система, представляющая собой устойчивую социальную структуру, которая берет ресурсы из окружающей среды и обрабатывает их, чтобы произвести продукцию для реализации в окружающей среде (см. Рис. 1.1). Любое предприятие, изготавливающее продукцию, содержит в своем составе орган управления (руководители и отделы) и исполнительный орган (подразделения, цеха). Назначением предприятия является изготовление готовой продукции, под которой имеют в виду объекты любой природы: – материальные (приборы, оборудование); – энергию (электрическую, тепловую); – информационные (программные продукты, документы). Для изготовления продукции предприятие должно располагать ресурсами: – оборудованием для изготовления продукции (станки, генераторы, вычислительная техника); – для работы оборудования, отопления помещений требуется энергия; – на предприятии имеются необходимые для изготовления продукции сырье, материалы, комплектующие, информация, поставляемые из внешней среды. Процесс изготовления изделия описывается следующим образом. 1. Для преобразования материи с целью изготовления продукции, в первую очередь, нужна команда на ее изготовление, выдаваемой ЛПР, т.е. входная информация . 2. По этой информации определяется концептуальная модель продукции, содержащая характеристики, которым должно отвечать готовое изделие. Концептуальная модель определяется в техническом задании, содержащем требования к изготавливаемому изделию в виде информации , по которой определяется характер воздействия на элементы материального потока. 13 Iвх Концептуальная модель изделия – (ТЗ-что делать?) Iвых Iрасс=Iпрг : ТЗ не выполнено Информация о процессе изготовления (техпроцесс - как делать?) U1 Орган управления ЛПР Ui ТО Un ТО Информация обратной связи Информационные потоки Iос ТО Iос1 Iосi Iосn ИС ИС ИС Исполнительный орган (цех) Объект Сырье, материалы, комплектующие ГП ГП ... ТP - Техническое задание ЛПР – лицо, принимающее решение ТО - Технологическое оборудование (станки, оргтехника,...) ИС - Измерительные системы ГП – Готовая продукция Рис. 1.1 – Схема потоков материи, энергии и информации при управлении производственным процессом 14 3. Далее необходимо трансформировать эту информацию в алгоритмическую модель (технологический процесс), представляющую собой упорядоченную последовательность управляющих команд для технологического оборудования, определяющих характер воздействия на материалы и комплектующие. Именно в этой последовательности содержится информация о том, как изготовить изделие, соответствующее требованиям . Трансформация концептуальной модели изделия в алгоритмическую модель осуществляется на этапах проектно-конструкторских работ и технологической подготовки производства. 4. На ответственных этапах технологической операции определяется состояние изготавливаемой продукции, а для этого надо выполнить обратное преобразование, т.е. состояние материалов и комплектующих на этих этапах должно быть преобразовано в информацию. Для этого служат измерительные системы, определяющие количественные значения характеристик создаваемого изделия, или используются методики для проверки заданных характеристик. Значения, полученные после выполнения измерений или проверок по методикам, создают информацию обратной связи , передаваемый по каналам связи (КС) в орган управления. Здесь – информация о состоянии -й составной части изделия. 5. Цикл технологического процесса изготовления изделия и его элементов заканчивается операцией сравнения концептуальной модели изделия с информацией , описывающей полученный образец. При отклонениях , равных или превышающих некоторые пороговые значения , т.е. , полученный экземпляр отправляется на доработку (т.е. процесс изготовления продукции продолжается путем выполнения п. п. 3 – 5). Если информация соответствует требованиям модели изделия , т. е. , процесс изготовления продукции завершается выдачей лицу, принимающему решения (ЛПР) выходной информации о готовности изделия. 15 Таким образом, будучи информационным процессом, управление поддерживает структуру, режим деятельности, выполнение заданной программы работы системы за счёт полной, своевременной и достоверной информации. Причём информация в процессе управления выступает одним из основных ресурсов. Она собирается, передаётся, накапливается, подвергается анализу и обработке и используется для принятия управленческих решений, регулирующих производственно-хозяйственную деятельность предприятий и организаций. Для этого требуются необходимые условия – наличие чётко организованной информационной системы, которая обеспечивает информационное обслуживание ЛПР, реализует обмен информацией между ее элементами, с исполнительными органами и внешней средой [2]. 1.1.2 ПОНЯТИЕ И ВИДЫ ИНФОРМАЦИОННОЙ СИСТЕМЫ Орган управления является системой обслуживания работников управленческих служб (руководителей или ЛПР), и выполняет технологические функции по накоплению, хранению и обработке информации для принятия решений, т.е. по сути, является информационной системой (ИнфС). С технологической точки зрения такая информационная система представляет собой совокупность специалистов, участвующих в процедурах обработки информации, методов и средств подготовки управленческих решений, внутренних и внешних потоков информации прямой и обратной связи (см. Рис. 1.1). На современном этапе развития ИнфС потоки информации представляют собой движение данных на: – бумажных носителях с использованием традиционных КС; – машинных носителях по информационным каналам вычислительной сети. В связи с этим различают информационные системы, ориентированные на ручную или машинную технологию обработки информации при решении задач управления. 16 Ручная технология обработки информации, использующая бумажные носители информации, ориентирована на использование простых технических средств (счетов, калькуляторов) и полностью регламентируется действующими инструкциями по решению управленческих задач в рамках сложившихся методологии и законодательства. При управлении производством, использующем ручную технологию обработки информации, каждое функциональное подразделение (плановый отдел, бухгалтерия и т.д.) имеет свои информационные связи с производственными подразделениями (цехами, складами и т.д.), в которых информационные потоки во многом дублируются (см. Рис. 1.2 (а)). ОУ1 ... ОУi ... ОУ1 ОУn ... ОУi ... АС ПП1 ... ППj ... а) ОУ - Органы управления ПП1 ППm ... ППj ОУn БД ... ППm б) ПП - Производственные подразделения Рис. 1.2 – Структура ИнфС при бумажном документообороте (а) и при автоматизированной обработке данных (б) Но еще большую проблему создает то обстоятельство, что для информации на бумажных носителях, ориентированной на восприятие человеком, не предъявляется строгих ограничений к форме представления. Поэтому одни и те же данные на разных документах, могут быть представлены и обработаны по-разному. Это приводит к большим затратам на переформатирование и обработку данных при выполнении задач управления на основе бумажного документооборота. Для решения этих проблем были предприняты меры по упорядочению потоков информации и установлению строго регламентированного, необходимого и достаточного количества видов доку17 ментов, используемых в качестве информационного обеспечения функций управления. Но в условиях постоянного усложнения производственных процессов потоки данных неуклонно наращивались и даже перечисленные меры по усовершенствованию информационного обеспечения функций управления не позволяли вовремя и качественно перерабатывать имеющуюся информацию. Поэтому на предприятиях и в организациях появилась острая потребность в механизации, а затем и автоматизации обработки информации. Машинная технология обработки информации рассчитана на применение широкого спектра технических средств и, прежде всего, компьютерной техники и средств связи для создания вычислительных систем и сетей различных конфигураций. При этом обеспечивается не только накопление, хранение, автоматизированная переработка информации, но и максимальное приближение терминальных устройств к рабочим местам специалистов в области информационных технологий и ЛПР. При организации системы автоматизированной обработки информации потоки данных подвергаются существенным изменениям (см. Рис. 1.2 (б)). Здесь данные направляются от органов управления и производственных подразделений в центр обработки, связанной с памятью машины, в которой сохраняется вся поступающая информация. АС по этой информации осуществляет необходимые расчеты для снабжения функциональных служб и производственных подразделений соответствующей информацией. В этом случае для хранения информации используются базы данных (БД), интегрирующие в общем хранилище все виды данных предприятия или организации. При этом сведения о потоках материалов и информации включаются в единую сбалансированную систему, и в единой базе собираются данные для разработки и конструирования, планирования производства, управления оборудованием и процессами и т.д. 18 1.1.3 АВТОМАТИЗИРОВАННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ ДЛЯ УПРАВЛЕНИЯ СЛОЖНЫМИ СИСТЕМАМИ Использование технических средств для повышения эффективности управленческого труда имело место и до начала компьютерной эры. Но при этом речь шла об использовании простых технических средств, облегчающих выполнение только отдельных операций. Как уже было отмечено, начало комплексной автоматизации управленческого труда было положено в середине 60-х годов прошлого века с появлением первых ЭВМ. С тех пор и до настоящего времени главным фактором повышения эффективности деятельности работников в управленческой сфере является внедрение компьютерных технологий, обеспечивающих автоматизацию таких функций и процедур, как: – подготовка и регистрация информации; – передача информации к месту обработки; – собственно обработка информации; – хранение и поиск информации. К настоящему времени применение автоматизированных ИнфС, т.е. использование АС при управлении, стало повсеместным и термины АС и ИнфС используются практически как синонимы. Этой традиции будем придерживаться и мы, поэтому в дальнейшем речь будем вести об АС, имея в виду автоматизированные ИнфС [3]. Изучение и создание сложной человеко-машинной системы, каковыми являются ИнфС, требуют четкого определения ее внутренней структуры. В процессе структуризации система разделяется на части, имеющие меньшую сложность, т.е. на подсистемы и их элементы (задачи). В первую очередь АС делится на две подсистемы: функциональную и обеспечивающую. Функциональная составляющая представляется так называемыми функциональными системами (ФС) и подсистемами (ФП), состав которых в различных АС может существенно различаться. Но предприятия работают в рамках общего правового пространства, что позволяет выделить некоторые общепринятые подсистемы функци- 19 ональной составляющей АС. В качестве таких подсистем можно рассматривать процедуры учета и отчетности, экономического анализа, текущего планирования, прогнозирования и т.д. Но спектр деятельности предприятий весьма широк, и вывести некий общий алгоритм деятельности даже для таких подсистем не представляется возможным. Поэтому данная составляющая, несмотря на наличие некоторых общих функций управления, определяется в ходе разработки и является специфической для каждой конкретной создаваемой АС. С другой стороны, состав, структура обеспечивающих подсистем, а также термины, определяющие понятия, связанные с элементами обеспечения системы, имеют более устойчивый характер и в меньшей степени зависят от особенностей конкретных АС. В обеспечивающей части ИнфС принято выделять подсистемы технического, математического, программного, информационного и лингвистического обеспечения [4]. Техническое обеспечение системы – это комплекс технических средств (компьютер, оборудование локальной вычислительной сети, оргтехника, периферийная техника, средства связи). Математическое обеспечение системы представляет собой совокупность средств и методов, позволяющих строить математические модели задач управления предприятиями. Программное обеспечение системы – это совокупность программ (общесистемных и прикладных) для реализации задач, подсистем информационной системы на базе компьютерной техники. Программное обеспечение должно предоставить пользователям наибольшие удобства в работе и свести к минимуму затраты на программирование задачи обработки информации. Оставшиеся два вида обеспечения АС являются предметом рассмотрения данного учебного пособия и будут описаны более подробно ниже. Подчеркнув комплексный характер обеспечивающих средств, необходимо иметь в виду, что каждое из них имеет специфический характер. Поэтому изучаются они по-отдельности и создаются разными категориями разработчиков. 20 1.2 ИНФОРМАЦИОННОЕ И ЛИНГВИСТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ АС В отличие от разработки отдельных программных модулей, использующих локальные данные, создание АС требует организации информации в виде централизованных БД, а также определения средств доступа к этой информации для многочисленных пользователей. Так как решение этих вопросов обязательно при создании любой АС, в их составе выделяются подсистемы информационного и лингвистического обеспечения, относительно назначения, состава и структуры которых выработаны соответствующие требования. Информационное обеспечение (ИО) представляет собой важнейший элемент современных АС и предназначено для отражения информации, характеризующей состояние управляемого объекта, и являющейся основой для принятия управленческих решений. Выработка и принятие управленческих решений представляет собой информационный процесс и реализуется в ходе обмена информацией по установившимся каналам между работниками, занятыми управлением. Для этого работники сферы управления используют естественный язык, позволяющий адекватно воспринимать смысл передаваемых и получаемых сообщений. При автоматизации процессов управления обмен данными в системе управления осуществляется через АС, что приводит к необходимости формализации естественного языка, направленной: – с одной стороны, на сохранение естественного языка как средства представления информации для работников сферы управления или пользователей АС; – с другой стороны, на обеспечение автоматизированной обработки информации, введенной пользователями в терминах естественного языка, путем ее преобразования в машинную форму. Усилия по формализации естественного языка привели к созданию информационных языков общения, создающих у пользователей ощущение работы на естественном языке при обмене данными с машиной, которые в совокупности со средствами формализации естественного языка составляют основу лингвистического обеспечения (ЛО) АС. 21 ЛО АС предназначено для преодоления «языковых проблем» при взаимодействии пользователей с аппаратными и программными средствами АС и объединяет в себе совокупность языковых средств доступа к элементам ИО, обеспечивающих работу пользователей АС в диалоговом режиме с использованием текстовой и графической форм взаимодействия. 1.2.1 ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ АС Весь комплекс данных, отражающий течение процессов производства или иного вида деятельности, необходимый для эффективного управления процессами и технологическим оборудованием, обмена информацией между органом управления и исполнительным органом для регулирования его деятельности, определяется как информационное обеспечение АС [5, 6]. Основная цель ИО заключается в повышении качества решения задач управления путем предоставления достоверных и актуальных данных, необходимых для принятия управленческих решений. Основное назначение ИО заключается в такой организации и представлении информации, которая отвечает требованиям пользователей, а также условиям для реализации автоматизированных технологий обработки и приема-передачи данных. Требования к ИО обусловливаются их назначением и определяются как совокупность следующих возможностей: – представления полной, достоверной и своевременной информации для реализации всех расчетов и процессов принятия управленческих решений в ФС и ФП с минимумом затрат на ее сбор, хранение, поиск, обработку и передачу; – обеспечения взаимной увязки задач ФС и ФП на основе однозначного и формализованного описания их входов и выходов на уровне показателей документов, хранимых в машинной памяти; – эффективной организации хранения и поиска данных, позволяющей АС формировать данные в рабочие массивы под решаемые задачи и функционировать в режиме информационно-справочного обслуживания. 22 Состав ИО АС. Для разработки ИО АС в результате изучения документооборота системы управления или моделируемой предметной области определяются: – состав входных и выходных документов по каждой задаче; – документы нормативного и справочного характера; – по совокупности документов определяется состав показателей, необходимых для решения задач функций управления, и их информационные связи. Далее по выявленным показателям и их информационным связям определяются: – словари и классификаторы и коды входящих в них объектов; – сущности для учета данных о важных объектах моделируемой предметной области; – БД для машинного хранения информации о сущностях предметной области, нормативов и справочных данных, словарях и классификаторах. Перечисленный состав ИО можно разбить на две части: – одна часть ИО связана с организацией и рационализацией различных информационных массивов, используемых работниками сферы управления, а впоследствии для автоматизированного решения задач управления и передачи данных; – другая, учитывающая особенности взаимодействия пользователя с комплексом средств автоматизации (КСА), используется при выполнении технологических операций по обработке информации. Поэтому в составе ИО выделяется внемашинное и внутримашинное ИО. Внемашинное ИО формируется на основе документации с выявленной системой экономических показателей и включает в свой состав (см. Рис. 1.3): – унифицированную систему документации (УСД), содержащую сведения о состоянии технологического оборудования, управляемого объекта и среды в виде системы показателей; – систему классификации и кодирования информации (СККИ); – нормативно-справочная информация (НСИ). 23 Внутримашинное информационное обеспечение включает в себя информационную базу на машинных носителях и систему программ ее организации, накопления, ввода и доступа к данным (см. Рис. 1.3). Источником формирования внутримашинного информационного обеспечения служит внемашинная информационная база. Информационно-лингвистическое обеспечение АС Внемашинное информационное обеспечение Унифицированная система документации Система кодирования и классификации Нормативно-справочная информация Внутримашинное информационное обеспечение Базы данных Программные средства ведения баз данных Лингвистическое обеспечение Словари и классификаторы Средства формализации языка Информационные языки Рис. 1.3 – Структура информационно-лингвистического обеспечения АС Основные требования к ИО АС формулируются на основе данных предпроектного обследования организации. В них обязательно должна быть отмечена необходимость обеспечения адекватности машинного представления данных о предметной области и однозначной интерпретации модели. К ИО АС предъявляются также следующие общие требования: – для кодирования информации должны использоваться принятые у заказчика классификаторы; 24 – должна быть обеспечена информационно-логическая совместимость с создаваемым ИО систем, взаимодействующих с разрабатываемой АС; – формы документов должны отвечать требованиям корпоративных стандартов заказчика (или унифицированной системы документации); – структура документов и экранных форм должна соответствовать характеристикам терминалов на рабочих местах конечных пользователей; – содержание информационных сообщений, а также используемые аббревиатуры должны быть общеприняты в этой предметной области и согласованы с заказчиком; – в АС должны быть предусмотрены средства контроля входной и результатной информации, обновления данных в информационных массивах, контроля целостности информационной базы, защиты от несанкционированного доступа. 1.2.2 ЛИНГВИСТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ АС АС является сложным человеко-машинным комплексом и требует наличия средств взаимодействия, обеспечивающих совместную работу в режиме диалога сотрудников ОУ и компьютерной техники. Для этого в АС определяются система терминов, используемых при разработке и функционировании АС, методы формализации естественного языка, а также информационные языки, в совокупности составляющие ЛО АС, направленное на поддержку взаимодействия персонала ОУ со средствами вычислительной техники [7]. Назначение ЛО. Главное назначение ЛО АС, включающего в свой состав различные диалоговые формы представления информации, заключается в предоставлении удобных и эффективных средств взаимодействия пользователей с АС. Требования к ЛО. ЛО АС должно быть достаточным для: – общения различных категорий пользователей с КСА с целью их совместной работы; 25 – реализации средств информационного языка АС, обеспечивающих общение пользователей с КСА, в удобной для них форме; – выполнения преобразования пользовательского представления в машинное, а машинного – в пользовательское, при вводе и выводе обрабатываемой в АС информации. Для удовлетворения предъявляемых требований в ЛО АС должны быть: – предусмотрены языковые средства для описания и представления любой используемой в АС информации; – унифицированы используемые языковые средства; – стандартизованы описания однотипных элементов информации и записи синтаксических конструкций; – обеспечены удобство, однозначность и устойчивость общения пользователей со средствами автоматизации АС; – предусмотрены средства исправления ошибок, возникающие при общении пользователей с техническими средствами АС. Состав ЛО АС. ЛО АС представляется совокупностью средств и правил для формализации естественного языка, используемых при общении пользователей с КСА, и включает в свой состав (см. Рис. 1.3): – систему словарей терминов и понятий, используемых в процессе разработки и функционирования автоматизированных систем управления; – правила формализации естественного языка, включая методы обработки текстов, представленных на естественном языке; – информационные языки, используемые для взаимодействия пользователей с КСА, включая: а) языковые средства автоматизации проектирования АС; б) информационные языки для описания структурных единиц ИБ АС (документов, показателей, реквизитов и т.п.); в) языки управления и манипулирования данными ИБ АС; г) диалоговые языки для взаимодействия с КСА АС. 26 1.2.3 ИНФОРМАЦИОННО-ЛИНГВИСТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ АС Информационное и лингвистическое обеспечение АС настолько тесно взаимосвязаны, что иногда рассматриваются как единый вид обеспечения, называемым информационно-лингвистическим обеспечением (ИЛО). Этот вид обеспечения является одним из основных и предназначен для: – поддержания информационно-вычислительного процесса в системе; – обеспечения информационной совместимости КСА с сопрягаемыми комплексами вышестоящих, взаимодействующих и подчиненных органов и объектов управления; – эффективного взаимодействия ДЛ органов управления с техническими средствами автоматизированных рабочих мест (АРМ) и программным обеспечением АС. Эффективность применения средств автоматизации в значительной степени зависит от качества ИЛО, которое обеспечивается: – максимальной унификацией представления информации, ее хранения и обработки; – исключением дублирования информации; – простотой использования языковых средств взаимодействия ДЛ с КСА. По составу ИЛО делится на две взаимосвязанные компоненты: лингвистическое и информационное обеспечение. Информационное и лингвистическое обеспечение АС представляет собой интеграцию компонентов ИО и ЛО подсистем и сопрягаемых объектов и включает в свой состав: – унифицированную систему документов; – систему классификации и кодирования информации; – нормативно-справочную информацию; – информационную базу; – средства формализации языка, включающих в свой состав систему словарей понятий, правила формализации информации и методы выделения и представления информационных сообщений; 27 – информационные языки АС, включающие группы языков описания данных и манипулирования данными, проектирования и программирования компонентов АС, управления функционированием АС и ее обслуживанием. 1.3 ФОРМАЛИЗАЦИЯ СТРУКТУРЫ ИНФОРМАЦИИ УПРАВЛЕНИЯ Реализация информационного процесса управления поддерживается за счет обмена сообщениями о событиях, имеющих место в системе. Сообщения представляют собой информационное отображение событий, и фиксируются в документах. Сообщения в документах выражаются на естественном языке, но по возможности представляются в виде формализованных выражений, в которых приводятся только названия опорных свойств (параметров) происходящего события и их значения. Поэтому формализованные сообщения – наиболее массовый вид сообщений, хранимых и обрабатываемых в документах ИнфС. Вопросы структурирования информации документов, изучались еще в то время, когда управление предприятиями и организациями было основано на бумажном документообороте. Именно в это время были определены такие понятия как неделимая единица информации – реквизит, минимальная составная единица информации, сохраняющая информативность, – показатель [8]. Эти понятия позволили формализовать информацию в документах, представленную на естественном языке, выделить ее составные части (опорные свойства) и установить взаимосвязи между ними с целью рационализации содержания документации в целом. С изобретением компьютеров появилась возможность применения методов структуризации информации для создания машинных ИБ на основе содержания документации, используемой в социальных системах. При этом сначала на логическом уровне (путем представления документов в терминах единиц информации) определяется структура ИБ, а затем эта структура реализуется на физическом уровне в машинной памяти. 28 Таким образом, методологию структурирования информации можно использовать при переходе от ИнфС, основанной на бумажном документообороте, к автоматизированной ИнфС, реализованной на основе централизованной БД. Основная задача разработчиков автоматизированных ИнфС заключается в выражении этих формализованных сообщений в терминах логических структур ИБ в виде единиц информации в памяти машины. Для этого в данном разделе сначала рассмотрим определения единиц информации, составляющих основу методологии структуризации информации документов, а затем приведем пример анализа структуры документа в терминах этих единиц для представления их в машинной памяти. 1.3.1 РЕКВИЗИТЫ Окружающий мир представляет собой огромное разнообразие предметов, объектов, явлений, процессов, отображаемых посредством информации. Каждая представляемая информацией сущность (объект, явление) имеет ряд характерных для нее свойств. Свойства физических сущностей, отображаемых в документах с помощью переменных величин, являющихся элементарными единицами информации, принято называть реквизитами. В обрабатываемой информации реквизиты представляются как бы «атомами», из которых компонуются более сложные по структуре компоненты информации. И, наоборот, единицы информации любой сложности можно последовательным разложением на составляющие компоненты в конечном итоге расчленить на реквизиты. Синонимами понятия реквизит, используемыми в информационных технологиях, являются элемент, поле, свойство, атрибут. Таким образом, реквизиты относятся к простейшей единице информации, неделимой на смысловом уровне, и отражающей количественную или качественную характеристику сущностей (объектов, процессов) предметной области. Реквизит – это логически неделимый элемент документа, описывающий определенное свойство или группу свойств отображаемого объекта. Дальнейшее членение реквизита на более мелкие со29 ставляющие – символы (символов в свою очередь на биты) разрывает его привязку к определенному свойству объекта (процесса) и нарушает информативность. Один и тот же признак может наблюдаться у разных объектов и явлений. Поэтому каждый реквизит, хотя и проявляется только в конкретных объектах и явлениях, обладает известной самостоятельностью и имеет особые, характерные для него черты. Это свойство находит свое отражение в форме, всесторонне характеризующей реквизит вне зависимости от его конкретного вхождения в ту или иную составную единицу информации. Поэтому каждый реквизит имеет форму и содержание и характеризуется именем (наименованием), областью определения (типом) и значением: – идентификатор реквизита (имя) – служит для обращения к нему и обычно представляется словом или группой слов (например, «табельный номер»); – область определения реквизита – множество значений свойства объекта (явления), которое информационно отображает данный реквизит. Например, для реквизита «табельный номер» рабочего предприятия область определения может быть представлена порядковыми номерами от 00001 до 99999; – значение реквизита является элементом множества значений из области определения реквизита. Оно отображает состояние свойства объекта (явления), характеризуемое реквизитом. Например, «табельный номер» = 23927. В зависимости от характера отображаемого ими свойства реквизиты делятся на реквизиты-признаки и реквизиты-основания: – реквизиты основания, характеризуют количественную или качественную сторону процесса или объекта и чаще всего выражаются в цифровой форме. Над ними могут выполняться логические и арифметические операции. Например, реквизитом-основанием будет сумма, имеющая численное значение и полученная путем арифметических подсчетов (количество умножить на цену). 30 – реквизиты признаки, отражают качественные свойства объекта, процесса или явления и, представляя, как правило, собой нечисловые данные, могут быть выражены в алфавитном, цифровом или алфавитно-цифровом виде. Реквизиты-признаки используются для логической обработки составных единиц, т.е. для поиска, сортировки, группировки, выборки и т.д. В качестве реквизитовпризнаков выступают, например, наименование предприятия, код объекта, номер документа, номер счета. 1.3.2 ПОКАЗАТЕЛИ Каждый из наблюдаемых объектов, процессов характеризуется, как уже говорилось, рядом присущих ему свойств, отражаемых в различных управленческих документах. Для организации ввода в машину информации документов об этих свойствах и формирования из них баз данных выделяются реквизиты. Но точно так же, как взятое в отдельности свойство еще не представляет сущность (объект, процесс) в целом, так и изолированно взятый реквизит, не имея смысла, не может служить полной информацией о наблюдаемом объекте (процессе). Для исчерпывающей характеристики процесса, объекта или явления необходима определенная совокупность реквизитов, описывающих качественные и количественные свойства отображаемого объекта. Поэтому реквизиты объединяются в структурные единицы более высокого уровня, называемые показателем. Именно показатель является основной структурной единицей, состоящей из определенной совокупности реквизитов, характеризующей какой-либо конкретный объект, факт, процесс с количественной и качественной стороны. Существует два определения этого понятия. В соответствии с первым, принятым в практике учета, статистики, планирования, под показателем понимается качественно определенная переменная величина, которой может быть поставлено в соответствие множество возможных количественных значений, а также алгоритмы их вычисления по различным исходным данным. 31 Прежде чем приступить к описанию второго определения показателя рассмотрим процесс общения между людьми. Человек воспринимает информацию (сообщения) на естественном языке (ЕЯ). Его знакам (словам, словосочетаниям, предложениям) в памяти воспринимающего соответствуют понятия, суждения и более сложные модели реального мира. Восприятие смысла сообщения обеспечивается тем, что знак сопоставляется с соответствующим понятием, вызываемым из памяти. В памяти помимо понятий фиксируются различные связи между ними, благодаря чему вместе с понятием, соответствующим полученному знаку, вызываются и связанные с ним другие понятия. Это чрезвычайно важное свойство, так как только в сопоставлении с взаимосвязанными понятиями возможна интерпретация сообщения. Естественно предположить, что общение между человеком и машиной будет облегчено, если приблизить структуру используемого при этом языка к структуре естественного, а машинную память строить примерно на тех же принципах, на которых построена человеческая, так, чтобы машина реагировала на запрос подобно человеку. Для этого, прежде всего, необходимо перейти к содержательному кодированию сообщений, используя то обстоятельство, что в совокупности реквизиты образуют высказывание (сообщение), имеющее законченный предметный смысл. Именно для этого сообщения в машинной памяти представляются в виде показателей. При этом структура памяти, ее организация должны быть построены таким образом, чтобы по некоторому набору содержательных признаков в ней можно было бы отыскать необходимый реквизит. Теперь перейдем ко второму определению, принятому в теории и практике автоматизированной обработки данных, описывающему показатель как высказывание, содержащее количественную или качественную характеристику какого-либо свойства (реквизита) отображаемого объекта. Такое высказывание содержит единственное значение свойства и определенный набор признаков, необходимых для его однозначной идентификации. 32 Приведенные определения не противоречат друг другу, просто в первом акцентируется внимание на то, как получен показатель, а во втором – какие атрибуты показателя отражают его конкретное смысловое содержание. Таким образом, показатель – это сообщение об объекте, представляющее собой минимальную составную единицу информации, сохраняющую информативность и включающую один реквизитоснование и группу взаимосвязанных с ним и между собой по смыслу реквизитов-признаков. Показатель можно определить как качественно определенную величину, дающую количественную характеристику отображаемому объекту. С одной стороны, показатели представляют составную единицу информации, способную образовать документ, с другой стороны, – описание количественного параметра, характеризующего какой-либо объект или процесс с количественной и качественной стороны. Таким образом, для определения показателя необходимо определить объект, один или несколько его признаков (атрибутов) со значениями, определяющие экземпляр этого объекта, а также признак с числовым или качественным значением. Поэтому показатель имеет название, раскрывающее его форму, и значение, добавляющее к форме количественно-качественные ее характеристики. Название показателя раскрывает его основной экономический смысл (что соответствует первому определению понятия показатель, так как позволяет сопоставить е му экономико-математическую модель расчета). Обычно в состав наименования показателя входят термины, обозначающие: – определяемый объект, точнее его экземпляр; – характеристику объекта, т.е. название его свойства. Значение показателя может быть либо качественным, либо количественным. Качественные показатели только констатируют наличие или отсутствие качества в терминах номинальной шкалы (ФИО, пол, наименование продукции и т.д.). Количественные показатели свидетельствуют об интенсивности проявления свойств в значениях. 33 Кроме того, показатель может содержать дополнительные признаки, которые не выражают его основной экономический смысл, но уточняют конкретное количественное значение показателя, а также обстоятельства его реализации как факта. Состав дополнительных признаков определяется в каждом конкретном случае по-разному, но обычно к ним относятся термины, обозначающие: – единицу измерения (кг., т., шт., руб., и т.п.), – время, к которому относится данный показатель (момент или период); – место, в котором реализуется факт, описываемый показателем; – кто производит действие над измеряемым объектом. Дополнительные признаки позволяют конкретизировать модель расчета показателя, характеризуя его особенность для каждого конкретного случая. В приведенном описании показатель представляет собой высказывание с законченным смыслом, включающее как название переменной величины, необходимое для ее идентификации, так и ее конкретное количественное или качественное значение. Такая точка зрения естественна для теории автоматизированной обработки данных, поскольку ее интересует идентификация именно каждого конкретного числа, а также возможность выполнения широкого круга логических операций над качественными признаками, характеризующими различные массивы данных. Например, высказывание на естественном языке «Длина кабеля 450 м» состоит из следующих реквизитов: – наименование объекта – кабель; – наименование свойства – длина; – единица измерения – м; – значение свойства – 450. Смысл этого высказывания определяется следующим образом: значение свойства «длина» объекта «кабель» в метрах – «450». Для передачи информации об объекте «кабель» определяется показатель, составленный из: 34 – нескольких реквизитов-признаков, определяющих его наименование («длина кабеля»); – дополнительного признака, указывающего единицу измерения показателя («м»); – реквизита-основания («450»), определяющего его значение. Именно в названиях данных выражается их смысл, определяемый как их контекст, позволяющий идентифицировать значение некоторого свойства названного экземпляра объекта. В период ручной обработки данных на эти моменты не обращали внимания, поскольку предполагалось, что человек сможет легко идентифицировать данные, если будет определен их смысл. В настоящее время с появлением СУБД и языка SQL в области содержательного кодирования информации в АС достигнут существенный прогресс. В БД АС показатель выступает естественной единицей хранения и передачи информации между пользователем и приложениями и представляется значением поля записи таблицы. При этом объект идентифицируется именем таблицы, экземпляр объекта или запись (строка) таблицы идентифицируется значениями простого или составного первичного ключа, а свойство – именем поля или атрибута таблицы. 1.3.3 ДОКУМЕНТЫ Показатель – основная единица документной информации, так как он имеет смысл, а исключение хотя бы одной его составляющей неизбежно влечет потерю смысла. Вместе с тем в целях организации эффективной обработки информации и реализации функций управления из показателей составляются более сложные структурные единицы информации: документы, массивы, информационные базы. 1.3.3.1 О б щ е е о п и с а н и е д о к ум е н т а Документ представляет собой определенным образом организованную совокупность взаимосвязанных по смыслу показателей. Документ является основной и наиболее удобной формой представления информации с точки зрения управления, так как наряду с 35 полнотой и наглядностью представления информации, он содержит реквизиты, придающие ему юридический статус. Под документом следует понимать такую информационную совокупность, которая имеет самостоятельное смысловое значение и характеризуется полным набором реквизитов и показателей, описывающим некоторую ситуацию. Данная информационная совокупность должна быть зафиксирована на материальном носителе в соответствии с существующими правилами, придающими ей юридическую силу. Каждый документ может включать в себя любое число реквизитов-признаков и реквизитов-оснований. Структура информации, содержащейся в документе, и определяет состав, название и размещение показателей и их реквизитов, входящих в документ. Содержательная часть (или контент) документа включает названия показателей и реквизитов и данные, внесенные в места, отведенные для значений реквизитов. Форма документа – это результат материализации контента и структуры документа в виде шрифтов, используемых для представления наименований и значений реквизитов, их размеров, стилей, цвета, заголовков, абзацев, отступов. Форма документа обеспечивает восприятие данных документа органами чувств человека и их последующую интерпретацию. Анализ структуры показателей документа имеет большое значение для их представления в машинной памяти с целью использования при автоматизированной обработке. Этот анализ приводит к выявлению объектов, их показателей и реквизитов (атрибутов) и заканчивается составлением таблиц, в строках которых информация, описывающая различные аспекты (атрибуты) объектов, сгруппирована по ключевым реквизитам-признакам. Для такой группировки показателей используется методология, основанная на понятии функциональной зависимости реквизитов. Функциональная зависимость реквизитов – это не что иное, как связь между реквизитами-признаками и реквизитами-основаниями показателя, отражающая тот факт, что его реквизиты-основания однозначно идентифицируются реквизитами-признаками. 36 На основе понятия функциональной зависимости реквизитов были выработаны формальные правила, которые хотя и не могут быть использованы для автоматического выделения информационных объектов, но с их помощью можно построить информационную структуру документа в следующей последовательности: – на основе изучения документов ПрО выявляются реквизиты, подлежащие хранению в машинной памяти; – определяются функциональные зависимости между выявленными реквизитами путем их группирования в показатели. При этом в каждом показателе его реквизиты-основания идентифицируются реквизитами-признаками; Накладная на отпуск изделий Номер накладной 19 Дата 08.09.2010 Получатель Наименование Завод МЛЗ Шифр 132 Платежное требование Номер Дата Вид упаковки Станция назначения Основание Вид операции 51 Склад 4 Адрес г. Москва, ул. 1 Мая, 1 № 899 от 08 февраля 2010 г. Ящики г. Москва-Товарная II Договор №20 от 06.07.2010 г. Отпускаемый товар Наименование № номенкл Цена Подшипники Кольца Сепараторы 11250 11781 12261 Отпуск разрешил Ильин Ф.О. 250 150 115 Гл. бухгалтер Зуев П.И. Количество по наряду отпущено 100 100 30 30 100 100 Отпустил Осин В.Г. Рис. 1.4 – Реквизитный состав документа 37 Сумма 25000 4500 11500 Получил Кузин Е.С. – выбираются реквизиты-основания, зависящие от общего реквизита-признака, который для каждой выбранной группы реквизитов-оснований определяется в качестве ключевого реквизита; – сформированная группа реквизитов, зависимая от одного ключевого реквизита (также входящего в эту группу), определяется как реквизитный состав информационного объекта. В качестве примера анализа реквизитного состава документа рассмотрим процедуру формализации информации, содержащейся в таком распространенном документе, как приказ-накладная на отпуск изделий (см. Рис. 1.4). 1.3.3.2 Р е к в и з и т н ы й с о с т а в д о к у м е н т а Сначала определим реквизиты, значения которых определяют экземпляр документа. Как правило, в качестве реквизитов, идентифицирующих экземпляр документа, являются номер и дата документа. В нашем документе это: – «Номер накладной – 19»; – «Дата накладной – 08.09.2010». Кроме идентификационных реквизитов (т.е. реквизитов-признаков) в данном документе содержатся реквизиты, описывающие различные аспекты ситуации отпуска товаров, связанной с данным экземпляром документа: – «Вид операции» – «51» (код операции); – «Склад» – «4» (номер склада, с которого отпускается товар). Следующая группа реквизитов определяет характеристики получателя товара: – «Наименование – Завод МЛЗ»; – «Шифр – 132» (код предприятия для автоматизированной обработки); – «Адрес – г. Москва, ул. 1 Мая, 1». Далее следуют реквизиты, характеризующие документ «Платежное требование», составленное получателем товара: – «Номер – 899»; – «Дата – 08 февраля 2010 г.»; – «Вид упаковки – Ящики»; 38 – «Ст. назначения – г. Москва-Товарная II»; – «Основание – Договор №20 от 07.06.2010 г.» (реквизиты договора, на основании которого составлено платежное требование). В нижеследующей таблице представлены данные по отпускаемому товару: – «Наименование – значения», – «Цена – значения», – «Количество по наряду – значения», – «Количество отпущенного – значения», – «Сумма – значения». В таблицы в документах – это удобное средство для представления повторяющейся группы реквизитов. В нижней части документа содержатся реквизиты, придающие юридическую силу рассматриваемому документу: – «Отпуск разрешил – Ильин Ф.О.» (Фамилия И.О. и подпись лица, санкционирующего отпуск товара); – «Главный бухгалтер – Зуев П.И.» (Фамилия И.О. и подпись лица, фиксирующего факт оплаты за отпущенный товар); – «Отпустил – Осин П.И.» (Фамилия И.О. и подпись лица, фиксирующего факт отпуска товара получателю); – «Получил – Кузин Е.С.» (Фамилия И.О. и подпись лица, подтверждающего факт получения товара). Каждая конкретная ситуация «Отпуск товара» описываемая документом «Накладная на отпуск изделий» определяется значениями реквизитов выделенных объектов. 1.3.3.3 П о к а з а т е л и д о к ум е н т а В данном подразделе приведем описание порядка определения показателей объектов по их реквизитному составу. Для этого необходимо определить характер реквизитов, какие из них являются реквизитами-признаками, а какие – реквизитами-основаниями. Затем требуется определить, каким реквизитом-признаком идентифицируется каждый из выявленных реквизитов-оснований. При этом мы фактически определяем показатели документа. 39 Ситуация отпуска товаров, описываемая данным документом идентифицируется номером и датой документа. Следовательно, реквизиты «Номер накладной» и «Дата накладной» являются реквизитами-признаками. Реквизиты «Вид операции» и «Склад», описывающие ситуацию отпуска товаров, являются реквизитами-основаниями, идентифицируемыми реквизитами-признаками «Номер накладной» и «Дата накладной». Следовательно, аспекты ситуации отпуска товара организацией-составителем, описываются следующей последовательностью показателей: – «Номер накладной»; «Дата накладной» | «Вид операции»; – «Номер накладной»; «Дата накладной» | «Склад»; Для идентификации организации-получателя товара удобно использовать реквизит «Шифр». Хотя для этой цели подойдет и реквизит «Наименование», но с точки зрения машинной обработки использовать числовые значения для идентификации целесообразнее, нежели текстовые, так как это требует меньших вычислительных ресурсов. Отсюда следует, что реквизит «Шифр» является реквизитомпризнаком, реквизиты «Наименование» и «Адрес» – реквизитамиоснованиями, а состав показателей для описания организацииполучателя товара представлен последовательностью: – «Шифр» | «Наименование»; – «Шифр» | «Адрес». Реквизиты «Номер» и «Дата», представленные в данном документе, используются для идентификации платежного требования, на основании которого составлен анализируемый документ «Накладная на отпуск товара». Поэтому эти реквизиты определяются как реквизиты-признаки, используемые для идентификации реквизитов, описывающих платежное требование. Таким образом, реквизиты «Вид упаковки», «Ст. назначения» и «Основание» идентифицируются реквизитами-признаками «Номер» и «Дата», что и определяет состав показателей для описания платежного требования, перечисленный ниже: 40 – «Номер»; «Дата» | «Наименование»; – «Номер»; «Дата» | «Ст. назначения»; – «Номер»; «Дата» | «Основание». Данные об отпущенных данной накладной товарах представлены в таблице, из которых легко выделяется реквизит-признак «№ номенклатуры». Остальные реквизиты являются реквизитами-основаниями, идентифицируемыми данным реквизитом-признаком. Следовательно, для описания данных об отпускаемых товарах в данном документе используются показатели: – «№ номенклатуры» | «Наименование»; – «№ номенклатуры» | «Цена»; – «№ номенклатуры» | «Количество по наряду»; – «№ номенклатуры» | «Количество отпущенного»; – «№ номенклатуры» | «Сумма». Группа реквизитов «Отпуск разрешил», «Главный бухгалтер», «Отпустил», «Получил», придающая юридическую силу рассматриваемому документу, описывает экземпляр этого документа. Легко определить, что по своему смыслу эти реквизиты являются реквизитами-основаниями, идентифицируемые реквизитами-признаками «Номер накладной» и «Дата накладной» и мы получаем еще одну группу показателей, перечисленную ниже: – «Номер накладной»; «Дата накладной» | «Отпуск разрешил»; – «Номер накладной»; «Дата накладной» | «Главный бухгалтер»; – «Номер накладной»; «Дата накладной» | «Отпустил»; – «Номер накладной»; «Дата накладной» | «Получил». 1.3.3.4 О б ъ е к т ы д о к ум е н т а Хотя документы составляются на естественном языке, в них информация представляется в удобной для анализа реквизитного состава форме и, как правило, сгруппированы по объектам. Поэтому на двух предыдущих этапах анализа документа, как реквизиты, так и показатели уже были тематически сгруппированы, что фактически определяет состав показателей объектов, описываемых данным документом. 41 Все, что остается сделать на данном этапе анализа документа – это определить реквизитный состав объектов, объединив в показатели объектов те, которые имеют общие реквизиты-признаки. В соответствии с описанным порядком определяется реквизитный состав объекта «ОТПУСК ТОВАРА»: – «Номер накладной» – реквизит-признак; – «Дата накладной» – реквизит-признак; – «Вид операции» – реквизит-основание; – «Склад» – реквизит-основание; – «Отпуск разрешил» – реквизит-основание; – «Главный бухгалтер» – реквизит-основание; – «Отпустил» – реквизит-основание; – «Получил» – реквизит-основание. Обратите внимание на то, что в состав реквизитов объекта «ОТПУСК ТОВАРА» вошли и реквизиты-основания, определяющие юридический статус документа. Это объясняется тем, что их идентифицирующими реквизитами-признаками, как и для реквизитовоснований «Вид операции» и «Склад», являются реквизиты-признаки «Номер накладной» и «Дата накладной». Реквизитные составы остальных объектов определяются аналогично и представляются в виде следующих последовательностей. Реквизитный состав объекта «ОРГАНИЗАЦИЯ-ПОЛУЧАТЕЛЬ»: – «Шифр» – реквизит-признак; – «Наименование» – реквизит-основание; – «Адрес» – реквизит-основание. Реквизитный состав объекта «ПЛАТЕЖНОЕ ТРЕБОВАНИЕ»: – «Номер» – реквизит-признак; – «Дата» – реквизит-признак; – «Вид упаковки» – реквизит-основание; – «Ст. назначения» – реквизит-основание; – «Основание» – реквизит-основание. Реквизитный состав объекта «ОТПУСКАЕМЫЙ ТОВАР»: – «№ номенклатуры» – реквизит-признак; – «Наименование» – реквизит-основание; – «Цена» – реквизит-основание; 42 Документ «Накладная на отпуск изделий» Номер накладной Дата накладной Вид операции Склад Отпуск разрешил Главный бухгалтер Отпустил Получил 19 08.09.2010 51 4 Ильин Зуев Осин Кузин ПОЛУЧАТЕЛЬ Шифр Наименование Адрес 132 Завод МЗЛ г.Москва, ул. Мира, 1 ПЛАТЕЖНОЕ ТРЕБОВАНИЕ Номер Дата Вид упаковки Ст. назначения Основание 899 08.02.2010 Ящики Москва-Товарная II Договор №20 от 06.07.2010 ОТПУЩЕННЫЙ ТОВАР № номенклатуры Наименование Цена Кол-во по наряду Кол-во отпущен-го Сумма 11250 Подшипники 250 100 100 25000 ... ... ... ... ... ... 11261 Сепараторы 115 100 100 11500 Рис. 1.5 – Состав реквизитов, показателей и объектов документа «Накладная на отпуск товара» 43 – «Количество по наряду» – реквизит-основание; – «Количество отпущенного» – реквизит-основание; – «Сумма» – реквизит-основание. Состав реквизитов, показателей и объектов документа «Накладная на отпуск товара» приведен на Рис. 1.5. 1.3.4 ИНФОРМАЦИОННО-ЛОГИЧЕСКАЯ МОДЕЛЬ ДОКУМЕНТА С целью автоматизированной обработки информации, содержащейся в документах социальных систем, данные документов сохраняются в машинной памяти. При этом реквизиты, показатели и объекты, описываемые в документах, сохраняются в машинной памяти с помощью программных средств АС в виде значений полей, элементов записей и строк таблиц. Требования, диктуемые потребностями программных средств, соображения минимизации объема используемой памяти системы приводят к тому, что сохраняемые данные документов подвергаются определенной трансформации, в соответствии с которой: – часть данных кодируется, и представляется в виде, отличном от представляемых в документах (например, наименования реквизитов могут быть представлены на латинице и в сокращенном виде); – данные, не имеющие непосредственного отношения к автоматизированной обработке, игнорируются (например, данные о форматировании текста документа); – для выделения смысловых связей между реквизитами документов с целью их автоматизированной обработки вводится дополнительная информация, которая в документах представлена неявно и выявляется только человеком благодаря его интеллектуальным возможностям. Трансформация данных документа в части явного определения связей между его объектами осуществляется в ходе разработки информационно-логической модели документа, описываемого в данном подразделе, а изменения формы представления данных и сокращения их объема будет представлено в Главе 3 в ходе рассмотрения процесса разработки концептуальной схемы БД. 44 Описание процедуры разработки информационно-логической модели документа начнем с рассмотрения связей между его объектами. Выделенные в ходе анализа структуры документа четыре информационных объекта имеют между собой связи, описываемые следующим образом: – связь объектов «ОТПУСК ТОВАРА» – «ОРГАНИЗАЦИЯ-ПОЛУЧАТЕЛЬ» определяет, что данные экземпляра документа, идентифицируемого значениями «Номер накладной» = 19 и «Дата накладной» = 08.09.2010, связаны с данными организации-получателя, идентифицируемого кодовым значением «Шифр» = 132; – связь «ОТПУСК ТОВАРА» – «ПЛАТЕЖНОЕ ТРЕБОВАНИЕ» определяет, что данные экземпляра документа, идентифицируемого значениями «Дата накладной» = 08.09.2010 и «Номер накладной» = 19, связаны с данными документа «Платежное требование», идентифицируемого значениями «Номер» = 899, «Дата» = 08.02.2010; – связь «ОТПУСК ТОВАРА» – «ОТПУЩЕННЫЙ ТОВАР» определяет, что по экземпляру документа, идентифицируемого значениями «Номер накладной» = 19 и «Дата накладной» = 08.09.2010, отпущены товары, идентифицируемые значениями «Номер номенклатуры» = 11250, …, «Номер номенклатуры» = 11261. Функциональные связи реквизитов, входящих в показатели, показателей, входящих в состав объектов в документах, а также связи между объектами документа определяются человеком по их смысловым связям, а также по их размещению на одном документе. Например, реквизиты «Номер накладной», «Дата», «Вид операции» и «Склад» легко определяются как представляющие ситуацию отпуска товара, описываемую данным документом. Факт их размещения под заголовком документа облегчает их интерпретацию. Также легко определяется характер этих реквизитов. В соответствии с давней традицией делопроизводства, номер и дата документа используются для идентификации экземпляра документа. Поэтому реквизиты «Номер накладной» и «Дата» определяются как реквизиты-признаки, идентифицирующие реквизиты-основания «Вид операции» и «Склад», т.е. между ними устанавливаются связи в составе показателя. 45 Далее по общности реквизитов-признаков определяются связи между показателями объекта, а по факту расположения в одном документе – связи между объектами документа. Но при машинном представлении данных документов мы имеем дело со следующими проблемами: – в теории реляционных БД понятия реквизит-признак и реквизит-основание не рассматриваются, поэтому связь между этими видами реквизитов требуется устанавливать другими средствами; – реквизитный состав информационных объектов документа представляется в разных массивах ИБ АС. Поэтому установить связь между этими информационными объектами в машинной памяти не представляется возможным, так как фактор их размещения на одном документе при этом исчезает. Первая из описанных проблем решается легко путем установления соответствий: «реквизит-признак → ключевой атрибут» и «реквизит-основание → неключевой атрибут». Таким образом, реквизиты-признаки объектов модели документа в реляционной модели определяются как «первичные ключи», а реквизиты-основания – как «неключевые атрибуты» таблицы БД. В теории реляционных БД для описания связи между объектами используется понятия главного (родительского) и подчиненного (дочернего) объектов, между которыми имеет место связь, а также внешнего или вторичного ключа. Главным называется объект, значения первичного ключа которого используются для идентификации экземпляров подчиненного объекта, связанных с его экземплярами. Для этого в подчиненный объект добавляются атрибуты вторичного ключа. Вторичным ключом называется атрибут подчиненного объекта связи, область значений которого определяется множеством значений первичного ключа главного объекта связи. Эти понятия теории реляционных БД можно использовать для явного описания связей между объектами в модели документа путем внесения некоторых изменений в реквизитный состав объектов модели документа, приведенной на Рис. 1.5. 46 Документ «НАКЛАДНАЯ НА ОТПУСК ИЗДЕЛИЙ» Номер накладной Дата накладной ... Отпустил Получил 19 08.09.2010 ... Осин Кузин ПОЛУЧАТЕЛЬ Шифр 132 ... Номер накладной Дата накладной ... 19 08.09.2010 ПЛАТЕЖНОЕ ТРЕБОВАНИЕ Номер Дата 899 08.02.2010 ... Номер накладной Дата накладной ... 19 08.09.2010 ОТПУЩЕННЫЙ ТОВАР № номенклатуры 11250 ... ... Номер накладной 19 Дата накладной 08.09.2010 ... 11261 ... ... ... 19 ... 08.09.2010 Рис. 1.6 – Информационно-логическая модель документа «Накладная на отпуск товара» Для явного указания связей между объектами модели документа в подчиненном объекте добавляется реквизит, значения которого должны соответствовать одному из значений реквизита-признака главного объекта. 47 Таким образом, в информационно-логической модели документа связь между объектами документа устанавливается явно, которая сохраняется и при машинном представлении данных документа. Следует отметить, что добавление реквизитов связи осуществляется не в документе, а только в его информационно-логической модели (см. Рис. 1.6), используемой для формирования массивов (таблиц) БД АС по данным документов автоматизируемой социальной системы. Для двух оставшихся связей в объектах «ПЛАТЕЖНОЕ ТРЕБОВАНИЕ» и «ОТПУЩЕННЫЙ ТОВАР» также вводятся составные реквизиты «Номер накладной», «Дата накладной». В рассматриваемом примере для указания связи между главным («ОТПУСК ТОВАРА») и подчиненным объектами («ОРГАНИЗАЦИЯ-ПОЛУЧАТЕЛЬ», «ПЛАТЕЖНОЕ ТРЕБОВАНИЕ» и «ОТПУЩЕННЫЙ ТОВАР») в подчиненных объектах вводятся реквизиты «Номер накладной» и «Дата накладной», значения которых должны соответствовать значениям одноименных реквизитов-признаков объекта «ОТПУСК ТОВАРА». Экземпляры этих объектов считаются связанными, если значения соответствующих реквизитов подчиненного объекта совпадают со значениями реквизитов-признаков одного из экземпляров главного объекта. Соответствие имен реквизитов главного и подчиненного объектов связи необязательно. Это, как правило, делается для обеспечения наглядности представления связи в информационно-логической модели документа. При машинном представлении связи атрибуты вторичного ключа указываются явно. Также указывается, на значения каких атрибутов, и какой главной таблицы ссылаются значения определяемого вторичного ключа. Поэтому обозначать связь путем назначения одинаковых имен атрибутам первичных и вторичных ключей связи при их машинном представлении нет необходимости. КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Каким образом используется информация при реализации процесса управления? 2. Состав автоматизированной информационной системы. 48 3. Что собой представляет информационная система в управлении? 4. В чем особенности ручной и автоматизированной обработки данных в информационных системах. 5. Дайте определение информационного обеспечения автоматизированной системы. 6. Дайте определение лингвистического обеспечения автоматизированной системы. 7. Опишите, в чем заключается связь между информационным и лингвистическим обеспечением автоматизированной системы. 8. Опишите состав информационного обеспечения автоматизированной системы. 9. Опишите состав лингвистического обеспечения автоматизированной системы. 10. В чем заключается назначение информационного обеспечения автоматизированной системы. 11. В чем заключается назначение лингвистического обеспечения автоматизированной системы. 12. Дайте описание и определение реквизита. 13. Дайте описание и определение показателя. 14. Опишите порядок анализа реквизитного состава документа. 15. Опишите порядок формирования модели документа в терминах реквизитов, показателей и объектов. 16. Опишите порядок формирования информационно-логической модели документа в терминах объектов и их взаимосвязей, выраженных в терминах реляционной модели. 49 ИнфС, реализованные на основе АС, на начальных этапах своего развития представляли собой множества не связанных между собой приложений, данные которых хранились в плоских базах, поддерживаемых файловой системой. Но вскоре стало ясно, что, автоматизируя некоторую общую предметную область, отдельные разрозненные приложения должны между собой взаимодействовать, т.е. обмениваться данными. В начале 70-х годов прошлого века эта потребность была удовлетворена средствами систем обмена сообщениями. В результате была создана шина для обмена данными, которая оказалась довольно громоздкой, так как для согласования несвязанных между собой двоичных кодов требовались тяжеловесные адаптеры. Первая революция в области автоматизированных ИнфС, нацеленная на преодоление сложностей такого рода, была вызвана появлением реляционных СУБД. Важным преимуществом этой системы управления данными было такое качество, которое можно назвать «самоописанием данных». 50 Во-первых, при наличии этого описания, хранимого в базе метаданных, и языков запросов, разные приложения получили возможность обращаться к общим информационным массивам. Во-вторых, к средствам и возможностям реляционных баз данных получили непосредственный доступ специалисты самых разных предметных областей, работающих в ОУ предприятий и организаций и, как правило, не являющихся специалистами в области информационных технологий. На сегодняшний день системы, реализованные на основе СУБД, различные компоненты которой объединены с помощью локальной сети, составляют львиную долю АС, используемых органами управления, различные аспекты информационного и лингвистического обеспечения которых являются предметом изучения в первой части учебного пособия. 51 При проектировании и разработке ИО системы управления наиболее важной процедурой является установление состава и структуры информации, пригодной для хранения в памяти АС и необходимой и достаточной для принятой технологии управления. Именно эта работа выполняется на этапе разработки внемашинного ИО. Внемашинное ИО включает в свой состав унифицированную систему документации (включая нормативно-справочные документы), отражающую показатели, необходимые для решения управленческих задач, классификаторы и коды, используемые для описания объектов предметной области (ПрО), формуляры для представления информации. Система показателей, выявленная на этапе анализа документооборота автоматизируемой социальной системы, служит основой для формализации ее документов, с целью создания рационально организованного комплекса взаимосвязанных документов, отвечающего единым правилам и требованиям, и содержащего информацию, необходимую для управления системой. Автоматизация управленческих операций требует приведения всего множества показателей, используемого в документах, в единую, целостную систему, установления их содержательного и терминологического единства (однозначности), а также четких взаимосвязей между ними. 52 Установление содержательного и терминологического единства показателей реализуется путем введения классификаторов. Классификатор – это систематизированный свод однородных наименований, т. е. классифицируемых объектов и их кодовых обозначений. За классификацией выполняется кодирование – процесс присвоения условного обозначения различным позициям номенклатуры. Присвоением кодовых обозначений каждой позиции номенклатуры заканчивается формирование классификатора – систематизированного свода однородных наименований и их кодовых обозначений. В системах управления определяется еще и совокупность условно-постоянных данных, называемая нормативно-справочной информацией (НСИ), на которой основываются процессы формирования различных справочных и распорядительных документов. В отличие от текущей информации, относящейся лишь к конкретному документу, НСИ используется в разных документах, относящихся к разным бизнес-процессам. В системах управления НСИ представлена в табличном виде, обычно набором справочников, словарей и классификаторов. 2.1 УНИФИЦИРОВАННЫЕ СИСТЕМЫ ДОКУМЕНТАЦИИ Совокупность всех документов (приказов, инструкций, справок, докладных и служебных записок и т.д.), циркулирующих в системе управления, представляет собой систему документации, которая является базовым компонентом внемашинного ИО АС, и применяется в процессе управления социальной системой. От правильной и тщательно разработанной системы документации во многом зависят сокращение объемов работ по ее оформлению и подготовке к вводу в компьютер, уменьшение числа возможных ошибок при вводе данных и повышение надежности системы в целом. Системы документации, сформированные в эпоху бумажного документооборота, характеризуются большим количеством различных типов форм документов и неоднозначным именованием показателей и реквизитов в разных документах, что приводит к представлению одной и той же информации в документах под разными наименованиями. С целью устранения этих недостатков [6]: 53 – вводятся безбумажные технологии, основанные на использовании электронной документации; – проводится унификация и стандартизация документов. Унификация документов выполняется путем введения единообразия наименований показателей и реквизитов во всех документах системы документации. В результате получаем унифицированную систему документов, представляющую собой рационально организованный комплекс взаимосвязанных документов, отвечающий единым правилам и требованиям, и содержащий информацию для оптимального управления некоторым объектом. 2.1.1 ОСНОВНЫЕ ЦЕЛИ УНИФИКАЦИИ СИСТЕМЫ ДОКУМЕНТОВ Четкое построение документов, унификация и упрощение их форм способствуют сокращению цикла обработки и своевременному получению всех необходимых данных о результатах деятельности предприятий и организаций. На сегодняшний день унификация документации проведена в государственном масштабе. В результате унификации и стандартизации системы документов создается УСД, включающая в себя совокупность унифицированных форм документов (УФД), нормативные и методические документы по их разработке, ведению и применению [9]. УФД представляют собой совокупность взаимосвязанных показателей в этих документов. Основными целями унификации системы документов являются: – сокращение количества документов; – сокращение объема документов; – унификация и упорядочение показателей в документах; – формализация документов. Сокращение количества документов реализуется за счет унификации форм документов, имеющих общую содержательную часть, но незначительно отличающихся по форме представления. Сокращение объема документа достигается за счет: – сокращения избыточности информации в документе, которая в то же время должна быть достаточной и обеспечивать информационные потребности должностных лиц (ДЛ); 54 – сокращения числа показателей в документе за счет удаления избыточных; – сокращения текстовых материалов посредством формализации, реализуемой их заменой табличными и анкетными формами; – использования фрагментов документов, содержащих только актуальную информацию. Унификация и упорядочение информации в документах проводится на основе: – применения единых правил формализации информации; – использования единого порядка размещения и следования реквизитов в формах документов; – использования общей модели построения документов, позволяющей максимально их унифицировать. Формализация документов проводится на основе: – определения реквизитного состава документов; – кодирования реквизитов документов; – кодирования наименований показателей документов; – выделения информационных объектов документов и определения их реквизитного состава. Унификация документов обеспечивает снижение трудоемкости обработки документов, достижение их информационной совместимости и способствует более эффективному использованию вычислительной техники. 2.1.2 УНИФИЦИРОВАННАЯ СИСТЕМА ДОКУМЕНТАЦИИ РОССИИ Национальные стандарты на системы документации были введены еще в 70-х годах, а в 1994 г. был утвержден ГОСТ на унифицированную систему организационно-распорядительной документации [10]. В него вошел комплекс стандартов на составление: актов делового письма, докладной записки, заявлений, инструкций, кадровой анкеты, объяснительной записки, приказов, распоряжений и др. При этом были пересмотрены и утверждены новые государственные стандарты на ряд специальных УСД: плановую документацию, по бухгалтерскому учету, материально-техническому снабжению, финансам, статистическую документацию и др. 55 2.1.2.1 О б щ е р о с с и й с к и й к л а с с и ф и к а т о р у п р а в л е н ч е с к о й д о к ум е н т а ц и и Каждой утвержденной Госстандартом России форме документа присваивается в соответствии с Общегосударственным классификатором управленческой деятельности (ОКУД) код, который располагается в верхней правой части документа. Основой построения стандартных форм документов являются утвержденные формуляры-образцы. Так, составление организационно-распорядительных документов регламентируется государственными стандартами; это – основные положения о составлении и оформлении документов и формуляробразец, представляющий собой модель формы, присущей данной унифицированной системе. Унифицированная система документации устанавливает общие требования к разработке всех документов и их содержанию, включает формы документов, государственные стандарты и методические материалы, регламентирующие порядок оформления, согласования и утверждения документов. К настоящему времени унифицировано свыше трех с половиной тысяч форм плановых, учетных, финансовых и других документов, сведенных в 1993 г. в ОКУД. 2.1.2.2 О б щ е р о с с и й с к и е У С Д Обязательны к применению следующие общероссийские унифицированные системы управленческой документации, включающие в себя комплексы документов, сгруппированные по задачам: – унифицированная система организационно-распорядительной документации (УСОРД – код ОКУД 0200000); – унифицированная система первичной учётной документации (УСПУД – код ОКУД 0300000); – унифицированная система банковской документации (УСБД – код ОКУД 0400000); – унифицированная система финансовой, учетной документации организаций (УСФУ ОБД – код ОКУД 0500000); 56 – унифицированная система отчетно-статистической документации (УСОСД – код ОКУД 0600000); – унифицированная система учетной и отчетной бухгалтерской документации предприятий (УС УОБД – код ОКУД 0700000); – унифицированная система документации по труду (УСДТ – код ОКУД 0800000); – унифицированная система документации Пенсионного фонда РФ (УСДПФ РФ – код ОКУД 0900000); – унифицированная система внешнеторговой документации (УСВД – код ОКУД 1000000). Каждый документ, включенный в ОКУД, получает кодовое обозначение, определяемое принадлежностью к одной из УСД и местом документа внутри этой системы. 2.1.2.3 С и с т е м а к о д и р о в к и О К У Д В семизначном кодовом обозначении унифицированной системы документации отражены следующие признаки классификации: – первый и второй знаки (класс форм) – принадлежность унифицированной формы документа к соответствующей унифицированной системе документации (например, 02 – УСОРД); – третий и четвертый знаки (подкласс форм) – общность содержания множества форм документов и направленность их использования (например, 01 – документация по учету и распределению средств); – пятый, шестой и седьмой знаки – регистрационный номер унифицированной формы документа внутри подкласса (например, 004 – расчетная ведомость по страховым взносам). Кодовые обозначения объектов ОКУД подлежат простановке во всех унифицированных формах документов. 2.1.3 УНИФИЦИРОВАННАЯ СИСТЕМА ДОКУМЕНТАЦИИ АС Общероссийская УСД не в состоянии учитывать специфические документы, используемые в ходе деятельности предприятий и организаций. Поэтому при создании АС разрабатывается УСД АС, си- 57 стематизирующая документы предприятий и организаций, не представленные в общероссийской УСД. УСД АС включает в свой состав формализованные документы информационного обмена, обеспечивающие информационное взаимодействие как объектов АС (включая пользователей) между собой, так и с другими системами. 2.1.3.1 О б щ и е п о л о ж е н и я Целью создания УСД АС является определение и установление рационального состава УФД предприятий и организаций, которые могут быть представлены в виде шаблонов, экранных форм, сообщений информационного обмена. Основным назначением УСД АС является: – создание условий для формирования единого информационного пространства АС; – обеспечение систематизации информации по единым правилам и ее использования при ведении учета и отчетности; – создание условий для обеспечения информационного взаимодействия АС и унификации протоколов обмена информацией. Состав УСД АС включает в себя: – совокупность УФД, используемых предприятиями и организациями, представленных в виде табелей и альбомов УФД; – средства ведения УФД, обеспечивающие ее автоматизированную обработку в составе АС; – нормативные и методологические документы, регламентирующие разработку, ведение и применение УФД. Таким образом, УСД или система формализованных документов информационного обмена АС формируется на основе УФД. 2.1.3.2 У н и ф и ц и р о в а н н ы е ф о р м ы д о к ум е н т о в УФД представляет собой упорядоченную совокупность реквизитов, установленных в соответствии с правилами формализации и унификации и решаемыми в данной сфере деятельности задачами. Состав (перечень) УФД определяется на основе анализа системы документов, представляемой в АС. 58 К УФД предъявляются следующие требования: – соответствие единым правилам построения; – минимальная избыточность реквизитов; – удобство их заполнения и машинной обработки. Введение новых УФД или изменение существующих должно происходить на основе соответствующих нормативных актов. Каждая вводимая УФД должна регистрироваться путем присвоения ей регистрационного номера и включения ее наименования в классификатор УФД (табель форм документов). Принципы создания УФД АС. УФД АС разрабатываются с целью установления единообразия форм документов на следующих принципах: – регламентации содержания документов, входящих в систему документации, путем определения совокупности реквизитов и показателей для каждого вида документов и создания единых моделей построения совокупности их видов, пригодных как к машинной обработке, так и для восприятия их человеком; – установления единых правил составления и оформления реквизитов документов, общих для всех видов документов системы документации; – единства применяемой терминологии и условных обозначений в целях сопоставимости показателей при переходе с одного уровня управления на другой и от одного вида документов к другому на основе унификации показателей документов; – исключения из документов дублируемых данных в целях обеспечения однократности ввода информации в процессе выполнения управленческой задачи. Разработка проектов УФД АС. Разработка проектов УФД АС осуществляется в соответствии с требованиями ГОСТ Р 6.30-2003. «Унифицированные системы документации. Требования к оформлению документов». Для разработки проекта УФД АС используется ее формуляробразец (ФО), содержащий план размещения реквизитов с указанием занимаемой ими площади. 59 ФО УФД устанавливает: – формат бумаги; – конструкционную сетку; – расположение частей и зон с реквизитами. Формат бумаги определяется исходя из состава реквизитов документа и занимаемой ими суммарной площади. Конструкционная сетка ФО УФД образуется пересечением вертикальных и горизонтальных линий на бумаге установленного формата, ограниченной полями. ФО УФД содержит следующие части: – адресную (заголовок); – содержательную или информационную; – подписную. Адресная и подписная часть – это служебные части документа и могут отсутствовать (например, в справочных документах). Адресная часть может содержать: гриф конфиденциальности, номер формы, получателя и т.д. Подписная часть может содержать: подпись, исходящий номер, дата и т.д. Содержательная часть определяет последовательность размещения сведений, последовательность следования постоянной и переменной части. 2.1.3.3 Н о р м а т и в н ы е и м е т о д о л о г и ч е с к и е док ументы разработк и УСД АС Нормативные и методологические документы, регламентирующие разработку, ведение и применение УСД АС содержат: – ГОСТ Р 51141-98. Делопроизводство и архивное дело. Термины и определения; – ГОСТ Р 6.30-2003. Унифицированные системы документации. Требования к оформлению документов; – Общероссийский классификатор управленческой документации (ОКУД), утвержденным и введенным в действие постановлением Госстандарта РФ №299 от 30.12.1993г. 60 2.1.4 НЕДОСТАТКИ СУЩЕСТВУЮЩИХ СИСТЕМ ДОКУМЕНТАЦИИ Из изложенного в данном подразделе материала следует, что УСД создаются на государственном и отраслевом уровнях, а также на уровне предприятий и организаций. Главная цель создания УСД – это обеспечение сопоставимости показателей различных сфер производственных и управленческих процессов. С этой целью разработаны стандарты, где устанавливаются требования к: – унифицированным системам документации; – УФД различных уровней управления; – составу и структуре реквизитов и показателей; – порядку внедрения, ведения и регистрации унифицированных форм документов. С прогрессирующим усложнением характера и системы управления быстро растет и число управленческих документов. Обработка документов в таких системах занимает существенную часть времени работников, занятых в сфере управления. Поэтому, несмотря на существование УСД, при обследовании организаций постоянно выявляется целый комплекс типичных недостатков: – УСД содержит довольно большой объем документов для ручной обработки; – несмотря на проведение мероприятий по унификации показателей в документах одни и те же показатели часто дублируются в разных документах; – работа с большим количеством документов отвлекает специалистов от решения непосредственных задач; – система документов содержит в своем составе не используемые показатели и др. Поэтому устранение указанных недостатков является одной из задач, стоящих при создании ИО АС. 61 2.2 СИСТЕМА КЛАССИФИКАЦИИ И КОДИРОВАНИЯ ИНФОРМАЦИИ АС Автоматизация операций АС требует приведения множества показателей в единую целостную систему, установления их содержательного и терминологического единства (однозначности), а также четких взаимодействий между ними. Чтобы сделать эту информацию удобной для восприятия человеком и машиной, потребовалось создание специальных средств формализованного описания информации, называемых словарями и классификаторами [11]. 2.2.1 ОСНОВНЫЕ ПОНЯТИЯ СККИ Создание системы словарей и классификаторов вызвано тем обстоятельством, что некоторые реквизиты (а также показатели, реализованные на их основе), выявленные в ходе создания УСД, с одной стороны, имеют предопределенный набор значений, с другой стороны, могут быть использованы во множестве документов. В этом случае возникает проблема их однозначной интерпретации в разных документах, поэтому написание их наименований и значений в разных документах должно быть унифицировано. В некоторых случаях предопределенный набор значений реквизита может быть представлен в качестве признака (основания) классификации объектов. При этом также возникает проблема унификации наименований и значений реквизитов объектов при их использовании в разных документах. Примерами объектов, подлежащих классификации, могут являться реальные объекты, например, производственные подразделения, материально-технические ресурсы, промышленная продукция т.д. Классификации могут быть подвергнуты также процессы, например, операции по изготовлению продукции, конструкций и изделий, операции учета и т.д. Систематизация и классификация информации УСД связаны с разработкой кодов – условных обозначений значений и наименований реквизитов, а также наименований показателей и объектов, в состав которых входят эти реквизиты. Поэтому технология проектиро- 62 вания внемашинного информационного обеспечения включает в себя еще и процедуры кодирования информации. Процедуры классификации и кодирования информации реализуются в специально созданном компоненте информационного обеспечения, называемом системой классификации и кодирования информации (СККИ) и представляющем собой комплекс: – методов и правил классификации и кодирования информации, подлежащей автоматизированной обработке; – взаимоувязанных кодировочных словарей и классификаторов; – средств ведения классификаторов и кодировочных словарей. Кодировочным словарем называется нормативный документ, устанавливающий систематизированный перечень групп наименований и кодов объектов, принятый на соответствующем уровне стандартизации. Классификатором называется нормативный документ, устанавливающий систематизированный перечень групп наименований и кодов объектов классификации, принятый на соответствующем уровне стандартизации. При таком подходе описания (т.е. в словарях и классификаторах) реквизитов, показателей и объектов не зависимо от того, в каких документах они встречаются и каково их положение в документе, они всегда будут интерпретированы однозначно. Это позволяет утверждать, что система классификации и кодирования является частью языка, единого для всей системы информации АС, и позволяет описывать реквизиты, показатели и объекты с помощью содержательного кодирования. 2.2.2 КЛАССИФИКАТОРЫ И ИХ ВИДЫ Классификатор содержит наименования объектов, классификационных группировок и их кодовые обозначения и является документом, с помощью которого осуществляется формализованное описание информации в АС. По сфере действия выделяют следующие виды классификаторов: международные, общегосударственные, отраслевые и локальные классификаторы. 63 Международные классификаторы входят в состав системы международных экономических стандартов и обязательны для передачи информации между организациями разных стран. Общегосударственные классификаторы, обязательны для организации процессов передачи и обработки информации между экономическими системами государственного уровня внутри страны. Общегосударственные классификаторы (ОК), разрабатываемые в централизованном порядке, содержат в своем составе: – ОК промышленной и сельскохозяйственной продукции – ОКП; – ОК отраслей народного хозяйства – ОК ОНХ; – система обозначений органов государственного управления – СО ОГУ; – система обозначений административно-территориальных объектов – СО АТО; – ОК профессий и услуг; – ОК единиц измерений и др. Отраслевые классификаторы используют для выполнения процедур обработки информации и передачи ее между организациями внутри отрасли. Отраслевые классификаторы, единые для какой-то отрасли деятельности, разрабатываются в типовых проектах автоматизированной обработки. Локальные классификаторы используют в пределах отдельных предприятий. Локальные классификаторы, составляемые на номенклатуры, характерные для данного предприятия, банка, фирмы (коды табельных номеров, подразделений, банковских счетов и др.) и разрабатываются в ходе создания АС предприятий и организаций. 2.2.3 КЛАССИФИКАЦИЯ ИНФОРМАЦИИ Классификация – это разделение множества объектов на подмножества по их сходству или различию в соответствии с принятыми методами. Классификация фиксирует закономерные связи между классами объектов. Под объектом понимается любой предмет, процесс или явление. 64 При разработке словарей и классификаторов выполняются следующие работы: – определение и анализ рассматриваемого множества объектов; – группировка или классификация рассматриваемого множества объектов. Если в рассматриваемом множестве объектов выделяется всего одна группировка, то речь идет о словаре; – унификация написания наименований объектов; – кодирование рассматриваемого множества объектов. Таким образом, совокупность правил распределения объектов множества на подмножества называется системой классификации, обеспечивающей группировку объектов в определенных классах, характеризующихся рядом общих свойств. Свойство (или реквизит) объекта классификации, которое позволяет установить его сходство или различие с другими объектами классификации, называется признаком или основой классификации. Например, признак «роль предприятия-партнера» позволяет разделить все предприятия на две группы (на два подмножества): «поставщики» и «потребители». Множество или подмножество, объединяющее часть объектов классификации по одному или нескольким признакам, носит название классификационной группировки. Определение и анализ рассматриваемого множества объектов предусматривает определение границ множества объектов, подлежащих группировке или классификации, выявление их свойств и характеристик, связей и отношений, определение сходных и отличительных признаков объектов. Группировка рассматриваемого множества объектов заключается в сортировке их наименований в алфавитном порядке. Классификация рассматриваемого множества объектов предусматривает: – выделение признаков классификации; – определение необходимой и достаточной глубины классификации. При унификации написания наименований объектов проводится упорядочение применяемой терминологии (исключение многознач- 65 ности, синонимии) и проверка на соответствие стандартизованной терминологии. 2.2.3.1 С в о й с т в а к л а с с и ф и к а ц и и Каждая система классификации характеризуется следующими свойствами: – гибкостью системы; – емкостью системы; – степенью наполненности системы. Гибкость системы – это способность допускать включение новых признаков, объектов без разрушения структуры классификатора. Необходимая гибкость определяется временем жизни системы. Емкость системы – это наибольшее количество классификационных группировок, допускаемое в данной системе классификации. Степень наполненности системы определяется как частное от деления фактического количества группировок на величину емкости системы. 2.2.3.2 М е т о д ы к л а с с и ф и к а ц и и В настоящее время чаще всего применяются два типа систем классификации: иерархическая и многоаспектная. Иерархический метод классификации. При использовании иерархического метода классификации происходит «последовательное разделение множества объектов на подчиненные классификационные группировки». Суть иерархического метода классификации заключается в установлении между классификационными группировками иерархических отношений подчинения, с последовательной детализацией их свойств: класс, подкласс, группа, подгруппа, вид и так далее. На каждом уровне классификационное множество (подмножество) по некоторому признаку деления делится на классификационные подмножества следующего уровня. Получаемая на основе этого процесса классификационная схема имеет иерархическую структуру. В ней первоначальный объем классифицируемых объектов по какому-либо признаку разбивается на подмножества и детализируется на каждой следующей ступени 66 классификации. Обобщенное изображение иерархической классификационной схемы представлено на Рис. 2.1. 0-й уровень 1-й уровень 2-й уровень 3-й уровень Исходное множество Подмножества, выделенные по 1-му признаку Разделение подмножеств, выделенных на 1-м уровне, по 2-му признаку Разделение подмножеств, выделенных на 2-м уровне, по 3-му признаку Рис. 2.1 – Иерархическая классификационная схема Особенностями иерархической системы являются: – возможность использования неограниченного количества признаков классификации; – соподчиненность признаков классификации, что выражается разбиением каждой классификационной группировки, образованной по одному признаку, на множество классификационных группировок по нижестоящему (подчиненному) признаку. Таким образом, классификационные схемы, построенные на основе иерархического принципа, имеют неограниченную емкость, величина которой зависит от глубины классификации (числа ступеней деления) и количества объектов классификации, которое можно расположить на каждой ступени. Количество же объектов на ступенях классификации определяется основанием кода, то есть числом знаков в выбранном алфавите кода. Например, если алфавит – двузначные десятичные числа, то можно на одном уровне разместить 100 объектов. Выбор необходимой глубины классификации и структуры 67 кода зависит от характера объектов классификации и характера задач, для решения которых предназначен классификатор. При построении иерархической системы классификации сначала выделяется некоторое множество объектов, подлежащее классифицированию, для которого определяются полное множество признаков классификации и их соподчиненность друг другу, затем производится разбиение исходного множества объектов на классификационные группировки на каждой ступени классификации. К положительным сторонам данной системы следует отнести логичность, простоту ее построения и удобство логической и арифметической обработки. Серьезным недостатком иерархического метода классификации является жесткость классификационной схемы. Она обусловлена заранее установленным выбором признаков классификации и порядком их использования по ступеням классификации. Это ведет к тому, что при изменении состава объектов классификации, их характеристик или характера решаемых при помощи классификатора задач требуется коренная переработка классификационной схемы. Гибкость этой системы обеспечивается только за счет ввода большой избыточности в ветвях, что приводит к слабой наполненности структуры классификатора. Поэтому при разработке классификаторов следует учитывать, что иерархический метод классификации более предпочтителен для объектов с относительно стабильными признаками и для решения стабильного комплекса задач. Фасетная классификация. Недостатки, отмеченные в иерархической методе, отсутствуют в фасетном методе, который относятся к классу многоаспектных методов классификации. Многоаспектный метод – это метод классификации, который использует параллельно несколько независимых признаков (аспектов) в качестве основания классификации. Фасет – это признак классификации, используемый для образования независимых классификационных группировок. Под фасетным методом классификации понимается «параллельное разделение множества объектов на независимые классификационные группировки». Метод фасетной классификации основан на множестве независимых признаков. Набор таких признаков может 68 быть произвольным, что позволяет группировать объекты по любому сочетанию признаков. Фасетный метод является одноуровневым. При этом методе классификации заранее жесткая классификационная схема не создается. Разрабатывается лишь система таблиц признаков объектов классификации, называемых фасетами. При необходимости создания классификационной группировки для решения конкретной задачи осуществляется выборка необходимых признаков из фасетов и их объединение в определенной последовательности. Общий вид фасетной классификационной схемы представлен на Рис. 2.2. Значения фасетов Фасеты Ф1 Ф2 Ф3 Фi ... ... 1 ... ... 2 ... ... ... k ... ... ... ... ... ... ... Фn ... ... Рис. 2.2 – Схема признаков фасетной классификации Внутри фасета значения признаков могут перечисляться по некоторому порядку или образовывать сложную иерархическую структуру, если существует соподчиненность выделенных признаков. К преимуществам данной системы следует отнести большую емкость системы и высокую степень гибкости, поскольку при необходимости можно вводить дополнительные фасеты и изменять их место в формуле. При изменении характера задач или характеристик объектов классификации разрабатываются новые фасеты или дополняются новыми признаками существующие фасеты без коренной перестройки структуры всего классификатора. К недостаткам, характерным для данной системы, можно отнести сложность структуры и низкую степень наполненности системы. В современных классификационных схемах часто одновременно используются оба метода классификации. Это снижает влияние недостатков методов классификации и расширяет возможность использования классификаторов в ИО АС. 69 2.2.4 КОДИРОВАНИЕ ИНФОРМАЦИИ Для полной формализации информации недостаточно простой классификации, поэтому проводят следующую процедуру – кодирование. Основой для кодирования является классификация признаков в обозначении объектов. Полученные кодовые обозначения объектов могут использоваться для автоматизированного упорядочения и поиска объектов, обладающих заданными признаками. Другое назначение кодирования – это обеспечение уникальной идентификации объектов, которая в совокупности с принятой системой классификации четко определяет сущность объекта. Данная процедура особенно важна для этапа проектирования базы данных при выделении информационных объектов и структурных связей между ними. Кодирование – это процесс присвоения условных обозначений объектам и классификационным группам по соответствующей системе кодирования. Кодирование реализует перевод информации, выраженной одной системой знаков, в другую систему, то есть перевод записи на естественном языке в запись с помощью кодов. Код или шифр – это условное отображение информационного понятия (позиции). Он характеризует одно понятие или одну позицию множества с помощью символов (букв или цифр). Цель кодирования – представление информации в более компактной и удобной форме при записи ее на машинный носитель, приспособление к передаче по КС, упрощение логической обработки. Система кодирования применяется для замены названия объекта на какой-либо код. Код строится на основе использования букв и цифр. Кодирование рассматриваемого множества объектов предусматривает: – выбор алфавита и длины кода; – построение структуры кода; – кодирование объектов классификации, их группировок, признаков и характеристик; – обеспечение резервной емкости кодов классификатора. 70 2.2.4.1 С и с т е м а к о д и р о в а н и я Система кодирования – это совокупность правил обозначения объектов и группировок с использованием кодов. Код – это условное обозначение объектов или группировок в виде знака или группы знаков в соответствии с принятой системой. Код базируется на определенном алфавите (некоторое множество знаков). Число знаков этого множества называется основанием кода. Различают следующие типы алфавитов: цифровой, буквенный и смешанный. Код характеризуется следующими параметрами: – длиной; – основанием кодирования; – структурой кода, под которой понимают распределение знаков по признакам и объектам классификации; – степенью информативности, рассчитываемой как частное от деления общего количества признаков на длину кода; – коэффициентом избыточности, определяемым как отношение максимального количества объектов к фактическому количеству объектов. К методам кодирования предъявляются следующие требования: – код должен осуществлять идентификацию объекта в пределах заданного множества объектов классификации; – желательно предусматривать использование в качестве алфавита кода десятичных цифр и букв; – необходимо обеспечивать по возможности минимальную длину кода и достаточный резерв незанятых позиций для кодирования новых объектов без нарушения структуры классификатора. 2.2.4.2 М е т о д ы к о д и р о в а н и я Методы кодирования могут носить самостоятельный характер – регистрационные методы кодирования, или быть основанными на предварительной классификации объектов – классификационные методы кодирования (см. Рис. 2.3). Регистрационные методы кодирования бывают двух видов: порядковый и серийно-порядковый. 71 Порядковый метод кодирования. В порядковом методе кодирования кодами служат числа натурального ряда. Каждый из объектов классифицируемого множества кодируется путем присвоения ему текущего порядкового номера. Данный метод кодирования обеспечивает довольно большую долговечность классификатора при незначительной избыточности кода. Этот метод обладает наибольшей простотой, использует наиболее короткие коды и лучше обеспечивает однозначность каждого объекта классификации. Кроме того, он обеспечивает наиболее простое присвоение кодов новым объектам, появляющимся в процессе ведения классификатора. Существенным недостатком порядкового метода кодирования является отсутствие в коде какой-либо конкретной информации о свойствах объекта, а также сложность машинной обработки информации при получении итогов по группе объектов классификации с одинаковыми признаками. Системы кодирования Регистрационные Порядковая Серийная Классификационные Последовательные Серийная Разрядная Комбинированная Параллельные Серийная Разрядная Комбинированная Рис. 2.3 – Системы кодирования 72 Серийный метод кодирования отличается от порядкового тем, что номенклатура кодируемых объектов предварительно должна быть разбита на группировки по одному признаку. При этом каждой группировке должна быть отведена серия кодовых обозначений, в пределах которой каждому элементу присваивается свой код по порядку. Серия обозначений для каждой группировки определяется таким образом, чтобы после присвоения кодов элементам этой группы в ней оставались бы свободные номера на случай появления новых объектов. Классификационные коды используют для отражения классификационных взаимосвязей объектов и группировок и применяются в основном для сложной логической обработки экономической информации. Группу классификационных систем кодирования можно разделить на две подгруппы в зависимости от того, какую систему классификации используют для упорядочения объектов: системы последовательного кодирования и параллельного кодирования. Последовательные системы кодирования характеризуются тем, что они базируются на предварительной классификации по иерархической системе. Код объекта классификации образуется с использованием кодов последовательно расположенных подчиненных группировок, полученных при иерархическом методе кодирования. В этом случае код нижестоящей группировки образуется путем добавления соответствующего количества разрядов к коду вышестоящей группировки. Параллельные системы кодирования характеризуются тем, что они строятся на основе использования фасетной системы классификации и коды группировок по фасетам формируются независимо друг от друга. В параллельной системе возможны два варианта записи кодов объекта: 1. Каждый фасет и признак внутри фасета имеют свои коды, которые включаются в состав кода объекта. Такой способ записи удобно применять тогда, когда объекты характеризуются неодинаковым набором признаков. При формировании кода какого-либо объекта берутся только необходимые признаки. 73 2. Для определения групп объектов выделяется фиксированный набор признаков и устанавливается стабильный порядок их следования, то есть устанавливается фасетная формула. В этом случае не надо каждый раз указывать, значение какого из признаков приведено в определенных разрядах кода объекта. 2.2.5 ВЫБОР МЕТОДОВ КЛАССИФИКАЦИИ И КОДИРОВАНИЯ Наиболее сложными вопросами, которые приходится решать при разработке классификатора, являются выбор методов классификации и кодирования и выбор системы признаков классификации. Основой классификатора должны быть наиболее существенные признаки классификации, соответствующие характеру решаемых с помощью классификатора задач. При этом данные признаки могут быть или соподчиненными, или несоподчиненными: – при соподчиненных признаках классификации и стабильном комплексе задач, для решения которых предназначен классификатор, целесообразно использовать иерархический метод классификации, представляющий собой последовательное разделение множества объектов на подчиненные классификационные группировки; – при несоподчиненных признаках классификации и при большой динамичности решаемых задач целесообразно использовать фасетный метод классификации. Важным вопросом является также правильный выбор последовательности использования признаков классификации по ступеням классификации при иерархическом методе классификации. Критерием при этом является статистика запросов к классификатору. В соответствии с этим критерием на верхних ступенях классификации в классификаторе должны использоваться признаки, к которым будут наиболее частые запросы. По этой же причине на верхних ступенях классификации выбирают наименьшее основание кода. 2.3 НОРМАТИВНО-СПРАВОЧНАЯ ИНФОРМАЦИЯ Как само собой разумеющееся воспринимается то, что во всем мире приняты и действуют единые правила дорожного движения. 74 Имеются, разумеется, некоторые национальные различия, но они касаются в основном санкций за нарушение этих правил, связанных с действующим законодательством. Не будь этих правил дорожного движения, общество погрузилось бы в хаос с катастрофическими последствиями [12]. Практически полной формальной аналогией с правилами движения транспортных средств является регламентация поведения социальных структур. Базисом для формирования этих правил становятся международные соглашения, в том числе в рамках ВТО, и соглашения в рамках региональных экономических организаций, таких как Таможенный и Европейский союз, стандарты ведомств и предприятий. Формирование правил, регламентирующих поведение социальных систем, связано с переходом национальных экономик на использование международных стандартов, классификаций и межгосударственных соглашений, регламентирующих нормы и правила экономического поведения. Единые для мирового сообщества нормативные документы составляют основу формирования поведения взаимодействующих субъектов всех видов деятельности. Для этого каждому хозяйствующему субъекту необходимо владеть требуемым для его экономической деятельности набором нормативно-справочной информации (НСИ). По этой причине НСИ занимает важное место в ИО АС и представляет систему нормативов, характеризующих количественную меру различных элементов процесса производства. НСИ автоматизируемого предприятия является важной частью ИО АС, и именно в ней закладывается научная обоснованность и комплексность управления предприятием. Нормативные массивы, зафиксированные на машинных носителях, составляют нормативную базу АС, т.е. ее нормативное хозяйство представляет собой размещенный на носителях информации систематизированный комплекс сведений и данных, обеспечивающих решение задач по управлению социальной системой. Норматив − это количественная и качественная характеристика управления, показывающая, каковы его нормальные параметры при 75 данном уровне развития производства. Применительно к предприятию нормативы должны выражать зависимость отдельных показателей его деятельности от технических и экономических условий. Норма − это первичный количественный норматив, полученный на предприятии путем проведения технического расчета, или установленный извне в качестве исходного. Нормы представляют собой входную информацию низкого уровня и выражаются в единицах физических величин. В базовое ИО также входят справочники. Справочник − это перечень данных, однозначно характеризующих состояние объекта на определенный период времени и позволяющих выделить этот объект из множества других. Перечисленные сведения (нормативы, нормы и справочные данные) представлены на машинных носителях информации и являются исходными данными при решении задач АС. Для этого нормы должны быть едиными для всех расчетов, проводимых на предприятии. Использование единых норм для расчетов, выполняемых с помощью АС, обеспечивается в результате централизованного формирования и обновления в памяти машины массивов НСИ. Такие массивы называются фондом НСИ. Фонд НСИ является составной частью ИО АС и представляет собой совокупность норм, нормативов, а так же условно-постоянных справочных и условных показателей, отражающих относительно устойчивые свойства объектов и явлений деятельности социальной системы. 2.4 ПРИМЕР РАЗРАБОТКИ ВНЕМАШИННОГО ИО Конечной целью разработки ИО АС, реализованного на основе БД, является создание массивов информации на машинных носителях, и их использование ДЛ (с помощью языковых средств) для принятия решений. Для этого необходимо: – ясное понимание целей, задач и функций системы управления моделируемой социальной системы; – изучение и совершенствование системы документооборота (включая документы нормативно-справочного характера); 76 – наличие и использование системы классификации и кодирования, обеспечивающей однозначное кодирование и именование реквизитов, используемых в документах; – владение методологией создания концептуальных информационно-логических моделей, отражающих взаимосвязь информации, выявленную на предыдущих этапах разработки внутримашинного ИО; – создание массивов информации на машинных носителях, что требует наличия современного технического обеспечения. 2.4.1 МЕТОДОЛОГИЯ РАЗРАБОТКИ ИО АС Разработка ИО АС осуществляется путем последовательной разработки внемашинного и внутримашинного ИО на основе методологии, базирующейся на многолетнем практическом опыте разработки АС, теоретических основах структурирования информации документов (см. разд. 1.3) и реляционной модели данных. На этапе разработки внемашинного ИО осуществляется обследование моделируемой социальной системы с целью: – изучения специфики и структуры ее деятельности; – анализа существующей системы документооборота и выявления реквизитов и показателей циркулирующих в нем документов и разработки системы УФД; – определения информационных объектов, описанных в документах моделируемой социальной системы, состава их реквизитов и показателей. – классификации объектов общего применения; – документирования полученных результатов. В результате выполнения перечисленных работ разрабатывается внемашинное ИО АС, состоящее из УСД, СККИ и НСИ. Базовым компонентом внемашинного ИО является УСД, на основе которой создаются все остальные компоненты ИО. Поэтому после определения УСД каждый ее документ подвергается анализу с целью выявления сущностей ПрО путем определения реквизитов и показателей документа. 77 Из выявленных сущностей ПрО выделяются кодовые, задающие область определения для значений атрибутов, принадлежащих другим сущностям. Для каждой такой сущности создается и утверждается документ, в котором определяется назначение сущности, состав ее реквизитов и номенклатура значений с указанием кода и наименования для каждого значения. Система таких документов определяет СККИ внемашинного ИО. Далее из документов УСД выделяются документы, содержащие информацию справочного и нормативного характера. Совокупность таких документов, среди которых могут быть как формализованные, так и не формализованные документы, составляет НСИ внемашинного ИО. Детали данного этапа методологии разработки ИО АС будут подробно описаны в последующих подразделах 2.4.3, 2.4.4, 2.4.5 данного раздела на примере разработки внемашинного ИО ПрО «Учебный процесс» (описание ПрО см. в подразделе 2.4.2). На этапе разработки внемашинного ИО осуществляется построение концептуальной информационно-логической схемы данных для обследованной на предыдущем этапе сферы деятельности, т.е. ПрО «Учебный процесс». В этой модели должны быть выявлены и оптимизированы все связи между объектами и их реквизитами, описанных в документах анализируемой системы. При этом сначала выявляются связи между объектами, описанными внутри отдельных документов, а затем – связи между объектами, представленными в разных документах. В результате выполнения второго этапа процесса разработки ИО АС формируется информационно-логическая модель ПрО, на основе которой будет создана БД. Детали второго этапа методологии построения БД представлены в Главе 3 на примере разработки внутримашинной ИБ для ПрО «Учебный процесс». 2.4.2 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ «УЧЕБНЫЙ ПРОЦЕСС» Приведем краткое описание фрагмента учебного процесса в части планирования занятий и тестирования студентов по окончании запланированных занятий [17]. Рассмотрим процедуру разработки 78 ИО АС, реализованной с целью автоматизации описанного учебного процесса в вузе на основе заданной системы документации учебного процесса. Определим требования к создаваемой системе, в соответствии с которыми пользователь должен иметь возможность ввести, обновлять, а также получать следующую информацию о ходе учебного процесса текущего семестра: – списки студентов групп; – преподавательский состав кафедр, обеспечивающих учебный процесс; – сведения о лекционных и практических занятиях по изучаемым предметам в каждой из групп; – результаты сдачи экзаменов (зачетов) студентов групп по изучаемым предметам. Для обеспечения создаваемой системы указанной информацией в ее БД должны храниться и обновляться данные о (об): – группах студентов учебного заведения; – студентах учебного заведения с указанием групп, в которых они обучаются; – кафедрах учебного заведения; – преподавательском составе кафедр учебного заведения; – предметах, изучаемых студентами, с указанием преподавателей, ведущих занятия; – учетных данных о занятиях, проводимых в группах; – успеваемости студентов групп по всем изучаемым предметам и видам занятий за текущий семестр. 2.4.3 ОПРЕДЕЛЕНИЕ УСД ВНЕМАШИННОГО ИО В ходе консультации с работниками учебного заведения определяется перечень документов, содержащих перечисленную в техническом задании информацию. Системы документации для предприятий и организаций создаются на государственном, региональном и отраслевом уровнях, поэтому будем считать, что УСД учебного заведения уже создана, в которой определены УФД для всех документов. 79 Поэтому будем исходить из того, что один из компонентов внемашинного ИО уже определен и им является УСД предметной области «Учебный процесс». Для демонстрации процедуры анализа ПрО рассмотрим документы, вырабатываемые в ходе реализации учебного процесса текущего семестра на кафедре. Унифицированные формы этих документов уже определены и будут описаны ниже. В первую очередь, путем анализа системы документов ПрО выявляем документы двух типов: документы со справочной информацией («Список студентов групп», «Список преподавателей кафедры»), описывающие состояния объектов, и документы учетной информации («План проведения занятий в группе», «Экзаменационная ведомость»), описывающие процессы, реализуемые в автоматизируемой ПрО. Документы со справочной информацией содержат: – «Список студентов групп» – описания групп и студентов, обучающихся в их составе; – «Список преподавателей кафедры» – описания преподавателей и кафедр, в которых они работают. Рассматриваемый учебный процесс включает в себя два вида деятельности: – организация учебного процесса путем проведения занятий по изучаемым предметам – описывается документом «План проведения занятий в группе»; – тестирование студентов путем проведения зачетов и экзаменов после окончания изучения предметов – описывается документом «Экзаменационная ведомость». Документы данного подраздела по своей структуре сложнее справочных документов, так как описывают не только относительно статичные сущности-объекты, но и сущности-процессы, которые в силу своей природы имеют множественные связи с объектами, реализующими эти процессы. Поэтому анализ таких документов требует не только рассмотрения собственно процессов, но и описания или указания на объекты, имеющие отношение к описываемому процессу. 80 Основной целью анализа документов ПрО «Учебный процесс» является выявление информационных объектов с указанием их реквизитного состава. Реквизитный состав документа используется для последующего машинного представления его данных. Порядок выявления реквизитов, показателей, составленных из реквизитов, и информационных объектов документа, представленных показателями, был подробно описан в подразделе 1.3.3. Поэтому в нижеследующем тексте эти подробности не будут повторяться, а будут приведены только перечни информационных объектов с указанием их показателей и реквизитного состава. Анализ наименований реквизитов документов рассматриваемой ПрО показывает, что нередко реквизиты, имеющие одинаковый смысл, в разных документах именуются по-разному. При бумажном документообороте это не приводит к большим проблемам, так как возможности человеческого интеллекта позволяют легко установить их идентичность. Возможности машин в этом плане гораздо скромнее, поэтому требуется унифицировать наименования таких реквизитов с целью их однозначной идентификации при автоматизированной обработке. В некоторых случаях наименования реквизитов, используемые в бумажных документах, могут не соответствовать требованиям стандартов именования элементов данных в информационных языках. Например, в языке XML не допускается наименование тегов «№ студента». Поэтому по ходу анализа реквизитного состава документов ПрО «Учебный процесс» при необходимости будем заменять такие наименования чтобы: – реквизиты разных документов, имеющих одинаковый смысл, именовались единообразно; – наименования реквизитов не противоречили требованиям их машинного представления. 2.4.3.1 Д о к у м е н т «С п и с о к с т уд е н т о в г р уп п » Унифицированная форма документа «Список студентов групп» со справочной информацией приведена на Рис. 2.4. 81 Список студентов группы № _______ № студента Фамилия И.О. Год рождения Адрес Прох. балл Рис. 2.4 – УФД со списком студентов Описание объекта СТУДЕНТ. В этом документе явно заданы следующие реквизиты объекта СТУДЕНТ: «№ студента», «Фамилия И.О.», «Год рождения», «Адрес» и «Прох. балл». Анализируя смысл перечисленных реквизитов, определяем реквизит «№ студента» как реквизит-признак, а остальные – как реквизиты-основания. Наименование «№ студента» заменим на «Ном. студ.» в соответствии с требованиями стандарта машинного представления информации. Также изменим наименование «Фамилия И.О.» на «ФИО студ.». Причина такого переименования заключается в том, что исходное наименование, используемое для обозначения студентов, в других документах используется для именования преподавателей. С учетом описанных изменений определим показатели, описывающие объект СТУДЕНТ: – «Ном. студ.» | «ФИО студ.»; – «Ном. студ.» | «Год рождения»; – «Ном. студ.» | «Адрес»; – «Ном. студ.» | «Прох. балл». Каждое значение реквизита-признака «Ном. студ.» определяет совокупность значений реквизитов-оснований, характеризующих некоторый экземпляр объекта СТУДЕНТ. Отсюда следует вывод, что реквизиты-признаки и зависящие от него реквизиты-основания однозначно определяют экземпляры объекта, следовательно, и объект в целом. Поэтому для машинного представления состава показателей объекта сформируем реквизитный состав объекта по следующему правилу: 82 – реквизит-признак и зависящие от него реквизиты-основания, формируют реквизитный состав объекта; – в реквизитном составе объекта общий реквизит-признак представляется идентификатором значений реквизитов-оснований данной группы показателей в одном экземпляре; В соответствии с приведенным правилом сформируем реквизитный состав объекта СТУДЕНТ для представления в машинной памяти, который имеет вид: – «Ном. студ.» – реквизит-признак; – «ФИО студ.» – реквизит-основание; – «Год рождения» – реквизит-основание; – «Адрес» – реквизит-основание; – «Прох. балл» – реквизит-основание. Описание объекта ГРУППА. По рассматриваемому документу можно определить еще один объект ГРУППА, для которого явно определен только реквизит «Группа №». В документах «План проведения занятий в группе» и «Экзаменационная ведомость» этот реквизит имеет наименование «Группа», поэтому этот вариант примем в качестве унифицированного, применяемого во всех документах. Еще два реквизита этого объекта в документе заданы неявно и определяются путем логических выводов: – по документу можно определить количество обучаемых в ней студентов и соответствующий реквизит «Кол-во студ.» для записи его значений; – просуммировав значения поля «Баллы» таблицы и поделив эту сумму на количество студентов, можно определить средний балл студентов группы при поступлении, т.е. реквизит «Средн. балл». Аналогично предыдущему случаю определим характер выделенных реквизитов: реквизит «Группа» представляет собой реквизит-признак, а реквизиты «Кол-во студ.» и «Средн. балл» – реквизиты-основания. С учетом этих данных определим показатели, описывающие объект ГРУППА: – «Группа» | «Кол-во студ.»; – «Группа» | «Средн. балл». 83 Реквизитный состав объекта ГРУППА для представления в машинной памяти имеет вид: – «Группа» – реквизит-признак; – «Кол-во студ.» – реквизит-основание; – «Средн. балл» – реквизит-основание. 2.4.3.2 Д о к у м е н т «С п и с о к п р е п о д а в а т е л е й кафедры» Унифицированная форма документа «Список преподавателей кафедры» со справочной информацией приведена на Рис. 2.5. Этот список аналогичен предыдущему, и по нему также можно определить не только сведения о преподавателях, но и о кафедрах. Таким образом, этот документ содержит сведения о двух объектах предметной области: КАФЕДРА и ПРЕПОДАВАТЕЛЬ. Список преподавателей кафедры Название кафедры _____________________________________ Код кафедры ________________ Телефон _________________ Заведующий _________________________________________ Таб. № Фамилия И.О. Год рождения Ученая степень Ученое звание Рис. 2.5 – УФД со списком преподавателей Описание объекта КАФЕДРА. Объект КАФЕДРА определяется следующими атрибутами: «Кафедра» – реквизит-признак, а «Назв. кафедры», «Заведующий» и «Телефон» – реквизиты-основания. Показатели, описывающие объект КАФЕДРА приведены в нижеследующем списке: – «Кафедра» | «Назв. кафедры»; – «Кафедра» | «Заведующий»; – «Кафедра» | «Телефон». 84 Реквизитный состав объекта КАФЕДРА для представления в машинной памяти имеет вид: – «Кафедра» – реквизит-признак; – «Назв. кафедры» – реквизит-основание; – «Заведующий» – реквизит-основание; – «Телефон» – реквизит-основание. Описание объекта ПРЕПОДАВАТЕЛЬ. Также легко определяются реквизиты объекта ПРЕПОДАВАТЕЛЬ: «Таб. №» – реквизит-признак, а реквизиты «ФИО_преп.», «Год рождения», «Уч. степень» и «Уч. звание» – реквизиты-основания. С целью унификации наименований реквизитов рассматриваемой УСД изменим «Таб. №» на «Таб. ном.», а «Фамилия И.О.» на «ФИО преп.» Объект ПРЕПОДАВАТЕЛЬ представлен следующим перечнем показателей: – «Таб. ном.» | «ФИО_прп.»; – «Таб. ном.» | «Год рождения»; – «Таб. ном.» | «Уч. степень»; – «Таб. ном.» | «Уч. звание». Реквизитный состав объекта ПРЕПОДАВАТЕЛЬ для представления в машинной памяти имеет вид: – «Таб. ном.» – реквизит-признак; – «ФИО преп.» – реквизит-основание; – «Год рождения» – реквизит-основание; – «Уч. степень» – реквизит-основание; – «Уч. звание» – реквизит-основание. 2.4.3.3 Д о к у м е н т «П л а н п р о в е д е н и я з а н я т и й в г р уп п е » Документ «План проведения занятий в группе» для заданной группы на текущий семестр содержит: – перечень изучаемых предметов; – виды занятий по каждому изучаемому предмету; – для каждого вида занятий указаны данные о преподавателях; – количество часов по каждому виду занятий (см. Рис. 2.6). 85 План проведения занятий в группе Группа № ____________________ Семестр _______________/текущий/ Код предм. Назв. предмета Фамилия И.О. Таб. № Вид занятия Часы Рис. 2.6 – УФД с перечнем предметов по видам занятий Исходя из этого, в данном документе можно выделить два объекта – это объект ГРУППА-СЕМЕСТР, сокращенно ГС, и ПЛАН. Описание объекта ГС. Объект ГС представляет собой сочетания групп и семестров, для которых составляются планы проведения занятий. Таким образом, каждый экземпляр объекта ГС идентифицируется: – группой, – семестром. Следует отметить, что объект ГС является искусственным образованием, используемым для удобства доступа к элементам объекта ПЛАН, описываемого ниже. Реквизитный состав этого объекта представлен двумя реквизитами-признаками: – «Группа» – реквизит-признак; – «Семестр» – реквизит-признак. Конечной целью анализа реквизитного состава документов ПрО является составление концептуальной схемы, а затем схемы реляционной БД, в которой реквизиты-признаки используются для составления первичных и вторичных ключей. В данном случае мы получили составной реквизит-признак, который может быть использован для составления ключевых атрибутов БД. Работа с составными ключами усложняет алгоритмы их обработки и требует больших вычислительных ресурсов. Поэтому, по возможности стараются заменить их искусственными ключами, в качестве которых, как правило, применяются просто порядковые номера. 86 В соответствии с описанным приемом введем для объекта ГС искусственный ключ «Ном_ГС» и определим его в качестве реквизита-признака. В модифицированном варианте объекта ГС получаем следующие показатели: – «Ном_ГС» | «Группа»; – «Ном_ГС» | «Семестр». Реквизитный состав объекта ГС для представления в памяти машины имеет вид: – «Ном_ГС» – реквизит-признак; – «Группа» – реквизит-основание; – «Семестр» – реквизит-основание. Описание объекта ПЛАН. Для каждого сочетания значений реквизитов «Группа» и «Семестр» составляется план, описание которого было приведено выше. В соответствии с этим описанием определим следующий реквизитный состав объекта ПЛАН: реквизит-признак «Ном_плн» и реквизиты-основания «Предмет», «Вид_ занятия», «Вид_сдачи», «Часы», «ФИО_прп». Таким образом, объект ПЛАН описывается показателями: – «Ном_плн» | «Предмет»; – «Ном_плн» | «Вид_занятия»; – «Ном_плн» | «Вид_сдачи»; – «Ном_плн» | «Часы»; – «Ном_плн» | «ФИО_прп». В соответствии с этим описанием определим реквизитный состав объекта ПЛАН: – «Ном_плн» – реквизит-признак; – «Предмет» – реквизит-основание; – «Вид_занятия» – реквизит-основание; – «Вид_сдачи» – реквизит-основание; – «Часы» – реквизит-основание; – «ФИО_прп» – реквизит-основание. Относительно приведенного состава реквизитов объекта ПЛАН необходимо привести следующие пояснение, т.к. в нем, с одной стороны, содержатся отсутствующие в УФД документа реквизиты 87 «Ном_плн» и «Вид_сдачи», с другой стороны, отсутствует реквизит «Таб_ном», который представлен в УФД: – реквизит «Ном_плн» введен искусственно по тем же соображениям, что и реквизит «Ном_ГС», т.е. для того, чтобы заменить составной реквизит-признак «Предмет»-«Вид занятия», для идентификации экземпляра объекта ПЛАН; – реквизит «Вид_сдачи» введен с учетом его применения в документе «Экзаменационная ведомость», описываемом ниже. Объясняется это тем, что вид тестирования по каждому виду занятия определяется на этапе планирования, а не при тестировании; – исключение из состава реквизитов табельного номера преподавателя объясняется тем, что в объекте ПРЕПОД для каждого «ФИО_прп» табельные номера уже определены, и повторное определение этого реквизита в объекте ПЛАН при наличии интегрированной БД ПрО является избыточным. 2.4.3.4 Д о к у м е н т «Э к з а м е н а ц и о н н а я в е д о м о с т ь » По окончании семестра по каждому виду занятий и изучаемому в заданном семестре определенной группой проводится тестирование. При этом вид тестирования зависит от вида занятий. Например, по лекционным занятиям проводится экзамен, в рамках которого знания студентов оценивается по пятибалльной шкале, а по лабораторным занятиям проводится зачет, в рамках которого знания студентов оценивается по двухбалльной шкале (зачет/незачет). Сведения об итоговых результатах по учебному процессу за семестр представляются в экзаменационных ведомостях, заполненных в каждом семестре, для каждой группы, по каждому предмету и виду занятий (см. Рис. 2.7). По аналогии с анализом документа «План проведения занятий в группе», в данном документе также следует описать перечень объектов реализующих процесс тестирования. В качестве таких объектов определяются: ВЕДОМОСТЬ и ОЦЕНКА. Описание объекта ВЕДОМОСТЬ. При анализе данного документа следует иметь в виду, что каждый экземпляр объекта ПЛАН задает один экземпляр объекта ВЕДОМОСТЬ и связан с одним эк88 земпляром объекта ГС. Это означает, что при определении реквизитного состава объекта ВЕДОМОСТЬ нецелесообразно вводить реквизиты «Группа», «Семестр», представленные в объекте ГС, и реквизиты «Предмет», «Вид_сдачи», «ФИО_прп», представленные в объекте ПЛАН, а используя описанные связи типа «1:1» между объектами ГС, ПЛАН и ВЕДОМОСТЬ, привлекать их из этих объектов. Экзаменационная ведомость № Название предмета ______________________ Группа _______ Преподаватель __________________ Вид сдачи ____________ Семестр ________________________ Дата ________________ № пп ФИО студента Оценка Подпись преподавателя Рис. 2.7 – УФД «Экзаменационная ведомость» С учетом изложенного объект ВЕДОМОСТЬ описывается одним показателем – «Номер» | «Дата», а реквизитный состав объекта ВЕДОМОСТЬ для представления в машинной памяти имеет вид: – «Ном_вдм» – реквизит-признак; – «Дата» – реквизит-основание. Объект ОЦЕНКА. Для каждой ведомости определяется список студентов группы с оценками по тестируемому предмету и виду занятий, представленный в структуре документа объектом ОЦЕНКА. В соответствии с УФД (см. Рис. 2.7) каждый экземпляр объекта ОЦЕНКА определяется реквизитом-признаком «Ном_оц» и описывается реквизитами-основаниями «ФИО_стд», «Оценка» и «Подп_ прп», т.е. показателями: – «Ном_оц» | «ФИО_стд»; – «Ном_оц» | «Оценка»; – «Ном_оц» | «Подп_прп». 89 Реквизитный состав объекта ОЦЕНКА для представления в машинной памяти имеет вид: – «Ном_оц» – реквизит-признак; – «ФИО_стд» – реквизит-основание; – «Оценка»– реквизит-основание; – «Подп_прп» – реквизит-основание. 2.4.4 РАЗРАБОТКА СЛОВАРЕЙ И КЛАССИФИКАТОРОВ Сущности внемашинного ИО разделяются на главные и кодовые. К главным (первичным или основным) сущностям относятся так называемые стержневые сущности, представляющие наиболее важные объекты предметной области. Именно эти сущности, выделенные в предыдущем подразделе, составляют ядро предметной области, а остальные типы сущностей играют вспомогательную роль, описывая их аспекты. Одной из таких категорий сущностей ПрО составляют кодовые сущности, часто называемые словарями или классификаторами. Уникальные экземпляры, представляемые кодовыми сущностями, задают области определения для значений атрибутов, принадлежащих другим сущностям. Эти области определения зависят от характера или типа данных атрибутов, задающих диапазоны их значений. В некоторых случаях этот диапазон задается ограниченным перечнем значений и представляется кодовыми сущностями. Другими словами, если реквизит главной сущности имеет фиксированный перечень значений, то формируется кодовая сущность. Как правило, кодовые сущности описываются полями: «Код», «Наименование» (в некоторых случаях в состав полей кодовой сущности включают поле «Полное наименование»). Если для кодирования экземпляров кодовой сущности используется регистрационный метод кодирования, то кодовая сущность называется словарем. При использовании классификационного метода кодирования кодовая сущность называется классификатором. Кодовые сущности могут использоваться одновременно несколькими главными сущностями. По этой причине словари и классификаторы часто совместно используются многими базами данных, что 90 обеспечивает целостный подход к формированию главных сущностей, атрибуты которых определяются областью значений, описываемых словарями и классификаторами. Поясним назначение кодовых сущностей на примере. В предыдущем подразделе был описан объект (главная сущность) ГРУППА. Реквизит «Группа» этого объекта используются в других сущностях, в частности – в объектах ПЛАН, ИЗУЧЕНИЕ и ТЕСТИРОВАНИЕ. Это может привести к рассогласованию в написании их наименований и кодов в этих сущностях. Поэтому для реквизитов общего пользования вводятся кодовые сущности, содержащие их унифицированные коды и наименования, используемые и единообразно понимаемые во всех сущностях. Пример кодовой сущности «К_Группа» приведен в таблице 2.1. Таблица 2.1. Словарь «К_Группа» Код Наименование 1 ИВТВМбд-11 2 ИВТАПбд-11 4 ........... 8 ИВТВМбд-41 8 ИВТАПбд-41 Определим остальные кодовые сущности для рассматриваемой ПрО. По документу «Список преподавателей кафедр» (см. Рис. 2.5), определяем кодовую сущность «К_Кафедра». Пример кодовой сущности «К_Кафедра» с номенклатурой наименований и кодов приведен в таблице 2.2. Таблица 2.2. Словарь «К_Кафедра» Код Наименование Полное наименование 1 ВТ Вычислительная техника 2 АП Авиаприборостроение 3 ИС Информационные системы 91 В документе «Список преподавателей кафедр» представлена таблица, содержащая в числе прочих столбцы «Уч. степень» и «Уч. звание». Эти реквизиты характеризуются тем, что имеют ограниченный и четко очерченный перечень возможных значений. Определим для них соответственно кодовые сущности «К_Уч. степень» и «К_Уч. звание», примеры которых приведены в таблицах 2.3 и 2.4. Таблица 2.3. Словарь «К_Уч. степень» Код Наименование 1 д.т.н. 2 к.т.н. Таблица 2.4. Словарь «К_Уч. звание» Код Наименование 1 Доцент 2 Профессор По документу «План проведения занятий в группе» (см. Рис. 2.6) определим кодовые сущности: – «К_Вид занятия» – для хранения значений реквизита «Вид занятия» (см. таблица 2.5); – «К_Семестр» – для представления значений реквизита «Семестр» (см. таблица 2.6). Таблица 2.5. Словарь «К_Вид занятия» Код Наименование 1 Лекция 2 Практическая работа 3 Лабораторная работа 4 Курсовая работа 92 Таблица 2.6. Словарь «К_Семестр» Код Наименование 1 первый ... ........... 8 восьмой Путем анализа документа «Экзаменационная ведомость» (см. Рис. 2.7) легко определяем, что для его заполнения мы можем использовать значения из других сущностей. Например, для заполнения реквизита: – «Назв. предмета» можно использовать значение реквизита «Назв. предмета» объекта ПРЕДМЕТ; – «Группа» – значение реквизита «Наименование» кодовой сущности «К_Группа»; – «Преподаватель» – значение реквизита «Фамилия ИО» объекта ПРЕПОДАВАТЕЛЬ; – «ФИО студента» – значение реквизита «Фамилия ИО» объекта СТУДЕНТ. Реквизит «Дата» представляется текущей датой и вводится пользователем при заполнении ведомости, атрибут «Подпись преподавателя», представляющий собой электронную подпись, также вводится пользователем после ввода значения реквизита ОЦЕНКА для каждого студента. Поэтому кодовые сущности для этих реквизитов не определяются. Остается определить кодовые сущности «К_Вид сдачи» и «К_Оценка» для реквизитов «Вид сдачи» и ОЦЕНКА, примеры которых приведены в таблицах 2.7 и 2.8. Таблица 2.7. Словарь «К_Вид сдачи» Код Наименование 1 Экзамен 2 Зачет 3 Курсовая работа 93 Таблица 2.8. Словарь «К_Оценка» Код Наименование 1 Не явился 2 Не удовлетворительно 3 4 Удовлетворительно Хорошо 8 Отлично Следующая группа кодовых сущностей («К_ФИО_Преп», «К_ ФИО_Студ», «К_Предм»), строго говоря, таковыми не являются, но они могут быть полезны для облегчения ввода данных, предоставляя пользователю возможность выбора необходимого значения вместо набора строк в поля ввода. Примеры этих кодовых сущностей приведены в таблицах 2.9, 2.10 и 2.11. Таблица 2.9. Словарь «К_ФИО_Преп» Код Наименование 1 Нилов В.Н. 2 3 Петров И.П. Устинов Н.В. ......... 15 Федоров О.Г. Таблица 2.10. Словарь «К_ФИО_Студ» Код Наименование 1 Антипов В.Р. 2 Горлов Б.Н. 3 Ильин М.К. ......... 31 Яковлев Б.П. 94 Таблица 2.11. Словарь «К_Предм» Код Наименование 1 БД 2 3 ИО АС ПО АС ......... 22 ФС Для каждой из кодовых сущностей составляется и утверждается документ, описывающий назначение кодовой сущности, структуру представляемой информации в виде перечня ее реквизитов (обычно это «Код» и «Наименование»), номенклатуру экземпляров сущности (строки таблицы со значениями). Описанная совокупность документов представляет собой СККИ внемашинного ИО, и является обязательной для применения разработчиками БД на этапе разработки внутримашинного ИО. 2.4.5 ОПРЕДЕЛЕНИЕ НСИ НСИ внемашинного ИО представляется документами нормативного и справочного характера. Поэтому для определения данной составляющей внемашинного ИО вновь обратимся к описанной выше УСД и выделим нее из документы, содержащие такого рода информацию. Как уже было определено в подразделе 2.4.3.1, таковыми являются документы «Список студентов групп», «Список преподавателей кафедры». Перечисленные документы составляют НСИ внемашинного ИО для рассматриваемой предметной области и являются основанием для реализации внутримашинной НСИ. В какой-то степени СККИ также можно рассматривать как нормативную информацию. Поэтому в некоторых случаях НСИ и СККИ объединяются и представляются как НСИ АС. 95 КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Дайте описание и определение унифицированной системы документации АС. 2. Опишите цели унификации и стандартизации документов. 3. Опишите общероссийский классификатор управленческой документации. 4. Опишите порядок создания УСД АС. 5. Дайте определение УФД. 6. Опишите главные и кодовые сущности. 7. Охарактеризуйте недостатки существующих систем документации. 8. Дайте описание и определение системы классификации и кодирования информации АС. 9. Опишите порядок создания словарей и классификаторов. 10. Опишите понятие «классификация». 11. Опишите понятие «кодирование». 12. Опишите методы классификации. 13. Опишите методы кодирования. 14. Опишите этапы разработки классификаторов АС. 15. Дайте описание и определение нормативно-справочной информации АС. 16. Дайте определения понятий: норматив, норма и справочник. 96 Внутримашинное ИО – это система специальным образом организованных данных, подлежащих автоматизированной обработке, накоплению, хранению, поиску, передаче в виде, удобном для восприятия техническими средствами. Источником для формирования внутримашинного ИО служат данные внемашинного ИО, компоненты которого были рассмотрены в разделах предыдущей главы. Внутримашинное ИО содержит массивы данных, формирующие информационную базу системы на машинных носителях, а также систему программ организации, накопления, ведения и доступа к информации этих массивов. 3.1 ОСНОВНЫЕ ПОНЯТИЯ ВНУТРИМАШИННОГО ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ Внутримашинное ИО АС состоит из разнообразных по содержанию, назначению, организации файлов и информационных связей между ними и связано с хранением, поиском и обработкой информации, содержащейся в этих файлах. Оно включает все виды специально организованной на машинных носителях информации АС, предназначенной для восприятия, передачи и обработки техническими средствами. 97 3.1.1 НАЗНАЧЕНИЕ И ТРЕБОВАНИЯ К ВНУТРИМАШИННОМУ ИО Назначение внутримашинного ИО. Внутримашинное ИО АС предназначено для быстрого и удобного удовлетворения информационных потребностей всех пользователей информационных технологий. Требования к внутримашинному ИО. При выборе рационального варианта организации внутримашинного ИО, наиболее полно отражающего специфику объекта управления, предъявляются следующие требования: – полноты представления данных; – независимости структуры массивов от использующих их программных средств; – динамичности структуры информационной базы; – быстроты и надежности при выполнении операций по поиску, обработке и представлению данных для пользователя. 3.1.2 СПОСОБЫ ОРГАНИЗАЦИИ ВНУТРИМАШИННОГО ИО Основной частью внутримашинного обеспечения является информационная база – специальным образом организованная совокупность данных, хранимая в памяти машины. Данные во внутримашинном ИО могут храниться двумя способами в виде: – совокупности локальных файлов, поддерживаемых функциональными пакетами прикладных программ. Файл представляется совокупностью однородных по структуре записей, состоящих из набора полей заданного формата; – интегрированной базы данных, основанной на использовании универсальных программных средств загрузки, поиска и обработки данных, представляющих собой системы управления базами данных. Для управления данными, организованными в виде совокупности локальных файлов используются средства файловой системы, а для управления данными, хранимыми в интегрированных базах данных, – системы управления базами данных (СУБД), представляю- 98 щие собой совокупность языковых и программных средств, предназначенные для создания, ведения и совместного использования БД многими пользователями. В современных системах ИО, организованные в виде совокупности локальных файлов, практически не используются. Краткое описание данного способа реализации ИО в части их достоинств и недостатков приведены в подразделе 3.2.1. Современные АС для организации данных преимущественно используют СУБД. Основная функция, выполняемая СУБД – это предоставление пользователю базы данных возможности работать с ней, не вникая в детали организации данных на уровне файловой системы и аппаратного обеспечения. При этом важным компонентом СУБД являются используемые ею языковые средства [14]. Языковые средства СУБД обеспечивают интерфейс пользователей и прикладных приложений разных категорий с БД. Примером языкового средства, широко применяемого для определения данных и манипулирования ими в базах, являются различные модификации языка структурированных запросов SQL (Structured Query Language) [15]. Организация хранения информации в базах данных требует использования определенной абстрактной или логической модели. Основное назначение логической модели данных – систематизация различной информации и отражение ее свойств по содержанию, структуре и связям. Для организации данных используются следующие модели данных: иерархическая, сетевая, реляционная. В настоящее время подавляющее большинство АС используют реляционную модель, поэтому в пункте 3.2.2.1 приведено ее краткое описание. 3.1.3 ЛОКАЛЬНЫЕ И РАСПРЕДЕЛЕННЫЕ БД С точки зрения размещения данных различаются локальные и распределенные БД. Локальные БД эффективны при работе одного или нескольких пользователей в пределах одной локальной сети. В этом случае разграничение полномочий осуществляется административным путем. 99 Распределенные БД позволяют организовать доступ к информации множества удаленных пользователей, и требует развитых форм администрирования доступа к данным. Такими требованиями администрирования доступа являются: – централизованное управление распределенными данными; – поддержка целостности и непротиворечивости данных; – обеспечение защиты информации; – повышение эффективности доступа к данным. 3.2 ОСНОВЫ ОРГАНИЗАЦИИ ВНУТРИМАШИННОГО ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ Большое внимание в процессе проектирования внутримашинной ИБ уделяется вопросам эффективной организации данных, хранимых на машинных носителях. В подразделе 3.1.2 были описаны два способа организации внутримашинного ИО в виде: – отдельных независимых файлов (файловая организация); – базы данных, являющейся интегрированной совокупностью взаимосвязанных массивов. Выбор способа организации данных в АС, определяемых средствами их ведения, во многом определяет затраты на разработку прикладных программных средств обработки информации, на возможность развития ИБ, ее надежность. Поэтому внутримашинная ИБ, прежде всего, характеризуется составом и структурой массивов, а также способами организации и доступа к данным на машинных носителях. В зависимости от используемого способа организации данных внутримашинное ИО АС имеет свои особенности. 3.2.1 ИНФОРМАЦИОННАЯ БАЗА, ОРГАНИЗОВАННАЯ НА ОСНОВЕ ФАЙЛОВ При разработке первых АС ее информационные базы были реализованы с помощью файловой системы и ориентировались на конкретные функциональные задачи. Внутримашинное ИО на этом этапе создавалось как множество локальных (независимых) файлов, каждый из которых содержал 100 данные некоторого множества однородных управленческих документов. 3.2.1.1 О п и с а н и е И Б н а о с н о в е л о к а л ь н ы х ф а й л о в При такой модели внутримашинная информационная база представляет собой множество не связанных между собой файлов из однотипных записей с одноуровневой структурой. Запись является структурной единицей обработки данных и состоит из фиксированного набора (кортежа) полей, каждое из которых представляет собой элементарную логическую единицу данных. Другими словами, структура записи определяется составом и последовательностью входящих в нее полей. Каждому экземпляру записи, как правило, ставятся в соответствие один или два ключа записи: первичный (уникальный) и вторичный ключ. Первичный ключ – это одно или несколько полей, однозначно идентифицирующих запись. В случае, если первичный ключ состоит из одного поля, он называется простым, если из нескольких полей – составным ключом. Вторичный ключ, как и в реляционной модели, используется для установления связи между записями разных файлов. При этом если значение вторичного ключа записи дочернего файла соответствует значению первичного ключа записи родительского файла, то считается, что эти записи связаны. Значение вторичного ключа может повторяться в нескольких записях файла, то есть он не является уникальным. Если по первичному ключу может быть найдена одна единственная запись, то по вторичному может быть выбрано несколько записей. Для ускорения доступа к записям файла выполняется процедура индексирования, результатом которой является создание дополнительного индексного файла, содержащего в упорядоченном виде все значения ключей файла данных. Для каждого значения ключа в индексном файле содержится указатель на соответствующую запись файла данных. Наличие индексного файла позволяет по заданному ключу быстро находить запись. Индексирование может 101 производиться не только по первичному ключу, но и по неключевому атрибуту. Описание логической организации данных файловой модели заключается в присваивании каждому файлу уникального имени, а также в описании структуры его записей. При этом каждому полю задается сокращенное обозначение (имя поля) и указывается формат поля (тип хранимого данного, длина поля и точность числовых данных). Для полей, выполняющих роль уникального (первичного) ключа записи, указывается признак ключа. Структура файла обычно описывается таблицей, в которой отмечаются первичные ключи. Файловые информационные базы обрабатываются системами управления файлами или файловые системы. Файловые системы легко осваиваются, достаточно просты и эффективны в использовании. Для работы с ними используются простые языки запросов, либо и вовсе ограничиваются набором программ-утилит. Такие системы обычно поддерживают работу с небольшим числом файлов, содержащих ограниченное число записей с небольшим количеством полей. 3.2.1.2 Н е д о с т а т к и И Б н а о с н о в е л о к а л ь н ы х файлов В свое время переход к использованию централизованных систем управления файлами явился важным шагом в развитии информационных систем. Эти системы устанавливали правила именования файлов, определяли способы доступа к данным, хранящимся в файлах, взяли на себя задачи по распределение внешней памяти, отображению имен файлов в соответствующие адреса во внешней памяти и обеспечения доступа к данным. В ИБ на основе локальных файлов информация для каждой задачи складывается из нескольких составляющих: – входных переменных массивов; – массивов, получаемых в результате решения других задач; – массивов получаемых, от предыдущего решения задачи; – массивов нормативно-справочной информации; – массивов, хранимых для последующего решения задачи; 102 – массивов, хранимых для решения других задач; – выходных документов. Описанный способ хранения данных, когда для решения каждой задачи создаются отдельные массивы данных, имеет определенные недостатки, связанные с дублированием одних и тех же данных в массивах, предназначенных для решения разных функциональных задач. Дублирование данных кроме избыточности имеет еще один недостаток, связанный с их рассогласованием в ходе их ведения, из-за чего возникает потребность в периодической синхронизации дублируемых данных. При такой организации данных ИБ: – несет в себе значительную долю избыточности из-за повторения одних и тех же реквизитов в разных массивах, ориентированных на решение локальных задач; – затрудняется актуализация данных, разбросанных по разным ее массивам; – сложно обеспечить достоверность и непротиворечивость дублированных данных, так как при их актуализации возможны ошибки, связанные с человеческим фактором. Еще одной особенностью организации данных в локальных файлах заключается в том, что логическая структура файловых массивов и параметры их размещения на машинных носителях фиксируются в прикладных программах. В этих же программах, как правило, предусматриваются процедуры их создания и корректировки. Кроме этого, поддержка связей между файлами, реализуемая соответствием значений первичных и вторичных ключей родительских и дочерних файлов, также осуществляется прикладными программами, в каждую из которых заносятся данные о конкретных ключевых полях. Это означает, что структуры файловых массивов и прикладные программы их обработки жестко связаны и любое, даже незначительное, изменение в структуре данных влечет за собой необходимость корректировки прикладной программы, а это в свою очередь приводит к большим затратам на поддержание ИБ. 103 Таким образом, основным недостатком ИБ на основе локальных файлов является не столько обилие массивов и связанная с этим избыточность данных, а то, что она не обеспечивает независимость прикладных программ от структур обрабатываемых данных. 3.2.2 ИНФОРМАЦИОННАЯ БАЗА, ОРГАНИЗОВАННАЯ НА ОСНОВЕ БД Недостатки файловых моделей организации данных внутримашинной ИБ привели к разработке моделей данных, обеспечивающих проектирование логически взаимосвязанных массивов информации в БД. Информационные системы, разработанные с применением БД, были рассчитаны на потребности не одного пользователя, а больших групп и коллективов. В ходе разработки концепции интегрированных БД, было сформулировано очень важное и принципиальное требование отделения программ от данных. Реализация этого требования привела к отчуждению данных от программ и позволила рассматривать их в качестве самостоятельного ресурса предприятия. Отделение данных от прикладных программ, обеспечивает, с одной стороны, их независимую разработку, с другой стороны, изменение структуры данных не влечет за собой изменение прикладной программы. Организация массивов данных в базах имеет еще и то преимущество, что управление данными, включая их создание и ведение, выполняется с помощью специализированных программных средств – систем управления базами данных (СУБД). 3.2.2.1 К р а т к о е о п и с а н и е р е л я ц и о н н о й м о д е л и Реляционная модель представляется в виде совокупности отношений, над которыми выполняются операции реляционной алгебры (объединения, пересечения, проектирование и т.д.) [16]. Отношение имеет простую графическую интерпретацию в виде таблицы, столбцы которой соответствуют вхождению доменов в отношения, а строки наборам из некоторого количества значений, взятых из исходных доменов. 104 Таблица (отношение) – основной тип структуры данных в реляционной модели. Структура таблицы определяется совокупностью столбцов (полей, атрибутов). В каждой строке (кортеже) содержится единственное значение в соответствующем столбце. Столбец соответствует некоторому реквизиту, хранящемуся в БД. Каждый столбец должен иметь определенное имя соответствующего элемента данных. Один или несколько атрибутов, однозначно идентифицирующих строку, называется первичным ключом таблицы. Столбцы первичных ключей таблицы соответствует реквизитам-признакам, а неключевые столбцы – реквизитам-основаниям. Атрибут, значения которого выбирается из множества значений первичного ключа другой таблицы, называется вторичным ключом таблицы. Связи между записями двух связанных таблиц устанавливаются по равенству значений атрибутов ключевых таблиц (первичной в родительской таблице и вторичной – в дочерней). Родительской называется та таблица связи, значения первичного ключа которой используются для идентификации связанных строк дочерней таблицы связи. Дочерней называется та таблица связи, столбец (столбцы) которой определен (определены) в качестве вторичного ключа. БД могут быть расположены на одном компьютере (локальные БД) или на нескольких, соединенных между собой вычислительной сетью, компьютерах (распределенные БД). Реляционная модель, определения основных понятий которой были приведены в подразделе 3.1.2, основана на математическом понятии отношения, расширенном за счет добавления специальной терминологии и развития соответствующей теории. На пользовательском уровне, а также на уровне программиста структура данных отношений представляется в виде таблицы, в которой каждая строка значений (кортеж) соответствуют записи, а заголовки столбцов являются названиями полей (элементов) записи. При этом используются понятия записи, первичных и вторичных 105 ключей, сформулированные в рамках разработки файловой системы. Процедуры манипуляции данными (запоминания и поиска) осуществляются с применением: – операций на множествах (объединение, пересечение, разность, произведение); – реляционных операций (выбрать, спроецировать, соединить, разделить). В реляционной модели каждому объекту предметной области соответствует одно или более отношений, а связи между объектами указываются в явном виде и поддерживаются на уровне СУБД. При определении связи, как и при файловой организации данных, в качестве ее конструктивных элементов указываются идентификаторы (первичные и вторичные ключи) взаимосвязанных объектов. Одним из важнейших достоинств реляционной модели является то обстоятельство, что объекты предметной области и связи между ними представляются одинаковыми конструкциями, а их ведение реализуется на уровне СУБД, что существенно упрощает разработку прикладных программ. «Распределение обязанностей» между СУБД и прикладными программами при ведении БД осуществляется следующим образом: – СУБД реализует организацию совокупности данных по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования данными; – прикладные программы ориентированы на непрерывное поддержание в системе точной динамической информационной модели объекта управления в ходе решения различных задач. 3.2.2.2 Н а з н а ч е н и е и п р и н ц и п ы р е а л и з а ц и и С У Б Д СУБД представляет собой пакет программ, обеспечивающий поиск, хранение, корректировку данных, формирование ответов на незапланированные (произвольные) запросы пользователей, и выполняет центральную роль в функционировании БД. СУБД также обеспечивает сохранность данных, их конфиденциальность, связь с другими программными средствами. 106 При файловой организации данных внутримашинного ИО все эти функции реализуются в прикладных программах, тиражируя практически одни и те же алгоритмы для каждой решаемой задачи. Основное назначение СУБД заключается в том, чтобы обеспечить доступ пользователей к данным через их абстрактное представление, скрыв конкретные особенности хранения в машинной памяти и управления ими при выполнении перечисленных выше функций СУБД. При этом пользователь при работе с данными имеет дело не с файлами, описание которых содержится в прикладных программах, а с их абстрактным представлением в виде взаимосвязанных таблиц, моделирующих объекты ПрО и описанных на уровне СУБД. Следует подчеркнуть, что это описание является общим для всех прикладных программ. Принципы реализации СУБД. При разработке пакета программ, составляющего СУБД, закладываются принципы, обеспечивающие: – единство структурно-информационной организации массивов данных; – централизованное выполнение процессов накопления, хранения и обработки различных видов информации; – многоразовое и многоцелевое использование однократно введенных массивов информации; – интеграцию массивов данных, с целью их использования различными приложениями; – унификацию доступа к различным элементам произвольных информационных массивов; – минимизацию стоимости создания и функционирования БД. 3.2.2.3 П р е и м ущ е с т в а Б Д Описанные принципы реализации СУБД обеспечивают хранение информации АС в БД, допускающей многоцелевое применение хранимой информации и эффективное удовлетворение информационных потребностей различных пользователей. На этой основе можно: – реализовать многоаспектный или многокритериальный доступ к взаимосвязанным данным; 107 – обеспечить интеграцию данных, а на этой основе унификацию и централизацию управления ими; – устранить избыточность данных; – обеспечить возможность совмещения эффективных режимов программной и диалоговой обработки данных. Принцип интеграции данных, используемый при реализации СУБД, предполагает организацию хранения информации в едином интегрированном хранилище, т.е. в БД, к которой обеспечен широкий доступ различных пользователей и приложений. При этом меняется отношение к данным, которые рассматриваются как информационные ресурсы для использования произвольными приложениями для решения различных задач, а не отдельными приложениями, решающими конкретные задачи. Преимущества работы с БД для пользователей настолько значительны, что легко окупают затраты и издержки на его создание. Они заключаются в следующем: – повышается эффективность доступа к данным и, соответственно, производительность работы пользователей; – централизованное управление данными освобождает программистов от необходимости описания данных непосредственно в программах, что обеспечивает независимость прикладных программ от данных; – хранение информационных ресурсов в БД, поддерживаемых СУБД, позволяет реализовать нерегламентированные (незапланированные) запросы приложений, что существенно повышает гибкость современных АС; – в результате обеспечения независимости прикладных программ от данных снижаются затраты не только на создание и хранение данных, но и на поддержание их в актуальном динамичном состоянии; – централизованное хранение данных уменьшает потоки данных, циркулирующих в системе, сокращает избыточность и дублирование данных. 108 3.3 ОПИСАНИЕ СУБД Основное достоинство реляционных СУБД заключается в том, что она позволяет абстрагировать данные, освобождает разработчиков от необходимости программировать операции с данными и позволяет выйти на декларативный (абстрактный) уровень запросов к хранимым данным. При этом для работы с данными в распоряжение пользователей предоставляется язык запросов, с помощью которого они могут сформулировать свои запросы и стандартным образом выбирать и изменять данные. Это позволяет изолировать данные от прикладных программ таким образом, что любая программа может использовать данные, созданные другими разработчиками. 3.3.1 ТРЕХУРОВНЕВАЯ АРХИТЕКТУРА ANSI-SPARC Основная идея реализации СУБД, предназначенной для унифицированной обработки данных, заключается в использовании абстрактного описания схемы данных, представленной в системном каталоге или базе метаданных СУБД. Именно это обстоятельство обеспечивает интеграцию данных АС, позволяющее использовать одни и те же данные для решения различных задач, и является фундаментальным моментом концепции БД. С целью реализации этой идеи в 1975 году Национальный институт стандартизации США ANSI (American National Standard Institute) и Комитет планирования стандартов и норм SPARC (Standards Planning and Requirements Committee) предложили трехуровневую архитектуру СУБД [17]. Эта трехуровневая архитектура содержит внешний, концептуальный и внутренний уровни, как показано на Рис. 3.1. На внешнем уровне данные представляются в виде, удобном для восприятия пользователями, тогда как СУБД и операционная система работают с данными внутреннего уровня. Данные на внутреннем уровне сохраняются в памяти машины с использованием структур файловой организации. Для отображения внешнего уровня на внутренний и обеспечения необходимой независимости друг от друга предназначен кон109 цептуальный уровень, представляющий собой описание схемы данных в системном каталоге. Внешний уровень Представление1 Концептуальный уровень Внутренний уровень Физическая организация данных Представление1 . . . Представление1 Концептуальная схема Внутренняя схема База данных Рис. 3.1 – Трехуровневая архитектура ANSI-SPARC Перечислим основные преимущества, получаемые от такого разделения: – по каждому источнику данных для каждого пользователя может определяться индивидуальное внешнее представление. Например, сведения о сотрудниках компании, представляемые для рядовых сотрудников и руководителей различных рангов должны различаться; – пользователи абстрагируются от подробностей физического хранения данных в базе, таких как индексирование и хеширование; – администратор БД имеет возможность изменять ее концептуальную структуру без влияния на пользовательские или внешние представления. 3.3.1.2 В н е ш н и й ур о в е н ь Внешний уровень трехуровневой архитектуры определяет представление БД с точки зрения пользователей и описывает ту часть базы данных, которая относится к пользователю. Внешний уровень состоит из нескольких различных внешних представлений БД, реализованных для каждого пользователя или группы пользователей. 110 Внешнее представление содержит только те сущности, атрибуты и связи БД, которые интересны конкретному пользователю и он имеет права на доступ к ним. Другие сущности, атрибуты или связи, которые ему неинтересны или у него нет прав на доступ к ним, хотя и содержатся в БД, но данный пользователь их не видит и может даже не знать об их существовании. С другой стороны, различные внешние представления могут поразному отображать одни и те же данные. Например, один пользователь может просматривать даты в формате «день-месяц-год», а другой – в соответствии нормой, принятой в его стране, например, в формате «год-месяц-день». Во внешних представлениях могут быть использованы производные или вычисляемые данные, которые не хранятся в базе, а создаются при выборке соответствующих данных. Например, вряд ли целесообразно хранить данные о возрасте сотрудников в БД, поскольку в таком случае их пришлось бы регулярно обновлять. Вместо этого в БД хранятся даты рождения сотрудников, а возраст определяется средствами СУБД как разность текущей даты и дат рождения сотрудников. Внешние представления могут также включать комбинированные данные из нескольких источников. 3.3.1.3 К о н ц е п т уа л ь н ы й ур о в е н ь На концептуальном уровне описывается состав данных, хранимых в базе данных, а также связи, существующие между ними. Этот уровень является промежуточным в трехуровневой архитектуре и содержит логическую структуру всей БД. На этом уровне определяются требования к данным, не зависящие от способа их хранения. На концептуальном уровне представлены следующие виды сведений о данных хранимых в БД: – перечень сущностей (таблиц), их атрибутов и связей между сущностями; – ограничения, накладываемые на данные; 111 – семантическая информация о данных, представленная контекстом. Под контекстом имеется в виду то, что каждое значение в БД сопоставляется с именем атрибута некоторой сущности; – информация о правах на доступ и мерах поддержки целостности данных. Концептуальный уровень поддерживает внешнее представление, в том смысле, что любые доступные пользователю данные должны быть описаны на этом уровне. Однако этот уровень не содержит никаких сведений о методах хранения данных. Например, описание сущности должно содержать сведения о типах данных атрибутов (целочисленный, действительный или символьный) и их длине (количестве значащих цифр или максимальном количестве символов), но не должно включать сведений об организации хранения данных, например об объеме занятого пространства в байтах. 3.3.1.4 В н ут р е н н и й ур о в е н ь Внутренний уровень описывает организацию данных на физическом уровне представления БД. На этом уровне содержатся определения хранимых записей и методов представления, описания полей данных, сведения об индексах и выбранных схемах хеширования. Другими словами, этот уровень описывает то, как информация БД хранятся в машинной памяти. Внутренний уровень описывает особенности физической реализации БД, определенную концептуальной схемой, и предназначен для достижения высокой производительности и обеспечения оптимального размещения данных в физической памяти. Он содержит описание структур данных, используемых для хранения данных в файлах запоминающих устройств. На этом уровне осуществляется взаимодействие СУБД с методами доступа ОС. С помощью функций хранения и извлечения записей данных СУБД осуществляет размещение данных на запоминающих устройствах, создание индексов, извлечение данных и т.д. На внутреннем уровне хранится следующая информация: – схема распределения дискового пространства для хранения данных и индексов; 112 – описание деталей сохранения записей, с указанием размеров сохраняемых элементов данных; – сведения о размещении записей. Ниже внутреннего уровня находится физический уровень, который контролируется ОС, но под управлением СУБД. Следует отметить, что функции СУБД и ОС на физическом уровне разделены не четко, и зависят от конкретной СУБД. В одних СУБД используются методы доступа ОС, а в других поверх ОС может быть реализована собственная файловая организация и применяются только самые основные методы доступа ОС. 3.3.2 СХЕМЫ БД И ОТОБРАЖЕНИЯ Общее описание БД представляется схемой БД, причем на каждом уровне трехуровневой архитектуры СУБД определяются три различных типа схем БД. На внешнем уровне определяются внешние схемы или подсхемы, по количеству пользователей или их групп. На концептуальном уровне определяется одна концептуальная схема, а на внутреннем уровне абстракции – одна внутренняя схема. Каждая внешняя схема выводится на основе концептуальной схемы таким образом, что обеспечивается установление соответствия между элементами концептуальной и внешних схем как показано на Рис. 3.2. При этом говорят, что каждая внешняя схема связана с концептуальной схемой с помощью концептуально-внешнего отображения. С его помощью СУБД может отображать имена пользовательского представления на соответствующую часть концептуальной схемы [17]. С другой стороны, концептуальная схема связана с внутренней схемой посредством концептуально-внутреннего отображения. Оно позволяет СУБД найти фактическую запись на физическом устройстве хранения, соответствующей логической записи в концептуальной схеме. За установление соответствия между тремя уровнями описания БД, а также за проверку их непротиворечивости отвечает СУБД. Для этого СУБД должна использовать информацию из концепту113 альной схемы, с помощью которой обнаруживаются любые различия в именах объектов, именах атрибутов, порядке следования атрибутов, их типах данных и т.д. Внешнее представление 1 Внешнее представление 2 tabNo Family Name Vozrast Oklad tabNo Family Otdel sotrNo Family Name datRozhd Oklad Otdel Концептуальный уровень Внутренний уровень struct Sotrudnik { int sotrNo, char Family, char Name, date datRozhd, float Oklad, int Otdel, struct Sotrudnik *next /*Указатель на следующую запись*/ } index sotrNo, index Otdel; /*Индексы для таблиц*/ Рис. 3.2 – Различия между тремя уровнями представления данных На Рис. 3.2 приведены примеры различных уровней представления схемы БД. На нем показаны два внешних представления информации о персонале: – одно содержит табельный номер (tabNo), имя (Family) и фамилию (Name), возраст (datRozhd) и сумму зарплаты за год (Oklad); – другое включает табельный номер (tabNo), фамилию (Family) и номер отделения компании (Otdel). Источником данных для двух внешних представлений является концептуальное представление. Особенностью данного отображения является то, что поле возраста сотрудника (Vozrast) преобразуется в поле даты его рождения (datRozhd), а поле sotrNo из внешнего представления отображается на поле tabNo в записи концептуального представления. Данные концептуального уровня используются также при отображении на внутренний уровень, содержащий физическое описание структуры записи концептуального представления (Sotrudnik). На 114 этом уровне определение структуры формулируется на языке высокого уровня, как показано на Рис. 3.2. Эта структура содержит указатель (next), который позволяет физически связать все записи о сотрудниках в единую цепочку. 3.3.3 СИСТЕМНЫЙ КАТАЛОГ Особенностью организации ИБ на основе БД является то, что в ней хранятся не только рабочие данные моделируемой ПрО, но и их описания. Такие данные представляют собой набор записей с самоописанием, и именно наличие этого описания обеспечивает интеграцию данных, используемых при решении различных задач, в единой централизованной базе. Самоописание данных реализуется с помощью метаданных, которые хранятся в системном каталоге и содержат сведения о схемах данных (таблицах, их атрибутах и связях между таблицами), индексах, пользователях, их правах по доступу к данным и т.д. Предполагается, что системный каталог доступен как пользователям, так и функциям СУБД [17]. В зависимости от типа используемой СУБД количество информации и способ ее применения могут различаться, но, как правило, все производители СУБД в системном каталоге хранят следующие виды «данных о данных»: – имена таблиц, связанные с их элементами данных; – имена, типы и размеры элементов данных; – имена связей и элементов их конструкций (первичных и вторичных ключей); – ограничения для поддержки целостности данных; – имена пользователей с их правами доступа к данным; – соответствия между компонентами внешней, концептуальной и внутренней схемы и ними. Использование метаданных в СУБД является одним из фундаментальных факторов концепции БД. Именно благодаря использованию данных, хранящихся в системном каталоге, программные компоненты СУБД обеспечивают унифицированную обработку произвольных данных базы. 115 Например, модуль проверки прав доступа использует системный каталог для определения наличия у пользователя полномочий, необходимых для выполнения запрошенных им операций. Для этого используются следующие сведения, содержащиеся в системном каталоге: – имена пользователей, имеющих право доступа к БД; – элементы данных, к которым каждый пользователь имеет право доступа, а также разрешенные типы доступа к ним (для вставки, обновления, удаления или чтения). Другим примером использования данных системного каталога могут служить средства проверки целостности данных. Для выполнения этой проверки соответствующие программные средства используют следующие сведения, хранящиеся в системном каталоге: – имена элементов данных из БД; – типы и размеры элементов данных; – ограничения, установленные для каждого элемента данных. Использование метаданных в СУБД позволяет достичь определенных преимуществ, перечисленных ниже: – информация о данных хранится в системном каталоге централизованно, что позволяет контролировать доступ к этим данным, как и к любому другому ресурсу; – с помощью данных системного каталога представляется семантическая информация, что позволяет другим программам «понять» их предназначение, т.е. интерпретировать; – в системном каталоге содержатся сведения о пользователях и их отношениях с данными: являются ли они создателями данных, т.е. владельцами, или просто обладают правом доступа к ним; – расширяются возможности по организации поддержки целостности данных. 3.3.4 НЕЗАВИСИМОСТЬ ДАННЫХ Еще одним важным преимуществом наличия описания данных в СУБД является возможность поддержки независимости данных. При этом различают два типа независимости данных: логическую и физическую [17]. 116 Логическая независимость данных защищает внешние схемы от изменений, вносимых в концептуальную схему. Иногда в ходе эксплуатации АС приходится выполнять изменения концептуальной схемы, такие как добавление или удаление новых сущностей, их атрибутов или связей. Логическая независимость данных позволяет внести эти изменения без необходимости изменений в уже существующих внешних схемах или корректировки прикладных программ. При этом очевидно, что пользователи, для которых эти изменения предназначались, должны знать о них, но очень важно, чтобы другие пользователи даже не подозревали об этом. Чтобы пояснить, каким образом реализуется такая независимость, рассмотрим программу, использующую в своей работе данные таблицы Т, которую администратор желает реорганизовать путем вертикального разделения на две части, сохраняемые в таблицах Т1 и Т2. Для сохранения работоспособности программы, зависящей от таблицы Т, администратор может определить представление (view) над таблицами Т1 и Т2, соответствующее исходному определению таблицы Т. Хотя реальная таблица Т была удалена из БД в ходе реорганизации, но с помощью инструкции CREATE VIEW можно создать виртуальную таблицу Т, которая имеет точно такую же структуру, что и реальная таблица и является внешним представлением таблиц Т1 и Т2. Таким образом, использование внешних представлений обеспечивает корректную работу старых программ при изменении концептуальной схемы БД. Физическая независимость данных означает защищенность концептуальной схемы от изменений, вносимых во внутреннюю схему. Под этим понимается способность СУБД предоставлять некоторую свободу модификации способов организации БД в среде хранения, не вызывая необходимости внесения соответствующих изменений в логическое представление и не затрагивая созданных прикладных программ, использующих эти БД. Это позволяет в АС заменить СУБД на более совершенную, так как вновь введенная СУБД может реализовать имеющееся логическое представление БД. При этом на физическом уровне представ117 ление этой БД, реализуемой новой СУБД, может существенно различаться. При этом пользователем могут быть замечены изменения только в производительности системы. Внешняя схема ... Внешняя схема Преобразование внешней схемы в концептуальную ... Внешняя схема Логическая независимость данных Концептуальная схема Преобразование концептуальной схемы. во внутреннюю Физическая независимость данных Внутренняя схема Рис. 3.3 – Реализация независимости от данных в трехуровневой архитектуре ANSI-SPARC На Рис. 3.3 показано место перечисленных выше типов независимости от данных в трехуровневой архитектуре СУБД. Следует отметить, что хотя принятое в архитектуре ANSI-SPARC двухэтапное отображение может сказываться на эффективности работы СУБД, но при этом оно обеспечивает независимость данных от приложений. Некоторое снижение эффективности работы СУБД можно компенсировать постоянно растущим быстродействием компьютерной техники, тогда как возможность изменений концептуальной и внутренней схем, не затрагивая созданных прикладных программ, является весьма ценным качеством современных АС, реализованных на основе СУБД. 3.4 ИСПОЛЬЗОВАНИЕ СУБД В АС И ЕЕ ВЛИЯНИЕ НА АРХИТЕКТУРУ АС Использование СУБД в современных АС внесло изменения не только на организацию ИО, но и существенно повлияло на архитектуру самой АС. Возможность СУБД, обеспечивающая предостав- 118 ление многоаспектного доступа со своих АРМ к общей централизованной БД и использование одних и тех же данных при решении различных задач является существенным преимуществом концепции БД. Данная схема работы, поддержанная современными сетевыми технологиями, сделала возможной реализацию в современных АС широко распространенной архитектуры «клиент-сервер». СУБД в этой архитектуре играет роль «сервера», обсуживающего многочисленных «клиентов» – прикладных программ АС. Идея архитектуры «клиент-сервер» сформировалась не сразу и прошла ряд этапов в своем развитии. В ходе эволюции концепции БД и развития сетевых технологий были реализованы две архитектуры АС, получившие название «файл-сервер» и «клиент-сервер» (в 2-хзвенных и 3-хзвенных вариантах). 3.4.1 ВЫДЕЛЕНИЕ СУБД В ОТДЕЛЬНЫЙ КОМПОНЕНТ АС До появления СУБД данные и фрагменты кода, управляющие этими данными, не вычленялись из состава приложения, и рассматривались как его неотъемлемые составляющие. В этом случае для каждой решаемой задачи приходилось определять данные, возможно описанные в других приложениях, и тиражировать практически одинаковые по смыслу (но не по форме) фрагменты кода, отвечающего за описание этих данных. В рамках концепции БД был сформулирован альтернативный подход к организации приложений, согласно которому из них были выведены: – данные с набором записей с их описаниями и занесены соответственно в БД и системный каталог; – фрагменты кода, отвечающие за работу с данными, реализованы в специализированной программе, названной СУБД. Изменения ИО, связанные с реализацией внутримашинных ИБ на основе БД, привели к изменению архитектуры всей АС, содержащей в своем составе следующие компоненты: – собственно БД, представляющую информационную модель предметной области; 119 – СУБД, с помощью которой реализуются централизованное управление данными, доступ к ним и поддержание их в состоянии, соответствующем текущему состоянию ПрО; – приложение, реализующее алгоритм решаемой задачи, и использующее СУБД для доступа к данным. СУБД изолирует данные от прикладных программ, и организует доступ к данным с помощью языка, позволяющего формулировать выражения запросов на выполнение стандартных операций вставки, выборки, удаления и обновления данных для прикладных программ. Так мы приходим к организации АС, в которой фрагмент логики программы, отвечающий за управление данными, был выделен в отдельный компонент и назван СУБД. Одно из важнейших требований, предъявляемых к СУБД,  это обеспечение многопользовательского доступа к данным ИБ для всех прикладных программ, нуждающихся в них. Эта логика программы определяется специализированными фирмами-разработчиками СУБД. Программный модуль 2 Локальная сеть Программный модуль 1 База данных1 Метаданные СУБД База данных2 Метаданные Программный модуль 3 Рис. 3.4 – АС с выделенной СУБД и БД с метаданными Схема организации АС с выделенными данными и логикой их обработки приведена на Рис. 3.4. На этом рисунке изображены три программных модуля, которые через одну СУБД (связи между приложениями и СУБД показаны сплошной линией) работают с двумя разными БД. На рисунке 120 также показано, что первый и второй модули работают с общей БД (связи между приложениями и БД показаны пунктирной линией). Следует отметить, что схема организации приложений, приведенная на рисунке, подготовила «почву» для разработки архитектуры «клиент-сервер». СУБД в этой архитектуре играет роль «сервера», обсуживающего множество «клиентов» – прикладных программ АС. 3.4.2 АРХИТЕКТУРА «ФАЙЛ-СЕРВЕР» Первым шагом в направлении создания АС по схеме «клиентсервер», обеспечивающей сетевую обработку данных ИБ, можно считать разработку архитектуры «файл-сервер», становление которой связано, прежде всего, с распространением персональных компьютеров и локальных сетей. В этих условиях появилась возможность совместного использования файлов данных с помощью многопользовательских версий БД для автономных персональных компьютеров. Реализация архитектуры «файл-сервер» предполагает наличие компьютера, выделенного под файловый сервер, на котором находятся ядро сетевой операционной системы и централизованно хранимые файлы с данными, необходимые для работы приложений и СУБД. Пользовательские приложения и СУБД по данной схеме размещены и функционируют на отдельных рабочих станциях и обращаются к файловому серверу только по мере необходимости получения доступа к нужным файлам. При этом обработка данных осуществляется на этих рабочих станциях и распределена по всей локальной сети, а файловый сервер функционирует просто как совместно используемый жесткий диск. В этой архитектуре обеспечивается коллективный доступ к общей ИБ на файловом сервере. Причем, когда происходит обновление файла одним из пользователей, этот файл блокируется для других пользователей. При этом запрошенные данные транспортируются с файлового сервера на рабочие станции, где и происходит их обработка средствами СУБД. 121 Достоинство этой модели заключается в том, что в ней было реализовано разделение монопольного приложения на два взаимодействующих процесса. При этом сервер может обслуживать множество клиентов, которые обращаются к нему с запросами. Но особенности обмена данными между СУБД и файловым сервером порождают серьезные недостатки данной архитектуры. Для пояснения этой особенности рассмотрим следующий пример. Допустим, что данные о сотрудниках офисов некоторой компании, размещены в двух таблицах БД: «Офис» и «Работник». Предположим, что требуется произвести изменение данных о сотрудниках одного офиса компании, размещенных в этих таблицах. Для этого необходимо выполнить следующие действия. 1. Для получения необходимых данных для обработки, хранимых на диске файлового сервера, СУБД рабочей станции посылает запросы файловому серверу. 2. Но файловый сервер не воспринимает команд на языке SQL, поэтому СУБД запрашивает у файлового сервера файлы таблиц «Офис» и «Работник» целиком, а не искомые данные о сотрудниках. 3. Обработка необходимых данных осуществляется на рабочей станции, а затем, после записи результатов обработки в файлы таблиц «Офис» и «Работник», происходит их передача обратно на файловый сервер. Таким образом, при хранении данных на файловом сервере даже для проведения незначительных манипуляций с данными по сети приходилось передавать огромное количество записей или даже всю базу данных целиком. Для этой схемы характерно наибольшее суммарное время обработки информации. Проанализировав описанный процесс обработки данных, хранящихся на файловом сервере, можно выделить следующие основные недостатки архитектуры «файл-сервер»: – большой объем сетевого трафика; – на каждой рабочей станции содержится полная копия СУБД; – управление параллельной работой, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД. 122 3.4.3 АРХИТЕКТУРА «КЛИЕНТ-СЕРВЕР» Для решения проблем, выявленных на этапе развития архитектуры «файл-сервер», разработчики переместили большую часть логики управления данными на серверы баз данных и стали хранить процедуры обработки данных централизованным образом. В результате появилась архитектура «клиент-сервер», согласно которой БД и ядро СУБД размещаются на машине-сервере. На клиентской стороне располагается прикладное приложение и клиентская часть СУБД. Сетевая компьютерная система «клиент-сервер» предполагает разделение функций обработки данных между клиентом (рабочей станцией) и машиной-сервером БД, где обработку осуществляет установленная там СУБД. В данном варианте по сети на сервер баз данных отправляется только запрос на обработку данных, где осуществляется поиск и обработка информации, а обратно передаются только ее результаты. Запросы на обработку данных формулируются на языке структурированных запросов SQL. Таким образом, взаимодействие между клиентом и сервером в рамках данной модели происходит на уровне команд манипулирования данными СУБД, реализованными в виде выражений SQL. Эти выражения могут быть сформированы с помощью клиентского приложения СУБД или встроены в код приложения БД, размещенного на машине-клиенте. Эффективность функционирования АС, реализованных по архитектуре «клиент-сервер», существенно повысилась, что повлияло на расширение области использования АС в сфере управления. При этом автоматизация охватывала все более широкий круг задач, требуя постоянного добавления в систему все новых и новых функций управления, т.е. масштабирования систем. Этот постоянно нарастающий объем приложений АС приходилось развертывать на сотнях и тысячах компьютеров конечных пользователей. В результате произошедших изменений разработчики клиентской части столкнулись с двумя описанными ниже про- 123 блемами, препятствующими достижению истинной масштабируемости приложений. 1. Для эффективной работы клиентского уровня требуются значительные вычислительные ресурсы, включая большое пространство на диске, оперативную память и мощность центрального процессора. Поэтому данный уровень в двухуровневой архитектуре получил название «толстый» клиент. 2. По этой же причине требуются значительные накладные расходы на администрирование клиентской части АС, связанного с постоянным обновлением ПО на сотнях и тысячах компьютеров конечных пользователей. 3.4.4 ТРЕХЗВЕННАЯ АРХИТЕКТУРА «КЛИЕНТ-СЕРВЕР» Проблема масштабируемости приложений не была решена в рамках двухзвенной архитектуры, и для ее преодоления был предложен новый вариант архитектуры «клиент-сервер», содержащий три уровня ПО: – пользовательского интерфейса – этот уровень, как и в двухзвенной архитектуре, располагается на компьютере конечного пользователя и называется «клиентом»; – реализации прикладных алгоритмов – промежуточный уровень, введенный в рамках нового варианта архитектуры «клиентсервер», располагается на отдельном компьютере и называется «сервером приложений»; – обработки данных – на этом уровне, как и в двухзвенной архитектуре, хранятся данные, необходимые для функционирования промежуточного уровня. Данный уровень, как правило, реализуется на отдельном сервере и называется «сервером базы данных». Клиент в данной архитектуре отвечает только за пользовательский интерфейс и, возможно, выполняет некоторую очень простую обработку данных, например, проверку введенной информации, поэтому клиентская часть приложения может быть построена с использованием так называемого «тонкого» клиента. Основные прикладные алгоритмы теперь реализованы на отдельном уровне, на сервере приложений, который физически связан 124 с клиентом и сервером базы данных посредством локальной или глобальной (распределенной) вычислительной сети. При этом предполагается, что один сервер приложений может обслуживать множество клиентов. Введение промежуточного уровня, на котором размещаются приложения, существенно упрощает масштабирование АС, так как при добавлении в систему новых функций управления уже не требуется развертывать соответствующие приложения на сотнях и тысячах компьютеров конечных пользователей, а достаточно установить по одному экземпляру новых приложений на сервере приложений. 3.5 ПРИМЕР РАЗРАБОТКИ ВНУТРИМАШИННОГО ИО Внутримашинное ИО современных АС создается в виде интегрированных данных, управляемых СУБД. Организация внутримашинной ИБ в виде БД имеет существенные преимущества перед ИБ, реализованными на основе локальных файлов. Эти преимущества в части организации процесса проектирования ИО АС основаны на том, что применение СУБД обеспечивает независимость данных от программ, которая заключаются в следующем. 1. При организации данных на основе локальных файлов проектирование ИО АС и ее программных приложений рассматривается как единый технологический процесс. В этом случае для каждой задачи определяется фрагмент ИО, который может быть использован только для решения данной задачи соответствующим программным приложением. 2. При реализации внутримашинного ИО в виде интегрированной БД его проектирование рассматривается как относительно самостоятельная часть разработки АС. Преимуществом данного подхода является его объективность, системное отображение ПрО, устойчивость ее информационной модели, обслуживающей все программные приложения по решению задач АС, в том числе и заранее незапланированные. Именно эти обстоятельства обеспечивают проектирование схем БД создаваемых АС специалистами в области 125 моделирования данных, осуществляемых независимо от разработчиков ПО АС. Порядок разработки внутримашинного ИО АС продемонстрируем на примере разработки АС для ПрО «Учебный процесс». Процедура разработки внемашинного ИО для данной ПрО была описана в разделе 2.4 и рассматривалась как реализация первого этапа методики создания ИО АС. На втором этапе создания ИО АС по этой же методике создается концептуальная схема ПрО, а на ее основе схема БД, используемая для организации хранения данных ПрО в машинной памяти. 3.5.1 ОСОБЕННОСТИ ПРЕДСТАВЛЕНИЯ КОМПОНЕНТОВ ВНЕМАШИННОГО ИО ВО ВНУТРИМАШИННОЙ ИБ АС Технология создания внемашинного ИО социальных систем сформировалась еще до появления вычислительной техники и была направлена на восприятие информации документов человеком для ее последующей переработки и использования для принятия управленческих решений. В условиях автоматизации управленческой деятельности внемашинное ИО представляется во внутримашинных ИБ, в которых в целях реализации машинной обработки информации документов его реквизиты и показатели получают другую физическую реализацию и организационное строение и называются данными, записями, таблицами, базами данных. Поэтому, в первую очередь, мы должны установить четкое соответствие между понятиями этих сфер описания ИО АС. 3.5.1.1 П р е д с т а в л е н и е р е к в и з и т о в и п о к а з а т е л е й в памяти машины Во внутримашинном ИО реквизиты-признаки и реквизиты-основания, описанные выше в разделах 1.3 и 2.4, хранятся в физической памяти машины и называются данными. При этом любое значение, описывающее какой-либо аспект моделируемого объекта, должно быть однозначно идентифицировано, с тем, чтобы их мож- 126 но было извлечь из базы в любой момент и использовать для решения задач АС. Поэтому реквизиты-основания в БД представляются только в паре с реквизитами-признаками. Такая пара реквизитов в подразделе 1.3.2 была определена как показатель, в состав которого входят один реквизит-основание и один или несколько реквизитов-признаков, однозначно идентифицирующие реквизиты-основания. Представление показателей документов в файлах или БД АС направлено на то, чтобы заменить обработку информации документов человеком обработкой данных с помощью средств вычислительной техники. При этом важно подчеркнуть, что представление данных документов в виде совокупности реквизитов-признаков и реквизитовоснований, сохраняет элементарные смысловые связи данных, определяющие какой атрибут, какого экземпляра объекта они представляют. Эти смысловые связи используются для доступа к отдельным данным, а также для восстановления данных документа хранимых в виде совокупности отдельных записей в ИБ. Следует отметить, что при обработке этих данных в приложениях их смысловые связи или игнорируются, или уходят на второй план, и каждый реквизит рассматривается как отдельный элемент данных, а их обработка происходит по «машинным законам», определенным еще фон-Нейманом. Согласно этим законам машинная обработка данных абстрагируется от контекстных взаимосвязей компонентов показателей и выполняется одинаково для информации любого смыслового содержания. После завершения обработки элементы данных снова помещаются в схемы данных, в которых связи между реквизитами-признаками и реквизитами-основаниями объектов документов учтены. Поэтому для представления смыслового содержания обработанных данных пользователю, они могут быть преобразованы обратно в реквизиты показателей документов, распечатанных на бумаге или отображенных на экране дисплея. 127 3.5.1.2 П р е д с т а в л е н и е р е к в и з и т н о г о с о с т а в а объектов в виде таблиц БД При разработке УСД ПрО «Учебный процесс» (см. подраздел 2.4.3) были определены информационные объекты документов с указанием их реквизитного состава, представленного одним или множеством реквизитов-оснований и реквизитом-признаком, используемым для их идентификации. В БД реквизитный состав информационного объекта представляется совокупностью столбцов таблицы. Реквизит-признак объекта в таблице определяется в качестве ключевого столбца (столбцов). Каждая совокупность значений реквизитного состава информационного объекта, размещаемая в одной строке таблицы, описывает один из его экземпляров. При этом значение ключевого столбца таблицы однозначно идентифицирует запись, т. е. экземпляр объекта, а остальные поля записи содержат значения реквизитов-оснований и характеризуют его с количественной или качественной стороны. 3.5.1.3 П р е д с т а в л е н и е м н о ж е с т в а и н ф о р м а ц и о н н ы х объектов как схемы базы данных Информационные объекты, выделенные в результате анализа реквизитного состава документа ПрО, представляют собой не изолированные сущности, а определенным образом связаны между собой. Связи между этими объектами определяются по факту их размещения на одном документе, т.е. описания некоторой производственной или иной ситуации. Связи между объектами на документах явно не обозначены, но человек, исходя из смысла описываемых данных, легко их устанавливает. Порядок определения функциональных зависимостей между объектами в пределах одного документа будет описан в подразделе 3.5.2. Проведенный анализ системы документов также показал, что в некоторых документах встречаются ссылки на объекты, описанные в других документах (см. схему документа «Экзаменационная ведомость», приведенную на Рис. 3.8). Это говорит о том, что связи между объектами имеют место не только в случае их размещения на одном документе, но и при их размещении в разных документах. 128 Данный тип связи также устанавливается исходя из смысла описываемых данных, и не представляет для человека особых трудностей. Порядок определения функциональных зависимостей между объектами разных документов будет описан в подразделе 0. Таким образом, в результате анализа системы документов ПрО выявляется множество объектов, соединенных между собой «незримыми» связями. Эти связи определяются человеком исходя из смысла данных, но при машинной реализации УСД в виде совокупности таблиц БД связи между объектами следует указать явно. Это требует некоторой модификации данных, полученных в ходе разработки внемашинного ИО. Следует отметить, что на сегодняшний день не все документы ПрО подлежат формализации для хранения их данных в базе с целью их автоматизированной обработки. Поэтому во внутримашинном ИО современных АС часть данных по-прежнему хранится в виде файлов и Web-сайтов. Совокупность всех выявленных таблиц БД, файлов и Web-сайтов, представленных в машинной памяти АС охватывает всю информацию моделируемой социальной системы и называется ее информационной базой (ИБ). В данном разделе, посвященной разработке концептуальной схемы БД, будем рассматривать только формализованную часть ИБ, представляемой в виде таблиц БД, и опишем процедуру формирования ее концептуальной модели на примере разработки схемы БД для ПрО «Учебный процесс». 3.5.2 ОПРЕДЕЛЕНИЕ ФУНКЦИОНАЛЬНЫХ ЗАВИСИМОСТЕЙ МЕЖДУ ОБЪЕКТАМИ ДОКУМЕНТОВ На втором этапе разработки ИО АС по описанию внемашинного ИО, реализованного на первом этапе разработки ИО АС, создаются компоненты внутримашинного ИО (первый этап был описан в подразделе 2.4). Следует отметить, что в ходе анализа ПрО «Учебный процесс», выполненного на первом этапе, информационные объекты ПрО уже были выявлены и определены составы их реквизитов. Для этого было использовано понятие функциональной связи 129 реквизитов и основанная на нем методология структурирования документов в виде совокупности информационных объектов с указанием составов их реквизитов и показателей. Наша задача на данном этапе заключается в установке явных связей между объектами документов ПрО «Учебный процесс». 3.5.2.1 С в я з и о б ъ е к т о в д о к ум е н т а «С п и с о к с т уд е н т о в г р уп п ы » Информационная структура документа «Список студентов группы» с выделенными объектами ГРУППА и СТУДЕНТ, описана в подразделе 2.4.3.1, и приведена на Рис. 2.4. Связь между объектами СТУДЕНТ и ГРУППА, отражает тот факт, что в каждом документе представляется список студентов, обучающихся в группе, указанной в заголовке документа. Эта связь задана неявно и может быть определена только человеком путем анализа контента (содержания) документа. В соответствии с реквизитным составом объекта ГРУППА, описанном в подразделе 2.4.3.1, и порядком определения информационно-логической структуры документа, приведенного в разделе 1.3.4, определим структуру таблицы БД ГРУППА, предназначенную для внутримашинного хранения данных этого объекта. Структура таблицы БД ГРУППА имеет вид: – «Группа» – первичный ключ; – «Кол_стд» – неключевой атрибут; – «Средн_балл» – неключевой атрибут. В соответствии с реквизитным составом объекта СТУДЕНТ, описанном в разд. 2.4.3.1, и порядком определения информационно-логической структуры документа, определим структуру таблицы БД СТУДЕНТ имеющую вид: – «Ном_стд» – первичный ключ; – «ФИО_стд» – неключевой атрибут; – «Год_рождения» – неключевой атрибут; – «Адрес» – неключевой атрибут; – «Прох_балл» – неключевой атрибут; – «Группа» – вторичный ключ. 130 СПИСОК СТУДЕНТОВ ГРУППЫ ГРУППА К_Группа Группа Кол_стд Средн_балл СТУДЕНТ Ном_стд ФИО_стд Год_рождения Адрес Прох_балл Группа К_ФИО_студ Рис. 3.5 – Связи объектов СТУДЕНТ и ГРУППА документа «Список студентов группы» Для предотвращения утери информации о связи между объектами СТУДЕНТ и ГРУППА при их сохранении в машинной памяти в соответствии с порядком, описанном в подразделе 1.3.4, в объекте СТУДЕНТ введем поле вторичного ключа «Номер группы» (НГ). В этом случае мы получаем модифицированную структуру документа «Список студентов группы», приведенную на Рис. 3.5. На этой схеме связи между: – реквизитами и словарями-классификаторами указаны штрихпунктирными линиями со стрелкой; – объектами документа – штриховыми линиями со стрелкой, указывающей направление ссылки на значение первичного ключа. 131 3.5.2.2 С в я з и о б ъ е к т о в д о к ум е н т а «С п и с о к преподавателей кафедры » Информационная структура документа «Список преподавателей кафедры» с выделенными объектами КАФЕДРА и ПРЕПОДАВАТЕЛЬ, описана в подразделе 2.4.3.2, и приведена на Рис. 2.5. Сначала определим структуры таблиц БД КАФЕДРА и ПРЕПОДАВАТЕЛЬ для машинного хранения данных об этих объектах в базе данных. В соответствии с реквизитным составом объекта КАФЕДРА, определенным в подразделе 2.4.3.2, структура таблицы КАФЕДРА имеет вид: – «Кафедра» – первичный ключ; – «Назв_кафедры» – неключевой атрибут; – «Заведующий» – неключевой атрибут; – «Телефон» – неключевой атрибут. В соответствии с реквизитным составом объекта ПРЕПОДАВАТЕЛЬ, описанном в разд. 2.4.3.2, и порядком определения информационно-логической структуры документа, определим структуру таблицы БД ПРЕПОДАВАТЕЛЬ имеющую вид: – «Таб_ном» – первичный ключ; – «ФИО_прп» – неключевой атрибут; – «Год_рождения» – неключевой атрибут; – «Уч_степень» – неключевой атрибут; – «Уч_звание» – неключевой атрибут; – «Кафедра» – вторичный ключ. Связь между объектами КАФЕДРА и ПРЕПОДАВАТЕЛЬ, отражает тот факт, что в каждом документе представляется список преподавателей, работающих на кафедре, указанной в реквизите «Назв. кафедры». Эта связь также задана неявно и при машинном сохранении данных документа будет утеряна. Как и в предыдущем случае, для предотвращения утери информации при сохранении данных этого документа в машинной памяти, в объекте ПРЕПОДАВАТЕЛЬ введем атрибут «Код кафедры» (ККАФ). 132 В этом случае мы получаем модифицированную структуру документа «Список преподавателей кафедры», приведенную на Рис. 3.6. СПИСОК ПРЕПОДАВАТЕЛЕЙ КАФЕДРЫ КАФЕДРА Кафедра Назв_кафедры К_КАФЕДРА Заведующий К_ФИО_прп Телефон ПРЕПОДАВАТЕЛЬ Таб_ном ФИО_прп К_ФИО_прп Уч_степень Уч_звание Кафедра К_УЧ_степень К_УЧ_звание Рис. 3.6 – Связи объектов КАФЕДРА и ПРЕПОДАВАТЕЛЬ документа «Список преподавателей кафедры» 3.5.2.3 С в я з и о б ъ е к т о в д о к ум е н т а «П л а н п р о в е д е н и я з а н я т и й в г р уп п е » Информационная структура документа «План проведения занятий в группе» с выделенными объектами ГС и ПЛАН, описана в подразделе 2.4.3.3, и приведена на Рис. 2.6. Реквизитный состав объекта ГС для представления в машинной памяти в соответствии с этим описанием имеет вид: – «Ном_ГС» – первичный ключ; – «Группа» – неключевой атрибут; – «Семестр» – неключевой атрибут. 133 В этом же подразделе приведен реквизитный состав объекта ПЛАН для представления в машинной памяти: – «Ном_плн» – первичный ключ; – «Предмет» – неключевой атрибут; – «Вид_занятия» – неключевой атрибут; – «Вид_сдачи» – неключевой атрибут; – «Часы» – неключевой атрибут; – «ФИО_прп» – неключевой атрибут; – «Ном_ГС» – вторичный ключ. Для явного представления связи между объектами ГС и ПЛАН в машинной памяти в объект ПЛАН дополнительно введен атрибут «Ном_ГС». В этом случае мы имеем структуру документа «План проведения занятий», приведенную на Рис. 3.7. ПЛАН ПРОВЕДЕНИЯ ЗАНЯТИЙ В ГРУППЕ ГС Ном_ГС Группа Семестр К_ГРУППА К_СЕМЕСТР ПЛАН Ном_плн Предмет Вид_занятия Вид_сдачи Часы ФИО_прп Ном_ГС К_ПРЕДМЕТ К_ВИД_занятия К_ВИД_сдачи К_ФИО_преп Рис. 3.7 – Связи объектов ПЛАН и ИЗУЧЕНИЕ документа «План проведения занятий» 134 3.5.2.4 И н ф о р м а ц и о н н а я с т р ук т ур а д о к у м е н т а «Э кзаменационная ведомость » Информационная структура документа «Экзаменационная ведомость» описана в подразделе 2.4.3.4, и приведена на Рис. 2.7. Эту структуру нам придется модифицировать, т. к. при определении реквизитного состава объекта ВЕДОМОСТЬ было отмечено, что часть его реквизитов будут извлечена из объектов ГС и ПЛАН документа «План проведения занятий в группе». Для этого добавим в объект ВЕДОМОСТЬ реквизит «Ном_плн». В результате для объекта ВЕДОМОСТЬ определяется следующий реквизитный состав: – «Ном_вдм» – первичный ключ; – «Дата» – неключевой атрибут; – «Ном_плн» – вторичный ключ. Каждому экземпляру объекта ВЕДОМОСТЬ соответствует множество экземпляров объекта ОЦЕНКА (мощность множества соответствует количеству студентов в группе), что означает наличие между ними связи типа . Для реализации этой связи в БД необходимо добавить в объект ОЦЕНКА реквизит «Ном_вдм». В реквизиты объекта ОЦЕНКА также добавляется поле для определения вторичного ключа, и после его введения мы имеем следующий реквизитный состав: – «Ном_оц» – первичный ключ; – «ФИО_стд» – неключевой атрибут; – «Оценка» – неключевой атрибут; – «Подп_прп» – неключевой атрибут; – «Ном_вдм» – вторичный ключ. С помощью связи «Ном_плн – Ном_плн» между объектами ВЕДОМОСТЬ и ПЛАН мы можем извлечь из документа «План проведения занятий в группе» недостающие реквизиты документа «Экзаменационная ведомость». Этими реквизитами являются: «Предмет», «ФИО_прп» и «Вид_сдачи». Оставшиеся реквизиты «Группа» и «Семестр» извлекаются из объекта ГС, используя связь «Ном_ГС – Ном_ГС» между объектами ГС и ПЛАН документа «План проведения занятий в группе», как показано на Рис. 3.8. 135 ЭКЗАМЕНАЦИОННАЯ ВЕДОМОСТЬ ВЕДОМ Ном_вдм Дата Ном_плн ОЦЕНКА Ном_оц ФИО_стд Оценка Подп_преп Ном_вдм К_Студент К_Оценка К_Подп_преп ПЛАН ПРОВЕДЕНИЯ ЗАНЯТИЙ В ГРУППЕ ГС Ном_ГС Группа Семестр ПЛАН Ном_плн Предмет Вид_сдачи ФИО_прп Ном_ГС Рис. 3.8 – Зависимости между объектами ГС, ПЛАН, ВЕДОМОСТЬ и ОЦЕНКА документа «Экзаменационная ведомость» 136 Из приведенного описания следует важный вывод: исходя из требований без избыточного представления данных документов в машинной памяти, информационная структура документа может быть составлена таким образом, что она будет отличаться от его исходной структуры, представленной в УФД. Для восстановления этой структуры при выполнении информационно-расчетных задач и отображении документа используются связи между объектами информационной модели. 3.5.3 КОНЦЕПТУАЛЬНАЯ СХЕМА БД ПРО Теперь у нас есть все необходимое для разработки концептуальной схемы, представляющей собой описание структуры всех единиц информации (объектов ПрО), хранящихся в БД, а также связей между ними. Наша задача на данном этапе заключается в том, чтобы на основе информационно-логических схем документов создать концептуальную схему БД в терминах таблиц, их строк и колонок с выявленными связями между ними. Предварительная работа для такого преобразования была уже проведена и описана в подразделе 3.5.2, в рамках которой реквизитный состав объектов был представлен в терминах ключевых и неключевых атрибутов. При этом были выделены родительские и дочерние объекты связей, а реквизитный состав дочерних объектов был модифицирован с целью явного определения связей между объектами при их представлении в машинной памяти. После выполнения описанных преобразований реквизитного состава объектов, полученных в рамках разработки внемашинного ИО, можно приступить к разработке концептуальной структуры реляционной БД, являющейся адекватным отображением полученной информационно-логической схемы, не требующей дополнительных преобразований. При этом каждый объект информационно-логической схемы отображается реляционной таблицей, а вторичные ключи, введенные при модификации дочерних объектов, в паре с первичными ключами соответствующих родительских объектов образуют связи между ними. 137 Структура реляционной таблицы определяется реквизитным составом соответствующего информационного объекта, где каждый столбец (поле) соответствует одному из реквизитов объекта. Ключевые реквизиты (реквизиты-признаки) объектов образуют уникальные ключи реляционных таблиц. Для каждого столбца задается формат и размер данных, т. е. определяется либо тип данных, поддерживаемый СУБД, либо домен, базирующийся на одном из встроенных типов данных. Строки (записи) таблицы, идентифицируемые значением соответствующего ключевого поля, определяют экземпляры объекта и формируются при загрузке таблицы. Связи между объектами модели данных реализуются реквизитами, имеющими одинаковый смысл (представленными как в родительской, так и дочерней таблицах), и называемыми ключами связи в соответствующих таблицах. При этом ключом связи родительской таблицы всегда является уникальный, т.е. первичный ключ. Ключом связи в подчиненной таблице является поле, областью значений которого является множество значений первичного ключа родительской таблицы. Ключ связи в дочерней таблице называется внешним (или вторичным) ключом. На Рис. 3.9 приведена схема данных, отображающая концептуальную схему реляционной БД рассматриваемой ПрО «Учебный процесс». На этой схеме прямоугольниками обозначены таблицы БД с полным списком их полей, а связи показывают, по каким полям (первичных и вторичных ключей) осуществляется взаимосвязь таблиц. Имена полей первичных ключей выделены и находятся в верхней части полного списка полей каждой таблицы. Стрелка связи исходит от первичного ключа родительской таблицы и входит в поле вторичного ключа дочерней таблицы. В концептуальной схеме также отражены таблицы словарей, реализованных на основе кодовых сущностей, разработанных на этапе создания СККИ внемашинного ИО (описание см. в подразделе 2.4.4). 138 Данные документа «План проведения занятий в группе» Данные документа «Список студентов группы» СТУДЕНТ Ном_стд ФИО_стд 9 Год_рождения Адрес Прох_балл ГС Ном_ГС Группа 1 Семестр 6 ГРУППА Группа 1 Кол_студ Средн_балл Группа 1 ПЛАН Ном_плн ОЦЕНКА Предмет 11 Вид_занятия 5 Вид_сдачи 7 Часы ФИО_прп 10 Ном_ГС Ном_оц ВЕДОМ ФИО_стд 9 Оценка 8 Подп_прп 12 Ном_вдм Дата Ном_плн Ном_вдм ПРЕПОД Таб_ном КАФЕДРА Кафедра Данные документа «Экзаменационная ведомость» 2 Назв_кафедры 2 Заведующий 10 Телефон ФИО_прп 10 Год_рождения Уч_степень 3 Уч_звание 4 Кафедра Данные документа «Список преподавателей кафедры» 2 Обозначения кодовых сущностей 1 К_Группа 5 К_Вид_занятия 9 К_ФИО_стд 2 К_Кафедра 6 К_Семестр 10 К_ФИО_прп 3 К_Уч_степень 7 К_Вид сдачи 4 К_Уч_звание 8 К_Оценка 11 К_Предм 12 К_Подп_прп Рис. 3.9 – Концептуальная схема БД ПрО 139 В схеме также выделены атрибуты, использующие для ввода значений данные этих таблиц. Для этого справа от атрибута сущности приведен закрашенный кружочек с соответствующим номером. Для наглядности таблицы БД, сформированные на основе общих документов, сгруппированы, хотя для схемы БД этот фактор не имеет значения и никак не фиксируется в системном каталоге. Структура данных, представленная на этой схеме, получена путем анализа структур документов ПрО «Учебный процесс». Обратите внимание на то, что объекты ГС и ПЛАН, представленные в двух УФД, на концептуальной схеме представлены в единственных экземплярах, но связи между этими объектами, а также между объектами ВЕДОМОСТЬ и ОЦЕНКА представлены в том составе, как были описаны в подразделе 3.5.2. В разделе 1.3 было отмечено, что схема БД не в полной мере соответствует структуре данных документов описываемой ПрО, и было показано, каким образом меняются данные документов при представлении связей между объектами документа в машинной памяти. При формировании логической схемы БД, для которой уже определена СУБД, наименования реквизитов представляются в форме, отличающейся от их представления в документах. Например, большинство современных СУБД требует представления наименований таблиц и их полей одним словом, т.е. словосочетания не допускаются. Поэтому, как правило, словосочетания превращаются в слова путем замены пробелов символами «нижняя черта». При формировании схемы БД также выясняется, что в ней отсутствуют данные о форматировании документов, так как эти данные не нужны при выполнении информационно-расчетных задач создаваемой АС. Но с развитием диалоговых средств АС появились возможности наглядного представления данных в виде привычных для специалистов в области ПрО (ДЛ ОУ) бумажных документов. И тут же обнаружилось, что данные о форматировании документов, проигнорированные на этапе разработки схемы БД, приходится восстанавливать на этапе программирования экранных форм для ввода и вывода информации. 140 Таким образом, в ходе машинного представления данных в рамках современной технологии разработки ИО АС допускается их неполное соответствие данным ПрО. Неполнота представления данных в описанной части ИО АС компенсируется на этапе разработки ПО, что может привести к повышению трудоемкости создания программ и АС в целом. КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Дайте определение внутримашинного ИО. 2. В чем заключается назначение внутримашинного ИО. 3. Опишите требования, предъявляемые к внутримашинному ИО. 4. Опишите способы организации внутримашинного ИО. 5. Дайте краткое описание локальных и распределенных БД. 6. Опишите организацию внутримашинного ИО на основе локальных файлов. 7. Опишите организацию внутримашинного ИО на основе БД. 8. Дайте краткое описание трехуровневой архитектуры ANSISPARC. 9. Опишите уровни архитектуры ANSI-SPARC и отображения между этими уровнями представления данных. 10. Опишите функции и общее значение системного каталога. 11. Опишите, каким образом СУБД обеспечивает независимость данных от программ. 12. Дайте определение понятий логической и физической независимости данных. 13. Опишите особенности организации АС с СУБД. 14. Объясните, что означает термин архитектура «клиент-сервер». Опишите преимущества, которыми обладает эта схема. 15. Опишите двухуровневую архитектуру «клиент-сервер». 16. Опишите трехуровневую архитектуру «клиент-сервер». 17. Опишите порядок выделения показателей из набора реквизитов. 18. Опишите порядок выделения объектов из набора реквизитов. 141 Использование данных, хранящихся в ИБ АС, человеком непосредственно, без помощи технических и программных средств, невозможно, т.к. данные в машинной памяти хранятся в формах, недоступных для восприятия органами чувств человека. Поэтому в человеко-машинных системах, каковыми являются АС, требуется посредник между внутримашинной ИБ и человеком. В качестве такого посредника используется набор средств, обеспечивающих доступ различных категорий пользователей к программным и информационным ресурсам АС, представляющих собой ее лингвистическое обеспечение. 4.1 ВЗАИМОДЕЙСТВИЕ ЧЕЛОВЕКА И МАШИНЫ 4.1.1 ВИДЫ ВЗАИМОДЕЙСТВИЯ ЧЕЛОВЕКА И МАШИНЫ Проблема эффективного взаимодействия человека и машины, возникла с появлением первых вычислительных машин. На начальном этапе внедрения вычислительной техники в сферу управления непосредственно со средствами автоматизации работали только программисты и операторы, т.е. специалисты в области вычислительной техники. Общение специалистов в управленческой деятельности или конечных пользователей с машиной сводилось к выдаче программистам и операторам заданий на разработку программ, решающих задачи и выдающих распечатки готовых результатов. 142 В задачах такого рода большой удельный вес занимали работы по составлению отчетов о производственно-хозяйственной деятельности, выполняемой органами управления различных уровней. Организация вычислительного процесса в этом режиме строилась практически без доступа пользователя к машине. Его функции ограничивались только подготовкой исходных данных и передачей их в центр обработки, где формировался пакет, включающий задание машине на обработку программы, а также вводом исходных, нормативно-расценочных и справочных данных. Далее пакет вводился в машину и выполнялся в автоматическом режиме без участия оператора. Поэтому описанный способ взаимодействия был назван пакетным взаимодействием. В дальнейшем по мере совершенствования аппаратных и программных средств вычислительной техники было реализовано интерактивное взаимодействие, предусматривающее более сложный вид обмена информацией пользователя с машиной. Это взаимодействие было реализовано в виде одноразового запроса (как правило, регламентированного) или диалога с машиной, когда пользователь и машина попеременно обмениваются информацией. Запросный режим используется пользователями для взаимодействия с системой при решении оперативных задач справочно-информационного характера, таких как резервирование билетов на транспорте, номеров в гостиничных комплексах, выдачи справочных сведений и т.д. Машина в подобных случаях работает в режиме разделения времени, при котором несколько независимых пользователей со своих устройств ввода-вывода могут выдать в процессе решения своих задач запрос на непосредственный доступ к ресурсам машины. При этом пользователи, действуя независимо друг от друга, могут выдавать свои запросы практически одновременно. Этот режим должен обеспечить в строго установленном порядке представление каждому пользователю времени для общения с машиной, а после окончания сеанса отключать его. Диалоговый режим позволяет пользователю непосредственно взаимодействовать с машиной в допустимом для него темпе рабо143 ты, выполняя повторяющийся цикл выдачи задания, получения и анализа ответа. При этом в некоторых случаях машина сама может инициировать диалог, определяя для пользователя последовательность шагов (например, путем представления меню) для получения искомого результата. Рассмотренные разновидности интерактивного взаимодействия получили бурное развитие с появлением персональных компьютеров, устанавливаемых на рабочих столах конечных пользователей, которые буквально перевернули наши представления о месте и роли вычислительной техники в жизни общества. Для персональных компьютеров было разработано множество программ, предназначенных для работы неподготовленных пользователей. Эти программы не требовали от них глубоких знаний информационных технологий, а были просты в использовании и интуитивно понятны. В качестве таких программ, в первую очередь, были созданы различные редакторы текстов, электронные таблицы и другие. С их появлением проще стало выполнять такие обыденные операции как копирование файлов, перенос информации с одного компьютера на другой, распечатка текстов, таблиц и т.д. Эти революционные изменения в вычислительной технике вовлекли в процесс непосредственного взаимодействия с машиной специалистов различных областей автоматизируемой ПрО, в результате чего сформировались две группы пользователей: – представители первой группы, т.е. эксплуатационный персонал (специалисты в области вычислительной техники), занимаются вводом информации в систему и решением заранее предопределенных регламентных задач по поддержке работы машины; – задача пользователей второй группы, т.е. конечных пользователей (или специалистов предметной области), заключается в использовании информации, вырабатываемой с помощью пользователей первой группы, для подготовки и принятия управленческих решений. Специфика работы конечных пользователей требует создания для них таких средств и методов взаимодействия с вычислительной системой, благодаря которым они, не зная архитектуры и принци144 пов функционирования компьютера, не владея профессиональными приемами программирования, могли бы самостоятельно удовлетворять свои информационные потребности. Именно для решения этой задачи создается лингвистическое обеспечение АС, реализуемое путем систематизации терминов и понятий автоматизируемой предметной области, выработки правил формализации естественного языка, используемых для создания информационных языков взаимодействия пользователей со средствами вычислительной техники. 4.1.2 ДОКУМЕНТ КАК ЕДИНИЦА ОБМЕНА ИНФОРМАЦИЕЙ В АС Основное назначение АС заключается в поддержании состояния ее внутримашинной ИБ в актуальном состоянии путем реализации информационного обмена между системой и пользователями, а также системой и другими взаимодействующими системами. Информация в социальных системах представляется в форме документов – материальных объектов с информацией, создаваемых для передачи и приема социальной информации в пространстве и времени по каналам связи, и рассматриваемых как средства социальной коммуникации. Документ как средство коммуникации представляет собой сообщение и содержит в себе собственно информацию и различную служебную информацию. Содержательная часть, т.е. собственно информация документа представлена постоянной и переменной частями (см. пункт 2.1.3.2). Служебная информация документа используется для организации обмена, постоянная часть информации документа, общая для всех его экземпляров, может быть представлена в программном коде в виде структурной составляющей документа, используемой для формирования сообщения, и только переменная часть информации документа используется как передаваемая или принимаемая информация. Описание документа с точки зрения организации его содержания в БД было дано в первой и второй главах пособия. В данном 145 подразделе опишем документ как средство передачи информации, т.е. как сообщение. Информационное сообщение – это законченная в смысловом отношении информация (информация взаимообмена), представленная в соответствии с установленными правилами и предназначенная для обмена между компонентами (включая пользователей) АС. Сообщения, полученные в ходе информационного обмена, сохраняются в памяти машины, что можно интерпретировать как передачу сообщения во времени. При этом информация содержательной части сообщения преобразуется в формат представления переменной части документа в БД, с тем, чтобы в любой момент времени данные сообщения можно было использовать для: – просмотра другими пользователями с целью решения управленческих задач; – логической обработки программными средствами; – передачи в другие системы. Виды сообщений. С точки зрения обработки данных сообщения выделяются формализованные и неформализованные сообщения. Формализованные сообщения – это сообщения, реализованные на основе формализованных документов, создание и анализ которых осуществляется программными средствами в соответствии с установленными правилами (см. подраздел 1.3.3). Возможность формирования анализа сообщений программными средствами определяется тем обстоятельством, что структура информационной составляющей формализованных сообщений соответствует информационно-логической модели документа (см. подраздел 1.3.4) и может быть представлена в памяти машины в виде совокупности взаимосвязанных записей БД. Элементы информационно-логической модели документа, определяют объекты информационного языка уровня сообщений и представляют внутримашинное описание других форм сообщений, используемых при реализации различных видов информационного обмена. В БД экземпляры типовых документов должны быть связаны с типовыми сообщениями, т.е. переменные данные каждого докумен146 та передаются определенным сообщением, как об этом уже было сказано выше. Причем, код документа и код сообщения, которым передаются переменные данные документа, могут совпадать. При этом каждый типовой документ должен быть привязан к соответствующей экранной форме ввода данных и просмотра документа. Неформализованные сообщения – сообщения, информационная часть которых представляет собой текст (последовательность символов в принятой кодировке), сформированный посредством соответствующих программных средств (редакторов). Для неформализованного сообщения в форматах описания сообщений указываются общие характеристики сообщения, структура служебной части сообщения, форма представления информационной части сообщения (произвольный текст, диаграмма и т.п.). Неформализованное сообщение может передаваться как самостоятельный файл или по правилам формализованного сообщения. Но в этом случае содержательная часть сообщения не подлежит автоматической обработке. Фиксируется только факт получения сообщения. Дальнейшее изложение в данном подразделе относится в основном к формализованным сообщениям, создаваемым на основе переменной части документов, хранящихся в БД, в которых сосредоточена львиная доля информации современных АС. Структура сообщения. Как уже было отмечено, сообщение состоит из адресно-служебной и информационной частей. Адресно-служебная часть сообщения предназначена для указания характеристик, идентифицирующих документ в системе, определяющих его принадлежность должностным лицам, а также других параметров, обеспечивающих автоматическое доведение сообщения по сетям передачи данных до абонента-получателя в требуемом режиме. Здесь содержатся сведения о режиме передачи, типе, варианте передачи (циркулярный, избирательный), категории срочности, конфиденциальности сообщения. В этой же части содержатся логические адреса отправителя и получателя. 147 Информационная часть сообщения является его содержательной частью, включающей семантически законченную информацию об объекте и его характеристиках, представленной в переменной части документа. Формы сообщения. Сообщение в ходе информационного обмена представляется в логической, визуальной (экранной) и физической форме. Сообщение в логической форме реализуется в виде совокупности взаимосвязанных записей в БД и представляет собой его внутримашинное описание, на основе которого создаются другие формы сообщений для реализации различных видов информационного обмена. Сообщение в экранной (визуальной) форме предназначено для информационного обмена между машиной и человеком и реализуется в виде экранной формы с: – пустыми полями, оставленными для заполнения пользователем, при вводе элементов данных сообщений в БД; – заполненными полями, для просмотра пользователем, при выводе элементов данных сообщений из БД. Сообщение в физической форме представления предназначено для обмена информацией между программными средствами различных АС через каналы связи и реализуется в виде кодограммы с последовательной структурой, в элементах которой содержатся значения полей записей БД. 4.1.3 ЛО АС КАК СРЕДСТВО ФОРМИРОВАНИЯ ФОРМАЛИЗОВАННЫХ СООБЩЕНИЙ Программные средства АС во взаимодействии с пользователями должны обеспечивать: – создание формализованных сообщений, предназначенных для передачи содержания документов; – при приеме содержательная часть документа должна восстанавливаться из входящего формализованного информационного сообщения. 148 В рамках создания ЛО АС должны быть разработаны унифицированные механизмы, позволяющие формировать из переменной части документов содержательную часть формализованных сообщений и, наоборот, из содержательной части формализованных сообщений – переменную часть документов. Эти механизмы должны обеспечивать: – считывание фрагментов БД для формирования переменной части документа; – создание формализованных сообщений путем установления соответствия между элементами документа и элементами содержательной части сообщений. Для этого должны быть разработаны соответствующие правила кодирования содержательной части формализованных сообщений на основе анализа переменной части документа, считанной из БД; – восстановление переменной части документа при приеме формализованных сообщений предполагает декодирование содержательной части и размещение выделенных элементов сообщения в элементах ; – разбор информации содержащейся в переменной части документа с последующей ее записью в БД. Именно с помощью этих механизмов реализуются информационные языки, в совокупности составляющие ЛО АС, обеспечивающие совместную работу пользователей АС со средствами вычислительной техники в режиме диалога. В предыдущем подразделе было отмечено, что экранная и физическая формы сообщений реализуются на основе их внутримашинного представления, определяющей объекты информационного языка уровня сообщений. Справедливо и обратное, сообщения в визуальной и физической формах могут быть преобразованы в их внутримашинные представления. Эти взаимно-обратные преобразования обеспечиваются тем, что информационная часть сообщения в экранной и физической формах имеет структуру, тождественную структуре информационнологической модели документа, т.е. логической формы сообщения. Отличие этих форм сообщений заключается в том, что: 149 – экранная форма предназначена для визуального восприятия, т.е. для передачи человеку, и размещена в двумерном пространстве; – физическая форма предназначена для передачи по проводам в удаленные системы и реализуется в одномерном пространстве; – логическая форма предназначена для хранения в БД, т.е. для передачи во времени. В рамках создания ЛО АС описанные преобразования форм сообщения должны быть реализованы в виде унифицированных механизмов, позволяющих формировать из внутримашинного представления сообщений в БД содержательные части сообщений различных видов. ЛО АС должно обеспечивать также выполнение обратных преобразований, в ходе которых по принятым сообщениям БД пополняется актуальными сведениями о событиях, происходящих в моделируемой системе. Для выполнения информационного обмена в АС реализуются следующие преобразования форм сообщения: – ввод данных осуществляется путем преобразования визуальных данных сообщения в формат хранения в БД, т.е. в виде взаимосвязанной совокупности записей; – отображение сообщения на экране осуществляется путем преобразования сообщения из формата хранения в БД в визуальную форму; – передача данных по каналу связи осуществляется путем преобразования сообщения из формата хранения в БД в физическую форму; – прием данных по каналу связи осуществляется путем преобразования сообщения из физической формы в формат хранения в БД. Приведенные преобразования осуществляются программными модулями, поэтому полезно описать формальное представление этих процедур. Для этого сформулируем следующие положения. 1. Все виды обмена информацией, имеющие место в АС, можно рассматривать как информационный процесс, для реализации которого необходимы источник информации, канал связи и приемник информации. При этом: 150 – источник формирует и передает информацию, а приемник ее получает; – информация передается в виде сообщений, определяющих форму и представление передаваемой информации; – сообщение от источника передается посредством какой-нибудь среды, называемой «каналом связи». 2. В качестве каналов связи для организации информационного процесса используются: – зрительный канал – для передачи информации в пространстве от системы человеку и от человека системе; – линии электрической передачи сигналов – для передачи информации в пространстве другой системе и от другой системы; – память машины – для передачи информации во времени, которая может быть использована как человеком, так и для передачи другой системе. 3. Информация документа в АС, оформленная в виде сообщения, предназначенная для: – восприятия человеком (как при передаче, так и при приеме) представляется в визуальной форме в виде экранной формы; – передачи во времени (т.е. хранения в памяти машины) представляется в виде совокупности взаимосвязанных записей в БД; – передачи в пространстве представляется в виде кодограммы, т.е. одномерной последовательности значений полей записей. Приступая к формальному описанию компонентов информационного процесса, в первую очередь, определим документ как носитель информации, состоящий из трех логических частей (о составе документа см. также подраздел 7.1.1): – контента – содержания документа; – структуры – информации, обеспечивающей сборку документа из элементов контента; – формы – информации, обеспечивающей материализацию документа в виде визуализации (для представления на экранной форме) или сериализации (для представления в кодограмме). 151 Имея в виду приведенное определение документа, представим формальное описание процедур преобразования форм сообщения, перечисленных выше. 1. Процедура ввода данных документа в память системы обозначается выражением , в котором символы в квадратных скобках означают, что данные о структуре и форме документа, используемые для создания экранной формы , встроены в программный код реализации процедуры. Символ в круглых скобках означает, что данные контента, вводимые через экранную форму являются входными аргументами процедуры, отображаются на экране и заносятся в структуру БД, соответствующей структуре . Ввод данных документа реализуется путем выполнения следующей последовательности функций: – формирования сообщения на экранной форме ; – преобразования визуальной формы сообщения в логическую форму и его записи в БД в соответствии с выражением . При выполнении данной процедуры данные о форме документа в памяти машины не сохраняются. 2. Процедура отображения на экране данных документа, хранимых в базе, обозначается выражением , в котором символы в квадратных и круглых скобках имеют тот же смысл, что и в предыдущем описании. Различие заключается в том, что символ в данном случае означает контент, считанный из БД. Отображение данных документа реализуется путем выполнения следующей последовательности функций: – считывания логической формы сообщения из БД; – преобразования логической формы сообщения в визуальную и отображение его на экране в соответствии с выражением . При выводе на экран документа данные о его визуальном представлении, отсутствующие в памяти машины, восстанавливаются, т.к. в программный код процедуры встроены сведения как о визу- 152 альном представлении (т.е. о форме ) элементов документа, так и об их размещении на площади документа (т.е. о структуре ). 3. Процедура передачи данных документа по каналу связи обозначается выражением . В данную процедуру вложена только информация о структуре передаваемого сообщения. Передача данных документа по каналу связи осуществляется путем выполнения функций: – считывания логической формы сообщения из БД; – преобразования логической формы сообщения в физическую форму и передачи в канал связи в соответствии с выражением . В сформированной кодограмме отсутствуют сведения о форме сообщения. Хотя информация о структуре сообщения в кодограмме в явном виде не представлена, но ее можно закодировать путем размещения элементов передаваемого сообщения в заданных позициях кодограммы. 4. Процедура приема данных документа, поступивших по каналу связи, обозначается выражением . В данную процедуру вложена только информация о структуре передаваемого сообщения. Прием данных документа по каналу связи осуществляется путем выполнения функций: – считывания принятых по каналу связи элементов данных физической формы сообщения ; – преобразования физической формы сообщения в логическую форму и записи его в БД в соответствии с выражением . При записи сообщения в память машины данные о его структуре восстанавливаются, т.к. в программный код процедуры приема данных документа встроены сведения о структуре путем указания соответствия позиции кодограммы элементу сообщения, сохраняемому в памяти. Путем комбинирования описанных процедур можно организовать циклы информационного обмена между компонентами локальной АС, так и между локальной и удаленными АС. 153 4.2 ОСНОВНЫЕ ПОНЯТИЯ ЛО АС Выше было отмечено, что элементы информационно-логической модели документа, хранимые в памяти системы, экранных форм, используемых для визуализации сообщений, и кодограмм, предназначенных для обмена информацией через каналы связи, представляют собой объекты информационного языка. Описание информационного языка АС, составленное на основе применения правил формализации естественного языка, реализуется в рамках разработки ЛО АС. 4.2.1 ОПРЕДЕЛЕНИЕ, НАЗНАЧЕНИЕ, ЦЕЛИ ЛО АС Определение ЛО. Под лингвистическим обеспечением АС понимается совокупность словарей терминов и понятий, а также средств и правил для формализации естественного языка, используемых при общении ДЛ (конечных пользователей и эксплуатационного персонала) с АС (вычислительной системой) при ее функционировании. В состав ЛО необходимо включить: – систему словарей терминов и понятий; – правила формализации естественного языка, включая методы смысловой обработки текстов, представленных на естественном языке; – информационные языки или языковые средства взаимодействия ДЛ с КСА. Основное назначение ЛО. С помощью ЛО осуществляется общение человека с АС, и его главное назначение заключается в предоставлении удобных и эффективных средств взаимодействия ДЛ с КСА, включающие в свой состав различные диалоговые формы представления информации. Цели ЛО. ЛО АС направлено на достижение следующих основных целей: – упрощения взаимодействия ДЛ с КСА путем максимально возможного приближения информационного языка системы к естественному; 154 – унификации информационного языка системы для реализации единых принципов обработки информации, выполняемых при решении задач взаимодействия ДЛ с КСА; – стандартизацию представления, отображения и документирования оперативной информации в АС. 4.2.2 ТРЕБОВАНИЯ К ЛО При разработке ЛО АС необходимо учитывать: – состав и содержание функций, выполняемых ОУ; – специфику используемой информации; – возможности и ограничения технических средств системы по вводу и отображению информации; – возможности программного и информационного видов обеспечения АС. Кроме того, необходимо предусмотреть возможность расширения и модификации ЛО при изменении обстановки (например, при изменении состава и содержания выполняемых функций, изменении информации предметных областей или конфигурации технических средств системы). ЛО и поддерживающие его средства должны обеспечивать унификацию решений при создании АС путем настройки на различные технологии обработки информации и сценарии взаимодействия пользователей с КСА в зависимости от сложившейся обстановки. При этом в результате реализации сценария должны обеспечиваться возможности: – получения стандартных справок, либо произвольной информации заданного вида в любые моменты времени с возможностью генерации или ввода запросов на ограниченном естественном языке; – формализации входных сообщений на естественном языке путем их перевода на информационный язык системы, конкретный вид которого определяется прикладными программами, реализующими обработку данных; – интерпретации запросов ДЛ, реализуемых в ходе диалогового взаимодействия, путем обработки информации в соответствии с текущим состоянием БД, с возможностью реакции на ошибочные си155 туации выдачей диагностических сообщений об ошибках и несанкционированных действиях ДЛ; – ведения диалогов, инициируемых как системой, так и пользователем. 4.2.3 СОСТАВ ЛО АС В состав лингвистического обеспечения должны входить: – средства формализации естественного языка; – информационные языки. Средства формализации естественного языка представляют собой определенный перечень выполняемых действий программиста при разработке экранных форм, обеспечивающих диалоговое взаимодействие ДЛ с программными средствами АС. Отображение соответствующих реквизитов экранных форм осуществляется в терминах профессионального языка и наименований из системы словарей и классификаторов СККИ. К средствам формализации естественного языка относятся: – система словарей терминов; – правила формализации информации; – методы и способы выделения, представления содержания информационных сообщений. Система словарей терминов содержит термины и определения понятий автоматизируемой ПрО для обязательного применения при разработке конструкторской документации на разрабатываемую систему, а также при составлении информационных сообщений. Правила формализации информации включают методы сжатия и развертывания текстов, представленных на естественном языке, а также способы кодирования информации. Методы и способы выделения, представления содержания информационных сообщений включают описания методов формирования наборов данных, составляющих содержание информационного сообщения, и способов его представления ДЛ. Информационные языки предназначены для обеспечения удобства работы ДЛ с АС, а также для работы с информацией, хранящейся в базе данных и сокращения количества ошибок, возникающих в 156 процессе работы. Информационные языки предлагается построить на основе применения диалоговых средств взаимодействия ДЛ с АС. Эти средства служат для передачи содержания документов, сообщений, запросов, результатов решения информационно-расчетных задач, а также используются для формализации информации при обмене сообщениями между ДЛ и АС. Информационные языки содержат в своем составе следующие группы языков: – описания данных; – манипулирования данными; – проектирования и программирования; – управления функционированием АС (и ее обслуживанием). Языки описания данных и манипулирования данными АС реализованы в языке SQL используемой СУБД, разработанной сторонней организацией, и входят в состав ОПО АС. В качестве языков проектирования и программирования используются языки программирования высокого уровня и его трансляторы (компиляторы), разработанные сторонними организациями, которые входят в состав ОПО АС. Языки управления функционированием АС, осуществляющие взаимодействие ДЛ и обслуживающего персонала с АС в диалоговой форме, реализуются в составе СПО АС в виде пользовательских интерфейсов. Далее, для краткости изложения, языки управления функционированием АС будем именовать пользовательскими интерфейсами (ПИ). 4.3 СРЕДСТВА ФОРМАЛИЗАЦИИ ЕСТЕСТВЕННОГО ЯЗЫКА 4.3.1 СИСТЕМА СЛОВАРЕЙ ТЕРМИНОВ Система словарей терминов АС представляет собой упорядоченный перечень языковых единиц (слов, словосочетаний и т.п.) с характеристиками обозначаемых ими понятий и составляет терминологическую основу процессов формирования, хранения, ведения и использования информационных фондов и хранилищ информации 157 разрабатываемой и эксплуатируемой АС. Условно все словари можно разбить на два типа. 1. К первому типу словарей относится группа словарей, применяемых при проведении эскизно-технического проектирования АС, а также словарная информация и терминология, установленная государственными стандартами. Предлагается включать в данную группу словарей также устоявшиеся и применяемые термины в рассматриваемой ПрО. Терминологическая информация, используемая на стадии проектирования АС, представляет собой связанную систему терминов понятий, в которой объясняются и уточняются отношения между понятиями, устанавливается эквивалентность между терминами. Таким образом, терминологическая система, используемая на стадии проектирования АС, строится на основе: – терминологических стандартов; – терминологических разделов нормативных документов; – словарей терминов и определений различных ПрО. Из приведенного перечня источников должны быть отобраны термины ПрО создаваемой АС, применяемые при разработке эскизно-технической и конструкторской документации на разрабатываемую систему. Отобранные словарные статьи должны быть оформлены в виде системы словарей терминов разрабатываемой АС и утверждены в установленном порядке. 2. Основной целью создания системы словарей второго типа является обеспечение всех категорий пользователей АС унифицированной лексикой, используемой для представления оперативной информации в процессе ее эксплуатации. Второй тип словарей реализуется в машинной памяти на этапе создания ИО АС в виде словарей и классификаторов СККИ и используется при составлении входных и выходных сообщений, составленных на информационном языке системы. Машинные словари используются в основном в процессе трансляции входных и выходных сообщений, и именно с их помощью реализуются методы сжатия и развертывания текстов, представленных на естественном языке, при преобразованиях: 158 – входных сообщений, представленных на информационном языке системы, в машинную форму; – выходных сообщений (результатов обработки информации и решения задач), представленных в машинной форме, на информационный язык системы. 4.3.2 ПРАВИЛА ФОРМАЛИЗАЦИИ ИНФОРМАЦИИ Правила формализации данных должны обеспечивать представление информации во входных и выходных сообщениях системы в виде, предназначенном для их автоматической обработки программными средствами АС и не допускать избыточности и неоднозначности представления информации. С этой целью при создании АС используется кодирование информации, которое заключается в замене слов и словосочетаний естественного языка их условными обозначениями – кодами, удовлетворяющими требованиям машинной обработки. Кодирование информации осуществляется на этапе создания СККИ, входящей в состав ИО АС. При этом информация не только кодируется, но и группируется или классифицируется в словарях и классификаторах, как это было описано в подразделах 2.2.3 и 2.2.4. Правила формализации данных, включающие методы сжатия и развертывания текстов, а также способы кодирования информации, представляют собой совокупность методов и способов перевода информации с естественного языка на внутренний язык системы. Эти правила используются при вводе, хранении, поиске, обновлении и передаче данных с целью сокращения времени передачи и доступа к данным. Правила формализации являются обязательными для выполнения предписаниями (положениями), в соответствии с которыми осуществляется представление информации в АС. Эти правила устанавливают набор разрешенных к применению терминов, перечень сокращенных обозначений и порядок их употребления. 159 Правила формализации излагаются в инструкциях (руководствах оператора) по работе с соответствующими компонентами информационного и программного обеспечения АС. 4.3.3 МЕТОДЫ И СПОСОБЫ ВЫДЕЛЕНИЯ, ПРЕДСТАВЛЕНИЯ СОДЕРЖАНИЯ ИНФОРМАЦИОННЫХ СООБЩЕНИЙ Выделение и представление содержания информационных сообщений осуществляется с помощью экранных форм, разрабатываемых в ходе создания ПО, и составляющих основу языков управления функционированием АС. Экранные формы используются для представления информационных сообщений ДЛ АС в визуальной форме как при вводе и выводе. С этой целью для каждого типа информационного сообщения должна быть создана соответствующая экранная форма, входящая в состав информационного языка АС. Выделение содержания информационного сообщения для представления ДЛ осуществляется с помощью языка манипулирования данными, описанного в подразделе 4.4.2. При этом используются возможности внедрения операторов языка SQL в программные коды, описанные в преамбуле раздела 4.4. Возможность включения операторов языка SQL непосредственно в программный код обеспечивается практически во всех современных языках программирования. Это дает возможность программным средствам АС формировать выражение запроса на языке SQL без участия человека и передать в СУБД для выполнения. СУБД выполняет запрос и формирует набор данных в соответствии с условием выборки, содержащемся в полученном выражении запроса. Сформированный набор данных представляет собой содержание информационного сообщения, передаваемое ДЛ АС. Описанный метод выделения, представления содержания информационных сообщений является доминирующим в современных АС. При этом языки управления функционированием АС (т.е. пользовательский интерфейс) строятся на основе экранных форм как совокупностей средств и способов, обеспечивающих взаимодействие человека с АС. Именно экранные формы делают доступными пользователям функциональные возможности аппаратных и 160 программных средств АС, и именно с их помощью пользователи осуществляют информационный обмен с машиной. Экранные формы АС должны содержать языковые средства, позволяющие осуществлять: – подготовку, ввод и обработку документальной информации; – подготовку, ввод и обработку фактографической информации; – подготовку, ввод и обработку графической информации; – ввод запросов; – управление ходом выполнения задач; – управление технологическими процессами; – управление техническими средствами. 4.4 ИНФОРМАЦИОННЫЕ ЯЗЫКИ При описании состава ЛО АС было отмечено, что к информационным языкам относятся: языки описания и манипулирования данными, языки проектирования и программирования АС и языки общения ДЛ (пользователей, персонала) с АС. Из перечисленных средств представления данных языки описания и манипулирования данными, а также языки проектирования и программирования не разрабатываются в ходе создания АС, а поставляются в покупных СУБД и инструментальных средствах разработки компонентов информационного, лингвистического и программного обеспечения. Языки описания (DDL – Data Definition Language) и манипулирования (DML – Data Manipulation Language) данными входят в состав структурированного языка запросов SQL, предназначенного для работы с данными и поставляются в составе СУБД [15]. Языки проектирования и программирования АС, используемые при разработке компонентов ее информационного, лингвистического и программного обеспечения, входят в состав интегрированных сред разработки. Интегрированные среды разработки облегчают процедуру создания и отладки программного кода на языках программирования высокого уровня, таких как Pascal, C++, Java. Следует также отметить, что в современных инструментальных средствах разработки ПО АС предусмотрена возможность внедре161 ния операторов языка SQL в программные коды, написанные на языках программирования высокого уровня. Таким образом, из перечисленного перечня информационных языков только языки общения ДЛ с КСА создаются в ходе разработки АС. Именно эти языки используются персоналом АС для доступа к ее ресурсам в ходе реализации интерактивной формы взаимодействия с целью ведения БД АС, а также использования ее данных при решении задач управления. 4.4.1 ЯЗЫК ОПИСАНИЯ ДАННЫХ – DDL Язык DDL позволяет программисту: – описать и именовать сущности и атрибуты, необходимые для работы некоторого приложения; – устанавливать связи, имеющиеся между различными сущностями; – указать ограничения целостности и защиты. С помощью языка DDL определяется схема базы данных, состоящая из набора определений, выраженных в терминах его конструкций. Язык DDL может использоваться как для определения новой схемы, так и для модификации уже существующей. Данный язык не предназначен для управления данными. В результате выполнения скриптов DDL-операторов в СУБД формируется набор таблиц, сведения о которых хранятся в специальных таблицах БД, входящих в состав системного каталога. В системном каталоге содержатся метаданные, представляющие собой данные, описывающие объекты базы данных. Метаданные включают определения таблиц, их атрибутов, связей между таблицами, а также других объектов, представляющих интерес для пользователей или необходимых для работы СУБД. Перед доступом к реальным данным СУБД обращается к системному каталогу. Именно наличие системного каталога позволяет СУБД реализовать доступ к произвольным БД путем выполнения незапланированных, т.е. произвольных запросов. 162 4.4.2 ЯЗЫК МАНИПУЛИРОВАНИЯ ДАННЫМИ – DML Язык DML – это язык, содержащий набор конструкций для формирования выражений запросов для выполнения операций манипулирования содержащимися в базе данными. Язык манипулирования данными можно определить как высокоуровневый узкоспециализированный язык, предназначенный для удовлетворения различных требований по выборке и обновлению информации, содержащейся в БД. Именно с помощью конструкций DML осуществляется формирование и выделение содержания информационного сообщения для представления ДЛ АС. Другими словами, язык манипулирования данными является посредником между информационным языком системы, представляющим сообщения ДЛ в визуальной форме, и внутримашинным представлением этих сообщений в БД. К операциям манипулирования данными, с помощью которых внутримашинные представления сообщения преобразуются в форму пригодную для использования в информационных языках, и обратно, относятся: – вставка в базу данных новых записей; – обновление записей, хранимых в базе данных; – выборку записей, содержащихся в базе данных; – удаление записей из базы данных. Поддержка языка манипулирования данными является одной из основных функций СУБД, которая позволяет пользователю создавать выражения запросов для выполнения перечисленных выше операций, которые к тому же и выполняются СУБД с помощью ее унифицированных процедур. 4.4.3 ЯЗЫКИ ПРОЕКТИРОВАНИЯ И ПРОГРАММИРОВАНИЯ Языки программирования. Современные языки программирования поставляются в составе интегрированных сред разработки (ИСР англ. IDE, Integrated development environment), предоставляющих в распоряжение разработчиков комплекс средств редактирования, отладки и сборки кода на языках программирования высокого уровня. 163 Как правило, ИСР разработки включает в себя: – текстовый редактор; – компилятор и/или интерпретатор; – средства автоматизации сборки; – отладчик. Иногда ИСР содержит также средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов для использования при объектно-ориентированной разработке ПО. Хотя и существуют ИСР, предназначенные для нескольких языков программирования такие, как Eclipse, NetBeans, Qt Creator или Microsoft Visual Studio, как правило, ИСР предназначается для одного определённого языка программирования как, например, Java, C++, Pascal. ИСР были созданы для того, чтобы максимизировать производительность программиста благодаря тесно связанным компонентам с простыми пользовательскими интерфейсами. Их применение заменяет использование разрозненных инструментов, таких как компиляторы, текстовые редакторы и т.п. При этом разработчик выполняет меньше действий для переключения различных режимов, чем при использовании отдельных средств разработки. 4.4.4 ЯЗЫКИ УПРАВЛЕНИЯ ФУНКЦИОНИРОВАНИЕМ АС Языки управления функционированием предназначены для общения персонала с аппаратными и программными средствами АС в диалоговой форме взаимодействия. На основе языков взаимодействия строятся пользовательские интерфейсы как совокупности способов и средств, обеспечивающих взаимодействие человека с КСА. Именно ПИ обеспечивают доступ персонала к функциональным возможностям аппаратных и программных средств АС. Для сокращения сроков разработки ПИ представляются в унифицированной структуре. Унифицированная структура интерфей- 164 сов позволит сократить время не только разработки, но и время, требуемое на освоение программно-технических средств системы. В качестве ПИ в современных АС используются экранные формы АС. Экранные формы АС разрабатываются в соответствии с Руководящими указаниями Главного конструктора АС, определяющими порядок разработки УФД (на этапе разработки УСД внемашинного ИО) и экранных форм АС. Разработанные на этапе создания внемашинного ИО УФД представляются в альбоме УФД и являются основой для разработки экранных форм АС. Пользовательский интерфейс системы и его связи с компонентами ИО. Пользовательский интерфейс системы, используемый в качестве языка общения пользователя с АС, по существу, является языком-посредником между естественным языком человека и машинным информационным языком. Использование ПИ системы должно позволять: – во-первых, организовывать взаимодействие ДЛ органов управления с АС при решении задач и обработке данных с помощью информационных процедур; – во-вторых, упрощать алгоритмы обработки оперативной информации, так как данные, вводимые с помощью ПИ, формализуются в соответствии с требованиями машинной обработки. Отображение информации, реализуемой при обмене сообщениями, осуществляется посредством экранных форм, по возможности моделирующих документы автоматизируемой социальной системы. Таким образом, с помощью экранных форм ДЛ должны иметь возможность формировать документы по определенным правилам. Графический интерфейс пользователя GUI. В настоящее время за стандарт ПИ принят графический интерфейс пользователя GUI (Graphics Users Interface), в основу построения которого положены следующие принципы [18]. Простота – является признаком наилучшей конструкции и предполагает, чтобы окно приложения открывало поверх себя как можно меньше окон дочерних приложений. Относительно же самого окна следует отметить, что оно должно содержать минимум од165 новременно необходимых рабочих и управляющих элементов (таблицы, кнопки, списки и т.п.). Логичность. Логично созданный ПИ позволяет быстро и удобно получать необходимые данные, переходить из одного окна или приложения в другое, при этом действия пользователя должны быть предопределены последовательностью обработки информации, и не создавать их многозначность. Все этапы работы с приложениями должны быть последовательно взаимоувязаны, с возможностью возврата на предыдущие этапы с целью изменения данных, которые указываются пользователем, для тех или иных действий, заложенных в приложении. Структура GUI. На основании сказанного можно сформулировать основные требования к структуре типового окна приложения, обеспечивающего взаимодействие с пользователем. Подобное типовое окно должно иметь: – заголовок окна; – кнопки системного меню, закрытия, минимизации и максимизации; – область меню пользователя и область панели управления; – рабочую область с необходимыми рабочими и управляющими элементами; – статусная строка приложения. Дополнительно следует отметить, что: – отдельные рабочие и управляющие элементы могут быть недоступны пользователю до выполнения им определенных обязательных действий; – при необходимости окно приложения должно блокировать все действия пользователя, не связанные с этим приложением, до выхода из него; – пользователь должен быть уверен, что его команды исполняются, т.е. важна обратная связь с приложением; – контекстная справка, появляющаяся при задержке указателя мыши на элементах панели управления, должна кратко характеризовать действия, возникающие при активизации данного элемента. 166 Требования к GUI. ПИ в стандарте GUI, должен строиться на основе общих понятий и принципов проектирования ПИ, налагающих ограничения на использование компонентов интерфейса, их физической, синтаксической и семантической согласованности. При этом: – проектирование панелей различных типов должно осуществляться на основе унифицированных конструктивных элементов (полей, ячеек, областей, меню, курсоров, заголовков, кнопок и др.); – проектирование диалогов должно осуществляться на основе унифицированных действий (отказ, команда, ввод, выход и т.д.) и всплывающих окон; – должны быть использованы вспомогательные функции (справки, подсказки, сообщения); – должны быть использованы дополнительные указания (назначения клавиш, способы выделения элементов панели). При разработке элементов интерфейса (например, списка элементов и объектов), окон интерфейса, а также организации диалога, необходимо использовать словари и классификаторы АС (созданные на этапе разработки СККИ внемашинного ИО и реализованные во внутримашинном ИО), которые являются лексической основой информационного языка системы. Основное окно ПИ. В качестве центра организации диалога с системой (подсистемой) создается основное окно ПИ, из которого вызываются остальные экранные формы ПИ. Обязательными атрибутами основного окна интерфейса каждой структурной подсистемы (или главного экрана) должны являться: – текущая дата и время; – идентификатор (название) главного экрана; – главное меню; – перечень абонентов, с которыми возможно взаимодействие. Основное окно должно также включать: – информационную строку для отображения сведений о поступивших сообщениях, документах, видеоизображениях со счетчиком количества поступивших сообщений; – указатели (счетчики) на количество поступивших сообщений и ожидающих подписи документов. 167 На главном меню главного окна должны располагаться меню и пиктограммы, с помощью которых выполняются основные и часто используемые пользовательские операции: – предоставление справочной информации об объектах системы; – выбор, обработка, управление отображением и документирование данных о состоянии системы, ее элементов, объектов и о состоянии взаимодействующих систем; – обмен с абонентами локальной вычислительной сети и сети обмена данными формализованной и неформализованной информацией, в т. ч. сообщениями, содержащими оперативную информацию; – автоматическое и интерактивное формирование ответных сообщений, посылаемых на запросы; – отображение картографической и другой графической и текстовой информации; – ввод-вывод информации из БД; – контроль доступа к БД системы; – вывод на печатающие устройства документов и другой информации в пределах полномочий ДЛ; – контроль технического состояния аппаратных средств объекта. Обмен документами с помощью ПИ. При формировании документов в процессе диалога ДЛ с системой должны быть предоставлены следующие возможности: – ввод с клавиатуры неформализованного документа; – помещение готового документа в архив; – использование в качестве прототипа документа любого ранее сформированного документа из числа, хранящихся в архиве; – выделение частей документа с целью их раздачи соисполнителям в процессе коллективной разработки документа и фиксации сроков разработки частей документа и их исполнителей в специальном журнале в базе данных; – автоматическая сборка документа из частей; – выдача документа на печать; – отправка документа или указанных его частей по КС указанным адресатам; 168 – просмотр полученных по КС документов и передача их другим адресатам, как целиком, так и по частям. При получении документа на АРМ должно формироваться уведомление, которое формируется автоматически в виде так называемой квитанции. Единицей информации взаимообмена является весь документ или его шаблон (прототип), который передается, хранится и тиражируется как единое целое. При формировании конкретного формализованного документа с помощью меню должен осуществляться выбор нужного бланка и заполнение его переменных полей. При формировании, поиске и отборе формализованных документов ДЛ должны быть предоставлены возможности, аналогичные перечисленным выше для неформализованных документов. Кроме того, при обработке формализованных документов ДЛ должна быть предоставлена возможность формирования документа на основе информации, имеющейся в базе данных. 4.5 ПРИМЕР РАЗРАБОТКИ ЛИНГВИСТИЧЕСКОГО ОБЕСПЕЧЕНИЯ ДЛЯ АВТОНОМНОЙ АС В данном разделе приведем описание примера разработки ЛО АС для ПрО «Учебный процесс» включающего в свой состав: – систему словарей терминов и понятий; – правила формализации естественного языка; – способов выделения информационных сообщений на экранных формах; – информационный язык АС «Учебный процесс», реализованный в виде совокупности экранных форм. 4.5.1 СИСТЕМА СЛОВАРЕЙ ТЕРМИНОВ И ПОНЯТИЙ Основной целью разработки системы словарей для использования в информационных языках АС является обеспечение всех категорий пользователей унифицированной лексикой, используемой для представления оперативной информации на этапе эксплуатации системы. Эта лексика должна быть привычной для пользователей си- 169 стемы (т.е. для ДЛ АС) и по этой причине ее целесообразно составлять из лексических элементов, используемых в системе документов автоматизируемой ПрО. Путем изучения системы УФД, разработанной на этапе разработки внемашинного ИО, отбираются те лексические элементы, которые могут быть использованы при разработке пользовательского интерфейса АС. При этом для каждой УФД может быть составлен словарь терминов, используемых при разработке экранных форм пользовательского интерфейса для ввода данных соответствующих документов. Реквизиты и показатели, используемые в разных документах, должны быть унифицированы с тем, чтобы не допускать использования: – одинаковых терминов для обозначения разных реквизитов; – а также разных терминов для обозначения одних и тех же реквизитов. Например, реквизит «Фамилия И.О.» в документе «Список студентов группы» используется для представления студентов, а в документе «Список преподавателей кафедры» – для представления преподавателей. В данном случае одно и то же наименование используется для обозначения разных реквизитов, поэтому предлагается присвоить этим реквизитам другие наименования, например, «ФИО студ.» и «ФИО преп.». С другой стороны в разных документах, а иногда даже в одном документе, один и тот же реквизит может именоваться по-разному. Например, для представления преподавателей в документах: – «Список преподавателей кафедры» используются наименования «Фамилия И.О.»; – «План проведения занятий в группе» – наименование «Фамилия И.О.» – «Экзаменационная ведомость» – наименование «Преподаватель». Поэтому для представления преподавателей во всех документах предлагается использовать наименование «ФИО преп.». Унификация написания наименований реквизитов была проведена уже на этапе разработки УСД, а значений реквизитов – на этапе 170 разработки СККИ внемашинного ИО (описание см. в подразделах 2.4.3 и 2.4.4). На этапе разработке ЛО отобранные лексические элементы систематизируются и могут быть разбиты на категории: – наименования документов (например, наименование документа «Список студентов группы» ПрО «Учебный процесс»); – наименования реквизитов (например, наименование «Адрес» реквизита в документе «Список студентов группы»); – значения реквизитов (например, значение «ул. Мира, д. 1» реквизита «Адрес»). Словари, описанные в подразделе 2.4.4, составляются для реквизитов, используемых в разных документах, а также имеющих четко определенный перечень значений, которые при их представлении на пользовательских интерфейсах АС: – с одной стороны, определяют стандартизованное написание наименований реквизитов; – с другой стороны, предоставляют пользователю возможный перечень значений для реквизитов. При разработке внутримашинного ИО словари реализуются в виде таблиц БД (описание см. в подразделе 0), которые могут быть использованы программистами для их отображения на экранных формах в виде единиц информационных языков. Таблица 4.1. Наименования документов (экранных форм) № пп Наименование 1 Список студентов группы 2 Список преподавателей кафедры 3 План проведения занятий 4 Экзаменационная ведомость 171 Таблица 4.2. Наименования реквизитов документа «Список студентов группы» № пп Наименование Область значений 1 Группа Поле «Наим-ие» словаря «К_Группа» 2 Ном. пп Натуральный ряд чисел 3 ФИО студ. Поле «Наименование» словаря «К_ФИО_Студ» 4 Год рождения Компонент «Дата» системы 5 Адрес Строка 6 Прох. балл Число с запятой Таблица 4.3. Наименования реквизитов документа «Список преподавателей кафедры» № пп Наименование Область значений 1 Назв. кафедры Поле «Наименование» словаря «К_Кафедра» 2 Код кафедры Поле «Краткое наим-ие» словаря «К_Кафедра» 3 Заведующий Поле «Наименование» словаря «К_ФИО_Преп» 4 Телефон Строка формата цц-цц-цц 5 Таб. ном Пятизначное целое число 6 ФИО преп. Поле «Наименование» словаря «К_ФИО_Преп» 7 Год рождения Компонент «Дата» системы 8 Уч. степень Поле «Наименование» словаря «К_Уч_степень» 9 Уч. звание Поле «Наименование» словаря «К_Уч_звание» Таблица 4.4. Наименования реквизитов документа «План проведения занятий в группе» № пп Наименование Область значений 1 2 Группа Семестр Поле «Наим-ие» словаря «К_Группа» Поле «Наим-ие» словаря «К_Семестр» 3 Код предм. Поле «Краткое наименование» словаря «К_Предм» 4 Назв. предм. Поле «Наименование» словаря «К_Предм» 172 № пп Наименование Область значений 5 ФИО преп. Поле «Наименование» словаря «К_ФИО_Преп» 6 Таб. ном. Пятизначное целое число 7 Вид занятия Поле «Наименование» словаря «К_Вид_занятия» 8 Часы Целое число Таблица 4.5. Наименования реквизитов документа «Экзаменационная ведомость» № пп Наименование Область значений 1 Номер Строка 2 3 Назв. предм. Группа Поле «Наименование» словаря «К_Предм» Поле «Наименование» словаря «К_Группа» 4 Преподаватель Поле «Наименование» словаря «К_ФИО_Преп» 5 Вид сдачи Поле «Наименование» словаря «К_Вид_сдачи» 6 Семестр Поле «Наименование» словаря «К_Семестр» 7 Дата Компонент «Дата» системы 8 Ном. пп Натуральный ряд чисел 9 10 ФИО студ. Оценка Поле «Наименование» словаря «К_ФИО_Студ» Поле «Наименование» словаря «К_Оценка» 11 Подп. преп. Поле «Наименование» словаря «К_ФИО_Преп» Описанная система словарей (см. таблицы 4.1 – 4.5), предназначенная для использования в информационных языках АС в качестве лексических элементов информационных сообщений, отображаемых на экранных формах. Данная система словарей утверждается руководством на соответствующем уровне и в дальнейшем должна служить в качестве руководящих указаний для программистов при разработке экранных форм ПИ. Следует отметить, что общепризнанного регламента разработки описанной системы словарей на сегодняшний день не существует и порядок их создания в лучшем случае определяется Руководящими указаниями Главного конструктора АС или другими регламентирующими документами. 173 4.5.2 ПРАВИЛА ФОРМАЛИЗАЦИИ ЕСТЕСТВЕННОГО ЯЗЫКА В АС «УЧЕБНЫЙ ПРОЦЕСС » Правила формализации данных, отображаемых на экранных формах, в форму, предназначенную для их автоматической обработки программными средствами АС, в данном примере реализуются с помощью словарей, описанных в подразделе 2.4.4, и реализованных при создании схемы БД (описание см. в подразделе 0). Словари используются для кодирования наименований реквизитов документов, введенных с экранной формы. Процесс преобразования наименования (т.е. термина информационного языка) в код (т.е. в термин на машинном языке) описан ниже в подразделе 4.5.4. Процедура преобразования наименования в код с помощью словарей реализуется просто и описывается следующим образом. Введенное с экранной формы наименование сравнивается со значениями поля «Наименование» соответствующего словаря. При совпадении значений фиксируется значение поля «Код» текущей строки словаря, и таким образом реализуется преобразование наименования в код. Следует отметить, что каждое поле ввода экранной формы, значение которого требуется преобразовать в код, должно быть связано с соответствующим словарем БД. Такая связь реализуется на этапе разработки программного кода экранной формы. В нижеследующем подразделе 4.5.4 приеден пример преобразования наименования группы, введенного с экранной формы, в код. Для этого поле ввода наименования группы должно быть связано со словарем БД К_Группа. После ввода наименования группы введенное значение сравнивается со значениями поля «Наименование» словаря К_Группа. Значение поля «Код» строки данного словаря, в которой произошло совпадение, является кодом введенного наименования группы. Аналогично реализуется и обратное преобразование: «Код» → «Наименование». Данные в БД, как правило, хранятся в кодовом виде. Такая форма представления удобна для проведения обработки программными средствами АС, но неудобна для восприятия человеком. Поэтому при выводе на экранную форму кодовых значений по- 174 лей БД требуется преобразовать их в термины машинного языка, т.е. в наименования. Например, при выводе на экран кода группы также используется словарь К_Группа. Отличие заключается в том, что в данном случае сравниваются коды, а наименование, соответствующее коду, выводится как результат преобразования. Следует также отметить, что в описанных преобразованиях используется язык манипулирования данными, описанный в подразделе 4.4.2. Именно с помощью выражений этого языка реализуется поиск строки с искомыми значениями (как наименования, так и кода) в словарях. Для этого программист использует прием внедрения операторов языка SQL в программные коды, обеспечиваемый современными языками программирования. Программное средство АС преобразует полученную конструкцию в выражение запроса на языке SQL и передает СУБД. СУБД выполняет запрос и возвращает искомое значение (наименование или код) в программное средство АС. 4.5.3 ИНФОРМАЦИОННЫЙ ЯЗЫК АС «УЧЕБНЫЙ ПРОЦЕСС» С помощью информационного языка, реализованного в виде совокупностей экранных форм, пользователи осуществляют манипуляции с данными внутримашинной ИБ АС. При этом экранные формы используются для: – ввода, обновления и удаления данных машинной памяти; – отображения данных машинной памяти для их представления пользователю в терминах информационного языка. Данные для выполнения перечисленных операций вводятся в терминах информационного языка, а при выполнении операций в машинной памяти преобразуются в термины внутримашинного представления. Экранные формы реализуются программистами с помощью: – УФД соответствующих документов для размещения лексических элементов словаря терминов на площади экранной формы; – словарей терминов, составленных для УФД, для определения и уточнения наименований экранной формы, наименований и значений реквизитов, размещаемых на экранной форме; 175 – таблиц словарей БД для связывания с элементами управления экранной формы с целью ввода данных документов в соответствующие поля таблиц БД, а также отображения значений полей БД в элементах управления экранной формы. Рис. 4.1 – Экранная форма для ввода данных документа «Список студентов группы» На приведенных в данном подразделе экранных формах представлены только информационные элементы, т.е. те, которые связаны с элементами БД в машинной памяти. Стандартные элементы управления (типа кнопок «OK», «Cancel»), на рисунках не представлены, как не имеющие отношения к освещению темы преобразования элементов информационного языка во внутримашинное представление и обратно. Рис. 4.2 – Экранная форма для ввода данных документа «Список преподавателей кафедры» 176 Языковые средства взаимодействия пользователя с АС для ПрО «Учебный процесс» представлены экранными формами для ввода и отображения данных документов: Рис. 4.3 – Экранная форма для ввода данных документа «План проведения занятий в группе» – «Список студентов группы» (см. Рис. 4.1); – «Список преподавателей кафедры» (см. Рис. 4.2); – «План проведения занятий в группе» (см. Рис. 4.3); – «Экзаменационная ведомость» (см. Рис. 4.4). Рис. 4.4 – Экранная форма для ввода данных документа «Экзаменационная ведомость» 177 Перечисленные экранные формы создаются следующим образом. 1. В качестве названий перечисленных экранных форм использованы наименования соответствующих документов, зафиксированные в поле «Наименование» таблицы «Наименования документов (экранных форм)» (см. Таблица 4.1). 2. Для определения порядка расположения реквизитов на экранной форме изучается соответствующая УФД из состава УСД внемашинного ИО. 3. В качестве названий реквизитов (в анкетной и табличной формах представления) использованы значения полей «Наименование» таблиц 4.2 – 4.5, содержащих наименования реквизитов для соответствующих документов. 4. Порядок ввода значений реквизитов определен в полях «Значение» таблиц 4.2 – 4.5, путем указания либо таблиц БД (словарей), предоставляющих необходимый перечень значений, либо характера вводимых пользователем в поля ввода значений (число натурального ряда, дата, строка и т.д.). При работе с экранными формами у ДЛ АС создается ощущение работы с документами, в ходе которой он пользуется привычными терминами своей области деятельности. При этом ему не требуется знать детали внутримашинного представления вводимых данных, т.к. он пользуется терминами естественного языка для ввода необходимых данных. Следует также подчеркнуть, что перечень используемых пользователем единиц естественного языка регламентирован при разработке внемашинного ИО и реализован в ходе разработки внутримашинного ИО и программных средств ЛО (т.е. экранных форм). 4.5.4 РЕАЛИЗАЦИЯ МЕТОДОВ И СПОСОБОВ ВЫДЕЛЕНИЯ ИНФОРМАЦИОННЫХ СООБЩЕНИЙ НА ЭКРАННЫХ ФОРМАХ АС «УЧЕБНЫЙ ПРОЦЕСС » Описанные в подразделе 4.5.3 экранные формы используются для выделения и представления содержания БД, реализованных в виде информационных сообщений, составляющих основу информационного языка АС. 178 Процесс выделения содержания информационного сообщения, осуществляемого с помощью экранной формы, опишем на примере работы одной из экранных форм (остальные описываются аналогично). В качестве примера выберем экранную форму «Список студентов группы», с помощью которой пользователем вводится наименование группы и при наличии в БД сведений о студентах выбранной группы на экране отображается список студентов этой группы с заданными атрибутами, т.е. выводится сообщение о состоянии объекта ГРУППА. Экранная форма 1 База данных 3 1. Поиск кода группы путем сравнения ее наименования, введенного с экранной формы, с наименованиями поля «Наим» таблицы «К_Группа» 2. Поиск записей со значением кода группы в поле «Группа» таблицы СТУДЕНТ 3. Вывод найденных записей из базы данных на экранную форму К_Группа СТУДЕНТ 2 Рис. 4.5 – Связи между элементами экранной формы для ввода (отображения) данных документа «Список студентов группы» и таблицами БД 179 Выведенные на экранную форму данные можно использовать: – как справочные сведения для принятия решения (например, по значению поля «Прох. балл» можно определить можно тем или иным студентам назначать повышенную стипендию или нет); – для обновления значений полей в соответствии с изменившейся обстановкой (например, обновление адреса студента при изменении места его жительства); – для удаления строки (например, при переводе студента в другую группу). В случае отсутствия сведений о студентах выбранной группы на экране отображается пустой список студентов. В этом случае экранную форму можно использовать для внесения данных о студентах выбранной группы (например, при формировании группы после вступительных экзаменов). Связи между элементами экранной формы «Список студентов группы» с элементами БД в машинной памяти и краткое описание процесса формирования информационного сообщения для вывода на экранную форму представлены на Рис. 4.5. 1. Поле ввода данных (в виде выпадающего списка), следующий за наименованием экранной формы, позволяет вводить наименование группы. Для этого данный выпадающий список в приложении должен быть связан с классификатором «К_Группа». При наличии этой связи нажатием значка «треугольник» в правой части выпадающего списка можно вывести список наименований групп для выбора. 2. По выбранному наименованию группы в таблице «К_Группа» БД фиксируется значение поля «Код» выбранной строки классификатора. Таким образом, с помощью словаря «К_Группа» осуществляется преобразование термина информационного языка в термин (т.е. код) машинного языка. 3. Далее в таблице СТУДЕНТ выделяются строки, в поле «Группа» которых содержатся значения, совпадающие с кодом группы, зафиксированным на предыдущем этапе. 180 4. Значения выделенных строк таблицы СТУДЕНТ БД отображаются в соответствующих полях строк таблицы экранной формы «Список студентов группы». Экранные формы представляют собой удобные средства взаимодействия пользователей с АС путем обмена информационными сообщениями: – при выводе данных по запросу пользователя (в нашем примере по введенному наименованию группы) машина формирует запрашиваемое сообщение и отображает его на экранной форме; – при вводе данных пользователь определяет экземпляр объекта, для которого формируется сообщение (в нашем примере это делается путем ввода наименования группы), затем на экранной форме вводятся требуемые элементы данных для формирования сообщения. 4.5.5 ВОЗМОЖНОСТИ ЛО АС (ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА) Пользовательский интерфейс, предназначенный для работы с УФД, должен обеспечивать возможности по выбору требуемых форм, активизацию требуемой экранной формы УФД или текстового редактора (специальной экранной формы). Для обеспечения анализа и обработки должностным лицом информации сообщений различной категории срочности на экране АРМ должно быть предусмотрено окно, содержащее сведения о поступающих сообщениях (окно оповещения о поступлении сообщений). В окне должны отображаться тип и вид, категория срочности, гриф конфиденциальности, вариант передачи, отправитель и адресаты сообщений. Выбранное в данном окне сообщение должно быть показано должностному лицу с предоставлением возможности передачи его на дальнейшую обработку. Окно должно автоматически появляться на экране дисплея при поступлении сообщения должностному лицу и исчезать с экрана по его команде. Ведение диалога ДЛ должно осуществляться на основе использования ограниченного естественного языка. При обработке формализованных документов, содержащих коды и сокращенные обозначения терминов, должна быть предусмотрена возможность вызова 181 соответствующих им наименований из классификатора или базового словаря. При формировании документов в процессе диалога должностному лицу должны быть предоставлены следующие возможности: – ввод с клавиатуры неформализованного документа; – помещение готового документа в архив; – использование в качестве прототипа документа любого ранее сформированного документа из числа, хранящихся в архиве; – выделение частей документа с целью их раздачи соисполнителям в процессе коллективной разработки документа и фиксации сроков разработки частей документа и их исполнителей в специальном журнале в базе данных; – автоматическая сборка документа из частей; – выдача документа на печать; – отправка документа или указанных его частей по каналам связи указанным адресатам; – просмотр полученных по каналам связи документов и передача их другим адресатам как целиком, так и по частям. Оперативный поиск и отбор документов должны осуществляться по следующим признакам: – коду формы; – адресам отправителей (получателей); – интервалу времени; – исходящему (входящему) номеру. При получении документа на АРМ должно формироваться уведомление, которое формируется автоматически при наличии в документе требования на выдачу подтверждения. Единицей информации взаимообмена является весь документ или его шаблон (прототип), который передается, хранится и тиражируется в АСУ как единое целое. При формировании конкретного формализованного документа с помощью меню должен осуществляться выбор нужного бланка и заполнение его переменных полей. В общем случае значениями переменных полей могут быть числа, коды (термины) или их сочетания. При вводе кода (термина) должна быть предусмотрена 182 подсказка путем вызова классификатора. При этом должен вызываться именно тот классификатор, который необходим для заполнения конкретного поля. При формировании, поиске и отборе формализованных документов должностному лицу должны быть предоставлены возможности, аналогичные перечисленным выше для неформализованных документов. Кроме того, при обработке формализованных документов должностному лицу должны быть предоставлены возможности выполнения операций: – ввода информации документа в базу данных; – формирования документа на основе информации, имеющейся в базе данных. В целях унификации ПО в АСУ рекомендуется использовать однотипный интерфейс пользователя, предназначенный для работы с УФД. КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Опишите режимы взаимодействия человека с компьютером. 2. Опишите определение, назначение, цели ЛО АС. 3. Перечислите требования к ЛО. 4. Опишите состав ЛО АС и дайте краткую характеристику каждого его компонента. 5. Опишите систему словарей терминов ЛО АС. 6. Опишите правила формализации информации, используемые в ЛО АС. 7. Опишите методы и способы выделения и представления содержания информационных сообщений. 8. Дайте определение и краткое описание языка описания данных – DDL. 9. Дайте определение и краткое описание языка манипулирования данными – DML. 10. Дайте определение и краткое описание языков проектирования и программирования АС. 11. Дайте определение и краткое описание языков управления функционированием АС. 183 12. Опишите пользовательский интерфейс АС и его связи с компонентами ИО. 13. Опишите графический интерфейс пользователя как средство реализации пользовательского интерфейса АС. 184 В первой части учебного пособия была рассмотрена технология создания ИЛО АС, спроектированного на основе СУБД, обеспечивающей поддержку абстрактной или логической модели ПрО и систематизирующей ее информацию по содержанию, структуре и связям. Это позволяет определять и поддерживать данные всей ПрО централизованно, что приводит к их интеграции. С другой стороны, начиная с 90-х годов, происходит быстрое развитие технологий сетевой связи и обмена данными, вызванное созданием сначала локальной, а затем и глобальной сети. В результате применения этих технологий при разработке АС, появилась возможность обмена данными между системами, выполняющими общие задачи. Это позволило создать техническую базу для реализации распределенных систем, в рамках которой при решении задач ДЛ могут быть использованы не только данные локальной АС, но и данные, размещенные на удаленных системах. Под влиянием этих тенденций технология обработки данных, являющаяся внутри отдельных АС централизованной, в масштабе распределенной системы снова становится децентрализованной. Это объясняется тем, что при объединении отдельных АС в интегрированные системы возникает вопрос о месте хранения данных сов- 185 местного использования. В результате многолетних дискуссий и практической работы был выработан ответ на этот вопрос: данные целесообразно хранить там, где они созданы и чаще всего используются. Именно данный способ хранения обеспечивает минимальный трафик в сети, а наличие современной сетевой инфраструктуры – приемлемые временные параметры по доступу к удаленным данным. В основе складывающейся инфраструктуры распределенной обработки данных лежат две революционные технологии взаимодействия компьютеров, разработанные в 80 - 90-е годы: – язык SQL и открытый стандарт ODBC, применяемый для соединения с БД, привели к развитию клиент-серверных архитектур в рамках локальных сетей; – технология взаимодействия компьютеров на основе протокола TCP/IP, высокоуровневый протокол гипертекстовых ссылок HTTP и язык HTML расширили возможности взаимодействия компьютеров до масштабов глобальной сети и усовершенствовали клиент-серверную архитектуру, добавив в нее третье звено. Перечисленные технологии открыли возможности создания распределенных систем, но следует иметь в виду, что язык HTML предназначен для визуального представления информации на экране, интерпретация которой осуществляется человеком. Поэтому данная технология не претендовала на всеобщее решение проблемы взаимодействия между удаленными АС, а охватывала только ее часть, касающуюся взаимодействия типа «человек-машина». Дальнейшее развитие распределенных систем связано с использованием технологии представления данных с помощью языка XML, которая кроме собственно данных содержит их описание, обеспечивающее автоматическую интерпретацию данных. Это существенно изменило отношение к данным, которые до этого рассматривались лишь как «сырье», обеспечивающее работу программ. С введением стандартов платформы XML данные приобрели относительную независимость, что позволило распределять их по местам создания и наиболее частого использования, сохранив при этом возможность доступа к ним с удаленных систем. При этом данные 186 распределенной системы образуют единое информационное пространство, в котором любая система имеет доступ как к локальным, так и удаленным данным. Рассмотрению принципов и проблем, связанных с разработкой ИО распределенных АС, качественно отличающихся от систем, основанных на централизованных БД, посвящена вторая часть учебного пособия. Важно иметь в виду, что решения, описываемые в этой части, на сегодняшний день еще не имеют широкого распространения и не являются повсеместно используемыми. Речь, скорее идет о тенденциях развития распределенного хранения и обработки данных, и системного изложения уже имеющихся решений и технологий. 187 Децентрализованный подход к хранению и обработке данных, складывающийся на современном этапе развития корпоративных систем, по сути, отражает организационную структуру многих компаний, подразделения и отделы которых распределены по разным офисам, отделениям, предприятиям или филиалам, причем каждая отдельная производственная единица имеет дело с собственным набором обрабатываемых данных. Технология обработки данных, учитывающая организационные структуры предприятий, обеспечивающая общедоступность данных, поддерживаемых каждым из существующих подразделений, и их хранение именно в тех местах, где они преимущественно используются, развивалась в рамках теории распределенных БД. 5.1 ОСНОВНЫЕ ПОНЯТИЯ РАСПРЕДЕЛЕННЫХ БД 5.1.1 ТРЕБОВАНИЯ К АС В УСЛОВИЯХ РАБОТЫ С РАСПРЕДЕЛЕННЫМИ ДАННЫМИ Современные АС развиваются в условиях глобализации экономики и становления общего информационного пространства на уровне корпораций, ведомств и государств. Эти условия оказывают огромное влияние на развитие АС и влекут за собой: – рост масштаба задач, решаемых информационными системами; 188 – рост числа сторон, участвующих в создании и использовании информации; – увеличение объемов обрабатываемой информации и частоты ее изменений; – распределение информации по местам ее создания и наибольшего использования. Эти факторы влекут за собой общие требования к информационным системам, заключающиеся в том, что они должны обладать гибкостью, масштабируемостью и открытостью [19]. Гибкость означает возможность настройки системы под информационные технологии пользователя, переносимость из одной среды эксплуатации в другую, независимость от конкретных компонент и приложений, участвующих в системе. Масштабируемость – это возможность построения (в том числе поэтапного) системы из готовых или стандартных компонентов. Это позволяет легко менять масштабы решаемых системой задач, изменять и поэтапно наращивать систему. Под открытостью понимается то, что информационная система базируется на мировых информационных стандартах. В качестве примера таких стандартов можно привести спецификации описания различных аспектов данных, определенные и описанные в рамках XML-платформы. 5.1.2 РАСПРЕДЕЛЕННАЯ БАЗА ДАННЫХ Технологии разработки ИО на основе централизованных данных, используемые для создания АС компактно размещенных предприятий, дают много преимуществ по сравнению с технологией разработки ИО на основе файловых систем. Но при использовании этой технологии для автоматизации деятельности компаний, чьи подразделения и филиалы географически разобщены, могут быть созданы АС, реализованные на основе несовместимых компьютерных архитектур, протоколов связи и т.д. Это объясняется тем, что такие системы могут быть созданы разными коллективами разработчиков, в разные периоды времени, и как следствие, в разной технологической среде. 189 Для решения подобного рода проблем, возникающих при автоматизации географически удаленных подразделений и филиалов, развивалась теория распределенной БД. Основной целью этой теории является такое представление БД отдельных подразделений и филиалов, чтобы пользователи АС воспринимали их как единую БД. Для начала приведем определения основных понятий теории распределенной БД. Распределенная база данных – это набор логически связанных совокупностей разделяемых данных (и их описаний), физически распределенных в глобальной компьютерной сети [17]. Распределенная СУБД – это программный комплекс, предназначенный для управления распределенными базами данных и обеспечивающий доступ пользователей к распределенной информации, как будто она содержится в единой базе данных [17]. Это важнейшее свойство распределенных СУБД называется прозрачностью, и характеризуется тем, что при его наличии действия пользователя при доступе к распределенным данным не отличается от его действий при доступе к локальным данным. Другими словами, распределение данных по разным базам должно быть прозрачным (незаметным) для конечного пользователя, и тот факт, что распределенная БД состоит из нескольких фрагментов, размещенных на различных компьютерах, не должен влиять на работу пользователей. При этом распределенная система внешне выглядит как централизованная, что является одним из основных принципов создания распределенных СУБД. Таким образом, распределенная СУБД управляет совокупностью баз данных, логически рассматриваемых как единая БД, состоящая из некоторого количества фрагментов. При этом каждый ее фрагмент может быть реализован на одном или нескольких компьютерах, работающих под управлением локальных СУБД, соединенных между собой глобальной сетью связи. Характеристики распределенной СУБД. Распределенная СУБД должна иметь следующие характеристики: – сохраняемые данные разбиты на некоторое количество фрагментов; 190 – между фрагментами данных имеют место логические связи; – узлы СУБД связаны между собой сетевыми соединениями; – на каждом узле СУБД могут иметь место локальные приложения; – на каждом узле СУБД должно быть хотя бы одно глобальное приложение. Топология распределенной СУБД, представленная на Рис. 5.1, показывает, что локальная БД на некоторых узлах системы может отсутствовать [17]. Узел 4 Узел 2 Узел 1 Компьютерная сеть БД Узел 3 БД БД Рис. 5.1 – Топология распределенной СУБД 5.1.3 ФУНКЦИИ И АРХИТЕКТУРА РАСПРЕДЕЛЕННОЙ СУБД Функции, архитектура и компоненты централизованных СУБД хорошо известны и были рассмотрены нами в первой части данного пособия (см. раздел 3.3). В этом подразделе рассмотрим, какое влияние на функциональные возможности и архитектуру СУБД оказывает распределение данных. Типичная распределенная СУБД должна обеспечивать все функции, присущие для централизованных СУБД, но, кроме этого, должна обладать следующими дополнительными возможностями: 191 – службы установки соединений должны обеспечивать доступ к удаленным узлам и позволять передавать запросы и данные между узлами, входящими в сеть; – средства ведения каталога, должны сохранять сведения о распределении данных в сети; – средства обработки распределенных запросов должны обеспечивать удаленный доступ к данным; – функции управления защитой должны обеспечивать соблюдение правил авторизации и прав доступа к распределенным данным. В подразделе 3.3.1 нами была рассмотрена трехуровневая архитектура для СУБД, рекомендованная ANSI-SPARC в качестве типового решения для централизованных СУБД. Но для организации распределенных СУБД данная архитектура не подходит, т.к. по характеру функционирования они существенно отличаются от локальных СУБД. Следует также отметить, что за годы интенсивного развития теории распределенной БД решения, учитывающие особенности работы распределенных систем, были выработаны и одно из них представлено на Рис. 5.2 и описано в работе [17]. В предлагаемой архитектуре распределенной системы содержатся следующие компоненты: – для каждой локальной СУБД, входящей в состав распределенной СУБД, представлена своя глобальная внешняя схема; – распределенная СУБД имеет общую глобальную концептуальную схему; – распределенная СУБД имеет общие схемы фрагментации и распределения; – каждая локальная СУБД, входящая в состав распределенной СУБД, должна соответствовать требованиям трехуровневой архитектуры ANSI-SPARC. Глобальная внешняя схема. Глобальная внешняя схема предложенной архитектуры определяет представление распределенной БД с точки зрения пользователей конкретных АС, и описывает ту часть распределенной БД, которая используется пользователями каждой АС распределенной системы. 192 Глобальная внешняя схема ... Глобальная внешняя схема ... Глобальная внешняя схема ... Локальная схема преобразования Глобальная концептуальная схема Схема фрагментации Схема распределения Локальная схема преобразования ... Локальная схема преобразования Локальная концептуальная схема Локальная концептуальная схема Локальная концептуальная схема Локальная внутренняя схема Локальная внутренняя схема Локальная внутренняя схема БД БД БД Рис. 5.2 – Трехуровневая архитектура ANSI-SPARC, рекомендуемая для распределенной СУБД Глобальная внешняя схема объединяет в себе внешние представления нескольких различных БД, управляемых собственными локальными СУБД, которые могут быть созданы различными производителями и иметь свои особенности представления данных. Задача глобальной внешней схемы заключается в том, чтобы нивелировать эти различия, т.е. внешнее представление распределенной БД должно быть инвариантным относительно этих особенностей и базироваться на некотором универсальном базисе, не зависящем от используемых компьютерных технологий. 193 Глобальная концептуальная схема. В глобальной концептуальной схеме представлено логическое описание всей совокупности баз данных, входящих распределенную систему, в виде единой базы данных. Этот уровень является аналогом концептуального уровню архитектуры ANSI-SPARC локальной СУБД. Его назначение заключается в: – определении распределенных сущностей и связей всех БД, входящих в распределенную систему, на единой основе; – поддержке ограничений ссылочной целостности для распределенных данных; – обеспечении защиты информации от несанкционированного доступа при распределенной обработке. На глобальную схему также возложена задача обеспечения физической независимости данных в распределенной среде. Схемы фрагментации и размещения. Схема фрагментации содержит информацию о логическом распределении данных по разделам концептуальной схемы. Схема размещения содержит информацию о расположении данных по конкретным АС, необходимую для доступа к ним с любого узла компьютерной сети. Локальные схемы. Кроме описанных глобальных определений каждая локальная СУБД имеет схемы, соответствующие уровням архитектуры ANSI-SPARC. Локальная СУБД содержит также локальную схему отображения, необходимую для преобразования элементов в схеме размещения. Эти элементы зависят от типа СУБД, поэтому для их использования в распределенной системе они должны быть преобразованы во внешние объекты, построенные на универсальном для всех узлов базисе. 5.1.4 ГЛОБАЛЬНЫЙ СИСТЕМНЫЙ КАТАЛОГ Для реализации глобальной концептуальной схемы, связанной со схемами фрагментации и размещения, а также содержащей данные о локальных схемах взаимодействующих АС, предложено организовать глобальный системный каталог. По функциональному назначению глобальный системный каталог и системный каталог централизованной БД совпадают, но с тем отличием, что в глобаль194 ном системном каталоге кроме описания собственно данных содержатся еще и схемы фрагментации, репликации и размещения. Глобальный системный каталог может быть построен по разным принципам: – может копироваться на всех локальных узлах; – данные обо всех локальных схемах могут располагаться на некотором централизованном узле; – иметь вид распределенной БД со схемами фрагментации и размещения. При полном копировании глобального системного каталога мы имеем большую избыточность и необходимость тиражирования его изменений на всех существующих узлах. А при использовании централизованного глобального каталога снижается надежность распределенной системы, так как отказ на центральном узле приводит к отказу всей системы. Глобальный системный каталог, построенный на основе распределенной БД свободен от перечисленных недостатков. В качестве примера реализации такого системного каталога можно привести систему R, описанную в работе [20]. В системе R на каждом узле содержится локальный системный каталог с метаданными о данных этого узла, в котором реализована определенная система именования и описания данных. Именно локальный каталог узла создания регистрирует определения данных и содержит информацию об их местонахождении. Если данные перемещаются в другое место, то сведения в локальном каталоге узла создания об этих данных должны соответствующим образом обновляться. Следовательно, для определения местонахождения удаленных данных необходимо получить доступ к локальному каталогу узла создания, сведения о которых фиксируются в каждом локальном экземпляре глобального системного каталога. В описанной системе R глобальный системный каталог организован в виде распределенной БД, что приводит к минимальной избыточности, высокой надежности работы системы и решает проблему обеспечения прозрачности именования. 195 5.2 ОСНОВНЫЕ ПРИНЦИПЫ РЕАЛИЗАЦИИ РАСПРЕДЕЛЕННЫХ БД При разработке распределенных БД возникают дополнительные факторы, которые при создании централизованных реляционных БД не имели существенного значения. К числу таких факторов относятся: Размещение. Главной особенностью распределенной системы является то, что она, в общем случае, представляет собой объединение разных БД, управляемых распределенной СУБД. Поэтому такую БД удобно рассматривать как состоящую из некоторого количества частей, называемых фрагментами. Фактор фрагментации, в свою очередь, вызывает проблему размещения (распределения) частей распределенной БД по различным узлам сети с точки зрения минимизации трафика. Именование. Еще одним важным фактором, требующим учета, является проблема именования объектов БД в разных ее фрагментах, так как в различных частях распределенной базы, созданных различными коллективами, необходимо гарантировать уникальность имен ее объектов. Использование различных СУБД. В общем случае распределенная СУБД создается на базе разнородных локальных СУБД. Хотя стандарт языка SQL предполагает, что внешний интерфейс доступа к данным для всех СУБД должен быть одинаковым, но на практике производители СУБД выходят за рамки этого ограничения. Поэтому выполнение одних и тех же запросов на разных СУБД требуют использования различных выражений запросов на языке SQL. Распределенная СУБД все эти факторы должна скрыть от пользователя, т.е. должна обеспечить прозрачность размещения, именования и использования различных СУБД. Прежде чем приступить к рассмотрению перечисленных типов прозрачности, необходимо отметить, что достижение полной прозрачности на сегодняшний день представляется чрезвычайно трудно реализуемой задачей. Теория распределенных БД находится еще на стадии развития и не все проблемы, стоящие на пути ее практического применения нашли 196 свое решение. Поэтому в данном разделе эти проблемы просто обозначены, а предлагаемые на сегодняшний день решения устраняют их лишь частично. 5.2.1 ПРОЗРАЧНОСТЬ РАЗМЕЩЕНИЯ Существуют три альтернативные стратегии размещения данных в распределенной системе: централизованное, с репликацией и раздельное (фрагментированное) [17]. Каждая из этих стратегий имеет свои достоинства и недостатки. При централизованном размещении на одном из узлов создается централизованная база данных, работающая под управлением СУБД, доступ к которой имеют все пользователи сети. Данный способ размещения называется «распределенной обработкой». В этом случае для всех узлов, за исключением центрального, для получения доступа к данным требуется установка сетевого соединения. Поэтому данная стратегия размещения имеет максимальный уровень затрат на передачу данных и низкую надежность, поскольку неисправность на центральном узле приведет к нарушению работы всей распределенной системы. Другая стратегия размещения, называемая размещением с репликацией, предусматривает копирование всей базы данных на каждом из узлов распределенной системы. Производительность работы, надежность, а также доступность данных в такой системе будут высокими, но затраты на хранение, передачу данных при обновлениях всех копий также будут максимальными. Стратегия размещения, когда БД разбивается на непересекающиеся фрагменты, каждый из которых размещается на одном из узлов системы, называется фрагментированным размещением. Распределение данных по разным узлам глобальной сети вместо их объединения в некоторую централизованную базу и организации к ним удаленного доступа представляется целесообразным, или копирования всей базы данных на каждом из узлов системы, имеет то преимущество, что в этом случае данные хранятся в тех местах, в которых они чаще всего используются. 197 Это приводит к существенному снижению трафика и повышению производительности работы распределенной системы в целом по сравнению с централизованными системами. Стоимость обеспечения надежности и доступности данных в данном способе размещения существенно ниже, чем в системе с репликацией. Поэтому по совокупности приведенных качеств фрагментированное размещение данных является наиболее приемлемым способом организации распределенной системы. При реализации прозрачности размещения распределенная БД воспринимается конечным пользователем как единая БД. При отсутствии прозрачности размещения в запросах на доступ к данным пришлось бы указывать имена и местонахождение ее фрагментов. Кроме этого составитель выражений запросов должен знать детали организации данных на удаленных узлах распределенной системы, что является основной проблемой удаленного доступа к данным. Можно предложить частичное решение этой проблемы путем размещения данных о местонахождении частей БД в схеме распределения, упомянутой в подразделе 5.1.3. Если данные о логических частях БД разместить в схеме фрагментации, то при наличии глобальной концептуальной схемы получаем практически полную реализацию глобального системного каталога, описанного в подразделе 5.1.4. Судя по этому описанию на сегодняшний день решены далеко не все вопросы его практической реализации и эта проблема пока еще находится на этапе теоретической проработки. 5.2.2 ПРОЗРАЧНОСТЬ ИМЕНОВАНИЯ Необходимость гарантировать уникальность имен ее объектов на всех узлах распределенной системы является прямым следствием требования наличия прозрачности размещения. На сегодняшний день наиболее популярны три способа обеспечения прозрачности имен [17]. Первым из этих способов является использование центрального сервера имен, отвечающего за уникальность всех существующих в 198 системе имен. Но данный способ имеет недостатки, свойственные всем централизованным системам: – центральный сервер имен, размещаемый на одном из узлов распределенной системы, превращается в узкое место всей системы, как в отношении производительности, так и надежности работы системы; – доступ к данным через единственный центральный узел снижает доступность данных системы в целом; – для присвоения имен локальным объектам необходимо обращаться к центральному серверу имен, что приводит к утрате локальной автономии. Другой, широко известный способ именования, связан с использованием префиксов, помещаемых в имена объектов. Эти префиксы идентифицируют узлы, на которых создаются объекты и, таким образом, даже в случае совпадения локальных имен будет гарантирована уникальность этих имен в распределенной системе. Недостатком данного способа именования является утрата прозрачности размещения, т.к. при обращении к объекту, пользователь должен знать его префикс, т.е. идентификатор узла, на котором он размещен. В уже упомянутой нами системе R (см. подраздел 5.1.4) разработан способ, согласно которому используются локальные и глобальные имена объектов [20]. Локальными называются имена, применяемые на конкретных узлах. На разных узлах один и тот же объект системы может именоваться по-разному. Локальные имена называются псевдонимами или синонимами и их преобразование в имена соответствующих объектов БД осуществляется распределенной СУБД. Кроме локальных имен объекту БД присваивается глобально уникальный идентификатор объекта, который на всех узлах системы остается неизменным. Данный способ гарантирует уникальность имен объектов БД в распределенной системе и, в то же время сохраняет прозрачность размещения, т.к. локальные имена не привязаны к узлам сети. 199 5.2.3 ПРОЗРАЧНОСТЬ ИСПОЛЬЗОВАНИЯ СУБД Обеспечение прозрачности использования СУБД актуальна для неоднородных распределенных СУБД и позволяет скрыть от пользователя тот факт, что на разных узлах могут функционировать различные типы локальных СУБД. Это один из самых сложных в реализации типов прозрачности, требующий размещения в глобальном системном каталоге особенностей формирования выражений запросов для каждого типа СУБД [17]. В общем случае в разнородной распределенной системе могут иметь место узлы, с иерархическими, сетевыми, реляционными и объектно-ориентированными СУБД. Но даже в случае использования только реляционных СУБД разных производителей проблема обеспечения прозрачности использования СУБД остается весьма сложной задачей, так как при этом распределенная система должна иметь возможность формулировать запросы на диалекте СУБД, размещенной на данном локальном узле. Типичное решение, применяемое в реляционных системах, заключается в том, что отдельные узлы разнородных распределенных систем используют шлюзы, предназначенные для преобразования входных выражений запросов с учетом особенностей языка SQL, применяемого на конкретном узле системы. 5.3 РАСПРЕДЕЛЕННЫЕ СИСТЕМЫ НА ОСНОВЕ РЕПЛИКАЦИИ ДАННЫХ Распределенные системы БД имеют несомненные преимущества перед традиционными централизованными системами БД, но недостаточная теоретическая обеспеченность вопросов организации распределенных данных, сложности практической реализации распределенных СУБД пока не позволяют говорить об их широком и повсеместном использовании в реально действующих АС. С другой стороны распределенные системы на основе репликации данных, несмотря на их существенные недостатки в плане стоимости хранения и обновления данных, находят все более широкое применение на практике. 200 Объясняется это тем, что, с одной стороны, практически каждый производитель СУБД реализует в своем продукте тот или иной механизм репликации, с другой стороны, существует много сторонних организаций, предлагающих решения для репликации данных, не зависящие от типов СУБД, используемых в сети. Поэтому можно констатировать, что на сегодняшний день распределенная обработка данных преимущественно реализована в системах с серверами репликации, которые являются более простым подходом к созданию распределенных систем. Репликация – это процесс создания и поддержки многочисленных копий данных, сформированных на одном из узлов распределенной системы. Данный механизм позволяет организовать доступ пользователям к актуальным данным независимо от того, на каком они узле произведены, причем тогда, когда они в этом нуждаются. Использование репликации позволяет достичь высокой производительности работы системы и надежности хранения данных, что обеспечивается наличием их резервной копии, т.к. данные, произведенные на одном узле, многократно дублируются на других узлах глобальной сети [17]. В этом разделе рассмотрим основные концепции механизма репликации данных. В первую очередь обсудим один из важнейших вопросов этого механизма: когда должны обновляться копируемые данные. 5.3.1 СИНХРОННАЯ И АСИНХРОННАЯ РЕПЛИКАЦИЯ Вопрос времени обновления данных решается в рамках разработки протокола обновления копируемых данных. Естественное решение этого вопроса заключается в том, что копируемые данные обновляются одновременно с изменением исходных данных. Данный вариант репликации называется синхронной репликацией. Хотя данный механизм репликации позволяет поддерживать абсолютную синхронность данных, но при частых изменениях исходных данных приходится формировать большое количество сообщений, необходимых для координации процесса синхронизации данных, что существенно нагружает глобальную сеть. 201 Поэтому на практике популярнее альтернативный механизм репликации, называемый асинхронным, согласно которому обновление данных осуществляется с некоторой задержкой в пределах от нескольких секунд до нескольких часов или даже суток. В заданных пределах (которые для каждой системы оговариваются) данные во всех копиях будут приведены в синхронное состояние. 5.3.2 ФУНКЦИОНАЛЬНЫЕ СРЕДСТВА РЕПЛИКАЦИИ Кроме вопросов синхронизации обновления данных механизм репликации должен поддерживать множество других функций. Перечислим основные из них, которые дают более развернутое представление о механизме репликации данных: – служба репликации должна обеспечивать копирование как малых, так и больших объемов данных. Другими словами, репликация должна быть реализована независимо от объемов данных, и эта функция называется масштабируемостью; – репликация данных в разнородных системах должна быть реализована независимо от того, на какой платформе работает тот или иной узел системы; – должна быть обеспечена возможность репликации не только данных, но и сопутствующих объектов БД. Например, в некоторых системах реализована репликация индексов, триггеров и хранимых процедур; – служба репликации должна предоставлять администратору БД удобные средства администрирования системы, обеспечивающие проверку ее состояния и контроля производительности компонентов системы репликации. 5.3.3 СХЕМА ВЛАДЕНИЯ ДАННЫМИ Важным элементом механизма репликации данных является схема владения данными, в которой содержатся сведения о том, какому из узлов предоставлена привилегия обновления тех или иных данных. Существует несколько вариантов схем, наиболее известными из которых являются: «ведущий/ведомый», «рабочий поток» и «обновление любой копии» [17]. 202 Схема владения «ведущий/ведомый». Согласно данному механизму асинхронно копируемые данные принадлежат ведущему узлу, создающему эти данные, и могут обновляться только на нем. Вопросы предоставления доступа к данным также решаются только ведущим узлом. Для этого другие узлы «оформляют подписку» на необходимые для них данные, а ведущий узел предоставляет доступ к этим данным другим узлам. В данной схеме владения существует только один узел, который является ведущим для обновляемой копии каждого конкретного набора данных. Это означает, что только этот узел имеет право обновлять этот конкретный набор данных, а значит, конфликты обновления данных в системе полностью исключены. Схема владения «рабочий поток». Данная схема владения, в отличие от предыдущей, позволяет передавать право обновления копируемых данных другим узлам при условии, что в каждый конкретный момент времени существует только один узел, имеющий право обновлять конкретный набор данных. В схеме владения «рабочий поток», как и в предыдущей схеме, исключены конфликты обновления, но реализована более гибкая и динамичная модель владения. Данную схему владения удобно использовать в тех случаях, когда работа выполняется в несколько этапов. Например, при работе с заказами с каждым заказом сначала выполняется ввод данных о заказе, контроль кредитоспособности клиента, выписка счета и т.д. Для выполнения каждого из этих этапов создаются соответствующие приложения, которые могут быть распределены по различным узлам. Распределенная система позволяет этим приложениям, выполняющим отдельные этапы обработки, получать доступ и обновлять данные в БД. При этом каждое приложение запрашивает соответствующие разделы данных о заказе, получает право на их обновление и обновляет их. Но это происходит лишь тогда, когда состояние заказа указывает на завершенность предыдущего этап работы. Схема владения «обновление любой копии». Предыдущие схемы владения имели одно общее свойство: право обновлять данные 203 в любой заданный момент времени имеет только один узел. В это время все остальные узлы имеют право только на чтение. Но в некоторых случаях это правило может оказаться слишком обременительным для решаемой задачи. Для этих случаев создается система, в которой множество узлов имеют одинаковые права на обновление копируемых данных. Такие ситуации характерны при организации «горячих линий», когда множество клиентов могут внести в базу свои данные по объектам, хранящимся в БД, т.е. выполнить действия, которые в отсутствии распределенной системы были возможны только при посещении клиентом офиса компании. При этом каждый центр обработки или узел сети должен иметь доступ к данным, размещенным на остальных узлах, и в случае необходимости иметь право обновлять записи, скопированные с других узлов. Другими словами, каждый клиент «горячей линии» имеет доступ к данным всех узлов системы, т.е. он имеет возможность скопировать или реплицировать их с другого узла, и имеет возможность внести в них свои данные по объектам БД, т.е. обновлять их. Последняя схема владения может привести к возникновению в системе конфликтов, поэтому служба репликации должна использовать методы выявления и разрешения конфликтов. 5.4 ПРЕИМУЩЕСТВА И НЕДОСТАТКИ РАСПРЕДЕЛЕННЫХ СУБД Объединение множества централизованных БД, описывающих состояние отдельных офисов, предприятий и организаций некоторой корпорации или ведомства, в единую распределенную систему с помощью сетей связи и управление этим объединением данных с помощью распределенной СУБД, имеет существенные преимущества перед разрозненными централизованными системами БД, работающих под управлением своих локальных СУБД. Что касается недостатков распределенных СУБД, то некоторые из них связаны с «болезнями роста», а другие носят принципиальный характер. Например, производительность работы распределенной системы по 204 определению не может быть выше производительности работы централизованной БД. Рассмотрим достоинства и недостатки работы распределенных систем. Преимущества распределенных СУБД. К преимуществам распределенных СУБД относятся следующие их особенности [17]. Отражение структуры организации. Такие организации как ведомства и корпорации довольно сложно организованы и содержат множество подчиненных предприятий и подразделений, которые могут размещаться в разных географических районах. При этом каждое предприятие или подразделение организации может поддерживать свою базу данных, содержащую сведения о его состоянии. При выполнении должностных обязанностей персонал структурного подразделения может выполнять необходимые ему запросы к локальной БД. С другой стороны, подразделениям этой организации может понадобиться выполнять запросы, предусматривающие получение доступа к данным, хранящимся в других подразделениях компании. В этих условиях целесообразно распределить используемую такой организацией БД между ее отдельными подразделениями, одновременно обеспечив доступ к своим данным для всех остальных подразделений. При этом структура распределенной БД будет соответствовать структуре организации. Таким образом, географическое размещение подразделений организации отражается в распределении ее данных, причем пользователи одного узла смогут получать доступ к данным, хранящимся на других узлах. Данные при этом помещаются на том узле, где зарегистрированы эти пользователи, создающие эти данные и чаще всего работающие с ними. В результате владельцы данных получают локальный контроль над своими данными и могут устанавливать или регулировать ограничения на их использование. Администратор глобальной базы данных отвечает за систему в целом, но часть этой ответственности делегирует на локальный уровень, благодаря чему администратор 205 локального уровня получает возможность управлять локальной СУБД. Повышение доступности. Если в централизованных СУБД неисправность центрального компьютера вызывает отказ всей СУБД, то при выходе из строя одного из узлов распределенной СУБД приводит лишь к тому, что данные некоторых узлов становятся недоступными, а вся система в целом продолжает свою работу. Повышение надежности. Повышение доступности способствует и повышению надежности системы, т. к. при размещении копий данных на нескольких узлах отказ отдельного узла или линии связи между узлами не приведет к прекращению работы системы в целом. Недостатки распределенных СУБД. Объединение локальных БД в распределенной системе имеет также и отрицательные последствия, к числу которых относятся следующие [17]. Повышение сложности. Объединение локальных БД в распределенной системе существенно усложняет управление этой совокупностью БД. При этом распределенная СУБД должна скрыть от пользователя распределенную природу используемых ими данных и обеспечить требуемую производительность и надежность работы системы, что только повышает сложность управления распределенной системой БД. Усложнение контроля целостности данных. В централизованных СУБД требования обеспечения целостности формулируются в виде некоторых ограничений, выполнение которых гарантирует целостность данных и защищает их от разрушения. Для реализации этих ограничений СУБД осуществляет доступ не только к проверяемым данным, но и к большому количеству связанных с ними данных, на которые распространяются ограничения, обеспечивающие их целостность. В распределенной системе гораздо сложнее обеспечить правильность и согласованность хранящихся в ней данных, т.к. взаимосвязанные данные могут храниться в различных локальных БД, созданных и сопровождаемых разными коллективами разработчиков и пользователей. По этой причине в распределенной системе контроль целостности усложняется вследствие высокой стоимости 206 передачи и обработки распределенных данных при выполнении проверок ограничений целостности. Проблемы защиты. В локальных БД проблемы защиты информации при доступе к данным в целом решены. Но в распределенной системе необходимо обеспечить не только контроль доступа к данным, расположенных на нескольких узлах, но и защиту сетевых соединений. При этом важно иметь в виду, что в последнее время вопросы защиты информации при передаче по сети весьма успешно решаются. Увеличение стоимости. Увеличение сложности управления распределенными системами ведет к увеличению затрат на сопровождение распределенной СУБД и на приобретение дополнительного сетевого оборудования, необходимого для установки соединений между узлами. В завершении главы еще раз подчеркнем, что описанные в данной главе решения по реализации распределенной СУБД еще не стали повседневной практикой при автоматизации управленческих процессов корпораций, концернов, ведомств и т.д. Практическая реализация рекомендуемой архитектуры распределенной СУБД еще не обрела контуры промышленных образцов и требует продолжения исследовательских работ. Поэтому в части практической реализации распределенных СУБД уместно обратить внимание на решения, полученные в ходе развития Web-технологий, описываемых в следующей главе. КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Перечислите требования к АС, предъявляемые в условиях работы с распределенными данными. 2. Дайте определения распределенной БД и распределенной СУБД. 3. Опишите функции и архитектуру распределенной СУБД. 4. Опишите функции и назначение глобального системного каталога. 5. Перечислите основные принципы реализации распределенных БД. 207 6. Опишите понятие «прозрачность размещения». 7. Опишите понятие «прозрачность именования». 8. Опишите понятие «прозрачность использования СУБД». 9. Опишите достоинства и недостатки распределенных систем на основе репликации данных. 10. Опишите процедуры синхронной и асинхронной репликации. 11. Перечислите функциональные средства репликации. 12. Опишите понятие «схема владения данными». 13. В чем заключается преимущества и недостатки распределенных СУБД? 208 С развитием Web-технологий благодаря их повсеместному распространению открылись новые возможности по глобальному доступу к данным, а теория и практика распределенных СУБД получила дополнительный импульс развития. Технология Web была создана как независимая от платформы и по этой причине ее компоненты могут быть легко установлены в любой аппаратно-программной среде. Благодаря этому обстоятельству эта технология обладает значительным потенциалом существенного сокращения расходов на развертывание приложений и обучение персонала. В настоящее время многие организации создают новые или совершенствуют старые приложения БД с целью использования преимуществ, достигаемых при использовании технологии Web в качестве платформы для автоматизации управленческой деятельности. Следует отметить, что развитие распределенных СУБД не являлось основной целью при создании Web-технологии. На начальных этапах развития этой технологии многие Web-узлы были созданы на основе файловых систем, в которых каждый документ хранился в виде отдельного сайта. Для хранения небольшого объема относительно статичных данных подобная структура была вполне приемлемой, но для хранения большого объема динамических данных это решение приводило к большим издержкам по ведению таких Webузлов. 209 Например, достаточно сложно организовать своевременное обновление содержимого сотен или тысяч разных документов, хранящихся в отдельных сайтах. Еще более трудной задачей оказалась поддержка в актуальном состоянии связей между этими данными, особенно если документы создавались и сопровождались разными авторами. Эта проблема обусловлена тем, что большинство Web-узлов содержат в основном динамичную информацию, например сведения об имеющихся товарах и о ценах на них. Сопровождение подобной информации одновременно в БД и в отдельных HTML-файлах представляет собой довольно сложную задачу, особенно если учесть, что поддержание на Web-узлах актуальности данных требует постоянной синхронизации этих двух видов представления информации. По этим и многим другим причинам возникла задача реализации непосредственного доступа к БД из Web-среды, решение которой могло бы обеспечить интеграцию этих двух технологий. В этой главе рассмотрим эволюцию подходов использования технологий СУБД в среде Web с целью получения общего представления о текущем состоянии дел в этой области информационных технологий. 6.1 ОСНОВНЫЕ ПОНЯТИЯ WEB-СРЕДЫ Если корпоративную АС, реализованную на основе локальных сетей, подключить к глобальной сети, то появляется возможность доступа к ее информационным ресурсам (ИР) с любого рабочего места организации. Однако при попытке использовать существующие БД возникают проблемы связанные с: – требованием к однородности рабочих мест (для запуска «родных» интерфейсов); – высоким трафиком в сети (доступ идет напрямую к файлам БД); – загрузкой файлового сервера и невозможностью удаленной работы (например, командированных сотрудников). 210 6.1.1 ИНФРАСТРУКТУРА WEB-ТЕХНОЛОГИЙ И ПРОТОКОЛЫ Решением перечисленных проблем могло бы стать использование унифицированного интерфейса Web-среды для доступа к ресурсам организации. Именно пользовательский интерфейс технологии Web, ее простота и удобство, способствовали тому, что «Всемирная паутина» получила столь широкое распространение за весьма короткий срок. Основу Web составляют разработки и стандарты, созданные за последние тридцать с лишним лет. В 80-е гг. в Министерстве обороны США был разработан ТСР/IР (Transmission Control Protocol / Internet Protocol) − простой протокол, обеспечивший связь между локальными сетями путем передачи пакетов через сети общего пользования. На основе этого протокола была создана инфраструктура Webтехнологий для обеспечения доступа к информационным ресурсам в рамках глобальной сети, содержащая следующие компоненты: – ТСР/IР-сеть с поддержкой базового набора услуг по передаче данных с единой политикой нумерации и маршрутизации, работающим сервисом имен DNS; – выделенные информационные серверы – Web-серверы, обеспечивающие предоставление гипертекстовых документов через ТСР/IР-сеть в ответ на запросы Web-клиентов. Описанная инфраструктура Web-среды обеспечила возможность связывать удаленные компьютеры, размещенные в разных локальных сетях, и обмена данными между ними путем передачи пакетов. Это послужило основой для разработки следующих высокоуровневых протоколов, реализующих преимущества Web-среды: – передачи файлов FTP (File Transfer Protocol); – электронной почты SMTP (Simple Mail Transfer Protocol). 6.1.2 ЯЗЫК HTML И ПРОТОКОЛ HTTP Протоколы передачи файлов и электронной почты представляют собой очень удобный инструмент обмена данными между удаленными системами и в настоящее время они используются довольно интенсивно. Но они не могли обеспечить стандартный ме211 тод представления информации. Поэтому со временем был разработан язык HTML (Hyper Text Markup Language), как простой метод разметки документов для представления информации в программе, которую сегодня называют браузером [21]. Отличительной особенностью этого языка является то, что он содержит тэг , который использует преимущества новой глобальной сети, позволив переходить в другое место на странице или к новой странице. Таким образом, появился новый тип доступа к информации, основанный на клиентах, использующих стандартный для Web-среды язык гипертекстовой разметки HTML. На сегодняшний день основная часть информации в среде Web хранится в документах, созданных на языке HTML, поэтому браузеры при отображении документов должны понимать и правильно интерпретировать дескрипторы этого языка. Протокол, с помощью которого происходит обмен информацией между Web-сервером и браузером, называется HTTP (Hypertext Transfer Protocol). HTTP является текстовым протоколом, т.е. HTTPзапросы представляют собой последовательность символов в коде ASCII. В общем виде HTTP-запрос имеет следующую структуру. Метод URL HTTP-версия Дополнительная информация Здесь Метод – это текстовое название действия или способа передачи данных на сервер. Самыми часто используемыми являются методы GET и POST. URL (Uniform Resource Locator) представляет собой адрес, по которому размещаются документы и разделы документов, и имеет следующий формат: [путь] [файл] [?параметр=значение [&параметр=значение [& . . . ]]]. Компоненты адреса описываются следующим образом: – путь – путь до запрашиваемого файла указывается относительно корневого каталога Web-сервера (он задается при настройке); – файл – имя запрашиваемого файла. По умолчанию имя файла index.html, которое может быть изменено, но в этом случае его придется указать в адресной строке; 212 – параметры, перечисляемые после знака вопроса,  это данные, передаваемые на сервер с помощью метода GET. При этом название и значение параметра разделяются знаками равенства ‘=’, а пары параметр=значение – амперсандами (&). Параметр HTTP-версия определяет версию протокола, в соответствии с которой будут обмениваться данными браузер и сервер. Пример HTTP-запроса приведен ниже по тексту в нижеследующем подразделе. Если запрашиваемая страница доступна на сервере, то Web-сервер формирует ответ. Пример HTTP-ответа также приведен в следующем подразделе. 6.1.3 МЕХАНИЗМ ПУБЛИКАЦИИ ДАННЫХ В WEB-СРЕДЕ Механизм публикации данных в Web-среде подразумевает наличие составных частей, показанных на Рис. 6.1, и описывается следующим образом. Рис. 6.1 – Принцип работы Web-сервера 213 1. Клиенты взаимодействуют с Web-серверами, посылая HTTPзапросы с использованием методов GET или POST. Предположим, что клиент ввел через браузер адрес вида www.example.com/content/chapters/. 2. Введенная пользователем строка преобразуется Webбраузером в HTTP-запрос и отправляется Web-серверу, находящемуся по адресу www.example.com. Сформированный HTTP-запрос имеет вид: GET /content/chapters/ HTTP/1.1 200 OK Accept-Language: en-us Connection: Keep-Alive Host: 82.179.73.32 User_Agent: Opera/7.54 (X11; Linux i686; U) [en] 3. Web-сервер, получив данный запрос определяет местонахождение запрашиваемого документа в своих каталогах. В соответствии с введенным адресом это будет каталог root/content/chapters. Строка /content/chapters направляет Web-сервер в подкаталог корневого каталога документов, где он по умолчанию (т.к. имя файла в адресной строке не указано) запрашивает файл с именем index.html. 4. Web-сервером извлекается текстовый файл root/content/chapters/index.html, который поступает на Web-сервер без обработки. 5. Затем Web-сервер к содержимому файла присоединяет очень важный блок информации, который называется заголовком. В первой строке HTTP-заголовка содержится код ответа. В нашем случае значение кода 200 – это означает, что документ доступен, и сервер начинает его передачу. Кроме кода ответа заголовок предоставляет клиенту информации о том, как интерпретировать полученную информацию. В нашем примере заголовок сообщает клиенту о том, что передается текстовый файл, который должен интерпретироваться как HTMLкод. Далее следует различная служебная информация, и после пустой строки начинается сам документ. Причем, этот документ не- 214 обязательно текстовый – это может быть и бинарный файл, например, изображение или архив. Сформированный HTTP-ответ может иметь следующий вид: HTTP/1.1 200 OK Server: Apache/2.0.52 (Gentoo/Linux) Connection: Keep-Alive Date: Sat, 5 Mar 2005 10:27:16 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 2964 Last-Modified: Sat, 5 Mar 2005 10:27:16 GMT Cookie: uid=456578 Host: 82.179.73.32 User_Agent: Opera/7.54 (X11; Linux i686; U) [en] ........ 6.2 АРХИТЕКТУРЫ, ОБЕСПЕЧИВАЮЩИЕ ИНТЕГРАЦИЮ СУБД В WEB-СРЕДУ Механизм публикации данных Web-среде, описанный в предыдущем разделе, обеспечивает доступ к документам, хранящимся в отдельных файлах. Этот механизм доступа к данным использовался на начальных этапах развития Web-среды и не был приспособлен для решения задачи интеграции СУБД в Web-среду. Поэтому для доступа к информационным ресурсам БД с помощью инфраструктуры Web-технологий многие поставщики СУБД пытались создать собственные подходы интеграции баз данных в среду Web. Но ни одно из этих решений не стало общепринятой технологией, так как пользователи предпочитали использовать унифицированные решения просто для того, чтобы не зависеть целиком и полностью от какой-то одной технологии. Информационное сообщество должно было решить задачу включения СУБД в среду Web таким образом, чтобы удовлетворять следующим требованиям: 215 – в первую очередь, способ интеграции баз данных в среду Web должен быть независимым от платформы; – пользователь должен иметь возможность взаимодействия с БД, независимо от типа используемого браузера или Web-сервера; – пользователь и приложения должны иметь способ подключения к БД, предоставляющий свободу выбора типа СУБД, как в настоящем, так и в будущем; – допускать масштабируемость системы, способствующее сокращению расходов на разработку и сопровождение приложений; – обладать возможностью защищенного доступа к конфиденциальным данным; – предъявлять минимальные требования к администрированию. В качестве возможного решения задачи интеграции СУБД в среду Web, удовлетворяющего перечисленным требованиям, сначала рассмотрим традиционную двухуровневую архитектуру «клиент/сервер», описанную в первой части учебного пособия, согласно которой решаемые задачи распределяются между двумя уровнями: – клиентская часть (уровень 1), отвечает за представление данных на экране компьютера пользователя; – серверная часть, или сервер (уровень 2), – за обеспечение доступа клиента к данным (Рис. 6.2). Первый уровень Клиент Задачи: - Пользовательский интерфейс - Основные алгоритмы расчетов и обработки данных Второй уровень Сервер БД Задачи: - Проверка данных на сервере - Доступ к базе данных БД Рис. 6.2 – Двухуровневая архитектура «клиент/сервер» 216 Основным и существенным недостатком данной архитектуры является сложность масштабирования систем, созданных на ее основе, по мере развития предприятий. Это объясняется тем, что основная часть прикладного ПО размещается на клиенте, которую приходится тиражировать на сотнях и тысячах компьютеров конечных пользователей. Большой объем ПО на клиенте препятствует достижению масштабируемости приложений по следующим причинам: – клиент двухуровневой архитектуры является «толстым», для эффективной работы которого требуются значительные вычислительные ресурсы, включая большое пространство на диске и мощность центрального процессора; – требуются значительные накладные расходы на администрирование клиентской части приложений как при расширении и изменении конфигурации системы, так и при ее эксплуатации. Для преодоления этих проблем была предложена другая архитектура, адаптированная к Web-среде (см. разд. 3.4.4). Новый вариант архитектуры «клиент-сервер», в котором были определены три звена программного обеспечения, каждый из которых может функционировать на разных платформах, был разработан в 1995 году. Особенностью трехуровневой архитектуры является наличие промежуточного уровня, реализующего обработку запросов, поступающих от браузеров, и выдачу ответов на запросы. Введение третьего промежуточного уровня обработки определило следующее перераспределение функций между уровнями данного варианта архитектуры «клиент/сервер» (см. Рис. 6.3): – на уровне клиента, расположенного на компьютере конечного пользователя, выполняется только функции пользовательского интерфейса, а также некоторая очень простая обработка данных, например, проверка введенной информации. Поэтому клиентская часть трехуровневой архитектуры строится с использованием так называемого «тонкого» клиента; – основные прикладные алгоритмы с клиентского уровня переносятся на промежуточный уровень. Другими словами, основные задачи системы выполняются на сервере приложений; 217 – СУБД размещается на отдельном сервере, называемом сервером БД. Основное назначение этого уровня, как и в традиционной схеме «клиент/сервер», заключается в хранении данных и обеспечении доступа к ним. Первый уровень Клиент Задачи: - Пользовательский интерфейс Второй уровень Сервер приложений Задачи: - Алгоритмы расчетов - Алгоритмы обработки данных Третий уровень Сервер БД Задачи: - Проверка данных - Доступ к базе данных БД Рис. 6.3 – Трехуровневая архитектура «клиент/сервер» Прикладные алгоритмы, перенесенные с клиентского уровня на сервер приложений, связаны с клиентом и сервером базы данных посредством локальной или глобальной вычислительной сети. При этом предполагается, что один сервер приложений может обслуживать множество клиентов. Описанная архитектура имеет много преимуществ перед двухуровневой моделью: – «тонкий» клиент требует менее дорогостоящее аппаратное обеспечение; – передача средств реализации прикладных алгоритмов, применяемых многочисленными конечными пользователями, на общий сервер приложений обеспечивает централизацию сопровождения 218 приложений. При этом решается одна из самых сложных проблем двухуровневой модели «клиент/сервер» – проблема масштабирования – за счет устранения необходимости развертывания прикладного ПО на множестве клиентских компьютеров; – дополнительная модульность упрощает модификацию или замену ПО каждого уровня без изменения остальных уровней; – отделение основных средств реализации прикладных алгоритмов от функций БД и клиентского уровня упрощает задачу равномерного распределения нагрузки по уровням системы. Дополнительное и довольно важное преимущество заключается в том, что трехуровневая архитектура довольно естественно вписывается в среду Web, где браузер выполняет функции «тонкого» клиента, а Web-сервер (вместе с модулями расширения) – сервера приложений. 6.3 МЕХАНИЗМЫ ИНТЕГРАЦИИ СУБД В WEB-СРЕДУ Архитектуры, обеспечивающие интеграцию СУБД в Web-среду, рассмотренные в предыдущем разделе, должны иметь возможность формировать динамичные Web-страницы, требующие постоянного обновления, внося изменения в HTML-код при каждом обращении клиента. В отличие от механизма публикации статических Web-страниц в данном механизме осуществляется формирование Web-страниц «на лету», что является довольно затратной процедурой, поэтому в механизм публикации статических Web-страниц потребовалось внести следующие изменения: – данные Web-страницы по запросу от браузера формируются динамически путем их извлечения из базы; – далее эти данные встраиваются в HTML-код и отправляются браузеру в ответ на запрос. HTML-код с встроенными данными из базы создается «на лету» программой, установленной на сервере приложений, и отправляется браузеру Web-сервером. При этом содержимое динамической Web-страницы генерируется всякий раз, когда Web-сервер получает текст запроса от браузера. 219 Динамическая Web-страница, формируемая таким образом обладает дополнительными возможностями, которых нет у статических Web-страниц. Она может:  реагировать на данные, вводимые пользователем с помощью браузера. Например, динамические страницы способны возвращать данные, полученные после заполнения формы или в результате выполнения запросов к базе данных; – быть настроена по требованиям конкретного пользователя. Например, как только пользователь установит собственные предпочтения при посещении некоторого Web-узла (путем указания области своих интересов или уровня квалификации), эта информация может быть сохранена и впоследствии возвращаемая пользователю информация будет отобрана с учетом указанных условий. Если документы публикуются в динамическом режиме (например, по результатам выполнения запроса к базам данных), то серверу потребуется генерировать их в гипертекстовом формате. Для достижения этой цели следует подготовить сценарии, называемые модулями расширения, предназначенные для выполнения преобразования данных различного формата в HTML-формат непосредственно в процессе их формирования. Эти сценарии, или модули расширения, должны интерпретировать содержание запросов, посылаемых клиентом с помощью форм HTML, а также соблюдать формат результирующих данных, генерируемых их приложениями-владельцами (например, СУБД). Поскольку база данных является динамическим объектом, изменяющимся в результате того, что пользователи могут создавать, вставлять, обновлять или удалять сохраняемые в ней данные, выработка динамических Web-страниц представляется гораздо более приемлемым подходом, чем создание статических Web-страниц. Модули расширения, обеспечивающие формирование динамических Web-страниц, представляют собой дополнительный уровень обработки, реализующий прикладные алгоритмы по запросам многочисленных конечных пользователей. Поэтому наиболее подходящей архитектурой, в которой может функционировать предло- 220 женный подход доступа к удаленным данным, является трехуровневая архитектура. В рамках трехуровневой архитектуры были предложены различные методы публикации Web-страниц в динамическом режиме. В данном разделе рассмотрим некоторые из них, демонстрирующих эволюцию технологий доступа к данным в Web-среде: – интерфейс CGI (Common Gateway Interface – общий шлюзовой интерфейс) – первый метод публикации динамических Webстраниц. – сервлеты, основанные на технологии Java; – серверные страницы Java (JSP). 6.3.1 ОБЩИЙ ШЛЮЗОВОЙ ИНТЕРФЕЙС Первым интерфейсом для создания модулей расширения Webсерверов был CGI (Common Gateway Interface  общий шлюзовой интерфейс), пришедший из Unix. Web-приложения в этом случае представляют собой сценарий или обычный исполняемый файл (*.exe), получающий от сервера необходимую информацию из переменных окружения [22]. Взаимодействие клиента с сервером через общий шлюзовой интерфейс проиллюстрировано на Рис. 6.4, и описывается следующим образом. 1. Клиент вводит в поле адреса браузера строку вида www.example.com/cgi-bin/a.cgi/. 2. Web-серверу по адресу www.example.com, будет отправлен запрос на выполнение программы a.cgi. При этом сервер «знает», что производится запрос исполняемого файла, поскольку в адресе присутствует строка cgi-bin. 3. Web-сервер устанавливает местонахождение файла на жестком диске. В нашем примере файл находится в каталоге root/cgibin/. 4. После этого исполняемый файл отправляется на сервер. 4.1. Программа формирует SQL-запрос и передает серверу базы данных. 221 Рис. 6.4 – Обработка динамических данных 4.2. Сервер базы данных выполняет запрос и возвращает результаты его выполнения программе. 5. На Web-сервере программа a.cgi генерирует соответствующий HTML-код, который отправляется клиенту. 6. Web-сервер формирует заголовок для html-кода. 7. HTML-код передается по HTTP-протоколу и отображается браузером. С использованием данного подхода пользователь Интернета может не только получить доступ к базе данных, но и обновлять 222 данные в ней. Для этого создается HTML страница с текстовыми полями и кнопкой «Submit». Пользователь вводит необходимую информацию в текстовые поля созданной HTML-страницы (или HTML-формы) и нажимает кнопку «Submit». После этого данные передаются вместе с URL, которые указывают расположение программы CGI и говорят серверу, что делать с данными. Затем эту программу запускает сервер, обеспечивая программу данными, которые она запрашивает. CGI-программа обычно пишется на Perl, C, C++ или любом другом языке, который умеет читать стандартный ввод и писать в стандартный вывод. Это все, что предоставляет Web-сервер: вызывается CGI-программа и используются стандартные потоки для ввода и вывода. CGI-программа отвечает за все остальное. 1. Во-первых, она просматривает данные и решает, является ли их формат корректным. 2. Если нет, CGI-программа должна сформировать HTMLстраницу для описания проблемы; эта страница передается Webсерверу (через стандартный вывод из CGI-программы), который посылает ее назад пользователю. 3. Пользователь возвращается на страницу и пробует запустить ее снова. 4. Если введенные данные корректны, CGI-программа обрабатывает данные соответствующим способом, возможно, добавляя их в базу данных. 5. Затем она генерирует соответствующую HTML страницу для Web-сервера, чтобы вернуть ее пользователю. С появлением технологии CGI, исполняемые приложения, написанные обычно на Perl или С, получили интерфейс, который позволял клиентам обращаться к ним стандартным способом через HTTP. Это позволило создать как персонализированный контент, так и приложения для сбора и распространения информации в Интернете. Но со временем обнаружилось, что CGI имеет множество недостатков:  языки, на которых пишутся приложения, являются процедурными; 223  неисправность в программе CGI может привести к краху всей машины;  способ работы CGI-приложений требует создания нового экземпляра приложения для каждого запроса, что затрудняет масштабируемость. Это может привести к значительному торможению на сервере. Нужно заметить одну очень важную вещь: CGI только описывает контракт между Web-сервером и программой, и не предоставляет никаких служб, помогающих реализовать системы с поддержкой персонализации, такие как поддержка опознавания клиента, предоставление доступа к средствам поддержки пользовательской информации, запрет доступа к приложению авторизованным пользователям, и хранение в приложении информации периода выполнения. Таким образом, довольно быстро назрела необходимость создать среду, в которой бы «жили» Web-приложения, и которая предоставляла бы упомянутые выше службы. Наличие такой среды, кроме того, предоставляла бы более совершенную службу управления жизненным циклом, чтобы уменьшить проблемы с производительностью. 6.3.2 СЕРВЛЕТЫ JAVA Дальнейшее развитие Web-технологий связано с применением языка Java и технологий, основанных на этом языке. Платформа Java является промышленным стандартом, позволяющим создавать из унифицированных компонентов интероперабельные программные решения для самых разных систем, в которых установлена виртуальная машина Java Virtual Machine (JVM). Для решения проблем, создаваемых CGI, фирмой Sun Microsystems были созданы сервлеты, представляющие собой программы, выполняемые на Web-сервере с поддержкой Java и формирующие Web-страницы, аналогично программам CGI. Сервлеты вызываются удаленно из Web-браузера с помощью HTTP-протокола через Webсервер для динамического генерирования контента и предоставляют способ для развертывания приложения в Web-среде. 224 Сервлеты могут выполнять все те же функции, которые выполняются CGI-скриптами, только вместо Perl или C++ в данном случае используется язык Java, что дает много преимуществ. Эти преимущества заключаются в удобстве написания, поддержки и изменения кода, а также в самом способе исполнения Java-программ на Webсервере. Особенностью нового подхода к решению проблемы доступа к данным в Web-среде является наличие контейнера сервлетов, предоставляющего окружение для выполнения сервлетов. Контейнер сервлетов может работать как полноценный самостоятельный сервер, но чаще используется совместно с другим серверным ПО. Контейнер сервлета  это «движок», отвечающий за выполнение сервлетов, т.е. это та самая среда, в которой «живут» Webприложения. Контейнер сервлетов предоставляет службы, обеспечивающие доступ к средствам поддержки пользовательской информации, запрет доступа к приложению неавторизованным пользователям и хранение в приложении информации периода выполнения. Он обеспечивает: – обмен данными между сервлетом и клиентами; – создание рабочей среды для функционирующего сервлета; – идентификацию и авторизацию клиентов; – организацию сессии для каждого клиента. В отличие от CGI-скриптов, код инициализации сервлета выполняется только один раз. При этом сервлеты наследуют все свойства языка программирования Java. Например, подобно всем стандартным классам Java, сервлет не зависит от платформы и может использоваться в различных операционных системах, а также может пользоваться богатыми возможностями Java, такими как работа в сети, JDBC, RMI и многими другими. Web-контейнер управляет сервлетом, вызывая различные методы жизненного цикла. Эти методы определены в Java Servlet API и сосредоточены в наборе классов и интерфейсов, которые можно использовать для разработки сервлета. 225 1 Webклиент 5 2 Webсервер 3 4.4 Контейнер сервлетов 4.3 4.2 Драйвер 4.1 JDBC Сервер баз данных Рис. 6.5  Формирование сервлетом динамической HTMLстраницы 226 Классы и интерфейсы находятся в пакетах javax.servlet и javax. servlet.http, а Web-контейнер вызывает их методы (init, service, destroy) в ходе обеспечения жизненного цикла сервлета. Процесс формирования сервлетом динамической HTML-страницы представлен на Рис. 6.5. Вкратце работу сервлета можно описать следующим образом. 1. Пользователь вводит данные в HTML-форму. 2. Браузер формирует запрос по введенным данным. 3. HTTP-запрос пересылается Java-сервлету, запущенному на Web -сервере. 4. Если сервлет ориентирован на работу с базой данных, то по полученным данным Java-сервлет: 4.1. Осуществляет соединение с БД; 4.2. Конструирует SQL-запрос с учетом введенных пользователем через браузер данных; 4.3. Сервер базы данных выполняет запрос и возвращает результаты его выполнения Java-сервлету; 4.4. Сервлет по полученным данным генерирует HTML-страницу с данными. 5. HTML-страница отображается пользователю. Каждый сервлет может обрабатывать много запросов от многих клиентов. Интерфейс Servlet определяет метод с именем service (), который вызывается для каждого клиентского запроса. Этот метод управляет всей обработкой для получения ответа, который возвращается клиенту. Когда запрос выполняется и ответ возвращается клиенту, сервлет ожидает следующего запроса. В приложениях HTTP метод service() проверяет, какой тип HTTP запроса, GET или POST, был сделан, и перенаправляет его методам, определенным для обработки этих запросов. 6.3.3 СЕРВЕРНЫЕ СТРАНИЦЫ JAVA С появлением технологии сервлетов разработчики столкнулись с одним большим неудобством: для генерации HTML-страниц «на лету» с помощью сервлета весь HTML-код приходилось помещать в сервлеты. Получалось, что HTML-код страницы (форма или дизайн) 227 смешивался с Java-кодом (логикой), что затрудняло работу как дизайнера, так и программиста сайта. Практика включения HTML-кода в код сервлета не является оптимальной, так как эти действия «отвлекают» сервлет от его основной роли – контроллера приложения. Сервлет должен использоваться только для реализации алгоритма работы приложения и его следует отделить как от непосредственного формирования ответа на запрос, так и от данных, необходимых для этого. Для решения этой проблемы была придумана технология JSP (Java Server Pages), основанная на серверном языке сценариев, подобном Java, которая позволяет формировать Web-сайты, содержащие сочетание статического кода HTML с динамически формируемым кодом HTML. Результатом отделения динамической части страниц от статического HTML является возможность изменения дизайна страницы, не затрагивая динамическое содержание. Процедура довольно проста: создается обычный код HTML (статический), а динамическая часть заключается в специальные теги "<% %>". Это дает возможность раздельного кодирования дизайна, т.е. HTML-кода и логики (Java-кода) Web-сайта. При этом специалист, знающий HTML, но не умеющий программировать, создает шаблон Web-сайта, а затем другой специалист, владеющий программированием, добавляет исполняемый код непосредственно в HTML-файл. Статические части HTML-страниц посылаются в виде строк в метод write(). Динамические части включаются прямо в код сервлета. С этого момента страница ведет себя как обычная HTMLстраница с ассоциированным сервлетом. В целом процедура преобразования JSP-файла при первом вызове описывается следующим образом (см. Рис. 6.6). 1. Браузер делает запрос к странице JSP. 2. JSP-engine анализирует содержание файла JSP. 3. JSP-engine создает временный сервлет с кодом, основанным на исходном тексте файла JSP, при этом контейнер транслирует операторы Java в метод _jspService(). Если нет ошибок компиляции, то этот метод вызывается для непосредственной обработки запроса. 228 Созданный сервлет ответствен за исполнение статических элементов JSP, определенных в дополнение к динамическим элементам. Рис. 6.6  Формирование HTML-страницы с помощью JSP 229 4. Полученный код компилируется в файл *.class. 5. Вызываются методы init() и _jspService(), и сервлет исполняется. 6. Сервлет на основе JSP установлен. Комбинация статического HTML и графики вместе с динамическими элементами, определенными в оригинале JSP, пересылаются браузеру через выходной поток объекта ответа ServletResponse. Последующие обращения к файлу JSP просто вызовут метод _jspService() сервлета. Сервлет используется до тех пор, пока сервер не будет остановлен и сервлет не будет выгружен вручную. 6.4 ПРЕИМУЩЕСТВА И НЕДОСТАТКИ ИНТЕГРАЦИИ СУБД В СРЕДУ WEB Публикация документов, содержащих актуальные сведения из БД, в общедоступных сетях революционизировала взгляд на информацию, поскольку пользователи получили стандартное представление информации, независимое от платформы, операционной системы или программного обеспечения. Теперь любой пользователь может работать в сети, используя одно единственное приложение, т.е. браузер. К сожалению, этот подход имеет также определенные недостатки. Приведем сравнительную характеристику преимуществ и недостатков данного подхода при организации взаимодействия АС с другими системами. 6.4.1 ПРЕИМУЩЕСТВА Основное достоинство использования Web-технологий для распределенного доступа к данным АС заключается в том, что в части организации ее внутримашинного ИО на основе БД практически не вносится никаких изменений. Все возможности по удаленному доступу к данным АС обеспечиваются инфраструктурой Web-технологий, а также так называемыми модулями расширения, рассматриваемыми в качестве компонентов, расширяющих возможности Web-сервера. 230 Использование функций СУБД. На начальных этапах развития Web-технологий Web-узлы были полностью основаны на использовании файловой системы, где каждый документ хранится в отдельном файле. И таким образом оказалось, что наибольшая в мире «база данных» (World Wide Web) разрабатывалась без какого-либо использования достижений технологии баз данных. В главе 3 рассматривались преимущества СУБД перед файловой системой, многие из которых можно отнести и к случаю интеграции СУБД в Web-среду. Интеграция СУБД в Web-среде решает сложную проблему синхронизации информации, содержащейся в БД и в файлах HTML, поскольку HTML-страницы динамически формируются на основе информации, извлекаемой из БД. В результате упрощается сопровождение системы, а информационное наполнение HTML поддерживается функциональными возможностями СУБД, такими как соблюдение прав доступа и поддержание целостности данных. Независимость от платформы. Еще одним важным преимуществом использования приложений БД в Web-среде является независимость Web-клиентов или браузеров от платформы. Это качество существенно облегчает переносимость приложений с одной платформы на другую, так как при использовании браузеров для доступа к БД перенос приложения на другую платформу не требует внесения изменений в клиентскую составляющую приложения, так как браузеры имеются для всех современных платформ. К сожалению, разработчики браузеров стали включать в свои продукты специфические компоненты собственной разработки, что приводит к постепенному исчезновению данного преимущества. Стандартизация. Разработчики браузеров во всем мире поддерживают язык HTML, предоставляющий конечным пользователям единый графический пользовательский интерфейс. На сегодняшний день HTML фактически является стандартом, который поддерживается всеми существующими браузерами, что позволяет читать документы HTML, находящиеся на одном компьютере, с помощью другого компьютера, расположенного в любой точке земного шара. Однако, как уже было отмечено, этот стандарт постепенно перестает быть всеобщим, поскольку разработчики браузеров все ча- 231 ще включают и распространяют собственные специфические компоненты, которые не являются общепризнанными. Прозрачный сетевой доступ. Важнейшим достоинством среды Web является прозрачность сетевого доступа для пользователя. Для доступа к необходимым данным ему достаточно указать требуемый URL. Такая прозрачность сетевого доступа полностью обеспечивается браузером и Web-сервером. Поддержка функций сетевого доступа упрощает доступ к БД, исключает необходимость приобретения дорогостоящего сетевого ПО, и устраняет дополнительные сложности согласования взаимодействующих платформ. Масштабируемость развертывания. «Толстые» клиенты традиционной двухуровневой архитектуры «клиент/сервер» недостаточно эффективно реализуют как функции интерфейса пользователя, так и прикладные алгоритмы. Трехуровневая архитектура более равномерно распределяет нагрузку на разные уровни системы и обеспечивает ее масштабируемость. Размещение функциональных средств приложения на отдельном сервере и удаление их из клиентской части позволяет существенно снизить затраты на развертывание и сопровождение приложений. В то же время упрощается проведение обновлений и администрирование системы при работе с различными вычислительными платформами, расположенными в многочисленных офисах. Сервер приложения трехуровневой архитектуры обеспечивает доступ к функциям приложения с любого компьютера, расположенного в любой точке планеты. 6.4.2 НЕДОСТАТКИ Основное достоинство использования Web-технологий для распределенного доступа к удаленным данным, позволяющее использовать внутримашинное ИО локальных АС, не внося в него практически никаких изменений, определяет также основной недостаток данного подхода распределенного доступа к данным. Слабые стороны и ограничения языка HTML, обусловленные тем, что для HTML-документов не поддерживаются метаданные, ко232 торые описывали бы структурные, семантические и другие их свойства. Без поддержки таких свойств качественное совершенствование способов организации ИО АС невозможно, чем и объясняется отсутствие изменений в его структуре при использовании Web-среды для доступа к удаленным данным. В рамках описанного подхода речь о распределенной обработке данных, т.е. об организации межпрограммного обмена данными, не идет и для этого требуется использование более совершенных инструментов представления данных, чем язык HTML. Ограниченные функциональные возможности языка HTML. Возможности языка HTML позволяют реализовать общепринятый и простой в использовании интерфейс доступа к БД. Но для приложений БД с высоким уровнем интерактивности этих возможностей явно недостаточно и очень сложно обеспечить высокий уровень удобства работы пользователей. Поэтому для организации интерфейса доступа к БД приходится использовать дополнительные инструменты в виде языков сценариев JavaScript или средств языка Java. Однако данный подход, с одной стороны, требует высокой квалификации разработчиков, с другой стороны, приводит к снижению производительности (за счет пересылки по сети и выполнения соответствующего кода). Высокие требования к пропускной способности сети. Пропускная способность локальной сети существенно выше пропускной способности сети при передаче пакетов по самым быстрым соединениям Internet. Поэтому главным лимитирующим ресурсом Internet является ее пропускная способность. Недостаточная производительность. Содержимое HTML-страниц должно интерпретироваться и развертываться на экране браузером; кроме того язык сценариев JavaScript, дополняющий язык HTML некоторыми программными конструкциями, также является интерпретируемым языком. В результате клиентская часть такой БД работает медленнее, чем клиентская часть приложения, использующего обычную БД. 233 КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Перечислите основные компоненты инфраструктуры Webсреды. 2. Опишите взаимосвязь языка HTML и протокола HTTP. 3. Опишите механизм публикации данных в Web-среде. 4. Дайте описание архитектуры АС, обеспечивающей интеграцию СУБД в Web-среду (опишите двухзвенную и трехзвенную варианты АС). 5. Опишите механизм интеграции СУБД в Web-среду с помощью модулей расширения Web-серверов CGI. 6. Опишите механизм интеграции СУБД в Web-среду с помощью сервлетов Java. 7. Опишите механизм интеграции СУБД в Web-среду с помощью серверных страниц Java. 8. Опишите преимущества и недостатки современных средств интеграции СУБД в среду Web. 234 Развитие Web-технологий, использующих Web-серверы в качестве слоя приложений, привело к широкому распространению трехзвенной архитектуры АС, описанной в предыдущей главе, достоинства которой, в первую очередь, связаны со стандартизацией взаимодействия между всеми ее слоями. В результате развития Web-технологий были решены многие проблемы удаленного доступа к данным, которые не удавалось решать в рамках теории распределенных БД. Эти успехи были обусловлены построением инфраструктуры распределенной Web-среды, в которой информация БД может распространяться по всему миру с минимальными затратами времени и усилий, а также без необходимости решения проблем совместимости типов оборудования, операционных систем и программного обеспечения. Но к настоящему времени потенциал качественного совершенствования технологий существующей версии Web-среды оказался в значительной мере исчерпанным. Сдерживающее влияние на дальнейшую эволюцию приложений Web-технологий оказывают, прежде всего, слабые стороны языка HTML – основного средства представления информационных ресурсов в Web-среде. 235 7.1 XML-ПЛАТФОРМА КАК ОСНОВА ДЛЯ ФОРМАЛИЗАЦИИ ИЛО РАСПРЕДЕЛЕННЫХ СИСТЕМ Недостатки языка HTML связаны, прежде всего, отсутствием в нем средств поддержки метаданных (см. подраздел 6.4.2), что существенно ограничивает возможности по интеграции СУБД и Webсреды. При этом хотя и обеспечивается доступ к БД, но ее ресурсы остаются для среды Web «черным ящиком» и предназначены только для визуального представления пользователю. Это объясняется тем, что без метаданных, только с помощью средств языка HTML, невозможно обрабатывать структуры, адекватные схемам БД [21]. Поэтому использование языка HTML для представления данных из баз не внесло существенных изменений в части организации ИЛО АС, а возможности по организации распределенной БД были реализованы лишь в довольно узком спектре ее использования, касающегося просмотра содержимых БД человеком через браузер. 7.1.1 ТРАДИЦИОННАЯ ТЕХНОЛОГИЯ ФОРМИРОВАНИЯ ИЛО АС И ПРОБЛЕМА ФОРМАЛЬНОГО ОПИСАНИЯ ДОКУМЕНТОВ Трудности интеграции СУБД в Web-среду связаны не только с недостатками языка HTML, а во многом объясняются особенностями технологии разработки ИО, используемой при создании современных АС. Эти особенности заключаются в том, что: – данные, реализованные в бинарной форме в БД (а это основная форма представления данных на сегодняшний день), могут быть использованы только той СУБД, с помощью которой они были созданы; – внемашинное ИО содержит довольно большой объем информации, не фиксируемой в составе внутримашинного ИО, а реализуемой при разработке ПО АС в виде программного кода (экранных форм, программных модулей (ПМ) бизнес-процессов и приемапередачи данных); – система словарей, как составляющая ЛО, фиксируется в качестве компонента внутримашинного ИО лишь частично в таблицах словарей-классификаторов БД в полях наименований. Тогда как наименования, используемые для идентификации значений 236 данных на экранных формах, вводятся программистами, как правило, без использования каких-либо регламентирующих документов. То обстоятельство, что существенный объем внемашинного ИО реализуется вне внутримашинного ИО, т.е. вне БД (см. Рис. 7.1), объясняется недостаточной формализацией сведений о структуре и форме данных в рамках традиционной технологии разработки ИЛО. Внешинное ИО Программист УСД Информационные объекты (реквизиты и показатели), извлеченные из документов Экранные формы Внутримашинное ИО БД СКК и формализованная НСИ . Документы ПрО Неформализованная НСИ Протоколы информационного взаимодействия Программист ПМ бизнеспроцессов Программист ПМ приема и передачи данных ПрО – предметная область УСД – унифицированная система документов ИО – информационное обеспечение БД – база данных СКК – система классификации и кодирования НСИ – нормативно-справочная информация ПМ – программный модуль Рис. 7.1 – Традиционная схема разработки ИО АС 237 Если формализованная часть внемашинного ИО определяется в виде декларативных знаний в БД, то ее неформализованная составляющая реализуется в виде процедурных знаний на этапе разработки ПО путем создания: – экранных форм, используемых для заполнения информационных структур (таблиц баз данных) данными документов и их последующего отображения; – ПМ, обеспечивающих решение задач АС в соответствии с требованиями, представленными в неформализованной НСИ; – ПМ, обеспечивающих обмен данными по протоколам взаимодействия между различными АС. Наличие большого объема неформализованной составляющей ИЛО при ее традиционной реализации является серьезным препятствием создания распределенных систем. Это объясняется тем, что для представления неформализованных данных в разных системах применяются специфические формы, что приводит к необходимости согласования различий в форматах данных, способов ввода и вывода при обмене данными между этими системами. Это существенно усложняет совместную работу при большом количестве объединяемых систем. Повышение относительного объема формализованной составляющей ИЛО – основная цель разработчиков систем распределенной обработки информации. При этом необходимо иметь в виду, что данные, используемые как в системах управления, основанных на бумажном документообороте, так и в системах с применением автоматизированного управления, представляются в виде документов. Документ, как носитель информации, подготовленный к печати или публикации электронными средствами, можно представить в виде трех логических частей: – первая часть – это содержимое документа, обычно состоящее из текста, таблиц и графики, представляет собой его смысловое содержание; – вторая часть документа представляется данными о его структуре, т.е. данными о заголовках, абзацах и т.д., обеспечивающих 238 упорядоченную «сборку» содержания документа как целостного образования; – третья часть содержит данные о форматировании документа, т.е. данные о шрифтах, отступах, параметрах страниц и т.д., обеспечивающие визуальное представление содержания документа. Следует констатировать, что в рамках традиционной технологии формирования ИЛО АС только первая часть документа, а именно его содержание, фиксируется во внутримашинном ИО, т.е. в БД, как используемая информация (см. Рис. 7.1). Остальные составляющие документа рассматриваются как важные, но имеющие вспомогательную роль и используемые при разработке других видов обеспечения. Относительно представления структурной составляющей документов необходимо сделать оговорку, т.к. она косвенным образом представлена в БД в виде ее схемы. Но при этом необходимо иметь в виду, что: – схема БД представляет структуру ПрО в целом, а структуры документов по-отдельности в БД не фиксируются; – процедуры нормализации, используемые при разработке схем БД, приводят к тому, что фрагменты схем БД, соответствующие отдельным документам, отличаются от их исходных структур. Необходимо также отметить, что сведения о структуре и форме документа учитываются в современном делопроизводстве при разработке УФД, включающей в себя структуру и форму документа. Структура и форма документа, представленные в УФД, являются способом компактного хранения информации о строении и визуальном представлении документов. УФД с этой точки зрения представляет собой ИР, реализованный в виде различных нормативных документов, которыми руководствуются ДЛ при составлении документов. Однако важно иметь в виду, что УФД является внемашинным ИР, который хотя и может храниться на машинных носителях, но не используется в программах непосредственно, а служит в каче- 239 стве справочного материала для составителей документов и разработчиков ПМ, реализующих экранные формы. Описанный подход к разработке ИЛО сложился исторически в условиях ограниченных объемов памяти средств хранения данных, который был направлен на сохранение только важнейших компонентов данных о ПрО. В современных условиях, когда стоимость единицы памяти постоянно снижается, а объемы памяти запоминающих устройств выросли на многие порядки, имеются все возможности для того, чтобы использовать способы формального представления документа, описывающие его в полном объеме. 7.1.2 ИСПОЛЬЗОВАНИЕ ЯЗЫКОВ РАЗМЕТКИ XML-ПЛАТФОРМЫ ДЛЯ ФОРМАЛЬНОГО ПРЕДСТАВЛЕНИЯ ДАННЫХ ДОКУМЕНТОВ Проблема формального представления данных о структуре и форматировании текстовых документов возникла еще в давние времена, с момента появления типографской техники. С целью решения этой проблемы редакторы для описания структуры и формы документа использовали специальные символы разметки, которые вставлялись прямо в его содержимое. По этим символам работники издательств определяли, какова структура печатаемого документа и как он должен форматироваться для печати. Языки формализации текстовых документов. С появлением компьютерных издательских программ символы разметки, встраиваемые в содержимое документа, трансформировались в команды издательских программ. При этом каждый тип издательского оборудования поддерживал свой набор команд разметки, что очень затрудняло переход от одной системы к другой. Поэтому для стандартизации разметки был разработан язык SGML (Standard Generalized Markup Language  стандартный обобщенный язык разметки), который со временем был принят как стандарт ISO. Язык SGML по существу является метаязыком для определения конкретных языков разметки. Его изобретатели исходили из того, что один язык разметки просто не в состоянии удовлетворять всем возможным требованиям представления данных о структуре, форма- 240 тировании, семантике и других аспектах документа, но при этом у всех языков разметки должны быть общие элементы. Стандартизировав эти общие элементы можно сгенерировать семейство тесно связанных между собой языков разметки. Одним из таких языков, созданных на базе SGML, стал упомянутый нами HTML, предназначенный для создания гипертекста, обеспечивающий отображение документов с помощью браузера и связывающий между собой отдельные документы. Несомненно, сильная сторона языка HTML – это форматирование документов, которое определяется так строго, что независимо от браузера, в котором выводится конкретный документ, он всегда выглядит одинаково. К сожалению, логическая структура данных в HTML-документе не задается явно, и определить, где в нем находятся данные содержания, а где – данные форматирования, довольно сложно. Это ограничивает возможности извлечения и обработки данных HTMLдокумента программными средствами. Язык XML – средство описания содержания документов. Для решения этой проблемы на основе языка SGML был создан еще один язык, названный XML, в котором разметка документов была определена на логическом уровне. В отличие от языка HTML он обеспечивает содержательную (структурную) разметку документа, выделяя с помощью тегов отдельные элементы, составляющие содержание документа, а не элементы его форматирования. [24, 25] Следует подчеркнуть, что XML, в отличие от HTML, не является полнофункциональным языком, который должен решать все задачи представления, поддержки и обработки данных. Если проводить аналогию с технологиями баз данных, то XML можно отнести к языку определения данных. Специфика XML как языка определения данных заключается в том, что в нем в нем должны сочетаться возможности: – описания элементов XML-документов, составляющих содержание данного конкретного документа; – определения значений элементов XML-документов в соответствии с типами элементов. 241 Отсюда следует, что возможности языка XML по выделению элементов данных документа с учетом порядка их следования и определения их типов должны быть усилены, и это было сделано с помощью еще одного стандарта, получившего название XML Schema (или XML-схема по-русски). Язык XSD – средство описания структур и типов данных. Определение структуры документа путем описания порядка следования и иерархии его элементов, а также типов данных для каждого элемента приводится в XML-схеме. Именно в XML-схеме формализуется набор правил, с соблюдением которых составляется XMLдокумент конкретного назначения. Стандарт XML Schema для определения структуры документа использует специальный язык, созданный на основе спецификации XSD (XML Schema Definition) [24, 25]. В дальнейшем спецификация XSD была расширена конструкциями, обеспечивающими возможности представления в XML-документах структур, адекватных используемым в языках программирования и БД. Эта модификация спецификации XSD имеет большое значение, т.к. основное назначение языка XML заключается в том, что с его помощью данные представляются в текстовом формате с целью обмена информацией в глобальной сети между программами и БД, реализованными на произвольных платформах. Суммируя вышеизложенное можно констатировать, что XMLсхема выполняет следующие функции: 1. Описывает названия элементов и атрибутов, т.е. определяет словарь документа. 2. Определяет типы данных элементов и атрибутов, что налагает ограничения на значения элементов и атрибутов. 3. Описывает взаимосвязь между элементами и атрибутами документа, т.е. определяет структуру содержания документа. Язык XSL – средство описание данных форматирования. Создателям XML-платформы удалось отделить содержимое документа не только от его структуры, но и от форматирования, т. е. от данных, определяющих его внешний вид. Поскольку информация XMLдокумента не указывает на то, как она будет отображена на визу- 242 ально, то в рамках XML-платформы дополнительно определяется таблица стилей, посредством которой документу придается желаемый внешний вид. С помощью таблицы стилей осуществляется преобразование XML-документа в HTML-страницу с целью ее отображения браузером в виде визуального документа пригодного для восприятия человеком [24, 25]. Кроме этого, XML-платформа предоставляет средства трансформирования данных XML-документа для представления на различных устройствах. Имея один экземпляр XML-документа можно преобразовать его в формат представления для Internet-браузера (HTML), для вывода на печать на принтере (RTF) и т.д. Для этих целей используется язык таблиц стилей XSL (eXtensible Stylesheet Language). Язык xForms – средство разработки экранных форм. В арсенале средств XML-платформы есть также средства, направленные на непосредственную поддержку разработки экранных форм для ввода данных в систему. В качестве такого средства можно рассматривать технологию разработки Web-форм, названную xForms [27]. Данная технология была разработана для замены морально устаревших классических Web-форм. По сравнению с Web-формами, формы, созданные по новой технологии, не только обеспечивает ввод информации, но и имеет довольно широкие возможности для её обработки, например: – обработки правильности отправляемых данных (проверки XML-документа на корректность); – взаимодействия с протоколом SOAP (описание см. ниже); – в клиентском приложении осуществляется минимальная обработка данных (нет необходимости перезагружать страницу); – совмещения серверных технологий и преимуществ клиентской обработки. Экранные формы обеспечивают визуализацию документа, поэтому, как и таблицы стилей являются средством форматирования документа. Отличия между этими видами визуального представления документа заключается в том, что: – с помощью языка xForms обеспечивается преобразование визуальных данных, вводимых пользователем, в XML-данные, в то 243 время как с помощью таблиц стилей осуществляется обратное преобразование; – часть элементов данных документа, отображаемых на экранных формах и реализованных с помощью языка xForms, являются активными (т.е. реагирующими на действия пользователя), а в таблицах стилей данные просто отображаются. Спецификация SOAP. Говоря об описании документа, следует иметь в виду еще одну форму его представления, когда информация документа передается по каналам связи в виде последовательности сигналов. При этом данные документов, представляемые в виде сложных иерархических схем, требуется преобразовать в последовательность логических элементов с указанием адресов отправителя и назначения, а также другой служебной информации. Эту ситуацию можно сравнить с отправкой письма по почте, когда мы вкладываем письмо в конверт и отправляем его по определенному адресу, указанному на конверте. На конверте указывается также обратный адрес, а также другая служебная информация (например, способ доставки, объявление ценности и т.д.). Данная форма представления информации, предназначенная для передачи и приема другой программой, называется кодограммой (КдГ) или сообщением. В рамках XML-платформы разработана спецификация SOAP [28], которая формализует процедуру упаковки (распаковки) XML-данных в SOAP-конверты (из SOAP-конвертов). Таким образом, XML-платформа, с одной стороны, содержит в себе средства для представления всех логических частей документа: – XML-схемы, описывающие структуры документов ПрО; – XML-документы, соответствующие XML-схемам, и представляющие данные экземпляров документов; – таблицы стилей XSL, используемые для описания формы документов. С другой стороны, в XML-платформе представлены средства для реализации коммуникативных функций: – таблицы стилей XSL, используемые для преобразования XMLфайлов в HTML-файлы, используются для передачи информации, содержащейся в XML-документе пользователю. 244 – файлы xForms, используемые для формирования визуального отображения вводимых данных и их преобразования в XML-формат являются средством передачи информации от пользователя системе; – SOAP-конверты, используются для передачи и приема данных в XML-документов по каналам связи. 7.1.3 ЯЗЫКИ РАЗМЕТКИ И РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ КАК ВЗАИМОДОПОЛНЯЮЩИЕ ТЕХНОЛОГИИ ПРЕДСТАВЛЕНИЯ ДАННЫХ Описанные в предыдущем подразделе средства XML-платформы обеспечивают формальное описание всех трех логических частей документа, а также содержат в себе средства для реализации коммуникативных функций, обеспечивающих прием и передачу данных, представленных в XML-формате. Другими словами, XML-платформа по сравнению с реляционными СУБД имеет гораздо больше возможностей, как в части описания данных, так и в части реализации возможностей по приему и передаче данных. В связи с этим возникает вопрос: нельзя ли при разработке распределенных систем заменить реляционные БД, служащие в подавляющем большинстве сегодняшних АС средствами хранения и источниками данных, текстовыми базами, данные которых представлены с помощью перечисленных языков разметки. При ответе на этот вопрос необходимо учитывать, что: – в рамках XML-технологий пока не наработан арсенал средств, сопоставимый с возможностями СУБД, обеспечивающей индексацию данных, легкость доступа к данным из прикладных программ, разграничение доступа и многие другие операции, присущие системам обработки данных, хранимых в базах; – организовать корректную работу множества пользователей с данными, представленными в файлах практически невозможно. Как только одна из клиентских программ начинает модифицировать такой файл, все остальные пользователи будут либо ждать окончания этого процесса, либо пытаться одновременно внести в файл противоречивые данные, модифицированные разными пользователями; – открытость XML-файлов делает их беззащитными от внешнего просмотра конфиденциальной информации. 245 Поэтому хранение данных по-прежнему предпочтительнее в реляционных БД, так как современные СУБД содержат эффективные средства доступа к отдельным элементам и манипулирования ими, а также сертифицированные средства защиты конфиденциальной информации. С другой стороны, XML-технологии предоставляют полный набор средств для реализации коммуникативных возможностей как в пределах локальной, так и глобальной сети. Эти возможности представляют особый интерес при разработке распределенных систем, т.к. текстовое представление данных, выполненное с применением средств XML-платформы, является инвариантным относительно информационных технологий, используемых в различных взаимодействующих системах. Таким образом, технологии БД и языков разметки представляют альтернативные и взаимодополняющие технологии описания данных, поэтому целесообразно использовать их совместно и провести между ними следующее «распределение обязанностей». СУБД, содержащие в своем арсенале мощные средства по обработке структурированных данных, обслуживают запросы приложений БД и выполняют такие операции, как: – хранение структурированных данных; – индексация данных; – поддержка целостности данных; – доступ к данным из прикладных программ; – разграничение доступа; – множество других операций, присущих системам обработки данных. Средствами XML-платформы могут быть выполнены следующие коммуникативные операции: – передача данных от XML-документа пользователю и от пользователя XML-документу, т.е. выполнение преобразований «XMLВзД»; – передача (прием) данных XML-документа внешней системе (от внешней системы), т.е. выполнение преобразований «XMLКдГ». 246 С учетом перечисленных возможностей бинарного и текстового представления данных ставится задача: определить технологию создания ИЛО распределенной системы на основе интеграции технологий XML и реляционных БД, обеспечивающей представление информации в следующих формах: – реляционных структур, при хранении в БД в SQL-формате; – логических данных (ЛгД), используемых для обработки в ПМ; – текстовой, для временного хранения данных в XML-формате; – кодограммы, при передаче и приеме данных по КС; – визуальной, при обмене данными между пользователем и АС. Эффект от использования описанного подхода представления данных распределенной АС заключается в том, что практически все преобразования, включая «XMLЛгД», «XMLВзД», «XMLКдГ», реализуются унифицированными процессорами из состава инфраструктуры XML-платформы. Исключение составляют преобразования «XSDSQL», для которых приходится разрабатывать программный код в рамках создания СПО АС. 7.1.4 СОСТАВ ИЛО РАСПРЕДЕЛЕННЫХ АС Для определения состава средств обработки данных, включаемых в состав ИЛО распределенных АС, обратим внимание на следующее обстоятельство. Если работу АС рассматривать с точки зрения реализации ее информационных процессов, то можно обнаружить, что кроме логической обработки (преобразования структуры и контента документов), довольно большой объем работы АС связан с преобразованием одних форм существования данных в другие. Необходимость выполнения этих преобразований объясняется тем, что в человеко-машинных системах приходится иметь дело с многообразием форм представления информации в следующем составе: – информация, предназначенная для восприятия человеком, как правило, представляется в форме визуального документа, максимально приближенной к форме его бумажного оригинала; 247 – после ввода пользователем, т.е. представления в визуальной форме, данные преобразуются в текстовую форму, т.е. в сообщения для передачи другим программным средствам; – сообщения в текстовой форме в приложениях преобразуются в логическую форму, например, в данные экземпляров классов объектно-ориентированного языка программирования, с целью их логической обработки; – если данные (введенные, обработанные приложением или принятые по каналам связи) требуется сохранить в БД, то они преобразуются в реляционную форму, путем их размещения в таблицах; – при передаче по каналам связи данные преобразуются в кодограммы для их представления в виде последовательности электрических сигналов. Известны два способа выполнения преобразований одних форм представления данных в другие: – «каждая в каждую», согласно которому для каждой формы представления информации создаются преобразователи во все другие формы; – «центральное звено», в соответствии с которым одна из форм представления определяется как «центральная», для которой создаются взаимно обратные преобразователи во все остальные формы. Последний способ реализации преобразований предпочтительней, т.к. схема «каждая в каждую» требует , а схема «центральное звено» – всего преобразователей, где – количество форм представления информации. Ценность использования XML-платформы для организации ИЛО АС заключается в том, что информация, представляемая в виде XMLданных, может служить «центральным звеном» для остальных форм материализации информации, как показано на Рис. 7.2. Еще одним достоинством описания данных с помощью языков разметки является то обстоятельство, что для преобразования текстовых данных в другие формы представления в рамках XML-платформы, а также семейства интерфейсов Java API for XML (JAX) создана инфраструктура в виде следующих унифицированных процессоров. 248 ПМ ПИ «ЛгД-XML» ЛгД - Cls ЛгД - Rld ВИ «ВзД-XML» XMLформат ПМП «XML-SQL» СУБД SQL ВзД - HTML БД Канал связи КИ «КдГ-XML» КдГ - SOAP Рис. 7.2 – Состав форматов данных АС и их преобразователей 1. XSD-процессор. Язык XSD (так часто называют спецификацию XSD) определяет структуру XML-документа, что означает наличие средства, поддерживающего соответствие его элементов и структуры описаниям, определенным в XML-схеме. Такое средство создано в рамках XML-платформы и называется XSD-процессором. Поддержка XSD-процессора при формировании и использовании XML-документов заключается в том, что при попытке ввода элемента данных, тип которого не соответствует определенному в XML-схеме, XSD-процессор выдает сообщение об ошибке. XSD-процессор поддерживает также: – соответствие порядка следования элементов XML-документа, определенному в его XML-схеме; – уникальность значений элементов XML-документа, если она определена в XML-схеме; – ограничения ссылочной целостности на значения элементов данных точно так же, как это делается в реляционных СУБД. При попытке ввода значения элемента данных, выходящего за пределы такого ограничения, XSD-процессор реагирует на это выдачей соответствующего сообщения. Наличие XSD-процессора в составе XML-платформы обеспечивает использование данных XML-документа в языках программирования и 249 БД, что существенно повышает значимость такой формы представления данных. 2. XSL-процессор. Для представления информации пользователю данные XML-документа должны быть преобразованы в визуальную форму. Отображение данных XML-документа пользователю выполняется с помощью XSL-процессора, встроенного в браузер. При этом XSL-процессор, используя шаблоны XSL-файла, преобразует данные XML-документа в HTML-код, который с помощью браузера преобразуется в визуальные данные. Поэтому обозначим операцию, выполняемую с помощью XSL-процессора, как преобразование «XML ВзД». 3. XForms-процессор. При вводе данных в АС пользователь определяет данные в визуальной форме, а затем эти данные преобразуются в текстовую форму и фиксируются в XML-документе. Ввод данных пользователем в визуальной форме выполняется с помощью экранной формы. Экранная форма для ввода данных конкретного документа АС создается с помощью предварительно созданного xForms-файла. Введенные с этой экранной формы данные могут быть предназначены для выполнения операций вставки, выборки, обновления или удаления записей БД, и с помощью xFormsпроцессора, встроенного в браузер, сохраняются в XML-документе. Обозначим эту операцию, выполняемую с помощью xForms-процессора, как преобразование «ВзД XML». Если спецификации XML, XSD и XSLT заняли прочные позиции в арсенале средств проектирования информационных систем, и соответствующие процессоры для их поддержки встроены в браузеры, то этого нельзя сказать о спецификации xForms. Хотя эта спецификация была опубликована консорциумом 3WC еще в 2002 году, но до сих пор в популярных браузерах не реализованы средства ее поддержки, т.е. xForms-процессоры. 4. SOAP-процессор. По спецификации SOAP, вкратце описанной в подразделе 7.1.2, в рамках XML-платформы реализованы SOAP-процессоры, преобразующие XML-документы в кодограммы (т.е. фор- 250 мирующие по XML-документам SOAP-конверты) и обратно (т.е. извлекающие из SOAP-конвертов XML-документы). Передача XML-данных по каналу связи с использованием SOAPпроцессора, встроенного в сервер приложения АС, выполняется в следующем порядке: – SOAP-процессор принимает передаваемый XML-документ; – данные XML-документа (а также необходимая служебная информация) с помощью SOAP-процессора упаковываются в SOAPконверт и передаются по каналу связи удаленной АС. С помощью SOAP-процессора выполняется также прием XML-данных, поступающих по каналу связи. При этом SOAP-процессор: – принимает SOAP-конверт по КС от удаленной АС; – распаковывает его данные с помощью SOAP-процессора и составляет из них XML-документ. Информация, упакованная в SOAP-конверт, по существу является КдГ, представленной в XML-формате. Поэтому обозначим операцию формирования SOAP-конверта, как преобразование «XML КдГ», а операцию извлечения XML-данных из SOAP-конверта – как преобразование «КдГ XML». 5. SQL-процессор. SQL-процессор был создан задолго до появления XML-платформы и в составе СУБД успешно эксплуатируется с 80-х годов прошлого столетия [15]. SQL-процессор выполняет операции в БД с произвольной схемой в следующем порядке: – в соответствии со сформированным выражением запроса выполняются операции выборки, вставки, обновления или удаления данных в БД; – после выполнения операции выдается набор данных (после операции выборки) или текст уведомления (после операций вставки, обновления или удаления). 6. Набор прикладных программных интерфейсов JAXB. Средствами набора программных интерфейсов JAXB (Java API for XML Binding) из состава JAX, обеспечивается быстрый и удобный способ создания двухстороннего преобразования между XML-документами и классами языка Java. Имея XML-схемы обрабатываемых XMLдокументов из состава ИЛО, компилятор JAXB создает набор классов 251 Java, необходимый для анализа XML-документов, основанных на данных схемах [29]. Разработчик, использующий созданные классы, может строить дерево объектов Java, изображающих XML-документ, обрабатывать содержимое этого дерева и заново создавать XML-документы из него. При этом он остается в своей привычной объектно-ориентированной среде программирования. Реализация JAXB технологии включает в себя следующие архитектурные компоненты: – компилятор схемы: связывает исходные XML-схемы с классами языка Java; – генератор схемы: с помощью аннотаций, встроенных в классы, отображает классы языка Java на XML-схему; – платформа JAXB: обеспечивает операции демаршалинга (чтения) и маршалинга (записи) данных XML-документов, используя сведения из XML-схемы. Важно подчеркнуть, что программные интерфейсы JAXB, а также ПМ, выполняющие обработку объектно-ориентированных данных (полученных преобразованием XML-документов), относятся к сфере ПО АС. В данном подразделе эта технология упомянута с целью показать, что данные рассматриваемого ИЛО, представленные в XML-формате, могут быть непосредственно использованы не только стандартными процессорами инфраструктуры Web-среды, но и приложениями из состава ПО АС. При этом архитектурными компонентами JAXB реализуется еще один вид преобразований, а именно, «XMLЛгД ». Таким образом, практически все преобразования, выполняемые в ходе функционирования АС, включая «XMLВзД», «XMLКдГ», «XMLЛгД», реализуются унифицированными процессорами. Исключение составляют преобразования «XMLSQL», выполняемые при вводе (выводе) XML-данных в (из) БД (см. Рис. 7.2). Для этой категории преобразований приходится создавать ПМ, обеспечивающие ввод (вывод) XML-данных типовых документов в (из) БД. Сложность реализации этих преобразований заключается в том, что при: 252 ИЛО распределенной АС Внемашинное ИЛО Унифицированная система документации Словари и классификаторы Нормативно-справочная информация Внутримашинное ИО Базы данных SQL-процессор XML-файлы (обменные форматы документов) XML-Схемы (XSD) документов ПрО XSD-процессор SOAP-процессор ПМ преобразования «XML-SQL» Внутримашинное ЛО Словари (представлены в XML-Схемах) XSLT-файлы экранных форм XForms-файлы экранных форм XSL-процессор XForms-процессор Рис. 7.3 – Состав и структура ИЛО распределенной АС 253 – вводе в БД необходимо по входным XML-данным сформировать выражение запроса на языке SQL; – выводе из БД наборы реляционных данных или уведомления о выполнении операции доступа необходимо представить в виде XML-данных. Следует также отметить, что как только технология XML получила достаточную известность, через некоторое время появились реляционные СУБД, предложившие обмен данными на языке XML. В качестве примера такой СУБД можно привести Oracle, в которой были проведены следующие модификации [30]: – в состав СУБД был введен конвертор, осуществляющий преобразования «SQLXML»; – разработан специальный язык запросов XQL, с помощью которого формулируются запросы, управляющие выполнением преобразований для конкретных XML-данных в конверторе. К сожалению предложенный подход на сегодняшний день не получил широкого распространения, поэтому для выполнения преобразований «SQLXML» для каждого типового документа, попрежнему, приходится создавать соответствующие программные модули преобразования (ПМП). Таким образом, использование для представления данных спецификаций XML-платформы, расширяет спектр формализованных компонентов декларативной части ИЛО. Это приводит к тому, большинство операций по преобразованию форматов данных (при их вводе, выполнении доступа к данным базы, отображении, приеме и передаче по КС) выполняются унифицированными процедурами, реализованными в стандартных процессорах из инфраструктуры Web-среды. Поэтому по традиции, сложившейся при создании ИЛО автономных АС, целесообразно включить все перечисленные унифицированные процессоры и ПМП в состав ИЛО распределенной АС, как показано на Рис. 7.3. 254 7.1.5 ОПЕРАЦИИ, ВЫПОЛНЯЕМЫЕ ИНФРАСТРУКТУРНЫМИ КОМПОНЕНТАМИ РАСПРЕДЕЛЕННОЙ СИСТЕМЫ Объявленная цель увеличения относительного объема формализованных данных ИЛО АС, в конечном счете, направлена на унификацию обработки этих данных с помощью соответствующих процессоров, реализованных на основе спецификаций, разработанных как в рамках технологии реляционных БД, так и в рамках XMLплатформы. Таким образом, развитие и совершенствование моделей данных и средств их обработки взаимно влияют друг на друга, а описанные выше унифицированные процессоры из состава инфраструктуры Web-среды и сервера БД, а также ПМП из состава СПО АС, можно рассматривать как результат достигнутого уровня формализации представления документов АС. Поэтому в описываемом ИЛО распределенной АС изменяется не только состав декларативной составляющей, но и его процедурная часть подвергается существенным изменениям (см. Рис. 7.3), которые заключаются в том, что: – расширяется состав унифицированных процессоров, обеспечивающих стандартную обработку всех аспектов представления документов (контента, данных о структуре и форме); – большинство стандартных обработчиков может работать с распределенными данными, т.к. размещается в глобальном адресном пространстве; – стандартизация входных и выходных атрибутов процессоров, представленных специфицированными форматами XMLплатформы и технологии реляционных БД, обеспечивает возможность их комбинирования для организации более сложных процессов. Как было показано в подразделе 7.1.4, унифицированные процессоры из состава инфраструктуры Web-среды и сервера БД, ПМП из состава СПО АС также входят в состав ИЛО и их организация в архитектуре АС должна быть соответствующим образом согласована с организацией декларативной составляющей. 255 7.1.5.1 С х е м а р а з м е щ е н и я л о к а л ь н о й и распределенной составляющих ИЛО Особенность рассматриваемого ИЛО распределенной АС заключается в том, что в нем кроме традиционных составляющих, включающих внемашинное ИЛО и внутримашинное ИО, а также ЛО, реализованное в составе СПО АС, содержатся: – формальное описание сведений о структуре и форме всех типовых документов из УСД внемашинного ИЛО АС; – семейство унифицированных процессоров, осуществляющих взаимно-обратное преобразование текстовых данных в другие формы представления. Это означает, что описания всех логических частей документов АС входят в состав внутримашинного ИЛО и доступны для программной обработки как унифицированными процессорами из состава ИЛО, так и приложениями из состава ПО АС. Другая особенность предлагаемого ИЛО определяется его распределенным характером и связана с размещением его компонентов. В описываемой схеме размещения компонентов ИЛО предполагается, что современные АС, входящие в распределенную систему, имеют трехзвенную архитектуру, содержащую уровни сервера данных, сервера приложений и клиентского приложения. В зависимости от места размещения компонента ИЛО в трехзвенной архитектуре определяется его доступность: – при размещении компонента ИЛО в папках сервера приложений для него определяется URL-адрес, что обеспечивает доступ к нему со всех АС распределенной системы; – процедурные компоненты, встроенные в Web-браузер, поддерживают загруженные в него XML-документы. При этом URL-адреса XML-документов с помощью встроенных компонентов-обработчиков обеспечивают связь с другими XML-документами, размещенными на удаленных АС; – компоненты, размещенные на сервере БД, доступны только для локальной СУБД, а через нее для приложений, размещенных на данной АС. 256 АС Клиентские приложения Сервер приложений Сервер данных ЛО распределенной АС ИЛО распределенной АС ИО локальной АС XML XSD БД СУБД 4 XML XSD-процессор 1 xForm-процессор Локальная сеть XSL-процессор 2 XSL 3 xForm 5 SOAP 6 7 Глобальная сеть Концептуальная схема документа SOAP-процессор АС АС ПМП «SQL-XML» АС Рис. 7.4 – Схема размещения компонентов внутримашинного ИЛО распределенной АС Схема размещения компонентов внутримашинного ИЛО распределенной АС приведена на Рис. 7.4. Размещение компонентов декларативной составляющей ИЛО согласно данной схеме описывается следующим образом: 257 – схема БД, соответствующая концептуальной схеме ПрО размещается на сервере данных; – БД, описываемая этой схемой, и заполненная данными экземпляров типовых документов, размещается на сервере данных; – обменные форматы документов, представляющие собой XMLдокументы, составленные по соответствующим XML-схемам, размещаются на сервере приложений; – XML-схемы, созданные по концептуальным схемам типовых документов размещаются на сервере приложений; – xForms-файлы, обеспечивающие визуализацию процесса ввода данных экземпляров типовых документов, размещаются на сервере приложений; – XSL-файлы, обеспечивающие визуальное отображение данных документов, размещаются на сервере приложений. Процедурная составляющая ИЛО обеспечивает доступ к его декларативным компонентам как для локальных, так и для удаленных приложений распределенной системы. Размещение процедурной составляющей ИЛО описывается следующим образом: – SQL-процессор традиционно размещается на сервере данных и доступен только для приложений, размещенных на локальной АС; – XSD-процессор встроен в Web-браузер и обеспечивает связь XML-документов, загруженных в клиентское приложение данной АС, с XML-схемами, размещенными на локальной или удаленных АС распределенной системы; – XSL-процессор встроен в Web-браузер и обеспечивает связь XML-документов, загруженных в клиентское приложение данной АС, с XSL-файлами, размещенными на локальной или удаленных АС распределенной системы; – XForms-процессор встроен в Web-браузер и обеспечивает связь XML-документов, загруженных в клиентское приложение данной АС, с XForms-файлами, размещенными на локальной или удаленных АС распределенной системы; – SOAP-процессор размещается на сервере приложений и обеспечивает формирование по XML-документам SOAP-конвертов и их 258 передачу по каналу связи, а также прием SOAP-конвертов, поступивших по каналам связи, и извлечение из них XML-документов; – ПМП размещается на сервере приложений и обеспечивает доступ к СУБД как для локальных, так и удаленных приложений распределенной системы. На сегодняшнем этапе развития теории и практики распределенной обработки приложения, доступ к которым осуществляется с удаленных систем, реализованы в виде Webсервисов. Подробное описание этой довольно сложной технологии программирования приведено в работе [31]. 7.1.5.2 Б а з о в ы е о п е р а ц и и И Л О Процедуры, выполняемые в ходе функционирования АС, реализуются в виде преобразований форматов данных XML-платформы и технологии БД, которые в рассматриваемом ИЛО обозначаются и описываются следующим образом: – – данные в XML-формате, предназначенные для преобразования в другие форматы; – – визуальные данные, введенные на экранной форме; – – визуальные данные, полученные путем преобразования с помощью таблицы стилей ; – – выражение запроса на языке SQL для выполнения SQL-процессором; – – результат выполнения запроса, представленный в виде набора данных или текста уведомления; – – xForms-файл, используемый для формирования экранной формы, предназначенной для ввода данных в визуальной форме и их преобразования в XML-формат ; – – XSL-файл, предназначенный для преобразования данных в XML-формате в визуальную форму; – – данные входного SOAP-конверта, полученные по КС; – – данные выходного SOAP-конверта, подготовленные для передачи по КС. Далее опишем операции преобразования перечисленных форматов представления данных ИЛО, общее описание которых было приведено в подразделе 7.1.4. Назовем эти операции базовыми, т.к. 259 на их основе (с небольшими добавлениями не базовых операций) можно составить практически все типовые процедуры по ведению ИЛО и распределенной обработки данных. Инфраструктура Webсреды, технологии БД и СПО АС, обеспечивающая выполнение базовых операций, с указанием их входных и выходных атрибутов, показана на Рис. 7.5, а более детальное и формализованное описание собственно базовых операций приведено ниже по тексту. 1. Операция «Ввод визуальных данных». Ввод данных документа в систему осуществляется с помощью экранной формы, построенной в соответствии с концептуальной схемой типового документа. Операция ввода данных пользователем осуществляется в следующем порядке: – по xForms-файлу из состава ИЛО распределенной системы, созданному на основе XML-схемы, в клиентской части АС xForms-процессором генерируется экранная форма; – пользователь с помощью экранной формы вводит необходимые данные в визуальной форме. При этом xForms-процессор, входящий в состав браузера, поддерживает реакции экранной формы на действия пользователя по вводу данных; – после ввода всех необходимых данных пользователь нажимает на кнопку подтверждения завершения ввода данных, и xForms-процессор сохраняет введенные данные в XML-формате в файле из состава ИЛО АС. Базовую операцию, выполняемую с помощью xFormsпроцессора и осуществляющую преобразование «ВзД XML», назовем «Ввод визуальных данных». 2. Операция «Прием кодограммы». Другая форма ввода данных в систему осуществляется путем приема КдГ по КС. Данные, поступившие в систему по КС, в соответствии с требованиями протокола SOAP, содержатся в SOAP-конверте. Эти данные при поступлении в систему должны быть приняты, а затем в ходе анализа содержания SOAP-конверта с помощью SOAP-процессора из него должно быть извлечено передаваемое сообщение и сохранено в XML-формате. 260 Сервер баз данных ИО ЛАС SQLпроцессор БД Isql Osql Сервер приложений ИЛО РАС Osql ПМП СПО АС XSD Cxml Isql Cxml Oenv SOAPпроцессор Cxml Ienv Канал связи локальной АС ПМ СПО АС Cxml XML Oxsl XSL Ixfr xForm Клиент XSLпроцессор XSDпроцессор Ivsl XFormsпроцессор Oxsl Cxml Ienv Cxml Ixfr Cxml Oenv Глобальный канал связи Ovsl Глобальная сеть ПМП - программный модуль преобразования, ИО - информационное обеспечение, СПО - специализированное ПО, ЛАС - локальная АС, РАС - распределенная АС Рис. 7.5 – Инфраструктура Web-среды и программных средств АС, используемая для выполнения базовых операций 261 Операция ввода данных, принятых по КС, осуществляется в следующем порядке: – средствами взаимодействия АС с внешними системами осуществляется прием SOAP-конверта , поступившего по КС, и его сохранение в буферной памяти сервера приложений для последующего анализа; – в SOAP-конверте помимо информационной части, т.е. принимаемых данных содержится различная служебная информация, поэтому принятая информационная составляющая из конверта должна быть извлечена и помещена в XML-документ из состава ИЛО АС. Эта стандартная операция называется «распаковка данных конверта» и выполняется с помощью SOAP-процессора, входящего в состав сервера приложений. Базовую операцию, выполняемую с помощью SOAP-процессора и осуществляющую преобразование «SOAP XML», назовем «Прием кодограммы». 3. Операция «Формирование запроса». Формирование выражения запроса по данным, введенным пользователем или принятым по КС, и сохраненном в XML-формате, осуществляется в следующем порядке: – формирование выражения запроса на языке SQL осуществляется ПМП из состава СПО АС по данным, содержащимся в файле . В результате выполнения этой процедуры в зависимости от характера данных формируется выражение запроса для выполнения в БД с помощью SQL-процессора одной из операций: выборки, вставки, обновления или удаления данных; – ПМП устанавливает связь с СУБД; – ПМП отправляет выражение непосредственно СУБД, размещенной на сервере данных. Базовую операцию, выполняемую с помощью ПМП и осуществляющую преобразование «XML SQL», назовем «Формирование запроса». 4. Операция «Выполнение запроса». Выполнение запроса реализуется СУБД, одной из унифицированных процедур ее SQL-про- 262 цессора в зависимости от сформированного выражения запроса на языке SQL. В ходе выполнения этой процедуры осуществляется: – прием выражения запроса и его выполнение СУБД. При этом может быть выполнена одна из следующих операций доступа: а) «Выборка данных БД»; б) «Вставка данных БД»; в) «Обновление данных БД»; г) «Удаление данных БД»; – формирование СУБД результатов выполнения операции и отправление в ПМП из состава СПО АС. Данная базовая операция, названная «Выполнение запроса» реализуется SQL-процессором, запускается из процедуры «Формирование запроса». 5. Операция «Формирование ответа». Полученный после выполнения операции БД результат либо отображается на экране пользователя, либо передается по КС удаленной АС. Обе операции для своей реализации требуют преобразования данных , полученных в результате выполнения процедуры «Выполнение запроса», в XMLдокумент . В зависимости от выполненной операции описываемая процедура должна сформировать либо: – после выполнения операции выборки – структурированный XML-документ, согласованный с соответствующей XML-схемой; – после выполнения других операций – XML-документ, содержащий простой текст уведомления о выполненной операции, размещающийся в пределах одного тега. Базовую операцию, выполняемую с помощью ПМП и осуществляющую преобразование «SQL XML», назовем «Формирование ответа». 6. Операция «Вывод визуальных данных». Отображение данных системы пользователю осуществляется путем их сохранения в форме XML-документа и его открытия с помощью XSL-процессора, встроенного в браузер. Для визуализации данных XML-документа использу- 263 ется XSL-файл из состава ИЛО АС, представляющий собой последовательность шаблонов форматирования XML-документа. Назначение данной процедуры заключается в: – определении XML-документа , содержащего отображаемые данные; – вызове XSL-процессора для обработки XSL-файла , URLадрес которого содержится в заголовочной части XML-документа ; – преобразовании XML-документа в HTML-код, а затем в визуальную форму с помощью браузера. Базовую операцию, выполняемую с помощью XSL-процессора и осуществляющую преобразование «XML ВзД», назовем «Вывод визуальных данных». 7. Операция «Передача кодограммы». Данные, подготовленные для передачи по КС, должны отвечать требованиям протокола SOAP. Согласно спецификации протокола SOAP передаваемые данные должны быть представлены в XML-формате, размещены в SOAPконвертах и переданы по КС. Размещение XML-данных в SOAP-конвертах можно представить как преобразование «XML SOAP», реализуемое в виде процедуры упаковки данных XML-документа в SOAP-конверт. Эта процедура унифицирована и выполняется с помощью SOAP-процессора, встроенного в сервер приложения АС. При этом: – определяется передаваемый XML-документ ; – выбранный документ подается на вход SOAP-процессора, где и происходит его преобразование в ; – далее SOAP-конверт передается по КС средствами сервера приложений. Базовую операцию, выполняемую с помощью SOAP-процессора и осуществляющую преобразование «XML SOAP», назовем «Передача кодограммы». 264 7.1.5.3 П р о ц е д ур ы р а с п р е д е л е н н о й А С к а к комбинации базовых операций Функционирование АС, входящей в распределенную систему, можно представить как выполнение следующих типовых схем ее работы: – «Работа с локальной БД», представляется как ввод данных для выполнения операции доступа локальной СУБД и отображение результатов выполнения; – «Работа с локальным ПМ», представляется как ввод данных для выполнения работы локального ПМ и отображение результатов выполнения; – «Работа с удаленной БД», представляется как ввод данных для выполнения операции доступа удаленной СУБД, передачу введенных данных и прием результатов работы удаленной СУБД по КС, отображение результатов выполнения; – «Работа с удаленным ПМ», представляется как ввод данных для выполнения работы удаленного ПМ, передачу введенных данных и прием результатов работы удаленного ПМ по КС, отображение результатов выполнения. С одной стороны, по описанным схемам можно реализовать практически любую работу, выполняемую распределенной системой, с другой стороны, любую из процедур, приведенных выше, можно определить как комбинацию базовых процедур, описанных в пункте 7.1.5.2. Процедуры распределенной АС, представляемые как комбинации базовых процедур, описываются следующим образом. 1. Процедура «Работа с локальной БД» составляется из следующей последовательности базовых операций: – «Ввод визуальных данных» – пользователем вводятся данные, необходимые для выполнения операции доступа; – «Формирование запроса» (не является базовой операцией) – по введенным данным ПМП формирует выражение запроса для выполнения операции доступа в БД; 265 – «Выполнение запроса» – локальной СУБД выполняется операции доступа и выдается результат; – «Формирование ответа» (не является базовой операцией) – по выданному результату ПМП формирует XML-документ; – «Вывод визуальных данных» – сформированный XML-документ отображается пользователю. 2. Процедура «Работа с локальным ПМ» составляется из последовательности операций: – «Ввод визуальных данных» – пользователем вводятся данные, необходимые для выполнения локального ПМ; – Выполнение работы локального ПМ (не является базовой операцией) – результат выполнения выдается в виде XML-документа; – «Вывод визуальных данных» – выданный XML-документ отображается пользователю. 3. Процедура «Работа с удаленной БД» составляется из последовательности операций, выполняемых на разных АС (локальной и удаленной) распределенной системы: – «Ввод визуальных данных» – локальным пользователем вводятся данные, необходимые для выполнения операции доступа в удаленной АС; – «Передача кодограммы» – введенные данные (в виде XMLдокумента) передаются удаленной АС по КС; – «Формирование запроса» (не является базовой операцией) – по введенным данным ПМП удаленной АС формирует выражение запроса для выполнения операции доступа СУБД данной АС; – «Выполнение запроса» – удаленной СУБД выполняется операции доступа и выдается результат; – «Формирование ответа» (не является базовой операцией) – по выданному результату ПМП удаленной АС формирует XML-документ; – «Передача кодограммы» – сформированный XML-документ передается в локальную АС; – «Прием кодограммы» – переданный XML-документ принимается в локальную АС; 266 – «Вывод визуальных данных» – принятый XML-документ отображается пользователю. 4. Процедура «Работа с удаленным ПМ» составляется из последовательности операций, выполняемых на разных АС (локальной и удаленной) распределенной системы: – «Ввод визуальных данных» – локальным пользователем вводятся данные, необходимые для выполнения работы удаленного ПМ; – «Передача кодограммы» – введенные данные (в виде XMLдокумента) передаются удаленной АС по КС; – Выполнение работы удаленного ПМ (не является базовой операцией) – результат выполнения выдается в виде XML-документа; – «Передача кодограммы» – выданный XML-документ передается в локальную АС; – «Прием кодограммы» – переданный XML-документ принимается в локальной АС; – «Вывод визуальных данных» – принятый XML-документ отображается пользователю локальной АС. Как видно из приведенных описаний, небольшое число не базовых операций в перечисленных процедурах все же используется. Но описанная организация работы АС, опирающаяся на предлагаемое ИЛО распределенной АС, обладает следующими достоинствами: 7.2 ТЕХНОЛОГИЧЕСКАЯ ЛИНИЯ РАЗРАБОТКИ ИЛО АС Предлагаемый подход интеграции технологии баз данных и XML-технологий предусматривает разработку XSD-, XML-, XSL- и SOAP-файлов. Это требует выполнения большого объема работ по кодированию и отладке документов, составленных по разным спецификациям. Поэтому для успешного внедрения данной технологии разработки ИЛО распределенной АС требуется снизить трудоемкость создания его компонентов. На сегодняшний день на рынке программных продуктов представлен широкий спектр средств автоматизации, существенно облегчающих процесс разработки и создания всех перечисленных компонентов представления документов. Задача заключается в том, 267 чтобы выстроить из этих средств единую технологическую линию автоматизированной разработки ИЛО. Технологический процесс разработки ИЛО АС должен начинаться с определения концептуальной схемы ПрО и ее фиксирования в памяти машины либо в виде схемы базы данных, либо в виде XML-схемы, с тем, чтобы на ее основе вывести все остальные компоненты ИЛО. При этом необязательно разрабатывать обе схемы, достаточно разработать одну из них, а другую, воспользовавшись изоморфизмом структур схем баз данных и XML-схем можно сформировать путем соответствующего преобразования спецификаций уже разработанной схемы. Если речь идет о вновь создаваемой АС, то целесообразно сначала разработать XML-схему, а на ее основе с помощью XML-редактора – сгенерировать схему БД. Если АС уже создана, и она интегрируется с другими системами, то на основе имеющихся схем БД с помощью того же XMLредактора можно сгенерировать соответствующие XML-схемы. Далее, на основе полученной XML-схемы создаются расширяемая таблица стилей XSL, xForms-файл для формирования диалогового окна ввода данных ИР и структура кодограммы для передачи контента ИР в виде SOAP-конверта. На Рис. 7.6 приведен один из возможных вариантов технологической линии автоматизированной разработки ИЛО АС, реализованной по описанной схеме. Обратите внимание на то, что связь между компонентами схемы БД и XML-схемы изображена двумя стрелками. Это говорит о том, что на данной технологической линии в зависимости от обстоятельств основой формирования ИР могут быть приняты как XML-схемы, так и схемы баз данных. По данному рисунку видно, что относительно к традиционной схеме разработки ИО описание ИР с помощью языков разметки обеспечивает существенно больший объем формализации данных. Причем эти данные фиксируются в стандартных форматах и обладают большим интеграционным потенциалом. 268 ИО АС Разработчик данных Редактор таблиц стилей XSLT-файлы Редактор таблиц стилей XSLT-файлы Разработчик данных УФД XML-файлы Разработчик данных XMLредактор УСД, НСИ, СККИ XSD-файлы Разработчик данных CASEсредство Схемы БД УСД, НСИ, СККИ Базы данных Внемашинное ИО SOAP-конверт Неформализованная НСИ Программист ПО АС Интегрированная среда разработки программ ПМ функций управления Рис. 7.6 – Автоматизированная линия разработки ИЛО АС 269 7.2.2 СРЕДСТВА ДЛЯ РАЗРАБОТКИ СХЕМЫ БАЗЫ ДАННЫХ Для разработки схем баз данных в рамках традиционной технологии разработки ИО АС созданы и широко используются так называемые средства CASE (Computer-Aided Software Engineering) различного класса и назначения, существенно облегчающие процесс создания баз данных с большой номенклатурой таблиц и множественными связями между ними. В России популярностью пользуется CASE-средство ERwin [32], используемое как инструментарий для построения визуальных диаграмм схем баз данных и генерации скриптов на языке SQL. Данное CASE-средство не привязано к какой-либо конкретной СУБД и поддерживает различные серверы БД и настольные СУБД, а также может обращаться к БД через интерфейс ODBC. 7.2.3 XML РЕДАКТОРЫ ДЛЯ РАЗРАБОТКИ XML-СХЕМЫ Как уже было отмечено, с помощью спецификации XSD можно описать любую структуру данных, используемых современными средствами обработки данных. Система типов данных XSD реализована таким образом, что позволяет конструировать любую структуру для использования в базах данных и программных средствах. Если данные, передаваемые в XML-формате, предполагается хранить в базе данных, то наряду с системой типов данных, для моделирования связей между сущностями можно воспользоваться конструкциями определения первичных и вторичных ключей. Далее приведем краткое описание каждого из звеньев описываемой технологической линии. Описываемая технологическая линия предполагает два способа формирования XML-схемы. 1. XML-схема и ее экземпляры создаются с использованием визуального XML-редактора по концептуальной схеме ПрО. 2. XML-схема и ее экземпляры создаются по разработанным и эксплуатируемым фрагментам схем баз данных. В основе реализации перечисленных вариантов создания XMLсхем лежит наличие строгого соответствия между элементами БД и языковыми конструкциями XML-схемы. На сегодняшний день реа- 270 лизованы XML-редакторы, обеспечивающие возможность автоматической генерации: – XML-схемы по схеме базы данных; – схемы базы данных по XML-схеме. В качестве возможных кандидатов на роль XML-редактора для нашей технологической линии можно рассматривать следующие программные продукты: – редактор XMLSpy фирмы Altova [33]; – свободно распространяемый редактор EditiX [34]; – визуальный XML редактор Syntext Serna [35] и др. Визуальный редактор Altova XMLSpy является наиболее предпочтительным вариантом для нашей технологической линии, так как обеспечивает: – оба варианта разработки XML-схемы; – взаимодействие со средствами разработки других компонентов представления ИР (например, таблиц стилей). 7.2.4 РЕДАКТОРЫ XSLT-ФАЙЛОВ ДЛЯ РАЗРАБОТКИ ТАБЛИЦ СТИЛЕЙ Для разработки таблиц стилей визуального отображения XMLдокументов можно предложить следующие программные продукты: – редактор дизайна XML-документа StyleVision фирмы Altova [36]; – свободно распространяемый редактор EditiX [34]; – инструменты для работы с XML в Visual Studio [37] и др. С учетом предыдущего выбора, из рассматриваемого перечня предлагается выбрать визуальный редактор дизайна StyleVision фирмы Altova, обеспечивающий формирование аутентичного представления документа по его XML-схеме и рабочему XML-файлу. Разработка XSL-файлов в данном редакторе выполняется в три шага в следующей последовательности: – по XML-схеме и XML-документу разрабатывается дизайн документа в виде промежуточного файла; – на основе разработанного дизайна генерируется XSLT-файл; 271 – с помощью XML-редактора XMLSpy в XML-файл добавляется URL-адрес сгенерированного XSLT-файла. Обратите внимание на тот факт, что на последнем этапе разработки XSLT-файла используется XML-редактор XMLSpy. Это говорит в пользу выбора этих редакторов, так как они, являясь продуктом одной фирмы, работают в комплексе. 7.2.5 XFORMS-РЕДАКТОРЫ Из существующих на сегодняшний день можно выделить следующие реализации xForms-процессоров: – одним из самых развитых xForms-процессоров является Orbeon Forms [38]. Реализован этот процессор на Java в виде Webприложения. Содержит визуальный редактор xForms-документов. Orbeon Forms является достаточно сложным продуктом с большим объемом документации; – betterFORM является более простым решением по сравнению с Orbeon Forms. Содержит только xForms-процессор и реализован в виде Web-приложения на Java. Для работы с Orbeon Forms или betterFORM необходимо использовать какой-либо Web-сервер на основе Java-платформы, например, Apache Tomcat; – xForms-процессор XSLTForms встроен в СУБД «eXist », полностью основанной на технологии XML. XSLTForms является клиентским решением и работает в браузере. При этом нет необходимости использовать Web-сервер; – Mozilla xForms Project является плагином к браузеру Firefox. То есть он, как и XSLTForms, также является «клиентским» решением. Реализован только в Mozilla Firefox версии 3.8. В последующих версиях этого браузера наличие xForms-процессора не наблюдается. Здесь выбрать предпочтительный вариант сложнее, чем для предыдущих звеньев технологической линии, так как каждый из этих вариантов наряду с преимуществами имеет серьёзные недостатки. Среди предлагаемых вариантов xForms-процессоров визуальным редактором, обеспечивающим автоматизированную разработку xForms-документов, имеет только Orbeon Forms, а их реализации, встроенные в Web-браузеры и вовсе отсутствуют. 272 Имея в виду проблемы с реализацией xForms-процессоров при разработке распределенного ИЛО, описанного в подразделе 7.3, предложено отказаться от формирования экранных форм в виде xForms-файла в пользу их создания с помощью редактора StyleVision в виде XSLT-файла. Описание процедуры разработки экранных форм с помощью редактора StyleVision приведено в подразделе 7.3.6. 7.2.6 SOAP-ПРОЦЕССОР SOAP-конверты не являются хранимыми единицами информации и формируются автоматически SOAP-процессором на основе XMLдокументов в ходе функционирования системы при передаче данных. На принимаемой стороне из SOAP-конверта извлекается XMLдокумент, и именно XML-документ является единицей хранения и обработки. Поэтому хранить сформированный SOAP-конверт после его передачи, а также после приема, нецелесообразно [28]. Данное звено в технологической линии (см. Рис. 7.6) отмечено лишь формально, с целью показать, что при формировании SOAPконверта, т.е. кодограммы сообщения, используются XML-документ и его XML-схема, разработанные на этой технологической линии. При приеме SOAP-конверта соответствующий процессор извлекает из него XML-файл, содержащий принятую информацию. 7.3 ПРИМЕР РАЗРАБОТКИ ИЛО НА ОСНОВЕ ИНТЕГРАЦИИ XML-ТЕХНОЛОГИЙ И ТЕХНОЛОГИИ БД В этом разделе на основе примера ПрО «Учебный процесс» продемонстрируем разработку ИЛО распределенной АС. При этом покажем, что XML-схема – это универсальное средство описания грамматики данных, которое может применяться для формирования концептуальных схем ПрО, схем баз данных, экранных форм и даже для автоматического генерирования ПМ отображения XMLданных в БД и обратно. Для освоения материала данного раздела требуются знания по основам XML-технологий. Поэтому прежде чем приступить к дальнейшему изучению материала рекомендуется ознакомиться с материалами учебного пособия [42]. 273 ИЛО автономных АС, описанное в первой части пособия, создаются в соответствии с действующими стандартами, разработанными еще до начала широкого применения XML-технологий. С другой стороны, стандартов разработки ИЛО распределенных АС с применением XML-технологий еще не существует. Поэтому в соответствии с изложенным выше материалом предлагается при разработке ИЛО распределенной АС к ИЛО автономной АС, содержащем внемашинное ИО, внутримашинное ИО и ЛО, добавить (см. разделы 3.5 и 4.4): – данные о структуре документов АС в виде XSD-файлов; – данные о форме документов АС в виде XSL-файлов; – обменные форматы документов АС в виде XML-файлов; – данные о структуре кодограмм, используемых при передаче данных документов АС по КС в виде SOAP-конвертов. Со временем технология разработки ИЛО с учетом приобретенного опыта и более полного использования возможностей XMLплатформы может быть оптимизирована и реализована в виде соответствующих стандартов. Достоинства моделирования данных с помощью XSD состоит в том, что возможности XML-схемы позволяют реализовать автоматизированную генерацию компонентов ИЛО распределенной системы на всех этапах его разработки. При этом модель данных с использованием XSD-спецификации определяется однажды и используется для генерирования компонентов всей системы, вместо того, чтобы создавать их вручную. В рассматриваемом примере сначала создадим XML-схемы документов ПрО «Учебный процесс», унифицированные формы которых были описаны в подразделе 2.4.3. Далее продемонстрируем, как можно использовать созданные XML-схемы для: – формирования XML-схемы для описания ПрО в целом; – реализации схемы БД в качестве хранилища данных XML-документов; – генерирования обменных форматов данных документов ПрО «Учебный процесс» в виде шаблонов XML-документов; 274 – создания расширяемых таблиц стилей для отображения документов и электронной формы для ввода данных в XML-документы; – формирования кодограмм в виде SOAP-конвертов; – генерирования ПМ отображения данных XML-документов в БД; – генерирования ПМ отображения данных из БД в XMLдокумент. 7.3.1 РАЗРАБОТКА УСД СРЕДСТВАМИ XSD Формуляры-образцы документов предметной области «Учебный процесс», описанные в разделе 2.4.3, дают представление о реквизитном составе документов, и в рамках разработки традиционного ИЛО АС оформляются в виде чертежей внешнего вида документов. Но данные о структуре и форме документов, представленные в них, не фиксируются в машинной памяти в формализованном виде и их невозможно использовать при автоматизированной обработке. В примере разработки внемашинного ИО (см. подраздел 2.4) эти данные были использованы на этапе анализа структуры документов, по результатам которого были выделены сначала реквизиты, а затем показатели и, описываемые ими объекты. На этапе разработки внутримашинной ИБ по полученным описаниям объектов была составлена концептуальная схема ПрО. Вся описанная обработка данных формуляров-образцов выполняется в рамках традиционной технологии создания ИЛО «вручную». В составе XML-платформы содержатся средства для формализованного представления всех аспектов описания документов ПрО, в результате применения которых, описания документов становятся доступными для программной обработки. Одним из важнейших средств описания структур данных, в том числе и документов, является спецификация XSD. По данной спецификации можно составить XML-схемы документов, в которых фиксируются объекты документа и их реквизитный состав в виде показателей. Важно подчеркнуть, что спецификация XSD, кроме этого, предоставляет возможности явного представления связей между 275 объектами, также доступные для использования при программной обработке. Эти качества языка XML-схемы позволяют реализовать возможности по автоматизированному созданию остальных компонентов ИЛО, т.к. данные о структуре документов ПрО, в которых содержится вся информация о моделируемой ПрО, представляют собой базовые конструкции для формирования ИЛО распределенной системы в целом. 7.3.1.1 С т р ук т у р а д о к ум е н т а « С п и с о к с т уд е н т о в г р уп п ы » На Рис. 7.7 приведена структура документа, представленная в виде XML-схемы в соответствии со спецификацией XSD. На рисунке в виде корневого элемента представлено сокращенное наименование документа «Список_стд_грп», а также две группы реквизитов, представляющих объекты ГРУППА и СТУДЕНТ. Для объекта ГРУППА в XML-схеме фиксируются реквизиты в виде элементов: – «Группа» – используется в качестве реквизита-признака и имеет тип «string»; – «Кол_стд» – реквизит-основание – определяет количество студентов в группе и имеет тип «integer».; – «Средн_балл – реквизит-основание – определяется по значениям столбца «Прох. балл» таблицы и имеет тип «float». Объект СТУДЕНТ представлен реквизитами: – «Ном_стд» – используется в качестве реквизита-признака и имеет тип «integer»; – «ФИО_стд» – реквизит-основание имеет пользовательский тип «ФИО_стдType»; – «Год_рождения» – реквизит-основание имеет тип «date»; – «Адрес» – реквизит-основание имеет тип «string»; – «Прох_балл» – реквизит-основание имеет тип «float». Для приведения XML-схемы в соответствие с реляционной схемой БД дополнительно определяются: 276 Рис. 7.7 – XML-схема документа «Список студентов группы» 277 – первичный ключ PK_grp объекта ГРУППА – вводится на базе реквизита-признака «Группа»; – первичный ключ PK_std объекта СТУДЕНТ вводится на базе реквизита-признака «Ном_стд»; – для введения вторичного ключа в объект СТУДЕНТ добавляется реквизит «Группа». Вторичный ключ FK_std объекта СТУДЕНТ вводится на базе реквизита «Группа», и ссылается на первичный ключ PK_grp объекта ГРУППА. Введенные ограничения на элементы представлены на схеме, а также описаны в соответствующих блоках «constraints» (см. Рис. 7.7). На XML-схеме приведены не только наименования реквизитов, но указаны их типы данных, а также уточнены диапазоны значений для некоторых реквизитов в виде определения пользовательских типов данных. Например, для реквизита «ФИО_стд» в схеме определен пользовательский тип ФИО_стдType, представленный в виде перечня фамилий студентов, обучающихся на кафедре. Введение ограничений на вводимые значения дает следующие преимущества: – во-первых, облегчает ввод данных, предоставляя перечень допустимых значений для выбора, так что при этом не требуется набирать строку ввода; – во-вторых, предотвращает ввод ошибочных данных, т.к. при этом выбираются данные, введенные и проверенные заранее. 7.3.1.2 С т р ук т у р а д о к ум е н т а « С п и с о к преподавателей кафедры » На Рис. 7.8 приведена XML-схема документа «Список преподавателей кафедры». На рисунке в виде корневого элемента представлено сокращенное наименование документа «Список_прп_каф», а также две группы реквизитов, представляющие объекты КАФЕДРА и ПРЕПОД. 278 Рис. 7.8 – XML-схема документа «Список преподавателей кафедры» 279 Ограничения на значения в виде предопределенных перечней определены для реквизитов в виде пользовательских типов, как и в предыдущей схеме. Объект КАФЕДРА в XML-схеме представлен реквизитами: – «Кафедра» – используется в качестве реквизита-признака и имеет пользовательский тип «КафедраType»; – «Назв_кафедры» – реквизит-основание имеет пользовательский тип «Назв_кафType»; – «Заведующий» – реквизит-основание имеет пользовательский тип «ФИО_препType»; – «Телефон» – реквизит-основание имеет тип «string». Объект ПРЕПОД в XML-схеме представлен реквизитами, указанными в заголовке таблицы: – «Таб_ном» – используется в качестве реквизита-признака и имеет тип «integer»; – «ФИО_прп» – реквизит-основание имеет пользовательский тип «ФИО_прпType»; – «Год_рождения» – реквизит-основание имеет тип «date»; – «Уч_степень» – реквизит-основание имеет пользовательский тип «Уч_степType»; – «Уч_звание» – реквизит-основание имеет пользовательский тип «Уч_званType». – «Кафедра» – добавленный реквизит используется в качестве вторичного ключа для связи с экземпляром объекта КАФЕДРА; Для приведения XML-схемы в соответствие с реляционной схемой БД дополнительно определяются: – первичный ключ PK_kaf объекта КАФЕДРА – вводится на базе реквизита-признака «Кафедра»; – первичный ключ PK_prp объекта ПРЕПОДАВАТЕЛЬ вводится на базе реквизита-признака «Таб_ном»; – вторичный ключ FK_prp объекта ПРЕПОДАВАТЕЛЬ вводится на базе реквизита «Кафедра», и ссылается на первичный ключ PK_kaf объекта ГРУППА. 280 7.3.1.3 С т р ук т у р а д о к ум е н т а «П л а н п р о в е д е н и я з а н я т и й в г р уп п е » На Рис. 7.9 приведена XML-схема документа «План проведения занятий в группе». Процесс выделения реквизитов объектов по данному документу был описан в подразделе 2.4.3.3. Для объекта ГС в XML-схеме представлены реквизиты в виде элементов: – «Ном_ГС» – используется в качестве реквизита-признака и имеет тип «integer»; – «Группа» – реквизит-основание имеет пользовательский тип «ГруппаType»; – «Семестр» – реквизит-основание имеет тип «СеместрType». Объект ИЗУЧЕНИЕ в XML-схеме представлен элементами: – «Ном_плн» – используется в качестве реквизита-признака и имеет тип «integer»; – «Предмет» – реквизит-основание имеет пользовательский тип «ПредметType»; – «Вид_занятия» – реквизит-основание имеет пользовательский тип «Вид_занType»; – «Вид_сдачи» – реквизит-основание имеет пользовательский тип «Вид_сдType». – «Часы» – реквизит-основание имеет тип «integer»; – «ФИО_прп» – реквизит-основание имеет пользовательский тип «ФИО_прпType»; – «Ном_ГС» – добавленный реквизит используется в качестве вторичного ключа для связи с экземпляром объекта ГС. Для приведения описываемого документа к реляционной структуре в данной XML-схеме определены: – первичный ключ PK_GS – на базе реквизита «Ном_ГС»; – первичный ключ PK_pln – на базе реквизита «Ном_плн»; – вторичный ключ FK_pln – на базе реквизита «Ном_плн», ссылающийся на первичный ключ объекта ГС. Для введения вторичного ключа для объекта ПЛАН добавляется реквизит «Ном_ГС». 281 Рис. 7.9 – XML-схема документа «План проведения занятий в группе» 282 С учетом изложенного получаем XML-схему, приведенную на Рис. 7.9, и содержащую корневой элемент «План проведения занятий в группе», а также группы реквизитов, описывающих объекты ГС и ПЛАН. 7.3.1.4 С т р ук т у р а д о к ум е н т а «Э к з а м е н а ц и о н н а я ведомость » На Рис. 7.10 приведена XML-схема документа «Экзаменационная ведомость». В соответствии с учебным планом по каждому изучаемому предмету и по каждому виду занятия требуется провести тестирование, результаты которого фиксируются в данном документе. На рисунке в виде корневого элемента XML-схемы определено сокращенное наименование документа «Ведомость», содержащего группы реквизитов ГС, ПЛАН, ВЕДОМОСТЬ и ОЦЕНКА. Порядок выделения перечисленных объектов по данной схеме описан в подразделе 2.4.3.3. Реквизиты объектов ГС и ПЛАН документа «Экзаменационная ведомость» в XML-схеме представлены точно так же как и в XMLсхеме документа «План проведения занятий в группе» (см. предыдущий подраздел), поэтому в данном подразделе не описываются. Объект ВЕДОМОСТЬ в XML-схеме представлен элементами: – «Ном_вдм» – используется в качестве реквизита-признака и имеет тип «integer»; – «Дата» – реквизит-основание имеет тип «date»; – «Ном_плн» – добавленный реквизит используется в качестве вторичного ключа для связи с экземпляром объекта ПЛАН. Объект ОЦЕНКА в XML-схеме представлен элементами: – «Ном_оц» – используется в качестве реквизита-признака и имеет тип «integer»; – «ФИО_стд» – реквизит-основание, имеет пользовательский тип «ФИО_стдType»; – «Оценка» – реквизит-основание, имеет пользовательский тип «ОценкаType»; – «Подп_прп» – реквизит-основание, имеет пользовательский тип «Подп_прпType»; 283 Рис. 7.10 – XML-схема документа «Экзаменационная ведомость» 284 – «Ном_вдм» – добавленный реквизит, используется в качестве вторичного ключа для связи с экземпляром объекта ВЕДОМОСТЬ. Для приведения описываемой схемы к реляционной структуре в ней определены: – первичный ключ PK_GS – на базе реквизита «Ном_ГС»; – первичный ключ PK_pln – на базе реквизита «Ном_плн»; – первичный ключ PK_vdm – на базе реквизита «Ном_ вдм»; – первичный ключ PK_pln – на базе реквизита «Ном_оц»; – вторичный ключ FK_pln – на базе реквизита «Ном_ГС», ссылающийся на первичный ключ объекта ГС. – вторичный ключ FK_vdm – на базе реквизита «Ном_плн», ссылающийся на первичный ключ объекта ПЛАН. – вторичный ключ FK_oc – на базе реквизита «Ном_вдм», ссылающийся на первичный ключ объекта ВЕДОМОСТЬ. Для введения вторичных ключей в объект: – ПЛАН добавляется реквизит «Ном_ГС». – ВЕДОМОСТЬ добавляется реквизит «Ном_плн». – ОЦЕНКА добавляется реквизит «Ном_вдм». 7.3.2 ГЕНЕРИРОВАНИЕ ШАБЛОНОВ XML-ДОКУМЕНТОВ Описанные XML-схемы содержат в себе средства формализованного описания данных документов, адекватные используемым в языках программирования и БД. С другой стороны, XML-схемы, размещенные на Web-сервере, доступны с любой точки Web-среды, а стандарт XSD, на основе которого реализуются XML-схемы, имеет открытый характер. Поэтому XML-документы, сведения о структуре которых содержатся в соответствующих XML-схемах, доступных по URL-адресам в заголовке, представляют собой средство обмена данными в распределенной системе. Таким образом, для АС, входящих в распределенную систему очень важно иметь возможность представлять обменные форматы ИР в виде XML-документа. В качестве таких ИР в нашем примере рассматриваются данные документов ПрО. Именно путем создания, модификации, просмотра этих документов осуществляется работа должностных лиц 285 с АС, а полученные при этом данные в дальнейшем могут быть использованы для принятия решений. Например, результаты тестирования студентов можно использовать при назначении стипендий, переводе на следующий курс и т.д. При функционировании распределенной АС осуществляется обмен данными документов как между ее подсистемами, так и с внешними АС. Для этого каждый информационный ресурс или типовой документ распределенной среды, должен быть снабжен шаблоном XML-файла, используемым в качестве обменного формата при приеме/передаче данных документов. Количество таких информационных ресурсов в каждой системе может исчисляться сотнями и тысячами, поэтому очень важно иметь средства автоматического определения таких шаблонов по XML-схеме для последующего заполнения данными. Большинство современных XML-редакторов предоставляют такую возможность. Если XML-схема некоторого информационного ресурса определена (пусть это будет XML-схема документа «Экзаменационная ведомость»), то с помощью XML-редактора (например, XMLSpy фирмы Altova) очень легко можно сгенерировать шаблон XML-документа. Для этого в строке меню XML-редактора выбирается команда DTD/Schema/Generate Sample XML file и в окне Generate Sample XML file задаются опции для генерации экземпляра XML-документа. В качестве одного из параметров определим количество элементов c опцией Unbounded. В соответствии с введенными значениями в сгенерированном документе будет определено соответствующее число элементов Оценка, как показано в листинге 7.2. Листинг 7.2. Шаблон документа «Экзаменационная ведомость» <Ведомость xsi:noNamespaceSchemaLocation="Vdm_grp.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ГС> <Ном_ГС>0 <Группа>ИВТВМбд-11 <Семестр>первый 286 <План> <Ном_плн>0 <Предмет>Базы данных <Вид_занятия>лекция <Вид_сдачи>экзамен <Часы>0 <ФИО_прп>Петров И.П. <Ном_ГС>0 <Ведом> <Ном_вдм>0 <Дата>1967-08-13 <Ном_плн>0 <Оценка> <Ном_оц>0 <ФИО_стд>Горлов Б.Н. <Оценка>отлично <Подп_прп>Петров <Ном_вдм>0 ................................ <Оценка> <Ном_оц>0 <ФИО_стд>Горлов Б.Н. <Оценка>отлично <Подп_прп>Петров <Ном_вдм>0 Таким же образом определим шаблоны для остальных документов описываемой ПрО: «Список студентов группы», «Список преподавателей кафедры», «План проведения занятий в группе». Обратите внимание на то, что для некоторых элементов при генерации шаблона введены реальные данные, а для некоторых – нулевые значения. Например, для элемента «Группа» введено значение ИВТВМбд-11 , а для элемента «Ном_ГС» – нулевое значение. Объясняется это тем, что для элемента «Группа» определен пользовательский тип данных с предопределенным перечнем зна- 287 чений, и XSD-процессор автоматически вводит первое из них в качестве значения данного элемента. Для элемента «Ном_ГС» определен встроенный тип данных integer и XSD-процессор определяет для этого типа значение по умолчанию «0». Оставим пока сгенерированные шаблоны без изменения, чтобы ввести в них реальные значения с помощью экранных форм, которые будут созданы позже. 7.3.3 СОЗДАНИЕ СИСТЕМЫ СЛОВАРЕЙ АС СРЕДСТВАМИ XSD Прежде чем приступить к разработке XML-схемы ПрО в целом, обратим внимание на одно важное обстоятельство, касающееся определения типов данных элементов XML-схем рассмотренных документов. Большинство из этих типов определено в виде пользовательских типов данных, представленных предопределенными перечнями значений заданного базового типа данных. Данный способ определения типов данных доступен для обработки XSD-процессором, который при вводе данных в XML-файл (в XML-редакторе или через экранную форму) предоставляет пользователю на выбор список этих значений, тем самым, с одной стороны, облегчает ввод данных, с другой стороны, предотвращает ввод ошибочных данных. Это практически равнозначно определению словарей и классификаторов, т.к. задает стандартизованный перечень значений элементов XML-схемы. Поэтому введенные пользовательские типы можно рассматривать в качестве словарей и классификаторов и установить следующие соответствия между ними и словарями и классификаторами, описанными в подразделе 2.4.4: – ГруппаType соответствует словарю К_Группа; – КафедраType соответствует словарю К_Кафедра; – Уч_степType соответствует словарю К_Уч_степень; – Уч_званType соответствует словарю К_Уч_звание; – Вид_занType соответствует словарю К_Вид_занятия; – СеместрType соответствует словарю К_Семестр; – Вид_сдType соответствует словарю К_Вид_сдачи; – ОценкаType соответствует словарю К_Оценка; 288 – ФИО_стдType соответствует словарю К_ФИО_стд; – ФИО_прпType соответствует словарю К_ФИО_прп; – ФИО_прпType соответствует словарю К_Подп_прп; – ПредметType соответствует словарю К_Предмет. Листинг XSD-файла словарей и классификаторов приведен ниже. Листинг 7.1. XSD-файл словарей и классификаторов 289 290 291 В описанных схемах большинство предопределенных перечней используются в разных документах. Например, перечень фамилий преподавателей факультета используется в документах: – «Список преподавателей кафедры» – для реквизитов «Заведующий» и «ФИО_прп»; – «План проведения занятий в группе» – для реквизита «ФИО_ прп»; – «Экзаменационная ведомость» – для реквизита «ФИО_прп». Ограничительные перечни формируются в виде пользовательских типов данных в отдельном файле. В описываемом примере в качестве такого файла определен файл со схемой Types.xsd. Для обеспечения доступа к этим описаниям с XML-схем в них должны быть определены ссылки на файл Types.xsd с помощью конструкции include. 7.3.4 СОЗДАНИЕ КОНЦЕПТУАЛЬНОЙ СХЕМЫ ПРО XML-схема ПрО в целом составляется на основе XML-схем рассмотренных документов и практически представляет собой объединение этих схем за небольшими исключениями. Этими исключениями являются объекты ГС и ПЛАН, а также вторичный ключ FK_pln, определенные в двух документах. В совокупной схеме эти объекты и вторичный ключ определяются по одному разу. XML-схема ПрО «Учебный процесс» приведена на Рис. 7.11, в которой объекты схемы представлены в свернутом виде, т.к. они тождественны описанным в XML-схемах документов. С другой стороны, описания связей между объектами (т.е. вторичных ключей) даны в развернутом виде, что позволяет получить общее представление о связях между объектами концептуальной схемы ПрО. 292 Рис. 7.11 – XML-схема ПрО «Учебный процесс» 293 Формирование совокупной схемы осуществляется в XML-редакторе путем переноса на новую схему уже созданных компонентов XML-схем документов. Хотя данное представление концептуальной схемы не привязано к конкретной СУБД, в данном случае мы имеем формализованное описание объектов ПрО с их взаимосвязями, и его можно будет использовать для автоматической генерации схемы БД для выбранной СУБД, а также других компонентов ИЛО АС, как это будет показано ниже. 7.3.5 ГЕНЕРИРОВАНИЕ ПОСТОЯННОГО ХРАНИЛИЩА ДАННЫХ Следующим шагом в создании нашего проекта является генерирование схемы БД для постоянного хранения данных. Имея XMLсхему концептуальной модели ПрО «Учебный процесс» можно выполнить генерирование схемы БД для выбранной реляционной СУБД (например, PostgreSQL) с помощью XML-редактора (например, редактора XMLSpy фирмы Altova). Спецификация XSD содержит в себе достаточно выразительных средств для определения общей схемы данных ПрО, содержащей домены, составные элементы, соответствующие таблицам, а также описания связей между ними. Этой информации вполне достаточно, чтобы сгенерировать скрипт на языке SQL, используемый для создания БД. Концептуальная схема ПрО представленная в виде XML-схемы и описанная в подразделе 7.3.4, разработана в виде агрегированной схемы, т.е. схемы, компоненты которой могут быть разработаны независимыми разработчиками, связи между которыми устанавливаются некоторым стандартным способом. В качестве такого стандартного способа принят способ соединения сущностей в реляционных схемах с помощью, так называемых вторичных ключей. Именно это обстоятельство позволяет преобразовать концептуальную схему ПрО, представленную в виде XML-схемы, в реляционную схему БД. При этом: – для всех элементов (реквизитов) XML-схемы определены типы данных; 294 – для каждого объекта XML-схемы (составного элемента) определен первичный ключ; – для явного указания связей между объектами XML-схемы определены вторичные ключи; – для некоторых элементов XML-схемы определены предопределенные перечни значений. Рис. 7.12 – Схема БД, сгенерированная по XML-схеме ПрО «Учебный процесс» 295 Для генерирования скрипта на языке SQL в открытом XML-редакторе (например, редакторе XMLSpy фирмы Altova) загружается преобразуемая XML-схема и при открытой вкладке Schema в строке меню выбирается команда Convert/Create DB Structure from XML Schema. Затем в окне Connect to a Data Source выбирается СУБД с помощью которой генерируется SQL-скрипт схемы БД. В следующем шаге набираются необходимые параметры для связывания с выбранной СУБД, и после нажатия кнопки Next осуществляется переход в окно Create DB Structure from XML Schema. В этом окне в блоке Source отображается структура генерируемой схемы БД. После изучения этой схемы нажимается кнопка Export и требуемый SQL-скрипт схемы БД будет сгенерирован автоматически. В качестве исходной XML-схемы выберем концептуальную схему ПрО «Учебный процесс», описанную в подразделе 7.3.2, и сгенерируем в описанном порядке схему БД для СУБД PostgreSQL, диаграмма которой приведена на Рис. 7.12. Приведенный пример показывает легкость, с которой мы можем сгенерировать схему БД от XSD-специфицированной модели. 7.3.6 СОЗДАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА Поскольку информация XML-документа не указывает на то, как она будет отображена на экране, то дополнительно определяется таблица стилей, с помощью которой документу придается желаемый внешний вид. Современные редакторы таблиц стилей обеспечивают не только визуализацию XML-данных, но и содержат средства реализации активных элементов ввода и редактирования данных. Эти возможности компенсируют отсутствие реализаций xForms-процессоров и превращают редакторы таблиц стилей в полноценные инструменты создания пользовательского интерфейса. В качестве примера такого редактора можно привести редактор StyleVision фирмы Altova, с помощью которого можно создавать электронные формы как для просмотра, так и для ввода и редакти- 296 рования данных. Данный редактор таблиц стилей использует модель данных XSD, определенную наряду с шаблоном XML-документа (см. подраздел 7.3.2), что позволяет разработчикам создавать электронные формы, обеспечивающие просмотр и редактирование последующих экземпляров XML-документов. Внешний вид редактора таблиц стилей StyleVision приведен на Рис. 7.13 и Рис. 7.14. Скриншот левой панели редактора таблицы стилей, содержащей окна Design Overview и Schema Tree приведен на Рис. 7.13. В окне Design Overview содержатся наименования файлов XML-схемы (Vdm_grp.xsd) и рабочего XMLдокумента (Vdm_grp.xml), на основе которых строятся элементы дизайна пользовательского интерфейса. Структура XML-схемы представлена деревом в окне Schema Tree. Вкладка Design рабочего окна расположена на правой панели редактора и предназначена для размещения элементов дизайна электронной формы (см. Рис. 7.14) путем «перетаскивания» элементов схемы из окна Schema Tree (см. Рис. 7.13). На Рис. 7.14 приведен дизайн пользовательского интерфейса для ввода данных документа «Экзаменационная ведомость». Как уже было отмечено, элементы дизайна формиРис. 7.13 – Левая панель руются на правой панели путем «передактора таблицы ретаскивания» соответствующих элестилей ментов XML-схемы с левой панели. Например, элемент «Название пред- 297 мета» образован от элемента «Ведомость/План/Предмет» XMLсхемы, размещенной в окне Schema Tree. При формировании элементов дизайна имеется возможность их настройки. Например, при формировании элемента «Название предмета» имеется возможность связывания с перечнем предопределенных значений, заданных при проектировании XML-схемы Vdm_ grp.xsd. Элемент ввода типа «выпадающий список» после нажатия на треугольник справа выводит перечень допустимых значений для данного элемента. Пользователю остается только выбрать необходимое значение. Рис. 7.14 – Окно проектирования дизайна интерфейса пользователя на правой панели редактора таблицы стилей Возможно также создание динамических таблиц на основе данных XML-документа. На Рис. 7.14 приведен дизайн динамической таблицы, отображающей список студентов группы с оценками по результатам тестирования, извлеченными из таблицы «Оценка» БД «Учебный процесс». Редактор StyleVision предоставляет широкий спектр возможностей по форматированию дизайна пользовательского интерфейса. Например: 298 – можно ввести статические надписи, поясняющие смысл элементов дизайна; – для введенных надписей и элементов содержания формы можно определять шрифты, их стили и размеры; – для элементов ввода типа «выпадающий список» можно установить связь с перечнем данных соответствующего словаря; – можно организовать динамическую таблицу, структура которой соответствует структуре объекта XML-схемы с опцией Unbounded, определяющей повторяющиеся записи и т.д. Рис. 7.15 – Интерфейс пользователя для ввода данных документа «Экзаменационная ведомость» Таким образом, с помощью редактора StyleVision можно создать полноценную экранную форму для ввода данных документа, согласованную с XML-схемой и рабочим XML-файлом, созданным на ос- 299 нове этой схемы, отображающую как статические, так и динамические элементы, реагирующие на действия пользователя. На Рис. 7.15 приведена экранная форма для ввода данных, созданная на основе описанного дизайна интерфейса пользователя. С помощью этой формы введенные данные можно записать в XMLфайл, определенный в качестве рабочего. Для этого перейдите на вкладку Authentic и после ввода данных в электронную форму нажмите кнопку Save Authentic XML data. При этом в XML-файл, определенный в качестве рабочего экземпляра документа, вводятся данные с формы. На листинге 7.3 приведен текст экземпляра XML-документа, сформированного путем заполнения файла Vdm_grp.xml данными, введенными в поля ввода экранной формы. Листинг 7.3. Данные документа «Экзаменационная ведомость», введенные с экранной формы <Ведомость xsi:noNamespaceSchemaLocation="Vdm_grp.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ГС> <Ном_ГС>1 <Группа>ИВТВМбд-11 <Семестр>первый <План> <Ном_плн>1 <Предмет>Базы данных <Вид_занятия>лекция <Вид_сдачи>экзамен <Часы>32 <ФИО_прп>Петров И.П. <Ном_ГС>1 <Ведом> <Ном_вдм>1 <Дата>2017-06-07 <Ном_плн>1 <Оценка> 300 <Ном_оц>1 <ФИО_стд>Антипов В.Р. <Оценка>хорошо <Подп_прп>Петров <Ном_вдм>1 <Оценка> <Ном_оц>2 <ФИО_стд>Афонин Г.М. <Оценка>удовлетворительно <Подп_прп>Петров <Ном_вдм>1 <Оценка> <Ном_оц>3 <ФИО_стд>Горлов Б.Н. <Оценка>не удовлетворительно <Подп_прп>Петров <Ном_вдм>1 <Оценка> <Ном_оц>4 <ФИО_стд>Ивлев Ф.Н. <Оценка>не аттестован <Подп_прп>Петров <Ном_вдм>1 <Оценка> <Ном_оц>5 <ФИО_стд>Ильин М.К. <Оценка>хорошо <Подп_прп>Петров <Ном_вдм>1 <Оценка> <Ном_оц>6 <ФИО_стд>Филин В.П. <Оценка>отлично <Подп_прп>Петров <Ном_вдм>1 301 Обратите внимание на то, что шаблон данного XML-документа был уже сформирован на этапе генерирования XML-файла по XMLсхеме (см. листинг 7.2). Далее создадим экранную форму для вывода данных, не содержащую элементов ввода данных, а только отображающую данные соответствующего документа. Этот тип экранной формы предназначен для другой категории пользователей системы и обеспечивает выдачу справочных данных (см. Рис. 7.16). Рис. 7.16 – Интерфейс пользователя для отображения данных документа «Экзаменационная ведомость» По описанной схеме создаются интерфейсы пользователя для отображения и ввода данных остальных документов ПрО: «Список студентов группы», «Список преподавателей кафедры», «План проведения занятий в группе». 302 7.3.7 ОТОБРАЖЕНИЕ «XML-СХЕМА  СХЕМА БД» Можно считать, что на этапе формирования пользовательского интерфейса завершается разработка ИЛО АС, содержащего в своем составе: – XML-схемы документов, описывающие структуры документов и словарь ПрО; – концептуальную модель в виде XML-схемы, описывающую структуру ПрО в целом; – шаблоны XML-файлов для всех XML-схем документов, представляющие собой обменные форматы документов ПрО; – схему БД ПрО; – интерфейсы пользователя, представляющие информационный язык системы и обеспечивающие ввод и вывод данных документов. Но обратим внимание на то обстоятельство, что в разработанном ИЛО сосуществуют два формата данных: – бинарные данные в БД используются для хранения и выполнения информационно-расчетных задач; – текстовые данные в формате XML используются для выполнения коммуникационных задач. Наличие двух форматов представления данных предполагает необходимость их взаимно обратного преобразования. Например, при обмене данными между системами передаваемые данные, извлеченные из базы, необходимо представить в платформенно-независимом формате, так как АС, принимающая эти данные, может быть реализована на совершенно иной платформе. Поэтому для передачи по каналу связи данные извлекаются из базы и преобразуются в XML-формат. На приемной стороне эти данные должны быть занесены в БД АС, т.е. при этом осуществляется обратное преобразование XML-документа в бинарный формат СУБД адресата. Преобразование бинарных данных в текстовый формат при их передаче осуществляется по той причине, что текстовые данные могут быть правильно интерпретированы на любой аппаратнопрограммной платформе. Поэтому, несмотря на неизбежные временные и ресурсные издержки, выполнение этих преобразований 303 представляет собой ценный фактор при реализации распределенных систем. Описанные преобразователи можно рассматривать как средства ведения данных и отнести в состав ИЛО, так как преобразования форматов данных осуществляются по единой схеме и могут быть легко формализованы. С точки зрения формализации задачу преобразования форматов данных можно рассматривать: – с одной стороны, – как отображение XML-документа, введенного с экранной формы, или поступающего по каналу связи, на структуру фрагмента БД; – с другой стороны, – как выборку данных фрагмента структуры БД для отображения на XML-документ для вывода на экранную форму или для передачи по каналу связи. Для выполнения этих взаимно обратных преобразований можно прибегнуть к программированию на одном из языков высокого уровня, но можно воспользоваться возможностями средств визуального проектирования. Одним из таких средств является редактор MapForce фирмы Altova, обеспечивающий использование XSDспецифицированных моделей для формализации процессов отображения XML-документов на структуру фрагмента БД, и обратно. Рис. 7.17 – Диаграмма отображения XML-документа на БД 304 Суть формализации процедур отображения XML-схем на схемы БД и обратно заключается в том, что редактор MapForce обеспечивает их представление в виде древовидных структур и соединение их элементов. В качестве примера рассмотрим процедуру преобразования «XML БД», используемого при вводе XML-данных в БД. ПС MapForce рассматривает данную задачу как отображение данных эквивалентных структур текстового формата на бинарный. На Рис. 7.17 приведена диаграмма отображения данных XML-документа на соответствующий фрагмент схемы БД. Решение задачи отображения данных с одной структуры на другую заключается в том, чтобы по данным входного XML-документа и его XML-схемы, а также данным о структуре фрагмента схемы БД, сгенерировать SQL-скрипты для записи данных, содержащихся в XML-документе, в БД. Рис. 7.18 – Скрипт отображения XML-документа на схему БД Визуальный редактор MapForce по данной диаграмме генерирует код программного модуля, осуществляющего запись данных 305 входного XML-документа в БД. На Рис. 7.18 приведены скрипты, сгенерированные этим программным модулем, которые после выполнения в соответствующей СУБД приводят к вставке данных XML-документа в поля таблиц БД. Результат выполнения скриптов можно просмотреть, открыв соответствующую базу данных. В нашем случае – это база данных, созданная с помощью СУБД Access (см. Рис. 7.19). Рис. 7.19 – Отображение XML-документа на схему БД С помощью MapForce можно выполнить отображение данных и в обратном направлении, т. е. из структуры фрагмента БД в XML-документ. Диаграмма такого отображения приведена на Рис. 7.20. Как видно из приведенного рисунка, структура данного отображения сложнее логики отображения, рассмотренного выше. Объясняется это тем, что в данном случае требуется: – во-первых, ввести критерий отбора записей БД; – во-вторых, сравнить введенный критерий с данными из базы; – в-третьих, для выявления связанных записей сравнить значения первичных ключей родительских таблиц с вторичными ключами дочерних таблиц. С этой целью в диаграмму отображения «Схема БД  XMLсхема» вводятся: – элемент ввода Gruppa для ввода наименования группы; 306 – первый логический элемент equal, обеспечивающий сравнение введенного значения Gruppa со значениями ключевого поля Группа таблицы Группа; – элемент Filter с именем Группа, обеспечивающий считывание записей из БД по результатам сравнения в первом элементе equal; – второй логический элемент equal, обеспечивающий сравнение введенного значения Gruppa со значениями вторичного ключа Группа, для выявления записей из таблицы Студент, связанных с текущей записью таблицы Группа; – элемент logical-and, обеспечивающий выявление связанных записей таблиц Группа и Студент. Связанные записи определяются при одновременном совпадении входных значений в обоих элементах equal; – элемент Filter с именем Студент, обеспечивающий считывание записей из таблицы Студент по совпадению выходных значений обоих элементов equal. Рис. 7.20 – Диаграмма отображения Схемы БД на XML-схему По существу с помощью перечисленных элементов формируются элементы программного модуля, сгенерированного визуальным редактором MapForce по диаграмме отображения Схемы БД на 307 XML-схему. По входным критериям выборки этот программный модуль генерирует запросы SELECT * FROM Группа WHERE «Группа = ИВТВМбд-11» SELECT * FROM Студент WHERE «Группа = ИВТВМбд-11» В результате выполнения этих запросов MapForce формирует два набора данных и заносит эти данные в шаблон XML-файла документа «Список студентов группы». При этом по данным из таблиц «Группа» и «Студент» БД (см. Рис. 7.19) формируется XMLфайл Spis_std.xml, текст которого приведен в листинге 7.4. Листинг 7.4. Данные документа «Список студентов группы», извлеченные из БД и преобразованные в XML-формат <Список_стд_грп xsi:noNamespaceSchemaLocation="Spis_std.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Группа> <Группа>ИВТВМбд-11 <Кол_стд>6 <Средн_балл>3.95 <Студент> <Ном_стд>1 <ФИО_стд>Антипов В.Р. <Год_рождения>2001-08-14 <Адрес>ул. Мира 1, кв. 18 <Прох_балл>3.40 <Группа>ИВТВМбд-11 <Студент> <Ном_стд>2 <ФИО_стд>Афонин Г.М. <Год_рождения>2001-06-15 <Адрес>ул. 1 Мая 23, кв. 54 <Прох_балл>4.20 <Группа>ИВТВМбд-11 308 <Студент> <Ном_стд>3 <ФИО_стд>Горлов Б.Н. <Год_рождения>2001-04-11 <Адрес>ул. Марата 31, кв. 112 <Прох_балл>4.10 <Группа>ИВТВМбд-11 <Студент> <Ном_стд>4 <ФИО_стд>Ивлев Ф.Н. <Год_рождения>2001-12-21 <Адрес>ул. Жданова 17, кв. 128 <Прох_балл>4.30 <Группа>ИВТВМбд-11 <Студент> <Ном_стд>5 <ФИО_стд>Ильин М.К. <Год_рождения>2001-02-28 <Адрес>ул. Венская 9, кв. 19 <Прох_балл>3.90 <Группа>ИВТВМбд-11 <Студент> <Ном_стд>6 <ФИО_стд>Филин В.П. <Год_рождения>2001-10-02 <Адрес>ул. Минина 25, кв. 13 <Прох_балл>3.80 <Группа>ИВТВМбд-11 Создадим описанные диаграммы отображения для остальных XML-документов ПрО, и на этом процесс разработки ИЛО распределенной АС завершается. Как видно из приведенных диаграмм (см. Рис. 7.18 и Рис. 7.20) при визуальной разработке программных модулей отображения «Схема БД  XML-схема» также используется XML-схема, а также созданная на ее основе схема БД. Это говорит о том, что в модели 309 данных типа XML-схема содержится информация, достаточная для автоматизированного создания всех остальных компонентов ИЛО АС. КОНТРОЛЬНЫЕ ВОПРОСЫ 1. В чем заключается разница разработки УСД традиционными средствами и средствами языка XSD. 2. Какой способ моделирования XML-схем целесообразно применить при разработке УСД: композиционный или агрегированный. 3. Опишите способ создания системы словарей АС средствами XML-схемы. 4. Опишите порядок создания концептуальной схемы ПрО на основе УСД. Объясните, при каком способе моделирования УСД (композиционном или агрегированном) проще и удобнее создавать концептуальные схемы ПрО. 5. Опишите процесс создания постоянного хранилища данных на основе XML-схемы. 6. Опишите или покажите процесс отображения XML-документа в базу данных. 7. Опишите или покажите процесс отображения БД в XML-документ. 8. Опишите или покажите процесс создания пользовательского интерфейса на основе XML-схемы документа ПрО. 310 1. Основы методологий проектирования автоматизированных систем обработки информации и управления / Учебное пособие / Составитель: А.В. Иващенко, Самара: СНЦ РАН, 2009. – 40 с. 2. Емельянова Н.З., Партыка Т..Л., Попов И.И. Основы построения автоматизированных информационных систем: Учебное пособие. – М.: ФОРУМ-ИНФРА-М, 2005. – 415 с. 3. ГОСТ 34.003-90. Автоматизированные системы. Термины и определения. 4. ГОСТ 19.101-77. Единая система программной документации. Виды программ и программных документов. 5. Пономарева К.В., Кузьмин Л.Г. Информационное обеспечение АСУ. Учебник. – 2-е изд., перераб. и доп. – М.: Высш. шк., 1991. – 222 с. 6. Смирнова Г.Н., Проектирование экономических информационных систем : Учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; под ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2002. – 512 с. 7. Белоновская И.Л. Лингвистическое обеспечение АБИС : учеб.метод. пособие / И. Л. Белоновская. – Минск : БГУКИ, 2017. – 78 с. 8. Структура экономической информации – https://studopedia.info/ 4-98120.html. 311 9. Унифицированная система документации – https://studopedia.ru/ 3_68331_unifitsirovannaya-sistema-dokumentatsii.html. 10. ГОСТ 6.10.1 – 88. УСД. Основные положения. М.: Изд-во стандартов, 1994. 11. Информационное обеспечение (ИО) АИС – https://studopedia.ru/ 14_119508_tema--informatsionnoe-obespechenie-io-ais.html 12. Нормативно-справочная информация (НСИ) – http://ausferr.ru/ infosystems/nsi.html. 13. Информационные системы / Петров В.Н. – СПб.: Питер, 2003. 688 с. 14. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2006. – 352 с. 15. Энциклопедия SQL. 3-е изд. / Дж. Грофф, П. Вайнберг. – СПб.: Питер, 2004. – 896 с. 16. Цикритзис Д., Лоховски Ф. Модели данных / Пер. с англ. – М.: Финансы и статистика, 1985. – 344 с. 17. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : Пер. с англ. – М.: Издательский дом "Вильямс", 2003. – 1440 с. 18. Гультяев А.К., Машин В.А. Проектирование и дизайн пользовательского интерфейса. – СПб.: КОРОНА принт, 2000. – 352 с. 19. Черняк Л. Следующая волна технологической революции: от баз данных к распределению данных // Открытые системы. – 2003. – № 3. 20. Williams R. et al. (1982). R*: An Overview of the Architecture. In Improving Database Usability and Responsiveness. (Scheuermann P., ed.). New York: Academic Press. 21. Моррисон М. HTML и XML. Быстро и эффективно. – СПб.: Питер, 2005. 303 с. 312 22. Хокинс Скотт. Администрирование Web-сервера Apache и руководство по электронной коммерции.: М.: Издательский дом "Вильямс", 2001. – 336 с. 23. Брюс У. Перри. Java сервлеты и JSP. Сборник рецептов. Москва.: КУДИЦ-Образ, 2006. – 768 с. 24. Холзнер С. XML. Энциклопедия, 2-е изд. – СПб.: Питер, 2004. – 1001 с. 25. Гарольд Э., Минс С. XML. Справочник. – Пер. с англ. – СПб.: Символ-Плюс, 2002. – 576 с. 26. Рей Э. Изучаем XML. – Пер. с англ. – СПб.: Символ-Плюс, 2001. – 408 с. 27. Приготовьтесь: XForms. Дата: Сентябрь 2002 года. Джоэл Ривара (Joel Rivera), Лен Тейнг (Len Taing). – http://iso.ru/ru/presscenter/journal/1892.phtml. 28. Бекет Г. Java SOAP для профессионалов. Москва.: Лори, 2004. – 458 с. 29. Курс Java. JAXB. – https://javarush.ru/quests/lectures/questcollections.level03.lecture07. 30. XML как способ логического представления информации – http://kunegin.com/ref2/xml/go33.htm. 31. Айверсон У. Популярные Web-сервисы: практика использования / Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2005. – 240 с. 32. Маклаков. С.В. CASE-средства разработки информационных систем. – М.: Диалог – МИФИ, 2004. – 256 с. 33. XMLSpy 2013 Enterprise Edition. – URL: http://manual.altova. com/XMLSpy/spyenterprise. 34. EditiX XML Editor 2010 Build/ – URL: http://zara.net.ua/45988editix-xml-editor-2010-build-020110.html. 35. Бесплатный XML редактор Serna Free 4.3 для Windows – http://www.skan.ru/software/n6531_besplatnyi_xml_redaktor_serna_free. html. 313 36. Stylevision® 2013 Enterprise Edition – http://manual.altova.com/ Stylevision/stylevisionenterprise/. 37. Stylus Studio 2008 XML Enterprise Suite v9.2.1147c – http:// newshot.ru/soft/1157001104-stylusstudio-2008-xml-enterprise-suitev9.2.1147c.html. 38. Orbeon Forms 4 – http://orbeon.com. 39. better FORM – http://betterform.de/en/index.html. 40. XSLTForms – http://www.agencexml.com/xsltforms. 41. Mozilla XForm Project – http://www.sitepoint.com/mozillaxforms-project-threatenedby-cutbacks/. 42. Токмаков Г.П. Основы XML-технологий: учебное пособие. – Ульяновск : УлГТУ, 2017. – 228 с. 314 Автоматизированные информационные системы – применяются для управления сложными системами и используют компьютерные технологии, обеспечивающие автоматизацию таких функций и процедур, как: – подготовка и регистрация информации; – передача информации к месту обработки; – собственно обработка информации; – хранение и поиск информации. Внемашинное ИО – устанавливает состав и структуру информации, пригодной для хранения в памяти АС, и включает в свой состав унифицированную систему документации (включая нормативно-справочные документы), отражающую показатели, необходимые для решения управленческих задач, классификаторы и коды, используемые для описания объектов предметной области (ПрО), формуляры для представления информации. Внемашинное ИО АС – формируется на основе документации с выявленной системой экономических показателей и включает в свой состав: – унифицированную систему документации (УСД), содержащую сведения о состоянии технологического оборудования, управляемого объекта и среды в виде системы показателей; – систему классификации и кодирования информации (СККИ); – нормативно-справочная информация (НСИ). 315 Внутримашинное ИО – это система специальным образом организованных данных, подлежащих автоматизированной обработке, накоплению, хранению, поиску, передаче в виде, удобном для восприятия техническими средствами. Источником для формирования внутримашинного ИО служат данные внемашинного ИО. Внутримашинное ИО АС включает в себя информационную базу на машинных носителях и систему программ ее организации, накопления, ввода и доступа к данным (см. Рис. 1.3). Источником формирования внутримашинного информационного обеспечения служит внемашинная информационная база. Гибкость АС – означает возможность настройки системы под информационные технологии пользователя, переносимость из одной среды эксплуатации в другую, независимость от конкретных компонент и приложений, участвующих в системе. Глобальная внешняя схема – определяет представление распределенной БД с точки зрения пользователей конкретных АС, и описывает ту часть распределенной БД, которая используется пользователями каждой АС распределенной системы. Глобальная концептуальная схема – представляет логическое описание всей совокупности баз данных, входящих распределенную систему, в виде единой базы данных. Этот уровень является аналогом концептуального уровню архитектуры ANSI-SPARC локальной СУБД. Его назначение заключается в: – определении распределенных сущностей и связей всех БД, входящих в распределенную систему, на единой основе; – поддержке ограничений ссылочной целостности для распределенных данных; – обеспечении защиты информации от несанкционированного доступа при распределенной обработке. Документ представляет собой определенным образом организованную совокупность взаимосвязанных по смыслу показателей. Документ является основной и наиболее удобной формой пред- 316 ставления информации с точки зрения управления, так как наряду с полнотой и наглядностью представления информации, он содержит реквизиты, придающие ему юридический статус. Интегрированная база данных – совокупность данных, созданная с помощью универсального программных средств загрузки, поиска и обработки данных, представляющих собой системы управления базами данных. Информационная база – часть внутримашинного ИО, представляющая собой специальным образом организованную совокупность данных, хранимой в памяти машины. Информационное обеспечение АС – представляет собой важнейший элемент современных АС и предназначено для отражения информации, характеризующей состояние управляемого объекта, и являющейся основой для принятия управленческих решений. Информационно-лингвистическое обеспечение АС – представляет собой интеграцию компонентов ИО и ЛО подсистем и сопрягаемых объектов и включает в свой состав: – унифицированную систему документов; – систему классификации и кодирования информации; – нормативно-справочную информацию; – информационную базу; – средства формализации языка, включающих в свой состав систему словарей понятий, правила формализации информации и методы выделения и представления информационных сообщений; – информационные языки АС, включающие группы языков описания данных и манипулирования данными, проектирования и программирования компонентов АС, управления функционированием АС и ее обслуживанием. Информационные языки – обеспечивают удобство работы персонала с АС, а также для работы с информацией, хранящейся в базе данных и сокращения количества ошибок, возникающих в процессе работы. Информационные языки строятся на основе применения диалоговых средств взаимодействия персонала с АС. Эти средства служат для передачи содержания документов, сообщений, за- 317 просов, результатов решения информационно-расчетных задач, а также используются для формализации информации при обмене сообщениями между ДЛ и АС. Информационные языки содержат в своем составе следующие группы языков: – описания данных; – манипулирования данными; – проектирования и программирования; – управления функционированием АС (и ее обслуживанием). Классификатор – нормативный документ, устанавливающий систематизированный перечень групп наименований и кодов объектов классификации, принятый на соответствующем уровне стандартизации. Классификационная группировка – множество или подмножество, объединяющее часть объектов по одному или нескольким признакам классификации. Классификация – это разделение множества объектов на подмножества по их сходству или различию в соответствии с принятыми методами. Классификация фиксирует закономерные связи между классами объектов. Под объектом понимается любой предмет, процесс или явление. Код – это условное отображение информационного понятия. Он характеризует одно понятие или одну позицию множества с помощью символов (букв или цифр). Кодирование – это процесс присвоения условных обозначений объектам и классификационным группам по соответствующей системе кодирования. Кодирование реализует перевод информации, выраженной одной системой знаков, в другую систему, то есть перевод записи на естественном языке в запись с помощью кодов. Кодировочный словарь – нормативный документ, устанавливающий систематизированный перечень групп наименований и кодов объектов, принятый на соответствующем уровне стандартизации. 318 Лингвистическое обеспечение АС – это система терминов, используемых при разработке и функционировании АС, методы формализации естественного языка, а также информационные языки, направленные на поддержку взаимодействия персонала ОУ со средствами вычислительной техники. Логическая структура документа – представляется в виде трех логических частей: – первая часть – это содержимое документа, обычно состоящее из текста, таблиц и графики, представляет собой его смысловое содержание; – вторая часть документа представляется данными о его структуре, т.е. данными о заголовках, абзацах и т.д., обеспечивающих упорядоченную «сборку» содержания документа как целостного образования; – третья часть содержит данные о форматировании документа, т.е. данные о шрифтах, отступах, параметрах страниц и т.д., обеспечивающие визуальное представление содержания документа. Локальные БД – используются при работе одного или нескольких пользователей в пределах одной локальной сети. Масштабируемость АС – это возможность построения (в том числе поэтапного) системы из готовых или стандартных компонентов. Это позволяет легко менять масштабы решаемых системой задач, изменять и поэтапно наращивать систему. Машинная технология обработки информации – применяет широкий спектр технических средств и, прежде всего, компьютерной техники и средства связи для создания вычислительных систем и сетей различных конфигураций. При этом обеспечивается не только накопление, хранение, автоматизированная переработка информации, но и максимальное приближение терминальных устройств к рабочим местам специалистов в области информационных технологий и ЛПР. 319 Методы и способы выделения, представления содержания информационных сообщений – включают описания методов формирования наборов данных, составляющих содержание информационного сообщения, и способов его представления ДЛ. Набор прикладных программных интерфейсов JAXB – обеспечивает быстрый и удобный способ создания двухстороннего преобразования между XML-документами и классами языка Java. Имея XML-схемы обрабатываемых XML-документов из состава ИЛО, компилятор JAXB создает набор классов Java, необходимый для анализа XML-документов, основанных на данных схемах. Назначение ЛО АС – заключается в предоставлении удобных и эффективных средств взаимодействия пользователей с АС. Норма − это вид нормативно-справочной информации, представляющий первичный количественный норматив, полученный внутри предприятия путем технического расчета, или установленный извне в качестве исходного. Нормы представляют собой входную информацию низкого уровня и выражаются в единицах физических величин. Норматив – это вид нормативно-справочной информации, определяющая количественную и качественную характеристику управления, и показывающая, каковы нормальные его параметры при данном уровне развития производства. Применительно к предприятию нормативы должны выражать зависимость отдельных показателей его деятельности от технических и экономических условий. Нормативно-справочная информация – единые для отрасли или ведомства нормативные документы, составляющие основу формирования поведения взаимодействующих субъектов всех видов деятельности. Общий шлюзовой интерфейс CGI (Common Gateway Interface)  интерфейс для создания модулей расширения Webсерверов, пришедший из ОС Unix. Web-приложения в этом случае представляют собой сценарий или обычный исполняемый файл 320 (*.exe), получающий от сервера необходимую информацию из переменных окружения. Основная цель ИО АС – заключается в повышении качества решения задач управления на основе обеспечения достоверности и своевременности данных, необходимых для принятия управленческих решений. Основное назначение ИО АС – обеспечивать такую организацию и представление информации, которые отвечали бы требованиям пользователей, а также условиям для реализации автоматизированных технологий обработки и приема-передачи данных. Открытость АС – означает, что система базируется на мировых информационных стандартах. Показатель – это сообщение об объекте, представляющее собой минимальную составную единицу информации, сохраняющую информативность и включающую один реквизит-основание и группу взаимосвязанных с ним и между собой по смыслу реквизитов-признаков. Правила формализации информации – включают методы сжатия и развертывания текстов, представленных на естественном языке, а также способы кодирования информации. Признак или основа классификации – свойство (реквизит) объекта классификации, с помощью которого устанавливается его сходство или различие с другими объектами классификации. Распределенная БД – это набор логически связанных совокупностей разделяемых данных (и их описаний), физически распределенных в глобальной компьютерной сети. Распределенная СУБД – это программный комплекс, предназначенный для управления распределенными базами данных и обеспечивающий доступ пользователей к распределенной информации, как будто она содержится в единой базе данных. 321 Реквизит – это логически неделимый элемент документа, описывающий определенное свойство или группу свойств отображаемого объекта. Дальнейшее членение реквизита на более мелкие составляющие – символы (символов в свою очередь на биты) разрывает его привязку к определенному свойству объекта (процесса) и нарушает информативность. Репликация – это процесс создания и поддержки многочисленных копий данных, сформированных на одном из узлов распределенной системы. Данный механизм позволяет организовать доступ пользователям к актуальным данным независимо от того, на каком они узле произведены, причем тогда, когда они в этом нуждаются. Использование репликации позволяет достичь высокой производительности работы системы и надежности хранения данных, что обеспечивается наличием их резервной копии, т.к. данные, произведенные на одном узле, многократно дублируются на других узлах глобальной сети. Ручная технология обработки информации – использует бумажные носители информации, ориентирована на использование простых технических средств (счетов, калькуляторов) и полностью регламентируется действующими инструкциями по решению управленческих задач в рамках сложившихся методологии и законодательства. Серверные страницы Java JSP (Java Server Pages) – создаются на серверном языке сценариев, подобном Java, позволяющем формирование Web-сайтов, содержащих сочетание статического кода HTML с динамически формируемым кодом HTML. Результатом отделения динамической части страниц от статического HTML является возможность изменения дизайна страницы, не затрагивая динамическое содержание. Сервлеты – представляют собой программы, выполняемые на Web-сервере с поддержкой платформы Java и формирующие Webстраницы, аналогично программам CGI. Сервлеты вызываются удаленно из Web-браузера с помощью HTTP-протокола через Web- 322 сервер для динамического генерирования контента и предоставляют способ для развертывания приложения в Web-среде. Система классификации – совокупность правил распределения объектов множества на подмножества. Обеспечивает группировку объектов и выделение определенных классов, характеризующихся рядом общих свойств. Система классификации и кодирования информации, представляет собой комплекс: – методов и правил классификации и кодирования информации, подлежащей автоматизированной обработке; – взаимоувязанных классификаторов и словарей; – средств ведения классификаторов и словарей. Система кодирования – это совокупность правил обозначения объектов и группировок с использованием кодов. Код – это условное обозначение объектов или группировок в виде знака или группы знаков в соответствии с принятой системой. Код базируется на определенном алфавите (некоторое множество знаков). Число знаков этого множества называется основанием кода. Различают следующие типы алфавитов: цифровой, буквенный и смешанный. Система словарей терминов – содержит термины и определения понятий автоматизируемой ПрО для обязательного применения при разработке конструкторской документации на разрабатываемую систему, а также при составлении информационных сообщений. Система управления базами данных – совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями. Состав ИО АС – включает в себя внемашинное и внутримашинное ИО. Состав ЛО АС – представляется совокупностью средств и правил для формализации естественного языка, используемых при общении пользователей с КСА, и включает в себя: 323 – систему словарей терминов и понятий, используемых в процессе разработки и функционирования автоматизированных систем управления; – правила формализации естественного языка, включая методы обработки текстов, представленных на естественном языке; – информационные языки, используемые для взаимодействия пользователей с КСА, включая: а) языковые средства автоматизации проектирования АС; б) информационные языки для описания структурных единиц ИБ АС (документов, показателей, реквизитов и т.п.); в) языки управления и манипулирования данными ИБ АС; г) диалоговые языки для взаимодействия с КСА АС. Спецификация SOAP – средство представления информации для передачи/приема по каналу связи. Спецификация SOAP, разработанная в рамках XML-платформы, формализует процедуру упаковки (распаковки) XML-данных в SOAP-конверты (из SOAPконвертов). Справочник − это вид нормативно-справочной информации, представляющий собой перечень данных, однозначно характеризующих состояние объекта на определенный период времени и позволяющих выделить этот объект из множества других. Средства формализации естественного языка – представляют собой определенный перечень выполняемых действий разработчика при создании экранных форм, обеспечивающих диалоговое взаимодействие ДЛ с программными средствами АС. Отображение соответствующих реквизитов экранных форм осуществляется в терминах профессионального языка и наименований из системы словарей и классификаторов СККИ. К средствам формализации естественного языка относятся: – система словарей терминов; – правила формализации информации; – методы и способы выделения, представления содержания информационных сообщений. 324 Схема размещения – содержит информацию о расположении данных по конкретным системам, необходимую для доступа к ним с любого узла компьютерной сети. Схема фрагментации – содержит информацию о логическом распределении данных по разделам концептуальной схемы. Требования к ИО АС – обусловливаются их назначением и определяются как совокупность следующих возможностей: – представления полной, достоверной и своевременной информации для реализации всех расчетов и процессов принятия управленческих решений в ФС и ФП с минимумом затрат на ее сбор, хранение, поиск, обработку и передачу; – обеспечения взаимной увязки задач ФС и ФП на основе однозначного и формализованного описания их входов и выходов на уровне показателей документов; – эффективной организации хранения и поиска данных, позволяющей АС формировать данные в рабочие массивы под решаемые задачи и функционировать в режиме информационносправочного обслуживания. Требования к ЛО АС: ЛО АС должно быть достаточным для: – общения различных категорий пользователей с КСА с целью их совместной работы; – реализации средств информационного языка АС, обеспечивающих общение пользователей с КСА, в удобной для них форме; – выполнения преобразования пользовательского представления в машинное, а машинного – в пользовательское, при вводе и выводе обрабатываемой в АС информации. Унифицированная система документации – рационально организованный комплекс взаимосвязанных документов, циркулирующих в системе управления, созданный по единым правилам и требованиям. Унификация документов обеспечивает приведение множества показателей в определенную систему с целью установления терминологического единства, однозначности описания, взаимосвязи между показателями. 325 Язык xForms – средство разработки экранных форм, разработанное для замены морально устаревших классических Web-форм. По сравнению с Web-формами, формы, созданные по новой технологии, не только обеспечивает ввод информации, но и имеет довольно широкие возможности для её обработки, например: – обработки правильности отправляемых данных (проверки XML-документа на корректность); – взаимодействия с протоколом SOAP (описание см. ниже); – в клиентском приложении осуществляется минимальная обработка данных (нет необходимости перезагружать страницу); – совмещения серверных технологий и преимуществ клиентской обработки. Язык XML – средство описания содержания документов, в котором разметка документов определена на логическом уровне. В отличие от языка HTML он обеспечивает содержательную (структурную) разметку документа, выделяя с помощью тегов отдельные элементы, составляющие содержание документа, а не элементы его форматирования. Язык XSD – средство описания структур и типов данных, с помощью которого формализуется набор правил, с соблюдением которых составляется XML-документ конкретного назначения. Языки описания данных и манипулирования данными АС – реализованы в языке SQL используемой СУБД, разработанной сторонней организацией. Языки проектирования и программирования – включают языки программирования высокого уровня и его трансляторы (компиляторы), разработанные сторонними организациями. Языки управления функционированием АС (Информационные языки) – осуществляют взаимодействие ДЛ и обслуживающего персонала с АС в диалоговой форме, реализуются в виде пользовательских интерфейсов. 326 Языки формализации текстовых документов – специализированные языки разметки, такие как HTML, XML и т.д., созданные на основе стандартного обобщенного языка разметки SGML (Standard Generalized Markup Language). Языковые средства СУБД – обеспечивают интерфейс пользователей и прикладных приложений разных категорий с базой данных. Примером языкового средства, широко применяемого для определения данных и манипулирования ими в базах, являются различные модификации языка структурированных запросов SQL. 327 Глобальная внешняя схема ...................................... 201 Глобальная концептуальная схема.......................... 203 Глобальный системный каталог ................................... 203 Графический интерфейс пользователя GUI ................. 168 А Архитектура «файл-сервер» ....................... 127 Архитектура распределенной системы ..................... 201 В Внемашинное ИО ............. 25, 54 Внешний уровень трехуровневой архитектуры ........ 115 Внутренний уровень трехуровневой архитектуры................ 116 Внутримашинная информационная база ........... 106 Внутримашинное информационное обеспечение .................. 26 Внутримашинное ИО ........... 102 Д Диалоговый режим взаимодействия..................... 148 Документ ................................. 37 Дочерняя таблица ................. 105 Е Емкость системы классификации........................ 70 Г З Генератор схемы ................... 261 Гибкость системы ................. 198 Гибкость системы классификации ........................ 70 Запросный режим взаимодействия..................... 147 Значение показателя ............... 35 Значение реквизита ................ 32 328 М И Идентификатор реквизита...... 32 Иерархический метод классификации ........................ 70 Интерактивное взаимодействие ..................... 147 Информационное обеспечение ............................. 23 Информационно-лингвистическое обеспечение ............. 29 Информационные языки ....... 159 Масштабируемость системы ................................. 198 Математическое обеспечение системы ..................... 22 Машинная обработки информации ............................ 20 Международные классификаторы ...................... 68 Методы и способы выделения, представления содержания информационных сообщений ............................. 159 Модель, реляционная ........... 301 К Качественные показатели ...... 35 Классификатор ........................ 67 Классификационная группировка ............................. 69 Классификационные коды ...... 77 Классификация ........................ 69 Код или шифр ......................... 74 Кодирование............................ 74 Количественные показатели ............................... 35 Компилятор схемы ............... 261 Концептуальный уровень трехуровневой архитектуры .......................... 115 Н Набор прикладных программных интерфейсов JAXB...................................... 260 Название показателя .............. 35 Норма....................................... 80 Норматив ................................. 80 Нормативно-справочная информация ............................. 79 О Область определения реквизита ................................. 32 Общегосударственные классификаторы ...................... 68 Общий шлюзовой интерфейс CGI ...................... 230 Обязательная платформа ...... 261 Основное назначение СУБД ..................................... 111 Открытость системы ............ 198 Л Лингвистическое обеспечение АС .............. 27, 156 Логическая независимость данных ................................... 121 Локальная схема отображения .......................... 203 Локальные классификаторы .. 68 329 Отношение ............................ 104 Отображение, XML схемы на БД ...................................... 313 Отображение, БД на XML схему ....................... 315 Отраслевые классификаторы ...................... 68 Реляционная модель ............. 104 Репликация ............................ 210 Родительская таблица .......... 105 С Связи между таблицами....... 105 Серверные страницы Java JSP.................................. 237 Сервлеты Java ....................... 233 Серийный метод кодирования ............................ 77 Система R .............................. 204 Система классификации ......... 69 Система кодирования ............. 75 Система словарей и классификаторов информации ............................ 66 Система словарей терминов ................................ 159 Системный каталог .............. 119 Словарь .................................... 67 Содержательная часть документа ................................ 38 Состав ИО АС ......................... 25 Состав лингвистического обеспечения АС .................... 158 Состав ЛО АС ......................... 28 Спецификация SOAP ........... 253 Справочник ............................. 80 Средства формализации естественного языка ............. 158 Степень наполненности системы классификации ........ 70 Столбец таблицы .................. 105 Строка таблицы .................... 104 П Пакетный режим взаимодействия ..................... 147 Параллельные системы кодирования............................. 77 Первичным ключ таблицы ... 105 Показатель ............................... 33 Порядковый метод кодирования ............................ 76 Последовательные системы кодирования............................. 77 Правила формализации информации ........................... 159 Признак квалификации ........... 69 Принципы реализации СУБД...................................... 111 Программное обеспечение системы .................................... 22 Прозрачность СУБД.............. 199 Протокол HTTP ..................... 221 Р Распределенная база данных ................................... 199 Распределенная СУБД .......... 199 Регистрационные методы кодирования............................. 76 Реквизит ................................... 31 330 Структура информации документа ................................ 38 СУБД...................................... 111 Сущность, кодовая.................. 94 Схема владения данными системы репликации ............. 211 Схема размещения ................ 203 Схема фрагментации ............ 203 Ц Цель кодирования .................. 74 Я Язык DDL .............................. 164 Язык DML ............................. 165 Язык xForms .......................... 252 Язык XML ............................. 250 Язык XSD .............................. 251 Язык XSL .............................. 251 Язык запросов SQL .............. 164 Языки описания данных и манипулирования данными АС .......................... 159 Языки программирования ... 166 Языки проектирования и программирования ................ 160 Языки управления функционированием АС....... 160 Языки формализации текстовых документов ............................ 249 Т Таблица .................................. 104 Техническое обеспечение системы .................................... 22 У Унифицированная система документации .......................... 56 Унифицированная форма документов .............................. 61 Ф Фасетная классификация ........ 72 Физическая независимость данных ................................... 121 Форма документа .................... 38 Формуляр-образец документа ................................ 62 Функциональная зависимость реквизитов ......... 38 S SOAP-процессор ................... 259 SQL-процессор ..................... 260 X XForms-процессор ................ 259 XSD-процессор ..................... 258 XSL-процессор ..................... 259 Х Характеристики кода .............. 75 331