Добавить на Яндекс
Нравится
Доп-инфо
Home » Misc » Звезда снежинка

Звезда снежинка


12) Схема звезд и снежинок

Что такое многомерная схема?

Многомерная схема специально разработана для моделирования систем хранилищ данных. Схемы предназначены для удовлетворения уникальных потребностей очень больших баз данных, разработанных для аналитических целей (OLAP).

Типы схем хранилища данных:

Ниже приведены 3 основных типа многомерных схем, каждая из которых имеет свои уникальные преимущества.

  • Схема звезды
  • Снежинка Схема
  • Галактика Схема

В этом уроке вы узнаете больше о

  • Что такое схема звезды?
  • Что такое схема снежинка?
  • Схема «звезда против снежинки»: основные отличия
  • Что такое схема Galaxy?
  • Что такое схема звездного кластера?

Что такое схема звезды?

В схеме STAR центр звезды может иметь одну таблицу фактов и несколько связанных таблиц измерений. Это известно как схема звезды, поскольку ее структура напоминает звезду. Схема «звезда» – это самый простой тип схемы хранилища данных. Он также известен как схема соединения звездой и оптимизирован для запросов больших наборов данных.

В следующем примере таблица фактов находится в центре, которая содержит ключи для каждой таблицы измерений, такие как Dealer_ID, ID модели, Date_ID, Product_ID, Branch_ID и другие атрибуты, такие как проданные единицы и доход.

Пример схемы звезды

Характеристики схемы звезды:

  • Каждое измерение в звездообразной схеме представлено единственной одномерной таблицей.
  • Таблица измерений должна содержать набор атрибутов.
  • Таблица измерений присоединяется к таблице фактов с помощью внешнего ключа
  • Таблица измерений не соединена друг с другом
  • Таблица фактов будет содержать ключ и меру
  • Схема Star проста для понимания и обеспечивает оптимальное использование диска.
  • Таблицы измерений не нормализованы . Например, на приведенном выше рисунке Country_ID не имеет таблицы поиска Country, как было бы в проекте OLTP.
  • Схема широко поддерживается BI Tools

Что такое схема снежинка?

SCHEMA SNOWFLAKE – это логическое расположение таблиц в многомерной базе данных, так что диаграмма ER напоминает форму снежинки. Схема «Снежинка» является расширением схемы «Звезда» и добавляет дополнительные измерения. Таблицы измерений нормализуются, что разбивает данные на дополнительные таблицы.

В следующем примере Страна далее нормализуется в отдельную таблицу.

Пример схемы снежинки

Характеристики схемы «Снежинка»:

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

Схема «звезда против снежинки»: основные отличия

Схема звезды Схема снежных хлопьев
Иерархии для измерений хранятся в таблице измерений. Иерархии разделены на отдельные таблицы.
Он содержит таблицу фактов, окруженную таблицами измерений. Одна таблица фактов, окруженная таблицей измерений, которая в свою очередь окружена таблицей измерений
В схеме типа «звезда» только одно соединение создает связь между таблицей фактов и любыми таблицами измерений. Схема снежинки требует много соединений для извлечения данных.
Простой дизайн БД. Очень сложный дизайн БД.
Денормализованная структура данных и запрос также выполняются быстрее. Нормализованная структура данных.
Высокий уровень избыточности данных Очень низкоуровневая избыточность данных
Таблица одного измерения содержит агрегированные данные. Данные разбиты на разные таблицы измерений.
Обработка куба происходит быстрее. Обработка куба может быть медленной из-за сложного соединения.
Предлагает более эффективные запросы, используя Star Join Query Optimization. Таблицы могут быть связаны с несколькими измерениями. Схема снежных хлопьев представлена ​​централизованной таблицей фактов, которая вряд ли связана с несколькими измерениями.

Что такое схема Galaxy?

