Подходы к архитектуре и принципам проектирования хранилищ данных

Основные подходы к архитектуре

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

  • Модель звезды (Star Schema)

  • Модель снежинки (Snowflake Schema)

  • Таблица фактов (Fact Table) и таблицы изменений (Dimension Tables)

Таблицы измерений

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

Модель звезды (Star Schema)

e70e1ed54b2b7681aaef8e3b5edc4917.png

Центральный мост «Звезды» — это таблица, в которую добавлены блоки ключевых полей из тех таблиц, связанных друг с другом

ce755fed2e931897ae71f108d0cd5ef3.png

Характеристики:

  • Каждое измерение в звёздообразной схеме представлено единственной одномерной таблицей

  • Таблица измерений должна содержать набор атрибутов

  • Таблица измерений присоеденяется к таблице фактов с помощью внешнего ключа

  • Таблицы измерений не соеденины друг с другом

  • Таблица фактов будет содержать ключ и меру

  • Схема Звезда проста для понимания и обеспечивает оптимальное использование диска.

  • Таблица измерений не нормализованы.

  • Схема широко поддерживается BI Tools

Модель снежинки (Snowflake Schema)

963093d444484fa5ec9ea797ea4e5167.png

Снежинка — это та же Модель звезды (Star Schema), только измерения могут зависеть от измерений следующего уровня, а те в свою очередь могут включать ещё уровни.

  • Основное преимущество этой схемы — использование меньшего дискового пространства

  • Проще реализовать добавление измерения в схему

  • Из-за нескольких таблиц производительность запросов снижается

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

Сравнительная характеристика Звезды и Снежинки

Схема звезды

Схема снежинки

Иерархии для измерений хранятся в таблице измерений.

Иерархии разделены на отдельные таблицы.

Он содержит таблицу фактов, окруженную таблицами измерений.

Одна таблица фактов, окруженная таблицей измерений, которая в свою очередь окружена таблицей измерений

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

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

Простой дизайн БД.

Очень сложный дизайн БД.

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

Нормализованная структура данных.

Высокий уровень избыточности данных

Очень низкоуровневая избыточность данных

Таблица одного измерения содержитагрегированные данные.

Данные разбиты на разные таблицы измерений.

Обработка куба происходит быстрее.

Обработка куба может быть медленной из-за сложного соединения.

Предлагает более эффективные запросы, используя Star Join Query Optimization. Таблицы могут быть связаны с несколькими измерениями.

Схема снежных хлопьев представлена ​​централизованной таблицей фактов, которая вряд ли связана с несколькими измерениями.

Таблица фактов (Fact Table) и таблицы измерений (Dimension Tables)

0046d88f7d4d1a7d45aed3adad45566c.gif678304ca5f7f49483935b5b91e8dd41e.gif

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

Таблицы измерений

fb4e6bbfa2ec95a9201aabe184a76098.gifAGV_vUd-PGTUmIjVubxnC8djAo78XTDpaU-63ll6fm963vxAQGFCtXCFDB_1qQc0J37KiLsUTvv59nSMAd_D8qRqOzxLQGX45VP_wapIAgN4U8QKrUj9KQXCJWaoutFmB_JHbNaAezF8CQ=s2048?key=30qOc8xKqqfHYUc-aTUB_dVr

Хранение ссылочных данных, таких как таблицы подстановки, от идентификатора сущности до её свойств. Хранение данных, подобных snapshot, в таблицах, все содержимое которых изменяется в одной транзакции Таблицы измерений не регулярно помечаются с новыми данными. Вместо этого все содержимое данных обновляется одновременно с помощью таких операций, как .set-or-replace, .move extents или .rename tables. Иногда таблицы измерений могут быть производными от таблиц фактов. Этот процесс можно выполнить с помощью политики обновления в таблице фактов с запросом к таблице, которая принимает последнюю запись для каждой сущности.

Основные принципы проектирования хранилищ данных

  • Нормализация

  • Денормализация

  • Разделение данных

  • Использование индексов

  • Управление изменениями

  • Использование ETL

  • Обеспечение безопасности и конфиденциальности

Разделение данных

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

Преимущества разделенной базы данных

  • Улучшенная производительность

  • Большая доступность

  • Улучшенная безопасность

© Habrahabr.ru