segurança em banco de dados 1 prof: thiago moraes martins bacharel em sistemas de informa ç ão p...

Segurança em Banco de Dados

1

Prof: Thiago Moraes MartinsBacharel em Sistemas de InformaçãoPós-Graduação Software Livre AplicadoPós-Graduação Analista de SistemasPós-Graduação Metodologia do Ensino SuperiorMestrado Engenharia de Software (Andamento)

Certificado ITILCertificado COBITCertificado CWSP


2

Refactoring de Banco de Dados


3

Para que serve:

As técnicas de refactoring de banco de dados permitem evoluir de forma segura o design de um esquema em pequenos passos. Além disso, elas ainda podem ser utilizadas para apoiar o desenvolvimento de software evolutivo.

Em que situação o tema útil:

Além de serem muito úteis na migração de bancos de dados legados, as técnicas apresentadas neste artigo permitem alterações em esquemasque já estejam em produção. Sendo esta uma das grandes dificuldadesdas empresas de desenvolvimento de software


4

As empresas de desenvolvimento de software têm evoluído constantemente. Muitas delas devem isto às novas e modernas metodologias ágeis que defendem a construção do software de maneira incremental e iterativa. Entretanto, disponibilizar sistemas de informação com qualidade em ciclos cada vez menores, ainda é uma missão desafiadora para muitas delas. Isto porque, é preciso garantir que a cada entrega, o sistema não perderá as suas funcionalidades e continuará sem erros. Além do mais, estas metodologias não prevêem a mesma iteratividade para o banco de dados. Para finalizar, algumas destas empresas ainda utilizam bancos de dados legados e não migram para sistemas mais novos por diversos motivos, dentre eles:


5

- Complexidade;- Alto custo;- Mudança de cultura da empresa;- Falta de conhecimento dos desenvolvedores;- Mudanças de paradigmas dos DBAs.


6

O antes e o depois

Os consultores de informática: Pramod J. Sadalage e Scott W. Ambler criaram algumas técnicas para refatoração de banco de dados.

Estas técnicas têm como base os mesmos objetivos das metodologias ágeis: minimizar o risco pelo desenvolvimento de software em períodos curtos, chamados de iteração, os quais duram de uma a quatro semanas.

Cada iteração é como um projeto de software em miniatura, incluindo todas as tarefas necessárias para implantá-lo: planejamento, análise de requisitos, projeto, codificação, teste e documentação.


7

É neste cenário que surge a figura do DBA ágil. Diferente do DBA comum,este participa de todas as iterações do projeto, planejando o esquema do banco de dados e apoiando a equipe de desenvolvimento.


8Figura 1. Modelo Cascata.


9

O que é Refactoring?

Outra conseqüência é a melhora no entendimento do código, o que facilita a manutenção e evita a inclusão de defeitos.

É fundamental que o sistema de software possua testes automatizados para realizar refatorações.

Dessa forma será possível garantir que o comportamento externo não foi alterado.


10

O que é Refactoring de Banco de Dados?

Refactoring de Banco de Dados não é mágica! Consiste em simples mudanças no esquema do banco de dados (tabelas, views, trigger, procedures, etc.) que melhoram o design sem alterar a semântica e o significado dos dados que já estão persistidos. O processo de refactoring de banco de dados define a forma de evoluir de maneira segura um esquema em pequenos passos (incremental e evolutivamente).

Ela também fornece uma estratégia coerente para organizações quequerem migrar seus bancos de dados legados para outros maismodernos.


11

Figura 2. Modelo Espiral.


12

Conceitualmente, refactoring de banco de dados é mais difícil que refactoring de código. Isto porque, refactoring de código precisa apenasmanter a semântica comportamental, enquanto refactoring de banco de dados, além de ter esta obrigação, ainda precisa assegurar a semântica informacional. A complexidade de um projeto de refactoring de banco de dados pode ser ainda maior em ambientes onde a arquitetura de acessoaos dados é altamente acoplada, como o exemplo da Figura 3.


13Figura 3. Modelo complexo de arquitetura de acesso aos dados.


14

Por outro lado, algumas empresas têm o privilégio de possuir uma arquitetura mais simples, onde apenas uma aplicação acessa o banco de dados, permitindo assim, a refatoração de ambos em paralelo. Estas aplicações são conhecidas como “standalone” ou sistemas “stovepipe”.


15

Por que utilizar Refactoring de Banco de Dados?

1. Reparar bancos de dados legados: permite evoluir de forma segura o design do esquema em pequenos passos, tornando-se uma técnica importante para a melhoria do patrimônio legado dentro das organizações. Esta é, sem duvidas, muito menos arriscada do que a abordagemconhecida como “big bang”, onde as melhorias são aplicadas de uma só vez em produção. Além disso, é muito melhor do que “vamos migrare ver no que dá”;