GALAXY SCHEMA содержит два факта таблицы , что таблицы измерений доли между ними. Это также называется Схема Созвездия Фактов. Схема рассматривается как набор звезд, отсюда и название Galaxy Schema.

Пример галактической схемы

Как вы можете видеть в приведенном выше примере, есть две таблицы фактов

  1. доходов
  2. Товар.

В общих схемах Galaxy размеры измерений называются Conformed Dimensions.

Характеристики галактической схемы:

  • Измерения в этой схеме разделены на отдельные измерения на основе различных уровней иерархии.
  • Например, если география имеет четыре уровня иерархии, таких как регион, страна, штат и город, то схема Galaxy должна иметь четыре измерения.
  • Более того, можно построить схему такого типа, разбив схему с одной звездой на несколько схем типа Star.
  • Размеры в этой схеме велики, что необходимо для построения на основе уровней иерархии.
  • Эта схема полезна для объединения таблиц фактов для лучшего понимания.

Что такое схема звездного кластера?

Схема снежинки содержит полностью расширенные иерархии. Однако это может усложнить схему и потребует дополнительных объединений. С другой стороны, схема «звезда» содержит полностью свернутые иерархии, что может привести к избыточности. Таким образом, лучшим решением может быть баланс между этими двумя схемами, который представляет собой проект STAR CLUSTER SCHEMA .

Пример схемы звездного скопления

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

Резюме:

  • Многомерная схема специально разработана для моделирования систем хранилищ данных
  • Схема «звезда» – это самый простой тип схемы хранилища данных. Это известно как схема звезды, поскольку ее структура напоминает звезду.
  • Схема «Снежинка» является расширением схемы «Звезда» и добавляет дополнительные измерения. Это называется снежинка, потому что ее схема напоминает снежинку.
  • В звездообразной схеме только одно соединение определяет связь между таблицей фактов и любыми таблицами измерений.
  • Звездная схема содержит таблицу фактов, окруженную таблицами измерений.
  • Схема снежных хлопьев окружена таблицей измерений, которые в свою очередь окружены таблицей измерений
  • Схема снежинки требует много соединений для извлечения данных.
  • Схема галактики содержит две таблицы фактов, которые совместно используют таблицы измерений. Это также называется Схема Созвездия Фактов.
  • Схема звездного кластера содержит атрибуты схемы запуска и медленной схемы.

 

традиционная и облачная / Хабр

Привет, Хабр! На тему архитектуры хранилищ данных написано немало, но так лаконично и емко как в статье, на которую я случайно натолкнулся, еще не встречал.

Предлагаю и вам познакомиться с данной статьей в моем переводе. Комментарии и дополнения только приветствуются!

(Источник картинки)

Введение

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

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

Компании все чаще переходят на облачные хранилища данных вместо традиционных локальных систем. Облачные хранилища данных имеют ряд отличий от традиционных хранилищ:

  • Нет необходимости покупать физическое оборудование;
  • Облачные хранилища данных быстрее и дешевле настроить и масштабировать;
  • Облачные хранилища данных обычно могут выполнять сложные аналитические запросы гораздо быстрее, потому что они используют массовую параллельную обработку.

Традиционная архитектура хранилища данных

Следующие концепции освещают некоторые из устоявшихся идей и принципов проектирования, используемых для создания традиционных хранилищ данных.

Трехуровневая архитектура

Довольно часто традиционная архитектура хранилища данных имеет трехуровневую структуру, состоящую из следующих уровней:

  • Нижний уровень: этот уровень содержит сервер базы данных, используемый для извлечения данных из множества различных источников, например, из транзакционных баз данных, используемых для интерфейсных приложений.
  • Средний уровень: средний уровень содержит сервер OLAP, который преобразует данные в структуру, лучше подходящую для анализа и сложных запросов. Сервер OLAP может работать двумя способами: либо в качестве расширенной системы управления реляционными базами данных, которая отображает операции над многомерными данными в стандартные реляционные операции (Relational OLAP), либо с использованием многомерной модели OLAP, которая непосредственно реализует многомерные данные и операции.
  • Верхний уровень: верхний уровень — это уровень клиента. Этот уровень содержит инструменты, используемые для высокоуровневого анализа данных, создания отчетов и анализа данных.


