Проблема обмена информацией и коммуникативные (обменные) форматы

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

• идентификации данных;

• локализации описания данных.

Проблема идентификации заключается в следующем:

• необходимость правильного распознавания и «привязывания»
данных, размещенных на внешнем носителе (файл) к тем областям памяти, которые выделены для размещения этих данных
(им соответствуют какие-то имена переменных в обрабатываю­
щей программе);

• обнаружение ошибок при считывании данных (например, не­
соответствие типа или длины данного ожидаемому и т. п.);

• пропуск ошибочных данных (записей, строк и пр.) или вывод
их в специальные файлы ошибок.

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

• определять начало и окончание элементарного данного внутри
записи;

• определять начало и окончание записи файла.

Здесь необходимо отдельно рассмотреть записи постоянной и переменной (неопределенной) длины. Выделяют следующие методы записи.

1. Ввод, управляемый редактированием (GET EDIT в ЯП ПЛ/1).
В этом случае данные на носителе (в файле) должны иметь строго ту
длину, которая задана в их описании (в прикладной программе).

Это ограничение, очевидно, имеет смысл только для файлов с записями постоянной длины. При этом символьные данные (поля) должны быть дополнены до стандарта хвостовыми пробелами (trailing blanks), а числовые — ведущими нулями (leading zeros). Для записей фиксированной длины, состоящих из элементов постоянной или ограниченной длины в буфере считывания выделяется область, рав­ная общей длине записи. Всякое нарушение длины и типа приводит к ошибке считывания и выбраковке записи.

2. Ввод, управляемый списком (GET LIST в ЯП ПЛ/1). Этот метод называется также «с разделителями». При этом записи должны
быть отделены друг от друга разделителями (ограничителями) записей
(record terminators, delimiters), а элементы данных внутри записи —
разделителями данных (data terminators). Этот подход действителен
как для записей постоянной, так и фиксированной длины.

3. Ввод, управляемый данными (GET DATA в ЯП ПЛ/1). Здесь
каждое данное в файле снабжается идентификатором, или меткой,
которая совпадает с именем элемента данных в программе. Это способствует «точному приземлению» указанной информации в отведенную память. Также подходит для всех типов записей.

Пусть структура (запись) в некоторой программе имеет следую­щее описание

TOWN CHAR(20), PEOPLE NUM(8), YEAR_F NUM(4);

*наименование города

*население

*год основания

Тогда при первом методе записи информация в файле должна выглядеть так:

МОСКВА

(после «Москвы» — 13 «пробелов»);

при втором:

#МОСКВА# 8000000#1147#$

(если разделитель данных — #, а записей — $);

третий метод допускает следующую форму записи:

TOWN-'МОСКВА', YEAR_F='1147', PEOPLE-'8000000'$ (по-

рядок данных здесь может быть произвольным, а разделитель запи­сей все же нужен — $, а также ограничитель данного — ').

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

Кроме перечисленных возможны также и другие методы, на­пример, первый байт каждой записи может содержать длину всей записи, а первый байт каждого элементарного данного — его длину.

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

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

Для установления независимости программ от данных в некото­рых системах и ситуациях описание данных размещают совместно с файлом данных. По такому принципу организован весьма распро­страненный формат файла данных (dbf-формат), происходящий от систем dBase — Clipper — FoxBASE — FoxPro, а затем принятый и ря­дом других систем. В этом случае в начале файла создается заголовок, содержащий описание полей записи (имя, тип, длина данного, код информации и пр.). В этом случае описание данных файла (внешних) в программе не требуется (см. [6]).

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

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

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

Дата добавления: 2015-07-20