Как хранить метаданные покупки в хранилище данных

Question

Предположим, что моя компания продает много товаров, например, домены, футболки и фургоны.

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

fact_invoice_item

id                   | pk
invoice_item_id      | id of invoice in OLTP
dim_customer_key     | fk to customer dimension
dim_product_key      | fk to product dimension
dim_billing_date_key | fk to date dimension
dim_due_date_key     | fk to date dimension
invoice_amount       | fact
item_amount          | fact
dd_invoice_id        | degenerate dimension to group together invoice items on the same invoice

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

Текущее мышление:

Вариант 1

Имейте одну общую invoice_item_metadata таблицу размеров с fk к ней из таблицы invoice_item. Эта таблица измерений может хранить метаданные элемента в форме json. Или даже просто сохраните метаданные покупки в таблице фактов в форме JSON. Это усложнит ситуацию, так как мне нужно будет распаковать json, чтобы выполнить любой анализ на нем.

Вариант 2

Имейте таблицу фактов для каждого типа купленного продукта, например. fact_domain_purchase и fact_van_purchase. Эти таблицы фактов могут иметь собственную структуру, которая наилучшим образом соответствует метаданным продукта. Это кажется логичным, но потом я начинаю думать, что домен - это скорее SCD, поскольку он может иметь такие атрибуты, как приостановленный / активный / просроченный, которые могут изменяться со временем. Это заставляет меня думать, что у меня может быть таблица fact_domain_purchase с таблицей fk в таблицу dim_domain, но тогда таблица dim_domain будет расти с той же скоростью, что и таблица fact_domain_purchase, что нежелательно.

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

Answer 1

Я думаю, вам нужно решить две вещи, where и how, чтобы хранить метаданные

Для хранения ваш вариант использования является идеальным примером для Extension table

fact_invoice_item_ext

id                   | pk
fact_invoice_item_id | id of fact_invoice_item table

Эта таблица похожа на вашу таблицу фактов, но в основном она является расширением ваших записей фактов для хранения дополнительных (возможно, также необязательных) данных

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

attr_key             | attribute key; domain, van, t-shirt etc.
attr_value           | attribute value; domain name, license plate etc.

. При таком подходе вы можете иметь несколько дополнительных атрибутов (метаданных) для элементов счета.

Пожалуйста, дайте мне знать, если это имеет смысл, или у вас есть дополнительные вопросы по поводу этой концепции

Answer 2

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

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

Либо в основной таблице фактов, что означает, что она содержит атрибуты для всех подтипов продукта (футболка, фургоны, ...), но заполнены только те, которые для подтипа проданы, все остальные - NULL.

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

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