Алешин Л.И., Максимов Н.В. Информационные технологии

Подождите немного. Документ загружается.

231

свойств математической теории, лежащей в его основе. Минимальный

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

точным для формулирования большинства запросов, и лишь формули-

ровка сложных запросов может потребовать использования всех вырази-

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

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

требуют от пользователя знания почти всего объёма средств языка, что

усложняет процесс их изучения.

Наиболее распространенным языком для работы с БД является

SQL (Structured Query Language), в своих последних реализациях пре-

доставляющий не только средства для спецификации и обработки запро-

сов на выборку данных, но и функции по созданию, обновлению, управ-

лению доступом и т.д.

По существу SQL соединяет и язык описания данных, и язык ма-

нипулирования данными. Он не является полноценным языком про-

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

БД из прикладных программ, SQL-выражения встраиваются в конструк-

ции базового языка.

Являясь внутренним языком БД, SQL естественно отражает осо-

бенности конкретной СУБД. Сегодня это единственный стандартизо-

ванный язык фактографических БД, достаточно мощный и в тоже время,

простой для понимания и использования. Сочетание этих факторов вме-

сте с поддержкой ведущих производителей, таких как IBM и Microsoft,

привели к его широкому распространению и совершенствованию. Бла-

годаря независимости от конкретных СУБД и межплатформенной пере-

носимости, SQL стал языком распределённых баз данных (РБД) и язы-

ком шлюзов, позволяющим совместно использовать СУБД разного типа.

Программные средства БД

Рис. 13-3. Программные средства СУБД

Язык базы данных

Генератор

форм

Генератор

отчетов

Обработчик

запросов

Прикладная

программа

Клиентская

программа СУБД

Ядро базы данных

БД

Язык базы данных Язык базы данных

Сервисные

программы

Шлюзы

других БД

Библиотеки и п

ессо

языка базы

анных .

232

Обработка данных и управление этой обработкой в вычислитель-

ной среде, а также взаимодействие с ОС и ПП осуществляется комплек-

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

13-3.

В составе комплекса обычно выделяют следующие компоненты:

• ядро, обеспечивающее управление данными во внешней и опе-

ративной памяти, а также протоколирование изменений;

• процессор языка базы данных, обеспечивающий обработку

(трансляцию или компиляцию) и оптимизацию запросов на выборку и

изменение данных;

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

обслуживающую прикладные программы управления данными, взаимо-

действующие с СУБД через средства пользовательского интерфейса;

• сервисные программы (системные и внешние утилиты), обес-

печивающие настройку СУБД, восстановление после сбоев и ряд допол-

нительных возможностей по обслуживанию

Большинство СУБД работают в среде ОС и тесно с ней связаны.

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

сов, защита данных требуют эффективно использовать ресурсы, управ-

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

процессорных систем и мультипоточных технологий обработки данных

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

но требует координации использования ресурсов между ОС и СУБД.

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

обычно интегрируются с соответствующими средствами ОС.

Именно централизованное управление данными обеспечивает:

● сокращение избыточности в хранимых данных;

● совместное использование хранимых данных;

● стандартизацию представления данных, упрощающую эксплуа-

тацию БД;

● разграничение доступа к данным;

● целостность данных, обеспечиваемую процедурами, предотвра-

щающими включение в БД неверных данных и её восстановление после

отказов системы.

Технические средства БД

Большинство банков данных создаётся и функционирует на основе

универсальных вычислительных машин. Отметим достаточно интенсив-

но развивавшееся в 1980–1990 гг. направление создания машин баз дан-

ных – аппаратной реализации «нечисловой» обработки, в том числе па-

раллельной и конвейерной обработки, ассоциативных процессоров и па-

мяти [Озкарахан]. Ныне для реализации промышленных БД использу-

ются специализированные серверы баз данных – машины с повышенной

233

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

вывода и развитой периферией.

Для больших БД, функционирующих в промышленном режиме,

обеспечение эффективной и бесперебойной работы должно основывать-

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

Устройства ввода-вывода и накопители внешней памяти – тради-

ционно узкое место любой БД. Объём и быстродействие накопителей

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

устойчивость. Следует отметить необходимость согласованных решений

при распределении ролей между аппаратными и программными компо-

нентами управления операциями ввода-вывода. Например, наличие бу-

