IN1008 – Projeto Conceitual de BD Projeto Evolutivo de Banco de Dados Por: Nielso Oliveira Júnior ncoj@cin.ufpe.br

Roteiro Motivação Objetivos Introdução Projeto Evolutivo de Banco de Dados Refactoring de Banco de Dados Referências

Motivação O funcionamento eficaz das organizações passa pelo gerenciamento e controle de seus ativos de informação Os sistemas de bancos de dados tem se tornado, cada vez mais, essenciais para o processo de tomada de decisão nas organizações Rapidez e qualidade no desenvolvimento de sistemas tem sido uma busca constante da indústria de software na última década Profissionais de banco de dados têm que buscar essa agilidade na entrega de seus produtos de trabalho

Objetivos Discutir o projeto de banco de dados com a adoção de algumas práticas ágeis Desenvolvimento incremental Refactoring

Figura 1. Níveis de Abstração de um Projeto de BD [1] Introdução Projeto de Banco de Dados Atividade de modelagem de dados em diversos níveis de abstração de forma que o BD torne-se eficaz, eficiente e fácil de manter [1] Projeto da estrutura lógica e física de um ou mais bancos de dados de acordo com as necessidade de informação do usuário, provendo uma estrutura fácil de ser comprendida e que atenda aos objetivos de performance (tempo de resposta, tempo de processamento, espaço de armazenamento, etc) [2] Figura 1. Níveis de Abstração de um Projeto de BD [1]

Figura 2. Ciclo de Vida Cascata Introdução Modelo de Ciclo de Vida Cascata Abordagem sequencial para o desenvolvimento de softwares que começa com a especificação de requisitos pelo cliente e progride a longo do planejamento, modelagem, construção e implantação [3] Requisitos Projeto Implementação Testes Implantação Figura 2. Ciclo de Vida Cascata

Figura 3. Projeto de BD no Ciclo de Vida Cascata Introdução E onde entra o Projeto do BD? Requisitos Projeto Projeto BD Implementação Projeto Conceitual Testes Projeto Lógico Implantação Projeto Físico Figura 3. Projeto de BD no Ciclo de Vida Cascata

Introdução A principal vantagem do Ciclo de Vida Cascata diz respeito Requisitos Projeto Implementação Testes Implantação A principal vantagem do Ciclo de Vida Cascata diz respeito à documentação que é gerada em cada fase. Por outro lado... A necessidade de se firmar compromissos num estágio inicial do projeto torna difícil responder a mudanças de requisitos. [4] MUDANÇAS DE REQUISITOS SÃO INEVITÁVEIS!

Figura 4. Ciclo de Vida Incremental. Adaptado de [3] Introdução Modelo de Ciclo de vida Incremental Combina elementos do modelo cascata aplicado de maneira iterativa. Cada sequencia linear produz incrementos do software passíveis de serem entregues, fornecendo progressivamente funcionalidade para os clientes. [3] Requisitos Projeto Implementação Testes Implantação Entrega 1 Entrega 2 Entrega n . . . Tempo decorrido do projeto Figura 4. Ciclo de Vida Incremental. Adaptado de [3]

Introdução Os requisitos são priorizados e os mais Projeto Implementação Testes Implantação Os requisitos são priorizados e os mais prioritários são entregues nos primeiros incrementos. Assim, minimiza-se os riscos do projeto falhar com um todo, Pois os problemas não são descobertos quando está tudo pronto [4] Mudanças nos requisitos podem levar incrementos serem retirados de uso ou retrabalhados. O gerenciamento do projeto (custos, cronograma, configuração, etc) fica mais complexo. [5]

