AXForum  
Вернуться   AXForum > BI > BI: Общий раздел
CRM
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.12.2016, 13:21   #1  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Чем Qlik похож на Axapta
Выделено отсюда: Бесплатное обучение для форумчан BI-системе Qlik 21 января 2015 года
Цитата:
Сообщение от wojzeh Посмотреть сообщение
хе-хе! меня-то за советскую власть можно не агитировать - я ж сертифицированный дев и дизайнер и фанат номер один этой штуки. очень давно не испытывал подобного кайфа от софтины.
Кстати, только недавно сформулировал, что мне так понравилось в Qlik. Две основные причины:

I. Быстро. Вернее, ОЧЕНЬ быстро. Ну, ты-то и сам знаешь, а для коллег - объясню: использование Qlik позволяет быстро получить итоговый результат. Ну, тут и в целом результаты в большинстве BI получаются гораздо быстрее (и нагляднее), чем в учетных системах. Но, все-таки, обычно, чтобы получить конечный результат, надо сделать кучу работы в разных системах.
1й слой: ETL - собирает данные из разных систем.
2й слой: А как их клеить? Что является мастер-данными, ключом, "золотой записью?" Хорошо, когда есть единая мастер-система - 1С, DAX, NAV. Но, бывает, данные разбросаны и их надо между собой корректно увязать - тут возникают вопросы управления справочной информацией (НСИ) и мастер-данными - это уже класс MDM систем.
3й слой: Возникают вопросы к качеству извлеченных данных - данные нужно чистить, убирать дубликаты, убирать выбросы, восстанавливать - например, интерполировать нулевые значения до средних и т.д. - DQM.
4й слой: Хранение данных - DHW. Извлеченные и трансформированные данные надо где-то хранить. Иногда это "классическое" хранилище данных или витрины в хранилище - но, в большинстве случает, основное предназначение подобных хранилищ это не подготовка данных к анализу, а хранение исторических данных или интеграция нескольких систем.
5й слой: Подготовка данных к аналитике - группировка, агрегация, построение срезов данных, расчетные показатели, простановка флагов и т.д. Фактически, на этом этапе строится аналитическое хранилище данных, многим известна, например, OLAP - технология ("кубы") - это оно.
6й слой: Портал. Т.к. мы живем в 21м веке, то многие хотят видеть результат на мобильном устройстве. Значит, надо постараться чтобы аналитические витрины были доступны (желательно, в красивом виде) с разных устройств.
7й слой: Визуализация. Здесь аналитик уже рисует аналитические отчеты, дашборды, KPI и т.д.

Так вот, в Qlik - все эти слои лежат внутри одного продукта. Стал строить витрину, каких-то данных нехватает - нажал Ctrl+E, открыл загрузку, загрузил и давай дальше строить. Данные кривые - прямо в загрузчике можно писать алгоритмы по чистке данных, маппингу и т.д. Данный подход очень много времени экономит - обычно очень много времени и трудозатрат приходится на интеграцию систем и "прокидывания" данных между ними. Ну и поиска ошибок еще - в каком слое косяк.

Тоже самое было в Axapta - мне не нужна была никакая другая система для решения задач немаленького, в общем-то, предприятия. Новый модуль можно было написать очень быстро - WMS (ну, или не очень быстро, но с чего-то начать а потом доделывать), ТСД оператора производства, портал поставщика, розницу допилить... Да, не стоило писать проектирование изделий (CAD) или календарное планирование (Project) - но с ними можно было легко интегрироваться. Хранилище? Да у меня в DAX вся информация лежала, не было большой надобности в отдельном DWH. Т.е. скорость разработки в DAX - просто поражала. Хотя, конечно, это имело и свои отрицательные последствия.

II Многооконность. Какой же кайф был открыть одно окно и получить в соседнем все связанные значения. Прям как в Qlik - выбираешь значения в одних фильтрах / закладках и видишь связанные значения во всех остальных. Т.е. видны не просто данные, а их связь.

Так что между продуктами много общего есть, на мой взгляд.

