A Resposta aos Desafios: Por Que o SGBD?

A partir da década de 1960, com o aumento da complexidade dos sistemas e do volume de dados, as limitações dos sistemas de arquivos tradicionais (discutidas no slide anterior) tornaram-se insustentáveis. Era evidente a necessidade de uma solução mais robusta, que oferecesse:

• **Centralização e Controle:** Um único ponto para gerenciar todos os dados da organização.
• **Independência de Dados:** Separar a forma como os dados são vistos pela aplicação da forma como são armazenados fisicamente.
• **Integridade:** Garantir que os dados sejam corretos e consistentes.
• **Segurança:** Controlar o acesso e as permissões de forma granular.
• **Concorrência:** Permitir acesso simultâneo sem conflitos.
• **Recuperação:** Restaurar dados após falhas.

Essas necessidades impulsionaram o desenvolvimento dos **Sistemas Gerenciadores de Banco de Dados (SGBDs)**.

Modelos Pioneiros e Marcos Históricos

A jornada dos SGBDs começou com modelos que, embora menos flexíveis que os atuais, foram fundamentais para a sua evolução:

• **Anos 1960: Modelo Hierárquico (Ex: IBM IMS)**

  Baseado em uma estrutura de árvore, onde cada registro filho tem um único pai. Eficiente para algumas operações, mas inflexível para relações complexas. Foi um dos primeiros SGBDs comerciais de sucesso.

• **Início dos Anos 1970: Modelo em Rede (Ex: CODASYL DBTG)**

  Uma evolução do hierárquico, permitindo que um registro filho tivesse múltiplos pais, formando uma rede. Mais flexível, mas a navegação ainda era complexa e procedural.

• **1970: A Revolução do Modelo Relacional (Edgar F. Codd)**

  Proposto por Codd na IBM, o Modelo Relacional simplificou drasticamente a forma de organizar e consultar dados, utilizando o conceito de **tabelas (relações)** com linhas e colunas. Sua base matemática (teoria dos conjuntos) e a subsequente criação da **SQL (Structured Query Language)** tornaram o acesso aos dados muito mais intuitivo e poderoso, definindo o padrão para as décadas seguintes.

• **1975: C.J. Date publica “Introdução a SGBD”**

  Um marco literário que ajudou a popularizar os conceitos e a importância dos SGBDs.

• **Anos 1980–1990: Consolidação e Padrão Corporativo**

  Os SGBDs relacionais se tornam o padrão-ouro na indústria. Grandes sistemas como Oracle, IBM DB2 e SQL Server ganham destaque. A SQL se firma como a linguagem universal para bancos de dados, oferecendo consultas simplificadas, controle de concorrência robusto e alta integridade de dados.

-- Exemplo de como um SGBD garante a integridade de dados (unicidade)
CREATE DATABASE empresa_db;
\c empresa_db
CREATE TABLE clientes (
  id SERIAL PRIMARY KEY,
  nome VARCHAR(100) NOT NULL,
  email VARCHAR(100) UNIQUE
);
-- Inserção bem-sucedida:
INSERT INTO clientes (nome, email) VALUES ('João Silva', 'joao@email.com');
-- Tentativa de inserção com email duplicado (viola UNIQUE):
INSERT INTO clientes (nome, email) VALUES ('João Oliveira', 'joao@email.com');
-- Resultado: ERRO (o SGBD impede a inconsistência!)
-- ERROR: duplicate key value violates unique constraint "clientes_email_key"
      

-- 1. Criar a tabela 'pedidos' com FOREIGN KEY:
CREATE TABLE pedidos (
  id_pedido SERIAL PRIMARY KEY,
  id_cliente INT,
  data_pedido DATE DEFAULT CURRENT_DATE,
  valor DECIMAL(10, 2),
  FOREIGN KEY (id_cliente) REFERENCES clientes(id)
);

-- 2. Inserir um novo cliente (se não houver um 'João Silva' já, o id será 1)
INSERT INTO clientes (nome, email) VALUES ('Maria Clara', 'maria.clara@email.com');
-- Supondo que Maria Clara tenha id = 2 (se 'João Silva' for id=1).

-- 3. Inserir um pedido para o novo cliente (use o ID real que foi gerado)
INSERT INTO pedidos (id_cliente, valor) VALUES (2, 150.00);

