Tipos de Bases de Dados: Relacionais, NoSQL e Outros Modelos
Lição 1.2 · Tempo de leitura: ~20 min · Tarefas para praticar ↓
Existem muitos tipos de bases de dados, cada um otimizado para um tipo específico de dados, padrão de consulta ou requisito de escalabilidade. Nesta lição, aprenderá os principais modelos - relacionais, chave-valor, documentais, colunas largas, grafo, séries temporais e colunares - com as suas diferenças, casos de uso típicos e exemplos de sistemas reais. Para cada tipo, verá também como ficam nele os mesmos dados de uma loja online.
Na lição anterior, introduzimos a ideia geral de uma base de dados e de um SGBD. Na prática, nem todas as bases de dados são construídas da mesma forma. Diferentes tipos são otimizados para diferentes tipos de dados, padrões de consulta, requisitos de escalabilidade e necessidades de consistência.
Também vamos olhar com mais atenção para as bases de dados relacionais, porque continuarão a ser o nosso principal foco ao longo deste curso.
Porque Existem Diferentes Tipos de Bases de Dados?
Nenhum modelo único é perfeito para todas as aplicações.
Por exemplo:
- Um sistema bancário precisa de forte consistência e transações fiáveis.
- Um sistema de caching precisa de pesquisas por chave extremamente rápidas.
- Uma rede social pode precisar de armazenamento documental flexível e análise de relações em estilo grafo.
- Uma plataforma analítica pode precisar de analisar milhares de milhões de valores de forma eficiente.
Como sistemas diferentes resolvem problemas diferentes, vários modelos de bases de dados surgiram ao longo do tempo.
Principais Tipos de Bases de Dados: Tabela Comparativa
Comparação rápida antes de analisarmos cada tipo em detalhe:
| Tipo | Modelo de Dados | Pontos Fortes | Casos de Uso | Exemplos |
|---|---|---|---|---|
| Relacional | Tabelas com linhas e colunas | Forte consistência, SQL, joins, dados estruturados | Banca, ERP, CRM, e-commerce, relatórios | PostgreSQL, MySQL, MariaDB, SQLite, Oracle |
| Chave-Valor | Chave associada a um valor | Pesquisas muito rápidas, escalabilidade simples | Caching, sessões, feature flags, carrinhos | Redis, Amazon DynamoDB, Riak |
| Documental | Documentos do tipo JSON | Esquema flexível, dados aninhados | Gestão de conteúdo, perfis, catálogos | MongoDB, Couchbase, Firestore |
| Colunas Largas | Linhas com colunas flexíveis em famílias | Alta taxa de escrita, escalabilidade horizontal | Registo de eventos, IoT, cargas distribuídas | Apache Cassandra, HBase, ScyllaDB |
| Grafo | Nós e arestas | Consultas centradas em relações | Redes sociais, deteção de fraude, recomendações | Neo4j, Amazon Neptune, ArangoDB |
| Séries Temporais | Registos com marca temporal | Ingestão e agregação eficientes ao longo do tempo | Monitorização, métricas, sensores | InfluxDB, TimescaleDB, OpenTSDB |
| Colunar Analítica | Dados por coluna em vez de por linha | Análises e agregações rápidas | BI, dashboards, data warehousing, OLAP | ClickHouse, DuckDB, Amazon Redshift, BigQuery |
| Em Memória | Dados principalmente em RAM | Latência extremamente baixa | Caching, leaderboards, contadores em tempo real | Redis, Memcached, SAP HANA |
Bases de Dados Relacionais
As bases de dados relacionais armazenam os dados em tabelas compostas por linhas e colunas. As tabelas podem ser ligadas entre si através de relações, normalmente usando chaves primárias e chaves estrangeiras.
Este modelo é especialmente adequado quando os dados estão bem estruturados e quando a correção, a consistência e as consultas complexas são importantes.
Exemplo de dados:
Todos os exemplos desta lição usam os mesmos dados de uma loja online: Ann (cliente com id 42) e as suas encomendas. Numa base de dados relacional, clientes e encomendas ficam em duas tabelas ligadas pela coluna customer_id:
customers
| id | name | city |
|---|---|---|
| 42 | Ann | Lisbon |
| 43 | Bob | Madrid |
orders
| id | customer_id | order_date | total |
|---|---|---|---|
| 1 | 42 | 2026-03-14 | 99.50 |
| 2 | 42 | 2026-04-02 | 15.00 |
| 3 | 43 | 2026-04-02 | 12.00 |
O valor 42 em orders.customer_id aponta para a linha de Ann em customers: os dados do cliente ficam guardados uma única vez e cada encomenda faz referência a eles.
Propriedades Fundamentais das Bases Relacionais
1. Esquema estruturado - exige um esquema claramente definido com tabelas, colunas, tipos de dados, restrições e relações. Torna a estrutura previsível e fácil de validar.
2. Relações entre tabelas - capacidade de modelar relações explicitamente entre entidades (ex. customers → orders → order_items). Ideal para sistemas de negócio.
3. Suporte a SQL - linguagem padrão para filtrar, juntar, agregar, ordenar e modificar dados estruturados.
4. Transações ACID :
- Atomicidade: uma transação é totalmente bem-sucedida ou falha por completo.
- Consistência: os dados permanecem válidos segundo as regras definidas.
- Isolamento: transações concorrentes não interferem incorretamente.
- Durabilidade: dados confirmados são mantidos mesmo após falhas.
5. Restrições de integridade - chaves primárias, estrangeiras, unicidade, NOT NULL, CHECK para evitar dados inválidos.
6. Joins poderosos - ideais para combinar dados de várias tabelas em relatórios e análises.
7. Normalização - redução de duplicação através de tabelas relacionadas.
Casos de Uso Comuns
As bases relacionais são a melhor escolha quando os dados são estruturados, as relações são importantes, as transações devem ser fiáveis e são necessárias consultas complexas.
Exemplos
- PostgreSQL, MySQL, MariaDB, SQLite, Oracle Database, Microsoft SQL Server
Bases de Dados Chave-Valor
Armazenam dados como um par simples chave + valor. Acesso direto por chave - modelo muito simples e muito rápido.
Exemplo de dados:
Cada valor é encontrado pela sua chave. A base de dados não olha para dentro do valor: para ela, o JSON abaixo é apenas uma string.
| Chave | Valor |
|---|---|
session:8f3a2c | { "customer_id": 42, "expires": "2026-03-14T12:00:00Z" } |
cart:42 | [101, 205] |
views:product:101 | 1532 |
feature:new_checkout | on |
Chaves como session:8f3a2c costumam ter um tempo de vida, por exemplo uma hora, após o qual são apagadas automaticamente. Em contrapartida, a base de dados não consegue responder a «todas as sessões do cliente 42»: só encontra um valor quando a chave já é conhecida.
Casos de uso: cache, sessões, carrinhos, feature flags, leaderboards.
Exemplos: Redis, Amazon DynamoDB, Riak
Bases de Dados Documentais
Armazenam dados como documentos JSON. Cada documento pode ter uma estrutura diferente.
Exemplo de dados:
A encomenda 1 é guardada como um único documento: o cliente e as linhas da encomenda estão aninhados lá dentro, por isso uma só leitura devolve tudo, sem JOIN.
{
"_id": 1,
"order_date": "2026-03-14",
"customer": { "id": 42, "name": "Ann", "city": "Lisbon" },
"items": [
{ "product": "Keyboard", "qty": 1, "price": 79.50 },
{ "product": "Mouse pad", "qty": 2, "price": 10.00 }
],
"total": 99.50
}
Outro documento da mesma coleção pode ter campos diferentes, por exemplo uma encomenda de oferta com gift_message:
{
"_id": 2,
"order_date": "2026-04-02",
"customer": { "id": 42, "name": "Ann" },
"items": [ { "product": "Gift card", "qty": 1, "price": 15.00 } ],
"gift_message": "Happy birthday!",
"total": 15.00
}
A contrapartida: o nome de Ann é copiado para cada encomenda; se mudar, é preciso atualizar todos os documentos.
Casos de uso: gestão de conteúdo, catálogos de produtos, perfis de utilizador, aplicações web e móveis.
Exemplos: MongoDB, Couchbase, Google Firestore
Bases de Dados de Colunas Largas
Armazenam dados em linhas com um conjunto flexível de colunas. Concebidas para distribuição por muitos servidores e alta taxa de escrita.
Exemplo de dados:
As linhas são encontradas por uma chave de linha (row key), e cada linha guarda apenas as colunas que realmente tem. As colunas agrupam-se em famílias (aqui info e orders, escritas como family:column), e é possível acrescentar colunas novas a uma só linha sem alterar nenhum esquema:
customer:42
info:name = Ann
info:city = Lisbon
orders:1 = 99.50
orders:2 = 15.00
customer:43
info:name = Bob
orders:3 = 12.00
A linha de Bob não tem coluna city: não é NULL, simplesmente não existe. A linha de Ann ganha uma coluna nova a cada encomenda. A chave de linha decide em que servidor fica a linha, por isso os dados são procurados por ela; para encontrar encomendas por total, seria precisa outra tabela organizada por esse valor.
Casos de uso: registo de eventos, IoT, sistemas de mensagens, sistemas distribuídos geograficamente.
Exemplos: Apache Cassandra, Apache HBase, ScyllaDB
Bases de Dados Colunares Analíticas
Armazenam os valores da mesma coluna juntos em disco - diferente das bases de colunas largas. Eficientes para consultas analíticas que leem poucas colunas de grandes conjuntos de dados.
Exemplo de dados:
Considere a tabela orders do exemplo relacional. Uma base de dados orientada a linhas grava cada linha junta; uma colunar grava cada coluna junta:
Armazenamento por linhas:
[1, 42, 2026-03-14, 99.50] [2, 42, 2026-04-02, 15.00] [3, 43, 2026-04-02, 12.00]
Armazenamento por colunas:
id: 1, 2, 3
customer_id: 42, 42, 43
order_date: 2026-03-14, 2026-04-02, 2026-04-02
total: 99.50, 15.00, 12.00
Um relatório de receita por data só precisa de order_date e total: uma base colunar lê apenas essas duas colunas e ignora as restantes. Com centenas de colunas e milhares de milhões de linhas, a poupança é enorme. Além disso, os valores repetidos numa coluna (como 2026-04-02) comprimem-se muito bem.
Casos de uso: business intelligence, data warehousing, dashboards, análise de logs.
Exemplos: ClickHouse, DuckDB, Amazon Redshift, Google BigQuery
Bases de Dados em Grafo
Concebidas para dados onde as relações são a parte mais importante. Armazenam nós (entidades) e arestas (relações). Navegação por relações rápida e natural.
Exemplo de dados:
Clientes, encomendas e produtos tornam-se nós; «fez», «contém» e «segue» tornam-se arestas. Cada aresta tem direção e tipo, e tanto os nós como as arestas podem ter propriedades:
(Ann:Customer)-[:PLACED]->(Order 1 { total: 99.50 })-[:CONTAINS]->(Mouse pad:Product)
(Ann:Customer)-[:PLACED]->(Order 1 { total: 99.50 })-[:CONTAINS]->(Keyboard:Product)
(Bob:Customer)-[:PLACED]->(Order 3 { total: 12.00 })-[:CONTAINS]->(Mouse pad:Product)
(Bob:Customer)-[:FOLLOWS]->(Ann:Customer)
Para descobrir quem comprou os mesmos produtos que Ann, a base de dados limita-se a percorrer as arestas: Ann → Order 1 → Mouse pad → Order 3 → Bob. Numa base de dados relacional, a mesma pergunta exige combinar várias tabelas.
Casos de uso: redes sociais, deteção de fraude, sistemas de recomendação, grafos de conhecimento.
Exemplos: Neo4j, Amazon Neptune, ArangoDB
Bases de Dados de Séries Temporais
Especializadas em dados associados ao tempo, otimizadas para ingestão, retenção, compressão e agregação temporal.
Exemplo de dados:
As encomendas não encaixam bem aqui: os dados típicos são um fluxo de medições. Por exemplo, os servidores da loja enviam métricas a cada minuto:
| time | host | cpu_percent | requests_per_sec |
|---|---|---|---|
| 2026-03-14 10:00:00 | web-01 | 37.5 | 120 |
| 2026-03-14 10:00:00 | web-02 | 41.2 | 134 |
| 2026-03-14 10:01:00 | web-01 | 39.0 | 126 |
| 2026-03-14 10:01:00 | web-02 | 44.8 | 141 |
As linhas são apenas acrescentadas e quase nunca alteradas. As perguntas típicas dizem respeito a janelas de tempo, por exemplo a carga média de CPU de cada servidor em intervalos de 5 minutos na última hora. A base de dados também pode apagar ou comprimir automaticamente os dados antigos: por exemplo, manter os pontos originais durante 30 dias e depois apenas as médias por hora.
Casos de uso: monitorização de servidores, métricas, dados de sensores, dados do mercado bolsista.
Exemplos: InfluxDB, TimescaleDB, OpenTSDB
Bases de Dados em Memória
Armazenam a maioria dos dados em RAM em vez de em disco - extremamente rápidas, embora a memória seja mais cara.
Exemplo de dados:
O Redis mantém na RAM estruturas de dados como o conjunto ordenado (sorted set). Aqui guarda um ranking de clientes por valor gasto: cada nova encomenda aumenta a pontuação do cliente e o conjunto mantém-se sempre ordenado:
top_customers
customer:42 114.5
customer:43 12
Ler o top 10 demora menos de um milissegundo. Uma base relacional teria de somar toda a tabela de encomendas para obter este ranking; aqui está sempre pronto.
Casos de uso: caching, sessões, contadores em tempo real, leaderboards de jogos.
Exemplos: Redis, Memcached, SAP HANA
Como Escolher o Tipo Certo de Base de Dados?
Questões a colocar:
- Os dados são altamente estruturados ou flexíveis?
- Preciso de transações ACID fortes?
- Vou executar joins complexos?
- A pesquisa por chave com baixa latência é a principal prioridade?
- A carga é transacional ou analítica?
- O sistema vai escalar por muitos servidores?
- As relações entre entidades são centrais para a aplicação?
Em muitos sistemas reais, as organizações usam mais do que um tipo de base de dados - a chamada persistência poliglota: relacional para dados de negócio, Redis para cache, documental para conteúdo flexível, colunar para análise.
Resumo: Diferenças-Chave Entre Tipos de Bases de Dados
- Modelo de dados - tabelas, documentos, chave-valor, grafos, registos temporais
- Flexibilidade do esquema - fixo ou flexível
- Estilo de consulta - SQL, chave, documentos, grafos, janelas temporais
- Modelo de consistência - garantias ACID fortes ou compromissos para escalabilidade
- Perfil de desempenho - transações, análise, relações ou acesso ultra-rápido
Principais Conclusões:
- Diferentes tipos de bases de dados existem porque diferentes aplicações têm requisitos diferentes.
- As bases relacionais são ideais para dados estruturados com relações, transações ACID e SQL.
- As bases chave-valor são excelentes para pesquisas rápidas e caching.
- As bases documentais são úteis para dados flexíveis ou em mudança.
- As bases de colunas largas são construídas para cargas distribuídas em grande escala.
- As bases colunares analíticas otimizam o reporting e a análise em grande escala.
- As bases em grafo são ideais para dados ricos em relações.
- As bases de séries temporais especializam-se em métricas e eventos temporais.
- A persistência poliglota combina vários tipos para diferentes necessidades.
Perguntas Frequentes
Qual é a diferença entre bases de dados relacionais e NoSQL?
As bases relacionais usam esquema fixo, transações ACID e SQL. NoSQL é um termo genérico para modelos chave-valor, documentais, colunas largas e grafo - trocam algumas garantias de consistência por flexibilidade ou escalabilidade horizontal. A escolha certa depende dos seus dados e carga de trabalho.
Quando usar uma base documental em vez de relacional?
Use uma base documental quando os dados têm estrutura aninhada variável e joins entre coleções são raros. Use uma base relacional quando os dados são estruturados, as entidades estão interligadas e precisa de transações fiáveis com consultas multi-tabela complexas.
Uma aplicação pode usar vários tipos de bases de dados?
Sim - isso chama-se persistência poliglota. É comum em produção: PostgreSQL para dados transacionais, Redis para cache, ClickHouse para análise. Cada tipo é usado onde tem melhor desempenho.
Perguntas de Entrevista
Que tipo de base de dados escolheria para um caso de uso específico, e porquê?
Comece pela carga e pelas restrições: estrutura dos dados, requisitos de consistência, padrão de consultas, objetivos de latência e escala. Por exemplo, escolha uma base relacional para transações ACID, uma base documental para registos JSON flexíveis e uma base de séries temporais para métricas com marca temporal.
Quais são os prós e os contras de um tipo de base de dados face a outro?
Cada modelo envolve compromissos. As bases relacionais oferecem forte consistência, joins e um ecossistema SQL maduro, mas alterações de esquema podem ser mais rígidas em grande escala. Os modelos NoSQL costumam oferecer mais flexibilidade ou escalabilidade horizontal, mas podem limitar joins ou exigir mais cuidado no desenho da consistência.
É possível usar diferentes tipos de bases de dados na mesma aplicação?
Sim. Isso é persistência poliglota: usar várias bases, cada uma para a carga que trata melhor. Um padrão comum é PostgreSQL para transações, Redis para cache e ClickHouse (ou outro sistema colunar) para análise.