Star-Schema Design [закрыто]
Является ли дизайн Star-Schema необходимым для хранилища данных? Или вы можете сделать хранилище данных с другим шаблоном проектирования?
Ответы на вопрос(8)
я хранилища данных. Как вы туда попали, это другой вопрос. Насколько я знаю, есть два больших лагеря: Билл Инмон и Ральф Кимбалл. Возможно, вы захотите взглянуть на теории этих двух парней, если / когда вы решите пойти со звездой.
Кроме того, некоторым инструментам отчетности действительно нравится настройка схемы «звезда». Если вы привязаны к конкретному инструменту отчетности, это может повлиять на то, как выглядит витрина отчетности на вашем складе.
ых, которая соответствует обычным потребностям хранилищ данных; если дана реляционная среда, схема «звезда» или «снежинка» будет хорошим шаблоном проектирования, встроенным во многие методологии проектирования DW.
Однако существуют и другие механизмы, помимо реляционных баз данных, и они могут использоваться для эффективного хранения данных. Многомерные механизмы хранения могут быть очень быстрыми для задач OLAP (например, TM1); мы не можем применить дизайн схемы звезды в этом случае. Другие примеры, требующие специальных логических моделей, включают базы данных XML или базы данных, ориентированные на столбцы (например, экспериментальныеС-магазин)).
к большим объемам данных. Высокая производительность достигается за счет уменьшения количества объединений, необходимых для удовлетворения любого запроса, который может быть сделан по предметной области. Это достигается за счет обеспечения избыточности данных в таблицах измерений.
Вы должны помнить, что схема «звезда» является шаблоном для верхнего слоя склада. Все модели также включают промежуточные схемы в нижней части стека хранилища, а некоторые также включают постоянную преобразованную объединенную промежуточную область, где все исходные системы объединяются в моделируемую схему 3NF. Различные предметные области сидят выше этого.
Альтернативы звездообразным схемам на верхнем уровне включают в себя вариант, который представляет собой схему снежинки. Новый метод, который также может провести какое-то исследованиеМоделирование хранилища данных предложенный Дэном Линстедтом.
вы усложните себе жизнь - ваша организация захочет использовать стандартные инструменты, расположенные поверх DW, и эти инструменты будут рассчитывать по схеме «звезда» - много усилий будет потрачено на установку квадратного колышка за раунд. отверстие.
Многие оптимизации уровня базы данных предполагают, что у вас есть звездообразная схема; вы потратите много времени на оптимизацию и реструктуризацию, чтобы заставить БД делать «правильные вещи»; с вашим не совсем звездным макетом.
Убедитесь, что плюсы перевешивают минусы ..
(Похоже, я был там раньше?)
-D
where в архитектуре хранилища данныхStar-схема дизайн должен быть применен.
КорочеКимбалл выступает очень высоко за использование только дизайна Star-Schema в хранилище данных, в то время какInmon сначала хочет построить Enterprise Datawarehouse с использованиемнормализованный 3NF дизайн, а затем использовать дизайн Star-Schema в датамарках.
Кроме того, здесь вы также можете сказать, чтоСнежинка дизайн схемы это другой подход.
Четвертый дизайн может бытьМоделирование хранилища данных подход.
1) Как получить данные из операционной исходной системы, не оказывая на них чрезмерного давления, объединяя таблицы внутри и между ними, очищая данные по мере их извлечения, создавая деривации и т. Д.
2) Как объединить данные из разрозненных источников - некоторые унаследованные, некоторые на основе файлов - из разных отделов в единое, точное, эффективно хранимое целое, которое моделирует бизнес и не отражает структуры исходных систем. Помните, что системы меняются / заменяются относительно быстро, но базовая модель бизнеса меняется медленно.
3) Как структурировать данные так, чтобы они максимально быстро и точно отвечали определенным аналитическим требованиям и требованиям к отчетности для конкретных людей / подразделений в бизнесе.
Решение этих трех очень разных проблем требует разных архитектурных слоев для их решения.
Промежуточный слой Мы копируем структуры источников, но каждую ночь загружаются только измененные данные из источников. как только данные взяты из промежуточного слоя на следующий уровень, данные отбрасываются. Запросы представляют собой запросы отдельных таблиц с простым фильтром data_time. Очень мало влияет на источник.
Уровень предприятия Это ориентированная на бизнес база данных третьей нормальной формы. Данные извлекаются (и затем удаляются) из промежуточного уровня на уровень предприятия, где они очищаются, интегрируются и нормализуются.
Слой представления (звездная схема) Здесь мы моделируем в соответствии с конкретными требованиями. Данные намеренно отменяют нормализацию, чтобы уменьшить количество объединений. Иерархии, которые могут занимать несколько таблиц на уровне предприятия, объединены в таблицы с одним измерением, а несколько таблиц транзакций могут быть объединены в таблицы с одним фактом.
Вы всегда сталкиваетесь с этими тремя проблемами. Если вы решите покончить с корпоративным уровнем, вам все равно придется решить вторую проблему, но вы должны сделать это на уровне звездной схемы, и, на мой взгляд, это неправильное место для этого.
звездные схемы для системы хранилища данных вы получаете несколько преимуществ, и в большинстве случаев целесообразно использовать их для верхнего уровня. У вас также может быть хранилище оперативных данных (ODS) - нормализованная структура, которая хранит «текущее состояние». и облегчает такие операции, как конформация данных. Однако существуют разумные ситуации, когда это нежелательно. Я имел возможность создавать системы с уровнями ODS и без них и имел конкретные причины для выбора архитектуры в каждом случае.
Не вдаваясь в тонкости архитектуры хранилища данных или не начав войну против Кимбалла против Инмона, основными преимуществами звездной схемы являются:
Most database management systems have facilities in the query optimiser to do 'Star Transformations' that use Bitmap Index structures or Index Intersection for fast predicate resolution. This means that selection from a star schema can be done without hitting the fact table (which is usually much bigger than the indexes) until the selection is resolved.
Partitioning a star schema is relatively straightforward as only the fact table needs to be partitioned (unless you have some biblically large dimensions). Partition elimination means that the query optimiser can ignore patitions that could not possibly participate in the query results, which saves on I/O.
Slowly changing dimensions are much easier to implement on a star schema than a snowflake.
The schema is easier to understand and tends to involve less joins than a snowflake or E-R schema. Your reporting team will love you for this
Star schemas are much easier to use and (more importantly) make perform well with ad-hoc query tools such as Business Objects or Report Builder. As a developer you have very little control over the SQL generated by these tools so you need to give the query optimiser as much help as possible. Star schemas give the query optimiser relatively little opportunity to get it wrong.
Как правило, ваш уровень отчетности будет использовать звездообразные схемы, если у вас нет особых причин не делать этого. Если у вас есть несколько исходных систем, вы можете реализоватьОперативное хранилище данных с нормализованной или снежинкой схемой для накопления данных. Это проще, потому что ODS обычно не делает историю. Историческое состояние отслеживается в звездных схемах, где это сделать гораздо проще, чем с нормализованными структурами. Нормализованное или «снежное» хранилище оперативных данных отражает «текущие» показатели. состояние и не имеет исторического представления сверх любого, что присуще данным.
Процессы загрузки ODS связаны с очисткой и согласованием данных, что проще сделать с нормализованной структурой. Как только вы получите чистые данные в ODS, измерения и загрузки фактов могут отслеживать историю (изменения во времени) с помощью общих или относительно простых механизмов относительно просто; это гораздо проще сделать со звездообразной схемой. Многие инструменты ETL (например) предоставляют встроенные средства для медленно меняющихся измерений, а реализация универсального механизма относительно проста.
Расслоение системы таким образом обеспечивает разделение обязанностей - логика очистки бизнеса и данных рассматривается в ODS, а загрузка схемы типа «звезда» связана с историческим состоянием.
то они являются естественной моделью для тех вещей, которые большинство людей хотят делать с хранилищем данных. Например, легко создавать отчеты с разной степенью детализации (например, месяц, день или год). Кроме того, эффективно вставлять типичные бизнес-данные в схему типа «звезда», что также является распространенной и важной особенностью хранилища данных.
Вы, конечно, можете использовать любую базу данных, какую захотите, но если вы не очень хорошо знаете свой бизнес-домен, вполне вероятно, что ваши отчеты не будут работать так же эффективно, как если бы вы использовали звездообразную схему.