Лекция 19. Основные направления развития технологий баз данных




НазваниеЛекция 19. Основные направления развития технологий баз данных
страница3/3
Дата публикации05.06.2013
Размер0.51 Mb.
ТипЛекция
uchebilka.ru > История > Лекция
1   2   3

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

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

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

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

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

^ Обнаружение моделей и зависимостей в наборах данных (Data Mining). Исторически направление data mining направлено на обеспечение эффективных способов обнаружения моделей существующих наборов данных. Эти модели должны раскрывать некоторые полезные аспекты данных, скрывая детали, не являющиеся полезными для приложения. В разных исследовательских сообществах разработаны алгоритмы классификации, кластеризации, выявления ассоциативных правил и обобщения.

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

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

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

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

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

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

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

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

^ Новые пользовательские интерфейсы. В течение многих лет в сообществе баз данных пользовательским интерфейсам уделялось незначительное внимание. Мощность современных настольных компьютеров позволяет запускать на них мощные системы визуализации. Однако остается неясным, как наилучшим образом визуализировать информацию, поступающую из СУБД. Отличные системы визуализации информации – QBE и VisiCalc – были предложены еще в 80-е гг. прошлого века. За последние 15 лет не появилось ничего принципиально нового. Крайне необходимы свежие идеи.

Тридцать лет исследований в области языков запросов сводятся к тому, что «мы двигаемся от SQL к XQuery». В лучшем случае мы переходим от одного декларативного языка к другому, обладающему примерно тем же уровнем выразительности. Конечные пользователи не знают SQL, это язык профессиональных программистов. В родственных сообществах имеются идеи, которые могли бы повлиять на исследования в области интерфейсов к базам данных. Например, в информационно-поисковых системах в течение многих лет используются запросы по ключевым словам, в ряде областей растет популярность браузеров.

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

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

^ Увеличение роли метаданных. Например, для фиксации научных данных требуется сохранение как «родословных» этих данных, так и программ, требуемых для доступа к этим данным. Очень важно наличие метаданных, описывающих контекст, при отсутствии которого даже доступные данные могут быть бесполезными. В целом, человечество нуждается в средствах хранения, поддерживающих неограниченный во времени доступ к данным в полезной форме. Эти средства должны, насколько это возможно, автоматизировать процесс миграции данных из одного формата в другой и/или поддерживать аппаратно-программные механизмы, требующиеся для доступа к данным. Вместе с хранимыми документами должны присутствовать описывающие их метаданные.

^ Оптимизация запросов. Многие участники собрания расценивали оптимизацию запросов как важный элемент решения упомянутых выше проблем. Общий принцип состоит в том, что при наличии очень больших объемов данных мы склонны манипулировать этими данными стандартным образом. Эта стандартность позволяет успешно использовать в мире данных языки очень высокого уровня SQL и XQuery, но больше они почти нигде не применяются. Для языков очень высокого уровня требуются надлежащие оптимизаторы. Нужно продолжать работать в областях оптимизации средств интеграции информации, языков запросов полуструктурированных данных, таких как XQuery, процессоров потоков, сенсорных сетей и т.д.

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

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

19.3 Нереляциооные системы управления базами данных
19.3.1 Посреляционные системы управления базами данных
Рассмотрим основные направления в области исследований и разработок систем управления так называемых постреляционных баз данных. Можно отметить три направления развития СУБД следующего поколения.

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

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

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

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

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

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

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

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

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

С расширением области применения реляционного подхода для решения задач, особенно в направлении CALS-технологий, стало очевидным, что применение принципа нормализации таблиц БД и создание отдельных транзакций и процедур при выполнении различных запросов «сводит на нет» все преимущества нормализованной схемы организации базы данных.

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

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

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

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

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

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

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

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

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

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

