Показать сообщение отдельно
Старый 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).