2 Apoiar o desenvolvimento de software: usando estas técnicas pode-se apoiar no processo de desenvolvimento de softwaresevolutivos, incluindo Rational Unified Process (RUP),


16

O que deve ser refatorado?

- Tabela genérica: quando uma tabela está sendo usado para armazenar vários tipos de entidades, é provável que exista uma falha de projeto. Umexemplo é a tabela de pessoa, onde são inseridas informações de clientes e de fornecedores. O problema é que cliente e fornecedor têm as suas diferenças, e desta forma, a tabela conterá colunas que só serãopreenchidas quando o tipo da pessoa for um ou outro;

- Coluna genérica: desta mesma forma, se uma coluna está sendo usadapara vários fins, é provável que exista um código extra para identificar osdados contidos nela.


17

Um exemplo é uma coluna da tabela de pessoa usada para armazenar data de nascimento de um cliente ou a data de admissão de um empregado.A única forma saber se o dado contido nesta coluna é uma data de admissãoou uma data de nascimento, é verificando outra coluna que identifique apessoa. Agora suponha que seja necessário adicionar a data denascimento do empregado, se for criado uma nova coluna, a tabela ficará ainda mais redundante;

-Dados redundantes: os dados redundantes é um problema grave nos bancos de dados operacionais, pois quando os dados são armazenados em vários locais, a possibilidade de inconsistência é muito grande.

É comum, por exemplo, ter informações de clientes armazenadas em locais diferentes, e no momento em que estes dados necessitarem de manutenção será difícil saber qual deles é o correto;


18

- Dados redundantes: os dados redundantes é um problema grave nos bancos de dados operacionais, pois quando os dados são armazenados em vários locais, a possibilidade de inconsistência é muito grande.

É comum, por exemplo, ter informações de clientes armazenadas emlocais diferentes, e no momento em que estes dados necessitarem de manutenção será difícil saber qual deles é o correto;


19

-Tabelas com muitas linhas: tabelas muito grandes são fortes candidatasa causar problemas de desempenho. O exemplo mais comum é a tabela de movimento de estoque, onde são armazenadas todas as movimentações dos produtos. Neste caso, o correto seria criar tabelas de histórico para guardar os dados antigos, deixando a vista apenas os registros de determinado período;

-Modelo intocável: se você tem medo de alterar o modelo do seu bancode dados é porque certamente ele precisa ser refeito. O medo da mudançaé uma boa indicação de que você tem sérios riscos técnicos em suas mãos, que só vão piorar ao longo do tempo.


20

Antes de começar

Antes de começar um projeto de refactoring de banco de dados, leve emconsideração as recomendações a seguir:

Verifique se o refactoring é mesmo necessário, pois talvez a estrutura domodelo atual esteja correta. É comum os desenvolvedores discordarem, ou simplesmente não compreender o projeto existente de um banco de dados.

Este mal-entendido poderá levá-los a acreditar que o projeto precisa seralterado quando ele realmente não precisa.


21

O DBA deve ter um bom conhecimento do esquema do banco de dados, e em casos de haver sistemas externos acessando-o, ele deve saber quem contatar para discutir questões técnicas e tomar as medidas cabíveis.

Além disso, o DBA, por ter participado de diversos projetos relacionados ao esquema do banco de dados, conhece o panorama global da empresa, possuindo uma visão importante que pode não estar aparente do ponto de vista dos desenvolvedores;


22

- É preciso ter em mente que nenhuma estrutura deve ser tão rígida a ponto de ser inalterável, isto porque, pequenas melhorias sempre irão acontecer;

- Divida o seu projeto de refactoring em pequenas etapas para facilitar o controle e a compreensão de todos os profissionais envolvidos.

Entretanto, isto exigirá um controle rigoroso sobre o versionamento dasalterações. Por exemplo: imagine que em uma etapa qualquer, você altere o nome da coluna de uma tabela, e algumas semanas depois, seja necessário mover a mesma coluna para outra tabela. Se estas alteraçõesnão forem aplicadas no momento adequado e não estiveremversionadas, a última refatoração poderá ser executada antes da primeira;


23

-Evite duplicações de código SQL. Utilize um framework de persistênciapara encapsular o acesso ao banco de dados.


24

Qual a melhor estratégia de refatoração?

1. Avaliação do impacto: antes de fazer qualquer alteração na estrutura,deve-se avaliar o tamanho do impacto, tanto interno quanto externo, ou seja, descobrir todas as views, triggers, procedures, constraints e sistemas que serão afetados com a mudança;

