Добавил:

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

Вуз:

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

Предмет:

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

Файл:

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

.pdf

Скачиваний:

Добавлен:

21.10.2023

Размер:

8.9 Mб

Скачать

☆

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

Третий раздел запроса содержит спецификацию Вы ходных устройств (OUTPUT D E V I C E ) . В некоторых си стемах речь может идти о выборе выходного устройства.

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

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


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

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

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

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


выделяя		основные	функциональные			компоненты		струк
туры	файла .
Четвертый раздел				запроса	под названием		Условия
(DATA		CONDITIONS)		содержит у п р а в л я ю щ и е			аргумен
ты или		параметры .		Например,	при	действии		поиска
д о л ж н ы быть определены ключи, классификаторы								и ус
ловия	поиска. При		обновлении		у п р а в л я ю щ и м и		парамет

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

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

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


моническими символами, например KU К2,		Cl, С2		(см.
рис. 4-1), с тем	чтобы далее использовать		мнемонику
естественного языка для спецификации имени			ключа или
классификатора,	его значения или серии значений, а			так
ж е требуемого соотношения между именем		и	значением.


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

или классификатора в его системной форме представле

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

висимости от типа оператора отношения), и, наконец,

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

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

лежит поле данных, определенное			в р а з д е л е обработка,
а новые	данные, которые	д о л ж н ы	быть добавлены или
внесены	в поле, у к а з а н ы	и помечены в разделе Условие.

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

С помощью метки проектировщик системы может ре шать вопрос о том, следует ли пользователю различать

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

Пятый раздел запроса содержит спецификацию про цесса поисковой Обработки (PROCESSING), являющей ся функцией условий. Р а з л и ч а ю т два типа обработки: внутризаписиые логические функции и м е ж з а п и с н а я об работка .

В	первом	случае записи извлекаются в оператив
ную	память	из З У П Д согласно поисковому описку,

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

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

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

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

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


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

типа программ, с о д е р ж а щ и х встроенные функции языка запроса типа For (цикл в приложении к списку) D'elete key name, add key Name, Sort name, Tally data condition,

Sum	name и т.	д. и высказывания	о локализации	типа
a = ß ,	которое	определено, если	ß — функциональное
в ы р а ж е н и е типа sum name или			A l A N D А2, а	а —
принятый пользователем символ			дл я хранения	мет
ки ß.

Шестой раздел запроса содержит Выходной формат
(Output F O R M A T ) . При правильном	формировании от
четности заголовки и метки д о л ж н ы	либо в явной форме

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

ных ранее		меченых форм. Кроме того, результаты по
иска д о л ж н ы быть размещены и упорядочены.
	Из опыта большинства начинающих программистов
известно,		что стандартные высказывания	ввода-вывода
на	языках	программирования Ф О Р Т Р А Н ,	А Л Г О Л .и да
же	К О Б О Л требуют большего навыка и		представляют

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

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

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


TALLY, A D D KEY и т. д., пишутся					системными		програм
мистами	дл я	предоставления		пользователю			удобных
форматных пакетов			(наборов) .		Н а п р и м е р ,		функция
W H O L E RECORD1 NAME может формировать и печатать
(или высвечивать) любую запись в					файле	NAME, ранее
определенную выражением типа NAME-ß. Стандартный
формат	записи	м о ж е т	быть настроен на			формат любой
записи системы. Это			означает,	что	файл	NAME должен

иметь соответствующее описание формата, которое может быть интерпретировано функцией W H O L E RECORD1 . Дальнейшее расширение состояло бы в написании серии

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

кретных пользователей. Исполнительная или вызываю


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

2)	з а д а т ь	алфавитно - цифровые	метки;
3)	занести	основные макетные	линии д л я графиков

исхем при работе с ЭЛТ ;

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

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

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

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

Д о сих пор при использовании ЭВ М в работе инфор мационных систем внимание фокусировалось в основном


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

с информационными управляющими системами, систе

