Ю. А. Григорьев, Г. И. Ревунков - Банки данных

L Основы построения банков данных

данных из базы), организует запрос к ОС на считывание из физической БД (ФБД) необходимой порции данных с машинного носителя в свою буфер­ ную область памяти. Таким образом, в буферной памяти СУБД окажутся хранимые записи, имеющие структуру в соответствии со схемой ВнМД. После этого выполняется требуемое отображение хранимых записей в запи­ си модели, а уже затем затребованные записи модели передаются СУБД в рабочую область (РО) ввода—вывода ПП, затребовавшей эти данные.

Рассмотренная схема решает вопрос обеспечения независимости при­ кладных программ от данных, позволяет реализовывать определенную не­ зависимость системы от используемых технических средств. Однако такая схема, имеющая в своем составе МД, являющуюся глобальным логическим представлением информационного содержимого БД, требует, чтобы поль­ зователь ознакомился с информационным содержимым всей БД. Такая си­ туация во многих случаях неприемлема. Во-первых, потому, что каждый отдельный пользователь в большинстве случаев имеет отношение лишь к небольшой, вполне определенной части данных, хранимых в базе, и у него нет никакой необходимости (да и желания) знакомиться со всем ее инфор­ мационным содержимым. Во-вторых, необходимое пользователю логиче­ ское представление требуемой части хранимых данных может отличаться от их логического представления, принятого в МД. Например, его не интере­ суют многие информационные связи между данными, представленные в модели, но эти связи могут интересовать других пользователей. В-третьих, необходимо обеспечить защиту данных, не имеющих отношения к конкрет­ ному пользователю, от его некомпетентных действий.

Модель данных, являясь глобальным логическим представлением ин­ формационного содержимого БД, не решает этих вопросов. Поэтому необ­ ходимо ввести в рассмотрение еще один уровень логического представле­ ния данных — для каждого конкретного пользователя. Такое представление можно обеспечить введением модели для каждого конкретного внешнего представления. Они получили название внешних моделей данных (ВМД). Рассмотренная в предыдущей схеме МД, в связи с тем, что в ней реализует­ ся полнота охвата всего содержимого БД и принятое в ней логическое пред­ ставление, являясь как бы основной, «синхронизирующей» для конкретного БнД, получила название концептуальной модели (КМД).

Между ВМД и КМД также должно быть реализовано необходимое отображение. Описание отображения может быть выполнено АБД и введе­ но в систему. ВМД имеет свою схему (иногда ее называют «подсхемой», оставляя термин «схема» для КМД), поскольку ВнМД по существу отражает некоторую часть КМД. На рис. 1"3 представлена трехуровневая архитектура БД, в котором СУБД реализует следующие отображения:

ВМД <^ КМД ^ ВнМД ^ ФБД.

30

1.4. Архитектура банка данных

Схема КМД

КМД

Схема ВнМД

ВнМД

ФБД

Рис. 1.3. Трехуровневая архитектура БиД

Система управления базой данных реализует обмен данными между РО ввода—вывода прикладных программ и БД. Любой запрос прикладной программы, сформулированный на языке манипулирования данными, по­ ступает в СУБД. Имея соответствующие описания моделей и описания отоб­ ражений между моделями, СУБД обращается к ОС для выполнения опера­ ций на физическом уровне.

Рассмотрим последовательность действий СУБД при формировании записи ВМД для ПП. Примерный алгоритм выполнения операции чтения данных состоит из следующих шагов.

1. Прикладная программа обращается к СУБД с запросом на чтение записи ВМД.

2.Система управления базой данных, используя схему ВМД, схему КМД и описание отображения ВМД на КМД, определяет, какие записи КМД необходимы для формирования записи ВМД.

3.Используя схему КМД, схему ВнМД и описание отображения КМД на ВнМД, СУБД определяет, какие хранимые записи необходимы для по­ строения затребованных записей КМД, и соответственно определяет сово­ купность физических записей, которые необходимо для этого считать с ма­ шинного носителя.

31

1.Основы построения банков данных

4.Система управления базой данных выдает ОС запрос на считывание

всвою буферную область памяти необходимых записей из ФБД.

5.ОС с помощью своих методов доступа считывает из физической памяти (с машинных носителей) затребованные СУБД физические записи и помещает их в системные буфера СУБД. (Сообщения ОС о выполнении этого пункта добавляются к сообщениям СУБД.)