С Уважением,
Георгий
За это сообщение автора поблагодарили: mazzy (2), alex55 (1).
Старый 28.12.2016, 13:30   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Причина одна - меньше народа задействовано при сдаче результата. )

Чем меньше, тем легче подписать акт.
Можешь бизнес-консультантов спросить - они сдают только владельцам.
Или тренеров по личностному росту - там вообще только одному человеку )


Цитата:
Сообщение от George Nordic Посмотреть сообщение
Но, бывает, данные разбросаны и их надо между собой корректно увязать
...
в Qlik - все эти слои лежат внутри одного продукта.
эти два тезиса логически противоречат друг-другу.
да, понятно что ты хотел сказать.
но существующая формулировка требует доработки, чтобы не коробило от внутренних противоречий.
Старый 28.12.2016, 13:38   #3  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Исходные данные разбросаны по разным системам, а функциональные слои для сбора, склейки, чистки, подготовки, агрегирования, анализа, визуализации данных лежат внутри одного продукта. В чем противоречие?
За это сообщение автора поблагодарили: mazzy (2).
Старый 28.12.2016, 13:42   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
И еще.
Цитата:
Сообщение от George Nordic Посмотреть сообщение
объясню: использование Qlik позволяет быстро получить итоговый результат.
Qlik позволяет быстро получить промежуточный результат.
результат, который можно показать в качестве Proof of Concept
да, в области BI часто этого уже достаточно.

но итоговый?
В ERP под итоговым результатом подразумевается нечто, включающее и согласованное оформление результата, и защиту от дурака, и диагностику ошибок и т.д.
стоит ли использовать настолько толстую подмену понятий?

Полностью был бы согласен с формулировкой:
"Qlik позволяет быстро получить результат."

)))
Старый 28.12.2016, 13:51   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Исходные данные разбросаны по разным системам, а функциональные слои для сбора, склейки, чистки, подготовки, агрегирования, анализа, визуализации данных лежат внутри одного продукта. В чем противоречие?
1.
для данных есть слой обеспечения доступа к данным.
этот слой вряд ли может находится не в разбросанных системах.
по крайней мере, я хотел бы увидеть обоснование )

просто в формулировке не хватает слова ODBC или какой-нибудь другой провайдер данных.
но формулировка станет уже другой )

контрпример - данные "разбросаны" в Lotus Notes. Каким должно быть утверждение, чтобы оставаться хотя бы не ложным?

upd: контрпример2 - данные "разбросаны" по традиционным реляционным поставщикам. Но связь между ними происходит очень асинхронно и редко.
Например, данные с военных городков, где интернета нет в принципе, а связь осуществляется фельдъегерями на собачьих упряжках.
Или, например, данные с ноутбуков ремонтных бригад, которые занимаются обслуживанием газовой трубы.

2.
системы, предоставляющие исходные данные, как правило, содержат свои бизнес-правила для валидации и поддержки целостности данных. Причем таких бизнес-правил может быть очень много.

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

Другими словами, говорится, что в Qlik нужно пересоздавать бизнес-правила поддержки целостности, которые уже реализованы во внешних системах. Зная трудоемкость разработки таких бизнес-правил, начинаешь сомневаться в необходимости затрат на ПЕРЕСОЗДАНИЕ. в любом продукте.

и т.д.

Повторюсь, я отлично понимаю, что Nordic хотел сказать.
Я утверждаю, что "существующая формулировка требует доработки, чтобы не коробило от внутренних противоречий."

