Карпова Т.С. Базы данных: модели, разработка, реализация

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

Методы

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

оптимизации

запросов

291

предикат

соединения;

особенно

важен

случай

экви

соединения,

когда

ОС

оно

равенство).

Если

начальном

представлении

предикат

имеет

вид:

12*(Rl.A)-n*(R2.B)

ОС п.

то его

каноническое

представление:

R1.A

ОС

Cm+n*(R2,B)/12

общем

случае

желательно

приведение

нррдпката

каноническому

пред-

. ,

ставлеиию

вида

арифметическое

выражение

ОС

константное арифнетическое

выраже-

ние,

где

выражения

правой

левой

частей

также

приведены

каноническому

представлению.

дальнейшем

можно

произвести

поиск

общих

арифметиче-

ских

выражений

разных

предикатах

запроса.

Это

оправдано,

поскольку

при

выполнении

запроса

вычисление

арифметических

выражений

будет

произ-

водиться

при

выборке каждого очередного

кортежа,

то

есть

потенциально

боль-

шое

число

раз.

При

приведении

предикатов

каноническому

представлению

можно

вычис-

лять

константные

выражения

избавляться

от

логических

отрицаний.

Еще

один

класс

логических

преобразований

связан

приведением

канони-

ческому

виду

логического

выражения,

задающего

условие

выборки

запроса.

Как

правило,

используются

либо

дизъюнктивная,

либо

конъюнктивная

нор-

мальные

формы. Выбор

канонической

формы

зависит

от

общей

организации

оптимизатора.

При

приведении

логического

условия

каноническому

представлен

ню

мож-

но

производить

поиск

общих

предикатов

(они

могут

существовать

изначаль-

но,

могут-

появиться

после

приведения

предикатов

каноническому

виду

или

процессе

нормализации

логического

условия)

упрощать

логическое

вы-

ражение

за

счет,

например,

выявления

конъюнкции

взаимно

противореча-

щих

предикатов.

Преобразования

запросов

изменением

порядка

реляционных

операций.

традиционных

оптимизаторах

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

логические

преобразования,

связанные

изменением

порядка

выполнения

реляционных

операций.

Например,

имеем следующий

запрос:

NATURAL

JOIN

WHERE

R1.A

ОС a

AND

R2.B

С b

Здесь

некоторые

константы,

которые

ограничивают

значение

атрибутов

отношений

R2.

Если

мы его

рассмотрим

терминах

реляционной

алгебры,

то это

естествен-

ное

соединение

отношений

R1 и R2, в

которых заданы

внутренние

ограниче-

ния

на

кортежи каждого

отношения.

Для

уменьшения

числа

соединяемых

кортежей

резоннее

сначала

произвести

операции

выборки

на

каждом

отношении

только после

этого

перейти

опе-

рации

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

соединения,

292

Глава

14.

Обобщенная

архитектура

СУБД

Поэтому

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

операций

реляционной

алгебры:

R1CR1.A

ОС а]

R2ER2.B

Ь]

R3*[ ]*R4

Хотя

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

чистом виде

на

реляционной

алгебре,

правила

преобразований

алгебраиче-

ских выражений

могут

быть полезны

и в

других

случаях.

Довольно

часто

реляционная

алгебра используется

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

внутреннего'представ-

ления

запроса. Естественно,

что

после этого можно выполнять

алгебраиче-

ские

преобразования.

частности, существуют подходы, связанные

преобразованием запросов

на

языке

SQL к

алгебраической

форме.

Особенно

важно

то, что

реляционная

алгебра более проста,

чем

язык SQL. Преобразование запроса

алгебраиче-

ской

форме упрощает

дальнейшие

действия оптимизатора

по

выборке опти-

мальных

планов.

Вообще говоря, развитый оптимизатор запросов

системы,

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

на

SQL,

должен

выявить

все

возможные планы

йыполне-

ния

любого запроса,

но

«пространство поиска» этих планов

общем случае

очень

велико;

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

стики

для

сокращения пространства

поиска.

Некоторые, возможно, наиболее

оптимальные планы никогда

не

будут

рассматриваться. Разумное

преобра-

зование

запроса

на SQL к

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

про-

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

гарантией

того,

что

опти-

мальные

планы потеряны

не

будут.

Приведение

запросов

вложенными

подзапросами

запросам

соедине-

ниями.

Основным отличием языка

SQL от

языка

реляционной

алгебры