6.На основании имеющихся схем моделей и описаний соответствую­ щих отображений СУБД формирует в буферной памяти запись ВМД в том виде, какой требуется прикладной программе.

7.Система управления базой данных выполняет пересылку сформи­ рованной записи ВМД в РО.

8.ОС передает в ПП свои сообщения и сообщения СУБД о результа­ тах выполнения запроса.

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

вее рабочую область ввода—вывода.

Таким образом, для БД имеются одна ВнС, описывающая ВнМД, одна КС, описывающая КМД, и столько внешних схем (ВС), сколько требуется, чтобы описать различные ВМД, подлежащие реализации.

Описания отображений между МД необязательно должны выполнять­ ся АБД. Если формализовать ситуации, возникающие при обмене данными между моделями, то СУБД сможет выполнять необходимые преобразования данных на основании имеющихся схем МД.

Наличие в БнД процессов обмена информацией между пользователя­ ми и системой, между АБД и системой, а также между МД различных уров­ ней ставит вопрос об унификации этих процессов, т.е. о разработке соответ­ ствующих интерфейсов — языков описания и манипулирования данными на соответствующих уровнях. Интерфейс пользователя представляет собой язык внешнего уровня, с которым работает пользователь при подготовке исходных текстов ПП или формулировке запросов. После трансляции (или интерпретации) ПП (или запроса) операторы языка внешнего уровня посту­ пают на вход СУБД в объектных кодах. Система управления базой данных имеет внутрисистемные интерфейсы для реализации обмена между МД. Для написания и коррекции схем МД АБД также обеспечивается соответствую­ щими языками.

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

Рассмотрим упрощенный вариант одной из возможных схем функ­ ционирования БнД в составе АС. Основу СУБД составляют программы, реализующие все необходимые преобразования данных в соответствии с имеющимися в системе интерфейсами. Это преобразователи внутренней (ПрВнС), концептуальной (ПрКС) и внешних (ПрВС) схем; преобразо-

32

1.4. Архитектура банка данных

ватели данных, реализующие отображения «внешний—концептуальный» (Пр_В-К), «концептуальный—внутренний» (Пр_К-Вн), «внутренний—па­ мять» (Пр_Вн-П). Таким образом, СУБД можно рассматривать как систему:

СУБД = {Пр_ВнС, Пр_КС, Пр_ВС, Пр_В-К, Пр_К-Вн, Пр_Вн-П}.

Словарь данных (СД) включает в свой состав в минимальном вариан­ те лишь описания схем данных по ПО:

СД={ВнС,КС, {BQ,/=1,/7}}.

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

Интерфейс пользователя обеспечивается соответствующими транслято­ рами для входных языков, на которых формируются запросы или составляют­ ся ПП. После трансляции процедуры реализации запросов (ПРЗ) или ПП в объектных кодах обращаются к СУБД с требованием на выполнение необхо­ димого обмена данными с базой, указывая при этом имя ВС, в соответствии с которой должен быть выполнен обмен. СУБД обращается к словарю данных, считывает ВнС, КС и соответствующую ВС и настраивается на вьшолнение необходимых преобразователей данных; затем она считывает требуемые дан­ ные из базы и, выполнив все преобразования, передает их в ПП.

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

Рассмотренный трехуровневый подход к построению БнД, включающий внешний, концептуальный и внутренний уровни, получил наибольшее распро­ странение и признание. При таком подходе на внешнем уровне поддерживают­ ся ограниченные модели ПО, видимые отдельными приложениями (пользова­ телями). На концептуальном уровне поддерживается модель ПО для всех при­ ложений. Хранимые данные также представляют модель ПО для всех приложений, но они выделены в отдельный, внутренний уровень. При такой архитектуре БнД обладает высокой способностью адаптации к воз­ можным изменениям как в ПП, так и в самих данных: любые изменения ВС и ВнС изолированы друг от друга и от КС и могут выполняться неза-

33

/. Основы построения банков данных

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

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

Может существовать диапазон реализаций функций отображения меж­ ду моделями и функций манипулирования данными при разработке кон­ кретных СУБД. Этот диапазон определяется компромиссным решением между производительностью системы и ее функциональной гибкостью. На одном ее конце может быть решение, при котором каждой концептуальной записи соответствует внутренняя запись, а каждой внешней записи — кон­ цептуальная запись. В этом случае внешняя запись реализуется непосредст­ венно и взаимно однозначно из внутренней записи. Такой вариант обладает высокой производительностью при обработке приложений и наибольшей избыточностью (дублированием) данных со всеми вытекающими отсюда последствиями. На другом конце диапазона находятся системы, в которых сразу на основании схем создается (компилируется) программа для реализа­ ции требуемого отображения и с ее помощью выполняется непосредствен­ ное формирование внешней записи из внутренних.

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

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

