

Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Os melhores documentos à venda: Trabalhos de alunos formados
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Comunidade
Peça ajuda à comunidade e tire suas dúvidas relacionadas ao estudo
Descubra as melhores universidades em seu país de acordo com os usuários da Docsity
Guias grátis
Baixe gratuitamente nossos guias de estudo, métodos para diminuir a ansiedade, dicas de TCC preparadas pelos professores da Docsity
Neste documento, aprenda sobre a construção de comandos sql eficientes em bancos de dados relacionais. Saiba como as tabelas são organizadas como conjuntos, como as consultas e alterações são operações realizadas sobre eles, e como o otimizador de banco de dados escolhe o caminho mais curto para resolver uma consulta. Além disso, saiba sobre a importância de índices, seletividade e o uso de nulos em tabelas.
Tipologia: Notas de estudo
1 / 3
Esta página não é visível na pré-visualização
Não perca as partes importantes!
Em bancos de dados relacionais as informações são guardadas em tabelas. Para recuperar uma informação necessaria ao usuário, deve-se buscá-la em várias tabelas diferentes, estabelecendo-se um relacionamento entre elas. Esta é a origem do nome deste paradigma de banco de dados. Tabelas são na verdade conjuntos. Por exemplo, quando em um sistema existe uma tabela de vendas, esta tabela corresponde ao conjunto de todas as vendas feitas por uma empresa. A tabela de vendedores corresponde ao conjunto de vendedores que trabalham em uma empresa. Cada linha ou registro da tabela corresponde a um elemento do conjunto. Consultas e alterações na base de dados correspondem a operações realizadas sobre conjuntos. Estas operações são definidas pela álgebra relacional. Por exemplo, determinar quais os vendedores com tempo de casa maior que um determinado patamar, significa determinar um subconjunto do conjunto de vendedores, onde todos os elementos possuam uma determinada propriedade. Para determinar as vendas destes vendedores, é necessário realizar a operação já citada e depois, para cada elemento do subconjunto "vendedores veteranos" é necessário determinar o subconjunto do conjunto de vendas, contendo a propriedade de ter sido realizada pelo vendedor em questão. O resultado final da consulta será a união de todos estes subconjuntos. O problema apresentado possuí também outra forma de solução. Podemos, em um primeiro momento, determinar para cada vendedor, quais as suas vendas. Teríamos então vários subconjuntos, cada um contendo as vendas de um vendedor. Feito isto,podemos verficar quais os vendedores são veteranos, formando o resultado final a partir da união dos subconjuntos associados a cada um. Consultas em banco de dados não passam de problemas de álgebra relacional. Assim como acontece com a álgebra "tradicional", os operadores possuem algumas propriedades. Sabemos que 2 x 3 = 3 x 2. Isto significa que, quando precisamos contar uma expressão de álgebra relacional para chegar a um determinado resultado,podemos faze-lo de mais de uma forma, pois várias expressões levam ao mesmo resultado. Em outras palavras, quando o banco de dados precisa montar uma expressão algébrica para encontrar um resultado, ele deve escolher uma entre várias. Apesar de apresentarem o mesmo resultado, as expressões são diferentes, e a diferença fará com que o banco de dados adote um diferente caminho para resolver cada uma. Escolher o caminho mais curto é uma das grandes atribuições do banco de dados. Está é a missão do otimizador, um subsistema do banco da dados, responsável por determinar o plano de execução para uma consulta. A linguagem SQL (Structured Query Language) é um grande padrão de banco de dados. Isto decorre da sua simplicidade e facilidade de uso. Ela se opõe a outras linguagens no sentido em que uma consulta SQL especifica a forma do resultado e não o caminho para chegar a ele. Ela é um linguagem declarativa em oposição a outras linguagens procedurais. Isto reduz o ciclo de aprendizado daqueles que se iniciam na linguagem.
Vamos comparar:
Na verdade, fui bem pouco honesto na comparação. Minha declaração procedural tem
muito de declarativa, o que a torna mais simples. Se ela fosse realmente procedural, seria ainda mais complicada. O fato é que, ter que informar o como fazer, torna as coisas mais difíceis. Neste sentido, SQL facilitou muito as coisas. Porém, a partir do nosso "o que queremos", o banco de dados vai determinar o "como fazer". No problema das "vendas dos veteranos", descrevi duas formas de solucionar o problema, a primeira certamente melhor que a segunda. O objetivo deste texto é apresentar formas de dizer para o banco de dados o que queremos, ajudando-o a determinar uma forma de fazer que tenha esforço mínimo. Para chegarmos a este objetivo, lamentavelmente, teremos que nos preocupar com o "como fazer”. É fato que parte da necessidade da nossa preocupação com o "como fazer" é decorrência do estágio atual da tecnologia, que ainda pode evoluir. Porém, por melhor que seja o otimizador de um banco de dados, ele poderá trocar a consulta fornecida pelo usuário por outra equivalente segundo a álgebra relacional. Em algumas situações uma consulta é equivalente à outra apenas considerando-se a semântica dos dados. Neste caso, se nós não nos preocuparmos com o "como fazer “, teremos uma performance pior.
Quando fazemos consultas em uma tabela estamos selecionando registros com
determinadas propriedades. Dentro do conceito de álgebra relacional, estamos fazendo uma simples operação de determinar um subconjunto de um conjunto. A forma trivial de realizar esta operação é avaliar cada um dos elementos do conjunto para determinar se ele possui ou não as propriedades desejadas. Ou seja, avaliar, um a um, todos os seus registros. Em tabelas grandes, a operação descrita acima pode ser muito custosa. Imaginemos que se deseje relacionar todas as apólices vendidas para um determinado cliente, para saber seu histórico. Se for necessário varrer toda a tabela de apólices para responder esta questão o processo certamente levará muito tempo. A forma de resolver este problema é o uso de índices. Índices possibilitam ao banco de dados o acesso direto às informações desejadas. Fisicamente, a tabela não está organizada em nenhuma ordem. Os registros são colocados na tabela na ordem cronológica de inserção. Deleções ainda causam mudanças nesta ordem. Um índice é uma estrutura onde todos os elementos de uma tabela estão organizados, em uma estrutura de dados eficiente, ordenados segundo algum critério. Um registro no índice é composto pelo conjunto de valores dos campos que compõem o índice e pelo endereço fisico do registro na tabela. Ao escrever uma consulta SQL, não informamos especificamente qual índice será usado pela consulta. Esta decisão é tomada pelo banco de dados. Cabe a nós escrever a consulta de forma que o uso do índice seja possível. É preciso que nossa consulta disponibilize o índice.
O critério básico para escolha de índices é a seletividade. Quando o banco de dados
resolve uma consulta, freqüentemente, ele precisa percorrer mais registros do que aqueles realmente retomados pela consulta. Os registros percorridos que forem rejeitados representarn o trabalho perdido. Quanto menor for o trabalho perdido, mais perto estaremos da performance ótima para resolver a consulta. Portanto, o melhor índice para uma consulta é aquele que apresenta a maior seletividade.