|
28.12.2016, 13:38 | #1 |
Участник
|
Исходные данные разбросаны по разным системам, а функциональные слои для сбора, склейки, чистки, подготовки, агрегирования, анализа, визуализации данных лежат внутри одного продукта. В чем противоречие?
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
28.12.2016, 13:51 | #2 |
Участник
|
Цитата:
для данных есть слой обеспечения доступа к данным. этот слой вряд ли может находится не в разбросанных системах. по крайней мере, я хотел бы увидеть обоснование ) просто в формулировке не хватает слова ODBC или какой-нибудь другой провайдер данных. но формулировка станет уже другой ) контрпример - данные "разбросаны" в Lotus Notes. Каким должно быть утверждение, чтобы оставаться хотя бы не ложным? upd: контрпример2 - данные "разбросаны" по традиционным реляционным поставщикам. Но связь между ними происходит очень асинхронно и редко. Например, данные с военных городков, где интернета нет в принципе, а связь осуществляется фельдъегерями на собачьих упряжках. Или, например, данные с ноутбуков ремонтных бригад, которые занимаются обслуживанием газовой трубы. 2. системы, предоставляющие исходные данные, как правило, содержат свои бизнес-правила для валидации и поддержки целостности данных. Причем таких бизнес-правил может быть очень много. в данной формулировке подчеркивается, что "сбора, склейки, чистки, подготовки, агрегирования, анализа, визуализации данных лежат внутри одного продукт". но не говорится о том, что поддерживаются бизнес-правила чужих систем. Другими словами, говорится, что в Qlik нужно пересоздавать бизнес-правила поддержки целостности, которые уже реализованы во внешних системах. Зная трудоемкость разработки таких бизнес-правил, начинаешь сомневаться в необходимости затрат на ПЕРЕСОЗДАНИЕ. в любом продукте. и т.д. Повторюсь, я отлично понимаю, что Nordic хотел сказать. Я утверждаю, что "существующая формулировка требует доработки, чтобы не коробило от внутренних противоречий." Последний раз редактировалось mazzy; 28.12.2016 в 14:07. |
|
28.12.2016, 14:36 | #3 |
Участник
|
Цитата:
Цитата:
Цитата:
Сообщение от mazzy
системы, предоставляющие исходные данные, как правило, содержат свои бизнес-правила для валидации и поддержки целостности данных. Причем таких бизнес-правил может быть очень много. в данной формулировке подчеркивается, что "сбора, склейки, чистки, подготовки, агрегирования, анализа, визуализации данных лежат внутри одного продукт". но не говорится о том, что поддерживаются бизнес-правила чужих систем. Другими словами, говорится, что в Qlik нужно пересоздавать бизнес-правила поддержки целостности, которые уже реализованы во внешних системах.
Это спор с самим собой |
|
28.12.2016, 15:00 | #4 |
Участник
|
?!
для дальнейшего обсуждения, предположим что ты прав и как твои слова должны отразиться на исходном утверждении? Цитата:
как согласуются твои слова "Так вот, в Qlik - все эти слои лежат внутри одного продукта" ))) Цитата:
а контрпример не доказывает. контрпример опровергает утверждение "Так вот, в Qlik - все эти слои лежат внутри одного продукта." )))))) Цитата:
Сообщение от gl00mie
Не буду говорить за все системы, предоставляющие исходные данные, но по опыту Аксапты, в них обычно содержатся правила валидации и поддержки целостности для вводимых данных, когда те из условных журналов трансформируются в проводки. Для проводок же подобных бизнес-правил поддержки целостности обычно либо намного меньше, либо нет вовсе.
иначе не советовали бы пользоваться только семейством классов inventMov* для создания складских проводок иначе не советовали бы пользоваться только семейством FormLetter для создания документов контрагентам про производство и сводное планирование уж и говорить не стоит. причем не только для ВВОДИМЫХ данных. Нет, правил очень много. Причем как правило идет дикая смесь бизнес-логики c чисто техническими аспектами поддержки целостности нормализованных данных. Цитата:
Цитата:
Сообщение от gl00mie
Отсюда, утверждение, что "в Qlik нужно пересоздавать бизнес-правила поддержки целостности, которые уже реализованы во внешних системах", я лично считаю неверным (для любой BI-системы) при условии, что в качестве исходных берутся данные "проводок", а не "журналов".
Это спор с самим собой я утверждаю ровно то что уже написал: "существующая формулировка требует доработки, чтобы не коробило от внутренних противоречий." Последний раз редактировалось mazzy; 28.12.2016 в 15:03. |
|
28.12.2016, 15:06 | #5 |
Модератор
|
Это так, только если мы говорим про небольшие проекты. Да, если ты решаешь задачу одного отдела - Продаж, Маркетинга, Закупок - то да, приемка у тебя идет на уровне руководства данным отделом. Да ито - еще надо финансистов надо убедить, закупки, руководство... Но дело в том, что в последнее время я встречаюсь с проектами, которые гораздо больше виденных мною на DAX. И тут все гораздо сложнее - и много отделов, и уровней приемки.
Цитата:
Цитата:
Сообщение от mazzy
системы, предоставляющие исходные данные, как правило, содержат свои бизнес-правила для валидации и поддержки целостности данных. Причем таких бизнес-правил может быть очень много.
в данной формулировке подчеркивается, что "сбора, склейки, чистки, подготовки, агрегирования, анализа, визуализации данных лежат внутри одного продукт". но не говорится о том, что поддерживаются бизнес-правила чужих систем. Другими словами, говорится, что в Qlik нужно пересоздавать бизнес-правила поддержки целостности, которые уже реализованы во внешних системах. Зная трудоемкость разработки таких бизнес-правил, начинаешь сомневаться в необходимости затрат на ПЕРЕСОЗДАНИЕ. в любом продукте. Но я понимаю, о чем ты говоришь - про RLS. Да, если есть разграничение доступа к данным или настроен RLS, то любой ETL, включая Qlik, вытащат все доступные им данные. И, если надо будет пользователям снова обеспечить разграничение по данным, то придется дублировать структуру разграничения доступа. Обычно это делается созданием отдельно справочника разграничения прав доступа и заливкой в него данных из таблиц, отвечающих за доступ. Да, тут есть важное "но!" Если в учетных системах требуется RLS вот как сейчас - т.е. ты же не разграничивешь права доступа "как они были год назад", то вот в BI мне пришлось столкнуться с очень непростым проектом, когда заказчик просил вот этому пользователю "заливать данные по март, а потом - в соответсвии с новыми правами". Пришлось делать иерархию прав, закачивать историчность доступа, потом грузить данные и резать их в соответствии с залитыми ограничениями. Часто такое в банках есть, самое простое - это CRM. Вот менеджеры, вот права. Залили менеджеров, права, и нарубили исходник на группы. А вот с аудитом работы - не просто кто с чем имеет право работать, а кто что открывал и копировал в буфер - там посложнее. Но и это решается. Вот как бывает. С Уважением, Георгий |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
28.12.2016, 15:12 | #6 |
Участник
|
Цитата:
Сообщение от George Nordic
Это так, только если мы говорим про небольшие проекты. Да, если ты решаешь задачу одного отдела - Продаж, Маркетинга, Закупок - то да, приемка у тебя идет на уровне руководства данным отделом. Да ито - еще надо финансистов надо убедить, закупки, руководство... Но дело в том, что в последнее время я встречаюсь с проектами, которые гораздо больше виденных мною на DAX. И тут все гораздо сложнее - и много отделов, и уровней приемки.
Цитата:
ведь в ходе очистки могут произойти и вставки данных. хотя бы "дефолтных". с остальным - согласен. про права - понял. |
|
28.12.2016, 23:46 | #7 |
Участник
|
Цитата:
1) кв - отличный инструмент для хранения данных, его файлы квд могут служить промежуточным (staging) хранилищем, скажем, для случаев инкрементной загрузки (дельта). один файл, сжатый, зашифрованный, скорость загрузки из него - наивысшая. 2) кв - отличный инструмент для проверки целостности данных. ему плевать на бизнес-правила, ибо би-ай не имеет цели сохранять транзацкии согласно моральному закону внутри нас, а наоборот, достигать космических скоростей вращения любых данных вокруг своего фаркопа. грубо говоря, если стоит задача, например, мигрировать со старой ерп на ту же аксапту и нужно перетащить или добавить некоторые данные, например, для дополнения или корректировки тех же остатков, то сценарий крайне прост. засосал все таблицы в кв, открутил их там как бог черепаху и давай подгружать, чего душеньке угодно. ещё раз: никаких правил, sky is limit. пример из жизни. медицинская компания ведёт учёт обращений застрахованных предприятий по целой куче показателей, вроде кровяного давления и т.п. при этом медицинские показатели, обращения существующих клиентов, выставление счетов и работа над продажами ведётся в четырёх специально заточенных системах (основная система - аксапта). каждый регион учитывается отдельно. пообщавшись с одним представителем от каждого отдела, через три недели представили работающее решение с системой доступа к данным в разрезе регионов, автоматической доставкой отчётов, возможностью доступа ко всей визуализации с мобил, а вишенка на торте - найденная во время анализа (вот тут первый раз и появились на сцене их "бизнес-правила") дыра в их данных. размер дыры был чуть больше миллиона. руку жали, провожали, всё, как в песне было. особенность проекта была в том, что в силу конфиденциальности персональных данных невозможно было получить доступ к живым базам. поэтому были созданы семплы всех нужных таблиц, в них перебиты все реальные персональные данные (фио, адреса, коды страхования и прочие телефоны), и вся разработка велась на "кошках". потом просто перенесли один единственный файл со скриптами и визуализациями и запустили -- скрипты подхватили строки подключения из внешнего файла, и всё заверте... вы когда-нибудь за три недели миллион долларов находили?
__________________
Felix nihil admirari |
|
|
За это сообщение автора поблагодарили: gl00mie (3). |
28.12.2016, 15:13 | #8 |
Модератор
|
Цитата:
Сообщение от mazzy
upd: контрпример2 - данные "разбросаны" по традиционным реляционным поставщикам. Но связь между ними происходит очень асинхронно и редко.
Например, данные с военных городков, где интернета нет в принципе, а связь осуществляется фельдъегерями на собачьих упряжках. Или, например, данные с ноутбуков ремонтных бригад, которые занимаются обслуживанием газовой трубы. Не надо в BI пихать "внутренные расчеты". Зачем дублировать упомянутый тобой InventMoment*, когда можно забрать итоговый InventSum??? С Уважением, Георгий |
|
28.12.2016, 22:38 | #9 |
Участник
|
имея конкретный практический опыт нескольких успешных проектов, могу ответить на конкретные вопросы.
вкратце, кликвью - бомба, жрёт всё подряд и быстро, имеет все необходимые инструменты для скриптов, поддержки, деплоймента, безопасности доступа, и всё в одном внутри себя. иммануил кант был бы в восторге (звёздное небо внутри нас и никаких моральных законов)
__________________
Felix nihil admirari Последний раз редактировалось wojzeh; 28.12.2016 в 23:24. |
|
28.12.2016, 23:57 | #10 |
Аманд
|
Цитата:
Сообщение от wojzeh
имея конкретный практический опыт нескольких успешных проектов, могу ответить на конкретные вопросы.
вкратце, кликвью - бомба, жрёт всё подряд и быстро, имеет все необходимые инструменты для скриптов, поддержки, деплоймента, безопасности доступа, и всё в одном внутри себя. иммануил кант был бы в восторге (звёздное небо внутри нас и никаких моральных законов) |
|
|
За это сообщение автора поблагодарили: BIDeveloper (1). |
29.12.2016, 00:03 | #11 |
Участник
|
Цитата:
Сообщение от Vals
Эту штуку пробовал? http://sisense.com/
вкратце вот с их же сайта и блэк маджик квадрант
__________________
Felix nihil admirari Последний раз редактировалось wojzeh; 29.12.2016 в 00:08. Причина: забыл ссылку на gartner |
|
29.12.2016, 00:30 | #12 |
Аманд
|
|
|
Теги |
qlik |
|
|