No documento da Oracle The Query Optimizer , em View Merging , encontrei as seguintes informações
A otimização de mesclagem de exibição se aplica a exibições que contêm apenas seleções, projeções e junções. Ou seja, as exibições mescláveis não contêm operadores de conjunto, funções agregadas, DISTINCT, GROUP BY, CONNECT BY e assim por diante. (ênfase minha)
No entanto, só posso adivinhar a que tal projeção realmente se refere.
Em Álgebra Relacional, projeção significa coletar um subconjunto de colunas para uso em operações, ou seja, uma projeção é a lista de colunas selecionadas.
Em uma etapa do otimizador de consulta, a projeção se manifestará como um buffer ou área de spool de alguma descrição contendo um subconjunto das colunas da tabela ou operador subjacente, ou uma visão lógica baseada nessas colunas que é usada por operações subsequentes.
Em uma exibição, uma projeção equivale à lista de colunas selecionadas na consulta subjacente à exibição.
A projeção refere-se a esse subconjunto do conjunto de todas as colunas encontradas em uma tabela, que você deseja retornar. Pode variar de 0** até o conjunto completo.
Existem dois "conjuntos" em uma tabela que correspondem às duas dimensões de uma tabela. Cada tabela tem um conjunto de colunas e também um conjunto de linhas . Cada valor individual em uma tabela pode ser encontrado em uma interseção específica desses dois *conjuntos**. No entanto, seu valor não é encontrado ao "ir para" um endereço, como T60 , da maneira que você faria com o Excel.
Não há ordem inerente às tabelas relacionais . Isso é importante lembrar. Em vez disso, para recuperar seu valor único, você selecionaria um subconjunto das colunas (um neste caso) e um subconjunto das linhas (um neste caso). Para selecionar um subconjunto de uma coluna de todas as disponíveis, basta saber seu nome, bem como o nome da tabela. O nome da coluna será exclusivo em sua tabela.
Depois de escolher a coluna em que seu valor está, você precisará escolher a linha específica em que está. No entanto, as linhas não têm nomes como as colunas. A maneira como especificamos uma linha é . . . bem, nós não exatamente. . . Especificamos algo que sabemos sobre o valor que estamos procurando. Você tem que saber algo relacionado (literalmente) ao valor que está procurando. Se você puder especificar informações relacionadas suficientes, poderá reduzir o conjunto de linhas retornadas apenas para o que está procurando.
Pense nisso como se um estudante universitário tivesse perdido sua mochila. Digamos que um cara perdeu. Ele liga para achados e perdidos, e a mulher que atende diz: "Sim, temos algumas dúzias de mochilas. Você pode descrevê-las?" Você diz "Bem, é azul?". Ao que ela responde "Você está me perguntando ou me dizendo", e depois diz "Eu tenho oito azuis, vou ter que fazer melhor do que isso, e você não parecia muito certo disso". Você diz "Vamos ver, umm, oh sim! Tinha meu livro de matemática 1010 nele." "Bom, agora você caiu para quatro." Então você se lembra que deveria encontrar sua namorada, Lucy, em 15 minutos, e isso desencadeou outra memória - da vez em que você estava entediado em Matemática 1010 e escreveu - em letras pequenas reais no fundo da mochila: "Eu amo Lúcia".Ricky ."
A projeção pode ser comparada a dizer o que você perdeu - uma mochila. A seleção pode ser comparada à descrição de seus atributos : é azul, tem um livro de matemática 1010 dentro e tem "Eu amo Lucy" escrito na parte inferior.
Você faz a mesma coisa com o SQL. Primeiro, que tipo de informação você deseja ver. Segundo, critérios que descrevem qual ou quais você deseja ver. Estes são chamados de predicados ou declarações de verdade . Elas são verdadeiras para um ou mais membros do conjunto. Se não forem, eles não retornarão nenhum valor.
* As implementações de SQL de alguns fornecedores fornecem meios para quebrar essas regras, como tabelas aninhadas no Oracle. No entanto, as tabelas bidimensionais padrão ainda são a forma predominante.
** CJ Date escreveu um artigo muito interessante chamado "A Table With No Columns". Achei que valeu muito a pena ler, como faço a maioria de seus muitos artigos "Writings". Eu os recomendo!