Star-Schema Design

Использование звездообразных схем для системы хранилища данных дает вам несколько преимуществ, и в большинстве случаев целесообразно использовать их для верхнего слоя. У вас также может быть оперативное хранилище данных (ODS) - нормализованная структура, которая содержит «текущее состояние» и облегчает такие операции, как подтверждение данных. Однако есть разумные ситуации, когда это нежелательно. Мне приходилось создавать системы со слоями ODS и без них, и в каждом случае у меня были определенные причины для выбора архитектуры.

Если не вдаваться в тонкости архитектуры хранилища данных и не начинать войну между Кимбаллом и Инмоном, главные преимущества звездообразной схемы:

• В большинстве систем управления базами данных есть средства в оптимизаторе запросов для выполнения «звездообразных преобразований», которые используют структуры Bitmap Index. или Index Intersection для быстрого разрешения предикатов. Это означает, что выбор из звездообразной схемы может выполняться без обращения к таблице фактов (которая обычно намного больше, чем индексы), пока выбор не будет разрешен.

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

• Медленно меняющиеся размеры гораздо проще реализовать в схеме "звезда", чем в снежинке.

• Схема легче для понимания и, как правило, включает меньше объединений, чем снежинка или схема E-R. Ваша команда по отчетности будет любить вас за это

• Звездные схемы намного проще в использовании и (что еще более важно) хорошо работают с инструментами специальных запросов, такими как Business Objects или Report Builder. Как разработчик, у вас очень мало контроля над SQL, сгенерированным этими инструментами, поэтому вам нужно как можно больше помочь оптимизатору запросов. Звездообразные схемы дают оптимизатору запросов относительно небольшую возможность ошибиться.

Обычно ваш уровень отчетности использует звездообразные схемы, если у вас нет особой причины не делать этого. Если у вас есть несколько исходных систем, вы можете реализовать Оперативное хранилище данных с нормализованной схемой или схемой снежинки для накопления данных. Это проще, потому что ODS обычно не ведет историю. Историческое состояние отслеживается в звездообразных схемах, где это намного проще сделать, чем с нормализованными структурами. Нормализованное или «снежное» хранилище операционных данных отражает «текущее» состояние и не содержит исторического обзора сверх того, что присуще данным.

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

Такое многоуровневое распределение системы обеспечивает разделение ответственности - бизнес-логика и логика очистки данных обрабатываются в ODS, а загрузки звездообразной схемы имеют дело с историческим состоянием.

В литературе по хранилищам данных продолжаются споры о том, где в архитектуре хранилища данных Следует применить дизайн Star-Schema.

Короче говоря, Кимбалл очень сильно выступает за использование в хранилище данных только схемы «звезда», в то время как Inmon сначала хочет создать Enterprise Datawarehouse, используя нормализованный 3NF, а затем использовать дизайн Star-Schema в картах данных.

В дополнение к этому вы также можете сказать, что дизайн схемы снежинки - это еще один подход.

Четвертым вариантом может быть подход моделирования хранилища данных.

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

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

Альтернативы звездным схемам на верхнем уровне включают вариант, который представляет собой схему «снежинка». Новый метод, который также может подтвердить некоторые исследования, - это Моделирование хранилища данных, предложенное Дэном Линстедтом.

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

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

Звездообразные схемы естественным образом подходят для последнего уровня хранилища данных. Как вы попали, возникает другой вопрос. Насколько я знаю, есть два больших лагеря: Билла Инмона и Ральфа Кимбалла. Возможно, вам захочется взглянуть на теории этих двух парней, если / когда вы решите пойти со звездой.

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

Схема «звезда» - это логическая модель данных для реляционных баз данных, которая соответствует обычным потребностям хранилищ данных; Если задана реляционная среда, хорошим шаблоном проектирования будет схема «звезда» или «снежинка», встроенная во многие методологии проектирования DW.

Однако существуют и другие механизмы, помимо реляционных баз данных, и их можно использовать для эффективного хранения данных. Механизмы многомерного хранения могут быть очень быстрыми для задач OLAP (например, TM1); в этом случае мы не можем применить дизайн звездообразной схемы. Другие примеры, требующие специальных логических моделей, включают базы данных XML или базы данных, ориентированные на столбцы (например, экспериментальный C-store )).

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

Многие оптимизации на уровне базы данных предполагают наличие звездообразной схемы; вы потратите много времени на оптимизацию и реструктуризацию, чтобы заставить БД делать «правильные вещи» с вашим не совсем звездным макетом.

Убедитесь, что плюсы перевешивают минусы.

(Похоже, я был там раньше?)

-D

Нам нужно решить три проблемы.

1) Как получить данные из операционной исходной системы, не оказывая на них чрезмерного давления, путем объединения таблиц внутри и между ними, очистки данных по мере извлечения, создания производных и т. Д.

2) Как объединить данные из разрозненных источников - некоторые унаследованные, некоторые на основе файлов, из разных отделов в единое, точное, эффективно хранимое целое, которое моделирует бизнес и не отражает структуры исходных систем. Помните, что системы меняются / заменяются относительно быстро, но базовая модель бизнеса меняется медленно.

3) Как максимально быстро и точно структурировать данные в соответствии с конкретными аналитическими требованиями и требованиями к отчетности для конкретных людей / отделов бизнеса.

Решение этих трех очень разных проблем требует различных архитектурных уровней для их решения.

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

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

Уровень представления (звездообразная схема) Здесь мы моделируем размерно для удовлетворения конкретных требований. Данные намеренно денормализованы, чтобы уменьшить количество объединений. Иерархии, которые могут занимать несколько таблиц на уровне предприятия, сворачиваются в таблицы с одним измерением, а несколько таблиц транзакций могут быть объединены в отдельные таблицы фактов.

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