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

Question

СПАСИБО: Оба ответа очень полезны, но я мог выбрать только один. Я очень ценю совет!

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

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

Наша таблица "person" является ключевой - она ​​содержит более 4 миллионов записей и будет наиболее часто используемым источником в запросах. Ее можно увидеть в центре звезды с несколькими измерениями (например, с возрастом). , пол, принадлежность, местоположение и т. д.). Это очень длинная таблица, особенно когда я присоединяю ее к адресу и контактной информации.

Однако это больше похоже на таблицу измерений, когда мы начинаем смотреть на историю. Например, есть две разные таблицы истории, у которых есть личный ключ, указывающий на личную таблицу. У одной записи более 20 миллионов, а у другой почти 50 миллионов, и она растет ежедневно.

Является ли эта таблица таблицей фактов или таблицей измерений? Можно ли работать как оба? Если так, это будет большой проблемой производительности? Распространено ли запрашивать больше из измерения, чем факт? Что произойдет, если РАЗНАЯ таблица фактов, использующая таблицу person в качестве измерения, на самом деле составляет всего 60 000 записей (намного меньше).

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

РАЗЪЯСНЕНИЕ: Ниже были добавлены некоторые хорошие мысли, но, возможно, я упустил слишком много, чтобы действительно хорошо объяснить. Вот еще немного информации:

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

На данный момент я сосредотачиваюсь на двух основных «бизнес-процессах»: регистрация избирателей (то есть избиратель) и явка избирателей. Во первых, избиратель это факт. Во втором случае избиратель - это измерение, наряду с партией, выборами и типом голосования. (и в случае, если кто-то обеспокоен - нет, мы не знаем, КАК люди голосуют. Просто, что они делают. LOL)

Надеюсь, это немного прояснит ситуацию.

Answer 1

Крупные измерения «люди» (клиенты) часто встречаются в телекоммуникациях, банковском деле, страховании и т. Д. В Kimball есть раздел «Большие изменения размеров клиента» в главе CRM (6). Он показывает, как создавать «миниразмеры». Часто меняющиеся или часто анализируемые атрибуты (столбцы) разбиваются на отдельные таблицы мини-измерений. Эти мини-измерения связаны через таблицу фактов, поэтому таблица фактов имеет FK для каждой из этих таблиц отдельно.

Мне кажется, ваш пример близок к этому.

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

ПОСЛЕ РАЗЪЯСНЕНИЯ :
Я бы сказал, что Voter на самом деле является согласованным измерением - общим для всех витрин данных (бизнес-процессов). Другие согласованные измерения будут: дата, партия, выборы, голосующие станции. Мини-измерения будут демографическими и географическими. Таблицы фактов: RegistrationEvent (кто, когда и где зарегистрировался) и ElectionEvent (кто, когда и где проголосовал, на каких выборах, с помощью чего).
Измерение избирателя и факт RegistrationEvent загружаются из операционных систем, которые фиксируют регистрацию избирателей и другие изменения.
Это упрощено, но я надеюсь, что оно отражает основную идею.

Answer 2

хорошо - это не полный «ответ», но он близок.

Обратите внимание на эту запись в блоге, описывающую лекцию Кимбалла: http://database -geek.com / 2005/03/28 / в день-с-Ральфа Кимбалл-часть-2 /

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

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

РЕДАКТИРОВАТЬ: Кроме того, я нашел, что поиск по термину "измерение монстра" очень полезен. Это очень похоже на медленно меняющееся измерение клиента. Пока я готов к снежинке, я могу достигать того, что мне нужно - присоединения звездочек при опросе избирателей, и при этом не возникает проблем с использованием избирателя в качестве измерения для различных таблиц фактов.

EDIT: Вот мой окончательный вывод: как указывалось выше, цель состоит в том, чтобы облегчить бизнес-процесс, а не соответствовать диаграмме учебника.

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

Моя главная цель - СКОРОСТЬ. Поэтому я выбрал измененный формат - очень похожий на снежинку - где избиратель является центром нескольких таблиц, и оракул может использовать соединение звездой, когда я правильно все индексирую. Затем я использую избирателя как измерение во всех других моих «звездах». В каждом случае я настраивал его так, чтобы большинство, если не все таблицы, можно было объединять с помощью соединения звездой, даже если это не «учебник».

Еще раз спасибо за помощь!

Answer 3

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

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

Наконец, да, в некоторых случаях мы запрашиваем только наши таблицы измерений, часто, когда приложению требуется определенный список элементов (т. Е. Продукты, клиенты и т. Д.), Это допустимое использование, однако лучшее решение, вероятно, будет использовать ОРВ, а не наша звездная схема.

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

Редактировать Я уверен, что был более конкретным со ссылкой на СОД.

Оперативное хранилище данных (или «ODS») - это база данных, предназначенная для интеграции данных из нескольких источников, чтобы упростить анализ и отчетность. Поскольку данные поступают из нескольких источников, интеграция часто включает в себя очистку, устранение избыточности и проверку на целостность в соответствии с бизнес-правилами. ОРВ обычно предназначен для хранения низкоуровневых или атомарных (неделимых) данных (таких как транзакции и цены) с ограниченной историей, которые регистрируются в «реальном времени» или «почти в реальном времени», в отличие от гораздо больших объемов данных, хранящихся в Хранилище данных, как правило, реже.

По словам Билла Инмона, создателя концепции, ОРВ - это «предметно-ориентированный, интегрированный, изменчивый, актуальный, актуальный, только для подробных данных сбор данных в поддержку потребности организации в актуальном состоянии». во-вторых, оперативная, интегрированная, коллективная информация. "

ODS отличаются от определения Inmon хранилища корпоративных данных тем, что имеют ограниченную историю и более частое обновление, чем EDW. На практике ОРВ, как правило, лучше отражают исходные структуры, чтобы ускорить реализацию и обеспечить более точное представление производственных данных.

http://en.wikipedia.org/wiki/Operational_data_store