Gerenciando Objeto VIEW

Uma VIEW ou (visão/visualização) atua como se fosse uma tabela. A view tem um nome. Você pode descrever um VIEW com DESCRIBE da mesma maneira que descreveria uma tabela. Você pode executar uma instrução SELECT em uma view da mesma maneira que selecionaria em uma tabela.

Dependendo do tipo da view com a qual você está trabalhando, você pode até executar instruções INSERT, UPDATE e / ou DELETE em uma view para manipular o conteúdo das tabelas subjacentes. Mas uma view não é uma tabela e não possui dados armazenados. Uma visualização nada mais é do que uma instrução SELECT que é salva no banco de dados com um nome atribuído a ela.

Os tipos de dados para essas colunas são selecionados automaticamente na tabela subjacente ou nas expressões usadas na instrução SELECT para criar a view. Uma view é basicamente um apelido para uma consulta previamente realizada.

A View funciona como um “filtro” através do qual você pode pesquisar uma tabela e interagir com uma tabela. Os objetos VIEW podem ser usados para mascarar partes da lógica da tabela subjacente por vários motivos – talvez para simplificar a lógica comercial ou adicionar uma camada de segurança ocultando a fonte real de informações. Uma VIEW pode ser usada para exibir certas partes de uma tabela enquanto oculta outras partes da mesma tabela.

Outro benefício para as VIEWs é a capacidade de facilitar uma consulta complexa. Por exemplo, você pode criar uma VIEW em uma junção complexa para que a complexidade seja incorporada à VIEW. O resultado é uma VIEW que parece ser uma única tabela, que você pode consultar agora como se fosse uma tabela. Você pode adicionar na sua VIEW outras tabelas e outras VIEWs. Nessa situação, uma exibição pode ser usada para simplificar a complexidade de uma junção comumente usada. Na próxima seção, criaremos um objeto VIEW.

Criando uma Views

Vamos supor que temos duas tabelas EMPREGADO e HISTORICO_DE_PAGAMENTOS, na tabela EMPREGADO temos as colunas id, nome, cpf, telefone e na tabela HISTORICO_DE_PAGAMENTOS temos id_empregado, salario, data_ini, data_fim. Digamos que não podemos divulgar o telefone do funcionário, então podemos “esconder” essa coluna fazendo uma VIEW.

CREATE VIEW FUNC AS
SELECT ID, NOME, CPF, SALARIO 
FROM EMPREGADO 
JOIN HISTORICO_DE_PAGAMENTOS ON 
EMPREGADO.ID = HISTORICO_DE_PAGAMENTOS.ID_EMPREGADO

Para executar a VIEW faça a seguinte intrução SQL abaixo:

SELECT * FROM FUNC;

Caso a VIEW tenha alguma expressão ou concatenação, essa coluna deverá ser apelidada. Exemplo:

create view teste as
 select 1+1 from dual

A tentativa de criação da VIEW acima vai dar o seguinte erro: (ORA-00998: must name this expression with a column alias) ou seja, a expressão precisa de um apelido. Ex: select 1+1 as soma from dual; ao substituir o select por esse que foi apelidado vai conseguir criar a VIEW.

A sintaxe para criar a VIEW é:
As palavras-chave CREATE VIEW
As palavras-chave opcionais OR REPLACE
Um nome para a visualização, especificado de acordo com as regras para nomear objetos de banco de dados
A palavra-chave AS Finalmente, uma instrução SELECT válida, com algumas restrições:

Um dos requisitos da instrução CREATE VIEW é o seguinte: a VIEW resultante deve ter nomes de colunas válidos. Isso significa que, se você escolher uma instrução SELECT que incorpore quaisquer expressões complexas na lista de seleção, cada expressão deverá receber um alias de coluna ou nomes de colunas deverão ser atribuídos pela própria instrução CREATE VIEW. Por exemplo, vamos usar a opção OR REPLACE para criar uma VIEW.

