GBDBI · Projeto Final — SoundByte Series B

GBDBI · Projeto Final Integrador · Aula 8 · 09.11.2026

SoundByte
Series B

Modelo de Dados · Arquitetura · Governança · Narrativa Estratégica · Em grupo · Canvas 09.11.2026

O fundo quer
ver os dados.

O Cenário

O Fundo Vega Capital enviou um term sheet para a SoundByte: R$ 50 milhões por 18% da empresa, valuation de R$ 278 milhões. Antes de assinar, o fundo exige uma due diligence de dados. O parceiro responsável não quer apenas ver números — quer entender se a empresa sabe o que está fazendo com seus dados. Seu grupo é a equipe de dados da SoundByte. Vocês precisam demonstrar maturidade analítica.

O que o Vega Capital quer avaliar

#	Pergunta do Investidor	Componente
1	"O banco de dados está bem estruturado? As entidades refletem o negócio real? Há inconsistências que escondem problemas?"	🗂️ Modelo de Dados
2	"As escolhas de tecnologia fazem sentido? A arquitetura é coerente com o modelo de dados e suporta crescimento?"	🏗️ Arquitetura
3	"A empresa está em conformidade com a LGPD? A política de acesso cobre os dados que o modelo identifica como sensíveis?"	🛡️ Governança
4	"A equipe consegue articular suas decisões de dados? Modelo, arquitetura e governança contam a mesma história?"	🎤 Narrativa

O Foco deste Projeto

Não é sobre gerar métricas ou visualizações. É sobre avaliar se há consistência conceitual e lógica na forma como a SoundByte trabalha com seus dados. O modelo reflete o negócio real? A arquitetura suporta o modelo? A governança cobre o que o modelo expõe? Se os três respondem "sim" de forma coerente, a empresa tem maturidade de dados.

Os Dados Fornecidos

🗄️

soundbyte_projeto_final.sql

PostgreSQL

Script que cria e popula o banco com dados sintéticos da SoundByte: 200 usuários, 50 artistas, 300 músicas, 5.000 reproduções e 250 assinaturas dos últimos 18 meses. O foco é o schema — as tabelas, colunas, tipos, chaves e relacionamentos — não os valores numéricos.

O blueprint
do sistema.

🗂️

Componente 1

Modelo de Dados

30%

O que Este Componente Avalia

Não basta apresentar os diagramas — é preciso avaliar criticamente o modelo. O investidor quer saber se a equipe entende as decisões por trás da estrutura e consegue identificar onde o modelo está sólido e onde existem fragilidades. Um diagrama sem análise crítica não serve para due diligence.

O que entregar

ERD OLTP — Diagrama Entidade-Relacionamento do banco transacional da SoundByte (dbdiagram.io, draw.io ou equivalente). Deve mostrar todas as 8 tabelas com atributos, PKs, FKs e cardinalidades.

Star Schema — Diagrama do modelo dimensional para análise. 1 tabela fato + pelo menos 3 dimensões. Indique granularidade e métricas da tabela fato.

Análise de Consistência — Texto de 1–2 páginas avaliando: As entidades refletem o negócio real? Há normalização adequada? A granularidade da fato responde as perguntas estratégicas? Quais são as fragilidades do modelo atual? O Star Schema é coerente com o ERD?

Perguntas que a análise deve responder

🔍

As entidades fazem sentido? As tabelas representam corretamente as entidades do negócio de streaming? Há entidades ausentes que deveriam existir (ex.: playlists, dispositivos, eventos de sessão)?

⚠️

Há redundância ou inconsistência lógica? O modelo está normalizado de forma adequada? Existem dados duplicados ou desnormalização não justificada? Algum campo pode gerar leituras ambíguas?

📐

A granularidade da fato é correta? A tabela fato captura o evento certo (reprodução individual, sessão, dia)? Essa granularidade permite responder as perguntas estratégicas de um investidor?

🔗

