Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 Как вы храните комменты?  [new]
aleksrov
Member

Откуда:
Сообщений: 899
Всем привет!
В источнике есть таблица комментариев, в ней хранится текст, дата создание, id сотрудника, id клиента, id того что коментируем, тип того что коментируем (заявка, звонок и т.д.). Для каждого id может быть несколько комментов, не все заявки, звонки и т.д имеют комменты. Анализ идет только на вхождение определенных слов в тексте.
По Кимбалу это Dim, но тогда нужно Bridge делать. Комменты на 90% уникальны. Как факт она тоже не уперлось, к тому же если как факт ее не получится подцепить со звонками, т.к. это факт, а не справочник. Думаю все таки разбивать на 3 таблицы (на 3 типа того что коментируем) и цеплять к соответствующим фактам и делать bridge как нибудь.
7 сен 18, 13:04    [21668075]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
aleksrov
Member

Откуда:
Сообщений: 899
Хочу сделать так
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 в таком случае.
7 сен 18, 13:07    [21668078]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
aleksrov
Member

Откуда:
Сообщений: 899
Забыл, дата создания комента важна.
7 сен 18, 14:52    [21668239]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
tarrus
Member

Откуда: Bergen
Сообщений: 726
aleksrov
Забыл, дата создания комента важна.


Вроде бы классическая таблица фактов у вас из двух стобцов (если раделите на сущности). Не?

CommentKey, WordKey

или

PhoneCallKey, EmailKey, WordKey
7 сен 18, 15:17    [21668271]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
aleksrov
Member

Откуда:
Сообщений: 899
tarrus,

В таком случае два факта связаны напрямую, факт звонков и коментов.
И на сущности нет смысла делить, достаточно тип комента держать к примеру.
Запросы если в комменте находим строку то смотрим информацию о событии (звонок\заявка + все его атрибуты с Dim'ов), анализ такой.
Это может быть как и Dim так и факт в принципе, если делать как факт вопрос как связать со звонком правильно, если как Dim с Bridge гемор.
7 сен 18, 15:27    [21668285]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
tarrus
Member

Откуда: Bergen
Сообщений: 726
aleksrov
tarrus,

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


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

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

select OrderKey
from DimOrder
7 сен 18, 15:32    [21668291]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
aleksrov
Member

Откуда:
Сообщений: 899
aleksrov,

Суть такая, там повторюсь: текст, дата создание, id сотрудника, id клиента, id того что коментируем, тип того что коментируем (заявка, звонок и т.д.).
Если как факт.
Id сотрудника - у меня есть DimStaff, можно вытащить Key
Id клиента - есть DimClient, можно вытащить Key
То что комментим:
Id заявки - есть как факт и как Dim с маппингом 1:1 (знаю что так неверно но по другому никак, в факте только дата и сумма в Dim атрибуты разные и флаги, по чему делаем анализ), т.е. Key заявки можно вытащить.
Id Задачи - задача это когда сотруднику дают план сделать 20 звонков (не путать с фактом звонков, разные сущности совершенно), когда но их делает в источнике в строку проставляется время, так вот, каждый звонов это срока в факте, а время создания задачи, ее закрытие и прочее Dim, т.е. Key задачи можно вытащить.
А вот DimЗвонков у меня нет, это факт, где суррогатный ключ, время, клиент, сотрудник и ключ на небольшой справочник (где причина звонка, тип и т.д.).
Поэтому если делать из коментов факт то как соединить со звонками вопрос.
7 сен 18, 15:35    [21668296]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
aleksrov
Member

Откуда:
Сообщений: 899
tarrus
aleksrov
tarrus,

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


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

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

select OrderKey
from DimOrder


Ну ХЗ, впервые такое слышу.
В принципе если подумать по требованиям к отчету это все таки Dim, ведь мы сначала находим нужные строки в коментах, а потом уже идем смотреть нужные звонки\заявки, а не наоборот. Анализа вроде все коменты с заявками у которых какой нибудь флаг = 1 точно не будет.
Но тогда ХЗ как Bridge делать если честно.
7 сен 18, 15:40    [21668303]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
tarrus
Member

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


Ну тогда через bridge, который и будет недостающей таблицей фактов, все правильно мыслите.
7 сен 18, 15:41    [21668305]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
aleksrov
Member

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


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


В смысле? Т.е. между фактом комент и звонок сделать bridge? Не понял немного.
7 сен 18, 15:50    [21668320]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
aleksrov
Member

Откуда:
Сообщений: 899
Хотя как факт все таки проще конечно намного хранить, ETL проще и все таки если хотелки у бизнеса изменется проще делать анализ в разрезе клиента\сотрудника по коментам.
Вопрос только в звонки упирается.
К тому же разумеется комента есть от силы у 10% звонков.
7 сен 18, 16:03    [21668336]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
aleksrov
Member

Откуда:
Сообщений: 899
Как я понимаю вы это имели ввиду
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 обычный.
7 сен 18, 16:25    [21668364]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30486
Блог
Модель куба будет зависеть только от того, что хотят пользователи.
Можно их вообще в куб не класть, а сделать действие детализации.
7 сен 18, 19:22    [21668568]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
tarrus
Member

Откуда: Bergen
Сообщений: 726
aleksrov
Как я понимаю вы это имели ввиду
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 обычный.


Тогда чего огород городить? Сделайте обычный отчет и все. Или как Критик предлагает.

Если вам интересно чисто академически, то прочитайте M2M

Там все варианты разжованы
7 сен 18, 20:01    [21668590]     Ответить | Цитировать Сообщить модератору
 Re: Как вы храните комменты?  [new]
aleksrov
Member

Откуда:
Сообщений: 899
tarrus,

Спасибо, сейчас читаю.
Я обычный запрос и буду делать. Вопрос в том, что из источника я не могу брать данные, их очень много (источников) и не все они доступны бывают, в общем сейчас это гемор, поэтому коменты и должны быть тоже в хранилище, но как я понимаю если в кубе мы все ровно не используем их то мы можем спокойно соединить коменты с фактом звонков напрямую и не парится?
Если да то так даже будет быстрее, т.к. если мы в коментах нашил нужное слово (обычно таких строк не много), нам нужно получить до инфу по звонку, SQL скорее всего сделает look и все, разумеется без bridge и прочего это будет быстрее.
8 сен 18, 17:50    [21668945]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить