Please enable JavaScript.
Coggle requires JavaScript to display documents.
Projeto Físico - Anhanguera - Tópicos avançados - Coggle Diagram
Projeto Físico - Anhanguera - Tópicos avançados
1.1 - Definição e criação de itens
Tabelas
Visões
atendimento das necessidade dos usuários
indices
usuários
Restrições de integridade
1.2 - Relacionado a aspéctos técnicos de armazenamento
capacidade
armazenamento
velocidade de acesso
disco
rede
largura de banca
tipo de dado e adequação para armazeamento da informação
estruturado/tabular
número
strings
não estruturado
audio
vídeo
imagens
1.3 - Etapas do projeto físico
a) dependem da
arquitetura do sistema
abrangeinca do banco
objetivos do sistema
b) não há uma lista definitiva de tarevas
c) principais tarefas comumente relacionadas
a) Dimensionamento de espaço
pré alocação de espaço
reauzir problmemas de sobralizção de espaço
Carga Inicial dos dados
deve ser revisado de tempos em tempos
crescimento constante
crescimento sazonal
Comumente analista informa ao DBA
volume esperado
número de transações por unidade de tempo
tentar delinear uma equação que possa prever o crescimento /necesidades
Equação comum para determinar crescimento geométrico
Tamanho atual
(1+fator de crescimento mensal em %)
número_meses
deve-se estimar a quantidade de meses
equacao de crescimento deve ser revisitada de tempos em tempos pois o fator de crescimento pode mudar
Tamanho atual considera volume inicial das tables do database
Exemplo:
Base atual 100GB
Crescimento 2% ao mes
Período 4 anos
Resultado: 100
(1.02)
48
Com banco em produção pode-se utilizar as estatísticas do próprio banco para auxiliar na estimativa de cresimento
b) análise de transações
deve considerar
Consultas feitas
atualizações faitas
Frequencia de transações
número de transações realizadas pelos sistemas e usuários que interagem com o datbase
volume de dados das tabelas envolvidas em cada transação
analisar volume de dados para cada tabela e impacto na trasaçao
avaliar em especial transações que acessam tabelas com alto volume de dados
verificar comprometimento do desempeno dado o volume
comumente identifica-se necessidade de índices por meio das avaliações de transações
concorrência de tabelas envolvidads em tuma transação
Atualização
otimizar scopo da transação
breve bolqueio de páginas de dados
pode afetar desempenho das tabelas envolvidas
número de linhas afetadas pela transação
influi no espaço alocado para rolback
quanto maior o número, maior o espaço alocado para rolback
probabilidade de afetar desempenho do sistema
transações devem ser rápidas de forma a não afetar o sistema
analista informa ao dba
número de transações
tabelas envolvidade em cada transção
se possível a definição das consultas
lembre que aqui pode-se utilizar algebra relacional (não sendo necessário especificar o database/tecnologia)
c) criação de índices
não devem ser criados sem critério
consomem armazenamento
impactam nas tansações de atualização
Analista deve informar tabelas que serão
consultadas pelas transações
volume de dados das tabels
consultas SQL executadas pelo sistema
colunas/campos utilizados como critérios nas consultas
frequencia das consultas
considerar granularidade da consulta
quantidade de linhas esperadas como retorno
poucas linhas
alta granulariade
muitas linhas
baixa granularidade
métrica de quantidade de linhas
considera-se 600 linhas como boa métrica
consultas com mais que 600 linhas precisa ser bem avaliada
consultas on line
1 more item...
Projeto de índices
Pode inclusive levar a revisão do modelo relacional
visando desempenho
se identificar de consultas de baixa granularidadde (alto volume de linhas) deve-se avaliar esta questão
não se resolve todos os problemas de acesso criando índices
número grande e índices em uma tabela pode indicar necessidade de revisão do projeto do modelo relacional
pode indicar necessidade de fatiamento dos dados
tipos de índices
BTree
arvore B
RTree
Arvore R
adequandoa a consultas de dados espaciais
Hash
pode ser localizado mais rapidamente
associa cada valor a um iten de dado exclusivo
podem tratar apenas comparações de igualdade simples
considera usar em operadores "="
O autor comenta que:
índices hash do PostgreSQL não têm desempenho melhor do que os índices B-tree, e que o tamanho e o tempo de construção dos índices hash são muito piores. Por estas razões, desencoraja-se a utilização dos índices hash.
Gist
etc
cada tipo utiliza um algoritmo diferente
CREATE INDEX
POSTGRES
Padrão Btree
adequado a maioria das situações
utilizado quando existem os operadores
< ; <= ; = ; >= ; >
betwen e in (também podem utilizar
Like, Ilike e ~e~* (no ínicio da cadeia)
d) distribuição dos arquivos
itens a serem considerados
capacidade de processamto do servidor para retorno das consultas
nível de atualizações do banco de dados
DBA informoo
alto volume de consulta e atualizações
considerar distribuição dos arquivos
servidor com alta capacidade de armazenamento
sistema de discos rápoido
questoes inviabilizadora
custo
hardware diferenciaodo
alta concorrencia em acessos
distribuir arquios de dados em mais de um disco
permitir leituras em paralelo
acelerar consultas
agilizar atualizações
e) Desnormalização visando performance (caso, e se realmente necessário necessário)
Sistemas OLAP
Usada de forma controlada para otimizar a performance
Em sistemas OLTP
pode trazer vários problemas
mesmo asssim, fica a pergunta: Isto é realmente necessário
Deve ser utilizada apenas em último caso
usada para obter canhos de desempenho
Acarreta em problemas como
redundancia
inconsistência
anomailias de atualização
etc.
comumente pode resolver problemas para o DBA, mas fica um grande problema para o projeto do banco e deve consistir em tratar as problemáticas citadas que podem trazer conseguqencias graves para o database
Existem 3 técnicas
Agrupar tabelas
diminuir número de junções
Duplicar Atributos
diminuir número de acesso e junções
Transitividade
Útil quando há acessoa a tabela implicada pela transitividade ??? (autor não definiu claramente esta questão)
Link para conteúdo -
Aula 2 - Projeto Físico de Banco de Dados
1.0 - Visão Geral de contexto
Projeto o banco possue 3 etapas distintas começando a nível de conceitos do negócio até chegar a apsectos de tecnologia e implementação
Projeto conceitual
boa elicitação e espeificacao dos requisitos
não são considerados apéctos técnicos
independente da tecnologia/banco de dados
MER
Projeto lógico
Mapeamento das entidades do modelo coneitual para tableas do modelo relacional
Projeto físico
1.0 - Definição e criação
Tabelas
Visões
atendimento das necessidade dos usuários
indices
usuários
Restrições de integridade
1.1 - Definidas as características de armazenamento
1.2 - Relacionado a aspéctos técnicos de armazenamento
1.3 - Etapas do projeto físico