Я и еще один администратор базы данных в нашей компании занимаемся рассмотрением дизайна базы данных, разработанного для нас поставщиком. Продавец сказал, что они используют Kimball в качестве основы для своего дизайна. (ПРИМЕЧАНИЕ: я не ищу аргументы Кимбалла против Инмона и т. Д.) Они разработали витрину с несколькими фактами и измерениями.
Теперь, честно говоря, наша компания никогда не проектировала ни одного магазина. У нас всегда были консультанты, делающие это. И нас никогда не отправляли на занятия или что-то еще. Таким образом, наше знание складирования / витрин / размерного моделирования и т. Д. Основано на том небольшом опыте, который у нас есть, на том, что мы можем найти в Интернете, и на самостоятельном чтении (у нас есть книги Инмона и Кимбалла, и мы пытаемся пробиться через них) ,
Теперь, когда подготовлена почва для моего уровня знаний, мы подошли к задаче проектирования.
Существует таблица фактов, которая называется «Статистика потерь» (это для страховки). И они пытаются захватить как платежи по претензиям (свернутые до месячного уровня), так и деньги в резервах (вроде банковского счета для претензий). Они хотят видеть ежемесячные суммы для платежей (не важно). Но они хотят видеть на счету текущий баланс резервов.
Я приведу наглядный пример.
Скажем, мы создали резервы в размере 1000 долларов США для требования. Это откладывается (поэтому в некоторых отношениях он функционирует как банковский счет).
В октябре 2014 года мы еще ничего не выплачиваем. Таким образом, бизнес хочет увидеть платежи и резервный баланс в конце октября.
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------Затем наступает ноябрь. Мы оформляем платежи в размере 100, 150 и 75 долларов. Они хотят видеть эти суммы агрегированными и резерв на балансе следующим образом:
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
- 112014 - 325.00 - 675.00 -
-----------------------------------------------А потом скажите, что у нас нулевые платежи в декабре, а затем еще 200 долларов в январе следующего года.
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
- 112014 - 325.00 - 675.00 -
-----------------------------------------------
- 122014 - 0.00 - 675.00 -
-----------------------------------------------
- 12015 - 200.00 - 475.00 -
-----------------------------------------------Вот где я борюсь. Насколько я понимаю, платежная часть верна. Все они свернуты на ежемесячном уровне в каждой записи. Таким образом, вы можете свернуть дальше, если вы хотите на год, квартал и т. Д.
Но сумма резервов другая. Это баланс. И бизнес хочет видеть, сколько на балансе в каждом месяце. Но вы не можете агрегировать на этом поле. Если бы вы это сделали, вы бы получили некоторые неожиданные результаты.
Как-то это мне кажется неправильным. Но я не могу честно сказать, что достаточно смоделировал или знаю достаточно. Все, что я могу сказать, это то, что я знаю. И насколько я знаю, все значения в факте должны быть одинаковыми.
Оба числа имеют одинаковую гранулярность «месяца», но они не с точки зрения того, что они обозначают. Один из них - совокупные доллары в течение месяца. Другой просто баланс.
Это правильно? Я давлю на этот дизайн. Я ошибаюсь, чтобы сделать это? Это нормально делать это в факте? Или моё чувство «запаха кода» плохого дизайна точно?
Любая помощь будет оценена. ПРИМЕЧАНИЕ: пожалуйста, не просто говорите «Это должно быть способом X», пожалуйста, объясните, почему это должно быть так, чтобы я мог извлечь уроки из этого.
РЕДАКТИРОВАТЬ : Ну, я узнал, что мое первоначальное понимание Факта неверно. Детализация НЕ ежемесячно. Гранулярность - это уровень транзакции. Таким образом, это означает, что в течение MONTH_YEAR (то есть на самом деле это финансовый отчетный период) будет несколько транзакций оплаты и восстановления. Они будут опубликованы по дате или дате транзакции. Но из-за предварительного отчета, который видит бизнес, а также из-за того, как данные хранятся в прежней системе, из-за которой они хотели разместить как транзакционные данные (по одной строке на каждый), так и резервный ежемесячный баланс (по одной строке в месяц). ).
Когда я узнал об этом, я понял, что проблема была не столько в аддитивности, сколько в аддитивности или даже полудобавке, а в том, что это было зерно, о чем я и подозревал с самого начала. Наша команда DBA обсудила это с командой проекта и сообщила, что они пытаются поместить два разных фактора в один и тот же факт, и это было неправильно. Они должны либо повысить роль транзакций до ежемесячного уровня, что позволит им затем получать платежи, возвраты и ежемесячный резервный баланс (т.е. полуаддитивный факт), потому что все будет на уровне ежемесячного зерна. Или им нужно найти способ разбить резервный баланс на транзакции, чтобы сохранить уровень транзакций. Или им нужно разбить факт на два факта. Можно указать месячный уровень резервного баланса. Другой может быть на уровне транзакции для платежей и возмещений. (Нет никаких причин, по которым они также не могли поставить платежи и возвраты на ежемесячный уровень в факте на ежемесячном уровне. Просто зависит от потребностей бизнеса.)
Учитывая то, что я узнал, я буду отмечать ответ Томаса как правильный. Тем не менее, я чувствую, что обсуждение, которое я начал с первоначального вопроса, все еще полезно для изучения другими, поэтому я оставлю оригинальную часть моего вопроса без изменений. Я также намерен присудить награду за ответ никадама, так как он многому научил меня о аддитивных, неаддитивных и полуаддитивных фактах и исправил множество недоразумений, которые у меня были по поводу размерного моделирования.
источник
reserveв аддитивный фактpayment into reserve, который будет на том же уровне детализации,payment out of reserveчто и сейчас.Вы правы: « разные зерна не должны смешиваться в одной таблице фактов ».
Но резервный баланс на конец месяца и сумма платежей на конец месяца находятся на одном уровне. Это всего лишь один из фактов, полудобавок . Тип факта (аддитивный или нет) не определяет зерна таблицы.
Исходя из того, что вы описываете, я вижу ваше зерно как «ежемесячный снимок заявки», что делает вашу таблицу фактов «Таблица фактов периодического снимка ».
В этой статье у Кимбалла есть пример аддитивных и полуаддитивных фактов в одной таблице фактов.
Вот пример периодического снимка с полуаддитивными фактами из набора инструментов хранилища данных (стр. 116):
Рекомендуется иметь таблицу фактов транзакций, которая будет отражать каждое изменение резерва (платежей и корректировок) на самом низком атомарном уровне. Когда вы имеете дело с претензиями, часто атомарный уровень - это не претензия, а суб-претензия (у вашей страховой компании может быть свой термин). Обычно каждая подпретензия представляет отдельную сторону претензии и выплаты / резервы для каждой из сторон. Например, могут не производиться выплаты застрахованному лицу, но выплачиваются не застрахованному пострадавшему лицу вашей компании, а платежи больнице и адвокату.
В зависимости от производительности вашего инструмента BI вы можете напрямую использовать таблицу фактов транзакций для получения ежемесячных платежей и остатков. Или вы можете обновить периодическую таблицу фактов моментального снимка из транзакции ежедневно или в конце месяца.
Способность обрабатывать полуаддитивные факты будет зависеть от того, какой BI-слой вы используете. Некоторые инструменты способны легко справляться с полуаддитивными фактами, а некоторые нет.
В основной книге Кимбалла ( Набор инструментов хранилища данных ) есть полная глава (16) о страховании.
источник