Kimball vs. Inmon

Два пионера хранилищ данных: Билл Инмон и Ральф Кимбалл предлагают разные подходы к проектированию.

Подход Ральфа Кимбалла основывается на важности витрин данных, которые являются хранилищами данных, принадлежащих конкретным направлениям бизнеса. Хранилище данных — это просто сочетание различных витрин данных, которые облегчают отчетность и анализ. Проект хранилища данных по принципу Кимбалла использует подход «снизу вверх».

Подход Билла Инмона основывается на том, что хранилище данных является централизованным хранилищем всех корпоративных данных. При таком подходе организация сначала создает нормализованную модель хранилища данных. Затем создаются витрины размерных данных на основе модели хранилища. Это известно как нисходящий подход к хранилищу данных.

Модели хранилищ данных

В традиционной архитектуре существует три общих модели хранилищ данных: виртуальное хранилище, витрина данных и корпоративное хранилище данных:

  • Виртуальное хранилище данных — это набор отдельных баз данных, которые можно использовать совместно, чтобы пользователь мог эффективно получать доступ ко всем данным, как если бы они хранились в одном хранилище данных;
  • Модель витрины данных используется для отчетности и анализа конкретных бизнес-линий. В этой модели хранилища – агрегированные данные из ряда исходных систем, относящихся к конкретной бизнес-сфере, такой как продажи или финансы;
  • Модель корпоративного хранилища данных предполагает хранение агрегированных данных, охватывающих всю организацию. Эта модель рассматривает хранилище данных как сердце информационной системы предприятия с интегрированными данными всех бизнес-единиц

Звезда vs. Снежинка

Схемы «звезда» и «снежинка» — это два способа структурировать хранилище данных.

Схема типа «звезда» имеет централизованное хранилище данных, которое хранится в таблице фактов. Схема разбивает таблицу фактов на ряд денормализованных таблиц измерений. Таблица фактов содержит агрегированные данные, которые будут использоваться для составления отчетов, а таблица измерений описывает хранимые данные.

Денормализованные проекты менее сложны, потому что данные сгруппированы. Таблица фактов использует только одну ссылку для присоединения к каждой таблице измерений. Более простая конструкция звездообразной схемы значительно упрощает написание сложных запросов.

Схема типа «снежинка» отличается тем, что использует нормализованные данные. Нормализация означает эффективную организацию данных так, чтобы все зависимости данных были определены, и каждая таблица содержала минимум избыточности. Таким образом, отдельные таблицы измерений разветвляются на отдельные таблицы измерений.

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


ETL vs. ELT

ETL и ELT — два разных способа загрузки данных в хранилище.

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

В случае ELT (Extract, Load, Transform) данные сразу же загружаются после извлечения из исходных пулов данных. Промежуточная база данных отсутствует, что означает, что данные немедленно загружаются в единый централизованный репозиторий.
Данные преобразуются в системе хранилища данных для использования с инструментами бизнес-аналитики и аналитики.


Организационная зрелость

Структура хранилища данных организации также зависит от его текущей ситуации и потребностей.

Базовая структура позволяет конечным пользователям хранилища напрямую получать доступ к сводным данным, полученным из исходных систем, создавать отчеты и анализировать эти данные. Эта структура полезна для случаев, когда источники данных происходят из одних и тех же типов систем баз данных.

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

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

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


Новые архитектуры хранилищ данных

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

В этом разделе кратко описываются архитектуры, используемые двумя наиболее популярными облачными хранилищами: Amazon Redshift и Google BigQuery.

Amazon Redshift

Amazon Redshift — это облачное представление традиционного хранилища данных.

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

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