мами	с у п р а в л я ю щ и м			воздействием,				системами		учета
и т. д.
На рис. 4-2—4-6 представлены варианты запроса раз
личного уровня			сложности, имеющие					общий	прототип.
Н а	рис. 4-2 пользователь идентифицируется в									заго
ловке	ка к >NL 252. Д а л е е				пользователь приписывает за
просу	приоритет,		равный		единице,		и	представляет		ключ
доступа к		ф а й л у	12743.	Ключ		этот	м о ж е т быть исполь
зован	как	код идентификации				ф а й л а		или ка к	код	раз

решения работ. В начале работы с мультифайловой си

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

решены вопросы з а щ и т ы и доступа к файлу, достигается уровень управления файлом вплоть до элементарной за писи (см. рис. 3-5), селективно р а з р е ш а ю щ и й или за-

	N.L252,		PR I, FA 12743 '
	R E T R I E V E AND REPORT
	OUTPUT			D E V I C E
			TYP							/
	DATA CONDITIONS
			K l (NAME = SMITH
			K2(AGE.BTW,21,30)
			K3(Kl* = GORDON)
			K4 (JOB = PROGRAMMER )
			C l ( L O C N = PHILA)
			C2(DRAFT=IA)
	PROCESSING
			INTRA
				File	1=K2(K1 +	( ~ K 4 ) K 3 ) C 1 ( ~ C 2 )
			INTER
				FOR	F I L E 1
					F I L E 2 = SORT AGE
	OUTPUT FORMAT
	(LI)	TAB'20,"PROGRAMMER					LISTING"
	(L3F)		WHOLE RECORD			F I L E	2
			Рис. 4-2. Образец			запроса		1.
п р е щ а ю щ ий доступ к фиксированным								записям внутри
файла . Выходным				устройством		может			быть	пишущая
машинка .	Если		система имеет			единственное				выходное
устройство или если адрес устройства								(а,	следовательно,
тип) у к а з а н		в	поле		идентификатора,			раздел		Выходное
устройство	в	запросе			может быть		полностью			опущен.

Запрос состоит в поиске и формировании отчетности по

шести условиям д л я данных. Метки данных						(рис. 4-2)
имеют	простое разъяснение:	первые		четыре		из них —
ключи,	две последние — классификатдры .				Однако,		как
уже было указано, эти метки		(Kl,	К2	и т.	д.)	не	могут
быть использованы д л я различения			ключей		и	классифи

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

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

пол ьз овате ль извещается об этом, после чего он может соответственно модифицировать вопрос.

Вприведенном примере пользователь определил

Ключ и соотношения И м я Ключа/Значение

как

N A M E

равно

S M I T H ,

AGE

менаду 21 и 30,

N A M E

равно GOR

DON, JOB

равно PROGRAMMER . Д л я удобства

элемент

N A M E

тройке

N A M E / R E L A T I O N / V A L ' U E

можно

не

повторять,

приписав

соответствующему

обозначению

данных

метку

со

спецальньш

символом

(например,

звездой) .

Таким

образом,

при написании

условия

КЗ

И м я

Ключа

N A M E

обозначается

ссылкой

на

К1*.

За-,

прос

содержит

два

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

L'OCATION - PHILA,

DRAFT - IA .

Логика

внутризаітисной

обработки принадлежит

ти

пу a = i ß .

В левой

части

равенства стоит имя

промежуточ

ного

файла,

определенное

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

справа — ло

гическое

выражение, аргументами

которого

с л у ж а т

мет

ки раздела

Условие.

В рассматриваемом

примере

со

здается

ф а й л с

меткой

F I L E 1 и

вызываются

процедура

поиска

по

списку

внутризаписиая

обработка,

которая

д о л ж н а

найти

все

записи

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

людей

«в

воз

расте от

до

лет

по

имени

S M I T H

или

GORDON,

при

условии,

что

GORDON — непрограммист,

ж и в у щ и х

в Филадельфии

не

п о д л е ж а щ и х

призыву

по

статье

1А». Следует отметить, что справочный просмотр ука


жет, что поиск по списку возможен, потому что									к а ж д а я
дизъюнкция логического в ы р а ж е н и я (приведенного											к
нормальной дизъюнктивной форме) содержит по										край
ней	мере		один	неотрицаемый		ключ.	Однако			усло
вия Cl и не С2"				могут быть	проверены		только		после
того,		как	запись	перенесена	из-	З У П Д	в оперативную
память .
	Вторая		часть	раздела Обработка, ф о р м и р у ю щ а я							от
чет,	интерпретируется следующим					образом . Д л я			каждой
записи		из	файла	F I U E l построить		второй	ф а й л	с	меткой
FILE2, отсортированный по значениям из							поля	с	именем
A G E . Подчеркивающие линии иа рис. 4-2 не несут смыс
ловой		нагрузки — они выделяют типы функции						или		дей
ствий		процессора		запроса . Употребление			а б з а ц е в		в	рас


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

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

слов индекс,	цикл	или гнездо. Некоторые терминальные
устройства.	та>к ж е	как pura M A C H 10, имеют кодовую

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

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

просу.	И м я	это может и не оказаться среди имен,				поме
ченных	в р а з д е л е Условие. Например, возможна					т а к а я
строка: F I L E 2 = SIRT SS			LYLBER; в	этом случае		файл
FILE2 строится по порядку номеров социального инди
видуального		страхования.	З а м е т и м	т а к ж е ,	что	FILE2
в этом примере состоял из полных				записей	и	раздел
Условие не		с о д е р ж а л требования какой-либо			специфиче
ской выборки элементов данных .
Р а з д е л		Выходной ф о р м а т д о л ж е н иметь			непосред
ственную и		простую процедуру построчного			редактиро

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

начало		последовательности		строк, на	которых д о л ж н ы
быть	размещены		различные	заголовки и данные. Запись
( L I )	на	рис. 4-2	означает	1-ю строку.	Операция TAB

принадлежит к функциям процессора запроса . Его ис полнение вызывает табуляцию указанного числа пробе

лов, в нашем случае 20.		Алфавитно - цифровая информа
ция, взятая в	кавычки,	д о л ж н а быть	отпечатана		бук
вально. Таким	образом,	цель первого	ответа	состоит
в изображении	слов PROGRAMMER		L I S T I N G	на	1-й

строке дисплея, начиная с 20-й позиции. Второй ответ С указывает на то, что изображение должно начаться с 3-й строки и занять столько строк (L3F), сколько необходи мо д л я выполнения последующей команды печати. Функ

ция W H O L E		RECORD означает отсутствие		выборки		дан
ных,	т. е. что	и з о б р а ж е н д о л ж е н	быть весь	ф а й л	с	мет
кой	FILE2 с	использованием для	каждой	записи		ранее

размещенного ф о р м а т а изображения . При этом, естест

венно, необходимо убедиться, что любой аргумент	(в на
шем случае FILE2) функции W H O L E RECORD	ранее

определен в запросе. В нашем случае это сделано при

описании межзаписной обработки, когда F I L E 2	опреде
лен как операция сортировки по AGE F I L E 1 ,	который

AQT 1, PRIORITY I, FA 1234

R E T R I E V E AND REPORT

OUTPUT D E V I C E

TYP

DATA CONDITIONS

D! (PROCUREMENT ACTION.LT.5)

D2(BUS1NESS TYPE = J)

D3(D2* = K)

PROCESSING

INTRA

F I L E 1 = D1 AND

F I L E 2 = ( ~ D I

AND (D2 OR

D3)

INTER

FOR

F I L E 1

T O T A L L Y

S1 = SUM ACTION AMOUNT

FOR

F I L E 2

F I L E

3 = SORT DI*

FOR

F I L E

3, SAME DI*

T2=TALLY

S2=SUM ACTION AMOUNT

PRINT (1)

Рис. 4-3. Образец запроса 2.

в свою очередь определяется логической

функцией

вну-

тіризаписной

обработки.

На рис. 4-3 представлен несколько более сложный

пример. У к а з а н ы

три

типа

условий.

Первое

из

них

PROCUREMENT

A C T I O N < б

(при этом

предполагает

ся,

что значения

PROCUREMENT A C T I O N д л я

задан

ного

типа записи

закодированы

как

числа);

второе —

BUSINESS

T Y P E = / .

третье — BUSINESS

TYPE = К.

В действительности, следует ожидать, что значение

поля

данных (ключа или классификатора)

под

именем

PRO

C U R E M E N T A C T I O N представляет собой

выражение на

естественном

языке типа

T E R M I N A T I O N ,

A D D I T I O N A L

TASK, C H A N G E

OF SCOPE и т. д. Однако

из

сообра

жений экономии памяти эти термины часто бывает по лезно кодировать целыми числами. К а к показано в этом

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

поставки с присвоенным кодом менее пяти весьма инте ресуют пользователя) . В нашем примере они представ ляют новый тип контрактов (NEW CONTRACT TYPES) 78

в противоположность модифицированным типам кон

трактов. Внутри записи можно кодировать	как Имена,
так и Значения . В любом случае желательно	разрешить

пользователю специфицировать или название на естест

венном

языке,

или

код

Имени или Значения . Это

требу

ет составления таблицы

перевода

из естественного

языка

в код, а если, кроме того, желательно

получить изобра

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

кодированных

записей, то

и ' о б р а т н о й

таблицы

перевода.

Внутризаписная

функция

Обработки

вызовет

созда

ние

двух

ф а й л о в :

одного

из

них

из

Ç]D2,

