Nome do Banco de Dados: dw_tasks Objetivo: Armazenar e gerenciar dados relacionados a tarefas, projetos, usuários, roles, status, epics, stories e tags, seguindo um modelo de data warehouse com suporte a SCD (Slowly Changing Dimensions) Tipo 2.

Ferramentas utilizadas:

• Gerenciamento de Banco de Dados: pgAdmin, DBeaver
• ORM / Versionamento: Flyway (via Redgate Flyway Desktop)
• SGBD: PostgreSQL

• Permite versionar o banco de forma rastreável e segura
• Automatiza alterações estruturais com scripts SQL versionados
• Suporte a CI/CD e integração com projetos Java
• Compatível com PostgreSQL
• Interface gráfica com Flyway Desktop

Requisitos: Baixar Flyway Desktop - Community e clonar o projeto atualizado do repositório GitHub: web-server-2025-1

• Abra o Flyway Desktop
• Clique em New Project
• Nomeie o projeto (ex: dashflow_db_versioning)
• Em "Script location", selecione a pasta src/main/resources/db/migration
• Escolha o tipo de banco: PostgreSQL

• No menu lateral, clique em Database > New Connection

• Insira os dados da conexão:

  • Host: localhost
  • Port: 5432 (ou a porta usada)
  • Database: postgres
  • Schemas: dw_dashflow,dashflow_appl
  • Username: seu usuário do PostgreSQL
  • Password: sua senha do PostgreSQL

• Clique em Test Connection

• Se estiver tudo certo, clique em Save

• Clique no botão + no menu esquerdo e selecione Versioned

• Preencha:

  • Description: uma descrição clara da alteração (ex: criar_tabela_usuarios)
  • Script: insira o SQL que será aplicado

CREATE TABLE usuarios (
  id SERIAL PRIMARY KEY,
  nome VARCHAR(100),
  email VARCHAR(100) UNIQUE
);

• Clique em Save para salvar o script
• Após salvar, o script será listado na aba principal do projeto Flyway Desktop

• No menu superior, clique em Migrate
• O Flyway aplicará os scripts pendentes na ordem de versão
• Verifique a aba Output para conferir se tudo ocorreu corretamente
• Caso ocorra erro, revise o script ou a conexão antes de tentar novamente

• A aba History mostra todos os scripts aplicados, com:

  • Número da versão (ex: V1__criar_tabela_usuarios.sql)
  • Status da execução (Success, Failed, Skipped)
  • Data e hora da aplicação

• Isso permite rastrear o que foi alterado e quando

Embora o Flyway Desktop facilite o versionamento e a aplicação dos scripts no banco de dados, ele não faz o commit diretamente no seu sistema de controle de versão (Git). Isso significa que, após você criar e aplicar os scripts de migração, você precisa comitar esses arquivos manualmente para o repositório Git.

1. Verifique os scripts no Flyway Desktop Após a criação e aplicação de migrações no Flyway Desktop, seus scripts de migração estarão na pasta de migrações do seu projeto (normalmente, em src/main/resources/db/migration).

2. Abra o Git no seu terminal ou na IDE Você pode usar o terminal ou o Git integrado na sua IDE (ex: IntelliJ, VS Code, etc.). Caso esteja usando o terminal, navegue até a pasta do projeto.

3. Comitar os scripts de migração Após verificar os arquivos de migração, adicione-os ao Git, comite as mudanças e faça o push para o repositório:

git add src/main/resources/db/migration/
git commit -m "Adicionada migração para criar tabela 'usuarios'"
git push origin main

• Explicação: O git add adiciona os novos scripts de migração ao repositório. O git commit cria um commit com uma mensagem descritiva, e o git push envia as mudanças para o repositório remoto (por exemplo, GitHub, GitLab).

• Integração manual: Embora o Flyway Desktop facilite a execução de migrações, ele não integra diretamente com o Git. Então, depois de aplicar as migrações no banco, você deve gerenciar o versionamento do código e dos scripts manualmente.

• Organize o histórico do Git: Para facilitar o controle de alterações, sempre associe os commits de migração a tarefas específicas do projeto ou mudanças nas funcionalidades. Isso mantém o histórico do Git claro e organizado.

Requisito: Clonar o projeto atualizado do repositório GitHub: web-server-2025-1

• No painel do projeto, navegue até src/main/resources/db/migration

• Crie um novo arquivo com o padrão de nomenclatura: V<versão>__<descrição>.sql

  • Exemplo: V1_2__criar_tabela_tags.sql

CREATE TABLE tags (
  id SERIAL PRIMARY KEY,
  nome VARCHAR(50) NOT NULL
);

