IECBanco 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

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

11

Perfomance

R (X,Y,Z) 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.

0

0.005

0.01

0.015

0.02

No Partitioning -XYZ

VerticalPartitioning - XYZ

No Partitioning -XY

VerticalPartitioning - XY

Th

rou

gp

ut

(qu

erie

s/se

c)

Cenário 2

numCli, endereco, cep, saldo Este esquema faz sentido?

(numCli,endereco) (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.

14

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%

0

0.0005

0.001

0.0015

0.002

normalized denormalized

Th

rou

gh

pu

t (Q

uer

ies/

sec)

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

viraSelect 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

20

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

21

Elimine DISTINCTs desnecessários Query: Encontrar empregados do

departamento “ti”. Sem duplicatas.SELECT distinct cpfFROM funcionarioWHERE dept = ‘ti’

DISTINCT desnecessário, já que cpf é chave de funcionario

22

Elimine DISTINCTs desnecessários Query: Encontrar cpf dos funcionarios de

algum departamento sem duplicatas.SELECT DISTINCT ssnumFROM employee, techWHERE employee.dept = tech.dept

Distinct necessário?

23

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.

24

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.

25

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.

26

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.

27

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.cpfFROM funcionario, dept

WHERE funcionario.gerente = dept.gerente

28

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.nomeFROM funcionario, dept

WHERE funcionario.gerente = dept.gerente

29

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.cpfFROM estudante, funcionario, dept

WHERE estudente.nome = funcionario.nome AND funcionario.dept = dept.nome;

30

Queries – Subconsultas correlacionadas

Original:select cpffrom funcionario e1 where salario = (select max(salario) from funcionario e2 where e2.dept = e1.dept);

Reescrita:select max(salario) as maiorsalario, deptinto TEMP from funcionario group by dept;

Select cpffrom funcionario, TEMPwhere salario = maiorsalarioand funcionario.dept = temp.dept;

31

Subconsultas relacionadas

SQL Server 2000 vai bem (usa hashjoin ao invés de repetição aninhada)

-10

0

10

20

30

40

50

60

70

80

correlated subquery

Th

rou

gh

pu

t im

pro

vem

ent p

erce

nt

SQLServer 2000

Oracle 8i

DB2 V7.1

> 10000> 1000

32

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

33

Manutenção de Agregação -- triggersTriggers 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

set qtde =

(select lojaOtimo.total+sum(inserted.qtde*item.preco)

from inserted,item

where inserted.itemnum = item.itemnum

)

where idloja = (select idloja from inserted)

34

Aggregate Maintenance -- transações

Inserçõesinsert 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;

35

Manutenção de integração

Gatilhos para manutenção Se tem muitas consultas e poucas

inserções, então vale a pena.pect. of gain with aggregate maintenance

21900

31900

- 62.2-5000

0

5000

10000

15000

20000

25000

30000

35000

insert vendor total store total