явля-

ется возможность использовать

логическом

условии

выборки

предикаты»

содержащие

вложенные подзапросы. Глубина вложенности

не

ограничива-

ется

языком,

то

есть,

вообще

говоря,

может

быть

произвольной. Предикаты

вложенными подзапросами

при

наличии общего синтаксиса могут обладать

весьма различной семантикой.

Единственным

общим

для

всех

возможных

се-

мантик

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

выполнения

запроса является

вычисление

вложенного

подзапроса всякий

раз при

вычислении значения пре-

диката. Поэтому

естественно

стремиться

такому

преобразованию

запроса,

содержащего предикаты

со

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

се-

мантику

подзапроса более

явной,

предоставив

тем

самым

дальнейшем

оп-

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

запроса,

наиболее точ-

но

соответствующий семантике подзапроса.

Каноническим

представлением

запроса

на

п-отношениях

называется запрос,

содержащий

п-1

предикат соединения

и не

содержащий предикатов

вло-

женными

подзапросами.

Фактически каноническая форма

- это

алгебраиче-

ское представление запроса.

Например, запрос

вложенным

подзапросом:

Методы

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

оптимизации запросов

293

(SELECT

R1.A

FROM

WHERE

Rl.B

IN'

(SELECT

R2.B

FR^M

WIPE

Rl.C

R2.D)

)

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

(SELECT

Rl.A

FROM

Rl. R2

WHERE'Rl.A

R2.B

AND

Rl.C

R2.D)

Второй

запрбс:

(SELECT

Rl.A

FROM

WHERE

Rl.K

(SELECT

AVG4R2.B)

FROM

WHERE

Rl.C

•=

R2.D)

или

(SELECT

Rl.A

FROM

Rl,

WHERE

Rl.C

R3.D

AND

Rl.K

R3.L)

SELECT

R2.D/L

AVG

(R2.B)

FROM

GROUP

R2.D

При

использовании подобного подхода

оптимизаторе запросов

не

обязательно

производить

формальные преобразования запросов. Оптимизатор

должен

боль-

шей

степени

использовать

семантику

обрабатываемого запроса,

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

она

будет

распознаваться

— это

вопрос

техники.

Заметим,

что в

кратко

описанном

нами подходе имеются некоторые тонкие

се-

мантические

некорректности.

Известны

исправленные

методы,

но они

слишком

сложны

технически,

чтобы рассматривать

их в

данном

пособии.

Методы

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

оптимизации

запросов

Рассмотренные

ранее

методы

никак

не

связаны

семантикой конкретной

БД,

они

применимы

любой

БД, вне

зависимости

от ее

конкретного

содержания.

Семантические методы оптимизации

основаны

как раз на

учете

семантики кон-

кретной

БД.

Таких методов

различных

реализациях может быть множество,

мы

вами коснемся лишь

некоторых

из

них:

Преобразование

запросов

с учетом

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

информации.

Это

преж-

де

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

запросам,

которые выполняются

над

представлениями.

Само

представление

представляет собой запрос.

В БД

представление

хранит-

ся в

виде

скомпилированного

плана выполнения запроса,

то

есть

в нем в не-

294

Глада

14.

Обобщенная

архитектура

СУБД

которой

канонической форме

представлены

уже

вес

предикаты

'сам

план

выполнения

запроса.

При

преобразовании внешнего

запроса

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

объединение

внешнего

запроса

внутренней

формой

запроса,

составляюще-

го

основу

представления,

строится

обобщенная

каноническая

форма,

объе-

диняющая

оба

запроса.

Для

этой

новом

формы

проводится

анализ

преобра-

зование

предикатов.

Поэтому

при

выполнении

запроса

над

представлением

будет

выполнено

не

два,

только

один

запрос,

оптнмн.-шрованный

по

обоб-

щенным

параметрам запроса.

Использование

ограничений

целостности

при

анализе

запросов.

Ограниче-

ния

целостности

связаны

условиями,

которые

накладываются

па

значения

столбцов

таблицы.

При

выполнении

запросов

лад

таблицами

условия

запро-

сов

объединяются

специальным

образом

условиями

ограничений

таблицы

полученные

обобщенные

предикаты

уже

анализируются.

Допустим,

что мы

ищем

нашей

библиотеке

читателей

возрастом

более

100

лет,

но

если

у пас

есть

ограничение,

заданное

для

таблицы

READERS,

которое

ограничивает