• No IntelliJ, abra o terminal (View > Tool Windows > Terminal)
• Rode o comando:

./mvnw flyway:migrate

Ou, se estiver usando Gradle:

./gradlew flywayMigrate

• O Flyway vai ler os scripts da pasta db/migration e aplicar os que ainda não foram executados no banco

• Verifique se a tabela flyway_schema_history foi atualizada no banco.
• Cada script aplicado é registrado com data, checksum e status.

• Após rodar os scripts, valide as alterações no banco de dados. Você pode:

  • Verificar se as tabelas ou colunas esperadas foram criadas com sucesso.
  • Executar uma consulta SQL simples para verificar a estrutura, por exemplo:

SELECT * FROM usuarios;

• Se a consulta retornar os dados esperados (ou uma tabela vazia, no caso de uma nova tabela), significa que o script foi aplicado corretamente.

• Após confirmar que as alterações foram feitas no banco, teste a aplicação para garantir que:

  • As novas funcionalidades ou tabelas estão sendo usadas corretamente pelo backend.
  • Não há erros de conexão com o banco ou falhas devido à aplicação da migração.

• Após garantir que as alterações estão funcionando corretamente, é hora de comitar e enviar os scripts de migração e quaisquer outras alterações no código para o repositório:

git add .
git commit -m "✨(feat): adicionada a migração para criação da tabela 'usuarios'"
git push origin main

• Isso mantém o histórico de versões do banco e do código atualizado.

• Caso a alteração tenha sido significativa ou complexa, é interessante documentar o que foi feito nos comentários do script de migração ou na documentação do projeto.

Exemplo de comentário no script:

-- Criação da tabela usuarios
-- Esta tabela irá armazenar informações dos usuários do sistema, como nome e email.

• Use nomes de scripts claros e padronizados: V1__nome_descritivo.sql
• Nunca edite scripts já aplicados — crie um novo com nova versão
• Organize os scripts em subpastas por tipo, se necessário (ex: dimensoes/, fatos/)
• Sempre teste os scripts em ambiente local antes de aplicar em produção
• Faça commits frequentes e associe cada versão a uma issue/tarefa do projeto

O versionamento com Flyway garante que todas as alterações no banco de dados sejam rastreáveis, reversíveis (em casos controlados) e consistentes entre ambientes. Combinado ao PostgreSQL, essa prática traz segurança e organização ao ciclo de vida do banco de dados dw_tasks.

Para dúvidas ou problemas, consulte a documentação oficial do Flyway ou entre em contato com o time responsável pela modelagem de dados do projeto.

Criação das tabelas, separadas em 3 conjuntos de dados: dataflow_appl, dw_tasks e public.

• Tabelas principais criadas: fact_tasks, projects, users, tools, stories, epics, status, roles, user_role, dates, tags, task_tag.
• Relacionamentos funcionais definidos.

Versionamento feito por substituição de arquivo.

Alterações feitas:

• Nova fato adicionada: fact_issues (nova granularidade focada em "issues").

• Novas dimensões adicionadas:

  • issue_priority
  • issue_severity
  • issue_status
  • issue_type

• tags agora também se relaciona com fact_issues.

• projects, users, tools, status, stories, epics, roles, user_role, dates, tags, task_tag, fact_tasks permanecem com mesma estrutura da V1.

• Expansão do modelo para representar mais atributos típicos de ferramentas de gestão de tarefas (prioridade, severidade, tipo etc).

Versionamento feito por substituição de arquivo.

Alterações feitas:

• Novo escopo focado em gestão de acessos e segurança.

• Banco dataflow_appl recebeu nova modelagem separada, mais enxuta e focada em autenticação e permissões:

  • Tabelas novas: permissions, role_permissions, user_roles, audit_log, accounts.
  • Tabelas reutilizadas com estrutura reduzida: users, tools, roles.

• Remoção de campos relacionados a controle histórico e descrição das tabelas herdadas.

• Registro de ações de usuários com a nova tabela audit_log.

Versionamento feito usando o padrão de versões do Flyway.

Alterações feitas:

• Adição da tabela accounts, conectando usuários, ferramentas, projetos e papéis de forma mais contextualizada.
• Inclusão da tabela audit_log, responsável por registrar logs de requisições feitas por usuários na aplicação.
• Introdução de controle de permissões granulares com novas tabelas: permissions e role_permissions.
• Refatoração das tabelas users, roles e tools:
• Separação das responsabilidades entre operação da aplicação (autenticação/autorização) e análise de dados.

Versionamento feito com Flyway.