Pesquisar conteúdos

Encontre uma trilha ou aula pelo assunto.

Experimente pesquisar por “governança”, “ITIL” ou “planejamento”.

Conteúdo da trilha

Modelos de dados: relacional, documentos, chave-valor, colunar e grafos

Compare os principais modelos de dados pelas estruturas, relacionamentos e padrões de acesso que cada um favorece.
Fundamentos e modelagem3 de 2020 min de leitura
Os mesmos fatos são organizados como relação, documentos, pares chave-valor, colunas largas e grafo

Um modelo de dados define como representar e trabalhar com a informação

Na aula anterior, vimos que a arquitetura de um banco separa visões, estrutura lógica e armazenamento físico. Agora avançamos para uma decisão do nível lógico: qual forma usar para representar os elementos do domínio e suas relações?

Um modelo de dados fornece conceitos para descrever dados, relacionamentos, restrições e operações. Tabelas, documentos, pares chave-valor, famílias de colunas e grafos não são apenas formatos visuais diferentes. Cada modelo torna certos caminhos de leitura e atualização mais naturais e exige decisões próprias de projeto.

Nesta aula, usaremos sempre o mesmo domínio: uma plataforma com estudantes, trilhas, módulos, conteúdos, matrículas e progresso. Isso evita comparar exemplos incomparáveis e mostra que o mesmo problema pode ser organizado de maneiras diferentes.

A mesma plataforma de estudos aparece organizada como tabelas, documento, par chave-valor, famílias de colunas e grafo
Os cinco desenhos partem do mesmo domínio. O que muda é a unidade principal de organização e o caminho favorecido para encontrar ou relacionar os dados.

O modelo relacional organiza fatos em relações

No modelo relacional, os dados são percebidos como relações, normalmente apresentadas como tabelas. Cada linha representa uma ocorrência; cada coluna descreve um atributo; chaves e restrições identificam registros e preservam regras. Operações relacionais combinam, filtram e transformam conjuntos de linhas.

Na plataforma, uma representação introdutória poderia separar:

  • estudantes, com identificador e nome;
  • trilhas, com identificador e título;
  • matriculas, ligando estudante e trilha;
  • conteudos, ligando cada aula à trilha correspondente;
  • conclusoes, ligando estudante, conteúdo e momento da conclusão.

Essa separação evita repetir todo o cadastro da trilha em cada matrícula. Quando uma consulta precisa mostrar “as trilhas de Ana e seu progresso”, o SGBD combina as relações pelas chaves apropriadas.

O modelo relacional costuma ser uma base forte quando o domínio possui regras explícitas, transações que abrangem dados relacionados e consultas variadas. Isso não significa que toda informação deva ser dividida no maior número possível de tabelas. Projeto relacional também envolve escolher limites, restrições e formas adequadas de consulta — assuntos desenvolvidos no próximo módulo.

O modelo de documentos reúne dados em agregados

No modelo de documentos, a unidade principal é um documento com campos, valores, objetos aninhados e listas. Documentos de uma coleção podem admitir variações estruturais, conforme as regras do produto e da aplicação.

Uma página do catálogo poderia ler um único documento de trilha contendo título, descrição e uma lista de módulos com resumos de seus conteúdos. Os dados consumidos juntos ficam próximos:

{
  "trilha": "Banco de Dados e SQL",
  "modulos": [
    {
      "titulo": "Fundamentos e modelagem",
      "conteudos": ["Dados e SGBDs", "Modelos de dados"]
    }
  ]
}

Incorporar dados pode tornar natural recuperar e atualizar um agregado em uma operação. Referenciar outros documentos evita incorporar coleções que crescem sem limite ou dados compartilhados por muitos agregados. Bancos de documentos, portanto, não eliminam a modelagem: exigem decidir o que deve ficar junto, o que pode ser duplicado e quando uma referência é mais segura.

Um catálogo com atributos diferentes por tipo de conteúdo pode aproveitar a flexibilidade documental. Em contrapartida, matrículas de muitos estudantes em muitas trilhas não devem ser incorporadas ingenuamente dentro de um único documento que cresceria continuamente.

O modelo chave-valor privilegia o acesso por uma chave conhecida

No modelo chave-valor, cada objeto é associado a uma chave única. A aplicação fornece essa chave para recuperar ou modificar o valor correspondente. O valor pode ser uma sequência de bytes ou uma estrutura tipada, dependendo do sistema.

Para abrir rapidamente o progresso de um estudante em uma trilha, a aplicação poderia construir a chave:

progresso:estudante:104:trilha:banco-dados

e associá-la a um valor compacto com percentual, último conteúdo e data de atualização. Esse desenho é direto quando a pergunta já chega com a chave exata.

A simplicidade cobra uma contrapartida: descobrir “todos os estudantes que concluíram determinada aula” não decorre automaticamente da mesma chave. Pode ser necessário manter outra estrutura, criar um índice suportado pelo produto ou consultar a fonte principal. A forma das chaves também vira parte do contrato da aplicação e precisa de convenções, ciclo de vida e política de expiração quando aplicável.

Produtos associados a chave-valor podem oferecer listas, conjuntos, hashes, documentos e outras estruturas. A categoria descreve o acesso fundamental por chave; não autoriza reduzir todos os produtos a valores opacos nem supor que possuem exatamente os mesmos recursos.

Famílias de colunas organizam dados por partição e consulta conhecida

O modelo chamado de colunar, colunas largas ou famílias de colunas organiza linhas dentro de partições identificadas por uma chave. Colunas de agrupamento podem determinar como as linhas ficam ordenadas dentro de cada partição. O projeto costuma começar pelas consultas que precisam ser atendidas.

Para consultar o histórico recente de progresso de um estudante, uma tabela poderia usar o estudante e o mês como partição e o instante do evento como ordenação:

partição: (estudante 104, 2026-08)
ordem:    instante decrescente
dados:    conteúdo, ação, percentual

Assim, a pergunta “quais foram as atividades recentes deste estudante neste mês?” segue um caminho previsto. Uma pergunta com outra entrada — por exemplo, “quais estudantes acessaram a aula X?” — pode exigir outra tabela desenhada para essa consulta e duplicar dados de forma deliberada.

Esse modelo é associado a cargas distribuídas, grande volume e acesso previsível por partição. Ele não deve ser escolhido apenas porque “escala”: uma chave de partição ruim pode concentrar carga, criar partições excessivas ou tornar consultas necessárias incompatíveis com o desenho.

“Colunar” também descreve outra ideia

Há uma ambiguidade importante. Família de colunas é um modelo operacional de organização por partições, linhas e colunas. Armazenamento orientado a colunas descreve como valores de uma mesma coluna são mantidos próximos para leitura analítica, compressão e processamento em massa.

Um arquivo Apache Parquet, por exemplo, é um formato orientado a colunas. Isso não o transforma em um banco de famílias de colunas. Da mesma forma, um SGBD relacional pode usar armazenamento colunar para análise e continuar expondo tabelas relacionais.

Comparação entre famílias de colunas, organizadas por chave de partição, e armazenamento analítico, que agrupa os valores de cada coluna
Os termos se parecem, mas respondem a perguntas diferentes: famílias de colunas tratam do modelo e do acesso por partição; orientação a colunas trata da disposição física favorável à leitura analítica.

O modelo de grafos torna conexões elementos de primeira classe

Em um grafo de propriedades, nós representam entidades; relacionamentos conectam nós e possuem tipo e direção; nós e relacionamentos podem ter propriedades.

Na plataforma, poderíamos representar:

  • um nó Estudante ligado por MATRICULOU_SE a uma Trilha;
  • a trilha ligada por CONTÉM aos conteúdos;
  • um conteúdo ligado por RELACIONA_SE a outro;
  • a matrícula com propriedades como data e situação, conforme o projeto adotado.

Esse formato favorece perguntas cujo valor está no caminho: “quais conteúdos se relacionam a assuntos já concluídos por Ana?” ou “qual sequência conecta este conceito a outro em até três passos?”. A travessia segue relacionamentos explícitos em vez de reconstruir cada conexão somente durante a consulta.

Grafos não são automaticamente melhores sempre que há relacionamentos. Uma consulta simples por identificador ou um relatório tabular pode continuar mais natural em outro modelo. Além disso, rótulos, tipos de relacionamento, propriedades, índices e restrições ainda precisam ser projetados.

A pergunta de acesso vem antes do rótulo do banco

Comparar modelos apenas por adjetivos como “flexível”, “rápido” ou “escalável” produz decisões fracas. O ponto de partida deve ser a carga real: quais operações dominam, quais regras não podem ser violadas e como os dados crescem e se relacionam.

