UC00664

Bases de Dados NoSQL

MongoDB, Redis, Elasticsearch

Curso profissional · 50h · BDs modernas

Plano

  1. SQL vs NoSQL — quando usar
  2. Tipos de NoSQL
  3. MongoDB (document)
  4. Redis (key-value)
  5. Elasticsearch (search)
  6. Modelagem em document DBs
  7. Performance e escala
  8. Backup e segurança

Bloco 1 · SQL vs NoSQL

SQL (relacional)

  • MySQL, PostgreSQL, SQLite, SQL Server, Oracle.
  • Tabelas com schemas rígidos.
  • Relações via JOINs.
  • ACID (Atomicity, Consistency, Isolation, Durability).
  • Mature, bem entendido, suporte excelente.
SELECT u.name, COUNT(o.id) 
FROM users u 
LEFT JOIN orders o ON o.user_id = u.id 
GROUP BY u.id;

NoSQL — alternativa

  • Schemas flexíveis ou ausentes.
  • Optimizadas para casos específicos (escala, latência, queries).
  • Diferentes paradigmas: document, key-value, column, graph, search.
  • BASE (Basically Available, Soft state, Eventually consistent) em vez de ACID estrito.

Quando NoSQL faz sentido

✅ Schema flexível (user-generated content, IoT).
✅ Escala horizontal (milhões de utilizadores).
✅ High throughput (cache, sessions).
✅ Full-text search.
✅ Real-time (chats, notifications).

❌ Transações complexas multi-row.
❌ Joins frequentes.
❌ Reporting/BI tradicional.

Bloco 2 · Tipos de NoSQL

Document stores

  • MongoDB — JSON-like, mais popular.
  • CouchDB — sync-friendly.
  • Firebase Firestore — real-time, cloud.

Cada record = "document" (JSON). Sem schema rígido.

{
  "_id": "user123",
  "name": "Ana",
  "email": "ana@x.pt",
  "orders": [{"id": 1, "total": 50}, {"id": 2, "total": 30}]
}

Key-value

  • Redis — in-memory, rápido.
  • Memcached.
  • DynamoDB (AWS, parte).

Chave → valor (string, número, hash, lista, set).

SET session:abc123 "{user: 'Ana', exp: ...}"
GET session:abc123

Wide-column

  • Cassandra.
  • HBase.
  • ScyllaDB.

Escalam imensamente (PB+). Usados em logging, IoT, fraud detection.

Graph

  • Neo4j.
  • ArangoDB.

Nodes + relationships. Ideal para social networks, recommendations, fraud detection.

MATCH (u:User)-[:FRIEND]->(f:User)
WHERE u.name = "Ana"
RETURN f.name
  • Elasticsearch (e Open Search).
  • Algolia (SaaS).
  • Meilisearch.

Optimizados para full-text search, aggregations, faceting.

Bloco 3 · MongoDB

Setup

# Docker (mais fácil)
docker run -d -p 27017:27017 --name mongo mongo:7

# Ou MongoDB Atlas (cloud free tier)
# https://www.mongodb.com/cloud/atlas

Cliente: MongoDB Compass (GUI), mongosh (CLI), drivers Python/Node/Java.

Conceitos

MongoDB instance
└── Database (ex: "loja")
    └── Collection (ex: "products")
        └── Document (JSON-like)
  • Database = "BD".
  • Collection = "tabela" (sem schema rígido).
  • Document = "linha" (BSON, similar a JSON).

Operações CRUD

// Connect
use loja

// Insert
db.products.insertOne({
  name: "Caneta",
  price: 1.50,
  stock: 100
});

// Insert many
db.products.insertMany([
  {name: "Caderno", price: 5.00, stock: 50},
  {name: "Mochila", price: 35.00, stock: 20}
]);

// Find all
db.products.find();

// Find one
db.products.findOne({name: "Caneta"});

Queries

// Filtros
db.products.find({price: {$gt: 10}});       // price > 10
db.products.find({stock: {$lte: 50}});      // stock <= 50

// AND
db.products.find({
  price: {$gt: 10}, 
  stock: {$lt: 100}
});

// OR
db.products.find({
  $or: [{price: {$lt: 5}}, {stock: 0}]
});

// In
db.products.find({name: {$in: ["Caneta", "Caderno"]}});

// Regex
db.products.find({name: /^Ca/});

// Projection (só campos)
db.products.find({}, {name: 1, price: 1});