-- 4. Tentar inserir um pedido com id_cliente que não existe (ex: 999)
INSERT INTO pedidos (id_cliente, valor) VALUES (999, 250.00);
-- Resultado esperado: ERRO (Violação de FOREIGN KEY!)
-- ERROR: insert or update on table "pedidos" violates foreign key constraint "pedidos_id_cliente_fkey"
--   Key (id_cliente)=(999) is not present in table "clientes".
      

Modelo Hierárquico (Anos 1960)

O Modelo Hierárquico foi um dos primeiros modelos de banco de dados a ganhar destaque comercial. Sua estrutura se assemelha a uma árvore invertida ou um organograma. Os dados são organizados em segmentos (ou nós) onde cada segmento "filho" pode ter apenas um segmento "pai", mas um "pai" pode ter múltiplos "filhos".

• Estrutura: Organização em árvore, com um único caminho de navegação de um nó raiz até qualquer folha. Cada registro tem um único "pai".
• Acesso aos Dados: As operações de manipulação de dados (DML) são essencialmente navegacionais. Você precisa percorrer a hierarquia, do pai para o filho, para encontrar os dados desejados. Por exemplo, para encontrar um projeto, você primeiro teria que navegar até o departamento, depois até o funcionário, e então para o projeto associado a esse funcionário.
• Vantagem: Era eficiente para certas operações quando a estrutura de dados se encaixava perfeitamente na hierarquia (relações 1:N).
• Limitação: Extremamente inflexível para representar relações muitos-para-muitos (N:M). Se um projeto fosse associado a vários funcionários de diferentes departamentos, o dado do projeto teria que ser duplicado ou a modelagem ficaria artificialmente complexa. Mudanças na estrutura eram difíceis.
• Exemplo Notável: IBM IMS (Information Management System), um SGBD amplamente utilizado em grandes corporações por décadas.

-- Exemplo Conceitual de Estrutura Hierárquica:
Departamento (Pai)
└── Funcionário (Filho)
    └── Projeto (Neto)

-- Limitação: Se um Projeto 'X' é trabalhado por 'Funcionário A' (Dep. 1) e 'Funcionário B' (Dep. 2),
-- o registro de 'Projeto X' precisaria ser duplicado sob ambos os funcionários,
-- ou então 'Funcionário B' não poderia se relacionar diretamente com 'Projeto X' dentro dessa hierarquia.
-- Isso leva a: Redundância ou Dificuldade de Modelagem de N:M.
          

Modelo em Rede (Anos 1970)

O Modelo em Rede surgiu como uma evolução do modelo hierárquico, buscando superar suas principais limitações, especialmente na representação de relações complexas. Ele permite uma estrutura de dados mais flexível, semelhante a um grafo.

• Estrutura: Os dados são organizados como um grafo simples, onde um registro "filho" pode ter múltiplos registros "pais". Isso significa que múltiplos caminhos de navegação são possíveis para alcançar um dado.
• DML Navegacional Flexível: A linguagem de manipulação de dados (DML) ainda era navegacional e procedural, mas mais flexível que a hierárquica. O programador precisava saber as "ligações" (ponteiros) entre os registros para navegar de um para outro.
• Vantagem: Conseguiu representar diretamente relações muitos-para-muitos (N:M) de forma mais natural que o modelo hierárquico, eliminando algumas redundâncias.
• Desvantagem: A complexidade na modelagem e na programação era alta. A navegação de dados ainda era procedural, o que significava que o programador precisava saber a estrutura exata e os "caminhos" para acessar os dados. Mudanças na estrutura do banco ainda exigiam alterações significativas nos programas.
• Exemplo Notável: CODASYL DBTG (Data Base Task Group), um padrão que influenciou vários SGBDs da época.

-- Exemplo Conceitual de Estrutura em Rede:
Departamento <--- (pertence_a) --- Funcionario --- (trabalha_em) ---> Projeto
                 ^                                    ^
                 |                                    |
                 +------------------------------------+

-- Comandos de Navegação (Pseudocódigo):
GET (Funcionario) ONDE nome = 'FuncionarioA';
ENCONTRAR PROXIMO (Projeto) ATRAVES DE 'trabalha_em' DE FUNCIONARIO;
-- Desafio: A complexidade reside na necessidade de gerenciar as múltiplas conexões
-- e entender o caminho correto para o dado desejado, o que era responsabilidade do programador.
          

-- 1. Modelagem em Modelo Hierárquico (Produto-Fornecedor N:M):
-- Opção A: Fornecedor (pai) -> Produto (filho)
--    Limitação: Um Produto só pode ter um Fornecedor "pai". Se o mesmo produto
--    é fornecido por 3 fornecedores diferentes, o registro do Produto teria que
--    ser DUPLICADO 3 vezes, uma para cada Fornecedor pai. Isso gera redundância.

