Aula 17 – Otimização Modelo Relacional IEC Banco de Dados I Aula 17 – Otimização Modelo Relacional Turmas: Sistemas de Informação Professora: André Luiz da Costa Carvalho E-mail: andre@icomp.ufam.edu.br Site: http://bdufam.wordpress.com

Técnicas de otimização de Esquema Sumário Técnicas de otimização de Esquema Técnicas de otimização de Consultas

Introdução O primeiro lugar onde podemos fazer Bancos de Dados melhores é na criação das tabelas (relações) Com a aplicação rodando, mudar tableas pode levar à alterações em todos os programas que a usam Importante acertar na primeira tentativa.

Alguns esquemas são melhores que outros Vejamos estes dois esquemas para informações de pedidos feitos para compra de materiais: Fornece1(ID_forn,ID_mat,qtde,end_forn) Fornece2(ID_forn,ID_part,qtde) Fornecedor(ID_forn,end_forn) Vamos comparar estes dois esquemas no seguinte cenário: 100000 compras 2000 fornecedores Inteiros de 8 bytes e end_forn de 50 bytes.

1 - Espaço Segundo esquema usa espaço extra para o ID_forn redundante. 2000 x 8 = 16 mil bytes Contudo, economiza nos endereços 2000 endereços vs 100000 do primeiro. 98000 x 50 = 4.950.000 bytes a menos Total 4.934.000 bytes a menos para o segundo Só 5 megas? Sim, mas ganho se manteria mesmo se aumentássemos para 1 bilhão de linhas

2 – Preservação da Informação Imaginem que um fornecedor X entregou todos os pedidos pendentes. Faz sentido que as linhas pertinentes a ele sejam deletadas. Dessa forma, no esquema 1, a informação de endereço de X seria perdida junto. Então 1 é sempre pior? Nem sempre

3 - Performance Se você tem uma necessidade constante de saber o endereço do fornecedor de um dados pedido/peça, ele pode ser melhor. Especialmente se houverem poucas inserções. Se houverem novas inserções constantes, o endereço extra em cada pedido vai ser trabalho extra. Então, cada esquema pode ser útil dependendo do caso.

Normalização Esquema 1 é não normalizado, enquanto o esquema 2 é normalizado. Dependência funcional X são atributos de R, A é um atributo específico de R X -> A X determina A Se duas instâncias diferentes tem o mesmo valor de X, elas terão o mesmo valor para A Isto é mais interessante se A não é um atributo de X Como assim? Cada fornecedor tem um endereço Cada ID_forn determina o endereço

Particionamento Vertical Banco: numCli, saldo e endereco Dependências: numCli->endereco e numCli->saldo Duas formas de fazer o esquema respeitando as dependências (numCli, endereco, saldo) (numCli, endereco) (numCli,saldo) Qual é melhor? Depende das consultas!

Banco Endereço é usado geralmente uma vez por mês. Para mandar contas. Saldo, em contrapartida é usado o tempo todo Tabela (numCli,saldo) seria menor, o que traria benefícios Índices de cluster esparsos podem ser menores. Mais pares numCli,saldo caberão na memória Consulta que precisar ler todos saldos leria menos blocos

Perfomance R (X,Y,Z) Consulta de Scan X inteiro YZ são strings Consulta de Scan Particionamento Vertical ruim quando todos atributos são acessados. Melhora quando só dois são acessados.

Cenário 2 numCli, endereco, cep, saldo Este esquema faz sentido? (numCli,cep) (numCli,saldo) Separar CEP e endereço não parece uma boa idéia, já que eles devem ser sempre acessados junto. Quando particionar: Acessos costumam ser em um dos conjuntos de atributos, nunca entre atributos de ambos. Atributos Y e Z são grandes (1/3 do tamanho de um bloco)

Desnormalização As vezes, pode ser interessante ter uma informação não relacionada diretamente em uma relação, se houverem muitas consultas que projetem esta informação. Ou seja, se tiver que fazer vários joins para acessar a informação. Joins são caros. Pode valer a pena ter informação duplicada para agilizar.

Desnormalização Consulta: encontrar itens cujo fornecedor fica na Europa. Normalizado precisa de 4 joins Desnormalizado: adiciona nome daregião ao item (foreign key denormalization) Performance melhora 30%

Manutenção de agregação Consultas com SUM, AVERAGE e afins podem ser muito caras. Pode valer a pena guardar visões materializadas destas consultas. Espaço extra será usado. Cada insert gerará custos extras de atualização da visão. Vale a pena se houverem mais consultas que inserções. Pode-se criar tabelas redundantes com gatilhos também.

Manutenção de agregação

Domínios dos atrinutos Sempre prefira Integer a Float se possível. Float força range queries. Ex: Select nota from aluno where nota = 5 vira Select nota from aluno where nota >=4.999 and nota <=5.001 Atributos que variam de tamanho: Use tipos variáveis. Varchar melhor que char se tamanho do texto variar muito. Porém updates podem causar fragmentação se valor novo não couber no bloco

Otimização de Consultas

Otimização de Consultas Sempre começe a otimização pelo que pode ser 100% benéfico. Criar índices, mudar o esquema, criar visões, podem gerar custos novos. Reescrever consultas para ser mais rápidas só traz benefícios

