Дизайн звездной схемы

Ответ 1

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

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

• Большинство систем управления базами данных иметь средства в оптимизаторе запросов сделать "Звездные трансформации", которые используйте Структура Bitmap или Пересечение индексов для быстрого предикатное разрешение. Это означает, что выбор из звездной схемы может быть выполнен без попадания таблицы фактов (которая обычно намного больше, чем индексы), пока выбор не будет разрешен.

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

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

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

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

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

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

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

Ответ 2

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

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

Кроме того, здесь вы также можете сказать, что схема схемы снежинок - это еще один подход.

Четвертым дизайном может быть подход Data Vault Modeling.

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

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

(Звучит ли так, будто я был там раньше?)

-D

Ответ 8

Мы должны решить три проблемы.

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

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

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

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

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

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

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

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