// Sort + limit
db.products.find().sort({price: -1}).limit(10);

Update e Delete

// Update one
db.products.updateOne(
  {name: "Caneta"},
  {$set: {price: 1.80}}
);

// Update many
db.products.updateMany(
  {stock: 0},
  {$set: {discontinued: true}}
);

// Operadores: $set, $inc, $push, $pull
db.products.updateOne(
  {_id: ObjectId("...")},
  {$inc: {stock: -1}}
);

// Delete
db.products.deleteOne({name: "Velho"});
db.products.deleteMany({stock: 0});

Aggregation pipeline

// Total vendas por categoria
db.orders.aggregate([
  {$match: {date: {$gte: new Date("2026-01-01")}}},
  {$group: {
    _id: "$category",
    total: {$sum: "$amount"},
    count: {$sum: 1}
  }},
  {$sort: {total: -1}},
  {$limit: 10}
]);

Pipeline = lista de stages. Equivalente NoSQL ao GROUP BY + WHERE + ORDER BY.

Python driver — pymongo

from pymongo import MongoClient

client = MongoClient("mongodb://localhost:27017/")
db = client.loja
products = db.products

# Insert
products.insert_one({"name": "Caneta", "price": 1.50})

# Find
for p in products.find({"price": {"$gt": 5}}):
    print(p["name"], p["price"])

# Aggregate
result = products.aggregate([
    {"$group": {"_id": "$category", "total": {"$sum": "$price"}}}
])

Bloco 4 · Redis

Para que serve

  • Cache (resultados de queries lentas).
  • Sessions (login state).
  • Rate limiting.
  • Pub/sub (real-time).
  • Queues (background jobs).
  • Leaderboards (sorted sets).

In-memory = microssegundos de latência.

Setup

docker run -d -p 6379:6379 redis:7

# CLI
redis-cli

Tipos de dados

# String
SET nome "Ana"
GET nome
EXPIRE nome 60        # TTL em segundos

# Number (string que parece int)
INCR contador        # +1
INCRBY contador 5

# Hash (objecto)
HSET user:1 name "Ana" age 25
HGET user:1 name
HGETALL user:1

# List (queue/stack)
LPUSH queue "task1"
RPOP queue

# Set (únicos, sem ordem)
SADD tags "python" "web"
SMEMBERS tags

# Sorted set (score → member)
ZADD leaderboard 100 "Ana" 200 "Bruno"
ZRANGE leaderboard 0 -1 WITHSCORES

Cache pattern

import redis
import json

r = redis.Redis(host='localhost', port=6379)

def get_user(id):
    key = f"user:{id}"
    
    # Try cache
    cached = r.get(key)
    if cached:
        return json.loads(cached)
    
    # Miss → fetch from DB
    user = fetch_user_from_db(id)
    
    # Cache for 1h
    r.setex(key, 3600, json.dumps(user))
    
    return user

Bloco 5 · Elasticsearch

Para que serve

  • Full-text search (Google-like).
  • Logging (com Logstash + Kibana = ELK stack).
  • Analytics.
  • APM (application monitoring).

Setup

docker run -d -p 9200:9200 -p 9300:9300 \
  -e "discovery.type=single-node" \
  -e "xpack.security.enabled=false" \
  elasticsearch:8.12.0

curl http://localhost:9200
# {"cluster_name": ...}

Indexar e procurar

# Index document
curl -X POST "localhost:9200/products/_doc" \
  -H 'Content-Type: application/json' \
  -d '{"name": "Caneta azul", "price": 1.50}'

# Full-text search
curl -X GET "localhost:9200/products/_search" \
  -H 'Content-Type: application/json' \
  -d '{"query": {"match": {"name": "azul"}}}'

Retorna scored results — mais relevantes primeiro.

Bloco 6 · Modelagem

SQL vs Document

SQL (normalizado):

users
  id, name, email

orders
  id, user_id, total, date

MongoDB (denormalizado):

{
  "name": "Ana",
  "email": "ana@x.pt",
  "orders": [
    {"id": 1, "total": 50, "date": "2026-01-15"},
    {"id": 2, "total": 30, "date": "2026-02-01"}
  ]
}

Embed vs Reference

Embed (data dentro):

  • Pros: 1 query, atomicidade.
  • Cons: doc cresce, duplicação.
  • Use quando: 1:1 ou 1:N pequeno, frequentemente lido junto.

