Всем привет!
В источнике есть таблица комментариев, в ней хранится текст, дата создание, id сотрудника, id клиента, id того что коментируем, тип того что коментируем (заявка, звонок и т.д.). Для каждого id может быть несколько комментов, не все заявки, звонки и т.д имеют комменты. Анализ идет только на вхождение определенных слов в тексте.
По Кимбалу это Dim, но тогда нужно Bridge делать. Комменты на 90% уникальны. Как факт она тоже не уперлось, к тому же если как факт ее не получится подцепить со звонками, т.к. это факт, а не справочник. Думаю все таки разбивать на 3 таблицы (на 3 типа того что коментируем) и цеплять к соответствующим фактам и делать bridge как нибудь.

Хочу сделать так
http://kimballgroup.forumotion.net/t784-modelling-free-text-comments
"
What I normally do is store a comment once. To do this, I generate a checksum of the text (I like to use the CRC32 function) and use that as a non-unique natural key to the dimension (with index). To get the surrogate key, I calculate the CRC32 value for the incomming comment and use the checksum and text to locate the dimension row. If I get a match, I use that key, otherwise I create a row. The reason for the checksum is to provide a small value (an integer) for indexing. You will get duplicates, so lookups must match text values as well, but it avoids having to index the text itself.

This will keep the size of the table to a minimum
"

Вопрос как быть c Brodge в таком случае.

Забыл, дата создания комента важна.

tarrus,

В таком случае два факта связаны напрямую, факт звонков и коментов.
И на сущности нет смысла делить, достаточно тип комента держать к примеру.
Запросы если в комменте находим строку то смотрим информацию о событии (звонок\заявка + все его атрибуты с Dim'ов), анализ такой.
Это может быть как и Dim так и факт в принципе, если делать как факт вопрос как связать со звонком правильно, если как Dim с Bridge гемор.

aleksrov,

Суть такая, там повторюсь: текст, дата создание, id сотрудника, id клиента, id того что коментируем, тип того что коментируем (заявка, звонок и т.д.).
Если как факт.
Id сотрудника - у меня есть DimStaff, можно вытащить Key
Id клиента - есть DimClient, можно вытащить Key
То что комментим:
Id заявки - есть как факт и как Dim с маппингом 1:1 (знаю что так неверно но по другому никак, в факте только дата и сумма в Dim атрибуты разные и флаги, по чему делаем анализ), т.е. Key заявки можно вытащить.
Id Задачи - задача это когда сотруднику дают план сделать 20 звонков (не путать с фактом звонков, разные сущности совершенно), когда но их делает в источнике в строку проставляется время, так вот, каждый звонов это срока в факте, а время создания задачи, ее закрытие и прочее Dim, т.е. Key задачи можно вытащить.
А вот DimЗвонков у меня нет, это факт, где суррогатный ключ, время, клиент, сотрудник и ключ на небольшой справочник (где причина звонка, тип и т.д.).
Поэтому если делать из коментов факт то как соединить со звонками вопрос.

tarrusaleksrovtarrus,

В таком случае два факта связаны напрямую, факт звонков и коментов.
И на сущности нет смысла делить, достаточно тип комента держать к примеру.
Запросы если в комменте находим строку то смотрим информацию о событии (звонок\заявка + все его атрибуты с Dim'ов), анализ такой.
Это может быть как и Dim так и факт в принципе, если делать как факт вопрос как связать со звонком правильно, если как Dim с Bridge гемор.

Если таблица и факт и и измерение одновременно, то я часто использую просто представление с усеченным количеством полей. А-ля, факты. Но SSAS умеет и такую связь сам создавать, но там есть подводные камни.

Т.е. DimOrder - таблица, а FactOrder - это представление.

select OrderKey
from DimOrder

Ну ХЗ, впервые такое слышу.
В принципе если подумать по требованиям к отчету это все таки Dim, ведь мы сначала находим нужные строки в коментах, а потом уже идем смотреть нужные звонки\заявки, а не наоборот. Анализа вроде все коменты с заявками у которых какой нибудь флаг = 1 точно не будет.
Но тогда ХЗ как Bridge делать если честно.

tarrusaleksrovА вот DimЗвонков у меня нет, это факт, где суррогатный ключ, время, клиент, сотрудник и ключ на небольшой справочник (где причина звонка, тип и т.д.).
Поэтому если делать из коментов факт то как соединить со звонками вопрос.

Ну тогда через bridge, который и будет недостающей таблицей фактов, все правильно мыслите.

В смысле? Т.е. между фактом комент и звонок сделать bridge? Не понял немного.

Хотя как факт все таки проще конечно намного хранить, ETL проще и все таки если хотелки у бизнеса изменется проще делать анализ в разрезе клиента\сотрудника по коментам.
Вопрос только в звонки упирается.
К тому же разумеется комента есть от силы у 10% звонков.

Как я понимаю вы это имели ввиду
https://dwbi1.wordpress.com/2014/06/19/connecting-fact-tables/
In some cases, several fact tables need to be joined, for the purpose of reporting. Cubes join different fact tables, but reports can’t do that.
There are 2 approaches to do this:
1) Create a “fact table bridge” table. The bridge table contains the fact key columns of each fact table, plus any filtering columns required.
2) Create a new fact table containing all the required measures at the combined grain
Как я понимаю вы про первый подход?
Кстати куба по комментам не будет, запросы по коментам не постоянные, сейчас найти такой слово, потом такое, потом строку и т.д., это будут нечастые запросы через T-SQL обычный.

tarrus,

Спасибо, сейчас читаю.
Я обычный запрос и буду делать. Вопрос в том, что из источника я не могу брать данные, их очень много (источников) и не все они доступны бывают, в общем сейчас это гемор, поэтому коменты и должны быть тоже в хранилище, но как я понимаю если в кубе мы все ровно не используем их то мы можем спокойно соединить коменты с фактом звонков напрямую и не парится?
Если да то так даже будет быстрее, т.к. если мы в коментах нашил нужное слово (обычно таких строк не много), нам нужно получить до инфу по звонку, SQL скорее всего сделает look и все, разумеется без bridge и прочего это будет быстрее.