Решают эту проблему с помощью компромиссных решений, не выходящих за пределы традиционной технологии производства компиляторов. В основном все они связаны с применением тех или иных инструментальных средств, обеспечивающих автоматизацию построения компиляторов. Такие инструментальные средства имеются, например, в системах DB2, Oracle, Informix.

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

Конечно, можно ввести в хранимые отношения временной атрибут и поддерживать его значения на уровне приложений. В большинстве случаев так и поступают. Так, в стандарте SQL появились специальные типы данных: date и time. Но в таком подходе имеются недостатки: СУБД не знает семантики временного поля отношения и не может контролировать корректность его значений.

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

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

Создание прототипов темпоральных СУБД обычно выполняется на основе некоторой реляционной СУБД в виде надстройки над реляционной системой.
^ 19.3.2 Объектно-ориентированные системы управления базами данных
Создание объектно-ориентированных баз данных (ООБД) началось в середине 1980-х г.г. Наиболее активно ООБД развиваются в последние годы. Правда, необходимо отметить, что начальный оптимизм сменился некоторым снижением интереса к ООБД. Тем не менее, исследования в этом направлении весьма интересны и перспективны. Недаром современные коммерческие серверы баз данных начинают приобретать черты систем управления ООБД.

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

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

В наиболее общей постановке объектно-ориентированный подход базируется на следующих концепциях:

  • объект и идентификатор объекта;

  • атрибут и метод;

  • класс;

  • иерархия и наследование классов.

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

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

Значение атрибута объекта – это тоже некоторый объект или множество объектов. Состояние и поведение инкапсулированы в объекте. Взаимодействуют объекты на основе передачи сообщений и выполнения соответствующих методов.

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

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

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

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

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

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

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

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

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

Второй аспект – потребность в механизме определения разного рода семантических связей между объектами разных классов. Фактически это означает требование полного распространения на ООБД средств семантического моделирования данных. Потребность в использовании абстракции ассоциирования отмечается и в связи с использованием ООБД в сфере автоматизированного проектирования.

Третий аспект связан с пересмотром понятия класса. В контексте ООБД оказывается более удобным рассматривать класс как множество объектов данного типа, т.е. одновременно поддерживать понятия и типа, и класса объектов.

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

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

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

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

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

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

Эта сторона ООБД наиболее близка родственному направлению языков программирования баз данных. Языки программирования ООБД и БД во многом различаются только терминологически; существенным отличием является лишь поддержание в языках ООБД подхода к наследованию классов.

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

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

Одним из первых созданных для реализации объектно-ориентированного и функционального подходов к программированию является язык Лисп. Потребность более эффективной реализации заставляет в качестве основы объектно-ориентированного языка использовать известные языки программирования Basic и Си++.

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

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

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

Второй подход основывается на построении полного логического объектно-ориентированного языка исчисления.

Третий подход основывается на применении декларативного и объектно-ориентированного методов программирования.

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

Основной целью оптимизации запроса в системе ООБД является создание оптимального плана его выполнения с использованием доступа к внешней памяти данной БД.

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

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

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

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

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

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

Общий подход к предоптимизации условий выборки для одного класса объектов может быть следующим:

1) Преобразовать логическую формулу условия выборки в конъюнктивную нормальную форму (КНФ).

2) Для каждого конъюнкта, включающего в себя методы с известным во время компиляции телом, заменить вызовы методов на их тела с подставленными параметрами.

3) Для каждого конъюнкта произвести все возможные упрощения, т.е. вычислить все, что можно вычислить в статике.

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

Указанные ограничения не вызывают зависимости прикладной программы от особенностей реализации ООБД. Это обусловлено тем, что объекты БД могут быть определены семантически.
^ 19.3.3 Системы баз данных, основанные на правилах
В любой базе данных хранится три вида информации:

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

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

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

Информация первого и второго видов в совокупности явно описывает объекты (сущности) реального мира, моделируемые в базе данных. Другими словами, это явные факты, предоставленные пользователями для хранения в БД. Эту часть базы данных принято называть экстенциональной.

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

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

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

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

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

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