Redshift использует архитектуру MPP (Massively Parallel Processing), разбивая большие наборы данных на куски, которые назначаются слайсам в каждом узле. Запросы выполняются быстрее, потому что вычислительные узлы обрабатывают запросы в каждом слайсе одновременно. Узел Leader Node объединяет результаты и возвращает их клиентскому приложению.

Клиентские приложения, такие как BI и аналитические инструменты, могут напрямую подключаться к Redshift с использованием драйверов PostgreSQL JDBC и ODBC с открытым исходным кодом. Таким образом, аналитики могут выполнять свои задачи непосредственно на данных Redshift.

Redshift может загружать только структурированные данные. Можно загружать данные в Redshift с использованием предварительно интегрированных систем, включая Amazon S3 и DynamoDB, путем передачи данных с любого локального хоста с подключением SSH или путем интеграции других источников данных с помощью API Redshift.

Google BigQuery

Архитектура BigQuery не требует сервера, а это означает, что Google динамически управляет распределением ресурсов компьютера. Поэтому все решения по управлению ресурсами скрыты от пользователя.

BigQuery позволяет клиентам загружать данные из Google Cloud Storage и других читаемых источников данных. Альтернативным вариантом является потоковая передача данных, что позволяет разработчикам добавлять данные в хранилище данных в режиме реального времени, строка за строкой, когда они становятся доступными.

BigQuery использует механизм выполнения запросов под названием Dremel, который может сканировать миллиарды строк данных всего за несколько секунд. Dremel использует массивно параллельные запросы для сканирования данных в базовой системе управления файлами Colossus. Colossus распределяет файлы на куски по 64 мегабайта среди множества вычислительных ресурсов, называемых узлами, которые сгруппированы в кластеры.
Dremel использует колоночную структуру данных, аналогичную Redshift. Древовидная архитектура отправляет запросы тысячам машин за считанные секунды.

Для выполнения запросов к данным используются простые команды SQL.

Panoply

Panoply обеспечивает комплексное управление данными как услуга. Его уникальная самооптимизирующаяся архитектура использует машинное обучение и обработку естественного языка (NLP) для моделирования и рационализации передачи данных от источника к анализу, сокращая время от данных до значения как можно ближе к нулю.

Интеллектуальная инфраструктура данных Panoply включает в себя следующие функции:

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


По ту сторону облачных хранилищ данных

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

  • Загрузка данных в облачные хранилища данных нетривиальна, а для крупномасштабных конвейеров данных требуется настройка, тестирование и поддержка процесса ETL. Эта часть процесса обычно выполняется сторонними инструментами;
  • Обновления, вставки и удаления могут быть сложными и должны выполняться осторожно, чтобы не допустить снижения производительности запросов;
  • С полуструктурированными данными трудно иметь дело — их необходимо нормализовать в формате реляционной базы данных, что требует автоматизации больших потоков данных;
  • Вложенные структуры обычно не поддерживаются в облачных хранилищах данных. Вам необходимо преобразовать вложенные таблицы в форматы, понятные хранилищу данных;
  • Оптимизация кластера. Существуют различные варианты настройки кластера Redshift для запуска ваших рабочих нагрузок. Различные рабочие нагрузки, наборы данных или даже различные типы запросов могут потребовать иной настройки. Для достижения оптимальной работы, необходимо постоянно пересматривать и при необходимости дополнительно настраивать конфигурацию;
  • Оптимизация запросов — пользовательские запросы могут не соответствовать передовым методам и, следовательно, будут выполняться намного дольше. Вы можете работать с пользователями или автоматизированными клиентскими приложениями для оптимизации запросов, чтобы хранилище данных могло работать так, как ожидалось
  • Резервное копирование и восстановление — несмотря на то, что поставщики хранилищ данных предоставляют множество возможностей для резервного копирования ваших данных, их нетривиально настроить и они требуют мониторинга и пристального внимания