Переход от одного уровня абстрагирования к другому и составляет в общем случае процесс проектирования БД, представляющий собой слож­ ный процесс проектирования отображения:

34

L4. Архитектура банка данных

Описание ПО ^ ВнС БД.

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

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

Основные этапы проектирования БД: инфологическое и датологическое проектирования, причем последнее подразделяют на логическое и фи­ зическое проектирования.

В зависимости от этапа различают инфологическую и датологическую КМД (последнюю обычно называют просто концептуальной), инфологиче­ скую и датологическую ВМД.

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

Выполняется структуризация знаний ПО — выделяются и классифи­ цируются множества составляющих ПО, стандартизируется терминология. Затем осуществляется композиция инфологической КМД, в процессе кото­ рой основную роль играют потребности пользователей, а также описание информации, требуемой каждому конкретному пользователю (т.е. описание запросов к БД). Каждый запрос соотносится с определенным фрагментом ПО. Далее формируются описания инфологических ВМД, их взаимная увязка с инфологической КМД. Полученные описания инфологических мо­ делей отражают составляющие ПО, связи между ними, но они не должны зависеть от методов представления данных в конкретной СУБД.

Концептуальная инфологическая модель призвана обеспечить проч­ ную и долговременную работу всей системы. Эта модель должна выдержи­ вать замену одной используемой СУБД на другую.

35

/. Основы построения банков данных

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

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

1.5. Централизация и децентрализация процессов обработки данных

Централизация процессов обработки данных позволила устранить та­ кие недостатки, как несвязность, противоречивость и избыточность данных в информационной системе, обеспечила возможность комплексно решать вопросы стандартизации в представлении данных, обеспечения санкциони­ рованного доступа к ним и др. Однако по мере роста БД использование их в территориально разнесенных организациях привело к тому, что централизо­ ванная СУБД, находящаяся в узле телекоммуникационной сети, обеспечи­ вающей доступ пользователей из территориально разнесенных пунктов к хранимым данным, стала плохо справляться с ростом числа обрабатывае­ мых транзакций в связи с большим потоком обмена данными между терми­ налами и центральной ЭВМ. Такая ситуация привела к снижению надежно­ сти и общей производительности системы при обработке запросов пользо­ вателей. Поэтому была предложена идея децентрализации процессов обра­ ботки данных в информационных системах для организаций, подразделения которых разнесены. И хотя децентрализация данных затрудняет решение таких вопросов, как обеспечение целостности и непротиворечивости дан­ ных, их безопасности, тем не менее она позволяет повысить производитель­ ность обработки, улучшить использование данных на местах и снизить за­ траты на их обработку.

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

36

7.5. Централизация и децентрализация процессов обработки данных

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

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

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

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

все данные распределенной БД полностью дублируются в каждом уз­ ле сети;

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

Децентрализованная обработка данных помимо задачи распределения их по сети выдвигает ряд новых требований по сравнению с централизованной:

1)распределенные БД могут быть однородными или неоднородными

всмысле используемых в системе технических и программных средств (СУБД), поэтому должна быть решена проблема преобразования структур данных и ПП;

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

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

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

Рассмотрим архитектуру однородных распределенных БД. Для описа­ ния информационной структуры всей сети используедгся интерфейс КМД — глобальная сетевая концептуальная схема, или сетевая метамодель данных. Для обеспечения работы внешних пользователей вводится интерфейс внеш-

37

/. Основы построения банков данных

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

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

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

1.6. Архитектура банков знаний

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

Экспертные системы создаются для решения разного рода практиче­ ских проблем. Рассмотрим некоторые из них.

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

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

Прогноз. При прогнозировании ЭС определяет вероятные последствия заданных ситуаций.

Управление. Здесь ЭС осуществляет адаптивное руководство поведе­ нием системы в целом.

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

38

1.6. Архитектура банков знаний

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

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

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

Основные характеристики экспертных систем

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

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

3.Способность анализировать и объяснять пользователю свои дейст­ вия и знания.

4.Способность приобретать от эксперта или пользователя новые зна­ ния и менять в соответствии с ними свое поведение.

5.Обеспечение дружественных по отношению к пользователю интер­ фейсов (обычно это естественно-языковый интерфейс).

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

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

39