Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

книги из ГПНТБ / Левковиц, Д. Структуры информационных массивов оперативных систем

.pdf

Скачиваний:

Добавлен:

21.10.2023

Размер:

8.9 Mб

Скачать

☆

<<< < Предыдущая 1 2 3 4 5 67 / 217 8 9 10 11 12 13 14 15 16 17 18 19 20 21 > Следующая >>>

К л а с с и ф н к а т о р а / З н а ч е п пе					*. В		случае ключа для каж
дой пары	Им я Ключа/Значение						генерируется			список или
происходит разбиение				файла .
Вообще говоря, существуют два класса									методов		орга
низации	списковой структуры. К первому								п р и н а д л е ж а т
ото	Счет 4					0600		ИнВоп # 18
	накладная/^							Страсх/о.]
	Поручитель/^							ядpec связи ОЮО/у.
or,	Накладнаяы							ядpec связи ОЮО/у.
or,	Накладнаяы
	Счет/аг		'
«2	Накладная		#2			0250		Поручитель #3
«2	Накладная		#2					Счет/ф
	Счет/ф
	Суасх/у
fil	Поручитель #/
	Счет//Зг							Страсх #/
	Поручитель		#2					Накладиая/уц
	Поручитель		#2					Инбоп/у6
	Счет//33							Инбоп/у6
	Счет//33
	\Ддрес продолжения 0251							Страсх ъ 2
	\Ддрес продолжения 0251							йакладиая/у5
	Страсх # /							йакладиая/у5
	Страсх # /							Страсх # J
	Накладная/у2							Страсх # J
	Страсх	# 2						Накладная/а3
	Страсх	# 2						Ядрес связи 0600
	Накладная/а.							Ядрес связи 0600
	Накладная/а.
	Индоп/уя
Рис. 3-4. Пример				файла		с иерархическим			управле
					нием.
методы	последовательного					мультисписка			• , ко второ
м у — м е т о д ы инвертированного							списка. В первом				случае
для образования		списка			разбиения ф а й л а					необходим

адрес связи, расположенный внутри записи. Следова тельно, в поле ключа дополнительно к Имени Клю-

*В некоторых системах Имя опускается или подразумевается и хранятся только Значения. {Прим. пер.)

**Иногда называемого узловым списком. (Прим. пер.)

Номер элемента Управляющая информация элемента

•Ключ доступа

•Статистика использования Оглавление

'Начальный адрес данных

• Число ключей или список длин ключей

• Список длин по составу данных

Ключи

•Имя ключа/зиачеііис/адрсс связи

•Имя ключа/значение/адрес связи

Классификаторы

•Имя классификатора/значение

Данные

Запись

Данные

Рис...3-5.. Ассоциативное управление и размещение данных для запи-

,си обобщенного формата.

ча/Значению записывается Адрес связи,			у к а з ы в а ю щ и й
следующую запись в		З У П Д , с о д е р ж а щ у ю	то	ж е	И м я
Ключа/Значение	(или	З н а ч е н и е ) . З а п и с и	этого	списка,
вообще говоря,	физически не расположены последова
тельно, а связаны между собой программным				образом
через адреса связи. Классификаторы не образуют					спис

ка и, следовательно, рассматриваются только как инди

видуальные входы ( И м я	Классификатора/Значение)
внутри к а ж д о й записи. С	программной точки зрения

поиск по списку может быть выполнен только для клю


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

выражение запроса имеет нормальную дизъюнктивную форму (сумма произведений) или преобразовано к та кому виду предыдущей обработкой. Участок логики за

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

дизъюнкции запроса содержится хотя бы один меотрйцаемый ключ.

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

ко по-другому. Адреса связи изъяты из индивидуальных


записей и помещены в виде компактных,							последователь
ных списков			в другой	области З У П Д .			Таким		образом,
адреса		связи	не фигурируют внутри			записи			явно,		ка к
это	показано		на рис. 3-4, но тем не менее в системе								фай
лов они существуют и выполняют					те ж е функции.
	Следует отметить,			что в случае	запроса,			выраженно
го в терминах пар Имя/Значение,					система,			р а б о т а ю щ а я
со	списком,		с о д е р ж а щ и м Значения,			менее		эффективна,
чем	система		со списком пар И м я Ключа/Значение .								Сни
жение		эффективности		происходит из-за необходимости
вести		более	длинный	поиск по списку. Однако						система
со списком Значений				более гибка,	не требует				от	пользо

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

Разработчики . В той ж е	системе,	просматривая	список
Смитов и классифицируя	к а ж д у ю	запись после	ее пере

носа в оперативную память по имени ключа, можно по лучить списки Автор/Смит и Главный Р а з р а б о т ч и к / Смит. С другой стороны, система со списком пар могла

бы найти всех Смитов только по запросу				Автор/Смит
или Главный	Разработчик/Смит, что возможно				только
в том случае,	когда	пользователь	знает,	что	Автор и
Главный Р а з р а б о т ч и к		есть имена	именно	тех	ключей,

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


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

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

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

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

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


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

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

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

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

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

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

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

полей

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

вать

