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

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

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

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

Замечание. Смысл термина размерность разъясняется в разделе 21.6.

В целях демонстрации предположим, что снова необходимо модифицировать базу данных поставщиков и деталей, на этот раз так, чтобы показать каждую поставку за определенное время, когда эта поставка осуществлялась. Присвоим поставке за определенный период идентификатор iTP и введем еще одну таблицу TP, чтобы связать идентификаторы с соответствующими периодами. Теперь исправленная таблица SP и новая таблица периодов времени будут выглядеть так, как показано на рис. 21.3°. В соответствии с терминологией схем типа звезда таблица поставок SP представляет собой таблицу фактов, а таблица периодов времени TP - таблицу размерностей (также в эту схему входят таблица поставщиков S и таблица деталей Р, как показано на рис. 21.4).

Замечание. Напомним, что общие вопросы обработки данных, представляющих периоды времени, будут подробно рассмотрены в главе 22.

Не имеет ничего общего с каталогами баз данных в современном смысле этого термина. В столбцах FROM и ТО таблицы TP содержатся данные типа временной отметки. Для упрощения на рисунке показаны не реальные значения временных отметок, а символические обозначения.

Puc. 21.3. Пример таблицы фактов (SP) и таблицы размерностей (TP)

S I S# I SNAME I STATUS CITY TP TP# FROM TO \

t t

SP I S# I P# I TP# I QTY

P I P# I PNAME I COLOR [ WEIGHT

CITY

Puc. 21.4. Схема типа звезда для базы данных поставщиков и деталей (с периодами времени)

При обработке запросов в схеме типа звезда таблицы размерности обычно используются для поиска всех необходимых сочетаний внешних ключей, после чего найденные сочетания используются для доступа к таблице фактов. Предположим, что доступ к таблице размерности и соответствующий доступ к таблице фактов связаны в единый запрос. Тогда лучшим способом реализации такого запроса, как правило, является так называемое звездообразное соединение. Звездообразное соединение представляет собой специальную стратегию реализации операции соединения, которая отличается от обычных стратегий тем, что соединение преднамеренно начинается с вычисления декартова произведения, а именно - декартова произведения таблиц размерностей. Как мы уже видели в главе 17, оптимизаторы запросов обычно пытаются избежать вычисления декартова произведения [17.54], [17.55]. Однако в данном случае формирование, в первую очередь, декартова произведения таблиц значительно меньшей размерности, а затем использование результата для просмотра таблицы фактов очень больших размеров с помощью индексов почти всегда эффективнее любой другой стратегии. Поэтому для эффективной обработки запросов в схеме типа звезда традиционные оптимизаторы нуждаются в переработке.

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

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

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

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

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

5. Опять же, из-за отсутствия строгости таблицы размерностей Могут оказаться неоднородными. Такая ошибка обычно возникает, когда таблица фактов используется для размещения данных из разных уровней обобщения. Например, мы могли бы (ошибочно) добавить в таблицу поставок строки, содержащие итоговые количества деталей, поставленных за каждый день, каждый месяц, каждый квартал, каждый год и даже сводный текущий итог. Прежде всего, обратите внимание, что такое изменение приводит к тому, что столбцы идентификатора периода (iTP) и количества (QTY) в таблице SP будут иметь не единообразные значения. Предположим теперь, что столбцы FROM и ТО в таблице размерности TP заменены комбинациями столбцов YEAR, MONTH, DAY и т.д. Тогда все эти столбцы YEAR, MONTH, DAY и др. должны будут допускать NULL-значения. Кроме того, возможно, потребуется также столбец флажка, указывающего тип соответствующего периода времени.