-- Opção B: Produto (pai) -> Fornecedor (filho)
--    Limitação: Similar, um Fornecedor só pode ser "filho" de um Produto. Se um Fornecedor
--    fornece 10 produtos diferentes, o registro do Fornecedor seria DUPLICADO 10 vezes.

-- 2. Modelagem em Modelo em Rede (Produto-Fornecedor N:M):
-- Produto <--- (fornece_para) --- Fornecedor
--    Vantagem: O modelo em rede permite que um registro de Produto tenha múltiplos
--    "pais" (Fornecedores), e um registro de Fornecedor tenha múltiplos "filhos" (Produtos),
--    conectando-os diretamente. Isso elimina a redundância de dados que a hierárquica teria.
--    Desafio: A navegação ainda é procedural. Para encontrar todos os fornecedores de um produto,
--    o programador precisa seguir as ligações específicas, o que é complexo e menos flexível
--    que as consultas declarativas da SQL.
      

A Simplicidade que Transformou Tudo

Proposto por Edgar F. Codd na IBM, o Modelo Relacional revolucionou o gerenciamento de dados ao introduzir uma abordagem matemática e lógica que era incrivelmente mais simples e flexível que seus antecessores (hierárquico e em rede). A grande sacada foi organizar os dados em tabelas simples, eliminando a complexidade da navegação por ponteiros.

Conceitos Chave do Modelo Relacional

Para entender o poder do Modelo Relacional, a gente precisa dominar seus pilares:

• Tabelas (Relações): Onde os dados são armazenados. Pense em uma tabela como uma planilha de dados, com linhas e colunas. No contexto de banco de dados, "relação" é o termo técnico para tabela.
• Tuplas (Registros/Linhas): Cada linha em uma tabela representa uma única ocorrência de um objeto ou evento. Por exemplo, em uma tabela de clientes, cada tupla seria um cliente específico.
• Atributos (Campos/Colunas): Cada coluna em uma tabela representa uma característica ou propriedade dos objetos/eventos. Por exemplo, "nome", "endereço" ou "telefone" seriam atributos da tabela de clientes.
• Domínios de Valores: Cada atributo possui um domínio, que é o conjunto de valores permitidos para ele (ex: o domínio do atributo "idade" seriam números inteiros positivos). Isso contribui para a integridade de dados.
• Integridade de Dados: O modelo relacional tem regras claras para garantir que os dados sejam válidos e consistentes. Isso inclui:
  • Integridade de Entidade: Cada tupla em uma tabela precisa ser única e identificável.
  • Integridade Referencial: Garante que as relações entre tabelas sejam mantidas (ex: não dá pra ter um pedido sem um cliente associado).
• Chaves Primárias (PRIMARY KEY - PK): Um atributo ou conjunto de atributos que identifica de forma única e não nula cada tupla em uma tabela. É a "identidade" de cada registro.
• Chaves Estrangeiras (FOREIGN KEY - FK): Um atributo em uma tabela que estabelece um relacionamento com a chave primária de outra tabela. A chave estrangeira é o que "liga" as tabelas no modelo relacional, permitindo consultar dados relacionados facilmente.

-- Criando Tabelas Relacionais com Chaves Primárias e Estrangeiras
-- Tabela 'categorias': 'id' é a PRIMARY KEY.
CREATE TABLE categorias (
  id INT PRIMARY KEY,
  descricao VARCHAR(100) NOT NULL UNIQUE
);

-- Tabela 'produtos': 'id' é PRIMARY KEY, 'categoria_id' é FOREIGN KEY, referenciando 'categorias(id)'.
CREATE TABLE produtos (
  id INT PRIMARY KEY,
  nome VARCHAR(150) NOT NULL,
  preco DECIMAL(10, 2) CHECK (preco > 0),
  categoria_id INT,
  FOREIGN KEY (categoria_id) REFERENCES categorias(id)
);

-- Inserindo dados (tuplas) nas tabelas
INSERT INTO categorias (id, descricao) VALUES (1, 'Eletrônicos');
INSERT INTO categorias (id, descricao) VALUES (2, 'Livros');

INSERT INTO produtos (id, nome, preco, categoria_id) VALUES (101, 'Laptop Gamer', 4500.00, 1);
INSERT INTO produtos (id, nome, preco, categoria_id) VALUES (102, 'O Senhor dos Anéis', 80.00, 2);

-- Consultando dados relacionados usando JOINs (o poder das relações!)
SELECT p.nome AS NomeProduto, p.preco, c.descricao AS Categoria
FROM produtos p
JOIN categorias c ON p.categoria_id = c.id
WHERE p.preco > 100.00;
-- Resultado: Laptop Gamer | 4500.00 | Eletrônicos
-- Demonstra como dados de tabelas diferentes são facilmente combinados.
      

-- 1. Inserir nova categoria:
INSERT INTO categorias (id, descricao) VALUES (3, 'Móveis');

-- 2. Inserir produto associado à nova categoria:
INSERT INTO produtos (id, nome, preco, categoria_id) VALUES (103, 'Cadeira de Escritório', 350.00, 3);

-- 3. Consultar produtos da categoria 'Móveis' com preço > 50:
SELECT p.nome AS Produto, p.preco, c.descricao AS Categoria
FROM produtos p
JOIN categorias c ON p.categoria_id = c.id
WHERE c.descricao = 'Móveis' AND p.preco > 50.00;
-- Resultado: Cadeira de Escritório | 350.00 | Móveis
      

Conceitos do Modelo Orientado a Objetos

O Modelo de Banco de Dados Orientado a Objetos (SGBDOO) surgiu buscando unir a programação orientada a objetos (POO) diretamente com o armazenamento de dados. A ideia era superar a "impedância de mismatch" — a dificuldade de mapear objetos complexos de linguagens de programação para as tabelas relacionais.

Em um SGBDOO, os dados são armazenados como objetos. Esses objetos encapsulam tanto os dados (seus atributos) quanto o comportamento (os métodos ou operações que podem ser realizadas sobre eles). Os principais conceitos incluem:

• Classes e Objetos: Dados são organizados em classes, e cada registro no banco é uma instância (um objeto) dessa classe, assim como na POO.
• Encapsulamento: Atributos e métodos são agrupados dentro do mesmo objeto. Você acessa esses dados e funções por meio de interfaces bem definidas, escondendo os detalhes internos.
• Herança: Permite que classes (e, consequentemente, objetos) herdem propriedades e comportamentos de outras classes, criando hierarquias de dados.
• Polimorfismo: Objetos de diferentes classes podem responder ao mesmo método de maneiras distintas, dependendo de sua própria implementação.
• Complexidade de Objetos: Os SGBDOOs eram ideais para lidar com estruturas de dados muito complexas, como modelos de engenharia (CAD/CAM), sistemas de design de software ou aplicações multimídia, onde as relações internas de um objeto são mais importantes que as relações entre objetos simples.

Apesar de seu poder conceitual para objetos complexos, os SGBDOOs não alcançaram a popularidade dos bancos de dados relacionais. Isso ocorreu devido a desafios de desempenho em larga escala, a falta de uma linguagem de consulta padrão e, ironicamente, a própria evolução dos bancos de dados relacionais, que passaram a suportar tipos de dados mais complexos e recursos aproximados de objetos.

Simulando Conceitos Orientados a Objetos no SQL (PostgreSQL)

Embora não seja um SGBDOO puro, alguns bancos de dados relacionais modernos, como o PostgreSQL, oferecem recursos que simulam o encapsulamento de dados. Podemos usar tipos compostos para agrupar atributos, criando algo similar a um objeto que pode ser usado como tipo de uma coluna, aproximando-se do conceito de encapsulamento.

-- 1. Criando um TIPO COMPOSTO 'endereco' (similar a uma 'classe' de endereço)
CREATE TYPE endereco AS (
  rua VARCHAR(100),
  cidade VARCHAR(50),
  cep VARCHAR(10)
);

-- 2. Criando uma tabela 'usuarios' que usa o tipo 'endereco' como uma COLUNA
CREATE TABLE usuarios (
  id SERIAL PRIMARY KEY,
  nome VARCHAR(100) NOT NULL,
  email VARCHAR(150),
  endereco endereco -- A coluna 'endereco' agora é do nosso tipo composto
);

-- 3. Inserindo dados na tabela 'usuarios', usando o construtor ROW para o tipo composto
INSERT INTO usuarios (nome, email, endereco)
VALUES (
  'João Silva',
  'joao.silva@example.com',
  ROW('Rua da Paz', 'São Paulo', '01000-000')::endereco
);

