Производительность запросов к хранилищу данных SQL Server 2008 - Логическая структура базы данных: многомерное моделирование
ОГЛАВЛЕНИЕ
Логическая структура базы данных: многомерное моделирование
Транзакционные бизнес-приложения обычно имеют нормализованную схему базы данных. Логическая структура схемы базы данных для реляционных хранилищ данных не так связана с нормализацией. Многие современные структуры реляционных хранилищ данных основаны на подходе многомерного моделирования, который стал популярен после выхода книги Ральфа Кимбалла (Ralph Kimball) и Марджи Росс (Margy Ross) «The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling» (Инструментарий хранилища данных: полное руководство по многомерному моделированию).
Те, кто работает с хранилищами данных, наверняка знакомы с обычными схемами для реляционных хранилищ данных (такие, как «звезда» и «снежинка»). В многомерном моделировании выделяются таблицы измерений и таблицы фактов. Таблицы измерений содержат основные данные (продукты, клиенты, магазины или страны), а таблицы фактов содержат данные транзакций (продажи, заказы, покупки или возвраты).
Таблицы измерений и фактов имеют связь «первичный (PK)-внешний (FK) ключ». Многие хранилища данных не используют ограничения FK для уменьшения требований к объему хранилища. Это спасает от дополнительных затрат на хранение подлежащих индексов и сокращает стоимость поддержания таблицы фактов. Таблицы измерений в хранилище данных обычно небольшие, они содержат в среднем тысячи и до нескольких миллионов строк. Таблицы фактов, с другой стороны, могут быть очень большими и содержать от сотен миллионов до миллиардов строк. Поэтому логическая структура должна уделять особое внимание требованиям таблицы фактов к объему хранилища.
Этот фактор размера влияет на то, какой ключ следует выбрать из таблицы измерений, чтобы поддерживать соотношения таблицы фактов к таблице измерения. Составные ключи, основанные на бизнес-ключе измерения (то есть на реальном идентификаторе объекта, представленного измерением), обычно занимают несколько столбцов. Следует знать, что это проблема для соответствующего внешнего ключа в таблице фактов, потому что составной ключ из нескольких столбцов будет повторяться для каждой строки таблицы фактов.
Чтобы этого не было, для реализации отношений между таблицей фактов и ее измерениями часто применяют маленькие суррогатные ключи. Суррогатный ключ – это столбец идентификаторов типа integer, который служит искусственным первичным ключом таблицы измерения. Большие таблицы фактов, ссылающиеся на маленькие суррогатные ключи, требуют гораздо меньше места. На Рис. 1 показана схема хранилища данных на основе многомерной модели, использующая таблицы фактов и измерений с суррогатными ключами.
Рис. 1 Пример схемы «звезда» с таблицей фактов и двумя таблицами измерений
Схема «снежинка» распространяет одно или несколько измерений на множество уровней (например, клиент, страна и регион для измерения «клиент»), нормализуя большие измерения, которые могут быть перегружены избыточными данными. Уровни представлены отдельными таблицами, поэтому схема похожа на снежинку. Структура схемы «звезда», напротив, не распространяет измерения на таблицы. Эта схема имеет форму звезды, где центром служит таблица фактов, а вокруг нее собраны таблицы измерений.
В схемах "звезда" или «снежинка», смоделированных многомерно, запросы поддержки решения следуют такой типичной последовательности: запрос выбирает несколько нужных мер из таблицы фактов, объединяет строки фактов с одним или несколькими измерениями вместе с суррогатными ключами, размещает предикаты фильтров в бизнес-столбцы таблиц измерений, группирует по одной или нескольким бизнес-столбцам и собирает меры, полученные из таблицы фактов за промежуток времени. Ниже приведена эта последовательность, которую иногда называют «запрос типа ‘звезда’»:
select ProductAlternateKey,
CalendarYear,sum(SalesAmount)
from FactInternetSales Fact
join DimTime
on Fact.OrderDateKey = TimeKey
join DimProduct
on DimProduct.ProductKey =
Fact.ProductKey
where CalendarYear between 2003 and 2004
and ProductAlternateKey like 'BK%'
group by ProductAlternateKey,CalendarYear