Home	Escopo e Cronograma	Processo	Design/Mockups	Configuração	Arquitetura	Infra	Código	BD

Banco de Dados

Visão Geral

O projeto utiliza PostgreSQL como banco de dados relacional e Prisma ORM para gerenciamento do esquema, migrations e interações com o banco. O Prisma facilita a modelagem dos dados e permite um fluxo estruturado para evolução do schema ao longo do desenvolvimento.

Estrutura do Banco

O banco de dados segue o seguinte modelo:

()

As principais entidades e suas relações são:

Resumo das Mudanças no Modelo de Banco de Dados (Início para Fim)

Expansão e Detalhamento de Usuários:

User (singular, com poucos campos) foi substituído por users (plural, com document, telephone, e campos de auditoria isDeleted, createdAt, updatedAt). Adição de user_roles e roles para um sistema de papéis mais flexível e robusto. Adição de password_resets para gerenciamento de redefinição de senha. Alteração na Relação forms e users:

Mudou de uma relação N:M (muitos-para-muitos, usando a tabela auxiliar Users no início) para uma relação 1:N (um-para-muitos, com user_id direto em forms no final). Isso significa que cada formulário agora pertence a um único usuário. Adição de Detalhes Geográficos:

Inclusão da tabela communities, adicionando uma camada extra de granularidade geográfica. Expansão da Tabela forms:

Inúmeras colunas foram adicionadas para coletar mais informações detalhadas: personDocument, personPhone, isMedicationUser, weight, bloodType, familyHeadEducationLevel, familySize. A coluna communityName foi substituída pela chave estrangeira Community_id, apontando para a nova tabela communities. Padronização e Detalhamento de ENUMs:

As tabelas de enumeração foram renomeadas de formatos como gender e CoreNote para gender_enum, satisfaction_enum, etc., com o sufixo _enum e um campo value. Refinamento de Tipos de Dados e Nomenclatura:

Os tipos de dados se tornaram mais específicos (ex: varchar, timestamp, boolean) em vez de genéricos (string, DateTime). A nomenclatura das tabelas foi padronizada para plural e minúsculas (ex: City para cities, State para states). Inclusão de Auditoria:

Campos como createdAt, updatedAt e isDeleted foram adicionados a várias tabelas (ex: users, forms), indicando maior controle e rastreamento de dados. Em essência, o modelo final é uma versão mais completa, granular e detalhada do modelo inicial, refletindo um projeto que amadureceu e precisou incorporar mais requisitos e complexidade em sua estrutura de dados.