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

Из сказанного выше должно быть ясно, что проблема обеспечения независимости физических данных- это, в основном, проблема обновления представления поддержки (исключая проблему обновления фрагментов, которая обсуждалась в главе 20 и имеет совсем другой смысл во всей архитектуре системы). Как мы убедились в главе 9, теоретически все реляционные представления обновляемы. Следовательно, теоретически, если физическая схема является производной от логической схемы в смысле, который имелся в виду выше, будет достигнута максимальная физическая независимость данных. Любое обновление, выраженное в терминах логической схемы, будет автоматически транслируемым в обновление, выраженное в терминах физической схемы, и наоборот, а сами изменения физической схемы не будут требовать изменений в логической схеме.

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

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

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

Логическое проектирование

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

Использование сочетаний столбцов и уменьшение количества зависимостей

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

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

Замечание. Стоит еще упомянуть о том, что полная и эффективная поддержка составных столбцов- задача нетривиальная и зависит от типов, определенных пользователем. Дополнительный материал по этому вопросу можно найти в [21.11], а также в главах 5 и 25.

Общие ограничения целостности

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

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

Временные ключи

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

содержат столбец с подобной отметкой. Например, вновь обратимся к нашей базе данных поставщиков и деталей. Предположим, что необходимо расширить ее так, чтобы для каждой поставки был известен конкретный месяц (от 1 до 12), когда поставка производилась. В этом случае таблица поставок SP может выглядеть, как показано на рис. 21.1. Обратите внимание, что дополнительный столбец MID (идентификатор месяца) входит в состав ключа расширенной версии таблицы SP. Теперь при формулировке запросов, включающих таблицу SP, нужно будет учитывать, что данные имеют различные временные отметки (кроме тех случаев, конечно, когда в запросе этого специально не нужно учитывать). Мы уже коснулись данного вопроса в разделе 21.2, а в главе 22 рассмотрим его более детально.

Замечание. В результате добавления столбцов с временными метками может возникнуть необходимость в корректировке проекта базы данных. Предположим, например, хотя это и несколько надуманно, что количество деталей в каждой поставке зависит от месяца, когда эта поставка производилась (на рис. 21.1 данные соответствуют этому ограничению). Тогда пересмотренная версия таблицы SP будет удовлетворять функциональной зависимости MID -> QTY, но не будет удовлетворять условиям пятой нормальной формы и даже третьей нормальной формы. Поэтому она должна быть нормализована, как показано на рис. 21.2. К сожалению, проектировщики баз данных поддержки принятия решений редко беспокоятся о том, чтобы учитывать такие включаемые зависимости.

Рис. 21.1. Пример таблицы SP, включающей поле идентификатора месяца

Физическое проектирование

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