Figura 5. Projeto de Banco de Dados no Ciclo de Vida Incremental Introdução E como fica o projeto do BD? Projeto BD Projeto Conceitual Projeto Lógico Projeto Físico Requisitos Projeto Implementação Testes Implantação Projeto BD Projeto Conceitual Projeto Lógico Projeto Físico Requisitos Projeto Implementação Testes Implantação Projeto BD Projeto Conceitual Projeto Lógico Projeto Físico Requisitos Projeto Implementação Testes Implantação Entrega n . . . Entrega 2 Entrega 1 Como fazer o projeto do banco de dados sem ter os requisitos completamente definidos??? Tempo decorrido do projeto Figura 5. Projeto de Banco de Dados no Ciclo de Vida Incremental

Introdução Rational Unified Process - RUP Processo de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM. Usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza o desenvolvimento iterativo e incremental de software. Figura 6. Rational Unified Process. Copyright (c) 1987 - 2001 Rational Software Corporation

Introdução Metodologias Ágeis Em 2001, 17 pessoas da área de desenvolvimento de software se reuniram e formaram a Agile Alliance. Buscavam uma alternativa a processos heavyweight de desenvolvimento do software. Indivíduos e Interações mais que processos e ferramentas. Software operante mais que documentações completas. Colaboração do cliente mais que negociações contratuais Responder às mudanças mais que seguir um planejamento [6]

Introdução Metodologias Ágeis Formularam princípios que definem os critérios para processos ágeis de desenvolvimento: Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais; Softwares funcionais são entregues frequentemente (semanas, ao invés de meses) Softwares funcionais são a principal medida de progresso do projeto; Até mesmo mudanças tardias de escopo no projeto são bem-vindas; Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores; Projetos surgem através de indivíduos motivados, e que deve existir uma relação de confiança. [6]

Introdução Metodologias Ágeis O método mais eficiente e eficaz de fazer saber à informação para uma equipe e dentro de uma equipe de desenvolvimento é a conversa olho no olho Atenção contínua à excelência técnica e bons projetos, melhora a agilidade Simplicidade é essencial As melhores arquiteturas, requisitos, e projetos emergem de equipes auto-organizadas Em intervalos regulares, a equipe reflete sobre como podem ser mais eficazes, então sintonizam e ajustam seus comportamentos desta maneira. [6]

Introdução Desenvolvimento Incremental é uma REALIDADE! XP RUP Desenvolvimento Incremental é uma REALIDADE! OpenUP Scrum E como fica o projeto de Banco de Dados neste cenário?

Projeto Evolutivo de BD O desenvolvimento incremental requer uma mudança de postura dos profissionais. Algumas dificuldades no relacionamento entre desenvolvedores e Dba’s estão relacionadas a Diferença de prioridades Super especialização de papéis Impedância do processo Impedância tecnológica Falta de atualização tecnológica dos gestores Desenvolvedores estão focados nas necessidades específicas de seus projetos. DBAs estão preocupados em “proteger” os bancos que estão sob a sua responsabilidade, minimizando as mudanças nos mesmos. A super especialização de papéis leva os profissionais a direcionar seus esforço para saber tudo relacionado a uma determinada área tornando-se, às vezes, alheio a tudo o mais. Infelizmente, muitos profissionais de banco de dados ainda vêem o desenvolvimento de software como uma atividade serial, onde o modelo de dados completo precisa ser feito no início do projeto (big up-front design); Desenvolvedores trabalham com objetos e componentes, enquanto DBAs com bancos de dados e tabelas. [7]

Projeto Evolutivo de BD – Caso 1 Alan Harriman, Paul Hodgetts e Mike Leo ~ 5 pessoas ~3 semanas/entrega Premissas Consideradas O custo de mudar o banco de dados é muito maior que mudar a aplicação Modelos de dados são inerentemente mais estáveis que a lógica de negócio Práticas Adotadas Consultores foram contratados para fazer o projeto do banco de dados no início do projeto (big up-front design) [8]

Projeto Evolutivo de BD – Caso 1 Com o início do desenvolvimento, surgiram as necessidades de mudança no banco de dados Um desenvolvedor ficou responsável por realizar tais modificações. Com o tempo, criou-se um “gargalo” Mudanças simples passaram a ser realizadas pelos próprios desenvolvedores. Mudanças de maior impacto eram feitas em grupo. No projeto inicial, foram incluídos campos pensando em necessidades futuras. O custo de manter esses campos passou a ser maior que o benefício de tê-los. A equipe decidiu por exclui-los. Com a implantação do primeiro release, foi necessário definir uma estratégia para as mudanças [8]

