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

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

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

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

Добавлен: 19.10.2024

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

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

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

лезно в системах с обновлением в реальном

масштабе

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

можно

поместить некоторую у п р а в л я ю щ у ю

информацию, на­

пример ключ, у п р а в л я ю щ и й доступом

запроса

к

этому

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

тарной записи позволяет д е р ж а т ь ф а й л ы с

различными

типами записей, используемые на разных

уровнях до­

ступа. Рассмотрение этого

вопроса

будет

продолжено

в гл. 4.

 

 

 

Помимо ключа доступа

к записи

в качестве управ­

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

мог бы быть подсчет числа

обращений к элементарной

записи

из

З У П Д , возникших

в процессе поиска по спис­

ку, и числа

осуществленных

этой записью условий по­

иска. М о ж н о

рассмотреть и более подробную

статистику,

например

статистику использования

индивидуальных

ключей

и

классификаторов

и д а ж е

д а н н ы е

обратной

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

изводить

обновление Элементарной

записи.

 

Д л и н ы

записей следует принять

переменными.

Во-

первых, к а ж д а я запись, вообще говоря, не содержит

все

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

чае, если

переменными могут

быть

и

длины значений,

длину к а ж д о г о ключа и классификатора . Иногда

ж е л а ­

тельно присвоить к а ж д о м у имени ключа

и имени класси­

фикатора

числовой

код. Д а л е е

этот

код д о л ж е н

быть

введен в

оглавление.

Тогда программа,

сканируя

оглав­

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

63


 

П о м и мо определения длин соответствующих

полей

 

Ключей и Классификаторов, оглавление д о л ж н о указы ­

 

вать

начало поля

данных. П о л я

ключей и

классифика ­

 

торов вместе с оглавлением составляют

у п р а в л я ю щ у ю

 

структуру ассоциативной информации. Номер

д о с т у п а

 

для

Элементарной

записи

и

ее

 

у п р а в л я ю щ а я

информа ­

 

ция являются составной частью подсистемы

обслужива ­

 

ния файла в информационно-поисковой системе. В фор­

 

мате, приведенном на рис. 3-5,

 

все

остальные

данные

 

записи, т. е. данные, не имеющие отношения ни к иерар­

 

хической или ассоциативной структуре файла, ни к ин­

 

формации д л я его обслуживания,

обозначены

блоком

 

data

(данные) .

Д а н н ы е

внутри

блока

представляются

 

в любом ж е л а е м о м формате . В

случае

переменного

фор­

 

мата

блок этот,

например,

может

иметь

 

собственное

 

оглавление. Более

того, к а ж д ы й

файл мог

бы иметь соб­

 

ственный формат .

Б л а г о д а р я

структуре

управляющей

 

информации этот формат будет правильно интерпрети­

 

рован системой выборки и размещения

записей, Ключей

 

и Классификаторов . Таким образом, при программиро­

 

вании приложений информационно-поисковая

система

 

представляется

в

виде оперативной

системы. Д л я

обра­

 

щения к записям согласно ключам, классификаторам и

 

другим

функциональным

спецификациям

 

программист

 

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

 

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

 

переносятся соответствующие записи. Запись переносит­

 

ся вместе с указателем на начало блока «Данные», ко­

 

торые теперь могут быть произвольно обработаны в пре­

 

делах

блока.

Модификацию

 

структуры

управляющей

 

информации, подобную включению или исключению

 

ключей или классификаторов, можно производить

толь­

 

ко в терминах команд языка

запроса

информационно-

 

поисковой системы. Некоторые из

утверждений

этого

 

языка

(в особенности формирующие

обновление)

могут

I

играть

привилегированную

роль . В гл.

4 более подробно

I

рассмотрены функции и структуры

языка

запроса

при­

 

менительно к структуре файла .

Р а с ш и р я я

систему,

 

можно

написать специальные

программы,

 

реализущие

 

описанный выше

перечень запросов

к

информационно-

 

поисковой системе, и, кроме того, выполняющие

автома­

 

тическую перекомпоновку раздела данных соответствен­

 

но заранее фиксированному д л я

заданного

файла

 

формату.

 

 

 

 

 

 

 

 

 

 

 

 

64


О б ъ е д и н яя изложенные понятия, можно представить оперативную систему файлов как систему с произволь­

ным

числом типов файлов, имеющих

иерархическую

и (или) ассоциативную структуру информации,

в кото­

рой

прикладные программисты, т. е.

те, кто

связан

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

си. Эта обработка может

быть выполнена

с помощью

межзаписных и внутризаписных процедур.

 