O OLTP e o Star Schema são coerentes entre si? As dimensões do Star Schema derivam naturalmente das tabelas do ERD? As métricas da fato existem no OLTP ou precisariam ser calculadas? Há decisões do Star Schema que contradizem o OLTP?

Star Schema — Estrutura de Referência

TABELA FATO

fato_reproducao: reproducao_key, usuario_key, musica_key, data_key, dispositivo, duracao_seg, completou_musica (booleano), plano_usuario, receita_atribuida

DIMENSÕES MÍNIMAS

dim_usuario
usuario_key, nome, plano, cidade, estado, faixa_etaria

dim_musica
musica_key, titulo, artista, genero, album, pais_artista

dim_data
data_key, data, dia, mes, trimestre, ano, dia_semana, hora

dim_dispositivo (se aplicável)
dispositivo_key, tipo, sistema_operacional

Rubrica — Modelo de Dados

Critério

Pts

O que é esperado

ERD OLTP completo

7

Todas as 8 tabelas com atributos, PKs marcados, FKs com seta, cardinalidades indicadas (1:N, N:M quando aplicável)

Star Schema correto

8

Tabela fato com métricas identificadas, granularidade declarada, ≥ 3 dimensões derivadas do OLTP, chaves surrogate indicadas

Análise de consistência

15

Identifica pelo menos 2 pontos fortes e 2 fragilidades no modelo. Justifica as decisões de granularidade. Avalia a coerência entre OLTP e Star Schema. Conecta as escolhas de modelagem ao negócio da SoundByte.

Prompt IA — Análise de Consistência do Modelo

Você é um arquiteto de dados sênior revisando um modelo de dados para due diligence de investimento. Contexto: SoundByte é um serviço de streaming musical brasileiro com 200 mil usuários, 3 planos (gratuito/estudante/premium), dados de reprodução e assinaturas. O ERD OLTP proposto é: [COLE AQUI A DESCRIÇÃO OU IMAGEM DO SEU ERD] O Star Schema proposto é: [COLE AQUI A DESCRIÇÃO DO STAR SCHEMA] Por favor, avalie: 1. As entidades do ERD representam adequadamente o negócio de streaming? Falta alguma entidade importante? 2. Há problemas de normalização, redundância ou inconsistência lógica no modelo? 3. A granularidade da tabela fato é adequada para perguntas estratégicas de um investidor? 4. O Star Schema é coerente com o ERD, ou há dimensões que contradizem o modelo transacional? 5. Dê uma avaliação geral (1–5) sobre a maturidade do modelo de dados

Por que SQL aqui
e NoSQL ali?

🏗️

Componente 2

Arquitetura de Dados

25%

A Conexão com o Modelo

Cada decisão de arquitetura deve ser ancorada no modelo de dados do Componente 1. Não argumente "NoSQL é escalável" em abstrato — argumente "usamos MongoDB para perfis de usuário porque o ERD mostra que os dados de escuta são semi-estruturados e variam por usuário, o que torna um schema fixo inadequado". Arquitetura sem ancoragem no modelo é genérica e não convence um investidor.

A Arquitetura Proposta para a SoundByte

CAMADA OLTP

PostgreSQL
Usuários, assinaturas, pagamentos, transações — dados com integridade referencial forte

CAMADA NoSQL

MongoDB Atlas
Perfis de usuário, histórico de escuta, recomendações — dados semi-estruturados e variáveis

CAMADA ANALÍTICA

Star Schema
Relatórios, KPIs, due diligence — modelo dimensional derivado das camadas anteriores

O que justificar

Por que PostgreSQL para a camada OLTP? Conecte com as entidades do ERD: quais tabelas exigem integridade referencial forte (ACID)? Onde as transações precisam ser atômicas (ex.: assinatura + pagamento)?

Por que MongoDB para perfis e histórico? Mostre como o ERD evidencia dados semi-estruturados: o perfil de escuta varia por usuário, playlists têm estrutura variável, recomendações são documentos JSON. Conecte com a Aula 6.