дату

рождения

наших

читателей,

так

чтобы

читатель

имел

дату

рождения

преде-

лах

от 17 до 100 лет

включительно. Поэтому

оптимизатор

запроса,

сопоста-

вив

два

эти

предиката,

может

сразу

определить,

что

результатом

запроса

бу-

дет

пустое множество.

После

оптимизации

запрос

имеет

непроцедурный

вид,

то

есть

нем

но

опреде-

лен

жесткий

порядок

выполнения

элементарных

операций

над

исходными

объ-

ектами.

На

следующем этане

строятся

все

возможные

планы

выполнения

запро-

сов

для

каждого

из

них

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

стоимостные

оценки.

Оценка планов

выполнения

запроса

основана

на

анализе

текущих

объемов

данных,

хранящихся

отношениях

БД,

на

статистическом

анализе

хранимой

информации.

боль-

шинстве

СУБД

ведется

учет

диапазона

значений

отдельного

столбца

указани-

ем

процентного

содержания

для

каждого

диапазона.

Поэтому

при

построении

плана

запроса

СУ15Д

может

оцепить

объем

промежуточных

отношений

по-

строить

план таким образом, чтобы

па

наиболее

ранних

этапах

выполнения

за-

проса

минимизировать

количество

строк, включаемых

промежуточные

отно-

шения.

Кроме

ядра

СУБД

каждый

поставщик

обеспечивает

специальные

инструмен-

тальные

средства,

облегчающие

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

БД

разработку

новых

про-

ектов

БД

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

приложений

для

данного сервера.

последнее

время

практически

все

утилиты

инструментальные

средства

имеют

развитый

графический

интерфейс.

Для

разработки

приложений

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

могут

применять

не

только

инстру-

ментальные

средства,

поставляемые вместе

сервером

БД,

но

средства сто-

ронних

поставщиков.

Так,

нашей

стране

получила

большую

популярность

ин-

струментальная

среда

Delphi,

которая позволяет разрабатывать

приложения

для

различных

серверов

БД. За

рубежом более

популярными

являются

инстру-

ментальные

системы

быстрой

разработки

приложений

(RAF Rapid

Application

Foundation)

продукты

компании

Advanced

Information

System,

инструменталь-

ной

среды

Power

Builder

фирмы

Power

Soft,

системы

SQL

Windows

фирмы

Gupta

(Taxedo).

ЗАКЛЮЧЕНИЕ

Перспективы

развития

БД

СУБД

Современные базы данных являются

основой

многочисленных

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

ных

систем.

Информация,

накопленная

них,

является

чрезвычайно

цепным

материалом,

л в

настоящий момент

широко

распространяются методы обработ-

ки

баз

данных

точки

зрения

извлечения

из

них

дополнительных знаний,

мето-

дов, которые связаны

обобщением

различными

дополнительными

способами

обработки

данных.

Базы

данных

данной

концепции

выступают

как

хранилища

информации,

это

направление

называется

«Хранилища

данных»

(Data Ware-

house),

Для

работы

«Хранилищами

данных»

наиболее

значимым

становится

так

на-

зываемый

интеллектуальный

анализ

данных

(НАД),

пли

data mining,

— это

про-

цесс

выявления

значимых

корреляций,

образцов

тенденций

больших

объемах

данных. Учитывая высокие темпы роста объемов

накопленной

современных

хранилищах

данных

информации,

невозможно

недооценить

роль

НАД.

По

мне-

нию

специалистов Gartner Group,

уже в

1998

г.

НАД

вошел

десятку важней-

ших

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

технологий.

последние

годы началось активное

вне-

дрение

технологии

НАД,

Ее

активно

используют

как

крупные корпорации,

так

более мелкие фирмы, которые серьезно

относятся

вопросам

анализа

про-

гнозирования

своей

деятельности.

Естественно,

на

рынке программных продук-

тов

стали

появляться

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

инструментальные средства.

Особенно

широко

методы

НАД

применяются

бизнес-приложениях

аналитика-

ми

руководителями

компаний.

Для

этих

категорий

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

разрабаты-

ваются

инструментальные

средства высокого

уровня,

позволяющие решать доста-

точно

сложные

практические

задачи

без

специальной

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

подготовки,

Актуальность

использования

НАД

бизнесе

связана

жесткой

конкуренцией,

воз-

никшей

вследствие

перехода

от

«рынка

продавца»

«рынку