Base de exemplo funcionario(cpf, nome, dept, salario, numamigos); estudante(cpf, nome, curso, periodo); dept(dept, gerente, localizacao); clustered index i1 on funcionario (cpf); nonclustered index i2 on funcionario (nome); nonclustered index i3 on funcionario (dept); clustered index i4 on estudante (cpf); nonclustered index i5 on estudante (nome); clustered index i6 on dept (dept); 100000 tuplas funcionario, 100000 estudante, 10 departments; Cold buffer

Elimine DISTINCTs desnecessários Query: Encontrar empregados do departamento “ti”. Sem duplicatas. SELECT distinct cpf FROM funcionario WHERE dept = ‘ti’ DISTINCT desnecessário, já que cpf é chave de funcionario

Elimine DISTINCTs desnecessários Query: Encontrar cpf dos funcionarios de algum departamento sem duplicatas. SELECT DISTINCT ssnum FROM employee, tech WHERE employee.dept = tech.dept Distinct necessário?

DISTINCT desnecessário Como dept é chave de dept, cada funcionário vai casar com um único registro de dept. Cpf é chave do funcionário, então será 1 para um, sem precisar de distinct.

Generalizando Relacionamento entre DISTINCT, chaves e joins pode ser generalizado: Uma tabela T é chamada de privilegiada se os campos retornados pelo select contém uma chave de T Dado R, uma tabela não privilegiada. Se R é joinada através de uma chave a outra tabela S, diz se que R alcança S (reaches). Alcance é transitivo. Se R1 alcança R2 e R2 alcança R3, então R1 alcança R3.

Reaches: Teorema Não haverão duplicatas, mesmo sem distinct, se uma das duas condições for válida: Toda tabela no FROM é privilegiada Toda tabela não-privilegiada alcança ao menos uma tabela privilegiada.

Reaches Se toda relação é privilegiada então não haverão duplicatas Chaves da relação estão no from. Dada uma relação T que não é privilegiada mas alcança ao menos uma relação privilegiada R. O Link entre T e R garante que cada combinação de registros privilegiados é juntada com pelo menos um registro de T.

Reaches: Exemplo 1 O mesmo funcionário pode casar com vários deptos (gerente não é chave), então cpf pode aparecer várias vezes. Dept não alcança a a relação privilegiada funcionário. SELECT funcionario.cpf FROM funcionario, dept WHERE funcionario.gerente = dept.gerente

Reaches: Exemplo 2 Cada valor de cpf seria acompanhado de um valor de departamento diferente, já que dept.nome é chave de dept. Ambas relações são privilegiadas. SELECT cpf, dept.nome FROM funcionario, dept WHERE funcionario.gerente = dept.gerente

Reaches: Exemplo 3 Estudante é privilegiado Funcionário não alcança estudante (Nome não é chave) DISTINCT é necessário. Só em caso de nomes repetidos. SELECT estudante.cpf FROM estudante, funcionario, dept WHERE estudente.nome = funcionario.nome AND funcionario.dept = dept.nome;

Queries – Subconsultas correlacionadas Original: select cpf from funcionario e1 where salario = (select max(salario) from funcionario e2 where e2.dept = e1.dept); Reescrita: select max(salario) as maiorsalario, dept into TEMP from funcionario group by dept; Select cpf from funcionario, TEMP where salario = maiorsalario and funcionario.dept = temp.dept;

Subconsultas relacionadas SQL Server 2000 vai bem (usa hashjoin ao invés de repetição aninhada) > 1000 > 10000

Manutenção de Agregação pedidos( numPedido, itemnum, qtde, idloja, idvend); create clustered index i_pedr on pedidos(itemnum); store( idloja, nome); item(itemnum, preco); create clustered index i_item on item(itemnum); vendOtimo( idvend, total); lojaOtimo( idloja, total); 1000000 pedidos, 10000 lojas, 400000 items; Cold buffer

Manutenção de Agregação -- triggers Triggers para Manutenção de Agregação create trigger atualizaVendOtimo on pedidos for insert as update vendOtimo set qtde = (select vendOtimo.total+sum(inserted.qtde*item.preco) from inserted,item where inserted.itemnum = item.itemnum ) Where idvend = (select idvend from inserted) ; create trigger atualizaLojaOtimo on pedidos for insert as update lojaOtimo (select lojaOtimo.total+sum(inserted.qtde*item.preco) where idloja = (select idloja from inserted)

Aggregate Maintenance -- transações Inserções insert into pedidos values (1000350,7825,562,'xxxxxx6944',’jose'); Consultas (sem e com tabelas redundantes) select pedidos.vendid, sum(pedidos.qtde*item.preco) from pedidos,item where pedidos.itemnum = item.itemnum group by pedidos.vendid; vs. select * from vendOtimo; select loja.nome, sum(pedidos.qtdey*item.preco) from pedidos,item, loja where pedidos.itemnum = item.itemnum and pedidos.idloja = loja.idloja group by loja.idloja; vs. select * from lojaOtimo;

Manutenção de integração Gatilhos para manutenção Se tem muitas consultas e poucas inserções, então vale a pena.