Comments 5
алгебра операций над данными
Есть какое-то систематизированное описание этого понятия? Может онтология, концепция и т.п. Это как-то можно "притянуть" к МетаТеории связей? Также есть понятие Алгебра процессов (process algebra), но это тоже видимо "не сюда".
Поверх механизма связей в платформе реализован отдельный визуальный инструмент – «Область связей». Это виджет, в который перетаскиваются поля из разных источников, и который отображает их взаимосвязи через справочники и пользовательские связи в виде графа.
Как это пересекается с инструментами Качество данных \ Управление данными?
Есть какое-то систематизированное описание этого понятия? Может онтология, концепция и т.п. Это как-то можно "притянуть" к МетаТеории связей? Также есть понятие Алгебра процессов (process algebra), но это тоже видимо "не сюда".
Про «алгебру операций над данными»: я использовал термин в широком неформальном смысле – обозначая набор операций rapeed над источниками (справочники как виртуальные поля, связи между источниками разной гранулярности, агрегации поверх них). Публичного формализованного описания я у вендора в открытых материалах не встречал.
Как это пересекается с инструментами Качество данных \ Управление данными?
Про пересечение Области связей с Качеством данных и Управлением данными: прямого пересечения нет. Это инструмент data discovery – визуального исследования модели данных, которую пользователь собрал в rapeed. С DQ пересечение косвенное: аномалии в иерархиях Область связей подсвечивает попутно, но это побочный эффект, а не результат проверки правил.
Я правильно понял пример со связью, что оно понимает, что таблица с планами стоит слева, а значит правую таблицу нужно сначала сгруппировать по полю связи, и потом сделать left join ? Я к тому, что если эта операция выражается через группировки и join-ы, то зачем выделяется?
Ещё про управление ресурсами хотел спросить: у вас в сессии выделяется какой-то объём памяти под загрузку таблиц с диска и хранение результатов запроса, чтобы быстро пользователю показывать, или результаты забываются, как только их отдали пользователю?
Ну и про название вам, наверное, уже говорили.
Тут больше вопросы к вендору. Мы не вендор, но передали ему ваши вопросы.
Ответ от вендора: таблицу сначала группировать не нужно. Вы связываете поля по содержимому, тем самым создавая ось агрегации - одну или сколько угодно. И система автоматически агрегирует данные из нескольких источников по объявленным вами осям агрегации (то есть по связанным полям).
Сохранённые DOLAPы (сокр. от distributed OLAP) как результаты расчётов остаются в памяти и следующий пользователь уже не ждёт загрузки первичных данных с диска. При обновлении источника результаты расчётов по нему обнуляются.
Управление памятью в rapeed - отдельная большая тема. Мы сделали так, что и при малом объёме ОЗУ система справляется с вычислениями на больших объёмах, делая их медленнее, но надёжно. Чем больше доступной памяти, тем меньше её "круговорот" и тем комфортнее работа пользователей.
Название, кстати, для любого англоговорящего человека звучит как "быстрый, молниеносный".
rapeed: in-memory OLAP-движок с собственной алгеброй связей