2 All: постил я это не только сюда, и знаете, в чем отличие местной, да и вообще русской реакции?
В наличии воинствующих лузеров с неадекватной реакцией, не знающих предмета, зато имеющих желание сказать свое "фи" якобы в сторону коммерции. Это роднит их с пенсионерами совковыми.

Реакция на западных форумах:
-О! впечатляет! по какой CRM вы разрабатывали схему?
-А не могли бы вы опубликовать схему в редактируемом формате?

2 Jimmy:
1. С очисткой данных как-то встречаться не приходилось, видимо, потому что эти вопросы решались в учетных системах. Но готов во всеоружии, вплоть до AI-алгоритмов ;)

2. Предыдущие проекты выработали такой подход: если клиенту важно наличие истории положения элементов, то она делается следующим образом:
При загрузке данных в хранилище положения элементов в иерархии сравниваются с теми, что зафиксированы на последнюю загрузку. Если положение элемента изменилось, то создается новый элемент с новым внутренним для хранилища ID, и новые факты цепляются уже к этому элементу.
Для элементов ММИ, которые могут менять положение, в скобках после наименования или в member properties указывается период актуальности элемента. Впрочем, можно и не указывать - при фильтрации только значащих строк (не NULL) в OLAP-клиенте все равно останутся элементы, актуальные в пределах выбранного по измерению типа Time периода.

Спам - изначально незатребованные предложения коммерческих услуг. Конференция спамится не так ;).
Незаинтересованные спокойно могут не читать этот топик.

Описание хода проекта - вполне себе самостоятельный жанр и имеет высокую ценность, для тех, кто понимает.
Не я его придумал.

А визжать начал CatTail, которому я, видимо, где-то раньше наступил на хвост.

2 Dedugan
Спасибо за конкретику.

>Uvazhaemii lubimov.
>
>Vopros vami zatronutii interesen ne tolko publike s kirillitsei >na klaviature :-))

Именно. В наших пенатах модно с пеной у рта кричать о спаме, или же критиковать саму концепцию OLAP, как будто я ее придумал, вместо изучения и внедрения современной аналитической технологии. $)

>Po delu. Iz predtavlenoi shemi ne yasno kak ustroeni kubi - >nelzya li privest skrinshoti iz Olap-Administrator a ne etot ?>nechitaemii *.png file.

Кубы можно в полном цвете посмотреть на http://www.1bi.ru/acc_bi_crm.html

>Interesno kak butet zhit vashe reshenie na ~4.000.000 >tablitsah faktov i chto esche interesnee, esli u vas >nomenklatura okolo 100.000 da i dokumentov stolko zhe, A >server samii sho ni na est srednestatisticheskii.

Есть опыт на проекте примерно с такими показателями, только 100000 не номенклатура, а клиентура. Живет и дышит. Факты делятся по годовым или квартальным партициям, гигантские измерения - для обхода ограничений в 64К элементов дробятся служебным промежуточным слоем. Нижний уровень таких измерений обычно пользователю не показывается, т.к. дриллдаун на него может прочно подвесить систему.
Правда серверы - совсем не средние, а рэковые четырехпроцессорные Xeon-Compaq-и, с парой гиг памяти, какие могут себе позволить америкосы. ;)

>Kak vi reshaete problemu (OLAP i MDX) pokaza dimension >elementov, kotorie ne imeut dlya dannogo sochetaniya >slicers faktov, no mogli bi. U vas gruppi tovarov i tovari >yavlyayutsya raznimi izmereniyami

Долго бились над этой проблемой. Решений найдено два:
1. Добавлять по нулевому факту на каждое возможное пересечение.
2. Делать спецкубы для отражения возможных связей, где таблица фактов - содержит каждую возможную связь отдельной записью. Затем эти кубы объединяются в виртуальные с основными.

На практике пользователи часто готовы отказаться от такой информации (показывать возможный факт), если с ними аргументированно поспорить.

Нет, у нас группы товаров входят в иерархию Товар.Товар.
А вот разные аналитические признаки - отдельными иерархиями Товар.*
См. картинки на сайте.

Андрей Любимов.

2 boogier: стратегия выбора вида измерения хорошо описана в BOL и RK SQL Server 2000.

ну вот, век живи - век учись.
у меня нет опыта применения MDX для получения данных - этим занимается клиентское ПО, а на MDX я делаю элементы кубов.

http://www.1bi.ru/acc_bi_crm.html

Да сплошь и рядом - продажи ведутся в одной системе, маркетинг - в другой, логистика в третьей.
Целая наука сейчас на подъеме - EAI назвается.
Интеграция корпоративных приложений то есть.

Общие справочники, это тяжело применимо для тиражных систем.
Хотя бы единые внутренние коды товаров. ИНН для юрлица, ФИО и адрес для физлица.

AI - ИИ, искуственный интеллект. Есть кейс по получению данных по адресам из вручную заполненных анкет. Делал не я, но могу отослать в нужную контору.

Товарищ Мазай, неужели не заметно, что ветку я создал?
И тематические ответы только я делал?

Я в курсе, что настоящим программистам не нужны ни менеджеры, ни проекты, ни заказчики ;)
А 45 постов - совсем не монструозный топик, по моим меркам ;) Заодно и энжин тестируется ;)

Очень приятно, Дед Мазай, меня зовут Андрей Любимов.
Остается только пасть ниц пред вашей подчеркнутой вежливостью....
В треп топик превратили ваши аналоги, которые вместо мыслей по теме выражают свое отношение к автору & теме и рекомендации, где этот топик лучше вести.
Спасибо, это очень ценные сведения.