Como a camada analítica se conecta ao Star Schema? O Star Schema do Componente 1 deve alimentar essa camada. Explique o fluxo: como os dados migram do PostgreSQL e MongoDB para o modelo dimensional?

Escalabilidade: o que quebra primeiro a 10× o volume atual? Identifique o gargalo mais provável (PostgreSQL de reproduções? MongoDB de histórico?) e proponha uma solução (sharding, particionamento, cache, separação de leitura/escrita).

Diagrama da arquitetura: crie no Lucidchart (lucid.app — gratuito) mostrando os 3 sistemas, o fluxo de dados entre eles e quem consome cada camada. Inclua no PDF um print do diagrama e o link de compartilhamento do Lucid.

Rubrica — Arquitetura

Critério

Pts

O que é esperado

Diagrama da arquitetura (Lucid)

5

Diagrama com 3 camadas identificadas, fluxo de dados indicado e consumidores mapeados. Print + link incluídos no PDF.

Justificativa SQL vs. NoSQL

12

Argumentos específicos para SoundByte, ancorados no modelo de dados do Componente 1. Menciona entidades ou atributos do ERD para justificar cada escolha. Justificativas genéricas não pontuam.

Análise de escalabilidade

8

Identifica o componente de maior risco de gargalo a 10× o volume atual, conecta ao modelo de dados e propõe solução concreta (índices, sharding, cache, etc.)

Prompt IA — Revisão de Arquitetura

Você é um arquiteto de dados sênior avaliando uma proposta de arquitetura para due diligence de investimento. Contexto: SoundByte é um serviço de streaming musical. O ERD proposto pelo grupo é: [COLE A DESCRIÇÃO DO ERD] A arquitetura proposta é: - PostgreSQL para: [descreva quais dados] - MongoDB para: [descreva quais dados] - Star Schema para: [descreva quais dados] As justificativas do grupo são: [COLE AS JUSTIFICATIVAS] Por favor: 1. As justificativas estão ancoradas no modelo de dados, ou são genéricas? 2. Há dados no ERD que foram alocados na tecnologia errada? 3. Qual é o ponto mais frágil da arquitetura a 10× o volume atual? 4. A camada analítica (Star Schema) é acessível a partir das camadas propostas?

Quem acessa o quê.
Com qual base legal.

🛡️

Componente 3

Governança e LGPD

25%

A Conexão com o ERD

A política de governança deve ser construída a partir dos dados reais identificados no ERD do Componente 1. Cada campo sensível que aparece no modelo — e-mail, localização, histórico de escuta, dados de pagamento — deve aparecer nominalmente no mapa de riscos LGPD e na matriz RBAC. Governança desconectada do modelo é burocracia sem valor.

Entregável 1 — Mapa de Riscos LGPD

Dado no ERD	Classificação	Base Legal	Retenção	Risco · Mitigação
→ Preencha para cada campo sensível identificado no seu ERD (e-mail, localização, pagamentos, histórico de streaming, etc.)
E-mail e nome tabela: usuarios	Dado Pessoal	Execução de contrato (Art. 7º, V)	Enquanto conta ativa + 5 anos	Baixo — padrão de mercado
Localização / cidade tabela: usuarios	Dado Pessoal	Consentimento (Art. 7º, I)	Enquanto conta ativa	Médio — GPS preciso é sensível em contexto
Histórico de streaming tabela: reproducoes	Dado Comportamental	Legítimo interesse (Art. 7º, IX)	36 meses após último acesso	Alto — pode revelar preferências religiosas, políticas
Dados de pagamento tabela: assinaturas	Dado Financeiro	Execução de contrato (Art. 7º, V)	10 anos (obrigação fiscal)	Alto — acesso restrito ao financeiro
→ Continue para todos os campos sensíveis do seu ERD...

Entregável 2 — Matriz RBAC

Situação Especial — Due Diligence