Reference (ID linkado):

  • Pros: sem duplicação, doc pequeno.
  • Cons: precisa segunda query.
  • Use quando: N:M, dados independentes.
// Embed
{
  "post": "...",
  "comments": [{"text": "...", "author": "..."}]
}

// Reference
{
  "post": "...",
  "comment_ids": ["c1", "c2"]
}

Trade-offs

  • Sem JOINs nativos: ou denormalizas (embed) ou fazes 2 queries.
  • Schema flexível = liberdade mas também caos.
  • Eventual consistency: replicação tem delay.
  • Sharding: escala horizontal mas adiciona complexidade.

Bloco 7 · Performance

Indexes

// MongoDB
db.products.createIndex({name: 1});         // ascending
db.products.createIndex({price: 1, stock: -1}); // composto

// Verificar uso
db.products.find({name: "Caneta"}).explain("executionStats");

Sem index, find = scan da collection inteira.

Sharding e replication

  • Replica set (MongoDB): primary + secondaries (high availability).
  • Sharding: dados divididos por chave entre nodes (scale horizontal).
  • Redis Cluster: hash slots em vários nodes.

Setup complexo — normalmente cloud-managed (Atlas, ElastiCache).

Bloco 8 · Backup e segurança

Backup MongoDB

# Backup
mongodump --uri="mongodb://localhost:27017" --out=/backup

# Restore
mongorestore --uri="mongodb://localhost:27017" /backup

Atlas: backups automáticos integrados.

Segurança

  • Autenticação: utilizadores com roles.
  • TLS: connections encriptadas.
  • Network: firewall, VPC.
  • Field-level encryption (MongoDB enterprise).
  • GDPR: anonimização, right to be forgotten.
mongosh --username admin --password ... --authenticationDatabase admin

UC00664 · resumo

  • NoSQL = alternativa a SQL para casos específicos.
  • Document (MongoDB) = JSON-like, flexível.
  • Key-value (Redis) = ultra-rápido, in-memory.
  • Search (Elasticsearch) = full-text + analytics.
  • MongoDB CRUD + aggregation pipeline.
  • Modelagem: embed vs reference (trade-offs).
  • Indexes essenciais para performance.
  • Sharding + replication para escala.
  • Cloud-managed (Atlas, ElastiCache) é norma.

NOTAS DO PROFESSOR 📖 O modelo relacional como ponto de partida Antes de falar de NoSQL é preciso situar o que ele substitui ou complementa: as bases relacionais, com tabelas de schema rígido, relações por JOINs e garantias ACID. Este modelo é maduro e excelente para dados estruturados e transações. Compreender as suas forças torna mais claro porque, em certos casos, se procura uma alternativa. 🗣️ Pontos a desenvolver oralmente • Explicar o significado prático das garantias ACID • Mostrar o que um JOIN faz no exemplo SQL apresentado • Sublinhar que SQL continua a ser a escolha certa na maioria dos casos

NOTAS DO PROFESSOR 📖 NoSQL: outra filosofia de dados NoSQL não é uma tecnologia única, mas uma família de abordagens que abdicam do schema rígido e por vezes da consistência estrita em troca de escala, flexibilidade e desempenho. A oposição entre ACID e BASE é central: BASE aceita consistência eventual para ganhar disponibilidade e escala horizontal. Convém deixar claro que NoSQL não substitui SQL, antes resolve problemas diferentes. 🗣️ Pontos a desenvolver oralmente • Explicar o que significa consistência eventual com um exemplo • Contrastar a rigidez do schema SQL com a flexibilidade NoSQL • Desfazer o mito de que NoSQL é sempre melhor que SQL

NOTAS DO PROFESSOR 📖 Escolher a ferramenta certa A competência mais valiosa deste bloco é saber quando NoSQL faz sentido e quando não. Ganha em schemas flexíveis, escala horizontal, alta taxa de pedidos e pesquisa de texto; perde em transações complexas, JOINs frequentes e reporting tradicional. A regra prática é deixar o problema escolher a tecnologia, e não o contrário. 🗣️ Pontos a desenvolver oralmente • Dar um exemplo concreto para cada caso favorável a NoSQL • Explicar porque transações multi-registo são um ponto fraco do NoSQL • Discutir cenários híbridos que usam SQL e NoSQL em conjunto