2. Definição do período de transição: após fazer a avaliação acima, serápossível definir com maior precisão o período de transição. Entretanto, deve-se fazer um controle rigoroso para garantir que os prazos estabelecidos serão seguidos;

3. Criação e execução de testes: antes de alterar o modelo é precisogarantir que atualmente ele está funcionando. Crie testes automatizados para facilitar a identificação e correção dos impactos causados pelas refatorações;


25

4. Executar a refatoração: crie os scripts necessários para aplicar a refatoração e adicione os comentários nas colunas, tabelas e triggers queserão removidas após o período de transição;

5. Execute os testes: antes de anunciar as refatorações feitas, é preciso garantir que nada do que estava funcionando deixou de funcionar. Para isto, execute os testes criados antes da refatoração e caso algum deles falhe, faça as correções necessárias;

6. Alteração das dependências internas e externas: se for possível, façaas alterações necessárias nos objetos internos (triggers, procedures, etc.) e externos (sistemas, outros bancos de dados, etc.) em paralelo. Caso contrário, prefira iniciar as alterações pelos objetos internos, já que estãomais próximos do seu domínio.


26

Categorias de refatoração de banco de dados

As técnicas de refactoring de banco de dados estão divididas em categorias. Neste artigo serão abordadas as cinco principais. São elas:

1.Estrutural;2.Qualidade dos dados;3.Integridade referencial;4.Arquitetura;5.Métodos.


27

Estrutural

A categoria estrutural engloba mudanças em estruturas de tabelas e/ou views, como:

- Renomear colunas, tabelas, views, functions e procedures;- Introduzir colunas calculadas para melhorar a performance dos sistemas;- Introduzir surrogate keys para aumentar a consistência dos dados;- Mesclar colunas e tabelas para evitar redundâncias;- Mover coluna para outra tabela;- Particionar tabelas com muitas colunas para melhorar a coesão do esquema do banco de dados;


28

-Substituir associações um para muitos por tabelas associativas.

-Ao implementar a refactoring estrutural, leve em consideração alguns impedimentos comuns que certamente aparecerão. Dentre os quais se podem listar:

- Triggers circulares: em quase todas as refactorings que alteram a estrutura do modelo, é comum o uso de triggers para controlar o sincronismo dos dados. Em alguns casos, podem-se ter duas ou mais triggers, uma disparando a outra. E se não houver um controle rigoroso, elas entrarão num loop infinito comprometendo o desempenho do banco de dados;

- Objetos do banco que acessam a tabela: é muito comum, durante este tipo de refatoração, deixar para trás alguns objetos que fazem referências às tabelas alteradas. Exemplos: views, triggers, stored procedures, etc.


29

Qualidade de dados

As implementações feitas nesta categoria visam melhorar a qualidade dasinformações contidas no banco de dados. São elas:

- Adicionar tabelas de consulta;- Padronização de siglas;- Aplicar tipos padrões para evitar, por exemplo, que em uma tabela uma informação seja do tipo varchar e em outra ela seja do tipo numérico;- Adicionar ou remover chaves estrangeiras;- Adicionar ou remover valores padrões em colunas;- Mover dados de uma tabela para outra.


30

Integridade referencial

As implementações feitas nesta categoria visam garantir a integridade dos dados. São elas:

- Adicionar ou remover chave estrangeira;- Adicionar trigger para coluna calculada;- Adicionar exclusão em cascata;- Adicionar trigger para armazenar em log as alterações.


31

- Adicionar métodos CRUD (procedures para inserção, consulta, atualização e exclusão);- Adicionar encapsulamento à tabela através de views;- Adicionar métodos de cálculos;- Adicionar tabelas apenas para leituras;- Migrar métodos dos sistemas externos para o banco de dados.

Arquitetura

As implementações feitas nesta categoria visam melhorar de forma globalas interações entre os programas externos e o banco de dados. São elas:


32

Métodos

Como o próprio nome sugere, as refatorações desta categoria têm por objetivo melhorar a qualidade de stored procedures, triggers ou funções armazenadas no banco de dados.

Por razões de simplicidade, Ambler se refere a estes três tipos de funcionalidade simplesmente como métodos. As implementações comuns desta categoria são:

- Adicionar ou remover parâmetros dos métodos;- Renomear métodos;- Reordenar os parâmetros dos métodos;- Substituir vários métodos por um método genérico;- Substituir um método genérico por vários outros métodos.


33

FIM

segurança em banco de dados 1 prof: thiago moraes martins bacharel em sistemas de informa ç ão p...

Documents