Введение в системы БД (542480), страница 214
Текст из файла (страница 214)
Из сказанного выше должно быть ясно, что проблема обеспечения независимости физических данных — это, в основном, проблема обновления представления поддержки (исключая проблему обновления фрагментов, которая обсуждалась в главе 20 и имеет совсем другой смысл во всей архитектуре системы). Как мы убедились в главе 9, теоретически все реляционные представления обновляемы. Следовательно, теоретически, если физическая схема является производной от логической схемы в смысле, который имелся в виду выше, будет достигнута максимальная физическая независимость данных.
Любое обновление, выраженное в терминах логической схемы, будет автоматически транслируемым в обновление, выраженное в терминах физической схемы, и наоборот, а сами изменения физической схемы не будут требовать изменений в логической схеме. Заивчание. Отметим, что единственной причиной подобных изменений в физической схеме должно быть обеспечение эффективности хранения данных и повышение обшей производительности системы. Однако, к сожалению, современные ЯО).-продукты не поддерживают в необходимой мере обновление представлений.
Поэтому набор допустимых физических схем в этих продуктах очень (и совершенно излишне) ограничен. Говоря конкретнее, если мы на логическом уровне рассматриваем базовые таблицы как представления, а хранимые версии этих "представлений" на физическом уровне — как базовые таблицы, физическая схема должна быть такой, чтобы рассматриваемый продукт мог реализовать все логически возможные обновления таких "представлений" в терминах этих "базовых таблиц".
Замечание. На практике это возможно благодаря моделированию подходящего механизма обновления представления средствами хранимых процедур, триггерных процедур, промежуточного программного обеспечения или различных их сочетаний. Однако обсуждение этих методов выходит за рамки данной главы. Логическое проектирование Правила логического проектирования не зависят от предполагаемого использования базы данных.
То же самое относится ко всем без исключения видам приложений. Следовательно, в частности, должно быть все равно, какими являются эти приложения: оперативными (0(,ТР) или приложениями поддержки принятия решений. В любом случае должна использоваться одна и та же процедура. Еше раз рассмотрим три логические характеристики баз данных поддержки принятия решений, определенные в начале раздела 21.2, а также рассмотрим их следствия лля логического проектирования. ° Использование сочетаний столбцов и уменьшение количества зависимостей В запросах поддержки принятия решений, а также в обновлениях, если они применимы, сочетания столбцов часто рассматриваются как единое целое.
Имеется в виду, что к входящим в состав подобных сочетаний столбцам никогда не обраша- 818 Часть К Дополнительные аспекты ются по отдельности (наглядным примером может служить адрес й008888). Условимся называть такие сочетания столбцов составными столбцами. Но с логической точки зрения подобные составные столбцы ведут себя так, как будто на самом деле они не составные. Прелположим, что СС вЂ” это составной столбец и С— какой-либо иной столбец в той же таблице.
Тогда зависимости между столбцом С и компонентами столбца СС сводятся к одной зависимости между столбцом С и составным столбцом СС как единым целым. Более того, зависимости, включаюшие компоненты составного столбца СС и ие включающие никакие другие столбцы, излишни и могут просто игнорироваться. В результате обшее число зависимостей сокращается и логический проект становится проше, с меньшим количеством столбцов и, возможно, даже с меньшим числом таблиц.
Зачечание. Стоит еше упомянуть о том, что полная и эффективная поддержка составных столбцов — задача нетривиальная и зависит от типов, определенных пользователем. Дополнительный материал по этому вопросу можно найти в 121,111, а также в главах 5 и 25. ° Общие ограничения целостности Как уже объяснялось, базы данных поддержки принятия решений, главным образом, только читаются и ограничения целостности проверяются при загрузке (или обновлении) базы данных.
Поэтому часто полагают, что нет никако~о смысла в объявлении ограничений целостности в логической схеме. Однако это звучит неубедительно. Если база данных действительно лишь читается, такие ограничения на самом деле не могут быть нарушены. Но нельзя недооценивать семантическое значение этих ограничений.
Как уже отмечалось в разделе 8.10 главы 8, ограничения служат для определения смысла таблиц и всей базы данных в целом. Определение ограничений предоставляет способ передачи пользователям смысла данных, а значит, помогает им в формулировании запросов. Кроме того, объявление ограничений может предоставлять критически важную информацию для оптимизатора (см. обсуждение семантической оптимизации в разделе 17.4 главы 17). Замечание. В некоторых БЯЬ-продуктах объявление определенных ограничений приводит к автоматическому созданию соответствуюших индексов н других механизмов обеспечения, что может существенно увеличить стоимость загрузки и пополнения базы данных.
В свою очередь, для проектировшиков это может послужить поводом для отказа от объявлений ограничений. И снова повторим, что зта проблема возникает из-за путаницы между логическими н физическими аспектами проектирования. Должна существовать возможность определить ограничения целостности декларативно, на логическом уровне, и независимо указать соответствующий механизм их обеспечения на физическолг уровне. К сожалению, современные БЯЬ-продукты неудовлетворительно проводят разграничение между логическим и физическим уровнями (более того, разработчики этих продуктов вряд ли осознают семантическое значение ограничений вообше). ° Временные ключи Оперативные базы данных обычно содержат только текущие данные.
Базы данных поддержки принятия решений, наоборот, обычно содержат архивы исторически накопленных данных, и поэтому большая часть или даже все данные включают временной шталт илн временную отметку. Ключи в таких базах данных часто Глава 21. Поддержка принятия решений 819 содержат столбец с подобной отметкой.
Например, вновь обратимся к нашей базе данных поставщиков и деталей. Предположим, что необходимо расширить ее так, чтобы для каждой поставки был известен конкретный месяц (от! до 12), когда поставка производилась. В этом случае таблица поставок ЯР может выглядеть, как показано иа рис. 21.1. Обратите внимание, что дополнительный столбец И1Р (идентификатор месяца) входит в состав ключа расширенной версии таблицы ЯР. Теперь при формулировке запросов, включающих таблицу ЯР, нужно будет учитывать, что данные имеют различные временные отметки (кроме тех случаев, конечно, когда в запросе этого специально не нужно учитывать).
Мы уже коснулись данного вопроса в разделе 21.2, а в главе 22 рассмотрим его более детально. Замечание. В результате добавления столбцов с временными метками может возникнуть необходимость в корректировке проекта базы данных. Предположим, например, хотя это и несколько надуманно, что количество деталей в каждой поставке зависит от месяца, когда эта поставка производилась (на рис. 21.1 данные соответствуют этому ограничению).
Тогда пересмотренная версия таблицы ЯР будет удовлетворять функциональной зависимости М1Р— з Р11, но не будет удовлетворять условиям пятой нормальной формы и даже третьей нормальной формы. Поэтому она должна быть нормализована, как показано на рис. 21.2. К сожалению, проектировщики баз данных поддержки принятия решений редко беспокоятся о том, чтобы учитывать такие вкчючаемые зависимости. Рис.
21.1. Пример таблииы БР, включающей поле идентисрикатора месяиа Физическое проектирование В разделе 21.2 было отмечено, что базы данных поддержки принятия решений, как правило, большие и чрезмерно индексированные, а также часто включают различные виды контролируемой избыточности. В этом подразделе кратко рассматриваются вопросы, касающиеся физического проектирования. агО Часть Р'. Дополнительные аспекты Рис.
21.2. Нормализованный аналог таблицы БР, представленной на рис. 21.! Сначала разберемся в разбиении таблиц на разделы, что иначе называется фрагментацией. Фрагментация представляет собой возможный подход к решению проблемы "больших баз данных". Каждая таблица делится на группу непересекающихся разделов или фрагментов, предназначенных для независимого физического хранения (см. обсуждение вопроса о фрагментации в главе 20). Такое разделение может существенно расширить возможности управления и доступа к данной таблице. Обычно за каждым разделом закрепляются определенные выделенные (в той или иной степени) ресурсы, например диск или процессор, вследствие чего конкуренция между разделами за такие ресурсы минимизируется. Таблицы разделяются горизонтальное с помощью функции разделения, которая использует значения выбранных столбцов, составляющих ключ раздача, в качестве аргументов, а возвращает номер раздела или его адрес.
Такие функции обычно поддерживают разделение по диапазонам (гапйе), кэшированное (Ьазй) разделение, круговое (гоцпд-гоЬ)п) разделение и прочие виды разделения (см. аннотацию к [17.581 в главе 17). Теперь обратимся к индексированию. Известно, что, используя подходящий индекс, можно резко сократить количество физических операций чтения. В ранних 8О)=продуктах предоставлялся лишь один вид индексов, а именно — индексы, представленные в виде В- деревьев, Позже, через несколько лет, стали применяться и некоторые другие виды индексов, особенно в связи с использованием баз данных поддержки принятия решений. Среди них наибольшее распространение получили битовые отображения, кэш-индексы, мультитабпичные»ндексы, булевы индексы, функциональные индексы, а также уже известные нам индексы в виде В-деревьев. Рассмотрим каждый из этих видов индексов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
