Агрегаты размерной модели для вложенных/дробных объектов

Question

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

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

Каждый запрос надувательства формирует запись в журнале примерно так:

{ 
    sellRequestID: 123, 
    userID: 456, 
    timestamp: 1449043403, 
    country: "United States", 
    goods: [ "eggs", "beef", "chicken" ] 
} 

запрос на покупку может генерировать запись журнала примерно так:

{ 
    buyRequestID: 987, 
    sellRequestID: 123, 
    userID: 789, 
    timestamp: 1449043408, 
    good: "eggs" 
} 

Я хотел бы быть в состоянии ответить на вопросы например:

1. Общее количество запросов на продажу в день и страну?
2. Каково общее количество индивидуальных запросов на продажу товаров (детские запросы), представленные днем ​​и страной? (В некоторой степени это раскрывает «коэффициент инфляции запроса» или среднее количество товаров за запрос на продажу).
3. Каково общее количество детских запросов, представленных днем, страной и типом (т. Е. Какая общая «доступность» каждого товара на рынке продавцов)?

Предполагая, что у меня есть относительно стандартные таблицы размеров:

users   countries  goods 
-----   ---------  ----- 
456 John Smith 1 United States 1 eggs 
789 Jane Doe  2 Canada   2 beef 
... ...   . ...   3 chicken 

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

Date  CountryID  Total Requests 
2015-12-01 1    1,000,000 
2015-12-01 2    200,000 
... 

таблица, которая может ответить на мой второй вопрос и третий вопросы могут выглядеть так:

Date  CountryID GoodID  Total Requests 
2015-12-01 1   1   600,000 
2015-12-01 1   2   300,000 
2015-12-01 1   3   400,000 
... 

Есть ли дизайн, который позволил бы мне ответить на все вопросы в одной таблице? Я рассмотрел пару возможностей, и я ищу любой практический опыт или совет.

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

Один из подходов может использовать схему, как:

Date  CountryID GoodID Parent Requests Child Requests 

Если бы я сделать это, чтобы избежать инфляции в предыдущем случае, я должен был бы «fractionalize» родительские запросы - например, запрос, содержащий три товара, все равно добавит 1 к столбцу дочерних запросов по трем строкам, но добавит 1/3 к агрегатам родительских запросов. Аналогичным образом запрос с двумя товарами добавит 1/2 к столбцу родительских запросов через две его строки.Таким образом, я мог бы иметь данные, такие как:

Date  CountryID GoodID Parent Requests Child Requests 
2015-12-01 1   1   1/3    1 
2015-12-01 1   2   5/6    2 
2015-12-01 1   3   5/6    2 

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

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

Answer 1

Непонятный ответ, сам по себе, но несколько мыслей.

1) Недостатком подхода является то, что фракция в родительских запросах будет полуаддитивной, поэтому вам необходимо тщательно контролировать любые запросы, которые объединяют этот столбец. Это может показаться тривиальным, но оно может ударить ваш прикладок, когда вы добавляете измерения, или, возможно, сообщество ваших конечных пользователей растет. Если вы пройдете этот маршрут, вы можете заменить имена «Родительские запросы» и «Запросы детей» на что-то более ориентированное на бизнес. Вы можете обсудить это с вашими пользователями. От манжеты я могу попытаться заменить «Запросы к ребенку» только «Запросами», поскольку он применим непосредственно к естественному ключу и, возможно, заменит «Родительские запросы» на что-то вроде «Good_to_Request_Ratio». (Мне это уже не нравится.)

2) Правильно проиндексированный, таблица взвешенных мостов может обеспечить решение. Но это еще много строк. В этом случае вы добавляете измерение «Запрос», которое соединяется с параметром «Хорошее».

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