GitLab

Visão Geral

O projeto utiliza Cloud Firestore, um banco de dados NoSQL do Firebase, para gerenciar eventos interativos. O banco de dados foi projetado para acesso em tempo real, alta escalabilidade e performance de leitura, utilizando referências e denormalização planejada. O sistema é estruturado em torno das coleções centrais users (os participantes) e events (os contêineres principais da experiência).

Para gerenciar as interações, a plataforma utiliza outras coleções:

• activities: Agenda detalhada do evento, como palestras e workshops.
• tasks: Desafios gamificados para engajar o público.
• user_event: Gerencia as inscrições dos participantes e consolida a pontuação final.
• user_task: Registra em detalhes as submissões de tarefas, incluindo as respostas dos usuários e os resultados das validações.

A arquitetura da plataforma é construída sobre o ecossistema Google Firebase, utilizando serviços como Cloud Firestore, Firebase Authentication, Cloud Functions, Cloud Storage e Firestore Security Rules.

Coleções e Campos

users

Armazena os dados de perfil de cada indivíduo cadastrado na plataforma. É a coleção fundamental que gerencia a identidade e as permissões dos usuários, como se são administradores ou usuários comuns.

events

Define os eventos principais. Cada documento é um evento único (ex: congresso, feira, simpósio) que serve como um contêiner para todas as atividades e tarefas relacionadas a ele. Controla informações macro como datas, título e o status geral do evento.

events.customization

Este objeto funciona como um painel de controle para a identidade visual de um evento, permitindo a personalização de cores, fontes e imagens para criar uma experiência única para os participantes.

events.tasks

Contém o catálogo de todas as tarefas interativas que os usuários podem realizar. Cada sub documento define uma tarefa, seja ela um quiz, uma question ou um challenge.

events.tasks.questions

Objeto aninhado que define a estrutura de uma pergunta.

events.tasks.questions.options

Objeto aninhado que representa uma opção de resposta.

events.activities

Representa a agenda ou a programação de um evento. Cada documento é uma atividade específica e agendada.

user_task

É o registro de auditoria de todas as interações. Cada documento representa uma única tentativa que um usuário fez em uma tarefa. Armazena as respostas exatas, o resultado da correção e a pontuação obtida.

user_task.answers

Detalha as respostas de uma submissão de tarefa.

user_event

Funciona como a lista de inscrição oficial, conectando usuários a eventos. Cada documento é a prova de que um usuário está participando de um evento específico. Além disso, serve como um placar consolidado, armazenando o total_score do usuário.

Relacionamentos

Relações Principais

• events (Eventos): Um evento contém subcoleções aninhadas de activities e tasks. Um evento tem muitos users participantes, através da coleção de junção user_event.
• users (Usuários): Um usuário pode participar de muitos events através da coleção user_event. Um usuário pode submeter muitas tasks através da coleção user_task.

Relações nas Coleções "Filhas"

• activities (Atividades): É uma subcoleção aninhada dentro de cada documento de evento. Cada activity pertence ao evento pai por meio de sua hierarquia de caminho (/events/{event_id}/activities/{activity_id}).
• tasks (Tarefas): É uma subcoleção aninhada dentro de cada documento de evento. Cada task pertence ao evento pai por meio de sua hierarquia de caminho (/events/{event_id}/tasks/{task_id}).

Relações nas Coleções de Junção

• user_event: Conecta um user a um event. Serve como a "inscrição" e o placar geral, contendo o user_id e o event_id.
• user_task: Conecta um user a uma task. Representa a "submissão", registrando a ação de um usuário em uma tarefa específica. Contém o user_id e o task_id, além de uma cópia do event_id para otimização de consultas.

Convenções de Nomenclatura

Para manter a consistência e a clareza do banco de dados, todas as coleções e campos devem seguir as seguintes convenções de nomenclatura:

• Coleções: Nomes de coleções devem ser escritos em snake_case (letras minúsculas separadas por underscore) e sempre no plural. Exemplos: users, events, user_tasks.
• Campos: Nomes de campos devem ser escritos em snake_case. Exemplos: total_score, start_date, access_code.
• Campos de Identificação (IDs): Campos que armazenam referências (chaves estrangeiras) devem seguir o padrão nome_da_colecao_no_singular_id. Exemplos: user_id, event_id, task_id.
• Campos Booleanos: Preferencialmente, devem começar com um prefixo como is_, has_ ou can_ para que a leitura se assemelhe a uma pergunta. Exemplos: is_active, is_admin, is_correct.
• Campos de Data e Hora: Devem terminar com o sufixo _at. Exemplos: created_at, updated_at, start_at.
• IDs de Documento Compostos: Para coleções de junção, o ID do documento deve ser composto pelos IDs das entidades relacionadas, separados por um underscore (_). Exemplos: user_event (ID: ${user_id}_${event_id}), user_task (ID: ${user_id}_${task_id}).