rhuanmmaciel / dbest Goto Github PK

Um Sistema Gerenciador de Banco de Dados que visa a exposição de um plano de execução de consulta completo. Ele funciona com árvores de operadores sobre tabelas(Fyi, csv).

Java 99.64% ANTLR 0.36%

dbest's Introduction

Database Basics for Engaging Students and Teachers (DBest)

Resumo

Objetivo inicial

O DBest surge como um projeto que pretende ser um Sistema Gerenciador de Banco de Dados (SGBD) que demonstra as operações da álgebra relacional de uma forma visual, de modo que fosse implementado de maneira extensível, assim facilitando a adição de novas operações.

Objetivo atual

O escopo atual visa construir um plano de execução de consulta em um nível mais baixo.

Ferramentas

O software é construído utilizando Java.

Utilização

Este software existe com a intenção de facilitar o aprendizado das operações envolvendo tabelas relacionais.

Dependências externas

Nome	Descrição
For Your Information Database (FYI Database)	Utilizado como o banco de dados principal
ANTLR4	Utilizado para validar as entradas possíveis da DSL desenvolvida para o software
JGraphX	Utilizado para construir os nós visuais e suas conexões
Data Faker	Utilizado para gerar dados e popular as tabelas criadas na ferramenta

Contribuições

Caso você queira contribuir com o projeto, abaixo estão os contatos das pessoas que participam dele.

Nome	Contato
Sérgio	[email protected]
Rhuan	[email protected] [email protected]
Luiz	[email protected]
Marcos	[email protected] [email protected]

dbest's People

Contributors

Stargazers

Watchers

Forkers

matheus-delazeri

dbest's Issues

Bug: operadores com duas saidas

Hoje o dbest permite que um operador tenha duas saidas como a imagem abaixo:

O problema disso é que não funciona, então acho que a partir do momento que um operador já tem uma saida, deveria ser impossivel gerar outra seta a partir dela, impedir ele de iniciar uma edge a partir daquele nó.

Nenhum nó vai ter duas saidas, então n tem problema.

Implementar a funcionalidade de undo/redo para cada ação da barra inferior da interface

Organização do Github

Vamos organizar esse github q ta uma tristeza.

1- Vamos parar de upar o .jar do fyidatabase e do dbest no github.

O fyidatabase a gente tem q começar a importar via maven: https://jitpack.io/#crazynds/FyiDatabase-Java
Já o DBest.jar a gente vai lançar com as releases, que fica mais fácil de manter o controle. A gente lança primeiro um Jar e divulga no grupo para testar e tals, e dps publica na release.

2- Ocultar algumas coisas que não são necessárias no git:

Não sei se META-INF é necessário no git, acho que ele é auto gerado e pode ser adicionado no gitignore.
csv-tables/ é pra testes internos mas não deve existir no github.
dsl-operations/ é pra testes internos mas não deve existir no github.
lib/ essa pasta vai deixar de existir dps que a gente adicionar no maven do DBest a lib corretamente.
oficina/ não deveria existir essa pasta
tutorial/ move esse link do README.md do tutorial para dentro do README do root do repositório.

Adiciona no .gitignore todos os .jar e remove os items destacados do git.

3- Dar uma melhorada no doc do github.

Existir um tutorial de como fazer o básico com a ferramenta (abrir um csv, executar nó, teclas de atalho)
Uma descrição melhorada, isso da pra construir em cima de um artigo.
Colocar algumas telas no README.md do DBest para mostrar melhor a interface.

Importar zip

Fazer método para importar zip.

Tudo que for head e csv ele importa como tabela.
Claro, é ideal que ele copie para fora do zip todos os dados e depois importe, da pra jogar isso na pasta tmp

Bug: Generate FyiTableCell

Ao gerar um fyiTableCell usando qualquer nó, ele da um erro como o abaixo:

O estranho é que ele cria o .head dentro da pasta temp normal, mas o .dat ele cria na raiz. Após esse erro ele ainda consegue usar aquela tabela novamente, porém quando tu fecha o programa ele apaga a pasta temp, mas não apaga o .dat, então acaba gerando um pouco de lixo.

Bug no comparator

Quando tu está comparando duas table scans de tamanhos diferentes (imagino que dois operators de tamanhos diferentes de o mesmo result), quando uma operação chega no fim, ao executar o próximo next, a operação que chegou ao fim duplica cada uma das suas estatisticas, o que não faz sentido:

Operador da direita já chegou ao fim, Iteração 1:

Operador da direita já chegou ao fim, Iteração 2:

Quando eu mando executar até o final, o operador da direita que terminou zera todos os seus dados, talvez deva ter acontecido um overflow?

Stats: Adicionar/Modificar os stats

Alguns stats da engine foram modificados ou adicionados, e acho que seria interessante atualizar a tela de comparação:

Todos os status atuais:

Acho que para o DBest, todas as memórias poderiam virar a mesma coisa, não precisa ser separado como é no FYI. Tem que adicionar a info do Full table scan, SORT_TUPLES, cache hit e cache miss. Eu acho que seria bem legal se ao invez dele exibir o número de cache miss e cache hit, exibir a porcentagem, ai toda vez tu calcular pra exibir ali, é um sobre o outro * 100 + '%'.

Blocos salvos também acho que não precisamos, podemos só ignorar essa estatistica.

Corrigir condicional Is null

O is null não ta funcionando. Tem q corrigir para poder verificar fields com o campo nulo.

Padronização do estilo de código

Hoje à tarde eu fui atualizar minha branch a partir da principal e acabou resultando em vários conflitos, grande parte por causa do estilo de código (e.g., indentação, linhas em branco, espaçamento entre operadores, etc). Eu acho que isso pode ser um problema lá na frente, então seria uma boa a gente adotar um padrão de codificação. Isso pode ser feito tanto pela configuração da IDE, já que usamos a mesma (IntelliJ IDEA), ou pelo EditorConfig (um arquivo de configuração de estilo de código que fica no diretório raíz do projeto), que é uma solução bem consolidada pra esse tipo de problema.

Estilo de código é algo meio subjetivo, mas não dá pra negar que existem boas práticas seguidas por grande parte da comunidade Java, então eu acho que é válido tirar um tempo pra pensar nisso, não só pela qualidade do código, mas também pra economizar tempo futuramente nos merges.

Aqui tá o .editorconfig que eu montei a partir de outros que encontrei na web. A gente pode discutir a estrutura dele nesse issue, se faz sentido ou não o estilo que ele gera. Pra usar, é só copiar ele pro diretório raíz do projeto (DBest/sgbd/) e ativar o plugin EditorConfig do IntelliJ IDEA.

Quando a gente entrar em um consenso, começamos a usar ele! :D

Criação de novos operadores

Vamos precisar de mais alguns operadores que seria importante criar:

BlockNestedLoopJoin: Ao invez de criar esse operador, criar uma forma de editar um join e selecionar o algoritmo para ser usado nele.
Diferença: Tem q ver se a engine já tem, mas vou deixar aq pq é importante
Distinct projeção: Eu acho que não deveria existir o operador select columns, e a projeção por default não faça distinct, e ao editar ela tenha uma checkbox que o usuario seleciona se ele quer distinct ou não.
OuterJoin
Operadores de agregação: group by e operações (count, sum, avg, min, max)

Cancelar operação durante execução.

Fazer uma forma de cancelar a execução da thread executando o operador. Garantir que a thread morra (shutdowNow) e depois executar o close e o freeResources.

Fazer a esturuta de que ao invez de ter uma instancia Operador para cada nó, tu ter uma função que constroi o operator e sempre retorna um operator novo. Ai sempre que tu chamar uma thread para executar tu manda um operator 'limpo' pra ela.

Evitar reaproveitar operators.

Conexão com o MySql

Criar uma forma de criar uma tabela importada do mysql. Já tem o MysqlTable no FYI, só precisa adicionar um botão no importar tabela, para modelo mysql, e inserir informações: host, post, user, password, database, table.

Carregar stats no open

Alguns operadores executam e mudam os stats no open. Quando tu usa o comparator para ver os stats, seria interessante ver os stats no momento da abertura.

nome do arquivo exportado errado

quando o usuário exporta uma tabela para o Fyi DataBase e não digita a extensão .head no nome do arquivo, o arquivo .dat gerado vem com um .head no final

Manter o estado do nó ao edita-lo

O nó de filtro, após cria-lo, quando tu tenta editar ele, toda a informação é apagada e tem q fazer tudo do zero.
O join a mesma coisa, ele não salva o estado anterior que o join foi criado, quando tu apaga uma perninha e depois junta dnv ele reinicia o join para desde o inicio.

Tem o caso do usuario conectar uma perninha que não tem as colunas que o nó usava pra fazer algum filtro, da pra só ignorar isso, e se o usuario bocó n se ligar nisso, e salvar daquela forma, só deixar vermelho de erro e só. Ou se tiver outra ideia melhor, faz o q achar bom.