ГЛАВА

ЧЕТВЕРТАЯ

 

Я З ЫК

ЗАПРОСА

 

Язык запроса о т р а ж а е т все функциональные

требования

і?"системе, сформулированные в гл. 3. Он является свое­ го рода посредником между пользователем и системой 1 автоматического поиска и хранения информации. Други ­ ми словами, язык запроса должен позволить пользова­ телю реализовать все проектные возможности, з а л о ж е н ­ ные в структуре файла .

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

ляется ли она

иерархической, ассоциативной и т. д. В то

ж е время вопросы организации

файла — использован­

ные методы

разбиения, структура

списка — пользовате­

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

мые с внутренней организацией

ф а й л а в системе. Язык ;

запроса служит д л я связи м е ж д у

человеком и автомати-

5-88

65


зированнной системой файлов . При этом в совместном пользовании человека и машины находятся только струк­ тура информации и язык запроса. Однако следует отме­

тить, что

к а ж д ы й

из них подвержен

возможным иска­

жениям .

Если при

программировании

информационно-

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

Язык

запроса искажен или, вернее, обеднен

тогда, когда

в нем

ие реализованы все возможности,

заложенные

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

гвистической структуры

языка запроса,

при решении

которого

существуют

две

крайние точки

зрения. Язык

получает

гибкость и

выразительную силу

посредством

обогащенного словаря и контекстно чувствительного син­

таксиса. Оба эти

фактора

приводят к

неоднозначности

в языке, что легко видно на примере естественных

язы­

ков.

Д р у г а я крайность

находит свое

в ы р а ж е н и е

в

чис­

то

механических

языках,

подобных

машинному

 

коду

или

языку большинства

трансляторов, — я з ы к а х

с

кон­

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

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

так

и форм правильных конструкций.

Т а к а я

ситуация

для

непрограммиста может

оказаться

менее

желатель ­

ной,

чем чисто механический

язык типа программного.

Следует отметить, что трудность заключается здесь не

столько

в словаре управляющих команд

(или

глаголов,

как их

иногда

называют)

и

других вспомогательных

управляющих

слов, сколько

в

синтаксисе

языка . М ы по­

нимаем

под

этим

правила,

у п р а в л я ю щ и е

пользованием

комбинациями терминов, или структуру фразы . Включе­

ние

в

компилятор словарных

понятий

типа do,

find,

get,-

if и

т. д. в действительности

является

не более

свой­

ством естественного языка, чем использование эквива­

лентных им

численных кодов, потому

что

утверждение,

с о д е р ж а щ е е

make

вместо do,

в случае,

если

оба понятия

не эквивалентны

на языке

процессора,

останется непо-

66


мятным. Или, например, ф р а з а

do later станет означать

отложенное действие только

в том случае, если слово

later, связанное с программой, является одним из поня­ тий словаря и существует синтаксическое правило, пре­ образующее комбинацию do laier в соответствующую машинную программу. Если в реализованном алгоритме

запроса

не

блокируется

употребление

недозволенных

слов, то

непонимание может углубиться. Другим, более

сильным

аргументом против использования

естественно­

го языка являются затраты на его написание.

Таким образом,

мы предполагаем, что в течение бли­

ж а й ш и х

пяти

лет

язык

запроса

для

информационных

систем

окажется близким по структуре к компилируемым

языкам

с возможным внесением

некоторых

синтаксиче­

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

можное согласование

м е ж д у процессами

естественного

мышления в обращении

с ф а й л а м и и внутренней машин­

ной организацией этих

ж е файлов . Это

приводит нас

к пониманию языка запроса как буфера между челове­ ком и машиной.

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

приводят

к дорогим и

бесполезным поискам.

Полезный

и широко

распространенный на

сегодня подход состоит

в построении диалога человек-машина. В этом

процессе

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

передает

машине

относительно

малыми

порциями точную и хорошо формализованную

информа­

цию; система

в свою очередь отвечает статистикой пред­

стоящего поиска, таблицами или указаниями,

которые

должны помочь пользователю в дальнейшей

формули­

ровке запроса .

 

 

 

Содержательный и хорошо разработанный язык за­ проса должен быть ориентирован как на программистов, работающих в области приложений, так и на пользовате­ лей-непрограммистов. Являясь процедурно- и проблемноориентированным, он должен наиболее полно использо­ вать возможности системы при внутризаписной и м е ж з а ­ писной обработке. Его можно написать к а к подъязык компилятора, и тогда функции управления файлом, пере­ численные в гл. 3, становятся доступными програм-

67