начало поля

данных. П о л я

ключей и

классифика

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

у п р а в л я ю щ у ю

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

д о с т у п а

для

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

записи

ее

у п р а в л я ю щ а я

информа

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

обслужива

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

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

все

остальные

данные

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

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

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

обозначены

блоком

data

(данные) .

Д а н н ы е

внутри

блока

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

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

случае

переменного

фор

мата

блок этот,

например,

может

иметь

собственное

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

того, к а ж д ы й

файл мог

бы иметь соб

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

Б л а г о д а р я

структуре

управляющей

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

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

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

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

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

система

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

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

системы. Д л я

обра

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

другим

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

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

программист

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

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

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

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

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

делах

блока.

Модификацию

структуры

управляющей

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

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

толь

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

запроса

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

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

утверждений

этого

языка

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

обновление)

могут

играть

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

роль . В гл.

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

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

языка

запроса

при

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

Р а с ш и р я я

систему,

можно

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

программы,

реализущие

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

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

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

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

автома

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

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

заданного

файла

формату.

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

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

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

си. Эта обработка может	быть выполнена	с помощью
межзаписных и внутризаписных процедур.
ГЛАВА	ЧЕТВЕРТАЯ
Я З ЫК	ЗАПРОСА
Язык запроса о т р а ж а е т все функциональные		требования

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

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

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

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

мые с внутренней организацией	ф а й л а в системе. Язык ;
запроса служит д л я связи м е ж д у	человеком и автомати-
5-88	65

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

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

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

Язык	запроса искажен или, вернее, обеднен	тогда, когда
в нем	ие реализованы все возможности,	заложенные

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

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

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


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

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

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

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

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

столько	в словаре управляющих команд					(или	глаголов,
как их	иногда		называют)	и	других вспомогательных
управляющих		слов, сколько		в	синтаксисе	языка . М ы по
нимаем	под	этим	правила,	у п р а в л я ю щ и е		пользованием

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

ние	в	компилятор словарных	понятий	типа do,	find,
get,-	if и	т. д. в действительности	является	не более	свой

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

лентных им	численных кодов, потому			что	утверждение,
с о д е р ж а щ е е	make	вместо do,	в случае,	если	оба понятия
не эквивалентны		на языке	процессора,	останется непо-

мятным. Или, например, ф р а з а	do later станет означать
отложенное действие только	в том случае, если слово

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


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

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

можное согласование	м е ж д у процессами	естественного
мышления в обращении	с ф а й л а м и и внутренней машин
ной организацией этих	ж е файлов . Это	приводит нас

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

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


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

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

мисту-прикладпику, работающему с компилятором . Язык запроса может функционировать к а к средство об


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

1)поиск, основанный на использовании ключей и классификаторов;

2)обновление записей — присоединение и исключе ние записей, присоединение, исключение и модификации

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

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

Язык запроса, описываемый в этой главе, представ ляет собой некоторый прототип или модель, поскольку

главной его	целью	является выяснение	требований
к структурам	файла	и их иллюстрация . К а к	прототип

описываемый далее язык запроса удовлетворяет всем че тырем минимальным требованиям, перечисленным выше. Читатель может его расширить или адаптировать для

своих приложений,	поскольку к а ж д а я система	может
содержать некоторые	специальные требования,	которые

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

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

HEADER (ID, Priority, File Access Key)

COMMAND (Retrieve, Update, Report, etc.)

OUTPUT D E V I C E (Typewriter, Display, Printer)

DATA CONDITIONS

K l (key name R value)

K2 (key name R value)

CI (qualifier name R value)

C2 (qualifier name R value)

PROCESSING (A function of K l , K2, .. . C l , C2 .. Л

• Intra — Record Logic Functions

•Inter — Record Processing OUTPUT FORMAT

•Titles

•Formatting Print Statements

Рис. 4-1. Прототип схемы запроса.

Ф о р м а т запроса,	представленный	на рис. 4-1, состоит
из шести основных	разделов, первые	три из которых со

держат основную у п р а в л я ю щ у ю информацию и здесь

нами не рассматриваются; остальные			три существенно
связаны	со структурой	и обслуживанием файла		и обра
щением с ним.
Первый раздел представляет собой			Заголовок	(HEA
DER),	с о д е р ж а щ и й	идентификатор	пользователя, а
в случае	мультитерминальной системы		с дальней	связью
т а к ж е идентификатор		терминального устройства. Заголо

вок, кроме того, может содержать и другую информацию,


такую как, например, приоритет		запроса	и ключ доступа
к файлу, используемый дл я подтверждения				подлинности
системных	файлов или записей,	участвующих в запросе.
Р а з д е л	Действие ( C O M M A N D ) запроса			обычно пред
ставляет	собой относительно	простое	мнемоническое
утверждение или функцию, которое д о л ж н о				быть выпол

нено в ответ на запрос. Следует отметить, что понятие

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

<<< < Предыдущая 1 2 3 4 5 67 / 217 8 9 10 11 12 13 14 15 16 17 18 19 20 21 > Следующая >>>

Соседние файлы в папке книги из ГПНТБ