покупателя».

этих

условиях

особенно

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

обоснованность

принимаемых

решений,

что

требует

строгого

количественного

анализа

имеющихся

данных.

При

работе

боль-

шими

объемами

накапливаемой

информации

необходимо

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

отслеживать

динамику

рынка,

а это

практически

невозможно

без

автоматизации

аналитической

деятельности.

296

Заключение

бизнес-приложениях

наибольший

интерес представляет интеграция

методов

интеллектуального анализа данных

технологией

оперативной

аналитической

обработки

данных

(On-Line

Analytical Processing,

OLAP).

OLAP

использует

мно-

гомерное

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

для

быстрого доступа

важ-

ной

информации

дальнейшего

ее

анализа.

Системы OLAP обеспечивают

аналитикам

руководителям быстрый последо-

вательный

интерактивный доступ

внутренней структуре данных

возмож-

ность

преобразования исходных данных

тем, чтобы

они

позволяли отразить

структуру системы нужным

для

пользователя способом. Кроме

того,

OLAP-сис-

темы

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

выявлять имеющиеся

них

законо-

мерности

либо визуально, либо

простейшими

методами (такими

как

линейная

регрессия),

включение

в их

арсенал

нейросетевых

методов обеспечивает суще-

ственное

расширение аналитических возможностей.

основе концепции

оперативной

аналитической обработки

(OLAP)

лежит

мно-

гомерное представление данных. Термин OLAP ввел Кодд

(Е.

Codd)

1993

году.

своей

статье

он

рассмотрел недостатки реляционной модели,

первую

очередь

невозможность

«объединять,

просматривать

анализировать

данные

точки

зрения

множественности

измерений,

то

есть

самым понятным

для

кор-

поративных

аналитиков

способом»,

определил общие требования

системам

01ЛР,

расширяющим функциональность реляционных СУБД

включающим

многомерный

анализ

как

одну

из

своих характеристик.

Следует заметить,

что

Кодд обозначает

термином

OLAP многомерный способ

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

на

концептуальном уровне. Используе-

мые

им

термины

—

«Многомерное

концептуальное

представление»

(«Multidi-

mensional

conceptual

view»),

«Множественные

измерения

данных»

(«Multiple

data

dimensions»),

«Сервер

OLAP»

(«OLAP

server»)

—

не

определяют физического

механизма

хранения данных (термины

«многомерная

база данных»

«много-

мерная

СУБД»

не

встречаются

ни

разу).

Часто

публикациях

аббревиатурой OLAP

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

не

только многомер-

ный

взгляд

на

данные,

но и

хранение самих данных

многомерной

БД,

что

принципе неверно.

По

Кодду,

многомерное концептуальное представление (multi-dimensional con-

ceptual

view)

является

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

персона-

ла на

объект

управления.

Оно

представляет собой

множественную

перспективу,

состоящую

из

нескольких

независимых

измерений,

вдоль которых могут быть

проанализированы

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

совокупности

данных.

Одновременный

анализ

по

нескольким измерениям

данных

определяется

как

многомерный анализ.

Ка-

ждое

измерение

включает

направления

консолидации данных, состоящие

из се-

рии

последовательных уровней

обобщения,

где

каждый вышестоящий

уровень

соответствует

большей степени агрегации данных

по

соответствующему измере-

нию.

Так, измерение

Исполнитель

может определяться

направлением

консолида-

ции,

состоящим

из

уровней

обобщения

«предприятие—подразделеиие-отдел--

служащий».

Измерение

Время

может даже включать

два

направления

консолида-

ции

«год-квартал-месяц-деиь»

«неделя-день»,

поскольку счет

времени

по

месяцам

к по

неделям несовместим.

этом случае становится

возможным

произвольный

выбор желаемого уровня детализации информации

по

каждому

Перспективы

разаития

БД и

СУБД

297

из

измерений.

Операция спуска (drilling

down)

соответствует

движению

от

выс-

ших

ступеней

консолидации

низшим; напротив, операция подъема (rolling

up)

означает

движение

от

низших

уровней

высшим.

Следующем

новым

направлением

развитии систем управления базами дан-

ных

является

направление,

связанное

отказом

от

нормализации отношений.

Во

многом

нормализация

отношений

нарушает

естественные

иерархические свя-

зи

Между

объектами,

которые

достаточно

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

нашем

мире.

Воз-

можность сохранять

их

на

концептуальном

