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

Question

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

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

В хранилище данных капельных следует хранить информацию о продукте:

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

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

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

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

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

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

Answer 1

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

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

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

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

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