Последний раз редактировалось mazzy; 28.12.2016 в 14:07.
Старый 28.12.2016, 14:36   #6  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
для данных есть слой обеспечения доступа к данным.
этот слой вряд ли может находится не в разбросанных системах. контрпример - данные "разбросаны" в Lotus Notes. Каким должно быть утверждение, чтобы оставаться хотя бы не ложным?
Насколько я помню семинар по Qlik, в нем есть открытый API для написания адаптеров доступа к данным. На счет Lotus Notes не скажу, но как минимум для 1С такой адаптер на 2015 год имелся, так что Qlik'у достаточно было доступа к базе 1С, без прослойки в виде платформы 1С.
Цитата:
Сообщение от mazzy Посмотреть сообщение
контрпример2 - данные "разбросаны" по традиционным реляционным поставщикам. Но связь между ними происходит очень асинхронно и редко. Например, данные с военных городков, где интернета нет в принципе, а связь осуществляется фельдъегерями на собачьих упряжках.
И что доказывает этот контрпример? Что в Qlik нет функционального слоя "фельдъегерская служба"?.. Как в контексте данного контрпримера будут работать другие BI-решения? Почему-то вспоминаются суровые сибирские мужики и железобетонная шпала...
Цитата:
Сообщение от mazzy Посмотреть сообщение
системы, предоставляющие исходные данные, как правило, содержат свои бизнес-правила для валидации и поддержки целостности данных. Причем таких бизнес-правил может быть очень много. в данной формулировке подчеркивается, что "сбора, склейки, чистки, подготовки, агрегирования, анализа, визуализации данных лежат внутри одного продукт". но не говорится о том, что поддерживаются бизнес-правила чужих систем. Другими словами, говорится, что в Qlik нужно пересоздавать бизнес-правила поддержки целостности, которые уже реализованы во внешних системах.
Мне кажется, тут имеет место подмена понятий Не буду говорить за все системы, предоставляющие исходные данные, но по опыту Аксапты, в них обычно содержатся правила валидации и поддержки целостности для вводимых данных, когда те из условных журналов трансформируются в проводки. Для проводок же подобных бизнес-правил поддержки целостности обычно либо намного меньше, либо нет вовсе. Если BI-система в качестве исходных данных использует проводки, то нет необходимости в BI-системе применять к ним те же правила валидации и проверки целостности, какие применялись при формировании этих проводок из журналов в системе-источнике. Но может быть необходимость применять новые правила валидации и контроля целостности, которых в системе-источнике не было. Отсюда, утверждение, что "в Qlik нужно пересоздавать бизнес-правила поддержки целостности, которые уже реализованы во внешних системах", я лично считаю неверным (для любой BI-системы) при условии, что в качестве исходных берутся данные "проводок", а не "журналов".
Цитата:
Сообщение от mazzy Посмотреть сообщение
Зная трудоемкость разработки таких бизнес-правил, начинаешь сомневаться в необходимости затрат на ПЕРЕСОЗДАНИЕ. в любом продукте.
Это спор с самим собой
Старый 28.12.2016, 15:00   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
?!

для дальнейшего обсуждения, предположим что ты прав
и как твои слова должны отразиться на исходном утверждении?

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Насколько я помню семинар по Qlik, в нем есть открытый API для написания адаптеров доступа к данным. На счет Lotus Notes не скажу, но как минимум для 1С такой адаптер на 2015 год имелся, так что Qlik'у достаточно было доступа к базе 1С, без прослойки в виде платформы 1С.
возможно что QLIK'у достаточно.
как согласуются твои слова "Так вот, в Qlik - все эти слои лежат внутри одного продукта"
)))

Цитата:
Сообщение от gl00mie Посмотреть сообщение
И что доказывает этот контрпример? Что в Qlik нет функционального слоя "фельдъегерская служба"?.. Как в контексте данного контрпримера будут работать другие BI-решения?
а чё ты стрелки то переводишь? слабо говорить только про Клик в теме про Клик? ))))

а контрпример не доказывает.
контрпример опровергает утверждение "Так вот, в Qlik - все эти слои лежат внутри одного продукта."
))))))

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Не буду говорить за все системы, предоставляющие исходные данные, но по опыту Аксапты, в них обычно содержатся правила валидации и поддержки целостности для вводимых данных, когда те из условных журналов трансформируются в проводки. Для проводок же подобных бизнес-правил поддержки целостности обычно либо намного меньше, либо нет вовсе.
конечно же ты не прав ))))
иначе не советовали бы пользоваться только семейством классов inventMov* для создания складских проводок
иначе не советовали бы пользоваться только семейством FormLetter для создания документов контрагентам

