Linguagem SQL: geração de relatórios - Revista SQL Magazine 95 - Parte 2

Este é o segundo artigo de uma série que pretende apresentar recursos da linguagem SQL que ajudam na criação de relatórios. Repetindo o que escrevi no primeiro artigo:

 “É consenso entre os especialistas que SQL não é a melhor linguagem para criação de consultas complexas. Apesar de esta ser uma verdade inegável, é muito comum nos depararmos com situações em que ele, o SQL, é a única ferramenta que temos à mão para criação de um relatório. Isso ocorre muitas vezes por questão de custos, já que nem sempre é economicamente viável optar pela compra de uma solução especializada. Este cenário é muito comum no dia-a-dia das empresas e, no fim das contas, somos forçados a usá-lo.

Por esta razão, eu considero importante que todo profissional de banco de dados conheça os principais recursos do SQL para atender as solicitações dos seus usuários”.

Neste sentido, é importante relembrarmos uma definição básica ao se trabalhar com consultas SQL que é a definição de expressão SQL. A definição que temos para o termo expressão é bastante simples: uma expressão retorna um valor. Os tipos utilizados em uma expressão variam bastante, cobrindo diferentes tipos de dados como string, numeric e boolean. Na verdade, quase tudo que inserirmos depois do SELECT ou FROM em um comando SQL pode ser considerado uma expressão. Caso você queria encontrar um item ou grupo de itens em particular em seu banco de dados, você precisará fazer uso de uma ou mais condições em suas queries. Podemos definir condições em consultas SQL utilizando a cláusula where.

Vimos no artigo anterior vários recursos úteis da linguagem SQL que nos ajudam na criação de relatórios. Neste texto atual, apresentaremos recursos da linguagem SQL para geração de objetos especiais para manipulação dos dados, como visões e consultas aninhadas. O leitor com alguma familiaridade com SQL já deve ter visto tais recursos, por isso acrescentaremos aqui um estudo de performance para auxiliá-lo a explorar estas técnicas de forma otimizada.

Este material foi extraído de uma palestra sobre recursos oferecidos pelo DB2, porém iremos priorizar nestes artigos os recursos e as sintaxes que sejam padrão ANSI SQL, ou seja, que estão ou deveriam estar disponíveis em qualquer sistema gerenciador de bancos de dados (SGBD).

Neste artigo, vamos falar do uso dos seguintes recursos SQL:

·         Visões;

·         Consultas aninhadas na cláusula WHERE;

·         Consultas aninhadas na cláusula FROM;

·         Consultas aninhadas na cláusula SELECT.

Na teoria de banco de dados, uma visão (view) consiste de uma consulta armazenada acessível como uma tabela virtual em um banco de dados relacional ou um conjunto de documentos em um banco de dados orientado a documentos, composto pelo conjunto de resultados de uma consulta. Ao contrário de tabelas comuns (tabelas base) em um banco de dados relacional, uma visão não faz parte do esquema físico: é uma tabela virtual dinâmica computada a partir de dados no banco de dados. Alterar os dados em uma tabela altera os dados mostrados nas invocações subsequentes da visão. Em alguns bancos de dados NoSQL as visões são a única forma de consulta a dados.

Visões podem oferecer vantagens sobre tabelas nos seguintes aspectos:

·         Visões podem representar apenas um subconjunto dos dados contidos em uma tabela;

·         Visões podem juntar e simplificar várias tabelas em uma tabela virtual única;

·         Visões podem funcionar como tabelas agregadas, através dos mecanismos de agregação do banco de dados (sum, average, etc.) e apresenta os resultados calculados como parte dos dados;

·         Visões podem esconder a complexidade dos dados, por exemplo, uma visão poderia se chamar Vendas2000 ou Vendas2001, particionando transparentemente a tabela básica real;

·         Visões ocupam muito pouco espaço de armazenamento, o banco de dados contém apenas a definição de uma visão e não uma cópia de todos os dados que ele apresenta;

·         Dependendo do SGBD utilizado, visões podem fornecer a segurança extra;

·         Visões podem limitar o grau de exposição de uma ou mais tabelas para o mundo exterior.

Assim como funções (function, na programação) podem fornecer abstração, usuários do banco de dados podem criar abstrações usando visões. Em outro paralelo com as funções, os usuários do banco de dados podem manipular visões aninhadas, assim, uma visão pode agregar dados de outras visões. Sem o uso de visões a normalização de bases de dados além da segunda forma normal se tornaria muito mais difícil. Visões podem tornar mais fácil a criação de junções sem perdas de decomposição.

Assim como as linhas em uma tabela base não têm qualquer ordem definida, as linhas disponíveis através de uma visão não aparecem com qualquer classificação padrão.

"

A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

Saiba como acessar este post através de Créditos DevMedia:

Assinatura de Créditos – Aqui este post custa R$ 1,50
Com esse plano você compra R$ 180,00 em créditos e ganha, em média, 80% de desconto no preço do post.  
Assine agora

Plano ocasional - Aqui este post custa: R$ 2,00 (assinante) ou R$ 2,50 (não-assinante)
Você compra um mínimo de R$ 60,00 em créditos e ganha, em média, 50% de desconto no preço do post.  
Compre agora

Plano conveniência – Neste plano este post custa R$ 5,00
Neste plano você compra somente um post, pagando seu preço sem desconto.  
Compre agora