NOTAS DO PROFESSOR 📖 Bases de documentos As bases documentais, lideradas pelo MongoDB, guardam cada registo como um documento JSON, sem schema rígido e com dados aninhados. O exemplo mostra como as encomendas de um utilizador podem viver dentro do próprio documento, evitando JOINs. Esta proximidade ao formato JSON usado nas aplicações torna o modelo muito natural para programadores web. 🗣️ Pontos a desenvolver oralmente • Comparar o documento JSON com várias tabelas relacionais equivalentes • Explicar a vantagem de ter dados aninhados num único documento • Antecipar o trade-off entre aninhar e referenciar (visto mais à frente)

NOTAS DO PROFESSOR 📖 Bases chave-valor O modelo chave-valor é o mais simples de todos: uma chave aponta para um valor, como num dicionário. Bases como o Redis vivem em memória, o que lhes dá latência de microssegundos, ideal para cache, sessões e limitação de pedidos. A simplicidade é a força e também o limite: não há consultas ricas, apenas acesso direto por chave. 🗣️ Pontos a desenvolver oralmente • Relacionar o modelo chave-valor com um dicionário de programação • Explicar porque viver em memória dá tanta velocidade • Dar exemplos concretos de uso: cache, sessões, contadores

NOTAS DO PROFESSOR 📖 Bases wide-column As bases de colunas largas, como Cassandra, foram desenhadas para escalar a volumes massivos de dados distribuídos por muitos servidores. São a escolha típica para logging, telemetria IoT e deteção de fraude, onde se escreve e lê a uma escala que esmagaria uma base relacional. Convém referir que esta potência vem com maior complexidade de modelação e operação. 🗣️ Pontos a desenvolver oralmente • Explicar a ideia de distribuir dados por muitos nós • Dar exemplos de cargas de trabalho de escala petabyte • Sublinhar que a complexidade operacional sobe com a escala

NOTAS DO PROFESSOR 📖 Bases de grafos As bases de grafos modelam dados como nós e relações, sendo imbatíveis quando o valor está nas ligações: redes sociais, recomendações e deteção de fraude. A consulta de exemplo, em Cypher, mostra como encontrar os amigos de alguém percorrendo relações, algo que em SQL exigiria JOINs sucessivos e pesados. Sempre que o problema é sobre conexões, vale a pena considerar um grafo. 🗣️ Pontos a desenvolver oralmente • Explicar a leitura da consulta Cypher de amizades • Contrastar percorrer relações num grafo com JOINs em SQL • Dar exemplos de problemas naturalmente expressos como grafos

NOTAS DO PROFESSOR 📖 Motores de pesquisa Bases orientadas a pesquisa, como o Elasticsearch, são otimizadas para procura de texto completo, agregações e facetagem, o tipo de funcionalidade que está por trás de uma barra de pesquisa do estilo Google. Resolvem um problema que as bases relacionais fazem mal: encontrar rapidamente texto relevante em grandes volumes. São muitas vezes usadas em conjunto com outra base, não em substituição. 🗣️ Pontos a desenvolver oralmente • Explicar o que é a pesquisa de texto completo e a relevância • Dar o exemplo da barra de pesquisa de um site de e-commerce • Sublinhar que estes motores complementam, não substituem, a base principal

NOTAS DO PROFESSOR 📖 Pôr o MongoDB a correr A forma mais simples de começar é via Docker, que cria uma instância isolada num comando, ou via Atlas, a oferta cloud gerida com plano gratuito. Convém apresentar também os clientes: o Compass com interface gráfica para explorar dados e o mongosh para a linha de comandos. Ter o ambiente a funcionar é o primeiro passo prático para todos os exercícios seguintes. 🗣️ Pontos a desenvolver oralmente • Mostrar a vantagem do Docker para um ambiente descartável e limpo • Comparar o uso do Compass com o do mongosh • Referir o Atlas como opção sem instalação local

NOTAS DO PROFESSOR 📖 O vocabulário do MongoDB Mapear os conceitos do MongoDB aos termos relacionais que os formandos já conhecem acelera muito a aprendizagem: database é a BD, collection equivale a tabela e document a linha. A diferença essencial é que as collections não impõem schema rígido e os documentos são BSON, próximo de JSON. Esta tradução evita confusão quando se passa do mundo SQL para o documental. 🗣️ Pontos a desenvolver oralmente • Fazer a correspondência termo a termo com o modelo relacional • Sublinhar a ausência de schema rígido nas collections • Explicar brevemente o que é BSON face a JSON