-- 4. Consultando dados e acessando atributos dentro do tipo composto
SELECT nome, (endereco).cidade AS Cidade, (endereco).rua AS Rua
FROM usuarios
WHERE (endereco).cidade = 'São Paulo';
-- Resultado: João Silva | São Paulo | Rua da Paz
-- Vemos como o SGBD "entende" a estrutura interna do 'objeto' endereço.
      

-- 1. Criando o tipo composto 'contato_info':
CREATE TYPE contato_info AS (
  telefone VARCHAR(20),
  email_contato VARCHAR(100)
);

-- 2. Criando a tabela 'clientes_com_contato':
CREATE TABLE clientes_com_contato (
  id SERIAL PRIMARY KEY,
  nome_cliente VARCHAR(100) NOT NULL,
  contato contato_info -- Usando o tipo composto aqui
);

-- 3. Inserindo um cliente com dados de contato:
INSERT INTO clientes_com_contato (nome_cliente, contato)
VALUES (
  'Maria Eduarda',
  ROW('5511987654321', 'maria.eduarda@email.com')::contato_info
);

-- 4. Consultando o nome e o email de contato:
SELECT nome_cliente, (contato).email_contato AS EmailCliente
FROM clientes_com_contato
WHERE nome_cliente = 'Maria Eduarda';
-- Resultado: Maria Eduarda | maria.eduarda@email.com
      

A Era NoSQL: Novas Respostas para Novos Desafios

A explosão do Big Data, a demanda por escalabilidade horizontal massiva e a necessidade de lidar com dados não estruturados ou semi-estruturados levaram ao surgimento dos bancos de dados NoSQL (Not Only SQL). Eles não são uma substituição, mas uma alternativa poderosa aos SGBDs relacionais para cenários específicos, focando em flexibilidade e desempenho em larga escala.

Os principais motivadores para a adoção do NoSQL incluem:

• Escalabilidade Horizontal: Capacidade de distribuir o banco de dados entre muitos servidores commodity, adicionando mais máquinas para aumentar a capacidade.
• Flexibilidade de Esquema (Schema-less): Não exigem um esquema rígido pré-definido, facilitando a evolução e o gerenciamento de dados com estruturas variadas.
• Desempenho para Grandes Volumes: Otimizados para altas taxas de leitura/escrita e para lidar com grandes volumes de dados.
• Variedade de Dados: Suporte nativo para diferentes tipos de dados (documentos, grafos, chave-valor, etc.).

Principais Categorias de Bancos de Dados NoSQL

Os bancos NoSQL são divididos em categorias, cada uma otimizada para diferentes padrões de dados e necessidades de aplicação:

• 1. Bancos de Documento:

  Armazenam dados em documentos semi-estruturados, geralmente no formato JSON-like (BSON). Cada documento é uma unidade independente, permitindo estruturas flexíveis.

  Casos de Uso: Catálogos de produtos com atributos variáveis, perfis de usuário, sistemas de gerenciamento de conteúdo (CMS).

  Exemplos: MongoDB, Couchbase.

• 2. Bancos Chave-Valor:

  São os mais simples, armazenando dados como pares de "chave" única e "valor" (que pode ser qualquer tipo de dado). Acesso ultrarrápido diretamente pela chave.

  Casos de Uso: Caching de dados, gerenciamento de sessões de usuário, leaderboards, contadores.

  Exemplos: Redis, DynamoDB, Memcached.

• 3. Bancos Colunares (ou de Colunas Largas):

  Organizam os dados em "famílias de colunas", otimizando o armazenamento e o acesso para consultas que leem colunas específicas. Bom para dados que variam muito por linha.

  Casos de Uso: Big Data analytics, séries temporais (dados de IoT, logs), sistemas de mensagens em larga escala.

  Exemplos: Cassandra, HBase, Google Bigtable.

• 4. Bancos de Grafo:

  Representam dados como nós (entidades) e arestas (relacionamentos) que conectam esses nós. Ideais para modelar e consultar relações complexas e interconectadas.

  Casos de Uso: Redes sociais (conexões entre pessoas), sistemas de recomendação, detecção de fraude, análise de redes.

  Exemplos: Neo4j, Amazon Neptune, OrientDB.

-- Exemplo 1: MongoDB (Documento) - Inserindo um produto
db.produtos.insertOne({
  nome: "Laptop Ultrabook",
  preco: 1200,
  fabricante: "TechCorp",
  especificacoes: { cpu: "i7", ram: "16GB", ssd: "512GB" },
  categorias: ["eletrônicos", "computadores", "portáteis"],
  disponivel: true
});
-- Observação: A estrutura pode variar para outros produtos.