про производство и сводное планирование уж и говорить не стоит.
причем не только для ВВОДИМЫХ данных.

Нет, правил очень много.
Причем как правило идет дикая смесь бизнес-логики c чисто техническими аспектами поддержки целостности нормализованных данных.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Если BI-система в качестве исходных данных использует проводки, то нет необходимости в BI-системе применять к ним те же правила валидации и проверки целостности
Даже после чистки и другой "подготовка данных к аналитике - группировка, агрегация, построение срезов данных, расчетные показатели, простановка флагов и т.д"?

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Отсюда, утверждение, что "в Qlik нужно пересоздавать бизнес-правила поддержки целостности, которые уже реализованы во внешних системах", я лично считаю неверным (для любой BI-системы) при условии, что в качестве исходных берутся данные "проводок", а не "журналов".
Это спор с самим собой
Ok. Как скажешь.

я утверждаю ровно то что уже написал:
"существующая формулировка требует доработки, чтобы не коробило от внутренних противоречий."

Последний раз редактировалось mazzy; 28.12.2016 в 15:03.
Старый 28.12.2016, 15:06   #8  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от mazzy Посмотреть сообщение
Причина одна - меньше народа задействовано при сдаче результата
Это так, только если мы говорим про небольшие проекты. Да, если ты решаешь задачу одного отдела - Продаж, Маркетинга, Закупок - то да, приемка у тебя идет на уровне руководства данным отделом. Да ито - еще надо финансистов надо убедить, закупки, руководство... Но дело в том, что в последнее время я встречаюсь с проектами, которые гораздо больше виденных мною на DAX. И тут все гораздо сложнее - и много отделов, и уровней приемки.
Цитата:
Сообщение от mazzy Посмотреть сообщение
1.для данных есть слой обеспечения доступа к данным.
этот слой вряд ли может находится не в разбросанных системах.
по крайней мере, я хотел бы увидеть обоснование )
Да, есть слой для обеспечения к доступам. Это или ODBC / OLEDB / REST / табличные форматы, или готовые коннекторы (к SAP, SalesForce, Teradata, Informatica, Cloudera и т.д.) или написанные партнерами (например, к 1C, R или Hadoop), или открытый API для разработки собственных коннекторов.
Цитата:
Сообщение от mazzy Посмотреть сообщение
системы, предоставляющие исходные данные, как правило, содержат свои бизнес-правила для валидации и поддержки целостности данных. Причем таких бизнес-правил может быть очень много.

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

Другими словами, говорится, что в Qlik нужно пересоздавать бизнес-правила поддержки целостности, которые уже реализованы во внешних системах. Зная трудоемкость разработки таких бизнес-правил, начинаешь сомневаться в необходимости затрат на ПЕРЕСОЗДАНИЕ. в любом продукте.
Это не дело ETL. Это отдельная задача определенного класса BI, валидация данных до конечного результата, включая валидацию прав данных. Не надо дублировать бизнес-правила и внутреннию валидацию данных. BI должен показать, какие данные есть, и уже бизнес должен решать, что с ними делать. Или технические специалисты - почему так произошло. Но BI может взять и "сырые" данные, и "прошедшие внутренюю обработку" - смотря что за задачу ты ставишь.

Но я понимаю, о чем ты говоришь - про RLS. Да, если есть разграничение доступа к данным или настроен RLS, то любой ETL, включая Qlik, вытащат все доступные им данные. И, если надо будет пользователям снова обеспечить разграничение по данным, то придется дублировать структуру разграничения доступа. Обычно это делается созданием отдельно справочника разграничения прав доступа и заливкой в него данных из таблиц, отвечающих за доступ.

Да, тут есть важное "но!" Если в учетных системах требуется RLS вот как сейчас - т.е. ты же не разграничивешь права доступа "как они были год назад", то вот в BI мне пришлось столкнуться с очень непростым проектом, когда заказчик просил вот этому пользователю "заливать данные по март, а потом - в соответсвии с новыми правами". Пришлось делать иерархию прав, закачивать историчность доступа, потом грузить данные и резать их в соответствии с залитыми ограничениями.