NOTAS DO PROFESSOR 📖 As operações CRUD no MongoDB CRUD (criar, ler, atualizar, apagar) é a base de qualquer interação com dados, e no MongoDB exprime-se com métodos como insertOne, find e findOne. O exemplo mostra que se trabalha com objetos no formato JSON, o que é muito intuitivo para quem já programa em JavaScript ou Python. Convém praticar estas operações ao vivo, vendo os documentos a surgir na collection. 🗣️ Pontos a desenvolver oralmente • Distinguir insertOne de insertMany na prática • Mostrar a diferença entre find e findOne nos resultados • Propor um exercício de inserir e listar documentos

NOTAS DO PROFESSOR 📖 Consultar dados com filtros As queries do MongoDB usam operadores como $gt, $lte, $or e $in para filtrar documentos, com uma sintaxe baseada em objetos. O exemplo cobre comparações, condições combinadas, projeções para devolver só certos campos, e ordenação com limite. Dominar estes operadores é o que permite extrair exatamente os dados pretendidos, o equivalente ao WHERE do SQL. 🗣️ Pontos a desenvolver oralmente • Traduzir alguns filtros para o seu equivalente em SQL • Explicar o valor das projeções para reduzir dados transferidos • Propor exercícios de filtros combinados com sort e limit

NOTAS DO PROFESSOR 📖 Atualizar e apagar documentos As operações de atualização usam operadores específicos como $set para definir campos e $inc para incrementar, e podem afetar um ou muitos documentos. Um ponto a destacar é a distinção entre updateOne e updateMany, e o cuidado que esta última exige para não alterar mais do que o pretendido. O mesmo princípio de um ou muitos aplica-se ao apagar. 🗣️ Pontos a desenvolver oralmente • Explicar a diferença entre $set e $inc com exemplos • Alertar para o risco de updateMany e deleteMany sem filtro adequado • Mostrar como o $inc evita ler e reescrever um valor manualmente

NOTAS DO PROFESSOR 📖 Agregações em pipeline O aggregation pipeline é a ferramenta poderosa do MongoDB para análises: os dados passam por uma sequência de etapas, cada uma transformando o resultado da anterior. O exemplo filtra com $match, agrupa com $group, ordena e limita, sendo o equivalente combinado de WHERE, GROUP BY e ORDER BY do SQL. Pensar em etapas encadeadas é a mudança mental necessária para dominar esta funcionalidade. 🗣️ Pontos a desenvolver oralmente • Percorrer cada etapa do pipeline e o que faz aos dados • Comparar o pipeline com uma query SQL de agregação equivalente • Sublinhar que a ordem das etapas influencia o resultado e o desempenho

NOTAS DO PROFESSOR 📖 Usar o MongoDB a partir de Python O driver pymongo permite usar tudo o que se viu na shell diretamente em código Python, com os filtros e operadores a manterem a mesma sintaxe de objetos. Note-se como find devolve um iterável que se percorre com um ciclo for, integrando-se naturalmente no fluxo de uma aplicação. Esta continuidade entre a shell e o código facilita passar do protótipo para o programa real. 🗣️ Pontos a desenvolver oralmente • Sublinhar que os operadores são os mesmos da shell, agora em dicionários • Mostrar como iterar o resultado de find num ciclo • Relacionar o driver com a forma como uma aplicação acede aos dados

NOTAS DO PROFESSOR 📖 Para que serve o Redis O Redis brilha onde a velocidade é tudo: cache de queries lentas, gestão de sessões, limitação de pedidos, filas e leaderboards. Por viver em memória, oferece latência de microssegundos, ordens de grandeza acima de qualquer base em disco. A mensagem é que o Redis raramente é a base principal, mas sim um acelerador colocado à frente de outra base. 🗣️ Pontos a desenvolver oralmente • Explicar o padrão de usar Redis como cache de uma base mais lenta • Dar um exemplo de leaderboard com sorted sets • Sublinhar que dados em memória exigem estratégia de persistência

NOTAS DO PROFESSOR 📖 Arrancar com o Redis Tal como o MongoDB, o Redis sobe num único comando Docker, e o redis-cli dá acesso imediato à linha de comandos para experimentar. Ter o servidor a correr permite testar os comandos do slide seguinte em tempo real e ver os resultados na hora. Este arranque rápido é parte do apelo do Redis, que é simples de pôr a funcionar. 🗣️ Pontos a desenvolver oralmente • Mostrar o arranque via Docker e a ligação com redis-cli • Antecipar que se vão experimentar comandos diretamente na CLI • Referir que em produção há configuração adicional de persistência