ферной памяти в накопителе ускоряющей ввод-вывод (аппаратное кэ-

ширование) при сбоях системы во время выполнения операции записи в

БД может привести к потере данных: переданные для записи данные бу-

дут ещё находиться в буфере, а СУБД отметит операцию записи как за-

вершившуюся и откат для восстановления данных станет невозможным.

Для повышения надёжности хранения часто используют специали-

зированные дисковые подсистемы – RAID (тема 12). В случае повреж-

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

данные.

Не менее значима роль центрального процессора. Многие про-

мышленные СУБД поддерживают многопроцессорную обработку запро-

сов. Теоретически использование ещё одного процессора позволяет ус-

корить обработку. Однако на практике многопроцессорные системы

требуют повышенного внимания при приобретении оборудования: на-

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

соответствующие периферийные устройства.

Для распределённых и удалённо используемых БД также важно

сетевое окружение: связное оборудование и сетевые протоколы. Причём

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

можности обеспечения безопасности.

Организационно-административные подсистемы БД

Организационно-методические средства не являются технической

компонентой системы, однако трудно рассчитывать на устойчивое и

долговременное функционирование БД, если отсутствуют необходимые

методические и инструктивные материалы, регламентирующие работу

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

сти.

234

Пользователи БД

В информационных системах, создаваемых на основе СУБД, спо-

собы организации данных и методы доступа к ним перестали играть ре-

шающую роль, поскольку оказались скрытыми внутри СУБД. Массо-

вый, так называемый конечный пользователь, как правило, имеет дело

только с поддерживаемым СУБД внешним интерфейсом.

Эти преимущества не могут быть реализованы путём механиче-

ского объединения данных в БД. Предполагается, что в системе сущест-

вует (как неотъемлемая составная часть) специальное должностное лицо

(группа лиц) — администратор базы данных (АБД), несущий ответст-

венность за проектирование и общее управление БД. АБД определяет

информационное содержание БД, идентифицируя объекты БД и модели-

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

дальнейшем справочным документом для администраторов приложений

и пользователей. Администратор решает также все вопросы, связанные с

размещением БД в памяти, выбором стратегии и ограничений доступа к

данным. В функции АБД входят организация загрузки, ведения и вос-

становления БД и многие другие действия, которые не могут быть пол-

ностью формализованы и автоматизированы.

Администратор приложений (если таковой специально не выде-

ляется – администратор БД) определяет для приложений подмодели

данных. Тем самым разные приложения обеспечиваются собственным

«взглядом», но не на всю БД, а только на требуемую для конкретного

приложения («видимую») её часть. Вся остальная часть БД для данного

приложения «прозрачна».

Прикладные программисты имеют, как правило, в своем распоря-

жении один или несколько языков программирования, с помощью кото-

рых генерируются ПП.

Основное внимание в этой теме уделено системам управления

данными, построенным на основе однородных файлов, а также рассмот-

рению основ построения систем управления, использующих «однофай-

ловые» страничные модели организации данных.

Организация данных на машинных носителях

С общепринятой точки зрения к вопросам организации данных от-

носятся:

• выбор типа записи – единицы обмена в операциях ввода-

вывода;

• выбор способа размещения записей в файле и, возможно мето-

да оптимизации размещения;

• выбор способа адресации и метода доступа к записям.

235

Типы записей

Логическая запись, с которой работает прикладная программа –

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

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

прикладной программой как единое целое. Последовательность записей

в логике обработки образует файл.

Физическая запись, с которой работает файловая система – сово-

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

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

мандой ввода-вывода. Здесь файл

– последовательность физических

записей, размещаемых в линейном пространстве носителя. В общем

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

Организация данных в случаях логического и физического пред-

ставления может не совпадать, в частности, одна физическая запись мо-

жет включать несколько логических (блокирование записей). При этом

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

ной степени зависят от типа записи, рассматриваемого как характер ор-

ганизации последовательности байтов.

На логическом уровне выделяют следующие типы:

• записи фиксированной длины, для размещения каждой из кото-

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

ранее. В этом случае данные, образующие запись, имеют устойчивую

природу и представляются жёсткими структурами, например ряд число-

вых полей или символьная последовательность заданной длины;

• записи переменной длины, когда каждый экземпляр записи мо-

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

этом случае запись содержит либо элементы данных переменной длины

(например, текстовую строку), либо переменное число элементов фик-