Часто такое в банках есть, самое простое - это CRM. Вот менеджеры, вот права. Залили менеджеров, права, и нарубили исходник на группы. А вот с аудитом работы - не просто кто с чем имеет право работать, а кто что открывал и копировал в буфер - там посложнее. Но и это решается. Вот как бывает.

С Уважением,
Георгий
За это сообщение автора поблагодарили: mazzy (2).
Старый 28.12.2016, 15:12   #9  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Это так, только если мы говорим про небольшие проекты. Да, если ты решаешь задачу одного отдела - Продаж, Маркетинга, Закупок - то да, приемка у тебя идет на уровне руководства данным отделом. Да ито - еще надо финансистов надо убедить, закупки, руководство... Но дело в том, что в последнее время я встречаюсь с проектами, которые гораздо больше виденных мною на DAX. И тут все гораздо сложнее - и много отделов, и уровней приемки.
ok. услышал. надо подумать.

Цитата:
Сообщение от George Nordic Посмотреть сообщение
Не надо дублировать бизнес-правила и внутреннию валидацию данных.
даже ПОСЛЕ процедур очистки данных?
ведь в ходе очистки могут произойти и вставки данных. хотя бы "дефолтных".

с остальным - согласен.
про права - понял.
Старый 28.12.2016, 15:13   #10  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от mazzy Посмотреть сообщение
upd: контрпример2 - данные "разбросаны" по традиционным реляционным поставщикам. Но связь между ними происходит очень асинхронно и редко.
Например, данные с военных городков, где интернета нет в принципе, а связь осуществляется фельдъегерями на собачьих упряжках.
Или, например, данные с ноутбуков ремонтных бригад, которые занимаются обслуживанием газовой трубы.
Смысл этого утверждения? А баба Нюра складской журнал в тетрадке ведет. Есть данные - BI должен их достать и дать конечный результат (Визуализацию, отчеты) максимально быстро. И дать знать, что части данных нехватает. Или он некорректные.

Не надо в BI пихать "внутренные расчеты". Зачем дублировать упомянутый тобой InventMoment*, когда можно забрать итоговый InventSum???

С Уважением,
Георгий
Старый 28.12.2016, 22:38   #11  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
672 / 512 (19) +++++++
Регистрация: 27.04.2006
Адрес: Montreal
имея конкретный практический опыт нескольких успешных проектов, могу ответить на конкретные вопросы.

вкратце, кликвью - бомба, жрёт всё подряд и быстро, имеет все необходимые инструменты для скриптов, поддержки, деплоймента, безопасности доступа, и всё в одном внутри себя. иммануил кант был бы в восторге (звёздное небо внутри нас и никаких моральных законов)
__________________
Felix nihil admirari

Последний раз редактировалось wojzeh; 28.12.2016 в 23:24.
Старый 28.12.2016, 23:46   #12  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
672 / 512 (19) +++++++
Регистрация: 27.04.2006
Адрес: Montreal
Цитата:
Сообщение от mazzy Посмотреть сообщение
ok. услышал. надо подумать.


даже ПОСЛЕ процедур очистки данных?
ведь в ходе очистки могут произойти и вставки данных. хотя бы "дефолтных".

с остальным - согласен.
про права - понял.
пара центов в беседу джентльменов:

1) кв - отличный инструмент для хранения данных, его файлы квд могут служить промежуточным (staging) хранилищем, скажем, для случаев инкрементной загрузки (дельта). один файл, сжатый, зашифрованный, скорость загрузки из него - наивысшая.

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

грубо говоря, если стоит задача, например, мигрировать со старой ерп на ту же аксапту и нужно перетащить или добавить некоторые данные, например, для дополнения или корректировки тех же остатков, то сценарий крайне прост. засосал все таблицы в кв, открутил их там как бог черепаху и давай подгружать, чего душеньке угодно. ещё раз: никаких правил, sky is limit.

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