NOTAS DO PROFESSOR 📖 As estruturas de dados do Redis O Redis é mais do que um simples chave-valor: oferece strings, números, hashes, listas, sets e sorted sets, cada um com comandos próprios. Esta riqueza permite resolver problemas concretos de forma elegante, como filas com listas ou rankings com sorted sets. Conhecer a estrutura certa para cada caso é o que distingue um uso ingénuo de um uso proficiente do Redis. 🗣️ Pontos a desenvolver oralmente • Associar cada estrutura a um caso de uso prático • Mostrar o TTL com EXPIRE como base de caches que expiram • Demonstrar um sorted set a manter um ranking ordenado

NOTAS DO PROFESSOR 📖 O padrão cache-aside Este exemplo ilustra o padrão de cache mais comum: tentar primeiro o Redis, e só em caso de falha consultar a base lenta e guardar o resultado com um tempo de vida. É a forma prática de aliviar a base principal e acelerar respostas. O setex com expiração garante que os dados em cache não ficam desatualizados para sempre. 🗣️ Pontos a desenvolver oralmente • Percorrer o fluxo: tentar cache, falhar, ir à base, guardar • Explicar a importância do tempo de expiração na frescura dos dados • Discutir o problema de invalidar a cache quando os dados mudam

NOTAS DO PROFESSOR 📖 Para que serve o Elasticsearch O Elasticsearch resolve a pesquisa de texto completo ao estilo Google, mas é também o coração da stack ELK para gestão e análise de logs. É a ferramenta a que se recorre quando se precisa de procurar rapidamente em enormes volumes de texto ou de dados de eventos. Convém posicioná-lo como um motor especializado que coexiste com a base de dados principal da aplicação. 🗣️ Pontos a desenvolver oralmente • Explicar o papel do Elasticsearch na stack ELK de logging • Dar exemplos de pesquisa e análise em grandes volumes de logs • Distinguir o seu papel do de uma base relacional ou documental

NOTAS DO PROFESSOR 📖 Arrancar e contactar o Elasticsearch O Elasticsearch sobe via Docker e expõe uma API REST sobre HTTP, que se pode testar logo com um simples curl. Verificar que o cluster responde no porto 9200 confirma que o ambiente está pronto. Convém notar que neste arranque a segurança vem desativada para simplificar a aprendizagem, algo que em produção teria de ser revisto. 🗣️ Pontos a desenvolver oralmente • Mostrar a resposta do cluster a um pedido HTTP simples • Sublinhar que toda a interação é feita por API REST • Alertar que desativar segurança só é aceitável em ambiente de teste

NOTAS DO PROFESSOR 📖 Indexar e pesquisar texto No Elasticsearch, primeiro indexa-se um documento e depois pesquisa-se com queries como match, que procura por relevância e não apenas por igualdade exata. O ponto distintivo é que os resultados vêm pontuados, com os mais relevantes primeiro, ao contrário de uma base relacional onde tudo é igual ou diferente. É esta noção de relevância que torna a pesquisa de texto tão poderosa. 🗣️ Pontos a desenvolver oralmente • Explicar a diferença entre match e uma comparação exata • Mostrar como a pontuação ordena os resultados por relevância • Dar exemplos de pesquisas onde a relevância faz toda a diferença

NOTAS DO PROFESSOR 📖 Pensar em documentos, não em tabelas A modelação documental exige uma mudança de mentalidade: em vez de normalizar dados em tabelas separadas, junta-se o que se lê em conjunto dentro de um único documento. O exemplo mostra encomendas aninhadas no documento do utilizador, evitando o JOIN que o SQL exigiria. Esta desnormalização é uma escolha de design deliberada, com vantagens e custos que se exploram no próximo slide. 🗣️ Pontos a desenvolver oralmente • Contrastar a abordagem normalizada do SQL com a documental • Explicar quando juntar dados num documento beneficia a leitura • Antecipar os custos da desnormalização, como a duplicação

