Por que os bancos de dados relacionais funcionam, dada a complexidade exponencial teórica da busca de respostas (no tamanho da consulta)?

Parece sabido que, para encontrar uma resposta para uma consulta em um banco de dados relacional , é preciso tempo e não é possível se livrar do expoente.$Q$$D$$|D|^{|Q|}$$|Q|$

Como pode ser muito grande, nos perguntamos por que os bancos de dados funcionam na prática.$D$

É apenas uma questão de as consultas usuais não serem grandes nas aplicações do mundo real? (É interessante saber qual é o tamanho usual das consultas feitas aos sistemas de bancos de dados relacionais e qual é o tamanho "máximo" das consultas que devem ser efetivamente respondidas por um sistema de banco de dados na prática .)

Notas sobre o expoentenão `removível '$|Q|$

Para mostrar que o expoentenão é removível, pode-se usar uma consulta perguntando se existe um clique do tamanho no gráfico fornecido pelo banco de dados. Verificar se um gráfico tem um class é um problema NP-complete. Além disso, não é um parâmetro fixo tratável, com o parâmetro . Detalhes podem ser encontrados em, por exemplo, Libkin, L .: Elements Of Finite Model Theory. Springer (2004) ou Papadimitriou, CH, Yannakakis, M .: Sobre a complexidade das consultas ao banco de dados. J. Comput. Syst. Sci. 58 (3), 407-277 (1999)$|Q|$$n$$n$$n$

Existem grandes classes de consultas que são "fáceis", mesmo no pior caso. Em particular, se a classe de consultas contiver apenas consultas conjuntivas e cada consulta tiver largura delimitada (por exemplo, largura da árvore, largura do gráfico de incidência, largura fracionada da hiperárvore ou largura submodular), a consulta poderá ser respondida usando algo como uma árvore de junção , juntamente com a enumeração de força bruta para as partes locais da consulta que se desviam da árvore. Isso requer tempo polinomial, com o grau do polinômio determinado pelo parâmetro width.

Parece que muitas consultas encontradas na prática são conjuntivas e têm pouca largura. Portanto, o tempo de execução polinomial tem um baixo grau nesse caso.

Dániel Marx apresentou um artigo no STOC 2010 sobre largura submodular recentemente, cuja versão completa inclui um bom resumo das várias noções de largura e como a formulação do CSP se relaciona com o formalismo do banco de dados (a versão da conferência não possui isso).

• Dániel Marx, Propriedades de hipertexto tratáveis ​​para satisfação de restrições e consultas conjunturais , 2010. arxiv: 0911.0801

Essa não é uma resposta completa, pois não lida com a complexidade "típica" das consultas ao banco de dados, mas mesmo com a análise do pior caso, existem consultas fáceis.

Pode-se usar as consultas Q_n para verificar se um gráfico, representado como um banco de dados, contém um clique com n elementos. Verificar se um gráfico tem uma clique é um problema completo de NP. Além disso, não é um parâmetro fixo tratável, com o parâmetro n (que significa D ^ n).

Outra maneira de responder a essa pergunta é "eles não"!

Se você fornecer a uma implementação típica do DBMS uma consulta contendo um número muito grande de junções, ela nem passará pela fase de planejamento / otimização (sem falar na avaliação), mesmo se a consulta for acíclica ou tiver uma estrutura muito simples, como András faz alusão ao acima.

Mas, para cargas de trabalho "típicas" do DBMS, essas consultas parecem não surgir.

Aqui está uma versão mais preocupada com a realidade da resposta da tigreen, a partir do ponto de uma pessoa que realmente faz uso pesado de bancos de dados (relacionais): O objetivo e a complexidade de seu aplicativo são estruturá-los de uma maneira que exigiriam o mínimo de se une a todas as consultas sempre necessárias quanto possível e é por isso que elas realmente funcionam . Em outras palavras, não espere que os bancos de dados resolvam problemas complexos por conta própria - eles não resolveriam, mas se usados ​​com sabedoria, são um instrumento realmente útil e aplicável.

As uniões são quadráticas em relação aos relacionamentos muitos-para-muitos. Isso é relativamente raro: na prática, a maioria dos relacionamentos e junções é de um para muitos; portanto, levará tempo linear se índices / chaves forem definidos. Consultas com várias associações muitos-para-muitos são um problema sério.