Durante a due diligence, o Vega Capital terá acesso limitado e temporário a certos dados. Sua matriz RBAC deve incluir o perfil "Auditor Externo (Due Diligence)" — com acesso de leitura apenas aos dados necessários para validar a estrutura do modelo e métricas agregadas, sem acesso a dados pessoais individuais de usuários. Justifique cada restrição.

Dado (tabela no ERD)	Estagiário Mktg	Analista BI	Eng. Dados	DPO	Auditor Externo
Dados pessoais (email, nome)	preencher	preencher	preencher	preencher	—
Dados financeiros (assinaturas)	—	preencher	preencher	preencher	L (anonimizado)
Histórico de streaming	preencher	preencher	preencher	preencher	L (agregado)
Schema do banco (ERD)	—	preencher	preencher	preencher	L (estrutura)

L = Leitura · E = Edição · X = Exclusão · — = Sem acesso · Continue para todos os dados do seu ERD

Rubrica — Governança

Critério

Pts

O que é esperado

Mapa de riscos LGPD

10

Cobre todos os campos sensíveis do ERD (com nome da tabela). Base legal com artigo citado. Período de retenção por tipo. Pelo menos 3 riscos com mitigação específica para a SoundByte.

Matriz RBAC completa

8

Todos os dados × todos os perfis (incluindo Auditor Externo). Perfil de due diligence com acesso mínimo necessário e justificativa do que foi restringido e por quê.

Plano de resposta a incidentes

7

Processo de 4–5 etapas: detecção → escalonamento → notificação ANPD (prazo 72h) → comunicação ao Vega Capital durante a due diligence. Inclui quem notifica quem.

Prompt IA — Revisão da Política de Governança

Você é um DPO (Data Protection Officer) sênior revisando a política de governança de uma empresa de streaming para due diligence de investimento. O ERD da SoundByte contém os seguintes dados sensíveis identificados pelo grupo: [LISTE OS CAMPOS SENSÍVEIS COM SUAS TABELAS] O mapa de riscos LGPD proposto é: [COLE O MAPA DE RISCOS] A matriz RBAC proposta é: [COLE A MATRIZ RBAC] Por favor, avalie: 1. Algum campo sensível do ERD foi esquecido no mapa de riscos? 2. As bases legais estão corretas para cada tipo de dado? 3. O perfil "Auditor Externo (Due Diligence)" tem acesso mínimo necessário ou está muito permissivo/restritivo? 4. O plano de resposta a incidentes cobre o cenário de uma violação durante a due diligence?

A análise é evidência.
A decisão é sua.

🎤

Componente 4

Narrativa e Apresentação

20%

O que Será Avaliado

A apresentação dura 10 minutos por grupo. Use o próprio documento PDF de entrega como suporte — não é necessário preparar slides separados. Os outros grupos atuam como o time do Vega Capital e podem fazer perguntas. O professor avalia a clareza da argumentação, a coerência entre os três componentes e a capacidade de conectar modelo, arquitetura e governança a uma avaliação estratégica.

Roteiro da Apresentação (10 min · usando o PDF de entrega)

Seção do PDF	O que apresentar	Tempo
Abertura	O que é a SoundByte — contexto em 1 frase e o desafio central da due diligence	30s
Modelo de Dados	Mostrar o ERD e o Star Schema — "veja onde o modelo é sólido e onde identificamos fragilidades"	2.5 min
Arquitetura	Explicar por que cada tecnologia foi escolhida — conectando às entidades do ERD apresentado	2.5 min
Governança	Mostrar o mapa LGPD e a matriz RBAC — "os dados sensíveis que identificamos no modelo estão cobertos assim"	2 min
Avaliação Final	A SoundByte tem maturidade de dados para receber R$ 50 milhões? Quais são os pontos fortes e os riscos reais?	1.5 min
Perguntas	Responder as objeções do time do Vega Capital	1 min

A Regra da Coerência