Ссылка на оригинальный текст: panoply. io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud

Схема

Star и схема Snowflake — разница между ними

Автор: Дэвид Тейлор

Часов

Обновлено

Ключевое различие между схемой «звезда» и схемой «снежинка»
  • Схема «звезда» — это простейший тип схемы хранилища данных. Она известна как схема звезды, поскольку ее структура напоминает звезду.
  • При сравнении схемы «Снежинка» и «Звезда» схема «Снежинка» является расширением схемы «Звезда» и добавляет дополнительные измерения. Он называется снежинкой, потому что его схема напоминает снежинку.
  • В звездообразной схеме только одно соединение определяет отношение между таблицей фактов и любыми таблицами измерений.
  • Схема "звезда" содержит таблицу фактов, окруженную таблицами измерений.
  • Схема снежинки окружена таблицей измерений, которая, в свою очередь, окружена таблицей измерений
  • Схема "снежинка" требует много соединений для выборки данных.
  • При сравнении схемы «Звезда» и «Снежинка» схема «Пуск» имеет простую структуру БД, а схема «Снежинка» имеет очень сложную структуру БД.

Что такое звездная схема?

Схема звезды в хранилище данных, в котором центр звезды может иметь одну таблицу фактов и ряд связанных таблиц измерений. Она известна как схема звезды, поскольку ее структура напоминает звезду. Модель данных Star Schema — это простейший тип схемы хранилища данных. Она также известна как схема соединения звезд и оптимизирована для запросов к большим наборам данных.

В следующем примере схемы Star таблица фактов находится в центре и содержит ключи для каждой таблицы измерений, таких как Dealer_ID, Model ID, Date_ID, Product_ID, Branch_ID и другие атрибуты, такие как количество проданных единиц и доход.

Пример диаграммы схемы звезды

Что такое схема снежинки?

Схема снежинки в хранилище данных — это логическое расположение таблиц в многомерной базе данных, при котором диаграмма ER напоминает форму снежинки. Схема «Снежинка» является расширением схемы «Звезда» и добавляет дополнительные измерения. Таблицы измерений нормализованы, что разбивает данные на дополнительные таблицы.

В следующем примере схемы Snowflake столбец Country дополнительно нормализуется в отдельную таблицу.

Пример схемы «снежинка»

Разница между схемой «звезда» и схемой «снежинка»

Ниже приводится ключевое различие между схемой «снежинка» и схемой «звезда»:

схема «звезда» Схема снежинки
Иерархии измерений хранятся в таблице измерений. Иерархии разделены на отдельные таблицы.
Содержит таблицу фактов, окруженную таблицами измерений. Одна таблица фактов, окруженная таблицей измерений, которая, в свою очередь, окружена таблицей измерений
В звездообразной схеме только одно соединение создает связь между таблицей фактов и любыми таблицами измерений. Для получения данных по схеме "снежинка" требуется множество соединений.
Простой дизайн БД. Очень сложный дизайн БД.
Денормализованная Структура данных и запросы также выполняются быстрее. Нормализованная структура данных.
Высокий уровень избыточности данных Избыточность данных очень низкого уровня
Таблица одного измерения содержит агрегированные данные. Данные разделены на разные таблицы измерений.
Обработка куба выполняется быстрее. Обработка куба может быть медленной из-за сложного соединения.
Предлагает более производительные запросы с использованием оптимизации запросов Star Join.
Таблицы могут быть связаны с несколькими измерениями. 		Схема Snowflake представлена ​​централизованной таблицей фактов, которая вряд ли связана с несколькими измерениями.
Схема

«Звезда» и схема «Снежинка» и 7 критических отличий

7 основных отличий схемы «звезда» от схемы «снежинка» и как выбрать правильную схему для вашего варианта использования.

Схемы «звезда» и «снежинка» — два преобладающих типа схем хранилища данных.