-- Exemplo 2: Redis (Chave-Valor) - Gerenciando sessão de usuário
SET usuario:123:nome "João Silva"
SET usuario:123:last_login "2025-07-21T09:30:00Z"
GET usuario:123:nome
-- Resultado: "João Silva"

-- Exemplo 3: Neo4j (Grafo) - Criando relacionamento em uma rede social
CREATE (p1:Pessoa {nome: 'Ana'}),
       (p2:Pessoa {nome: 'Carlos'}),
       (p1)-[:AMIGO_DE]->(p2);
-- Consulta: Quem são os amigos de Ana?
MATCH (ana:Pessoa {nome: 'Ana'})-[:AMIGO_DE]->(amigo) RETURN amigo.nome;
          

Atividade em Duplas: Explorando um Banco NoSQL

Aprofundem seus conhecimentos sobre os bancos de dados NoSQL, essenciais para as arquiteturas modernas. Esta atividade visa explorar a diversidade e a aplicabilidade desses sistemas:

1. Formem duplas.
2. Escolham um dos tipos de banco de dados NoSQL abaixo (ou outro, com aprovação do professor):
   • MongoDB (Documento)
   • Redis (Chave-Valor)
   • Cassandra (Colunar)
   • Neo4j (Grafo)
   • CockroachDB (Considerado um "NewSQL", pode ser interessante para discutir escalabilidade de bancos SQL)
3. Pesquisem e preparem uma breve apresentação (5-7 minutos) para a turma, abordando os seguintes pontos:
   • Características Principais: Como ele armazena dados, qual sua estrutura lógica, e para qual modelo CAP ele se inclina.
   • Casos de Uso Ideais: Para quais tipos de aplicações ele é mais indicado e por quê. Citem exemplos de empresas ou cenários reais que o utilizam.
   • Vantagens e Desvantagens: Em que ele se destaca e quais suas limitações em comparação com outros tipos de bancos de dados.
   • Exemplo de Comando Básico: Mostrem um comando simples de interação (inserção ou consulta) nesse SGBD, como os vistos nos terminais.

-- Exemplo de Roteiro para Apresentação sobre Cassandra (Colunar):
-- 1. Introdução: O que é Cassandra? Um banco de dados de colunas largas NoSQL, distribuído e altamente escalável.
-- 2. Características Principais:
--    - Armazena dados em tabelas com chaves de linha e colunas dinâmicas.
--    - Arquitetura distribuída sem mestre (peer-to-peer).
--    - Alta disponibilidade e tolerância a falhas.
--    - Escala linearmente adicionando mais nós.
--    - Modelo CAP: Prioriza Disponibilidade e Tolerância a Partição (AP).
-- 3. Casos de Uso Ideais:
--    - Sistemas de Big Data e análise em tempo real (dados de IoT, logs).
--    - Mensageria e streaming de dados.
--    - Gerenciamento de dados de usuário em larga escala (ex: histórico de acesso).
--    - Exemplos de empresa: Apple (para serviços de iCloud), Netflix (dados de streaming).
-- 4. Vantagens:
--    - Desempenho excepcional para escrita e leitura de grandes volumes de dados.
--    - Alta disponibilidade e resiliência a falhas de nó.
--    - Facilidade de expansão horizontal.
-- 5. Desvantagens:
--    - Consultas complexas (joins, agregações avançadas) são difíceis ou ineficientes.
--    - Modelo de dados e linguagem (CQL) exigem aprendizado específico.
--    - Consistência eventual padrão (pode não ser adequado para transações financeiras críticas).
-- 6. Exemplo de Comando Básico (CQL):
--    CREATE KEYSPACE meus_logs WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
--    USE meus_logs;
--    CREATE TABLE eventos (id timeuuid PRIMARY KEY, sensor_id text, temperatura float, timestamp_evento timestamp);
--    INSERT INTO eventos (id, sensor_id, temperatura, timestamp_evento) VALUES (now(), 'S001', 25.5, toTimestamp(now()));
--    SELECT * FROM eventos WHERE sensor_id = 'S001' LIMIT 1;
          

Teste de Conhecimento

Responda às perguntas abaixo para consolidar o aprendizado sobre a evolução e tipos de bancos de dados.

RUN db_evolution_check;
-- Quiz finalizado. 
Parabéns por explorar a evolução dos bancos de dados!