Среди вопросов, ответы на которые до сих пор не получены, следующие:

1) Как эффективно определить набор вспомогательных действий, вызываемых прямым действием пользователя?

2) Каким образом распознавать циклы в цепочке «действие–условие–действие–…» и что делать при возникновении таких циклов?

3) В рамках какой транзакции выполнять дополнительные условные действия и к бюджету какого пользователя относить возникающие накладные расходы?

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

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

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

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

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

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

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

Конечно, когда набор правил дедуктивной БД становится большим и их невозможно разместить в оперативной памяти, возникает проблема управления их хранением и доступом к ним во внешней памяти. В этом случае также можно применить реляционную систему, но уже не очень эффективно, так как требуются более сложные структуры данных и другие условия выборки. Известны лишь частные попытки решить эту проблему, но общего решения пока нет.
Информацию по теме лекции можно найти в [10], [13], [20-21], [37], [40].


^

Ключевые термины


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

^ Дедуктивная база данных состоит из двух частей: экстенциональной, содержащей факты, и интенциональной, содержащей правила для логического вывода новых фактов на основе экстенциональной части и запроса пользователя.

^ Объектно-ориентированная база данных основана на объектно-ориентированной модели данных, адаптированной для применения в среде обработки данных.

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


^

Краткие итоги


В лекции рассматривается история развития технологии обработки данных, даются характеристики постреляционным, объектно-ориентированные базам данных, базам данных, основанные на правилах.

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

1 Лекция 4 Базовые понятия реляционной модели данных

2 Лекция 5 Ограничения целостности реляционной модели

3 Лекция 6Основы реляционной алгебры и реляционного исчисления
1   2   3

Похожие:

Лекция 19. Основные направления развития технологий баз данных iconЛекция Введение в теорию баз данных Лекция посвящена рассмотрению...
Цель: выявить основные структурные элементы баз данных и основные принципы, используемые при их разработке

Лекция 19. Основные направления развития технологий баз данных iconЛекция Введение в базы данных
Обсуждается состав пользователей и распределение обязанностей в информационных системах с базами данных. Дается обзор моделей баз...

Лекция 19. Основные направления развития технологий баз данных iconЛекция 1 (2 часа)
Базы данных являются одной из основных составляющих информационных технологий предприятий. В настоящее время без применения баз данных...

Лекция 19. Основные направления развития технологий баз данных icon3. Лекция: Введение в реляционную модель данных Вопросы: Основные понятия реляционных баз данных
Эдгаром Коддом. В последние десятилетия этот подход является наиболее распространенным (с оговоркой, что в называемых в обиходе реляционными...

Лекция 19. Основные направления развития технологий баз данных iconКурс лекций по дисциплине "Организация баз данных"
В настоящем курсе рассматриваются вопросы организации баз данных (БД). Это важная тема, без основательного знакомства с которой,...

Лекция 19. Основные направления развития технологий баз данных iconКурс лекций по дисциплине "Организация баз данных"
В настоящем курсе рассматриваются вопросы организации баз данных (БД). Это важная тема, без основательного знакомства с которой,...

Лекция 19. Основные направления развития технологий баз данных iconЛекция 14 Транзакции и восстановление баз данных
Одним из основных средств восстановления базы данных после сбоев является журнал транзакций. Для восстановления данных с помощью...

Лекция 19. Основные направления развития технологий баз данных icon1. Архитектура баз данных
Архитектура баз данных субд, которые поддерживают реляционную модель данных. Средства субд для создания базы данных и работы с ее...

Лекция 19. Основные направления развития технологий баз данных iconПримерная должностная инструкция главного специалиста администратора...
Администратор баз данных в соответствии с возложенной на него задачей выполняет следующие функции

Лекция 19. Основные направления развития технологий баз данных iconЛекция по основам торговой деятельности Лекция №1 Введение Основные...

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
uchebilka.ru
Главная страница


<