Ведем проект создания тиражного продукта. Это будет Data Warehouse и OLAP-кубы для CRM (оптовые продажи, склад, сервис, и прочее).
Я думаю, многим будет полезно видеть процесс этого.
Уже сейчас можно посмотреть на схему хранилища (70 таблиц) и первые измерения кубов.

Схема: www.1bi.ru/acc_bi/acc_bi_crm_schm.png

Измерения иерархии Клиент: www.1bi.ru/acc_bi/acc_bi_crm_as_customer_dims.gif

контекст: есть хитрая схема из 70 таблиц в MSSQL
задача: нагенерить жизнеподобных тестовых данных во все таблицы с учетом связей

сделано: при помощи Rational TestBytes (продукт уже не производится), рук и такой-то матери.

1 Jason Gross sSgyNHpzZfCyRQYfDOdXXHzFsPIW 47 40 42 2629062005 yhra0flywap@05y3.oi http://lj.3k3clgs.so
2 Michael Oakman iLKTKWXNmwNCulprVdcMVAgsJIVIWJiyo 29 45 46 3117908275 619brt9t@v_q26cigmh.vut http://efo.0gbskmtttww.wll
3 Skye Norling-Christenson yLHeXwDtuzDRwyzCCJmMQiIzVUiNAIJchwwpLX 23 16 12 1045714479 vp@xz0us.iv http://ysz.h2v1.zlm
4 Robert Marley RxcebPhWmzimNZsVSpqyVMXjjxMoDNeFbBkYsRtM 42 8 43 8978516898 7r_@ij3ce8jn.hb http://as.41zna3ps44h1.rst

набил тестовыми данными всю базу
сейчас разрабатываются общие измерения для кубов

А в чем ваши проблемы, CatTail, что с ходу называете это "лабудой"?

Заодно вопрос профи:
мне нужно посчитать разницу в днях или часах между запланированной датой и фактической.
Что получается, если я считаю просто арифметическую разницу между полями типа datetime?

Созданы практически все общие измерения для кубов:
http://www.1bi.ru/acc_bi/acc_bi_crm_dims.gif

Что касается этой темы, то даже в 1С-овской "Торговле и складе" навскидку больше 150 таблиц.

А у меня в хранилище 70, потому что разработка для OLAP/DataWarehousing включает в себя денормализацию и упрощение структур для повышения быстродействия отчетов.

У CatTail-а похоже крупная разработка на SQL - склад метелок в ЖЭУ ;)

Ура,
заработало
теперь можно анализировать опоздание с доставкой клиенту и опоздание с выполнением сервисных заказов ;)

Под предлогом борбы со спамом такие, как вы, сливают излишки половой и отрицательной энергии. Диву даюсь этому племени!
Помимо вас здесь ненужной информации нет.
Голосование по теме "нужен этот топик или нет?" никто не открывал.

Курите в сторонке, плз.

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 постов - совсем не монструозный топик, по моим меркам ;) Заодно и энжин тестируется ;)

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