Файл: Левковиц, Д. Структуры информационных массивов оперативных систем.pdf

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 19.10.2024

Просмотров: 72

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

Системы

первого типа, несмотря

на свою ограниченность,

имеют много приложений. К а ж д ы й ключ

в таких

систе­

мах определяет единственную запись. Примером

может

служить

банковская система,

в которой

к а ж д ы й

счет

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

ставному

признаку. Если в

описанном

выше

примере

к записи

счета добавить

ключи, соответствущие

д а т а м

и-именам, то разбиения, генерируемые запросами,

могут

содержать

класс

записей.

 

 

 

 

 

 

 

Таким образом, можно создать разбиение для всех

записей, с о д е р ж а щ и х данное число или данное

имя,

так

чтобы, например,

организовать прямой доступ

к

к а ж д о ­

му счету,

заприходованному,

например,

19

мая

1968

г.

Т а к а я система со

многими ключами могла

бы

работать

по типу системы

с запросом по одному ключу. Н о

как

только разрешены

запросы типа «Выбрать запись

Д ж о н а

Смита, внесшего

в к л а д 9

апреля 1968 г.», возникает

не­

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

только от структуры

файла, в то

время как

разбиение

по

мультисписку в

большинстве

систем

генерируется

в

процессе

программного поиска

согласно

логическому

в ы р а ж е н и ю

запроса,

с о д е р ж а щ е м у

составной

ключ. Р а ­

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

Другое функциональное требование к организации файла в информационно-поисковых системах заклгочает-

44


ся в необходимости неключевой классификации записей. В гл. 1 описан двухуровневый поисковый процесс. На первом уровне через декодирующий справочник опреде­

ляются

списки

или разбиения записей, после

чего из

З У П Д

в процессор передаются физические записи

спи­

ска. Составное

ключевое

в ы р а ж е н и е

запроса,

являясь

входом

в декодирующий

справочник,

определяет

доступ

к элементам списка. Д а л ь н е й ш а я классификация

запи­

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

совпадение подцепочки

и т.

д. Эти

ж е

операции

можно

з а л о ж и т ь в в ы р а ж е н и е

д л я

запроса,

но

тогда выполнять­

ся они д о л ж н ы не внутри записи, а

процедурой справоч­

ного декодирования . С точки зрения

пользователя

систе­

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

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

измещение ниже среднего. Т а к а я формулировка

предпо­

лагает, что существует программа, вычисляющая

среднее

значение и что среди подполя классификаторов

(или да­

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

45


O T I I O C I I T Ö L K

ции этого требования в системах, работающих в реаль­ ном масштабе времени, рассмотрены в гл. 4.

Решение об отборе той или иной записи по результату арифметического сравнения ее классификатора зави­ сит только от данных рассматриваемой записи и ие зави­ сит от значений или процедур, выполняемых над другими записями файла в целом или списком его записей, счи­ танных с З У П Д . Такие системные процедуры называют ­ ся внутризаписной обработкой (intrarecord processing). Результат сравнения функционально преобразованных значений обычно зависит от результатов предшествую­

щей обработки других записей файла

или его

разбиения,

а т а к ж е от результатов

внутризаписной обработки. Соот­

ветствующие

системные

процедуры

называются

межза ­

писной обработкой (interrecord processing).

 

 

Вопросы

функционального

преобразования

данных

тесно связаны с вопросами

формирования

отчетности,

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

мым к

оперативной системе. Генерируемая отчетность

д о л ж н а

обладать гибким и высококачественным форма ­

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

Одна из главных з а д а ч

при работе

с ф а й л а м и

в

опе­

 

ративных системах заключается в выборе

способа

обнов-

_ ^ л е н и я ѵ П р и необходимости

обновления

в

реальном

мас­

ш т а б е времени сложность программ, связанных с эксплу­

атацией

файлов, возрастает. В этом случае в целях об­

л е г ч е н и я

внесения

исправлений списковые

структуры

д о л ж н ы

содержать

некоторые у п р а в л я ю щ и е

элементы.

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

46


а

не к

обновлению. Новые записи можно сгруппировать

в

пакет

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

щение новых записей в оперативной памяти или на внеш­ нем носителе не зависит от организации файла, посколь­

ку

его обновление планируется на время,

когда система

не

работает

в оперативном режиме . Однако оперативное

обновление

имеет и ряд преимуществ, в

некоторых слу­

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

новления в

реальном

м а с ш т а б е времени. В

этом

случае,

так

ж е как

в случае

оперативного

формирования ф а й л а ,

для

редактирования

входов, формализации

 

обновления

и обнаружения текущих

ошибок

можно

использовать

специальные программы

редактирования .

 

 

 

 

Таким образом, первая з а д а ч а проектировщика си­

стемы состоит в определении необходимости

требования

обновления

файлов

в

реальном

масштабе

-времени..

Если такой

необходимости" нет, он

располагает

большей

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

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

ко ухудшают состояние организации . Н а п р и м е р ,

в неко­

торых системах

д л я новых записей возрастающей

длины,

которые нельзя

разместить по соответствующему

адресу

полностью, формируют - в - конце записи остаточную часть

(trailer), которая

р а з м е щ а е т с я

по некоторому

п р о и з в о л ь 7

но отдаленному,_ад£есу.

Б о л е е

того, остаточные

записи

могут создавать

новые

фрагменты, т а к что д л я

восста­

новления полной

записи

может

потребоваться

несколько

обращений с произвольным доступом. Д р у г о й подход со­ стоит в резервировании п а м я т и • для -- разм«щения . лолной

записи. П р и этом некоторый прилегающий

объем памяти

остается незаполненным. В обоих случаях

как

д л я сбор­

ки записи по фрагментам, так и д л я сборки и

возвраще ­

ния системе участков свободной памяти появляется не­ обходимость в процедуре обслуживания файла . Приве -

47


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

тода обновления. В некоторых системах

упорядочивание

пространства

можно приурочить

к з а р а н е е

запланиро ­

ванным

интервалам времени, выполняя его над файлом

в целом

или

его значительной частью. В

других случаях

требования к

скорости обновления настолько динамич­

ны, что

упорядочивание пространства проектируется как

фоновая

з а д а ч а и выполняется

в условиях

разрешения

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

3-2. СТРУКТУРА ИНФОРМАЦИИ

ИОРГАНИЗАЦИЯ ФАЙЛА

Дл я четкого понимания дальнейшего изложения в а ж н о определить термины: структура информации, организа­

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

(если

это в о з м о ж н о ) , — воспользоваться ее

преимущест­

вами

при организации файла . В свою очередь

организация

файла определяется как выбор формата для записи дан­ ных, управляющих списков, закрепление и распределение типов файлов в устройствах внешней памяти.. Д р у г и м и словами, структура информации з а д а е т с я извне системо-

аналитиком, проектирующим процедуры сбора

и передачи

I информации* Решение проблемы организации

файла це-

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

48