Схема хранилища данных относится к форме, которую принимают ваши данные: как вы структурируете свои таблицы и их взаимоотношения в базе данных или хранилище данных.

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

Как схемы помогают аналитике? И каковы различия и компромиссы между схемами звезды и снежинки?

В этой статье мы сравниваем два основных варианта схем хранилища данных и сопоставляем их преимущества и недостатки.

Содержание:

  • Что такое схема «звезда»
  • Что такое схема «снежинка»
  • 7 важных различий между схемой «звезда» и схемой «снежинка»
  • Какую выбрать?

Что такое схема звезда?

Чтобы понять моделирование данных по схеме «звезда», давайте рассмотрим пример розничной торговли. Представьте, что вы управляете международным торговым брендом и хотите анализировать покупки в своих физических точках.

Вы извлекаете данные из своей базы данных в виде файла Excel:

Но вскоре вы понимаете, что строк слишком много, и данные необходимо очистить, прежде чем вы сможете их проанализировать.

Вы решили преобразовать данные в звездообразную схему.

Звездообразная схема — это модель данных, в которой информация хранится в нескольких типах таблиц: одной таблице фактов и многомерных таблицах.

В отличие от классического дизайна базы данных с нормализованными таблицами, звездообразные схемы связывают многомерные данные с фактическими данными в форме, напоминающей звезду (отсюда и название), как видно из следующей диаграммы:

‍

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

Таблица фактов связана посредством отношения внешнего ключа с первичным ключом каждого измерения (иначе говоря, идентификатор в каждой таблице измерений, например, customer_id связывает клиента из таблицы dim_customer с таблицей fact_sales).

Этот тип моделирования данных позволяет нам запрашивать данные быстрее и с более простыми запросами, чем нормализованная структура базы данных.

Что такое схема снежинки?

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

Например, на приведенной выше диаграмме показано, как поле customer_country разбито на дополнительные таблицы измерений:

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

7 основных различий между схемой «звезда» и схемой «снежинка»


1. Нормализация таблиц измерений

Схема «снежинка» представляет собой полностью нормализованную структуру данных. Иерархии измерений (например, город > страна > регион) хранятся в отдельных таблицах измерений.

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

2. Избыточность данных

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

Например, схема «звезда» будет повторять значения в поле customer_address_country для каждого заказа из одной и той же страны.

Избыточность или дублирование записей возникает из-за конструкции схемы денормализации и нормализации.

3. Сложность запроса

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

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

4. Производительность запросов

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

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

5. Место на диске

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

6. Целостность данных

Целостность данных подвергается большему риску в схемах «звезда», чем в схемах «снежинка». Поскольку данные хранятся избыточно, в размерных таблицах звездообразной схемы существует несколько копий одних и тех же данных. Это означает, что новые вставки, обновления или удаления могут поставить под угрозу целостность данных.

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

7. Настройка и обслуживание 

Схемы типа «звезда» легче проектировать и настраивать. Поскольку они представлены простыми отношениями, инженеру данных или архитектору данных легко настроить соответствующую звездообразную схему.

С другой стороны, схемы «звезда» сложнее поддерживать, чем схемы «снежинка». По мере поступления новых данных в хранилище данных схемы типа «звезда» становится сложнее поддерживать и проверять на наличие нарушений целостности данных.

Какой выбрать?

Какой из двух типов схемы хранилища данных выбрать?

С одной стороны, звездообразные схемы проще, запросы выполняются быстрее и их проще настроить.

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

Исходя из приведенных выше компромиссов, решение зависит от того, какое преимущество (или недостаток) лучше всего подходит для вашего бизнеса.

Одно мы знаем точно: с Keboola поверх любой схемы хранилища данных вы сможете быстрее моделировать свои данные.

Создайте архитектуру данных своей мечты с помощью Keboola

Keboola — это платформа данных как услуга, которая помогает автоматизировать конвейеры данных.

Learn more



© 2010—, Кулинарные рецепты. Карта сайта, XML.