---
id: modelo-de-dados-nucleo
title: Modelo de dados — Núcleo
description: Relações centrais entre cadastros, solicitações, estágios, documentos e avaliações.
type: data-model
status: in-progress
visibility: public
tags: sge/modelagem, sge/mermaid
related: modelo-de-dados-acesso, modelo-de-dados-historico, ciclos-de-status
source_refs:
diagram: modelo-nucleo-identidade
---
> [!info] Nível deste diagrama
> Este é um recorte do modelo lógico relacional publicado. Ele mostra tabelas, colunas-chave e relações; o contrato completo de campos, índices e nulabilidade fica em uma única fonte técnica, evitando duplicação no diagrama.

## Identidade, cidades, endereços e cadastros

> **Diagrama: Esquema lógico — identidade e cadastros**
> Tabelas e colunas de identidade, dados pessoais, cidades, endereços, campus e vínculos institucionais.
> Leitura semântica: A conta possui dados pessoais e vínculos; cidades são catalogadas pelo código IBGE, endereços apontam para elas e cadastros mantêm endereços atuais.
> Fonte semântica: `diagrams/modelo-nucleo-identidade.json`
> Dados estruturados: `api/diagrams/modelo-nucleo-identidade.json`
> Fonte declarativa: `diagrams/sources/modelo-nucleo-identidade.mmd`

| Entidade | Responsabilidade |
| --- | --- |
| `users` | identidade autenticada e credenciais |
| `user_personal_data` | Dados pessoais atuais e dados profissionais opcionais do supervisor, compartilhados por usuário; CPF permanece em `users` |
| `cities` | catálogo local de municípios por código IBGE e UF |
| `addresses` | endereços atuais e cópias históricas usadas por estágios |
| `affiliations` | função institucional, campus e e-mail contextual; a Migration 10 adiciona `course_id` obrigatório para vínculos de discente |
| `campuses` e `courses` | escopo acadêmico e administrativo |
| `internship_types` | regras de carga, notas e exceções aplicáveis ao curso |
| `granting_parties` | cadastro atual da concedente, vinculado a um campus; CPF/CNPJ podem se repetir e os dados locais não são compartilhados |

Uma pessoa possui uma conta e quantos vínculos forem necessários. O vínculo ativo, e não a conta isolada, define o contexto usado por Gates e Policies.

## Da solicitação ao estágio

> **Diagrama: Esquema lógico — solicitação e formalização**
> Tabelas e colunas que registram a solicitação e os cadastros usados para formalizar o estágio.
> Leitura semântica: A solicitação é enviada por um vínculo discente, referencia curso, tipo e concedente, e mantém o estado que conduz à formalização.
> Fonte semântica: `diagrams/modelo-nucleo-solicitacao.json`
> Dados estruturados: `api/diagrams/modelo-nucleo-solicitacao.json`
> Fonte declarativa: `diagrams/sources/modelo-nucleo-solicitacao.mmd`

- Existe uma solicitação por processo iniciado pelo discente; devoluções editam o mesmo registro.
- Evidências de emancipação são registros privados, analisados manualmente pelo Setor.
- O estágio nasce apenas após o aceite da solicitação e preserva FKs e snapshots dos dados aprovados.
- Correções posteriores atualizam somente os campos autorizados e não apagam documentos ou estados anteriores.

## Execução, formalização e conclusão

> **Diagrama: Esquema lógico — execução do estágio**
> Tabelas e colunas que controlam endereço de trabalho, feriados, vigência, jornadas, pausas e cancelamento.
> Leitura semântica: O estágio usa os feriados nacionais, estaduais e municipais aplicáveis ao endereço do local de trabalho, possui jornadas, pausas e exceções e pode receber um pedido de cancelamento; a avaliação é detalhada no contrato próprio.
> Fonte semântica: `diagrams/modelo-nucleo-execucao.json`
> Dados estruturados: `api/diagrams/modelo-nucleo-execucao.json`
> Fonte declarativa: `diagrams/sources/modelo-nucleo-execucao.mmd`

| Conjunto | Regra central |
| --- | --- |
| jornadas, pausas, calendário e exceções | determinam a previsão reproduzível de término |
| templates e versões | preservam o modelo usado em cada geração |
| documentos | mantêm origem, versão, estado e snapshot; o arquivo final é temporário |
| avaliação do supervisor | reutiliza o mesmo formulário em `Draft` ou `Returned` |
| notas | supervisor é calculada; relatório e apresentação são lançadas pelo orientador |
| cancelamento | exige pedido e decisão do Setor, preservando o histórico |

## Regras de integridade

- Dados atuais relacionam-se por FK; valores usados em um processo histórico são congelados em snapshots.
- A jornada é pactuada na abertura; outra vigência só pode nascer de aditivo com assinaturas conferidas e não reescreve dias já cumpridos.
- Templates usados não são alterados; uma mudança cria nova versão.
- `Submitted` e `Approved` bloqueiam a avaliação; `Returned` reabre o mesmo registro.
- O Activity Log registra alterações relevantes, mas não substitui tabelas de domínio.

## Leituras relacionadas

- [Conta, vínculos e autorização](doc:modelo-de-dados-acesso).
- [Snapshots, logs e mensagens](doc:modelo-de-dados-historico).
- [Estados e transições](doc:ciclos-de-status).
- [Modelagem de dados](doc:modelagem-de-dados).