(но не на

физическом) уровне

по-

зволяет

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

области.

настоящий момент

уже

существует теоретическое обоснование рабо-

ты с

ненормализованными отношениями

практические реализации подобных

систем.

Дальнейшим расширением

структурных преобразованиях являются объектно-

ориентированные

базы

данных.

объектно-ориентированной парадигме пред-

метная

область

моделируется

как

множество классов взаимодействующих объ-

ектов.

Каждый

объект

характеризуется

набором

свойств,

которые

являются

как

бы его

пассивными

характеристиками

набором

методов работы

этим

объек-

том.

Работать

объектом можно только

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

его

методов.

Атрибу-

ты

объекта могут принимать

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

множество допустимых

значений,

набор

конкретных

значений

атрибутов объекта определяет

его

состояние. Используя

методы

работы

объектом,

можно

изменять

значение

его

атрибутов

и тем са-

мым как бы

изменять состояние самого объекта.

Множество

объектов

одним

тем же

набором

атрибутов

методов

образует

класс

объектов.

Объест

должен

принадлежать

только одному классу (если

не

учитывать

возможности

наследо-

вания).

Допускается наличие

примитивных

предопределенных классов,

объек-

ты-экземпляры которых

не

имеют

атрибутов:

целые,

строки

и т, д.

Класс,

объек-

ты

которого

могут

служить

значениями

атрибута объектов другого

класса,

называется

доменом

этого

атрибута.

Одной

из

наиболее

перспективных

черт объектно-ориентированной парадигмы

является

принцип

наследования.

Допускается

порождение

нового

класса

на

основе

уже

существующего класса,

этот процесс называется

наследованием.

этом

случае

новый

класс,

называемый подклассом существующего класса (су-

перкласса), наследует

все

атрибуты

методы

суперкласса.

подклассе, кроме

того, могут быть определены

дополнительные

атрибуты

методы. Различаются

случаи простого

множественного

наследования.

первом случае подкласс

мо-

жет

определяться только

на

основе одного

суперкласса,

во

втором случае супер-

классов

может

быть

несколько,

Если

языке

или

системе

поддерживается

еди-

ничное

наследование

классов,

набор

классов образует

древовидную

иерархию.

При

поддержании

множественного

наследования классы связаны

ориентиро-

ванный

граф

корнем,

называемый решеткой классов. Объект подкласса счита-

ется

принадлежащим любому суперклассу

этого

класса.

Можно

считать,

что

наиболее

важным

качеством

ООБД

(объектно-ориентиро-

ванной базы

данных),

которое позволяет реализовать

объектно-ориентирован-

ный

подход» является учет поведенческого аспекта

объектов,

прикладных

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

системах,

основывавшихся

на БД с

традицион-

ной

организацией (вплоть

до

тех, которые базировались

на

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

моде-

298

—,-,.,-,

Заключение

лях

данных), существовал

принципиальный

разрыв между

структурной

пове-

денческой частями. Структурная часть

системы

поддерживалась всем

аппаратом

БД,

ее

можно было

моделировать,

верифицировать

т. д., а

поведенческая

часть

создавалась изолированно.

частности,

отсутствовали

формальный

аппарат

системная

поддержка

совместного

моделирования

гарантии согласованности

структурной

(статической)

поведенческой

(динамической)

частей.

среде

ООБД

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

разработка

сопровождение

прикладной

системы ста-

новятся процессом,

котором интегрируются структурный

поведенческий

ас-

пекты.

Конечно,

для

этого

нужны

специальные

языки,

позволяющие

определять

объекты

создавать

па их

основе

прикладную

систему.

Специфика

применения"

объектно-ориентированного

подхода

для

организации

управления

БД

потребовала

уточненного

толкования

классических

концеп-

ций

некоторого

их

расширения.

Прежде

всего,

возникло

направление,

которое

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

возможность

хране-

ния

объектов

внутри

реляционной

БД,

тогда дополнительно необходимо

преду-

смотреть

хранение

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

специфических

методов

работы

этими

объектами,

а это в

свою очередь

требует

расширения

стандарта языка SQL. Час-

тично

это

уже

сделано

новом

стандарте

SQL3,

однако

там

далеко

не

все

вопро-

сы

получили однозначное разрешение.

Однако

часть

разработчиков

придерживается

мнения

необходимости

полного

отказа

от

реляционной парадигмы

перехода

на

объектно-ориентированную

парадигму.