сированной длины.

Организация физической записи для достаточно часто встречаю-

щегося случая блокирования логических записей фиксированной или

переменной длины представлена на Рис. 13-4.

Рис. 13-4. Физическая организация логических записей

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

В некоторых операционных системах, например IBM, файл на внешних носителях называют набо-

ром данных в отличие от логического файла.

Физическая запись

Лог. запись

Лог. запись Лог.запись

Физическая запись

Лог.запись N+1

236

длины

отличается тем, что байтам содержания – собственно данным,

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

содержания этой логической записи.

Существует и другая физическая структура представления запи-

сей, имеющих переменную длину – запись неопределённой длины, когда

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

«конец записи»

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

поскольку для определения начала следующей записи надо считать зна-

чение длины текущей.

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

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

относительного номера нужной записи на длину записи.

Физические записи на носителе следуют непосредственно друг за

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

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

ситель.

Первый способ, применяемый в запись-ориентированных устрой-

ствах внешней памяти мэйнфреймов, основан на том, что каждая запись

отделяется от соседней физическим промежутком, неиспользуемым для

записи, и воспринимаемым устройством чтения как сигнал «конец запи-

си».

Другой способ – размещение байтов следующей записи без каких

либо разделителей непосредственно за последним байтом предыдущей

записи. Для этого способа характерна меньшая зависимость от особен-

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

блокирование

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

Организация файлов – способ размещения записей

Записи файла обычно располагаются на носителе последовательно

в том порядке, как они создаются в прикладной программе. Но иногда

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

от их логической последовательности.

Последовательность размещения физических записей естественно

может быть только одна (если содержание логической записи сознатель-

но не дублируется в другой форме) и она должна быть выбрана с учётом

эффективности использования данных в различных приложениях. Спо-

собы организации файлов представлен на Рис. 13-5.

Выбор последовательности связывается с одним из следующих

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

В поток-ориентированных файловых системах этому соответствует организация текстовых файлов,

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

кодами «CR» «LF».

Блокирование записей переменной и неопределенной длины в этом случае будет практически не-

возможно.

237

обстоятельств:

1. Ускорением выполнения наиболее частых операций путём раз-

мещения записей в той последовательности, которая требуется при по-

следующей обработке.

2. Ускорением или упрощением средств адресации файла (напри-

мер, средств прямой адресации или хэшивания).

3. Уменьшением размера используемого индекса и сокращением,

таким образом, времени поиска в нем.

4. Сокращением среднего времени доступа за счёт размещения в

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

частое обращение.

5. Облегчением операций включения, обновления и удаления за-

писей в интенсивно изменяемых файлах.

Можно выделить две «чистые» стратегии определения места (ад-

реса) для размещения записей: последовательное (sequential) и произ-

вольное (random) размещение. В этом смысле алгоритм размещения оп-

ределяет тип организации файла.

В первом случае каждая следующая запись физически располага-

ется следом за предыдущей. Во втором – по месту, адрес которого опре-

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

тых выше.

Рис. 13-5. Способы организации файлов

Хотя записи на устройствах с прямым доступом могут записы-

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

данных существует некоторая определенная последовательность, в ко-

торой записи можно читать намного быстрее, чём при других способах

размещения.

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

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

Страничная организация. Данные можно перемещать между

Страничная

организация

Параллельная

секционная

организация

Размещение

соответст-

венно частоте

использова-

ния

Записи

Ин

екс

Данные

238

внешней и оперативной памятью страницами фиксированной длины.

Размер страницы определяется системой, а не длиной записи. Там, где

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

симы от размера страницы, но они должны быть физически сгруппиро-

ваны СУБД так, чтобы эффективно заполнять страницы.

Параллельная секционная организация. Если имеется несколько

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

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

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

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

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

ожиданий. Запросы должны ожидать позиционирования механизма дос-

тупа (операция установки и задержки на вращение), а затем – ждать вы-

полнения операции чтения-записи. Время, в течение которого запись чи-

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

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

при параллельной организации будет меньше.

В современных СУБД наиболее часто используется страничная

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

на одном пакете дисков, чем на нескольких, однако принципы секцион-

ной организации вновь нашли применение в системах планирования БД,

а так же на уровне аппаратных решений RAID-массивов.

Размещение соответственно частоте использования. Если в

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

системе предусмотрены специальные методы доступа, то наиболее часто

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

