Modelagem de Dados
Visão geral
O banco principal da API é relacional e modelado em Prisma. Esta página mostra como as tabelas se conectam e como o domínio do Etnos foi organizado no Postgres.
Arquivos relacionados
- DDL PostgreSQL para DrawSQL
- fonte de verdade do schema:
apps/api/prisma/schema.prisma - Arquitetura de Banco de Dados
Resumo rápido
| Tabela | Finalidade |
|---|---|
users |
Perfil de negócio vinculado ao Firebase Auth |
schools |
Cadastro de escolas |
characters |
Personagens culturais da plataforma |
game_configs |
Configuração por jogo e personagem |
memory_game_contents |
Conteúdo visual do jogo da memória |
game_scores |
Pontuações por usuário |
midia |
Metadados dos arquivos salvos no Storage |
Visão relacional
erDiagram
SCHOOLS ||--o{ USERS : "id -> school"
CHARACTERS ||--o{ GAME_CONFIGS : "slug -> character_slug"
CHARACTERS ||--o{ MEMORY_GAME_CONTENTS : "id -> character_id"
CHARACTERS ||--o{ GAME_SCORES : "slug -> character_slug"
USERS ||--o{ GAME_SCORES : "firebase_uid -> user_id"
USERS ||--o{ MIDIA : "firebase_uid -> user_id"
USERS {
string id PK
string firebase_uid UK
string email
string parent_name
string child_name
string child_birth_date
string parent_phone
string school "schoolId"
string[] roles
}
SCHOOLS {
string id PK
string name UK
string city
string state
}
CHARACTERS {
string id PK
string slug UK
string name
string region
string description
string image_url
}
GAME_CONFIGS {
string id PK
string game_slug
string character_slug FK
string image_cover_url
}
MEMORY_GAME_CONTENTS {
string id PK
string slug
string character_id
string url
}
GAME_SCORES {
string id PK
string slug
string character_slug
int score
string user_id
}
MIDIA {
string id PK
string user_id
string folder
string path
string url
}
Imagem da modelagem

Mermaid
Tabelas
users
Representa o perfil de negócio do usuário autenticado.
Campos principais:
id: identificador internofirebase_uid: vínculo com o Firebase Authemailparent_namechild_namechild_birth_dateparent_phoneschoolrolescreated_atupdated_at
Regras:
firebase_uidé único- o usuário autentica no Firebase, mas o perfil é salvo aqui
Na prática, o campo persistido hoje se chama school, mas ele representa o
schoolId e aponta para schools.id.
schools
Cadastro de escolas disponíveis para uso na plataforma.
Campos principais:
idnamecitystatecreated_atupdated_at
Regras:
-
nameé único no schema atual -
alimentar seletores de escola no cadastro e no perfil
characters
Entidade principal para personagens culturais usados nos jogos e na biblioteca.
Campos principais:
idnameregiondescriptionslugimage_urlcreated_atupdated_at
Regras:
slugé único
Uso típico:
- servir como catálogo principal da experiência cultural e base dos jogos
game_configs
Configuração por jogo e personagem.
Campos principais:
idgame_slugcharacter_slugimage_cover_urlcreated_atupdated_at
Relações:
character_slugreferenciacharacters.slug
Regras:
- combinação
game_slug + character_slugé única
Uso típico:
- guardar a capa e a configuração visual do
memory-gamepara cada personagem
memory_game_contents
Conteúdo visual usado no jogo da memória.
Campos principais:
idurlslugcharacter_idcreated_atupdated_at
Aqui, character_id referencia characters.id, e o campo slug continua
sendo usado nas consultas por personagem.
Uso típico:
- montar as cartas e imagens do jogo da memória por personagem
game_scores
Pontuações salvas por usuário em cada jogo/personagem.
Campos principais:
idslugcharacter_slugscoreuser_idcreated_atupdated_at
Regras:
- combinação
slug + character_slug + user_idé única
Aqui, character_slug referencia characters.slug e user_id referencia
users.firebase_uid.
Uso típico:
- recuperar o desempenho do estudante por jogo
midia
Metadados dos arquivos enviados para o Firebase Storage.
Campos principais:
idurlfolderpathuser_idcreated_atupdated_at
Uso típico:
- organizar a biblioteca de imagens usada pelo admin e pelos jogos
Regras:
- índice por
user_id - índice por
folder
Observação:
- o arquivo físico fica no Firebase Storage
- esta tabela guarda apenas metadados e vínculo com usuário
user_idreferenciausers.firebase_uid- também sustenta a listagem da biblioteca de mídia e a organização por pasta
Resumo relacional
Relações explícitas no Prisma
game_configs.character_slug -> characters.slug
Relações implícitas por convenção
users.school -> schools.idmemory_game_contents.character_id -> characters.idgame_scores.character_slug -> characters.sluggame_scores.user_id -> users.firebase_uidmidia.user_id -> users.firebase_uidusers.firebase_uid <-> Firebase Auth uid
Observações de modelagem
Relações ainda não formalizadas no banco
Alguns vínculos ainda carregam nomes herdados da estrutura anterior,
principalmente o campo users.school, que semanticamente funciona como
schoolId. Na documentação, essas relações aparecem do ponto de vista do
domínio, mesmo quando o nome físico da coluna ainda é legado.
Índices e unicidade
Chaves únicas
users.firebase_uidschools.namecharacters.sluggame_configs(game_slug, character_slug)game_scores(slug, character_slug, user_id)
Índices auxiliares
memory_game_contents.sluggame_scores.user_idmidia.user_idmidia.folder
Decisões importantes da modelagem
Uso de firebaseUid
O firebaseUid é a chave de integração entre autenticação e domínio. Isso evita
duplicar responsabilidade de auth no banco relacional.
Slugs como chave de domínio
characters.slug e game_slug aparecem bastante porque fazem parte do contrato
atual da API e simplificam consultas e URLs.
Arquivos fora do banco
O banco não armazena binários. Apenas URLs, caminhos e metadados.