Uma forma alternativa de dar nome as colunas é a seguinte:

create or replace view test (soma, colunaB) as
select 1+1, colunaB from dual;

Observe as palavras-chave opcionais OR REPLACE na instrução CREATE VIEW. Essas palavras não funcionam com CREATE TABLE, mas funcionam com CREATE VIEW. Tenha cuidado com eles – quando incluídos, eles não avisarão se você estiver ou não substituindo alguma VIEW existente. Eles simplesmente substituirão a antiga pela nova VIEW. É uma opção conveniente e poderosa, por isso tome cuidado.

Note que o apelido não foi dado no SELECT e sim na linha 1 da instrução CREATE VIEW. A view pode também usar uma instrução SELECT com uma junção JOIN, uma cláusula GROUP BY, uma WHERE e funções agregadas; podemos criar uma VIEW com tudo isso. Os objetos VIEW podem ser baseados em instruções SELECT com subconsultas, funções e muito mais.

Alterando os dados por meio de Views

Em algumas situações podemos alterar os dados através de UPDATE, INSERT ou DELETE. Dependendo das constraints, pode ser possível usar algumas instruções DML (Data Manipulation Language).

Caso criarmos uma VIEW que tenha as colunas nome e telefone mas não incluirmos a coluna ID que é chave primária o que vai ocorrer? a view vai ser criada com sucesso com as colunas nome e telefone mas caso executarmos um insert vai dar erro pois vai exigir informar o ID que é chave primária e não deixa inserir um valor nulo.

Para um comando INSERT funcionar numa VIEW deve respeitar todas as contraints das tabelas que são referenciadas na view. Outra observação é linhas agrupadas, ou seja, consulta que faz uso do GROUP BY não irá funcionar DML (INSERT, UPDATE, DELETE). Você será impedido de usar INSERT, UPDATE ou DELETE se criar uma VIEW com base em uma instrução SELECT que inclua qualquer um dos seguintes:

  • Omissão de quaisquer colunas necessárias (NOT NULL) na tabela subjacente.
  • GROUP BY ou qualquer outra agregação, como OPERADORES DE CONJUNTO.
  • DISTINCT.
  • A cláusula FROM que faz referência a mais de uma tabela – ou seja, subconsultas no SELECT ou na maioria das junções JOIN.

Se concatenarmos uma coluna NOME ||’, ‘||SOBRENOME AS NOME_COMPLETO, então não poderemos usar um INSERT informando um valor para NOME por exemplo, a não ser que crie outra coluna NOME sem a concatenação, também não poderíamos usar um valor para inserir o SOBRENOME pelo mesmo motivo, mas poderíamos fazer um insert nas outras colunas da VIEW normalmente. Podemos usar um DELETE e UPDATE usando VIEW, desde que não esteja nas condições listadas acima, principalmente verificando constraints, se a VIEW tem GROUP BY ou DISTINCT, operadores de conjunto ou subconsultas ou na maioria dos JOINS, nesses casos vão ocorrer erro ao executar uma DML.

Com relação à questão geral de usar INSERT, UPDATE e / ou DELETE em qualquer exibição, a resposta geral é simples: se a view fornecer acesso em nível de linha (não agregado) a uma tabela – e apenas uma – e incluir o parâmetro capaz de acessar as colunas necessárias nessa tabela, você pode usar INSERT, UPDATE e / ou DELETE na view para efetuar alterações na tabela subjacente, de acordo com as restrições listadas anteriormente. Caso contrário, talvez você não consiga executar com êxito uma alteração nos dados na view.

Inline Views

Uma Inline Views ou exibição embutida ou exibição em linha é uma subconsulta contida em uma instrução SELECT maior, de forma que substitua a cláusula FROM de uma instrução SQL. Aqui está um exemplo:

SELECT * FROM (SELECT * FROM DUAL);

A inline view é a que está dentre parênteses e não há limite de quantidade de aninhamento:

SELECT * FROM (SELECT * FROM ( SELECT * FROM DUAL ));

Esse “aninhamento ilimitado” é diferente do limite para subconsultas típicas, em que o limite é de 255 subconsultas aninhadas. As visualizações embutidas podem ser combinadas com várias consultas complexas, como aquelas que usam cláusulas JOIN e GROUP BY e muito mais. Aqui está um exemplo:

Fazendo JOIN com INLINE VIEW

Um ótimo uso de uma exibição em linha é solucionar um problema que envolve a pseudocoluna ROWNUM. ROWNUM é um número de linha atribuído automaticamente a cada resultado de uma consulta. O desafio do ROWNUM é que ele é atribuído antes do processamento da cláusula ORDER BY. Como resultado, você não pode classificar linhas e, em seguida, usar ROWNUM como uma maneira de exibir, por exemplo, o número da linha de cada linha de saída. Os resultados serão misturados, já que ROWNUM é executado antes do de ORDER BY. Mas você pode mover a cláusula ORDER BY para uma exibição embutida e, em seguida, usar a pseudocoluna ROWNUM na consulta externa para exibir os números de linha corretamente. Aqui está um exemplo:

ROWNUM com INLINE VIEW

Alter VIEW

A instrução ALTER VIEW é usada para realizar qualquer uma das seguintes tarefas:

  • Criar, modificar ou eliminar constraints em uma view
  • Recompilar uma exibição inválida

Recompilar uma view é uma etapa que você pode executar se tiver criado uma view e depois executado algum tipo de modificação na tabela ou tabelas subjacentes nas quais a visualização é criada. Dependendo da alteração que você fizer na tabela de origem da visualização, a visualização pode ser invalidada como resultado. Depois de invalidada, uma tentativa subsequente de usar a exibição resultará em um dos dois resultados:

Resultado 1: Se a alteração resultar em uma situação em que a instrução CREATE VIEW original teria sido executada com êxito, uma instrução subsequente usando essa view fará com que a exibição seja recompilada com êxito.
Resultado 2: Se a alteração resultar em uma situação em que a instrução CREATE VIEW original não teria sido executada com êxito, as tentativas subsequentes de usar a exibição falharão. Um exemplo dessa alteração seria alterar uma tabela subjacente para eliminar uma coluna que faz parte da lista de colunas de uma visualização.

No capítulo de dicionário de dados, veremos como você pode determinar se uma exibição é inválida ou não consultando o dicionário de dados. Uma alternativa para consultar o dicionário de dados, que nem sempre está disponível para um aplicativo, é emitir uma instrução ALTER VIEW… COMPILE. Esta declaração pode ser usada para recompilar uma exibição inválida. Se a visualização não puder ser recompilada, a instrução ALTER VIEW … COMPILE será executada com êxito com uma mensagem declarando “Aviso: Visualização alterada com erros de compilação”. O dicionário de dados mostrará a visualização como permanecendo inválida. Aqui está um exemplo de uma instrução que recompila uma exibição:

ALTER VIEW tabela_funcionarios COMPILE;

Você não pode alterar a instrução SELECT de uma visualização com a instrução ALTER VIEW. Em vez disso, você deve executar um DROP e depois CREATE. Depois de compilada com êxito, a exibição volta à condição de trabalho. Se não for compilado, você saberá que a alteração na tabela subjacente pode ter alterado a estrutura da view. Por exemplo, se uma view que consulta uma coluna nomeada de uma tabela subjacente e essa coluna for renomeada a recompilação não funcionará e pode ser necessário recriar a view e reavaliar o código.

Além disso, se você simplesmente tentar usar uma exibição inválida, ela será compilada automaticamente. Se puder ser compilado, a tentativa de usar a exibição será bem-sucedida, com tudo o resto sendo igual. No entanto, se não puder ser recompilado, ao contrário da instrução ALTER VIEW… COMPILE, que executaria mas emitirá um aviso, qualquer tentativa de usar uma exibição inválida que não possa ser recompilada automaticamente resultará em erro.

