Современные направления изследваий и разработок

21.1. Ориентация на расширенную релационную модель

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

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

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

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

21.2. Абстрактные типы от данни

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

Заметим, что в середине 1995 г. компания Sun Microsystems объявила о выпуске нового продукта - езика и семейства интерпретаторов под названием Java. Език Java является расширенным подмножеством езика Си++. Основные изменения касаются того, что език является пооператорно интерпретируемым (в стиле езика Бейсик), а програмы, написанные на езике Java, гарантированно безопасны (в частности, при изпълнении любой програмы не може да бъде поврежден интерпретатор). За этого, в частности, из езика удалена арифметика над указателями. В то же время Java остается мощным обектно-ориентированным езиком, включающим развитые средства определения абстрактных типов от данни. Компания Sun продвигает език Java с целью расширения възможностей службы Всемирной Паутины (World Wide Web) Internet (основная идея състои в том, что из сървъра WWW в клиенты передаются не данные, а обекти, методы които запрограмированы на езике Java и интерпретируются на стороне клиента; этот подход, в частности, решает проблему нестандартизованного представления мультимедийной информации). Однако, как кажется, интерпретируемый и безопасный език типа Java може да бъде успешно применен и в системах баз от данни, допускающих хранение от данни с типами, определенными потребителями.

21.3. Генерация систем баз от данни, ориентированных на приложения

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

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

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

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

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

21.4. Оптимизация заявките, управляемая правилами

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

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

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

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

Однако наиболее революционный подход среди известных автору был применен в экспериментальной пострелационной системе компании IBM Starburst. В някоиом смысле этот подход является развитием идеи Столлмана, примененной при реализации широко популярного редактора Emacs. Напомним, что в основе этого редактора лежит интерпретатор расширенного диалекта езика Common Lisp. Сам этот интерпретатор написан на езике Си, а основная часть редактора написана на езике Лисп. Это позволяет, среди прочего, добавлять в редактор новые възможности, не покидая его среды: вы просто пишете новый текст на Лиспе и объявляете съответствующую функцию подключенной к редактору.

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

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

21.5. Поддержка исторической информации и темпоральных заявките

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

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

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

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

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

Главными особенностями системы управления паметью в Postgres являются, во-первых, то, что в ней не ведется обычная журнализация изменений базы от данни и мгновенно обеспечивается коректное состояние базы от данни после переизвикванеа системы с утратой состояния оперативной памети. Во-вторых, система управления паметью поддържа исторические данные. Заявки могут съдържать временные характеристики интересующих обектов. Реализационно эти два аспекта свързаны.

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

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

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

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

Каталог: tadmin -> upload -> storage
storage -> Литература на факта. Аналитизъм. Интерпретативни стратегии. Въпроси и задачи
storage -> Лекция №2 Същност на цифровите изображения Въпрос. Основни положения от теория на сигналите
storage -> Лекция 5 система за вторична радиолокация
storage -> Толерантност и етничност в медийния дискурс
storage -> Ethnicity and tolerance in media discourse revisited Desislava St. Cheshmedzhieva-Stoycheva abstract
storage -> Тест №1 Отбележете невярното твърдение за подчертаните думи
storage -> Лекции по Въведение в статистиката
storage -> Търсене на живот във вселената увод
storage -> Еп. Константинови четения – 2010 г някои аспекти на концептуализация на богатството в руски и турски език

Изтегляне 1.71 Mb.

Сподели с приятели: