Você está na página 1de 78

Hugo Pedro Proença, © 2007

Segurança em BD

- A generalidade dos SGBD’s administra o


acesso a qualquer recurso da Base de
Dados.
- Qualquer
q operação
p ç só é possível
p se uma
das seguintes condições for satisfeita:
- Foi garantido o privilégio ao utilizador.
- A operação está disponível genericamente
para todos os utilizadores.
Hugo Pedro Proença, © 2007

Segurança em BD
z Cabe ao DBA a administração de todos os
privilégios.
– Que utilizadores podem aceder a que bases de dados.
– Quais as operações que cada aplicação pode efectuar
na base de dados.
z A definição da política de segurança requer
privilégios máximos por parte do administrador.
z Sistemas independentes que facilitam a tarefa de
administração de privilégios em bases de dados
(IBM-RACF, Computer Associates ACF2, Top
Secret,...)
Hugo Pedro Proença, © 2007

Segurança em BD
z A definição da política de segurança de uma base
de dados executa-se baseada em métodos de
“autenticação
autenticação forte
forte” (strong autentication).

– Cada utilizador possui um Login (Account) unívoco com


uma palavra-passe associada.
associada
• Alguns SGBD’s utilizam a informação proveniente do
sistema operativo local.
• Outros requerem a definição de utilizadores e palavras-
passe específicas
Hugo Pedro Proença, © 2007

Segurança em BD
z A informação relativa a um utilizador é
usualmente composta pelos atributos:
– Login Æ Identificador unívoco do utilizador.
– Password Æ Palavra, frase ou sequência de caracteres
associada ao login e que apenas deve ser do
conhecimento do próprio utilizador.
– Default DataBase Æ Identificação da base de dados a
que o utilizador se ligará por defeito.
– Nome Æ Nome completo do utilizador.
– Detalhes Adicionais Æ Informação adicional
eventualmente relevante para o DBA, no cumprimento
de qualquer tarefa de administração.
• E_mail,
E mail telefone,
telefone morada,
morada fax
fax, ...
Hugo Pedro Proença, © 2007

Segurança em BD
z Palavras-Chave
– Devem ser periodicamente actualizadas
(alteradas) por forma a dificultar a tarefa de
hackers (Sniffers) ou utilizadores com
propósitos danosos para a BD.
– Podem
P d ser automaticamente
i gerados
d pela l
SGBD.
• Potencialmente mais fiáveis e improváveis de decifrar.
• Mais
M i difíceis
difí i de
d memorização
i ã por parte
t do
d utilizador
tili d (ausência
( ê i de
d
mnemónicas, ...)
– A não actualização da palavra passe pode
simplesmente determinar a inactividade de
uma conta no SGBD.
Hugo Pedro Proença, © 2007

Segurança em BD
z Palavras- Chave (Regras)
– Evitar palavras-passe demasiadamente curtas. Cada uma
d
deverá á ter
t no mínimo
í i seis
i caracteres.
t
– Cada palavra-passe deve consistir de uma sequência de
caracteres alfanuméricos e numéricos, sendo encorajada a
utilização de outros símbolos que dificultem a sua decifração
(, $, #, &, £,§ )
– Evitar a utilização de palavras completas em qualquer
linguagem (estrangeira ou nativa)
– Não utilizar informação pessoal do utilizador na construção da
palavra-passe. (Telefone, nº contribuinte,...)
– Considerar a concatenação de várias palavras com símbolos
de ligação
• Exemplo: “MoonDance de Van Morrison é o meu album
favoritoӮ MDVMmaf
Hugo Pedro Proença, © 2007

Segurança em BD
z Logins – Parâmetros de segurança
– Alguns SGBD´s
SGBD s disponibilizam formas
de controlo e parametrização dos logins
de cada utilizador.
• Número de autenticações falhadas antes de bloquear
a conta.
• Número de dias de validade da palavra
palavra-passe
passe
• Reusabilidade de palavras-passe anteriores
• Número de dias sem utilização da base de dados
• ...
Hugo Pedro Proença, © 2007

Segurança em BD - Utilizadores
Utilizador 1
UtilizadorBD1

B
UtilizadorBD1
D Utilizador 2

UtilizadorBD2
Utilizador 3
Hugo Pedro Proença, © 2007

Segurança em BD
z Utilizadores de Base de Dados
– Alguns SGBD´s requerem adicionalmente à informação
d autenticação
de t ti ã no SGBD,
SGBD informação
i f ã específica
ífi para
cada base de dados.
• Cada utilizador possui um login + palavra-passe para
ligação ao SGBD.
SGBD
• Por cada Base de dados permitida, terá que possuir um
nome de utilizador e palavra-passe associada.
– Na maioria dos SGBD´s
SGBD s é permitida a criação de
utilizadores do tipo “GUEST”
• Normalmente para operações de consulta em tabelas
((vistas)
stas) basta
bastante
te espec
específicas
cas
Hugo Pedro Proença, © 2007

Segurança em BD
z Gestão de permissões
– A administração
ç de p permissões num SGBD
é efectuada através das instruções DAL
(DCL – Data Control Language)
• GRANT ÆAtribuição de permissões
permissões. È
necessário que o utilizador que atribui as
permissões:
– Seja o dono do objecto
– Possua permissões de nível máximo.
– A permissão sobre o objecto lhe tenha sido
atribuída com a clausula “WITH GRANT OPTION”
• REVOKE Æ Remoção de permissões
Hugo Pedro Proença, © 2007

Segurança em BD
z “WITH GRANT OPTION”
– Clausula q
que permite
p a um utilizador a
transferência do privilégio de atribuição a
outros utilizadores. A sua utilização origina a
diferença principal entre:
• Administração Centralizada: Apenas um único
utilizador possuir competências de gestão de
permissões Facilita a tarefa de administração
permissões. administração,
apesar de sobrecarregar o administrador.
• Administração Descentralizada: Fácil de estabelecer,
dificulta o controlo sobre objectos específicos.
específicos
Hugo Pedro Proença, © 2007

Segurança em BD
z Tipos de Privilégios
– Existem diferentes tipos de privilégios passíveis de atribuição
/ remoção, sendo alguns específicos de cada SGBD:
• TabelaÆControlo sobre os utilizadores que podem aceder /
modificar a informação contida numa tabela.
• Objecto da BD Æ Controlo sobre os utilizadores que podem criar
ou remover objectos
bj t dad base
b de
d dados
d d (funções,
(f õ procedimentos,
di t
vistas, ...).
• SistemaÆ Controlo sobre os utilizadores com permissões para
executar tarefas de administração de sistema (REORG, ...).
• Stored ProceduresÆ especificação dos utilizadores que podem
executar procedimentos ou funções guardadas no SGBD.
Hugo Pedro Proença, © 2007

Segurança em BD
z Atribuição de Privilégios
– Tabelas
• SELECT Æ Permissão para o utilizador consultar
informação de uma tabela ou vista.
• INSERT Æ Permissão para o utilizador inserir novas
instâncias numa tabela.
• UPDATE Æ permissão para o utilizador alterar informação
da tabela.
• DELETE Æ Permissão para o utilizador eliminar instâncias
de uma tabela
• ALL Æ Conjunto de todas as permissões anteriores.
Hugo Pedro Proença, © 2007

Segurança em BD
• Exemplos:
– GRANT DELETE ON Pessoas TO Utilizador1;
• Permite qque o “Utilizador1” possa
p eliminar instâncias da
tabela “Pessoas”.
– GRANT UPDATE ON Alunos (Nome) TO Utilizador2;
• Permite que o “utilizador2” possa alterar o conteúdo do
atributo “Nome”
Nome da tabela “Alunos”
Alunos .
– Objectos da Base de Dados
• Permite a criação de cada um dos tipos disponibilizados pelo
SGBD ((bases de dados, tablespaces, índices, eventos, tipos,...))
– GRANT CREATE table TO Utilizador1;
• Permite que “Utilizador1” crie tabelas.
– GRANT CREATE trigger, CREATE index TO Utilizador1;
• Permite que o “Utilizador1” crie índices e eventos.
Hugo Pedro Proença, © 2007

Segurança em BD
– Privilégios de Sistema
• Define os utilizadores que podem executar
comandos SQL específicos (criação de ficheiros de
log, desactivação de bases de dados, monitorização
de performance, criação de backups,...)
– Não são atribuídos ao nível da base de dados
dados,
– Varia bastante enter SGBD´s
– Exemplo:
• GRANT TRACE TO Utilizador1;
• Permite que o “utilizador1” possa efectuar a
análise do caminho para os dados de
determinadas consultas
Hugo Pedro Proença, © 2007

Segurança em BD
– Privilégios de execução
• Permitem definir quais os utilizadores que
podem executar que funções e
procedimentos guardados no SGBD.
– Exemplo:
• GRANT EXECUTE ON funcao1f 1 TO Utilizador1
Utili d 1
Permite que “Utilizador1” execute a
“funcao1”.
• GRANT EXECUTE ON proced procedure1re1
TO Utilizador1, Utilizador2, ..., UtilizadorN
Permite que “n” utilizadores executem o
procedimento “procedure1”
procedure1
Hugo Pedro Proença, © 2007

Seg rança em BD
Segurança
– Privilégios públicos
• É possível a atribuição de privilégios a todos
os utilizadores de um SGBD.
SGBD
– Não pode ser conjugado com a clausula “WITH
GRANT OPTION”
– Indicada para os recursos que devam estar
disponíveis para todos os utilizadores.
– Pode implicar falhas ao nível da fiabilidade da
informação.
– Exemplo:
• GRANT DELETE ON Pessoas TO PUBLIC
Permite q
que q
qualquer
q utilizador possa
p eliminar
instâncias da tabela “Pessoas”
Hugo Pedro Proença, © 2007

Seg rança em BD
Segurança
z Remoção de privilégios
– Constituí a instrução “simétrica” de “GRANT”.
– Possui
P i sintaxe
i t exactamente
t t igual
i l ao GRANT.
GRANT
• Exemplo:
– REVOKE UPDATE ON Pessoas (Nome) To Utilizador1
• Retira o privilégio de alteração do atributo
“Nome”da tabela “Pessoas” ao “Utilizador1”.
– A remoção de privilégios com a clausula
“PUBLIC” não ã os retira
ti aos utilizadores
tili d cuja
j
atribuição tenha sido feita especificamente.
– A remoção de objectos de uma base de dados
implica automaticamente a remoção de todos
os privilégios atribuídos sobre ele.
Hugo Pedro Proença, © 2007

Seg rança em BD
Segurança
– Remoção em cascata
• É possível a remoção de privilégios a um
utilizador e simultaneamente efectuar a sua
remição a todos os utilizadores que os tenham
obtido a partir deste.
– Exemplo:
• CASCADE REVOKE DELETE ON X TO Utilizador1
Neste caso é explicitado que o “Utilizador1”
Utilizador1
perde o privilégios de remoção de instancias da
tabela “X”. Caso este tenha atribuído privilégios
ç ao outros utilizadores,, estes serão
de remoção
automaticamente retirados.
Hugo Pedro Proença, © 2007

Seg rança em BD
Segurança
z Regras de Autorização e Grupos
– Por forma a facilitar as tarefas de
administração de privilégios
privilégios, é possível:
• Criar regras que contenham um conjunto de
privilégios.
• Exemplo:
– CREATE role MANAGER;
GRANT SELECT ON Tabela1 TO MANAGER;
GRANT UPDATE ON Tabela2 TO MANAGER;
COMMIT;
GRANT MANAGER TO Utilizador1
– Permite atribuir 2 regras
g (selecção
( ç e alteração)
ç ) ao
“Utilizador1” numa só instrução.
Hugo Pedro Proença, © 2007

Seg rança em BD
Segurança
z Auditorias
– É um mecanismo fornecido pela generalidade dos SGBD’s que
p
disponibiliza informação
ç detalhada sobre a utilização
ç de todos
os recursos das várias bases de dados.
– Regista para cada operação efectuada:
• Utilizador que a executou.
• Quais os objectos afectados
afectados.
• Tempo da execução.
– Pode ser efectuada ao nível das bases de dados, dos objectos
e dos utilizadores.
– Causa um impacto (previsível) no desempenho do SGBD.
– Especialmente importante para sistemas onde a informação
tem elevada:
• Relevância
• Privacidade
• ...
Hugo Pedro Proença, © 2007

Acesso a Bases de Dados


– Dependendo dos SGBD´s, é usual as
capacidades de auditoria incluírem:
• Informação sobre as entradas e saídas efectuadas no
SGBD (Bem ou mal sucedidas).
• Paragens e reinicializações efectuadas sobre o SGBD.
• Comandos executados pelos utilizadores.
utilizadores
• Tentativas de violação de restrições implementadas
(CHECK, REFERENCES,...).
• Operações
O õ ded manipulação
i l ã de d dados
d d efectuadas.
f t d
• Procedimentos e funções executadas.
• Alterações efectuadas à configuração do sistema.
Hugo Pedro Proença, © 2007

Administração
z A manutenção e administração do SGBD é
obviamente crucial para...
– Avaliabilidade
• Quantidade proporcional de tempo em que as bases de
dados estão disponíveis.
– Desempenho
• Tempo médio de resposta a cada pedido
– Consistência
• Fiabilidade e integridade da informação
– Segurança
• Gestão dos recursos pelos utilizadores
Hugo Pedro Proença, © 2007

Administração
z OS SGBD contêm normalmente
ferramentas auxiliares que facilitam as
tarefas de administração:
– Checkpoints
– Database Consistency Checker
– Backups
p
– Transferências de informação
Hugo Pedro Proença, © 2007

Administração - Checkpoints
z Constituem um mecanismo de
gravação de estado de uma base de
dados.
– Informação
ç
– Configurações
z Execução
– Manual
– Processo automático do SGBD
Hugo Pedro Proença, © 2007

Administração - Checkpoints
z Aquando da sua execução, todas as
dirty pages são escritas em ficheiro.
– Dirty pageÆ Contêm actualizações da
informação ainda não aplicados
fisicamente à base de dados
dados.
z Por omissão ocorrem normalmente a
cada 60 segundos.
– Valor parametrizável pelo administrador
do SGBD
Hugo Pedro Proença, © 2007

Administração - Checkpoints
z O comando CHECKPOINT é executado
ao nível da base de dados. Caso um
sistema tenha múltiplas bases de
dados ele deverá ser executado em
cada uma delas
– Para o efectuar é necessário que o
utilizador seja o dono (owner) da base de
dados.
Hugo Pedro Proença, © 2007

Administração - Checkpoints
z Após uma falha abrupta no sistema
(shutdown) o SGBD efectua o
ROLLBACK das transações efectuadas
depois do ultimo checkpoint.
– Desta forma o estado da base de dados
passará a ser o ultimo estado consistente
conhecido.
• Dados
• Informação
I f ã de
d registo
i t (log)
(l )
Hugo Pedro Proença, © 2007

Administração - Checkpoints

•Em sistemas com elevado número de acessos


e transações, o volume ocupado pela informação
de registo de actividade é bastante superior ao
efectivamente ocupado pela informação.
Log
• O administrador pode especificar a opção
“Truncate
Truncate Log
Log” que automaticamente faz com
que a informação de log seja truncada em
cada execução de um checkpoint. Dados
Hugo Pedro Proença, © 2007

Administração - Checkpoints
z Esta opção é também efectuada ao
nível de cada base de dados.
– Edição de propriedades no menu da base
de dados.
– Quando está activa
activa, o SGBD elimina toda a
informação de log anterior ao ultimo
checkpoint
p correctamente atingido
g
– Caso esteja a ser usada a replicação,
apenas é truncado o log relativo a
t
transações
õ já replicadas.
li d
Hugo Pedro Proença, © 2007

Administração - DBCC
z Database Consistency Checker
– É uma ferramenta destinada a gerar
g
informação detalhada sobre os objectos
que o SGBD contém.
– Quando a quantidade de objectos (tabelas,
regras, triggers, procedimentos, ...) é
elevada
l d torna-se
t necessária
á i a existência
i tê i
de uma aplicação que efectue uma
verificação completa do sistema
sistema.
Hugo Pedro Proença, © 2007

Administração - DBCC
z Database Consistency Checker
– Para a sua execução
ç é imprescindível
p q
que
a actividade do SGBD seja minimizada,
pelo que é conveniente efectuar a
passagem para o modod de
d utilizador
tili d
único:
• sp_dboption
sp dboption <base dados>
dados>, <parâmetro>,
<parâmetro> <valor>

• sp_dboption ‘pubs’, ‘single_user’, True


Hugo Pedro Proença, © 2007

Administração - DBCC
z Database Consistency Checker
– No modo de utilizador único, é vedado o
acesso a todos os restantes utilizadores.
– Após a execução das tarefas de
verificação, deverá ser efectuada ao modo
de utilização multi-utilizador:

• sp_dboption ‘pubs’, ‘single user’, FALSE


Hugo Pedro Proença, © 2007

Administração - DBCC
z Database Consistency Checker
– DBCC NEWALLOC
• Esta opção substitui outra activa por omissão
(CHECKALLOC) em que o processo de
verificação pára sempre que é encontrado um
erro.
• Pelo contrário,, ao utilizar esta clausula,, a
verificação chega é efectuada a todos os
objectos e só depois apresentada uma lista
dos erros e estados encontrados
encontrados.
Hugo Pedro Proença, © 2007

Administração - DBCC
z Database Consistency Checker
– DBCC NEWALLOC

• Esta opção é também aquela que retorna maior


volume de informação.
– Estruturas de tabelas
– Alocações físicas (páginas)
– Estruturas de índices
– Critérios de ordenação
– ...
Hugo Pedro Proença, © 2007

Administração - DBCC
z Database Consistency Checker
– DBCC CHECKDB
• Esta opção valida cada tabela de uma base de
dados e as páginas de dados associadas, bem
como os índices e referências.
referências
• O administrador deve ter em atenção que a
verificação
ç é também efectuada às tabelas de
sistema.
– Quando o número de tabelas é muito restrito pode
ser usada a clausula CHECKTABLE
Hugo Pedro Proença, © 2007

Administração - DBCC
z Database Consistency Checker
– DBCC SHRINKDB
• Ao criar uma nova base de dados é
normalmente disponibilizado bastante mais
espaço que aquele que esta efectivamente vai
ocupar.
• Após
p a implementação
p ç e utilização
ç da base de
dados, pode-se chegar à conclusão de que
existe bastante espaço desaproveitado.
Hugo Pedro Proença, © 2007

Administração - DBCC
z Database Consistency Checker
– DBCC SHRINKDB
• Sintaxe:
– DBCC SHRINKDB <base dados> [,<tamanho>]
•Q
Quando
d o administrador
d i i t d já sabe b previamente
i t o
espaço disponibilizado para a base de dados
pode explícita-lo:
p p
– DBCC SHRINKDB pubs 20000
• O valor é indicado em páginas
– 1 página
á i = 2048 b
bytes
t
Hugo Pedro Proença, © 2007

Administração - DBCC
z Database Consistency Checker
– DBCC SHRINKDB
• Caso o administrador não saiba qual o
tamanho mínimo a disponibilizar, pode obter
essa informação através de:
– DBCC SHRINKDB <base de dados>
• O sistema devolve então o valor mínimo em
páginas em que a base de dados pode ser
alojada.
Hugo Pedro Proença, © 2007

Administração
z Regra geral os altos níveis de desempenho
obtidos pelos SGBD são derivados de
metodologias
t d l i inteligentes
i t li t ded acesso à
informação.
z Quando é criado um procedimento o SGBD
determina o melhor caminho para os dados.
– Desempenho
z Este caminho é altamente dependente do
tipo de volume de dados.
Hugo Pedro Proença, © 2007

Administração
z Cada execução do procedimento é
efectuada segundo o caminho para os
d d previamente
dados i t estabelecidos.
t b l id
z Quando a informação é
substancialmente
b t i l t alterada,
lt d o melhor
lh
caminho pode deixar de o ser.
– Torna-se
Torna se necessário explicitar o calculo do
novo melhor caminho, através do
comando: update
p statistics
Hugo Pedro Proença, © 2007

Administração
z Sintaxe:
– Update
p Statistics <tabela> [.<indice>]
[ ]
z Se fôr especificado um índice são
apenas recalculados os caminhos que
o estejam a utilizar.
z Caso não seja referido nenhum índice,
índice
deverão ser recalculados todos os
caminhos que envolvam a tabela
tabela.
Hugo Pedro Proença, © 2007

Administração
z Sintaxe:
– Update
p Statistics <tabela> [.<indice>]
[ ]
z Se fôr especificado um índice são
apenas recalculados os caminhos que
o estejam a utilizar.
z Caso não seja referido nenhum índice,
índice
deverão ser recalculados todos os
caminhos que envolvam a tabela
tabela.
Hugo Pedro Proença, © 2007

Administração
z Recompilação
– O passo seguinte consiste em explicitar a
recompilação
il ã d dos procedimentos.
di t
– Não é necessário ao administrador conhecer
antecipadamente todos os procedimentos cujo
caminho para os dados necessita de ser
actualizado.
– Basta
B t marcar a(s) ( ) ttabela(s)
b l ( ) para recompilação
il ã e
todos os procedimentos que delas necessitarem
p
serão recompilados.
Hugo Pedro Proença, © 2007

Administração
z Recompilação
– Sintaxe:
• sp_recompile <tabela>
– Desta forma, antes da sua próxima
execução, o melhor caminho para os
dados de cada um desses procedimentos
será
á recalculado.
l l d
– Usualmente este procedimento é também
efectuado em modo de utilizador único
único.
Hugo Pedro Proença, © 2007

Administração - Backups
Back ps
z A confiança depositada pelos
utilizadores de um sistema informático
é um d dos ffactores
t d
de qualidade
lid d maisi
relevantes desse sistema.
z No
N caso dosd SGBD esta t característica
t í ti é
ainda mais visível.
– Múltiplos utilizadores
– Múltiplas exigências
– Múltiplos requisitos.
requisitos
Hugo Pedro Proença, © 2007

Administração - Backups
Back ps
z A criação de cópias de segurança é um dos
pilares essenciais de um SGBD.
z A periodicidade de criação dessas cópias é
dependente de cada sistema em particular.
–QQuantidade
tid d de
d informação
i f ã
– Importância da informação
z Cabe ao DBA a tarefa de conceber planos de
segurança para a informação.
Hugo Pedro Proença, © 2007

Administração - Backups
Back ps
z Usualmente implementam-se sistemas
de backups rotativos.
– 2 semanas
– 2 blocos de 1 semana
• As unidades de backup (tapes) colocadas em
lugares fisicamente (bastante) distantes.
– Garantia da existência de 14 dias com
estados estáveis da base de dados.
Hugo Pedro Proença, © 2007

Administração - Backups
Back ps
z Os backups são efectuados para
unidades designadas de “dump
devices”
– Unidades automaticamente reconhecidas
pelo SGBD como um repositório de
informação.
– Copiadas para diferentes localizações do
disco ou para diferentes suportes
• CD,
CD DVD
DVD, T
Tapes, ...
Hugo Pedro Proença, © 2007

Administração - Backups
Back ps
z O primeiro passo consiste em definir os
devices de backup
– É usual definir estas unidades em sistemas
diferentes daquele onde está alojado o SGBD.
– Incremento de segurança sem custos adicionais
relevantes.
– Garantia de acessibilidade ao sistema remoto
• Privilégios
– Garantia de espaço no sistema remoto
Hugo Pedro Proença, © 2007

Administração - Backups
Back ps
z De seguida pode-se partir para a
criação do backup.
– Backup explicito: É definido manualmente
pelo administrador do SGBD. Maior
vulnerabilidade a esquecimentos ou
outros factores inesperados.
– Backup
B k escalonado.
l d É definida
d fi id no SGBD a
periodicidade com que devem ser
automaticamente executados os backups.
backups
Hugo Pedro Proença, © 2007

Administração - Backups
Back ps
z Em qualquer dos casos, a operação é
efectuada apenas sobre uma base de dados.
z A criação de backups da informação de
registo de actividade (log) é também
imprescindível
p à segurança
g ç do sistema e em
nada difere do backup de dados.
z É possível a definição de opções de
notificação
tifi ã de
d estado.
t d
– Escrita no registo de log do sistema operativo.
– Envio de emails.
emails
Hugo Pedro Proença, © 2007

Administração - Recuperação
Rec peração
zTendo criado os devices de backup e
executado as respectivas operações de
salvaguarda de informação, pode a
qualquer momento ser necessário
recuperar a informação
zOp primeiro passo
p será localizar o
ficheiro “dump device” desejado para
p
recuperar a BD.
Hugo Pedro Proença, © 2007

Administração - Recuperação
Rec peração
z De seguida, e consoante o estado de perda
do sistema poderá ser necessário:

– Instalar SGBD
– R t
Restaurar ab
base de
d dados
d d principal
i i l (master)
( t )
– Criar os devices para a base de dados
– Restaurar a base de dados
– Restaurar os ficheiros de registo de actividade
Hugo Pedro Proença, © 2007

Administração - Mirroring
z Como forma de incremento de segurança os
SGBD possuem ainda outra opção:
R li
Replicação
ã (Mi
(Mirroring)
i )
z Os discos rígidos constituem uma das partes
mais vulneráreis a falhas físicas no sistema
computacional.
z As operações de mirroring são efectuadas
ao nível dos devices e portanto
transparentes para as aplicações cliente.
Hugo Pedro Proença, © 2007

Administração - Mirroring

abcd
efa

a
SGBD

abcd
efa
Hugo Pedro Proença, © 2007

Administração - Mirroring
z Quando o SGBD está a aceder a um
dos devices e deixa de o conseguir
fazer passa automaticamente para o
device de mirror sem que isso seja
perceptível para a aplicação cliente.
z Ao editar as opções
pç de um device é
possível definir as propriedades de
g
mirroring
Hugo Pedro Proença, © 2007

Administração - Mirroring
z É imprescindível que ao implementar
processos de mirroring, estes também sejam
f it para a base
feitos b de
d dados
d d principal
i i l
(master) do SGBD
– Esta BD contém informação imprescindível à
correcta execução do processo de mirroring.
z Finalmente
a e te é necessário
ecessá o indicar
d ca os
parâmetros de mirroring da base de dados
principal.
Hugo Pedro Proença, © 2007

Data Warehouses
- A crescente necessidade de sistemas
“inteligentes” e de aquisição de conhecimento
levaram à necessidade de implementação de
Data Warehouses.

- O que é uma Data


D t WWarehouse
h ?
- “Colecção de bases de dados orientadas por assunto e
desenhadas para suportar sistemas de apoio à decisão”
(William Inmon)
- Bases de dados desenhada e optimizada para um tipo
de processamento específico.
Hugo Pedro Proença, © 2007

Data Warehouses
z Orientada por Assunto
– A informação contida numa Data Warehouse pertence a
p
um domínio específico,, em vez de englobar
g as
necessidades específicas de uma organização
z Integrada
– Apesar da informação poder ter origem diversas, deve-
deve
se encontrar num estado estável e coerente.
z Variação temporal
– Toda a informação contida numa Data Warehouse esta
associada a um intervalo específico de tempo.
z Não-Volatilidade
– Toda a informação é estável dentro da Data Warehouse.
Warehouse
Pode ser adicionada mas não removida informação.
Hugo Pedro Proença, © 2007

Data Warehouses
z Processo de integrar as transformações efectuadas sobre
determinado tipo de informação por forma a permitir a
aplicação de sistemas de aquisição de conhecimento.
z Aquisição de conhecimento não-imediato a partir da
análise factual de uma BD.
z Normalmente alimentadas por um ou vários sistemas
OLTP.
OLTP

– Sistemas de inferência.
– Geração de regras
regras.
• Arvore de decisão
– Algoritmos de agrupamento (Clustering)
– Sistemas de apoio à decisão
– ...
Hugo Pedro Proença, © 2007

Data Warehouses
z OnLine Transaction Process (OLTP)
– Enquadramento das bases de dados tradicionais.

– Âmbito de trabalho Æ Transação


– Quantidade de informação Æ Grupos de linhas
– Natureza da informação Æ Primitiva
– Volatilidade da informação Æ Alta
– Tempo de resposta Æ Segundos
– Prioridades Æ Desempenho e avaliabilidade
– Tipos de acessos Æ Predefinidos e estáticos
Hugo Pedro Proença, © 2007

Data Warehouses
z OnLine Analytical Process (OLAP)
– Enquadramento das Data Warehouses

– Âmbito de trabalho Æ Base de dados inteira


– Quantidade de informação Æ Linhas individuais
– Natureza da informação Æ Derivada
– Volatilidade da informação Æ Baixa
– Tempo de resposta Æ Horas, dias, ...
– Prioridades Æ Flexibilidade
– Tipos de acessos Æ Não definido e dinâmico
Hugo Pedro Proença, © 2007

Data Warehouses
Código Nome Idade Morada Função

z Tabela Clientes 1
5
Ana
José
22
24
Abc
Dfg
Operário
Operário
6 Paulo 55 Odk Director
– BD Tradicional 2 Carla 73 Ikj Secret.

• Criação
C i ã d da tabela
t b l
• Inserção de elementos
• Alteração de elementos
• R
Remoçãoã dde elementos
l
• Consulta da informação desejada
– Data Warehouse
• Instante em que foram adicionados, alterados ou
eliminados elementos.
• Aquisição de conhecimento sobre as alturas em que
normalmente
l se inserem,
i alteram
l ou removem
elementos
Hugo Pedro Proença, © 2007

Data Warehouses
z Administração de Data Warehouses
– São acedidas essencialmente ppara operações
p ç
de leitura
– Aplicação de processos analíticos sobre a
informação.
– Tal como nas Bases de Dados tradicionais:
• Conhecimento prévio das operações a efectuar.
• Conhecimento
C h i t prévio
é i das
d aplicações
li õ a acederd à BD.
BD
– Arquitectura
– Tipo de acesso
– Consultas-Padrão
– ...
Hugo Pedro Proença, © 2007

Data Warehouses
z Desenho de Data Warehouses
– Requisitos de acesso à informação, estruturas, índices
e processos de
d optimização
ti i ã (clustering)
( l t i ) são ã específicos
ífi
das Data Warehouses.
– Bastante usual a arquitectura em estrela: Dimension Table
Dimension Table

Subject Table

Dimension Table
Dimension Table
Hugo Pedro Proença, © 2007

Data Warehouses
z Arquitectura em Estrela
– Uma tabela central (Subject table) mantém a informação
primária sobre o assunto da Data Warehouse.
p
– Rodeada por tabelas que representam os factores que
influenciam (Dimension tables) a actividade.
z Justificações:
ç
– É uma arquitectura flexível o suficiente para permitir a adição
de novas tabelas á medida que a Data Warehouse cresce.
– É facilmente perceptível para os implementadores e
utilizadores da BD.
BD
– Modela a forma como os utilizadores tipicamente raciocinam
acerca de uma domínio.
• Facto central influenciado por vários factores.
– Muitos SGBD´s estão optimizados para construir junções em
arquitecturas em estrela, potenciando a eficiência do sistema.
Hugo Pedro Proença, © 2007

Data Warehouses

z Arquitectura em Estrela - Exemplo


Tipo Tempo

Rendimento

Clientes Local
Hugo Pedro Proença, © 2007

Data Warehouses
z Quando a complexidade do domínio aumenta, esta
arquitectura pode dar origem à "Floco de Neve" em que as
tabelas terminais da estrela são também influenciadas por
diversos factores e constituem elas próprias tabelas
centrais de outras estrelas.
D10 D9 D1

DS1 D2 D = Dimension table


D8 DS3 S = Subject Table
DS = Dimension / Subject Table
S1 D3
D7
DS4 DS2

D6 D5 D4
Hugo Pedro Proença, © 2007

Data Warehouses
– Desnormalização é factor bastante usual nas Data
Warehouses.
– Uma vez que funcionam como armazém para os dados e
as suas alterações, tendem a apresentar dimensões
elevadas.
– Necessidade de aplicação de mecanismos de
compressão sobre algumas tabelas ou atributos
específicos.
– Encorajamento de operações paralelas,
paralelas sem
necessidade de dependência entre parcelas da BD.
Hugo Pedro Proença, © 2007

Data Warehouses
z Registo de Informação
– Uma das tarefas principais consiste na análise dos
objectivos dos utilizadores da Data Warehouses de
forma a poder implementar métodos que registem
a informação pretendida.
• Evolução de determinados factores (ao longo do dia
dia,
hora, segundos, ...)
• Relação entre vários parâmetros
– Importante a percepção:
• Qual o objectivo principal da Data Warehouse?
• Que resultados se esperam obter após a análise da
informação aqui contida?
Hugo Pedro Proença, © 2007

Data Warehouses
z Registo de Informação
– Fase seguinte
g consiste na captura
p da
informação necessária a partir dos
sistemas OLTP.
• SGBD´s internos / externos,
• Sinais do utilizador,
• Sensores
Sensores, OLTP

• Etc...
OLAP

OLTP
Hugo Pedro Proença, © 2007

Data Warehouses
z Qualidade da Informação
– Utilizadores da Data Warehouse poderão não
ter:
• Conhecimentos específicos de informática.
• Conhecimento sobre significado de determinados
valores em campos específicos da BD
BD.
– Necessidade da informação permanecer
legível.
– Substituição de códigos por valores com
significado intrínseco.
– No processo de transferência da informação,
tomar previdência de forma a que permaneça
legível.
Hugo Pedro Proença, © 2007

Data Warehouses
z Qualidade da Informação – Exemplo
– Análise da relação entre a categoria dos empregados da
firma “X” e a sua produtividade.

Código_Categoria Produtividade Categoria Produtividade


1 17% Condutor 17%
5 27% Estagiário 27%
6 62% Chefe de Linha 62%
2 82% Efectivo 82%
Hugo Pedro Proença, © 2007

D t Warehouses
Data W h
z Qualidade da Informação
– Identificação de informação inválida ou
irrelevante.
irrelevante
– A implementação de valores por defeito pode
constituir um problema.
• A
Ao id
identificar
tifi valor
l "1/1/1900" em “Dt
“Dt_Nascimento”
N i t ”
significa que o empregado tem realmente 103 anos, ou
não?
– Ter em mente que a análise da informação será
feita por sistemas computacionais.
• Pouco racionais
• Pouco
P fl
flexíveis
í i
Hugo Pedro Proença, © 2007

D t Warehouses
Data W h
z Qualidade da Informação
– Necessário o estabelecimento de políticas
relativamente a anomalias (inevitáveis)
• Encontradas pelos implementadores.
• Idenbtificadas pelos utilizadores finais.

– Inconsistências nos sistemas OLTP reflectem-


se nas Data Warehouses
• Ignorar inconsistencias?
• Corrigir o problema no sistema OLTP?
• Corrigir
g o problema
p na fase de importação
p ç da
informação?
Hugo Pedro Proença, © 2007

D t Warehouses
Data W h
z Desempenho de Data Warehouses
– Tabelas automáticas de sumarização
• Constituem um dos factores principais com vista a
melhoria da eficiência de uma Data Warehouse
• Consistem em tabelas / vistas, actualizadas a partir de
eventos (triggers) e que sumariam o conteúdo de
parcelas de informação.
• Alguns SGBD´s permitem a sua criação automática a
partir das funções matemáticas SQL:
– COUNT
– SUM
– AVG
– MIN
– MAX
Hugo Pedro Proença, © 2007

D t Warehouses
Data W h

z Consistência da informação
– Informação nos sistemas OLTP-fonte
está permanentemente a mudar
• Necessidade de actualização da Data
Warehouse.
Warehouse
– Implementação de mecanismos que
determinem o g
grau de actualização
ç da
Data Warehouse
• Grau de confiança nos resultados obtidos
após análise e aquisição de conhecimento.
conhecimento