Для

перехода

объектно-ориентированным

БД

стандарт объектного

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

был

дополнен

стандартизованными

средствами

доступа

базам

данных

(стандарт

ODMG93).

Поставщики коммерческих

СУБД

немедленно

отреагировали

на эту

потребность.

Практически каждая уважающая себя фирма обратилась

объектным

техноло-

гиям

продуктивно

сотрудничает

разработчиками

объектно-ориентированных

СУБД.

IBM и

Oracle

доработали

свои СУБД

(соответственно,

t>B2

ORACLE),

добавив объектную надстройку

над

реляционным ядром

системы.

Другой

путь

выбрал Informix, который

приобрел

серьезную

объектно-реляционную

СУБД

Illustra

встроил

ее в

свою

СУБД.

результате получился продукт,

именую-

щийся

универсальным

сервером. Другой

лидер

рынка СУБД

Computer

Asso-

ciates,

поступил

иначе.

Он

сделал

ставку

на

чисто

объектную

базу

Jasmine,

ак-

тивно пропагандируя

ее

достоинства.

Кто

прав

—

покажет будущее.

Следующим направлением развития

баз

данных

является

появление

так

называе-

мых

темпоральных

баз

данных,

то

есть

баз

данных,

чувствптелыгых

ко

Бремени.

Фактически

БД

моделирует

состояние

объектов

предметной

области

некото-

рый

текущий

момент

времени.

Однако

ряде

прикладных

областей

необходимо

исследовать

именно

изменение

состояний объектов

во

времени,

Если

использо-

вать

чисто

реляционную

модель,

то

требуется

строить

хранить

дополнительно

множество

отношений,

имеющих

одинаковые

схемы,

отличающиеся

временем

существования

или

снятия

данных. Гораздо

перспективнее

удобнее

для

этого

использовать специальные механизмы

снятия

срезов

по

времени

для

определен-

ных

объектов

БД.

Основной

тезис

темпоральных

систем

состоит

том,

что для

любого объекта

данных)

созданного

момент

времени

уничтоженного

в мо-

мент

времени

t2,

в БД

сохраняются

(и

доступны

пользователям)

все его

состоя-

Перспективы развития

БД и

СУБД

299

пня

но

временном

интервале

[11,

t2).

При

обозначении

интервала

квадратные

скобки означают,

что

граница

интервала

включена

него,

круглые

скобки

означают,

что

точка

па

временной

оси,

соответствующая

границе

интсрпала,

не

включается

интервал.

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

если

объект

уничтожен

момент

вре-

мени

12,

то и

:-л;ой

точке

премсшюн

реп

он уже

не

существует,

поэтому

мы ос-

тавляем

правую

границу

временного

интервала

открытой.

Еще

одним

из

перспективных

направлений

развития

баз

данных

является

на-

правление,

связанное

объедниеинем

технологии

экспертных

систем

баз

дан-

ных

развитие

так

называемых

дедуктивных

баз

данных.

Эти

базы

основаны

на

выявлении

новых

знаний

из

баз

данных

не

путем

запросов

пли

аналитической

обработки,

путем

использования

правил

вывода

построения

цепочек

приме-

нения

этих

правил

для

вывода

ответов

на

запросы,

Для

этих

баз

данных

сущест-

вуют

языки

запросов,

отличные

от

классического

SQL.

экспертных

системах

также знания экспертов хранятся

форме правил, чаще

псего

используются

так

называемые

продукционные

правила

типа

«если

описание

ситуации

то

описа-

ние

действия*.

Хранение

подобных

правил

организация

вывода

на

основании

имеющихся

фактов

иод

силу

современным

СУБД.

наконец,

последним,

но,

может

быть,

самым значительным

направлением

раз-

вития

баз

данных

является

перспектива

взаимодействия

Web-техиологни

и баз

данных. Простота

доступность

Wcb-техпологии,

возможность

свободной

пуб-

ликации

информации

Интернете,

так

чтобы

она

была

доступна

любому

коли-

честву

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

несомненно,

сразу

завоевали

авторитет

большого

числа

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

Однако

процесс

накопления

слабо

структурированной

информа-

ции

быстро проходит

далее наступает момент

обеспечения

эффективного

управ-

ления

этой

разнообразной

информацией.

И это уже

серьезная

проблема.

Неко-

торые

исследователи

даже вывели

определенную

тенденцию,

которая

выражается

том,

что

наиболее