Хранилище данных иерархического моделирования - снежинка или звезда?

Question

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

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

библиотека -> ячейка -> контакт -> время / мощность

Мне интересно знать свойство ячейки -timing/power, чтобы я мог сделать сравнение позже.

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

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

Меня беспокоит то, что мои данные очень большие, так как у меня есть около 200 библиотечных файлов, каждый библиотечный файл содержит около 20 тыс. Ячеек, каждая ячейка содержит несколько выводов, а каждый вывод содержит немного информации о времени и мощности. Таким образом, общий размер большой, что составляет 200 х 20000 х 4 х 4

Я буду постоянно качать этот большой набор данных всякий раз, когда будет выпущена новая версия файла библиотеки

Можете ли вы дать мне предложение, что лучше? Dfdf

Редактировать:

Library A
   Cell A
      Pin A1
        Condition A11
           riseTimingTemplate
           fallTimingTemplate
           risePowerTemplate
           fallPowerTemplate

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

Допустим, мой факт зерна будет рассчитывать время и энергетическую ценность конкретной ячейки
так что мое измерение будет иметь библиотеку, ячейку, пин-код, условие, riseTimingTemplate, fallTimingTemplate, risePOwerTemplate и fallPowerTemplate, все ссылки на таблицу фактов правильны?

Answer 1

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

Инман:
Для эффективности использования пространства, скорости и простоты конструкции; рассмотреть возможность использования дизайна Inman, который основан на сущностях. В вашем примере это может быть одна таблица для каждой сущности, факты которой хранятся непосредственно в таблице и связаны в иерархии с помощью простой ссылки ключ / fk между таблицами. Например, у вас может быть 4 таблицы, как вы упомянули выше. Свяжите эти таблицы с естественным ключом, чтобы избежать зависимости от порядка сортировки или других случайных ключей на случай, если вам нужно сравнить ранее загруженные данные с текущей загрузкой. Это также может быть более эффективным для фактов, где время не гладко. Тем не менее, это компромисс, если временные ряды или другие ряды должны быть гладкими, поскольку отчетность может быть более трудной для разработки любых требований сглаживания.

Кимбалл:
Хорошим примером использования модели Кимбалла в этом случае является случай, когда существует много разных фактов, но все в одном и том же аспекте. Смешивание фактов на разных уровнях делает модель данных более сложной для построения и использования. Я определяю зерно в вашем примере как факты на уровне ячеек, а затем факты на уровне мощности находятся на другом уровне, предполагая, что между каждой таблицей существует отношение 1-n. Там, где вы можете просто хранить измерения для объекта в проекте Inman, вы обычно отделяете факты от измерений в проекте Kimball, который создает дополнительные таблицы для сохранения этих показателей.

OLAP:
Если вы используете технологии OLAP для вашего механизма запросов, это немного сложнее. Большинству потребуется модель данных в виде звездообразной схемы. Большинство механизмов не допускают определение снежинки, так как это рискует "объединением продукта", которое происходит, когда у вас есть n-1 или nn отношений между зависимыми таблицами измерений. Результатом nn таблиц измерений могут быть дубликаты строк фактов, если их не обрабатывать осторожно, и их очень трудно устранить, когда запросы приводят к слишком высоким значениям, когда эти дубликаты появляются в данных, просто объединяя эти nn измерений. ** Если вы можете гарантировать, что внешние измерения всегда равны 1-1 или 1-n (имеется в виду 1 библиотека на x ячеек, но никогда не 2+ библиотеки на ячейку), и ваши меры записываются на уровне синхронизации / мощности, тогда снежинка является отличный способ хранения ваших данных (минимум места), но вам все равно может потребоваться создание "представлений", поэтому ваш дизайн кажется звездой для вашего набора инструментов OLAP (несколько более новых движков olap позволят такие конструкции). Построение ваших данных в виде звезды займет больше места, но может позволить вам легче обнаружить nn или n-1 инциденты.

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

[Редактировать из комментариев]Основываясь на комментариях и вашей модели, несколько мыслей:

• Факты таблицы ФК также являются ПК для этой таблицы
• Модель говорит, что вы не собираете факты на булавках или шаблонах, делая их просто информационными. Возможно, не стоит использовать их, если у вас есть много выводов / шаблонов в одной ячейке, так как они представят объединение продуктов, которое может создавать повторяющиеся факты при объединении этих таблиц. Тем не менее, оставьте их, если вы можете спросить: "Учитывая некоторые необычные меры, как мои клетки связаны общими булавками?" или аналогичные виды анализа.
• Дизайн указывает, что библиотеки связаны с клетками только через собранные факты. Делая эти отношения (либ к клетке) динамичными.

Наконец, совет для измерения даты: pk для даты может быть отформатирован # на основе уровня детализации сбора даты / времени (т. Е. 20150101 может быть ключом для 1 января 2015 года, добавьте вторую таблицу для времени, если вам нужно время, иначе таблица дат будет очень быстро расширяться в хранилище. Ускоряет сборку ETL, и вы даже можете пропустить соединения с таблицей дат для получения базовых данных дат)