Projeto Evolutivo de BD – Caso 1 Discutir as mudanças com a equipe Escrever rotinas de conversão dos dados Versionar scripts Alterar o esquema de desenvolvimento Executar migração numa cópia do esquema de produção Realizar testes de integração Migração de dados? Sim Comparar esquema migrado com um esquema vazio Não Realizar as mudanças na camada de acesso aos dados Realizar testes unitários [8]

Projeto Evolutivo de BD – Caso 1 Conclusões Construir a aplicação a partir de um banco de dados já definido se mostrou mais difícil do que produtivo Apesar do projeto inicial do banco de dados ter se mostrado muito valioso para o conhecimento do domínio, utilizá-lo como banco de dados da aplicação impediu de adotar plenamente as práticas ágeis Libertar-se para criar incrementalmente o banco de dados lhes permitiu ampliar e aprofundar seus conhecimentos no domínio da aplicação Tornar-se responsável pelo banco de dados lhes permitiu entregar versões em iterações muito mais curtas. [8]

Projeto Evolutivo de BD – Caso 2 Martin Fowler, Pramod Sadalage e Peter Schuh Experiência do Projeto Atlas ~ 3 anos de duração ~100 pessoas (EUA, Austrália e India) + 200 tabelas [9]

Projeto Evolutivo de BD – Caso 2 Práticas adotadas DBAs e desenvolvedores trabalharam em colaboração constante; Cada desenvolvedor possuia sua própria instância do Banco de Dados; Des1 Des2 Des n Des1 Des2 Des n E1 Esquema de Desenvolvimento E2 En Figura 7. Esquemas individuais de desenvolvimento. Adaptada de [13] [9]

Projeto Evolutivo de BD – Caso 2 Práticas adotadas Os desenvolvedores integravam suas mudanças num Banco de Dados compartilhado (master instance); Log de mudanças Release X.Y ALTER TABLE ... CREATE TABLE ... UPDATE... Des1 Des2 Des n E1 Instância Master E2 En Figura 8. Atualização dos Esquemas [9] [13]

Projeto Evolutivo de BD – Caso 2 Práticas adotadas O código de acesso ao banco de dados foi ser isolado. Camada de Interface com o Usuário Camada de Lógica de Negócio Camada de Acesso ao Banco de Dados Banco de Dados Figura 9. Isolando ao acesso ao Banco de Dados [9]

Projeto Evolutivo de BD – Caso 2 Práticas adotadas Todas as mudanças foram tratadas como refactoring do Banco de Dados; Refactorings foram automatizados (DDL e DML); [9]

Refactoring de Banco de Dados Refactoring – técnica para reestruturar um código existente, melhorando sua estrutura interna sem mudar seu comportamento externo (funcionalidade). [14] Database Refactoring - Alteração simples no esquema do banco de dados com o objetivo de melhorar o projeto, sem alterar qualquer funcionalidade ou semântica dos dados. [10] Por que? Corrigir problemas em bancos de dados existentes Dar suporte ao desenvolvimento incremental [10]

Refactoring de Banco de Dados Fazer refactoring pode ser fácil... Figura 10. O melhor cenário [10]

Refactoring de Banco de Dados Mas normalmente não é! Figura 11. O pior cenário [10]

Refactoring de Banco de Dados Verifique a necessidade do refactoring Migre os dados Divulgue as mudanças que você fez Atualize os programas Selecione o padrão de refactoring mais apropriado Versione as mudanças Execute os testes de regressão Escreva os testes unitários Publique no ambiente de integração Passou? Não Modifique o Esquema do BD Publique no ambiente de produção Sim Figura 12. Realizando o refactoring. Adaptado de [10]

