blendb issueshttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues2018-05-16T13:40:51Zhttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/66Redefinir algoritmo de junção2018-05-16T13:40:51ZLucas Fernandes de OliveiraRedefinir algoritmo de junçãoO algoritmo de junção possui uma regra: Quando agregações de granularidade diferentes são unidas, não é possível agregagar. Essa regra atrapalha alguns casos onde a ordem das junções afeta o resultado final. Buscar uma solução. Possíveis...O algoritmo de junção possui uma regra: Quando agregações de granularidade diferentes são unidas, não é possível agregagar. Essa regra atrapalha alguns casos onde a ordem das junções afeta o resultado final. Buscar uma solução. Possíveis soluções incluir utilizar dependência funcional e salvar esse tipo de informação na agregação ou dimensão.1.0Lucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/44Mover metricas dimensionais para Engine2018-05-16T13:40:54ZLucas Fernandes de OliveiraMover metricas dimensionais para EngineAtualmente as métricas dimensionais são tratadas apenas pelo adapter. Esse efeito surge ao realizar certos Joins entre as views sobre certas condições.
Descobrir se esse problema já pode ser detectado na Engine, e resolvido nesse ponto....Atualmente as métricas dimensionais são tratadas apenas pelo adapter. Esse efeito surge ao realizar certos Joins entre as views sobre certas condições.
Descobrir se esse problema já pode ser detectado na Engine, e resolvido nesse ponto. Provavelmente se isso for possivel, a view deverá ter uma estrutura mais elaborada do que um vetor de childViews para passar ao adapter para gerar a consulta. Provavelmente terá que indicar exatamente quais joins devem ser feitos e quais agregações devem ser feitas.
Com essa alteração o adapter terá que ser refatorado (Novamente), mas provavelmente deverá ficar mais simples.1.0Lucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/41[BUG]: Metricas retornam resultados incorretos em alguns joins2017-09-12T14:00:54ZLucas Fernandes de Oliveira[BUG]: Metricas retornam resultados incorretos em alguns joinsEmbora o mecanismo funcione corretamente o resultado não é o esperado. O problema ocorre quando a junção das tabelas não é "perfeita". Um exemplo uma view tem os atributos met:count:point e dim:point e outra tem met:sum:download, dim:poi...Embora o mecanismo funcione corretamente o resultado não é o esperado. O problema ocorre quando a junção das tabelas não é "perfeita". Um exemplo uma view tem os atributos met:count:point e dim:point e outra tem met:sum:download, dim:point, dim:macAddr. A consulta seleciona as duas métricas, logo será feita uam junção das duas views pela dimensão dim:point que é comum entre os dois. Porém o resultado da métrica met:count:point possivelmente será incorreto.
Isso ocorre pois é muito provavel que a segunda tabela que tem mais dimensões tenha mais de uma entrada por dim:point, dessa forma ao realizar o join as entradas da primeira serão repeditas e contabilizadas mais de uma vez, resultando em um resultado incorreto.
*Proposta:* para realizar joins as views tem que ter uma relação de um para um, ou seja, as mesmas dimensões antes de fazer um join.
*Problemas:* Em alguns casos é necessário fazer junções com quantidades de dimensões diferentes.
Considere o mesmo exemplo, agora além das métricas a dim:macAddr também é selecionada, a junção com quantidade diferente de dimensões é obrigatória.
*Proposta:* Em certos casos, a partir de um ponto as métricas devem se comportar como dimensões.
A junção com outra view com quantidade de entradas maior é inevitavel, porém se met:count:point fosse uma dimensão o resultado não seria incorreto, em outras palavras se o valor fosse agrupado ao invés de agregado não seriam contabilizadas de forma errada, logo se comportária como uma dimensão.
*Proposta:*
1. Agregamos as views materializadas separadamente, com as respectivas dimensões necessárias
2. Depois da agregação é feito o join, com as dimensões restantes, que seriam as necessárias para realizar o join entre as views e as que foram escolhidas na consulta
3. Remoção das dimensões extras (usadas apenas para propósito de junção) agrupando por todos os parametros que estavam na consulta
*Problemas:*
1. Nem todas as views criadas podem ser reaproveitas para realizar outras consultas, e portanto essas não podem ser materializadas.
2. A partir do momento que um métrica tem que ser tratada como uma dimensão, ela pode ser replicada e não pode ser agregada novamente
Usando esse algoritmo a query 1 (apenas as métricas) não funcionaria, na realidade ela seria equivalente a consulta utilizando também a dim:point, para que o resultado fosse correto, as métricas teriam que ser agregadas novamente, não tratadas como dimensões, isso se deve ao fato de que a junção nesse caso poderia ter sido "perfeita", primeiro agrupando por dim:point seriam criadas views com dimensões iguais, assim elas poderiam ser juntadas normalmente e as metricas poderiam ser agregadas normalmente.
*Solução:*
As junções devem ser feitas 2 a 2, ao invés de todas ao mesmo tempo, em formato de árvore, sempre que uma junção "perfeita" foi feita em um passo, então o resultado deve ser agregado novamente removendo as dimensões de junção, se for o caso. Se a junção não for perfeita a partir desse ponto as métricas devem ser tratadas como dimensões.
1. Escolhe-se 2 views
2. Agregamos as views separadamente, com as respectivas dimensões necessárias, tanto para consulta como para joins (além das duas em questão, mas de todo o conjunto)
3. Faz-se o join das duas views
4. Se a junção foi perfeita, as métricas continuam factíveis e podem continuar sendo agregadas, caso contrário marca as métricas para que sejam tratadas como dimensões agora e a view como não-materializavel
5. Volta para o passo 1 até que reste apenas uma view
6. Se a última junção foi perfeita agrega a view com as métricas restantes (métricas marcadas para o algoritmo não são consideradas métricas)
*Problemas:*
1. Vão existir views não-materializaveis (Elas podem serr materizalizadas mas seu resultado não pode ser aproveitado por outras consultas, então é pouco desejavel materializar uma consulta dessas)
2. Muito provavelmente a consulta construída será muito menos eficiente
3. A partir do momento que um métrica tem que ser tratada como uma dimensão, ela pode ser replicada e não pode ser agregada novamente
*Resolve:*
A junção de views com quantidade de dimensões diferentes se torna possível e retorna o resutlado corretoLucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/33Melhorar função de analise dos filtros2017-10-16T11:49:30ZLucas Fernandes de OliveiraMelhorar função de analise dos filtrosA escolha de views e agregações é limitada pelos filtros aplicados. No momento apenas se o filtro casar perfeitamente (tem que se identico) a view é escolhida. En varios casos é o suficiente (Para operadores == e !=), porém com o operado...A escolha de views e agregações é limitada pelos filtros aplicados. No momento apenas se o filtro casar perfeitamente (tem que se identico) a view é escolhida. En varios casos é o suficiente (Para operadores == e !=), porém com o operador de > por exemplo, se a restrição é de maior que 3 meses, maior que 6 meses também poderia utilizar essa view, mas isso não ocorre.
Operadores individuais parecem simples de resolver, bastaria olhar o operador do filtro e aplicar algumas comparações, entretanto quando combinados com operador OR (maior que 3 meses ou ativo) já não funciona tão bem.
Acredito que o melhor é analizar alguns casos que seriam mais úteis que e que mais ocorrem e tentar abordar esse modelo mais restrito do que acertar 100% dos casos.
Encontrar essa lista de casos e melhorar a escolha dos filtros, a principio modificar a função checkConstranits da classe graph deve ser o suficiente para aplicar as mudanças.Lucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/23Implementar filtros básicos2017-08-10T12:35:24ZLucas Fernandes de OliveiraImplementar filtros básicosImplementar filtros para dimensões. Isso significa o trabalho completo, desde adicionar o parâmetro na API até modificar o gerador de consulta para aplicar os filtros
No momento apenas dois operadores serão implementados, igualdade e de...Implementar filtros para dimensões. Isso significa o trabalho completo, desde adicionar o parâmetro na API até modificar o gerador de consulta para aplicar os filtros
No momento apenas dois operadores serão implementados, igualdade e desigualdade, mas a estrutura deve ser feita para facilitar a criação de outros filtros.Lucas Fernandes de OliveiraLucas Fernandes de Oliveirahttps://gitlab.c3sl.ufpr.br/c3sl/blendb/-/issues/22Incrementar Algoritmo de Cobertura para considerar conectividade das Views2017-07-14T14:36:49ZLucas Fernandes de OliveiraIncrementar Algoritmo de Cobertura para considerar conectividade das ViewsUm problema conhecido com a cobertura gerada pelo BlenDB é que o conjunto de Views selecionadas nem sempre pode sofrer um join perfeito, em alguns casos é feito um produto cartesiano que pode levar a resultados inconsistentes.
O esquema...Um problema conhecido com a cobertura gerada pelo BlenDB é que o conjunto de Views selecionadas nem sempre pode sofrer um join perfeito, em alguns casos é feito um produto cartesiano que pode levar a resultados inconsistentes.
O esquema do banco que o BlenDB usa pode ser representado por um grafo onde os vértices são métricas e dimensões e uma aresta existe entre dois vértices se, e somente se eles fazem parte de uma mesma view.
Uma consulta pode ser vista como um sub-grafo, onde o Usuário escolhe os vértices e o BlenDB escolhe as arestas.
Para que a consulta não realize produtos, o sub-grafo resultante da consulta deve ser conexo.
Implementar esse grafo para representar o esquema do banco, mantê-lo com a adição de métricas e dimensões e views e implementar o algoritmo que verifica conectividade do sub-grafo. Uma busca em largura deve resolver.Lucas Fernandes de OliveiraLucas Fernandes de Oliveira