Cinco perguntas de acesso conduzem a estruturas relacionais, documentais, chave-valor, famílias de colunas e grafos
O diagrama não escolhe um produto automaticamente. Ele mostra afinidades: a pergunta dominante ajuda a identificar qual estrutura merece ser avaliada com mais profundidade.
Se a necessidade dominante é...Modelo que merece avaliaçãoDecisão que não pode ser ignorada
combinar entidades, aplicar regras e variar consultasrelacionalchaves, restrições, transações e custo das combinações
recuperar e alterar um agregado como uma unidadedocumentosincorporar ou referenciar, duplicação e crescimento
buscar um objeto por chave conhecidachave-valordesenho da chave, consultas alternativas e expiração
atender consultas previstas dentro de partiçõesfamílias de colunaschave de partição, ordenação, distribuição e duplicação
percorrer conexões e caminhos variáveisgrafostipos de relação, direção, propriedades e ponto inicial

Essa tabela indica afinidades, não uma sentença. Consistência, disponibilidade, latência, volume, custo operacional, experiência da equipe, segurança, backup e recursos concretos do produto também influenciam a decisão. A última aula da trilha reunirá esses critérios em uma comparação de arquitetura mais completa.

Modelo, produto e mecanismo de armazenamento não são a mesma coisa

Um modelo oferece conceitos de representação. Um SGBD implementa um ou mais modelos e acrescenta linguagens, índices, transações, replicação, segurança e operação. Um mecanismo de armazenamento decide como bytes, páginas ou colunas são organizados internamente.

Por isso, o nome comercial de um produto não basta para prever seu comportamento. Um SGBD relacional pode armazenar e consultar documentos JSON; uma plataforma chave-valor pode oferecer estruturas ricas; um produto multimodelo pode expor documentos e grafos. A presença de um recurso, contudo, não garante que ele possua a mesma semântica, desempenho ou maturidade de um sistema especializado.

Também é possível combinar bancos em uma arquitetura, prática às vezes chamada de persistência poliglota. A plataforma poderia manter matrículas em um banco relacional e uma projeção chave-valor para acelerar uma tela. Isso adiciona sincronização, observabilidade, backup, segurança e conhecimento operacional. Dois bancos não são uma melhoria gratuita.

Um roteiro prático para comparar modelos

Antes de selecionar uma tecnologia, registre exemplos concretos:

  1. quais são as três leituras mais frequentes e as três mais críticas?
  2. quais dados são criados ou alterados juntos?
  3. quais relações crescem sem limite e quais permanecem pequenas?
  4. quais regras precisam ser verificadas na mesma transação?
  5. as consultas são previsíveis ou surgem perguntas novas com frequência?
  6. qual é a distribuição esperada de chaves, volume e tráfego?
  7. como serão feitos migração, autorização, auditoria, backup e recuperação?
  8. a equipe consegue operar a solução durante falhas e evolução do esquema?

Modele uma pequena fatia do domínio em mais de uma alternativa e teste as operações representativas. Um desenho que parece elegante no quadro pode gerar documentos ilimitados, partições desequilibradas, relações duplicadas ou consultas impossíveis de sustentar.

Erros comuns

  • escolher pelo nome da categoria: produtos da mesma família possuem recursos e compromissos diferentes;
  • confundir flexibilidade com ausência de regras: qualquer aplicação duradoura precisa administrar contratos e evolução;
  • normalizar ou duplicar por reflexo: cada decisão deve corresponder às leituras, escritas e regras do domínio;
  • usar chave-valor sem mapear consultas alternativas: uma chave excelente para uma tela pode não atender relatórios e auditoria;
  • criar partições sem estimar distribuição: partições muito quentes ou grandes anulam o benefício esperado;
  • usar grafo para qualquer dado conectado: quase todo domínio possui relações, mas nem toda pergunta exige travessia;
  • confundir famílias de colunas com armazenamento analítico colunar: são conceitos de níveis diferentes;
  • adotar vários bancos cedo demais: cada tecnologia acrescenta contratos, falhas e tarefas operacionais.

O que você deve guardar

O modelo relacional organiza relações e regras; documentos reúnem agregados; chave-valor atende acesso por identificador conhecido; famílias de colunas alinham partições a consultas previstas; grafos colocam conexões e caminhos no centro.

Nenhum desses modelos é universalmente superior. O melhor encaixe depende da forma das perguntas, das atualizações, das relações e das garantias exigidas. A comparação começa no domínio e nos padrões de acesso, não no produto mais popular.

Na próxima aula, aprenda a transformar requisitos em um modelo entidade-relacionamento com entidades, atributos, relacionamentos e cardinalidades. Esse passo antecede a implementação e ajuda a separar o significado do domínio da tecnologia escolhida.

Referências