Refactoring de Banco de Dados É necessário haver um período de transição Figura 13. Ciclo de Vida do Refactoring de Banco de Dados [11]

Refactoring de Banco de Dados Padrões de Refactoring Estrutural: altera a estrutura de uma tabela, coluna, view, etc. Merge Column – funde duas ou mais colunas de uma mesma tabela. Voltar Figura 14. Exemplo de aplicação do padrão Merge Column [11]

Refactoring de Banco de Dados Split Table– divide uma tabela duas ou mais. Voltar Figura 15. Exemplo de aplicação do padrão Split Table [11]

Refactoring de Banco de Dados Qualidade dos dados: melhora a consistência e a utilização dos dados armazenados. Add Lookup Table – cria integridade referencial para uma coluna existente. Voltar Figura 16. Exemplo de aplicação do padrão Add Lookup Table [11]

Refactoring de Banco de Dados Introduce Common Format – aplica um formato consistente aos dados de uma determinada coluna. Voltar Figura 17. Exemplo de aplicação do padrão Introduce Common Format [11]

Refactoring de Banco de Dados Integridade Referencial: garante a integridade referencial dos dados. Add Foreing Key –define integridade referencial para uma coluna existente. Voltar Figura 18. Exemplo de aplicação do padrão Add Foreink Key [11]

Refactoring de Banco de Dados Introduce hard delete – remove uma coluna que indica a deleção lógica, realizando a deleção física do registro. Voltar Figura 19. Exemplo de aplicação do padrão Introduce Hard Delete [11]

Refactoring de Banco de Dados Arquitetural: melhora a maneira como programas externos interagem com o banco de dados. Add CRUD Method – define stored procedures para implementar inserção, recuperação, atualização e deleção de registros. Voltar Figura 20. Exemplo de aplicação do padrão Add CRUD Method [11]

Refactoring de Banco de Dados Introduce Index – define um novo índice. Voltar Figura 21. Exemplo de aplicação do padrão Introduce Index [11]

Refactoring de Banco de Dados Métodos: melhora a qualidade de uma stored procedure, função ou trigger. Add Parameter– define um novo parâmetro para um método existente. Voltar Figura 22. Exemplo de aplicação do padrão Add Parameter [11]

Refactoring de Banco de Dados Replace Nested Expressions With Guard Clauses – dsubstitui IFs aninhados por uma série de IFs separados. Antes BEGIN IF condition1 THEN -- do something 1 ELSE IF condition2 THEN -- do something 2 END IF; END; Depois BEGIN IF condition1 THEN -- do something 1 RETURN; END IF; IF condition2 THEN -- do something 2 END; Outros padrões de refactoring Voltar Figura 23. Exemplo de aplicação do padrão Replace Nested Expressions With Guard Clauses [11]

Referências [1] Fidalgo, Robson. Conceitos Básicos sobre Projeto e Ciclo de Vida de BD. Notas de Aula, 2009 [2] Elmasri, Ramez. Navathe, Shamkant. Fundamentals of Database Systems. Fourth Edition. Addison Wesley, 2003. [3] Presman, Roger S. Engenharia de Software. 6ª Edição. McGraw-Hill, 2006 [4] Sommerville, Ian. Engenharia de Software. 6 ª ed. São Paulo: Addison Wesley, 2003. [5] Natali, Ana C. Ciclo de Vida de Software. Notas de Aula, 2006. [6] Beck, Kent et al. Agile Manifesto. Disponível em http://www.agilemanifesto.org. Acessado em 10 de maio de 2009 [7] Ambler, Scott W. The Vision of the Agile Data Method. Dispnível em http://www.agiledata.org/essays/vision.html Acessado em 26 de abril de 2009. [8] Harriman, Alan. Hodgetts, Paul. Leo, Mike. Emergent Database Design: Liberating Database Development with Agile Practices. Proceeding of the Agile DEvelopment Conference. 2004. [9] Fowler, Martin. Sadalage, Pramod. Evolutionary Database Design. Disponível em http://martinfowler.com/articles/evodb.html. Acessado em 19 de abril de 2009 [10] Ambler, Scott W. The Process of Database Refactoring: Strategies for Improving Database Quality. Disponível em http://www.agiledata.org/essays/databaseRefactoring.html. Acessado em 26 de abril de 2009 [11] Ambler, Scott W. Catalog of Database Refactorings. Disponível em http://www.agiledata.org/essays/databaseRefactoringCatalog.html. Acessado em 08 de maio de 2009 [12] Heuser, Carlos Alberto. Projeto de Banco de Dados. Sagra Luzzatto, 2004, 5ª edição. [13] Schuh, Peter. Agility and the Database. Disponível em www.agilealliance.org/system/article/file/924/file.pdf. Acessado em 11 de maio de 2009 [14] Fowler, Martin. Refactoring Home Page. Disponível em http://www.refactoring.com. Acessado em 11 de maio de 2009.