пообщавшись с одним представителем от каждого отдела, через три недели представили работающее решение с системой доступа к данным в разрезе регионов, автоматической доставкой отчётов, возможностью доступа ко всей визуализации с мобил, а вишенка на торте - найденная во время анализа (вот тут первый раз и появились на сцене их "бизнес-правила") дыра в их данных. размер дыры был чуть больше миллиона. руку жали, провожали, всё, как в песне было.

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


вы когда-нибудь за три недели миллион долларов находили?
__________________
Felix nihil admirari
За это сообщение автора поблагодарили: gl00mie (3).
Старый 28.12.2016, 23:57   #13  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,765 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
Сообщение от wojzeh Посмотреть сообщение
имея конкретный практический опыт нескольких успешных проектов, могу ответить на конкретные вопросы.

вкратце, кликвью - бомба, жрёт всё подряд и быстро, имеет все необходимые инструменты для скриптов, поддержки, деплоймента, безопасности доступа, и всё в одном внутри себя. иммануил кант был бы в восторге (звёздное небо внутри нас и никаких моральных законов)
Эту штуку пробовал? http://sisense.com/
За это сообщение автора поблагодарили: BIDeveloper (1).
Старый 29.12.2016, 00:03   #14  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
672 / 512 (19) +++++++
Регистрация: 27.04.2006
Адрес: Montreal
Цитата:
Сообщение от Vals Посмотреть сообщение
Эту штуку пробовал? http://sisense.com/
нет, никогда. даже не слышал.

вкратце вот с их же сайта
Название: QV_VS_SIS.png
Просмотров: 3634

Размер: 66.7 Кб



и блэк маджик квадрант
__________________
Felix nihil admirari

Последний раз редактировалось wojzeh; 29.12.2016 в 00:08. Причина: забыл ссылку на gartner
Старый 29.12.2016, 00:37   #16  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
672 / 512 (19) +++++++
Регистрация: 27.04.2006
Адрес: Montreal
Цитата:
Сообщение от Vals Посмотреть сообщение
Могу устроить тестдрайв и демо
оффтопик - это грех!

чего-чего, а драйва и демо у кв - хоть на зиму в банки закатывай. ограничение одно - нельзя делиться своими файлами.

кстати, в продолжении предложенной изначально темы, у кв отличная экосистема с форумом и тренингами.
__________________
Felix nihil admirari
Старый 29.12.2016, 02:37   #17  
BIDeveloper is offline
BIDeveloper
Участник
 
26 / 11 (1) +
Регистрация: 27.11.2016
Пора создавать ветку про сравнение BI )
Старый 29.12.2016, 09:12   #18  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Или форум в DynamicsBI переименовать
__________________
Ivanhoe as is..
Старый 10.05.2019, 16:48   #19  
cuba is offline
cuba
Участник
 
346 / 134 (5) +++++
Регистрация: 18.09.2014
Адрес: Kyiv
Да, обсудить некую статью
Например, вот такого плана: https://habr.com/ru/company/newprolab/blog/349186/ или https://habr.com/ru/post/438648/
С т.з. применения BI продукта в семействе продуктов Dynamics
За это сообщение автора поблагодарили: AlGol (2).
Теги
qlik

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Видео и флэш-ролики по Microsoft Axapta 3.0 mazzy Microsoft и системы Microsoft Dynamics 12 30.05.2009 13:17
### Вакансии: программисты, консультанты AXAPTA Metetam Рынок труда Microsoft Dynamics 0 20.12.2006 17:09
### Вакансии: программисты, консультанты AXAPTA (Москва, $1600-3100) Metetam Рынок труда Microsoft Dynamics 3 20.12.2006 17:00
### 4 ВАКАНСИИ: программисты, консультанты AXAPTA Metetam Рынок труда Microsoft Dynamics 1 29.11.2006 12:07
AXAPTA 4.0 задерживается до весны 2006 (eng.) dmit2604 Microsoft и системы Microsoft Dynamics 61 12.03.2005 16:14
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:34.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.