Моделирование отношений "многие ко многим" в хранилище данных

Question

Я должен спроектировать модель хранилища данных и процесс ETL для класса в моем университете. В моем хранилище данных должны храниться мнения / комментарии о продукте, каждая запись должна состоять из:

• текст комментария (строка)
• оценка продукта ({0, 0,5, …, 4,5, 5})
• комментарий автора (String)
• дата комментария (Date)
• рекомендация продукта ({Да, Нет})
• комментировать голоса (Int)
• комментарий вниз голосов (Int)
• Плюсы продукта (много строк, например, {цена, дизайн, долговечность, … }) и их количество
• минусы продукта (много строк, например {слишком громко, слишком тяжело, цена, … }) и их количество

Дополнительно в хранилище данных должна храниться информация о товаре:

• Категория продукта
• марка продукта
• модель продукта

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

Сначала я рассматриваю 3 подхода, которые я представил на диаграмме ниже. Я использовал метод таблицы мостов (хотя я не знаю, правильно ли), чтобы избавиться от отношений "многие ко многим". Я не знаю, как это повлияет на производительность запросов.

Второй подход, который я могу использовать, это метод логических столбцов. В таблице PROS и CONS я могу создать столбец для каждого возможного значения, но может быть до 100 различных плюсов и минусов. Также количество возможных плюсов или минусов не является постоянным во времени. Авторы в своих комментариях могут перечислить новые плюсы и минусы (вот как это работает в источнике данных), но я не могу добавить новые столбцы (я не должен изменять данные в хранилище данных).

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

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

Answer 1

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

в предоставленном вами изображении хорошо иметь таблицу Pros_Bridge_Detail. Остальные должны быть изменены.

• Вы можете удалить таблицу pros_Bridge, которая содержит только количество. вы можете добавить этот столбец к вашей таблице фактов COMMENT, которая у вас там есть. Это было бы более эффективно и легко, когда дело доходит до запросов, а не запросов во многих таблицах.
• Вы сказали, что у вас есть много областей, чтобы дать плюсы, такие как цена, дизайн, долговечность и т.д.
• Добавьте новый столбец в таблицу Pros_Bridge_Detail для хранения идентификатора вновь созданного измерения, в котором содержатся типы продуктов (дизайн, долговечность и т. Д.). Теперь, как только вы добавите продукт Pro, таблица Pros_Bridge_Detail будет иметь плюсы, которые дает пользователь, а также будет содержать значение относительно того, что профи предоставляется через идентификатор нового измерения.
• Также не забудьте сохранить идентификатор комментария в таблице Pros_Bridge_Detail, поскольку это будет ваша ссылка (FK) на таблицу фактов комментариев, которая у вас есть.

То же самое можно сделать и с минусами.

Надеюсь, вы понимаете, что я только что объяснил, и надеюсь, что это поможет. сообщите, если у вас есть какие-либо проблемы.