🎓 Portal do Curso: GTI (FATEC)

Bem-vindo ao portal oficial de materiais das disciplinas para o curso de Gestão da Tecnologia da Informação (GTI) da FATEC. 🛡️🧩

Este ambiente foi projetado para ser seu guia prático durante o semestre, reunindo toda a teoria, roteiros de laboratório e apresentações em um só lugar de forma estruturada e profissional. 🚀

📚 Disciplinas Disponíveis

💻 GTI - Gestão da Tecnologia da Informação

Foco no ciclo de vida do software, banco de dados, metodologias ágeis e engenharia de requisitos:

🛢️ Banco de Dados e Aplicações
⚙️ Engenharia de Software e Aplicações

🗺️ Como Iniciar?

Navegue pelo menu lateral à esquerda para acessar os módulos de cada disciplina. Cada capítulo contém o conteúdo teórico, diagramas acadêmicos e links para atividades práticas. 🚀

🛠️ Ferramentas Recomendadas (Manto Técnico)

Para um melhor aproveitamento das disciplinas técnicas, reunimos abaixo as principais ferramentas, linguagens e utilitários utilizados no mercado e nas aulas. 🚀

💻 IDEs e Editores de Código

Nome	Versão	Descrição	Link
VS Code	Atual	Editor de código-fonte leve e extensível.	Download
IntelliJ IDEA Community	2023.1	IDE focada em desenvolvimento Java e Kotlin.	Download
PyCharm Community	2023.1	IDE focada em desenvolvimento Python profissional.	Download
Android Studio	2023 (Hedgehog)	IDE oficial para aplicativos Android.	Download
Code::Blocks	20.03	IDE para C/C++ (inclui compilador MinGW).	Download
Notepad++	Atual	Editor de texto avançado e versátil.	Download

🧩 Extensões Essenciais (VS Code)

Para os alunos de GTI, recomendamos as seguintes extensões para melhorar a produtividade:

ESLint: Para padronização de código Javascript.
Prettier: Para formatação automática de código.
Database Client: Para conectar diretamente ao MySQL/PostgreSQL dentro do VS Code.
Draw.io Integration: Para criar diagramas UML diretamente no editor.

💡 Dica do Especialista: Uma boa ferramenta não substitui o conhecimento, mas potencializa o seu trabalho. Domine os atalhos do seu editor favorito! 🚀🛡️

Banco de Dados e Aplicações

📋 Plano de Ensino

Disciplina: Banco de Dados e Aplicações
Carga Horária: 80 horas (Aulas) + 40 horas (Atividades Autônomas)
Curso: Tecnólogo em Gestão da Tecnologia da Informação

🎯 Objetivo

Entender fundamentos e arquitetura de sistemas de bancos de dados bem como técnicas de projeto e implementação de banco de dados com o uso de ferramentas.

📚 Ementa

Sistemas de Arquivos vs. SGBD.
Sistemas de gerenciamento de banco de dados (SGBD): arquitetura e aspectos operacionais.
Aplicações e tecnologias emergentes em Banco de Dados.
Técnicas e ferramentas de gerenciamento de Banco de dados.
Storage.
Controle de concorrência.
Segurança e integridade.
Modelagem de dados a partir do modelo de negócios.
Modelo entidade-relacionamento e suas extensões.
Mapeamento de modelo Entidade-Relacionamento para modelo relacional.
Formas Normais (Normalização).
Linguagem de Manipulação (DML) e de Descrição (DDL) de dados.
Projeto e Implementação de Banco de Dados com ferramentas de produtividade.

📖 Bibliografia Básica

BEIGHLEY, Lynn. Use a Cabeça SQL. Alta Books, 2008.
HEUSER, C.A. Projeto de Banco de Dados. Serie Livros Didáticos, V.4. Bookman, 2009.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. Campus, 2006.

📖 Bibliografia Complementar

MACHADO, Felipe Nery R. Banco de Dados – Projeto e implementação. São Paulo: Érica, 2004.
ELMASRI, R.; NAVATHE, S. B. Sistemas de Banco de Dados: Fundamentos e Aplicações. SP: Pearson, 2005.

🧭 Navegação por Módulos

Introdução e Arquitetura de SGBD
- Cap 01: Introdução e Visão Geral | Cap 02: Fundamentos de SGBDs | Cap 03: Transações ACID, Nuvem e Revisão | Cap 04: Setup Completo (SQL e NoSQL)
Modelagem Conceitual (Entidade-Relacionamento)
- Cap 05: Modelo Relacional e Modelagem | Cap 06: Atributos, Domínios e Tipos | Cap 07: Chaves e Cardinalidade | Cap 08: Extensões do MER e Revisão
Modelagem Relacional e Normalização
- Cap 09: Mapeamento e Álgebra Relacional | Cap 10: Normalização (1FN, 2FN e 3FN)
Linguagem SQL (DDL e DML)
- Cap 11: Ecossistema SQL e DDL | Cap 12: Restrições de Integridade | Cap 13: DML — Inserção e Modificação | Cap 14: Consultas SELECT e Exercícios | Cap 15: JOINs e Subqueries
Administração, Concorrência e Segurança
- Cap 16: Views, Índices e Otimização | Cap 17: Segurança DCL e Evolução
Projeto Prático e Tendências
- Cap 18: NoSQL e MongoDB | Cap 19: Apache Cassandra e Big Data | Cap 20: Estudo de Caso e Conclusão

📚 CAPÍTULO 01: INTRODUÇÃO E VISÃO GERAL

Seja bem-vindo ao módulo de Banco de Dados. Aqui aprenderemos os fundamentos conceituais e a implementação prática de sistemas relacionais modernos. 🛡️🧩

Formar profissionais capazes de modelar, criar, otimizar e administrar bancos de dados relacionais de alta performance, entendendo desde a base teórica até a implementação corporativa no padrão da indústria.

🏢 O Cenário Prático (Seu Desafio)

Imagine que você é o Arquiteto de Dados Júnior da TecProExpress. A empresa estava controlando entregas e clientes usando planilhas soltas do Excel, o que estava gerando duplicações, perda de dados e lentidão.

"O seu desafio é entender os pilares dos bancos de dados profissionais para migrar toda a operação da TecProExpress das planilhas para um Sistema Gerenciador de Banco de Dados (SGBD) robusto e seguro."

🧠 Fundamentos: A Teoria Traduzida

Explore os pilares que sustentam o universo dos dados:

📊 Visão Geral do Banco de Dados

mindmap
    root(("Banco de Dados"))
        Conceitos
            SGBD e ACID
            Big Data & Cloud
            NoSQL
        Modelagem
            ER (Entidade-Relacionamento)
            Modelo Relacional
            Normalização
        Linguagem SQL
            DDL (Estrutura)
            DML (Manipulação)
            Consultas Avançadas
        Estudo de Caso
            TecProExpress
            Persistência Poliglota

🔍 Detalhamento dos Conceitos:

SGBD: "Sistema Gerenciador de Banco de Dados". É o programa que controla os dados (como o MySQL ou PostgreSQL).
ACID: Sigla para Atomicidade, Consistência, Isolamento e Durabilidade. São as regras que impedem que uma transferência bancária seja feita pela metade se acabar a energia.
DDL (Data Definition Language): Comandos que criam o "esqueleto" das tabelas.
DML (Data Manipulation Language): Comandos que inserem ou alteram os dados dentro do esqueleto.

💡 O Manto dos Dados: O banco de dados não é apenas um "depósito", mas a base sólida sobre a qual toda a lógica de negócio de uma empresa é construída. 🛡️

📗 Stack Tecnológica Abordada

Adotamos uma abordagem comparativa (Poliglota) para maximizar sua empregabilidade:

Tecnologia	Ferramenta	Foco Profissional
🐬 MySQL 8.4 LTS	Workbench 8.0	Web (Node.js, PHP, Python).
🐘 PostgreSQL 17	pgAdmin 4 v14	Corporativo e Análise de Dados.
🍃 MongoDB 7.0	Compass v1.4x	Flexibilidade e Dados NoSQL.
⚙️ Apache Cassandra 4.x	Docker / cqlsh	Big Data e Alta Disponibilidade.

📖 Exemplo Guiado: A Diferença Prática (DDL -> DML)

Muitos iniciantes tentam inserir dados diretamente. Em um SGBD, precisamos seguir uma sequência lógica rígida: Primeiro a estrutura (DDL), depois os dados (DML).

🛠️ Código do Exemplo (Criar antes de Inserir)

-- PASSO 1: DDL (Criação da Tabela)
-- O 'CREATE TABLE' levanta as paredes antes de colocar os móveis.
CREATE TABLE cliente (
    id INT PRIMARY KEY,
    nome VARCHAR(100)
);

-- PASSO 2: DML (Inserção dos Dados)
-- O 'INSERT INTO' coloca os dados dentro da estrutura criada.
INSERT INTO cliente (id, nome) VALUES (1, 'TecProExpress');

🔍 Detalhamento do Código:

CREATE TABLE cliente: Instrução DDL que avisa ao banco para reservar um espaço chamado "cliente".
INT PRIMARY KEY: Define que a coluna "id" aceitará apenas números Inteiros e será a identificação única e obrigatória do registro.
VARCHAR(100): Define que a coluna "nome" aceita textos de até 100 caracteres.
INSERT INTO: Instrução DML que empurra os valores "1" e "TecProExpress" para dentro das colunas preparadas.

🛠️ Prática Obrigatória 1: Seu Primeiro Script

Cenário: A TecProExpress precisa de uma tabela para guardar o registro de seus veículos de frota.

Crie a tabela veiculo com as colunas placa (Texto de 7 caracteres) e modelo (Texto de 50 caracteres).
Insira 2 veículos de exemplo.

🚀 Script de Seed (Gabarito)

-- DDL
CREATE TABLE veiculo (
    placa VARCHAR(7) PRIMARY KEY,
    modelo VARCHAR(50)
);

-- DML
INSERT INTO veiculo (placa, modelo) VALUES ('ABC1234', 'Caminhão Mercedes');
INSERT INTO veiculo (placa, modelo) VALUES ('XYZ9876', 'Van Renault');

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos:

Use o operador e para critérios rigorosos e ou para critérios flexíveis. Salve os arquivos com a extensão .sql (Ex: Atividade_XX_SeuNome.sql ou Atividade_XX_SeuNome.png ou Atividade_XX_SeuNome.drawio

💡 Checkpoint de Lógica

[!IMPORTANT] Dica do Especialista: O mercado valoriza o profissional que entende a lógica por trás dos dados, não apenas quem decora comandos. Nunca inverta a ordem: sem DDL (estrutura), seu DML (dados) vai gerar um erro de "Tabela Inexistente". 🚀🛡️

🏗️ CAPÍTULO 02: FUNDAMENTOS DE SGBDS E SISTEMAS DE ARQUIVOS

Seja bem-vindo(a) à base da pirâmide do conhecimento em tecnologia. Nesta unidade, desconstruiremos a forma como as aplicações modernas armazenam e processam seu maior ativo: o Dado. 🛡️🧩

🎯 Objetivo Curricular

Compreender a diferença técnica entre dados e informações, a anatomia de um SGBD moderno e os quatro pilares (Autodescrição, Abstração, Visões e Concorrência) que tornam o modelo relacional indispensável para empresas.

🏢 O Cenário Prático (Seu Desafio)

Imagine que você assumiu como Arquiteto de Banco de Dados na TecProExpress. A empresa atualizou o sistema de rastreamento de entregas, mas o setor de atendimento ainda salva os contatos dos clientes no Excel.

"Seu desafio é demonstrar para a diretoria, de forma técnica e prática, por que manter dados de clientes em planilhas gera inconsistência e por que a TecProExpress deve centralizar tudo no novo SGBD."

🧠 Fundamentos: A Teoria Traduzida

1. O Ciclo de Vida da Informação

Na engenharia de software de alta performance, trabalhamos com ativos que seguem um fluxo de valor:

flowchart TD
    D["📄 DADO<br/>Fato Bruto"] --> P{"⚙️ SGBD<br/>Processamento"}
    P --> I["📊 INFORMAÇÃO<br/>Conhecimento"]
    I --> V["💰 VALOR<br/>Decisão Estratégica"]

🔍 Detalhamento do Fluxo:

DADO: Um fato isolado, por exemplo, o texto "TecProExpress". Sozinho, ele é mudo.
INFORMAÇÃO: O dado contextualizado. "TecProExpress é o nosso cliente VIP de transporte".
BANCO DE DADOS (DB): Uma coleção de dados logicamente relacionados.
SGBD (Sistema Gerenciador): O motor de execução (ex: MySQL 8.4) que processa esses dados em alta velocidade.

2. Por que não usar planilhas?

Característica	Planilhas (Excel) 📁	SGBD Relacional (MySQL/Postgres) 🛡️
Redundância	Alta (nomes repetidos)	Minimizada e controlada
Integridade	Depende de quem digita	Automática com Constraints (`CHECK`, `PK`)
Acesso Simultâneo	Bloqueia o arquivo para outros	Permite milhares de transações ao mesmo tempo

📖 Exemplo Guiado: Protegendo os Dados (DDL -> DML)

A principal vantagem do SGBD é a Integridade. Veja como o SGBD impede erros que uma planilha permitiria. Lembre-se do fluxo obrigatório: primeiro desenhamos a tabela (DDL), depois inserimos o dado (DML).

🛠️ Código do Exemplo

-- PASSO 1: DDL (Criação da Estrutura com Regras)
CREATE TABLE cliente_vip (
    id INT PRIMARY KEY,
    nome VARCHAR(100) NOT NULL,
    limite_credito DECIMAL(10,2) CHECK (limite_credito >= 0)
);

-- PASSO 2: DML (Inserção Válida)
INSERT INTO cliente_vip (id, nome, limite_credito) VALUES (1, 'TecProExpress', 5000.00);

-- PASSO 3: Tentativa de Erro (O SGBD bloqueia!)
-- INSERT INTO cliente_vip (id, nome, limite_credito) VALUES (2, 'Transportadora B', -100.00);

🔍 Detalhamento do Código:

NOT NULL: Regra que impede que um cliente seja salvo sem nome. (No Excel, isso passaria).
CHECK (limite_credito >= 0): Regra matemática. O SGBD recusa qualquer limite de crédito negativo. O Passo 3 falharia de propósito para proteger os dados.

🛠️ Prática Obrigatória: Abstração de Dados

Cenário: O catálogo interno da TecProExpress. Um SGBD guarda a "receita" do banco (Metadados) em um Catálogo interno. Isso permite que diferentes perfis vejam o mesmo dado de formas diferentes.

Crie uma visão (View) simulando o painel de um Gerente, que quer ver os dados de faturamento.
Não se preocupe se errar a sintaxe avançada, foque na estrutura.

🚀 Script de Seed (Gabarito de Visão)

-- PASSO 1: DDL (Criar Tabela Mestre)
CREATE TABLE faturamento (
    id INT PRIMARY KEY,
    filial VARCHAR(50),
    lucro_total DECIMAL(15,2)
);

-- PASSO 2: DML (Popular)
INSERT INTO faturamento VALUES (101, 'São Paulo', 250000.00);
INSERT INTO faturamento VALUES (102, 'Rio de Janeiro', 180000.00);

-- PASSO 3: DDL (Criar a VIEW - Visão do Usuário)
CREATE VIEW relatorio_gerente AS
SELECT filial, lucro_total FROM faturamento WHERE lucro_total > 200000;

🔍 Detalhamento do Seed:

CREATE VIEW: Cria um "atalho" ou "lente virtual" que filtra os dados originais. O Gerente só verá a filial de São Paulo.

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Qual a diferença entre um DB (Database) e um DBMS (Sistema Gerenciador de Banco de Dados)? O DB é o arquivo salvo no disco rígido. O DBMS é o software (MySQL, Postgres) que você usa para conversar com esse arquivo e garantir a segurança dele de forma simultânea. 🧠🛡️

🔐 CAPÍTULO 03: TRANSAÇÕES ACID E ECOSSISTEMA CLOUD

No coração de sistemas críticos (Bancos, Hospitais, Logística), existe o conceito de Transação. Uma transação não é apenas um comando SQL solto, mas uma Unidade Lógica de Trabalho indestrutível. 🛡️🧩

🎯 Objetivo Curricular

Dominar os pilares ACID e o controle transacional (TCL) que garantem a integridade dos dados em cenários de alta concorrência. Além disso, entender os modelos de nuvem (IaaS, PaaS, SaaS) na era moderna.

🏢 O Cenário Prático (Seu Desafio)

Você atua na TecProExpress. Imagine que o sistema debita R$ 1.500 do saldo de um cliente para pagar um frete internacional, mas antes do sistema creditar esse valor na conta da TecProExpress, o servidor de banco de dados sofre uma queda de energia.

"Seu desafio é arquitetar o banco de dados para garantir que, caso o fluxo inteiro não se complete, o dinheiro volte imediatamente para a conta do cliente (Rollback). Nenhum centavo pode desaparecer do sistema."

🧠 Fundamentos: O Escudo de Confiança (ACID)

Para garantir que o seu banco nunca entre em um estado corrupto, o SGBD aplica as propriedades ACID:

⚛️ Atomicidade (Tudo ou Nada): Se uma transação tem 10 passos e o passo 9 falha, os 8 anteriores são desfeitos automaticamente.
⚖️ Consistência (Regras): A transação leva o banco de um estado válido para outro estado válido (ex: o saldo nunca ficará negativo se houver um CHECK >= 0).
🔒 Isolamento (Invisibilidade): Se o operador A e o operador B estiverem alterando o estoque ao mesmo tempo, um não enxerga os dados parciais do outro.
💾 Durabilidade (Permanência): Após o comando COMMIT, o dado está salvo no disco permanentemente. Nem mesmo um apagão remove o dado.

📊 Fluxo da Transação (TCL)

flowchart TD
    START["▶️ BEGIN TRANSACTION"] --> OP1["📝 UPDATE: Debitar Saldo Cliente"]
    OP1 --> OP2["📝 UPDATE: Creditar Conta TecProExpress"]
    OP2 --> DEC{"❓ Sucesso Total?"}
    DEC -- SIM --> COM["✅ COMMIT: Salva no Disco"]
    DEC -- NÃO --> ROL["❌ ROLLBACK: Desfaz Tudo"]
    COM --> END["🏁 Fim da Transação"]
    ROL --> END

🔍 Detalhamento do Fluxo:

BEGIN TRANSACTION: Avisa ao banco que uma sequência de operações críticas começou.
COMMIT: A confirmação de que tudo deu certo.
ROLLBACK: O botão de "Pânico" ou "Ctrl+Z" que cancela todas as ações pendentes.

📖 Exemplo Guiado: Transações Seguras

Vamos simular o cenário da TecProExpress no banco de dados. Seguindo nossa regra de excelência: primeiro DDL, depois DML.

🛠️ Código do Exemplo

-- PASSO 1: DDL (Criar a conta corrente)
CREATE TABLE conta_corrente (
    id INT PRIMARY KEY,
    titular VARCHAR(100),
    saldo DECIMAL(10,2) CHECK (saldo >= 0)
);

-- PASSO 2: DML (Carga Inicial)
INSERT INTO conta_corrente VALUES (1, 'Cliente João', 2000.00);
INSERT INTO conta_corrente VALUES (2, 'TecProExpress', 0.00);

-- PASSO 3: O Fluxo Transacional (TCL + DML)
START TRANSACTION;
  -- Retira do Cliente
  UPDATE conta_corrente SET saldo = saldo - 1500.00 WHERE id = 1;
  -- Credita na Empresa
  UPDATE conta_corrente SET saldo = saldo + 1500.00 WHERE id = 2;
COMMIT;

🔍 Detalhamento do Código:

START TRANSACTION: Inicia a unidade lógica.
UPDATE: Altera os dados. O valor só será efetivado no banco de dados quando o COMMIT for lido e executado pelo sistema.

☁️ A Era da Nuvem (Cloud Databases)

Atualmente, não instalamos mais servidores físicos em salas geladas. Utilizamos a Cloud Computing para hospedar nossos SGBDs.

📊 Modelos de Nuvem

flowchart LR
    U1["👤 Usuário Final"]
    U2["🛠️ Dev / DBA"]
    U3["⚙️ SysAdmin / Infra"]
    
    subgraph Cloud ["Modelos de Serviços Cloud"]
    UC1(("SaaS: App Pronto"))
    UC2(("PaaS: DBaaS"))
    UC3(("IaaS: Infra Bruta"))
    end
    
    U1 --> UC1
    U2 --> UC2
    U3 --> UC3

🔍 Detalhamento dos Modelos:

IaaS (Infraestrutura como Serviço): Você aluga a máquina e tem que instalar o banco. Controle total, mas requer gestão manual.
PaaS (Plataforma como Serviço - Foco do DBA): O provedor (AWS, Azure) te entrega o banco pronto para conectar (DBaaS). Eles cuidam da atualização e do hardware.
SaaS (Software como Serviço): O usuário apenas usa o sistema (Ex: Netflix, Gmail).

🛠️ Prática Obrigatória: O Botão de Pânico

Cenário: Simular um erro transacional para a TecProExpress.

Crie a tabela e os inserts da Prática Guiada acima.
Inicie uma nova transação (START TRANSACTION).
Tente transferir 3000.00 do Cliente João (que só tem 500 restantes). O banco dará um erro devido ao CHECK.
Execute ROLLBACK;.

🏁 Resultado Esperado

Ao executar um SELECT * FROM conta_corrente, o saldo do Cliente João não deve ter sido negativado, comprovando que a transação bloqueou o estado inconsistente.

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Qual é a grande vantagem da nuvem em termos de transações financeiras? O DBaaS (Database as a Service) moderno oferece backups automáticos diários. Se um Rollback falhar por erro catastrófico, o provedor da nuvem pode restaurar o banco exatamente para 1 minuto antes do acidente. 🧠🛡️

⚙️ CAPÍTULO 04: SETUP POLIGLOTA E CONEXÕES

Bem-vindo à preparação do seu ambiente. A engenharia de plataformas modernas exige o domínio de diferentes ecossistemas. Você aprenderá a configurar um ambiente Poliglota, suportando tabelas e documentos. 🛡️🧩

🎯 Objetivo Curricular

Configurar e validar a conectividade local de bancos de dados relacionais (MySQL 8.4 e PostgreSQL 17) e bancos NoSQL (MongoDB e Cassandra). Compreender o papel das portas, serviços e variáveis de ambiente no ecossistema.

🏢 O Cenário Prático (Seu Desafio)

Você lidera a nova célula de Engenharia de Dados da TecProExpress. A equipe de backend desenvolveu um novo painel administrativo, mas eles não conseguem se conectar ao banco de dados porque as portas estão bloqueadas ou os serviços não foram iniciados.

"Seu desafio é criar um laboratório local na sua máquina, garantindo que o PostgreSQL (Relacional) e o MongoDB (NoSQL) rodem simultaneamente em portas diferentes, sem conflitos, provando a saúde do ambiente com testes DDL/DML."

🧠 Fundamentos: Anatomia de um Serviço

Quando instalamos um banco de dados, não instalamos apenas uma "pasta de arquivos". Instalamos um Serviço (Daemon/Background Worker) que fica ouvindo por chamadas.

📊 Comunicação Cliente-Servidor

flowchart LR
    C1["👤 Desenvolvedor<br/>(DBeaver / Compass)"] --> P{"Porta Lógica"}
    P -- 5432 --> S1[("🐘 PostgreSQL Server")]
    P -- 27017 --> S2[("🍃 MongoDB Server")]
    
    style P fill:#ffcc80,stroke:#e65100

🔍 Detalhamento das Conexões:

Localhost (127.0.0.1): Endereço que aponta para a sua própria máquina.
Porta (Port): O "guichê" de atendimento. Cada banco tem uma porta padrão. Se dois bancos tentarem usar a mesma porta, o serviço cai.

🐘 SETUP RELACIONAL: PostgreSQL e MySQL

1. Download e Instalação

Para SGBDs relacionais pesados, usamos versões nativas LTS (Long Term Support).

PostgreSQL 17: Acesse o portal da EnterpriseDB. A porta padrão é a 5432.
MySQL 8.4: Acesse o MySQL Installer. A porta padrão é a 3306.

[!IMPORTANT] A Senha Mestra: Durante a instalação, você criará a senha para os superusuários (postgres ou root). O banco de dados é implacável: se você perder essa senha, terá que reinstalar todo o sistema e perderá os dados. Anote em local seguro!

🍃 SETUP NOSQL: MongoDB e Cassandra

1. MongoDB (Documentos Flexíveis)

Para dados não estruturados, como os logs das entregas da TecProExpress.

Servidor: Baixe o MongoDB Community Server 7.0+. Porta padrão: 27017.
Cliente: A instalação já traz o MongoDB Compass, que é a interface gráfica (IDE).

2. Apache Cassandra (Big Data via Docker)

Para lidar com bilhões de registros (ex: dados de GPS dos caminhões), usamos o Cassandra. Para evitar configurar a máquina virtual Java (JVM) na sua máquina, usaremos Docker.

-- Passo 1: Baixar e rodar a imagem do Cassandra pelo terminal
docker run --name cassandra-tecpro -p 9042:9042 -d cassandra

📖 Exemplo Guiado: Validando o Setup (DDL -> DML)

A melhor forma de testar se a instalação do PostgreSQL ou MySQL funcionou é criar e povoar uma tabela de testes.

🛠️ Código de Validação

Abra o pgAdmin 4 (ou DBeaver), crie um banco de dados chamado teste_db e execute o script abaixo:

-- PASSO 1: DDL (Criar a estrutura de testes)
CREATE TABLE validacao_ambiente (
    id INT PRIMARY KEY,
    status_servidor VARCHAR(50)
);

-- PASSO 2: DML (Inserir os dados de teste)
INSERT INTO validacao_ambiente (id, status_servidor) VALUES (1, 'Setup Relacional Ativo na TecProExpress!');

-- PASSO 3: Query (Verificar a inserção)
SELECT * FROM validacao_ambiente;

🔍 Detalhamento do Teste:

O sucesso na execução deste bloco inteiro garante que a instalação do serviço e a permissão do usuário postgres estão perfeitamente saudáveis.

🛠️ Prática Obrigatória: Conectando a Nave-Mãe

Cenário: O ambiente de testes locais.

Garanta que o Postgres (5432) e o Mongo (27017) estão ativos nos serviços do Windows/Mac.
Abra a interface (pgAdmin/Compass).
Crie as conexões.
No MongoDB Compass, crie uma base de dados (Database) chamada tecpro_nosql e uma coleção chamada teste_conexao. Insira um documento qualquer em JSON para validar.

🏁 Resultado Esperado

Duas janelas verdes na sua máquina atestando que os motores relacional e documental operam simultaneamente sem choque de recursos.

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!TIP] Dica do Especialista: Quando você rodar o Cassandra via Docker, a bandeira -d (detach) no comando permite que o terminal fique livre enquanto o banco roda silenciosamente nos bastidores. A conteinerização é o futuro da arquitetura de dados! 🚀🛡️

📐 CAPÍTULO 05: MODELO RELACIONAL E INTRODUÇÃO À MODELAGEM

O "coração" da engenharia de dados moderna é baseado na matemática. Criado na década de 70 por Edgar F. Codd (cientista da IBM), o Modelo Relacional revolucionou o mundo ao organizar informações de forma previsível e segura. 🛡️🧩

🎯 Objetivo Curricular

Dominar a nomenclatura corporativa (Relação, Tupla, Atributo, Domínio) e compreender o ciclo de abstração da modelagem de dados, passando do mundo real para o Modelo Entidade-Relacionamento (MER).

🏢 O Cenário Prático (Seu Desafio)

Você assumiu a área de Arquitetura de Dados da TecProExpress. A equipe de negócios enviou um documento textual gigante descrevendo como eles querem que o sistema funcione. Os programadores não sabem por onde começar a codificar as tabelas.

"Seu desafio é ser a ponte de comunicação. Você precisa traduzir as necessidades do negócio (Mundo Real) em um diagrama visual (Mini-mundo) e depois em código SQL estruturado."

🧠 Fundamentos: O Dicionário Relacional

No mercado profissional, evitamos termos amadores. Um Arquiteto de Elite domina a nomenclatura técnica.

Nome Comercial	Nomenclatura Científica	O que representa na prática?
Tabela	Relação	Estrutura que guarda entidades (ex: `cliente`).
Linha / Registro	Tupla	Uma ocorrência específica (ex: O cliente João).
Coluna / Campo	Atributo	Propriedade (ex: `nome`, `cpf`).
Tipo de Dado	Domínio	Regras de formato permitidas (ex: `INT`, `VARCHAR`).

📊 Anatomia de uma Tabela (Relação)

erDiagram
    PRODUTO {
        int id_produto PK
        string nome
        decimal preco
    }

🔍 Detalhamento das Regras de Ouro:

Atomicidade: Cada célula deve conter apenas um único valor indivisível. (Nada de guardar dois telefones na mesma coluna).
Unicidade: Não existem linhas 100% iguais (garantido pela PK - Primary Key).
O Valor NULL: Representa ausência de informação. Atenção: NULL não é zero e nem um texto vazio ("").

📖 Exemplo Guiado: Criando o Dicionário (DDL -> DML)

A melhor forma de entender os domínios é aplicando restrições no código.

🛠️ Código do Exemplo

-- PASSO 1: DDL (Definindo Relação, Atributos e Domínios)
CREATE TABLE fornecedor (
    id INT PRIMARY KEY,
    nome VARCHAR(100) NOT NULL,
    status_ativo BOOLEAN
);

-- PASSO 2: DML (Inserindo Tuplas)
INSERT INTO fornecedor (id, nome, status_ativo) VALUES (1, 'TecProExpress', TRUE);
INSERT INTO fornecedor (id, nome, status_ativo) VALUES (2, 'Fornecedor Beta', NULL);

🔍 Detalhamento do Código:

VARCHAR(100): O domínio restringe o tamanho do atributo "nome" a 100 letras.
NULL: O segundo INSERT usa NULL porque ainda não sabemos o status do Fornecedor Beta.

📐 O Ciclo de Vida da Modelagem

O processo de traduzir o mundo real para tabelas ocorre em 3 fases:

🧠 Modelo Conceitual: Foca na regra de negócio. Desenho em alto nível (Diagrama Entidade-Relacionamento - DER) que o cliente consegue entender.
⚙️ Modelo Lógico: Traduz o diagrama para tabelas (com PKs e FKs), mas ainda sem código específico.
💻 Modelo Físico: O script de criação (SQL DDL) que roda dentro do SGBD (MySQL/Postgres).

📊 O Fluxo de Abstração

flowchart TD
    REAL["🌍 Mundo Real"] --> ABS{"🔍 Abstração"}
    ABS --> MINI["🗺️ Modelo Conceitual"]
    MINI --> LOG["📐 Modelo Lógico"]
    LOG --> FIS["💻 Modelo Físico (SQL)"]

🛠️ Prática Obrigatória: Abstração Inicial

Cenário: A TecProExpress quer modelar seus veículos de frota.

Identifique as Entidades e Atributos para um veículo.
Crie a tabela veiculo_frota usando DDL e insira uma tupla usando DML.

🚀 Script de Seed (Gabarito Físico)

-- DDL
CREATE TABLE veiculo_frota (
    id_veiculo INT PRIMARY KEY,
    placa VARCHAR(7) NOT NULL,
    capacidade_carga_kg DECIMAL(10,2)
);

-- DML
INSERT INTO veiculo_frota (id_veiculo, placa, capacidade_carga_kg) VALUES (101, 'ABC1234', 5000.00);

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Por que a Modelagem Conceitual é considerada a fase mais crítica de um projeto de software? (Resposta: Porque código SQL mal feito pode ser reescrito rapidamente, mas se a equipe entender a regra de negócio errado no Modelo Conceitual, todo o sistema será construído para resolver o problema errado). 🧠🛡️

🧬 CAPÍTULO 06: ANATOMIA DE ATRIBUTOS, DOMÍNIOS E TIPOS

No Modelo Relacional, a organização da informação é cirúrgica. Para que um banco de dados seja escalável e performático (como no MySQL 8.4 ou PostgreSQL 17), precisamos entender como cada "pedaço" de dado se encaixa na estrutura. 🛡️🧩

🎯 Objetivo Curricular

Compreender a estrutura interna dos dados através da definição técnica de atributos, tuplas e o papel vital da Chave Primária (PK). Comparar os tipos de dados entre os SGBDs e dominar o uso de autoincremento e campos híbridos.

🏢 O Cenário Prático (Seu Desafio)

Você atua na TecProExpress. O setor de desenvolvimento reclamou que os IDs dos novos pacotes estão colidindo e gerando erros nas aplicações. Além disso, eles precisam de uma forma de salvar "detalhes técnicos variáveis" de eletrônicos (voltagem, cor, garantia) que mudam para cada produto, tudo sem criar mil colunas vazias.

"Seu desafio é dominar a engenharia de chaves primárias (Autoincrement/Identity) e explorar como armazenar flexibilidade no modelo relacional usando campos JSON nativos."

🧠 Fundamentos: Anatomia de um Registro

1. O Atributo (Campo)

Um Atributo é a menor unidade de informação. Ele precisa seguir as regras do seu Domínio:

Atomicidade: O valor deve ser indivisível (ex: separar a Rua do Bairro em vez de criar um "Endereço Completo").
Tipo de Dado: INT, VARCHAR, DATE (Limita o que o usuário pode preencher).

2. A Chave Primária (PK)

Nenhuma tabela profissional existe sem uma Chave Primária. Ela é o DNA da tupla, garantindo a integridade dos registros.

🔍 As Duas Leis da PK:

Unicidade: O valor nunca se repete.
Obrigatoriedade: O campo da PK é sempre NOT NULL (Não pode ser vazio).

📖 Exemplo Guiado: Autoincremento Poliglota (DDL -> DML)

A solução para o problema de IDs colidindo na TecProExpress é deixar o próprio SGBD gerenciar a numeração automática das chaves primárias.

Muitos iniciantes não sabem que a sintaxe muda radicalmente entre os bancos.

🛠️ Código no MySQL 8.4 LTS

-- DDL
CREATE TABLE pacotes_mysql (
    id INT PRIMARY KEY AUTO_INCREMENT,
    destino VARCHAR(100)
);

-- DML (O ID é gerado sozinho)
INSERT INTO pacotes_mysql (destino) VALUES ('São Paulo');

🛠️ Código no PostgreSQL 17

-- DDL
CREATE TABLE pacotes_postgres (
    id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    destino VARCHAR(100)
);

-- DML
INSERT INTO pacotes_postgres (destino) VALUES ('Rio de Janeiro');

🔍 Detalhamento do Código:

AUTO_INCREMENT vs GENERATED ALWAYS AS IDENTITY: É essencial dominar ambos para atuar no mercado poliglota.
Note que, no INSERT, omitimos a coluna id de propósito, pois o SGBD é o responsável pela geração.

📐 Tipos de Dados e Restrições de Domínio

1. Power Tools de Domínio

Além dos tipos básicos (Texto, Número, Data), adicionamos inteligência com restrições (Constraints):

NOT NULL: Preenchimento obrigatório.
UNIQUE: Valor não repetido, mas permite NULL (ex: E-mail de marketing secundário).
CHECK: Valida lógicas (ex: CHECK (preco > 0)).

2. JSON vs JSONB (Arquitetura Híbrida)

A resposta para a TecProExpress armazenar "detalhes técnicos variáveis" sem criar mil colunas é utilizar o poder dos SGBDs modernos que suportam Documentos JSON dentro do modelo relacional:

MySQL JSON: Armazena e valida o texto estruturado.
Postgres JSONB: Armazena em binário indexado. É incrivelmente rápido para filtros internos.

🛠️ Prática Obrigatória: Carga Híbrida

Cenário: A tabela de produtos avançados da TecProExpress.

Crie a tabela produto_hibrido com uma PK autoincremental e uma coluna chamada especificacoes do tipo JSON.
Insira 2 produtos com detalhes estruturais completamente diferentes usando DML.

🚀 Script de Seed (Gabarito)

-- DDL (Sintaxe MySQL)
CREATE TABLE produto_hibrido (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(100) NOT NULL,
    especificacoes JSON
);

-- DML
INSERT INTO produto_hibrido (nome, especificacoes) 
VALUES ('Notebook Gamer', '{"cpu": "i7", "ram": "16GB"}');

INSERT INTO produto_hibrido (nome, especificacoes) 
VALUES ('Cabo HDMI', '{"tamanho_metros": 2, "cor": "preto", "banhado_ouro": true}');

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!TIP] Dica do Arquiteto: Evite usar BIGINT para tudo. No MySQL, se um campo nunca passará de 255 valores (ex: status de um pedido, idade), use TINYINT. Economia de espaço é sinônimo de performance em larga escala! 🚀🛡️

🔗 CAPÍTULO 07: CHAVES, RELACIONAMENTOS E CARDINALIDADE

A grande força de um banco de dados Relacional está no seu próprio nome: Relacionamentos. Neste capítulo, vamos entender como tabelas isoladas se conectam para formar um ecossistema inteligente, capaz de responder perguntas de negócios complexas. 🛡️🧩

🎯 Objetivo Curricular

Dominar o uso de Chaves Estrangeiras (Foreign Keys - FK) para implementar relacionamentos. Compreender e mapear as cardinalidades 1:1, 1:N e N:M no modelo físico.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, o RH solicitou um sistema para controlar quais motoristas estão utilizando quais caminhões. Além disso, eles precisam de um sistema de entregas, onde um cliente pode ter vários pacotes. Os estagiários de TI desenharam tabelas, mas não conseguiram "conectá-las".

"Seu desafio é ser o Engenheiro de Integração: usar Chaves Estrangeiras para garantir que nenhum pacote seja registrado sem um cliente responsável, dominando as cardinalidades 1:N e N:M."

🧠 Fundamentos: O Fio Condutor (FK)

A Chave Estrangeira (FK) é o mecanismo de vínculo. Ela é literalmente o valor da Chave Primária (PK) de uma tabela, copiado para dentro de outra tabela.

📊 Diagrama de Cardinalidade (Crow's Foot)

Existem 3 tipos básicos de relacionamentos, representados pela notação "Pé de Galinha":

erDiagram
    CLIENTE ||--o{ PACOTE : "possui (1:N)"
    MOTORISTA |o--o| CAMINHAO : "dirige (1:1)"
    ENTREGADOR }|--|{ ROTA : "atua (N:M)"

🔍 Detalhamento Visual:

||: Indica que a participação é obrigatória (ex: Mínimo 1).
o{: Indica "Zero ou Muitos". Um cliente pode acabar de se cadastrar e ainda não ter pacotes (zero), ou pode ter dezenas (muitos).

📐 O Guia de Ouro da Cardinalidade

Onde eu coloco a Chave Estrangeira? Esta é a pergunta que mais derruba candidatos em entrevistas.

Cardinalidade	Analogia	Onde colocar a FK?
1:1 (Um para Um)	Casamento exclusivo	Em qualquer lado (prefira a tabela dependente).
1:N (Um para Muitos)	Pai e Filhos	Sempre no lado N. (O pacote recebe o ID do Cliente).
N:M (Muitos para Muitos)	Atores e Filmes	Cria uma Terceira Tabela! (Associativa).

📖 Exemplo Guiado: O Relacionamento 1:N (Pai e Filho)

A TecProExpress quer vincular um cliente aos seus pacotes. Veja como aplicar isso no SQL garantindo a ordem correta (DDL -> DML).

🛠️ Código do Exemplo

-- PASSO 1: DDL (Criar a tabela PAI primeiro)
CREATE TABLE cliente_exp (
    id INT PRIMARY KEY,
    nome VARCHAR(100)
);

-- PASSO 2: DDL (Criar a tabela FILHO com a Chave Estrangeira)
CREATE TABLE pacote (
    codigo INT PRIMARY KEY,
    descricao VARCHAR(100),
    id_cliente INT, -- A coluna que receberá o link
    CONSTRAINT fk_cliente_pacote FOREIGN KEY (id_cliente) REFERENCES cliente_exp(id)
);

-- PASSO 3: DML (Inserir Pai, depois Filho)
INSERT INTO cliente_exp VALUES (10, 'Maria Silva');
INSERT INTO pacote VALUES (5001, 'Notebook', 10);

🔍 Detalhamento do Código:

A Regra da Ordem: Você não pode nascer sem ter pais. No SGBD, você não pode inserir um pacote apontando para o cliente 10 se o cliente 10 ainda não foi cadastrado (INSERT).
FOREIGN KEY: Avisa o SGBD para vigiar esta coluna. Se alguém tentar deletar a Maria Silva, o banco bloqueará, avisando que existem pacotes vinculados a ela.

🛠️ Prática Obrigatória: Resolvendo o Caos do N:M

Cenário: O sistema de Entregadores e Rotas da TecProExpress. Um Entregador pode atuar em Várias Rotas. Uma Rota pode ser feita por Vários Entregadores.

Crie as tabelas independentes entregador e rota.
Crie a tabela associativa escala_trabalho contendo a chave estrangeira de ambos.
Insira dados provando a vinculação.

🚀 Script de Seed (Gabarito de Associação)

-- DDL PAI 1
CREATE TABLE entregador ( id INT PRIMARY KEY, nome VARCHAR(50) );
-- DDL PAI 2
CREATE TABLE rota ( id INT PRIMARY KEY, regiao VARCHAR(50) );

-- DDL FILHO ASSOCIATIVO (A ponte entre os dois)
CREATE TABLE escala_trabalho (
    id_entregador INT,
    id_rota INT,
    PRIMARY KEY (id_entregador, id_rota), -- Chave Composta
    FOREIGN KEY (id_entregador) REFERENCES entregador(id),
    FOREIGN KEY (id_rota) REFERENCES rota(id)
);

-- DML (Carregando a base)
INSERT INTO entregador VALUES (1, 'Carlos'), (2, 'Ana');
INSERT INTO rota VALUES (100, 'Centro'), (200, 'Litoral');

-- DML (O Relacionamento N:M na prática)
INSERT INTO escala_trabalho VALUES (1, 100); -- Carlos atende o Centro
INSERT INTO escala_trabalho VALUES (1, 200); -- Carlos atende o Litoral
INSERT INTO escala_trabalho VALUES (2, 100); -- Ana também atende o Centro

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Em um relacionamento Muitos para Muitos (N:M), por que a Tabela Associativa (escala_trabalho) tem uma PRIMARY KEY composta pelos dois IDs? (Resposta: Para garantir que o mesmo entregador não seja escalado duas vezes exatamente para a mesma rota no mesmo turno). 🧠🛡️

🧭 CAPÍTULO 08: EXTENSÕES DO MER E REVISÃO DA MODELAGEM

Até agora, lidamos com objetos simples (Clientes, Produtos, Pedidos). Mas a vida real não é apenas "Pai e Filho". Como mapeamos um "Dependente" que só existe se o titular existir? Como mapeamos a herança de características? Hoje vamos ver as Extensões do MER. 🛡️🧩

🎯 Objetivo Curricular

Dominar a modelagem avançada resolvendo problemas de Entidades Fracas, Generalização/Especialização (Herança) e consolidar os fundamentos preparatórios para a Normalização.

🏢 O Cenário Prático (Seu Desafio)

O RH da TecProExpress solicitou que o banco de dados armazene os Dependentes (filhos) de cada funcionário para o plano de saúde. Além disso, a empresa agora possui uma frota mista: Caminhões (que têm capacidade de carga) e Motos (que têm cilindrada), mas ambos são Veículos.

"Seu desafio é elevar o nível da sua arquitetura, aplicando os conceitos de 'Entidade Fraca' para os dependentes e 'Herança' para a frota, garantindo que o banco de dados seja escalável e evite colunas com valores NULL desnecessários."

🧠 Fundamentos: Modelagem Avançada

1. Entidade Fraca (Dependência Existencial)

Uma Entidade Fraca não tem vida própria. O "Filho do João" só está no plano de saúde porque o João é funcionário. Se João for demitido (deletado), o dependente deve desaparecer do banco também.

No SQL, garantimos isso usando a restrição ON DELETE CASCADE na Chave Estrangeira.

2. Generalização e Especialização (Herança)

Assim como na Programação Orientada a Objetos (POO), no banco de dados podemos ter uma tabela "Pai" Genérica e tabelas "Filhas" Específicas.

📊 Diagrama de Herança (IS-A)

flowchart TD
    VEI["🚙 VEÍCULO <br/> ID, Placa, Ano"] -->|Especialização| CAM["🚛 CAMINHÃO <br/> Cap_Carga"]
    VEI -->|Especialização| MOT["🏍️ MOTO <br/> Cilindradas"]
    
    style VEI fill:#e3f2fd
    style CAM fill:#fffde7
    style MOT fill:#fffde7

Vantagem: Evita colocar "Capacidade_Carga" e "Cilindradas" na mesma tabela, o que faria as Motos terem a coluna de carga como NULL (desperdício de espaço e lógica).

📖 Exemplo Guiado: Criando uma Entidade Fraca (DDL -> DML)

Veja como modelar a dependência forte no PostgreSQL ou MySQL para a TecProExpress.

🛠️ Código do Exemplo

-- PASSO 1: DDL (A Entidade Forte / Titular)
CREATE TABLE funcionario (
    id INT PRIMARY KEY,
    nome VARCHAR(100)
);

-- PASSO 2: DDL (A Entidade Fraca / Dependente)
CREATE TABLE dependente (
    id_func INT,
    nome_dep VARCHAR(100),
    data_nasc DATE,
    PRIMARY KEY (id_func, nome_dep), -- Chave Composta!
    CONSTRAINT fk_titular FOREIGN KEY (id_func) 
        REFERENCES funcionario(id) 
        ON DELETE CASCADE -- A mágica acontece aqui!
);

-- PASSO 3: DML (Carga Inicial)
INSERT INTO funcionario VALUES (10, 'Carlos Oliveira');
INSERT INTO dependente VALUES (10, 'Pedrinho', '2015-05-10');

🔍 Detalhamento do Código:

Chave Composta: A PK do dependente é a junção do ID do funcionário + o nome do dependente.
ON DELETE CASCADE: Se rodarmos DELETE FROM funcionario WHERE id = 10;, o banco de dados, sozinho, vai deletar o "Pedrinho" da tabela dependente. Integridade automática!

🛠️ Prática Obrigatória: Implementando a Frota (Herança)

Cenário: A frota mista da TecProExpress.

Crie a tabela genérica veiculo (Pai).
Crie as tabelas filhas caminhao e moto.
Faça com que a Chave Primária das filhas também seja a Chave Estrangeira que aponta para o Pai.

🚀 Script de Seed (Gabarito Físico)

-- DDL Genérico (Pai)
CREATE TABLE veiculo (
    id INT PRIMARY KEY,
    placa VARCHAR(7) UNIQUE,
    ano INT
);

-- DDL Específico (Caminhão)
CREATE TABLE caminhao (
    id_veiculo INT PRIMARY KEY, -- PK e FK ao mesmo tempo!
    capacidade_toneladas INT,
    FOREIGN KEY (id_veiculo) REFERENCES veiculo(id)
);

-- DML (Inserindo a Herança)
-- Passo A: Insere na tabela Pai
INSERT INTO veiculo VALUES (1, 'AAA1234', 2026);
-- Passo B: Complementa na tabela Filha
INSERT INTO caminhao VALUES (1, 15);

🔍 O Segredo da Abstração

No DML acima, o veículo ID 1 existe em duas partes: os dados gerais estão no Pai, e os dados específicos estão no Caminhão. Na hora do relatório, usaremos um JOIN para juntar as duas metades.

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!IMPORTANT] Revisão Estratégica: Chegamos ao fim da modelagem pura. Você aprendeu a criar Entidades, ligar Relacionamentos (1:N, N:M), lidar com Dependências e Herança. O próximo passo será refinar tudo isso com a "Normalização", a vacina contra as redundâncias. O seu raciocínio estrutural está preparado? 🧠🛡️

🧮 CAPÍTULO 09: MAPEAMENTO MER-RELACIONAL E ÁLGEBRA

Chegamos à fase final do design de banco de dados. Você já tem um Diagrama Entidade-Relacionamento (DER) validado com o cliente. Agora, você precisa "traduzir" esse desenho para a estrutura física (Tabelas, Chaves) que o SGBD entende. Além disso, vamos espiar o motor matemático que faz o SQL ser tão rápido: a Álgebra Relacional. 🛡️🧩

🎯 Objetivo Curricular

Executar o roteiro de mapeamento lógico (MER para Relacional) sem perda de semântica e compreender os operadores algébricos (Seleção, Projeção, Junção) que fundamentam as consultas corporativas.

🏢 O Cenário Prático (Seu Desafio)

Os diretores da TecProExpress aprovaram no quadro branco o diagrama de como a empresa funciona: "O Cliente faz um Pedido, que é entregue por um Motorista usando um Veículo".

"Seu desafio é pegar esse desenho (MER) e transformá-lo em tabelas reais usando regras estritas de mapeamento para que a equipe de desenvolvimento possa finalmente conectar a aplicação ao SGBD."

🧠 Fundamentos: O Roteiro de Mapeamento (MER -> Lógico)

A tradução de um diagrama para tabelas segue um roteiro matemático. Você não pode adivinhar o resultado; deve aplicar a regra:

Componente no MER (Mundo Abstrato)	O que vira no Relacional (Tabelas)
Entidade Forte	Vira uma Tabela independente (com PK).
Atributo Simples	Vira uma Coluna na tabela.
Relacionamento 1:N	A PK do lado 1 vira FK no lado N.
Relacionamento N:M	Vira uma Tabela Associativa (composta pelas duas FKs).
Atributo Multivalorado	Vira uma Nova Tabela atrelada à original (Ex: Telefones).

📖 Exemplo Guiado: Mapeamento da Rota de Entregas (DDL -> DML)

A TecProExpress tem Entregadores e Telefones. Como o entregador pode ter vários telefones (Multivalorado), não podemos colocar 3 colunas de telefone na mesma tabela. A regra diz: "Crie uma nova tabela".

🛠️ Código do Exemplo

-- PASSO 1: DDL (A Tabela Principal - Entidade)
CREATE TABLE entregador_tecpro (
    id INT PRIMARY KEY,
    nome VARCHAR(100) NOT NULL
);

-- PASSO 2: DDL (A Nova Tabela gerada pelo Atributo Multivalorado)
CREATE TABLE telefone_entregador (
    id_entregador INT,
    numero VARCHAR(15),
    PRIMARY KEY (id_entregador, numero), -- Chave Composta!
    FOREIGN KEY (id_entregador) REFERENCES entregador_tecpro(id) ON DELETE CASCADE
);

-- PASSO 3: DML (Carga dos Dados)
INSERT INTO entregador_tecpro VALUES (1, 'Marcos Silva');
INSERT INTO telefone_entregador VALUES (1, '11-9999-8888');
INSERT INTO telefone_entregador VALUES (1, '11-7777-6666');

🔍 Detalhamento do Código:

A tabela telefone_entregador só tem sentido de existir por causa do entregador. Por isso ela tem ON DELETE CASCADE.
A junção do ID com o Número forma a Chave Primária, garantindo que não cadastraremos o mesmo número duas vezes para a mesma pessoa.

🧮 Álgebra Relacional (O Motor Oculto)

Você nunca escreverá "Álgebra Relacional" no terminal do seu trabalho. No entanto, o motor do MySQL/PostgreSQL lê o seu SQL, o converte em álgebra relacional nos bastidores, e otimiza a matemática para responder rápido.

1. Operadores Unários (Atuam em uma tabela)

Seleção (σ - Sigma): Funciona como um filtro horizontal (Linhas). É o WHERE no SQL. Ex: Mostrar apenas entregas de SP.
Projeção (π - Pi): Funciona como um filtro vertical (Colunas). É o SELECT coluna1, coluna2 no SQL. Ex: Mostrar apenas os Nomes, não os CPFs.

2. Operadores Binários (Juntam tabelas)

Produto Cartesiano (X): Cruza todas as linhas de A com todas as linhas de B. (Geralmente evitado, pois gera caos).
Junção (⋈ - Join): A operação mais importante! Ela cruza a Tabela A com a Tabela B apenas onde as chaves (PK e FK) batem.

📊 Fluxo da Junção (⋈)

flowchart LR
    T1["Tabela: CLIENTE<br/>ID=10, Nome=Maria"] --> J{"⋈<br/>Onde as chaves batem"}
    T2["Tabela: PACOTE<br/>ID_Cliente=10, Item=Laptop"] --> J
    J --> RESULT["Resultado Unificado:<br/>Maria comprou um Laptop"]

🛠️ Prática Obrigatória: O Encontro do SQL com a Álgebra

Cenário: O diretor pediu a lista de pacotes e seus donos na TecProExpress.

Crie a query SQL que representa a Junção (⋈) entre a tabela Cliente e a tabela Pacote.

🚀 Script de Seed (Gabarito da Junção)

-- DDL de Setup Rápido (Se você não os tiver da unidade passada)
-- CREATE TABLE cliente (id INT PRIMARY KEY, nome VARCHAR(50));
-- CREATE TABLE pacote (id INT PRIMARY KEY, fk_cliente INT);

-- DML (A Consulta SQL que representa a Álgebra: Cliente ⋈ Pacote)
SELECT cliente.nome, pacote.id 
FROM cliente 
JOIN pacote ON cliente.id = pacote.fk_cliente;

🔍 Detalhamento da Consulta:

O comando JOIN ... ON é a tradução exata do símbolo ⋈ (Junção Natural). Ele varre as duas tabelas e só retorna os dados que estão perfeitamente linkados.

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!TIP] Dica do Especialista: Por que aprender a teoria da Álgebra se você vai programar em SQL? Porque quando você escreve uma query SQL que demora 10 minutos para rodar, o SGBD fornece um "Plano de Execução" estruturado matematicamente na Álgebra. Quem entende os símbolos (σ, π, ⋈) consegue corrigir o gargalo em segundos! 🚀🛡️

📐 CAPÍTULO 10: NORMALIZAÇÃO (1FN A 3FN)

A Normalização é a "vacina" contra dados ruins. É um processo passo a passo (algoritmo) que aplicamos nas nossas tabelas para eliminar redundâncias (dados repetidos à toa) e prevenir anomalias (erros que acontecem quando tentamos salvar ou apagar algo). 🛡️🧩

🎯 Objetivo Curricular

Compreender o conceito de Dependência Funcional e aplicar, na prática (via DDL), a 1ª, 2ª e 3ª Formas Normais (FN) para decompor tabelas doentes em uma arquitetura saudável.

🏢 O Cenário Prático (Seu Desafio)

O setor comercial da TecProExpress criou uma planilha gigante para controlar Vendas. Nela, eles colocaram o Nome do Cliente, o Nome do Entregador, a Placa do Caminhão e o Valor do Frete — tudo na mesma linha! Quando o Entregador mudava de caminhão, o pessoal tinha que atualizar essa informação em 500 linhas diferentes manualmente, causando um caos no faturamento.

"Seu desafio é pegar esse 'Galinheiro de Dados' não normalizado e aplicar as três regras de ouro da Normalização para quebrá-lo em tabelas menores, perfeitamente integradas e imunes a anomalias."

🧠 Fundamentos: As Anomalias e a Dependência Funcional

Se não normalizarmos, o banco sofrerá três doenças fatais:

Anomalia de Inserção: Você não consegue cadastrar um Caminhão novo no sistema porque ele ainda não fez nenhuma venda (e a tabela exige os dados da venda na mesma linha).
Anomalia de Atualização: Você precisa alterar o endereço de um cliente em 500 registros antigos. Se o computador travar no registro 250, o banco ficará inconsistente.
Anomalia de Exclusão: Se você deletar o registro da única venda que um cliente fez, você acidentalmente deleta o cadastro do cliente inteiro junto!

📊 O Algoritmo de Normalização

flowchart LR
    UNF["❌ Tabela Caótica<br/>(A Planilha)"] --> FN1["✅ 1FN:<br/>Atomicidade"]
    FN1 --> FN2["✅ 2FN:<br/>Sem Dependência Parcial"]
    FN2 --> FN3["✅ 3FN:<br/>Sem Dependência Transitiva"]

🔍 Dependência Funcional: O que é isso?

Dizemos que B depende funcionalmente de A (ou A -> B) quando: se eu te der o valor de A, você consegue descobrir com certeza absoluta qual é o valor de B.

Exemplo: O CPF determina o Nome (Um CPF só tem um dono). Mas o Nome não determina o CPF (Existem muitos "Joões"). A Chave Primária (PK) deve sempre ser o determinador de tudo na tabela!

📖 A Jornada das Formas Normais (DDL na Prática)

Vamos resolver o problema da TecProExpress passo a passo.

1️⃣ Primeira Forma Normal (1FN)

Regra: Todos os atributos devem ser atômicos. Sem "células duplas" ou grupos repetitivos.

A Violação: O Excel tinha a coluna "Itens do Pedido" com "Teclado, Mouse, Monitor" dentro da mesma célula.
A Correção (1FN): Quebramos isso. O Pedido vira 3 linhas diferentes.

2️⃣ Segunda Forma Normal (2FN)

Regra: Estar na 1FN + Nenhuma coluna pode depender apenas de metade da Chave Primária Composta.

A Violação: Imagine que a Chave da nossa tabela seja (ID_Venda, ID_Produto). A coluna Nome_do_Produto só depende do ID do Produto, ela não quer nem saber qual foi a Venda! Isso é dependência parcial.
A Correção (2FN): Puxamos o Produto para uma tabela separada.

3️⃣ Terceira Forma Normal (3FN)

Regra: Estar na 2FN + Nenhuma coluna "não-chave" pode depender de outra coluna "não-chave" (Dependência Transitiva).

A Violação: Na tabela de Venda, temos o ID do Cliente, o Nome do Cliente e a Cidade do Cliente. A Cidade depende do Nome, que depende do ID. Se o Cliente não é a Chave Primária da tabela de Vendas, ele não pode morar lá com seus atributos.
A Correção (3FN): Puxamos o Cliente para sua própria tabela.

🛠️ Prática Obrigatória: Quebrando o Monstro (DDL -> DML)

Cenário: O resultado da 3FN. Após a sua análise, a planilha gigante virou três tabelas limpas: Cliente, Produto e a associativa Venda.

🚀 Script de Seed (Gabarito da 3FN)

-- PASSO 1: DDL (As Tabelas Bases - Fortes)
CREATE TABLE cliente_norm (
    id_cliente INT PRIMARY KEY,
    nome VARCHAR(100),
    cidade VARCHAR(50)
);

CREATE TABLE produto_norm (
    id_produto INT PRIMARY KEY,
    descricao VARCHAR(100)
);

-- PASSO 2: DDL (A Tabela Normalizada que liga tudo sem redundância)
CREATE TABLE venda_norm (
    id_venda INT PRIMARY KEY,
    id_cliente INT, -- A FK apontando para o cliente (Nada de escrever a cidade dele aqui!)
    id_produto INT,
    FOREIGN KEY (id_cliente) REFERENCES cliente_norm(id_cliente),
    FOREIGN KEY (id_produto) REFERENCES produto_norm(id_produto)
);

-- PASSO 3: DML (Carga dos Dados Sem Repetição)
INSERT INTO cliente_norm VALUES (1, 'Maria Silva', 'São Paulo');
INSERT INTO produto_norm VALUES (10, 'Teclado Gamer');
-- Agora registramos 100 vendas sem nunca digitar "São Paulo" de novo!
INSERT INTO venda_norm VALUES (1001, 1, 10);

🔍 Detalhamento do Código:

Note que a tabela venda_norm é extremamente leve! Ela só guarda os números dos IDs. Se a Maria mudar de 'São Paulo' para 'Rio de Janeiro', você fará o UPDATE em exatamente 1 linha na tabela cliente_norm, e todas as milhares de vendas dela já estarão magicamente atualizadas! Isso é a força da 3FN.

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Um banco de dados 100% normalizado é sempre a melhor escolha? (Resposta: Para sistemas Transacionais/Operacionais, SIM! Mas em Data Warehouses de Analytics - onde a leitura de relatórios pesados é mais importante que a escrita - às vezes os arquitetos aplicam a Desnormalização propositalmente para evitar muitos cruzamentos de JOINs e acelerar a velocidade do painel). 🧠🛡️

🏗️ CAPÍTULO 11: ECOSSISTEMA SQL E DDL

A primeira ideia que define um desenvolvedor experiente é entender que a SQL (Structured Query Language) não é apenas uma ferramenta, mas uma linguagem declarativa de escala global, capaz de gerenciar desde pequenos aplicativos até a bolsa de valores. 🛡️🧩

🎯 Objetivo Curricular

Compreender a filosofia declarativa da SQL (o papel do otimizador de consultas) e aplicar comandos de Definição de Dados (DDL) para criar schemas, tabelas e gerenciar a evolução da arquitetura.

🏢 O Cenário Prático (Seu Desafio)

A TecProExpress decidiu criar um módulo de "Agenda de Contatos" para os fornecedores logísticos. Os analistas desenharam o MER, mas o banco de dados ainda está vazio.

"Seu desafio é abrir o terminal (ou a interface DBeaver/pgAdmin) e usar a linguagem SQL para construir as fundações do prédio: criar o espaço de trabalho (Schema) e a tabela que armazenará os fornecedores, com regras rígidas."

🧠 Fundamentos: As 5 Famílias da SQL

A SQL é dividida em 5 subconjuntos. Todo o nosso trabalho até agora na criação de tabelas pertenceu ao primeiro grupo.

Sigla	Significado	Comandos Principais	O que faz?
DDL	Data Definition Language	`CREATE`, `ALTER`, `DROP`	Monta o "esqueleto" do banco.
DML	Data Manipulation Language	`INSERT`, `UPDATE`, `DELETE`	Manipula os "órgãos" (dados).
DQL	Data Query Language	`SELECT`	Faz as consultas e relatórios.
DCL	Data Control Language	`GRANT`, `REVOKE`	Segurança (Dá e tira permissão).
TCL	Transaction Control Language	`COMMIT`, `ROLLBACK`	Salva ou Cancela um lote de ações.

📊 Fluxo de Processamento Declarativo

Diferente do Java ou Python (onde você diz como fazer o laço de repetição), a SQL é Declarativa. Você diz o que quer, e o SGBD se vira para otimizar.

flowchart LR
    A["📜 Declaração SQL"] --> B{"⚙️ Otimizador SGBD"}
    B -- "Calcula a Rota" --> C["🗺️ Plano de Execução"]
    C --> D["📊 Resultado Final"]

📖 Exemplo Guiado: O DDL em Ação (Criando a Base)

Sempre organize seus projetos criando um SCHEMA. Ele funciona como uma "pasta" dentro do banco de dados, evitando que as tabelas da logística se misturem com as do RH.

🛠️ Código do Exemplo

-- PASSO 1: DDL (Criação do Namespace/Schema)
CREATE SCHEMA logistica;

-- PASSO 2: DDL (Criação da Tabela com Constraints Base)
CREATE TABLE logistica.fornecedor (
    id INT PRIMARY KEY,
    nome_fantasia VARCHAR(100) NOT NULL,
    cnpj CHAR(14) UNIQUE
);

-- PASSO 3: DDL (Evoluindo a tabela - ALTER)
ALTER TABLE logistica.fornecedor ADD COLUMN email VARCHAR(100);

-- PASSO 4: DML (Carga Inicial)
INSERT INTO logistica.fornecedor (id, nome_fantasia, cnpj, email) 
VALUES (1, 'Baterias Moura', '12345678901234', 'contato@moura.com');

🔍 Detalhamento do Código:

CREATE SCHEMA logistica;: Cria a área de trabalho. No Postgres, isso cria uma divisão lógica no mesmo banco. (Nota: No MySQL, Schema e Database são sinônimos).
logistica.fornecedor: Boa prática! Sempre referenciamos a tabela pelo nome do schema seguido de um ponto.
ALTER TABLE ... ADD COLUMN: A vida real muda! O comando ALTER permite colocar uma nova coluna (email) sem ter que apagar (DROP) a tabela e perder os dados.

🛠️ Prática Obrigatória: Construção e Destruição

Cenário: A base de teste para a equipe de desenvolvimento.

Crie um schema chamado treinamento.
Crie a tabela teste_dev dentro dele.
Insira 1 linha de dados.
Destrua a tabela completamente usando o comando de aniquilação do DDL.

🚀 Script de Seed (Gabarito de Ciclo de Vida)

-- 1. Cria o ambiente
CREATE SCHEMA treinamento;

-- 2. Cria a estrutura (DDL)
CREATE TABLE treinamento.teste_dev (
    id INT PRIMARY KEY,
    descricao VARCHAR(50)
);

-- 3. Insere dados (DML)
INSERT INTO treinamento.teste_dev VALUES (1, 'Cobaia 01');

-- 4. Aniquila a estrutura (DDL Destrutivo)
-- CUIDADO! O DROP apaga a tabela e todos os dados dentro dela sem aviso!
DROP TABLE treinamento.teste_dev;

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!WARNING] Dica do Arquiteto: Qual a diferença entre DELETE (DML) e DROP (DDL)? O DELETE FROM tabela apaga apenas as linhas (os dados), mas o esqueleto da tabela continua existindo para receber novos registros. O DROP TABLE é uma bomba atômica: apaga a estrutura, as colunas, as regras e, por consequência, todos os dados de uma vez. Use com extrema cautela! 🚀🛡️

🔒 CAPÍTULO 12: RESTRIÇÕES DE INTEGRIDADE E CONSTRAINTS

As restrições (Constraints) são as muralhas do seu banco de dados. Elas garantem que os dados inseridos no banco sigam as regras de negócio rigorosas e mantenham a consistência da informação, impedindo que a aplicação salve um preço negativo ou um cliente sem CPF. 🛡️🧩

🎯 Objetivo Curricular

Dominar as restrições de integridade (NOT NULL, UNIQUE, DEFAULT, CHECK) e as Ações Referenciais em Chaves Estrangeiras (CASCADE, RESTRICT) para blindar o banco de dados contra lixo digital.

🏢 O Cenário Prático (Seu Desafio)

A equipe de auditoria da TecProExpress encontrou anomalias gravíssimas na base de testes: existiam produtos cadastrados com peso negativo, motoristas cadastrados com a mesma placa de CNH e registros vazios.

"Seu desafio é reescrever a DDL do sistema de transportes adicionando Constraints (Restrições) diretas no motor SQL. Se um programador tentar inserir um pacote com peso de -5 kg, o SGBD deve cuspir um erro de volta na cara da aplicação antes mesmo do dado chegar no disco!"

🧠 Fundamentos: O Arsenal de Defesa (Constraints)

Você já usou a restrição máxima (PRIMARY KEY), mas o DDL nos fornece ferramentas mais granulares:

Constraint	Função de Defesa	Exemplo Prático
NOT NULL	O campo é obrigatório.	Nenhum usuário sem Nome.
DEFAULT	Valor automático se ninguém enviar nada.	Cliente novo entra com status `Ativo` por padrão.
UNIQUE	Impede valor repetido (mas aceita NULL).	O E-mail da conta de acesso.
CHECK	Validações matemáticas e lógicas.	O frete deve ser sempre `>= 0`.

📖 Exemplo Guiado: O DDL Blindado (Regras de Negócio)

Vamos criar a tabela de "Frete" da TecProExpress com uma armadura pesada de validações.

🛠️ Código do Exemplo

-- PASSO 1: DDL (Criando a Tabela Blindada)
CREATE TABLE frete_blindado (
    id INT PRIMARY KEY,
    codigo_rastreio CHAR(10) UNIQUE NOT NULL, -- Obrigatório e Exclusivo
    peso_kg DECIMAL(5,2) CHECK (peso_kg > 0), -- A regra de ouro da auditoria
    data_registro DATE DEFAULT CURRENT_DATE,  -- Se omitido, pega o dia de hoje
    status VARCHAR(20) DEFAULT 'PENDENTE'
);

-- PASSO 2: DML (Carga de Sucesso)
-- Omitimos a data e o status para ver o DEFAULT agir!
INSERT INTO frete_blindado (id, codigo_rastreio, peso_kg) 
VALUES (1, 'AB12345678', 15.50);

-- PASSO 3: DML (A Carga que VAI FALHAR - Teste o CHECK)
-- Descomente e rode. O banco VAI recusar a inserção por causa do peso negativo.
-- INSERT INTO frete_blindado (id, codigo_rastreio, peso_kg) VALUES (2, 'XY99999999', -2.00);

🔍 Detalhamento do Código:

DEFAULT CURRENT_DATE: Uma função nativa. Se a aplicação de frontend esquecer de mandar a data, o próprio banco preenche.
CHECK (peso_kg > 0): A parede intransponível. A aplicação Node.js ou Python vai receber um erro "Constraint Violation" caso tente registrar peso negativo. O banco de dados nunca confia no Frontend!

🔗 Ações Referenciais em Chaves Estrangeiras (FK)

A Chave Estrangeira não serve apenas para "vincular". Ela define o que acontece quando alguém apaga o dado PAI.

RESTRICT (Padrão): O SGBD proíbe a deleção do Cliente se ele tiver Pacotes no sistema.
CASCADE: Se você deletar o Cliente, o SGBD deleta todos os Pacotes dele junto. (Use com extrema sabedoria).
SET NULL: Deleta o Cliente e deixa os Pacotes órfãos (com ID NULL). Útil se você não quer apagar o histórico de transporte, mas o cliente cancelou a conta.

📊 Fluxo da Chave Estrangeira

flowchart TD
    DEL["❌ Ação: DELETE FROM Cliente WHERE id=10"] --> SGBD{"⚙️ Motor de FK"}
    SGBD -- "RESTRICT" --> B1["⛔ ERRO: Ação Bloqueada"]
    SGBD -- "CASCADE" --> B2["🔥 Deleção em Massa (Cliente e Pacotes)"]
    SGBD -- "SET NULL" --> B3["🧹 Apaga o Cliente. Atualiza Pacotes para NULL"]

🛠️ Prática Obrigatória: Nomeando as Muralhas

Cenário: Facilitando o debug do desenvolvedor. Se você não der um nome para o seu CHECK, o banco cria um nome feio (ex: SYS_C0015). Veja como nomear sua restrição para o log de erro ficar legível.

Crie a tabela de funcionario com um CHECK de salário nomeado como chk_salario_minimo.

🚀 Script de Seed (Gabarito de Nomenclatura)

-- DDL
CREATE TABLE funcionario (
    id INT PRIMARY KEY,
    nome VARCHAR(100),
    salario DECIMAL(10,2),
    
    -- O 'CONSTRAINT' antes da regra permite batizá-la!
    CONSTRAINT chk_salario_minimo CHECK (salario >= 1412.00)
);

-- DML (Essa linha falha e o erro vai explicitar o nome 'chk_salario_minimo')
-- INSERT INTO funcionario VALUES (1, 'João', 1000.00);

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!TIP] Dica do Especialista: Uma arquitetura de dados sênior deve sempre possuir uma "Defesa em Profundidade" (Defense in Depth). Não é porque a linguagem de programação no frontend tem um "IF" bloqueando pesos negativos que o banco de dados deve aceitar qualquer coisa. A Constraint é o goleiro do seu time: se a defesa do código falhar, o goleiro do banco espalma a bola! 🚀🛡️

📝 CAPÍTULO 13: DML — INSERT, UPDATE E DELETE

Se o DDL constrói a "casa", o DML (Data Manipulation Language) são os móveis e as pessoas dentro dela. O DML é a linguagem do dia a dia do desenvolvedor; é com ela que sua aplicação web cadastra usuários, altera senhas e exclui postagens. 🛡️🧩

🎯 Objetivo Curricular

Dominar a sintaxe dos comandos INSERT, UPDATE e DELETE, além de compreender o risco crítico arquitetural de realizar operações massivas sem filtros e regras de segurança.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, um desenvolvedor júnior precisava dar um aumento de 10% no salário do "João". Ele rodou o comando e, quando os holerites saíram, todos os 5.000 funcionários da empresa haviam recebido 10% de aumento. O prejuízo foi milionário.

"Seu desafio é treinar os estagiários para nunca mais cometerem esse erro fatal. Você deve demonstrar o uso seguro da DML, explicando como a cláusula WHERE é o único escudo entre uma atualização pontual e a demissão sumária por erro em produção."

🧠 Fundamentos: Os Três Pilares da Manipulação

1. Inserindo (INSERT INTO)

O comando INSERT adiciona uma ou mais linhas (tuplas) à tabela.

-- DDL Rápido para contexto
-- CREATE TABLE cliente (id INT PRIMARY KEY, nome VARCHAR(50), saldo DECIMAL(10,2));

-- Inserção Explicita (A mais segura, você diz quais colunas)
INSERT INTO cliente (id, nome, saldo) VALUES (1, 'Maria', 500.00);

-- Inserção Implícita (Se você souber a ordem exata das colunas)
INSERT INTO cliente VALUES (2, 'José', 1000.00);

-- Múltipla (Várias linhas num único comando - Alta Performance)
INSERT INTO cliente (id, nome, saldo) VALUES 
(3, 'Ana', 0), 
(4, 'Carlos', 200);

2. Atualizando (UPDATE)

Altera dados que já existem. O maior perigo do SQL mora aqui.

-- O Jeito Certo (Uso obrigatório do WHERE)
UPDATE cliente 
SET saldo = 800.00 
WHERE id = 1; -- Apenas a Maria recebe o novo saldo

-- O Erro do Estagiário (NUNCA FAÇA ISSO)
-- UPDATE cliente SET saldo = 800.00;
-- Efeito: Maria, José, Ana e Carlos teriam seu saldo substituído para 800.

3. Excluindo (DELETE FROM)

Remove linhas inteiras da tabela.

-- Exclusão Segura
DELETE FROM cliente WHERE id = 4; -- O Carlos é removido do sistema

-- O Desastre (Evacuação Total)
-- DELETE FROM cliente; 
-- Apaga absolutamente TODAS as linhas da tabela. Apenas a estrutura (DDL) sobrevive.

📖 Exemplo Guiado: O Teste de Sobrevivência (DDL -> DML)

Sempre teste atualizações complexas antes de rodá-las em produção.

🛠️ Código do Exemplo (Com Segurança)

-- PASSO 1: DDL (Criando a Tabela)
CREATE TABLE frota_tecpro (
    id_veiculo INT PRIMARY KEY,
    placa VARCHAR(7),
    status VARCHAR(20)
);

-- PASSO 2: DML (Carga Inicial)
INSERT INTO frota_tecpro VALUES (10, 'AAA1234', 'ATIVO');
INSERT INTO frota_tecpro VALUES (20, 'BBB9999', 'ATIVO');

-- PASSO 3: O Teste de Segurança (Usando transação)
START TRANSACTION;
  UPDATE frota_tecpro SET status = 'MANUTENCAO' WHERE id_veiculo = 10;
COMMIT;

🔍 Detalhamento do Código:

Envelopar um UPDATE ou DELETE dentro de um START TRANSACTION é uma prática Sênior. Se você esquecer o WHERE e estragar a tabela, basta rodar ROLLBACK; em vez de COMMIT; para desfazer o erro antes que ele seja salvo no disco!

🛠️ Prática Obrigatória: A Manutenção da Frota

Cenário: A TecProExpress vendeu o veículo 20 e comprou um novo veículo 30.

Insira o novo veículo (ID 30, Placa CCC5555, Status ATIVO).
Atualize o status do veículo 10 para 'VIAGEM'.
Exclua o veículo 20 do sistema.

🚀 Script de Seed (Gabarito DML)

-- 1. Insert
INSERT INTO frota_tecpro (id_veiculo, placa, status) 
VALUES (30, 'CCC5555', 'ATIVO');

-- 2. Update seguro (Sempre use a Chave Primária no WHERE!)
UPDATE frota_tecpro 
SET status = 'VIAGEM' 
WHERE id_veiculo = 10;

-- 3. Delete seguro
DELETE FROM frota_tecpro 
WHERE id_veiculo = 20;

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!WARNING] Reflexão Profissional: Diferente de editores de texto como o Word, comandos DML como UPDATE e DELETE sem controle transacional (como vimos no Cap 03) não possuem Ctrl+Z. Ao executar o comando, o disco rígido é reescrito instantaneamente. No MySQL Workbench, existe uma trava de segurança chamada Safe Updates que bloqueia UPDATEs que não usam a Chave Primária no WHERE, mas em servidores em nuvem, essa trava não existe! Respeite o WHERE! 🚀🛡️

🔍 CAPÍTULO 14: CONSULTAS SELECT (A ARTE DO DQL)

Dos milhares de comandos SQL rodando agora nos servidores da Amazon ou do Google, 90% deles são comandos SELECT. A Extração de Dados (DQL - Data Query Language) é o que permite que a diretoria tome decisões baseadas em fatos, e não em achismos. 🛡️🧩

🎯 Objetivo Curricular

Dominar o comando SELECT e suas cláusulas de filtragem (WHERE, LIKE, IN, BETWEEN) e ordenação (ORDER BY) para a geração de relatórios precisos.

🏢 O Cenário Prático (Seu Desafio)

O Diretor de Operações da TecProExpress quer um painel de controle. Ele diz: "Quero ver apenas os motoristas do estado de São Paulo, que ganham mais de R$ 3.000,00, organizados do maior salário para o menor, e quero o nome de quem tem 'Silva' no sobrenome".

"Seu desafio é transformar esse pedido humano em uma Query SQL matemática e cirúrgica, extraindo exatamente o que o diretor quer da base de dados, ignorando os milhares de outros registros irrelevantes."

🧠 Fundamentos: A Anatomia da Busca

O comando SELECT lê as tabelas de forma passiva. Ele nunca altera ou apaga um dado. Ele apenas tira uma "foto" e te mostra.

1. Seleção Básica (O Coringa)

-- DDL/DML Base para os exemplos
-- CREATE TABLE motorista (id INT, nome VARCHAR(50), estado CHAR(2), salario DECIMAL(10,2));
-- INSERT INTO motorista VALUES (1, 'João Silva', 'SP', 3500.00), (2, 'Maria Souza', 'RJ', 2800.00);

-- O * (asterisco) significa "traga todas as colunas"
SELECT * FROM motorista;

-- Traga apenas colunas específicas (Melhor performance)
SELECT nome, salario FROM motorista;

2. O Filtro Matemático (WHERE)

Você não quer ver o banco inteiro, você quer filtrar linhas (Tuplas).

-- Filtro Exato
SELECT nome FROM motorista WHERE estado = 'SP';

-- Filtro Numérico Maior/Menor
SELECT nome FROM motorista WHERE salario > 3000.00;

3. Filtros Avançados de Padrão (LIKE e IN)

Para buscar textos parciais ou listas específicas.

-- O operador % funciona como um coringa (qualquer coisa antes, 'Silva', qualquer coisa depois)
SELECT nome FROM motorista WHERE nome LIKE '%Silva%';

-- O operador IN evita ter que escrever vários OR (estado='SP' OR estado='RJ')
SELECT nome FROM motorista WHERE estado IN ('SP', 'RJ', 'MG');

4. Ordenação (ORDER BY)

Como o resultado será apresentado na tela.

-- ASC = Crescente (A-Z ou 0-9) | DESC = Decrescente (Z-A ou 9-0)
SELECT nome, salario FROM motorista ORDER BY salario DESC;

📖 Exemplo Guiado: O Relatório do Diretor

Vamos unir todas as cláusulas para resolver o desafio da TecProExpress.

A ordem de escrita é obrigatória no SQL:

SELECT (O que eu quero ver?)
FROM (De onde vem?)
WHERE (Quais são as condições?)
ORDER BY (Como organizo?)

🛠️ Código do Exemplo

SELECT nome, estado, salario 
FROM motorista 
WHERE estado = 'SP' 
  AND salario > 3000.00 
  AND nome LIKE '%Silva%'
ORDER BY salario DESC;

🔍 Detalhamento do Código:

AND: O operador lógico exige que as três condições sejam verdadeiras simultaneamente para que a linha seja exibida na tela.
ORDER BY salario DESC: O motorista que ganha R$ 4.000 aparecerá antes do que ganha R$ 3.500.

🛠️ Prática Obrigatória: Extração de Dados

Cenário: O relatório de Pacotes da TecProExpress.

Crie a tabela pacote com id, descricao, peso_kg e valor_frete.
Insira 4 pacotes com pesos e fretes diferentes.
Crie um SELECT que mostre apenas a descricao e o valor_frete dos pacotes que pesam entre 10 e 50 kg (BETWEEN), ordenados pelo frete mais barato primeiro.

🚀 Script de Seed (Gabarito DQL)

-- 1. Setup (DDL)
CREATE TABLE pacote (
    id INT PRIMARY KEY,
    descricao VARCHAR(100),
    peso_kg DECIMAL(5,2),
    valor_frete DECIMAL(10,2)
);

-- 2. Massa de Dados (DML)
INSERT INTO pacote VALUES (1, 'Televisão', 15.50, 150.00);
INSERT INTO pacote VALUES (2, 'Celular', 0.50, 30.00);
INSERT INTO pacote VALUES (3, 'Geladeira', 80.00, 400.00);
INSERT INTO pacote VALUES (4, 'Bicicleta', 20.00, 200.00);

-- 3. O Relatório (DQL)
SELECT descricao, valor_frete 
FROM pacote 
WHERE peso_kg BETWEEN 10.00 AND 50.00 
ORDER BY valor_frete ASC;

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Nunca, em hipótese alguma, utilize SELECT * no código fonte de uma aplicação em produção (Java, Node.js, C#). Se a sua aplicação só precisa mostrar o Nome e o Email do usuário, fazer SELECT * fará com que o SGBD traga todas as colunas, incluindo Fotos, Textos longos de Biografia e a Senha criptografada pela rede. Isso gasta banda, atrasa a tela e gera risco de segurança. Sempre cite as colunas que você quer no SELECT! 🧠🛡️

🔗 CAPÍTULO 15: LÓGICA NULL, SUBQUERIES E JOINS

No mundo real corporativo, os dados nunca estão em uma única tabela. Eles estão espalhados por dezenas de tabelas normalizadas. O desenvolvedor sênior é aquele capaz de "costurar" essas informações em tempo real. 🛡️🧩

🎯 Objetivo Curricular

Dominar a lógica ternária do valor NULL, compreender o escopo de Subqueries e construir painéis complexos cruzando dados através de INNER, LEFT, RIGHT e FULL JOIN.

🏢 O Cenário Prático (Seu Desafio)

A equipe de faturamento da TecProExpress fez uma busca simples para somar todos os pacotes entregues, mas o valor bateu milhares de reais a menos do que o real. Por quê? Porque alguns pacotes ainda não tinham um Motorista designado (ID_Motorista = NULL), e o JOIN que o desenvolvedor júnior usou simplesmente deletou esses pacotes do relatório!

"Seu desafio é dominar as armadilhas do NULL e aplicar o tipo correto de JOIN para garantir que pacotes não atribuídos continuem aparecendo no faturamento geral."

🧠 Fundamentos: O Buraco Negro do NULL

No SQL, a lógica não é Binária (True/False). É Ternária (True/False/Unknown). O NULL representa o "Desconhecido". E a regra de ouro é: A matemática com o desconhecido sempre resulta em desconhecido.

10 + NULL = NULL
'A' = NULL -> FALSO (Nem o NULL é igual a outro NULL!)

🛠️ Como checar se algo é NULL?

Você não pode usar = (igual). Você deve usar a palavra IS.

-- Errado (Não retorna nada)
SELECT * FROM pacote WHERE id_motorista = NULL;

-- Certo (Traz os pacotes sem motorista)
SELECT * FROM pacote WHERE id_motorista IS NULL;

📖 Subqueries (A Consulta Inception)

Uma Subquery é um SELECT dentro de outro SELECT. Usamos isso quando precisamos do resultado de uma busca para poder fazer outra busca.

🛠️ Código do Exemplo (Quem ganha mais que a média?)

-- A Subquery (entre parênteses) roda PRIMEIRO e calcula a média. 
-- O valor calculado é passado para o SELECT de fora.
SELECT nome, salario 
FROM motorista 
WHERE salario > (SELECT AVG(salario) FROM motorista);

🔗 A Arte dos JOINs

Quando as tabelas foram normalizadas (Cap. 10), elas foram separadas. O JOIN é a "Supercola" que une elas de volta.

📊 Diagrama de Venn dos JOINs

flowchart LR
    subgraph INNER JOIN
    A1(("Tabela A")) --- B1(("Tabela B"))
    end
    
    subgraph LEFT JOIN
    A2((("Tabela A"))) --- B2(("Tabela B"))
    end
    
    style A1 fill:#e0e0e0
    style B1 fill:#e0e0e0
    style A2 fill:#4caf50
    style B2 fill:#e0e0e0

1. INNER JOIN (A Interseção Perfeita)

Retorna APENAS o que existe dos dois lados. (O erro do júnior da TecProExpress).

Se o pacote não tem motorista, ele não aparece.

2. LEFT JOIN (Preservando a Tabela da Esquerda)

Retorna TUDO da Tabela A (Esquerda), mesmo que ela não tenha correspondência na Tabela B. (A solução para o relatório!).

Todos os pacotes aparecem. Se não tiver motorista, a coluna do motorista vem preenchida com NULL.

🛠️ Prática Obrigatória: Salvando o Faturamento

Cenário: Corrigindo o erro do painel da TecProExpress.

Crie a tabela motorista e a tabela pacote.
Insira dois pacotes com motoristas e um pacote com id_motorista = NULL.
Crie uma query que liste todos os pacotes, mostrando o nome do motorista apenas quando ele existir.

🚀 Script de Seed (Gabarito de JOINs)

-- DDL
CREATE TABLE motorista (id INT PRIMARY KEY, nome VARCHAR(50));
CREATE TABLE pacote (id INT PRIMARY KEY, descricao VARCHAR(50), valor DECIMAL(10,2), id_motorista INT);

-- DML
INSERT INTO motorista VALUES (1, 'Carlos'), (2, 'Ana');
INSERT INTO pacote VALUES (100, 'Geladeira', 200.00, 1);
INSERT INTO pacote VALUES (101, 'TV', 50.00, 2);
INSERT INTO pacote VALUES (102, 'Micro-ondas', 30.00, NULL); -- Pacote sem dono

-- O ERRO DO JÚNIOR (O Micro-ondas não aparece)
-- SELECT p.descricao, m.nome FROM pacote p INNER JOIN motorista m ON p.id_motorista = m.id;

-- DQL (A SOLUÇÃO COM LEFT JOIN)
SELECT p.descricao, p.valor, m.nome AS motorista_responsavel
FROM pacote p
LEFT JOIN motorista m ON p.id_motorista = m.id;

🔍 Detalhamento da Consulta:

pacote p: A letra p é um Alias (Apelido), para não precisarmos digitar o nome completo da tabela toda hora.
LEFT JOIN: O pacote é a Tabela A (Esquerda, citada antes do JOIN). Logo, a query promete: "Mostrarei todos os pacotes, custe o que custar!".

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!IMPORTANT] Dica do Especialista: Você quer se destacar na engenharia de dados? Entenda que JOINs são operações matemáticas pesadas (Produto Cartesiano + Filtro). Em relatórios que cruzam 15 tabelas com milhões de linhas, a ordem que você escreve seus INNER JOIN e LEFT JOIN pode fazer a diferença entre a consulta terminar em 2 segundos ou travar o servidor da empresa. 🧠🛡️

⚡ CAPÍTULO 16: VIEWS, ÍNDICES E OTIMIZAÇÃO

Escrever um SQL que devolve o resultado correto é fácil. Escrever um SQL que devolve o resultado correto em 3 milissegundos sob um banco com 10 milhões de linhas é o que separa um programador iniciante de um Arquiteto de Software. 🛡️🧩

🎯 Objetivo Curricular

Aprender a abstrair a complexidade e aumentar a segurança com a criação de VIEWs. Entender o impacto arquitetural da criação de Índices na leitura vs gravação e analisar planos de execução com o comando EXPLAIN.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, a tabela de Pacotes atingiu 5 milhões de registros. A busca no painel do usuário ("Procurar pacote pelo Código de Rastreio") começou a demorar 8 segundos para responder. Os clientes estão reclamando no Reclame Aqui. Além disso, o RH pediu um relatório com os dados dos estagiários, mas o banco se recusou a dar acesso à tabela original, pois nela constam salários confidenciais.

"Seu desafio é criar uma VIEW cega para proteger os salários do RH e implementar um Índice (Index) no Código de Rastreio para derrubar o tempo de busca da tabela de pacotes de 8 segundos para 3 milissegundos!"

🧠 Fundamentos 1: O Encapsulamento (VIEW)

Uma VIEW (Visão) é uma tabela virtual. Ela não armazena dados físicos no HD. Ela armazena apenas a "lógica" de um SELECT.

Segurança: Você pode criar uma VIEW que esconde a coluna "Salario" da tabela original e dar permissão para o usuário ler apenas essa VIEW.
Abstração: Se você tem um relatório que exige 5 JOINs super complexos, você pode salvar tudo isso em uma VIEW. O desenvolvedor frontend apenas fará SELECT * FROM nome_da_view;.

🛠️ Criando a Visão do RH

-- DDL Rápido: A tabela original (Intocável)
-- CREATE TABLE funcionario (id INT, nome VARCHAR(50), salario DECIMAL(10,2));

-- Criando a Visão Segura (Ignoramos o salário de propósito)
CREATE VIEW vw_funcionarios_rh AS
SELECT id, nome FROM funcionario;

-- Como o usuário (RH) irá consultar:
SELECT * FROM vw_funcionarios_rh;

🧠 Fundamentos 2: O Acelerador (Índices)

Quando você manda o SGBD procurar o código de rastreio 'BR123', e a tabela não tem Índice, o banco faz um Full Table Scan (Ele lê a linha 1, depois a linha 2... até a linha 5.000.000). Isso é terrível.

Um Índice (Index) é uma cópia organizada de uma coluna específica, guardada em uma árvore de busca (B-Tree). Funciona como o índice remissivo no final de um livro.

📊 Comparação de Busca

flowchart LR
    A["Tabela sem Índice<br/>(Lê 5 milhões de linhas)"] -->|O(N)| B["Demora 8 segundos"]
    C["Tabela com Índice B-Tree<br/>(Busca binária)"] -->|O(log N)| D["Demora 3 milissegundos"]

⚠️ O Preço do Índice

Se índices são tão maravilhosos, por que não colocamos em TODAS as colunas? Porque o Índice atrasa a gravação. Toda vez que houver um INSERT ou UPDATE, o banco terá que escrever o dado na tabela e depois reorganizar a árvore do Índice.

A Regra: Tabelas com muita leitura (Consultas) exigem índices. Tabelas com muita gravação (ex: Logs de GPS em tempo real) exigem o mínimo de índices possível.

📖 Exemplo Guiado: Otimizando o Rastreio (EXPLAIN)

O comando EXPLAIN é a ferramenta de raio-x do SGBD. Ele não executa a consulta, ele te diz o "Plano Matemático" que o SGBD faria.

🛠️ Código do Exemplo

-- DDL Base
-- CREATE TABLE pacote_log (id INT, codigo_rastreio VARCHAR(15), status VARCHAR(20));
-- (Imagine 5 milhões de inserts aqui)

-- 1. O Diagnóstico: "Como você faria essa busca, Banco de Dados?"
EXPLAIN SELECT * FROM pacote_log WHERE codigo_rastreio = 'BR123';
-- O SGBD responderá: type = "ALL" (Ele vai ler TODAS as linhas).

-- 2. A Cura (DDL de Otimização)
CREATE INDEX idx_pacote_rastreio ON pacote_log(codigo_rastreio);

-- 3. O Novo Diagnóstico
EXPLAIN SELECT * FROM pacote_log WHERE codigo_rastreio = 'BR123';
-- O SGBD responderá: type = "ref" (Usando o Índice). Velocidade máxima atingida!

🛠️ Prática Obrigatória: Abstração e Velocidade

Cenário: O sistema de relatórios da TecProExpress.

Crie a tabela faturamento com id_venda, data_venda, nome_cliente e valor_lucro.
Crie uma VIEW chamada vw_vendas_publicas que mostre apenas a data e o cliente (escondendo o lucro da equipe de vendas).
Crie um INDEX na coluna data_venda para acelerar os relatórios de fechamento mensal.

🚀 Script de Seed (Gabarito de Otimização)

-- 1. Tabela Original (DDL)
CREATE TABLE faturamento (
    id_venda INT PRIMARY KEY,
    data_venda DATE,
    nome_cliente VARCHAR(100),
    valor_lucro DECIMAL(15,2)
);

-- 2. View Segura (DQL encapsulada em DDL)
CREATE VIEW vw_vendas_publicas AS
SELECT data_venda, nome_cliente 
FROM faturamento;

-- 3. Índice Estratégico (DDL)
CREATE INDEX idx_data_fechamento ON faturamento(data_venda);

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos práticos e de estudo:

💡 Checkpoint de Lógica

[!TIP] Dica do Engenheiro: Um erro clássico de performance é colocar o código dentro de funções (ex: WHERE YEAR(data_venda) = 2026). Quando você envolve a coluna com uma função, o SGBD é forçado a ignorar o Índice e fazer o Full Table Scan. O correto para alta velocidade é: WHERE data_venda BETWEEN '2026-01-01' AND '2026-12-31'. 🧠🛡️

?? CAPÍTULO 17: SEGURANÇA DCL, EVOLUÇÃO DE SCHEMA E REVISÃO

Em ambientes corporativos, nem todo usuário deve ter acesso a tudo. A Data Control Language (DCL) é a sub-linguagem SQL responsável por controlar quem pode fazer o quê no banco de dados. ?????

Objetivo: Dominar os comandos GRANT e REVOKE para criar políticas de acesso granulares, compreendendo o conceito de Roles (Papéis) em MySQL 8.4 e PostgreSQL 17.

?? PASSO 1: O Modelo de Privilégios

?? Hierarquia de Acesso

flowchart TD
    DBA["👑 DBA\nTODOS os privilégios"] --> DEV["💻 Desenvolvedor\nSELECT + INSERT + UPDATE"]
    DBA --> REPORT["📊 Analista\nApenas SELECT"]
    DBA --> EST["🎓 Estagiário\nSELECT em Views"]

Tipos de Privilégios SQL

Privilégio	Descrição	Exemplo de Uso
`SELECT`	Ler dados	Relatórios, consultas
`INSERT`	Inserir novos registros	Cadastro de dados
`UPDATE`	Alterar registros existentes	Atualização de dados
`DELETE`	Remover registros	Manutenção de dados
`CREATE`	Criar tabelas/schemas	Desenvolvimento
`DROP`	Remover tabelas/schemas	Administração
`ALL PRIVILEGES`	Todos os acima	Apenas DBA

?? PASSO 2: Criando Usuários

?? MySQL 8.4

-- Criar usuário
CREATE USER 'analista'@'localhost' IDENTIFIED BY 'Senha@Forte123';

-- Criar usuário que pode acessar de qualquer host
CREATE USER 'dev'@'%' IDENTIFIED BY 'Dev@2026!';

?? PostgreSQL 17

-- Criar usuário (ROLE com LOGIN)
CREATE USER analista WITH PASSWORD 'Senha@Forte123';

-- Criar role sem login (grupo de permissões)
CREATE ROLE equipe_relatorios;

?? PASSO 3: Concedendo Privilégios (GRANT)

?? MySQL 8.4

-- SELECT em todas as tabelas do schema petsaude
GRANT SELECT ON petsaude.* TO 'analista'@'localhost';

-- SELECT + INSERT em uma tabela específica
GRANT SELECT, INSERT ON petsaude.consulta TO 'dev'@'%';

-- Todos os privilégios (apenas DBA!)
GRANT ALL PRIVILEGES ON petsaude.* TO 'dba_master'@'localhost';

-- Aplicar as alterações
FLUSH PRIVILEGES;

?? PostgreSQL 17

-- SELECT em todas as tabelas do schema
GRANT SELECT ON ALL TABLES IN SCHEMA petsaude TO analista;

-- SELECT + INSERT em tabela específica
GRANT SELECT, INSERT ON petsaude.consulta TO analista;

-- Acesso ao schema (obrigatório no PostgreSQL)
GRANT USAGE ON SCHEMA petsaude TO analista;

?? PASSO 4: Revogando Privilégios (REVOKE)

-- MySQL
REVOKE INSERT ON petsaude.consulta FROM 'dev'@'%';

-- PostgreSQL
REVOKE INSERT ON petsaude.consulta FROM analista;

?? PASSO 5: Roles (Papéis) — Agrupando Permissões

Em vez de conceder permissões usuário por usuário, criamos Roles (grupos de permissões):

?? PostgreSQL 17 (Suporte nativo a Roles)

-- 1. Criar Role com permissões
CREATE ROLE leitura_relatorios;
GRANT USAGE ON SCHEMA petsaude TO leitura_relatorios;
GRANT SELECT ON ALL TABLES IN SCHEMA petsaude TO leitura_relatorios;

-- 2. Atribuir a Role ao usuário
GRANT leitura_relatorios TO analista;
GRANT leitura_relatorios TO estagiario;

?? MySQL 8.4 (Roles a partir do MySQL 8.0)

-- 1. Criar Role
CREATE ROLE 'leitura_relatorios';
GRANT SELECT ON petsaude.* TO 'leitura_relatorios';

-- 2. Atribuir ao usuário
GRANT 'leitura_relatorios' TO 'analista'@'localhost';

-- 3. Ativar a role (obrigatório no MySQL)
SET DEFAULT ROLE 'leitura_relatorios' TO 'analista'@'localhost';

?? Modelo de Roles

flowchart TD
    R1["🔑 Role: admin_full"] --> U1["👑 DBA"]
    R2["👥 Role: leitura_relatorios"] --> U2["📊 Analista"]
    R2 --> U3["🎓 Estagiário"]
    R3["🛡️ Role: dev_crud"] --> U4["💻 Dev Backend"]

?? PASSO 6: Views + DCL = Segurança Completa

A combinação mais poderosa é usar Views (Cap. 056) com DCL:

-- 1. Criar View que oculta dados sensíveis
CREATE VIEW vw_funcionarios_publico AS
SELECT id, nome, data_admissao FROM funcionario;

-- 2. Dar acesso apenas à View, NUNCA à tabela real
GRANT SELECT ON vw_funcionarios_publico TO estagiario;

-- O estagiário pode:
SELECT * FROM vw_funcionarios_publico;  -- ? OK

-- O estagiário NÃO pode:
SELECT * FROM funcionario;  -- ? ACESSO NEGADO (salário protegido!)

?? Dica do Especialista: Em produção, NUNCA dê ALL PRIVILEGES a usuários de aplicação. Crie Roles específicas com o mínimo de permissões necessárias. Este é o Princípio do Menor Privilégio (Principle of Least Privilege). ?????

??? EVOLUÇÃO E ARQUITETURAS MODERNAS

Mudar a estrutura de um banco de dados em produção é um desafio técnico chamado Schema Evolution. ?????

Objetivo: Dominar os comandos de alteração estrutural (ALTER TABLE), compreender a manipulação de dados semiestruturados (JSON) e diferenciar as arquiteturas SQL e NoSQL.

?? PASSO 1: Evolução de Schema (ALTER TABLE)

Sistemas reais mudam. O comando ALTER TABLE permite que a tabela se adapte sem perda de dados.

?? Ciclo de Adaptação

flowchart LR
    V1["📦 Tabela V1"] --> |"ADD COLUMN"| V2["📦 Tabela V2"]
    V2 --> |"ALTER COLUMN"| V3["📦 Tabela V3"]
    V3 --> |"DROP COLUMN"| V1

?? MySQL 8.4 (MODIFY)

-- Alterando o tipo de uma coluna existente
ALTER TABLE CONTATO MODIFY COLUMN APELIDO VARCHAR(50);

?? PostgreSQL 17 (ALTER TYPE)

-- Alterando o tipo de uma coluna existente
ALTER TABLE CONTATO ALTER COLUMN APELIDO TYPE VARCHAR(50);

?? PASSO 2: JSON em Bancos Relacionais

Os SGBDs modernos (MySQL 8.4 e Postgres 17) suportam dados híbridos (NoSQL dentro do SQL).

SGBD	Tipo de Dado	Operador de Extração
MySQL 8.4	`JSON`	`->` (ex: `JSON->'$.NOME'`)
PostgreSQL 17	`JSONB`	`->>` (ex: `JSONB->>'NOME'`)

?? PASSO 3: O Ecossistema NoSQL

Surgiu da necessidade de Escalabilidade Horizontal (adicionar mais servidores) em vez de apenas um servidor potente.

?? Tipos de NoSQL

Tipo	Exemplo	Aplicação Profissional
Documentos	MongoDB	Esquema flexível (JSON).
Chave-Valor	Redis	Cache e Sessoes ultrarápidas.
Grafos	Neo4j	Redes sociais e Fraudes.
Colunares	Cassandra	Big Data e Escala Global.

? Verificação de Aprendizagem (Unidade IV)

1. No Postgres 17, qual operador extrai JSON como Texto Limpo? a) -> b) ->> c) JSON_EXTRACT

2. O que ocorre no comando DROP SCHEMA VENDAS CASCADE? a) Apaga o schema e tudo o que depende dele (Tabelas, FKs, Views). b) Dá erro se houver tabelas.

?? Clique aqui para revelar o Gabarito (SPOILER) ??

?? Gabarito:

Letra B. O ->> converte para TEXT. O -> mantém como JSON.
Letra A. O CASCADE é destrutivo e remove as dependências.

?? Perspectiva do Arquiteto: SQL é para consistência. NoSQL é para volume e velocidade. O engenheiro moderno sabe usar ambos de forma híbrida. ?????

?? CONSIDERAÇÕES FINAIS: UNIDADE IV

Você concluiu o módulo avançado. Agora você possui o conhecimento para realizar consultas sofisticadas e gerenciar a evolução do Schema. ?????

Objetivo: Aplicar os conhecimentos de DDL, DML, JOINs e Agregações em um cenário real da indústria: o Sistema de Plano de Saúde.

? Verificação de Aprendizagem (Unidade IV)

?? Questões Objetivas

1. A Lógica Ternária do SQL manipula o valor NULL diferentemente de strings vazias. Em uma consulta com a cláusula WHERE IDADE = NULL, qual será o comportamento matemático do SGBD? a) O SGBD retornará todas as linhas onde a idade não foi preenchida. b) O SGBD acusará um erro de sintaxe, pois o = não aceita 4 letras. c) O SGBD não retornará nenhuma linha, dado que NULL = NULL resulta em Falso (Unknown) para a lógica booleana do WHERE. d) O SGBD retornará apenas o valor 0.

2. Qual operação de junção (JOIN) deve ser utilizada caso você deseje buscar 100% dos registros da tabela Primária (Esquerda), independentemente de haver correspondência válida na tabela Secundária (Direita)? a) INNER JOIN b) CROSS JOIN c) RIGHT EXCLUSIVE JOIN d) LEFT OUTER JOIN (LEFT JOIN)

?? PASSO 1: Estrutura do Projeto (Relatório)

Crie as tabelas seguindo a arquitetura abaixo:

Tabela	Atributos Principais
PLANO	`id` (PK), `nome` (Not Null), `valor` (Decimal)
BENEFICIARIO	`id` (PK), `nome`, `altura` (Decimal), `plano_fk` (FK)
DEPENDENTE	`id` (PK), `nome`, `beneficiario_fk` (FK)

?? PASSO 2: Atividade Prática (Consultas)

Com base no projeto, resolva os desafios: ???

??? DDL: Escreva o script de criação das três tabelas.
?? JOINs:
- a. Liste os nomes dos beneficiários juntamente com o nome de seus dependentes.
- b. Liste o beneficiário com o dependente de maior altura na base.
?? Agregação:
- a. Calcule a altura média dos beneficiários agrupados pelo Plano.
- b. Liste os planos que possuem mais de 5 beneficiários (HAVING).

?? Clique aqui para revelar os Gabaritos e Soluções (SPOILER) ??

?? Gabarito das Questões Objetivas:

Letra C. Em SQL moderno, verificações nulas devem obrigatoriamente usar o operador IS NULL. O sinal de igualdade falha misteriosamente (False/Unknown).
Letra D (LEFT JOIN). Ele preserva o universo total da Entidade Dominante à esquerda e preenche com NULL a tabela dependente caso não encontre relacionamento.

??? Resolução DDL:

CREATE TABLE PLANO (
    ID INT PRIMARY KEY AUTO_INCREMENT,
    NOME VARCHAR(50) NOT NULL,
    VALOR DECIMAL(10,2)
);

CREATE TABLE BENEFICIARIO (
    ID INT PRIMARY KEY AUTO_INCREMENT,
    NOME VARCHAR(100) NOT NULL,
    ALTURA DECIMAL(3,2),
    PLANO_FK INT,
    FOREIGN KEY (PLANO_FK) REFERENCES PLANO(ID)
);

?? Resolução JOINs e Agregação:

-- 2a. Beneficiário e Dependente
SELECT B.NOME, D.NOME 
FROM BENEFICIARIO B
JOIN DEPENDENTE D ON B.ID = D.BENEFICIARIO_FK;

-- 3a. Média por Plano
SELECT P.NOME, AVG(B.ALTURA) 
FROM PLANO P
JOIN BENEFICIARIO B ON P.ID = B.PLANO_FK
GROUP BY P.NOME;

-- 3b. Planos com mais de 5 beneficiários
SELECT P.NOME, COUNT(B.ID) 
FROM PLANO P
JOIN BENEFICIARIO B ON P.ID = B.PLANO_FK
GROUP BY P.NOME
HAVING COUNT(B.ID) > 5;

?? Dica Final: Todo problema complexo pode ser decomposto em partes menores. Use essa técnica e aplique as ferramentas assimiladas. ?????

?? CAPÍTULO 18: NOSQL E MONGODB — DO DOCUMENTO À AGGREGATION

Bem-vindo(a) à fronteira atual da Engenharia de Dados corporativa. A partir de agora, expandiremos a sua mente arquitetural para além do clássico paradigma relacional. ?????

Objetivo: Compreender as motivações essenciais que deram origem ao movimento NoSQL, suas diferenças arquiteturais em relação aos sistemas RDBMS, e o impacto estratégico do Teorema CAP na concepção de sistemas distribuídos de escala global.

?? PASSO 1: A Origem do Paradigma "Not Only SQL"

Por mais de três décadas, bancos como PostgreSQL e SQL Server dominaram absolutos. Contudo, com o advento das Redes Sociais, da Internet das Coisas (IoT) e de volumes na casa dos Petabytes, o modelo relacional rígido sofreu impactos em escalabilidade.

Surgiram então os bancos de dados não-relacionais (NoSQL), priorizando velocidade massiva de leitura/escrita e esquemas flexíveis. Atualmente, o termo é amplamente aceito como Not Only SQL (Não Apenas SQL), indicando que ele complementa o relacional, e não tenta substitui-lo de forma arrogante. ???

?? PASSO 2: O Desafio Estratégico do Teorema CAP

Ao abandonarmos um único servidor potente e passarmos a rodar bancos de dados cruzando oceanos em centenas de máquinas (clusters), esbarramos numa lei física da engenharia de computação postulada por Eric Brewer: O Teorema CAP.

Para qualquer banco de dados distribuído de grande escala, é matematicamente impossível garantir simultaneamente as 3 propriedades abaixo:

C (Consistência): Todos os clientes enxergam a mesma informação simultaneamente.
A (Disponibilidade): O sistema responde sempre, mesmo que dados estejam desatualizados.
P (Tolerância à Partição): O sistema sobrevive se um cabo de rede for cortado entre o Brasil e o Japão.

?? Balanço Arquitetural (Teorema CAP)

flowchart TD
    CAP["⚖️ Teorema CAP"]
    CAP -->|CP| MGB["MongoDB / HBase"]
    CAP -->|AP| CAS["Cassandra / DynamoDB"]
    CAP -->|CA| RDB["PostgreSQL / MySQL"]

    subgraph Prioridade CP
        direction TB
        MGB_info("Garante Consistência<br/>Resiste a quedas de rede<br/>Mas pode falhar na Disponibilidade")
    end
    
    subgraph Prioridade AP 
        direction TB
         CAS_info("Sempre Disponível<br/>Resiste a quedas de rede<br/>Consistência eventual")
    end

?? Atenção: Em sistemas complexos nativos da nuvem (Cloud Native), as "Partições" (quedas de comunicação entre os hubs nos EUA e Europa, por exemplo) não são probabilidades, são certezas. Portanto, você deve escolher na realidade entre CP ou AP. ???

?? PASSO 3: Por que o MongoDB 7.0 LTS?

Dentre de dezenas de modalidades de sistemas "NoSQL", o MongoDB domina a vasta maioria dos cenários contemporâneos.

Arquitetura baseada em Documentos: Os dados não são forçados em matrizes bi-dimensionais (tabelas e colunas). Eles fluem de forma hierárquica usando BSON (Uma versão binária de hiper-performance do JSON).
Schema Dinâmico (Flexible Schema): Um usuário pode ter um endereço com número de casa e outro usuário com lote, andar de apartamento, tudo sob a mesma entidade sem precisar gerar "colunas nulas".
Filosofia CP: Ele prioriza a Consistência dos dados acima de tudo através do sistema elegante do seu "Replica Set".

?? Nota do Arquiteto: Você não precisa escolher entre relacional e NoSQL. A arquitetura corporativa moderna utiliza a Persistência Poliglota: Usar PostgreSQL ?? para auditoria financeira e MongoDB ?? para a navegação acelerada de um feed infinito. ?????

?? MODELAGEM ORIENTADA A DOCUMENTOS

Se na engenharia SQL nós dividimos e isolamos os dados em dezenas de tabelas (Normalização), na engenharia Documental aplicamos frequentemente a fusão das informações vitais num pilar estratégico único. ?????

Objetivo: Diferenciar as abordagens de Modelagem Relacional da Abordagem Documental do MongoDB 7.0, compreendendo os conceitos de Embedding, Referencing e Documentos Aninhados.

?? PASSO 1: O Paradigma do Preço Computacional

Em sistemas RDBMS massivos, o JOIN computacional pode ser dispendioso. No MongoDB 7.0 (arquitetura BSON), se um Cliente possui "Endereços" e "Telefones", qual a forma mais rápida de exibi-los? Guardando tudo junto do Cliente!

O ato de acoplar sub-detalhes dentro do seu registro primário recebe o nome acadêmico de Embedding (Documento Incorporado).

?? PASSO 2: Embedding vs DBRefs (Referências Virtuais)

Devemos analisar a necessidade de arquitetura com precisão lógica:

?? Embedding (Guardar Junto): Acessa tudo numa pancada de I/O em tela. Excelente para relacionamentos 1:1 e relacionamentos 1:N onde "N" é um número controlado.
?? References (Chavear/Apontar): Guarda apenas o _id do documento equivalente (Similar ao modelo Foreign Key - FK do relacional). Obrigatório se envolver um crescimento contínuo e infinito de registros M:N.

?? PASSO 3: Diagrama de Entidade-Documento (Mermaid Híbrido)

A notação de Chen (losangos e elipses) perde eficiência diante de estruturas fortemente encadeadas (Arrays/Objetos profundos).

A notação didática da escola de inteligência de dados sugere fundir o MER (Entidade-Relacionamento) utilizando Tipos JSON explícitos (Array/Object) e detalhando no modelo do conector Mermaid a natureza da associação (EMBEDDED vs REFERENCE):

?? Modelo Híbrido Didático (Composição MongoDB)

erDiagram    
    CLIENTE ||--o{ EMBEDDED_ENDERECO : "EMBEDDED (JSON)"
    CLIENTE ||--o{ COMPRA : "REFERENCE (DBRef)"
    
    CLIENTE {
        ObjectId _id PK
        String nome
        String email
        Array~String~ telefones
        Array~Object~ enderecos
        Document metadados
    }
    
    EMBEDDED_ENDERECO {
        String logradouro
        String cidade
        String uf
    }
    
    COMPRA {
        ObjectId _id PK
        ObjectId cliente_id FK
        Decimal128 valor_total
        Date criado_em
    }

?? Atenção (Rigidez Tecnológica): Na Engenharia MongoDB v7.0, todos os documentos ganham compulsoriamente um identificador único indexado de alta performance chamado _id (do tipo ObjectId, equivalente conceitual ao UUID relacional).

?? PASSO 4: Regra Prática de Engenharia de Sistemas (Desempenho)

A resposta da pergunta clássica moderna — "Qual abordagem usar no Mongo?"

Você tem um PostBlog que sempre precisa exibir uma miniatura de perfil do Autor (nome e foto_url)? Faça Embedding dos metadados essenciais.
Você tem um PostBlog que precisa registrar visualizações de milhares de máquinas (Analytics)? O array explodirá muito rápido! Use obrigatoriamente Referencing (DBRefs) via IDs para uma collection de logs secundária separada.

?? Dica de Engenheiro de Dados: A normalização (1NF, 2NF, 3NF) foi projetada historicamente para salvar espaço de disco (que era caro em 1980 na matriz do sistema bancário). Hoje o disco é infinitamente barato comparado ao custo de se demorar 2 minutos aguardando relatórios em RAM para a máquina analítica de negócio (Analytics). Priorize sempre a velocidade das "QueryReads"! ?????

?? OPERAÇÕES CRUD MODERNAS E SINTAXE MQL

Tendo compreendido que o NoSQL é focado em matrizes declarativas flexíveis (Documentos BSON), você deve abandonar a mentalidade rígida do SQL em prol da versatilidade ágil do MQL (MongoDB Query Language). ?????

Objetivo: Diferenciar o comportamento transacional do SQL para a manipulação rápida de documentos usando funções Javascript assíncronas no motor V8 do MongoDB 7.0 (via mongosh e Compass).

?? PASSO 1: Estrutura Base (Collection MQL)

Em ambientes RDBMS (?? PostgreSQL), as faturas dependem dos produtos, os telefones da tabela dependente e todos são fortemente tipados.

No MongoDB 7.0, os dados residem numa Collection. Ao invés de Insert, Select, Update e Delete monolíticos, o MongoDB padronizou seus vetores via métodos tipificados JavaScript.

?? PASSO 2: `INSERT` (Create)

A função insertOne() e insertMany() recebem objetos literais estruturados e aceitam metadados não tipados (JSON arrays nativos):

/* INSERINDO O CLIENTE COM ARRAY (TELEFONES) NA COLLECTION DE "USUARIOS" */
db.usuarios.insertOne({
    nome: "Linus Torvalds",
    email: "linus@kernel.org",
    idade: 54,
    telefones: ["55-8888-1234", "55-9999-4321"],
    endereco: {
        logradouro: "Rua Open Source, 101",
        cep: "1001-500"
    },
    status_assinatura: "Ativa"
});

?? PASSO 3: `FIND` (Read)

No MQL, o SELECT * FROM TABELA cede espaço à abstração mais veloz e paramétrica da busca por expressões regulares e encadeamentos ($gt, $in e propriedades dot.notation):

/* BUSCANDO CLI COM MAIS DE 40 ANOS (Gt = Greater Than) */
db.usuarios.find({ idade: { $gt: 40 } });

/* BUSCAR CLIENTE PELO LUGAR NIDIFICADO (DOT NOTATION) */
db.usuarios.find({ "endereco.cep": "1001-500" });

?? PASSO 4: `UPDATE` (Update Parcial BSON)

Se errar a lógica do comando e submeter o nó inteiro em vez de apenas o parâmetro usando a instrução chave de atualização (O operador set), o arquivo JSON é sobrescrito:

/* O OPERADOR $SET SÓ ALTERA A CHAVE SELECIONADA. SE NÃO LHE INSTRUIR, ELE APAGA TODO RESTO! */
db.usuarios.updateOne(
    { email: "linus@kernel.org" }, 
    { $set: { status_assinatura: "Suspensa" } }
);

/* O OPERADOR $PUSH INSERE UM NOVO ITEM NO FINAL DE UM ARRAY */
db.usuarios.updateOne(
    { nome: "Linus Torvalds" }, 
    { $push: { telefones: "00-0000-0000" } }
);

?? PASSO 5: `DELETE` (Removendo O Documento Inteiro)

/* Exclui o primeiro documento encontrado que tem menos de 18 anos */
db.usuarios.deleteOne({ idade: { $lt: 18 } });

?? Diferença de Dialeto SQL vs MQL: No PostgreSQL 17, UPDATE table SET campo = valor atinge a tabela inteira se esquecer o WHERE. No MongoDB, o updateOne é cirúrgico e trava na primeira correspondência, evitando acidentes nucleares de DBA. ?????

?? AGGREGATION FRAMEWORK E PIPELINE

Se o find() te leva de 0 a 100 na abstração rápida, o Aggregation Framework te eleva de 100 a 1000, dominando qualquer Business Intelligence complexo. ?????

Objetivo: Extrair poder máximo de relatórios cruzados (Análises, Filtros de Etapas, Projetos de Sub-campos Arrays, Group By nativo MQL).

?? PASSO 1: A Arquitetura do Operador de Tubulação (Pipeline)

No relacional (SQL), a leitura da CPU e Ram do servidor obedece à linearidade estrita SELECT, FROM, WHERE, GROUP BY, HAVING. Na matemática NoSQL distribuída, os dados massivos desistem das tabelas únicas, processando blocos e empurrando o resultado via "Pipeline" (Em lotes de estágios) para que uma máquina minúscula aguente trabalhar grandes Gigabytes.

?? Ciclo de Estágios do Pipeline do BSON

flowchart LR
    M1["🔍 1. $match"] --> G1["👥 2. $group"]
    G1 --> P1["📊 3. $project"]
    P1 --> S1["🔀 4. $sort"]

$match: Filtra como o clássico WHERE e joga metade dos documentos no Lixo cedo (economiza Ram).
$group: O clássico GROUP BY e agregadores de soma (SUM, AVG).
$project: Modela quais atributos a aplicação cliente receberá (Economiza Banda/Tráfego de Internet).
$sort: Põe os dados em Ordem (ORDER BY).

?? PASSO 2: Anatomia de Extração no MongoDB 7.0

Como o engenheiro descobre "Quantidade de Dinheiro da Filial SP nos últimos 7 dias?".

db.faturas.aggregate([
    
    // 1º ETAPA DO CANO: CORTA O QUE NÃO FOR DE SÃO PAULO
    { 
       $match: { filial: "SP", ano: 2026 } 
    },
    
    // 2º ETAPA: JUNTA TODOS QUE SOBRARAM SOMANDO A FATURA E AGRUPANDO PELO VENDEDOR
    { 
       $group: { 
           _id: "$vendedor", 
           faturamento_total: { $sum: "$valor_liquido" },
           total_vendas: { $sum: 1 } 
       } 
    },
    
    // 3º ETAPA: ORDENANDO O MELHOR FATURAMENTO
    {
       $sort: { faturamento_total: -1 } // -1 = DESCENDING
    }

]);

?? PASSO 3: Cross-Joins `$lookup` do MQL (DBRefs Profundos)

A ideia de que "MongoDB e NoSQL não faz Join" é Fake News Arquitetônica. Através do estágio $lookup da Pipeline moderna (> MongoDB 6.0+), unimos Arrays nativamente:

/* BUSCANDO PEDIDO E SUAS REFERÊNCIAS DE FATURA EXCLUSIVA */
db.pedidos.aggregate([
   {
     $lookup: {
       from: "detalhesFatura",   // Qual a "tabela" secundária 
       localField: "faturaId",   // Onde está o ID nesse Documento A
       foreignField: "_id",      // Onde está o ID no Documento B (Fatura)
       as: "faturaCorrigida"     // Qual será o nome do Objeto Inserido Array
     }
  }
]);

?? Nota do DBA Master: Assim que uma Collection cresce com velocidade, usar $lookup esgota a CPU (ele compara 1 doc contra milhares toda hora). Se precisar buscar juntas sempre, mude a estrutura do projeto da Empresa e faça EMBEDDING JSON direto! ?????

?? PERFORMANCE: ÍNDICES E SCHEMA ANALYSIS

Como engenheiro estrito do NoSQL, não há compilação linear como no RDBMS, há verificação de cache e leituras contínuas (I/O). Se a coleção da empresa tem milhões de usuários, um db.usuarios.find({ status: "Ativo" }) fará uma verificação um por um no HD (Collection Scan). ?????

Objetivo: Explorar os mecanismos nativos de performance visual do Compass v1.4x, criando Índices B-Tree eficientes para evitar Gargalos de I/O em produções NoSQL de larga escala.

?? PASSO 1: Índices Básicos via Shell

Um índice empacota metadados de acesso (Ponteiros Lógicos) na RAM e os ordena (ASC/DESC). No MQL, adicionamos performance com precisão em Campos Filhos de forma fluída.

/* CRIANDO O MAPEAMENTO RÁPIDO PARA ORDENAR IDADES DOS CLIENTES (-1 para Z-A Descendente) */
db.usuarios.createIndex({ idade: -1 });

/* ÍNDICES DE ARRAYS INTEIROS (Multikey Index) */
db.loja.createIndex({ "categorias_produto": 1 });

?? PASSO 2: O Poder do Compass (Visual Schema Analysis)

Diferente do SQL (onde você sabe na vírgula quais são os campos tipados de uma Tabela Fixa), no MongoDB 7.0 um documento pode ser livre de Schema ("Schemaless"). Então, como descobrir as chaves de 1 milhão de Jsons diferentes salvos lá dentro em um servidor AWS? Através do Compass!

Aba Schema: No MongoDB Compass, abra a Collection e vá na aba Schema.
Analyze (Amostragem Rápida): Clique em Analyze Schema. O Compass irá varrer alguns milhares de BSONs originais e exibir um Gráfico de Barras indicando que:
- 80% dos documentos possuem a chave data_criacao.
- Os 20% restantes possuem um createdAt (Sujeira do legado NoSQL).
Tome a Decisão: Faça correções com $set ou indexe ambos se for um Legacy Bank.

?? PASSO 3: Identificando Lerdeza (`.explain()`)

Mesmo com Índices, como provar se uma Query está utilizando ele de verdade (Sendo performática) ou lendo TUDO na marra (COLLSCAN)?

/* O EXPLAIN() MOSTRARÁ OS BASTIDORES DO MOTOR (PLANO DE EXECUÇÃO), TEMPO DE MILISEGUNDOS, ETC */
db.faturas.find({ filial: "SP" }).explain("executionStats");

O que Focar na Resposta MQL?

executionTimeMillis: Tempo (Menos é Mais).
totalDocsExamined: Quantos Documentos ele puxou para analisar um a um? Se deu 10.000 e ele retornou apenas 50 resultados reais, seu servidor está processando e apagando o excedente do Lixo na RAM por falta flagrante de Índice exato!

?? Dica de Infra: Se um índice consome 2 Gigabytes da Ram, o motor do MongoDB se sente à vontade para expulsar a sua base diária principal pro SwapHD limitando a velocidade. Analise e Crie índices apenas para os campos "Mais Buscados do WHERE e ORDER BY". Não construa Índices baseados na esperança do Cliente! ?????

?? CONSIDERAÇÕES FINAIS E DESAFIOS: UNIDADE VI (NOSQL)

O Engenheiro Poliglota não teme o paradigma Não-Relacional. Ele sabe que a escolha da tecnologia deve pender para o melhor benefício da Aplicação (App) da Empresa, e não para preferências literais de uma década. ?????

Objetivo: Formatar o domínio lógico recém-adquirido entre os paradigmas Relacionais (SQL) e Orientados a Documento (MQL), mesclando uma lista robusta de avaliações Múltipla Escolha e Desafios Práticos com resoluções explicativas.

? Lista de Exercícios: Questões Objetivas

1. Sob a visão estratégica do Teorema CAP, a Arquitetura do MongoDB prioriza qual das combinações em sua entrega de Distribuição Padrão? a) AP (Disponibilidade contínua acima de Consistência). b) AC (Consistência Forte em um Único Servidor). c) CP (Consistência Constante e Tolerância a Partição de Redes). d) CA (Alta Disponibilidade com Particionamento Relacional).

2. Na Arquitetura MongoDB (NoSQL de Documentos), qual o maior motivador para a Abordagem Didática de Embedding (Fusão de Documentos)? a) Fazer com que o campo ocupe o mínimo tamanho no disco rígido do servidor. b) Simular tabelas fixas Relacionais. c) Facilitar os $lookups no motor V8 de MapReduce. d) Reduzir a latência do aplicativo, centralizando a massa de metadados em uma única operação de Leitura (I/O).

3. Por que o Operador de Pipeline da Collection MongoDB inicia, em 99% das vezes Profissionais (Escala Analítica), com a Etapa $match na Função de Aggregations? a) Porque sem Ordenação Linear não existe Agrupamento. b) Para diminuir o peso final do tráfego JSON pela internet. c) Para cortar imediatamente da Memória RAM os documentos inúteis à pergunta, agilizando os cruzamentos das fases subsequentes. d) O $match apenas renomeia os campos internos cruzando referências.

4. Em Operações CRUD MQL, qual o comportamento imediato de proteção ao utilizar a função updateOne() (com os parâmetros corretos de filtro e $set), em comparação direta a um UPDATE equivalente no SQL Padrão? a) O MQL atualizará todos os documentos por padrão, igual ao SQL sem WHERE. b) O MQL travará na primeira correspondência encontrada, protegendo a base de adulterações acidentais em massa. c) O MQL criará uma nova coleção de backup temporária. d) O MQL deletará o documento caso o $set inclua campos nulos.

?? Lista de Desafios Práticos MongoDB 7.0

Desafio 1: Inserção Multi-nível (O CRUD Moderno)

Você foi encarregado de modelar a inserção de um Aluno na nova plataforma NoSQL do MEC. O Aluno possui RG, Nome e concluiu dois cursos de tecnologia em anos distintos.

Tarefa: Crie o comando em MQL que insira este único documento na collection estudantes, garantindo que o histórico de cursos seja Embutido (Array de Objetos).

Desafio 2: Análise de Performance Visual

Após subir uma collection de Pedidos_Ecommerce com 1 milhão de vendas, o seu aplicativo web começa a congelar (Timeout) na tela de "Pedidos do Vendedor Z".

Tarefa: Explique como utilizar as ferramentas embutidas (db.collection.explain() ou Compass) e quais métricas chaves ler para comprovar a falta de índices e resolver o estrangulamento.

Desafio 3: O Paradigma MQL Translator (Refatoração Analítica)

O sistema antigo em PostgreSQL possuía um relatório gerencial que avaliava o total arrecadado das vendas feitas fisicamente na loja ('POS'):

SELECT VENDEDOR_NOME, 
       SUM(VALOR_TOTAL) AS ARRECADACAO 
FROM VENDAS 
WHERE TIPO_VENDA = 'POS' 
GROUP BY VENDEDOR_NOME 
ORDER BY ARRECADACAO DESC;

Tarefa: Reescreva esse comportamento mental do administrador para a abordagem de Aggregation Pipeline do MongoDB. Traduza linha a linha o sentido do motor de dados.

?? Clique aqui para revelar os Gabaritos e Soluções Detalhadas ??

?? Gabarito e Justificativas das Questões Objetivas:

Letra C. Justificativa: Em clusters corporativos, partições de rede são inevitáveis. O MongoDB escolhe "Ocultar o Errado Mapeado" protegendo a Consistência (CP), em vez da disponibilidade irrestrita de dados corrompidos.
Letra D. Justificativa: Evitar pulular entre Registros (JOINs de disco) é fundamental. Quando a UI precisa de "Perfil Completo + Endereço", buscar do mesmo cilindro (Embedding) destrói as latências clássicas de IOPS.
Letra C. Justificativa: A memória RAM do banco é preciosa. Se o Motor não filtra e joga o "Lixo" fora logo na primeira linha de execução ($match), a RAM esgota rapidamente ao entrar na etapa de Agrupamento ($group) com dados irrelevantes.
Letra B. Justificativa: Sistemas Node.JS / Python muitas vezes executam operações genéricas. Ter métodos estanques como o updateOne é a evolução máxima do Safe Design comparado à perigosa instrução genérica UPDATE do SQL ANSI.

?? Solução Detalhada dos Desafios:

Solução Desafio 1 (Inserção de Embedding): Uma das vantagens cruciais do MongoDB é não criar "Tabela de Histórico de Cursos" atrelada ao Cliente por FK. Tudo flui de forma atômica no JSON.

db.estudantes.insertOne({
    rg: "123.456.789",
    nome: "Ricardo Machado",
    historico_cursos: [
        { nome: "Arquitetura Python", ano_conclusao: 2024 },
        { nome: "SQL Transacional", ano_conclusao: 2025 }
    ]
});

Solução Desafio 2 (Análise de Índice - Profiling): O gargalo é o clássico COLLSCAN (Varredura de Coleção Inteira). A justificativa prática do analista seria:

No Shell da AWS / Servidor, eu faria: db.Pedidos_Ecommerce.find({ vendedor: "Vendedor Z" }).explain("executionStats").
A métrica totalDocsExamined provavelmente mostraria 1 Milhão.
A métrica nReturned mostraria a realidade (ex: 50 pedidos).
Analisando a discrepância (Ler 1M e Devolver 50), o banco teve alto estrangulamento de CPU. Solução: Engatar imediatamente um db.Pedidos_Ecommerce.createIndex({ vendedor: 1 }).

Solução Desafio 3 (Tradução para MQL Pipeline): No MongoDB, o Pipeline "quebra" as instruções relativas (SQL Linear) empurrando a massa residual do Topo para a Base.

db.vendas.aggregate([
    // 1ª Etapa (WHERE SQL): Corta tudo da RAM que NÃO vier do canal físico (POS).
    { $match: { tipo_venda: "POS" } },

    // 2ª Etapa (GROUP/SUM): Agrupa a massa sobrevivente criando o novo eixo virtual.
    { $group: {
        _id: "$vendedor_nome",                   // O EIXO Agrupador
        arrecadacao: { $sum: "$valor_total" }    // O Acumulador
    }},

    // 3ª Etapa (ORDER BY DESC): Ordena o novo objeto finalizado
    { $sort: { arrecadacao: -1 } }
]);

Dica do Especialista

**A Próxima Fronteira:** O NoSQL não apaga o modelo tabular RDBMS, as duas engrenagens dominam o mercado global sob a ótica da Arquitetura Distribuída. Domine Ambas, o Emprego Perfeito te espera logo em seguida! ?????

??? CAPÍTULO 19: APACHE CASSANDRA — BIG DATA E CQL

Bem-vindo ao universo das tabelas imensas, de leituras e gravações em nível global. O Apache Cassandra 4.x (e sua vertente em C++, o ScyllaDB) revolucionou a forma como gigantes da tecnologia absorvem dados. ?????

Objetivo: Compreender a ruptura da arquitetura clássica Client-Server, abraçando a distribuição Descentralizada (Peer-to-Peer), o protocolo de rede Gossip e o formato estrutural do Anel Bi-Direcional (Ring).

?? PASSO 1: O Fim do Servidor Principal (Masterless)

Na engenharia clássica do SQL (mesmo particionada), é comum existir um Servidor "Mestre" (que domina a escrita) e Servidores "Escravos" (que fazem cópia para leitura). Se o mestre cai, o banco pára de gravar até que a equipe assuma ou um escravo se promova.

O Cassandra é Masterless (Sem Mestre). Ele adota a arquitetura Peer-to-Peer originada no manifesto do Amazon Dynamo. Todas as máquinas (Nós) ligadas na mesma rede são iguais. Todas podem escrever, todas podem ler. Se um nó queima, os usuários nem percebem.

?? PASSO 2: A Matemática do Anel (Ring)

Os dados não ficam num nó aleatório. Eles são distribuídos através de um cálculo criptográfico (Hashes) distribuindo as fatias da pizza igualmente em um Anel Virtuall (Ring).

?? Análise da Arquitetura Distribuída (Cassandra Ring)

flowchart TD
    APP["📱 Sua Aplicação Node.js / Python"]

    subgraph Cluster Cassandra ["Anel de Dados / Ring"]
        direction LR
        NO_A(("Nó Europa"))
        NO_B(("Nó Brasil"))
        NO_C(("Nó USA"))
        NO_D(("Nó Ásia"))

        NO_A <-->|Gossip| NO_B
        NO_B <-->|Gossip| NO_C
        NO_C <-->|Gossip| NO_D
        NO_D <-->|Gossip| NO_A
    end

    APP -.->|"Conecta em Qualquer Nó"| NO_B
    APP -.->|"O Nó vira Coordenador"| NO_C

??? O Protocolo Gossip (A Fofoca)

Como o Nó do Brasil sabe que o Nó da Ásia caiu? Através do protocolo Gossip (Fofoca). A cada segundo, os nós se comunicam trocando metadados uns dos outros. "Ei, eu estou vivo, e falei com o Nó da Ásia e ele está morto há 30 segundos". Todo o anel toma consciência instintiva do estado da infraestrutura.

?? PASSO 3: Soluções On-Premise vs Cloud Providers

Montar servidores bare-metal pelo mundo exige engenheiros Sêniores de Redes. Portanto, a indústria foca nos Cloud Providers (DBaaS). O Cassandra brilha sob as opções Serverless:

DataStax Astra DB: O ambiente oficial criado pelos mantenedores do Cassandra. Gerenciamento zero para o programador, foco 100% no uso da linguagem (CQL).
Amazon Keyspaces (for Apache Cassandra): A réplica compatível da AWS.
ScyllaDB: Construído em C++, é compatível nativamente com os drivers CQL do Cassandra, oferecendo performance bruta de latência em milissegundos para casos radicais e sem o "peso" na memória exigido pelo Java.

?? Dica de Infra: Mesmo utilizando a Nuvem sob demanda (Astra, AWS Keyspaces), estudar o funcionamento local (Docker) ou a lógica do Ring é mandatório, pois o mau uso das chaves derruba sua aplicação inteira gerando custos imprevistos na AWS. ?????

?? MODELAGEM DE DADOS: O FIM DO JOIN

No RDBMS (Relacional), você modela as tabelas baseando-se no que será Guardado (Data-Driven). O aluno faz um MER focado primariamente na clareza (Normalização) (User, Pedido, Item) para evitar dados duplicados. Isso é lindo no Papel, mas mata o HDD. ?????

Objetivo: Adotar a arquitetura Query-Driven Modeling (Modelagem Focada na Pergunta), compreendendo o motivo vital pelo qual o ecossistema Distribuído aboliu as amarras do RDBMS.

?? PASSO 1: A Morte da Teoria dos Conjuntos Analíticos

?? REGRA DE OURO E DE SANGUE: NÃO EXISTE JOIN NO CASSANDRA!

Se você tiver uma tabela de USUARIOS em um Nó no Japão, e a tabela de COMPRAS no Nó do Brasil, tentar realizar um SELECT ... INNER JOIN exigiria que milhões de Gigabytes subissem no cabo de fibra ótica cruzando o Oceano toda vez que alguém clicasse em "Ver meu Histórico". O Timeout quebraria a internet.

Portanto, o Cassandra abandonou a junção de servidor (JOIN). Para que as respostas sejam servidas em menos de 10 milissegundos, você precisou abolir a normalização e forçar a "Leitura Seqüencial".

?? PASSO 2: Mudança de Paradigma (Query-Driven)

Para desenhar o seu banco a partir de agora, você precisa seguir este exato ritual:

Comece pelas Queries (Quais Perguntas a UI do seu App fará ao usuário?).
Desenhe uma Tabela Específica para Cada Pergunta.

?? Dica de Performance: No Cassandra, duplicar dados não é pecado, é estratégia primária. Se seu App tem duas abas na interface ("Buscar por Usuário" e "Buscar por E-mail"), você não vai usar subconsultas secundárias ou Joins reversos. Você terá obrigatoriamente duas tabelas gigantes: users_by_id e users_by_email.

?? PASSO 3: O Custo de Escrita vs. Custo de Leitura

No mundo anterior (SQL Clássico) aprendemos: "Evite gravar o mesmo dado duas vezes senão o HD acaba e a anomalia acontece."

No ecossistema de dados distribuído de altíssima escala (Cassandra/ScyllaDB), a verdade é matemática: Escrita é Barata, Leitura Cruzada é Extremamente Cara. O Cassandra foi projetado com otimizações nativas poderosas para escrever simultaneamente em 3, 5 ou 10 tabelas em microssegundos (utilizando o CommitLog em memória nativa), mas ele detesta ter que procurar peças que faltam usando a CPU dele (o Read dele é pior sem os metadados ideais).

Então, sempre crie e use comandos síncronos da sua Linguagem (Seu backend Node, Spring Boot, etc.) e mande ele inserir o mesmo evento de Venda nas 3 tabelas específicas ao vivo na hora da compra (Desnormalização Forte). ?????

?? CHAVES: PARTITION KEY VS CLUSTERING KEY

A essência de toda a magia distribuída, de por que o Cassandra alcança performance na casa dos milissegundos operando em Petabytes, jaz inteiramente no Design Matemático da sua Primary Key Composta (Chave Primária). ?????

Objetivo: Diferenciar o comportamento físico dos discos quando criamos Partition Keys (Localizador Global de Nó) e Clustering Keys (Localizador Magnético Interno / Ordem).

?? PASSO 1: A Dissecção da Chave Primária CQL

Na linguagem CQL, a Primary Key base não significa "Valor Único Aleatório Auto-Increment" como estamos moldados a pensar no MySQL Clássico. Aqui, uma "Chave Primária" é o controle total sobre o Motor Físico do cluster.

Se declararmos a tabela pedidos_by_cliente:

CREATE TABLE pedidos_by_cliente (
    cliente_id UUID,
    data_compra TIMESTAMP,
    produto TEXT,
    valor DECIMAL,
    PRIMARY KEY ((cliente_id), data_compra)
);

A primeira parte isolada em parênteses (cliente_id) é a Partition Key (K-Hash).
A segunda parte data_compra é a Clustering Key (K-Ordem).

?? PASSO 2: O Agrupamento de Discos Virtuais

O papel vital dessas chaves para o desenvolvedor Cloud:

Partition Key (A Viagem Geográfica): Determina em GIGABYTES ONDE (em qual computador/Nó físico de Tóquio, NY ou SP) aquele registro viverá. Registros com o mesmo cliente_id cairão infalivelmente no mesmo servidor da rede.
Clustering Key (A Viagem Magnética): Uma vez que fomos enviados ao Nó correto de Tóquio, ela dita a Ordem exata em que as linhas serão gravadas fisicamente juntas lado a lado. Por padrão (ASC).

?? NÃO EXISTE JOIN NO CASSANDRA! Portanto, agrupar fisicamente (Via Partition e Clustering) os dados que você deseja resgatar na sua tela inicial se torna vitalícia a regra do engenheiro da Alta Disponibilidade.

?? PASSO 3: Lógica Visual do Motor (Diagrama de Chato)

Abaixo vemos as dependências matemáticas geradas pela criação exata de chaves. O Nó que reter a Partição "X" reterá todas as ordenações magnéticas vinculadas a essa "Partição K".

?? Modelagem Híbrida de Escala

erDiagram    
    TABELA_PEDIDOS ||--o{ REGISTRO_FISICO : "Contém (Via Partition/Clustering)"
    
    TABELA_PEDIDOS {
        UUID cliente_id "PK (Partition_Key) - Hashing Token"
        TIMESTAMP data_compra "CK (Clustering_Key) - Order ASC"
        TEXT produto "Payload Data"
        DECIMAL valor "Payload Data"
    }

    REGISTRO_FISICO {
        Disco log_sequencial_node
        Ordenamento data_crescente
    }

?? Dica de Engenheiro: Um "Ponto de Atenção" fatal na carreira de um Analista de Dados Distribuído! Ao criar a Query, o WHERE no Cassandra é Obrigatório e Engessado. Você não pode buscar com um WHERE data_compra = X sem ANTES dizer WHERE cliente_id = Y. Você precisa informar primeiro ao Motor Distribuído qual país ele deve ir voar (Partition), para então ele ordenar e varrer a porta. ?????

?? CQL BÁSICO: COLLECTIONS E TIME TO LIVE (TTL)

Ao aceitar a natureza imutável do Apache Cassandra e o "Fim do JOIN", o Cassandra Query Language (CQL) compensou essa rigidez arquitetural entregando mecanismos elegantes poderosos de inserção temporária e arrays nativos via Colecionadores. ?????

Objetivo: Operacionalizar consultas e comandos de gravação distribuídos, explorando Tipos Complexos (List, Set, Map), O Fetiche mortal do Allow Filtering e as Exclusões Orgânicas (Tombstones e TTL).

?? PASSO 1: A Gravação Distribuída (Actor Model)

Sistemas Cloud escrevem metralhando milhares de Nós da forma mais brutalmente assíncrona.

?? Workflow das Operações Multi-Escrita

flowchart LR
    APP("?? Aplicação Back-end") -- "INSERT INTO (Level: QUORUM)" --> COORD("?? Coordinator Node")
    
    subgraph "Gravação Ponto-Comum (Replica = 3)"
        direction TB
        COORD --> N1[("??? Escrita Nó Principal")]
        COORD --> N2[("??? Escrita Réplica 1")]
        COORD --> N3[("??? Escrita Réplica 2")]
    end

(O Node de contato, chamado Coordinator, orquestra magicamente o disparo da replicação global em milissegundos)

?? PASSO 2: Trabalhando Collections (Sem JOINs de Fato)

Ao modelar entidades Query-Driven, às vezes queremos incluir anexos menores sem precisar gerar Duplicações Extras gigantes de tabelas inteiras.

O CQL disponibiliza SET, LIST e MAP.

/* ADICIONAR CONTEÚDO EXTRA EMBUTIDO */
CREATE TABLE user_perfis (
    email text PRIMARY KEY,
    nome text,
    telefones SET<text>,          -- Lista de valores únicos
    historico LIST<timestamp>,    -- Lista ordenada aceita duplicados
    preferencias MAP<text, text>  -- Chave : Valor (Dicionário)
);

/* INSERINDO METADADOS NOSQL (Sets utilizam chaves e Maps também) */
INSERT INTO user_perfis (email, nome, telefones, preferencias)
VALUES ('ceo@empresa.com', 'Alex', {'55999999', '55888888'}, {'tema':'dark', 'alertas':'on'});

?? PASSO 3: O Mortal `ALLOW FILTERING`

A engine exigirá obrigatoriamente que suas pesquisas contemplem a Partition Key exata da Tabela Desnormalizada, como visto anteriormente (O "Voo" direto ao servidor correto).

Se num momento trágico de gambiarra o DBA tentar consultar pelo Nome do Cidadão (que NÃO é chave Primária ou Índex) a tela devolverá um Erro fatal, te bloqueando.

?? A Marreta do Mal: ALLOW FILTERING
-- NUNCA FAÇA ISSO NO GLOBO (APENAS PARA POGS LOCAIS MINÚSCULOS)
SELECT * FROM user_perfis WHERE nome = 'Alex' ALLOW FILTERING;
O ALLOW FILTERING obriga o Cassandra a ignorar o roteamento da Partição (Ele avisa: Pode ler do HD da Terra inteira Node por Node de forma cega!). Você colapsará a RAM e a CPU do Cluster e ele cairá (Latency Timeouts Diários). ???

?? PASSO 4: Validade dos Dados (Time To Live - TTL)

Sistemas "Temporais", Sensores IoT (Temperatura da Fábrica) ou Cookies Lógicos no Banco ganham uma expiração da prateleira orgânica. No Big Data distribuído não ficamos executando lógicas pesadas de "Rotinas de DELETE Diárias":

/* O dado sumirá orgânicamente como fantasmas (Tombstone) em Segundos Exatos (60s) */
INSERT INTO medicoes_sensores (sensor_id, temp, timestamp) 
VALUES ('ZN01', 58, toTimestamp(now())) USING TTL 60;

A matemática da nuvem cria Marcadores Fúnebres (Tombstones) aos quais as operações diárias de varredura magnética compactam removendo efetivamente a lixeira sem sobrecarregar ninguém! ?????

?? CONSIDERAÇÕES FINAIS: UNIDADE VII (BIG DATA / CASSANDRA)

A essência da Arquitetura Distribuída separa os programadores dos Engenheiros de Dados de Alta Performance. Dominar a estratégia Masterless (Nó-a-Nó) molda profundamente o seu poder de escala em projetos que outrora sofreriam quedas drásticas no mundo corporativo. ?????

Objetivo: Ratificar os axiomas do Cluster NoSQL, avaliando mentalmente decisões rigorosas de Query-Driven Modeling e Particionamento Físico de chaves compostas (Discos e Localização).

? Exercícios de Fixação: Partitioning & Ring Nodes

1. Sob o protocolo de espalhamento matemático em um cluster Ring (Anel) do Apache Cassandra, o que efetivamente o Protocolo GOSSIP entrega como valor insuperável à rede? a) O Gossip transfere e copia a Primary Key inteira para o Banco Relacional. b) O Gossip converte o tráfego Binário do Sistema Operacional local para formato JSON e retransmite para o mongosh. c) O Gossip é o mensageiro vitalício (1 Segundo) onde os Servidores (Nós) atualizam reciprocamente o status uns dos outros, mapeando falhas ou lentidões da topologia (Cluster Health) de forma autonôma e descentralizada, sem precisar de um "Servidor Gerenciador Central". d) O Protocolo Gossip apenas funciona na Nuvem AWS.

2. No paradigma Masterless, se o Nó Brasil recebe do aplicativo a instrução INSERT com um número de réplicas setado para 3 geografias globais, qual a função sistêmica deste nó específico no momento da operação? a) Ele declina o insert exigindo que o Master do Japão aprove a Gravação. b) Ele assume provisoriamente o cargo de Coordinator, executando cópias assíncronas paralelas aos outros nós-alvo ditados pelo Driver do App. c) Ele armazena um arquivo XML de backup. d) Ele inicia um ROLLBACK preventivo.

3. Uma Equipe tentou executar um SELECT por NOME DO CLIENTE em uma enorme Tabela desenhada com id_cliente como Partition Key Exclusiva. Eles não receberam resultado, mas sim um Erro Sistêmico. O Analista Júnior propôs usar brutalmente a clausura ALLOW FILTERING. O que ocorrerá com a corporação? a) A pesquisa ocorrerá rápido e sem restrições usando Inteligência Artificial. b) O Cluster sofrerá esgotamentos mortais de Timeout e lentidão, já que você ordenou que HDs do mundo inteiro (Sem critério Geográfico Hashing) varressem exaustivamente todos os registros da Tabela, quebrando a regra fundamental do roteamento por Particionamento. c) O ALLOW FILTERING apenas ordena os resultados pelo alfabeto ASC. d) O ALLOW FILTERING criará um Log Seguro.

?? Desafio de Modelagem (O Arquiteto Data-Driven vs Query-Driven)

O Problema (Mudança Brusca na Nuvem de Telemetria): Uma montadora RDBMS coletava a velocidade e temperatura dos Seus Carros e salvava tudo em PostgreSQL de forma linear. Toda vez que os Analistas queriam a "Temperatura do Motor X nos Últimos 10 Minutos", o banco de dados desmaiava rodando um milhão de Table Scans. O CTO mandou você migrar o sistema vital para Servidores Físicos Apache Cassandra (ScyllaDB em C++).

Você sabe que a Query Principal Vital é: "Quero TODAS as temperaturas coletadas de UM ESPECÍFICO Motor (motor_serial), ordenados dos registros Mais Recentes para os Mais Antigos!"

Sua Missão Arquitetural: Crie a Tabela Primária CQL perfeita (telemetria_por_motor), isolando quem será a Partition Key (Localidade do HDD do Ring) e quem será a dependente Clustering Key (Ordenando no próprio HDD no sentido Temporal Descendente).

?? Clique aqui para revelar os Gabaritos e Soluções (SPOILER) ??

?? Gabarito e Justificativas das Questões:

Letra C. A robustez de ser "Descentralizado" não existiria sem a Fofoca constante alertando anomalias.
Letra B. O Nó atingido vira o maestro provisório (Coordinator).
Letra B. O Cassandra bloqueia o ALLOW FILTERING nas telas pois quer proteger a Infraestrutura física da Empresa de analistas incautos e acostumados com o Relacional WHERE %LIKE%.

?? Solução Detalhada do Desafio CQL:

O Segredo da Chave Primária: Na Sintaxe do Cassandra, o primeiro parâmetro isolado é a Partição. O segundo parâmetro (e opcionais consecutivos à direita) dita a Ordem Magnética Física dos logs já concentrados neste computador!

CREATE TABLE telemetria_por_motor (
    motor_serial text,
    data_coleta timestamp,
    temperatura decimal,
    velocidade int,
    
    -- ESTRUTURANDO AS CHAVES DO HD:
    PRIMARY KEY ( (motor_serial), data_coleta )

) WITH CLUSTERING ORDER BY (data_coleta DESC);

A Mágica da Query-Driven que salvou a Montadora:

Partition (motor_serial): Todo pacote novo daquele MotorX vindo por 4G cairá obrigatoriamente no exato mesmo nó do Ring responsável por este carro. Não haverá HDs pulando em redes cruzadas.
Clustering data_coleta: Cada novo LOG de temperatura será armazenado EXATAMENTE EM CIMA do evento do segundo passado, devido à clausura DESC.
A Resposta Instantânea (< 1ms): Quando a UI chama os últimos 10 minutos deste motor, o braço magnético do disco apenas baixa e varre "um montinho físico isolado", alcançando a perfeição analítica e a glória arquitetônica!

A Jornada do Arquiteto Moderno

Parabéns por atingir o ápice do treinamento Poliglota Operacional! Do ACID (MySQL/PostgreSQL), transicionando pela Flexibilidade JSON (MongoDB), até atingir a escala hiperdistribuída (Cassandra/ScyllaDB). Você domina as engrenagens da Internet Atual! ?????

?? CAPÍTULO 20: ESTUDO DE CASO (TecProExpress) E CONCLUSÃO

Nesta unidade final de engenharia de dados, nosso objetivo é aplicar todo o conhecimento acumulado em um cenário real da indústria. ?????

Objetivo: Consolidar a visão de arquiteto de dados através da modelagem, criação e manipulação de um sistema comercial completo (SGBD Relacional).

?? PASSO 1: O Mercado de Tecnologia

O domínio de SGBDs abre portas para as carreiras mais bem remuneradas do mercado global: ???

Área Profissional	Desafio e Foco
Engenharia de Software	Persistência de dados para apps escaláveis.
DBA (Admin)	Gerenciar infraestruturas críticas e performance.
Engenharia de Dados	Pipelines de Big Data e transformação de dados.
Cloud & DevOps	Soluções distribuídas em AWS/Azure/GCP.

?? PASSO 2: Ferramenta de Elite (PostgreSQL)

Recomendamos o PostgreSQL 17 para este estudo. Ele é o banco de dados livre mais robusto e próximo dos padrões globais ANSI SQL. ???

?? Dica do Mestre: O PostgreSQL é a escolha de grandes Unicórnios devido à sua conformidade rigorosa e suporte nativo a JSON (NoSQL) dentro do ambiente Relacional. ?????

?? CONTEXTUALIZAÇÃO: TecProExpress

A empresa TecProExpress solicita um sistema para gerenciar suas operações de venda. O objetivo estratégico é possuir controle total sobre o fluxo comercial. ?????

Objetivo: Analisar requisitos de negócio, identificar entidades e definir as restrições de integridade de um cenário comercial real.

?? PASSO 1: Levantamento de Requisitos

Para o desenvolvimento, foram identificadas as seguintes necessidades críticas: ???

?? Clientes: Cadastro e histórico (CNPJ/CPF, Localização).
?? Produtos: Gestão de itens com preços de mercado.
?? Vendedores: Controle de equipe para comissões.
?? Vendas: Registro imutável de transações financeiras.

??? Regras de Negócio (Integridade)

Uma Venda pertence a apenas um Cliente.
Uma Venda é realizada por apenas um Vendedor.
Uma Venda pode conter múltiplos Produtos (N:M).
O sistema opera em Matriz Centralizada.

?? PASSO 2: Identificação de Entidades

Após a análise, identificamos as seguintes tabelas lógicas: ???

?? CLIENTE
????? VENDEDOR
?? PRODUTO
?? VENDA
?? VENDA_ITENS (Tabela Associativa M:N)

?? Nota de Projeto: A entidade "Empresa" não será modelada como tabela, por ser um sistema exclusivo para uma unidade de negócio centralizada. ?????

?? MODELAGEM ER: TecProExpress

Para projetar um banco de dados de alto desempenho, mapeamos as entidades respeitando as regras de negócio. ?????

Objetivo: Visualizar a arquitetura do banco de dados comercial através de diagramas ER e compreender a integridade referencial dos relacionamentos 1:N e N:M.

?? PASSO 1: Diagrama de Entidade-Relacionamento

O diagrama abaixo consolida a estrutura profissional da TecProExpress: ???

?? Arquitetura de Dados Comercial

erDiagram
    CLIENTE ||--o{ VENDA : "possui"
    VENDEDOR ||--o{ VENDA : "realiza"
    VENDA ||--|{ VENDA_ITENS : "contém"
    PRODUTO ||--o{ VENDA_ITENS : "compõe"

    CLIENTE {
        int cli_id PK
        string cli_nome
        string cli_documento
    }
    VENDEDOR {
        int ven_id PK
        string ven_nome
        decimal ven_comissao
    }
    VENDA {
        int vda_id PK
        date vda_data
        int vda_cliente_id FK
        int vda_vendedor_id FK
    }
    VENDA_ITENS {
        int vdi_venda_id PK, FK
        int vdi_sequencia PK
        int vdi_produto_id FK
        decimal vdi_quantidade
        decimal vdi_preco_venda
    }
    PRODUTO {
        int prod_id PK
        string prod_nome
        decimal prod_preco_atual
    }

?? PASSO 2: Análise dos Relacionamentos

?? CLIENTE x VENDA (1:N): Um cliente realiza múltiplas compras históricas. ???
????? VENDEDOR x VENDA (1:N): Transação creditada a um vendedor responsável. ???
?? VENDA x VENDA_ITENS (1:N): A venda conecta a lista de itens físicos. ???
??? PRODUTO x VENDA_ITENS (1:N): O produto compõe diversos carrinhos de compra. ???

?? Valor Histórico: O preço do produto no momento da venda é armazenado em VENDA_ITENS. Isso garante que mudanças futuras no preço do produto não alterem o valor de vendas passadas. ???

??? MAPEAMENTO PARA O RELACIONAL

Chegamos ao ápice da nossa jornada! Vamos aplicar o conhecimento na prática para a fábrica TecProExpress. ?????

Objetivo: Implementar o esquema físico (DDL) e desenvolver consultas de inteligência de negócio (JOINs) para extrair faturamento e detalhes de vendas.

?? PASSO 1: Levantamento Estratégico

Antes de codificar, relembramos o coração do negócio: ???

?? PRODUTOS: Itens fabricados e preço sugerido.
?? CLIENTES: Quem consome nossos produtos profissionais.
?? VENDAS: Registro de faturamento e movimentação.
?? ITENS DA VENDA: O detalhamento técnico de cada fatura.

?? PASSO 2: Implementação do Esquema (DDL)

Criaremos as tabelas respeitando a Integridade Referencial: ???

-- 1. Tabelas Independentes
CREATE TABLE PRODUTOS (
    ID INT PRIMARY KEY,
    DESCRICAO VARCHAR(100) NOT NULL,
    VALOR_SUGERIDO DECIMAL(12,2)
);

CREATE TABLE CLIENTES (
    ID INT PRIMARY KEY,
    NOME VARCHAR(100) NOT NULL,
    ESTADO CHAR(2)
);

-- 2. Tabela de Movimentação
CREATE TABLE VENDA (
    ID INT PRIMARY KEY,
    DATA_MOVTO DATE DEFAULT CURRENT_DATE,
    CLIENTE_ID INT,
    VALOR_TOTAL DECIMAL(12,2),
    FOREIGN KEY (CLIENTE_ID) REFERENCES CLIENTES(ID)
);

-- 3. Detalhamento (Tabela Associativa)
CREATE TABLE VENDA_ITENS (
    VENDA_ID INT,
    SEQUENCIAL INT,
    PRODUTO_ID INT,
    QUANTIDADE DECIMAL(10,2),
    VALOR_UNIDADE DECIMAL(12,2), -- PREÇO HISTÓRICO
    PRIMARY KEY (VENDA_ID, SEQUENCIAL),
    FOREIGN KEY (VENDA_ID) REFERENCES VENDA(ID),
    FOREIGN KEY (PRODUTO_ID) REFERENCES PRODUTOS(ID)
);

?? PASSO 3: Inteligência de Negócio (SELECT)

Como extrair um relatório completo de faturamento? Usamos o JOIN: ???

SELECT 
    V.ID AS "Nº VENDA",
    C.NOME AS "CLIENTE",
    P.DESCRICAO AS "PRODUTO",
    VI.QUANTIDADE AS "QTD",
    VI.VALOR_UNIDADE AS "PREÇO UN.",
    (VI.QUANTIDADE * VI.VALOR_UNIDADE) AS "SUBTOTAL"
FROM VENDA V
JOIN CLIENTES C ON V.CLIENTE_ID = C.ID
JOIN VENDA_ITENS VI ON V.ID = VI.VENDA_ID
JOIN PRODUTOS P ON VI.PRODUTO_ID = P.ID;

?? Desafio de Especialista

Tente criar uma consulta que mostre o Faturamento Total por Estado.

?? Clique aqui para revelar a Solução (SPOILER) ??

SELECT C.ESTADO, SUM(V.VALOR_TOTAL) AS FATURAMENTO
FROM VENDA V
JOIN CLIENTES C ON V.CLIENTE_ID = C.ID
GROUP BY C.ESTADO
ORDER BY FATURAMENTO DESC;

?? Visão de Arquiteto: Note como a tabela VENDA_ITENS é o coração estrutural. Sem ela, você saberia quanto o cliente pagou, mas nunca saberia o que ele realmente levou. ???

?? CONCLUSÃO: ALÉM DO RELACIONAL

Concluir esta jornada é o sentimento de dever cumprido. O banco de dados é a base sólida para a lógica estratégica. ?????

Reflexão Final: O banco de dados é um detalhe vital, mas a verdadeira inovação é o software que resolve problemas reais e o valor que ele gera para a sociedade.

?? PASSO 1: Libertando-se da "Prisão Relacional"

Ao concluir este material, você domina a integração SQL. No entanto, o engenheiro moderno deve ter senso crítico: ???

?? NoSQL & Escalabilidade: Onde o modelo relacional encontra gargalos, o NoSQL brilha.
?? Arquitetura: Escolha as ferramentas pela eficiência, não por dogmas técnicos ou preferências.

?? PASSO 2: A Jornada Contínua

?? O Caminho que se Abre

flowchart LR
    Start(("🏁 Fim do Módulo")) --> Practice["🛠️ Prática de Engenharia"]
    Practice --> LearnNoSQL["📚 Domínio NoSQL/Híbrido"]
    Practice --> Cloud["☁️ Especialização Cloud"]
    Practice --> Innovation(("🚀 Inovação Profissional"))

Desejo sucesso em sua jornada como Arquiteto(a) e Engenheiro(a) de Dados. O fim é apenas o começo. ?????

?? REFERÊNCIAS BIBLIOGRÁFICAS

Fontes e acervos que fundamentaram este material técnico sobre Banco de Dados. ?????

??? Acervo de Referência

?? Serpro. PostgreSQL: um banco de dados para todos. Disponível aqui. ???
?? CARDOSO, V.; CARDOSO, G. Sistema de Banco de Dados: uma abordagem introdutória e aplicada. ???
?? CHEN, Peter. Gerenciando Banco de Dados: A Abordagem Entidade-Relacionamento para Projeto Lógico. ???
?? DATE, C. J. Bancos de dados: tópicos avançados. ???
?? MongoDB. 10 things you should know about NoSQL. Disponível aqui. ???
??? HEUSER, C. A. Projeto de banco de dados. 6. ed. ???
??? NAVATHE, S. B.; ELMASRI, R. Sistemas de Banco de Dados. 6. ed. ???
?? PRITCHET, E. Base: an acid alternative. Disponível aqui. ???
?? SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. ???
?? TAURION, C. Banco de dados Open Source: presente ou futuro? IBM. ???
?? ZHANG, J. Banco de dados na nuvem. IBM. ???

?? Aviso: As bibliografias listadas são referências clássicas. Recomenda-se a consulta das edições mais recentes para acompanhar as inovações de mercado. ???

📚 ATIVIDADES DE PROJETOS III — BANCO DE DADOS

Bem-vindo(a) ao módulo de Atividades Práticas de Projetos III. Este planejamento foi expandido para uma série de 20 Tutoriais Guiados para garantir uma evolução profissional, do setup ao desenvolvimento de arquiteturas de dados resilientes de alta performance. 🛡️🧩

🗺️ Visão Geral da Jornada (20 Tutoriais)

🪜 Escadinha do Conhecimento

flowchart TD
    subgraph Bloco1 ["Bloco I: Design & Modelagem"]
        A01["⚙️ Atv 01: Setup"] --> A02["📐 Atv 02: Modelagem"]
        A02 --> A03["➗ Atv 03: Mapeamento & Álgebra"]
        A03 --> A04["📏 Atv 04: Normalização"]
    end
    subgraph Bloco2 ["Bloco II: SQL & Programação Avançada"]
        A04 --> A05["🏗️ Atv 05: SQL DDL"]
        A05 --> A06["📝 Atv 06: SQL DML"]
        A06 --> A07["📊 Atv 07: SQL Avançado"]
        A07 --> A11["⚡ Atv 11: Índices & Otimização"]
        A11 --> A12["🔄 Atv 12: Transações & ACID"]
        A12 --> A13["🤖 Atv 13: Stored Proc & Triggers"]
    end
    subgraph Bloco3 ["Bloco III: Híbrido & NoSQL"]
        A13 --> A14["🗂️ Atv 14: SQL Híbrido (JSON)"]
        A14 --> A08["🍃 Atv 08: NoSQL MongoDB"]
        A08 --> A09["🏛️ Atv 09: NoSQL Cassandra"]
        A09 --> A15["🔑 Atv 15: Chave-Valor (Redis)"]
        A15 --> A16["🕸️ Atv 16: Grafos (Neo4j)"]
        A16 --> A17["🧠 Atv 17: Vetoriais (pgvector)"]
    end
    subgraph Bloco4 ["Bloco IV: Big Data, DevOps & Projetos"]
        A17 --> A18["📈 Atv 18: DW & OLAP"]
        A18 --> A19["🔄 Atv 19: Schema Migrations"]
        A19 --> A10["🏁 Atv 10: Projeto Final - F1"]
        A10 --> A20["🏆 Atv 20: Projeto Final - F2"]
    end

🛠️ Stack Tecnológica

Tecnologia	Ferramenta	Uso na Disciplina
🛢️ MySQL 8.4	Workbench	Atividades SQL e DDL/DML
🐘 PostgreSQL 17	pgAdmin / pgvector	Atividades SQL, DDL/DML, Índices, Transações, JSONB e Vetores
🍃 MongoDB 7.0	Compass	Atividade NoSQL (Documentos e Logs)
📦 Cassandra 4.x	Docker / cqlsh	Atividade NoSQL (Colunas e Alta Escala)
🔑 Redis 7.x	Docker / redis-cli	Atividade de Cache (Chave-Valor In-Memory)
🕸️ Neo4j 5.x	Browser / Cypher	Atividade de Bancos em Grafos
🐳 Docker	Desktop	Execução de containers de todos os SGBDs e NoSQL
🐙 GitHub	Repositório	Versionamento de todas as entregas

📁 Regras de Entrega

Cada aluno deve manter um único repositório público no GitHub com a seguinte estrutura de pastas:

📂 atividades-banco-de-dados/
├── 📂 bd-atv-01-setup/
├── 📂 bd-atv-02-modelagem/
├── 📂 bd-atv-03-mapeamento-algebra/
├── 📂 bd-atv-04-normalizacao/
├── 📂 bd-atv-05-sql-ddl/
├── 📂 bd-atv-06-sql-dml/
├── 📂 bd-atv-07-sql-avancado/
├── 📂 bd-atv-08-nosql-mongodb/
├── 📂 bd-atv-09-nosql-cassandra/
├── 📂 bd-atv-10-projeto-final/
├── 📂 bd-atv-11-indices-otimizacao/
├── 📂 bd-atv-12-transacoes-concorrencia/
├── 📂 bd-atv-13-triggers-procedures/
├── 📂 bd-atv-14-sql-hibrido-json/
├── 📂 bd-atv-15-chave-valor-redis/
├── 📂 bd-atv-16-grafos-neo4j/
├── 📂 bd-atv-17-vetoriais-pgvector/
├── 📂 bd-atv-18-data-warehousing-olap/
├── 📂 bd-atv-19-migrations-ci-cd/
└── 📂 bd-atv-20-projeto-final-avancado/

📅 Cronograma de Atividades vs Conteúdo Teórico

#	Tutorial	Capítulo de Referência (20 Semanas)
01	Setup do Ambiente	Cap. 01 e 04
02	Modelagem Conceitual	Cap. 05 e 06
03	Mapeamento e Álgebra	Cap. 07 e 09
04	Normalização	Cap. 10
05	SQL DDL (Estrutura)	Cap. 11 e 12
06	SQL DML (Dados)	Cap. 13 e 14
07	SQL Avançado (Relatórios)	Cap. 15
08	NoSQL MongoDB	Cap. 18
09	NoSQL Cassandra	Cap. 19
10	Projeto Integrador Final (Fase 1)	Cap. 20
11	Índices e Otimização	Cap. 16
12	Transações e ACID	Cap. 03
13	Stored Procedures & Triggers	Cap. 11, 13 e 16
14	SQL Híbrido com JSON	Cap. 18
15	Chave-Valor com Redis	Cap. 18 e 19
16	Grafos com Neo4j	Cap. 18 e 19
17	Bancos Vetoriais (pgvector)	Cap. 18, 19 e 20
18	Modelagem Dimensional DW	Cap. 19
19	Schema Migrations	Cap. 11 e 13
20	Projeto Final Avançado (Fase 2)	Cap. 20

💡 Dica do Especialista: A expansão de 20 atividades permite que você domine as tendências de Big Data, DevOps e IA aplicadas a bancos de dados. Siga o fluxo passo a passo e eleve o nível da sua arquitetura! 🚀🛡️

📅 CRONOGRAMA E PLANEJAMENTO — 20 SEMANAS

Planejamento semanal das atividades práticas de Projetos III — Banco de Dados, estruturado como uma jornada contínua de 20 Tutoriais Guiados. 🛡️🧩

🗓️ Visão Geral do Semestre (20 Semanas)

🏗️ BLOCO I — DESIGN & SQL ESSENCIAL (Semanas 1–7)

Semana	Capítulo de Aula (Referência)	Tutorial Prático
1	Cap. 01 & 04: Introdução & Setup de Ambientes	✅ Atv 01: Setup
2	Cap. 05 & 06: Modelagem MER e Tipos de Dados	✅ Atv 02: Modelagem
3	Cap. 07 & 09: Chaves, Mapeamento Relacional & Álgebra	✅ Atv 03: Mapeamento + Álgebra
4	Cap. 10: Normalização (1FN, 2FN e 3FN)	✅ Atv 04: Normalização
5	Cap. 11 & 12: Ecossistema SQL, DDL & Restrições	✅ Atv 05: SQL DDL
6	Cap. 13: Linguagem DML (INSERT, UPDATE, DELETE)	✅ Atv 06: SQL DML
7	Cap. 14 & 15: Consultas SELECT, JOINs & Subqueries	✅ Atv 07: SQL Avançado

📝 AVALIAÇÃO E INTRODUÇÃO AO NOSQL (Semanas 8–10)

Semana	Capítulo de Aula (Referência)	Tutorial Prático
8	📝 AVALIAÇÃO I (Design de Dados e Consultas SQL)	—
9	Cap. 18: Conceitos NoSQL & MongoDB	✅ Atv 08: NoSQL MongoDB
10	Cap. 19: Apache Cassandra & Big Data	✅ Atv 09: NoSQL Cassandra

⚡ BLOCO II — PERFORMANCE, TRANSAÇÕES & PROGRAMAÇÃO (Semanas 11–14)

Semana	Capítulo de Aula (Referência)	Tutorial Prático
11	Cap. 20: Consolidação SQL & NoSQL	✅ Atv 10: Projeto Final (Fase 1)
12	Cap. 16: Views, Índices B-Tree/Hash & Otimização	✅ Atv 11: Índices e Otimização
13	Cap. 03: Transações ACID, Isolamento & Concorrência	✅ Atv 12: Transações e ACID
14	Cap. 11, 13 & 16: Programação Procedural (Procedures/Triggers)	✅ Atv 13: Stored Proc & Triggers

🌐 BLOCO III — ARQUITETURAS MODERNAS & DEVOPs (Semanas 15–20)

Semana	Capítulo de Aula (Referência)	Tutorial Prático
15	Cap. 18: SQL Híbrido & JSONB nativo no Postgres	✅ Atv 14: SQL Híbrido com JSON
16	Cap. 18 & 19: Bancos In-Memory & Estruturas de Cache	✅ Atv 15: Chave-Valor com Redis
17	Cap. 18 & 19: Redes Conectadas & Modelagem de Grafos	✅ Atv 16: Grafos com Neo4j
18	Cap. 18, 19 & 20: IA Generativa & Busca Semântica	✅ Atv 17: Bancos Vetoriais (pgvector)
19	Cap. 19: Modelagem Dimensional DW & OLAP	✅ Atv 18: Modelagem Dimensional DW
20	Cap. 11, 13 & 20: DevOps, Schema Migrations & Encerramento	✅ Atv 19: Schema Migrations ✅ Atv 20: Projeto Final (Fase 2)

📈 Composição da Nota

Componente	Peso
Conjunto de 20 Tutoriais Práticos	50%
AVALIAÇÃO I (Design de Dados e Modelagem)	20%
AVALIAÇÃO II (Transações, Otimização e NoSQL)	20%
Apresentação do Projeto Final Poliglota	10%

📊 Pesos Individuais das Atividades (Total 5.0 pontos na Média Final)

Atividades	Grupo Pedagógico	Pontuação Unitária	Peso Total
Atv 01 a 07	Design & SQL Essencial	0.20 pt cada	1.40 pt
Atv 08 e 09	NoSQL & Multi-Model	0.20 pt cada	0.40 pt
Atv 10	Projeto Final - Fase 1 (Marco SQL/NoSQL)	0.60 pt	0.60 pt
Atv 11 a 19	Performance, Programação & Tecnologias Modernas	0.20 pt cada	1.80 pt
Atv 20	Projeto Final - Fase 2 (Marco Enterprise Poliglota)	0.80 pt	0.80 pt
Total	Todas as 20 Atividades Práticas	—	5.00 pts

🎯 ATIVIDADE 01 — O DATA HUB DO ARQUITETO

Bem-vindo ao início da sua jornada técnica no curso de Banco de Dados. Nesta primeira semana (4 aulas), vamos construir o seu "arsenal" de ferramentas. No mercado moderno, não basta conhecer um único banco; precisamos dominar a Persistência Poliglota. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Instalar e validar SGBDs Relacionais (MySQL e Postgres) e NoSQL (MongoDB e Cassandra).
Configurar o ecossistema de versionamento (Git/GitHub) para gestão de artefatos.
Estruturar um ambiente de documentação técnica usando draw.io para modelagem.
Entender o papel de cada ferramenta no stack de um Arquiteto de Dados.

🏢 O Cenário Prático (Seu Desafio)

Você acaba de ser contratado como Analista de Infraestrutura de Dados na TecProExpress. A empresa precisa que cada desenvolvedor tenha um "Data Hub" local completo para testes e modelagem. Seu desafio é preparar este ambiente e garantir que todas as "peças" se comuniquem.

🧠 Fundamentos: A Teoria Traduzida

Por que tantas ferramentas? No mundo real, os dados têm "formas" e "velocidades" diferentes.

flowchart TD
    Computer["🖥️ Seu Computador (Windows)"]
    
    subgraph RelationalSQL ["SGBDs Relacionais (SQL)"]
        Postgres["🐘 PostgreSQL (Porta 5432)"]
        MySQL["🐬 MySQL (Porta 3306)"]
    end
    
    subgraph NoSQLDB ["SGBDs NoSQL"]
        Mongo["🍃 MongoDB (Porta 27017)"]
        Cassandra["🏛️ Cassandra (Porta 9042 / Docker Container)"]
    end

    subgraph Tools ["Ferramentas de Suporte"]
        Git["🐙 Git / GitHub (Versionamento)"]
        Drawio["🎨 draw.io (Modelagem)"]
    end
    
    Computer === RelationalSQL
    Computer === NoSQLDB
    Computer === Tools
    
    style Computer fill:#eceff1,stroke:#37474f,stroke-width:2px
    style RelationalSQL fill:#e3f2fd,stroke:#1e88e5
    style NoSQLDB fill:#e8f5e9,stroke:#4caf50
    style Tools fill:#fff8e1,stroke:#ffb300

1. SGBDs Relacionais (SQL) - O Armário de Aço

Imagine um arquivo de aço com gavetas etiquetadas. Tudo tem lugar certo e regras rígidas (Esquema Fixo).

MySQL: O banco de dados mais popular do mundo para aplicações web.
PostgreSQL: O "banco dos especialistas", focado em complexidade e integridade.

2. SGBDs NoSQL - A Caixa Flexível

Dados que mudam de formato ou chegam em alta velocidade.

MongoDB (Documentos): Como uma pasta com arquivos JSON. Você guarda o que quiser.
Cassandra (Colunas): Projetado para escalas gigantescas (Big Data), onde os dados são espalhados por vários servidores.

3. Versionamento e Container - O Passaporte e o Navio

Git/GitHub: O histórico de tudo o que você constrói. Funciona como um "Save Game" do seu código.
Docker: Permite rodar bancos complexos (como o Cassandra) sem "sujar" o seu Windows, criando mini-computadores isolados.

🛠️ O Arsenal Tecnológico (Guia de Ferramentas)

🐬 MySQL & 🐘 PostgreSQL

São os motores relacionais que daremos suporte ao longo do curso. Para interagir com eles, usamos interfaces visuais robustas:

MySQL Server + Workbench: Download Oficial do MySQL (Recomendado o instalador completo para Windows).
PostgreSQL: Download Oficial do PostgreSQL (Recomendado Versão 16 ou 17. O instalador já inclui a ferramenta visual pgAdmin).
DBeaver Community: Download Oficial do DBeaver (Uma ferramenta universal e leve para gerenciar qualquer banco SQL via JDBC).

🍃 MongoDB Compass

Diferente do SQL, o MongoDB não usa tabelas rígidas. O Compass é a interface oficial para visualizar seus dados como documentos JSON flexíveis.

MongoDB Community Server + Compass: Download Oficial do MongoDB

🎨 draw.io: Sua Prancheta de Desenho

Antes de criar código, desenhamos a "Planta Baixa" dos dados (MER).

Como usar: Você pode usar online em draw.io ou baixar a versão Desktop. Ative a biblioteca de formas Entity Relation no canto inferior esquerdo para ter acesso aos símbolos do padrão pé de galinha.
Exportação: Sempre salve seu arquivo fonte no formato .drawio e exporte a imagem como .png (lembre-se de marcar a caixa "Incluir cópia do meu diagrama" para embutir os dados do draw.io na própria imagem).

🚀 Git & GitHub

O GitHub é o portfólio profissional do desenvolvedor moderno.

Git: Download Oficial do Git
Fluxo: Você faz o trabalho localmente -> git add . -> git commit -m "mensagem" -> git push para sincronizar com a nuvem.

📖 Exemplo Guiado: Validando a Saúde do Ambiente

Não basta instalar; é preciso testar se os "corações" dos bancos estão batendo nas portas corretas.

Ferramenta	Porta Padrão	O que testar?	Comando / Ação	Resultado Esperado
MySQL	`3306`	Conexão local	Abrir terminal e rodar `mysql -u root -p`	Prompt solicitando senha do admin
PostgreSQL	`5432`	Versão ativa	No pgAdmin ou DBeaver, rodar `SELECT version();`	Versão 16/17 no console de dados
MongoDB	`27017`	Serviço	Conectar o MongoDB Compass em `mongodb://localhost:27017`	Visualizar bancos de sistema (`admin`, `config`)
Git	N/A	Instalação	Rodar `git --version` no prompt/powershell	Exibição da versão do Git instalada

🛠️ Prática Obrigatória 1: Setup dos Motores

Cenário: Instalação oficial na TecProExpress.

Instalação: Faça o download e instale o PostgreSQL (com pgAdmin), o MySQL (com Workbench ou DBeaver) e o MongoDB Compass.
Cassandra via Docker: Abra o terminal do PowerShell/Bash e execute:
```
docker run --name cassandra-tecpro -p 9042:9042 -d cassandra
```
(Nota: O mapeamento -p 9042:9042 garante que o seu Windows consiga se comunicar com a porta padrão do Cassandra localmente).
Evidências: Capture screenshots (prints) mostrando:
- pgAdmin conectado ao PostgreSQL.
- DBeaver ou MySQL Workbench conectado ao MySQL.
- MongoDB Compass conectado com sucesso na porta 27017.
- O container do Cassandra rodando no Docker Desktop ou via comando docker ps.

🏁 Resultado Esperado (Para sua Referência)

Ao final, você terá os serviços de banco instalados, com conexões ativas nas portas locais (3306, 5432, 27017, 9042), prontos para as práticas do semestre.

🔍 Detalhamento Técnico:

Mapeamento de Portas (-p): Direciona o tráfego da rede local para dentro do container isolado.
LTS (Long Term Support): Em produção, sempre optamos por versões estáveis (LTS) dos bancos para evitar quebras em atualizações de sistemas legados.

🛠️ Prática Obrigatória 2: O Pipeline de Entrega

Cenário: Configuração do portfólio no GitHub.

Repositório: Crie um repositório público chamado atividades-banco-de-dados.
draw.io: Crie um diagrama conceitual simples chamado infra_hub.drawio.png mostrando seu computador conectando-se a caixas representando MySQL (3306), PostgreSQL (5432), MongoDB (27017) e Cassandra (9042).

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas instalações e versionar suas pastas:

Salve as evidências em uma pasta local estruturada.
Exporte o diagrama de arquitetura do draw.io no formato .drawio.png.
Certifique-se de fazer o push de sua pasta de setup para o seu repositório do GitHub.
Envie o link do seu repositório GitHub e anexe a imagem infra_hub.drawio.png na plataforma do Microsoft Teams. (Exemplo de entrega: Atividade_01_SeuNome.drawio.png e link do repositório).

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Por que um gestor de TI prefere que você use Docker para o Cassandra em vez de instalar diretamente no Windows? (Resposta: Portabilidade e facilidade de desinstalação sem deixar rastros no sistema). 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Sênior 🏆

Configure o DBeaver para conectar simultaneamente ao seu MySQL e ao seu PostgreSQL. Como isso facilita sua vida no dia a dia?

🔑 Gabarito de Código/Fórmulas Completo

Comandos de Versão:

-- Postgres/MySQL
SELECT version();

-- MongoDB
db.version();

-- Git
git --version

Comando Docker:

docker run --name cassandra-tecpro -p 9042:9042 -d cassandra

🎯 ATIVIDADE 02 — A PLANTA BAIXA DOS DADOS

Bem-vindo à segunda semana (4 aulas) do curso de Banco de Dados. Se na semana anterior preparamos as ferramentas, agora vamos aprender a usá-las para "desenhar" a solução. Na engenharia de software, antes de qualquer linha de código, criamos a Planta Baixa — o Modelo Entidade-Relacionamento (MER). 🛡️🧩

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Extrair Regras de Negócio de um briefing técnico.
Identificar e classificar Entidades, Atributos e Relacionamentos.
Definir Cardinalidades (1:1, 1:N, N:M) com precisão cirúrgica.
Construir diagramas profissionais no draw.io seguindo a notação de Peter Chen ou Crow's Foot.

🏢 O Cenário Prático (Seu Desafio)

A TecProExpress, uma gigante do e-commerce, precisa de um novo módulo para gerenciar suas Entregas de Última Milha. O Gerente de Operações descreveu a necessidade:

"Preciso cadastrar nossos Entregadores (nome, CPF, veículo). Cada entregador realiza diversas Entregas. Cada entrega pertence a um único Pedido (número do pedido, data, valor). Um pedido pode conter vários Produtos, e um mesmo produto pode estar em vários pedidos diferentes. Além disso, cada entrega é enviada para um Cliente (nome, endereço, CEP)."

Seu desafio como Arquiteto de Dados é transformar esse texto em um modelo que o banco de dados consiga entender.

🧠 Fundamentos: A Teoria Traduzida

Modelagem é a arte de ignorar o que não importa e focar no que é essencial.

1. Entidades (Os Substantivos)

São os objetos do mundo real sobre os quais queremos armazenar informações. Se você pode dar um nome e ele tem propriedades, é uma entidade.

Ex: CLIENTE, PRODUTO, VEÍCULO.

2. Atributos (Os Adjetivos)

São as características das entidades. Todo objeto tem detalhes que o definem.

Ex: O Cliente tem NOME, o Produto tem PREÇO.

3. Relacionamentos (Os Verbos)

É como as entidades interagem entre si.

Ex: Um Cliente FAZ um Pedido. Um Entregador CONDUZ um Veículo.

📊 Visualizando a Hierarquia de Abstração

flowchart TD
    A[Mundo Real] -->|Abstração| B[Modelo Conceitual - MER]
    B -->|Mapeamento| C[Modelo Lógico]
    C -->|Implementação| D[Modelo Físico - SQL]
    style B fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px

📖 Exemplo Guiado: Analisando Cardinalidade

A cardinalidade define o "ritmo" do negócio. Vamos analisar o relacionamento entre PEDIDO e PRODUTO:

Regra de Negócio	Cardinalidade	Notação (Crow's Foot)
Um Pedido pode ter muitos produtos	1:N	`
Um Produto pode estar em muitos pedidos	1:N	`
Resultado Final	N:M (Muitos para Muitos)	Necessita de tabela associativa no futuro

🛠️ Prática Obrigatória 1: O Mini-Mundo Logístico

Cenário: Identificação de componentes do cenário TecProExpress.

Liste as Entidades: Identifique pelo menos 4 entidades no texto do desafio.
Atributos: Para cada entidade, liste 3 atributos essenciais, marcando qual seria o Identificador Único (PK).
Relacionamentos: Descreva em texto os relacionamentos (Ex: Cliente Realiza Pedido).

🏁 Resultado Esperado (Para sua Referência)

Suas entidades principais devem ser: CLIENTE, PEDIDO, PRODUTO, ENTREGADOR.

🔍 Detalhamento das Regras:

CLIENTE: Pessoa física ou jurídica que gera a demanda (O "Quem").
PEDIDO: Documento que formaliza a transação (O "O que" e "Quando").
ENTREGADOR: O agente que executa o serviço de Last Mile.

🛠️ Prática Obrigatória 2: Modelagem no draw.io

Cenário: Transformação da análise em diagrama visual de banco de dados.

🧭 Mini-Guia do draw.io:

Acesse o site draw.io.
No menu esquerdo inferior, clique em Mais Formas (More Shapes).
Marque a caixa Relação de Entidades (Entity Relation) e clique em aplicar.
Utilize o componente retangular com três divisões para desenhar a Entidade (Nome) e seus Atributos (com PK marcada).
Para desenhar os relacionamentos com cardinalidade pé de galinha, use as setas do grupo "Relação de Entidades" (ex: as conexões de 1 para N possuem a barra vertical | de um lado e as três ramificações < do outro).
Exportação: Salve o arquivo fonte como .drawio e exporte a imagem final em formato .png (lembre-se de marcar a opção de embutir os metadados do diagrama na imagem).

📤 Instruções de Entrega (Microsoft Teams)

Após validar a estrutura visual do seu diagrama conceitual:

Certifique-se de que todas as entidades e cardinalidades (Crow's Foot) estão legíveis.
Salve o arquivo fonte do diagrama com a extensão .drawio.
Exporte a imagem em alta resolução no formato .png.
Envie ambos os arquivos (Atividade_02_SeuNome.drawio e Atividade_02_SeuNome.png) na tarefa correspondente no Microsoft Teams. (Nesta etapa, não há arquivos de código .sql a serem entregues).

💡 Checkpoint de Lógica

[!IMPORTANT] A Importância da Chave Primária: Por que não usamos o NOME de um cliente como identificador único? Na indústria, nomes se repetem (homônimos). Um erro na modelagem da PK (Primary Key) pode causar a mistura de dados de clientes diferentes. Sempre escolha atributos imutáveis e únicos, como CPF, Código de Barra ou IDs auto-incrementais. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto 🏆

Adicione ao modelo a entidade OCORRÊNCIA (Ex: "Endereço não encontrado", "Cliente ausente"). Uma Entrega pode ter várias ocorrências ao longo do tempo. Como isso altera o seu diagrama?

🔑 Gabarito de Código/Fórmulas

Prática 1 (Sugestão de Análise):

Entidades: CLIENTE, PEDIDO, PRODUTO, ENTREGADOR.
PKs sugeridas: CPF_Cliente, ID_Pedido, SKU_Produto, CPF_Entregador.

Prática 2 (Lógica do Diagrama):

CLIENTE (1) ---- <Realiza> ---- (N) PEDIDO
PEDIDO (N) ---- <Contém> ---- (M) PRODUTO
ENTREGADOR (1) ---- <Efetua> ---- (N) ENTREGA
ENTREGA (1) ---- <Refere-se> ---- (1) PEDIDO

🎯 ATIVIDADE 03 — DO DESENHO À GRADE

Bem-vindo à terceira semana (4 aulas) do curso de Banco de Dados. Agora que você já sabe "desenhar" as necessidades do cliente (Modelo Conceitual), vamos aprender a traduzir esse desenho para a linguagem que os computadores entendem: o Modelo Lógico (Relacional) e a matemática que rege tudo isso, a Álgebra Relacional. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Mapear Entidades e Relacionamentos para Tabelas e Colunas.
Implementar a Integridade Referencial através de Chaves Estrangeiras (FK).
Executar operações de Seleção, Projeção e Junção usando Álgebra Relacional.
Criar diagramas lógicos profissionais no draw.io.

🏢 O Cenário Prático (Seu Desafio)

A TecProExpress aprovou seu MER (Atividade 02). Agora, a equipe de desenvolvimento precisa que você entregue o Esquema Lógico. Eles precisam saber exatamente quais colunas cada tabela terá e como elas se conectam via IDs.

Além disso, o time de BI (Business Intelligence) solicitou que você descreva, de forma lógica, como extrair relatórios específicos (Ex: "Quais entregadores estão usando veículos do tipo 'Caminhão'?").

🧠 Fundamentos: A Teoria Traduzida

O mapeamento é a ponte entre o abstrato e o concreto.

1. A Anatomia do Mapeamento

Mapear é transformar "caixas" em "tabelas". Veja a regra visual:

graph LR
    subgraph Conceitual ["Nível Conceitual (MER)"]
    A["Entidade: CLIENTE"] --- B(("Atributo: Nome"))
    end
    
    Conceitual -->|Mapeamento| Logico
    
    subgraph Logico ["Nível Lógico (Tabelas)"]
    C["Tabela: cliente"]
    C --- D["Coluna: nome (VARCHAR)"]
    end
    
    style Conceitual fill:#e3f2fd,stroke:#1e88e5
    style Logico fill:#f1f8e9,stroke:#558b2f

2. Álgebra Relacional: Os Três Pilares

O banco de dados não "procura" dados; ele realiza operações matemáticas sobre conjuntos.

Operação	Símbolo	Função Visual	Analogia
Seleção	σ	Filtra Linhas	Um filtro de busca por preço
Projeção	π	Filtra Colunas	Escolher quais campos exibir
Junção	⋈	Combina Tabelas	Cruzar dados de duas planilhas

flowchart TD
    subgraph Sigma ["σ Seleção (Horizontal)"]
    S1[Linha 1] --- S2[Linha 2] --- S3[Linha 3]
    end
    
    subgraph Pi ["π Projeção (Vertical)"]
    P1[Coluna A] 
    P2[Coluna B]
    end
    
    Sigma -.->|Filtra| R1[Resultado]
    Pi -.->|Escolhe| R1

📖 Exemplo Guiado: Mapeando 1:N

No cenário da TecProExpress:

Entidade: ENTREGADOR (1)
Entidade: VEÍCULO (N) - Assumindo que um entregador pode usar vários veículos.

🏁 Resultado Esperado (Modelo Lógico)

ENTREGADOR (id PK, nome, cpf UNIQUE, telefone)
VEICULO (id PK, placa UNIQUE, modelo, ano, id_entregador FK)

🔍 Detalhamento do Mapeamento:

PK (Primary Key): Identificador único sequencial (geralmente numérico auto-incremental).
FK (Foreign Key): A PK do "lado 1" (Entregador) que viaja para o "lado N" (Veículo) como id_entregador.
UNIQUE: Restrição que impede duplicidade (ex: não podem existir dois entregadores com o mesmo CPF ou duas placas iguais).
Integridade: Garante que não exista um veículo sem um entregador responsável.

🛠️ Prática Obrigatória 1: Mapeamento Logístico

Cenário: Transformação do MER da TecProExpress para o Modelo Lógico.

Com base no cenário da Atividade 02, escreva o esquema lógico das tabelas: CLIENTE, PEDIDO, PRODUTO e ENTREGADOR.
Indique claramente quais são as Primary Keys (PK) e as Foreign Keys (FK).

🏁 Resultado Esperado (Para sua Referência)

CLIENTE (id PK, nome, cpf UNIQUE, endereco)
PEDIDO (id PK, data, id_cliente FK)
PRODUTO (id PK, sku UNIQUE, nome, preco)

🔍 Detalhamento das Decisões:

CLIENTE: Adotamos id como PK numérica para otimização do banco, mantendo o cpf como coluna UNIQUE (regra de negócio).
PEDIDO: Recebe id_cliente como FK para conectar com o cliente associado.
PRODUTO: Usa id como PK, mantendo o SKU como chave única secundária para fins de código de barras industrial.

🛠️ Prática Obrigatória 2: Laboratório de Álgebra

Cenário: Extração de lógica para relatórios usando as tabelas abaixo (Seeds).

📋 Seed: Tabela ENTREGADOR

cpf	nome	veiculo_id
111	Ana Silva	10
222	João Souza	20
333	Bia Costa	10

📋 Seed: Tabela VEICULO

id	tipo	modelo
10	Caminhão	Mercedes 710
20	Moto	Honda Cargo

🚀 Script de Seed (SQL)

-- PASSO 1: Criar as Tabelas (Estrutura)
CREATE TABLE veiculo (
    id INT PRIMARY KEY,
    tipo VARCHAR(50),
    modelo VARCHAR(100)
);

CREATE TABLE entregador (
    cpf VARCHAR(11) PRIMARY KEY,
    nome VARCHAR(100),
    veiculo_id INT,
    FOREIGN KEY (veiculo_id) REFERENCES veiculo(id)
);

-- PASSO 2: Popular as Tabelas (Dados)
INSERT INTO veiculo (id, tipo, modelo) VALUES (10, 'Caminhão', 'Mercedes 710');
INSERT INTO veiculo (id, tipo, modelo) VALUES (20, 'Moto', 'Honda Cargo');

INSERT INTO entregador (cpf, nome, veiculo_id) VALUES ('111', 'Ana Silva', 10);
INSERT INTO entregador (cpf, nome, veiculo_id) VALUES ('222', 'João Souza', 20);
INSERT INTO entregador (cpf, nome, veiculo_id) VALUES ('333', 'Bia Costa', 10);

🔍 Detalhamento do Seed:

Ordem: Inserimos primeiro o VEICULO porque o ENTREGADOR depende dele (FK).
Vínculo: Note que o veiculo_id 10 é compartilhado por Ana e Bia.

📤 Instruções de Entrega (Microsoft Teams)

Após finalizar o mapeamento e as fórmulas matemáticas:

Digite a sua resposta contendo o mapeamento lógico e as fórmulas equivalentes da Álgebra Relacional (pode ser em formato texto no Word/Markdown ou PDF).
Salve o arquivo com a nomenclatura Atividade_03_SeuNome.pdf ou Atividade_03_SeuNome.md.
Envie a resposta na plataforma correspondente do Microsoft Teams para avaliação técnica. (Esta atividade é conceitual e foca na matemática relacional, sem necessidade de código .sql executável).

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Imagine que você tem 1 milhão de clientes. É mais eficiente fazer a Seleção (σ) antes ou depois da Junção (⋈)? Na indústria, filtrar os dados antes de cruzar tabelas economiza processamento e tempo. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Expert 🏆

O relacionamento entre PEDIDO e PRODUTO é Muitos para Muitos (N:M). Como mapear isso para o modelo lógico?

🏁 Resultado Esperado do Desafio

ITEM_PEDIDO (id_pedido FK, sku_produto FK, quantidade)

🔍 Explicação da Solução:

Relacionamentos N:M sempre geram uma terceira tabela (Associativa). Esta tabela carrega as chaves estrangeiras de ambos os lados e as transforma em uma Chave Primária Composta.

🔑 Gabarito de Código/Fórmulas Completo

Prática 1 (Mapeamento Completo):

CLIENTE (id PK, nome, cpf UNIQUE, endereco)
PRODUTO (id PK, sku UNIQUE, nome, preco)
PEDIDO (id PK, data, id_cliente FK, id_entregador FK)
ENTREGADOR (id PK, nome, cpf UNIQUE, veiculo_id FK)
VEICULO (id PK, placa UNIQUE, modelo, tipo)

Prática 2 (Álgebra vs SQL Passo a Passo):

Objetivo: Nomes dos Entregadores.
- Fórmula: π nome (ENTREGADOR)
- SQL Equivalente:
```
SELECT nome FROM entregador;
```
Objetivo: Filtro de Caminhões.
- Fórmula: σ tipo='Caminhão' (VEICULO)
- SQL Equivalente:
```
SELECT * FROM veiculo WHERE tipo = 'Caminhão';
```
Objetivo: Cruzamento de Dados (Nome + Modelo).
- Fórmula: π nome, modelo (ENTREGADOR ⋈ veiculo_id=id VEICULO)
- SQL Equivalente:
```
SELECT e.nome, v.modelo 
FROM entregador e 
INNER JOIN veiculo v ON e.veiculo_id = v.id;
```

Desafio (Mapeamento N:M):

Lógico: ITEM_PEDIDO (id_pedido FK, sku_produto FK, quantidade)

SQL de Criação:

CREATE TABLE item_pedido (
    id_pedido INT,
    sku_produto VARCHAR(50),
    quantidade INT,
    PRIMARY KEY (id_pedido, sku_produto),
    FOREIGN KEY (id_pedido) REFERENCES pedido(id),
    FOREIGN KEY (sku_produto) REFERENCES produto(sku)
);

🎯 ATIVIDADE 04 — A ARTE DA ORGANIZAÇÃO

Bem-vindo à quarta semana (4 aulas) do curso de Banco de Dados. Até aqui, você aprendeu a modelar o mundo real. Mas, às vezes, nossa modelagem inicial contém "armadilhas" — dados repetidos que causam erros. Hoje, vamos aprender a técnica de Normalização, o processo de refinamento que separa o bom design do amadorismo. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Identificar e corrigir Anomalias de Inserção, Exclusão e Alteração.
Aplicar a 1ª Forma Normal (1FN): Atomicidade.
Aplicar a 2ª Forma Normal (2FN): Dependência Total.
Aplicar a 3ª Forma Normal (3FN): Dependência Transitiva.

🏢 O Cenário Prático (Seu Desafio)

A TecProExpress herdou um banco de dados de uma empresa adquirida. Os dados estão em uma única tabela chamada PLANILHA_MESTRA. Quando um cliente muda de endereço, o sistema precisa atualizar centenas de linhas, gerando inconsistências.

📋 Seed: A Planilha "Bagunçada" (Não Normalizada)

Cod_Ped	Cliente	Endereco	Produtos	Valor_Un
1001	João Silva	Rua A, 10	Pneus, Óleo	400.00, 50.00
1002	Maria Souza	Rua B, 20	Filtro Ar	80.00

🧠 Fundamentos: A Teoria Traduzida

Normalizar é como organizar uma biblioteca por categorias, autores e títulos, em vez de empilhar tudo na entrada.

O Fluxo da Organização

Veja como os dados "evoluem" durante a normalização:

flowchart TD
    subgraph Erro ["Estado Crítico"]
    A["Tabela Única (Caos)"]
    end
    
    subgraph FN1 ["1ª Forma Normal"]
    B["Valores Atômicos (Sem listas)"]
    end
    
    subgraph FN2 ["2ª Forma Normal"]
    C["Chaves Primárias Definidas"]
    end
    
    subgraph FN3 ["3ª Forma Normal"]
    D["Tabelas Independentes (Padrão Indústria)"]
    end
    
    A -->|Dividir listas| B
    B -->|Mover campos parciais| C
    C -->|Mover campos indiretos| D
    
    style A fill:#ffcdd2
    style D fill:#c8e6c9

📖 Exemplo Guiado: Aplicando a 1FN

Problema: A coluna Produtos tem "Pneus, Óleo". O banco de dados não consegue somar o estoque assim. Solução: Cada produto deve ter sua própria linha.

Cod_Ped	Produto
1001	Pneus
1001	Óleo

🛠️ Prática Obrigatória 1: Diagnóstico de Anomalias

Cenário: Analise a PLANILHA_MESTRA da TecProExpress.

Aponte 2 anomalias que ocorrem se deletarmos o pedido 1002.
Explique por que o endereço do cliente não deve ficar na tabela de pedidos.

🏁 Resultado Esperado (Para sua Referência)

Anomalia de Exclusão: Ao deletar o pedido, perdemos os dados de contato da Maria Souza.
Redundância: O endereço se repete em cada pedido do mesmo cliente.

🛠️ Prática Obrigatória 2: O Esquema 3FN

Cenário: Projete o banco normalizado no draw.io.

Crie tabelas separadas para: CLIENTE, PEDIDO, PRODUTO e ITEM_PEDIDO.
Mova o Endereco para a tabela CLIENTE.
Mova o Valor_Un para a tabela PRODUTO.

🏁 Resultado Esperado (Seed das Tabelas Normalizadas)

Tabela CLIENTE:

id	nome	endereco
1	João Silva	Rua A, 10

Tabela ITEM_PEDIDO:

id_ped	id_prod	qtd
1001	50 (Pneu)	2

🔍 Detalhamento Técnico:

Atomicidade: Agora cada célula tem apenas um valor.
Relacionamento: Usamos IDs (FKs) para conectar as tabelas sem repetir nomes ou endereços.

📤 Instruções de Entrega (Microsoft Teams)

Após projetar seu banco de dados normalizado na 3ª Forma Normal:

Exporte a imagem do diagrama conceitual/lógico normalizado no formato .png.
Salve o arquivo fonte do draw.io no formato .drawio.
Caso tenha escrito scripts SQL adicionais para testes, você pode anexá-los.
Envie ambos os arquivos (Atividade_04_SeuNome.drawio e Atividade_04_SeuNome.png) na tarefa correspondente no Microsoft Teams para validação de integridade física.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Um banco normalizado economiza espaço em disco, mas exige mais "JOINS" nas consultas. Na TecProExpress, a prioridade é a Integridade dos Dados. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Expert 🏆

Onde você armazenaria o Preço de Venda? Na tabela PRODUTO ou na tabela ITEM_PEDIDO? (Dica: Pense no que acontece se o preço do produto mudar amanhã).

🔑 Gabarito de Código/Fórmulas Completo

Mapeamento 3FN Final:

CLIENTE (id PK, nome, endereco)
PRODUTO (id PK, descricao, valor_unitario)
PEDIDO (id PK, data, id_cliente FK)
ITEM_PEDIDO (id_pedido FK, id_produto FK, quantidade, valor_historia)

SQL de Criação (Gabarito):

CREATE TABLE cliente (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(100),
    endereco VARCHAR(200)
);

CREATE TABLE item_pedido (
    id_pedido INT,
    id_produto INT,
    quantidade INT,
    PRIMARY KEY (id_pedido, id_produto),
    FOREIGN KEY (id_pedido) REFERENCES pedido(id),
    FOREIGN KEY (id_produto) REFERENCES produto(id)
);

🔍 Explicação do Gabarito:

PRIMARY KEY (id_pedido, id_produto): Garante que um produto não seja inserido duas vezes no mesmo pedido.
valor_historia: Armazena o preço cobrado no dia, garantindo que relatórios antigos não mudem de valor se o produto encarecer hoje.

🎯 ATIVIDADE 05 — LEVANTANDO AS PAREDES

Bem-vindo à quinta semana (4 aulas) do curso de Banco de Dados. Hoje vamos abrir o terminal e "levantar as paredes" do nosso sistema usando a DDL (Data Definition Language). No mercado, um script DDL bem escrito é a fundação de qualquer software de sucesso. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Criar bancos de dados reais no MySQL e PostgreSQL.
Implementar tabelas usando o comando CREATE TABLE.
Configurar restrições de integridade (PK, FK, NOT NULL, UNIQUE, CHECK).
Dominar a Ordem de Criação dos objetos.

🏢 O Cenário Prático (Seu Desafio)

A TecProExpress precisa que você execute o script oficial de criação do banco. O CTO exige que o script seja "limpo" e que as chaves estrangeiras tenham nomes padronizados (ex: fk_pedido_cliente).

📊 Hierarquia de Criação (O que vem primeiro?)

Para evitar erros de "tabela não encontrada", siga esta ordem lógica:

graph TD
    A["1. Tabelas Independentes (Pais)"] --> B["2. Tabelas Dependentes (Filhos)"]
    B --> C["3. Tabelas Associativas (Netos)"]
    
    subgraph Exemplos
    E1[CLIENTE] --- E2[PRODUTO]
    E3[PEDIDO] --- E4[ITEM_PEDIDO]
    end
    
    E1 --> E3
    E2 --> E4
    E3 --> E4
    
    style A fill:#e8f5e9
    style C fill:#fffde7

🧠 Fundamentos: A Teoria Traduzida

DDL é a engenharia civil dos dados.

Comando	Função	Analogia
CREATE	Cria objetos	Construir a casa
ALTER	Modifica objetos	Fazer uma reforma
DROP	Deleta objetos	Demolir a estrutura

📖 Exemplo Guiado: Criando a Tabela Produto

Veja como definir tipos de dados e restrições no PostgreSQL (SGBD Foco) e no MySQL (Comparação).

🐬 Iniciando o Banco de Dados

Antes de criar qualquer tabela, é mandatório criar o container lógico (Banco de Dados) e dizer ao SGBD qual banco utilizar:

-- Executar no Console de Query (pgAdmin/DBeaver/Workbench)
CREATE DATABASE tecpro_express;

No pgAdmin (PostgreSQL), após criar o banco, você deve clicar com o botão direito no banco tecpro_express na árvore de navegação esquerda e selecionar Query Tool para garantir que as tabelas sejam criadas dentro dele. No MySQL Workbench/DBeaver, use o comando:

USE tecpro_express;

🛠️ Código do Exemplo (Equivalência Relacional)

```sql
-- 🐘 Padrão PostgreSQL (pgAdmin)
CREATE TABLE produto (
    id SERIAL PRIMARY KEY,               -- SERIAL gera inteiros sequenciais automáticos
    nome VARCHAR(100) NOT NULL,          -- Texto obrigatório
    preco DECIMAL(10,2) CHECK (preco > 0) -- Validação de integridade física
);

-- 🐬 Padrão MySQL (Workbench)
CREATE TABLE produto (
    id INT PRIMARY KEY AUTO_INCREMENT,   -- AUTO_INCREMENT gera inteiros sequenciais
    nome VARCHAR(100) NOT NULL,
    preco DECIMAL(10,2) CHECK (preco > 0)
);


#### 🔍 Detalhamento do Código:
*   `SERIAL` vs `AUTO_INCREMENT`: Ambas as cláusulas servem para gerar números sequenciais únicos automáticos (Chaves Primárias Surrogadas). O PostgreSQL usa o tipo virtual `SERIAL`, enquanto o MySQL usa o modificador `AUTO_INCREMENT` no tipo `INT`.
*   `DECIMAL(10,2)`: Ideal para armazenar valores monetários (10 dígitos totais de precisão, sendo 2 após a vírgula).
*   `CHECK`: Restrição física de coluna que impede que a **TecProExpress** registre preços menores ou iguais a zero.

---

## 🛠️ Prática Obrigatória 1: Script de Infraestrutura
**Cenário:** Criação das tabelas `CLIENTE` e `PEDIDO`.

1.  A tabela `CLIENTE` deve ter um ID auto-incremental e um CPF único.
2.  A tabela `PEDIDO` deve ter uma FK apontando para `CLIENTE`.

### 🏁 Resultado Esperado (Seed Visual)
Ao rodar `DESCRIBE pedido;` no seu banco, você deverá ver:
*   `id_cliente` marcado como **MUL** (Multiple) ou **FK**.

---

## 🛠️ Prática Obrigatória 2: O Elo Perdido (Associativa)
**Cenário:** Implementação da tabela `ITEM_PEDIDO`.

1.  Esta tabela deve conectar `PEDIDO` e `PRODUTO` (Tabela Associativa N:M).
2.  Adicione a coluna `quantidade` com valor padrão **1**.
3.  Implemente a **Chave Primária Composta** formada pelas duas chaves estrangeiras.

### 🏁 Resultado Esperado (Script SQL Correto)
```sql
CREATE TABLE item_pedido (
    id_pedido INT,
    id_produto INT,
    quantidade INT DEFAULT 1,
    PRIMARY KEY (id_pedido, id_produto),
    CONSTRAINT fk_item_pedido_ped FOREIGN KEY (id_pedido) REFERENCES pedido(id),
    CONSTRAINT fk_item_pedido_prod FOREIGN KEY (id_produto) REFERENCES produto(id)
);

📤 Instruções de Entrega (Microsoft Teams)

Após testar os comandos e confirmar a criação bem-sucedida das tabelas no pgAdmin (ou SGBD de sua preferência):

Organize as instruções em ordem cronológica de criação (pais antes dos filhos).
Salve as instruções SQL em um único arquivo de texto com a extensão .sql contendo CREATE DATABASE no início.
Envie o arquivo (Atividade_05_SeuNome.sql) na tarefa correspondente no Microsoft Teams para avaliação de sintaxe e restrições.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: O que acontece se você tentar deletar um CLIENTE que já tem PEDIDOS cadastrados? O banco impedirá a exclusão para proteger a Integridade Referencial. Isso é segurança de dados na prática! 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto 🏆

Pesquise a diferença entre INT, BIGINT e SERIAL. Qual deles você usaria para um sistema que processa 1 bilhão de entregas por mês?

🔑 Gabarito de Código/Fórmulas Completo

🐘 Gabarito Oficial PostgreSQL (pgAdmin)

-- 1. Criar Banco de Dados
CREATE DATABASE tecpro_express;
-- (Nota: No pgAdmin, lembre-se de abrir uma Query Tool apontando para o banco tecpro_express após criá-lo)

-- 2. Criar Tabelas Pais
CREATE TABLE cliente (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(100) NOT NULL,
    cpf CHAR(11) UNIQUE
);

CREATE TABLE produto (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(100) NOT NULL,
    preco DECIMAL(10,2) CHECK (preco > 0)
);

-- 3. Criar Tabela Dependente (Filho)
CREATE TABLE pedido (
    id SERIAL PRIMARY KEY,
    data_ped DATE,
    id_cliente INT,
    CONSTRAINT fk_ped_cli FOREIGN KEY (id_cliente) REFERENCES cliente(id)
);

-- 4. Criar Tabela Associativa (Neto)
CREATE TABLE item_pedido (
    id_pedido INT,
    id_produto INT,
    quantidade INT DEFAULT 1,
    PRIMARY KEY (id_pedido, id_produto),
    CONSTRAINT fk_item_ped FOREIGN KEY (id_pedido) REFERENCES pedido(id),
    CONSTRAINT fk_item_prod FOREIGN KEY (id_produto) REFERENCES produto(id)
);

🐬 Gabarito Alternativo MySQL (DBeaver / Workbench)

-- 1. Criar e Usar Banco
CREATE DATABASE tecpro_express;
USE tecpro_express;

-- 2. Criar Tabelas Pais
CREATE TABLE cliente (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(100) NOT NULL,
    cpf CHAR(11) UNIQUE
);

CREATE TABLE produto (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(100) NOT NULL,
    preco DECIMAL(10,2) CHECK (preco > 0)
);

-- 3. Criar Tabela Dependente
CREATE TABLE pedido (
    id INT PRIMARY KEY AUTO_INCREMENT,
    data_ped DATE,
    id_cliente INT,
    CONSTRAINT fk_ped_cli FOREIGN KEY (id_cliente) REFERENCES cliente(id)
);

-- 4. Criar Tabela Associativa
CREATE TABLE item_pedido (
    id_pedido INT,
    id_produto INT,
    quantidade INT DEFAULT 1,
    PRIMARY KEY (id_pedido, id_produto),
    CONSTRAINT fk_item_ped FOREIGN KEY (id_pedido) REFERENCES pedido(id),
    CONSTRAINT fk_item_prod FOREIGN KEY (id_produto) REFERENCES produto(id)
);

🔍 Explicação do Gabarito:

Ordem de Criação: Os bancos de dados exigem que tabelas sem Foreign Keys (cliente, produto) sejam criadas primeiro, antes das tabelas que fazem referência a elas (pedido, item_pedido). Caso contrário, ocorrerá erro de referência.
UNIQUE: Garante a integridade lógica (ex: impossibilita que dois clientes compartilhem o mesmo CPF).
CONSTRAINT: Dar nomes explícitos às chaves estrangeiras (ex: fk_ped_cli) facilita diagnósticos de erros e remoção de restrições em updates de produção.

🎯 ATIVIDADE 06 — MOBILIANDO A CASA

Bem-vindo à sexta semana (4 aulas) do curso de Banco de Dados. Sua estrutura teórica já está pronta. Agora, vamos "mobiliar" o sistema — inserir dados reais e aprender a fazer as perguntas certas ao banco de dados usando a DML (Data Manipulation Language). 🛡️🧩

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Inserir registros usando o comando INSERT INTO.
Consultar dados de forma seletiva com SELECT e WHERE.
Utilizar Operadores Lógicos (e / ou) para filtrar resultados com precisão.
Ordenar informações com ORDER BY.

🏢 O Cenário Prático (Seu Desafio)

A TecProExpress iniciou suas operações! Você recebeu uma lista de clientes iniciais e produtos. Seu desafio é popular o banco e gerar os primeiros relatórios para a gerência.

[!IMPORTANT] A Regra de Ouro: Você não pode colocar móveis em uma casa que ainda não tem paredes. No banco de dados, primeiro CRIAMOS a tabela (DDL) e depois INSERIMOS os dados (DML).

🧠 Fundamentos: A Teoria Traduzida

Consultar o banco é como usar o filtro de pesquisa do Instagram ou da Amazon.

O Fluxo da Pergunta (SELECT)

Veja como o banco processa sua solicitação:

flowchart LR
    A[1. Tabela Criada] --> B[2. Dados Inseridos]
    B --> C{"3. WHERE: Filtro"}
    C -- Atende --> D[Exibir Linha]
    C -- Não Atende --> E[Descartar]
    D --> F["4. ORDER BY: Ordenação"]
    
    style A fill:#e8f5e9
    style B fill:#fffde7

📖 Exemplo Guiado: O Passo a Passo Completo

Para quem está começando, este é o fluxo obrigatório para qualquer banco de dados.

1. Criando o "Espaço" (DDL)

-- Primeiro, criamos a tabela para receber os produtos
CREATE TABLE produto (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(100),
    preco DECIMAL(10,2)
);

2. Inserindo a "Mobília" (DML)

-- Agora que a tabela existe, inserimos os dados
INSERT INTO produto (nome, preco) VALUES 
('Smartphone X', 2500.00),
('Cabo USB', 25.00),
('Monitor 4K', 1800.00);

3. Fazendo a Pergunta (Query)

-- Selecionamos apenas o que nos interessa
SELECT nome, preco FROM produto WHERE preco > 100 AND preco < 2000;

🔍 Detalhamento do Código:

CREATE TABLE: Prepara o terreno. Sem isso, o comando INSERT dá erro de "Table doesn't exist".
INSERT INTO: "Empurra" os dados para dentro das colunas nome e preco.
AND: O operador e exige que as duas condições sejam verdadeiras ao mesmo tempo.

🛠️ Prática Obrigatória 1: Populando a TecProExpress

Cenário: Carga inicial de teste.

Crie a tabela cliente com as colunas id, nome e cidade.
Insira 5 Clientes (use cidades como 'São Paulo', 'Curitiba' e 'Santos').

🚀 Script de Seed Completo (SQL)

[!TIP] Copie e cole este bloco no seu SGBD para garantir que o ambiente esteja pronto:

-- PASSO 1: Criar a tabela
CREATE TABLE cliente (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(100),
    cidade VARCHAR(50)
);

-- PASSO 2: Inserir os dados
INSERT INTO cliente (nome, cidade) VALUES 
('Marcos Silva', 'São Paulo'),
('Julia Costa', 'Curitiba'),
('Roberto Dias', 'Santos'),
('Ana Paula', 'São Paulo'),
('Lucas Melo', 'Santos');

🛠️ Prática Obrigatória 2: Relatórios de Operação

Cenário: O Gerente solicitou dados específicos.

Filtro Flexível (ou): Liste os clientes que moram em 'São Paulo' ou 'Santos'.
Ordenação: Liste todos os produtos do mais caro para o mais barato (DESC).

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus códigos SQL locais:

Certifique-se de que os seus comandos INSERT INTO e SELECT estão em conformidade com o padrão ANSI SQL.
Salve os comandos em um único arquivo de script com a extensão .sql (Ex: Atividade_06_SeuNome.sql).
Certifique-se de incluir comentários no código explicando o papel dos filtros lógicos AND (operador e para restringir linhas) e OR (operador ou para ampliar critérios) nas consultas.
Envie o arquivo .sql correspondente no Microsoft Teams para avaliação técnica.

💡 Checkpoint de Lógica

[!IMPORTANT] Dica para Iniciantes: Sempre que você fechar seu banco de dados e abrir de novo, verifique se a tabela ainda existe. Se você estiver usando um banco em memória ou temporário, precisará rodar o CREATE TABLE novamente antes de inserir dados. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Analista Sênior 🏆

Use o operador LIKE para encontrar todos os clientes cujo nome comece com a letra "A". Como o WHERE se comporta nesse caso?

🔑 Gabarito de Código/Fórmulas Completo

Consultas da Prática 2:

-- 1. Filtro Flexível (OU)
SELECT * FROM cliente 
WHERE cidade = 'São Paulo' OR cidade = 'Santos';

-- 2. Ordenação Decrescente (Z-A / Maior-Menor)
SELECT * FROM produto 
ORDER BY preco DESC;

🔍 Explicação do Gabarito:

OR: Traz registros que atendam a QUALQUER uma das condições.
DESC: Inverte a ordem natural. No preço, coloca o mais caro primeiro.

🎯 ATIVIDADE 07 — O PODER DA INFORMAÇÃO

Bem-vindo à sétima semana (4 aulas) do curso de Banco de Dados. Agora que você já sabe inserir dados e fazer filtros básicos, vamos aprender o que realmente torna um Analista de Dados valioso: a capacidade de cruzar informações de tabelas diferentes e realizar cálculos automáticos. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Realizar junções entre tabelas usando INNER JOIN.
Utilizar funções de agregação (COUNT, SUM, AVG, MAX, MIN).
Agrupar resultados com GROUP BY.
Filtrar grupos com HAVING.

🏢 O Cenário Prático (Seu Desafio)

O Diretor Financeiro da TecProExpress precisa de um relatório consolidado. Ele não quer ver apenas "quem comprou", ele quer saber o Total Gasto por Cliente e quais são os Produtos mais vendidos.

Para isso, você precisará conectar as tabelas CLIENTE, PEDIDO e ITEM_PEDIDO, realizando somas e contagens automáticas.

🧠 Fundamentos: A Teoria Traduzida

Dados isolados são apenas registros. Dados cruzados são Inteligência de Negócio.

1. O Aperto de Mão (INNER JOIN)

Imagine que a tabela CLIENTE tem o nome e a tabela PEDIDO tem a data. O JOIN é o ponto de encontro onde o id_cliente de ambas as tabelas se reconhece.

graph LR
    A["CLIENTE (ID: 1, Nome: Ana)"] -- "id_cliente = id_cliente" --- B["PEDIDO (ID: 101, Data: 12/05)"]
    style A fill:#e3f2fd
    style B fill:#fffde7

2. A Calculadora do Banco (Agregações)

Em vez de somar na mão, o banco faz por você:

COUNT: Conta quantas linhas existem.
SUM: Soma valores numéricos.
AVG: Calcula a média.

📖 Exemplo Guiado: Relatório de Vendas

Veja como unir tabelas e somar valores em um único comando.

1. Preparando o Ambiente (DDL e Seed)

-- Estrutura Simplificada
CREATE TABLE categoria (id INT PRIMARY KEY, nome VARCHAR(50));
CREATE TABLE produto (id INT PRIMARY KEY, nome VARCHAR(50), preco DECIMAL(10,2), cat_id INT);

-- Seed
INSERT INTO categoria VALUES (1, 'Eletrônicos'), (2, 'Acessórios');
INSERT INTO produto VALUES (1, 'Mouse', 50.00, 2), (2, 'Teclado', 150.00, 2), (3, 'Monitor', 900.00, 1);

2. A Consulta com JOIN e SUM

-- Qual o valor total em estoque por categoria?
SELECT c.nome, SUM(p.preco) AS total_estoque
FROM categoria c
INNER JOIN produto p ON c.id = p.cat_id
GROUP BY c.nome;

🔍 Detalhamento do Código:

INNER JOIN ... ON: Diz ao banco: "Traga apenas os produtos que possuem uma categoria válida".
SUM(p.preco): Soma os preços de todos os produtos que caírem no mesmo grupo.
GROUP BY: Organiza os resultados em "gavetas" pelo nome da categoria.

🛠️ Prática Obrigatória 1: Agregando Valores

Cenário: Análise de inventário da TecProExpress.

Escreva uma consulta que conte quantos clientes existem cadastrados.
Escreva uma consulta que mostre o preço do produto mais caro e do mais barato.
Calcule a média de preços de todos os produtos.

🏁 Resultado Esperado (Seed Visual)

O resultado deve ser um valor único (ex: "Média: 450.50").

🛠️ Prática Obrigatória 2: O Grande Relatório (Join)

Cenário: Cruzamento de Pedidos e Clientes.

Liste o Nome do Cliente e a Data do Pedido de todos os pedidos realizados.
Desafio de Agrupamento: Mostre o nome do cliente e quantos pedidos cada um realizou até agora.

🚀 Script de Seed para Teste (SQL)

-- Use as tabelas da Atividade 06 e adicione estes dados:
INSERT INTO pedido (data_ped, id_cliente) VALUES 
('2026-05-01', 1),
('2026-05-02', 1),
('2026-05-03', 2);

📤 Instruções de Entrega (Microsoft Teams)

Após testar suas consultas agrupadas e junções no pgAdmin (ou SGBD de sua escolha):

Formate suas consultas mantendo palavras-chave em maiúsculas (ex: SELECT, INNER JOIN, GROUP BY, HAVING).
Salve todas as queries da Prática 1 e 2 em um único script .sql.
Adicione comentários detalhados explicando a diferença prática entre LEFT JOIN e INNER JOIN e quando usar HAVING em vez de WHERE.
Envie o arquivo (Atividade_07_SeuNome.sql) no Microsoft Teams.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Qual a diferença entre WHERE e HAVING? O WHERE filtra linhas antes do agrupamento. O HAVING filtra o resultado depois que o cálculo (como o SUM) já foi feito. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto de BI 🏆

Crie um relatório que mostre apenas os clientes que gastaram mais de R$ 1.000,00 no total de suas compras. Você precisará usar JOIN, SUM, GROUP BY e HAVING.

🔑 Gabarito de Código/Fórmulas Completo

Prática 1 (Agregações):

SELECT COUNT(*) FROM cliente;
SELECT MAX(preco), MIN(preco) FROM produto;
SELECT AVG(preco) FROM produto;

Prática 2 (Joins):

-- Nome do Cliente e Data
SELECT c.nome, p.data_ped 
FROM cliente c 
INNER JOIN pedido p ON c.id = p.id_cliente;

-- Contagem por Cliente
SELECT c.nome, COUNT(p.id) AS total_pedidos
FROM cliente c
LEFT JOIN pedido p ON c.id = p.id_cliente
GROUP BY c.nome;

🔍 Explicação do Gabarito:

LEFT JOIN: Usei aqui para que mesmo clientes que ainda não compraram nada apareçam na lista com o valor 0. O INNER JOIN os excluiria.
AS total_pedidos: Renomeia a coluna no resultado para ficar mais legível para o usuário final.

🎯 ATIVIDADE 08 — ALÉM DAS TABELAS

Bem-vindo à oitava semana (4 aulas) do curso de Banco de Dados. Até aqui, vivemos em um mundo de tabelas rígidas e linhas fixas (SQL). Mas e se precisarmos armazenar dados que mudam de formato o tempo todo? Hoje vamos entrar no universo NoSQL com o MongoDB, o banco de documentos mais popular do mundo. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Compreender a diferença entre Relacional (SQL) e Não Relacional (NoSQL).
Manipular Coleções e Documentos (JSON/BSON).
Realizar inserções e consultas básicas usando o MongoDB Compass e o Shell.
Entender o conceito de Esquema Flexível.

🏢 O Cenário Prático (Seu Desafio)

A TecProExpress está expandindo seu catálogo para produtos internacionais. O problema é que cada país envia detalhes diferentes: uns mandam voltagem, outros mandam tamanho de tela, outros mandam material. No SQL, teríamos muitas colunas vazias.

Seu desafio é criar uma coleção de PRODUTOS_NOSQL no MongoDB para armazenar esses dados de forma flexível, garantindo que nenhum detalhe técnico seja perdido.

🧠 Fundamentos: A Teoria Traduzida

NoSQL não significa "Não SQL", mas sim "Not Only SQL" (Não Apenas SQL).

1. Tabela vs. Coleção

No MongoDB, não temos tabelas, temos Coleções. Dentro delas, não temos linhas, temos Documentos.

graph LR
    subgraph SQL ["Mundo Relacional"]
    A[Tabela] --> B[Linha]
    B --> C[Coluna Fixa]
    end
    
    subgraph NoSQL ["Mundo MongoDB"]
    D[Coleção] --> E[Documento JSON]
    E --> F[Campos Variáveis]
    end
    
    style SQL fill:#f5f5f5
    style NoSQL fill:#e8f5e9

2. O Formato JSON

Os dados são guardados como objetos. Exemplo:

{
  "nome": "Smartphone",
  "preco": 2000,
  "detalhes": { "cor": "Preto", "ram": "8GB" }
}

📖 Exemplo Guiado: Sua Primeira Coleção

Veja como o MongoDB cria tudo automaticamente no momento da inserção.

1. Criando e Populando (DML NoSQL)

Diferente do SQL, se a coleção não existir, o MongoDB a cria na hora.

// Usando o Banco 'tecpro_express'
use('tecpro_express');

// Inserindo um produto com campos únicos
db.produtos_nosql.insertOne({
  "item": "Notebook",
  "marca": "TecPro",
  "especificacoes": { "cpu": "i7", "ssd": "512GB" },
  "tags": ["oferta", "tecnologia"]
});

2. Consultando (Query NoSQL)

// Buscar todos os notebooks
db.produtos_nosql.find({ "item": "Notebook" });

🔍 Detalhamento do Código:

db.colecao: Comando para acessar uma coleção específica.
insertOne: Insere um único documento.
{ "chave": "valor" }: Estrutura de filtro básica.

🛠️ Prática Obrigatória 1: Carga Flexível

Cenário: Cadastro de produtos variados na TecProExpress.

Abra o MongoDB Compass ou o Shell.
Crie uma coleção chamada catalogo.
Insira 3 Documentos com estruturas diferentes:
- Um produto com voltagem e cor.
- Um produto com tamanho_tela e peso.
- Um produto com uma lista de materiais (array).

🚀 Script de Seed (NoSQL)

db.catalogo.insertMany([
  { "nome": "Luminária", "voltagem": "Bivolt", "cor": "Branca" },
  { "nome": "Monitor", "tamanho_tela": "27 pol", "peso": "4kg" },
  { "nome": "Cadeira", "materiais": ["Couro", "Aço", "Plástico"] }
]);

🛠️ Prática Obrigatória 2: Buscas Inteligentes

Cenário: O time de marketing quer filtrar o catálogo.

Escreva uma consulta que traga apenas produtos da cor 'Branca'.
Escreva uma consulta que utilize o operador $gt (greater than) para listar produtos com preço acima de 100.

🏁 Resultado Esperado (Gabarito Visual)

No MongoDB, o resultado virá formatado como um objeto JSON entre chaves { }.

📤 Instruções de Entrega (Microsoft Teams)

Após testar suas operações JSON no MongoDB Compass ou no Mongo Shell:

Salve as consultas de busca (db.catalogo.find(...)) e inserção criadas em um arquivo com a extensão .js (JavaScript/BSON script).
Opcionalmente, envie capturas de tela mostrando os documentos inseridos visíveis na aba "Documents" do MongoDB Compass.
Envie o arquivo (Atividade_08_SeuNome.js) na plataforma do Microsoft Teams para avaliação de modelagem orientada a documentos.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Ter um esquema flexível significa que você pode salvar qualquer coisa, mas não significa que você deve. Na indústria, mesmo no NoSQL, mantemos um padrão mínimo para que o sistema não vire uma bagunça de dados sem sentido. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Desenvolvedor FullStack 🏆

Pesquise como realizar um UPDATE no MongoDB usando o operador $set. Como você alteraria apenas o preço de um documento sem apagar o resto dos dados?

🔑 Gabarito de Código/Fórmulas Completo

Prática 1 (Inserção):

db.catalogo.insertOne({ "nome": "Teclado", "idioma": "ABNT2" });

Prática 2 (Consultas):

-- Busca por campo exato
db.catalogo.find({ "cor": "Branca" });

-- Busca com Operador (Preço > 100)
db.catalogo.find({ "preco": { $gt: 100 } });

🔍 Explicação do Gabarito:

$gt: Significa "Greater Than" (Maior que). Operadores no MongoDB começam com $.
find(): Se deixado vazio find({}), ele retorna todos os documentos da coleção.

🎯 ATIVIDADE 09 — ESCALA PLANETÁRIA

Bem-vindo à nona semana (4 aulas) do curso de Banco de Dados. Após explorarmos o MongoDB, vamos subir o nível de escala. Hoje vamos conhecer o Apache Cassandra, o banco de dados utilizado por gigantes como Netflix e Uber para lidar com bilhões de transações por segundo. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Entender a arquitetura de Colunas de Larga Escala (Wide Column Store).
Criar e gerenciar Keyspaces e Tabelas no Cassandra.
Utilizar a linguagem CQL (Cassandra Query Language).
Compreender a importância da Chave de Partição para a escalabilidade.

🏢 O Cenário Prático (Seu Desafio)

A TecProExpress instalou sensores IoT em toda a sua frota de caminhões. Cada caminhão envia sua posição GPS, velocidade e temperatura da carga a cada 5 segundos. Com milhares de veículos, o volume de dados é gigantesco.

Seu desafio é configurar um ambiente no Cassandra para receber esse fluxo de dados, garantindo que as informações sejam gravadas de forma ultra-rápida e nunca sejam perdidas.

🧠 Fundamentos: A Teoria Traduzida

O Cassandra não organiza dados em uma única máquina; ele os espalha por um Anel (Cluster) de servidores.

1. O Keyspace (O Condomínio)

No SQL temos "Databases". No Cassandra, temos Keyspaces. É aqui que definimos como os dados serão replicados entre as máquinas.

2. A Chave de Partição (O Endereço)

Imagine um grande armazém. Para achar uma caixa rápido, você precisa saber o número da prateleira. No Cassandra, a Partition Key decide em qual servidor do mundo o dado será guardado.

graph TD
    subgraph Cluster ["Anel Cassandra"]
    N1[Nó 1] --- N2[Nó 2]
    N2 --- N3[Nó 3]
    N3 --- N1
    end
    
    Data[Dado de GPS] -->|Hash da Chave| N2
    
    style Cluster fill:#f3e5f5,stroke:#7b1fa2

📖 Exemplo Guiado: Criando sua Infraestrutura

Veja como o CQL é amigável e parecido com o SQL tradicional.

1. Preparando o Terreno (Keyspace)

-- Criando o Keyspace de Logística
CREATE KEYSPACE tecpro_logistica 
WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

USE tecpro_logistica;

2. Criando a Tabela de Sensores (DDL)

CREATE TABLE telemetria (
    veiculo_id INT,
    data_hora TIMESTAMP,
    latitude DECIMAL,
    longitude DECIMAL,
    velocidade FLOAT,
    PRIMARY KEY (veiculo_id, data_hora)
);

🔍 Detalhamento do Código:

SimpleStrategy: Estratégia de replicação para ambientes de teste (um único datacenter).
PRIMARY KEY (veiculo_id, data_hora):
- veiculo_id: Chave de Partição (espalha os caminhões pelo cluster).
- data_hora: Chave de Agrupamento (ordena os logs de cada caminhão por tempo).

🛠️ Prática Obrigatória 1: Setup e Carga

Cenário: Monitoramento de Frota na TecProExpress.

Acesse seu ambiente Cassandra (via Docker ou local).
Crie o Keyspace tecpro_iot.
Crie a tabela status_caminhao para armazenar id, placa, temperatura e timestamp.

🚀 Script de Seed (CQL)

INSERT INTO status_caminhao (id, placa, temperatura, timestamp) 
VALUES (101, 'ABC-1234', 5.5, toTimestamp(now()));

INSERT INTO status_caminhao (id, placa, temperatura, timestamp) 
VALUES (101, 'ABC-1234', 5.2, toTimestamp(now()));

🛠️ Prática Obrigatória 2: Consulta de Alta Performance

Cenário: O centro de controle quer ver os logs de um veículo específico.

Escreva uma consulta para listar todos os registros do caminhão com id = 101.
Tente filtrar por temperatura acima de 5 graus sem usar o ID do veículo. O que acontece?

📤 Instruções de Entrega (Microsoft Teams)

Após testar suas tabelas e consultas no Cassandra (via cqlsh):

Salve o script contendo a criação do Keyspace, da tabela com a Primary Key adequada (Chave de Partição + Chave de Agrupamento) e as consultas de teste em um arquivo com a extensão .cql ou .sql contendo comandos CQL.
Adicione comentários no código explicando por que a escolha da Partition Key (veiculo_id/id) é vital para a distribuição horizontal de dados do cluster.
Envie o arquivo (Atividade_09_SeuNome.cql) na tarefa correspondente no Microsoft Teams.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: No Cassandra, nós desenhamos as tabelas com base nas perguntas que vamos fazer (Query-Driven Design). Se você tentar filtrar por algo que não faz parte da chave primária, o Cassandra pode recusar a consulta para não perder performance. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto de Sistemas 🏆

O que é o Replication Factor (RF)? Se você configurar RF: 3 em um cluster de 5 máquinas, o que acontece se duas máquinas pegarem fogo ao mesmo tempo?

🔑 Gabarito de Código/Fórmulas Completo

Prática 1 (Criação):

CREATE TABLE status_caminhao (
    id INT,
    placa TEXT,
    temperatura FLOAT,
    data_leitura TIMESTAMP,
    PRIMARY KEY (id, data_leitura)
) WITH CLUSTERING ORDER BY (data_leitura DESC);

Prática 2 (Consulta):

SELECT * FROM status_caminhao WHERE id = 101;

🔍 Explicação do Gabarito:

WITH CLUSTERING ORDER BY: Faz com que os logs mais recentes apareçam no topo da lista automaticamente, sem precisar de um ORDER BY lento na hora da consulta.
TEXT: No Cassandra, usamos TEXT em vez de VARCHAR para a maioria das strings.

🎯 ATIVIDADE 10 — ARQUITETO DE ELITE

Parabéns! Você chegou à décima semana (4 aulas) e ao primeiro grande marco do curso de Banco de Dados. Hoje, você deixará de ser um estudante para se tornar um Arquiteto de Soluções. O desafio final da Fase 1 é consolidar tudo o que aprendemos sobre SQL e NoSQL em um único ecossistema corporativo. 🛡️🏆

🎯 Objetivo da Aula

Ao final desta semana, você terá construído:

Um Modelo Relacional completo e normalizado (3FN).
Um script de Banco de Dados Real com carga de dados (DDL/DML).
Relatórios de Business Intelligence usando Joins e Agregações.
Uma camada de Persistência NoSQL para dados flexíveis.

🏢 O Cenário Prático (Seu Desafio Final)

A TecProExpress vai lançar o serviço "Ultra-Priority", focado em entregas de alto valor (como obras de arte e joias). Este serviço exige:

Segurança Total (Relacional): Cadastro rigoroso de clientes, apólices de seguro e rotas.
Rastreamento Detalhado (NoSQL): Logs de sensores térmicos, fotos da carga e assinaturas digitais que mudam de formato conforme o país.

Seu desafio é entregar a Arquitetura de Dados completa para este novo negócio.

🧠 O Roadmap do Arquiteto

Veja o caminho que seus dados vão percorrer:

flowchart TD
    A[1. Modelagem MER] --> B[2. Mapeamento 3FN]
    B --> C[3. Script SQL DDL]
    C --> D[4. Seed de Dados DML]
    D --> E[5. Relatórios BI]
    E --> F[6. Integração NoSQL]
    
    style A fill:#e3f2fd
    style F fill:#e8f5e9
    style C fill:#fffde7

🛠️ Passo 1: A Fundação Relacional (SQL)

Tarefa: Crie o esquema de banco de dados para o serviço Ultra-Priority.

Modelagem: Desenhe no draw.io as tabelas CLIENTE, SEGURO e ENTREGA_ESPECIAL.
Normalização: Garanta que os dados de seguro não estejam duplicados.
Implementação: Escreva o script CREATE TABLE com todas as PKs e FKs.

🛠️ Passo 2: Inteligência e Auditoria

Tarefa: Gere os relatórios que o board da TecProExpress exigiu.

Join: Liste o nome do cliente, o valor da apólice de seguro e o status da entrega.
Agregação: Calcule o valor total segurado que está em trânsito no momento (SUM).

🛠️ Passo 3: Flexibilidade NoSQL (MongoDB)

Tarefa: Crie uma coleção no MongoDB chamada logs_rastreamento.

Insira documentos JSON que contenham dados variados de sensores (ex: Um log com temperatura, outro com foto_url, outro com biometria_recebedor).
Realize uma busca que traga apenas logs com alerta: true.

🚀 Script de Seed Consolidado (Gabarito de Teste)

-- DDL Rápido
CREATE TABLE seguro (id INT PRIMARY KEY, valor DECIMAL(15,2), descricao TEXT);
CREATE TABLE entrega_especial (id INT PRIMARY KEY, id_seguro INT, FOREIGN KEY (id_seguro) REFERENCES seguro(id));

-- DML de Carga
INSERT INTO seguro VALUES (1, 500000.00, 'Cobertura Diamante');
INSERT INTO entrega_especial VALUES (1001, 1);

📤 Instruções de Entrega (Microsoft Teams)

Parabéns por concluir o Projeto Integrador (Fase 1)! Para realizar a sua entrega com sucesso:

Certifique-se de organizar seu repositório Git pessoal seguindo rigorosamente a estrutura de pastas descrita na página inicial (index.md).
Adicione ao repositório:
- O diagrama lógico no draw.io (.drawio e .drawio.png).
- O script SQL completo (.sql) com CREATE DATABASE, criação física (DDL), carga de testes (DML) e os relatórios analíticos solicitados.
- Os scripts MongoDB de persistência flexível em formato .js ou .json.
Submeta na plataforma do Microsoft Teams:
- O link público do seu repositório GitHub.
- Os arquivos consolidados para verificação direta.

💡 Checkpoint de Lógica

[!IMPORTANT] Conselho de Carreira: Um projeto integrador é a sua melhor peça de portfólio. No GitHub, não suba apenas o código; use o README.md para explicar por que você escolheu o SQL para o seguro e o NoSQL para os logs. Isso demonstra visão arquitetural. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: CTO (Chief Technology Officer) 🏆

Tente integrar os dados: No seu relatório final, como você associaria o id_entrega do SQL com o documento_id do MongoDB? (Dica: Pesquise sobre referências cruzadas entre bancos poliglotas).

🔑 Gabarito de Código/Fórmulas Completo

Relatório de Valor Segurado (BI):

SELECT c.nome, SUM(s.valor) AS risco_total
FROM cliente c
JOIN entrega_especial e ON c.id = e.id_cliente
JOIN seguro s ON s.id = e.id_seguro
GROUP BY c.nome;

Inserção NoSQL (Logística):

db.logs_rastreamento.insertOne({
  "entrega_id": 1001,
  "evento": "Check-in Aeroporto",
  "detalhes": { "temp_externa": 22.5, "umidade": 40 },
  "alerta": false
});

🔍 Explicação do Gabarito:

JOIN Triplo: Conecta três tabelas para cruzar a pessoa, o serviço e o valor.
Objeto Detalhes: No MongoDB, usamos objetos aninhados para guardar dados técnicos que não precisam de colunas fixas no SQL.

🎯 ATIVIDADE 11 — O VELOCÍMETRO DOS DADOS

Bem-vindo à décima primeira semana (4 aulas) do curso de Banco de Dados. Até aqui, trabalhamos com tabelas pequenas, onde as consultas respondem instantaneamente. Mas o que acontece quando a tabela tem 10 milhões de linhas? Sem os índices corretos, seu banco travará e a aplicação ficará lenta. Hoje, você aprenderá a criar índices e a ler o plano de execução de uma consulta para atuar como um Especialista em Performance (Tuning). 🛡️⚡

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Compreender a diferença entre busca sequencial (Sequential Scan) e busca por índice (Index Scan).
Criar e gerenciar Índices B-Tree e Hash no PostgreSQL e MySQL.
Interpretar o plano de execução de uma consulta usando o comando EXPLAIN.
Identificar consultas lentas e propor a indexação correta para otimização de performance.

🏢 O Cenário Prático (Seu Desafio)

O aplicativo de rastreamento de entregas da TecProExpress está enfrentando lentidão crítica. O time de suporte identificou que a consulta de busca por CPF do cliente na hora de listar as entregas está levando mais de 5 segundos para responder no banco de produção.

Como Arquiteto de Banco de Dados, você recebeu a missão de analisar as consultas de busca utilizando ferramentas de execução e aplicar índices estratégicos para reduzir o tempo de busca para menos de 5 milissegundos.

🧠 Fundamentos: A Teoria Traduzida

Buscar dados em uma tabela sem índice é como procurar uma palavra em um dicionário que não está em ordem alfabética: você precisa ler o livro inteiro, página por página (Full Table Scan / Seq Scan). Criar um índice é como criar o índice remissivo no fim do livro: você vai direto para a página certa instantaneamente.

📊 Estrutura de Busca: B-Tree vs. Hash

flowchart TD
    subgraph BTree ["Árvore B-Tree (Busca de Intervalos: >, <, >=, <=)"]
        Root["Raiz: id = 50"] --> L1["Esquerda: < 50"]
        Root --> R1["Direita: >= 50"]
        L1 --> L2["Folha: 10, 20, 30"]
        R1 --> R2["Folha: 50, 60, 70"]
    end

B-Tree (Padrão): Organiza os dados em uma árvore balanceada. Excelente para consultas de igualdade (=) e buscas por intervalo (BETWEEN, >, <).
Hash: Mapeia chaves diretamente para endereços físicos. Perfeito para igualdades exatas (=), mas inútil para intervalos.

📖 Exemplo Guiado: Usando o EXPLAIN

Vamos analisar como o banco de dados planeja fazer uma busca antes de criar o índice.

1. Inicializando o Banco de Dados

CREATE DATABASE tecpro_performance;
-- (Nota: No pgAdmin, abra a Query Tool apontando para o novo banco)

2. Criando Tabela e Analisando sem Índice

CREATE TABLE entrega (
    id SERIAL PRIMARY KEY,
    codigo_rastreamento VARCHAR(50),
    data_envio DATE
);

-- Analisando a busca por código de rastreamento antes do índice
EXPLAIN ANALYZE 
SELECT * FROM entrega WHERE codigo_rastreamento = 'TRK1002938';

Saída Esperada no pgAdmin (Console): Seq Scan on entrega (cost=0.00..38.25 rows=1 width=58) (actual time=0.045..0.082 rows=0 loops=1) (Nota: O termo Seq Scan indica que o banco leu a tabela inteira do início ao fim para tentar achar o registro).

🛠️ Prática Obrigatória 1: Análise e Indexação

Crie a tabela cliente_historico com as colunas: id (PK), nome, cpf (sem chave única física inicial) e email.
Popule a tabela com alguns registros fictícios.

Execute o comando EXPLAIN para analisar a busca por cpf:

EXPLAIN SELECT * FROM cliente_historico WHERE cpf = '12345678901';

Crie um índice B-Tree na coluna cpf e execute novamente o EXPLAIN. Veja a diferença.

🛠️ Prática Obrigatória 2: B-Tree vs. Hash (Performance)

Crie um índice do tipo Hash na coluna email da tabela cliente_historico.
Crie um índice do tipo B-Tree na coluna id (gerado automaticamente pela PK).
Escreva o script SQL de criação dos dois índices (PostgreSQL e MySQL equivalentes).

📤 Instruções de Entrega (Microsoft Teams)

Após validar a performance das suas consultas locais:

Salve o script SQL contendo a criação da tabela, comandos de EXPLAIN e a criação dos índices em um arquivo .sql (Ex: Atividade_11_SeuNome.sql).
Adicione comentários no código explicando o que significa o custo (cost) retornado pelo EXPLAIN e quando se deve preferir um índice B-Tree sobre um Hash.
Envie o arquivo .sql no Microsoft Teams.

💡 Checkpoint de Lógica

[!IMPORTANT] O Preço do Índice: Se os índices deixam as consultas super rápidas, por que não indexamos todas as colunas de todas as tabelas? (Resposta: Cada índice consome espaço físico em disco e reduz a velocidade de escrita (INSERT, UPDATE, DELETE), pois o banco de dados precisa atualizar os índices a cada modificação. O bom arquiteto indexa apenas colunas usadas frequentemente em filtros WHERE e junções JOIN). 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Especialista em Performance 🏆

O que é um Covering Index (ou Índice Composto)? Como você criaria um único índice para otimizar uma busca que filtra por cidade E por status ao mesmo tempo?

🔑 Gabarito de Código/Fórmulas Completo

🐘 Padrão PostgreSQL (pgAdmin)

-- 1. Criação da Tabela
CREATE TABLE cliente_historico (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(100),
    cpf VARCHAR(11),
    email VARCHAR(100)
);

-- 2. Criação do Índice B-Tree (Foco em buscas por igualdade e ordenações)
CREATE INDEX idx_cli_cpf ON cliente_historico(cpf);

-- 3. Criação do Índice Hash (Exclusivo para igualdade exata)
CREATE INDEX idx_cli_email_hash ON cliente_historico USING HASH (email);

-- 4. Verificação de Execução
EXPLAIN ANALYZE 
SELECT * FROM cliente_historico WHERE cpf = '12345678901';

🐬 Comparativo MySQL (Workbench)

-- No MySQL, o índice Hash não é suportado no motor padrão InnoDB (apenas B-Tree)
CREATE INDEX idx_cli_cpf ON cliente_historico(cpf);
CREATE INDEX idx_cli_email ON cliente_historico(email);

🔍 Explicação do Gabarito:

idx_cli_cpf: Índice B-Tree criado para buscas por CPF.
USING HASH: Sintaxe do PostgreSQL para criar índices usando hashing direto. Muito rápido para buscas exatas por e-mail, mas não suporta operadores como >, <, LIKE ou ORDER BY.
EXPLAIN ANALYZE: Mostra o planejamento do otimizador e executa a query, trazendo o tempo real de CPU em milissegundos.

🎯 ATIVIDADE 12 — O COFRE DOS DADOS

Bem-vindo à décima segunda semana (4 aulas) do curso de Banco de Dados. Em sistemas comerciais, falhas acontecem: a energia cai, a internet desconecta ou a aplicação trava no meio de um processo. Se você estiver transferindo dinheiro ou atualizando o status de uma entrega, um erro no meio do caminho pode gerar dados órfãos e prejuízos. Hoje, aprenderemos a usar as Transações e o conceito ACID para transformar o banco de dados em um verdadeiro cofre inexpugnável. 🛡️🔒

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Compreender e aplicar as propriedades ACID (Atomicidade, Consistência, Isolamento, Durabilidade).
Controlar o fluxo transacional com BEGIN, COMMIT e ROLLBACK no PostgreSQL e MySQL.
Simular e evitar anomalias de concorrência (Leitura Suja, Leitura Não-Repetível e Fantasma).
Compreender a utilidade prática dos Níveis de Isolamento de transação.

🏢 O Cenário Prático (Seu Desafio)

A TecProExpress está implementando o pagamento automático de entregadores parceiros. O fluxo de repasse financeiro funciona assim:

Debita o valor da taxa da carteira digital da TecProExpress (Tabela carteira_empresa).
Credita o mesmo valor na conta do entregador (Tabela carteira_entregador).

Se o passo 1 rodar com sucesso, mas o servidor cair antes do passo 2, o dinheiro sumirá da empresa e nunca chegará ao entregador! Seu desafio é empacotar esse processo de transferência em uma transação segura, garantindo que se uma etapa falhar, toda a operação seja desfeita (Rollback).

🧠 Fundamentos: A Teoria Traduzida

As 4 Regras de Ouro: ACID

flowchart LR
    A["A: Atomicidade - Tudo ou Nada"] --> B["C: Consistência - Sem Regras Quebradas"]
    B --> C["I: Isolamento - Operações Separadas"]
    C --> D["D: Durabilidade - Gravado em Disco"]
    style A fill:#ffe0b2,stroke:#fb8c00
    style D fill:#c8e6c9,stroke:#4caf50

Atomicidade: A transação é indivisível. Se uma instrução falhar, o banco desfaz tudo o que já foi feito na mesma transação.
Consistência: A transação move o banco de um estado válido para outro estado válido, respeitando chaves estrangeiras e restrições.
Isolamento: Transações paralelas não interferem umas nas outras até que sejam finalizadas.
Durabilidade: Uma vez concluída (COMMIT), a alteração é permanente e não será perdida mesmo se o servidor pegar fogo no segundo seguinte.

📖 Exemplo Guiado: Transação Controlada

Veja como simular uma falha e proteger os saldos usando blocos de transação.

1. Inicializando o Banco de Dados

CREATE DATABASE tecpro_transacoes;
-- (Nota: No pgAdmin, abra a Query Tool apontando para o banco tecpro_transacoes)

2. Criando o Cenário Físico

CREATE TABLE conta (
    id SERIAL PRIMARY KEY,
    titular VARCHAR(100),
    saldo DECIMAL(10,2) CHECK (saldo >= 0) -- Não permite saldo negativo!
);

INSERT INTO conta (titular, saldo) VALUES 
('TecPro Express Corp', 1000.00),
('Entregador Marcos', 0.00);

3. A Simulação de Falha Segura (Rollback Automático)

BEGIN; -- Inicia a transação (No MySQL pode ser START TRANSACTION)

-- Passo 1: Retira 150.00 da empresa
UPDATE conta SET saldo = saldo - 150.00 WHERE titular = 'TecPro Express Corp';

-- Passo 2: Tenta depositar na conta de Marcos
UPDATE conta SET saldo = saldo + 150.00 WHERE titular = 'Entregador Marcos';

-- Vamos simular que algo deu errado e decidimos desfazer a operação antes de salvar
ROLLBACK;

-- Verificando saldos: tudo voltou ao estado original!
SELECT * FROM conta;

🛠️ Prática Obrigatória 1: O Teste de Restrição (Atomicidade)

Escreva uma transação SQL que tente transferir R$ 2.000,00 da TecPro Express Corp para o Entregador Marcos.
A execução falhará no Passo 1 devido à restrição física CHECK (saldo >= 0).
Prove, através de uma consulta ao final, que mesmo a instrução de crédito para Marcos não foi aplicada devido ao cancelamento total da transação.

🛠️ Prática Obrigatória 2: Níveis de Isolamento (Concorrência)

Abra duas janelas de Query Tool (Abas) no seu pgAdmin (representando dois usuários simultâneos no banco).

Na Aba 1, altere o saldo de Marcos para R$ 500,00 sem dar COMMIT:

BEGIN;
UPDATE conta SET saldo = 500.00 WHERE titular = 'Entregador Marcos';

Na Aba 2, realize uma consulta simples: SELECT saldo FROM conta WHERE titular = 'Entregador Marcos';.
O saldo consultado na Aba 2 é R$ 0,00 ou R$ 500,00? Justifique com base no conceito de Isolamento de Transação.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas transações:

Salve o script SQL contendo os testes de criação de contas, a simulação de rollback e as respostas textuais às perguntas de concorrência em um arquivo .sql (Ex: Atividade_12_SeuNome.sql).
Adicione comentários no código explicando o que são os operadores COMMIT e ROLLBACK.
Envie o arquivo .sql correspondente no Microsoft Teams para avaliação.

💡 Checkpoint de Lógica

[!IMPORTANT] O Perigo do Lock (Bloqueio): Quando você executa um UPDATE dentro de uma transação não finalizada, o banco de dados bloqueia aquela linha para que ninguém mais a modifique simultaneamente. Se você esquecer de dar COMMIT ou ROLLBACK, a linha ficará travada para sempre, fazendo com que outras conexões travem na fila! Mantenha transações rápidas e objetivas. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto de Sistemas 🏆

Pesquise sobre a anomalia Dirty Read (Leitura Suja) e o nível de isolamento READ UNCOMMITTED. Por que o PostgreSQL não permite leituras sujas mesmo se configurado explicitamente para esse nível?

🔑 Gabarito de Código/Fórmulas Completo

🐘 Padrão PostgreSQL (pgAdmin)

-- Prática 1: Simulação de estouro de saldo
BEGIN;

-- Tentativa de debitar mais do que o saldo atual de R$ 1000.00
UPDATE conta 
SET saldo = saldo - 2000.00 
WHERE titular = 'TecPro Express Corp';
-- (Isso causará uma violação de constraint de CHECK e anulará os comandos seguintes)

UPDATE conta 
SET saldo = saldo + 2000.00 
WHERE titular = 'Entregador Marcos';

COMMIT; -- O Postgres retornará "ROLLBACK" em vez de commit devido à falha anterior!

-- Verificando que nada foi alterado
SELECT * FROM conta;

🐬 Padrão MySQL (Workbench / DBeaver)

-- No MySQL, por padrão, violações de CHECK em motores antigos eram ignoradas,
-- mas a partir da versão 8.0 funcionam exatamente igual:
START TRANSACTION;

UPDATE conta SET saldo = saldo - 2000.00 WHERE titular = 'TecPro Express Corp';
UPDATE conta SET saldo = saldo + 2000.00 WHERE titular = 'Entregador Marcos';

COMMIT;

🔍 Explicação do Gabarito:

BEGIN / START TRANSACTION: Avisam ao SGBD para suspender a gravação automática imediata em disco (Autocommit) e aguardar confirmação.
Violação de Restrição: Uma vez que uma constraint é violada, a transação entra em estado de erro e o commit falha automaticamente, garantindo a integridade dos dados.

🎯 ATIVIDADE 13 — O BANCO INTELIGENTE

Bem-vindo à décima terceira semana (4 aulas) do curso de Banco de Dados. Até agora, tratamos o banco de dados como um repositório passivo: a aplicação envia os dados e o banco apenas os guarda. Mas e se o próprio banco de dados pudesse tomar decisões, rodar códigos automáticos e proteger as regras de negócio? Hoje entraremos no mundo do Banco Inteligente, aprendendo a criar Stored Procedures (Procedimentos Armazenados) e Triggers (Gatilhos) para automatizar rotinas operacionais cruciais. 🛡️🤖

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Compreender o conceito e os benefícios de programar dentro do SGBD.
Criar e executar Stored Procedures e Functions no PostgreSQL e MySQL.
Desenvolver Triggers (Gatilhos) automáticos para controle de eventos (INSERT, UPDATE, DELETE).
Automatizar o controle de inventário (baixa automática de estoque) a cada venda registrada.

🏢 O Cenário Prático (Seu Desafio)

O departamento de logística da TecProExpress está preocupado com furos no estoque. Atualmente, quando um pedido é feito, a aplicação web é responsável por subtrair a quantidade vendida da tabela de produtos. Porém, falhas na aplicação às vezes pulam essa etapa, fazendo com que produtos sem estoque continuem a ser vendidos.

Seu desafio como Engenheiro de Dados é mover essa inteligência para o banco de dados. Você criará uma Trigger que, de forma 100% garantida e automática, subtrairá a quantidade comprada do estoque toda vez que um novo produto for inserido na tabela item_pedido.

🧠 Fundamentos: A Teoria Traduzida

O Gatilho Automático (Trigger)

Uma Trigger é como um sensor de presença com alarme: ela fica "vigiando" uma tabela. Se ocorrer um evento específico (como a inserção de uma linha), ela dispara um bloco de código (função) automaticamente antes ou depois da modificação.

flowchart TD
    A["Usuário insere linha em ITEM_PEDIDO"] --> B{"Trigger disparada?"}
    B -- SIM --> C["Executa Função de Ajuste de Estoque"]
    C --> D["Estoque do Produto é Subtraído"]
    D --> E["Linha é gravada fisicamente"]
    style B fill:#ffe0b2,stroke:#fb8c00
    style D fill:#c8e6c9,stroke:#4caf50

OLD: Palavra-chave que dá acesso aos valores da linha antes da alteração (usado em Updates/Deletes).
NEW: Palavra-chave que dá acesso aos novos valores que estão sendo gravados (usado em Inserts/Updates).

📖 Exemplo Guiado: Criando uma Stored Procedure

Vamos criar um procedimento para reabastecer o estoque de um produto de forma rápida.

1. Inicializando o Banco de Dados

CREATE DATABASE tecpro_automacao;
-- (Nota: No pgAdmin, abra a Query Tool apontando para o banco tecpro_automacao)

2. Criando o Cenário de Teste

CREATE TABLE estoque_produto (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(100),
    quantidade_estoque INT NOT NULL DEFAULT 0
);

INSERT INTO estoque_produto (nome, quantidade_estoque) VALUES 
('Capacete Pro', 10),
('Cabo Carregador', 50);

3. Criando a Procedure no PostgreSQL

CREATE OR REPLACE PROCEDURE adicionar_estoque(prod_id INT, qtd INT)
LANGUAGE plpgsql
AS $$
BEGIN
    UPDATE estoque_produto 
    SET quantidade_estoque = quantidade_estoque + qtd 
    WHERE id = prod_id;
END;
$$;

-- Executando a Procedure para adicionar 20 capacetes
CALL adicionar_estoque(1, 20);

-- Verificando: Capacete Pro agora possui 30 unidades!
SELECT * FROM estoque_produto;

🛠️ Prática Obrigatória 1: Criando a Trigger de Estoque (PostgreSQL)

Crie a tabela pedido e a tabela item_pedido (seguindo as FKs para estoque_produto).
Crie uma Função de Trigger no PostgreSQL (linguagem plpgsql) que subtraia a quantidade comprada do estoque do produto correspondente na tabela estoque_produto usando o registro NEW.
Crie a Trigger associada à tabela item_pedido que dispara AFTER INSERT para cada linha inserida.

🛠️ Prática Obrigatória 2: Equivalência em MySQL

Pesquise a sintaxe de Trigger no MySQL (que não exige a criação de uma função separada, permitindo declarar o código diretamente no corpo do gatilho).
Escreva o script equivalente da Trigger de subtração de estoque adaptado para rodar no MySQL Workbench/DBeaver.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas automações:

Salve o script SQL completo contendo a criação das tabelas, da procedure, da função de trigger e da trigger física em um arquivo .sql (Ex: Atividade_13_SeuNome.sql).
Insira comentários explicando qual a diferença de comportamento entre uma Trigger disparada BEFORE (antes) e uma disparada AFTER (depois) do evento.
Envie o arquivo .sql correspondente no Microsoft Teams para avaliação.

💡 Checkpoint de Lógica

[!IMPORTANT] O Perigo das Triggers Ocultas: Embora as triggers sejam fantásticas para garantir a integridade, use-as com moderação. Como elas rodam "por baixo dos panos", novos desenvolvedores da equipe podem ficar confusos se o estoque começar a mudar de valor misteriosamente sem que haja nenhum comando UPDATE aparente no código da aplicação. Sempre documente suas triggers! 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto de Banco de Dados 🏆

Modifique a Trigger para impedir a inserção de um item no pedido caso a quantidade solicitada seja maior do que a quantidade disponível em estoque. (Dica: Use RAISE EXCEPTION no PostgreSQL ou SIGNAL SQLSTATE no MySQL para barrar a inserção).

🔑 Gabarito de Código/Fórmulas Completo

🐘 Padrão PostgreSQL (pgAdmin)

-- 1. Criação das Tabelas Base
CREATE TABLE estoque_produto (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(100),
    quantidade_estoque INT NOT NULL DEFAULT 0
);

CREATE TABLE pedido (
    id SERIAL PRIMARY KEY,
    data_criacao TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE item_pedido (
    id_pedido INT REFERENCES pedido(id),
    id_produto INT REFERENCES estoque_produto(id),
    quantidade INT,
    PRIMARY KEY (id_pedido, id_produto)
);

INSERT INTO estoque_produto (nome, quantidade_estoque) VALUES ('Smartphone X', 10);
INSERT INTO pedido VALUES (1);

-- 2. Criação da Função de Trigger no Postgres
CREATE OR REPLACE FUNCTION processar_baixa_estoque()
RETURNS TRIGGER AS $$
BEGIN
    UPDATE estoque_produto
    SET quantidade_estoque = quantidade_estoque - NEW.quantidade
    WHERE id = NEW.id_produto;
    
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- 3. Criação da Trigger vinculada
CREATE TRIGGER trg_baixa_estoque
AFTER INSERT ON item_pedido
FOR EACH ROW
EXECUTE FUNCTION processar_baixa_estoque();

-- 4. Teste Prático
INSERT INTO item_pedido (id_pedido, id_produto, quantidade) VALUES (1, 1, 3);

-- Verificação: O estoque deve ter baixado de 10 para 7!
SELECT * FROM estoque_produto;

🐬 Comparativo MySQL (Workbench / DBeaver)

-- No MySQL a trigger é declarada diretamente, sem necessidade de FUNCTION
DELIMITER $$

CREATE TRIGGER trg_baixa_estoque_mysql
AFTER INSERT ON item_pedido
FOR EACH ROW
BEGIN
    UPDATE estoque_produto
    SET quantidade_estoque = quantidade_estoque - NEW.quantidade
    WHERE id = NEW.id_produto;
END$$

DELIMITER ;

🔍 Explicação do Gabarito:

NEW.quantidade: Dá acesso à quantidade que o usuário está inserindo na tabela item_pedido.
FOR EACH ROW: Garante que se o usuário inserir 5 linhas de uma vez, a trigger rodará 5 vezes individualmente para dar baixa em cada produto.
DELIMITER: No MySQL, altera o caractere de término de instrução (de ; para $$) para que o SGBD não ache que a Trigger terminou no primeiro ponto e vírgula interno.

🎯 ATIVIDADE 14 — O MELHOR DE DOIS MUNDOS

Bem-vindo à décima quarta semana (4 aulas) do curso de Banco de Dados. Até aqui, ou trabalhamos com a rigidez total das tabelas SQL, ou com a flexibilidade completa das coleções JSON do MongoDB. Mas sabia que os SGBDs modernos permitem unificar essas duas abordagens? Hoje aprenderemos a criar e consultar dados JSONB nativos no PostgreSQL, entendendo como criar uma arquitetura de banco de dados híbrido poliglota de altíssima performance. 🛡️🧬

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Compreender o conceito de banco de dados semiestruturado e persistência híbrida.
Criar tabelas relacionais contendo colunas do tipo JSON e JSONB no PostgreSQL.
Utilizar operadores de navegação JSON (->, ->>, #>) em consultas SQL.
Filtrar e pesquisar campos aninhados dentro de objetos JSON usando a cláusula WHERE.

🏢 O Cenário Prático (Seu Desafio)

O catálogo de produtos eletrônicos da TecProExpress possui um grande problema: a diversidade de atributos técnicos. Um "Monitor" possui tamanho de tela e frequência de atualização, enquanto um "Teclado" possui tipo de switch mecânico e layout. No SQL tradicional, isso geraria uma tabela cheia de colunas nulas. No NoSQL puro, perderíamos a consistência relacional dos pedidos.

Como Arquiteto de Soluções, seu desafio é criar uma tabela relacional clássica de produto, mas que contenha uma coluna especial do tipo atributos_tecnicos JSONB. Você registrará itens variados e extrairá relatórios refinados acessando chaves JSON diretamente de dentro da sua consulta SELECT SQL.

🧠 Fundamentos: A Teoria Traduzida

JSON vs. JSONB

No PostgreSQL, temos dois tipos de dados para guardar objetos de documentos:

JSON: Guarda o dado exatamente como um texto de formato JSON. A gravação é rápida, mas a consulta é lenta porque o SGBD precisa re-analisar o texto a cada busca.
JSONB (Binário): Decompõe o objeto JSON em uma estrutura binária indexada. A escrita é um milissegundo mais lenta, mas as consultas são instantâneas, permitindo inclusive a criação de índices de performance sobre chaves internas!

flowchart TD
    subgraph Row ["Linha de Produto Relacional"]
        ID["id: 101 (SERIAL)"]
        Nome["nome: 'Teclado Gamer' (VARCHAR)"]
        Preco["preco: 250.00 (DECIMAL)"]
        
        subgraph JSONB ["detalhes (JSONB / NoSQL Híbrido)"]
            Switch["'switch': 'Red'"]
            Layout["'layout': 'ABNT2'"]
            Led["'led': true"]
        end
    end
    
    style Row fill:#eceff1,stroke:#37474f,stroke-width:2px
    style JSONB fill:#e8f5e9,stroke:#4caf50

Operadores de Navegação no Postgres:

Operador	Retorno	Uso Didático	Exemplo Prático
`->`	Objeto JSON	Retorna a chave mantendo o formato JSON	`atributos -> 'detalhes'`
`->>`	Texto Puro	Retorna o valor da chave convertida em string	`atributos ->> 'cor'`
`#>`	Objeto aninhado	Navega por um caminho específico de chaves	`atributos #> '{especificacoes, cpu}'`

📖 Exemplo Guiado: Gravando e Consultando JSONB

1. Inicializando o Banco de Dados

CREATE DATABASE tecpro_hibrido;
-- (Nota: No pgAdmin, abra a Query Tool apontando para o banco tecpro_hibrido)

2. Criando Tabela e Populando com Objetos Flexíveis

CREATE TABLE produto_hibrido (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(100) NOT NULL,
    preco DECIMAL(10,2),
    detalhes JSONB -- Coluna híbrida NoSQL
);

-- Inserindo produtos com dados de especificações completamente diferentes
INSERT INTO produto_hibrido (nome, preco, detalhes) VALUES 
('Teclado Gamer', 250.00, '{"switch": "Red", "layout": "ABNT2", "led": true}'),
('Monitor 27', 1500.00, '{"tamanho": "27 polegadas", "frequencia": 144, "entradas": ["HDMI", "DisplayPort"]}');

3. Consultando Chaves Internas via SQL

-- Queremos saber os nomes e os switches de todos os teclados mecânicos
SELECT nome, detalhes ->> 'switch' AS switch_utilizado 
FROM produto_hibrido 
WHERE detalhes ->> 'switch' IS NOT NULL;

🛠️ Prática Obrigatória 1: Consultando Estruturas Aninhadas

Insira um terceiro produto na tabela produto_hibrido contendo um objeto aninhado dentro da coluna detalhes.
- Exemplo de JSON a inserir: {"marca": "Logitech", "dimensoes": {"altura": 10, "largura": 20}}
Escreva uma consulta SQL que navegue por esse caminho e traga a altura do produto utilizando o operador de caminho #>.
Filtre a consulta usando WHERE para trazer apenas produtos da marca "Logitech".

🛠️ Prática Obrigatória 2: Equivalência e Limitações (Comparativo)

Pesquise como o MySQL implementa o suporte a dados JSON (utilizando o tipo JSON e a função JSON_EXTRACT ou o operador inline ->).
Escreva o script equivalente da Prática 1 adaptado para rodar no MySQL Workbench.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas consultas híbridas:

Salve o script SQL contendo a criação da tabela híbrida, as inserções de teste e as consultas elaboradas em um arquivo .sql (Ex: Atividade_14_SeuNome.sql).
Adicione comentários explicando por que a persistência híbrida é vantajosa sobre ter centenas de colunas vazias em uma tabela relacional.
Envie o arquivo .sql no Microsoft Teams para avaliação.

💡 Checkpoint de Lógica

[!IMPORTANT] Índices em JSONB: Um dos grandes trunfos do PostgreSQL é a capacidade de criar índices em chaves dentro do JSONB. Se você fizer muitas buscas filtrando pelo campo marca que está dentro do objeto JSON, você pode criar um índice específico: CREATE INDEX idx_prod_marca ON produto_hibrido ((detalhes->>'marca')); Isso eleva a performance para o patamar de buscas por colunas físicas relacionais! 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto de Dados Poliglota 🏆

Escreva uma query SQL que retorne o primeiro item da lista (array) de conexões entradas do monitor de 27 polegadas cadastrado no exemplo guiado. (Dica: Use -> com índices numéricos zero-based para navegar por arrays no Postgres).

🔑 Gabarito de Código/Fórmulas Completo

🐘 Padrão PostgreSQL (pgAdmin)

-- 1. Inserção do registro aninhado
INSERT INTO produto_hibrido (nome, preco, detalhes) VALUES 
('Mouse Pro', 300.00, '{"marca": "Logitech", "dimensoes": {"altura": 12, "largura": 6}}');

-- 2. Consulta de navegação de caminho aninhado (#> com array de chaves)
SELECT nome, detalhes #> '{dimensoes, altura}' AS altura_interna
FROM produto_hibrido
WHERE detalhes ->> 'marca' = 'Logitech';

-- 3. Resposta ao Desafio (Array Indexing)
SELECT nome, detalhes -> 'entradas' ->> 0 AS primeira_entrada
FROM produto_hibrido
WHERE nome = 'Monitor 27';

🐬 Comparativo MySQL (Workbench / DBeaver)

-- No MySQL usamos o tipo JSON genérico
CREATE TABLE produto_hibrido_mysql (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(100) NOT NULL,
    preco DECIMAL(10,2),
    detalhes JSON
);

INSERT INTO produto_hibrido_mysql (nome, preco, detalhes) VALUES 
('Mouse Pro', 300.00, '{"marca": "Logitech", "dimensoes": {"altura": 12, "largura": 6}}');

-- No MySQL usamos o operador ->> com sintaxe de caminho JSON de cifrão ($)
SELECT nome, detalhes ->> '$.dimensoes.altura' AS altura_interna
FROM produto_hibrido_mysql
WHERE detalhes ->> '$.marca' = 'Logitech';

🔍 Explicação do Gabarito:

Operador #>: Permite passar um array de chaves {objeto, subobjeto} para navegar recursivamente sem precisar fazer múltiplos encadeamentos de ->.
Sintaxe $.dimensoes.altura: No MySQL, o caractere $ representa o nó raiz do documento JSON, seguido por pontos para navegar pelos campos e subcampos.
Operador ->> 0: Acessa o índice 0 do array retornado pela chave entradas, convertendo o elemento final em string limpa (sem as aspas do JSON original).

🎯 ATIVIDADE 15 — O MOTOR SUPER-RÁPIDO

Bem-vindo à décima quinta semana (4 aulas) do curso de Banco de Dados. Até aqui, gravamos todas as nossas informações em disco rígido (HD/SSD), o que garante durabilidade, mas custa milissegundos preciosos em termos de performance. E se precisarmos armazenar dados temporários de altíssimo acesso (como tokens de login de aplicativos ou localizações GPS em tempo real)? Hoje, entraremos no universo dos bancos de dados em memória (In-Memory Database) conhecendo o Redis, o motor de cache e chave-valor mais rápido do mundo. 🛡️⚡

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Compreender a diferença entre persistência em disco e armazenamento em memória RAM.
Instalar e executar o Redis localmente utilizando containers Docker.
Dominar os comandos fundamentais do Redis (SET, GET, EXPIRE, TTL, DEL).
Configurar políticas de expiração de chaves para controle de cache e tokens temporários.

🏢 O Cenário Prático (Seu Desafio)

O aplicativo dos entregadores parceiros da TecProExpress envia o token de autenticação de login a cada requisição. Se o backend da aplicação tiver que fazer uma busca SELECT na tabela relacional de usuários a cada segundo por causa disso, o banco relacional principal entrará em colapso.

Seu desafio como Arquiteto de Infraestrutura de Dados é subir uma instância do Redis via Docker e simular o cacheamento do token do entregador Marcos. O token de sessão deve ser gravado com uma política de expiração (TTL - Time To Live) de 30 segundos, simulando a segurança de logout automático por inatividade do app.

🧠 Fundamentos: A Teoria Traduzida

Por que o Redis é tão rápido?

O Redis armazena 100% dos seus dados diretamente na Memória RAM do computador. Como a velocidade de leitura e escrita da memória RAM é ordens de grandeza maior do que o SSD ou HD, o Redis consegue responder a mais de 1.000.000 de operações por segundo!

flowchart LR
    A[Aplicação Web] -->|1. Busca no Cache| B(("Redis: RAM"))
    B -- Cache Miss: Dado não existe --> C(("PostgreSQL: Disco"))
    C -.->|2. Grava e responde| B
    B -- Cache Hit: Encontrado instantaneamente --> A
    style B fill:#ffebee,stroke:#f44336,stroke-width:2px
    style C fill:#e3f2fd,stroke:#1e88e5

Comandos Essenciais do Redis (CLI):

SET chave valor: Grava uma chave de texto e seu respectivo valor associado.
GET chave: Busca e retorna o valor associado àquela chave.
EXPIRE chave segundos: Define um timer de contagem regressiva para expirar e auto-deletar a chave.
TTL chave: Retorna quantos segundos restam antes da chave sumir do mapa.
DEL chave: Remove a chave imediatamente antes da sua expiração.

📖 Exemplo Guiado: Subindo o Redis e Salvando Dados

1. Inicializando o Redis via Docker Terminal

No terminal do seu Windows (PowerShell), execute o comando abaixo para criar o container do Redis:

docker run --name redis-tecpro -p 6379:6379 -d redis

(Nota: O Redis roda nativamente na porta 6379).

2. Acessando a CLI do Redis para comandos

docker exec -it redis-tecpro redis-cli

Após rodar este comando, você entrará no console interativo do Redis (127.0.0.1:6379>).

3. Executando os Comandos Básicos de Cache

# Salvando o nome do entregador de plantão
127.0.0.1:6379> SET entregador_atual "Marcos Silva"
OK

# Buscando o dado
127.0.0.1:6379> GET entregador_atual
"Marcos Silva"

🛠️ Prática Obrigatória 1: Cache de Sessão com TTL

Cenário: Simulação de Token de Login na TecProExpress.

Acesse a CLI do seu Redis no terminal.
Crie uma chave chamada sessao:token:marcos contendo o valor "TK_MARCOS_2026_XYZ".
Configure um tempo de vida (TTL) de 45 segundos para esta chave usando o comando EXPIRE.
Execute repetidamente o comando TTL sessao:token:marcos para visualizar a contagem regressiva dos segundos.
Aguarde o cronômetro zerar (retorno -2) e confirme com GET se a chave foi completamente apagada do banco.

🛠️ Prática Obrigatória 2: Otimizando Acessos de Inventário

Cenário: Cache de contagem rápida de estoque.

No Redis, salve o estoque inicial de um produto: SET produto:id:101:estoque 50.
Use o comando especial de incremento INCR para adicionar 5 itens ao estoque de forma ultra-rápida:
```
INCRBY produto:id:101:estoque 5
```
Use o comando de decremento DECR para simular uma venda de 1 unidade:
```
DECR produto:id:101:estoque
```

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus testes interativos com o Redis CLI:

Salve um arquivo de texto com a extensão .txt ou .sh (Ex: Atividade_15_SeuNome.txt) contendo a sequência exata de comandos que você digitou na CLI para a Prática 1 e 2.
Anexe uma captura de tela mostrando a contagem regressiva do comando TTL no seu terminal.
Envie o arquivo de texto e o print na tarefa correspondente no Teams.

💡 Checkpoint de Lógica

[!IMPORTANT] Consistência de Cache: Se os dados do Redis são armazenados na memória RAM, o que acontece se o servidor cair ou o computador for reiniciado? (Resposta: A memória RAM é volátil, o que significa que todos os dados salvos sem backup serão apagados. O Redis possui mecanismos opcionais de persistência em disco (como RDB e AOF), mas a sua prioridade industrial sempre será a performance de cache de dados descartáveis/temporários). 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto Sênior 🏆

Pesquise sobre as estruturas de dados avançadas do Redis. Como você usaria a estrutura HSET (Hash Set) para salvar um perfil completo do entregador contendo nome, veículo e saldo em uma única chave complexa?

🔑 Gabarito de Código/Fórmulas Completo

CLI do Redis (Gabarito Oficial)

-- Prática 1: Fluxo de Token com Expiração
127.0.0.1:6379> SET sessao:token:marcos "TK_MARCOS_2026_XYZ"
OK
127.0.0.1:6379> EXPIRE sessao:token:marcos 45
(integer) 1

-- Verificando tempo restante
127.0.0.1:6379> TTL sessao:token:marcos
(integer) 39

-- Repetindo após 45 segundos
127.0.0.1:6379> TTL sessao:token:marcos
(integer) -2  # Significa que a chave já expirou e foi excluída!

127.0.0.1:6379> GET sessao:token:marcos
(nil)         # Nil indica que a chave é nula (não existe)

-- Prática 2: Contagem Atômica e Incrementos
127.0.0.1:6379> SET produto:id:101:estoque 50
OK
127.0.0.1:6379> INCRBY produto:id:101:estoque 5
(integer) 55
127.0.0.1:6379> DECR produto:id:101:estoque
(integer) 54

🔍 Explicação do Gabarito:

(integer) 1: Indica que o comando EXPIRE foi bem-sucedido. Retornará 0 se a chave informada não existir.
(nil): É a representação do valor nulo (null) no ecossistema Redis.
INCRBY / DECR: São operações atômicas no Redis. Isso garante que mesmo se 10.000 usuários tentarem comprar ao mesmo tempo, o estoque será decrementado um por um corretamente, sem perigo de colisão de dados de CPU.

🎯 ATIVIDADE 16 — CONECTANDO OS PONTOS

Bem-vindo à décima sexta semana (4 aulas) do curso de Banco de Dados. Em modelos de dados relacionais clássicos, modelar redes altamente conectadas (como redes sociais com milhões de amigos, sistemas de recomendação baseados em curtidas comuns ou rotas de frete interconectadas) é um pesadelo técnico de performance, pois exige dezenas de JOINS lentos. Hoje, conheceremos o Neo4j, a ferramenta mais poderosa para bancos de dados de Grafos (Graph Database), e aprenderemos a linguagem Cypher para navegar por relações complexas instantaneamente. 🛡️🕸️

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Compreender a diferença prática entre Tabelas (SQL) e Relações de Grafos (Nós e Arestas).
Instalar e executar o Neo4j localmente através do Docker Desktop ou Neo4j Desktop.
Dominar comandos de modelagem física e busca em linguagem Cypher.
Criar Nós (Nodes), Propriedades (Properties) e Relacionamentos (Relationships) no Grafo.
Consultar rotas e encontrar o caminho mais curto usando funções de busca.

🏢 O Cenário Prático (Seu Desafio)

O departamento de roteamento de Last Mile da TecProExpress quer otimizar a distribuição de entregas no Sudeste do Brasil. Eles precisam de um mapa interativo onde:

Cidades são pontos de conexão (Nós).
Rodovias que conectam essas cidades são as conexões (Relacionamentos).
Cada relacionamento tem uma propriedade física de Custo/Distância em quilômetros.

Seu desafio é criar essa malha viária em formato de Grafo no Neo4j e executar uma busca em Cypher para encontrar a melhor rota e calcular a distância total de transporte entre São Paulo e Belo Horizonte.

🧠 Fundamentos: A Teoria Traduzida

A Anatomia dos Grafos

Diferente de tabelas que possuem linhas de grade, os bancos de grafos utilizam a matemática de Grafos para armazenar e organizar informações:

graph LR
    SP(("Cidade: São Paulo")) -- "RODOVIA {distancia: 430}" --> RJ(("Cidade: Rio de Janeiro"))
    SP -- "RODOVIA {distancia: 580}" --> BH(("Cidade: Belo Horizonte"))
    RJ -- "RODOVIA {distancia: 440}" --> BH
    style SP fill:#bbdefb,stroke:#1e88e5
    style RJ fill:#bbdefb,stroke:#1e88e5
    style BH fill:#bbdefb,stroke:#1e88e5

Nó (Node): A entidade do mundo real (ex: uma Cidade, uma Pessoa ou um Pedido).
Relacionamento (Relationship / Edge): A conexão física direcionada entre dois nós. Possui obrigatoriamente um Tipo de Relação (ex: -[:RODOVIA]->).
Propriedade (Property): Pares de chave-valor salvos nos nós ou nos relacionamentos (ex: nome: "São Paulo", distancia: 430).

Linguagem Cypher (Analogia de Busca):

Cypher é uma linguagem baseada em artes ASCII desenhadas em formato de texto para facilitar o reconhecimento visual dos relacionamentos pelo programador:

() representa um Nó (símbolo de círculo).
[] representa um Relacionamento (símbolo de caixa).
--> representa o direcionamento da conexão (uma seta física).

📖 Exemplo Guiado: Criando o Primeiro Grafo

1. Inicializando o Neo4j via Docker Terminal

Execute o comando abaixo no terminal do PowerShell/Bash:

docker run --name neo4j-tecpro -p 7474:7474 -p 7687:7687 -d -e NEO4J_AUTH=neo4j/senha_forte_123 neo4j

(Nota: A porta 7474 serve para o console de interface web do Neo4j, e a porta 7687 serve para tráfego binário de dados via Bolt).

2. Acessando a Interface de Consulta (Neo4j Browser)

Abra seu navegador e digite o endereço: http://localhost:7474. Faça login com o usuário neo4j e a senha definida senha_forte_123.

3. Criando as Cidades no Grafo (Comando Cypher)

// Criando três cidades no Neo4j
CREATE (sp:Cidade {nome: "São Paulo", estado: "SP"})
CREATE (rj:Cidade {nome: "Rio de Janeiro", estado: "RJ"})
CREATE (bh:Cidade {nome: "Belo Horizonte", estado: "MG"})

4. Estabelecendo Conexões (Relacionamentos)

// Buscando as cidades criadas e criando as rodovias
MATCH (sp:Cidade {nome: "São Paulo"}), (rj:Cidade {nome: "Rio de Janeiro"})
CREATE (sp)-[:RODOVIA {distancia: 430}]->(rj)

🛠️ Prática Obrigatória 1: Criando a Malha Sudeste

Acesse o painel do seu Neo4j Browser.
Crie as cidades de São Paulo, Rio de Janeiro e Belo Horizonte.
Crie os seguintes relacionamentos de estradas no seu painel:
- São Paulo para Rio de Janeiro com distância de 430 km.
- Rio de Janeiro para Belo Horizonte com distância de 440 km.
- São Paulo para Belo Horizonte com distância de 580 km (Rodovia direta Fernão Dias).
Escreva a consulta em Cypher para recuperar todos os nós da sua tela.

🛠️ Prática Obrigatória 2: Buscando Caminhos no Grafo

Escreva uma consulta em Cypher que localize todas as cidades conectadas diretamente a São Paulo.
Escreva uma consulta em Cypher que localize as rodovias cuja distância seja menor do que 500 km.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas consultas de Grafos no Neo4j Browser:

Salve todas as queries de criação e busca Cypher em um arquivo com a extensão .cypher ou .txt (Ex: Atividade_16_SeuNome.cypher).
Anexe uma captura de tela mostrando a visualização gráfica (o desenho de bolas e setas interconectadas) gerada na tela do Neo4j Browser.
Envie o arquivo de texto e o print na tarefa correspondente no Teams.

💡 Checkpoint de Lógica

[!IMPORTANT] Índices de Relacionamentos: Em bancos SQL, buscar caminhos indiretos (ex: Amigo do Amigo do Amigo) exige processar cruzamentos de tabelas inteiras na memória temporária. No Neo4j, as relações são salvas fisicamente com ponteiros diretos de memória nos nós. Isso faz com que navegar por relações complexas demore frações de milissegundos, independente do tamanho total do banco de dados! 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Cientista de Dados de Redes 🏆

Pesquise sobre funções matemáticas em Cypher. Como você utilizaria o operador MATCH p = shortestPath(...) para fazer o Neo4j calcular automaticamente qual é o caminho mais curto físico entre São Paulo e Belo Horizonte na malha viária?

🔑 Gabarito de Código/Fórmulas Completo

Painel Cypher (Gabarito Oficial)

-- Prática 1: Criação da Malha Viária
CREATE (sp:Cidade {nome: "São Paulo", estado: "SP"}),
       (rj:Cidade {nome: "Rio de Janeiro", estado: "RJ"}),
       (bh:Cidade {nome: "Belo Horizonte", estado: "MG"})
       
MATCH (a:Cidade {nome: "São Paulo"}), (b:Cidade {nome: "Rio de Janeiro"})
CREATE (a)-[:RODOVIA {distancia: 430}]->(b)

MATCH (b:Cidade {nome: "Rio de Janeiro"}), (c:Cidade {nome: "Belo Horizonte"})
CREATE (b)-[:RODOVIA {distancia: 440}]->(c)

MATCH (a:Cidade {nome: "São Paulo"}), (c:Cidade {nome: "Belo Horizonte"})
CREATE (a)-[:RODOVIA {distancia: 580}]->(c)

-- Prática 2: Consultas
-- 1. Cidades conectadas diretamente a São Paulo
MATCH (sp:Cidade {nome: "São Paulo"})-[r:RODOVIA]->(destino)
RETURN destino.nome, r.distancia;

-- 2. Rodovias com distância menor que 500km
MATCH (origem)-[r:RODOVIA]->(destino)
WHERE r.distancia < 500
RETURN origem.nome, destino.nome, r.distancia;

🔍 Explicação do Gabarito:

MATCH: Cláusula que localiza padrões geométricos descritos em formato ASCII.
-[r:RODOVIA]->: Identifica e atribui a variável r ao relacionamento para podermos filtrar ou exibir as propriedades dele.
shortestPath: O algoritmo interno do Neo4j varre os ponteiros de memória em largura (Breadth-First Search) para achar o menor número de saltos físicos instantaneamente.

🎯 ATIVIDADE 17 — O CÉREBRO DA IA

Bem-vindo à décima sétima semana (4 aulas) do curso de Banco de Dados. Com a ascensão da Inteligência Artificial Generativa (LLMs como ChatGPT, Claude e Gemini), a forma como pesquisamos dados mudou de rumo. Buscar por palavras-chave exatas (como SELECT * WHERE nome LIKE '%sapato%') não é suficiente para sistemas inteligentes. Hoje, entraremos no topo da inovação tecnológica conhecendo os Bancos de Dados Vetoriais (Vector Database) e aprenderemos a utilizar a extensão pgvector do PostgreSQL para realizar pesquisas semânticas baseadas em inteligência artificial. 🛡️🧠

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Compreender o conceito de Embeddings Vetoriais (conversão de significados textuais em vetores numéricos de alta dimensão).
Instalar e configurar a extensão pgvector em um banco PostgreSQL local.
Criar tabelas relacionais contendo dados do tipo VECTOR (vetoriais).
Executar consultas de busca semântica por similaridade de cosseno utilizando operadores vetoriais (<=>).

🏢 O Cenário Prático (Seu Desafio)

O time de marketing da TecProExpress quer um recomendador de produtos inteligente. Se o cliente pesquisar no app por "equipamento à prova d'água para transportar cargas sob chuva", o sistema deve retornar o produto "Bolsa de Lona Selada" ou "Baú Impermeável", mesmo se a palavra "chuva" ou "água" não estiver escrita na descrição física do produto!

Seu desafio como Arquiteto de IA e Dados é habilitar a extensão pgvector no seu PostgreSQL, criar a tabela de produtos com uma coluna de embeddings de 3 dimensões (simplificada para fins didáticos) e escrever consultas de busca semântica que encontrem os produtos com significados mais próximos ao termo de busca do usuário.

🧠 Fundamentos: A Teoria Traduzida

O que são Embeddings Vetoriais?

Imagine que cada palavra ou frase do mundo real possui um significado que pode ser representado por coordenadas em um mapa espacial de muitas dimensões. A inteligência artificial lê os textos e os converte em um array de números decimais (vetor).

Textos com significados parecidos (ex: "Entregador" e "Motociclista") ficam posicionados muito próximos no mapa tridimensional.
Textos com significados distantes (ex: "Caminhão" e "Banana") ficam muito distantes.

flowchart TD
    subgraph EspacoVetorial ["Espaço Vetorial 3D de Significados"]
        P1["Bolsa Impermeável (0.98, 0.12, 0.05)"] --- P2["Mochila Selada (0.95, 0.15, 0.08)"]
        P1 -.->|Distância de Cosseno Curta| P2
        P3["Teclado Mecânico (0.02, 0.88, 0.95)"] 
        P2 -.->|Distância Longa| P3
    end

Operadores de Distância no pgvector:

<->: Distância L2 (Euclidiana) - mede a distância física reta entre pontos.
<#>: Distância de Produto Interno (Negative Inner Product).
<=>: Distância de Cosseno (Cosine Distance) - mede a diferença de ângulo entre os vetores de significados. É a mais usada na indústria para buscas de IA e semântica.

📖 Exemplo Guiado: Preparando o pgvector

1. Habilitando a Extensão no PostgreSQL

-- Primeiro, criamos um banco dedicado
CREATE DATABASE tecpro_ia;
-- (Nota: Abra uma Query Tool conectada ao banco tecpro_ia)

-- Habilitando a biblioteca pgvector
CREATE EXTENSION IF NOT EXISTS vector;

(Nota: Se você estiver usando o pgAdmin local, certifique-se de que a extensão pgvector está instalada no seu servidor Postgres. Ela vem habilitada por padrão na imagem Docker pgvector/pgvector no Docker Hub).

2. Criando Tabela com Coluna Vetorial

CREATE TABLE produto_ia (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(100),
    descricao TEXT,
    vetor_significado VECTOR(3) -- Vetor tridimensional de embeddings
);

3. Populando o Banco com Embeddings Simulados

INSERT INTO produto_ia (nome, descricao, vetor_significado) VALUES 
('Baú Impermeável', 'Proteção total contra água e chuvas intensas', '[0.95, 0.12, 0.05]'),
('Mochila Estanque', 'Bolsa selada hermeticamente para transporte úmido', '[0.91, 0.14, 0.07]'),
('Teclado Mecânico RGB', 'Dispositivo de entrada com switches mecânicos retroiluminados', '[0.02, 0.85, 0.98]');

🛠️ Prática Obrigatória 1: Busca Semântica por Cosseno

Cenário: O usuário pesquisou por "mochila para chuva". A IA gerou a coordenada de busca: [0.89, 0.15, 0.08].

Escreva uma consulta SQL que utilize o operador de similaridade de cosseno (<=>) para ordenar os produtos do mais próximo ao mais distante em relação à busca do usuário.
Adicione um limite (LIMIT 2) para retornar apenas os 2 produtos mais parecidos semanticamente.

🛠️ Prática Obrigatória 2: Análise de Custo Vetorial

Escreva a mesma consulta utilizando a Distância Euclidiana (<->).
Pesquise na internet qual a finalidade de usar um Índice HNSW (Hierarchical Navigable Small World) ou IVFFlat sobre colunas do tipo VECTOR em tabelas com milhões de registros vetoriais.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas buscas vetoriais com o pgvector:

Salve o script SQL completo contendo a inicialização do pgvector, as inserções de embeddings e as buscas semânticas ordenadas por distância em um arquivo .sql (Ex: Atividade_17_SeuNome.sql).
Adicione comentários no código explicando o que são Embeddings Vetoriais de forma simples e didática.
Envie o arquivo .sql correspondente no Microsoft Teams para avaliação.

💡 Checkpoint de Lógica

[!IMPORTANT] A Importância da Dimensão: Nos nossos exercícios, usamos VECTOR(3) (três dimensões) para facilitar a visualização didática. Na indústria real, modelos de IA profissionais (como o Ada-002 da OpenAI ou o Gecko do Google Vertex AI) geram embeddings com 1536 ou mais dimensões de profundidade para capturar as nuances complexas da linguagem humana! 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto de IA Generativa 🏆

Escreva uma query SQL que retorne a distância numérica exata de similaridade de cosseno entre a busca do usuário [0.89, 0.15, 0.08] e os produtos da tabela, renomeando a coluna de cálculo como distancia_calculada.

🔑 Gabarito de Código/Fórmulas Completo

🐘 Padrão PostgreSQL (pgvector)

-- Habilita a extensão de IA
CREATE EXTENSION IF NOT EXISTS vector;

-- Criação da tabela
CREATE TABLE produto_ia (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(100),
    descricao TEXT,
    vetor_significado VECTOR(3)
);

-- Carga de Testes
INSERT INTO produto_ia (nome, descricao, vetor_significado) VALUES 
('Baú Impermeável', 'Proteção total contra água e chuvas intensas', '[0.95, 0.12, 0.05]'),
('Mochila Estanque', 'Bolsa selada hermeticamente para transporte úmido', '[0.91, 0.14, 0.07]'),
('Teclado Mecânico RGB', 'Dispositivo de entrada com switches mecânicos retroiluminados', '[0.02, 0.85, 0.98]');

-- Prática 1: Busca Semântica com Similaridade de Cosseno (<=>)
SELECT nome, descricao
FROM produto_ia
ORDER BY vetor_significado <=> '[0.89, 0.15, 0.08]'
LIMIT 2;

-- Resposta ao Desafio (Cálculo de Distância Exata de Cosseno)
SELECT nome, vetor_significado <=> '[0.89, 0.15, 0.08]' AS distancia_calculada
FROM produto_ia
ORDER BY distancia_calculada ASC;

🔍 Explicação do Gabarito:

vetor_significado <=> [...]: O operador <=> realiza a matemática de similaridade de cosseno (mede o cosseno do ângulo entre os dois vetores). Valores próximos a 0 indicam vetores quase idênticos de significado. Valores próximos a 1 indicam alta divergência.
ORDER BY ... ASC: Ordena do menor valor de distância para o maior, ou seja, os itens mais similares no topo da lista.
Índices IVFFlat e HNSW: Permitem realizar buscas rápidas de aproximação por vizinhos (Approximate Nearest Neighbors - ANN) em frações de segundos sobre milhões de vetores sem precisar realizar cálculos matemáticos individuais com toda a base de dados (Seq Scan Vetorial).

🎯 ATIVIDADE 18 — A VISÃO DO BOARD

Bem-vindo à décima oitava semana (4 aulas) do curso de Banco de Dados. Até aqui, projetamos apenas bancos de dados OLTP (Online Transaction Processing), que são ideais para o dia a dia operacional rápido (cadastrar cliente, fazer pedido, debitar saldo). No entanto, quando os executivos precisam tomar decisões macro (ex: "Qual o crescimento anual de vendas por estado nos últimos 5 anos?"), consultas analíticas em sistemas OLTP travam as transações diárias. Hoje, aprenderemos a projetar bancos de dados OLAP (Online Analytical Processing) utilizando a Modelagem Dimensional (Star Schema). 🛡️📈

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Compreender a diferença arquitetural e de performance entre sistemas OLTP e OLAP.
Identificar e desenhar componentes de modelagem dimensional: Tabela Fato e Tabelas Dimensão.
Projetar esquemas de modelagem dimensional no formato Star Schema (Esquema Estrela).
Executar consultas analíticas rápidas de BI cruzando fatos e dimensões.

🏢 O Cenário Prático (Seu Desafio)

O Diretor de BI da TecProExpress quer um relatório interativo (painel de dados) para acompanhar a performance histórica de vendas. Ele quer analisar o faturamento por:

Tempo: Ano, Trimestre, Mês, Dia.
Cliente: Nome, Gênero, Cidade, Estado.
Produto: Nome, Categoria, SKU.

Como Engenheiro de Analytics (Analytics Engineer), seu desafio é modelar e implementar uma estrutura analítica de Star Schema contendo a tabela central de fatos (fato_vendas) conectada a três tabelas de dimensões (dim_tempo, dim_cliente, dim_produto). Você preencherá a estrutura e extrairá as métricas consolidadas solicitadas pelo board.

🧠 Fundamentos: A Teoria Traduzida

OLTP vs. OLAP

Recurso	Banco de Dados OLTP (Operacional)	Banco de Dados OLAP (Analítico / DW)
Objetivo	Transações rápidas e integridade	Consultas complexas de relatórios
Design	Altamente normalizado (3FN) para evitar duplicados	Desnormalizado (Dimensional) para velocidade de leitura
Operação	Muitos `INSERT`, `UPDATE`, `DELETE` rápidos	Poucos `SELECT` gigantescos rodando em lote (Batch)

Anatomia do Star Schema (Esquema Estrela)

Na modelagem dimensional, organizamos os dados de forma que a tabela de métricas fique no centro, cercada pelas dimensões:

flowchart TD
    DimCliente["dim_cliente - Quem?"] --- FatoVendas["fato_vendas - Métricas/Valores"]
    DimProduto["dim_produto - O que?"] --- FatoVendas
    DimTempo["dim_tempo - Quando?"] --- FatoVendas
    style FatoVendas fill:#ffe0b2,stroke:#fb8c00,stroke-width:2px
    style DimCliente fill:#e3f2fd,stroke:#1e88e5
    style DimProduto fill:#e3f2fd,stroke:#1e88e5
    style DimTempo fill:#e3f2fd,stroke:#1e88e5

Tabela Fato: Contém as métricas quantitativas (ex: valor total, quantidade vendida) e as chaves estrangeiras que apontam para as dimensões. Registra acontecimentos históricos (fatos).
Tabela Dimensão: Contém os atributos descritivos qualificativos que servem de filtro para a métrica (ex: nome do cliente, ano da venda, cor do produto).

📖 Exemplo Guiado: Criando o Star Schema

1. Inicializando o Data Warehouse (Lógico)

CREATE DATABASE tecpro_dw;
-- (Nota: No pgAdmin, abra a Query Tool apontando para o banco tecpro_dw)

2. Criando as Tabelas Dimensão (Desnormalizadas)

CREATE TABLE dim_cliente (
    sk_cliente SERIAL PRIMARY KEY, -- SK = Surrogate Key (Chave Analítica)
    id_operacional INT,
    nome VARCHAR(100),
    cidade VARCHAR(100),
    estado CHAR(2)
);

CREATE TABLE dim_produto (
    sk_produto SERIAL PRIMARY KEY,
    id_operacional INT,
    nome VARCHAR(100),
    categoria VARCHAR(50)
);

3. Criando a Tabela Fato Central

CREATE TABLE fato_vendas (
    sk_cliente INT REFERENCES dim_cliente(sk_cliente),
    sk_produto INT REFERENCES dim_produto(sk_produto),
    quantidade INT,
    valor_total DECIMAL(12,2),
    PRIMARY KEY (sk_cliente, sk_produto)
);

🛠️ Prática Obrigatória 1: Criando a Dimensão Tempo

Na modelagem de Data Warehouse, a dimensão Tempo é essencial para evitar o uso lento de funções de manipulação de data (como EXTRACT) em tempo de consulta.

Crie a tabela dim_tempo contendo as colunas: sk_tempo (PK), data_completa (DATE), ano (INT), trimestre (INT), mes (INT) e dia (INT).
Adicione a chave estrangeira sk_tempo à tabela fato_vendas como parte da chave composta.

🛠️ Prática Obrigatória 2: Consulta Analítica OLAP

Popule as dimensões e a tabela fato com dados simulados de vendas da TecProExpress.
Escreva uma consulta analítica OLAP que retorne o Faturamento Total consolidado por Estado do Cliente no ano de 2026. (Dica: Você precisará cruzar a fato_vendas com dim_cliente e dim_tempo usando joins rápidos).

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas consultas analíticas no Data Warehouse local:

Salve o script SQL completo contendo a criação do Star Schema completo (Fato e 3 Dimensões), os scripts de inserção e a consulta analítica final em um arquivo .sql (Ex: Atividade_18_SeuNome.sql).
Adicione comentários no código explicando o que são Surrogate Keys (SK) analíticas e qual a diferença delas em relação às Chaves Primárias Operacionais (PK).
Envie o arquivo .sql correspondente no Microsoft Teams para avaliação.

💡 Checkpoint de Lógica

[!IMPORTANT] Star Schema vs. Snowflake Schema: No Star Schema, as tabelas dimensão são mantidas desnormalizadas (têm dados repetidos) para que o banco faça apenas 1 join direto com o fato. No Snowflake Schema (Esquema Floco de Neve), as dimensões são normalizadas em tabelas secundárias (ex: dim_cidade ligada a dim_estado). O Snowflake economiza espaço, mas deixa as buscas de BI lentas por causa dos joins em cascata. Na indústria de Big Data, priorizamos a velocidade e preferimos o Star Schema. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto de Analytics (CTO) 🏆

Pesquise sobre as operações analíticas clássicas do cubo OLAP: Drill-down, Roll-up, Slice e Dice. Escreva um pequeno parágrafo didático explicando a diferença teórica entre Drill-down e Roll-up no contexto de análise temporal.

🔑 Gabarito de Código/Fórmulas Completo

🐘 Padrão PostgreSQL (pgAdmin)

-- 1. Criação do Esquema Físico Analítico
CREATE TABLE dim_cliente (
    sk_cliente SERIAL PRIMARY KEY,
    id_operacional INT,
    nome VARCHAR(100),
    cidade VARCHAR(100),
    estado CHAR(2)
);

CREATE TABLE dim_produto (
    sk_produto SERIAL PRIMARY KEY,
    id_operacional INT,
    nome VARCHAR(100),
    categoria VARCHAR(50)
);

CREATE TABLE dim_tempo (
    sk_tempo SERIAL PRIMARY KEY,
    data_completa DATE,
    ano INT,
    trimestre INT,
    mes INT,
    dia INT
);

CREATE TABLE fato_vendas (
    sk_cliente INT REFERENCES dim_cliente(sk_cliente),
    sk_produto INT REFERENCES dim_produto(sk_produto),
    sk_tempo INT REFERENCES dim_tempo(sk_tempo),
    quantidade INT,
    valor_total DECIMAL(12,2),
    PRIMARY KEY (sk_cliente, sk_produto, sk_tempo)
);

-- 2. Carga de Dados (Seeds)
INSERT INTO dim_cliente (id_operacional, nome, cidade, estado) VALUES 
(10, 'Marcos Silva', 'São Paulo', 'SP'),
(11, 'Julia Costa', 'Rio de Janeiro', 'RJ');

INSERT INTO dim_produto (id_operacional, nome, categoria) VALUES 
(501, 'Capacete Pro', 'Equipamento'),
(502, 'Carregador Celular', 'Eletrônicos');

INSERT INTO dim_tempo (data_completa, ano, trimestre, mes, dia) VALUES 
('2026-05-19', 2026, 2, 5, 19);

-- Marcos comprou um Capacete Pro no dia 19/05/2026 por R$ 300.00
INSERT INTO fato_vendas VALUES (1, 1, 1, 1, 300.00);

-- 3. Consulta Analítica OLAP
SELECT c.estado, SUM(f.valor_total) AS faturamento_consolidado
FROM fato_vendas f
INNER JOIN dim_cliente c ON f.sk_cliente = c.sk_cliente
INNER JOIN dim_tempo t ON f.sk_tempo = t.sk_tempo
WHERE t.ano = 2026
GROUP BY c.estado;

🔍 Explicação do Gabarito:

Surrogate Keys (SK): Chaves primárias sintéticas independentes dos códigos das tabelas operacionais de produção (id_operacional). Isso blinda o Data Warehouse caso o sistema produtivo mude as chaves reais amanhã.
SUM(f.valor_total): As tabelas fato centralizam as agregações analíticas numéricas.
Drill-down vs Roll-up:
- Drill-down: Detalha o nível analítico (desce a hierarquia, ex: de Ano para Mês).
- Roll-up: Agrupa e consolida o nível analítico (sobe a hierarquia, ex: de Mês para Ano).

🎯 ATIVIDADE 19 — EVOLUÇÃO SEM DOR

Bem-vindo à décima nona semana (4 aulas) do curso de Banco de Dados. Até aqui, trabalhamos com bancos de dados de forma estática: criamos o banco no primeiro dia e rodamos consultas nele. No entanto, no mundo real das startups de crescimento acelerado e grandes corporações, o software muda diariamente. E se precisarmos adicionar uma coluna de pontuação, renomear um campo ou criar uma nova tabela sem desligar o sistema de produção?

Hoje, aprenderemos a realizar a Evolução de Esquemas (Database Schema Migrations), compreendendo como pipelines de CI/CD implantam alterações estruturais de forma segura e sem downtime usando o padrão Expand and Contract (Expandir e Contrair). 🛡️🔄

🎯 Objetivo da Aula

Ao final desta semana, você será capaz de:

Compreender o conceito de Versionamento de Banco de Dados (Database Migrations).
Escrever scripts estruturados de Up (avançar) e Down (desfazer) para controle de versão de schemas.
Diferenciar o suporte à DDL Transacional entre PostgreSQL (suportado com rollback completo) e MySQL (não suportado devido a commits implícitos).
Aplicar o padrão de design Expand and Contract para realizar refatorações de chaves e campos sem indisponibilidade (Zero-Downtime).

🏢 O Cenário Prático (Seu Desafio)

A equipe de engenharia da TecProExpress quer lançar um Programa de Fidelidade para recompensar os clientes mais ativos. Para suportar a nova funcionalidade, precisamos adicionar a coluna pontos_fidelidade à tabela cliente.

Como Engenheiro de DevOps e Banco de Dados (Database Reliability Engineer - DBRE), seu desafio é criar os arquivos de migração estruturados para essa alteração estrutural. Além disso, a empresa deseja renomear o campo antigo telefone para celular sem parar a operação móvel de entregadores que dependem desta coluna a cada segundo. Você deve planejar essa evolução com segurança de nível sênior.

🧠 Fundamentos: A Teoria Traduzida

O que são Database Migrations?

Imagine o Git para bancos de dados. Uma Migration é um arquivo de script versionado (geralmente numerado cronologicamente, ex: V1__criar_tabelas.sql, V2__adicionar_fidelidade.sql) que descreve exatamente como transicionar a estrutura do banco do estado A para o estado B.

Up Migration: Aplica a mudança física no banco de dados (ex: ALTER TABLE ADD COLUMN).
Down Migration: Desfaz a mudança física, restaurando o banco ao estado anterior caso algo dê errado em produção (ex: ALTER TABLE DROP COLUMN).

flowchart LR
    V1["Estado Inicial (V1)"] -- "Up Migration" --> V2["Estado Novo (V2)"]
    V2 -- "Down Migration (Rollback)" --> V1
    style V1 fill:#e3f2fd,stroke:#1e88e5
    style V2 fill:#e8f5e9,stroke:#4caf50

O Perigo Oculto: DDL Transacional (PostgreSQL vs. MySQL)

Este é um dos maiores pontos de falha em equipes de tecnologia júnior:

PostgreSQL (SGBD Superior em DDL): Suporta DDL Transacional. Se você colocar comandos ALTER TABLE ou CREATE INDEX dentro de uma transação (BEGIN; ... COMMIT;), e um comando no meio falhar, o Postgres reverte toda a estrutura de volta ao início (ROLLBACK). Nenhuma alteração incompleta ou corrompida sobrevive.
MySQL (Limitação Histórica): Não suporta DDL Transacional. Comandos DDL no MySQL acionam o que chamamos de Commit Implícito. Se você tentar colocar três comandos ALTER TABLE em um bloco de transação e o segundo falhar, as alterações do primeiro já terão sido salvas permanentemente em disco! Você terá uma "migration pela metade", o que exige intervenção manual de emergência.

📖 Exemplo Guiado: Usando DDL Transacional no pgAdmin

1. Preparando o Cenário de Teste (PostgreSQL)

CREATE DATABASE tecpro_producao;
-- (Nota: No pgAdmin, abra a Query Tool apontando para tecpro_producao)

CREATE TABLE cliente (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(100) NOT NULL,
    telefone VARCHAR(20)
);

INSERT INTO cliente (nome, telefone) VALUES ('Alice Silva', '11999999999');

2. Rodando uma Migration Transacional Segura (PostgreSQL)

BEGIN;

-- Tentamos alterar a tabela de forma segura
ALTER TABLE cliente ADD COLUMN pontos_fidelidade INT DEFAULT 0;

-- Simulamos um erro intencional no final para testar a segurança
-- (A tabela abaixo 'tabela_inexistente' causará um erro de sintaxe ou execução)
ALTER TABLE tabela_inexistente ADD COLUMN coluna_teste INT;

COMMIT;

No PostgreSQL, ao executar o bloco acima, você verá que o erro na segunda instrução cancelou a transação inteira. Se você fizer um SELECT * FROM cliente;, a coluna pontos_fidelidade não foi criada! O banco manteve-se íntegro.

🛠️ Prática Obrigatória 1: Versionando Migrations (Up e Down)

Para manter a consistência com frameworks profissionais de migração (como Flyway, Liquibase ou Prisma Migrations), você deve separar a lógica de alteração física da base de dados em arquivos de Up e Down estruturados.

Escreva o arquivo de migração segura V2__adicionar_fidelidade.up.sql para o PostgreSQL. Ele deve conter a criação da nova coluna pontos_fidelidade (com valor padrão 0 e restrição NOT NULL) dentro de um bloco transacional íntegro.
Escreva o arquivo correspondente de reversão V2__adicionar_fidelidade.down.sql que remove a coluna criada caso a equipe de negócios decida cancelar a funcionalidade.

🛠️ Prática Obrigatória 2: Refatoração Sem Downtime (Expand & Contract)

O Problema Sênior: Renomear colunas em bases de dados ativas na produção (ALTER TABLE RENAME COLUMN telefone TO celular) é altamente perigoso. Se a aplicação antiga tentar escrever em telefone enquanto a migration roda, a escrita falhará, gerando queda no sistema (downtime).

Para resolver isso, aplicamos a estratégia Expand and Contract (Expandir e Contrair):

flowchart TD
    E1["1. EXPANDIR: Cria a nova coluna 'celular' mantendo a antiga 'telefone'"] --> E2["2. TRANSIÇÃO: Sistema grava nas duas colunas simultaneamente (Dual Write)"]
    E2 --> E3["3. CARGA: Roda script DML para migrar dados históricos de telefone para celular"]
    E3 --> E4["4. CONTRAIR: Atualiza a aplicação para ler apenas da 'celular' e dropa 'telefone'"]
    style E1 fill:#e1f5fe
    style E4 fill:#ffebee

Escreva um script SQL que realize o Passo 1 (Expandir), adicionando a coluna celular na tabela cliente.
Escreva um script SQL DML que realize o Passo 3 (Carga), atualizando o campo celular com os valores existentes de telefone em todos os registros do banco.
Escreva o script final de Passo 4 (Contrair) que exclui a coluna telefone com segurança após a homologação das novas APIs.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas transações de DDL e estratégias de migração localmente:

Salve seus scripts estruturados organizados em uma estrutura de arquivos de versionamento:
- V2__adicionar_fidelidade.up.sql
- V2__adicionar_fidelidade.down.sql
- V3__refatorar_telefone_celular.up.sql (contendo os passos de Expand, Carga e Drop comentados passo a passo).
Adicione ao início de um arquivo de texto explicativo a comparação entre PostgreSQL e MySQL sobre o suporte a DDL Transacional, respondendo por que essa diferença impacta a escolha tecnológica de um time de DevOps.
Envie o conjunto de arquivos compactados ou em seu repositório no Microsoft Teams para avaliação técnica.

💡 Checkpoint de Lógica

[!IMPORTANT] Evitando Locks de Tabelas Grandes: Em bancos de dados de produção com milhões de linhas, adicionar colunas com valores padrão (ex: DEFAULT 'Valor' NOT NULL) ou criar índices normais bloqueia temporariamente a tabela para leitura e escrita, gerando interrupções graves de serviço.

No PostgreSQL, usamos CREATE INDEX CONCURRENTLY para compilar o índice em segundo plano sem bloquear transações.

No MySQL, indicamos ALGORITHM=INPLACE, LOCK=NONE na DDL para sinalizar ao SGBD a realização de alterações online. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto de DevOps / SRE Sênior 🏆

Escreva um script de trigger em PL/pgSQL (PostgreSQL) que automatize a sincronização durante a fase de transição (Dual Write) do padrão Expand and Contract: sempre que a coluna antiga telefone for atualizada, a nova coluna celular deve receber o mesmo valor de forma automática via gatilho, blindando sistemas legados que ainda escrevem no campo antigo.

🔑 Gabarito de Código/Fórmulas Completo

🐘 Padrão PostgreSQL (pgAdmin)

Arquivo: `V2__adicionar_fidelidade.up.sql`

BEGIN;

-- 1. Cria a coluna com valor default seguro
ALTER TABLE cliente ADD COLUMN pontos_fidelidade INT NOT NULL DEFAULT 0;

COMMIT;

Arquivo: `V2__adicionar_fidelidade.down.sql`

BEGIN;

-- 1. Remove a coluna criada na versão V2
ALTER TABLE cliente DROP COLUMN IF EXISTS pontos_fidelidade;

COMMIT;

Arquivo: `V3__refatorar_telefone_celular.up.sql`

-- ESTRATÉGIA EXPAND AND CONTRACT (Zero Downtime)

-- [PASSO 1: EXPANDIR]
-- Criamos a nova coluna mantendo a antiga ativa para evitar quebra em produção
ALTER TABLE cliente ADD COLUMN celular VARCHAR(20);

-- [PASSO 3: CARGA DOS HISTÓRICOS]
-- Migramos todos os telefones antigos cadastrados para a nova coluna celular
UPDATE cliente 
SET celular = telefone 
WHERE celular IS NULL AND telefone IS NOT NULL;

-- (Nota: A aplicação agora é atualizada na produção para escrever e ler apenas de 'celular')

-- [PASSO 4: CONTRAIR]
-- Com segurança e após homologação completa, dropamos a coluna depreciada 'telefone'
ALTER TABLE cliente DROP COLUMN telefone;

🐬 Comparativo de Sintaxe: Padrão MySQL

-- ATENÇÃO: No MySQL, ALTER TABLE ativa commit implícito.
-- Não coloque DDLs MySQL em blocos de transações (START TRANSACTION/COMMIT).

-- Up Migration no MySQL
ALTER TABLE cliente ADD COLUMN pontos_fidelidade INT NOT NULL DEFAULT 0;

-- Zero Downtime Expand and Contract (MySQL)
ALTER TABLE cliente ADD COLUMN celular VARCHAR(20) AFTER telefone;

UPDATE cliente 
SET celular = telefone 
WHERE celular IS NULL AND telefone IS NOT NULL;

ALTER TABLE cliente DROP COLUMN telefone;

🔍 Explicação do Gabarito:

DDL Transacional no PostgreSQL: Se o ALTER TABLE falhar devido a algum bloqueio (lock), o BEGIN garante que a tabela não será modificada pela metade, revertendo tudo para o estado original.
Dual Write / Migração de Dados: O comando UPDATE sincroniza o estado dos dados históricos. Em tabelas gigantescas, essa carga é executada em lotes pequenos (ex: 5000 linhas por vez) para evitar o travamento completo do banco por horas.
Implicit Commits: No MySQL, comandos como ALTER TABLE, DROP TABLE, CREATE TABLE salvam as mudanças imediatamente na estrutura do disco de dados e terminam a transação em execução silenciosamente, impedindo qualquer chance de ROLLBACK.

🎯 ATIVIDADE 20 — ARQUITETO SUPREMO

Parabéns! Você alcançou a vigésima semana do curso de Banco de Dados. Chegar até aqui é a prova definitiva do seu comprometimento e evolução técnica. De um estudante que estava instalando o SGBD local na primeira semana, você se transformou em um Engenheiro de Dados Sênior / Arquiteto de Soluções de Alta Performance.

O desafio final da Fase 2 é criar uma arquitetura de dados poliglota completa para a plataforma global TecProExpress Enterprise Engine, projetada para lidar com milhões de transações por minuto, auditorias em tempo real, cache veloz de motoristas e recomendações inteligentes baseadas em IA. 🛡️🏆

🎯 Objetivo da Aula

Ao final desta semana, você terá projetado e implementado:

A Persistência Poliglota (Polyglot Persistence) em ambiente real, usando cada banco de dados para seu propósito ideal.
Uma camada de transações relacionais segura (ACID) em PostgreSQL com triggers de integridade física de estoque.
Um sistema de cache e rastreamento em tempo real extremamente rápido com Redis.
Uma central de auditoria e logs telemétricos flexíveis de sensores em MongoDB.
Um mecanismo de recomendação semântica inteligente de rotas baseado em IA usando pgvector.

🏢 O Cenário Prático (Seu Desafio Final)

A TecProExpress fechou uma aliança internacional com grandes indústrias farmacêuticas e e-commerces globais. O novo sistema corporativo precisa garantir:

Segurança e Consistência (SQL - PostgreSQL): Controle absoluto de saldo de estoque nos galpões e processamento de pagamentos sob severas garantias ACID.
Rastreamento Instantâneo (Cache - Redis): Monitorar a posição geográfica exata em tempo real de milhares de motoristas, atualizada a cada 3 segundos.
Auditoria Telemétrica (Documento - MongoDB): Registrar os logs de temperatura de cargas de vacinas e medicamentos especiais coletados por sensores IoT.
Despacho Inteligente (IA - pgvector): Combinar semanticamente solicitações textuais complexas de clientes (ex: "preciso de transporte para carga refrigerada que não pode sofrer vibrações") com as características descritivas dos veículos disponíveis na frota.

Como Arquiteto Supremo, você irá consolidar esta solução integrada.

🧠 A Arquitetura Poliglota do Ecossistema

Abaixo está o mapeamento dos fluxos de dados que você irá implementar:

flowchart TD
    App["Aplicação Cliente / Gateway"] -->|Transações Operacionais & IA| Postgres["PostgreSQL - Core Relacional + pgvector"]
    App -->|Localização em Tempo Real / TTL| Redis["Redis - Caching e Status Rápido"]
    App -->|Logs de Telemetria de Sensores IoT| Mongo["MongoDB - Trilha de Auditoria e Documentos"]

    style Postgres fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style Redis fill:#ffebee,stroke:#e53935,stroke-width:2px
    style Mongo fill:#e8f5e9,stroke:#4caf50,stroke-width:2px

🛠️ Passo 1: O Núcleo Transacional Seguro (PostgreSQL / SQL)

O núcleo financeiro da TecProExpress exige consistência total de estoque. Você deve garantir que a liberação de um frete reduza automaticamente o inventário disponível e registre a movimentação financeira.

Tabelas: Crie as tabelas produto, pedido e estoque (com chaves numéricas substitutas).
Gatilho de Integridade (Trigger): Crie uma trigger em PL/pgSQL que impeça a inserção de um pedido se a quantidade solicitada for maior que o estoque atual (RAISE EXCEPTION), ou reduza a quantidade em estoque automaticamente após a aprovação do pedido.
Transação Concorrente: Escreva um bloco de transação segura que processe a venda e atualize as tabelas de forma atômica.

🛠️ Passo 2: O Cache de Alta Velocidade (Redis)

Os motoristas da TecProExpress enviam coordenadas geográficas de segundo em segundo. Salvar isso no PostgreSQL travaria as tabelas operacionais. Usaremos o Redis para cache rápido com tempo de expiração automática (TTL).

Rastreamento: Use o CLI do Redis para registrar a localização de um motorista (id: 502) no formato de Hash (latitude, longitude, status: em_transito).
TTL Constraint: Defina que esses dados de localização expiram automaticamente em 30 segundos (EXPIRE) caso o sinal do motorista caia, garantindo que o painel de controle detecte a perda de sinal.

🛠️ Passo 3: Auditoria Telemétrica e Flexível (MongoDB)

Cargas frias coletam dados de sensores IoT de temperatura. Como os sensores mudam conforme a marca e o modelo (alguns gravam apenas temperatura, outros gravam pressão e vibração), o MongoDB é o repositório perfeito.

Crie documentos contendo a telemetria estruturada das caixas de vacinas.
Escreva uma query agregada que busque todas as telemetrias onde a temperatura ultrapassou o limite crítico de segurança (ex: superior a 8.0 graus Celsius) para enviar alertas à central.

🛠️ Passo 4: O Mecanismo de Inteligência Vetorial (pgvector)

O cliente solicita um serviço escrevendo um texto livre. Precisamos cruzar esse texto com a descrição dos veículos de carga usando busca semântica para sugerir a frota ideal.

Habilite o pgvector na base PostgreSQL.
Crie a tabela frota_ia contendo o modelo do caminhão, descrição dos acessórios e um vetor tridimensional de significados (VECTOR(3)).
Realize a busca semântica por similaridade de cosseno com o embedding de busca do cliente.

📤 Instruções de Entrega (Microsoft Teams)

Como entrega deste projeto integrador sênior final da Fase 2, organize seus arquivos em um repositório Git ou pacote compactado (.zip) com a seguinte estrutura profissional:

/relacional: Arquivo relacional_core.sql contendo a DDL estruturada, sementes (DML), a trigger de estoque PL/pgSQL e os scripts de transações ACID.
/caching: Arquivo driver_cache.redis listando todos os comandos executados no Redis CLI para controle de driver e monitoramento de TTL.
/telemetria: Arquivo sensor_logs.js contendo os scripts de inserção NoSQL no MongoDB e a consulta analítica de auditoria IoT.
/inteligencia: Arquivo despacho_ia.sql contendo a criação da frota vetorial no pgvector e a query de recomendação semântica de cosseno.
README.md: Um documento sênior explicando a justificativa arquitetural do projeto, detalhando por que a arquitetura poliglota foi implementada e quais problemas de performance ela resolveu na TecProExpress.

💡 Checkpoint de Lógica

[!IMPORTANT] O Desafio dos Sistemas Distribuídos: Ao usar múltiplos bancos de dados (Persistência Poliglota), manter as informações sincronizadas é um grande desafio. Se o pagamento for cancelado no PostgreSQL, como avisamos o MongoDB e o Redis? Em sistemas avançados de software, usamos o Saga Pattern ou Event-Driven Architecture (Arquitetura Baseada em Eventos) com brokers de mensageria (como Apache Kafka ou RabbitMQ) para garantir que todas as pontas do sistema reajam de forma assíncrona e consistente às mudanças do ecossistema. 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Arquiteto de Soluções Principal (Staff Engineer) 🏆

Pesquise e desenhe em formato texto ou no seu README uma explicação sucinta sobre o Teorema CAP (Consistência, Disponibilidade e Tolerância a Partições). Explique para a equipe executiva qual das garantias o PostgreSQL (SQL) prioriza em comparação com o MongoDB (NoSQL) quando ocorre uma falha na infraestrutura de servidores de rede.

🔑 Gabarito de Código/Fórmulas Completo

🐘 1. PostgreSQL Relacional & Trigger (pgAdmin)

-- DDL Estruturada
CREATE TABLE produto (
    id SERIAL PRIMARY KEY,
    nome VARCHAR(100),
    preco DECIMAL(10,2)
);

CREATE TABLE estoque (
    id_produto INT PRIMARY KEY REFERENCES produto(id),
    quantidade_disponivel INT CHECK (quantidade_disponivel >= 0)
);

CREATE TABLE pedido (
    id SERIAL PRIMARY KEY,
    id_produto INT REFERENCES produto(id),
    quantidade INT
);

-- Trigger de Validação de Estoque em PL/pgSQL
CREATE OR REPLACE FUNCTION valida_e_atualiza_estoque()
RETURNS TRIGGER AS $$
DECLARE
    qtd_atual INT;
BEGIN
    SELECT quantidade_disponivel INTO qtd_atual 
    FROM estoque WHERE id_produto = NEW.id_produto;

    IF qtd_atual IS NULL OR qtd_atual < NEW.quantidade THEN
        RAISE EXCEPTION 'Erro: Estoque insuficiente para o produto %!', NEW.id_produto;
    END IF;

    UPDATE estoque 
    SET quantidade_disponivel = quantidade_disponivel - NEW.quantidade
    WHERE id_produto = NEW.id_produto;

    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_valida_pedido
BEFORE INSERT ON pedido
FOR EACH ROW
EXECUTE FUNCTION valida_e_atualiza_estoque();

🔴 2. Redis Caching CLI Commands

-- 1. Cria o cache de geolocalização do motorista
HSET motorista:502 latitude -23.550520 longitude -46.633308 status em_transito

-- 2. Define o tempo de vida (TTL) para 30 segundos
EXPIRE motorista:502 30

-- 3. Consulta rápida do status
HGET motorista:502 status

🍃 3. MongoDB Telemetria de Sensores IoT

// Inserção de Logs de Temperatura da Vacina
db.telemetria_vacina.insertMany([
  {
    "carga_id": 9091,
    "sensor": "SENS-TEMP-01",
    "leitura": { "temperatura_celsius": 4.2, "umidade": 35 },
    "data_hora": ISODate("2026-05-19T16:00:00Z"),
    "status": "normal"
  },
  {
    "carga_id": 9091,
    "sensor": "SENS-TEMP-01",
    "leitura": { "temperatura_celsius": 9.5, "umidade": 38 },
    "data_hora": ISODate("2026-05-19T16:05:00Z"),
    "status": "critico"
  }
]);

// Consulta de Auditoria para Alertas Críticos (Temperatura > 8 graus)
db.telemetria_vacina.find({
  "leitura.temperatura_celsius": { $gt: 8.0 }
});

🧠 4. Busca Semântica pgvector (IA)

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE frota_ia (
    id SERIAL PRIMARY KEY,
    modelo VARCHAR(100),
    recursos TEXT,
    vetor_especialidade VECTOR(3)
);

INSERT INTO frota_ia (modelo, recursos, vetor_especialidade) VALUES
('Caminhão Frigorífico Volvo', 'Câmara fria regulada, amortecedores de impacto pneumáticos', '[0.98, 0.95, 0.05]'),
('Furgão Elétrico Cargo', 'Focado em entregas urbanas rápidas sem refrigeração', '[0.10, 0.20, 0.99]');

-- O cliente pesquisou por: "Preciso de transporte congelado e estável para medicamentos"
-- Embedding gerado pela IA da busca do usuário: [0.95, 0.92, 0.08]
SELECT modelo, recursos
FROM frota_ia
ORDER BY vetor_especialidade <=> '[0.95, 0.92, 0.08]'
LIMIT 1;

🔍 Explicação do Gabarito:

Trigger Relacional: Garante consistência a nível transacional no Postgres. Se o estoque cair abaixo de zero, a restrição de integridade ou o RAISE EXCEPTION desfazem qualquer inserção de pedido, protegendo o faturamento físico da empresa.
TTL do Redis: Permite liberar memória RAM automaticamente de localizações antigas sem necessidade de rotinas lentas de expiração via banco de dados relacional.
MongoDB Flexível: Permite aninhar dados de sensores distintos (temperatura, umidade, etc.) sem forçar uma coluna vazia ou nula para outros sensores mais simples.
Similaridade pgvector: Localizou o Caminhão Frigorífico Volvo como par ideal semanticamente devido ao ângulo quase idêntico entre o vetor de busca do cliente e o vetor de especialidade da frota.

Engenharia de Software e Aplicações

📋 PLANO DE ENSINO ATUALIZADO

Carga Horária: 80 aulas presenciais + 40 atividades autônomas
Curso: Tecnólogo em Gestão da Tecnologia da Informação - FATEC

🎯 OBJETIVO GERAL

Capacitar o aluno a aplicar princípios da Engenharia de Software no desenvolvimento de sistemas, utilizando metodologias, técnicas e ferramentas modernas para análise, projeto, implementação e validação de software.

🧪 METODOLOGIA

Aulas expositivas + práticas.
Aprendizado baseado em projetos (PBL).
Estudos de caso reais.
Uso de ferramentas do mercado (Git, Docker, Jira, Figma).

📊 AVALIAÇÃO

Tipo	Peso
Exercícios e atividades	20%
Trabalhos práticos	30%
Projeto final	40%
Participação	10%

🚀 DIFERENCIAL TECNOLÓGICO

Integração de stacks modernas para o projeto final:

Backend: Spring Boot (Java)
Frontend: Angular
Banco: PostgreSQL
DevOps: Docker & Git

🧭 MÓDULOS DO CURSO

Módulo	Descrição / Capítulos Relacionados
1	Introdução à Engenharia de Software • Cap 01: Introdução e Natureza do Software
2	Ciclo de Vida de Software • Cap 02: Modelos de Processo de Software • Cap 03: As Atividades do Processo
3	Metodologias Ágeis • Cap 04: Metodologias Ágeis
4	Engenharia de Requisitos • Cap 05: Fundamentos de Requisitos • Cap 06: Elicitação e Levantamento • Cap 07: Especificação de Requisitos (ERS) • Cap 08: Validação e Gestão
5	Fundamentos de Modelagem • Cap 09: Fundamentos da Modelagem
6	Diagrama de Casos de Uso • Cap 10: Diagrama de Casos de Uso (Conceitos) • Cap 11: Casos de Uso (Prática e Relações)
7	Diagrama de Classes (UML) • Cap 12: Diagrama de Classes (Conceitos) • Cap 13: Herança e Polimorfismo
8	Diagrama de Sequência • Cap 14: Diagrama de Sequência
9	Diagramas Dinâmicos • Cap 15: Diagramas Dinâmicos (Estados e Atividades)
10	Qualidade de Software (SQA) • Cap 16: Qualidade de Software (SQA)
11	Estratégias de Teste • Cap 17: Estratégias de Teste
12	Manutenção e Configuração (SCM) • Cap 18: Manutenção e Evolução • Cap 19: Gerência de Configuração (SCM)
13	🚀 Conclusão e Próximos Passos • Cap 20: Conclusão e Próximos Passos

📖 BIBLIOGRAFIA BÁSICA

PILONE, Dan; MILES, Russell. Use A Cabeça - Desenvolvimento de Software.
PRESSMAN, R. S. Engenharia de Software.
SOMERVILLE, I. Engenharia de Software.

📖 BIBLIOGRAFIA COMPLEMENTAR

GUEDES, G. UML 2 – Uma Abordagem Prática.
YOURDON, E. Análise Estruturada Moderna.

📚 CAPÍTULO 01: INTRODUÇÃO E NATUREZA DO SOFTWARE

Seja muito bem-vindo ao módulo estratégico de Engenharia de Software da TecProExpress. Aqui, você aprenderá as bases técnicas para transformar a "arte" de programar em uma disciplina de engenharia rigorosa, focada em desenvolvimento moderno com foco prático no ecossistema corporativo utilizando Java 17 e Spring Boot 3.5. 🛡️🧩

🎯 Objetivo do Módulo

Ao final desta jornada, você não será apenas um programador, mas um arquiteto capaz de planejar, modelar e garantir a qualidade de sistemas complexos que sustentam grandes corporações.

🏢 O Cenário Corporativo (TecProExpress)

Imagine que você acaba de ser contratado como Engenheiro de Software Pleno na TecProExpress. A empresa possui um sistema legado de 15 anos que está "morrendo" (lento e difícil de manter) e precisa ser migrado para uma arquitetura de Microsserviços na nuvem.

"Seu desafio não é apenas escrever código novo, mas entender o ciclo de vida desse software, extrair os requisitos do negócio e garantir que a nova versão seja sustentável pelos próximos 20 anos."

📊 Mapa de Conhecimento do Módulo

Explore os quatro grandes pilares que regem a engenharia moderna de sistemas na TecProExpress.

flowchart TD
    subgraph "CICLO DE VIDA DO SOFTWARE"
    direction TB
    F["🌳 FUNDAMENTOS"] --> R["📋 REQUISITOS"]
    R --> M["📐 MODELAGEM UML & SPRING"]
    M --> G["🛡️ GERENCIAMENTO & QUALIDADE"]
    end
    
    subgraph "PILARES TÉCNICOS"
    direction LR
    T1["⚡ AGILIDADE"] --- T2["📊 DIAGRAMAS"]
    T2 --- T3["🧪 TESTES (JUNIT 5)"]
    end

📗 Cronograma de Excelência

Este curso foi desenhado em uma sequência lógica, integrada à realidade do mercado de desenvolvimento corporativo.

Unidade	Temática Principal	Foco Prático (Stack Principal)
I. Fundamentos	Modelos de Processos e Ágil	Ciclo de Entrega Corporativo
II. Requisitos	Elicitação e Histórias de Usuário	Validações com Jakarta Bean Validation
III. Modelagem	Objetos e Casos de Uso (UML)	Injeção de dependências (Spring DI)
IV. Diagramas	Sequência e Atividades	Fluxo REST e Mapeamento de Classes
V. Qualidade	SCM e Testes (TDD/BDD)	Automação com JUnit 5 e Mockito

🧠 Fundamentos: O que é Software?

Software de computador é o produto que profissionais desenvolvem e ao qual dão suporte no longo prazo. Diferente de produtos físicos, o software possui características únicas:

Característica	Impacto na Engenharia
Engenharia, não Manufatura	O custo está no design e na arquitetura, não na "produção" de cópias.
Não se Desgasta	O software não quebra fisicamente; ele degrada por falta de manutenção ou bugs lógicos.
Complexidade Crescente	Toda regra de negócio nova aumenta a chance de "Código Espaguete" se não houver padrão.

📊 Evolução Histórica (Do Cascata ao Cloud-Native)

timeline
    title Marcos da Engenharia de Software
    1968 : "Conferência da OTAN (Nascimento do Termo)"
    1970 : "Crise do Software (Falta de métodos)"
    1990 : "Orientação a Objetos : Ascensão do Java"
    2000 : "Manifesto Ágil : Scrum e Kanban"
    2010 : "Cloud & Microservices : Spring Boot e DevOps"

🔍 Detalhamento Técnico: Por que a Engenharia é Vital?

Sommerville (2011) destaca que a sociedade moderna depende de softwares para infraestruturas vitais. A falha de uma API de pagamentos por falta de tratamento de exceções (ex: @ExceptionHandler) pode causar colapso financeiro.

[!CAUTION] Dica de Performance Corporativa: "Software não se fabrica, se projeta." O sucesso de um projeto corporativo reside na clareza da arquitetura original. Sem isso, refatorar um monólito engessado é um pesadelo técnico e financeiro. 🧠🛡️

🏺 O Desafio dos Sistemas Legados (Legacy)

Na TecProExpress, você encontrará sistemas antigos (Java EE, Cobol) que sustentam o faturamento. Eles são chamados de "sistemas de herança".

🛠️ Arquiteturas Rígidas: Difíceis de integrar com APIs REST.
🍝 Código Espaguete: Funções acopladas que violam o SOLID.
❌ Falta de Testes: Ausência de cobertura de JUnit.

🔄 A Natureza Mutante

A engenharia moderna na TecProExpress é tracionada por:

graph TD
    A["Categorias em Evolução"] --> B["WebApps / APIs REST"]
    A --> C["Mobile Apps"]
    A --> D["Cloud Computing"]
    A --> E["Linhas de Produto B2B"]
    
    style B fill:#e3f2fd,stroke:#1e88e5 
    style C fill:#e3f2fd,stroke:#1e88e5 
    style D fill:#e3f2fd,stroke:#1e88e5 
    style E fill:#e3f2fd,stroke:#1e88e5

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Quando você estuda Spring Boot, você está se preparando para atuar nos eixos de APIs Cloud que alimentarão tanto WebApps (React/Angular) quanto Mobile (Flutter/Kotlin). Você está pronto para ser o motor dessa engrenagem? 🚀

🔄 CAPÍTULO 02: MODELOS DE PROCESSO DE SOFTWARE

Um modelo de processo de software é uma representação abstrata e simplificada de um processo real. Na engenharia moderna, esses modelos ditam como o código sai da IDE do desenvolvedor e chega com segurança à nuvem. 🛡️🧩

🎯 Objetivo do Capítulo

Compreender as atividades, artefatos e papéis envolvidos nos principais modelos de ciclo de vida, capacitando o aluno a escolher a melhor estratégia para cada tipo de projeto corporativo.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, a equipe de arquitetura está dividida. Para o novo sistema de Controle de Satélites de Logística, o gerente sênior exige o rigor do modelo em Cascata. Já para o App de Chat do Motorista, a equipe de inovação quer usar Desenvolvimento Incremental (Ágil).

"Seu papel como Engenheiro de Processos é definir qual modelo se encaixa melhor em cada projeto, equilibrando a necessidade de previsibilidade com a urgência de feedback do usuário."

🧠 Fundamentos: Modelos de Processos

No ecossistema corporativo atual, os modelos de processo funcionam como o "Manual de Instruções" da fábrica de software.

Comparação dos Modelos Fundamentais

Modelo Clássico	Descrição e Perspectiva Tecnológica
Cascata (Waterfall)	Abordagem sequencial rígida: Requisitos -> Projeto -> Implementação -> Teste.
Incremental (Ágil)	O sistema é construído por versões parciais (incrementos). A arquitetura cresce aos poucos.
Orientada a Reuso	Foca na integração de dependências (ex: pacotes do Maven Central) em vez de programar tudo do zero.

graph LR
    A["Caos Ad-hoc"] -->|Engenharia| B["Modelos"]
    B --> C["Processo Estruturado Agile"]
    B --> D["Pipeline CI/CD Predictível"]

🌊 O Modelo em Cascata (Waterfall)

O paradigma mais antigo da Engenharia de Software. Propõe uma abordagem sistemática onde cada fase deve ser concluída antes do início da próxima.

graph TD
    A["Análise e Requisitos"] --> B["Projeto de Domínio"]
    B --> C["Implementação do Código"]
    C --> D["Integração e Testes Funcionais"]
    D --> E["Deploy e Manutenção"]

    style A fill:#e3f2fd,stroke:#1e88e5 
    style B fill:#e3f2fd,stroke:#1e88e5 
    style C fill:#e3f2fd,stroke:#1e88e5 
    style D fill:#e3f2fd,stroke:#1e88e5 
    style E fill:#e3f2fd,stroke:#1e88e5

🔍 Os Desafios Críticos (Análise TecProExpress)

Dificuldade de Iteração: Mudanças tardias são extremamente custosas.
Incerteza Inicial: Exige que o cliente defina todos os requisitos no dia 1.
Demora no Resultado: O software funcional só aparece no final do ciclo de meses ou anos.

[!CAUTION] Dica de Especialista: O modelo em cascata ainda é usado? Sim, mas apenas quando os requisitos são imutáveis e regulamentados (ex: software de controle militar ou médico). Para construir APIs B2B/B2C, fuja do Cascata e abrace o ágil. 🧠🛡️

🚀 Desenvolvimento Incremental

Baseia-se na ideia de construir um MVP (Minimum Viable Product), expô-lo ao feedback e evoluí-lo em Sprints.

graph LR
    subgraph "Ciclo Incremental (Sprints)"
        direction TB
        E["Especificação da API"] <--> D["Desenvolvimento (Java)"]
        D <--> V["Validação (JUnit / CI)"]
    end

    Iteration --> V1["Release v1.0"]
    V1 --> V2["Release v1.1"]
    V2 --> V3["Release v2.0 Final"]

🔍 Vantagens Práticas

Redução de Custos: Menos documentação pesada inicial.
Feedback Antecipado: O cliente vê o sistema funcionando em semanas, não anos.
Resiliência: Se um incremento der errado, você refatora apenas aquela parte sem perder o projeto todo.

🧩 Engenharia Orientada a Reuso

No ecossistema Java/Spring, você não cria um sistema de segurança do zero. Você importa o Spring Security. Isso é Engenharia de Reuso.

graph LR
    subgraph "Etapas Iniciais"
        direction LR
        E1["Especificação"] --> E2["Busca de Libs (Maven)"] --> E3["Adaptação"]
    end

    subgraph "Implementação Prática"
        direction LR
        E4["Importação"] --> E5["Injeção de Bean"] --> E6["Validação"]
    end

    E3 --> E4

[!TIP] Dica de Performance Corporativa: Antes de criar sua própria solução "inovadora" para manipular datas ou gerar planilhas, verifique bibliotecas maduras como Apache Commons ou Google Guava. Um bom Sênior sabe conectar blocos prontos de forma segura. 🚀

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Por que o modelo incremental é o favorito das Startups e o modelo em Cascata é o favorito de órgãos governamentais de infraestrutura crítica? (Resposta: Startups vivem da incerteza e feedback rápido; Governos precisam de conformidade rígida e orçamentos fechados pré-determinados). 🧠🛡️

⚙️ CAPÍTULO 03: AS ATIVIDADES DO PROCESSO

Para que um software seja produzido e mantido em escala corporativa, são necessárias diversas etapas coordenadas chamadas de Processo de Software. Independente do modelo escolhido (Ágil ou Tradicional), as engrenagens fundamentais permanecem as mesmas. 🛡️🧩

🎯 Objetivo do Capítulo

Dominar as quatro atividades universais da engenharia de software, compreendendo como cada uma se traduz em tarefas técnicas e ferramentas no dia a dia de um desenvolvedor moderno.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, um novo projeto de Rastreamento de Carga em Tempo Real foi aprovado. Antes de começar a codificar, a diretoria exige saber como o time vai garantir que o sistema não quebre após cada atualização.

"Seu papel é estruturar o ciclo de vida deste projeto, garantindo que as etapas de Especificação, Implementação, Validação e Evolução estejam conectadas através de uma esteira automatizada de CI/CD."

🧠 As Quatro Atividades Fundamentais

Segundo Sommerville (2011), todo processo de software de sucesso roda estas 4 engrenagens essenciais:

Atividade	Descrição Corporativa e Tecnológica
Especificação	O cliente define o que o sistema faz. Criamos a lista de Requisitos Funcionais e Não-Funcionais.
Projeto e Implementação	O software ganha vida. Planejamento de Entities, Interfaces REST e codificação pura em Java.
Validação	Garantia de que o sistema funciona e não tem bugs. Uso de JUnit 5, Mockito e Testes de Integração.
Evolução	Adição de novas funcionalidades e correções, mantendo o sistema vivo e atualizado na Nuvem.

📊 Visualizando a Interação

flowchart LR
    A["📋 Especificação"] --> B["📐 Projeto & Implementação"]
    B --> C["🧪 Validação"]
    C --> D["🚀 Evolução"]
    D --> A

🔍 Detalhamento das Atividades

1. Especificação (Requisitos)

É o "Contrato" do que será construído. Na TecProExpress, uma falha aqui pode custar milhões. Se o requisito diz "A API deve suportar 10.000 requests/s", o arquiteto precisa planejar a infraestrutura para isso.

2. Projeto e Implementação

Aqui definimos as camadas do sistema (Controller, Service, Repository). O foco é transformar a lógica de negócio em código limpo (Clean Code) e escalável.

3. Validação (Testes)

Não basta o código rodar na máquina do desenvolvedor. Ele precisa passar por testes automatizados que provam que o sistema é resiliente.

[!TIP] Dica Sênior: Nunca envie um Pull Request sem testes unitários. Na TecProExpress, a Validação automatizada é o que impede que um erro de estagiário derrube o faturamento da empresa. 🛡️

4. Evolução (Manutenção)

O software nunca está "pronto". Ele está sempre em evolução para atender novas leis, novas tecnologias ou novas necessidades do mercado.

🚀 Rumo à Agilidade

Embora as atividades sejam as mesmas, a forma como as executamos muda. No modelo Ágil, essas atividades acontecem em ciclos muito curtos (Sprints), permitindo correções de rota rápidas.

graph LR
    A["Caos Ad-hoc"] -->|Engenharia| B["Modelos Estruturados"]
    B --> C["Esteira de CI/CD Automatizada"]
    C --> D["Entrega Contínua de Valor"]

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se você pular a etapa de Validação para entregar o código mais rápido para o cliente, o que acontecerá na etapa de Evolução daqui a 6 meses? (Resposta: A Evolução será lenta e perigosa, pois cada mudança nova poderá quebrar partes do sistema que você não testou antes). 🧠🛡️

⚡ CAPÍTULO 04: METODOLOGIAS ÁGEIS

As metodologias ágeis surgiram como uma alternativa às abordagens tradicionais, focando em flexibilidade, redução de burocracia e adaptação contínua. Em um mercado onde um microsserviço precisa ir ao ar em semanas, a agilidade é a alma do negócio. 🛡️🧩

🎯 Objetivo do Capítulo

Compreender os valores e as práticas dos principais frameworks ágeis (Scrum e XP), capacitando o desenvolvedor a atuar em equipes de alta performance focadas em entrega contínua de valor.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, a diretoria quer lançar o novo portal de Autoatendimento do Cliente em apenas 2 meses. O modelo em Cascata foi descartado imediatamente.

"Sua equipe foi organizada em um Squad Ágil. Vocês usarão Scrum para gerenciar as tarefas e práticas de XP (como TDD) para garantir que o código Java seja impecável. Prepare-se para sua primeira Sprint Planning!"

🚀 Extreme Programming (XP)

A XP é voltada para a excelência técnica. Se o Scrum foca na gestão, a XP foca no como o desenvolvedor trabalha.

Os Valores do XP

O sucesso da XP baseia-se na sinergia entre seus valores fundamentais:

graph LR
    V1["Comunicação"] --> S(("Valores do XP"))
    V2["Simplicidade"] --> S
    V3["Feedback"] --> S
    V4["Coragem"] --> S
    V5["Respeito"] --> S
    
    style S fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

[!TIP] Prática Sênior (XP): O "documento" de um sistema XP são os seus testes automatizados (JUnit 5). Se os testes passam e descrevem perfeitamente o comportamento, a documentação está viva no código, não mofando em um PDF. 🧪

🔄 O Framework Scrum

O Scrum organiza o trabalho em ciclos curtos chamados Sprints (geralmente de 2 semanas). É focado em transparência, inspeção e adaptação.

Estrutura do Scrum (Papéis e Artefatos)

flowchart LR
    subgraph "Papéis"
        direction TB
        P1["Product Owner (Negócio)"]
        P2["Scrum Master (Processo)"]
        P3["Time de Dev (Técnico)"]
    end

    subgraph "Artefatos"
        direction TB
        A1["Product Backlog (Fila)"]
        A2["Sprint Backlog (Meta)"]
        A3["Incremento (Produto)"]
    end

🔍 Comparação: Tradicional vs Ágil

Aspecto Corporativo	Metodologia Tradicional (Cascata)	Metodologia Ágil (Scrum)
Projeto Arquitetural	Estável e inflexível (Engessado).	Adaptável a mudanças (Evolutivo).
Cliente	Participa apenas no início e no fim.	Parte do time, dá feedback constante.
Planejamento	Longo prazo e detalhado inicialmente.	Curto prazo e iterativo semanalmente.

📋 Exemplo de Product Backlog (TecProExpress)

Abaixo, como as entregas são priorizadas em uma ferramenta como o Jira:

ID	Prioridade	Item / História de Usuário	Status
101	🔥 Alta	Configurar Autenticação Oauth2 (Segurança)	Concluído
102	⚡ Média	Criar Endpoints REST de Cadastro	Em Aberto
103	🧊 Baixa	Gerar Relatório em PDF (Opcional)	Pendente

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Muitos desenvolvedores juniores acham que as reuniões diárias (Dailies) são perda de tempo. No entanto, um desenvolvedor sênior usa a Daily para expor bloqueios técnicos pesados e exigir que o Scrum Master remova os impedimentos que travam a entrega. Você está usando o Scrum para se proteger ou apenas para reportar status? 🧠🛡️

📋 CAPÍTULO 05: FUNDAMENTOS DE REQUISITOS

A engenharia de requisitos é a fundação de qualquer projeto de software. Sistemas lentos e APIs que quebram diariamente raramente são culpa de "programadores ruins", mas sim de requisitos negligenciados. 🛡️🧩

🎯 Objetivo do Capítulo

Ao final desta unidade, você será capaz de diferenciar O Que o sistema faz (RF) de Como ele se comporta (RNF), traduzindo necessidades de negócio em especificações técnicas precisas.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, o departamento jurídico emitiu um alerta: o novo sistema de rastreamento deve estar 100% em conformidade com a LGPD (Lei Geral de Proteção de Dados). Ao mesmo tempo, o setor de vendas exige que o mapa de entregas carregue em menos de 1 segundo.

"Seu desafio como Analista de Requisitos é documentar essas necessidades. O que é uma funcionalidade (botão) e o que é uma restrição de performance ou lei? Se você errar aqui, o sistema pode ser multado ou rejeitado pelos usuários."

🧠 Perspectivas de Requisitos

Segundo Sommerville (2011), o termo "requisito" varia conforme quem o lê:

Perspectiva de Usuário (PO): Declarações de alto nível. Ex: "O motorista deve visualizar suas rotas".
Perspectiva de Sistema (Dev): Detalhamento técnico. Ex: "O endpoint GET /routes deve retornar um JSON com coordenadas geográficas do PostgreSQL".

📊 Classificação dos Requisitos

graph TD
    R(["Requisitos de API / Software"])
    R --> RF["Funcionais - RF"]
    R --> RNF["Não Funcionais - RNF"]
    
    RF --- |"Rotas / Endpoints"| E1["Serviços & Funções Lógicas"]
    RNF --- |"Performance / Segurança"| E2["Qualidade & Restrições Físicas"]

    style R fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px

1. Requisitos Funcionais (RF)

São as tarefas tangíveis. Se o sistema não faz o que o RF pede, ele está incompleto.

Exemplos: Cadastrar motorista, Gerar boleto de frete, Validar CPF.

2. Requisitos Não-Funcionais (RNF)

São as restrições e qualidades. Eles moldam a Arquitetura.

Performance: A API deve responder em < 100ms.
Segurança: Todas as senhas devem ser criptografadas (BCrypt).
Disponibilidade: O sistema deve operar 24/7 (SLA de 99.9%).

Categoria RNF	Exemplo na TecProExpress	Impacto Técnico
Segurança	Proteção via JWT.	Uso de Spring Security.
Performance	Cache de rotas frequentes.	Uso de Redis.
Legislativo	Conformidade com LGPD.	Anonimização de dados sensíveis.

🔍 Detalhamento: Ambiguidade é Retrabalho

Um requisito ambíguo como "Calcular o frete de forma rápida" é perigoso. "Rápida" para quem? Para um computador é 1ms, para um humano é 1 segundo.

[!CAUTION] Dica de Especialista: Sempre defina métricas exatas para requisitos não-funcionais. Em vez de "Rápido", use "A resposta deve ocorrer em no máximo 200ms". Isso protege a equipe durante a entrega final. 🧠🛡️

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se um cliente pede que o sistema "seja seguro", isso é um RF ou um RNF? (Resposta: É um RNF abstrato que gerará vários RFs concretos, como 'Tela de Login', 'Recuperação de Senha' e 'Logs de Auditoria'). Nunca ignore o "Como" em favor do "O Quê". 🧠🛡️

🔍 CAPÍTULO 06: ELICITAÇÃO E LEVANTAMENTO

O processo de engenharia de requisitos não é algo que ocorre apenas uma vez. Na agilidade, ele é contínuo e ocorre a cada ciclo de desenvolvimento. Descobrir o que o usuário realmente precisa (e não apenas o que ele diz que quer) é o grande segredo. 🛡️🧩

🎯 Objetivo do Capítulo

Dominar as quatro etapas sistêmicas do refinamento de requisitos: Estudo de Viabilidade, Elicitação, Especificação e Validação Comercial.

🏢 O Cenário Corporativo (TecProExpress)

O Diretor de Logística da TecProExpress quer que o sistema de rastreamento use Inteligência Artificial para prever o trânsito. O custo dessa tecnologia é alto e a equipe de desenvolvedores nunca trabalhou com IA.

"Seu papel é conduzir o Discovery. Vale a pena programar isso agora? Temos tecnologia para isso? Ou seria melhor focar em uma integração simples com o Google Maps primeiro? Você deve conduzir as entrevistas e o estudo de viabilidade para dar o veredito técnico."

🧠 O Ciclo de Refinamento de Requisitos

Segundo Sommerville (2011), o processo envolve quatro atividades cíclicas:

Etapa	Significado Prático
Estudo de Viabilidade	"Vale a pena?". Avaliamos custo, tecnologia e retorno de negócio.
Elicitação (Levantamento)	Reuniões e entrevistas com stakeholders para extrair a lógica.
Especificação	Documentar detalhadamente no Jira ou ERS o que será construído.
Validação Comercial	"Era isso mesmo?". Revisão final com o cliente antes de codar.

📊 Fluxo de Discovery e Delivery

graph TD
    A["Discovery da Feature"] -->|Aprovado| B["Levantamento Ágil"]
    B -->|User Stories| C["Especificação Técnica"]
    C -->|Revisão de Arquitetura| D["Validação / Grooming"]
    D -->|"Pronta para Devs"| E["CODIFICAÇÃO"]
    
    style E fill:#d4edda,stroke:#28a745,stroke-width:2px

🔍 As Três Peneiras da Viabilidade

Antes de escrever a primeira linha de código Java, o Arquiteto deve responder:

Retorno de Negócio (ROI): Isso trará lucro ou economizará dinheiro?
Viabilidade Tecnológica: Temos servidores, banco de dados e talentos para isso?
Integração (Lock-In): Dependemos de APIs de terceiros que podem falhar?

👥 Stakeholders: Os Interessados

Todo projeto afeta diferentes grupos na TecProExpress:

Usuários Finais: Querem simplicidade (foco em UX).
Gerentes: Querem rapidez e lucro (foco em Datas).
Engenheiros: Querem segurança e código limpo (foco em Qualidade).
Reguladores: Exigem conformidade (foco em LGPD/Leis).

🗣️ Técnicas de Elicitação (Entrevistas)

Escrever código só compensa se a regra estiver clara. O Engenheiro deve atuar como um "detetive" durante as entrevistas:

[!TIP] Dica do Tech Lead: Nunca entre em uma reunião sem conhecer o negócio do cliente. Se o sistema é contábil, estude o básico de fluxo de caixa antes. Se você não entende o domínio, não conseguirá traduzi-lo em código. 🚀

Desafios do Levantamento

Omissão: O usuário esquece de mencionar regras que ele considera "óbvias".
Conflitos: O setor de Vendas quer algo que o setor de Segurança proíbe.
Tradução: O cliente fala em "Leads", o dev ouve "Table Leads no PostgreSQL".

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se um cliente pede um botão que emita um Excel gigante com todos os dados do banco, pergunte sempre: "Por que você precisa disso?". Muitas vezes, ele só quer validar uma única informação que poderia ser resolvida com uma simples tela de consulta, economizando semanas de desenvolvimento inútil. 🧠🛡️

📜 CAPÍTULO 07: ESPECIFICAÇÃO DE REQUISITOS (ERS)

A Especificação de Requisitos de Software (ERS) é o documento oficial que descreve o que o sistema deve fazer. Na engenharia moderna, ela serve como o "Contrato Técnico" que unifica a visão do desenvolvedor em Home Office com a estratégia do CEO na Matriz. 🛡️🧩

🎯 Objetivo do Capítulo

Aprender a estruturar um documento de especificação profissional seguindo padrões internacionais (IEEE), garantindo que todos os endpoints, regras e metadados estejam documentados antes da codificação.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, um cliente externo contratou a empresa para desenvolver um módulo de Gestão de Frotas. Durante a reunião, o cliente disse: "Ah, e eu quero que o sistema seja integrado com o meu ERP antigo".

"Se você não colocar essa integração no documento de ERS, o desenvolvedor não saberá que precisa criar esse conector, e o cliente poderá cobrar a entrega sem pagar o custo extra da integração. O ERS é a sua proteção jurídica e técnica."

🧠 Estrutura Padrão da ERS

Abaixo, a organização funcional que você encontrará em ferramentas de documentação como o Confluence da sua Squad:

Bloco de Documentação	Descrição e Valia Prática
Glossário e Domínio	Dicionário de jargões (Ex: O que significa 'TED' ou 'PIX' neste contexto?).
Objetivos e Negócio	A necessidade global. O que a plataforma resolve comercialmente?
Modelagem de Arquitetura	Desenhos de infraestrutura, bancos de dados e fluxo de eventos.
Especificação Técnica	Detalhamento rota por rota REST, JSONs de entrada/saída e User Stories.

📊 O Papel da Documentação

graph TD
    ERS(["Repositório Confluence / ERS"])
    ERS --> DEV["Devs: Transformam ERS em CÓDIGO"]
    ERS --> CLI["Business: Transforma ERS em VALOR"]
    ERS --> TEST["QA: Transforma ERS em TESTES"]
    
    style ERS fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px

🔍 Estudo de Caso: Locadora Tech (ERS.01)

Imagine uma plataforma de empréstimos digitais (Streaming). O Arquiteto da TecProExpress mapeou as seguintes entidades:

👤 Usuário Titular: Nome, CPF (único), Hash de Senha.
👥 Dependentes: Atrelados ao titular via Foreign Key. Recebem Tokens JWT limitados.
🎬 Catálogo de Filmes: Endpoint POST /api/movies para persistir metadados e links de Blob Storage.

[!TIP] Dica Arquitetural: Nunca confie na memória. Software complexo leva meses para ser construído. Se uma regra de negócio mudar na Sprint 15 e não for atualizada no ERS, o time de QA testará a funcionalidade errada e o erro só aparecerá em produção. 🧠🛡️

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: O ERS serve para três momentos críticos: No Início (Barreira Contratual), No Meio (Guia de Implementação) e No Fim (Critério de Aceite). Se você pular essa documentação, como provará para o cliente que o sistema está "Pronto"? (Resposta: Sem o ERS, o sistema nunca estará pronto, pois o cliente sempre pedirá 'mais uma coisinha'). 🧠🛡️

⚖️ CAPÍTULO 08: VALIDAÇÃO E GESTÃO

A validação garante que os requisitos refletem fielmente a lógica do negócio antes que a primeira linha de código Java seja escrita. Validar o papel é muito mais barato do que refatorar o sistema pronto. 🛡️🧩

🎯 Objetivo do Capítulo

Dominar as técnicas de revisão de requisitos, aplicando os 5 pilares de qualidade (Validade, Consistência, Completeza, Realismo e Verificabilidade) para blindar o projeto contra falhas estruturais.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, o time de desenvolvimento reportou um conflito: o Requisito RF.02 diz que o CPF do motorista pode ser alterado, mas o Requisito RF.45 (Segurança) diz que campos chave de identidade nunca podem mudar após o cadastro.

"Seu papel como Analista de Requisitos Sênior é mediar esse conflito. Se o programador escolher qualquer um dos dois sem validação, o banco de dados pode ficar inconsistente. Você deve validar a 'Bíblia' do projeto antes da implementação."

🧠 Os 5 Pilares da Revisão (Sommerville)

Pilar de Qualidade	O que o Engenheiro deve checar?
Validade	O sistema realmente resolve a dor real do cliente?
Consistência	Existem requisitos conflitantes? (A tela permite deletar, mas a API proíbe?).
Completeza	Todas as propriedades do JSON e exceções de banco foram mapeadas?
Realismo	É possível implementar isso no prazo e orçamento atual (Budget)?
Verificabilidade	O requisito é testável? "Ser rápido" não é. "Responder em 200ms" é.

🔍 A Economia do Erro (Regra 1:10:100)

O custo de corrigir um erro cresce exponencialmente conforme o tempo passa:

R$ 1,00: Corrigir no papel (Documento/Requisito).
R$ 10,00: Corrigir durante o desenvolvimento (Refatoração de Código).
R$ 100,00: Corrigir em Produção (Nuvem/Cliente Final).

[!CAUTION] Dica Sênior: Nunca economize tempo no planejamento. Se você descobrir um erro de lógica na nuvem, ele pode custar o fechamento da empresa ou multas contratuais pesadas. Validar é investir em segurança. 🛡️

📊 Ciclo de Vida da Gestão de Requisitos

graph TD
    A["Especificação Backend"] --> B["Endpoints Funcionais"]
    A --> C["Restrições Não-Funcionais"]
    
    A --> D["Refinamento (Grooming)"]
    D --> E["Validação Técnica"]
    E --> F["Pronto para Codar (DoR)"]
    
    style F fill:#d4edda,stroke:#28a745,stroke-width:2px

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se você percebe que um requisito pede "Reconhecimento Facial" em um projeto que só tem 2 semanas de prazo restante, o que a regra do Realismo sugere? (Resposta: Recomendar o "Pivotamento" para uma solução mais simples, como Senha ou Biometria Digital, para garantir a entrega dentro do orçamento). 🧠🛡️

📐 CAPÍTULO 09: FUNDAMENTOS DA MODELAGEM

Um modelo é uma representação simplificada de um sistema. Da mesma forma que você não constrói um Boeing 747 sem uma planta aerodinâmica, você não codifica um ERP Bancário abrindo direto a IDE sem planejar a arquitetura. 🛡️🧩

🎯 Objetivo do Capítulo

Compreender a importância vital da modelagem visual (UML) e conhecer as ferramentas modernas de mercado (Mermaid, Draw.io, Enterprise Architect) que transformam ideias em plantas estruturais.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, o projeto de Integração Logística falhou na primeira tentativa. Os desenvolvedores saíram codando sem planejar como o Banco de Dados conversaria com a API. Resultado: 3 meses de trabalho jogados fora porque a lógia estava "engessada".

"Seu desafio é implementar a cultura de Modeling First. Antes de abrir o VS Code ou o IntelliJ, a equipe deve validar a planta baixa do sistema no Mermaid ou Draw.io. Isso reduzirá o retrabalho em 80%."

🧠 Por que Modelar? (A Realidade do Mercado)

Estudos de engenharia mostram o que acontece quando pulamos o planejamento:

Sintoma (Falta de Arquitetura)	Consequência Real
Dívida Técnica	Apenas 10% dos projetos sem documentação são concluídos no prazo.
Aborto do Projeto	25% dos projetos são cancelados porque o código virou um "espaguete" intragável.
Estouro de Orçamento	Chamadas de API não planejadas geram custos astronômicos na AWS/Azure.

[!CAUTION] O Paradoxo Ágil: Há um falso sentimento de que metodologias ágeis (Scrum/Kanban) aboliram a arquitetura. Mentira. Elas aboliram a burocracia inútil, não a necessidade de uma planta robusta. Antes de escrever cérebro em código, valide a regra no papel! 🧠🛡️

🛠️ Ferramentas do Arquiteto Moderno

Ferramenta	Paradigma e Uso
PlantUML / Mermaid	Docs as Code. Você escreve o diagrama em texto e ele gera a imagem. Perfeito para Versionamento (Git).
Draw.io / Miro	Colaboração Rápida. Arrastar blocos para brainstormings e fluxos rápidos.
Enterprise Architect	Engenharia Reversa. Lê seu código Java e desenha o banco e as classes sozinho.

📊 O Ciclo da Modelagem Profissional

graph LR
    A["Requisito (Texto)"] --> B["Modelo UML (Planta)"]
    B --> C["Codificação (Java)"]
    C --> D["Validação (Teste)"]
    
    style B fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Por que gastar 3 horas desenhando um diagrama de sequência é mais barato do que gastar 3 dias refatorando uma API que não funciona? (Resposta: Porque no diagrama você descobre o erro de lógica movendo uma seta; no código, você descobre o erro recebendo um erro 500 em produção). 🧠🛡️

🎭 CAPÍTULO 10: DIAGRAMA DE CASOS DE USO (CONCEITOS)

O Diagrama de Casos de Uso é a "foto panorâmica" do sistema sob a perspectiva do usuário final. Ele é o ponto de partida essencial para definir o escopo funcional e os limites do software. 🛡️🧩

🎯 Objetivo do Capítulo

Dominar os três elementos estruturantes da UML: Atores, Casos de Uso e Fronteira do Sistema, aplicando nomenclaturas profissionais alinhadas ao padrão RESTful de mercado.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, os diretores querem ver uma lista de funcionalidades do novo Módulo de Compras. Eles não querem saber de Java ou SQL, eles querem saber o que o Comprador, o Gerente e o Fornecedor poderão fazer na plataforma.

"Seu desafio é desenhar esse 'Cardápio de Funcionalidades'. Você deve estabelecer o que está dentro do nosso desenvolvimento (Fronteira) e quem são as entidades externas (Atores) que vão pressionar nossos botões."

🧠 Os 3 Elementos Estruturantes

Elemento Gráfico	Aplicação no Software
Atores (Boneco)	Papéis externos (Usuários, Sensores IoT ou APIs de Terceiros).
Casos de Uso (Elipse)	A funcionalidade real (Ex: "Efetuar Login", "Gerar Fatura").
Fronteira (Retângulo)	O limite do seu projeto. O que está dentro será desenvolvido por você.

📊 Visualizando a Lógica de Fronteira

graph LR
    A["Usuário Padrão"] --- UC(["Efetuar Login Seguro"])
    subgraph "Fronteira da sua API (TecProExpress)"
        UC
    end
    
    style UC fill:#e3f2fd,stroke:#1e88e5

👥 Atores e Papéis de API

Um Ator representa quem ou o quê está chamando o seu sistema.

Humano: Perfis como Admin, Motorista, Cliente_Premium. (Dica: Nunca use nomes próprios ou CPFs).
Hardware: Sensores de temperatura, leitores biométricos.
Sistemas Externos: API do Governo, Sistema de Pagamentos (Stripe/PayPal).

[!CAUTION] O Erro Comum: Nunca liste o seu Banco de Dados como um Ator. O banco faz parte interna do seu sistema (está dentro da fronteira). O Ator é sempre algo que está FORA, enviando ou recebendo dados da sua aplicação. 🧠🛡️

🏷️ Nomenclatura RESTful Profissional

Para que seus diagramas falem a língua dos programadores modernos, os Casos de Uso devem usar Verbos no Infinitivo acoplados ao recurso:

Verbo	Mapeamento Técnico	Exemplo
Cadastrar / Criar	Futura Rota `POST`.	Cadastrar Veículo
Consultar / Listar	Futura Rota `GET`.	Consultar Rastreio
Efetuar / Executar	Processos Complexos.	Efetuar Pagamento
Emitir / Gerar	Geração de Arquivos.	Gerar PDF de Relatório

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: O Diagrama de Casos de Uso mostra O QUE o sistema faz, mas não mostra COMO ele faz. O passo a passo (a lógica do código) será detalhado em outro diagrama. Você sabe qual é? (Resposta: Diagrama de Sequência). 🧠🛡️

🎭 CAPÍTULO 11: CASOS DE USO (PRÁTICA E RELAÇÕES)

Dominar os conceitos básicos é apenas o começo. Na engenharia profissional, precisamos modelar como as funcionalidades dependem umas das outras através de relacionamentos formais da UML. 🛡️🧩

🎯 Objetivo do Capítulo

Aplicar os relacionamentos de Inclusão (<<include>>) e Extensão (<<extend>>) em cenários reais, garantindo que o diagrama reflita regras de negócio obrigatórias e opcionais.

🏢 O Cenário Corporativo (TecProExpress Health)

A TecProExpress iniciou um projeto para uma rede de laboratórios. O sistema deve permitir que o Bioquímico valide exames, mas a lei exige que todo exame validado dispare automaticamente uma notificação para o Órgão Governamental.

Ao mesmo tempo, o paciente pode (ou não) solicitar o envio do laudo por e-mail após a visualização.

"Seu desafio é modelar essas dependências. O que é um passo obrigatório (Inclusão) e o que é uma ação opcional (Extensão)? Esse diagrama guiará a segurança e o fluxo de dados da aplicação."

🧠 Relacionamentos entre Casos de Uso

1. Inclusão (`<<include>>`)

Ocorre quando um Caso de Uso sempre precisa de outro para ser concluído. É uma dependência obrigatória.

Exemplo: Para Efetuar Pagamento, o sistema deve obrigatoriamente Validar Saldo.

2. Extensão (`<<extend>>`)

Ocorre quando um Caso de Uso pode disparar outro em situações específicas. É opcional.

Exemplo: Ao Realizar Pedido, o sistema pode (se o usuário quiser) Aplicar Cupom de Desconto.

📊 Visualização de Fluxo Laboratorial

graph LR
    subgraph "Fronteira TecPro Health"
        UC1(["Visualizar Exame"])
        UC4(["Validar Laudo"])
        UC5(["Gerar PDF do Prontuário"])
        UC7(["Disparar Webhook Governamental"])
        UC8(["Download Exame"])
    end

    RE["Recepcionista"] --- UC1
    BI["Bioquímico Sênior"] --- UC4
    UC4 -. "<< include >>" .-> UC7
    PA["Paciente"] --- UC8
    UC8 -. "<< extend >>" .-> UC5

🔍 Detalhamento: Segurança Visual

Note no diagrama acima como o Paciente nunca toca no endpoint de "Validar Laudo". Visualmente, o Arquiteto trancou a rota. Nenhum programador sênior esquecerá de colocar a trava de segurança no código Java após ver este fluxograma.

[!TIP] Dica Sênior: Se você tem uma ação que se repete em 10 Casos de Uso diferentes (ex: "Fazer Login"), use o <<include>> para não precisar redesenhar a lógica em todos. Isso é o equivalente ao reuso de código na modelagem. 🚀

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se você modelar um <<include>> para uma ação que na verdade é opcional, o que acontecerá com o sistema? (Resposta: O sistema ficará engessado. O usuário será obrigado a fazer algo que não queria, gerando uma péssima experiência de uso e um bug de regra de negócio). 🧠🛡️

📐 CAPÍTULO 12: DIAGRAMA DE CLASSES (CONCEITOS)

Chegamos ao núcleo da Engenharia de Sistemas modernos. Se os "Casos de Uso" explicavam o que o usuário vê, o Diagrama de Classes explica como o software organiza a Memória RAM e o Banco de Dados. 🛡️🧩

🎯 Objetivo do Capítulo

Dominar a estrutura de classes, atributos e métodos, aplicando os modificadores de visibilidade e as associações fundamentais para criar um modelo de dados escalável.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, o time de Backend está migrando do modelo de "Scripts de Banco" para a Orientação a Objetos em Java. Os desenvolvedores precisam saber: O que é um objeto vivo na memória? Como protegemos o saldo de uma conta de ser alterado por qualquer um?

"Seu desafio como Arquiteto de Dados é desenhar o molde das classes. Você deve definir quais informações são privadas (escondidas no cofre) e quais ações são públicas para os outros objetos."

🧠 Classes vs. Objetos (Instâncias)

Classe: É o "Molde" ou a "Planta". Não tem dados reais ainda. (Ex: A classe Motorista).
Objeto (Instância): É a "Vida" na memória RAM. Tem dados reais. (Ex: O motorista João, CPF 123.456...).

🔍 Anatomia de uma Classe UML

Uma classe é representada por um retângulo dividido em três partes:

Nome: Substantivo no singular (Ex: Produto).
Atributos (Dados): O que ele guarda. (Ex: - preco: Double).
Métodos (Ações): O que ele faz. (Ex: + calcularDesconto()).

🛡️ Visibilidade (Encapsulamento)

Controlamos o acesso aos dados usando símbolos universais:

+ (Public): Qualquer um pode acessar.
- (Private): Somente a própria classe pode mexer. (O "Cofre").
# (Protected): A classe e suas filhas (herança) podem acessar.

📊 Exemplo de Classe Protegida

classDiagram
    class ContaBancaria {
        -Double saldoOculto
        #String titular
        +efetuarSaque(Double valor)
        +consultarSaldo() Double
    }

[!TIP] Regra de Ouro (Java Sênior): Atributos devem ser SEMPRE Privados (-). O acesso a eles deve ser feito exclusivamente por métodos Públicos (+). Isso garante que ninguém mude um saldo para negativo por erro de lógica externa. 🚀

🖇️ Relacionamentos (Associações)

As classes não vivem isoladas. Elas se conectam para realizar tarefas complexas.

1. Multiplicidade (Cardinalidade)

Indica quantos objetos podem se conectar:

1: Exatamente um (Obrigatório).
0..*: Zero ou Muitos (Opcional).
1..*: Pelo menos um (Obrigatório).

classDiagram
    class Cliente {
        -String nome
    }
    class Pedido {
        -Date data
    }
    Cliente "1" -- "0..*" Pedido : Realiza

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Por que uma tabela de Banco de Dados não é exatamente a mesma coisa que uma Classe UML? (Resposta: Porque tabelas guardam apenas dados mortos; Classes guardam dados e também Comportamentos/Métodos que rodam na memória). 🧠🛡️

🧬 CAPÍTULO 13: HERANÇA E POLIMORFISMO

A Herança é o mecanismo onde uma classe "filha" herda automaticamente as características da classe "pai", permitindo a criação de sistemas modulares e a eliminação de redundância (DRY - Don't Repeat Yourself). 🛡️🧩

🎯 Objetivo do Capítulo

Dominar a hierarquia de classes, diferenciando Generalização de Especialização, e compreender como o Polimorfismo permite que objetos diferentes respondam à mesma chamada de formas distintas.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, o sistema de funcionários está crescendo. Temos o Motorista, o Mecânico e o Gerente. Todos eles têm nome, CPF e data de admissão. Se você criar essas variáveis em todas as classes, terá 3 vezes o mesmo trabalho.

"Seu desafio como Arquiteto Sênior é criar a Superclasse Funcionario. Nela, você colocará tudo o que é comum. As outras classes apenas 'estenderão' esse comportamento, focando apenas no que as torna únicas."

🧠 Hierarquia de Poderes no Java

Termo UML	Papel na Arquitetura
Superclasse (Pai)	Onde moram os dados genéricos (Ex: `Usuario`). Contém o que é comum a todos.
Subclasse (Filha)	Onde moram as especialidades (Ex: `Admin`, `Cliente`). Herda o Pai e adiciona permissões.

📊 Modelagem de Acesso

classDiagram
    class Usuario {
        +String email
        +String senha
        +fazerLogin()
    }
    class Admin {
        +Integer nivelAcesso
        +deletarUsuario()
    }
    class Cliente {
        +String cartaoCredito
        +comprarProduto()
    }
    Usuario <|-- Admin : extends
    Usuario <|-- Cliente : extends

🔍 Generalização vs. Especialização

Generalizar (Subir): Olhamos para as filhas e subimos para a classe Pai para remover repetições.
Especializar (Descer): Olhamos para a classe Pai e descemos para as filhas para adicionar comportamentos específicos (ex: o Motorista tem CNH, mas o Atendente não).

[!TIP] Dica de Reuso: O Polimorfismo permite que você trate todos os objetos como se fossem o "Pai". Na TecProExpress, você pode ter uma lista de Funcionarios e rodar um comando pagarSalario() para todos, independente se eles são motoristas ou gerentes. O sistema saberá qual regra aplicar a cada um. 🚀

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se você tem uma classe Animal e uma classe Cachorro que herda dela, e percebe que precisa criar uma classe Gato, você deve criar todos os atributos do zero ou herdar de Animal? (Resposta: Herdar de Animal. A herança economiza linhas de código e garante que, se o nome de um animal mudar, mudará para todos). 🧠🛡️

🎬 CAPÍTULO 14: DIAGRAMA DE SEQUÊNCIA

Enquanto o Diagrama de Classes mostra a "foto" parada do sistema, o Diagrama de Sequência mostra o "filme". Ele foca na ordem temporal das mensagens trocadas entre objetos para realizar um processo específico. 🛡️🧩

🎯 Objetivo do Capítulo

Dominar a modelagem dinâmica da UML, compreendendo como atores, controladores, serviços e bancos de dados interagem ao longo do tempo para entregar uma funcionalidade.

🏢 O Cenário Corporativo (TecProExpress)

Na TecProExpress, o time de Frontend reclama que a tela de Login está demorando muito. O desenvolvedor backend diz que é culpa do banco, o DBA diz que é culpa da rede.

"Seu desafio é desenhar o Diagrama de Sequência do Login. Você deve cronometrar visualmente onde a mensagem está passando. Quando o usuário clica em 'Entrar', quem recebe a mensagem primeiro? Quem valida o Token? Quem consulta o banco? Esse diagrama revelará o gargalo do sistema."

🧠 Elementos da Linha do Tempo

Elemento	Papel na Explicação Técnica
Ator e Objetos	Os participantes da interação (Usuário, API, Database).
Linhas de Vida	Linhas pontilhadas verticais que indicam o tempo.
Mensagens	Setas de chamada (Call) e de retorno (Return).
Foco de Controle	Retângulos que indicam que o objeto está executando uma lógica.

📊 Exemplo Prático: Fluxo de Autenticação JWT

Visualize como a TecProExpress valida o acesso seguro dos seus motoristas:

sequenceDiagram
    actor U as "Motorista App"
    participant API as "Gateway / Controller"
    participant S as "AuthService (Java)"
    participant B as "PostgreSQL"
    
    U->>+API: 1: POST /login (user, pass)
    API->>+S: 1.1: validateCredentials()
    S->>+B: 1.1.1: SELECT hash_password FROM users...
    B-->>-S: 1.1.2: hash_result
    S-->>-API: 1.2: Token JWT Gerado
    API-->>-U: 2: 200 OK (JWT Token)

🔍 Detalhamento: A Importância do Detalhe

Cada Caso de Uso desenhado no Capítulo 11 deve ser detalhado por um Diagrama de Sequência. Isso permite que o Arquiteto preveja:

Gargalos de Performance: Muitas setas indo para o banco de dados indicam que você precisa de um Cache (Redis).
Falhas de Segurança: Se o Ator fala direto com o Banco de Dados sem passar por um Service, você descobriu uma vulnerabilidade grave.

[!TIP] Dica Arquitetural: O Diagrama de Sequência é o melhor amigo do desenvolvedor na hora de escrever os testes de integração. Ele diz exatamente qual resposta esperar de cada camada do sistema. 🚀

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se o tempo flui de cima para baixo no diagrama, o que acontece se você desenhar uma resposta vindo antes da chamada? (Resposta: O diagrama está logicamente errado. Nada pode ser devolvido sem ser solicitado. O tempo é implacável na engenharia). 🧠🛡️

🔄 CAPÍTULO 15: DIAGRAMAS DINÂMICOS (ESTADOS E ATIVIDADES)

Enquanto o Diagrama de Sequência foca na troca de mensagens, os diagramas dinâmicos focam no Comportamento (Estados) e no Processo (Atividades). Eles são essenciais para modelar regras de negócio complexas. 🛡️🧩

🎯 Objetivo do Capítulo

Compreender as transições de situação de um objeto (Máquina de Estados) e o fluxo de controle de um algoritmo ou processo organizacional (Diagrama de Atividades).

🏢 O Cenário Corporativo (TecProExpress Logistics)

Na TecProExpress, o sistema de entrega de encomendas tem regras rígidas. Um pacote não pode ser marcado como "Entregue" se antes não passou pelo estado "Em Trânsito". Além disso, o processo de "Triagem" envolve várias sub-etapas paralelas.

"Seu desafio é modelar o ciclo de vida da encomenda. O que acontece se o cliente não estiver em casa? O pacote volta para qual estado? Use o Diagrama de Estados para garantir que o programador não permita 'pular etapas' no código."

🧠 Diagrama de Máquina de Estados

Foca nas transições de situação que um objeto único sofre. É o "Status" do banco de dados ganhando vida visual.

📊 Lifecycle de um Pedido (TecProExpress)

stateDiagram-v2
    [*] --> Aberto
    Aberto --> AguardandoPagamento : Checkout concluído
    AguardandoPagamento --> Pago : Confirmação Gateway
    AguardandoPagamento --> Cancelado : Timeout 24h
    Pago --> PreparandoEnvio : NF-e Gerada
    PreparandoEnvio --> Enviado : Coleta Transportadora
    Enviado --> Entregue : Protocolo Assinado
    Entregue --> [*]
    Cancelado --> [*]

🏗️ Diagrama de Atividades (Fluxogramas)

Descreve o fluxo de controle de um processo complexo. É um fluxograma inteligente com suporte a decisões e paralelismo.

Componente	Visual e Propósito
Atividade	Ação executada (Ex: "Calcular Frete").
Decisão (Losango)	Bifurcação (Sim/Não).
Sincronização (Barra)	Atividades simultâneas (Parallel Processing).

📊 Fluxo de Checkout e Pagamento

graph TD
    A(["INÍCIO"]) --> B["Realizar Checkout"]
    B --> C{"Pagamento Aprovado?"}
    C -- "Sim" --> D["Gerar Ordem de Serviço"]
    C -- "Não" --> E["Notificar Falha"]
    D --> F(["FIM"])
    E --> B
    
    style B fill:#e3f2fd,stroke:#1e88e5
    style D fill:#f1f8e9,stroke:#558b2f

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Qual a principal diferença entre um Diagrama de Atividades e um de Sequência? (Resposta: O de Atividades foca no Fluxo de Lógica/Algoritmo, enquanto o de Sequência foca na Troca de Mensagens entre Objetos). Use o de Atividades para processos de negócio e o de Sequência para arquitetura técnica. 🧠🛡️

🛡️ CAPÍTULO 16: QUALIDADE DE SOFTWARE (SQA)

Qualidade de software não é um acidente; é o resultado de esforço inteligente e processos bem definidos. No mundo corporativo, a qualidade é o que separa uma startup de fundo de quintal de uma empresa global de tecnologia. 🛡️🧩

🎯 Objetivo do Capítulo

Dominar os conceitos de SQA (Software Quality Assurance), compreendendo as normas internacionais (ISO/IEC 25010) e as diferentes perspectivas de satisfação do cliente.

🏢 O Cenário Corporativo (TecProExpress QA)

A TecProExpress acaba de perder um contrato de milhões porque o sistema de pagamentos caiu durante a Black Friday. O código funcionava, mas não aguentou o volume de acessos.

"Seu desafio como Líder de QA é implementar uma cultura de Zero Defeitos. Você deve aplicar as normas da ISO 25010 para garantir que o sistema não seja apenas funcional, mas também confiável, seguro e fácil de manter."

🧠 Perspectivas de Qualidade

A qualidade pode ser vista sob diferentes óticas estratégicas:

Autor / Norma	Abordagem Estratégica
Philip B. Crosby	Zero Defeitos: Qualidade é conformidade total com o que foi pedido.
Joseph M. Juran	Adequação ao Uso: O sistema deve ser útil e fácil para o usuário final.
ISO/IEC 25010	Modelo de Qualidade: Define 8 pilares, como Segurança e Portabilidade.

📊 O Ecossistema da Qualidade

graph LR
    QA["Garantia de Qualidade"] --> T["Testes Automatizados"]
    T --> E["Evolução Sustentável"]
    E --> C["DevOps & Configuração"]

🔍 Necessidades Explícitas vs. Implícitas

Um software de qualidade atende a dois mundos:

Explícitas: O que está no contrato. (Ex: "O sistema deve calcular o ICMS").
Implícitas: O que o usuário espera, mas não disse. (Ex: "O sistema não deve travar se eu clicar duas vezes no botão").

[!IMPORTANT] A Decisão do Engenheiro: A qualidade tem um custo. Implementar segurança máxima em um app de "Lista de Compras" é desperdício. Implementar segurança máxima em um "App Bancário" é obrigação. O bom engenheiro equilibra o investimento em qualidade com o risco do negócio. 🚀

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se um sistema atende todos os requisitos do contrato (Qualidade Explícita), mas é tão lento que o usuário desiste de usar (Falha Implícita), ele é um software de qualidade? (Resposta: Não. Segundo Juran, ele falhou na 'Adequação ao Uso'. Qualidade é satisfação, não apenas check-list). 🧠🛡️

🧪 CAPÍTULO 17: ESTRATÉGIAS DE TESTE

Testar é o processo de executar o software com a intenção deliberada de encontrar erros e validar o comportamento esperado. Na engenharia moderna, o foco é a Automação para garantir a velocidade da entrega. 🛡️🧩

🎯 Objetivo do Capítulo

Compreender a Pirâmide de Testes, diferenciando testes Unitários, de Integração e de Sistema, e aplicar os axiomas fundamentais da validação de software.

🏢 O Cenário Corporativo (TecProExpress QA)

Na TecProExpress, o time de desenvolvimento enviou uma atualização que quebrou o sistema de login em produção. O erro era simples, mas como ninguém testou, ele passou despercebido.

"Seu desafio é implementar a Pirâmide de Testes. Não aceitaremos mais códigos que não tenham cobertura de testes unitários. Você deve garantir que a base da pirâmide seja sólida para que possamos subir para a nuvem com confiança."

🧠 A Pirâmide de Testes

Os testes são organizados por granularidade. Quanto mais baixo na pirâmide, mais rápido e barato é o teste.

📊 Estrutura de Granularidade

graph TD
    A["🧪 Teste Unitário (JUnit)"] --> B["⚙️ Teste de Integração"]
    B --> C["🌐 Teste de Sistema (E2E)"]
    C --> D["🤝 Teste de Aceitação (UAT)"]
    
    style A fill:#e3f2fd,stroke:#1e88e5
    style D fill:#f1f8e9,stroke:#558b2f

Nível de Teste	O que validamos na prática?
Unitário	O método ou a classe funciona isolada? (Base da pirâmide).
Integração	O Banco de Dados e as APIs conversam corretamente?
Sistema (E2E)	O fluxo completo do usuário está estável (Cypress/Selenium)?
Aceitação	O cliente aprova a funcionalidade para subir em Produção?

🔍 Axiomas Fundamentais do Teste

Presença de Erros: Testes mostram que existem erros, nunca que o sistema é 100% perfeito.
Impossibilidade de Exaustão: Não dá para testar todas as combinações infinitas do mundo.
Princípio de Pareto (80/20): 80% dos problemas estão concentrados em apenas 20% das funcionalidades mais complexas.

[!TIP] Dica Sênior: Invista pesado na base da pirâmide (Testes Unitários). Eles rodam em milissegundos e pegam erros de lógica antes mesmo de o código sair da sua máquina. Testes de interface (E2E) são caros e lentos; use-os com moderação para os fluxos críticos. 🚀

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se você tem um prazo curto, deve focar em testes de Sistema (interface) ou em testes Unitários? (Resposta: Unitários. Eles dão o feedback mais rápido e garantem que o 'motor' do sistema está funcionando, mesmo que a 'carroceria' ainda tenha ajustes). 🧠🛡️

🔄 CAPÍTULO 18: MANUTENÇÃO E EVOLUÇÃO

Após a implantação, o software entra em sua fase mais longa: a Evolução. Um sistema que não evolui torna-se obsoleto e morre. Na engenharia, chamamos isso de combate à Entropia de Software. 🛡️🧩

🎯 Objetivo do Capítulo

Identificar os quatro tipos de manutenção (Corretiva, Adaptativa, Evolutiva e Perfectiva) e compreender como a gestão da Dívida Técnica impacta a sustentabilidade do projeto a longo prazo.

🏢 O Cenário Corporativo (TecProExpress Maintenance)

O sistema da TecProExpress roda há 5 anos. No início, era fácil adicionar novas funcionalidades. Hoje, qualquer mudança simples leva semanas porque o código está uma "bagunça" e ninguém sabe como certas partes funcionam.

"Seu desafio como Engenheiro de Manutenção é pagar a Dívida Técnica. Você deve dedicar 20% do tempo de cada Sprint para refatorar o código antigo, garantindo que o sistema continue evoluindo sem quebrar sob o próprio peso."

🧠 Tipos de Manutenção no Ciclo de Vida

Tipo de Manutenção	Gatilho Técnico
Corretiva	"Bugs". Reparar erros reportados pelos usuários.
Adaptativa	"Mudança". O sistema precisa rodar em um novo OS ou Nuvem.
Evolutiva	"Novas Features". Adicionar funções para manter a competitividade.
Perfectiva (Refatoração)	"Qualidade". Melhorar o código sem mudar o que ele faz.

📊 O Ciclo da Evolução

graph LR
    A["Lançamento v1.0"] --> B["Uso e Feedback"]
    B --> C["Manutenção Corretiva"]
    C --> D["Evolução v2.0"]
    D --> B

🔍 O Perigo da Dívida Técnica

Manutenções feitas às pressas, sem seguir padrões, geram "Dívida Técnica". Como um empréstimo bancário, essa dívida gera juros: cada nova funcionalidade fica mais cara e demorada de produzir.

[!CAUTION] Dica Sênior: Nunca ignore a manutenção Perfectiva. Refatorar o código hoje economiza meses de dor de cabeça amanhã. Na TecProExpress, a regra é clara: "Deixe o código sempre um pouco melhor do que você o encontrou". 🛡️

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se o mercado lança uma nova lei que obriga todos os sistemas a mudarem a forma de calcular impostos, que tipo de manutenção você deve realizar? (Resposta: Manutenção Adaptativa, pois o sistema precisa se adaptar a um novo ambiente externo/regulatório). 🧠🛡️

📦 CAPÍTULO 19: GERÊNCIA DE CONFIGURAÇÃO (SCM)

O SCM (Software Configuration Management) é o conjunto de processos que gerencia as mudanças inevitáveis nos artefatos de software. No mundo moderno, isso é sinônimo de Git e esteiras de automação (DevOps). 🛡️🧩

🎯 Objetivo do Capítulo

Compreender os pilares da governança de código, dominando termos como Baseline, Branching e Release, e entender como o Git atua como a espinha dorsal da colaboração em equipe.

🏢 O Cenário Corporativo (TecProExpress DevOps)

Na TecProExpress, 50 desenvolvedores trabalham no mesmo sistema de rastreamento. Ontem, um desenvolvedor apagou acidentalmente uma funcionalidade que outro estava terminando.

"Seu desafio é implementar uma política de SCM rigorosa. Nenhum código entra na 'main' sem passar por um Pull Request e por testes automatizados. Você deve garantir que tenhamos Baselines (versões estáveis) para que possamos voltar no tempo se algo der errado em produção."

🏗️ Os Pilares da Governança de Código

graph TD
    SCM(("SCM")) --> Mudanca["🛡️ Mudanças"]
    SCM --> Versao["🏷️ Versões (Git)"]
    SCM --> Construcao["⚙️ Builds (Docker)"]
    SCM --> Release["🚀 Releases"]
    
    Mudanca --> Impacto["Pull Request Review"]
    Versao --> Conflito["Merge & Conflict Resolution"]
    Construcao --> Exec["Continuous Integration"]
    Release --> Entrega["Continuous Delivery"]

🧠 Terminologias de Mercado

Termo	Definição na Engenharia Profissional
Baseline	Um ponto imutável no tempo (Tag no Git) que representa uma versão estável.
Branch / Merge	Desenvolvimento em paralelo. Isolar uma tarefa antes de fundi-la ao código principal.
Release	O pacote de software testado e aprovado pronto para os usuários.
CI/CD	A automação que testa e envia o código para a nuvem assim que você dá um 'push'.

[!TIP] Dica de Carreira: Não saber usar Git hoje em dia é como um engenheiro civil que não sabe usar uma trena. É a ferramenta básica que garante a integridade do seu trabalho e a colaboração saudável do time. 🚀

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se o seu sistema está com um bug crítico em produção e você não tem uma Baseline (Tag) da versão anterior, o que você fará? (Resposta: Você terá que tentar corrigir o erro sob pressão máxima, correndo o risco de criar novos bugs. Se tivesse uma Baseline, poderia fazer o 'Rollback' em segundos). 🧠🛡️

🏆 CAPÍTULO 20: CONCLUSÃO E PRÓXIMOS PASSOS

Parabéns! Você concluiu a jornada teórica de Engenharia de Software no padrão TecProExpress. O que antes era apenas "escrever código" agora se transformou em uma disciplina de engenharia rigorosa, focada em qualidade e entrega de valor. 🛡️🧩

🎯 Resumo da sua Trajetória

Ao longo deste módulo, você dominou os quatro pilares da engenharia moderna:

Fase	O que você dominou?
I. Fundamentos	Ciclo de Vida, Processos (Cascata/Incremental) e a agilidade do Scrum/XP.
II. Requisitos	A arte de descobrir o que o cliente precisa (Discovery) e documentar na ERS.
III. Modelagem	O poder da UML: Casos de Uso, Classes, Sequência e Estados.
IV. Qualidade	SQA, Pirâmide de Testes, Manutenção e Gerência de Configuração (Git).

🚀 O Próximo Nível

A Engenharia de Software não é estática. Agora que você tem a base, o próximo passo é aplicar esses conceitos em arquiteturas ainda mais complexas, como Microserviços, Cloud Native e DevSecOps.

"O código que você escreve hoje é a dívida técnica de amanhã. Escreva com orgulho, teste com rigor e documente com clareza."

Esperamos que este guia sirva como sua bússola técnica. A Engenharia de Software não é apenas sobre máquinas; é sobre resolver problemas reais de pessoas reais através da tecnologia.

Desejamos muito sucesso em sua trajetória como Engenheiro(a) de Software Profissional! 🌟🚀

Coordenação de Engenharia de Software | TecProExpress

📚 PROJETOS II — ENGENHARIA DE SOFTWARE

Bem-vindo(a) ao módulo prático de Projetos II. Aqui você aprenderá que desenvolver software é muito mais do que apenas escrever código: é entender pessoas, modelar processos e garantir a qualidade. 🛡️🧩

🏗️ O Desafio Semestral

Você trabalhará em um projeto único ao longo de todo o semestre. Cada atividade (01 a 09) é uma peça de um quebra-cabeça que resultará na Atividade 10: O Documento de Especificação de Requisitos (ERS) completo.

📁 Organização do Repositório (GitHub)

Crie um repositório chamado atividades-engenharia-software com a seguinte estrutura:

📂 atividades-engenharia-software/
├── 📂 es-atv-01-escopo/
├── 📂 es-atv-02-processos/
├── 📂 es-atv-03-requisitos/
├── 📂 es-atv-04-backlog/
├── 📂 es-atv-05-casos-uso/
├── 📂 es-atv-06-prototipagem/
├── 📂 es-atv-07-classes/
├── 📂 es-atv-08-sequencia/
├── 📂 es-atv-09-testes/
└── 📂 es-atv-10-projeto-final/

🛠️ Ferramentas Recomendadas

Para realizar as atividades, você precisará de:

Astah UML ou Lucidchart: Para os diagramas UML.
Figma ou Balsamiq: Para a prototipagem.
Trello ou Notion: Para a gestão do Backlog.
Git / GitHub: Para o versionamento da documentação.

💡 Dica do Especialista: Engenharia de Software é sobre comunicação. Se o seu diagrama não puder ser entendido por outra pessoa sem você explicar, ele precisa ser melhorado! 🚀🛡️

📅 CRONOGRAMA — PROJETOS II (ENGENHARIA DE SOFTWARE)

Planejamento de 20 semanas acadêmicas com atividades práticas lineares e autoguiadas, cobrindo todo o ciclo de vida moderno de engenharia e operações de software. 🛡️🧩

Semana	Tópico de Aula (Referência)	Atividade Prática de Engenharia
1	Introdução à Engenharia de Software	✅ Atv 01: Escopo e Personas
2	Modelos de Processos e Metodologias Ágeis	✅ Atv 02: Processos de Software
3	Elicitação e Engenharia de Requisitos	✅ Atv 03: Requisitos (FR/NFR)
4	Decomposição de Escopo e Gestão de Backlog	✅ Atv 04: User Stories e Backlog
5	Modelagem de Casos de Uso	✅ Atv 05: Diagrama de Casos de Uso (UML)
6	Design de Interfaces e Prototipagem	✅ Atv 06: Prototipagem (Wireframes)
7	Modelagem Estrutural: Classes	✅ Atv 07: Diagrama de Classes (UML)
8	Modelagem Dinâmica: Sequência	✅ Atv 08: Diagrama de Sequência (UML)
9	Conceitos de Testes e Plano de Testes	✅ Atv 09: Qualidade e Testes
10	Fase I: Consolidação de Requisitos	✅ Atv 10: Projeto Integrador Final (Fase I)
11	Modelagem de Processos Complexos	✅ Atv 11: Diagrama de Atividades (UML)
12	Modelagem de Comportamento Dinâmico	✅ Atv 12: Diagrama de Transição de Estados (UML)
13	Arquitetura de Software e Padrões de Design	✅ Atv 13: Arquitetura de Software e Padrões
14	Integração de Sistemas e Design de APIs	✅ Atv 14: Modelagem de APIs REST e Swagger
15	Gerência de Configuração e GitFlow	✅ Atv 15: GitFlow e Trabalho Colaborativo
16	Integração Contínua (CI)	✅ Atv 16: Pipelines de CI/CD com GitHub Actions
17	Containerização de Ambientes de Execução	✅ Atv 17: Containerização com Docker
18	Segurança no Ciclo de Vida (DevSecOps)	✅ Atv 18: Segurança e OWASP Top 10
19	Gestão e Métricas de Engenharia	✅ Atv 19: Métricas de Software, Estimativas e DORA
20	Fase II: Dossiê de Engenharia Moderno	🏆 Atv 20: Projeto Final Avançado (Fase II)

📊 Pesos das Atividades (Total 5.0 pontos na Média)

Atividade	Peso na Média Final
Atv 01 a 19	0.20 cada
Atv 20: Projeto Final (Fase II)	1.20

💡 Nota: O Projeto Final Avançado (Fase II) é o dossiê integrador que consolida todos os artefatos de engenharia desenvolvidos ao longo do semestre.

🎯 ATIVIDADE 01: ESCOPO E PERSONAS

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da indústria, definindo as bases de um projeto real de Engenharia de Software. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Definir um Escopo claro de projeto, diferenciando o que o sistema fará (In) do que não fará (Out).
Criar Personas que representem usuários reais, mapeando suas dores e necessidades.
Documentar a ideia central de um software profissional de ponta a ponta.

🏢 O Cenário Prático (Seu Desafio)

Imagine que você é o Líder de Produto (Product Owner) da TecProExpress. A diretoria identificou que os motoristas terceirizados estão com dificuldades para encontrar as entregas do dia, e o SAC está lotado de clientes perguntando "Onde está meu pacote?". O desafio desta semana é:

"Você precisa documentar a proposta de um novo App de Rastreamento. Sua primeira missão é definir o Escopo do projeto (para não estourar o orçamento da empresa) e descrever exatamente quem são as Personas (O Motorista e O Cliente) que vão usar a ferramenta."

🧠 Fundamentos: A Teoria Traduzida

Na Engenharia de Software, não saímos programando no primeiro dia. Precisamos alinhar as expectativas com os stakeholders (pessoas interessadas).

Escopo e Personas

Escopo (Scope): É o limite do projeto. Se o cliente pede um carro, o escopo é o carro; um avião está fora do escopo.
Persona: É uma representação semi-fictícia do seu cliente ideal baseada em dados reais e suposições educadas. Ela tem nome, dores e objetivos.

📊 Visualizando a Lógica

[!TIP] Em projetos ágeis, um escopo mal definido leva ao "Scope Creep" (quando o projeto cresce descontroladamente e nunca termina). Delimite desde o dia 1!

flowchart TD
    A[Dor do Cliente] --> B{Análise de Escopo}
    B -- Dentro (In) --> C[Desenvolver Funcionalidade]
    B -- Fora (Out) --> D[Registrar para o Futuro]

📖 Exemplo Guiado

Abaixo, veja como aplicar a teoria passo a passo no cenário da TecProExpress.

Passo	Ação de Engenharia	Resultado Esperado
01	Definir o Problema	Motoristas e Clientes perdidos sem saber onde está o pacote.
02	Mapear Escopo In/Out	O que o App fará e o que ele vai deixar de fora.
03	Criar Persona	Ficha técnica do usuário alvo.

📊 Delimitação Visual do MVP (Escopo In/Out)

flowchart TD
    subgraph IN [Escopo Ativo - MVP]
        direction TB
        F1["Chave de Ignição: Login Seguro"]
        F2["Painel do Motorista: Lista de Entregas"]
        F3["Status da Carga (Pendente / Trânsito / Entregue)"]
    end
    subgraph OUT [Escopo Futuro - Fora]
        direction TB
        NF1["Gestão Financeira & Comissões"]
        NF2["Algoritmo Avançado de Inteligência Artificial para Rotas"]
    end
    IN -.-> OUT
    style IN fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style OUT fill:#ffebee,stroke:#c62828,stroke-width:2px

🛠️ Exemplo de Documentação

# Projeto: Rastreio Express

**Escopo (In):**
- Login do Motorista.
- Atualização de status da entrega (Pendente, Em Trânsito, Entregue).

**Escopo (Out):**
- Pagamento de comissão do motorista (Fora do escopo atual).

**Persona:**
*Nome:* Roberto "Beto", 45 anos.
*Ocupação:* Motorista Terceirizado.
*Dor:* "O aplicativo antigo trava muito e eu perco tempo ligando pro cliente."
*Objetivo:* Um botão gigante de "Cheguei no local".

🔍 Detalhamento da Documentação:

Escopo (In): É o MVP (Mínimo Produto Viável).
Escopo (Out): Protege a equipe de desenvolvimento contra pedidos abusivos que atrasam a entrega.
Persona: Vai muito além de "homens de 40 a 50 anos". O Beto tem uma Dor e a nossa interface tem que curar essa dor.

🛠️ Prática Obrigatória 1: Definição do Escopo

Cenário: O projeto semestral que você vai desenvolver. Você pode escolher um sistema de Delivery, Gestão Escolar, PetShop ou criar o seu próprio.

Dê um Título para o seu sistema.
Escreva 1 parágrafo descrevendo "O Problema" que ele resolve.
Liste 3 funcionalidades que estão Dentro (In) do escopo.
Liste 2 funcionalidades que estão Fora (Out) do escopo.

🏁 Resultado Esperado (Para sua Referência)

Você deverá gerar um documento (Markdown ou PDF) contendo essas definições claras, sem jargões excessivos, provando que você sabe limitar o tamanho do seu projeto.

🛠️ Prática Obrigatória 2: As Personas

Cenário: Dar vida aos usuários do seu projeto.

Crie a Persona 1 (O usuário administrativo ou prestador de serviço).
Crie a Persona 2 (O cliente final).

Para cada uma, defina: Nome, Idade, Ocupação, Dores (frustrações) e Objetivo.

🏁 Resultado Esperado (Para sua Referência)

Fichas textuais ou cartões visuais (desenhados no draw.io ou Canva) detalhando humanamente quem utilizará o software.

📤 Instruções de Entrega (Microsoft Teams)

Após validar as suas definições de engenharia:

Salve o arquivo de documentação com o nome Atividade_01.md na pasta es-atv-01-escopo/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Por que é tão difícil dizer "Não" para o cliente na fase de escopo? (Resposta: Porque queremos agradar, mas como engenheiros, nossa função é garantir a entrega. Cada "Sim" para uma ideia fora do escopo aumenta o risco de falha do projeto inteiro). 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Expert 🏆

Se você terminou rápido, expanda o seu escopo criando a "Matriz de Priorização (MoSCoW)":

Must have (Deve ter)
Should have (Deveria ter)
Could have (Poderia ter)
Won't have (Não vai ter nesta versão)

Classifique as funcionalidades do seu projeto nessas 4 categorias e anexe ao documento final.

🎯 ATIVIDADE 02: MODELOS DE PROCESSO DE SOFTWARE

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da indústria, definindo as engrenagens de como a sua equipe vai trabalhar. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Diferenciar modelos Preditivos (Cascata/Waterfall) de modelos Adaptativos (Ágeis, Scrum, Kanban).
Justificar tecnicamente a escolha de um processo de software com base no nível de incerteza do escopo.
Definir papéis gerenciais e operacionais (ex: Product Owner, Scrum Master, Dev Team).

🏢 O Cenário Prático (Seu Desafio)

A diretoria da TecProExpress aprovou o escopo do seu "App de Rastreamento" (Atividade 01). Agora, o Gerente de Projetos quer saber: "Como vocês vão construir isso?"

Um diretor mais antigo sugeriu o uso do Modelo Cascata, exigindo que a equipe entregue o software completo apenas daqui a 6 meses. O seu time de desenvolvimento, no entanto, acredita que o mercado é muito volátil e prefere o Scrum para fazer entregas mensais.

"Seu desafio é vestir a camisa de Scrum Master / Agile Coach, escolher oficialmente qual modelo o projeto da sua equipe (criado na Atividade 01) vai seguir, e apresentar uma justificativa técnica blindada contra argumentos antigos."

🧠 Fundamentos: A Teoria Traduzida

Não existe um "melhor" modelo de processo de software. Existe o modelo que melhor lida com o nível de risco do seu projeto.

Preditivo vs Adaptativo

Cascata (Preditivo): Você tem que saber 100% do que o cliente quer no dia 1. Se o cliente mudar de ideia no meio, o projeto falha. Ideal para: Softwares de aviões ou satélites.
Ágil/Scrum (Adaptativo): Você assume que o cliente não sabe o que quer e vai mudar de ideia. O software é feito em "fatias" (Sprints) e o cliente testa mensalmente. Ideal para: Apps, Sistemas Web, Startups.

📊 Visualizando a Lógica

[!TIP] Em projetos acadêmicos e startups, a incerteza é gigante. Escolher metodologias ágeis é quase um instinto de sobrevivência!

flowchart LR
    subgraph Cascata
    A1["Requisitos"] --> B1["Design"] --> C1["Código"] --> D1["Testes"] --> E1["Morte se o cliente mudar de ideia"]
    end

    subgraph Scrum
    A2(("Sprint 1")) --> B2(("Sprint 2")) --> C2(("Sprint 3"))
    end

📖 Exemplo Guiado

Abaixo, veja como estruturar a escolha de um processo.

Passo	Ação de Engenharia	Resultado Esperado
01	Analisar a Incerteza	Alta incerteza (O motorista do App não sabe bem o que quer).
02	Escolher o Modelo	Scrum.
03	Definir Papéis	Quem é o Dono do Produto (PO)? Quem programa?

📊 Jornada de uma Tarefa no Kanban Ágil

flowchart LR
    B["Backlog (Ideias)"] --> TD["To Do (Sprint)"]
    TD --> IP["In Progress"]
    IP --> CR["Code Review"]
    CR --> QA["Testing/QA"]
    QA --> DN["Done (Produção)"]

    style B fill:#eceff1,stroke:#607d8b
    style TD fill:#e1f5fe,stroke:#0288d1
    style IP fill:#fffde7,stroke:#fbc02d
    style CR fill:#f3e5f5,stroke:#8e24aa
    style QA fill:#e8f5e9,stroke:#2e7d32
    style DN fill:#e0f2f1,stroke:#004d40,stroke-width:2px

🛠️ Exemplo de Documentação

# Processo Escolhido: Scrum

**Justificativa:** 
Optamos pelo Scrum porque o aplicativo de rastreio tem alta incerteza. Como não sabemos se os motoristas terceirizados vão se adaptar à interface, precisamos de feedback constante (Sprints de 2 semanas) para corrigir a rota antes do orçamento acabar, coisa que o Cascata não permitiria.

**Papéis no Scrum:**
* **Product Owner (PO):** O Gerente de Logística (Dono do processo).
* **Scrum Master:** O Líder Técnico do projeto.
* **Dev Team:** Os programadores e designers.

🔍 Detalhamento da Documentação:

A Justificativa não é "porque é mais moderno". É uma defesa baseada na Incerteza e no Custo do Erro.
O PO (Product Owner) não é um programador. É a pessoa que entende de logística e sabe o que dá dinheiro para a empresa.

🛠️ Prática Obrigatória 1: Escolha e Justificativa

Cenário: O projeto semestral da sua equipe.

Declare qual modelo seu projeto vai seguir: Scrum, Kanban ou Cascata.
Escreva um parágrafo de no mínimo 4 linhas justificando tecnicamente sua escolha, usando as palavras "Incerteza" e "Feedback".

🏁 Resultado Esperado (Para sua Referência)

Texto argumentativo profissional validando o modelo de trabalho escolhido.

🛠️ Prática Obrigatória 2: Papéis e Cadência

Cenário: Estruturação da equipe.

Definição de Papéis: Baseado nas suas Personas e no seu cenário da Atividade 01, liste quem ocuparia o papel de PO (Quem dita o que tem valor) e quem seria o Scrum Master / Time.
Cadência: Se escolheu Scrum, defina o tamanho da sua Sprint (ex: 1 semana, 2 semanas). Por que esse tempo?

🏁 Resultado Esperado (Para sua Referência)

Um arquivo de documentação (Markdown ou PDF) listando os atores do projeto e o calendário de entregas.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas documentações técnicas:

Salve o arquivo de documentação com o nome Atividade_02.md na pasta es-atv-02-processos/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se a sua equipe (Dev Team) atrasar uma entrega importante e reclamar que foi por causa de uma interrupção não programada, quem deveria intervir e protegê-los de distrações externas? O Product Owner ou o Scrum Master? (Resposta: O Scrum Master é o escudo do time contra o caos corporativo). 🧠🛡️

🎯 ATIVIDADE 03: ENGENHARIA DE REQUISITOS (FR E NFR)

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da indústria, aprendendo a redigir o contrato técnico que guiará todos os programadores. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Diferenciar Requisitos Funcionais (RF) (O que o sistema faz) de Requisitos Não-Funcionais (RNF) (Como o sistema se comporta).
Redigir requisitos com alto rigor técnico utilizando o padrão de escrita: "O sistema deve...".
Aplicar uma matriz de priorização de requisitos (Essencial, Importante, Desejável).

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, após o seu time decidir utilizar a metodologia ágil (Atividade 02), a diretoria começou a bombardear a equipe com ideias para o novo App de Rastreamento. O diretor de Vendas quer que o App tenha "um mapa bem bonito e rápido". O diretor de Logística quer "um botão de pânico para o motorista".

Ouvindo essas demandas soltas, os desenvolvedores não sabem o que programar primeiro, nem como medir se o mapa é "bonito e rápido" o suficiente.

"Seu desafio é atuar como Engenheiro de Requisitos. Você deve traduzir as falas confusas e abstratas da diretoria em Requisitos Funcionais e Não-Funcionais matemáticos, testáveis e priorizados, criando a lista mestra que o time de desenvolvimento vai usar para trabalhar."

🧠 Fundamentos: A Teoria Traduzida

A Engenharia de Requisitos é a arte de extrair a verdade. Se o requisito for mal escrito, o programador criará o código errado.

Funcional vs Não-Funcional

Funcional (RF): É uma ação. É um botão que você clica, uma tela que abre, um cálculo que é feito. (Ex: "O sistema deve calcular o frete").
Não-Funcional (RNF): É a infraestrutura, a performance, a segurança. Você não clica num RNF, você o sente. (Ex: "O cálculo do frete deve ser respondido em menos de 2 segundos").

📊 Visualizando a Lógica

[!TIP] Use sempre o padrão "O sistema deve [AÇÃO] quando [CONDIÇÃO]". Nunca use adjetivos (bonito, rápido, seguro), use métricas exatas!

flowchart LR
    A["Fica abstrata do cliente:<br/>'O app tem que ser seguro'"] --> B{"Filtro do Engenheiro"}
    B --> C["RNF01: O sistema deve exigir<br/>uma senha de 8 caracteres<br/>alfanuméricos no login."]

📖 Exemplo Guiado

Abaixo, veja como categorizar e escrever requisitos de forma profissional.

Passo	Fala do Cliente	Tradução da Engenharia
01	"Quero cadastrar meus clientes."	RF01: O sistema deve permitir o cadastro de clientes contendo Nome, CPF e Endereço.
02	"O mapa tem que carregar rápido."	RNF01: O mapa de rastreio deve ser renderizado em no máximo 3 segundos após o clique.
03	"Tem que rodar no celular de todo mundo."	RNF02: O sistema deve ser responsivo e suportar os sistemas Android 10+ e iOS 14+.

📊 Priorização MoSCoW dos Requisitos da TecProExpress

flowchart TD
    subgraph MUST [Must Have - Essencial]
        M1["RF01: Login do Motorista"]
        M2["RF02: Listar Entregas do Dia"]
    end
    subgraph SHOULD [Should Have - Importante]
        S1["RF03: Roteirização Automática"]
    end
    subgraph COULD [Could Have - Desejável]
        C1["RF04: Som ao atribuir carga"]
    end
    MUST --> SHOULD --> COULD

    style MUST fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style SHOULD fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style COULD fill:#fffde7,stroke:#fbc02d,stroke-width:2px

🛠️ Estrutura de Documentação de Requisitos

# Lista de Requisitos (App Rastreio Express)

## Requisitos Funcionais (RF)
| ID | Descrição | Prioridade |
| :--- | :--- | :--- |
| RF01 | O sistema deve permitir que o motorista faça login via CPF e Senha. | Essencial |
| RF02 | O sistema deve listar as entregas do dia em ordem de distância. | Importante |
| RF03 | O sistema deve emitir um som quando um novo pacote for atribuído. | Desejável |

## Requisitos Não-Funcionais (RNF)
| ID | Categoria | Descrição |
| :--- | :--- | :--- |
| RNF01 | Performance | A listagem de entregas deve carregar em < 2 segundos. |
| RNF02 | Segurança | As senhas devem ser criptografadas em BCrypt no banco. |

🔍 Detalhamento da Documentação:

A Prioridade salva projetos. Se o prazo apertar, o time corta os requisitos "Desejáveis" para garantir que o "Essencial" suba para produção.
Categorias de RNF: Podem ser de Performance, Segurança, Usabilidade ou Tecnológicas.

🛠️ Prática Obrigatória 1: A Lista de Requisitos

Cenário: O projeto semestral da sua equipe (criado na Atividade 01).

Crie uma tabela com pelo menos 10 Requisitos Funcionais (RF).
Crie uma tabela com pelo menos 5 Requisitos Não-Funcionais (RNF).
Utilize estritamente a nomenclatura formal (RF01, RNF01) e o padrão de escrita "O sistema deve".
Para os Funcionais, indique se a prioridade é: Essencial, Importante ou Desejável.

🏁 Resultado Esperado (Para sua Referência)

Duas tabelas organizadas e limpas, sem ambiguidades, onde qualquer programador saberia exatamente o que fazer ao lê-las.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas documentações técnicas:

Salve o arquivo de documentação com o nome Atividade_03.md na pasta es-atv-03-requisitos/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Imagine que você escreveu o seguinte requisito: "RF04: O sistema deve ter uma tela de relatórios legais". Durante a entrega, o cliente recusou o sistema dizendo que o relatório não era "legal" o suficiente. Como engenheiro, onde esteve o erro e como você reescreveria esse requisito para se proteger de recusas futuras? 🧠🛡️

📝 ATIVIDADE 04: USER STORIES E BACKLOG

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da indústria ágil, mudando o foco do "O Quê" para o "Por Quê". 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Converter Requisitos Funcionais tradicionais em User Stories (Histórias de Usuário).
Redigir histórias no padrão internacional da agilidade: "Como [Persona], Eu quero [Ação], Para que [Valor]".
Criar Critérios de Aceite testáveis para definir o que significa uma tarefa "Pronta" (DoD).
Priorizar e organizar um Product Backlog.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, você entregou a lista de Requisitos Funcionais (Atividade 03) para a equipe de programadores. Um dos requisitos era: "RF01: O sistema deve ter uma barra de busca na tela inicial".

Os programadores criaram uma barra de busca linda, mas ela só buscava clientes pelo CPF. Quando os motoristas tentaram usar, ficaram furiosos, pois eles queriam buscar o endereço do cliente, não o CPF! O requisito foi cumprido tecnicamente, mas falhou comercialmente por falta de empatia e contexto.

"Seu desafio como Product Owner / Analista é impedir que isso aconteça novamente. Você deve pegar seus requisitos frios e reescrevê-los como User Stories, colocando o desenvolvedor na 'pele' da Persona, e escrevendo Critérios de Aceite que não deixem margem para dúvidas sobre como a funcionalidade deve se comportar."

🧠 Fundamentos: A Teoria Traduzida

Na agilidade, nós não escrevemos ordens genéricas, escrevemos "histórias" curtas que justificam o esforço do programador.

O Padrão da User Story

Uma boa história deve caber em um post-it. Ela tem 3 partes:

Como [Papel/Persona]: Quem precisa disso?
Eu quero [Ação]: O que o sistema tem que fazer?
Para que [Valor/Benefício]: Por que isso é importante? Qual a dor que resolve?

📊 Visualizando a Lógica

[!TIP] Uma User Story sem Critérios de Aceite é apenas um desejo abstrato. O Critério de Aceite é o "Contrato" que o desenvolvedor assina dizendo: "Se o sistema passar nestes testes, a história está pronta".

flowchart TD
    A["RF01: O sistema deve ter uma busca"] --> B{"Lente Ágil"}
    B --> C["História:<br/>COMO Motorista...<br/>QUERO buscar por endereço...<br/>PARA evitar usar outro GPS."]
    C --> D["Critério de Aceite 1:<br/>A busca deve aceitar CEP."]
    C --> E["Critério de Aceite 2:<br/>Deve exibir mapa ao clicar."]

📖 Exemplo Guiado

Abaixo, veja como aplicar a técnica de User Stories e Critérios de Aceite no contexto da TecProExpress.

Passo	Estrutura	Aplicação Real
01	Como (Quem)	Como Dona Silvana (Dona da loja),
02	Quero (Ação)	Quero ver os pedidos atrasados destacados em vermelho na tela,
03	Para (Valor)	Para que eu saiba rapidamente quem eu preciso cobrar primeiro.

📊 Decomposição Ágil: Do Épico aos Critérios de Aceite

flowchart TD
    EP["Épico: Logística Last-Mile"] --> F1["Feature: Rastreamento em Tempo Real"]
    EP --> F2["Feature: Painel de Gestão Comercial"]
    F1 --> US1["US01: Atualização de Status da Carga"]
    F1 --> US2["US02: Geolocalização de Motoristas"]
    US1 --> CA1["Critério 1: Status 'Entregue' exige comprovante"]
    US1 --> CA2["Critério 2: Notificar cliente em < 5s"]

    style EP fill:#eceff1,stroke:#607d8b,stroke-width:2px
    style F1 fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style F2 fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style US1 fill:#fffde7,stroke:#fbc02d,stroke-width:2px
    style US2 fill:#fffde7,stroke:#fbc02d,stroke-width:2px

🛠️ Estrutura do Backlog

# Product Backlog (Priorizado)

## US01: Destaque de Pedidos Atrasados
**Como** Dona Silvana,
**Quero** ver os pedidos com prazo vencido destacados na cor vermelha,
**Para que** eu possa focar nas cobranças mais urgentes assim que abrir o sistema.

**Critérios de Aceite:**
1. Pedidos com data de vencimento < Data de Hoje devem ter a cor de fundo #FF0000.
2. A tela deve apresentar um botão no topo "Filtrar apenas atrasados".
3. Se não houver pedidos atrasados, exibir mensagem: "Tudo em dia!".

## US02: ...

🔍 Detalhamento da Documentação:

Ao ler a US01, o programador entende a dor da Dona Silvana. Ele não fará apenas um "IF", ele entenderá o valor do negócio.
Os Critérios de Aceite são o roteiro que o testador de QA (Quality Assurance) usará para aprovar ou reprovar a entrega da equipe.
O documento completo forma o Product Backlog, que deve sempre estar organizado de cima para baixo (do mais importante para o menos importante).

🛠️ Prática Obrigatória: Construindo o Backlog

Cenário: O projeto semestral da sua equipe.

Selecione os 5 Requisitos Funcionais Essenciais da sua Atividade 03.
Transforme cada um desses 5 requisitos em uma User Story completa (Como/Quero/Para).
Abaixo de cada história, escreva pelo menos 2 Critérios de Aceite exatos e testáveis.
Organize as 5 histórias em ordem de prioridade (A número 1 é a primeira que os desenvolvedores começariam a programar na segunda-feira).

🏁 Resultado Esperado (Para sua Referência)

Um documento Markdown listando seu Backlog Ágil inicial, contendo as 5 histórias detalhadas. Isso servirá de insumo para todas as modelagens UML das próximas aulas.

📤 Instruções de Entrega (Microsoft Teams)

Após validar seu Backlog Ágil:

Salve o arquivo de documentação com o nome Atividade_04.md na pasta es-atv-04-backlog/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Imagine uma história que diz: "Como usuário, quero me cadastrar no sistema, para acessar minha conta". Há dois erros gravíssimos nessa história. O primeiro é escrever "Como usuário" (um termo vago que destrói o propósito da Persona). O segundo é o "Para acessar minha conta" (Isso não é o benefício real do cadastro, é apenas uma obviedade do sistema. O real benefício de se cadastrar na Netflix, por exemplo, é 'salvar meus filmes favoritos'). Nunca escreva obviedades, descubra o valor de negócio! 🧠🛡️

🎭 ATIVIDADE 05: CASOS DE USO (UML)

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da indústria visual, transformando requisitos em diagramas universais. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Identificar Atores (pessoas ou sistemas externos que interagem com o seu software).
Mapear Casos de Uso (funcionalidades entregues ao ator).
Aplicar os relacionamentos de dependência <<include>> e <<extend>> corretamente, segundo as normas UML.
Descrever textualmente o "Caminho Feliz" de um Caso de Uso.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, você escreveu um Backlog incrível (Atividade 04). Mas quando levou os Post-its para a diretoria, o CEO disse: "Não consigo ler isso, são muitos textos soltos. Quero um desenho que me mostre de forma macro o que o Motorista pode fazer e o que o Administrador pode fazer".

"Seu desafio é desenhar o primeiro diagrama oficial da Engenharia de Software: O Diagrama de Casos de Uso. Ele será a 'Planta Baixa' do seu aplicativo, estabelecendo a Fronteira do Sistema (o que está dentro e o que está fora)."

🧠 Fundamentos: A Teoria Traduzida

A UML (Linguagem de Modelagem Unificada) é o idioma mundial da engenharia. Um desenvolvedor japonês que não fala português consegue entender seu projeto se você desenhar em UML.

Elementos Chaves

Ator (Boneco de Palito): É quem provoca o sistema. (Ex: O Cliente, O Motorista, ou até a API do Banco Central).
Caso de Uso (Oval): Sempre no infinitivo (Ex: Atualizar Rastreio, Realizar Login).
Fronteira (Retângulo): A caixa do seu software. Atores ficam de fora, Casos de Uso ficam dentro.

📊 Visualizando a Lógica

[!TIP] A grande dúvida: Include vs Extend. <<include>>: É OBRIGATÓRIO. (Ex: Para "Fazer Pix", eu incluo obrigatoriamente a "Validação de Saldo"). <<extend>>: É OPCIONAL. (Ex: Ao "Comprar Produto", eu estendo a opção de "Aplicar Cupom", pois nem todo mundo tem cupom).

flowchart LR
    A(("Ator")) --> B(["Caso de Uso Principal"])
    B -. "<< include >>" .-> C(["Passo Obrigatório"])
    D(["Passo Opcional"]) -. "<< extend >>" .-> B

📖 Exemplo Guiado

Abaixo, veja como estruturar o cenário do aplicativo de logística da TecProExpress.

Passo	Ação de Engenharia	Resultado Esperado
01	Listar Atores	Motorista e SAC (Suporte).
02	Listar Ações (Ovais)	Login, Reportar Atraso, Consultar Endereço.
03	Validar Regras	Todo Login inclui Validar Senha.

📊 Relações de Include e Extend da TecProExpress

flowchart LR
    M(("Motorista")) --> UC1(["Finalizar Entrega"])
    UC1 -. "<< include >>" .-> UC2(["Registrar Geolocalização"])
    UC3(["Registrar Foto do Comprovante"]) -. "<< extend >> (Se falhar GPS)" .-> UC1

    style M fill:#eceff1,stroke:#607d8b,stroke-width:2px
    style UC1 fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style UC2 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style UC3 fill:#fffde7,stroke:#fbc02d,stroke-width:2px

🛠️ Especificação Textual do Caso de Uso

Todo oval desenhado precisa de um "Manual de Instruções" por trás dele. Exemplo do Caso "Reportar Atraso":

Ator Principal: Motorista.
Pré-condição: O motorista deve estar logado no aplicativo.
Fluxo Principal (Caminho Feliz):
1. O motorista seleciona a entrega em andamento.
2. Clica no botão "Reportar Atraso".
3. O sistema pede o motivo (Trânsito, Veículo Quebrado, etc).
4. O motorista seleciona o motivo e confirma.
5. O sistema atualiza o status e notifica o SAC.
Pós-condição: O status da entrega muda para "Atrasado".

🔍 Detalhamento da Documentação:

O Caminho Feliz é a rota perfeita, sem erros. É essencial escrever isso para que o testador de software saiba o que esperar quando tudo dá certo.

🛠️ Prática Obrigatória 1: O Diagrama

Cenário: O projeto semestral da sua equipe.

Acesse o draw.io (ou Lucidchart, Astah) e crie um Diagrama de Casos de Uso.
Desenhe a Fronteira do Sistema (O retângulo com o nome do App no topo).
Insira pelo menos 2 Atores diferentes (do lado de fora).
Insira pelo menos 6 Casos de Uso (dentro da fronteira), derivados das suas User Stories.
Crie pelo menos uma relação de <<include>> e uma de <<extend>>.

🏁 Resultado Esperado (Para sua Referência)

Um arquivo de imagem (PNG/JPG) com o diagrama organizado, onde as linhas não se cruzam loucamente, provando que você sabe abstrair o macro do sistema.

🛠️ Prática Obrigatória 2: O Caminho Feliz

Cenário: O detalhamento da regra de negócio.

Escolha o Caso de Uso principal do seu diagrama (A funcionalidade core do sistema).
Escreva a Especificação Textual contendo: Ator, Pré-condição, Fluxo Principal (Passo a passo numerado) e Pós-condição.

🏁 Resultado Esperado (Para sua Referência)

Um arquivo Markdown documentando o texto do caso de uso escolhido.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas documentações técnicas:

Salve o arquivo de documentação com o nome Atividade_05.md e a imagem do seu diagrama com o nome Atividade_05.png na pasta es-atv-05-casos-uso/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Um erro crasso é usar o Caso de Uso para modelar a Interface do Usuário. Exemplo de Caso Errado: "Clicar no Botão Verde". O Caso de Uso descreve o Negócio, não o Mouse. A forma correta seria "Confirmar Pagamento". A interface pode mudar de botão verde para comando de voz amanhã, mas o negócio (Confirmar Pagamento) permanece o mesmo. 🧠🛡️

🖼️ ATIVIDADE 06: PROTOTIPAGEM E WIREFRAMES

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência visual, trazendo a interface do software para o "mundo real" antes mesmo de escrever a primeira linha de código. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Criar Wireframes (protótipos de baixa fidelidade) focados na funcionalidade, não na estética.
Projetar a Jornada do Usuário (o fluxo lógico de cliques entre as telas).
Validar se os requisitos e casos de uso das aulas anteriores estão visíveis e acessíveis na interface (Usabilidade).

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, você apresentou o Diagrama de Casos de Uso (Atividade 05). O Diretor de Marketing gostou, mas comentou: "Legal, mas como isso vai aparecer na mão do motorista? Vai ser fácil dele clicar com a mão suja ou usando luvas? Onde fica o botão de emergência?".

"Seu desafio como Designer de Interface (UI/UX) é desenhar o 'esqueleto' (Wireframe) das telas principais. Você não precisa de cores bonitas agora, você precisa provar que o fluxo de navegação é intuitivo o suficiente para que um motorista com pressa consiga usar o App sem treinamento."

🧠 Fundamentos: A Teoria Traduzida

A prototipagem é a ferramenta mais barata da engenharia. É muito mais fácil apagar um desenho do que refazer um banco de dados.

Wireframe vs Protótipo de Alta Fidelidade

Wireframe (Esqueleto): Preto e branco, focado no lugar dos botões e campos de texto. Resolve a Usabilidade.
Alta Fidelidade: Cores, logos e imagens reais. Resolve a Estética.

Jornada do Usuário

É o mapa de cliques. Se para fazer um rastreio o motorista precisa clicar em 10 telas diferentes, a sua jornada está ruim. O objetivo é o "Menor Caminho Crítico".

📊 Visualizando a Lógica

[!TIP] Ao desenhar, siga a regra de ouro: "Não me faça pensar". Se o usuário precisar ler um manual para saber onde está o botão de busca, a interface falhou.

flowchart LR
    A["Tela de Login"] --> B["Dashboard Principal"]
    B --> C["Detalhes da Entrega"]
    C --> D["Confirmação / Assinatura"]

📖 Exemplo Guiado

Abaixo, veja como planejar as telas para o aplicativo da TecProExpress.

Passo	Ação de Design	Resultado Esperado
01	Escolher Telas	Login, Lista de Entregas e Câmera (para comprovante).
02	Desenhar Esqueleto	Onde fica o menu? Onde fica o botão "Entregue"?
03	Validar Fluxo	Ao clicar em 'Finalizar', para onde o usuário vai?

📊 Fluxo de Transição e Navegação de Telas (TecProExpress)

flowchart TD
    L["Tela de Login (Entrada de Credenciais)"] -->|Autenticação bem-sucedida| D["Dashboard: Lista de Pedidos"]
    L -->|Falha de Login| E["Alerta: Credenciais Inválidas"]
    E -->|Tentar Novamente| L
    D -->|Selecionar Entrega| DET["Detalhes da Carga"]
    DET -->|Voltar| D
    DET -->|Iniciar Rota| MAP["Navegação no Mapa (GPS)"]
    MAP -->|Chegar ao Destino| CONF["Confirmar Recebimento (Câmera)"]
    CONF -->|Upload de Foto| SUC["Mensagem de Sucesso"]
    SUC --> D

    style L fill:#e1f5fe,stroke:#0288d1
    style D fill:#e8f5e9,stroke:#2e7d32
    style CONF fill:#fffde7,stroke:#fbc02d
    style E fill:#ffebee,stroke:#c62828

🛠️ Estrutura de Validação da Tela

Para cada tela desenhada, responda:

Qual o objetivo desta tela? (Ex: "Fazer o login").
Qual o elemento principal (Call to Action)? (Ex: "Botão Entrar").
Quais requisitos da Atividade 03 estão aqui? (Ex: "RF01 - Login").

🔍 Detalhamento do Processo:

Note que a prototipagem expõe falhas nos requisitos. Se você desenhou um botão de "Esqueci minha senha", mas não escreveu esse requisito na Atividade 03, você acaba de descobrir uma Lacuna de Requisitos. Parabéns, você está fazendo engenharia de verdade!

🛠️ Prática Obrigatória 1: Os Wireframes

Cenário: O projeto semestral da sua equipe.

Defina as 3 telas principais do seu sistema.
Utilizando uma ferramenta (Figma, Balsamiq, Draw.io ou papel e caneta), desenhe os wireframes (esqueletos) dessas 3 telas.
- Foque na disposição dos elementos.
- Use retângulos para botões, "X" em caixas para imagens.
- Proibido usar cores ou fotos nesta etapa.

🏁 Resultado Esperado (Para sua Referência)

Imagens dos 3 esqueletos (PNG/JPG) mostrando a estrutura lógica da interface.

🛠️ Prática Obrigatória 2: O Fluxo de Navegação

Cenário: Conectando os desenhos.

Desenhe setas entre os seus wireframes (ou faça um pequeno diagrama) mostrando como o usuário navega da Tela 1 para a Tela 2 e como ele volta.

🏁 Resultado Esperado (Para sua Referência)

Um diagrama de fluxo de telas (Storyboarding) que prove que o usuário não fica "preso" em nenhuma parte do sistema.

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus desenhos:

Salve o arquivo de documentação com o nome Atividade_06.md e as imagens dos seus wireframes na pasta es-atv-06-prototipagem/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Por que designers experientes fogem de cores e logotipos na primeira reunião de prototipagem com o cliente? (Resposta: Porque se houver uma cor bonita, o cliente vai focar em "Gostei desse azul" e vai esquecer de checar se o botão de "Confirmar Pagamento" realmente existe ou se está no lugar certo). Foque na função primeiro, na forma depois. 🧠🛡️

📐 ATIVIDADE 07: DIAGRAMA DE CLASSES (UML)

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da arquitetura de software, criando o guia mestre para a implementação do código. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Definir Atributos (o que o objeto guarda) e Métodos (o que o objeto faz).
Aplicar modificadores de Visibilidade (Público +, Privado -, Protegido #) baseados no princípio do Encapsulamento.
Modelar Associações e multiplicidade (1:1, 1:N, N:N).
Identificar oportunidades de Herança para otimização de código.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, os protótipos (Atividade 06) foram aprovados! Agora, o time de desenvolvimento backend (Java/C#/Python) precisa saber: "Como os dados serão organizados no código? Quais são as classes e como elas se conectam?".

Se você apenas disser "Cria uma tabela de motorista", o programador pode esquecer de validar se o motorista tem uma CNH válida ou se ele pode ter vários veículos associados a ele.

"Seu desafio é atuar como Arquiteto de Software. Você deve desenhar o Diagrama de Classes, que é o mapa estrutural que diz ao programador exatamente quais variáveis e funções ele deve criar para que o sistema suporte toda a lógica de logística da TecProExpress."

🧠 Fundamentos: A Teoria Traduzida

O Diagrama de Classes mostra a "foto" parada do sistema. Se o software fosse um prédio, o Diagrama de Classes seria a planta estrutural das paredes e colunas.

Anatomia da Classe

Nome: Sempre substantivo e no singular (Ex: Motorista).
Atributos (Dados): O que ele sabe? (Ex: - cnh: String).
Métodos (Ações): O que ele faz? (Ex: + validarDocumento()).

📊 Visualizando a Lógica

[!TIP] Visibilidade: Por padrão, atributos são sempre Privados (-). Isso protege os dados contra alterações acidentais externas. Somente métodos de acesso (Getters/Setters) ou ações explícitas devem ser Públicos (+).

classDiagram
    class Motorista {
        -String nome
        -String cnh
        +validarCnh() bool
    }
    class Veiculo {
        -String placa
        -String modelo
    }
    Motorista "1" -- "*" Veiculo : dirige

📖 Exemplo Guiado

Abaixo, veja como mapear as entidades da TecProExpress para classes UML.

Passo	Pergunta do Arquiteto	Tradução UML
01	O que um 'Pacote' tem?	Atributos: `-id`, `-peso`, `-status`.
02	O que o 'Pacote' faz?	Métodos: `+calcularFrete()`, `+atualizarStatus()`.
03	Como ele se conecta?	Um Motorista leva Muitos Pacotes (1:N).

📊 Graus de Acoplamento e Relacionamentos entre Classes

flowchart LR
    A["Associação Simples<br/>(Uso comum - Acoplamento fraco)"] -->|Motorista - Veiculo| B["Ex: Um motorista dirige um veículo"]
    C["Agregação<br/>(Todo/Parte - Partes vivem sem o todo)"] -->|Pedido - Cliente| D["Ex: Cliente possui pedidos, mas cliente existe sem o pedido"]
    E["Composição<br/>(Todo/Parte rígido - Partes morrem com o todo)"] -->|Pedido - ItemPedido| F["Ex: Pedido possui itens de pedido, se o pedido morre, itens morrem"]

    style A fill:#eceff1,stroke:#607d8b
    style C fill:#e1f5fe,stroke:#0288d1
    style E fill:#ffebee,stroke:#c62828

🛠️ Estrutura de Atributo e Método

Atributo: - salario: Double = 1412.00
- -: Privado.
- salario: Nome.
- Double: Tipo do dado.
- = 1412.00: Valor padrão.
Método: + calcularIdade(dataNasc: Date): Int
- +: Público.
- dataNasc: Date: Parâmetro de entrada.
- : Int: O que o método devolve (Tipo de retorno).

🔍 Detalhamento do Processo:

Note que no Diagrama de Classes não colocamos "clicar no botão". Colocamos a lógica do objeto. Se o botão na tela chama uma função de salvar, o método salvar() deve estar na Classe.

🛠️ Prática Obrigatória 1: O Diagrama de Classes

Cenário: O projeto semestral da sua equipe.

Identifique as 5 principais entidades do seu sistema (ex: Usuário, Produto, Pedido, Categoria, Endereço).
Utilizando uma ferramenta UML (Astah, Lucidchart ou Draw.io), desenhe o diagrama.
Cada classe deve conter pelo menos 3 atributos e 2 métodos.
Defina as multiplicidades corretamente (ex: Um cliente tem 0 ou N pedidos).

🏁 Resultado Esperado (Para sua Referência)

Uma imagem (PNG/JPG) do diagrama contendo as 5 classes conectadas, com tipos de dados e visibilidade (+ e -) aplicados.

🛠️ Prática Obrigatória 2: Justificativa de Visibilidade

Cenário: Proteção de dados (Encapsulamento).

Escolha uma classe do seu diagrama.
Explique por que você definiu um determinado atributo como Privado (-) e como o sistema fará para ler ou alterar esse dado com segurança.

🏁 Resultado Esperado (Para sua Referência)

Um pequeno texto em Markdown justificando a escolha técnica do encapsulamento na sua modelagem.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas documentações técnicas:

Salve o arquivo de documentação com o nome Atividade_07.md e a imagem do seu diagrama de classes com o nome Atividade_07.png na pasta es-atv-07-classes/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se você tem uma classe Funcionario e uma classe Gerente, e percebe que ambas têm os atributos nome, cpf e telefone, qual conceito de Orientação a Objetos você aplicaria para não precisar repetir esse código duas vezes? (Resposta: Herança. Você criaria uma classe pai 'Pessoa' e as outras herdariam dela). 🧠🛡️

🎬 ATIVIDADE 08: DIAGRAMA DE SEQUÊNCIA (UML)

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da dinâmica de software, entendendo como o sistema "conversa" internamente. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Modelar o fluxo temporal de uma funcionalidade específica (Diferente da Classes, que é estático).
Identificar Linhas de Vida (Lifelines) de objetos e atores.
Representar Mensagens Síncronas, Assíncronas e Respostas.
Visualizar a interação entre as camadas do sistema (Interface, Lógica e Banco de Dados).

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, você definiu as Classes (Atividade 07). Agora, os desenvolvedores de Frontend e Backend precisam sentar para combinar como as mensagens serão trocadas. O programador da tela pergunta: "Quando eu clicar em 'Confirmar Entrega', para quem eu mando o sinal? Quem valida se o motorista está no local certo? Quem avisa o banco de dados para salvar?".

"Seu desafio como Analista de Sistemas é desenhar o 'filme' dessa ação. Você deve criar o Diagrama de Sequência que mostra o passo a passo temporal: da tela para o servidor, do servidor para o banco, e a resposta voltando para o celular do motorista."

🧠 Fundamentos: A Teoria Traduzida

Se o Diagrama de Classes é a foto das peças de um tabuleiro de xadrez, o Diagrama de Sequência é a descrição de uma jogada específica.

Elementos Chaves

Atores e Objetos: Ficam no topo. De cada um desce uma Linha de Vida (tracejada).
Foco de Controle (Retângulo na linha): Indica que o objeto está "trabalhando" naquele momento.
Seta Contínua: Chamada de método (pergunta/ordem).
Seta Tracejada: Retorno (resposta).

📊 Visualizando a Lógica

[!TIP] A ordem importa! No Diagrama de Sequência, o tempo flui de cima para baixo. A primeira mensagem do topo é a primeira coisa que acontece no sistema.

sequenceDiagram
    participant M as Motorista
    participant T as Tela App
    participant S as Servidor API
    participant B as Banco de Dados

    M->>T: Clica em "Finalizar"
    T->>S: validarLocalizacao(gps)
    S->>B: salvarStatus("Entregue")
    B-->>S: OK (Sucesso)
    S-->>T: Exibir Mensagem Sucesso
    T-->>M: Notificação na Tela

📖 Exemplo Guiado

Abaixo, veja como planejar a sequência do "Login" no sistema da TecProExpress.

Ordem	Quem fala com quem?	O que é dito?
1	Usuário -> Tela	Digita usuário/senha e clica em Entrar.
2	Tela -> Servidor	`autenticar(user, pass)`
3	Servidor -> Banco	`SELECT * FROM usuarios...`
4	Banco -> Servidor	Retorna os dados do usuário.
5	Servidor -> Tela	Login Autorizado.

📊 Dinâmica de Chamadas e Foco de Controle

sequenceDiagram
    autonumber
    actor U as Usuário
    participant T as Tela Login
    participant S as Servidor Auth
    
    U->>T: Digita credenciais e clica em Entrar
    activate T
    T->>S: POST /login (payload JSON)
    activate S
    Note over S: Autentica credenciais e gera JWT
    S-->>T: 200 OK (Token JWT)
    deactivate S
    T-->>U: Redireciona para o Dashboard
    deactivate T

🛠️ Regras de Ouro do Diagrama

Objetos nunca falam sozinhos: Uma mensagem sempre sai de uma linha de vida e vai para outra.
Use verbos de ação: As setas representam chamadas de funções que você definiu lá na Atividade 07.
Mantenha o foco: Não tente colocar 50 telas no mesmo diagrama. Escolha um fluxo (ex: Realizar Compra) e desenhe apenas ele.

🔍 Detalhamento do Processo:

O Diagrama de Sequência é o melhor lugar para descobrir bugs de lógica. Se você desenhou que a "Tela" fala direto com o "Banco de Dados", você descobriu uma falha de segurança! Na engenharia profissional, a Tela sempre fala com o Servidor, e o Servidor fala com o Banco.

🛠️ Prática Obrigatória: Modelando a Jogada

Cenário: A funcionalidade principal do seu projeto semestral.

Escolha o fluxo mais importante do seu sistema (ex: Cadastrar Cliente, Realizar Venda, Agendar Horário).
Identifique pelo menos 3 participantes (ex: Ator, Tela, Banco de Dados).
Desenhe o Diagrama de Sequência mostrando o fluxo completo, desde a ação do usuário até a resposta final de sucesso.
Certifique-se de usar setas contínuas para chamadas e tracejadas para retornos.

🏁 Resultado Esperado (Para sua Referência)

Uma imagem (PNG/JPG) do diagrama de sequência limpo e lógico, descrevendo a dinâmica temporal da sua principal regra de negócio.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas documentações técnicas:

Salve o arquivo de documentação com o nome Atividade_08.md e a imagem do seu diagrama de sequência com o nome Atividade_08.png na pasta es-atv-08-sequencia/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se durante o desenho do Diagrama de Sequência você perceber que precisa chamar um método chamado verificarEstoque(), mas esse método não existe na classe Estoque lá na sua Atividade 07, o que você deve fazer? (Resposta: Voltar na Atividade 07 e atualizar o Diagrama de Classes. A modelagem é um processo vivo e as atividades devem estar sempre sincronizadas). 🧠🛡️

🧪 ATIVIDADE 09: QUALIDADE E TESTES DE SOFTWARE

Bem-vindo a mais uma etapa da sua jornada no curso de Gestão de TI / Desenvolvimento de Sistemas. Hoje vamos mergulhar em conceitos que conectam a teoria técnica diretamente com o padrão de excelência da qualidade, garantindo que o software seja robusto e confiável antes de chegar ao cliente final. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Diferenciar Verificação (Estamos construindo o produto certo?) de Validação (Estamos construindo o produto corretamente?).
Redigir Casos de Teste (Test Cases) com passo a passo e resultados esperados.
Aplicar a técnica de Teste de Caixa Preta (Black-Box), focando em testes positivos e negativos.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, os desenvolvedores terminaram o "App de Rastreamento". No entanto, no primeiro dia de uso, um motorista tentou digitar o número da placa e o sistema travou porque ele usou letras minúsculas. O cliente tentou rastrear um pedido inexistente e o App exibiu uma tela de erro técnica (código 500) em vez de uma mensagem amigável.

O custo de imagem da empresa foi lá embaixo.

"Seu desafio como Analista de QA (Quality Assurance) é criar um Plano de Testes. Você deve antecipar o erro humano e criar roteiros que garantam que, mesmo que o usuário faça 'bobagem', o sistema se comporte de forma segura e elegante."

🧠 Fundamentos: A Teoria Traduzida

Testar software não é apenas "clicar para ver se funciona". É tentar provar que o sistema falha.

O Caso de Teste (Test Case)

Um caso de teste é um experimento científico controlado. Ele tem:

Ação: O que eu faço? (Ex: Digito a senha errada).
Resultado Esperado: O que deve acontecer? (Ex: Mensagem de erro "Senha inválida").

Testes Positivos vs Negativos

Positivo: O usuário faz tudo certo. (Ex: Login com dados corretos).
Negativo: O usuário faz tudo errado ou tenta "quebrar" o sistema. (Ex: Colocar letras no campo de 'Quantidade' ou deixar campos obrigatórios vazios).

📊 Visualizando a Lógica

[!TIP] Um bom QA não testa apenas o que o sistema faz, mas o que o sistema NÃO DEVE fazer.

flowchart LR
    A[Entrada de Dados] --> B{Filtro de Teste}
    B -- "Dados Válidos" --> C[Sucesso]
    B -- "Dados Inválidos" --> D[Tratamento de Erro Amigável]

📖 Exemplo Guiado

Abaixo, veja como estruturar um Caso de Teste para o login da TecProExpress.

ID	Título do Teste	Ação do Usuário	Resultado Esperado
CT01	Login Vazio	Clica em 'Entrar' sem digitar nada.	O sistema deve exibir "Campos Obrigatórios".
CT02	Formato CPF	Digita CPF sem pontos e traços.	O sistema deve formatar e aceitar o login.

📊 A Pirâmide de Testes da Engenharia Profissional

flowchart TD
    subgraph P [Níveis de Cobertura e Esforço]
        direction BT
        E2E["Testes de Interface / Ponta a Ponta (E2E)<br/>(Lentos / Altamente Frágeis / Cobertura Focada)"]
        INT["Testes de Integração<br/>(Médio esforço / Valida comunicações entre APIs)"]
        UNI["Testes de Unidade (JUnit)<br/>(Ultra rápidos / Baratos / Cobertura massiva)"]
        UNI --> INT --> E2E
    end
    style UNI fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style INT fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style E2E fill:#fffde7,stroke:#fbc02d,stroke-width:2px

🛠️ Estrutura do Roteiro de Teste

# CT03: Teste de Upload de Comprovante

**Objetivo:** Validar se o sistema aceita apenas imagens de comprovantes.
**Pré-condição:** Estar na tela de finalização de entrega.
**Passos:**
1. Clicar no botão "Anexar Foto".
2. Tentar selecionar um arquivo do tipo ".PDF".
3. Clicar em "Confirmar".

**Resultado Esperado:** O sistema deve bloquear a seleção do PDF e exibir o erro "Formato não permitido. Use JPG ou PNG".

🔍 Detalhamento do Processo:

Note que o roteiro é tão detalhado que qualquer pessoa (mesmo quem não conhece o sistema) conseguiria executá-lo. Isso permite a Reprodutibilidade do Erro.

🛠️ Prática Obrigatória 1: Tabela de Casos de Teste

Cenário: O projeto semestral da sua equipe.

Escolha 3 Requisitos Funcionais da sua Atividade 03.
Para cada requisito, crie 2 Casos de Teste (um positivo e um negativo).
Organize-os em uma tabela contendo: ID, Título, Ação e Resultado Esperado.

🏁 Resultado Esperado (Para sua Referência)

Uma tabela com 6 roteiros de teste (3 pares) que cubram as funcionalidades críticas do seu sistema.

🛠️ Prática Obrigatória 2: O Teste de Caixa Preta

Cenário: Antecipando falhas críticas.

Identifique uma funcionalidade do seu sistema que envolva cálculos ou datas (ex: Data de entrega, Valor total, Idade do usuário).
Descreva um cenário de Teste Negativo complexo (ex: o que acontece se eu colocar uma data de nascimento no futuro?).

🏁 Resultado Esperado (Para sua Referência)

Um parágrafo descrevendo o cenário e como o sistema deveria "se defender" desse erro de entrada.

📤 Instruções de Entrega (Microsoft Teams)

Após validar seus roteiros de teste:

Salve o arquivo de documentação com o nome Atividade_09.md na pasta es-atv-09-testes/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: O que é mais caro para uma empresa: encontrar um erro durante a fase de Requisitos (Atividade 03) ou encontrar esse mesmo erro depois que o software já foi entregue para 10.000 clientes? (Resposta: Depois da entrega. O custo de correção no mercado pode ser até 100x maior devido a recalls, suporte e perda de reputação). 🧠🛡️

🏆 ATIVIDADE 10: PROJETO INTEGRADOR FINAL

Bem-vindo ao grande encerramento do seu módulo de Engenharia de Software. Ao longo deste semestre, você não apenas aprendeu teoria, você construiu um ativo intelectual. Hoje, você consolidará todas as etapas em um único documento de padrão internacional: o ERS (Especificação de Requisitos de Software). 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você terá em mãos um portfólio técnico que prova sua capacidade de:

Organizar um projeto de software do escopo à garantia de qualidade.
Integrar diagramas UML com regras de negócio e jornadas de usuário.
Apresentar um documento técnico polido, profissional e pronto para ser entregue a uma equipe de desenvolvimento real.

🏢 O Cenário Prático (Seu Desafio)

A diretoria da TecProExpress está impressionada com o seu trabalho. Eles decidiram que o seu "App de Rastreamento" receberá o investimento necessário para ser construído por uma fábrica de software externa. No entanto, para liberar a verba, a fábrica exige o Documento de Especificação (ERS) completo.

Sem este documento, os desenvolvedores externos vão cobrar por hora para tentar adivinhar o que você quer. Com este documento, eles terão um roteiro exato para seguir.

"Seu desafio final é reunir todas as peças do quebra-cabeça que você construiu (Atividades 01 a 09), revisar as falhas e entregar o dossiê final do projeto. Este documento será a prova da sua maturidade como futuro gestor ou desenvolvedor de TI."

🧠 Fundamentos: O Poder da Documentação Consolidada

Um bom ERS é o "Contrato" entre quem paga e quem faz. Se algo não está no ERS, o desenvolvedor não é obrigado a fazer. Se algo está lá e o desenvolvedor não fez, o cliente tem o direito de reclamar.

Estrutura do Dossiê Profissional (Checklist)

Capa e Introdução: Nome do sistema e visão do problema.
Definições de Negócio: Personas e Escopo (In/Out).
Processo: Justificativa da metodologia Ágil escolhida.
Requisitos: As tabelas de RFs e RNFs priorizados.
Documentação Ágil: User Stories e Critérios de Aceite.
Modelagem Visual: Casos de Uso, Classes e Sequência.
Interface: Wireframes das telas principais.
Qualidade: Casos de Teste.

📊 Visualizando a Integração

[!TIP] A consistência é a chave. Se o seu Requisito RF01 diz "Login", seu Diagrama de Casos de Uso deve ter um oval "Fazer Login", sua Classe deve ter um método autenticar() e sua interface deve ter uma "Tela de Login".

graph TD
    R[Requisitos] --> U[UML]
    U --> I[Interface]
    I --> T[Testes]
    T --> ERS(("ERS Final"))

📖 Exemplo Guiado: A Revisão Final

Antes de fechar o documento, o Engenheiro Sênior faz um "Double Check".

Artefato	O que conferir?	Status
Requisitos	Os IDs (RF01, RF02) estão batendo com as User Stories?	✅
Classes	O método que eu usei no Diagrama de Sequência existe na Classe?	✅
Protótipo	A tela de login tem campos para o CPF que eu exigi no requisito?	✅

📊 Pipeline de Consolidação e Revisão da Documentação ERS

flowchart TD
    A["Entrada 1: Requisitos (Atv 03, 04)"] --> R{"Revisão de Consistência"}
    B["Entrada 2: UML (Atv 05, 07, 08)"] --> R
    C["Entrada 3: Protótipos & Testes (Atv 06, 09)"] --> R
    R -->|OK| D["Documento ERS Consolidado (Atv 10)"]
    R -->|Inconsistência Detectada| E["Ajustes de Modelagem"]
    E --> R

    style R fill:#fffde7,stroke:#fbc02d,stroke-width:2px
    style D fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

🛠️ Prática Obrigatória: A Consolidação do ERS

Cenário: A entrega oficial para a diretoria da TecProExpress.

Unificação: Reúna todos os artefatos produzidos nas atividades 01 a 09 em um único arquivo (Markdown no GitHub ou um PDF profissional).
Refatoração: Aplique as correções sugeridas pelo professor ao longo do semestre. (Ex: se seu diagrama de classes estava errado na Atv 07, entregue-o corrigido agora).
Sumário: Crie um índice para facilitar a navegação no documento.
Conclusão: Escreva um parágrafo final descrevendo as lições aprendidas durante a modelagem deste projeto.

🏁 Resultado Esperado (Para sua Referência)

Um Documento de Especificação de Requisitos (ERS) de 10 a 15 páginas, organizado, com imagens nítidas e textos revisados. Este é o seu Trabalho de Conclusão do Módulo.

📤 Instruções de Entrega (Microsoft Teams)

Após validar o seu dossiê completo:

Salve o arquivo de documentação com o nome Atividade_10.md na pasta es-atv-10-projeto-final/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Você se sente mais confiante para gerir um time de desenvolvimento agora que sabe como especificar cada detalhe técnico antes de gastar dinheiro com programação? O que você diria para um cliente que diz: "Não precisamos de documentação, vamos apenas começar a codar"? (Resposta: "Codar sem documentação é como construir um prédio sem planta: no começo é rápido, mas no final as janelas não abrem e o teto cai"). 🧠🛡️

🔥 Desafio de Fixação (Opcional)

Nível: Black Belt 🥋

Adicione ao final do seu documento uma seção de Análise de Riscos. Liste 3 coisas que podem dar errado no desenvolvimento deste sistema (ex: falta de internet nos caminhões, resistência dos motoristas em usar o app) e como você, como Engenheiro de Software, mitigaria esses riscos.

🌿 ATIVIDADE 11: DIAGRAMA DE ATIVIDADES (UML)

Bem-vindo ao início do Bloco Avançado de Engenharia de Software. Ao longo das próximas semanas, você sairá da modelagem puramente estática e entrará de cabeça na lógica processual, no design de APIs modernas, no ecossistema corporativo (Java 17, Spring Boot 3.5.x, Thymeleaf, HTMX) e nas práticas de DevOps. Hoje, seu desafio é modelar o fluxo procedural dinâmico usando o Diagrama de Atividades. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Modelar a lógica processual e fluxos de negócio usando a sintaxe UML.
Representar bifurcações e junções lógicas (decisões lógicas).
Representar forks e joins para fluxos de processamento em paralelo.
Organizar responsabilidades usando Raias de Natação (Swimlanes / Subgraphs).

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, a diretoria de Logística percebeu um grande gargalo: quando um cliente clica em "Confirmar Compra", o sistema antigo esperava o faturamento da Nota Fiscal terminar para somente depois avisar o estoque. Em dias de grande volume, os motoristas ficavam parados esperando a emissão da nota, mesmo com a carga já pronta para carregar!

"Seu desafio como Analista de Processos de TI é desenhar o fluxo de atividades de faturamento e separação de forma paralela. Você deve modelar o processo de ponta a ponta: do clique do usuário, dividindo a ação em duas linhas paralelas (Faturamento e Separação), juntando-as no carregamento e finalizando com a saída do caminhão."

🧠 Fundamentos: A Teoria Traduzida

O Diagrama de Atividades UML é como um super fluxograma. Ele descreve a ordem em que as atividades de um sistema ou processo ocorrem, com excelente suporte para paralelismo.

Elementos Chave:

Nó Inicial (Círculo Preto Sólido): Onde o processo começa.
Ação/Atividade (Retângulo Arredondado): Um passo procedural executado pelo sistema ou humano.
Fork (Barra de Divisão): Divide uma linha em duas ou mais ações que acontecem em paralelo.
Join (Barra de Sincronização): Aguarda todas as linhas paralelas terminarem para continuar o fluxo.
Decisão (Losango): Uma bifurcação baseada em uma pergunta do tipo Sim/Não.
Nó Final (Círculo com Alvo): Onde o processo termina.

📊 Visualizando a Lógica

[!TIP] Fork vs Decisão: A decisão escolhe apenas um caminho. O Fork aciona todos os caminhos ao mesmo tempo. Nunca confunda as duas coisas!

flowchart TD
    Start(["Início"]) --> Fork{{"Fork (Paralelizar)"}}
    Fork --> A[Emissão de Nota Fiscal]
    Fork --> B[Separação Física dos Itens]
    A --> Join{{"Join (Aguardar Ambos)"}}
    B --> Join
    Join --> End(["Pronto para Envio"])

    style Start fill:#eceff1,stroke:#607d8b
    style Fork fill:#e1f5fe,stroke:#0288d1
    style Join fill:#e1f5fe,stroke:#0288d1
    style End fill:#e0f2f1,stroke:#004d40

📖 Exemplo Guiado

Abaixo, veja como detalhar o processamento com raias de natação (separando as responsabilidades entre Cliente, Financeiro e Logística).

Elemento UML	O que representa?	Ator/Componente Responsável
Iniciar Compra	Nó Inicial	Cliente
Faturar Cartão	Ação	Financeiro (Gateway)
Separar Caixas	Ação	Logística (Operador)
Despachar Caminhão	Ação	Transportadora

🛠️ Estrutura Visual da Expedição

Para facilitar a leitura profissional, dividimos o fluxo usando Raias de Natação (subgraphs no Mermaid):

flowchart TD
    subgraph CLI [Cliente]
        Start(["Compra Efetuada"]) --> Fork{{"Fork"}}
    end

    subgraph FIN [Financeiro]
        Fork --> F1[Emitir Nota Fiscal]
        F1 --> F2[Registrar Impostos]
    end

    subgraph LOG [Logística]
        Fork --> L1[Separar Produtos no Galpão]
        L1 --> L2[Embalar Carga]
    end

    subgraph TRA [Transportadora]
        F2 --> Join{{"Join"}}
        L2 --> Join
        Join --> T1[Carregar Caminhão]
        T1 --> End(["Caminhão Despachado"])
    end

    style Start fill:#eceff1,stroke:#333
    style End fill:#e0f2f1,stroke:#004d40
    style FIN fill:#fffde7,stroke:#fbc02d,stroke-width:1px
    style LOG fill:#e1f5fe,stroke:#0288d1,stroke-width:1px
    style TRA fill:#e8f5e9,stroke:#2e7d32,stroke-width:1px

🔍 Detalhamento do Processo:

A raia de natação deixa evidente quem faz o quê. Se o Financeiro falhar ao registrar impostos, o Join bloqueia o carregamento do caminhão na Transportadora, mesmo que a Logística já tenha embalado tudo!

🛠️ Prática Obrigatória 1: O Diagrama de Atividades

Cenário: O projeto de grupo semestral que você está desenvolvendo.

Selecione a funcionalidade principal ou a jornada de maior complexidade do seu sistema (Ex: Devolução de Mercadorias, Cadastro e Aprovação de Motoristas, Compra com Vários Modos de Pagamento).
Identifique pelo menos 3 raias de responsabilidade (Humanos ou Sistemas/Componentes).
Insira pelo menos 1 Fork e 1 Join para representar ações executadas em paralelo.
Insira pelo menos 1 Decisão com caminhos alternativos de erro ou validação.

🏁 Resultado Esperado (Para sua Referência)

Uma imagem (PNG/JPG) do diagrama de atividades estruturado de forma limpa, indicando claramente os caminhos paralelos e as fronteiras de responsabilidade.

🛠️ Prática Obrigatória 2: Justificativa de Paralelismo

Cenário: Defesa arquitetural do processo.

Escreva uma breve justificativa de 1 parágrafo explicando por que você decidiu paralelizar as ações mapeadas na Prática 1.
Explique o que aconteceria se esse processo fosse executado de forma estritamente sequencial (Cascata procedural) em termos de performance e satisfação do usuário.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas modelagens técnicas:

Salve o arquivo de justificativa como Atividade_11.md e a imagem do seu diagrama com o nome Atividade_11.png na pasta es-atv-11-atividades/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: O que acontece com o fluxo de atividades se uma das ramificações que saem de um Fork entrar em um loop infinito ou falhar e nunca alcançar o Join? (Resposta: O Join travará o processo para sempre, pois ele exige por especificação matemática que todas as ramificações paralelas cheguem até ele para liberar o fluxo sequencial subsequente). 🧠🛡️

🔄 ATIVIDADE 12: DIAGRAMA DE MÁQUINA DE ESTADOS (UML)

Bem-vindo a mais uma etapa prática do seu treinamento em Engenharia de Software. Na atividade anterior, você aprendeu sobre processos e fluxos lógicos. Hoje, nosso foco muda para o ciclo de vida de uma entidade do sistema. Você aprenderá como modelar os Estados pelos quais um dado transiciona, garantindo que o software nunca entre em inconsistência lógica. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Identificar entidades de negócio com ciclos de vida complexos.
Modelar os Estados estáveis de um objeto no sistema.
Mapear Eventos Gatilho (Triggers) que provocam a transição entre estados.
Aplicar Condições de Guarda (Guards) para proteção lógica contra transições inválidas.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, tivemos um incidente grave de banco de dados: um cliente de suporte ligou reclamando que a sua entrega apareceu no sistema como "Entregue com Sucesso", mas o motorista ainda nem havia saído com o caminhão do centro de distribuição!

Ao analisar o código, a equipe técnica descobriu que não havia validação de regras de negócios. Um motorista distraído clicou no botão "Confirmar Entrega" na tela errada de um pacote que ainda estava no estado de triagem físico!

"Seu desafio como Arquiteto de Software é desenhar o Diagrama de Máquina de Estados para a entidade Entrega. Você deve blindar o sistema, definindo as regras exatas de como um pacote muda de estado (ex: de Pendente para Em Rota) e quais validações (guardas) impedem que um pacote seja marcado como Entregue antes de ser despachado."

🧠 Fundamentos: A Teoria Traduzida

Enquanto o Diagrama de Atividades mostra o fluxo das ações de um processo, o Diagrama de Máquina de Estados foca em um único objeto do início ao fim da sua existência.

Elementos Chave:

Estado Inicial (Círculo Preto): O ponto de criação do objeto.
Estado (Retângulo Arredondado): Uma condição estável na vida do objeto onde ele aguarda um evento (Ex: PENDENTE, EM_ROTA, ENTREGUE).
Transição (Seta Direcionada): A mudança de um estado para o outro.
Evento Gatilho (Trigger): A ação que dispara a transição (Ex: despacharPacote()).
Condição de Guarda (Guard - entre colchetes [...]): Uma regra que precisa ser verdadeira para a transição acontecer. (Ex: [motorista_no_local == true]).

📊 Visualizando a Lógica

[!TIP] Condição Guarda: Pense na guarda como um segurança de boate. A transição quer acontecer, mas o segurança impede se a condição não for atendida!

stateDiagram-v2
    [*] --> PENDENTE : cadastrarPedido()
    PENDENTE --> EM_ROTA : despachar() [caminhao_carregado == true]
    EM_ROTA --> ENTREGUE : finalizar() [foto_comprovante_anexada == true]
    EM_ROTA --> TENTATIVA_FALHA : motoristaAusente()
    TENTATIVA_FALHA --> EM_ROTA : redirecionar()
    ENTREGUE --> [*]

📖 Exemplo Guiado

Abaixo, veja o mapeamento de transição para o ciclo de vida do pacote da TecProExpress.

Estado Origem	Evento Gatilho	Condição Guarda	Estado Destino
`PENDENTE`	`despachar()`	`[motorista_associado != null]`	`EM_ROTA`
`EM_ROTA`	`confirmarEntrega()`	`[distancia_gps_cliente < 100m]`	`ENTREGUE`
`EM_ROTA`	`cancelarPedido()`	`[motivo != null]`	`CANCELADO`

🛠️ Regra UML em Sintaxe Padrão:

A sintaxe formal gravada na seta da transição segue o padrão: Evento [Guarda] / Ação executada

Exemplo: confirmarEntrega [comprovanteAnexado] / notificarCliente()

stateDiagram-v2
    state "Pendente de Coleta" as P
    state "Em Rota de Entrega" as ER
    state "Cancelado" as C
    state "Entregue" as E

    [*] --> P
    P --> ER : atribuirMotorista [motorista_ativo == true]
    ER --> E : confirmarEntrega [gps_ok == true] / enviarSMS()
    ER --> C : cancelar [cliente_solicitou] / estornarCartao()
    C --> [*]
    E --> [*]

🔍 Detalhamento do Processo:

Note a guarda [gps_ok == true]. Se o aplicativo do motorista não coletar a coordenada geográfica a menos de 100 metros da casa do cliente, o sistema bloqueia a mudança para o estado Entregue, evitando fraudes ou cliques acidentais!

🛠️ Prática Obrigatória 1: A Máquina de Estados

Cenário: O projeto semestral da sua equipe.

Selecione a entidade mais crítica do seu sistema que possui vários status (Ex: Pedido em um e-commerce, Agendamento em uma clínica, Vaga em um estacionamento).
Mapeie pelo menos 4 estados distintos para essa entidade.
Defina claramente os Eventos Gatilho em cada seta de transição.
Adicione pelo menos 2 Condições de Guarda entre colchetes [...] para blindar transições perigosas.

🏁 Resultado Esperado (Para sua Referência)

Uma imagem (PNG/JPG) do diagrama de máquina de estados UML modelado de forma organizada, exibindo a trajetória completa da entidade do estado inicial ao final.

🛠️ Prática Obrigatória 2: Tabela de Transições Lógicas

Cenário: Detalhamento da lógica de negócios.

Crie uma tabela com 4 colunas: Estado Origem, Evento Gatilho, Condição de Guarda e Estado Destino.
Preencha as linhas detalhando as regras lógicas que você desenhou no diagrama da Prática 1.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas documentações técnicas de estados:

Salve o arquivo de tabela com o nome Atividade_12.md e a imagem do seu diagrama com o nome Atividade_12.png na pasta es-atv-12-estados/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: O que diferencia, na modelagem profissional, um Estado de uma Atividade? (Resposta: Um Estado representa uma situação de estabilidade temporária onde o objeto está aguardando passivamente um evento externo para mudar. Uma Atividade é uma ação ativa, de execução procedural contínua e computacional direta, que transiciona automaticamente para o próximo passo assim que termina). 🧠🛡️

🏛️ ATIVIDADE 13: ARQUITETURA DE SOFTWARE E PADRÕES

Bem-vindo a mais uma etapa do seu desenvolvimento técnico! Agora que você domina a modelagem de processos e dados, daremos o passo mais importante para quem quer se tornar um desenvolvedor sênior ou gestor técnico: projetar a arquitetura interna do software. Hoje, aprenderemos a organizar sistemas profissionais em camadas usando o padrão MVC (Model-View-Controller) corporativo com Java 17, Spring Boot 3.5.x, Thymeleaf e HTMX, além de aplicar o padrão de projeto criacional Factory. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Diferenciar monólitos, camadas MVC e arquiteturas desacopladas modernas.
Projetar o fluxo de dados entre Controller, Service e Repository do Spring Boot.
Compreender o uso do Thymeleaf + HTMX para gerar interfaces reativas sem o peso de frameworks complexos de SPA.
Aplicar o padrão de projeto Factory para criação desacoplada de objetos de negócio.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, a equipe de desenvolvimento estava sofrendo: toda vez que precisavam mudar o banco de dados de MySQL para PostgreSQL, tinham que reescrever a validação de rotas, o cálculo do frete e as telas do aplicativo! Tudo estava tão bagunçado e misturado (acoplado) que um erro de digitação no botão da tela derrubava o cálculo do financeiro!

"Seu desafio como Arquiteto de Software é reorganizar a plataforma. Você desenhará a estrutura do sistema em camadas estritas e isoladas no Spring Boot. Além disso, os motoristas exigem notificações de novas rotas via SMS, e-mail ou push móvel. Você implementará o padrão Factory para que o sistema escolha o tipo correto de envio de notificação sem acoplar a lógica de entrega."

🧠 Fundamentos: A Teoria Traduzida

Para que um sistema sobreviva a anos de manutenção, ele deve ser desacoplado (cada peça cuida de apenas um assunto).

A Estrutura em Camadas (Spring Boot)

View / Interface (Thymeleaf + HTMX): Renderiza o HTML dinâmico no servidor com Thymeleaf e realiza requisições parciais assíncronas com HTMX, mantendo o carregamento rápido e leve.
Controller (Camada de Apresentação): Recebe os cliques (requisições HTTP), extrai dados do formulário e chama a lógica. Ele nunca calcula regras de negócio!
Service (Camada de Negócio): Onde as regras morrem. É o "cérebro" do sistema (Ex: calcula desconto, valida se o motorista está ativo).
Repository / DAO (Camada de Dados): Onde ocorrem as queries SQL (SELECT, INSERT), salvando e buscando os dados no banco de dados.

📊 Visualizando a Lógica MVC + Camadas

flowchart TD
    Browser["Navegador (HTML + HTMX)"] -->|1. Requisição HTTP| Controller["Controller (Spring MVC)"]
    Controller -->|2. Valida & Encaminha| Service["Service (Regras de Negócio)"]
    Service -->|3. Consulta Dados| Repository["Repository (Acesso ao Banco)"]
    Repository -->|4. Retorna Entidades| Service
    Service -->|5. Retorna Resultados| Controller
    Controller -->|6. Renderiza Thymeleaf| Browser

    style Browser fill:#eceff1,stroke:#607d8b,stroke-width:2px
    style Controller fill:#fffde7,stroke:#fbc02d,stroke-width:2px
    style Service fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style Repository fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

📖 Exemplo Guiado: O Padrão Factory (Notificações)

Quando uma nova rota é atribuída, precisamos despachar um alerta ao entregador. Mas não queremos acoplar as classes SmsNotification, EmailNotification e PushNotification no código principal. Usaremos a NotificationFactory.

// 1. Interface comum de Notificação
public interface Notification {
    void send(String message, String target);
}

// 2. Implementações específicas
public class SmsNotification implements Notification {
    public void send(String message, String target) {
        System.out.println("Disparando SMS para " + target + ": " + message);
    }
}

public class EmailNotification implements Notification {
    public void send(String message, String target) {
        System.out.println("Enviando E-mail para " + target + ": " + message);
    }
}

// 3. A Fábrica (Factory) que desacopla a criação
public class NotificationFactory {
    public static Notification createNotification(String type) {
        if (type == null) return null;
        if (type.equalsIgnoreCase("SMS")) return new SmsNotification();
        if (type.equalsIgnoreCase("EMAIL")) return new EmailNotification();
        throw new IllegalArgumentException("Tipo de notificação desconhecido: " + type);
    }
}

🛠️ Código do Service utilizando a Factory no Spring Boot:

@Service
public class DeliveryService {
    
    @Autowired
    private DeliveryRepository repository;

    public void processarEntrega(Long deliveryId, String notificationType) {
        // Busca a entrega no banco
        Delivery delivery = repository.findById(deliveryId)
            .orElseThrow(() -> new RuntimeException("Entrega não encontrada"));

        // Lógica de Negócio: Atualiza status
        delivery.setStatus("EM_ROTA");
        repository.save(delivery);

        // Uso do Padrão Factory para enviar notificação sem acoplamento
        Notification notification = NotificationFactory.createNotification(notificationType);
        notification.send("Sua entrega está em rota!", delivery.getMotoristaContato());
    }
}

🔍 Detalhamento do Processo:

Se amanhã o diretor da TecProExpress exigir o envio de notificações por WhatsApp, basta criar a classe WhatsAppNotification e adicioná-la dentro da NotificationFactory. O arquivo DeliveryService continuará intacto, provando que nosso sistema atende ao Princípio do Aberto/Fechado (OCP) do SOLID! 🚀

🛠️ Prática Obrigatória 1: Desenho Arquitetural

Cenário: O projeto semestral da sua equipe.

Desenhe um diagrama flowchart no Mermaid representando a arquitetura em camadas do seu projeto de grupo.
Mapeie e rotule as caixas indicando onde ficará a sua Interface (Thymeleaf/HTMX), seus Controllers, seus Services (Regras de Negócio) e seus Repositories.
Garanta que a camada de interface fale exclusivamente com o Controller, e o Controller fale exclusivamente com o Service.

🏁 Resultado Esperado (Para sua Referência)

Um diagrama de arquitetura de camadas profissional documentado em formato Mermaid no corpo do seu arquivo Markdown de entrega.

🛠️ Prática Obrigatória 2: Modelando o Padrão Factory

Cenário: Desacoplando o fluxo criacional de classes do seu projeto.

Identifique uma regra do seu sistema que exige diferentes comportamentos ou envios dependendo de uma escolha do usuário (Ex: Modos de Pagamento [Pix, Crédito, Boleto], Calculadoras de Frete [Rápido, Econômico, Sedex], Relatórios [PDF, CSV]).
Escreva a estrutura de classes (pode ser em pseudo-código ou Java) contendo a Interface comum, duas classes filhas implementadoras e a Factory de decisão criacional.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas especificações arquiteturais:

Salve o arquivo de código e diagramas com o nome Atividade_13.md na pasta es-atv-13-arquitetura/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Por que na arquitetura profissional de desenvolvimento em camadas do Spring Boot, a classe de Controller nunca deve conter queries SQL ou lógicas pesadas de IF/ELSE de negócios? (Resposta: Para manter o desacoplamento e a testabilidade do sistema. O Controller deve apenas gerenciar a comunicação com o protocolo HTTP; se regras de negócio forem colocadas ali, o código ficará amarrado ao ambiente Web, impedindo que essa mesma lógica de negócio seja reutilizada em APIs móveis, agendadores automáticos ou testes unitários JUnit). 🧠🛡️

🔌 ATIVIDADE 14: DESIGN DE APIS REST E SWAGGER

Bem-vindo a mais uma etapa prática de Engenharia de Software! Agora que você conhece as camadas internas do software, aprenderá como expor e conectar o seu sistema ao mundo externo. Hoje, vamos nos tornar arquitetos de comunicação móvel e web, projetando contratos de integração baseados em APIs RESTful, payloads de dados JSON e documentando tudo com o padrão profissional global Swagger (OpenAPI). 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Mapear recursos de sistemas no formato e boas práticas de APIs REST.
Utilizar os Verbos HTTP (GET, POST, PUT, DELETE) e os Códigos de Retorno (Status Codes) corretos.
Escrever payloads estruturados em formato JSON (JavaScript Object Notation).
Interpretar e projetar documentações no padrão Swagger/OpenAPI.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, os motoristas que usam o aplicativo Android precisam enviar em tempo real a geolocalização do caminhão para o painel de controle do SAC. Além disso, o app precisa buscar a lista de entregas pendentes direto do servidor central. No entanto, os desenvolvedores Mobile e os programadores de Backend não combinaram o "formato de dados" e a comunicação travou!

O app móvel mandava POST /api/enviar_localizacao e o servidor dava erro de conexão porque esperava receber um formato diferente do JSON enviado pelo celular!

"Seu desafio como Designer de APIs é desenhar o contrato profissional de endpoints para a TecProExpress. Você criará a modelagem de recursos RESTful para /api/entregas e /api/motoristas/localizacao, definindo os verbos corretos, os dados em formato JSON e gerando a especificação profissional baseada em Swagger/OpenAPI."

🧠 Fundamentos: A Teoria Traduzida

Uma API (Application Programming Interface) é uma porta que permite que sistemas diferentes conversem de forma organizada. REST é o estilo arquitetural padrão da web.

Regras de Ouro do Design REST:

Recursos são Substantivos no Plural: Evite verbos no endereço!
- Errado: POST /api/salvarMotorista
- Certo: POST /api/motoristas
Use os Verbos HTTP Adequados:
- GET: Busca um ou vários registros (Ex: GET /api/entregas).
- POST: Cria um novo registro (Ex: POST /api/entregas).
- PUT: Atualiza o registro inteiro por completo.
- DELETE: Exclui um registro da base de dados.
Comunique-se por Status Codes:
- 200 OK: Requisição de consulta ou alteração com sucesso.
- 201 Created: Novo registro criado com sucesso (retorno típico de POST).
- 400 Bad Request: Envio de dados incorretos ou campos faltantes.
- 404 Not Found: O registro ou endpoint consultado não existe.
- 500 Internal Server Error: Falha técnica no servidor (bug).

📊 Visualizando a Comunicação HTTP

sequenceDiagram
    App Mobile->>Servidor API: POST /api/entregas (Payload JSON)
    Note over Servidor API: Processa no Spring Boot,<br/>Valida e Salva no Banco.
    Servidor API-->>App Mobile: 201 Created { "id": 125, "status": "PENDENTE" }

📖 Exemplo Guiado: Especificação Swagger e Spring Boot

Abaixo, veja como expor e documentar um endpoint de criação de entrega.

🛠️ Código Java 17 no Spring Boot (O Controller REST):

@RestController
@RequestMapping("/api/entregas")
@Tag(name = "Entregas", description = "Gerenciamento de entregas da TecProExpress")
public class DeliveryRestController {

    @Autowired
    private DeliveryService service;

    @PostMapping
    @Operation(summary = "Criar nova entrega", description = "Cria uma entrega no banco de dados e aguarda motorista")
    public ResponseEntity<DeliveryResponse> criarEntrega(@RequestBody DeliveryRequest request) {
        DeliveryResponse response = service.criar(request);
        return ResponseEntity.status(HttpStatus.CREATED).body(response);
    }
}

📄 O Contrato JSON enviado pelo App Mobile (Payload):

{
  "clienteId": 45,
  "enderecoDestino": "Av. Paulista, 1000 - São Paulo, SP",
  "pesoCarga": 12.5,
  "tipoNotificacao": "SMS"
}

📄 Documentação Swagger (OpenAPI YAML) correspondente:

openapi: 3.0.3
info:
  title: API TecProExpress
  version: 1.0.0
paths:
  /api/entregas:
    post:
      summary: Criar nova entrega
      tags:
        - Entregas
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - clienteId
                - enderecoDestino
              properties:
                clienteId:
                  type: integer
                enderecoDestino:
                  type: string
                pesoCarga:
                  type: number
      responses:
        '201':
          description: Criado com sucesso

🛠️ Prática Obrigatória 1: Tabela de Endpoints da API

Cenário: O projeto semestral da sua equipe.

Mapeie 3 endpoints críticos que o seu sistema precisará expor para um aplicativo celular ou sistema parceiro.
Organize-os em uma tabela contendo: Verbo HTTP, Caminho (URL), O que faz (Descrição) e Status Code de Sucesso (ex: 200, 201).

🏁 Resultado Esperado (Para sua Referência)

Uma tabela com o roteiro de comunicação REST detalhando as requisições principais de forma limpa e seguindo as boas práticas.

🛠️ Prática Obrigatória 2: O Payload JSON e Contrato Swagger

Cenário: Detalhando os dados de tráfego.

Para o endpoint principal de inserção de dados da Prática 1 (Ex: criar agendamento, realizar venda), escreva o payload em formato JSON real que o cliente enviará.
Escreva a especificação profissional simplificada no padrão Swagger/OpenAPI (formato YAML) que descreve esse endpoint e o corpo da requisição de forma estruturada.

📤 Instruções de Entrega (Microsoft Teams)

Após validar o seu design de API:

Salve o arquivo contendo a tabela de endpoints, o JSON e a especificação Swagger YAML com o nome Atividade_14.md na pasta es-atv-14-apis-swagger/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Por que no design REST profissional, nunca usamos o verbo GET para realizar a deleção de um dado (ex: GET /api/entregas/excluir?id=5) em vez do correto DELETE (ex: DELETE /api/entregas/5)? (Resposta: Pela natureza idempotente e segura dos verbos HTTP. Navegadores e proxies de cache assumem que requisições GET são seguras e não causam efeitos colaterais. Se você usar GET para excluir, um robô de busca de indexação automática da internet ao varrer os links do seu sistema poderia, acidentalmente, apagar o banco de dados inteiro da empresa!). 🧠🛡️

🐙 ATIVIDADE 15: GITFLOW E TRABALHO COLABORATIVO

Bem-vindo a mais uma etapa prática de Engenharia de Software! Até agora, você criou especificações e diagramas. Mas na vida real de desenvolvimento corporativo, as equipes trabalham juntas em uma base de código única. Como fazer para que 10 programadores editem o mesmo arquivo do Spring Boot ao mesmo tempo sem que um apague a alteração do outro? Hoje, aprenderemos a dominar o controle de versão profissional usando o Git e a metodologia estratégica GitFlow. 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Trabalhar de forma colaborativa usando repositórios Git/GitHub.
Aplicar o padrão de ramificação GitFlow (main, develop, feature/, hotfix/).
Criar Pull Requests (PR) e conduzir processos de Code Review.
Identificar e resolver de forma segura os clássicos Conflitos de Merge (Merge Conflicts).

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, os desenvolvedores Beto e Lucas estavam trabalhando na mesma tela de faturamento. Beto alterou o cálculo do frete adicionando o imposto do ICMS. Lucas, trabalhando no mesmo arquivo na mesma linha de código, mudou a lógica para aceitar Pix. Ao subir o código no final do dia, as alterações se atropelaram, o servidor do Git travou e metade da lógica do Beto sumiu da empresa!

O gerente técnico ficou furioso: "Como vocês não usam branches dedicadas e GitFlow?!".

"Seu desafio como Engenheiro de Configuração (DevOps) é implantar a metodologia GitFlow na TecProExpress. Você desenhará a topologia de branches mostrando a trilha do desenvolvimento de uma nova funcionalidade, como ela passa por revisão técnica e como resolver os conflitos de mesclagem lógicos se dois desenvolvedores tocarem no mesmo arquivo."

🧠 Fundamentos: A Teoria Traduzida

O Git é a ferramenta de controle de versão (como a máquina do tempo do seu código). O GitFlow é o "manual de trânsito" que diz quais faixas lógicas os desenvolvedores devem trafegar.

As Faixas Lógicas (Branches) do GitFlow:

main (antiga master): A faixa rápida de alta segurança. Contém apenas o código que está rodando em produção de forma 100% testada e estável.
develop: A faixa central de integração. Onde o time junta todas as novas funcionalidades que estão sendo desenvolvidas para a próxima versão.
feature/nome-da-tarefa: Faixas locais temporárias. Cada programador cria a sua para trabalhar isoladamente em uma tarefa específica (Ex: feature/login-htmx).
hotfix/correcao-critica: Faixa de emergência direta. Criada a partir da main para corrigir um bug grave que está derrubando a produção de forma imediata.

📊 Visualizando a Topologia GitFlow

[!TIP] Code Review: Nunca mescle seu código na branch de integração sem que pelo menos um outro colega de equipe faça o "Double Check" no seu Pull Request. Quatro olhos veem muito melhor do que dois!

gitGraph
    commit id: "v1.0.0 (Setup)"
    branch develop
    checkout develop
    commit id: "Inicializar Spring Boot"
    branch feature-login
    checkout feature-login
    commit id: "Criar Controller de Login"
    commit id: "Integrar Thymeleaf e HTMX"
    checkout develop
    merge feature-login id: "Merge: Sprint 1"
    checkout main
    merge develop id: "Release v1.1.0"

📖 Exemplo Guiado: Anatomia de um Conflito de Merge

Se dois desenvolvedores editarem a linha 42 do arquivo DeliveryService.java de forma diferente, o Git não saberá qual escolher. Ele gerará um Merge Conflict e marcará o arquivo assim:

<<<<<<< HEAD
    // Lógica do Desenvolvedor Lucas (Branch Local)
    double freteFinal = valorBase * 1.10;
=======
    // Lógica do Desenvolvedor Beto (Branch Remota)
    double freteFinal = (valorBase + impostoIcms) * 1.05;
>>>>>>> feature/calculo-beto

🛠️ Como resolver o conflito passo a passo:

Analise com calma: O conflito exibe a seção superior (<<<<<<< HEAD até =======) contendo o seu código, e a seção inferior (======= até >>>>>>>) contendo o código de quem já enviou.
Consenso técnico: Converse com seu colega de equipe para entender as necessidades de ambos os códigos.
Edição Limpa: Apague as marcações vermelhas do Git (<<<<<<<, =======, >>>>>>>) e mescle as duas lógicas na melhor solução possível:

    // Lógica Consolidada em Equipe
    double freteFinal = (valorBase + impostoIcms) * 1.10;

Commit de Resolução: Salve o arquivo editado e faça o commit de sucesso (git commit -am "Resolvendo conflito de cálculo de frete").

🛠️ Prática Obrigatória 1: A Linha do Tempo GitFlow

Cenário: O fluxo de versionamento do seu projeto semestral.

Escreva a sintaxe do Mermaid gitGraph (baseado no exemplo guiado) representando a evolução do seu projeto.
O seu gráfico deve apresentar:
- O commit inicial na branch main.
- A criação e checkout da branch develop.
- A criação de uma branch de feature/sua-funcionalidade-principal com pelo menos 2 commits individuais.
- O merge da feature de volta para a develop.
- O merge final da develop para a main selando a versão estável v1.0.0.

🏁 Resultado Esperado (Para sua Referência)

O diagrama interativo gitGraph renderizado no corpo do seu arquivo de entrega na documentação do mdBook.

🛠️ Prática Obrigatória 2: Manual de Resolução de Conflitos

Cenário: Proteção contra perda de arquivos.

Simule (em formato texto dentro do seu Markdown) um arquivo do seu projeto que sofreu conflito em equipe.
Escreva o bloco mostrando as tags de demarcação (<<<<<<<, =======, >>>>>>>) com os códigos conflitantes.
Escreva logo abaixo o arquivo final resolvido e justifique a escolha técnica da mesclagem.

📤 Instruções de Entrega (Microsoft Teams)

Após validar suas especificações de versionamento técnico:

Salve o arquivo contendo os diagramas GitGraph e a simulação de conflito com o nome Atividade_15.md na pasta es-atv-15-gitflow-colaboracao/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Por que a metodologia GitFlow proíbe terminantemente que os desenvolvedores façam commits diretos e pushes na branch main de produção? (Resposta: Para garantir estabilidade e governança do produto. A branch main representa o software rodando nos clientes; se pushes diretos fossem permitidos, qualquer erro de digitação local que quebrasse a compilação seria publicado imediatamente, parando as operações de faturamento ou de logística da empresa). 🧠🛡️

⚙️ ATIVIDADE 16: PIPELINES DE CI/CD COM GITHUB ACTIONS

Bem-vindo a mais uma etapa da sua jornada na Engenharia de Software! Nas atividades anteriores, aprendemos sobre GitFlow e arquitetura. Hoje, daremos um passo fundamental na automação de processos industriais de software: a Integração Contínua (CI). Aprenderemos como automatizar a compilação e execução de testes JUnit a cada Push que seu time faz para o repositório, garantindo blindagem contra códigos bugados! 🛡️🧩

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Compreender os conceitos fundamentais de CI/CD (Integração Contínua e Entrega Contínua).
Projetar e mapear pipelines lógicos e suas sequências de execução.
Configurar um arquivo YAML de automação corporativa real com GitHub Actions.
Integrar testes unitários JUnit em aplicações Spring Boot 3.5.x e Java 17 no fluxo de CI.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, a gerência estava cansada: toda vez que um desenvolvedor subia uma nova alteração de código, ele jurava de pés juntos que o sistema estava "funcionando perfeitamente". Porém, ao publicar na nuvem, o aplicativo do motorista quebrava porque alguém esqueceu de testar a alteração localmente!

Os testes manuais demoravam horas de digitação improdutiva e, frequentemente, bugs passavam para produção.

"Seu desafio como Analista de DevOps é criar o primeiro Pipeline de Integração Contínua (CI) para a TecProExpress. Você configurará um arquivo do GitHub Actions que, de forma 100% automática, baixa o código do repositório, instala o Java 17, compila a aplicação Spring Boot e executa todos os testes unitários do JUnit toda vez que um programador enviar um Push ou Pull Request."

🧠 Fundamentos: A Teoria Traduzida

CI (Continuous Integration): É a prática de integrar alterações de código com frequência e validá-las de forma automática. CD (Continuous Delivery): É a publicação automatizada do código validado no servidor web (produção).

Anatomia de um Workflow do GitHub Actions:

Workflow: O arquivo YAML que define a automação (salvo na pasta .github/workflows/).
Trigger (on): O evento que aciona o pipeline (Ex: push ou pull_request na branch develop/main).
Jobs (Trabalhos): As seções do pipeline (Ex: build-and-test).
Steps (Passos): A sequência de comandos que roda dentro de uma máquina virtual dedicada na nuvem (Runner).

📊 Visualizando a Sequência de Automação

flowchart LR
    Push["1. Git Push / PR"] --> Trigger{"2. Trigger do GitHub"}
    Trigger -->|Dispara Runner| VM["Máquina Virtual Ubuntu"]
    subgraph VM [VM na Nuvem do GitHub]
        direction TB
        S1["Step 1: Baixar Código (Checkout)"] --> S2["Step 2: Instalar Java 17 (JDK)"]
        S2 --> S3["Step 3: Compilar & Testar (Maven + JUnit)"]
    end
    VM -->|Falha no Teste| Block["Pipeline Vermelho: Bloquear Deploy!"]
    VM -->|Sucesso total| Pass["Pipeline Verde: Liberar Mesclagem!"]

    style VM fill:#f9f9f9,stroke:#333
    style Block fill:#ffebee,stroke:#c62828,stroke-width:2px
    style Pass fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

📖 Exemplo Guiado: Roteiro e Configuração do Pipeline

Para configurar a automação, precisaremos de duas coisas no nosso repositório Java Spring Boot: o teste unitário de negócio (JUnit) e o arquivo do pipeline (Actions).

1. 🛠️ O Teste Unitário JUnit em Java 17 (Cálculo de Frete):

Dentro da pasta src/test/java/com/tecproexpress/ do seu projeto Spring Boot, nós escrevemos o teste de validade da regra de negócio:

package com.tecproexpress.service;

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

public class DeliveryServiceTest {

    @Test
    public void deveCalcularFreteComSucesso() {
        double pesoCarga = 10.0; // 10kg
        double valorBase = 50.0;
        
        // Regra da TecProExpress: R$ 2.00 por Kg excedente
        double freteFinal = valorBase + (pesoCarga * 2.0);

        // Asserção JUnit de Sucesso
        assertEquals(70.0, freteFinal, "O cálculo de frete da TecProExpress falhou!");
    }
}

2. 📄 O Arquivo do Pipeline `.github/workflows/ci.yml`:

Este é o arquivo YAML que o GitHub interpreta para automatizar a verificação:

name: Java CI com Maven e Spring Boot

on:
  push:
    branches: [ "main", "develop" ]
  pull_request:
    branches: [ "main", "develop" ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
    # 1. Faz o download do código do repositório
    - name: Checkout do Código
      uses: actions/checkout@v4

    # 2. Configura a versão do Java no ambiente de execução
    - name: Instalar JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: maven

    # 3. Compila a aplicação Spring Boot e roda os testes do JUnit
    - name: Executar Build e Testes JUnit com Maven
      run: mvn -B clean test

🛠️ Prática Obrigatória 1: Desenho do Pipeline

Cenário: Mapeamento visual das etapas de automação do seu projeto.

Desenhe um diagrama flowchart no Mermaid representando a sequência de passos lógicos que o seu pipeline do GitHub Actions deve executar.
Adicione cores ou estilos para indicar a diferença visual entre o sucesso e a falha de um passo de teste.

🏁 Resultado Esperado (Para sua Referência)

Um diagrama Mermaid detalhado demonstrando o ciclo de CI acionado por um Push de branch e o desfecho do build.

🛠️ Prática Obrigatória 2: O Roteiro de CI e Teste de Unidade

Cenário: Escrevendo sua primeira verificação automatizada.

Crie a especificação em formato Markdown do seu arquivo de configuração .github/workflows/ci.yml customizado para o seu repositório do projeto.
Escreva a classe de teste JUnit (Java) correspondente a uma validação de dados lógica do seu sistema (Ex: Validar se uma senha tem menos de 8 caracteres e falha, Validar se a idade do usuário é maior que 18 para aprovação).

📤 Instruções de Entrega (Microsoft Teams)

Após validar a sua arquitetura de automação de testes:

Salve o arquivo de especificações e códigos com o nome Atividade_16.md na pasta es-atv-16-pipelines-cicd/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Se durante a execução do pipeline de CI no GitHub Actions um único teste unitário do JUnit falhar (ex: acusando AssertionError), o que o GitHub fará com o Pull Request de mesclagem de código daquele desenvolvedor? (Resposta: O GitHub marcará o build como "Falho" (Status Vermelho) e bloqueará a mesclagem automática do Pull Request, impedindo que o código defeituoso contamine a branch estável de desenvolvimento develop ou main). 🧠🛡️

🐳 ATIVIDADE 17: CONTAINERIZAÇÃO DE AMBIENTES COM DOCKER

Bem-vindo a mais uma etapa prática da sua jornada na Engenharia de Software! Após automatizarmos nossos testes no pipeline de CI/CD, agora resolveremos um dos problemas mais clássicos e irritantes no desenvolvimento de software: "Na minha máquina funciona, por que não funciona no servidor de produção?" 🤦‍♂️💻

Hoje, aprenderemos sobre Docker e Docker Compose, as tecnologias líderes de mercado que revolucionaram a forma de empacotar, distribuir e rodar aplicações em ambientes isolados e idênticos, garantindo previsibilidade absoluta! 🚀

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Compreender os conceitos fundamentais de Contêineres vs Máquinas Virtuais.
Escrever um Dockerfile otimizado para empacotar uma aplicação web Java 17 com Spring Boot.
Criar um arquivo docker-compose.yml para orquestrar múltiplos contêineres (App + PostgreSQL) em rede local isolada.
Gerenciar redes virtuais e volumes persistentes no ambiente Docker.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, a equipe de desenvolvimento estava enfrentando um caos diário de configuração. Cada desenvolvedor usava uma versão diferente do Java, um usava MySQL local, outro usava PostgreSQL, e um terceiro usava uma versão desatualizada do banco de dados que quebrava as chaves estrangeiras. A contratação de novos programadores demorava até 3 dias apenas para configurar o ambiente de desenvolvimento local!

"Seu desafio como Arquiteto de Soluções é padronizar e automatizar 100% do ambiente da TecProExpress. Você criará o arquivo Dockerfile da aplicação web (Java 17, Spring Boot, Thymeleaf e HTMX) e um arquivo docker-compose.yml que sobe, com um único comando, o servidor da aplicação e o banco de dados PostgreSQL configurados para conversar entre si em uma rede virtual isolada."

🧠 Fundamentos: A Teoria Traduzida

Imagem Docker: É um pacote imutável e somente-leitura que contém tudo o que é necessário para rodar a aplicação (código, dependências, runtime do Java, variáveis de ambiente e arquivos).
Contêiner Docker: É a instância em execução de uma imagem. Ele compartilha o kernel do sistema operacional do host, tornando-o extremamente leve, rápido e com consumo mínimo de memória.
Dockerfile: O script com comandos sequenciais para construir a Imagem do contêiner.
Docker Compose: A ferramenta que permite definir e rodar aplicações multi-contêiner. Com um único comando (docker-compose up), todas as dependências (banco, cache, app) sobem prontas.

📊 Arquitetura do Ambiente Orquestrado com Docker

flowchart TD
    subgraph Host ["Máquina do Desenvolvedor (Host OS)"]
        direction TB
        subgraph DockerNet ["Rede Virtual Isolada (tecpro-network)"]
            direction LR
            App["Contêiner Application: Spring Boot + Thymeleaf"] <-->|Porta 5432| DB[("Contêiner Database: PostgreSQL 15")]
        end
        PortApp["Porta Física Exposta: 8080"] <-->|Direciona Requisições| App
    end
    
    subgraph Persistencia ["Armazenamento Externo"]
        Volume[("Volume Docker: pgdata")] <---> DB
    end

    style Host fill:#f5f7fa,stroke:#333,stroke-width:2px
    style DockerNet fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style Persistencia fill:#fff3e0,stroke:#ef6c00,stroke-width:2px
    style App fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style DB fill:#ffe0b2,stroke:#f57c00,stroke-width:2px

📖 Exemplo Guiado: Dockerização de Ponta a Ponta

Para empacotarmos a aplicação Spring Boot 3.5.x da TecProExpress integrada ao PostgreSQL, utilizaremos a estratégia recomendada de infraestrutura como código.

1. 🛠️ O Arquivo `Dockerfile` da Aplicação

Criamos um arquivo com o nome exato Dockerfile (sem extensão) na raiz do projeto Java para definir a construção da nossa imagem:

# Etapa 1: Construção (Build) utilizando o Maven oficial com Java 17
FROM maven:3.8.8-eclipse-temurin-17 AS builder
WORKDIR /app

# Copia os arquivos de configuração do Maven e o código fonte
COPY pom.xml .
COPY src ./src

# Compila o projeto e gera o arquivo JAR executável ignorando os testes (já rodados no CI)
RUN mvn clean package -DskipTests

# Etapa 2: Execução (Runtime) com imagem leve JRE
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app

# Copia o JAR compilado da primeira etapa para o ambiente final
COPY --from=builder /app/target/*.jar app.jar

# Expõe a porta padrão do Spring Boot
EXPOSE 8080

# Variáveis de ambiente padrão (podem ser sobrescritas pelo Compose)
ENV SPRING_PROFILES_ACTIVE=prod

# Comando para iniciar a aplicação
ENTRYPOINT ["java", "-jar", "app.jar"]

2. 📄 O Arquivo `docker-compose.yml` de Orquestração

Na mesma raiz do projeto, criamos o arquivo docker-compose.yml para conectar a nossa aplicação ao banco de dados PostgreSQL de forma indestrutível:

version: '3.8'

services:
  # Serviço 1: Banco de Dados PostgreSQL
  database:
    image: postgres:15-alpine
    container_name: tecpro-db
    restart: always
    environment:
      POSTGRES_DB: tecproexpress
      POSTGRES_USER: tecpro_admin
      POSTGRES_PASSWORD: SenhaSuperSegura123
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - tecpro-network

  # Serviço 2: Aplicação Java Spring Boot
  web-app:
    build: .
    container_name: tecpro-web-app
    restart: always
    ports:
      - "8080:8080"
    environment:
      - SPRING_DATASOURCE_URL=jdbc:postgresql://database:5432/tecproexpress
      - SPRING_DATASOURCE_USERNAME=tecpro_admin
      - SPRING_DATASOURCE_PASSWORD=SenhaSuperSegura123
      - SPRING_JPA_DATABASE-PLATFORM=org.hibernate.dialect.PostgreSQLDialect
      - SPRING_JPA_HIBERNATE_DDL_AUTO=update
    depends_on:
      - database
    networks:
      - tecpro-network

# Definição dos Recursos Compartilhados
volumes:
  pgdata:
    driver: local

networks:
  tecpro-network:
    driver: bridge

🛠️ Prática Obrigatória 1: Desenho da Rede de Contêineres

Cenário: Mapeamento conceitual do ecossistema de contêineres e fluxo de comunicação.

Desenhe um diagrama flowchart no Mermaid representando a arquitetura dos contêineres da sua aplicação.
Destaque as portas físicas do Host (computador físico) expostas e como elas se mapeiam para as portas internas dos contêineres do Docker.
Evidencie a comunicação interna entre a aplicação e o banco PostgreSQL utilizando a rede virtualizada privada.

🏁 Resultado Esperado (Para sua Referência)

Um diagrama visual nítido exibindo o redirecionamento de portas (port-forwarding), volumes de persistência e a barreira da rede virtual.

🛠️ Prática Obrigatória 2: Criando os Arquivos de Configuração

Cenário: Escrevendo os scripts de containerização para o seu projeto semestral.

Escreva o script Dockerfile personalizado para o seu sistema de grupo, adaptando caso seu ecossistema necessite de variáveis ou passos específicos.
Escreva o arquivo docker-compose.yml que orquestra a aplicação de vocês integrada com um banco de dados persistido e mapeamento de portas do host para o contêiner.

📤 Instruções de Entrega (Microsoft Teams)

Após projetar a sua infraestrutura containerizada:

Salve o arquivo de especificações e códigos com o nome Atividade_17.md na pasta es-atv-17-conteineres-docker/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: No arquivo docker-compose.yml, a URL de conexão do banco de dados na aplicação web foi definida como jdbc:postgresql://database:5432/tecproexpress em vez de jdbc:postgresql://localhost:5432/tecproexpress. Por que a palavra database funciona ali dentro do Docker? E o que aconteceria com os dados do banco de dados do PostgreSQL quando o contêiner fosse deletado e recriado, considerando que usamos a seção volumes? (Respostas: O Docker possui um DNS embutido em suas redes virtuais que resolve o nome do serviço do Compose — no caso, database — diretamente para o IP interno dinâmico do contêiner do Postgres. Graças à declaração do volume pgdata mapeado para a pasta física de arquivos do host, os dados bancários permanecem intactos e persistem mesmo que o contêiner do Postgres seja totalmente destruído e recriado). 🐳💾🧠

🛡️ ATIVIDADE 18: SEGURANÇA NO DESENVOLVIMENTO E OWASP

Bem-vindo a mais uma etapa crítica da sua jornada na Engenharia de Software! Até aqui, aprendemos a modelar, testar, automatizar e containerizar sistemas. Mas de que adianta um sistema incrivelmente rápido, com CI/CD verde e rodando em Docker, se ele puder ser facilmente invadido por um hacker, vazando dados confidenciais dos usuários? 😱🔓

Hoje, mergulharemos no universo do DevSecOps e do Desenvolvimento Seguro (Secure by Design). Aprenderemos a analisar vulnerabilidades antes mesmo de escrevermos o código, utilizando a metodologia de modelagem de ameaças STRIDE e as diretrizes internacionais da OWASP.

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Compreender a importância da segurança proativa no ciclo de desenvolvimento de software.
Aplicar a metodologia STRIDE para identificar ameaças na arquitetura do sistema.
Identificar as principais falhas do OWASP Top 10 (como Injection e Broken Authentication).
Implementar defesas de código e configurações seguras em Java 17 e Spring Boot.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, a segurança costumava ser vista como "problema do pessoal de redes" ou "algo para olhar depois que o software estiver pronto". Essa mentalidade cobrou seu preço: na semana passada, um motorista mal-intencionado conseguiu manipular o parâmetro id na URL da API e visualizou os dados pessoais de entrega e faturamento de outros clientes. Além disso, a tela de busca de fretes sofreu um ataque de injeção de SQL que quase apagou a tabela de produtos!

"Seu desafio como Engenheiro de Segurança de Aplicações (AppSec) é blindar a arquitetura da TecProExpress. Você conduzirá uma modelagem de ameaças STRIDE e programará mecanismos de proteção no Spring Boot para barrar ataques de injeção de código e vazamento de dados de autorização de forma definitiva."

🧠 Fundamentos: A Teoria Traduzida

1. A Metodologia STRIDE (Modelagem de Ameaças)

Criada pela Microsoft, serve para mapear o que pode dar errado em um sistema com base em seis pilares fundamentais:

Spoofing (Falsificação de identidade): Alguém fingindo ser outro usuário.
Tampering (Adulteração de dados): Modificar dados em trânsito ou no banco.
Repudiation (Repúdio): Um usuário alegar que não realizou uma ação por falta de logs auditáveis.
Information Disclosure (Vazamento de informações): Expor dados confidenciais a pessoas não autorizadas.
Denial of Service (Negação de Serviço): Derrubar o sistema por sobrecarga de requisições.
Elevation of Privilege (Elevação de privilégio): Um usuário comum executando funções de administrador.

2. OWASP Top 10

A Open Worldwide Application Security Project (OWASP) é uma fundação global sem fins lucrativos que mapeia e publica regularmente as 10 vulnerabilidades de segurança mais críticas e recorrentes em aplicações web no mundo todo.

📊 Vetores de Ataque Comuns vs Defesa Ativa

flowchart TD
    subgraph Vetores ["Vetores de Ataque (Ameaças)"]
        A1["Injeção de SQL (SQLi)"]
        A2["Manipulação de URL (BOLA/IDOR)"]
        A3["Brute Force (Senha Fraca)"]
    end

    subgraph Defesas ["Mecanismos de Defesa (Spring Boot)"]
        D1["Uso de Spring Data JPA / Prepared Statements"]
        D2["Controle de Acesso baseado em Roles (Spring Security)"]
        D3["Criptografia BCrypt + Rate Limiting"]
    end

    A1 -->|Mitigado por| D1
    A2 -->|Mitigado por| D2
    A3 -->|Mitigado por| D3

    style Vetores fill:#ffebee,stroke:#c62828,stroke-width:2px
    style Defesas fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

📖 Exemplo Guiado: Codificação Segura e Defesa Ativa

Vamos analisar um exemplo de código vulnerável em Spring Boot e como corrigi-lo imediatamente usando boas práticas de programação.

1. Evitando a Injeção de SQL (SQL Injection)

Cenário vulnerável (O que NÃO fazer): Concatenar strings diretamente na consulta SQL permite que o atacante envie comandos maliciosos na variável input.

// VULNERÁVEL! Permite SQL Injection
public List<Pedido> buscarPedidosPorCidade(String input) {
    String query = "SELECT * FROM pedidos WHERE cidade = '" + input + "'";
    return entityManager.createNativeQuery(query, Pedido.class).getResultList();
}

Se o atacante passar o valor Joinville' OR '1'='1, a query executará retornando todos os pedidos do banco de dados!

Cenário Seguro (Como implementar): Usar consultas parametrizadas (Prepared Statements) ou Spring Data JPA, que higienizam as entradas automaticamente.

// SEGURO! Parâmetros higienizados pelo JPA/Hibernate
public List<Pedido> buscarPedidosPorCidadeSeguro(String input) {
    String query = "SELECT p FROM Pedido p WHERE p.cidade = :cidade";
    return entityManager.createQuery(query, Pedido.class)
                        .setParameter("cidade", input)
                        .getResultList();
}

2. Proteção de Acesso com Spring Security

Configuração para restringir privilégios em endpoints sensíveis da API (Evitando elevação de privilégios e Broken Access Control):

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(csrf -> csrf.disable()) // CSRF desabilitado apenas para fins didáticos de API
            .authorizeHttpRequests(auth -> auth
                // Endpoints públicos
                .requestMatchers("/api/public/**").permitAll()
                // Apenas motoristas autenticados podem ver entregas
                .requestMatchers("/api/entregas/**").hasRole("MOTORISTA")
                // Apenas gerentes podem deletar registros ou ver relatórios
                .requestMatchers("/api/admin/**").hasRole("GERENTE")
                .anyRequest().authenticated()
            )
            .httpBasic(Customizer.withDefaults()); // Autenticação básica simples
        
        return http.build();
    }
}

🛠️ Prática Obrigatória 1: Matriz de Ameaças STRIDE

Cenário: Analisando a segurança do seu projeto de grupo.

Crie uma tabela Markdown contendo uma análise de ameaças do seu sistema utilizando a metodologia STRIDE.
Mapeie pelo menos 3 das 6 letras do STRIDE aplicadas ao seu projeto real.
Preencha as colunas: Elemento do Sistema (ex: Tela de Login), Ameaça Identificada (ex: Usuário interceptar tráfego) e Mitigação Proposta (ex: Uso obrigatório de HTTPS e senhas salvas com Hash BCrypt).

🛠️ Prática Obrigatória 2: Higienização de Código

Cenário: Identificação e correção de falhas de segurança no código.

Crie um arquivo Markdown demonstrando um trecho de código hipotético ou real do seu sistema que seja vulnerável a Injeção de SQL ou Falha de Autorização.
Apresente, logo abaixo, a versão corrigida desse código (Refatoração de Segurança), explicando qual técnica foi aplicada para eliminar a vulnerabilidade.

📤 Instruções de Entrega (Microsoft Teams)

Após auditar e implementar as melhorias de segurança:

Salve a sua matriz de ameaças e os trechos de código com o nome Atividade_18.md na pasta es-atv-18-seguranca-devsecops/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Suponha que seu sistema utilize criptografia reversível (como AES) para salvar as senhas dos usuários no banco de dados, em vez de um algoritmo de hash criptográfico não-reversível (como BCrypt ou PBKDF2). Se um invasor conseguir acesso de leitura à tabela de usuários, por que salvar senhas com criptografia AES é perigoso? O que o invasor precisaria obter para ler todas as senhas em texto puro? (Resposta: A criptografia AES é bidirecional (simétrica), o que significa que se houver a chave de criptografia, o dado pode ser totalmente descriptografado para texto original. Se o invasor acessar o banco de dados e obter a chave de descriptografia que geralmente fica salva no código ou nas variáveis de ambiente do servidor, ele conseguirá reverter todas as senhas. Algoritmos de Hash como o BCrypt são unidirecionais e usam a técnica de Salting, tornando matematicamente impossível reverter o hash de volta à senha original, garantindo proteção mesmo que o banco de dados seja roubado). 🛡️🔑🧠

📊 ATIVIDADE 19: MÉTRICAS DE SOFTWARE, ESTIMATIVAS E DORA

Bem-vindo a mais uma etapa indispensável da sua formação em Engenharia de Software! Nas últimas semanas, focamos intensamente em aspectos técnicos: codificação, arquitetura, testes, infraestrutura e segurança. Hoje, assumiremos o papel de Gestores de TI e Líderes Técnicos (Tech Leads) para responder a uma das perguntas mais desafiadoras feitas pelos diretores de qualquer empresa: "Quando o sistema estará pronto e quão eficiente é a nossa equipe de engenharia?" ⏰💼

Aprenderemos sobre técnicas de estimativas ágeis e conheceremos as famosas Métricas DORA, a referência global e científica de mercado usada para medir a velocidade de entrega e a estabilidade de equipes de alto desempenho em DevOps.

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Diferenciar estimativas tradicionais de estimativas ágeis (Story Points).
Calcular a velocidade de desenvolvimento (Velocity) de um time de desenvolvimento.
Compreender e calcular as 4 Métricas Chaves da DORA (Deployment Frequency, Lead Time, MTTR, Change Failure Rate).
Mapear e classificar o nível de maturidade operacional de uma equipe de software.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, a diretoria estava insatisfeita. Os projetos sempre atrasavam, as estimativas em "horas" eram imprecisas e, pior, ninguém sabia medir se as recentes automações (CI/CD, Docker e testes JUnit) realmente trouxeram melhorias reais para a velocidade ou se apenas aumentaram a complexidade técnica.

Os gerentes cobravam relatórios baseados em "linhas de código escritas por dia", o que incentivava os programadores a escreverem códigos inchados e ruins apenas para bater a meta.

"Seu desafio como Tech Lead / Agile Coach é reformular a forma de planejar e medir a eficácia do time da TecProExpress. Você calculará a capacidade da equipe em Story Points, estimará a entrega de um backlog crítico de rotas e implantará os indicadores DORA para provar cientificamente os benefícios das práticas DevOps no negócio."

🧠 Fundamentos: A Teoria Traduzida

1. Estimativas Ágeis vs Tradicionais

Estimativa Tradicional (Horas/Dias): Tenta adivinhar o tempo exato de uma tarefa. Costuma falhar porque ignora a complexidade subjetiva, interrupções e riscos técnicos.
Story Points (Estimativa de Esforço): Medida relativa baseada na Sequência de Fibonacci (1, 2, 3, 5, 8, 13...) que avalia o esforço, complexidade e incerteza de um item do backlog, comparando-o com tarefas já conhecidas.
Velocidade (Velocity): A soma de Story Points de tarefas que o time consegue entregar (mudar para o status 'Done') no período de uma Sprint (normalmente 2 semanas).

2. As 4 Métricas DORA (DevOps Research and Assessment)

O grupo de pesquisa do Google (DORA) comprovou estatisticamente que a performance de engenharia de software é classificada por 4 métricas equilibradas entre Velocidade de Entrega e Estabilidade do Sistema:

📊 O Quadrante de Indicadores DORA

flowchart TD
    subgraph DORA ["As 4 Métricas Fundamentais DORA"]
        direction TB
        subgraph Velocidade ["Eficácia & Velocidade (Entrega)"]
            direction LR
            DF["Deployment Frequency<br/>(Frequência de Deploy)"]
            LT["Lead Time for Changes<br/>(Tempo de Espera por Mudança)"]
        end
        subgraph Estabilidade ["Qualidade & Estabilidade (Segurança)"]
            direction LR
            CFR["Change Failure Rate<br/>(Taxa de Falha de Mudanças)"]
            MTTR["Mean Time to Restore<br/>(Tempo Médio de Recuperação)"]
        end
    end

    style DORA fill:#f9f9f9,stroke:#333,stroke-width:2px
    style Velocidade fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style Estabilidade fill:#ffebee,stroke:#c62828,stroke-width:2px

Deployment Frequency (DF): Com que frequência sua equipe publica código em produção. (Meta Elite: Múltiplos deploys por dia).
Lead Time for Changes (LT): Quanto tempo leva para um commit de código sair da máquina do desenvolvedor e rodar com sucesso em produção. (Meta Elite: Menos de 1 hora).
Change Failure Rate (CFR): Qual a porcentagem de deploys em produção que causam falhas no sistema e exigem correção imediata (hotfix/rollback). (Meta Elite: 0% a 15%).
Mean Time to Restore (MTTR): Quanto tempo a equipe leva, em média, para recuperar o sistema de uma pane em produção. (Meta Elite: Menos de 1 hora).

📖 Exemplo Guiado: Calculando Capacidade e Métricas DevOps

A equipe de desenvolvimento da TecProExpress possui um histórico de desempenho nas últimas 3 Sprints de 15 dias:

Sprint 1: Entregou 24 Story Points.
Sprint 2: Entregou 30 Story Points (equipe mais focada).
Sprint 3: Entregou 21 Story Points (feriado e impedimento técnico).

1. Calculando a Velocidade Média do Time

$$\text{Velocidade Média} = \frac{24 + 30 + 21}{3} = 25 \text{ Story Points por Sprint}$$

Se o backlog total para o lançamento do novo módulo de motoristas tem um esforço estimado de 100 Story Points, o número de Sprints necessárias para entregar o projeto será: $$\text{Previsão de Sprints} = \frac{100 \text{ SP (Escopo)}}{25 \text{ SP (Velocidade)}} = 4 \text{ Sprints (aproximadamente 2 meses de trabalho)}$$

2. Painel de Indicadores DORA do Projeto (Simulado)

Com a adoção do pipeline CI/CD e Docker, o time registrou a seguinte performance no último mês:

Deploys em produção: 20 deploys efetuados no mês.
- Deployment Frequency: Aprox. 1 deploy por dia útil (Nível: Alto).
Tempo de Commit a Produção: Em média 4 horas (desde o merge na main até rodar no servidor).
- Lead Time for Changes: 4 horas (Nível: Alto).
Falhas pós-deploy: De 20 deploys, apenas 1 causou queda na API e exigiu rollback.
- Change Failure Rate: $1 / 20 = \mathbf{5%}$ (Nível: Elite).
Tempo de recuperação da falha: O rollback demorou exatamente 20 minutos para ser efetuado.
- Mean Time to Restore (MTTR): 20 minutos (Nível: Elite).

🛠️ Prática Obrigatória 1: Estimando o Backlog Ágil

Cenário: Planejando as entregas do projeto final de Engenharia de Software.

Crie uma tabela Markdown listando 5 requisitos/funcionalidades chave restantes para a consolidação final do seu projeto de grupo.
Atribua a cada funcionalidade uma estimativa em Story Points usando a escala de Fibonacci (1, 2, 3, 5, 8, 13). Justifique por que uma funcionalidade recebeu pontuação maior (ex: complexidade de banco de dados, API de terceiros) em comparação a uma simples (ex: CRUD básico).
Defina uma velocidade média hipotética para o seu grupo (ex: 8 SP por Sprint de 1 semana) e calcule em quantas Sprints o grupo entregará o backlog total.

🛠️ Prática Obrigatória 2: Diagnóstico DORA do Time

Cenário: Avaliando a maturidade operacional e qualidade do processo de desenvolvimento.

Crie uma seção no seu documento Markdown chamada "Painel DORA do Projeto".
Defina e explique como seu grupo coletará ou simulará cada uma das 4 métricas DORA no fluxo de trabalho de desenvolvimento de vocês.
Classifique o nível de maturidade simulada da sua equipe (Baixo, Médio, Alto ou Elite) com base em cada indicador de velocidade e estabilidade.

📤 Instruções de Entrega (Microsoft Teams)

Após estruturar os seus planos de estimativas e o painel DORA:

Salve o arquivo de especificações com o nome Atividade_19.md na pasta es-atv-19-metricas-estimativas/ do seu repositório GitHub.
Certifique-se de fazer o commit e push para o repositório público.
Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional: Imagine que um gerente de TI tradicional decida cobrar do time uma meta agressiva de aumentar a Deployment Frequency (Frequência de Deploy) para 5 vezes ao dia, porém sem investir em automação de testes unitários (JUnit) ou pipeline de CI. O que acontecerá inevitavelmente com a métrica Change Failure Rate (Taxa de Falha de Mudanças) e com o MTTR (Tempo de Recuperação) da equipe? Por que as métricas DORA devem ser analisadas de forma equilibrada? (Resposta: Aumentar a velocidade de deploy sem automação de testes fará com que códigos não-validados sejam publicados muito mais rápido, disparando a taxa de falhas pós-deploy (CFR) para níveis alarmantes. Além disso, sem testes ou infraestrutura resiliente, o time gastará muito mais tempo localizando a origem de bugs em produção, aumentando drasticamente o MTTR. As métricas DORA são propositalmente balanceadas: a velocidade de entrega (DF e LT) deve sempre caminhar de mãos dadas com a estabilidade e qualidade (CFR e MTTR), garantindo rapidez sem sacrificar a segurança). 📊⚖️🧠

🏆 ATIVIDADE 20: PROJETO FINAL AVANÇADO (FASE 2)

Parabéns! Você alcançou a reta final da disciplina de Engenharia de Software (Projetos II)! 🎓🚀

Durante este semestre desafiador, você não apenas aprendeu os conceitos teóricos clássicos, mas os aplicou de forma prática e corporativa: desde o levantamento inicial de escopo e diagramação de casos de uso até a estruturação de códigos robustos em Java 17 / Spring Boot, criação de testes unitários com JUnit, design de APIs documentadas com Swagger, automação via GitHub Actions, conteinerização com Docker e gestão operacional orientada a métricas DORA.

Hoje, é o dia de consolidar essa vasta jornada prática em um único documento de nível executivo industrial: o Dossiê de Engenharia de Software Avançado - Fase 2.

🎯 Objetivo da Aula

Ao final desta atividade, você será capaz de:

Consolidar artefatos de engenharia diversos em uma documentação técnica unificada e coerente de mercado.
Modelar a visão integradora de sistemas modernos cobrindo Processos, Arquitetura e DevOps.
Escrever resumos executivos profissionais focados em tomadas de decisões de negócios e viabilidade técnica.
Apresentar e defender o projeto técnico simulando o papel de um Arquiteto de Software ou CTO.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, a transformação digital foi um sucesso estrondoso. Graças ao trabalho árduo da equipe de engenharia, a empresa saiu do caos operacional e agora opera com pipelines automáticos, deploys seguros e isolados, e métricas claras de desempenho.

Os investidores e diretores da TecProExpress convocaram uma reunião geral do comitê executivo. Eles querem ver o resultado consolidado e a maturidade técnica da nova arquitetura de rotas de ponta a ponta antes de liberarem a verba milionária de expansão internacional do produto!

"Seu desafio como Chief Technology Officer (CTO) ou Arquiteto Líder da TecProExpress é estruturar e apresentar o Dossiê de Engenharia de Software Avançado. Você reunirá todos os artefatos desenvolvidos individualmente ou em grupo ao longo das últimas 10 semanas em uma documentação indestrutível e demonstrará a robustez operacional do seu projeto."

🧠 Fundamentos: A Visão Integradora Moderna

A engenharia moderna de software não enxerga a infraestrutura ou o processo de negócios como silos separados. O sucesso industrial depende da integração simétrica de três pilares centrais:

📊 O Mapa de Engenharia de Software Integrada

flowchart TD
    subgraph Pilar1 ["1. Engenharia de Processos (UML)"]
        direction TB
        P1["Diagrama de Atividades"] --> P2["Diagrama de Estados"]
    end

    subgraph Pilar2 ["2. Engenharia de Software (Arquitetura)"]
        direction TB
        A1["Arquitetura MVC & Patterns"] --> A2["Especificação Swagger/JSON"]
    end

    subgraph Pilar3 ["3. Engenharia de Operações (DevOps)"]
        direction TB
        D1["Workflow GitHub Actions (CI)"] --> D2["Docker Compose (Ambiente)"]
    end

    Pilar1 <-->|Alimenta| Pilar2
    Pilar2 <-->|Automatizado por| Pilar3

    style Pilar1 fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style Pilar2 fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style Pilar3 fill:#fff3e0,stroke:#ef6c00,stroke-width:2px

Engenharia de Processos: Modela o comportamento e as regras de negócio sob a notação UML padrão de mercado (Diagramas de Atividades e Transições de Estado).
Engenharia de Software: Define a separação estrutural de responsabilidades lógicas no código (Spring Boot, Thymeleaf e HTMX) e expõe as interfaces de comunicação claras e documentadas (Endpoints HTTP REST e Swagger).
Engenharia de Operações (DevOps): Automatiza a esteira de validações de qualidade e isola as dependências de infraestrutura, garantindo portabilidade absoluta (GitHub Actions CI/CD e contêineres Docker).

📖 Roteiro de Consolidação: Estrutura do Dossiê Final

A entrega final do seu projeto de Engenharia de Software deve seguir rigidamente a estrutura formal de um Dossiê Técnico de mercado. O seu documento final deve conter as seguintes seções estruturadas:

📑 Estrutura Sugerida do Dossiê Técnico

# DOSSIÊ DE ENGENHARIA DE SOFTWARE AVANÇADO: [NOME DO SEU PROJETO]

## 1. Introdução e Resumo Executivo
* Apresentação curta do problema de negócio e os objetivos principais do sistema.

## 2. Engenharia de Processos UML (Atividades 11 e 12)
* O Diagrama de Atividades atualizado com as raias de responsabilidades paralelas.
* O Diagrama de Transição de Estados da principal entidade de negócio (ex: Entrega, Pedido).

## 3. Arquitetura de Software e APIs REST (Atividades 13 e 14)
* Visão geral da arquitetura de classes e pastas (Padrões e MVC Spring Boot).
* O contrato OpenAPI/Swagger detalhado em formato YAML/JSON dos endpoints do sistema.

## 4. Gerência de Configuração e DevOps (Atividades 15 e 16)
* O gráfico GitFlow (`gitGraph`) simulando o fluxo de trabalho colaborativo seguro.
* O arquivo de configuração do pipeline de CI (`ci.yml`) do GitHub Actions.

## 5. Containerização e Segurança (Atividades 17 e 18)
* Os arquivos `Dockerfile` e `docker-compose.yml` criados para subir a infraestrutura.
* A Matriz de Ameaças de Segurança (STRIDE) e um exemplo prático de correção de vulnerabilidade.

## 6. Métricas Operacionais e de Desempenho (Atividade 19)
* O cálculo de velocidade estimada da equipe (Story Points e Fibonacci).
* O diagnóstico simulado dos 4 indicadores DORA das práticas DevOps do grupo.

## 7. Conclusões e Aprendizados
* Breve parágrafo auto-avaliativo sobre os aprendizados práticos do grupo durante a disciplina.

🛠️ Prática Obrigatória: A Consolidação do Dossiê de Engenharia

Cenário: Organizando o repositório e a apresentação final do produto de software.

Como equipe de engenharia do projeto semestral de vocês:

Reúnam-se para revisar todos os artefatos práticos produzidos individualmente ou coletivamente nas Atividades 11 a 19.
Corrijam qualquer imperfeição ou feedback técnico anterior (ex: ajustar a sintaxe de um diagrama Mermaid, corrigir um endpoint Swagger com verbo HTTP incorreto ou consertar uma credencial vulnerável no docker-compose).
Criem o arquivo unificado Dossie_Engenharia_Fase_2.md na pasta final de entregas.
Garantam que todos os diagramas Mermaid do documento final renderizem perfeitamente, usando aspas duplas nos nós contendo caracteres especiais ou parênteses, evitando bugs visuais.

📤 Instruções de Entrega (Microsoft Teams e GitHub)

Após estruturar o seu Dossiê Técnico Final Avançado:

Salve o documento completo com o nome Dossie_Engenharia_Fase_2.md na pasta es-atv-20-projeto-final/ na raiz do seu repositório Git público do grupo.
Certifique-se de realizar o commit final com uma mensagem profissional (Ex: docs: consolidação do dossiê de engenharia fase 2).
Submeta o link do repositório final e a cópia em PDF do dossiê no Microsoft Teams para avaliação e agendamento da apresentação oral presencial para o professor e convidados.

💡 Checkpoint de Lógica

[!IMPORTANT] Reflexão Profissional e de Carreira: Ao final deste ciclo, qual o real valor de um Engenheiro de Software moderno que sabe modelar requisitos e processos de negócio (UML), arquitetar código limpo e desacoplado (MVC/Spring Boot), testar de forma automatizada (CI/CD) e orquestrar infraestrutura em nuvem de forma resiliente (Docker)? Como esse conjunto integrado de competências se traduz em vantagens competitivas em relação a um programador tradicional que apenas digita código bruto sem compreender arquitetura ou DevOps? (Resposta: O engenheiro completo ("T-Shaped") consegue enxergar a visão holística do produto. Ele não se limita a escrever linhas de código vulneráveis e isoladas; ele projeta sistemas seguros, escaláveis e altamente portáveis. Isso reduz custos operacionais drásticos para a empresa, elimina falhas críticas pós-deploys em produção e acelera a inovação operacional medida cientificamente pela DORA. Profissionais com essa visão de ponta a ponta são extremamente disputados por grandes corporações globais, assumindo papéis de liderança técnica como Tech Leads, Arquitetos de Software e CTOs). 🏆📈🧠

Keyboard shortcuts

TECNÓLOGO EM GESTÃO DA TI - FATEC