а другого

из D2\JD3

Dl.

Другими

словами, F I L E 1 объединит две

поставки

с кодом, меньшим 5 типа

/ ,

a FILE2 — с .кодом,

большим или равным 5, н типом / или

К. М е ж з а п и с н а я

обработка состоит в следующем: д л я всех записей

FIL'El

производится

подсчет

( T A L L Y ) тех

записей,

д л я

кото

рых PROCUREMENT A C T I O N меньше

(т. е. DJ).

Ре

зультат подсчета

(TALLY)

хранится

буферной

памяти

меткой

Tl.

Поскольку

FIL'El

создан

конъюнкцией

Г] D2,

то очевидно, что TJ содержит

общее

число

за

писей

F I L E 1 ,

потому

что

к а ж д а я

запись

удовлетворяет

D1,

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

T A L L Y по

D2 д л я

FLLE2,

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

за

писей д л я

FILE2 . Аналогично, д л я

каждой записи

FILE1

суммируются

значения

поля

A C T I O N

A M O U N T ,

эта

сумма

помещается

в S1. Д л я

всех

записей FILE2

созда

ется

третий

ф а й л

меткой

FILE3,

представляющий

собой

сортировку

SORT

(FILE2)

по

PROCUREMENT

A C T I O N

(Dl*).

После

этого

д л я

всех записей

FILE3,

имеющих одинаковые значения PROCUREMEN T A C T I

ON,

производится

подсчет — T A L L Y

результат

поме

щается

Т2,

сумма

соответствующих A C T I O N

A M O

UNTS

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

помещается

S2.

Функция

T A L L Y без

аргумента

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

как п р и л о ж и м а я

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

опера

тора FOR,

в то время

как

T A L L Y

с аргументом в ы р а ж а

ет подсчет только тех записей, которые

удовлетворяют

аргументу.

Таким

образом,

предыдущее

высказывание

T A L L Y Dl

могло

бы

быть

благодаря

определению

FILE1

просто

T A L L Y .

Д а л е е

исполнится

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

печати,

обозначен

ная

(1).

Это

высказывание

находится

разделе

выход

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

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

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