Colunas Visible/Invisible

As visualizações são baseadas em tabelas e, no Oracle 12c, uma tabela pode ter colunas visíveis ou invisíveis. Como isso afeta as visualizações? Vamos começar analisando o uso de colunas invisíveis nas tabelas.

Invisible Columns and Tables

As colunas em uma tabela são visíveis por padrão. Novo no Oracle 12c, você pode especificar que uma ou mais colunas sejam invisíveis. Aqui está um exemplo:

Criando tabela com coluna Invisível

Observe a coluna CONSTRUCTION_COST, especificada como INVISIBLE. As outras colunas são visíveis por padrão. Então o que isso quer dizer?

Primeiro, vamos exibir a estrutura da tabela com DESC. Você pode descrever a tabela com DESC SHIP_ADMIN e verá a descrição típica da tabela, mas qualquer coluna especificada como INVISIBLE será omitida da exibição.

Não mostra a coluna invisível

Podemos inserir dados em uma coluna invisível mas temos de declarar o nome dessa coluna no INSERT para funcionar.

Colunas invisíveis e VIEW

Lembre-se de que uma VIEW é um objeto criado baseado uma consulta de uma ou mais tabelas. Quando falamos de uma view e colunas invisíveis, estamos falando das colunas da tabela ou tabelas nas quais a consulta da exibição se baseia. São invisíveis? Nesse caso, há vários problemas a serem resolvidos.

Se uma tabela tiver uma ou mais colunas especificadas como INVISÍVEL, as referências de caracteres curinga (com o asterisco) em uma instrução SELECT não reconhecerão a coluna invisível, também uma instrução INSERT se não declarar a coluna invisível não vai funcionar inserir valor nela. O mesmo problema se aplica às consultas usadas para criar uma VIEW.

Por exemplo, vamos começar com a mesma tabela SHIP_ADMIN que acabamos de criar. Lembre-se, ele tem três colunas, uma das quais é invisível. Agora também possui uma linha de dados:

Vamos criar duas views diferentes na tabela SHIP_ADMIN. Para a primeira view, nossa consulta usará uma referência curinga para todas as colunas da tabela. Lembre-se de que a tabela SHIP_ADMIN consultada possui duas colunas visíveis e uma coluna invisível. Veja a Figura abaixo. Criamos a visualização e depois a descrevemos. A coluna invisível é omitida da estrutura da visualização:

Para mostrar a coluna invisível deve ao criar a view colocar o nome da coluna, daí sim vai aparecer, veja o exemplo abaixo:

Agora vemos um resultado diferente. Essa segunda view é baseada em uma consulta que especifica uma coluna invisível por nome. Nessa situação, a visualização verá as colunas invisíveis. A coluna invisível é declarada na estrutura da view. Uma instrução SELECT nesta segunda view retornará o(s) valor(es) da coluna invisível, independentemente da instrução SELECT (na view) usar ou não uma referência curinga, como mostra a Figura acima.

A diferença é o uso do curinga na consulta usada para criar a view. Se a consulta usada para criar a view emprega uma referência de coluna curinga, as colunas invisíveis são ignoradas, mas a view será criada com sucesso; simplesmente omitirá a coluna invisível. No entanto, ao trabalhar com uma tabela que consiste em uma ou mais colunas invisíveis, é possível criar uma exibição que inclua essas colunas invisíveis, especificando os nomes de colunas invisíveis na consulta usada para criar a exibição. O resultado é uma visualização em que a coluna que está invisível na tabela é visível para a visualização, tanto na estrutura da visualização quanto nas interações com a própria visualização.

About these views, it’s all for now bye.

Referência

OCA Oracle Database SQL Exam Guide (Exam 1Z0-071). Páginas 499 – 516.