Introdução Estratégias para o Projeto Conceitual de BD Top-down: a partir da identificação de entidades genéricas, são definidos seus atributos, relacionamentos e especalizações. Bottom-up: utilizada quando já se tem a descrição dos dados (sistema já existente, pastas, fichas, notas fiscais, etc.). Os dados (atributos) são agregados em entidades que posteriormente são relacionadas e generalizadas. Inside-out: a partir de uma entidade importante do modelo, são identificados seus atributos, entidades relacionadas, generalizações e especializações da entidade em foco até que o modelo esteja completo. [12] Voltar

Refactoring de Banco de Dados Outros Padrões Estruturais: Drop Column , Drop Table, Drop View, Introduce Calculated Column, Introduce Surrogate Key, Merge Column, Merge Tables, Move Column, Rename Column, Rename Table, Rename View, Replace LOB With Table, Replace Column, Replace One-to-Many With Associative Table,Replace Surrogate Key with Natural Key, Split Column, Split Table. Qualidade dos dados: Add Lookup Table, Apply Standard Codes, Apply Standard Type, Consolidate Key Strategy, Drop Column Constraint, Drop Default Value, Drop Non-Nullable Constraint, Introduce Column Constraint, Introduce Common Format, Introduce Default Value, Make Column Non-Nullable, Move Data, Replace Type Code With Property Flags. Voltar [11]

Refactoring de Banco de Dados Outros Padrões Integridade Referencial: Add Foreign Key Constraint, Add Trigger for Calculated Column, Drop Foreign Key Constraint, Introduce Cascading Delete, Introduce Hard Delete, Introduce Soft Delete, Introduce Trigger for History. Arquitetural: Add CRUD Methods, Add Mirror Table, Add Read Method, Encapsulate Table With View, Introduce Calculation Method, Introduce Index, Introduce Read Only Table, Migrate Method From Database, Migrate Method to Database, Replace Method(s) With View, Replace View With Method(s), Use Official Data Source. Voltar [11]

Refactoring de Banco de Dados Outros Padrões Métodos: Add Parameter, Consolidate Conditional Expression, Decompose Conditional, Extract Method, Introduce Variable, Parameterize Methods, Remove Control Flag, Remove Middleman, Remove Parameter, Rename Method, Reorder Parameters, Replace Literal With Table Lookup, Replace Nested Expression With Guard Clauses, Replace Parameter With Specific Methods, Split Temporary Variable, Substitute Algorithm. Voltar [11]

Agile Data Metodologia que visa definir estratégias para que os profissionais de tecnologia da informação possam trabalhar juntos e eficientemente nas questões relativas aos dados envolvidos num sistema de software Subscreve os valores e princípios do Manifesto Ágil, extendendo-o com filosofias que refletem a realidade enfrentada pelos profissionais e banco de dados Dados Definições Organizacionais Grupos Organizacionais Unicidade dos Projetos Trabalho em Equipe Melhor solução [7]

Agile Data Define 4 papéis DBA Ágil Desenvolvedor de Aplicações Administradores Organizacionais Arquitetos Organizacionais [7]