в файлах с «быстрым» методом доступа.

Аналогичный принцип используется при «кэшировании», когда

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

память с быстрым доступом, обеспечивающимся в основном программ-

ными средствами за счёт упорядочения размещения и введения избы-

точности.

Поиск информации в БД

Обобщенная схема информационного поиска

Процесс поиска информации представляет последовательность

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

позволяющих пользователю оценить его полноту, т.е. оценить новое со-

стояние совокупной системы, как свое новое знание, так и системы (мо-

жет ли пользователь быть уверенным в том, что полученный результат –

исчерпывающий и ничего более по искомой проблеме не содержит). Так

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

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

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

239

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

межуточных результатах и обобщениях, сопоставляя их, например, с

предыдущими.

С другой стороны, поскольку запрос (его поисковый образ) явля-

ется формально описанной моделью информационной потребности

пользователя, то по смысловыражению ПОЗ и ПОД должны быть при-

ведены в соответствие. Т.е. либо пользователь должен принимать кон-

цептуальную платформу (и знаковую систему) индексатора, либо, если

ИПС является интеллектуальной, система на основе выражения запроса

(иногда представленного в форме естественного вопроса) должна рекон-

струировать проблему, решаемую пользователем, и построить логиче-

скую модель поиска.

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

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

АИПС может включать некоторое разнообразие механизмов поиска. На-

пример, в АИПС IRBIS представлены следующие механизмы поиска. В

случае формирования запроса на ИПЯ – это механизм поиска по совпа-

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

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

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

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

релевантности документа необходимо формировать результат логиче-

ского выражения. Если запрос представлен документами, то, в зависи-

мости от типа интерфейсного объекта, получаем: в случае отдельного

документа – поиск аналогов, если поиск выполняется автоматически, а

если поисковые термины указываются в документе пользователем – по-

иск по совпадению терминов. Соответственно, если интерфейсный объ-

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

формирует словник автоматически, получаем эвристический поиск, а

если поисковые термины в словнике указываются пользователем – «по-

иск по контексту».

Задача информационного поиска относится к классу человеко-

машинных. Образ информационной потребности имеет в качестве носи-

теля сознание человека, именно человек производит сопоставление об-

раза со смысловым содержанием отбираемых документов, а также оце-

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

вывод, что система должна предоставлять интерактивный режим для ор-

ганизации гибкого процесса, эффективного в первую очередь с точки

зрения человека.

Причём на уровне интерфейса такие технологические объекты и

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

что облегчает пользователю переключение с задачи своей основной дея-

тельности (сбора информации для решения задачи) на информационную

240

– оценку своих поисковых действий и состояний

Сам процесс поиска – итеративная последовательность создания и

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

ное и управляемое перемещение (навигацию) в документальном и лекси-

ческом пространстве БД и обеспечивающая оцениваемый уровень удов-

летворения информационной потребности или объективно подтвер-

ждающая отсутствие информации.

Целенаправленность здесь предполагает представление некоторой

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

ционных целей, имеющих тематический (многоаспектный поиск) и (или)

технологический характер. Это означает, что для того, чтобы обеспечить

целенаправленность избирательного обращения к поисковым объектам,

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

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

процессе её достижения.

Управляемость – с одной стороны, возможность выбора средств и

(или) параметров работы, а с другой – обоснованное обращение к техно-

логическим объектам, в том числе повторное обращение к результатам и

их обработка, например, статистическая или структурно-форматная.

Кроме того, поскольку выделенная последовательность результатов (фи-

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

цели) образует ряд, то это позволяет использовать статистически вычис-

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

процесса поиска и, в частности, обеспечивающие обоснованность реше-

ния об окончании процесса совершенствования запроса.

Поскольку объект поиска обычно не задан в виде образца, с кото-

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

всегда ограничены, задача организации процесса поиска имеет оптими-

зационный характер – при временных ограничениях максимизировать

показатели выдачи и получить максимальную (субъективную) уверен-

ность в качестве поиска за счёт предоставления пользователю в процессе

диалога альтернативных направлений, а также количественные и каче-

ственные оценки их соответствия запросу.

При этом активность системы по отношению к пользователю может реализоваться различными пу-

тями:

- непосредственным вмешательством в процесс через изменение параметров процедур, например

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

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

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

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

мулировании запроса по обратной связи).