Os três componentes devem se reforçar mutuamente na apresentação. Exemplo de coerência: "O ERD mostra que o histórico de streaming contém dados comportamentais sensíveis [Modelo]. Por isso, alocamos esse dado no MongoDB com acesso controlado [Arquitetura]. E na matriz RBAC, apenas o Eng. de Dados e o DPO têm acesso de leitura a esses documentos [Governança]." Essa cadeia é o que o investidor quer ver.

A Pergunta Final que Você Precisa Responder

Com base na análise dos três componentes, sua equipe deve emitir um parecer: "A SoundByte demonstra maturidade de dados suficiente para uma rodada Series B de R$ 50 milhões?" Sustente sua resposta com evidências concretas do modelo, da arquitetura e da governança — e seja honesto sobre os riscos encontrados. Investidores valorizam times que conhecem suas próprias fragilidades.

Rubrica — Narrativa

Critério

Pts

O que é esperado

Clareza e estrutura

6

Apresentação com início (contexto), meio (análise dos 3 componentes) e fim (parecer estratégico). Tempo respeitado. Navegação fluida pelo documento PDF.

Coerência entre componentes

8

Pelo menos 3 momentos em que uma decisão de um componente é conectada explicitamente a outro. O ERD justifica a arquitetura. A arquitetura justifica escolhas de governança. Os três convergem para o parecer final.

Parecer estratégico fundamentado

6

A avaliação final ("maturidade suficiente ou não") é sustentada por evidências específicas do modelo, da arquitetura e da governança — não por opinião geral.

O que entregar
e como pontua.

Pontuação Total

Componente	Peso	Pontos Máx.
🗂️ Modelo de Dados (ERD + Star Schema + Análise de Consistência)	30%	30
🏗️ Arquitetura (diagrama + justificativa + escalabilidade)	25%	25
🛡️ Governança (LGPD + RBAC + plano de incidentes)	25%	25
🎤 Narrativa (apresentação + coerência + parecer)	20%	20
Total		100

Formato de Entrega

Documento Principal (PDF)

Um único PDF organizado em 4 seções numeradas (uma por componente). Cada seção deve conter: (1) o entregável (diagrama, tabela ou texto) e (2) a análise/justificativa crítica. Imagens devem ser de alta resolução e legíveis.

Limite: 15 páginas (sem contar capa e índice). Objetividade é avaliada — não há bônus por extensão.

Diagrama de Arquitetura — Lucidchart

Inclua no PDF: 1 print do diagrama de arquitetura criado no Lucidchart (lucid.app — conta gratuita) + o link de compartilhamento. O diagrama deve mostrar os 3 sistemas (PostgreSQL, MongoDB, Star Schema), os fluxos de dados entre eles e os consumidores de cada camada.

Prompt IA — Revisão Final do Projeto

Prompt — IA como Analista do Vega Capital

Você é um analista sênior do Fundo Vega Capital, responsável pela due diligence de dados da SoundByte antes de uma rodada Series B de R$ 50 milhões. Vou submeter o pacote de due diligence preparado pela equipe de dados. Avalie cada componente: 1. MODELO DE DADOS: [cole o ERD e Star Schema + análise de consistência do grupo] 2. ARQUITETURA: [cole a justificativa SQL vs. NoSQL + diagrama] 3. GOVERNANÇA: [cole o mapa de riscos LGPD + matriz RBAC + plano de incidentes] Por favor: 1. Os três componentes são coerentes entre si? Há contradições entre o modelo, a arquitetura e a governança? 2. Qual pergunta da due diligence este pacote não respondeu satisfatoriamente? 3. Há algum red flag de governança, modelagem ou arquitetura que recomendaria investigar antes de aprovar o investimento? 4. Se fosse apresentar este pacote ao comitê do fundo, qual seria o principal ponto forte e o principal risco? Seja direto e técnico — como em um parecer real de due diligence.

Política de Uso de IA

IA pode e deve ser usada para revisar componentes, verificar consistência e gerar hipóteses. O que será avaliado é a capacidade de analisar, justificar e apresentar o que foi produzido. Indique no documento quais partes receberam assistência de IA e o que o grupo modificou, rejeitou ou aprofundou.