Database Programming & Design

       

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


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

  • Преобразование запросов: Оптимизатор запросов должен быть в состоянии переформулировать запрос для использования материализованных представлений, когда это выгодною
  • Поддержка представлений: Система должна автоматически обновлять все необходимые материализованные представления при каждом обновлении базовых таблиц.
  • До сих пор наша работа над материализованными представлениями фокусировалась на проблеме преобразования запросов. В большинстве предыдущих работ по поводу преобразования запросов делалось несколько упрощающих предположений: запросы и представления только категории "проекция-селекция-соединение" (Project-Select-Join - PSJ), семантика множеств (а не мультимножеств), никакого знания ограничений (таких как ключи и внешние ключи), вычисление запросов на одном представлении. В настоящее время мы имеем работающий прототип системы преобразования запросов, который справляется с более широким классом запросов и представлений (проекция-селекция-соединение-группирование) с обычной семантикой SQL, использует знания о ключах и внешних ключах, берется за преобразования запросов на нескольких представлениях. Мультимножественная семантика SQL добавляет новое измерение в проблему преобразования запросов, поскольку мы должны быть уверены не только в получении всех требуемых строк, но и в том, что будет правильно учтен фактор дубликации.

    Принятие во внимание знаний о ключах и внешних ключах оказалось очень важным, но также и поразительно сложным. Рассмотрим две таблицы - Orders и Customers, где таблица Orders содержит внешний ключ CustomerNo, в котором запрещены неопределенные значения и который ссылается на первичный ключ таблицы Customers.
    Предположим, что имеется представление, получаемое (естественным) соединением Orders и Customers, и что задается запрос, адресуемый к таблице Orders. Без знаний о ключах и внешних ключах мы могли бы заключить, что запрос не может быть выполнен с применением представления. (Поскольку операция естественного соединения в языке SQL по определению отсекает строки с неопределенными значениями столбца соединения и устраняет в результате дубликаты. Прим. С.Кузнецова.) Принимая во внимание внешние ключи, мы можем заключить, что в представлении присутствуют все требуемые строки, но, возможно, без учета фактора дублирования. Для гарантирования того, что фактор дублирования учитывается корректно, мы должны принять во внимание, одним из столбцов соединения является первичный ключ.

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


    Содержание раздела