NOTAS DO PROFESSOR 📖 Aninhar ou referenciar A decisão central na modelação documental é entre embeber dados dentro do documento ou referenciá-los por ID. Embeber dá leitura numa só query e atomicidade, mas faz o documento crescer e pode duplicar dados; referenciar mantém documentos pequenos mas exige uma segunda consulta. A regra prática liga-se à cardinalidade e ao padrão de acesso: o que se lê junto e é pequeno embebe-se; o que é independente ou muitos-para-muitos referencia-se. 🗣️ Pontos a desenvolver oralmente • Dar um caso claro a favor de embeber e outro a favor de referenciar • Explicar como o padrão de leitura orienta a decisão • Relacionar a escolha com a cardinalidade das relações

NOTAS DO PROFESSOR 📖 Os compromissos do NoSQL documental Trabalhar com bases documentais implica aceitar compromissos: sem JOINs nativos, ou se desnormaliza ou se fazem várias consultas; a flexibilidade do schema traz liberdade mas também risco de caos. A consistência eventual e o sharding dão escala, mas adicionam complexidade. A maturidade técnica está em reconhecer estes custos e decidir com conhecimento de causa, não por moda. 🗣️ Pontos a desenvolver oralmente • Discutir o risco de caos quando não há schema imposto • Explicar o impacto prático da consistência eventual • Relacionar o sharding com ganho de escala e aumento de complexidade

NOTAS DO PROFESSOR 📖 Índices: a chave do desempenho Sem índices, cada consulta percorre a collection inteira, o que se torna inviável à medida que os dados crescem. Criar índices nos campos por que se pesquisa transforma varrimentos lentos em acessos rápidos, tal como num livro o índice evita ler todas as páginas. O comando explain é a ferramenta para verificar se uma query está de facto a usar o índice. 🗣️ Pontos a desenvolver oralmente • Explicar a analogia entre índice de base de dados e índice de livro • Mostrar o uso de explain para confirmar o uso de um índice • Alertar que índices a mais penalizam as escritas

NOTAS DO PROFESSOR 📖 Escalar com replicação e sharding Dois mecanismos garantem que uma base NoSQL cresce e resiste a falhas: a replicação, que mantém cópias para alta disponibilidade, e o sharding, que divide os dados por vários nós para escalar horizontalmente. São conceitos poderosos mas de configuração complexa, razão pela qual a maioria das equipas opta por serviços geridos na cloud. Convém deixar claro que estes temas são o passo seguinte, depois de dominar o básico. 🗣️ Pontos a desenvolver oralmente • Distinguir o objetivo da replicação (disponibilidade) do do sharding (escala) • Explicar porque a maioria recorre a serviços geridos como o Atlas • Situar estes conceitos como nível avançado a explorar depois

NOTAS DO PROFESSOR 📖 Backups: a rede de segurança esquecida Fazer cópias de segurança é uma disciplina muitas vezes negligenciada até ser tarde demais. O MongoDB oferece mongodump e mongorestore para exportar e restaurar dados, e o Atlas automatiza tudo na cloud. A mensagem-chave para os formandos é que um backup só vale se já tiver sido testado um restauro, antes do dia em que for realmente preciso. 🗣️ Pontos a desenvolver oralmente • Demonstrar um ciclo completo de dump e restore • Sublinhar que um backup nunca testado não é um backup fiável • Referir a vantagem dos backups automáticos geridos pelo Atlas

NOTAS DO PROFESSOR 📖 Segurança e conformidade dos dados Proteger uma base de dados envolve várias camadas: autenticação com utilizadores e papéis, encriptação das ligações com TLS, isolamento na rede e, quando necessário, encriptação ao nível do campo. Acresce a dimensão legal: o RGPD obriga a anonimizar dados e a respeitar o direito ao esquecimento. Um profissional responsável trata estes temas como requisitos, não como opcionais. 🗣️ Pontos a desenvolver oralmente • Explicar o papel da autenticação baseada em papéis • Relacionar as exigências do RGPD com decisões técnicas concretas • Sublinhar que a segurança se constrói em camadas complementares

NOTAS DO PROFESSOR 📖 Síntese das bases NoSQL Este resumo consolida a ideia central da UC: NoSQL é uma família de ferramentas, cada uma boa para um tipo de problema, do documental ao chave-valor à pesquisa. Reforça também as competências transversais: modelar bem, indexar para desempenho e pensar em escala, backup e segurança. A mensagem final é escolher a base certa para cada caso, e não procurar uma solução única para tudo. 🗣️ Pontos a desenvolver oralmente • Pedir aos formandos para associarem cada tipo de base a um caso de uso • Reforçar a decisão embeber versus referenciar na modelação • Propor um projeto que combine MongoDB com Redis como cache