Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • bah-wiki bah-wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar
  • Bah – Plataforma de Inovação de Caxias do Sul
  • bah-wikibah-wiki
  • Wiki
  • Banco de Dados

Last edited by Maurício Gaspary Oct 17, 2025
Page history

Banco de Dados

Home Escopo Gerência Processo Design Configuração Arquitetura Banco de Dados

Sumário

  1. Banco de Dados
    1. Descrição
    2. Banco de dados escolhido (PostgreSQL)
    3. Diagrama do banco de dados
    4. Relacionamentos

Banco de Dados

Descrição

Esta seção visa fornecer uma breve introdução sobre o banco de dados escolhido para armazenar as informações manipuladas pela aplicação desenvolvida, assim como sua configuração e integrações no projeto.

Optou-se por utilizar o PostgreSQL como sistema de gerenciamento de banco de dados (SGBD) devido à sua escalabilidade, confiabilidade e suporte avançado a consultas SQL.

No projeto, o PostgreSQL é integrado ao backend desenvolvido em Python, onde as entidades são manipuladas por meio de repositórios, que realizam as operações de leitura, escrita e atualização diretamente no banco. Por meio do SQLAlchemy, essa abordagem segue o padrão ORM (Object Relational Mapping), garantindo maior organização e segurança na manipulação dos dados.


Banco de dados escolhido (PostgreSQL)

A escolha de um banco de dados relacional possibilitou a estruturação das informações em tabelas relacionadas, assegurando integridade referencial e consistência dos dados.

Além de atender aos requisitos tradicionais de um SGBD, o PostgreSQL foi escolhido também por oferecer suporte a vetores, recurso essencial para o projeto, que irá utilizar Inteligência Artificial (IA) para implementar uma pesquisa inteligente baseada em vetores.
Com esse recurso, é possível realizar operações como busca semântica, recomendação de conteúdo e análise de similaridade diretamente no banco de dados, sem depender de ferramentas externas.


Principais motivos para a escolha do PostgreSQL

O PostgreSQL oferece suporte a diversos recursos avançados, como:

  • Transações seguras, prevenindo inconsistências e garantindo confiabilidade nos dados.
  • Chaves primárias e estrangeiras para definir relacionamentos claros entre entidades.
  • Índices que otimizam a performance de consultas complexas.
  • Suporte a JSON, permitindo armazenar e manipular dados semiestruturados.
  • Banco vetorial integrado, através da extensão pgvector, possibilitando:
    • Armazenamento de vetores de embeddings gerados por modelos de IA.
    • Consultas para busca semântica e similaridade entre dados.
    • Implementação de recomendações inteligentes diretamente no banco.

Essa estrutura atende plenamente às necessidades do projeto, permitindo:

  • Organização e consistência dos dados por meio de um modelo relacional bem definido.
  • Eficiência em consultas mesmo em cenários com múltiplos usuários interagindo simultaneamente.
  • Integração nativa com IA, facilitando o desenvolvimento de funcionalidades avançadas, como:
    • Busca inteligente por similaridade.
    • Sugestões automáticas baseadas em contexto.
    • Melhor experiência de navegação e descoberta de conteúdo para os usuários.

Diagrama do banco de dados

Abaixo está a representação visual do banco de dados, mostrando as entidades principais e como elas se relacionam:

diagrama-bd

Relacionamentos do Banco de Dados

Esta seção descreve como as tabelas do banco de dados estão conectadas, detalhando os relacionamentos entre as entidades principais.


1. Tabela usuarios

  • Relacionamentos:
    • Relaciona-se com a tabela iniciativas através dos campos:
      • criado_por → Identifica o usuário que criou a iniciativa.
      • editado_por → Identifica o usuário que editou a iniciativa.
      • deletado_por → Identifica o usuário que deletou a iniciativa.
    • Cardinalidade:
      • Um usuário (0,1) pode criar, editar ou deletar muitas iniciativas.
      • Uma iniciativa deve ter pelo menos um usuário associado como criador.

2. Tabela organizadores

  • Relacionamentos:
    • Está vinculada à tabela iniciativas por meio do campo organizador_id.
    • Cada iniciativa está vinculada a um único organizador.
    • Cardinalidade:
      • Um organizador (1) pode estar relacionado a muitas iniciativas (N).

3. Tabela iniciativas

  • Relacionamentos principais:
    • Com organizadores:
      • Cada iniciativa tem um organizador responsável, definido pelo campo organizador_id.
    • Com usuarios:
      • Relaciona-se aos usuários através dos campos de auditoria:
        • criado_por, editado_por, deletado_por.
    • Com iniciativa_horarios:
      • Uma iniciativa pode ter vários horários cadastrados.
      • Relacionamento 1:N (uma iniciativa para muitos registros de horários).
    • Com tags:
      • Relacionamento muitos para muitos (N:N) através da tabela intermediária iniciativa_tag.

4. Tabela iniciativa_horarios

  • Relacionamentos:
    • Relaciona-se diretamente com a tabela iniciativas através do campo iniciativa_id.
    • Cardinalidade:
      • Uma iniciativa (1) pode ter vários horários cadastrados (N).
      • Cada horário pertence a apenas uma iniciativa.

5. Tabela tags

  • Relacionamentos:
    • Conectada à tabela iniciativas através da tabela intermediária iniciativa_tag.
    • Cardinalidade:
      • Uma tag (1) pode estar associada a várias iniciativas (N).
      • Uma iniciativa (1) pode conter várias tags (N).
    • Este é um relacionamento clássico de muitos para muitos (N:N).

6. Tabela iniciativa_tag (tabela intermediária)

  • Função:
    • Faz a ligação entre iniciativas e tags.
  • Campos principais:
    • iniciativa_id → Referência para a tabela iniciativas.
    • tag_id → Referência para a tabela tags.
  • Cardinalidade:
    • Cada registro associa uma iniciativa a uma tag específica.

7. Tabela contatos

  • Relacionamentos:
    • Não possui relacionamentos diretos com outras tabelas no momento.
    • É usada para armazenar mensagens enviadas pelos usuários, contendo:
      • Nome
      • E-mail
      • Assunto
      • Mensagem
      • Data de envio (enviado_em)

Resumo em formato de tabela

Tabela Relaciona-se com Tipo de relacionamento
usuarios iniciativas 1:N (auditoria: criado, editado, deletado)
organizadores iniciativas 1:N
iniciativas organizadores, usuarios, iniciativa_horarios, iniciativa_tag Vários (1:N e N:N)
iniciativa_horarios iniciativas 1:N
tags iniciativas (via iniciativa_tag) N:N
iniciativa_tag iniciativas, tags Tabela intermediária
contatos - Isolada (sem relacionamento)

Representação geral dos relacionamentos

  • Usuários gerenciam iniciativas (criando, editando, deletando).
  • Organizadores estão vinculados a iniciativas como responsáveis principais.
  • Iniciativas têm múltiplos horários e podem ser categorizadas por várias tags.
  • Tags são gerenciadas através da tabela intermediária iniciativa_tag.
  • Contatos servem como um repositório de mensagens enviadas, sem conexões diretas com outras entidades.
Clone repository
  • Arquitetura
  • Banco de Dados
  • Design
  • Escopo
  • Gerência
  • Processo
  • Home