🏠 Página Inicial

🎓 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. 🛡️

[!TIP] Reflexão Profissional: "A tecnologia move o mundo, mas a gestão da informação é o que o mantém girando." 🌐

🏗️ Configuração do Ambiente

Para começar seus estudos práticos, acesse a página de 🛠️ Ferramentas Recomendadas para baixar e configurar os softwares necessários. 🛡️

📚 Biblioteca Digital Recomendada

Para complementar os estudos teóricos e práticos, acesse nossa curadoria de livros técnicos abrangendo desenvolvimento, arquitetura, DevOps e metodologias:

• 📖 Dev-Livros: Repositório de Livros Técnicos 📚🚀

📱 Código QR do Portal

🛠️ 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

🧩 Extensões Essenciais (VS Code)

🐘 Banco de Dados

☕ Linguagens e Ambientes

⛓️ Controle de Versão e Gestão

📐 Modelagem e Design

🧪 Aprendizado e Algoritmos

🎨 Multimídia e Imagem

🎬 Áudio e Vídeo

📂 Utilitários Sistêmicos

[!IMPORTANT] 📗 Dica de Uso: Para os bancos de dados (MySQL e PostgreSQL), recomendamos desativar o serviço no boot automático para economizar RAM, iniciando-os manualmente apenas quando necessário.

📚 MÓDULO: BANCO DE DADOS

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. 🛡️🧩

Objetivo: Dominar a engenharia de dados, garantindo a integridade e a performance das informações em sistemas transacionais de alta escala.

🏗️ Mapa de Conhecimento

Explore os pilares que sustentam o universo dos dados:

📊 Visão Geral

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
            Top Uniformes
            Persistência Poliglota

💡 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. 🛡️

📚 PLANO DE ENSINO DETALHADO (SYLLABUS)

Bem-vindo(a) ao curso de Engenharia de Dados e Bancos de Dados Relacionais. Este material foi estruturado para atender às demandas da arquitetura moderna. 🛡️🧩

Objetivo Curricular: Formar profissionais capazes de modelar, criar, otimizar e administrar bancos de dados relacionais de alta performance (MySQL 8.4 e PostgreSQL 17).

📗 Stack Tecnológica Abordada

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

📗 Mapa da Jornada Curricular

O curso é dividido em 7 Unidades de Competência:

📊 Jornada de Aprendizado

mindmap
    root((🚀 Engenharia de Dados))
        Unidade I: Fundamentos
            SGBD vs Planilhas
            Transações ACID
        Unidade II: Modelagem
            DER / MER
            Normalização
        Unidade III: SQL Básico
            DDL / DML
            Constraints
        Unidade IV: SQL Avançado
            Joins / Agregações
            JSON Moderno
        Unidade V: Estudo de Caso
            TOP UNIFORMES
            Arquitetura Real
        Unidade VI: NoSQL (Docs)
            MongoDB 7.0
            Aggregation
        Unidade VII: NoSQL (Colunar)
            Apache Cassandra
            Model-by-Query

📗 Metodologia de Fixação

Para garantir sua evolução como Arquiteto(a), cada módulo conta com:

1. ✅ Revisão: Validação de conceitos teóricos.
2. 💻 Desafios: Práticas do "Mundo Real" na IDE.
3. 📖 Spoilers: Resoluções comentadas para entender o "porquê".

💡 Dica do Especialista: O mercado valoriza o profissional que entende a lógica por trás dos dados, não apenas quem decora comandos. Prepare seu terminal e bons estudos! 🚀🛡️

✍️ PREFÁCIO E AUTOR

👋 Boas-vindas

Caro(a) acadêmico(a)! Você está iniciando um processo de transformação fundamental para o sucesso no mercado de tecnologia moderno. 🛡️🧩

Objetivo: Introduzir a jornada de aprendizado e contextualizar a importância estratégica do domínio de bancos de dados na era do Big Data.

📖 Apresentação da Jornada

🌊 O Desafio dos Dados

Escrever este material foi um desafio recompensador. Lidamos hoje com a magnitude do Big Data, impulsionada por redes sociais, IoT e nuvem. Diante deste cenário, surgiram conceitos como o NoSQL. 🛡️

🗺️ Roteiro de Aprendizado

Nesta trilha, consolidaremos o conhecimento sobre o modelo relacional:

🏗️ O Banco de Dados é a Ferramenta

O banco de dados é vital, mas o "coração" da sua aplicação é a Engenharia de Software. Nosso objetivo é que você domine essa ferramenta para construir softwares inovadores. 🛡️

Desejamos sucesso em sua jornada acadêmica! 🚀🛡️

✍️ SETUP MYSQL

📗 PASSO: Preparando o Ambiente 🐬

Para acompanhar as aulas práticas, você deve configurar o seu laboratório local com as ferramentas oficiais. Siga as instruções abaixo: 🛡️🧩

1. Download do Instalador Global

Acesse o portal oficial dev.mysql.com/downloads/installer/ e escolha a versão MySQL Installer Community (Web ou Full). O instalador permite gerenciar todos os produtos de uma vez.

2. Configuração do Servidor (8.4 LTS)

No assistente de instalação, selecione a opção "Server only" ou "Custom" e inclua o MySQL Server 8.4.

• ⚙️ Tipo de Máquina: Escolha "Development Computer" (Gasta menos memória).
• 🔌 Porta de Comunicação: O padrão é a 3306.
• 🔒 Autenticação: Selecione "Use Strong Password Encryption" (Padrão do MySQL 8).

3. Instalando a IDE (Workbench 8.0)

Após configurar o servidor, instale o MySQL Workbench 8.0.x. Ele será nossa ferramenta visual (IDE) para escrever os comandos SQL e visualizar os diagramas.

4. Senha de Administrador (Root)

Durante a instalação, você definirá a senha do usuário root.

⚠️ IMPORTANTE: Anote esta senha em um local seguro. Ela é a chave mestra do seu banco de dados e será exigida em todos os nossos exercícios práticos! 🛡️

✍️ SETUP POSTGRESQL

📗 PASSO: Preparando o Ambiente 🐘

Para explorar o SGBD relacional mais avançado do mundo, você deve configurar o ecossistema PostgreSQL em sua máquina. Siga os passos técnicos abaixo: 🛡️🧩

1. Download do Instalador Profissional

Acesse o portal da EnterpriseDB (EDB) em enterprisedb.com/downloads/postgres e selecione a versão PostgreSQL 17 para Windows x86-64.

2. Configuração do Servidor (PostgreSQL 17)

Execute o instalador e mantenha os componentes padrão selecionados (Server, pgAdmin 4, Stack Builder e Command Line Tools).

• 🔌 Porta de Comunicação: O padrão universal do Postgres é a 5432.
• 🌍 Localidade (Locale): Selecione "[Default Locale]" ou "Portuguese, Brazil" para garantir o suporte correto a caracteres especiais.

3. Gerenciamento Visual (pgAdmin 4)

O pgAdmin 4 é a ferramenta de administração web-based que instalamos junto com o servidor. Ele será nossa central de controle para criar bancos, gerenciar usuários e executar scripts.

4. Senha do Superusuário (Postgres)

Diferente do MySQL (root), o usuário administrativo padrão aqui é o postgres.

⚠️ IMPORTANTE: Defina uma senha forte para o usuário postgres e guarde-a bem. Sem ela, você não conseguirá criar novos bancos de dados ou esquemas para os nossos estudos de caso! 🛡️

✍️ SETUP NOSQL (MongoDB e Cassandra)

A engenharia de plataformas modernas exige o domínio de diferentes ecossistemas NoSQL. Abaixo, você configurará o ambiente orientado a documentos (MongoDB) e, logo em seguida, o ecossistema distribuído de alta escala (Apache Cassandra 4.x). 🛡️🧩

🍃 PARTE 1: SETUP MONGODB 7.0

📗 PASSO 1: Preparando o Ambiente

Para explorar a flexibilidade dos bancos de dados orientados a documentos, você deve configurar o ecossistema MongoDB em sua máquina Windows. Siga os passos técnicos abaixo:

1. Download do Community Server Acesse o portal oficial mongodb.com/try/download/community e selecione a versão mais recente em formato MSI para Windows.

2. Configuração do Servidor (v7.0 LTS) Execute o instalador e escolha a opção "Complete".

   • ⚙️ Instalar como Serviço: Marque a opção "Install MongoDB as a Service" para que ele inicie automaticamente.
   • 🔌 Porta de Comunicação: O padrão universal do MongoDB é a 27017.
   • 📁 Diretórios de Dados: Mantenha os caminhos padrão em C:\Program Files\MongoDB\Server\7.0\data\.

3. Interface Visual (MongoDB Compass) Durante a instalação, certifique-se de manter marcada a opção "Install MongoDB Compass". Ele é a IDE gráfica onde visualizaremos nossos documentos JSON (BSON).

4. Ferramenta de Linha de Comando (mongosh) Para interagir via terminal, recomendamos o MongoDB Shell (mongosh). Ele pode ser instalado separadamente via Download Center.

📗 PASSO 2: Conectando a IDE (Compass)

O erro clássico ao iniciar com NoSQL é confundir o servidor local com a nuvem (Atlas). Veja como se conectar corretamente: 🛡️

• 🏠 Conexão Local (Instalação Padrão): Ao abrir o Compass, a tela de New Connection traz a URI padrão mongodb://localhost:27017. Apenas clique em Connect. (Na instalação local de laboratório não há usuário/senha).
• ☁️ Conexão Distribuída (MongoDB Atlas): Se o projeto utilizar o banco oficial da nuvem MongoDB, a plataforma te dará uma Connection String complexa (ex: mongodb+srv://aluno:senha123@cluster-dev.mongodb.net/). Cole o link na barra de conexão do Compass e clique em Connect.

💡 Nota do Especialista: O MongoDB sem senha local é prático para estudar, mas em produção a segurança de controle de acesso (RBAC) é absolutamente inegociável! 🚀🛡️

⚙️ PARTE 2: SETUP APACHE CASSANDRA 4.x

Bem-vindo à engenharia de Alta Disponibilidade Clássica. Para interagir com o massivo volume de dados promovido pelo Big Data, o Apache Cassandra será configurado via orquestração de containers.

📗 PASSO 1: A Natureza do Ecossistema Peer-to-Peer

O Cassandra possui uma forte diferença de softwares tradicionais: Não há um servidor "Mestre" e subordinados "Escravos". Todos os servidores (Nós) possuem os mesmos poderes e dividem matematicamente qual fatia dos dados cada um segura.

⚠️ Atenção (Reserva de Memória): O motor distribuído é faminto por recursos (baseado na Java Virtual Machine). Antes de iniciar, certifique-se de que o Docker Desktop na sua máquina esteja rodando e tenha pelo menos 4GB de RAM livres no Sistema Operacional.

📗 PASSO 2: Implementando via Docker Compose

Crie uma pasta de trabalho vazia (ex: C:\LabCassandra) e dentro dela crie um arquivo chamado docker-compose.yml. Adicione o manifesto abaixo:

version: '3.8'

services:
  cassandra-node1:
    image: cassandra:4.1
    container_name: cassandra
    restart: always
    ports:
      - "9042:9042" # Porta padrão nativa do protocolo CQL
    environment:
      - CASSANDRA_CLUSTER_NAME=LabCurso
      # Limitadores cruciais para que a máquina acadêmica não trave o seu PC
      - MAX_HEAP_SIZE=512M
      - HEAP_NEWSIZE=128M
    volumes:
      - cassandra_data:/var/lib/cassandra

volumes:
  cassandra_data:

Abra o Terminal nesta pasta e levante seu cluster rodando o comando: docker-compose up -d

📊 Arquitetura de Hospedagem Virtual

flowchart TD
    HOST[💻 Docker Host Windows] --> C_ENG[🐳 Engine Docker]
    C_ENG --> CONT[⚙️ Container: Cassandra 4.x]
    CONT --> VOL[(💾 Volume Permanente<br/>cassandra_data)]

📗 PASSO 3: Validando a Saúde do Nó (Ring)

Diferente de sistemas legados, no Cassandra utilizamos poderosas ferramentas nativas de telemetria. Escreva no seu terminal:

docker exec -it cassandra nodetool status

Para prosseguir, você deverá obrigatoriamente ver no Console as letras UN:

• U = Up (O nó está Ligado e Operando via Gossip).
• N = Normal (O nó está aceitando conexão cliente).

💡 Dica de Arquiteto: Você notará aí o campo de telemetria Load (Carga). No Cassandra, os bytes gravados se espalham em um anel de N servidores, portanto o Load exibe apenas a fração mínima individual daquele HD específico! 🚀

📗 PASSO 4: Conexão Interativa via CQLSH

Agora que nossa base opera estavelmente, invoque o cliente do shell de Cassandra Query Language (CQLSH):

docker exec -it cassandra cqlsh

Neste momento o terminal conectará exibindo "Connected to LabCurso na 127.0.0.1:9042". Diferente das outras pilhas SQL onde digitamos CREATE DATABASE, aqui criamos o nosso Keyspace, sendo obrigatório definir imediatamente a matemática da replicação geográfica.

Execute o CQL abaixo para ligar o Laboratório Acadêmico:

CREATE KEYSPACE loja_academica WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

-- Entrando no ambiente ativo
USE loja_academica;

🗄️ UNIDADE I: FUNDAMENTOS DA ENGENHARIA DE DADOS

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: Compreender a diferença técnica entre dados e informações, a anatomia de um SBD moderno e a soberania do modelo relacional frente a arquivos ou planilhas.

📗 PASSO 1: O Ciclo de Vida da Informação

Na engenharia de software de alta performance, não trabalhamos apenas com "pastas". Trabalhamos com ativos que seguem um fluxo de valor:

📊 Fluxo de Processamento de Dados

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]

💡 Entenda a Diferença:

1. DADO: Um fato isolado, por exemplo, o número 105. Sozinho, ele é mudo.
2. INFORMAÇÃO: O dado contextualizado. 105 é a quantidade de itens em estoque do produto "Placa-Mãe X".
3. BANCO DE DADOS: Uma coleção de dados logicamente relacionados, projetada para refletir um aspecto do mundo real (Mini-mundo).

📗 PASSO 2: A Anatomia do Sistema de Banco de Dados (SBD)

Para a MySQL 8.4 LTS ou PostgreSQL 17, o sistema é composto por camadas que separam o usuário do arquivo físico:

📊 Interação Usuário-SGBD

flowchart TD
    U1[👤 DBA / Desenvolvedor]
    U2[🌐 Aplicação Web/Mobile]
    
    subgraph SBD [Sistema de Banco de Dados]
        UC1((Executar Queries SQL))
        UC2((Consultar Metadados))
        UC3[(Persistência em Disco)]
    end
    
    U1 --> UC1
    U1 --> UC2
    U2 --> UC1
    UC1 -.-> UC3

📗 Definição de Componentes (Stack 2026)

• 🏦 Banco de Dados (DB): Repositório físico onde os bytes são armazenados.
• 🏗️ SGBD (DBMS): O motor de execução (Engine). Softwares como MySQL Workbench e pgAdmin são apenas interfaces (IDEs) que conversam com o SGBD real.
• 📚 Catálogo: Onde o SGBD guarda a "receita" do banco (tabelas, nomes de colunas, permissões).

📗 PASSO 3: Por que não usar o Excel? (Planilhas vs. SGBD)

🐘 Panorama Tecnológico Moderno

O mercado atual é dominado pela Persistência Poliglota. Abaixo, os pilares que utilizaremos neste curso:

1. MySQL 8.4 LTS: Foco em velocidade e simplicidade para aplicações transacionais massivas.
2. PostgreSQL 17: Foco em extensibilidade e inteligência de dados nativa.

💡 Dica do Especialista: O grande trunfo do SGBD é a Independência de Dados, permitindo que o banco mude sem que você tenha que reescrever toda a sua aplicação. 🚀🛡️

🏗️ AS 4 CARACTERÍSTICAS FUNDAMENTAIS DOS SGBDS

Para que um software seja considerado um verdadeiro SGBD de Elite (como o PostgreSQL 17 ou o MySQL 8.4), ele deve prover quatro pilares arquiteturais que o elevam acima de simples sistemas de arquivos. 🛡️🧩

Objetivo: Analisar os pilares que garantem a abstração, segurança e concorrência em sistemas de banco de dados modernos.

📗 PASSO 1: Natureza Autodescritiva (O Catálogo)

Diferente de uma planilha Excel, onde você precisa "adivinhar" o que cada coluna significa, um SGBD é autodescritivo. Ele armazena não apenas os dados, mas a definição completa da estrutura (Metadados).

• 📚 Catálogo do Sistema: Um banco de dados interno que guarda nomes de tabelas, tipos de dados, restrições e permissões.
• 🛡️ Vantagem: Qualquer aplicação pode consultar o catálogo para entender como interagir com os dados sem intervenção humana.

📗 PASSO 2: Independência entre Programa e Dados

Esta é a característica que permite a Abstração de Dados. O SGBD atua como um tradutor entre o que o usuário vê e como o dado é salvo no disco.

📊 Modelo de Três Esquemas (ANSI/SPARC)

flowchart TD
    EXT["📱 NÍVEL EXTERNO<br/>(Visões dos Usuários)"] --> CON["📐 NÍVEL CONCEITUAL<br/>(Estrutura Lógica / Tabelas)"]
    CON --> INT["💾 NÍVEL INTERNO<br/>(Estrutura Física / Arquivos)"]

1. Independência Lógica: Podemos mudar a estrutura de uma tabela sem quebrar as aplicações.
2. Independência Física: Podemos mudar o banco de disco (ex: HDD para SSD) sem alterar o código SQL.

📗 PASSO 3: Suporte a Múltiplas Visões (Views)

Um banco de dados corporativo pode ter 500 tabelas, mas um usuário precisa ver apenas o que é relevante para ele.

📊 Exemplo de Visões por Perfil

flowchart LR
    A1[👤 Analista Financeiro]
    A2[👤 Gerente de Vendas]
    
    subgraph SGBD [SGBD: Banco Corporativo]
        V1((View: Fluxo de Caixa))
        V2((View: Metas Mensais))
    end
    
    A1 --> V1
    A2 --> V2

📗 PASSO 4: Compartilhamento e Processamento de Transações

O SGBD é o Maestro da Concorrência. Ele garante que se dois usuários tentarem comprar o último ingresso ao mesmo tempo, apenas um consiga, sem corromper o sistema.

💡 Dica do Especialista: A arquitetura de camadas blinda sua aplicação contra mudanças futuras. Não codifique pensando no arquivo, codifique pensando no modelo! 🚀🛡️

🛡️ TRANSAÇÕES E AS PROPRIEDADES ACID

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

Objetivo: Dominar os pilares ACID e o controle transacional (TCL) que garantem a integridade dos dados em cenários de alta concorrência.

📗 PASSO 1: O Escudo de Confiança (ACID)

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

1. ⚛️ Atomicidade (Tudo ou Nada): Se uma operação de 10 falhar, todas são desfeitas.
2. ⚖️ Consistência (Regras): O banco garante que nenhuma regra de integridade seja quebrada (ex: CPF único).
3. 🔒 Isolamento (Invisibilidade): Uma transação "não sabe" o que a outra está fazendo enquanto ocorre.
4. 💾 Durabilidade (Permanência): Uma vez feito o COMMIT, o dado está salvo mesmo em falhas de energia.

📗 PASSO 2: Fluxo da Transação (TCL)

📊 Lógica de Controle Transacional

flowchart TD
    START[▶️ BEGIN TRANSACTION] --> OP1[📝 UPDATE Saldo Lançamento]
    OP1 --> OP2[📝 UPDATE Saldo Recebimento]
    OP2 --> DEC{❓ Sucesso em Tudo?}
    DEC -- SIM --> COM[✅ COMMIT: Salva em Disco]
    DEC -- NÃO --> ROL[❌ ROLLBACK: Desfaz Tudo]
    COM --> END[🏁 Fim]
    ROL --> END

📗 PASSO 3: Cenário do Mundo Real (Transferência Bancária)

Sem transações ACID, se a energia cair após tirar o dinheiro de João e antes de entregar para Maria, o dinheiro simplesmente desapareceria.

🛠️ Implementação em SQL (Universal)

START TRANSACTION; -- Ou BEGIN no PostgreSQL
  UPDATE contas SET SALDO = SALDO - 500 WHERE NOME = 'Joao';
  UPDATE contas SET SALDO = SALDO + 500 WHERE NOME = 'Maria';
COMMIT; -- Se houver erro em qualquer linha, execute ROLLBACK;

📗 PASSO 4: Os Atores do Ecossistema

📊 Papéis e Responsabilidades

flowchart TD
    DBA[👮 Administrador: DBA]
    ENG[🛠️ Engenheiro de Dados]
    USER[👤 Usuário Final]
    
    subgraph SGBD [SGBD: Motor Transacional]
        UC1((Configurar Isolamento))
        UC2((Escrever Scripts Robustos))
        UC3((Realizar Operações))
    end
    
    DBA --> UC1
    ENG --> UC2
    USER --> UC3

💡 Dica do Especialista: Níveis de isolamento altos garantem segurança total, mas podem reduzir a performance. Equilíbrio é a chave! 🚀🛡️

✅ VANTAGENS ESTRATÉGICAS E A ERA DA NUVEM

A decisão de migrar de um amontoado de arquivos para um SGBD Gerenciado não é apenas técnica, é uma decisão de sobrevivência do negócio. 🛡️🧩

Objetivo: Identificar as vantagens competitivas do uso de SGBDs e compreender os modelos de entrega em nuvem (IaaS, PaaS, SaaS) para bancos de dados modernos.

📗 PASSO 1: Por que sua empresa precisa de um SGBD?

Diferente de sistemas manuais, o SGBD oferece garantias que protegem o capital intelectual da organização:

1. ♻️ Controle de Redundância: Evita que o dado seja armazenado em múltiplos locais.
2. 🔒 Restrição de Acesso: Regras granulares por perfil de usuário.
3. 💪 Integridade Referencial: Impede a exclusão de dados vinculados a outros registros.
4. ⚡ Resiliência (Backup): Restauração automática em caso de falhas críticas.

📗 PASSO 2: A Nuvem e o Banco de Dados como Serviço (DBaaS)

Atualmente, não instalamos mais servidores físicos em salas geladas. Utilizamos a Cloud Computing para escalar nossos SGBDs de forma elástica.

📊 Modelos de Responsabilidade na Nuvem

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

📗 Diferenciando os Modelos

• SaaS: Você usa o software pronto (ex: Salesforce).
• PaaS (Foco do Dev): Você contrata um banco pronto (ex: AWS RDS). O provedor cuida do hardware e você do SQL.
• IaaS: Você aluga a máquina e instala o MySQL/Postgres. Controle total, mas responsabilidade alta.

📗 PASSO 3: O Impacto da Elasticidade

Um sistema Elástico consegue dobrar sua capacidade durante uma Black Friday e reduzi-la na manhã seguinte para economizar. Isso só é possível com SGBDs integrados a infraestruturas cloud.

💡 Insight de Mercado: Bancos em nuvem permitem que pequenas startups tenham a mesma potência de gigantes, pagando apenas pelo que consomem (Pay-as-you-go). 🚀🛡️

🏁 CONSIDERAÇÕES FINAIS: UNIDADE I

Parabéns! Você concluiu a base fundamental da Engenharia de Dados. Agora você compreende que um banco de dados não é apenas um lugar para "guardar coisas", mas um ecossistema complexo que garante a integridade e a sobrevivência da informação. 🛡️🧩

🏗️ Resumo da Jornada

Nesta unidade, navegamos por conceitos que separam profissionais de amadores:

• A tríade do SBD: Dados, Metadados (Catálogo) e Software (SGBD).
• Abstração ANSI/SPARC: A arquitetura de 3 níveis que garante que você possa trocar o hardware sem quebrar o código.
• O Escudo ACID: A garantia matemática de que transações nunca deixarão o banco em estado inconsistente.
• Custo-Benefício: Por que investir em um SGBD (MySQL/Postgres) em vez de persistir dados em planilhas ou arquivos.

✅ Verificação de Aprendizagem (Unidade I)

Teste seu domínio sobre os fundamentos antes de avançarmos para a Modelagem Relacional.

📝 Questões Objetivas

1. Qual propriedade ACID garante que, se um servidor de banco de dados for desligado abruptamente logo após a confirmação de uma transação (COMMIT), os dados não serão perdidos? a) Atomicidade b) Consistência c) Isolamento d) Durabilidade

2. Na arquitetura de três esquemas (ANSI/SPARC), qual nível lida com a forma como os dados são fisicamente armazenados em blocos no disco rígido ou SSD? a) Nível Externo b) Nível Conceitual c) Nível Interno d) Nível de Aplicação

3. O que define a natureza "autodescritiva" de um SGBD moderno como o PostgreSQL 17? a) O fato de o software vir com um manual de instruções em PDF. b) O armazenamento de metadados no Catálogo do Sistema. c) A capacidade do SGBD de escrever código SQL sozinho. d) O uso de Inteligência Artificial para nomear tabelas.

🧠 Desafios Práticos (Casos de Estudo)

Desafio 1: Análise de Riscos Uma startup de delivery está usando arquivos .json salvos em uma pasta do servidor para armazenar os pedidos dos clientes. Liste dois riscos críticos que eles correm por não utilizarem um SGBD com suporte a transações ACID.

Desafio 2: Escolha de Modelo Você foi contratado para projetar o sistema de uma nova biblioteca. O cliente pergunta: "Podemos usar o Excel, já que é mais barato?". Prepare uma justificativa técnica curta explicando por que o controle de concorrência do SGBD é vital para uma biblioteca com 50 terminais de consulta.

📐 UNIDADE II: ARQUITETURA E MODELO RELACIONAL

Bem-vindo à unidade mais fundamental da sua carreira como projetista de sistemas. Aqui, sairemos do "o que é" um banco de dados e entraremos no "como" estruturá-lo para que ele suporte o crescimento de uma corporação sem colapsar sob o peso da inconsistência. 🛡️🧩

Objetivo: Dominar os fundamentos teóricos e práticos do modelo relacional, compreendendo a anatomia de tabelas e as regras de integridade que sustentam sistemas de alta disponibilidade.

📗 PASSO 1: O Legado de Edgar F. Codd (IBM, 1970)

O Modelo Relacional não surgiu por acaso. Ele foi criado por E. F. Codd para substituir modelos antigos e complexos. Sua genialidade foi basear o armazenamento de dados em Lógica Matemática e Teoria dos Conjuntos.

💡 Por que o Modelo Relacional venceu?

1. Simplicidade: Tudo é representado como uma tabela (Relação).
2. Base Matemática: Permite que o SGBD otimize as consultas de forma previsível e segura.
3. Independência: O modo como o dado é guardado no disco não interfere em como você o consulta via SQL.

📗 PASSO 2: Panorama de Mercado (SGBDR)

Embora o curso foque em MySQL 8.4 e PostgreSQL 17, é vital conhecer os principais "players" que utilizam o modelo relacional:

📗 PASSO 3: Os Pilares do Modelo

Para o arquiteto de dados, o modelo relacional se resume a três dimensões:

📊 Visão Geral do Modelo Relacional

mindmap
    root((Modelo Relacional))
        Estrutura
            Tabelas (Relações)
            Linhas (Tuplas)
            Colunas (Atributos)
        Integridade
            Chaves Primárias (PK)
            Chaves Estrangeiras (FK)
            Domínios de Dados
        Manipulação
            SQL (Linguagem Padrão)
            Álgebra Relacional

💡 Dica do Especialista: Um banco mal modelado pode ser "consertado" com hardware caro, mas nunca será eficiente. Dedique tempo à Unidade II; ela é o alicerce de todo o seu ecossistema. 🚀🛡️

📐 O MODELO RELACIONAL (FUNDAMENTOS)

O Modelo Relacional é a tradução da matemática para blocos de construção de sistemas. Ele organiza os dados em estruturas bidimensionais chamadas Relações (popularmente conhecidas como tabelas). 🛡️🧩

Objetivo: Compreender a terminologia técnica do modelo relacional e a anatomia estrutural de tabelas, tuplas e atributos.

📗 PASSO 1: Mapeamento de Terminologia

Para ser um Engenheiro de Dados respeitado, você deve dominar tanto a linguagem acadêmica (Teoria) quanto a linguagem de mercado (Prática/SQL).

📗 PASSO 2: Anatomia de uma Relação (Tabela)

Observe como o SGBD (MySQL ou PostgreSQL) visualiza a estrutura de uma tabela internamente:

📊 Dicionário de Dados do Produto

erDiagram
    PRODUTO {
        int id_produto PK
        string nome
        decimal preco
    }

📗 Visualização dos Dados (Tuplas)

Abaixo, a representação de como as tuplas (registros) preenchem a estrutura acima:

💡 Regras de Ouro de uma Relação:

1. Ordem Inexistente: Na matemática e no banco, a ordem das linhas não importa.
2. Atomicidade: Cada célula deve conter apenas um único valor.
3. Unicidade: Não existem linhas iguais (garantido pela PK).

📗 PASSO 3: O Valor NULL (Nulo)

O valor NULL é um conceito especial do modelo relacional que representa:

• Informação desconhecida ou não aplicável.

⚠️ Nota para o Arquiteto: NULL não é ZERO nem VAZIO! Trate o NULL como um "buraco negro" de informação. Evite usá-lo em excesso para não complicar cálculos SQL. 🚀🛡️

🎨 INTRODUÇÃO À MODELAGEM E MER

Modelar é a arte de simplificar a realidade sem perder a sua essência. Na Engenharia de Dados, o Modelo Entidade-Relacionamento (MER) é a ferramenta de comunicação universal entre o cliente e o desenvolvedor. 🛡️🧩

Objetivo: Compreender as fases da modelagem de dados e a importância do MER/DER na abstração do mundo real para sistemas computacionais.

📗 PASSO 1: O Processo de Abstração

Para construir um banco de dados, não olhamos para "tudo". Olhamos para o Mundo Real e extraímos dele o Mini-mundo (a parte que interessa ao software).

📊 Ciclo de Abstração

flowchart TD
    REAL[🌍 Mundo Real] --> ABS{🧠 Abstração}
    ABS --> MINI[💻 Mini-mundo]

📗 PASSO 2: Os Três Níveis da Modelagem

Dividimos o projeto em três fases para evitar erros custosos:

1. 🎯 Modelo Conceitual: Foca na regra de negócio. Desenho abstrato (DER).
2. 🏗️ Modelo Lógico: Traduz o DER para tabelas. Define PKs/FKs.
3. ⚙️ Modelo Físico: É o código SQL final (MySQL 8.4 ou PostgreSQL 17).

📗 PASSO 3: A Notação de Peter Chen (1976)

Para desenhar o Diagrama Entidade-Relacionamento (DER), utilizamos símbolos universais:

📗 PASSO 4: Definindo Entidades no Modelo Lógico

Uma entidade representa um conjunto de objetos da mesma natureza. No nível lógico, transformamos isso em tabelas estruturadas.

📊 Estrutura da Entidade Aluno

erDiagram
    ALUNO {
        int matricula PK
        string nome
    }

📗 Classificação de Entidades:

• 🏢 Concretas: Coisas tangíveis (ex: CARRO, ALUNO).
• 🧩 Abstratas: Eventos ou conceitos (ex: VENDA, MATRÍCULA).

💡 Dica do Arquiteto: O modelo conceitual é a única fase onde o cliente valida o negócio. Nunca pule para o código SQL antes de ter o DER aprovado! 🚀🛡️

🏷️ ANATOMIA DE ATRIBUTOS E TUPLAS

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: 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).

📗 PASSO 1: O que define um Atributo?

Um Atributo é a menor unidade de informação relevante para uma entidade. Representa uma propriedade ou característica.

💡 Regras de Integridade do Atributo:

1. Atomicidade: O valor deve ser indivisível (ex: separar Rua e Bairro).
2. Domínio: Possui um tipo de dado definido (INT, VARCHAR, DATE) que limita a inserção.

📗 PASSO 2: A Tupla (O Registro Vivo)

Uma Tupla é o conjunto de valores de atributos que descrevem uma ocorrência específica.

📊 Visão de uma Tupla de Dados

flowchart LR
    A[ID: 10] --- B[NOME: ANA] --- C[CARGO: DBA]

📗 PASSO 3: O Atributo-Chave (Chave Primária - PK)

Nenhuma tabela profissional existe sem uma Chave Primária. Ela é o DNA da tupla, garantindo que nenhum dado seja duplicado.

🛡️ As Duas Leis da PK:

1. 🚫 Unicidade: O valor da PK nunca se repete.
2. ❗ Obrigatoriedade: O campo da PK é sempre NOT NULL.

📊 Representação de Tabela com PK

erDiagram
    PRODUTO {
        int id_produto PK
        string descricao
        decimal preco
    }

📗 PASSO 4: Restrições de Valor (NOT NULL e UNIQUE)

Além da PK, configuramos atributos com restrições rígidas:

• 🚫 NOT NULL: Preenchimento obrigatório.
• 💎 UNIQUE: Valor não repetido, mas permite nulos (ex: E-mail).

💡 Insight de Engenharia: Em diagramas clássicos, se um atributo estiver sublinhado, ele é a Chave Primária. No SQL Moderno, usamos a tag PRIMARY KEY. 🚀🛡️

🌿 ATRIBUTOS COMPOSTOS, MULTIVALORADOS E DERIVADOS

Na modelagem de alto nível, nem todo dado é uma simples "string" ou "número". Existem estruturas que exigem um olhar clínico do Arquiteto de Dados para evitar redundância e falhas de projeto. 🛡️🧩

Objetivo: Diferenciar tipos avançados de atributos e dominar as estratégias de decomposição para garantir a atomicidade dos dados e a performance do SGBD.

📗 PASSO 1: Atributo Composto (Hierarquia)

Ocorre quando um atributo pode ser subdividido em partes menores. No banco físico, ele deve ser decomposto em colunas individuais.

📊 Decomposição do Endereço

erDiagram
    CLIENTE {
        int id_cliente PK
        string logradouro
        string numero
        string bairro
        string cep
    }

• ⚠️ Alerta: Salvar endereço completo em uma única coluna dificulta filtros por bairro ou CEP.

📗 PASSO 2: Atributo Multivalorado (A Lista)

Ocorre quando uma única tupla possui vários valores para o mesmo atributo (ex: Telefone).

📊 Resolução via Tabela Secundária

erDiagram
    CLIENTE ||--o{ TELEFONE : "possui"
    CLIENTE {
        int id_cliente PK
        string nome
    }
    TELEFONE {
        int id_cliente FK
        string numero
        string tipo
    }

• 💡Dica: Atributos multivalorados geram uma nova tabela no modelo lógico para respeitar a 1FN (Primeira Forma Normal).

📗 PASSO 3: Atributo Derivado (Cálculo)

É aquele cujo valor não precisa ser armazenado fisicamente, pois pode ser calculado a partir de outros dados.

• 📍 Exemplo: Idade (derivada da Data de Nascimento).
• 🚀 Dica de Performance: Use Colunas Geradas (Generated Columns):

ALTER TABLE funcionarios 
ADD COLUMN idade INT GENERATED ALWAYS AS (YEAR(CURDATE()) - YEAR(data_nascimento)) VIRTUAL;

📗 PASSO 4: Resumo de Decomposição

💡 Regra de Ouro (Codd): Para que seu banco seja verdadeiramente "Relacional", cada coluna deve conter apenas valores atômicos (indivisíveis). 🚀🛡️

🔢 DOMÍNIOS E TIPOS DE DADOS (MYSQL VS POSTGRES)

O Domínio é o conjunto de valores válidos que um atributo pode aceitar. É a primeira linha de defesa da integridade dos dados. Na engenharia moderna, escolher o tipo de dado correto economiza espaço e aumenta a velocidade. 🛡️🧩

Objetivo: Comparar os tipos de dados entre MySQL 8.4 e PostgreSQL 17, dominando o uso de autoincremento, restrições de domínio e tipos híbridos (JSON/JSONB).

📗 PASSO 1: Mapeamento de Tipos Universais

📗 PASSO 2: Autoincremento (A Diferença Técnica)

Uma das maiores dúvidas é como criar IDs automáticos nas duas stacks:

🐬 No MySQL 8.4

CREATE TABLE produtos (
    id INT PRIMARY KEY AUTO_INCREMENT
);

🐘 No PostgreSQL 17

CREATE TABLE produtos (
    id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY
);

📗 PASSO 3: Restrições de Domínio (Integridade)

📊 Lógica da Restrição CHECK

flowchart TD
    IN[📥 Entrada de Valor] --> CHK{⚠️ Preço > 0?}
    CHK -- SIM --> OK[✅ Grava no Banco]
    CHK -- NÃO --> ERR[❌ Rejeita e Retorna Erro]

📗 Power Tools de Domínio

1. ✅ CHECK: Valida o valor antes de aceitá-lo (ex: CHECK (preco > 0)).
2. 📌 DEFAULT: Insere um valor padrão (ex: DEFAULT 'Ativo').
3. 🔢 ENUM: Lista fechada de opções (nativa no MySQL).

📗 PASSO 4: JSON vs JSONB (Arquitetura Híbrida)

Se o seu sistema precisa de campos flexíveis:

• MySQL JSON: Armazena e valida o texto.
• Postgres JSONB: Armazena em binário indexado. É muito mais rápido para filtros.

💡 Dica do Arquiteto: Evite usar BIGINT para tudo. No MySQL, se um campo nunca passará de 255 (ex: idade), use TINYINT. Economia de espaço é performance! 🚀🛡️

🔑 CHAVE ESTRANGEIRA (FOREIGN KEY) E INTEGRIDADE

Se a Chave Primária é o DNA, a Chave Estrangeira (FK) é o sistema circulatório que conecta as tabelas, permitindo que o banco de dados se comporte como um organismo único e coerente. 🛡️🧩

Objetivo: Compreender o conceito de integridade referencial e dominar as ações de gatilho (CASCADE, RESTRICT) para garantir a consistência das associações entre tabelas.

📗 PASSO 1: O Conceito de Relacionamento Pai-Filho

Uma Foreign Key é um atributo em uma tabela que aponta obrigatoriamente para a Primary Key de outra tabela.

📊 Relacionamento de Identidade

erDiagram
    DEPARTAMENTO ||--o{ FUNCIONARIO : "possui"
    
    DEPARTAMENTO {
        int id_depto PK
        string nome
    }
    
    FUNCIONARIO {
        int id_func PK
        string nome
        int **fk_depto** FK
    }

📗 PASSO 2: A Lei da Integridade Referencial

O SGBD (MySQL 8.4 ou Postgres 17) atua como um fiscal rigoroso. As regras são:

1. 🚫 Inserção de Órfãos: Não se cadastra Filho em Pai inexistente.
2. 🔒 Proteção contra Exclusão: Não se apaga o Pai se houver Filhos vinculados.

📗 PASSO 3: Ações de Gatilho (Trigger Actions)

O que ocorre com o "Filho" quando o "Pai" é alterado? Definimos isso com ON DELETE e ON UPDATE:

🛠️ Implementação Profissional

ALTER TABLE funcionario 
ADD CONSTRAINT fk_depto_func
FOREIGN KEY (fk_depto) REFERENCES departamento(id_depto)
ON DELETE RESTRICT
ON UPDATE CASCADE;

📗 PASSO 4: O Perigo do CASCADE em Cascata

Se você configurar CLIENTE -> PEDIDO como ON DELETE CASCADE, ao apagar um cliente, todos os pedidos dele somem instantaneamente.

💡 Regra de Ouro: Em sistemas financeiros, o CASCADE é proibido. Prefira o RESTRICT e obrigue a aplicação a lidar com a exclusão de forma consciente. 🚀🛡️

🕸️ RELACIONAMENTOS E ASSOCIAÇÕES LÓGICAS

Um banco de dados onde as tabelas não se conversam é apenas um conjunto de planilhas isoladas. O verdadeiro poder do Modelo Relacional reside nos Relacionamentos. 🛡️🧩

Objetivo: Compreender a mecânica das associações lógicas e dominar a representação de graus de relacionamento e atributos de ligação.

📗 PASSO 1: O Conceito de Associação

No MER, um relacionamento representa uma associação entre entidades. Graficamente, no nível lógico, utilizamos o erDiagram:

📊 Modelo de Venda Simples

erDiagram
    CLIENTE ||--o{ COMPRA : "realiza"
    PRODUTO ||--o{ COMPRA : "incluído em"
    
    CLIENTE {
        int id_cliente PK
        string nome
    }
    PRODUTO {
        int id_produto PK
        string nome
    }
    COMPRA {
        int id_cliente FK
        int id_produto FK
        date data_venda
    }

📗 PASSO 2: Graus de Relacionamento

O grau é definido pelo número de entidades na associação:

1. 🔄 Unário (Auto-relacionamento): A entidade se relaciona consigo mesma.
2. ↔️ Binário: Duas entidades conectadas (o mais comum).
3. 🔼 Ternário: Envolve três entidades simultaneamente (ex: MÉDICO prescreve EXAME para PACIENTE).

📗 PASSO 3: Atributos em Relacionamentos

Às vezes, um dado não pertence a nenhuma das entidades isoladas, mas sim à ação entre elas.

• Exemplo: No registro de Notas, o valor pertence ao cruzamento entre ALUNO e DISCIPLINA.

📊 Relacionamento com Atributo (Nota)

erDiagram
    ALUNO ||--o{ MATRICULA : ""
    DISCIPLINA ||--o{ MATRICULA : ""
    ALUNO {
        int id_aluno PK
        string nome
    }
    DISCIPLINA {
        int id_disciplina PK
        string nome
    }
    MATRICULA {
        int id_aluno FK
        int id_disciplina FK
        decimal nota
    }

📗 PASSO 4: Auto-relacionamento na Prática

📊 Hierarquia de Cargos

erDiagram
    FUNCIONARIO {
        int id_func PK
        string nome
        int fk_gerente FK
    }
    FUNCIONARIO ||--o{ FUNCIONARIO : "gerencia"

💡 Dica do Arquiteto: Relacionamentos ternários aumentam muito a complexidade. Tente sempre as decompor em binários antes de decidir pela ternária. 🚀🛡️

🔢 CARDINALIDADES E REGRAS DE NEGÓCIO

A Cardinalidade define a "quantidade" de participações de uma entidade em um relacionamento. Ela é a tradução técnica das regras de negócio. 🛡️🧩

Objetivo: Compreender as cardinalidades máximas (1:1, 1:N, N:M) e mínimas (opcionalidade) e dominar as regras de posicionamento de Chaves Estrangeiras (FK).

📗 PASSO 1: Cardinalidade Máxima (O Limite)

Diz respeito ao número máximo de ocorrências permitidas.

🌓 1:1 (Um-para-Um)

A ocorrência de A se liga a no máximo uma de B.

• Ex: Um GERENTE gerencia no máximo um DEPARTAMENTO.
• Decisão: A FK pode ir em qualquer lado, preferencialmente no dependente.

🌿 1:N (Um-para-Muitos)

A ocorrência de A se liga a várias de B, mas B se liga a apenas uma de A (Hierarquia).

• Ex: Um CLIENTE possui vários PEDIDOS.
• Decisão: A FK vai SEMPRE no lado N (Pé de Galinha).

🕸️ N:M (Muitos-para-Muitos)

Várias ocorrências de A se ligam a várias de B.

• Ex: ALUNOS e DISCIPLINAS.
• Decisão: Gera uma Nova Tabela (Associativa) com as duas FKs.

📗 PASSO 2: Cardinalidade Mínima (Opcionalidade)

Indica se a participação é obrigatória (1) ou opcional (0).

📊 Representação Crow's Foot

erDiagram
    CLIENTE ||--o{ PEDIDO : "faz"

• O traço vertical || indica que um Pedido deve ter 1 Cliente.
• O círculo o{ indica que um Cliente pode ter zero ou muitos Pedidos.

📗 PASSO 3: Resumo de Mapeamento (Onde vai a FK?)

📗 PASSO 4: Resolvendo o Relacionamento N:M

📊 Mapeamento de Consultas Médicas

erDiagram
    MEDICO ||--o{ CONSULTA : ""
    PACIENTE ||--o{ CONSULTA : ""
    
    MEDICO {
        int id_medico PK
        string nome
    }
    PACIENTE {
        int id_paciente PK
        string nome
    }
    CONSULTA {
        int **id_medico** FK
        int **id_paciente** FK
        date data
    }

💡 Insight do Arquiteto: Se você colocar a FK no lado "1", você limita o sistema. O "N" é quem recebe a chave estrangeira para apontar para o seu único pai. 🚀🛡️

🏁 CONSIDERAÇÕES FINAIS: UNIDADE II

Parabéns, Arquiteto de Dados! Você concluiu a Unidade II, o coração do projeto de software. Agora você sabe criar o esqueleto que sustenta os dados com segurança e performance. 🛡️🧩

Objetivo: Consolidar os conhecimentos de modelagem relacional, testando a capacidade de aplicar cardinalidades e chaves em cenários do mundo real.

📗 Resumo da Unidade II

Nesta jornada, dominamos:

• O Vocabulário do Especialista: Relações, Tuplas, Atributos e Domínios.
• Os Níveis de Abstração: Do MER (Conceitual) ao SQL (Físico).
• A Notação de Chen: Retângulos, Losangos e a importância do Sublinhado (PK).
• As Chaves da Integridade: PK para identificar e FK para associar sem criar órfãos.
• Cardinalidade: A arte de definir se o relacionamento é 1:1, 1:N ou N:M.

✅ Verificação de Aprendizagem (Unidade II)

📝 Questões Objetivas

1. Em um relacionamento 1:N entre CLIENTE e PEDIDO, onde deve ser posicionada a FK? a) Na tabela CLIENTE. b) Na tabela PEDIDO. c) Em uma terceira tabela associativa.

2. Qual das opções descreve uma "Chave Primária Composta"? a) Chave que aponta para duas tabelas ao mesmo tempo. b) Chave que aceita valores nulos (NULL). c) Chave formada pela união de dois ou mais atributos para garantir a unicidade.

3. Como representamos um "Atributo Multivalorado" na notação de Chen? a) Uma elipse tracejada. b) Uma elipse com contorno duplo. c) Um losango.

🧠 Desafios Práticos (Casos de Estudo)

Desafio 1: Design de Sistema Escolar Um aluno pode se matricular em várias disciplinas, e cada disciplina pode ter vários alunos.

1. Qual a cardinalidade?
2. Como resolveria no SQL?

Desafio 2: Integridade de Dados Tabela CARRO com FK fk_proprietario para PESSOA. Restrição: ON DELETE RESTRICT. O que ocorre ao apagar uma pessoa com carro cadastrado?

💡 Próximo Passo: Na Unidade III aprenderemos a falar com o banco! Prepare-se para o SQL Básico: SELECT, INSERT, UPDATE e DELETE. 🚀🛡️

🛠️ UNIDADE III: SQL BÁSICO

Nesta unidade acadêmica, iniciaremos nossa jornada prática com a linguagem SQL (Structured Query Language), a ferramenta padrão mundial para interação profissional com sistemas de bancos de dados relacionais. 🛡️🧩

Objetivo: Compreender a classificação da linguagem SQL (DDL, DML, DCL, TCL) e dominar as operações fundamentais de definição e manipulação de dados em ambientes profissionais.

📗 PASSO 1: O Ecossistema da Linguagem SQL

Diferente de linguagens imperativas como Java, o SQL é declarativo. Você descreve o que deseja, e o SGBD decide como executar.

🧩 Sub-linguagens Especializadas:

1. 🏗️ DDL (Data Definition): Foca na estrutura (tabelas, índices).
   • Comandos: CREATE, ALTER, DROP.
2. 📝 DML (Data Manipulation): Lida com o conteúdo dos dados.
   • Comandos: INSERT, UPDATE, DELETE, SELECT.
3. 🛡️ DCL (Data Control): Foca na segurança/permissões.
   • Comandos: GRANT, REVOKE.
4. ⚙️ TCL (Transaction Control): Gerencia as transações.
   • Comandos: COMMIT, ROLLBACK.

📗 PASSO 2: Mapa Mental do SQL

📊 Arquitetura da Linguagem

mindmap
    root((🛠️ SQL))
        DDL (Estrutura)
            CREATE
            ALTER
            DROP
        DML (Dados)
            SELECT
            INSERT
            UPDATE
            DELETE
        DCL (Segurança)
            GRANT
            REVOKE
        TCL (Controle)
            COMMIT
            ROLLBACK

📗 PASSO 3: Exemplos Práticos de Código

🏗️ DDL (Criação de Estrutura)

CREATE TABLE ALUNO (
    ID INT PRIMARY KEY,
    NOME VARCHAR(100) NOT NULL,
    RA INT UNIQUE
);

📝 DML (Manipulação de Dados)

-- Inserindo um novo registro
INSERT INTO ALUNO (ID, NOME, RA) VALUES (1, 'JOÃO SILVA', 202401);

-- Consultando informações
SELECT * FROM ALUNO;

🛡️ DCL e ⚙️ TCL (Controle e Transação)

-- Segurança: Permissão de leitura
GRANT SELECT ON ALUNO TO ESTAGIARIO;

-- Transação: Salvando mudanças
START TRANSACTION;
  UPDATE ALUNO SET NOME = 'JOÃO DA SILVA' WHERE ID = 1;
COMMIT;

💡 Dica do Especialista: Aprender SQL é dominar a linguagem universal de comunicação entre aplicações e seus dados estruturados. 🚀🛡️

🐘 NATUREZA DA LINGUAGEM SQL

A primeira ideia que define um desenvolvedor experiente é entender que a SQL não é apenas uma ferramenta, mas uma linguagem declarativa de escala global. 🛡️🧩

Objetivo: Compreender a filosofia declarativa da SQL e a importância do otimizador de consultas na transformação de códigos em planos de execução eficientes.

📗 PASSO 1: O Nome e as Origens

Embora pronunciada como sigla (S-Q-L), em contextos globais você ouvirá "SEQUEL" (pronuncia-se síquel). 🛡️

• História: Originalmente chamada de SEQUEL (Structured English Query Language), o nome foi simplificado para SQL (Structured Query Language).

📗 PASSO 2: Uma Linguagem Declarativa

Diferente de linguagens imperativas (Java, Python) — onde você diz como fazer — a SQL é Declarativa. 🛡️

Na SQL, você define o que deseja (quais dados recuperar), e o SGBD decide internamente o melhor caminho técnico (o como) por meio do seu Otimizador de Consultas.

📊 Fluxo de Processamento Declarativo

flowchart LR
    A[🛡️ Declaração SQL] --> B{⚙️ Otimizador SGBD}
    B -- Processamento --> C[🏗️ Plano de Execução]
    C --> D[📄 Resultado Final]

📗 PASSO 3: Padronização ANSI/ISO

Para garantir que o código funcione em diferentes sistemas (MySQL, PostgreSQL, Oracle), existem padrões globais:

• SQL-92: O padrão mais famoso e utilizado.
• SQL:2023: A norma mais recente, incluindo suporte avanzado a JSON e séries temporais.

💡 Dica do Especialista: Na Unidade III, focaremos em DDL (Criação) e DML (Manipulação). Dominar a base ANSI garante que seu conhecimento seja portável para qualquer SGBD do mundo. 🚀🛡️

🚀 MÃO NA MASSA COM SQL (DDL)

Seja bem-vindo à nossa jornada prática! Começaremos a construção da estrutura de um sistema profissional de Agenda de Contatos. 🛡️🧩

Objetivo: Aplicar comandos de Definição de Dados (DDL) para criar esquemas, tabelas e gerenciar a evolução da estrutura do banco de dados.

📗 PASSO 1: Organizando com SCHEMAS

Antes de criar tabelas, criamos um SCHEMA. Isso organiza o banco de dados em "bibliotecas" separadas, evitando conflitos.

-- Criando o espaço de nomes (Namespace)
CREATE SCHEMA AGENDA;

📗 PASSO 2: Criando a Tabela Principal

A SQL permite especificar tipos e restrições (Constraints) para garantir que apenas dados válidos entrem no sistema.

-- Criando a tabela com restrições profissionais
CREATE TABLE AGENDA.CONTATO (
    ID INT PRIMARY KEY,               -- Identificador Único
    NOME VARCHAR(50) NOT NULL,        -- Obrigatório
    EMAIL VARCHAR(100) UNIQUE,        -- Não repetido
    NASCIMENTO DATE,                  -- Formato AAAA-MM-DD
    ATIVO BOOLEAN DEFAULT TRUE        -- Valor automático
);

💡 Por que usar Constraints?

• 🛡️ PRIMARY KEY: Garante unicidade e impede nulos.
• 🚫 NOT NULL: Torna o preenchimento obrigatório.
• 🔑 UNIQUE: Impede duplicidade (ex: E-mails).
• ⚙️ DEFAULT: Define um valor padrão automático.

📗 PASSO 3: Modificando a Estrutura (ALTER e DROP)

O projeto de banco de dados evolui. O DDL permite mudanças seguras:

📗 Evoluindo a Tabela (ALTER)

-- Adicionando uma nova coluna
ALTER TABLE AGENDA.CONTATO ADD COLUMN CPF CHAR(11);

⚠️ Removendo Estruturas (DROP)

Cuidado! Estes comandos apagam os dados e estruturas permanentemente. 🛡️

🐬 MySQL 8.4

No MySQL, SCHEMA e DATABASE são sinônimos. Apagar um schema apaga tudo o que está nele automaticamente.

-- Remove a tabela específica
DROP TABLE AGENDA.CONTATO;

-- Remove o schema (banco de dados) completo
DROP SCHEMA AGENDA; 

🐘 PostgreSQL 17

No Postgres, um SCHEMA é um namespace dentro de um banco. Se houver tabelas, você deve usar CASCADE.

-- Remove a tabela específica
DROP TABLE AGENDA.CONTATO;

-- Remove o schema e força a exclusão de tudo o que estiver dentro (CASCADE)
DROP SCHEMA AGENDA CASCADE;

📗 PASSO 4: Tipos de Dados (Referência Rápida)

📗 PASSO 5: MySQL vs PostgreSQL (Auto-incremento)

📊 Divergência de Sintaxe para IDs

💡 Dica do Especialista: No PostgreSQL, o CREATE SCHEMA facilita a gestão de permissões para diferentes equipes. 🚀🛡️

🛡️ RESTRIÇÕES DE INTEGRIDADE EM SQL

As restrições (Constraints) garantem que os dados inseridos no banco sigam as regras de negócio e mantenham a consistência. 🛡️🧩

Objetivo: Dominar as restrições de integridade (NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK) para blindar o banco de dados contra inconsistências lógicas.

📗 PASSO 1: Valores NULL e DEFAULT

Por padrão, a SQL permite valores nulos (exceto PKs). 🛡️

• 🚫 NOT NULL: Torna o campo obrigatório.
• ⚙️ DEFAULT: Define um valor padrão automático.

CREATE TABLE CONTATO (
    ID INT PRIMARY KEY,
    NOME VARCHAR(30) NOT NULL,
    SOBRENOME VARCHAR(30) NOT NULL DEFAULT 'SILVA',
    NASCIMENTO DATE,
    ATIVO BOOLEAN DEFAULT TRUE,
    PESO DECIMAL(5,2)
);

📗 PASSO 2: Chaves e Identificadores

🥇 Chave Primária (PRIMARY KEY)

Identifica unicamente cada registro. Pode ser simples ou composta (M:N).

CREATE TABLE PERFIL_USUARIO (
    USER_ID INT,
    PERFIL_ID INT,
    PRIMARY KEY (USER_ID, PERFIL_ID) -- CHAVE COMPOSTA
);

🆔 Chave Única (UNIQUE)

Impede duplicidade em colunas que não são PK (ex: CPF, E-mail).

CREATE TABLE USUARIO (
    ID INT PRIMARY KEY,
    CPF CHAR(11) UNIQUE -- VALOR ÚNICO
);

📗 PASSO 3: Chave Estrangeira (FOREIGN KEY)

Estabelece o vínculo entre tabelas com Ações Referenciais:

• RESTRICT: Impede a exclusão do pai se houver filhos.
• CASCADE: Exclui os filhos automaticamente (Cuidado!).
• SET NULL: Zera a referência no filho.

-- Criando a tabela de dependentes (Relacionamento 1:N)
CREATE TABLE TELEFONE (
    ID INT PRIMARY KEY,
    NUMERO VARCHAR(15) NOT NULL,
    CONTATO_ID INT,
    FOREIGN KEY (CONTATO_ID) REFERENCES CONTATO(ID) ON DELETE CASCADE
);

📗 PASSO 4: Restrição de Verificação (CHECK)

Valida regras de negócio diretamente no motor do banco.

CREATE TABLE PRODUTO (
    ID INT PRIMARY KEY,
    PRECO DECIMAL(10,2) CHECK (PRECO > 0), -- PREÇO POSITIVO
    ESTOQUE INT CHECK (ESTOQUE >= 0)       -- ESTOQUE NÃO NEGATIVO
);

📗 PASSO 5: Melhores Práticas (Naming Constraints)

Nomear restrições facilita a leitura de erros e manutenção:

CREATE TABLE AGENDA.EVENTO (
    ID INT PRIMARY KEY,
    PRIORIDADE INT,
    CONSTRAINT CK_PRIORIDADE CHECK (PRIORIDADE BETWEEN 1 AND 5)
);

💡 Dica do Especialista: Se você não nomear sua constraint, o SGBD criará um nome aleatório (ex: SYS_C00123), o que torna o debug muito mais difícil. 🚀🛡️

🔍 DOMINANDO AS CONSULTAS (SELECT)

O comando SELECT é a ferramenta de extração de conhecimento. É como fazer uma pergunta profissional ao banco de dados para obter respostas estratégicas. 🛡️🧩

Objetivo: Dominar a estrutura da consulta SQL (SELECT, FROM, WHERE), compreender os tipos de junções (JOIN) e utilizar funções de agregação para análise de dados.

📗 PASSO 1: A Estrutura do Pensamento SQL

Para iniciantes, o segredo é seguir esta estrutura mental em 3 camadas: 🛡️

1. SELECT: O que eu quero ver? (Colunas).
2. FROM: Onde está a informação? (Tabelas).
3. WHERE: Quais filtros aplicar? (Condições).

📗 PASSO 2: O Raciocínio de Junção (JOIN)

Ao usar o JOIN, conectamos tabelas via colunas comuns (PK/FK).

📊 Tipos de Junção

• INNER JOIN (Padrão): Registros que possuem correspondência em ambas as tabelas.
• LEFT JOIN: Todos da esquerda, mesmo sem correspondência na direita.

flowchart LR
    C[👤 CLIENTE] -- "JOIN ON ID" --- T[📞 TELEFONE]
    T -- "WHERE" --- Filter{🔎 SILVA}
    Filter -- "SELECT" --- Result[📄 RESULTADO]

SELECT C.NOME, T.NUMERO 
FROM CONTATO C
INNER JOIN TELEFONE T ON C.ID = T.CONTATO_ID 
WHERE C.SOBRENOME = 'SILVA';

📗 PASSO 3: Filtros e Funcionalidades Avançadas

Além do =, a SQL oferece operadores poderosos:

• BETWEEN: Busca valores dentro de um intervalo.
• IN: Busca valores em uma lista específica.
• LIKE: Busca padrões de texto (ex: LIKE 'A%').
• IS NULL: Filtra campos que estão vazios.

📗 PASSO 4: Funções de Agregação e Agrupamento

Para extrair inteligência de grandes massa de dados:

📊 Ordem de Execução Mental

flowchart TD
    Data[📊 Dados Brutos] --> Filter[🔍 WHERE: Filtrar Linhas]
    Filter --> Group[📦 GROUP BY: Agrupar]
    Group --> Agg[📈 AGGREGATE: Contar/Somar/Média]
    Agg --> Having[🛡️ HAVING: Filtrar Grupos]

• COUNT(): Conta o número de registros.
• SUM(): Soma valores numéricos.
• GROUP BY: Agrupa os dados para a função de agregação.

-- Contar quantos telefones cada contato possui (Agregação + JOIN)
SELECT C.NOME, COUNT(T.ID) AS QUANTIDADE_FONES
FROM CONTATO C
INNER JOIN TELEFONE T ON C.ID = T.CONTATO_ID
GROUP BY C.NOME
HAVING COUNT(T.ID) > 1;

💡 Dica do Especialista: Use sempre Aliases (Apelidos) para suas tabelas (ex: CONTATO C). Isso torna o código SQL mais elegante e fácil de manter. 🚀🛡️

📝 MODIFICAÇÃO DE DADOS (DML)

Nesta aula, aprenderemos a vida ativa dos dados por meio dos comandos INSERT, UPDATE e DELETE. 🛡️🧩

Objetivo: Dominar os comandos de manipulação de dados (DML), compreendendo a importância do filtro WHERE e o ciclo de vida das informações em bancos relacionais.

📗 PASSO 1: Inserindo Dados (INSERT)

O comando INSERT adiciona registros (tuplas) às tabelas.

📗 Inserção de Múltiplas Linhas

INSERT INTO CONTATO (ID, NOME, SOBRENOME) 
VALUES 
    (20, 'LINUS', 'TORVALDS'),
    (21, 'MARGARET', 'HAMILTON');

📗 PASSO 2: Atualização Segura (UPDATE)

⚠️ ALERTA: Nunca execute um UPDATE sem a cláusula WHERE, a menos que deseje alterar todos os registros da tabela!

📊 Fluxo de Segurança

1. CONFERIR: Execute um SELECT com o filtro desejado.
2. EXECUTAR: Aplique o UPDATE com o mesmo filtro.

-- SEGURANÇA: Conferindo antes de alterar
SELECT * FROM CONTATO WHERE ID = 20;

-- EXECUTAR: Alterando o valor
UPDATE CONTATO SET NOME = 'LINUS B.' WHERE ID = 20;

📗 PASSO 3: Removendo Dados (DELETE)

O comando DELETE remove registros permanentemente.

📊 Ciclo de Vida do Dado

stateDiagram-v2
    [*] --> INSERT: Criar Registro
    INSERT --> SELECT: Visualizar
    SELECT --> UPDATE: Modificar
    UPDATE --> DELETE: Remover
    DELETE --> [*]

-- Removendo um contato específico
DELETE FROM CONTATO WHERE ID = 21;

📗 PASSO 4: SQL vs NoSQL (Modelagem)

A diferença fundamental está na rigidez da estrutura:

💡 Dica do Especialista: O mercado valoriza o desenvolvedor Poliglota de Dados. Domine o SQL como base, mas entenda o NoSQL para cenários de alta flexibilidade. 🚀🛡️

🏁 CONSIDERAÇÕES FINAIS: UNIDADE III

Você concluiu a jornada pelos fundamentos da linguagem SQL. Agora você é capaz de estruturar bancos de dados e manipular informações com precisão técnica. 🛡️🧩

Objetivo: Consolidar os conhecimentos de DDL e DML através de exercícios práticos e desafios de lógica SQL.

📗 Tabelas de Referência Acadêmica

Utilize as estruturas abaixo para resolver os desafios:

🎓 Tabela: ALUNO

👨‍🏫 Tabela: PROFESSOR

✅ Verificação de Aprendizagem (Unidade III)

📝 Questões Objetivas

1. Qual bloco da linguagem SQL é responsável pela criação, alteração e exclusão de estruturas de dados (como tabelas e índices)? a) DML (Data Manipulation Language). b) DDL (Data Definition Language). c) DCL (Data Control Language). d) TCL (Transaction Control Language).

2. Durante a manipulação de dados em uma tabela transacional corporativa, um DBA esqueceu a cláusula WHERE em um comando UPDATE. Qual será a consequência arquitetural dessa ação no SGBD PostgreSQL 17? a) O comando falhará imediatamente devido à proteção de segurança nativa contra perdas (Safe Updates block). b) Todas as linhas (tuplas) da tabela sofrerão a atualização mencionada. c) Apenas a última linha modificada será revertida (Rollback automático). d) O PostgreSQL exigirá a confirmação do comando.

🧠 Atividades Práticas: Unidade III

📝 Parte 1: Engenharia de Estruturas (DDL)

1. 🏗️ Nova Entidade: Crie a tabela CURSO com ID (PK), NOME (Not Null) e DURACAO_HORAS.
2. ⚙️ Evolução: Adicione a coluna DATA_CONTRATACAO (DATE) à tabela PROFESSOR.

📝 Parte 2: Manipulação de Dados (DML)

3. ➕ Inserção: Insira a professora 'Ana Souza', 'Mestre'.
4. 🔄 Atualização: Altere o e-mail do 'João Silva' para joao.silva@nova.br.
5. ❌ Remoção: Remova alunos com RA IS NULL.

📝 Parte 3: Inteligência de Dados (SELECT)

6. 🔍 Filtro: Selecione alunos com e-mail terminando em @univ.br.
7. 🔢 Ordenação: Liste professores por NOME (A-Z).

CREATE TABLE CURSO (
    ID INT PRIMARY KEY,
    NOME VARCHAR(100) NOT NULL,
    DURACAO_HORAS INT
);

ALTER TABLE PROFESSOR ADD COLUMN DATA_CONTRATACAO DATE;

INSERT INTO PROFESSOR (ID, NOME, SOBRENOME, TITULACAO) 
VALUES (11, 'ANA', 'SOUZA', 'MESTRE');

UPDATE ALUNO 
SET EMAIL = 'JOAO.SILVA@NOVA.BR' 
WHERE ID = 1;

DELETE FROM ALUNO WHERE RA IS NULL;

SELECT NOME, SOBRENOME 
FROM ALUNO 
WHERE EMAIL LIKE '%@univ.br';

SELECT * FROM PROFESSOR ORDER BY NOME ASC;

💡 Dica de Engenheiro: A SQL exige prática. Tente modificar as resoluções acima adicionando filtros mais complexos ou usando LIMIT para restringir resultados. 🚀🛡️

🧠 ATIVIDADE DE FIXAÇÃO: UNIDADE III (PARTE 1)

Nesta atividade, vamos exercitar a transição do modelo lógico para o modelo físico, focando na criação de tabelas e chaves. 🛡️🧩

Objetivo: Implementar a estrutura física de um banco acadêmico, configurando chaves primárias, estrangeiras e relacionamentos M:N.

🎭 Cenário: Sistema de Matrícula Acadêmica

O sistema gerencia quais alunos estão em quais cursos. Como um aluno pode cursar várias disciplinas e um curso possui vários alunos, usamos a tabela MATRICULA.

📊 Diagrama de Relacionamento (ER)

erDiagram
    ALUNO ||--o{ MATRICULA : "realiza"
    CURSO ||--o{ MATRICULA : "possui"
    ALUNO {
        int id PK
        string nome
    }
    CURSO {
        int id PK
        string nome
    }
    MATRICULA {
        int aluno_id FK
        int curso_id FK
    }

🛠️ Tarefas de Implementação

📗 PASSO 1: Criar a Tabela CURSO

📗 PASSO 2: Criar a Tabela MATRÍCULA (M:N)

🚀 Desafio SQL: Script de Criação

Tente escrever o código SQL. Se precisar de uma base, veja o modelo abaixo:

-- Criando a tabela de Cursos
CREATE TABLE CURSO (
    ID_CURSO INT PRIMARY KEY AUTO_INCREMENT,
    NOME VARCHAR(100) NOT NULL,
    ANO_CRIACAO INT
);

-- Criando a tabela de Matrícula (M:N)
CREATE TABLE MATRICULA (
    ALUNO_ID INT,
    CURSO_ID INT,
    PRIMARY KEY (ALUNO_ID, CURSO_ID), -- CHAVE COMPOSTA
    FOREIGN KEY (ALUNO_ID) REFERENCES ALUNO(ID),
    FOREIGN KEY (CURSO_ID) REFERENCES CURSO(ID_CURSO)
);

💡 Insight Profissional: Ao definir (ALUNO_ID, CURSO_ID) como PK, evitamos que o mesmo aluno se matricule duas vezes no mesmo curso, garantindo a integridade sem IDs extras. 🛡️

🎓 ATIVIDADE DE FIXAÇÃO: UNIDADE III (PARTE 2)

Continuando a modelagem do sistema, adicionamos agora as disciplinas e as regras cruciais de negócio acadêmico. 🛡️🧩

Objetivo: Integrar novas entidades (DISCIPLINA), configurar chaves estrangeiras 1:N e desenvolver consultas complexas utilizando JOINs para extração de dados.

🏗️ Estrutura Adicional da Base

Precisamos associar cada disciplina a um curso e a um professor responsável.

📊 Diagrama ER Ampliado

erDiagram
    CURSO ||--o{ DISCIPLINA : "contém"
    PROFESSOR ||--o{ DISCIPLINA : "leciona"
    DISCIPLINA {
        int id_disciplina PK
        string nome
        int curso_fk FK
        int professor_fk FK
    }

📗 Tabela: DISCIPLINA

🛠️ Atividade Prática de Engenharia

📗 Tarefa 1: Criação da Estrutura SQL

Escreva o script CREATE TABLE para a tabela DISCIPLINA, garantindo a integridade referencial.

📗 Tarefa 2: Consultas Estratégicas (JOINs)

Resolva os seguintes cenários de negócio:

1. 🔍 Listagem: Nome de todos os alunos matriculados no curso 'GTI'.
2. 👨‍🏫 Perfil: Nome e Titulação do professor da disciplina 'BANCO DE DADOS'.
3. 🛡️ Relatório: Nome e RA dos alunos do professor 'RICARDO'.

CREATE TABLE DISCIPLINA (
    ID_DISCIPLINA INT PRIMARY KEY AUTO_INCREMENT,
    NOME VARCHAR(100) NOT NULL,
    CURSO_FK INT,
    PROFESSOR_FK INT,
    FOREIGN KEY (CURSO_FK) REFERENCES CURSO(ID_CURSO),
    FOREIGN KEY (PROFESSOR_FK) REFERENCES PROFESSOR(ID)
);

-- 1. Alunos no curso GTI
SELECT A.NOME 
FROM ALUNO A
JOIN MATRICULA M ON A.ID = M.ALUNO_ID
JOIN CURSO C ON M.CURSO_ID = C.ID_CURSO
WHERE C.NOME = 'GTI';

-- 2. Professor de Banco de Dados
SELECT P.NOME, P.TITULACAO
FROM PROFESSOR P
JOIN DISCIPLINA D ON P.ID = D.PROFESSOR_FK
WHERE D.NOME = 'BANCO DE DADOS';

-- 3. Alunos do professor RICARDO
SELECT A.NOME, A.RA
FROM ALUNO A
JOIN MATRICULA M ON A.ID = M.ALUNO_ID
JOIN CURSO C ON M.CURSO_ID = C.ID_CURSO
JOIN DISCIPLINA D ON C.ID_CURSO = D.CURSO_FK
JOIN PROFESSOR P ON D.PROFESSOR_FK = P.ID
WHERE P.NOME = 'RICARDO';

💡 Insight Técnico: A ordem de criação importa! Crie primeiro as tabelas independentes (ALUNO, PROFESSOR) e depois as que possuem chaves estrangeiras. 🛡️

📐 UNIDADE IV: SQL AVANÇADO E DDL

Nesta unidade, avançaremos para consultas e comandos que demonstram o verdadeiro potencial analítico e estrutural dos SGBDs modernos. 🛡️🧩

Objetivo: Dominar a lógica ternária do SQL (TRUE, FALSE, NULL) e compreender o comportamento de valores ausentes em conjuntos de dados profissionais.

📗 PASSO 1: O Conceito de NULL

O valor NULL representa a ausência total de um dado. Ele possui três interpretações principais: 🛡️🧩

🕵️ Interpretações do NULL:

1. 🏷️ Valor Desconhecido: O campo existe, mas o valor é ignorado (ex: Data de Nascimento não informada).
2. 🔒 Valor Indisponível: Por motivos de privacidade ou política de dados.
3. 🚫 Valor Não Aplicável: A informação não faz sentido (ex: Complemento em casa térrea).

📗 PASSO 2: Lógica Ternária em SQL

Diferente da lógica booleana tradicional (True/False), o SQL utiliza a Lógica Ternária para lidar com a incerteza: 🛡️

📊 Fluxo de Decisão Ternária

flowchart TD
    A[🛡️ Expressão SQL] --> B{🎯 Resultado?}
    B -- "TRUE ✅" --> C[📄 Linha Selecionada]
    B -- "FALSE ❌" --> D[🗑️ Linha Descartada]
    B -- "NULL ❓" --> D

Na cláusula WHERE, apenas as linhas que resultam estritamente em TRUE são selecionadas tecnicamente. 🛡️

📗 PASSO 3: Operadores IS NULL e IS NOT NULL

Para checar a presença de valores nulos, nunca utilize =, mas sim os operadores universais: 🛡️

🛠️ Exemplo Prático:

-- Selecionar contatos sem data de nascimento definida
SELECT NOME, SOBRENOME 
FROM CONTATO 
WHERE NASCIMENTO IS NULL;

💡 Dica do Especialista: No SQL, a comparação NASCIMENTO = NULL sempre retornará FALSE (ou UNKNOWN), pois o nulo nunca é igual a nada, nem a si mesmo. 🚀🛡️

🚀 SUBQUERIES E JOINS AVANÇADOS

Neste capítulo, uniremos os recursos que permitem análises complexas através da combinação de tabelas e aninhamento de instruções. 🛡️🧩

Objetivo: Compreender a estrutura de consultas aninhadas (Subqueries), dominar a arquitetura de junções (JOINs) e aplicar filtros de agrupamento (HAVING) para inteligência de dados.

📗 PASSO 1: Consultas Aninhadas (Subqueries)

Uma Subquery é um SELECT dentro de outro. Elas calculam resultados temporários antes da consulta principal. 🛡️

🔄 Fluxo de Processamento (Escalar)

flowchart LR
    S[🔍 Subquery Interna] --> |"1. Executa Primeiro"| R[📄 Resultado Único]
    R --> |"2. Passa Valor"| M[⚙️ Query Principal]
    M --> |"3. Filtra"| F[✅ Resultado Final]

🎯 Tipos de Subqueries

• Não Correlacionada: A consulta interna independe da externa.
• Correlacionada (EXISTS): A interna depende de valores da externa.

-- Buscar contatos que possuem pelo menos um telefone
SELECT NOME 
FROM CONTATO C
WHERE EXISTS (
    SELECT 1 
    FROM TELEFONE T 
    WHERE T.CONTATO_ID = C.ID
);

📗 PASSO 2: Arquitetura de JOINs

Os JOINs permitem "colar" tabelas baseadas em chaves comuns. 🛡️

📊 Diagrama de Junções Profissionais

flowchart TD
    subgraph INNER [🤝 INNER JOIN]
        direction LR
        A1((A)) --- B1((B))
    end
    subgraph LEFT [⬅️ LEFT JOIN]
        direction LR
        A2((A)) --- B2((B))
    end

🛠️ Comportamento Técnico:

• INNER JOIN: Foco na intersecção. Se não há par, desaparece.
• LEFT JOIN: Foco na tabela esquerda. Se não há par, preenche com NULL.

📗 PASSO 3: Pipeline de Execução (SQL Order)

📊 O Segredo do Motor SQL

flowchart LR
    F[1. FROM] --> W[2. WHERE]
    W --> G[3. GROUP BY]
    G --> H[4. HAVING]
    H --> S[5. SELECT]
    S --> O[6. ORDER BY]

🧐 WHERE vs HAVING

• WHERE: Filtra as linhas individuais (Pré-agrupamento).
• HAVING: Filtra os resultados agregados (Pós-agrupamento).

SELECT SOBRENOME, AVG(PESO) AS MEDIA
FROM CONTATO
WHERE ATIVO = TRUE
GROUP BY SOBRENOME
HAVING AVG(PESO) > 80;

💡 Insight Profissional: Subqueries em cláusulas WHERE podem ser lentas em bases gigantes. Sempre que possível, converta-as em JOIN, pois os SGBDs modernos são otimizados para junções físicas. 🛡️🚀

🛠️ 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).

📗 PASSO 3: O Ecossistema NoSQL

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

📊 Tipos de NoSQL

✅ 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.

💡 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:

📗 PASSO 2: Atividade Prática (Consultas)

Com base no projeto, resolva os desafios: 🛡️

1. 🏗️ DDL: Escreva o script de criação das três tabelas.
2. 🔗 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.
3. 📊 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).

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)
);

-- 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. 🚀🛡️

🏗️ ESTUDO DE CASO: IMPLEMENTAÇÃO PRÁTICA

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: 🛡️

📗 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: TOP UNIFORMES

A empresa TOP UNIFORMES 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)

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

📗 PASSO 2: Identificação de Entidades

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

1. 👤 CLIENTE
2. 👨‍💼 VENDEDOR
3. 📦 PRODUTO
4. 📄 VENDA
5. 🔗 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: TOP UNIFORMES

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 TOP UNIFORMES: 🛡️

📊 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

1. 👤 CLIENTE x VENDA (1:N): Um cliente realiza múltiplas compras históricas. 🛡️
2. 👨‍💼 VENDEDOR x VENDA (1:N): Transação creditada a um vendedor responsável. 🛡️
3. 📂 VENDA x VENDA_ITENS (1:N): A venda conecta a lista de itens físicos. 🛡️
4. 🏷️ 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 TOP UNIFORMES. 🛡️🧩

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: 🛡️

1. 📦 PRODUTOS: Itens fabricados e preço sugerido.
2. 👤 CLIENTES: Quem consome nossos produtos profissionais.
3. 📄 VENDAS: Registro de faturamento e movimentação.
4. 🔗 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.

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. 🛡️

🍃 UNIDADE VI: NOSQL E ARQUITETURA DE DOCUMENTOS

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:

1. C (Consistência): Todos os clientes enxergam a mesma informação simultaneamente.
2. A (Disponibilidade): O sistema responde sempre, mesmo que dados estejam desatualizados.
3. 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 à quedas de rede<br/>Mas pode falhar na Disponibilidade)
    end
    
    subgraph Prioridade AP 
        direction TB
         CAS_info(Sempre Disponível<br/>Resiste à 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.

1. 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).
2. 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".
3. 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:

1. 🧩 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.
2. 🔗 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!

1. Aba Schema: No MongoDB Compass, abra a Collection e vá na aba Schema.
2. 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).
3. 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.

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

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 } }
]);

⚙️ INTRODUÇÃO AO CASSANDRA E ARQUITETURA DISTRIBUÍDA

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ó Europe))
        NO_B((Nó Brasil))
        NO_C((Nó USA))
        NO_D((Nó Asia))

        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:

1. Comece pelas Queries (Quais Perguntas a UI do seu App fará ao usuário?).
2. 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)
);

1. A primeira parte isolada em parênteses (cliente_id) é a Partition Key (K-Hash).
2. 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).

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);

🏁 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. 🛡️

📖 GABARITO DAS UNIDADES

Este capítulo contém a resolução acadêmica dos exercícios propostos ao longo do módulo de Banco de Dados. 🛡️🧩

🏷️ UNIDADE I: FUNDAMENTOS

1. 🛡️ Propriedades ACID:
   • Atomicidade: Unidade indivisível (tudo ou nada).
   • Consistência: Transição íntegra entre estados válidos.
   • Isolamento: Execução segura entre transações concorrentes.
   • Durabilidade: Persistência definitiva após a confirmação.
2. 📂 Arquivos vs SGBD: Os SGBDs oferecem controle de concorrência massiva, integridade automatizada e recuperação contra falhas físicas.
3. 🔌 Acesso Simultâneo: Permite que milissegundos de diferença não corrompam a base única central.

🏷️ UNIDADE II: MODELAGEM ER

1. 🏢 Concretas vs Abstratas: 🛡️
   • Concretas: Objetos físicos (Ex: CLIENTE, CARRO).
   • Abstratas: Eventos acadêmicos ou temporais (Ex: VENDA, RESERVA).
2. 📐 Mapeamento: Exemplo PRODUTO: {🔑 ID, 📄 Descrição, 💰 Valor_Venda, 🏷️ Categoria, 💵 Custo}.

🏷️ UNIDADE III: SQL BÁSICO

CREATE TABLE ALUNO (
    ALU_ID INT PRIMARY KEY,
    ALU_NOME VARCHAR(60),
    ALU_RA DECIMAL(10)
);

CREATE TABLE CURSO (
    CUR_ID INT PRIMARY KEY,
    CUR_NOME VARCHAR(60)
);

CREATE TABLE MATRICULA (
    MAT_CURSO_FK INT REFERENCES CURSO(CUR_ID),
    MAT_ALUNO_FK INT REFERENCES ALUNO(ALU_ID),
    PRIMARY KEY (MAT_CURSO_FK, MAT_ALUNO_FK)
);

🏷️ UNIDADE IV: SQL AVANÇADO

-- Consulta com JOIN
SELECT A.NOME 
FROM ALUNO A
INNER JOIN MATRICULA M ON A.ID = M.ALUNO_FK
INNER JOIN CURSO C ON M.CURSO_FK = C.ID
WHERE C.NOME = 'BANCO DE DADOS';

-- Subquery de existência
SELECT B.NOME FROM BENEFICIARIO B 
WHERE EXISTS (
    SELECT 1 FROM DEPENDENTE D WHERE D.NOME = B.NOME
);

🏆 Dica do Mestre: Continue praticando com o Case Estudo da Top Uniformes! 🛡️

💻 MÓDULO: ENGENHARIA DE SOFTWARE

Seja muito bem-vindo ao módulo estratégico de Engenharia de Software. 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.

📊 Mapa de Conhecimento do Módulo

Explore os quatro grandes pilares que regem a engenharia moderna de sistemas e o seu ciclo de vida.

flowchart TD
    subgraph SG_CICLO ["CICLO DE VIDA DO SOFTWARE"]
    direction TB
    F[🌳 FUNDAMENTOS] --> R[📋 REQUISITOS]
    R --> M[📐 MODELAGEM UML & SPRING]
    M --> G["🛡️ GERENCIAMENTO & QUALIDADE"]
    end
    
    subgraph SG_PILARES ["PILARES TÉCNICOS"]
    direction LR
    T1["⚡ AGILIDADE"] --- T2["📊 DIAGRAMAS"]
    T2 --- T3["🧪 TESTES (JUNIT 5)"]
    end

[!TIP] 💡 O Manto da Engenharia: Softwares não se fabricam, se projetam. O sucesso de um sistema complexo reside na robustez da sua arquitetura original e na clareza de sua documentação técnica. O domínio teórico-prático como Engenheiro de Software vai muito além de codificar: é planejar com base na qualidade e na manutenção inteligente.

📗 Plano de Ensino Detalhado

Este curso foi desenhado em uma sequência lógica, perfeitamente integrada à realidade exigida pelo mercado atual de desenvolvimento corporativo. Ao longo das Unidades, uniremos os conceitos fundamentais de Engenharia de Software aos artefatos concretos exigidos no design de bibliotecas e APIs modernas.

[!IMPORTANT] 📗 Atenção Estudante: O estudo deve seguir cronologicamente. Ao fim de cada Unidade (nos arquivos de "Considerações Finais"), você encontrará uma rigorosa bateria com Lista de Exercícios Objetivos e Desafios Práticos, desenhada para testar não apenas a base teórica, mas a sua habilidade em resolver problemas através da codificação.

👋 SEJA BEM-VINDO(A)!

Prezado(a) acadêmico(a), é com muito prazer que lhe apresentamos o livro de Engenharia de Software. A engenharia de software possui uma gama imensa de tópicos, os quais não seria possível abarcar em apenas cinco unidades, conforme este livro está organizado. Portanto, abordaremos os assuntos iniciais, essenciais para todo o contexto da disciplina.

Se gostar da matéria e quiser se aprofundar, você poderá consultar as obras citadas durante as unidades. Nelas, com certeza, você aprenderá muitos outros assuntos e poderá ter a certeza de que essa disciplina é fundamental quando tratamos de software como um todo. 🚀

📖 Estrutura do Livro

Este livro está organizado em cinco unidades estreitamente relacionadas:

• 📘 Unidade I: Apresentaremos alguns conceitos iniciais e fundamentais que serão utilizados com frequência ao longo das outras unidades.
• 📋 Unidade II: Trata especificamente dos conceitos relacionados aos Requisitos de Software. Para o desenvolvimento de um sistema conforme o esperado, é vital que os requisitos estejam claros.
• 📐 Unidade III: Estudaremos a Modelagem do Sistema utilizando conceitos de Orientação a Objetos (OO) e a linguagem UML (Unified Modeling Language).
• 📊 Unidade IV: Focaremos nos principais diagramas da UML (Casos de Uso, Classes, Sequência, Estados e Atividades) através de tutoriais passo a passo.
• 🏗️ Unidade V: Abordaremos o fechamento do ciclo de vida: as etapas de projeto, implementação, teste e manutenção de software.

[!IMPORTANT] A Essência do Software: Lembre-se que o termo Software compreende muito mais do que apenas código executável. Ele abrange toda a documentação referente ao sistema. A Engenharia de Software é a disciplina que garante que esses programas sejam confiáveis, com etapas bem definidas e custos previsíveis. 🛡️ Esperamos que sua leitura seja produtiva e que este conteúdo contribua para seu crescimento pessoal e profissional!

🌳 Unidade I: Introdução à Engenharia de Software

Nesta unidade, exploramos as bases fundamentais da engenharia de software corporativa, passando da superação da "crise de software" até a aplicação prática em ecossistemas ágeis com Java e Spring Boot.

[!TIP] 💡 Dica de Performance: O entendimento de Fundamentos é o que garantirá que você tome as decisões arquiteturais corretas amanhã. Sem estrutura, a agilidade se torna apenas caos rápido.

graph LR
  A[Fundamentos] --> B[Processos e Ágil]
  B --> C[Spring Boot / Java]
  C --> D[Entrega de Valor Contínua]

🎯 Objetivos de Aprendizagem

Ao final da Unidade I, você será capaz de:

• 💻 Definir as responsabilidades de um Engenheiro de Software no ecossistema de desenvolvimento corporativo.
• ⏳ Conhecer a evolução da engenharia e como a "Crise do Software" moldou ferramentas modernas de gestão.
• 🚀 Identificar arquiteturas e os tipos de aplicações (Cloud-Native, APIs RESTful, Sistemas Legados).
• 🔄 Compreender modelos de vida tradicionais vs. iterativos, com foco na mentalidade de entrega contínua.
• ⚡ Aplicar as metodologias ágeis (Scrum/XP) como fundação para projetos envolvendo Java 17 e Spring Boot.

[!NOTE] 📗 Passo Prático: Pense na Engenharia de Software não como teoria isolada, mas como a estrutura essencial antes de adicionar @RestController ou mapear dados.

graph LR
    A[Conhecimento Teórico] --> B[Prática em Java]
    B --> C[Profissionalismo Sênior]

📅 Plano de Estudo

📋 Tópicos da Unidade

Nesta unidade, você cursará os seguintes tópicos essenciais:

• Conceitos Básicos: O que é software no escopo corporativo.
• História e Crise: Da codificação artesanal à Engenharia de Software.
• Tipos de Aplicações: Compreendendo a nuvem e serviços web.
• Processos de Ciclo de Vida: Planejamento vs Execução.
• Metodologias Ágeis: O motor por trás do dinamismo das startups e empresas Enterprise.

🌊 Introdução e a "Crise do Software"

O termo Engenharia de Software surgiu inicialmente em 1968, em uma conferência organizada para discutir o que era chamado de "crise de software".

Nessa época, o hardware avançava vertiginosamente. O desenvolvimento de software, contudo, era informal e não documentado, resultando em:

• Falta de Confiabilidade: Sistemas instáveis.
• Custos Exorbitantes: Orçamentos estourados.
• Prazos Irreais: Demandas inatingíveis.
• Manutenção Impossível: O código virava um bloco impenetrável ("espaguete").

A ideia da Engenharia de Software é tornar o desenvolvimento um processo sistematizado. No ecossistema Java moderno, onde transitamos de Monólitos em Java EE para Microserviços descentralizados com Spring Boot, esse processo sistematizado não é apenas desejável, é obrigatório.

[!TIP] 💡 Dica de Performance: Aprender a usar bem a IDE e frameworks te faz um programador produtivo, mas entender a dor da "Crise de Software" te faz um engenheiro capaz de evitar que o seu código entre em falência estrutural.

Vamos, então, aos conceitos!

🏢 Conceitos Básicos e Aplicações de Software

O software pode ser definido como um segmento de instruções processadas pelo computador para executar tarefas específicas. Mais do que apenas código, os softwares comandam o funcionamento do hardware, fornecendo a lógica necessária para sua operação.

[!NOTE] 📗 Definição Profissional: "Software de computador é o produto que profissionais de software desenvolvem e ao qual dão suporte no longo prazo. Abrange programas executáveis em um computador de qualquer porte ou arquitetura..." (Pressman e Maxim, 2016).

📊 Características Fundamentais do Software

Diferente de produtos físicos (hardware), o software, especialmente no contexto de aplicações robustas em Java, possui três características peculiares que definem como ele deve ser desenhado e gerenciado:

"Software é tanto um produto quanto um veículo que distribui um produto." — Fonte: Pressman e Maxim (2016, p. 3).

⏳ História da Engenharia de Software

A Engenharia de Software é definida como o "estabelecimento e o emprego de sólidos princípios de engenharia para obter software de maneira econômica, que seja confiável e funcione de forma eficiente" (Bauer, 1969).

Fundamentalmente, baseia-se em métodos sistemáticos para o desenvolvimento de soluções computacionais. A ausência desses princípios leva ao que conhecemos como "Código Espaguete", algo terrível em ecossistemas corporativos modernos.

📊 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 e padrões UML
    2000 : Manifesto Ágil : Scrum, XP
    2010 : Cloud & Microservices : Spring Boot e DevOps

⚖️ Por que a Engenharia de Software é Vital?

Sommerville (2011) destaca motivos fundamentais para a aplicação rigorosa da disciplina, especialmente quando desenvolvemos arquiteturas em camadas (como os típicos Controllers, Services e Repositories em Java):

[!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.

🚀 Tipos de Aplicações de Software

O mercado de tecnologia divide os sistemas em categorias baseadas no domínio e missão. Com a evolução do Java e Ecossistema Spring, muitas dessas categorias migraram para ecossistemas distribuídos ou em nuvem.

📊 Categorias de Domínio

graph LR
    A[Sistemas Web / Cloud] --> B(API Gateway)
    B --> C[Spring Microservice A]
    B --> D[Spring Microservice B]
    
    style B fill:#e3f2fd,stroke:#1e88e5 
    style C fill:#e3f2fd,stroke:#1e88e5 
    style D fill:#e3f2fd,stroke:#1e88e5 

[!TIP] 📗 Passo Prático: Ao iniciar sua carreira ou um projeto corporativo novo com Java, identifique o escopo da aplicação. Uma API REST simples dispensa as complexidades do processamento científico pesado. A arquitetura escolhida deve ser sempre proporcional ao tipo de aplicação que você está construindo.

🏺 Software Legado (Legacy Systems)

Segundo Pressman e Maxim (2016), os softwares legados são sistemas mais antigos que demandam atenção contínua dos engenheiros. Embora desenvolvidos há anos (ex: sistemas em Java EE antigo, Cobol ou sistemas monolíticos pesados), eles permanecem em uso por suportarem funções de negócio vitais e indispensáveis para grandes corporações.

📊 Os Desafios Técnicos do Legado

Estes sistemas, muitas vezes chamados de "sistemas de herança", apresentam desafios técnicos significativos no dia a dia de um Desenvolvedor Sênior:

• 🛠️ Arquiteturas Rígidas: Difíceis de expandir ou integrar com APIs REST modernas.
• 🍝 Código Espaguete: Funções acopladas que quebram o padrão MVC ou SOLID.
• 📝 Documentação Escassa: Muitas vezes inexistente.
• ❌ Falta de Testes: Ausência de validação automatizada (ex: sem cobertura de JUnit).

🌀 Quando Evoluir um Sistema Legado?

A recomendação inicial da engenharia de software é prudente: não altere nada, a menos que o sistema exija modificações significativas para continuar operando. Refatorar "só para usar a tecnologia da moda" é um erro amador.

As razões inevitáveis para a evolução técnica são:

[!TIP] 💡 Dica de Performance: O objetivo da engenharia moderna não é sair construindo coisas novas do zero o tempo todo, mas elaborar estratégias para evoluir o código herdado de forma segura e incremental.

🔄 A Natureza Mutante do Software

Atualmente, o setor de engenharia de software corporativa é tracionado por grandes categorias que exigem arquiteturas resilientes e escaláveis (frequentemente usando a stack Java/Spring):

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 

[!NOTE] 📗 Passo Prático: Quando você estuda Spring Boot, você está na verdade se preparando para atuar diretamente nos três primeiros eixos (B, C e D), pois suas APIs Cloud alimentarão tanto WebApps em React/Angular quanto Mobile Apps em Flutter/Kotlin.

🌐 WebApps

No início da década de 1990, os sites eram predominantemente compostos por arquivos de hipertexto estáticos, exibindo textos e gráficos limitados.

Com a evolução das tecnologias de back-end e arquiteturas orientadas a serviços, surgiu a capacidade de oferecer processamento complexo e interatividade diretamente no navegador, transformando páginas de texto em sistemas operacionais na nuvem.

[!TIP] 💡 Dica de Performance: Diferente de sites institucionais, as WebApps são sistemas de software distribuídos complexos. Um Engenheiro de Software Full-Stack ou Backend deve projetar soluções que entreguem respostas rápidas em JSON (preferencialmente abaixo de 200ms) para que o WebApp tenha uma fluidez idêntica ao software instalado.

📱 Aplicativos Móveis (Mobile Apps)

Os aplicativos móveis são softwares popularmente conhecidos como "Apps", distribuídos em lojas online como Google Play e App Store.

Hoje, eles servem como a "ponta de lança" da experiência do usuário, consumindo dados que são orquestrados por um ecossistema gigantesco de APIs no backend (frequentemente desenvolvidas em corporações utilizando Spring Boot / Java).

📗 Categorias Práticas de Aplicativos

1. Ferramentas de Suporte à Produtividade: Editores B2B, planilhas corporativas integradas a CRMs.
2. Operações e Transações Financeiras: Fintechs, bancos, corretoras (exigem comunicação HTTP segura com o Backend via tokens JWT).
3. Ferramentas de Recuperação de Informação: Clima, streaming de dados e e-mails.

🤔 WebApp vs Aplicativo Nativo?

Existe uma distinção sutil, porém vital para arquitetos de software e engenheiros, entre o acesso web móvel e as aplicações instaladas no SO do celular:

[!IMPORTANT] 💡 Dica Arquitetural: A fronteira entre WebApps e Apps Nativos tende a se tornar cada vez mais tênue à medida que os frameworks evoluem. Um bom Engenheiro de Software não se prende a qual tela está consumindo o sistema, mas foca em construir um Back-End (API) agnóstico que sirva dados perfeitamente para qualquer interface, seja WEB, iOS ou Android.

☁️ Computação em Nuvem (Cloud Computing)

A computação em nuvem é descrita como uma infraestrutura ou ecossistema que permite a qualquer usuário ou empresa utilizar recursos computacionais em grande escala de forma flexível e descentralizada. Para um aplicativo desenvolvido em Spring Boot, a nuvem não é opcional, é o seu habitat natural de deploy.

📊 Arquitetura Lógica da Nuvem

A nuvem é organizada em camadas de serviço, garantindo acesso a dados persistentes e processamento escalável:

graph TD
    subgraph Dispositivos_Externos ["Dispositivos Externos"]
        D1[Servidores]
        D2[Desktops]
        D3[Telefones/Tablets]
    end

    subgraph Nuvem ["Nuvem (Recursos Compartilhados)"]
        direction TB
        
        subgraph Camada_SaaS ["Camada de Aplicação (SaaS)"]
            A1[Software as a Service]
        end

        subgraph Camada_PaaS ["Camada de Plataforma (PaaS)"]
            P1[Platform as a Service]
        end

        subgraph Camada_IaaS ["Camada de Infraestrutura (IaaS)"]
            I1[Infrastructure as a Service]
        end
    end

    Dispositivos_Externos -- "Acesso via Navegador / App" --> Camada_SaaS
    Camada_SaaS --> Camada_PaaS
    Camada_PaaS --> Camada_IaaS

📗 Os Três Pilares (IaaS, PaaS, SaaS)

[!TIP] 💡 Dica de Performance: A maior vantagem da Nuvem Corporativa é o Pay-as-you-go (Pague o que usar). Uma API REST construída adequadamente consome poucos recursos, mas pode escalar instâncias (IaaS/PaaS) instantaneamente durante a Black Friday. O Engenheiro projeta sua infra considerando o tráfego gerado.

📦 Software para Linha de Produto

A Linha de Produtos de Software (Software Product Line) é um conjunto, grupo de softwares ou uma família de sistemas que compartilham características comuns e blocos de código compartilhados.

No ecossistema corporativo Java, isso é extremamente comum: corporações criam starters próprios (como extensões do Spring Boot) ou pacotes comuns publicados num repositório Maven privado, para que todas as APIs construídas pela empresa compartilhem as mesmas regras de segurança e banco de dados.

📊 Arquitetura de Reuso (B2B e Ecossistema)

Em essência, trata-se do desenvolvimento de softwares similares a partir de uma base compartilhada, economizando tempo de engenharia.

graph TD
    subgraph Core ["Centro de Ativos (Dependências Maven comuns)"]
        direction TB
        A["Arquitetura Rest"]
        C["Componentes Security (JWT)"]
        R["Auditoria JPA Comum"]
    end

    subgraph Products ["APIs Customizadas da Empresa"]
        direction LR
        P1[Microsserviço de Vendas]
        P2[Microsserviço de Estoque]
        P3[Microsserviço RH]
    end

    Core --> P1
    Core --> P2
    Core --> P3
    
    style Core fill:#e3f2fd,stroke:#1e88e5 

📗 O Paradigma da Reutilização

O paradigma de reutilização dita que não podemos reinventar a roda. Se o setor de RH precisa gerar um PDF com logomarca, e o de Vendas também, isso deve virar um componente de reuso.

[!NOTE] 💡 Dica de Performance: Um Arquiteto Java não desenvolve a lógica de segurança em cada novo microservice que a empresa pede. Ele desenvolve o ativo uma única vez em uma biblioteca corporativa e exige que os serviços herdem esse ativo. Reuso constrói escalabilidade de equipe.

🔄 Processos de Software e Pipelines

Para que um software seja produzido e mantido em escala, são necessárias diversas etapas chamadas de Processo de Software.

Ele pode envolver tanto um repositório novinho iniciando com o Spring Initializr, quanto a manutenção de um monólito monstruoso Java corporativo. Independente do modo, se você não tem um processo, você caminha para o caos.

📊 As Quatro Atividades Fundamentais

Segundo Sommerville (2011), independentemente de você usar práticas ágeis ou conservadoras, todo ciclo de vida roda essas 4 engrenagens essenciais:

[!CAUTION] 💡 O Fator Humano (Dica Sênior): "Os processos de software são complexos e, como todos os processos intelectuais e criativos, dependem de pessoas para tomar decisões..." (Sommerville). Ferramentas não codificam sozinhas. Conhecer a stack corporativa de Spring Boot é importante, mas dominar comunicação durante a Especificação é o que salva o projeto.

🗺️ Modelos de Processos de Software

Um modelo de processo de software é uma representação abstrata e simplificada de um processo real. Segundo Sommerville (2011), esses modelos descrevem as atividades, os artefatos (documentos ou código) produzidos e os papéis das pessoas envolvidas.

No ecossistema corporativo atual liderado pelo Java, esses modelos ditam como o código sai da sua IDE e chega à Nuvem.

📊 Comparação dos Modelos Fundamentais

graph LR
    A[Caos Ad-hoc] -->|Engenharia| B[Modelos]
    B --> C[Processo Estruturado Agile]
    B --> D[Pipeline CI/CD Predictível]

[!TIP] 💡 Propósito do Modelo: A finalidade primordial é tentar reduzir o caos inerente ao desenvolvimento de novos produtos, fornecendo previsibilidade e visibilidade sobre o projeto. Não programe um endpoint REST sem saber em qual modelo o seu time opera.

🌊 O Modelo em Cascata

O modelo em cascata, ou ciclo de vida clássico, é o paradigma mais antigo da Engenharia de Software. Ele propõe uma abordagem sequencial e sistemática, onde cada fase deve ser concluída antes do início da próxima.

📊 Fluxo de Atividades do Cascata

graph TD
    A[Análise e Requisitos] --> B[Projeto de Dominio]
    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 (Pressman, 2011)

No mundo moderno, onde empresas exigem que aplicações (como microsserviços em Spring) evoluam rapidamente, engessar o sistema no Cascata gera problemas:

[!CAUTION] 💡 Dica de Performance Corporativa: O modelo em cascata ainda é usado? Sim, mas apenas quando os requisitos são imutáveis e regulamentados por leis estritas (ex: software de controle de tráfego aéreo ou de controle militar em baixo nível). Para construir APIs B2B/B2C, fuja do Cascata e abrace o Ágil.

📈 Desenvolvimento Incremental

O desenvolvimento incremental baseia-se na ideia de construir uma implementação inicial (um Minimum Viable Product - MVP), expô-la ao feedback dos usuários e evoluí-la através de sucessivas versões ou Sprints até chegar ao sistema final.

Para desenvolvedores Java, isso casa perfeitamente com abordagens como as ferramentas nativas de prototipação (ex: Spring Boot DevTools) e esteiras de Continuous Integration nas quais testamos incrementos diários de código.

📊 Atividades Concorrentes vs Versões

Neste modelo, as atividades de especificação, desenvolvimento e validação ocorrem simultaneamente, permitindo que o sistema incorpore novos requisitos dinamicamente.

graph LR
    subgraph Iteration ["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"]

    style Iteration fill:#e8f5e9,stroke:#43a047
    style V3 fill:#c8e6c9,stroke:#2e7d32

📗 Vantagens e Desafios (Sommerville, 2011)

[!TIP] 💡 Dica de Performance: O modelo incremental brilha intensamente em arquiteturas modernas (Microserviços). Se você construir um serviço de Pagamentos incrementalmente e ele der errado, você reescreve só ele, sem jogar o resto do e-commerce no lixo.

🏗️ Engenharia de Software Orientada a Reuso

A maioria dos projetos de software modernos envolve algum nível de reuso, baseado no conhecimento de sistemas análogos já desenvolvidos. A Engenharia de Software Orientada a Reuso formaliza essa prática.

No ecossistema corporativo, você não cria um sistema de login ou um conector de banco de dados do zero. Você importa uma dependência madura (como o Spring Security ou Spring Data JPA) e reaproveita o código pronto e validado pela comunidade.

📊 Ciclo de Vida do Reuso

Essa abordagem utiliza grandes bibliotecas de componentes reutilizáveis trazidas atráves de gerenciadores de dependência como o Maven ou Gradle. Em casos maiores, reusa-se sistemas inteiros chamados COTS (Commercial Off-The-Shelf ou Sistemas Comerciais de Prateleira).

graph LR
    subgraph Row1 ["Etapas Iniciais"]
        direction LR
        E1[Especificação] --> E2[Busca de Libs no Maven Central] --> E3[Adaptação dos Requisitos]
    end

    subgraph Row2 ["Implementação Prática"]
        direction LR
        E4["Importação e Configuração"] --> E5["Integração (Injeção de Bean)"] --> E6["Validação (Testes)"]
    end

    E3 --> E4
    
    style E2 fill:#fff9c4,stroke:#fbc02d 
    style E5 fill:#e3f2fd,stroke:#1e88e5 

📗 Vantagens e Riscos Técnicos

[!TIP] 💡 Dica de Performance Corporativa: Antes de criar sua própria "solução inovadora" para manipular datas ou gerar planilhas em Java, sempre verifique se não existe uma biblioteca mantida pela Apache (ex: Apache POI) ou pela Google (Guava) que já faz isso perfeitamente. Um bom Sênior sabe conectar os blocos do que reescrevê-los.

🛠️ Atividades Básicas do Processo de Software

Ao estudar os modelos de processo, nota-se que certas atividades são universais. Embora sua organização varie (engessadas no Cascata, fluidas e simultâneas no Ágil), a essência do trabalho intelectual permanece.

Para uma equipe desenvolvendo corporativamente em Java/Spring, essas fases definem como o código é gestado, escrito, quebrado e curado.

mindmap
  root((Engenharia de Software))
    ["Especificação"]
      ["O que a API faz?"]
    ["Projeto & Implementação"]
      ["Qual padrão Spring usar?"]
    ["Validação"]
      ["Testes JUnit passam?"]
    ["Evolução"]
      ["Adicionar novas features (CD)"]

[!NOTE] 📗 Passo Prático: A seguir, detalharemos cada uma destas 4 etapas de forma genérica, demonstrando as boas práticas e ferramentas usadas no mercado atual para cumpri-las.

📋 Especificação de Software

A especificação de software, frequentemente referida corporativamente como Engenharia de Requisitos, é a fase que define as funcionalidades requeridas e as restrições operativas do sistema. É uma atividade crítica: na arquitetura moderna, definir os dados que sua API REST receberá e como ela autenticará o usuário é feito aqui.

📊 As Quatro Fases da Especificação (Sommerville, 2011)

graph LR
    V[Viabilidade] --> L[Levantamento Ágil]
    L --> E[Backlog / User Stories]
    E --> VAL[Revisão Diária]
    VAL -->|Feedback| L
    
    style VAL fill:#d4edda,stroke:#28a745

[!CAUTION] 💡 Dica de Performance (O que mais dá erro): Estas atividades não são lineares; novos requisitos frequentemente surgem. A maior causa de falha em sistemas Java Enterprise não é "código lento", e sim o programador codificar perfeitamente uma "feature que o cliente nunca pediu", devido a uma falha na documentação de Especificação.

💻 Projeto e Implementação de Software

Segundo Sommerville (2011), a implementação é o processo de conversão de uma especificação em um sistema executável. Esta etapa é onde o café vira código. Nas engenharias modernas, isso se confunde: um Arquiteto projeta classes Java, e o Desenvolvedor as codifica quase ao mesmo tempo no Spring Boot.

📐 O Processo de Projeto

Para Pressman (2011), o projeto de software cria um modelo do sistema, detalhando a arquitetura, as estruturas de dados e interfaces. O programador deve:

1. Definir a Arquitetura Geral: Ex: Criar as pastas controller, service, repository e model (O padrão MVC).
2. Mapear o Banco de Dados: Construir as Entidades @Entity que virarão tabelas no banco de dados.
3. Desenvolver Lógica de Negócios: Escrever os métodos de serviço pesados com as regras operacionais.

📊 Teste vs Depuração (Debug)

No desenvolvimento, é comum que programadores garantam que seus códigos funcionam antes de entregar o MR (Merge Request). No entanto, é vital distinguir:

graph LR
    T[Testes Unitários / QA] --> |"Quebrou a API"| D[Depuração via IDE]
    D --> |"Erro de Lógica Corrigido"| T
    
    style D fill:#fdf2f2,stroke:#c0392b

[!TIP] 💡 Dica de Performance: Um desenvolvedor inexperiente espalha System.out.println por todo lado para achar o defeito. Um Engenheiro Sênior usa os atalhos de depuração do ambiente (Breakpoints) e logs avançados configurados (Logback / SLF4J no Spring).

🛡️ Validação de Software e Pipeline de Testes

A validação de software visa demonstrar que o sistema atende às especificações do usuário e é à prova de falhas. A técnica principal é o teste de software automatizado.

Não basta confiar no programador; se uma API Spring for para produção sem bater 80% de cobertura de código, é grande o risco de causar prejuízo aos clientes.

📊 Os Três Estágios do Teste (Sommerville, 2011)

graph LR
    C[JUnit: Teste Unitário] --> S[Integração CI: GitHub Actions]
    S --> A[Q.A. / Homologação]
    A -->|Sucesso Total| RL[Deploy Contínuo]
    
    style A fill:#c8e6c9,stroke:#2e7d32

[!IMPORTANT] 💡 Dica Corporativa (Validação vs Verificação):

• Validação: Estamos construindo a API Certa? (O cliente precisava disso?).
• Verificação: Construímos a API Corretamente? (Testes Unitários, Clean Code, Tratamento com @RestControllerAdvice). Não basta que funcione, tem que funcionar perfeitamente.

🔄 Evolução e Manutenção de Software

A evolução é inerente ao ciclo de vida do software. Após a implantação na rede ou nuvem, surgem necessidades de correções de bugs, adaptação a novas vulnerabilidades (ex: atualizar pacotes de segurança do Maven), e implantação de novas Features.

🏛️ Do Desenvolvimento à Manutenção (Mudança de Paradigma)

Antigamente o desenvolvimento era o "trabalho nobre" e a "manutenção" era o sub-produto ruim do projeto. No paradigma de integrações contínuas, são o mesmo trabalho integrado.

graph LR
    subgraph Old ["Arquiteto Monolítico Antigo"]
        direction LR
        D[Terminou Projeto 2018] --> M[Ficou em Manutenção Eterna]
    end

    subgraph New ["Engenharia Nuvem CI/CD"]
        direction LR
        E((DevOps e Ciclo Contínuo))
    end
    
    style E fill:#fff3e0,stroke:#fb8c00

📊 A Fronteira Fluida (Tipos de Evolução)

Hoje, a Engenharia encara o ciclo de vida como ininterrupto (DevOps). Mas as causas das alterações na plataforma têm naturezas distintas:

[!TIP] 💡 Dica de Performance: Integrar desenvolvimento e evolução em um fluxo contínuo de valor é o segredo para a longevidade dos sistemas modernos. Ter 100% de automação nas Esteiras (GitHub Actions, Jenkins) te economiza milhões em tempo humano ao não ter que verificar se a manutenção "Corretiva" estragou a parte antiga.

⚡ Metodologias Ágeis

As metodologias ágeis surgiram como uma alternativa às abordagens tradicionais, focando em flexibilidade, redução de burocracia e adaptação contínua ao longo do desenvolvimento.

Em um mercado de desenvolvimento corporativo onde um microsserviço precisa ir ao ar em questão de semanas, a agilidade tornou-se o alicerce da sobrevivência de qualquer Engenheiro Backend.

📊 Metodologia Tradicional vs Ágil

A escolha da abordagem depende majoritariamente do porte da organização e da natureza crítica do projeto:

[!TIP] 💡 Dica Arquitetural: Se o seu cenário prevê integrações contínuas, atualizações de APIs e o feedback do Product Owner é vital, a agilidade não é apenas uma opção. Um Sênior precisa dominar o código Java, mas também precisa jogar as regras do Ágil.

🚀 Extreme Programming (XP)

A Extreme Programming (XP) adota o paradigma de orientação a objetos de forma orgânica e é projetada especificamente para cenários onde os requisitos mudam de forma rápida e imprevisível.

O sucesso da XP baseia-se na sinergia entre suas regras, enfatizando o desenvolvimento guiado por testes (TDD) e o Pair Programming (programação em pares).

📊 Os Valores do XP

A meta principal da XP é entregar software de alta qualidade através de testes incansáveis. Num cenário Java, você escreve o teste JUnit antes mesmo de escrever o Controlador REST.

graph LR
    V1[Comunicação] --> S((Valores do XP))
    V2[Simplicidade Clean Code] --> S
    V3[Testes Automáticos CI] --> S
    V4[Refatoração Contínua] --> S
    V5[Pair Programming] --> S
    
    style S fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

📗 Aplicação e Escopo

Segundo Martins (2007), a metodologia é ideal para equipes enxutas e de alta produtividade técnica. O foco não pesadão dos documentos permite que o cliente interaja com endpoints funcioando o tempo todo.

[!NOTE] 💡 Foco no Valor Real: A XP foge da documentação excessiva. O "documento" do sistema XP é muitas vezes a sua própria suite de testes (JUnit). Se os testes passam e descrevem perfeitamente o comportamento do sistema de compras, a documentação está lá em código vivo e não num PDF defasado.

🔄 Scrum

As metodologias consideradas ágeis, assim como o Scrum, são fortemente influenciadas pelas práticas enxutas da indústria. A ideia principal é que equipes pequenas e multifuncionais (Desenvolvedores Backend, Frontend e QA) produzem resultados exponencialmente melhores.

📊 O Framework Scrum

O Scrum concentra atenções no produto final, no desenvolvimento rápido e nas interações humanas ao invés de ferramentas burocráticas.

flowchart LR
    subgraph P_BOX ["Papéis"]
        direction TB
        P1("Product Owner (PO)")
        P2("Scrum Master")
        P3("Time de Dev (Engenheiros)")
    end

    subgraph C_BOX ["Cerimônias"]
        direction TB
        C1("Sprint Planning (O que fazer?)")
        C2("Daily (Problemas?)")
        C3("Review (Entrega)")
        C4("Retrospective (Feedback)")
    end

    subgraph A_BOX ["Artefatos"]
        direction TB
        A1("Product Backlog (Jira)")
        A2("Sprint Backlog")
        A3("Burndown Chart")
    end

    P_BOX ~~~ C_BOX ~~~ A_BOX

    style P_BOX fill:#b3e5f2,stroke:none
    style C_BOX fill:#b3e5f2,stroke:none
    style A_BOX fill:#b3e5f2,stroke:none
    
    classDef item fill:#4a90a4,color:#fff,stroke:none
    class P1,P2,P3,C1,C2,C3,C4,A1,A2,A3 item

📗 O Fluxo de Trabalho (Sprints)

O Scrum estrutura seu funcionamento por ciclos chamados de Sprints (geralmente de 2 semanas). Durante a Sprint, o dev entra na sua máquina, escreve o código (ex: finaliza um microsserviço) sem ser interrompido com novos requisitos malucos.

Tabela: Exemplo de Product Backlog (Fila do Jira)

Abaixo, a representação de entregas organizadas:

⚖️ Metodologia Tradicional vs Ágil (O Resumo)

[!TIP] 💡 O Manto do Scrum para Desenvolvedores: Programadores inexperientes odeiam reuniões "Dailies". Programadores Sêniores usam a Daily para expor bloqueios técnicos pesados (ex: Banco de Dados indisponível) e jogar a responsabilidade de "desbloquear o caminho" para o Scrum Master. Use as Cerimônias ao seu favor.

🏁 Considerações Finais: Unidade I

Nesta primeira unidade, apresentamos conceitos fundamentais da Engenharia de Software. Vimos como a disciplina busca trazer rigor e previsibilidade ao desenvolvimento, migrando de escopos caóticos para a implantação automatizada (DevOps) de APIs corporativas.

📊 Resumo da Unidade

graph LR
    A[Engenharia e Arquitetura] --> B[Processos Ágeis]
    B --> C[Modelos de Ciclo de Vida]
    C --> D[Tradicional x XP/Scrum]
    D --> E[Entrega de Valor Contínua CI/CD]
    
    style E fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

Estudamos que um processo de software é um conjunto de atividades estruturadas (Especificação/Jira, Projeto/Arquitetura, Implementação/Java, Validação/JUnit e Evolução/AWS) que leva à produção de um sistema funcional. A escolha da abordagem correta depende do dinamismo e da criticidade do seu projeto.

📗 Desafios de Revisão (Contexto Backend)

1. Diferenciação Prática (Hardware e Software): Segundo Pressman (2011), é correto afirmar que o software:

   • a) Sofre falhas mecânicas como qualquer cluster de servidores.
   • b) Não é fabricado (estampado) no sentido clássico, mas sim projetado intelectualmente (Arquitetado).
   • c) Não usa bibliotecas prontas do Maven.
   • d) É atrelado a camada física do SO.

2. Validação vs Verificação: Qual a diferença técnica?

   • a) Nenhuma, são ferramentas do Jenkins.
   • b) Validação foca no cliente (Aceitação). Verificação foca no código (Regras do compilador Java, Testes Unitários).
   • c) Ambas ocorrem exclusivamente na esteira de Deploy.

[!TIP] 💡 Dica Arquitetural: Tente aplicar todo conceito teórico que você leu aqui no código. Quando escutar "Engenharia orientada a Reuso", não pense num cenário abstrato, pense em "Por que eu criaria um sistema de login na mão, se eu posso injetar o @EnableWebSecurity do ecossistema do Spring?". A teoria sem a prática codificada é o seu maior inimigo.

📚 Referências Bibliográficas e Recomendadas

As obras teóricas a seguir serviram de base para a construção das diretrizes clássicas desta unidade, enquanto as recomendações técnicas modernas o ajudarão a dominar as especificidades da Engenharia em Java e Spring:

Teoria Clássica e Gestão

• BROD, C. Scrum: Guia Prático para Projetos Ágeis. São Paulo: Novatec, 2013.
• FERNANDES, A. A.; TEIXEIRA, D. de S. Fábrica de Software: implantação e gestão de operações. São Paulo: Atlas, 2011.
• PRESSMAN, R. S.; MAXIM, B. Engenharia de Software. Uma abordagem profissional. 8. ed. Porto Alegre: McGraw Hill Brasil, 2016.
• SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.

Base Técnica (Java & Arquitetura Limpa)

• MARTIN, Robert C. (Uncle Bob) Código Limpo (Clean Code): Habilidades Práticas do Agile Software. Rio de Janeiro: Alta Books, 2009. (Essencial para TDD e refatoração em Java).
• WALLS, Craig Spring Boot em Ação. São Paulo: Novatec, 2016. (Leitura obrigatória para entender a Injeção de Dependência corporativa).
• RICHARDSON, Chris Microservices Patterns: With examples in Java. Manning, 2018.

[!TIP] 💡 Dica do Especialista: Não leia todos de uma vez. Comece pelo "Código Limpo" (Clean Code). Ele moldará para sempre a forma como você escreve uma classe e pensa na manutenção do seu método. Em Engenharia Corporativa, você gasta muito mais tempo lendo o código dos outros do que escrevendo o seu.

📖 Gabarito e Checklist: Unidade I

Abaixo estão as respostas comentadas para os desafios de revisão propostos.

Respostas Corretas

[!NOTE] 📗 Checklist de Prontidão (Unidade I): Você está pronto se conseguir responder a estas três perguntas com clareza:

1. Por que um Projeto focado em Spring/Microserviços se beneficia mais do Scrum em vez do Cascata?
2. Onde entram o JUnit 5 e os testes no pipeline da Engenharia Reversa ou Tradicional?
3. Como os conceitos de SaaS, PaaS, e IaaS definem onde a sua aplicação rodará depois que a etapa de Evolução for concluída?

📋 Unidade II: Requisitos de Software

A descoberta e documentação correta dos Requisitos de Software é a fase mais crítica da engenharia de software. Aqui, aprenderemos a ouvir o cliente e formalizar o que o sistema deve, de fato, realizar.

graph TD
  A[Necessidades do Cliente] --> B[Elicitação]
  B --> C[Análise & Aprovação]
  C --> D[Documento de Requisitos]
  
  style D fill:#d4edda,stroke:#28a745

🎯 Objetivos de Aprendizagem

Ao final desta unidade, você será capaz de atingir os seguintes marcos arquiteturais:

• 🔍 Entender os diversos tipos de requisitos (Funcionais, Não Funcionais) não de forma abstrata, mas como eles impactam as escolhas técnicas da equipe (Spring vs Quarkus, SQL vs NoSQL).
• 📋 Compreender a importância vital das Documentações de Especificação, que na nuvem moderna traduzem-se em Epics e User Stories.
• 🛠️ Conhecer o processo de descoberta e refinamento de requisitos (Discovery).
• ⚖️ Identificar as necessidades do negócio, evitando o desperdício de codificar o problema errado.

graph LR
    O[Objetivo do Cliente] --> P[Implementação Ágil]
    P --> V[Valor para o Negócio Mensurável]
    
    style O fill:#e1f5fe,stroke:#01579b

[!TIP] 💡 Dica Corporativa: A engenharia de requisitos é a fundação de qualquer projeto. Muito código macarrônico e APIs monolíticas gigantescas que quebram diariamente não são resultados de "programadores ruins", mas de uma Engenharia de Requisitos negligenciada, que exigiu que o dev remendasse a aplicação viva.

📅 Plano de Estudo e Introdução

Na primeira unidade vimos o ciclo de vida global do software (processos ágeis, testes em CI). Esta unidade travará seu foco especificamente no início desse ciclo: na fase de Especificação/Requisitos.

📋 Tópicos da Unidade

• 🏢 Definições Arquiteturais dos Requisitos de Software.
• 📄 Estrutura técnica das Histórias de Usuário / Documentos de Requisitos.
• 🔄 O Processo de Refinamento de Backlog.
• ⚖️ Qualidade de Software e Restrições de Operação.

🚀 Como o Backend nasce?

Entender o que o sistema deve fazer é o principal desafio antes de abrir a IDE. Os requisitos definem as regras e restrições do negócio, e para facilitar a abstração na sua mente de programador, os separamos didaticamente:

• RF (Requisitos Funcionais): Especificam o quê o sistema faz. Na prática de Backend, cada RF geralmente vira uma Rota da sua API (um Controller GET, POST).
• RNF (Requisitos Não Funcionais): Especificam o como o sistema faz. Na prática técnica, eles ditarão a Infraestrutura escolhida (A API precisa ser rápida? Talvez use Spring WebFlux. Precisa ficar online 24h? Talvez usemos Kubenetes na AWS).

Vamos decodificar essas necessidades!

📋 Requisitos de Software (Conceitos Básicos)

Descobrir e documentar o que deve ser construído é a essência da Engenharia de Requisitos.

Sommerville (2011) nota que o termo "requisito" pode variar de uma declaração abstrata de alto nível (uma ideia do cliente num guardanapo) até uma definição técnica formal. Para evitar confusão, separamos o entendimento em duas visões corporativas:

🏛️ Diferentes Perspectivas de Requisitos

[!WARNING] 💡 O Dilema da Codificação: "A parte mais difícil ao construir um sistema de software é decidir o que construir. Nenhuma parte do trabalho afeta tanto o sistema resultante se for feita a coisa errada. Nenhuma outra parte é mais difícil de consertar depois." — Frederick Phillips Brooks Jr. Codificar em Java um requisito mal formulado é o mesmo que dirigir em altíssima velocidade para o precipício errado. Em vez de consertar lógica, no final o time terá que jogar o repositório inteiro fora.

⚖️ Requisitos Funcionais e Não Funcionais

Um requisito é uma condição imprescindível para atingir um objetivo específico. Na Engenharia de Software, eles definem o que o algoritmo faz e quais os limites físicos e operacionais impostos (SOMMERVILLE, 2011).

Essa é a diferença mais fundamental na carreira de um Analista/Arquiteto.

📊 Classificação dos Requisitos (Sommerville, 2011)

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
    style RF fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px
    style RNF fill:#f5f5f5,stroke:#9e9e9e,stroke-width:1px

📗 Exemplos Técnicos Java/Cloud

[!CAUTION] 💡 A Fronteira do RNF gerando RF: Frequentemente, um requisito abstrato Não Funcional (ex: "O sistema deve ser super seguro") gerará diversos Requisitos Funcionais acionáveis para a equipe ("Fazer tela de Login", "Configurar Spring Security Oauth2", "Travar conta após 3 limites no banco"). O requisito Não Funcional sempre refina a sua Arquitetura base.

⚙️ Requisitos Funcionais

Os Requisitos Funcionais (RF) definem detalhadamente os serviços. No mundo lógico de um Backend, um Requisito Funcional é efetivamente a descrição de uma Entrada (JSON de Request), uma Lógica (Service/Use Case), e uma Saída (JSON de Response) além da definição de suas possíveis exceções (@ExceptionHandler).

🏗️ Riscos da Ambiguidade no Código

Requisitos ambíguos são letais: "Calcular o Frete" é ambíguo. Se o desenvolvedor não souber se o cálculo usa Sedex ou a Tabela particular, ele vai chutar a regra de negócio e gerar custos astronômicos de retrabalho meses depois.

💎 Completeza e Consistência (Sommerville, 2011)

Idealmente, a especificação funcional de qualquer Endpoint deve buscar dois estados fundamentais:

[!IMPORTANT] 💡 O Desafio Real: Em sistemas monolíticos complexos, atingir consistência total é uma tarefa árdua. Na nuvem, Arquiteturas Baseadas em Microserviços tentam quebrar esse grande problema em escopos menores (Bounded Contexts) para isolar a consistência.

🚀 Requisitos Não Funcionais (RNF)

Os Requisitos Não Funcionais (RNF) não descrevem o que a API faz, mas sim como ela deve operar sob estresse ou legislação. Eles definem as características de confiabilidade, tempo de resposta e segurança.

📊 Categorias de RNFs (Sommerville, 2011)

[!TIP] 💡 Dica Corporativa: No documento de requisitos (Jira), nunca ignore a aba de Restrições/RNFs. O Arquiteto pode perdoar se a lógica da venda estiver parcialmente incorreta, mas se você não implementar a criptografia estipulada pelo RNF e a base vazar, o sistema será imediatamente desligado com severas multas contratuais.

👤 Requisitos da Perspectiva do Usuário

Os "Requisitos de Usuário" devem descrever de forma compreensível o problema de negócios que as pessoas têm. Eles são pensados para usuários, clientes pagantes e Product Owners (PO) sem vasto conhecimento técnico computacional.

🎯 Foco e Formato

• 🔍 Foco Principal: Comportamento e resultado do sistema. (Ex: "A venda foi estornada?").
• 🖼️ Formato Recomendado: Normalmente redigidos através de User Stories (Histórias de Usuário) curtas: "Como <tipo_de_cliente>, eu quero <funcionalidade> para que <gere_este_valor>".
• ❌ O que evitar: Mencionar linguagens de código, bancos de dados, SQL, AWS. O cliente não quer saber se é relacional ou se usa Spring. Ele quer saber se funciona e reduz custos no financeiro da empresa.

graph LR
    U[Usuário Final / P.O.] --> |Revisa e Aprova| R[Cartão no Jira / User Story]
    R --> |Base para Tradução Técnica| S["Requisitos de Sistema (Back-end)"]
    
    style R fill:#fff3e0,stroke:#fb8c00,stroke-width:2px

[!IMPORTANT] 💡 A linguagem aqui deve ser a do Domínio do Negócio (Linguagem Ubíqua). Se o seu software for gerenciar Vagas em Hospitais, a documentação usará jargões médicos como Leito, Alta, Triagem, e não Controllers ou Banco de Dados.

🏗️ Requisitos de Sistema (O Contrato Técnico)

São descrições hiper detalhadas que servem de base para o contrato de implementação do programador. Devem constituir uma especificação precisa contendo os fluxos de dados, algoritmos exatos e modelagens base, servindo como ponto de partida real para que o Back-end inicie os trabalhos.

📊 O Abismo do Público-Alvo

Se você mostrar o diagrama detalhado do banco de dados (Modelo Entidade Relacionamento) do requisito de sistema para o dono da loja, ele não entenderá nada. A documentação técnica é estritamente voltada para fluência técnica:

🔎 Desafios Técnicos Imediatos

Diferentemente dos requisitos abstratos, os requisitos de sistema já engessam tecnologia. Ao documentá-los na esteira, você fatalmente define lógicas técnicas por duas razões obrigatórias:

1. Arquitetura Corporativa Base: Se a empresa usa Microsserviços e Java (Spring Cloud), o seu documento trará obrigatoriamente exigências sobre como usar o Gateway para aquele Endpoint específico.
2. Interoperabilidade: Muitas APIs modernas não sobrevivem sozinhas. Você precisará de integrações externas pesadas interagindo com REST, GraphQL ou Mensageria assíncrona RabbitMQ/Kafka predefinida.

[!WARNING] 💡 A Importância do Início Sólido: "As sementes das principais catástrofes de software são normalmente semeadas nos três primeiros meses do projeto durante o detalhamento irresponsável de sistemas." — Capers Jones

📄 O Documento de Requisitos (ERS)

Também conhecido como Especificação de Requisitos de Software (ERS), ele serve tradicionalmente como um contrato de consenso congelado entre a equipe executora e a empresa pagante, definindo os limites daquilo que o Dev promete entregar.

Na Era Ágil e Cloud, arquivos de "Word" engessados de 200 páginas muitas vezes são trocados por espaços colaborativos na Nuvem (Confluence, Notion ou pranchas de Backlogs no Jira). Contudo, a lógica e a divisão estrutural de Engenharia permanecem exatamente as mesmas para garantir controle de qualidade técnica.

📊 Estrutura Padrão Adaptada (IEEE / Sommerville)

Abaixo, a organização funcional e segura que você costuma achar no Confluence da sua Squad:

graph TD
    ERS([Repositório da Documentação/Confluence])
    ERS --> DEV[Programadores: Transformam a ERS em CÓDIGO]
    ERS --> CLI[Product Owners: Transformam ERS em DINHEIRO ou Contratos]
    ERS --> TEST[QA: Automatiza ERS em Automações Cypress]
    
    style ERS fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px

[!NOTE] 💡 Nota Didática: Para fins de sobrevivência técnica, você perceberá rapidamente que a documentação é um organismo vivo. Quando um campo no Banco de Dados muda seu tipo (varchar para integer), o documento tem que refletir essa mudança arquitetural caso contrário os analistas do futuro queimarão semanas caçando "fantasmas".

🎞️ Estudo de Caso: Locadora / Plataforma (ERS.01)

Para praticar Engenharia de Requisitos de forma real, vamos criar as especificações de uma Locadora Clássica (que atua como uma Plataforma de Empréstimos ou Streaming Híbrida).

🏛️ Contexto e Modelagem do Domínio

A empresa deseja migrar de fichas manuais para uma API em nuvem (Backend moderno). O Arquiteto fez uma reunião de Discovery e descobriu as seguintes entidades principais para o Banco de Dados:

⚙️ RF.01: Endpoints do Cadastro de Filmes/Catálogo

A API deve prover uma Rota (POST /api/movies) capaz de persistir no banco o seguinte JSON:

1. 🎞️ Metadados do Filme: Nome, duração em minutos, sinopse, classificação indicativa.
2. 💿 Dados da Cópia Física/Digital: Fornecedor, Link do Blob Storage, valor pago na licença.

[!TIP] 💡 O Objetivo Corporativo: O sistema deve reduzir perdas manuais e o Front-End fará buscas em tempo real usando tecnologias de busca textuais parecidas com Elasticsearch.

🛡️ Pipeline da Engenharia de Requisitos

O "Processo" da engenharia de requisitos não é algo que só ocorre uma vez na Agilidade, ele é contínuo e ocorre a cada final de Sprint.

Segundo Sommerville (2011), um refinamento maduro envolve quatro etapas sistêmicas:

🏗️ As Quatro Atividades do Ciclo

🔄 O Ciclo Contínuo de Discovery e Delivery

graph TD
    A["Discovery da Feature"] -->|Aprovado| B["Levantamento Ágil"]
    B -->|User Stories/Jira| C["Especificação Tecnológica"]
    C -->|Revisão de Arquitetura| D["Validação / Grooming"]
    D -->|"Pronta para Devs"| E["Próxima Etapa: CODIFICAÇÃO (Projeto)"]
    D -.->|Alteração de Rota| B
    
    style E fill:#d4edda,stroke:#28a745,stroke-width:2px

[!NOTE] 💡 Natureza Mutante: "Requisito não é sinônimo de arquitetura engessada. Requisito é sinônimo de necessidade." — Andrew Hunt & David Thomas. Necessidades mudam todos os dias no mercado de tecnologia, logo, seus Códigos terão de mudar (e é por isso que Arquitetura Limpa será exigida nos próximos módulos).

📊 Estudo de Viabilidade Arquitetônica

O estudo de viabilidade é a primeira peneira (Geralmente conduzido na Fase de Viabilidade de um Discovery Agile). Ele resulta em um relatório recomendando "Seguir / Descartar / Pivotar".

No desenvolvimento moderno de APIs, responder a essas três questões economiza a vida do time:

🏗️ As Três Peneiras da Avaliação

🔎 Fontes Primárias de Informação

As respostas devem ser buscadas diretamente com:

1. 👥 Product Owners & Stakeholders: Visão estratégica e orçamentária do produto.
2. 🏗️ Engenheiros de Software Staff/Sêniores: Avaliação dura e direta dos riscos técnicos, viabilidade computacional em Nuvem e gargalos operacionais.
3. 📱 Pesquisa com Usuários (UX Research): Validar se o cliente final realmente usaria esse botão.

[!WARNING] 💡 Se o sistema for tecnicamente State-of-The-Art (uma obra de genialidade atômica com os melhores Clusters do mundo), mas não se enquadrar como rentável para as metas da organização, todo o seu código gerará valor igual a zero.

🔎 Descoberta e Stakeholders

Nesta fase (Discovery), a equipe de POs e Engenheiros Sentam com o cliente para descobrir as restrições operativas da futura aplicação.

👥 Quem são os Stakeholders (Interessados)?

Todo projeto de tecnologia afeta grupos distintos com interesses de códigos distintos:

🏗️ Desafios da Fase de Discovery

1. 🧩 Articulação: O stakeholder de negócio mal sabe explicar o que a empresa faz (imagine pedir pra ele explicar a regra de uma API de pagamentos).
2. 🗣️ Tradução: O pessoal de vendas fala de "Leads". O programador Backend fala de Tabela Leads do PostgreSQL. O Arquiteto deve traduzir esses dois mundos.
3. ⚖️ Conflitos Táticos: O cliente quer o recurso feito em 2 dias. O Engenheiro avisa que leva 2 semanas para ser seguro.

[!TIP] 💡 Para se aprofundar nas dores dessa fase mista, leia o clássico "O Mítico Homem-Mês" de Brooks. Ele provou há décadas que "Adicionar mais programadores a um projeto atrasado, só o atrasará mais" (porque você gasta semanas ensinando o novato sobre requisitos que nem você entende direito).

🗣️ Técnicas de Extração Contínua (Entrevistas)

Escrever código só compensa se a regra estiver clara. As sessões de extração (Junto das cerimônias de Grooming no Scrum) são a barreira de defesa do programador. Se essa barreira quebrar, o dev trabalhará em finais de semana para corrigir interpretações ruins.

🏗️ A Postura de um Tech Lead

🔎 Observação Crítica do Arquiteto

O Analista/Arquiteto deve caçar mentiras involuntárias na fala dos Diretores:

• 🗣️ Descolamento Operacional: O Diretor diz que o processo de reembolso da filial demora 2 minutos. Na vida real, o operador leva 3 dias porque usa dados paralelos. A sua API precisa atender o trabalhador que está no caixa, não o diretor de gravata.
• 🛠️ Recursos Tecnológicos: A empresa pede reconhecimento Biométrico, mas os filiais rodam computadores de 15 anos sem câmera.

[!CAUTION] 💡 Dica do Sênior: Nas reuniões, pergunte "Por que?" exaustivamente. Se o cliente disser "Eu preciso de um botão que emita Excel com todos os dados do banco", pergunte "Por que você emite esse Excel?". As vezes ele só queria validar se o aluno está ativo, o que seria resolvido com uma singela tela de pesquisa Rápida, economizando semanas de desenvolvimento de planilhas.

📄 Resultado: A Especificação Viva

Após dias caçando os problemas, o produto oficial dessas reuniões são os documentados (Quer seja um ERS Gigantesco nos projetos em Cascata, ou Epics/Histórias super detalhadas no Jira de um projeto Scrum).

Isso unifica a visão entre o programador isolado no Home Office e o CEO da Matriz.

🏗️ O Papel da Especificação de Software

Eles cumprem os seguintes papéis críticos baseados no tempo:

1. 🛡️ Barreira Contratual (No Início): O cliente só pode cobrar aquilo que assinou. Se a Integração com API do governo não está no ERS, o prazo fatalmente será reavaliado antes de aceitarem cobrança grátis.
2. 🧩 Guia Arquitetônico (No Meio): Com todos os endpoints exigidos em mãos, o Dev de Backend modela o Banco (PostgreSQL) e projeta as chamadas da sua aplicação Spring Boot em cima de um papel antes de começar a codar.
3. 🛡️ Critério de Aceite e Testes (No Fim): O controle de qualidade (Quality Assurance) criará automações com Cypress e Selenium checando se o sistema atende ponto por ponto que está no papel.

[!NOTE] 💡 Nunca Confie na Memória: Documente tudo o que for acordado. Software complexo leva de 6 meses a 2 anos para existir com vigor. Você não se lembrará na Sprint 20 o que foi decidido de boca na Fase de Viabilidade.

✅ Validação Final (Grooming / Refinamento)

A validação garante que os requisitos refletem fielmente a Lógica de Negócios antes que uma única linha de código Java seja escrita.

Diferente do Discovery inicial (que lida com incertezas táticas), o refinamento atua em cima do documento para blindá-lo de incongruências.

🏛️ Os 5 Pilares da Revisão Sênior (Sommerville)

[!NOTE] 💡 Economia de Recursos (Regra 1:10:100): Se você corrige o erro no papel (Documento/Requisito), ele custa R$ 1. Se corrigir durante o desenvolvimento (Código), custa R$ 10 (Refatoração de Classes e Testes). Se descobrir o erro na Produção (Nuvem), ele custa R$ 100 ou o fechamento da empresa. Nunca economize tempo no planejamento dos requisitos.

🏁 Considerações Finais: Unidade II

Nesta segunda unidade, estudamos os Requisitos de Software, compreendendo a importância gigantesca e crítica de não pular de cabeça direto na IDE (Ato conhecido na agilidade como "Codelab irresponsável").

🏗️ Resumo Tecnológico

graph TD
    A[Especificação Backend] --> B[Endpoints da API / Funcionais]
    A --> C[Performance & Nuvem / Não Funcionais]
    
    A --> D[Board do Jira / Confluence]
    
    D --> E[Reunião de Discovery]
    E --> F[Refinamento de Rota]
    F --> G[Testes e Validação]
    
    style G fill:#fffde7,stroke:#fbc02d,stroke-width:2px

A clareza na abstração das regras é vital. Sem as descrições dos JSONs, Autenticações e Regras no papel, codificar o mundo real em Java é contar com a sorte.

Na próxima unidade, avançaremos para o visual. Como transformamos todos esses cartões de requisitos num "Planta Baixa" usando a UML (Linguagem Unificada de Modelagem) e Diagramas de Componentes Cloud. 🚀

📚 Material Complementar Avançado

📖 Literatura de Fronteira

O Mítico Homem-Mês: Ensaios sobre a Engenharia de Software

• Autor: Frederick P. Brooks | Editora: Alta Books
• O livro de cabeceira que explora magistralmente porque jogar mais programadores em problemas de requisitos não acelera o sistema, e sim afunda-o de vez. Indispensável para liderança técnica.

🎥 Leituras Extras Práticas

• 📹 Tudo o que você aprender sobre Clean Architecture (Teoria vs Prática).
• O canal oficial e cursos do Uncle Bob sobre como Requisitos Não Funcionais afetam diretamente a montagem da Arquitetura Limpa em projetos Java/C#.

📚 Referências Bibliográficas (Unidade II)

Para aprofundar os estudos desta unidade, recomendamos a imersão nos seguintes clássicos e literaturas de mercado:

• BROOKS, F. P. O Mítico Homem-Mês: Ensaios sobre a Engenharia de Software. 1. ed. Rio de Janeiro: Alta Books, 2018. (Imprescindível para entender gargalos em gestão de descoberta).
• MARTIN, R. C. Clean Architecture: A Craftsman's Guide to Software Structure and Design. 1. ed. Boston: Prentice Hall, 2017.
• SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011. (Base técnica de Qualificadores).
• MARQUIONI, C. E. Especificação de requisitos no desenvolvimento de software. Prisma.com, n. 15, p. 107-147, 2011.

📋 Gabarito de Revisão (Unidade II)

Confira suas respostas para garantir que a transição de conceitos funcionais para abstração em nuvem está clara.

1. Classificação de Requisitos:
   • Funcionais (Backend/API): Regras lógicas acopladas em fluxos (ex: Rota POST gerar PDF, Mapeamento JSON de Contatos).
   • Não Funcionais (Nuvem/Infra): Propriedades físicas (ex: CPU, JWTs de Segurança, Desempenho de 200ms, Deploy CI/CD).
2. Qualidade (ISO 9126): Funcionalidade Lógica, Usabilidade para o Front, Confiabilidade de Banco, Eficiência/Performance, Manutenibilidade (Clean Code na IDE) e Portabilidade (Docker/Contêineres).
3. Requisitos de Usuário (Histórias): Descrições escritas para negócio (Tickets no Jira), garantindo a visão de lucro da empresa.
4. Requisitos Funcionais: Exemplo: "A Rota de Checkout deve processar a comissão travando de forma otimista o carrinho de compras".
5. Stakeholders: Resposta correta: A (Qualquer grupo, inclusive o governo fiscal, com influência sobre as regras do sistema).

📐 Unidade III: Modelagem de Sistemas e UML

A modelagem é o momento em que a ideia se torna visível. Utilizaremos a UML e conceitos de Orientação a Objetos para representar a estrutura e o comportamento dos sistemas.

mindmap
  root((Modelagem))
    UML
      Casos de Uso
      Diagramas Estruturais
    Orientação a Objetos
      Classes
      Atributos
      Métodos

✍️ Exercícios Práticos: Unidade II

Teste seus conhecimentos para garantir que você absorveu o impacto dos requisitos antes de saltar para o Mundo do Código.

📝 Responda (Discussão Aberta)

1. Como diferenciamos os Requisitos no desenvolvimento de Software? Cite exemplos focados em APIs.
2. Descreva as seis características de qualidade da ISO/IEC 9126 traduzindo-as para necessidades modernas (ex: Cloud/DevOps).
3. Qual o risco de ignorarmos o "Discovery" e não validarmos um Requisito de Usuário com a diretoria da empresa?
4. Como uma regra de negócio ("Controlar Locações") vira um requisito acoplável em Software?

Múltipla Escolha: Stakeholders

5. Segundo a arquitetura e visão geral, quem dita o rumo e impõe regras no Software (Stakeholders)?

• a) O Product Owner, os Desenvolvedores, os Usuários Finais e Órgãos Reguladores Externos.
• b) Apenas os Diretores e Fundadores da Startup que pagam a conta.
• c) Apenas os Arquiteto Cloud da empresa.
• d) Apenas os programadores Juniors que criam os códigos.

[!TIP] 💡 Se teve dificuldades de compreender o Risco Tático de focar apenas no Programador na Pergunta 5, revise o tópico de Descoberta e Stakeholders (Capítulo 057).

🎯 Objetivos de Aprendizagem (Unidade III)

Ao final desta unidade, iniciaremos a Arquitetura. Transformar a lista de requisitos invisíveis em um "Blueprint" (Planta Baixa) que guiará os times Spring Boot e React.

Você será capaz de atingir os seguintes marcos técnicos:

• 🏗️ Decifrar os fundamentos da Linguagem de Modelagem Unificada (UML) no escopo Backend.
• 📊 Mapear Comportamentos através do Diagrama de Caso de Uso.
• ⚖️ Projetar a estrutura do Banco e Regras com a Orientação a Objetos (OO) (Foco em Classes e Heranças no Java).
• 🧩 Arquitetar as rotas de software utilizando estudos práticos como guia de design.

graph LR
    U[Requisitos Prontos] --> C[Diagramas Comportamentais]
    C --> OO[Diagramas Estruturais]
    OO --> P[Paradigma Orientado a Objetos]
    
    style P fill:#e1f5fe,stroke:#01579b

[!TIP] 💡 A modelagem é o passo decisivo para transformar o "Quê?" (Requisito no Banco de Dados) para o "Como?" (Diagrama de Classes Java). Dominar a UML não é apenas fazer desenhos bonitos; é conversar estruturalmente com as Equipes Pleno e Sênior da Engenharia.

📅 Plano de Estudo: Unidade III (Arquitetura Visual)

📋 Tópicos da Unidade

Nesta unidade, abordaremos os seguintes pilares da Modelagem UML e Orientação a Objetos:

• 🏗️ O que é UML e como criar diagramas (PlantUML, Draw.io).
• 📐 Traduzindo os Requisitos para Modelagem de Entidades (Banco de Dados).
• 📊 Diagramas de Caso de Uso (Atores e Fluxos).
• ⚖️ Conceitos Básicos de Orientação a Objetos (OO) (Como Classes Java e TypeScript representam diagramas).

📐 DO REQUISITO AO MODELO DE CÓDIGO

Nas unidades anteriores, você documentou o que a Nuvem tem que fazer. Agora, transformaremos essas descrições em Modelos Funcionais e Estruturais.

A modelagem permite que Desenvolvedores Back-ends e Front-ends olhem para o mesmo diagrama de fluxo e saibam o que codificar. Assim como arquitetos usam plantas em AutoCAD para construir prédios, engenheiros de software utilizam a UML para construir códigos escaláveis.

Veremos o Diagrama de Casos de Uso como pontapé, que mapeia todo o fluxo do Usuário com as engrenagens do sistema antes de escrevermos APIs.

[!NOTE] 💡 Para criar Software Cloud Native, não basta abrir o VS Code. Um bom planejamento arquitetural em UML impede que você crie classes monstro no Java que misturam regras de pagamento com regras de banco de dados (God Class).

🏗️ O Que é a Linguagem UML?

A UML (Unified Modeling Language) é a linguagem padrão universal da Engenharia de Software. Ela provê uma forma visual de organizar blocos de código complexos antes que o programador toque no compilador. A UML é estritamente aderente ao paradigma da Orientação a Objetos.

🏗️ Características Fundamentais (UML no Mercado)

[!IMPORTANT] 💡 A UML não Morreu com a Agilidade: Nos métodos Ágeis não fazemos mais cadernos de documentação gigantes. Hoje, o Arquiteto cria rápidos diagramas simplificados na ferramenta web, aprova com o time em 20 minutos e já parte para o código. A UML é a linguagem unificadora da Nuvem.

🛠️ Como Modelamos a UML na Prática (Ferramentas)

Antigamente, as empresas corporativas usavam ambientes trancados chamados de Ferramentas CASE. Hoje, o mundo da modelagem adotou arquiteturas visuais na Nuvem "como código" (Docs as Code).

🏗️ Principais Ferramentas do Arquiteto Moderno

[!TIP] 💡 Foco no Problema vs Beleza: Não perca 3 horas alinhando o bloco vermelho perfeitamente. Diagramas servem para se comunicar; se a lógica do Banco de Dados não estiver expressa perfeitamente nele de acordo com as Leis da API, nem o design visual mais requintado o salvará.

📐 Fundamentos da Modelagem UML

Um modelo é uma representação simplificada de um sistema a ser construído no Back-end. Da mesma forma que você não constrói um Boeing 747 sem uma planta aerodinâmica matemática, você não codifica um ERP Bancário abrindo direto o arquivo index.js.

📉 Por que Modelar? (A Realidade do Mercado)

A engenharia de software antiga nos deixou estatísticas assustadoras documentadas por estudos métricos. O que acontece quando os devs saem codando sem planejar a infraestrutura arquitetural?

[!CAUTION] 💡 O Paradoxo Ágil: Há um falso sentimento no mercado de que metodologias Ágeis (Scrum/Kanban) aboliram a arquitetura. Mentira. Eles aboliram a burocracia inútil de papeladas, não a necessidade de uma planta robusta de sistema. Antes de escrever código, valide a regra!

🚀 O Diagrama de Casos de Uso

O Diagrama de Casos de Uso (Use Case Diagram) é a "foto panorâmica" do sistema sob a perspectiva do usuário final. Ele é o ponto de partida essencial para a modelagem visual na UML.

👨‍🏫 A Visão de Endpoint (Menu de Opções)

Pense nos Casos de Uso como o "Contrato de APIs" ou o "Menu de Funcionalidades" do seu software. O que o usuário pode fazer? Ao olhar para este diagrama, o cliente de negócio imediatamente entende quais tarefas (Ações de Entrada e Saída) o sistema suporta.

🏗️ Os 3 Elementos Estruturantes

graph LR
    A[Usuário Padrão] --- UC([Efetuar Login Seguro])
    subgraph "Fronteira da sua API"
        UC
    end
    
    style UC fill:#e3f2fd,stroke:#1e88e5

[!NOTE] 💡 Os requisitos Não Funcionais (como "A senha deve ter criptografia RSA-256") não constam graficamente neste diagrama. O Diagrama de Casos de Uso lista apenas o escopo de Funcionalidades Declarativas.

🎭 Atores e Papéis de API (Actors)

Um Ator representa quem ou o quê está chamando o seu sistema para iniciar um fluxo. O Ator jamais participa passivamente; ele age ou sofre a ação de retorno do Banco de Dados.

🏗️ Categorias Autenticáveis

Dependendo da sua Arquitetura, você lidará com diferentes Atores. Abaixo está a visão em três frentes:

🎨 O que o Arquiteto Nunca Deve Fazer:

• 🚫 Nunca liste CPF/Nomes Próprios: Crie "Cargos" ou "Grupos Lógicos" (Admin, User_Premium).
• 🚫 Nunca liste o seu Banco de Dados como Ator: "Ah, quem checa a senha é o PostgreSQL, logo ele é o Ator!". Falso. O Banco de Dados não está FORA das fronteiras da sua API, ele faz parte orgânica do que você vai codar. O Ator sempre está FORA do Backend e do Frontend, pressionando o seu serviço.

🔵 Mapeando Ações Reais (Use Cases)

Um Caso de Uso (A elipse no diagrama) mapeia a Rota Lógica Exata entre a Interface com o Usuário e o que sua função no Back-end deverá realizar (Ex: Processar Pagamento).

Sempre espere um resultado quantificável: ou o usuário obteve um erro, ou ele atingiu sua meta final de negócio (Booch, 2006).

🏗️ Padrão Restful e Nomenclatura no Mercado

Para padronizar com as normas da arquitetura moderna que os programadores utilizam em APIs HTTP, obrigatoriamente os nomes das "bolinhas/elipses" da UML seguirão um Verbo de Ação no Infinitivo acoplado ao recurso manipulado:

graph LR
    CU1([🛒 Efetuar Checkout])
    CU2([🔍 Listar Carrinho])
    CU3([📄 Gerar Fatura PDF])
    
    style CU1 fill:#e3f2fd,stroke:#1e88e5

[!CAUTION] 💡 A Bolinha Mágica: O diagrama tem um defeito grave. Ele só mostra Que algo ocorre. O passo a passo (O Código) sobre Como aquele caso de uso valida senhas não cabe na figura. Veremos como destrinchar o "código" no Diagrama de Sequência ou nas Especificações Textuais.

🔗 Interações Dinâmicas (Relacionamentos)

Os componentes da nossa nuvem não vivem em silos. Se um "Caso de Uso" não se comunicar com nenhum Ator, ele é um caso de "Código Lixo/Morto".

Segundo Melo (2004), a UML usa associações em setas e pontilhados para gerenciar funções compostas dentro de componentes de software sem duplicar código.

🏗️ Padrões de Componentização

A UML provê maneiras nativas de representar reuso de código no back-end (Para garantir o princípio do "Don't Repeat Yourself" ou DRY):

graph LR
    A["Usuário Mobile"] --- C1(["Finalizar Compra"])
    
    C1 -.->|"<<include>> (Sempre Executa)"| IN(["Validar Cartão de Crédito"])
    EX(["Calcular Imposto Internacional"]) -.->|"<<extend>> (Se mora Fora)"| C1
    
    style C1 fill:#e3f2fd,stroke:#1e88e5
    style IN fill:#c8e6c9,stroke:#4caf50
    style EX fill:#fff3e0,stroke:#ff9800

🤝 Acoplamento Simples (Associação)

Na Engenharia, a Associação é uma relação não-direcionada entre a Fronteira do usuário e o Controlador do Sistema. Representa que a API/Tela está acessível para ele. 🛡️🧩

🏗️ Modelagem Gráfica de Permissões

A associação é representada visualmente por uma linha reta e sólida, ligando o Ator ao seu Evento.

• Identificação (Autenticação Implícita): Em sistemas modernos de microsserviços, essa linha se traduz num Filtro (CORS ou Spring Security). Ela diz que o Token de "Paciente" tem a permissão HTTP de acionar o controlador Emitir Relatório.

graph LR
    U[Paciente - ID:441] --- UC([Bater Endpoint de Prontuário])
    
    style UC fill:#e3f2fd,stroke:#1e88e5

[!NOTE] 💡 Nunca coloque setas apontando quem manda em quem numa Associação Ator-Caso de Uso. A linha reta sinaliza apenas que um Canal Seguro de comunicação bidirecional de dados (Request/Response API) está aberto entre eles.

➕ Call Mandatory (Inclusão - Include)

A Inclusão representa uma função que é obrigatória para o sucesso da Rota Principal. Sem esse sub-fluxo, o Pai abortará a Missão e retornará Falha ao App.

🏗️ A Lógica do Middleware

Sempre que uma Rota Web "A" não puder salvar no Banco sem que o Serviço "B" ocorra obrigatoriamente primeiro, usamos a Extensão.

• 🏆 Padrão de Reuso (DRY): Você cria a bolinha "Validar Autenticação" uma vez, e todas as bolinhas de Cadastro do sistema apontam para ela via Include.
• 🔵 Acoplamento Estrutural: O fluxo Master tem dependência 100% de vida do fluxo incluído.

graph LR
    V(["💰 Efetuar Checkout de Venda"]) -.->|"<<include>> (Obrigatório)"| VAL(["🛡️ Autenticar Token do Usuário"])
    P(["💳 Estornar Pagamento"]) -.->|"<<include>> (Obrigatório)"| VAL
    
    style V fill:#e3f2fd,stroke:#1e88e5
    style VAL fill:#f1f8e9,stroke:#558b2f

[!IMPORTANT] 💡 Não tem como fugir: A Inclusão é uma Ordem. Na UML acima, a seta tracejada sai da Rota de Venda e "engole" a de Validação. Se a API de Venda for chamada, é certeza absoluta que debaixo dos panos o código também varrerá se o usuário tem a senha válida.

📋 Tabela Universal de Tráfego de UML

Estes são os Legos de Arquitetura. Usando apenas essas 4 conexões, você descreve desde o sistema de Controle de Viagem da UBER até os Pix do Banco Central:

🏗️ Como a Engenharia entende as setas

[!NOTE] 💡 Dominar a UML antes de sair batendo código no Linux prova o nível da senioridade técnica de uma Squad Corporativa. O Código é descartável; a abstração do domínio corporativo desenhada na UML (e atestada pelo Diretor) dura anos.

🚀 Diagrama de API: Plataforma E-Health Laboratorial

Neste capítulo, compilaremos os Requisitos Restful em um diagrama de Casos de Uso arquitetural focado no Back-end do Produto.

🏗️ Roteiro do PlantUML

Mapeamentos baseados em Tokens Autorizados:

1. 👥 Níveis de Autenticação (Atores): Recepcionista_JWT, Bioquímico_JWT, Paciente_App, e o App Externo Auditoria_ANS.
2. 🔵 Endpoints Mapeados (Casos de Uso):
   • Cadastros Centrais: Cadastrar Paciente e Exames.
   • Relatórios Securitizados: Emitir Laudo PDF, Emitir Tabela SUS.
3. 🤝 Fronteira Nuvem: Tudo dentro da caixa "AWS LabSystem API" é o código que o servidor Java executará.

📐 Diagrama de Funcionalidades (Visão Macro)

graph LR
    subgraph "AWS LabSystem API (Spring Boot)"
        UC1(["Cadastrar Paciente e Coleta"])
        UC4(["Processar e Assinar Laudo Médio"])
        UC5(["Gerar PDF do Prontuário"])
        UC7(["Disparar Webhook ANS Legal"])
        UC8(["Download Exame Finalizado"])
    end

    RE["Recepcionista Web"] --- UC1
    RE --- UC5

    BI["Bioquímico Sênior"] --- UC4
    UC4 -.->|"<<include>> (Obrigatório Lei)"| UC7

    PA["App Mobile Paciente"] --- UC8
    PA --- UC5

    ANS["Robô Auditoria Governamental"] --- UC7
    
    style UC4 fill:#e3f2fd,stroke:#1e88e5
    style UC7 fill:#f1f8e9,stroke:#558b2f

[!TIP] 💡 Segurança Embutida Visualmente: Note como o Paciente nunca cruza a linha tocando no endpoint de "Processar Laudo". Visualmente, o Arquiteto trancou a rota e nenhum Eng. de Software Sênior esquecerá de colocar a trava no código depois de ver este fluxograma.

⚖️ O Princípio da Orientação a Objetos (OO)

Chegamos ao núcleo da Engenharia de Sistemas Corporativos modernos (Java, C#, TypeScript).

Se os "Casos de Uso" explicavam o fluxo visível, a Orientação a Objetos explica o fluxo invisível do Banco e da Memória RAM.

A UML foi criada pela trindade formadora do paradigma de Orientação a Objetos (OO). Para fazer diagramas de Classes e Banco, você deve raciocinar como a Linguagem de Programação raciocina.

🏗️ Pilares do Paradigma no Java

Nesta seção, exploraremos os conceitos do Clean Code no paradigma OO:

mindmap
    root((Ecossistema Orientado a Objetos))
        Classes
            O Molde Abstrato Java
            Variáveis de Classe e Funções
        Objetos
            A Instância Viva flutuando na Memória RAM
            Estados Únicos por Instância
        Pilares Herdados
            Herança
            Encapsulamento
            Polimorfismo

[!NOTE] 💡 O Paradigma Vencedor: Se você tentar desenhar Diagramas Funcionais C-Style de 1980 hoje, sua arquitetura falhará em microsserviços. Sem uma compreensão sólida de new Object(), a construção da UML é apenas desenho estético.

🧩 Instâncias e Objetos em RAM

Segundo a Engenharia, um Objeto é qualquer bloco autossuficiente que pulsa dentro da memória RAM do seu Servidor Cloud enquanto o fluxo de código roda.

Enquanto a "Classe" é um pedaço de folha de papel morta, o "Objeto" é a Vida. (Exemplo: O Humano é a classe genérica. O Fulano com CPF vivo na tela é a Instância / Objeto daquela classe).

🏗️ Tipos de Instâncias na Modelagem

Em aplicações Web como Spring Boot, dividimos os blocos em dois cenários drásticos de UML:

[!TIP] 💡 Extração de Objetos: Para identificar Classes na UML a partir do Documento de Requisitos, basta circular todos os Substantivos Fortes. Se o cliente falou: "O Médico atende o Paciente com um Prontuário"; parabéns, você achou as 3 classes centrais do ecossistema.

📊 Atributos Tipados Estruturais

Um Atributo é a variável (propriedade) que trafegará através do JSON ou Banco Relacional para construir o Corpo do seu Objeto.

Sem ele, uma classe Java não armazenaria dado algum na vida do paciente (Seria uma mera função estática).

🏗️ Nomes e Segurança Forte (Tipagem)

Diferente do Javascript de 2012 que aceitava qualquer lixo dentro da variável, a UML adota uma posição fortemente O.O (Tipagem Rigorosa).

• Tipagem Forte UML: O Atributo exige Tipagem explícita na anotação (Ex: String, Float, Integer, Boolean, Date).
• Visibilidade (+, -, #): As classes escondem informações pelo pilar do Encapsulamento.

classDiagram
    class ProdutoCloudObject {
        +String uuid_Produto
        -Float precoVendaOculto
        +Boolean emEstoqueAWS
        +Date dataCadastroTimeStamp
    }
    
    style ProdutoCloudObject fill:#e3f2fd,stroke:#1e88e5

[!NOTE] 💡 No diagrama acima, os sinais de + ou - definem a Visibilidade (Encapsulamento). Discutiremos como colocar "Private" (-) blinda a variável de ser invadida e modificada por outras classes nocivas na Arquitetura.

👁️ Segurança de Acesso (Visibilidade)

A Visibilidade controla quem pode "enxergar" ou "alterar" dados dentro de um componente de software. É a base física do Encapsulamento, protegendo a integridade do Banco de Dados contra acessos diretos desprotegidos.

🏗️ Modificadores de Acesso (UML vs Java)

classDiagram
    class ContaBancaria {
        -double saldoOculto
        #String titular
        +efetuarSaque(double valor)
        +consultarSaldo() double
    }

[!TIP] 💡 Padrão de Ouro de Backend: Atributos (Variáveis) devem ser SEMPRE Privados (-). O acesso a eles deve ser feito exclusivamente por métodos Públicos (+) (Getters e Setters) ou métodos de serviço, garantindo que ninguém mude um saldo bancário para negativo por erro de lógica externa.

🏗️ Heranças de Código (Generalização)

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).

🏗️ Hierarquia de Poderes no Java

classDiagram
    class Usuario {
        +String email
        +String senha
        +fazerLogin()
    }
    class Admin {
        +Integer nivelAcesso
        +deletarUsuario()
    }
    class Cliente {
        +String cartaoCredito
        +comprarProduto()
    }
    Usuario <|-- Admin : extends
    Usuario <|-- Cliente : extends

[!TIP] 💡 Generalizar vs Especializar: Subimos na hierarquia (Filha -> Pai) para Generalizar (tirar o que é comum). Descemos na hierarquia (Pai -> Filha) para Especializar (detalhar o comportamento específico do objeto).

🏁 Encerramento da Unidade III (Modelagem)

Parabéns! Você concluiu a base estratégica da Modelagem UML. Agora você entende que software não é apenas texto num arquivo .java, mas um ecossistema de objetos vivos conversando entre si.

🏗️ Checklist de Domínio

Revise se você domina estes conceitos antes de avançar para os diagramas avançados:

✍️ Desafio Sênior (Prática)

Tente esboçar estas soluções mentalmente (ou no papel):

1. 🔍 Lógica de Negócio: Em um sistema de Streaming, como o Include e Extend se aplicariam no ato de "Assistir Filme" considerando "Assinar Premium"?
2. 🔵 Hierarquia: Desenhe a hierarquia de um sistema de Ecommerce onde temos PedidoNacional e PedidoInternacional. O que ficaria na classe pai?
3. 👁️ Segurança: Se um atributo é - saldo, como uma classe externa pode consultá-lo sem quebrar o encapsulamento?

[!TIP] 💡 Próximo Passo: Na Unidade IV, vamos entrar na "Planta Baixa" detalhada. Prepare-se para o Diagramas Estruturais Avançados e Diagramas de Sequência. 🚀

📚 Referências Estratégicas (Unidade III)

Para quem deseja se tornar um Arquiteto de Software, estas são as biblias recomendadas para consulta profunda.

🏗️ Bibliografia Recomendada

• Booch, G.; Rumbaugh, J.; Jacobson, I. UML: Guia do Usuário. Elsevier, 2006. (Os criadores da linguagem).
• FOWLER, M. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, 2003.
• SOMMERVILLE, I. Engenharia de Software. 9. ed. Pearson, 2011.
• MARTIN, R. C. (Uncle Bob) Clean Architecture. Alta Books, 2018.

[!NOTE] 💡 A UML não é para ser decorada, é para ser consultada. Use estas referências para decidir se deve usar uma Agregação ou Composição em casos de dúvida técnica real no projeto.

✅ Gabarito Comentado (Unidade III)

Confira as diretrizes técnicas para os desafios propostos na revisão final da modelagem.

🏛️ Resolução dos Desafios

[!IMPORTANT] 💡 Nota Técnica: Se seus diagramas focaram no "Usuário fazendo algo", você está no caminho certo. UML de Casos de Uso é sobre funcionalidade, não sobre código interno do servidor.

📊 Unidade IV: Diagramas de Sistemas na Prática

Nesta unidade, aplicaremos os conceitos de modelagem na elaboração dos principais diagramas da UML, essenciais para o dia a dia do desenvolvedor.

graph TD
    UML([Diagramas UML])
    UML --> CU[Casos de Uso]
    UML --> CL[Classes]
    UML --> SE[Sequência]
    UML --> ME[Estados]
    UML --> AT[Atividades]
    
    style UML fill:#fff3e0,stroke:#fb8c00

🎯 Objetivos de Aprendizagem (Unidade IV)

Seja bem-vindo à fase avançada da nossa jornada em Engenharia de Software! Agora que já sabemos o que o sistema deve fornecer (Casos de Uso), aprenderemos como ele se organiza internamente e como seus componentes dialogam para realizar tarefas complexas.

Ao concluir esta unidade, você atingirá estes marcos técnicos:

• 🏗️ Projetar Diagramas de Classe rigorosos com multiplicidades e relacionamentos técnicos.
• ⏳ Analisar as trocas de mensagens entre objetos no tempo através do Diagrama de Sequência.
• 🔄 Modelar o ciclo de vida e as mudanças de estado dos objetos do negócio.
• 🌊 Estruturar fluxos de trabalho corporativos e algoritmos complexos via Diagrama de Atividades.

graph LR
    A[Requisitos] --> B[Modelagem Estrutural: CLASSES]
    B --> C[Modelagem Dinâmica: SEQUÊNCIA]
    C --> D[Modelagem de Ciclo: ESTADOS]
    D --> E[Modelagem de Processo: ATIVIDADES]
    
    style B fill:#e3f2fd,stroke:#1e88e5

[!TIP] 💡 A Visão do Arquiteto 👨‍💻: Enquanto arquitetos civis utilizam plantas detalhadas para guiar a construção de edifícios, nós utilizamos estes diagramas para garantir que o código seja construído com qualidade, evitando retrabalho e falhas de comunicação técnica. 🛡️

📅 Plano de Estudo: Unidade IV (Modelagem Dinâmica)

Nesta unidade, assumiremos papéis de verdadeiros Arquitetos de Software, utilizando diagramas que detalham a estrutura estática e o comportamento dinâmico e rigoroso do sistema de software.

🏗️ Tópicos da Trilha de Aprendizagem:

1. 🏗️ Diagrama de Classes Avançado: A "planta baixa" da estrutura estática do sistema. Define quais dados guardamos (atributos) e quais regras de negócio aplicamos (métodos) com foco em multiplicidade.
2. ⏳ Diagrama de Sequência: O "roteiro de cinema". Mostra a ordem exata das mensagens trocadas entre os objetos (Lifelines) para realizar um processo específico do negócio.
3. 🔄 Diagrama de Máquina de Estados: O "ciclo de vida". Descreve como um objeto (ex: um Pedido ou Orçamento) muda sua situação entre os estados permitidos (Pendente, Pago, Entregue).
4. 🌊 Diagrama de Atividades: O "fluxograma inteligente". Ideal para modelar processos complexos de trabalho (workflows) ou a lógica interna de algoritmos de alta complexidade.

[!NOTE] 💡 A Evolução da Modelagem: Passamos da visão externa e informal (Casos de Uso) para a visão técnica e estrutural necessária para a implementação real do código-fonte e do banco de dados. 🛡️

🏗️ Diagrama de Classes - Relacionamentos

O Diagrama de Classes descreve a estrutura estática do sistema, definindo quais classes existem e como elas se relacionam logicamente entre si. É a base para a criação de Entidades em frameworks como Hibernate ou JPA.

🏗️ Classe vs. Tabela de Banco de Dados

[!IMPORTANT] 💡 Não são a mesma coisa: Uma classe não é obrigatoriamente uma tabela de banco de dados. Enquanto tabelas armazenam registros estáticos, as classes residem em memória RAM e possuem métodos (comportamentos). No desenvolvimento moderno, usamos ORMs para mapear um ao outro.

🔗 Tipos de Relacionamentos (Associações)

As classes colaboram entre si para realizar as funcionalidades do sistema. Os principais tipos de associação são:

1. 🤝 Associação Binária

Conecta duas classes distintas, indicando que objetos de uma classe podem se comunicar com objetos da outra.

classDiagram
    class Cliente {
        -String nome
        -String endereco
    }
    class Cidade {
        -String nome
        -String UF
    }
    Cliente "0..*" -- "1" Cidade : Mora em

2. 🔄 Associação Unária (Reflexiva)

Ocorre quando um objeto de uma classe se relaciona com outro objeto da mesma classe. Um exemplo clássico é a relação de Gestão em um time.

classDiagram
    class Funcionario {
        -int matricula
        -String nome
    }
    Funcionario "0..*" -- "0..1" Funcionario : Gerencia

📊 Multiplicidade (Cardinalidade)

A multiplicidade indica quantos objetos de uma classe podem estar ligados a um único objeto da outra classe envolvida:

⏳ Fluxo Temporal (Diagrama de Sequência)

O Diagrama de Sequência foca na ordem temporal das mensagens trocadas entre objetos para realizar um processo específico do negócio ou uma requisição de API.

🏗️ Elementos da Linha de Tempo

🏗️ Exemplo Prático: Fluxo de Autenticação

Representação do fluxo de requisição entre o Front-end e o Back-end para validar um acesso.

sequenceDiagram
    actor U as Usuário App
    participant API as Gateway/Controller
    participant S as AuthService
    
    U->>+API: 1: POST /login (payload)
    API->>+S: 1.1: validateCredentials()
    Note right of S: Consultando Hash no Banco...
    S-->>-API: 1.2: Token JWT Gerado
    API-->>-U: 2: 200 OK (JWT)

[!TIP] 💡 A Importância do detalhe: Cada caso de uso (Unidade III) é detalhado por diagramas de sequência. Isso permite que o Arquiteto preveja gargalos de performance antes mesmo de escrever a primeira Rota.

🔄 Ciclo de Vida (Máquina de Estados)

O Diagrama de Máquina de Estados descreve o comportamento de um objeto único, focando nas transições de situação que ele sofre em resposta a eventos internos ou externos.

🏗️ Conceitos de Estado

🏗️ Exemplo Prático: Lifecycle de um Pedido Ecommerce

Um pedido de vendas percorre diversos estados conforme o pagamento e a logística avançam.

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 --> [*]
    
    style Aberto fill:#fff3e0,stroke:#fb8c00
    style Pago fill:#e1f5fe,stroke:#01579b
    style Entregue fill:#f1f8e9,stroke:#558b2f

[!NOTE] 💡 Onde Aplicar: Este diagrama é vital para sistemas com regras de negócio rígidas para mudanças de situação, como Workflows de Aprovação, Status de Processos Jurídicos ou Logística.

🌊 Fluxogramas de Processo (Diagrama de Atividades)

O Diagrama de Atividades descreve o fluxo de controle de um processo complexo ou algoritmo. Ele é um fluxograma inteligente com suporte a paralelismo e decisões condicionais.

🏗️ Componentes de Fluxo

🏗️ Exemplo Prático: Fluxo de Checkout e Pagamento

Simulação do fluxo desde a escolha do produto até a notificação final de erro ou sucesso.

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 no Cartão]
    D --> F([◉ FIM])
    E --> B
    
    style B fill:#e3f2fd,stroke:#1e88e5
    style D fill:#f1f8e9,stroke:#558b2f
    style E fill:#fdf2f2,stroke:#c0392b

[!TIP] 💡 Visão de Processo: O diagrama de atividades é a melhor ferramenta para documentar o workflow corporativo ou a lógica rigorosa de um algoritmo complexo antes de começar o desenvolvimento.

🏁 Considerações Finais: Unidade IV

Nesta quarta unidade, exploramos a modelagem avançada (estrutural e dinâmica), ferramentas essenciais para reduzir incertezas técnicas no desenvolvimento moderno de software.

🏗️ Resumo dos Diagramas Estudados

✍️ Atividades de Estudo (Prática)

Tente resolver estes desafios técnicos baseados em cenários reais:

1. 🏗️ Modelagem de Classes: Elabore o diagrama com relacionamento 1..*:
   • Classe Pedido: ID (Integer), Data (Date), ValorTotal (Double).
   • Classe ItemPedido: Quantidade (Integer), PrecoUnitario (Double).
2. ⏳ Diagrama de Sequência: Modele o fluxo de um processo de Checkout:
   1. Usuário clica em "Comprar" -> Controller -> PedidoService.
   2. PedidoService chama GatewayPagamento para validar cartão.
   3. Se OK, PedidoService chama NotificacaoService para enviar email.
3. 🔄 Máquina de Estados: Modele o ciclo de um Ticket de Suporte:
   • Aberto -> Em Atendimento -> Resolvido -> Fechado.

[!TIP] 💡 Rumo ao Final: Na próxima e última unidade, estudaremos a Gestão e Qualidade de Software, fechando o ciclo de engenharia profissional de ponta a ponta. 🚀

📚 Referências Avançadas (Unidade IV)

Principais clássicos da literatura técnica de modelagem avançada e arquitetura consultados para esta unidade.

🏗️ Literatura Obrigatória

• FOWLER, M. UML Essencial: Um Breve Guia para a Linguagem-Padrão de Modelagem de Objetos. 3. ed. Porto Alegre: Bookman, 2005.
• GUEDES, G. T. A. UML 2: Uma Abordagem Prática. 2. ed. São Paulo: Novatec, 2011.
• MELO, A. C. Desenvolvendo Aplicações com UML 2.0. Rio de Janeiro: Brasport, 2004.
• SOMMERVILLE, I. Engenharia de Software. 9. ed. Pearson Prentice Hall, 2011.

[!NOTE] 💡 Recomenda-se a leitura de Martin Fowler para entender como a UML pode ser usada de forma ágil e pragmática no dia a dia do desenvolvedor.

✅ Gabarito Comentado (Unidade IV)

Confira as soluções arquiteturais sugeridas para as atividades técnicas de modelagem estrutural e dinâmica.

🏗️ 1. Modelagem de Classes: Pedido e Itens

classDiagram
    class Pedido {
        +Integer id
        +Date data
        +Double valorTotal
        +fecharPedido()
        +cancelar()
    }
    class ItemPedido {
        +Integer quantidade
        +Double precoUnitario
        +calcularSubtotal()
    }
    Pedido "1" -- "1..*" ItemPedido : Contém

⏳ 2. Diagrama de Sequência: Fluxo de Checkout

sequenceDiagram
    actor U as Usuário
    participant C as OrderController
    participant S as OrderService
    participant P as PaymentGateway

    U->>C: 1: Click "Comprar"
    C->>S: 1.1: processCheckout(pedidoId)
    S->>P: 2: validatePayment(cardDetails)
    P-->>S: Approval Status
    S-->>C: Transaction Result
    C-->>U: Success/Failure UI

🔄 3. Máquina de Estados: Ticket de Suporte

stateDiagram-v2
    [*] --> Aberto
    Aberto --> EmAtendimento : Pegar Ticket
    EmAtendimento --> Resolvido : Aplicar Correção
    Resolvido --> Fechado : Confirmado pelo Usuário
    Resolvido --> EmAtendimento : Reaberto (Reprovado)
    Fechado --> [*]
    
    style Aberto fill:#fffde7,stroke:#fbc02d
    style EmAtendimento fill:#e1f5fe,stroke:#01579b
    style Resolvido fill:#f1f8e9,stroke:#558b2f

[!IMPORTANT] 💡 Nota do Arquiteto: Lembre-se que o diagrama é uma ferramenta de comunicação. Se ele estiver complexo demais para explicar aos desenvolvedores, simplifique-o sem perder a precisão da regra de negócio.

🚀 Unidade V: Gerenciamento e Qualidade de Software

Nesta unidade final, entenderemos como gerenciar todo o ciclo de vida do software, garantindo que o produto final seja confiável e passível de evolução.

graph LR
    P[Projeto] --> T[Testes]
    T --> E[Evolução]
    E --> M[Manutenção]
    
    style T fill:#fce4ec,stroke:#d81b60
    style E fill:#e8f5e9,stroke:#43a047

🎯 Objetivos de Aprendizagem (Unidade V)

Ao concluir esta unidade final, o aluno terá dominado os processos críticos para o encerramento do ciclo de vida do software e sua manutenção sustentável:

• 🛡️ Gestão da Qualidade: Conceituar qualidade de software baseada em padrões como ISO/IEC 25010 e fatores determinantes de garantia (QA).
• 🧪 Validação e Verificação: Definir estratégias de testes rigorosos, diferenciando TDD (Test Driven Development) e BDD.
• 🔄 Ciclo de Vida Pós-Entrega: Entender os processos de evolução, refatoração de código e gestão de sistemas legados.
• 📦 Gestão de SCM: Dominar os fundamentos da Gerência de Configuração de Software (Git, GitHub Actions, Baselines).

graph LR
    QA[Garantia de Qualidade] --> T[Testes Automatizados]
    T --> E[Evolução e Manutenção]
    E --> C[DevOps e Configuração]
    
    style C fill:#e1f5fe,stroke:#01579b

[!TIP] 💡 O Final da Jornada: Garantir que o produto entregue seja confiável e passível de evolução técnica é o que diferencia amadores de engenheiros de software seniores que sustentam plataformas de hardware e software por décadas. 🛡️

📅 Plano de Estudo: Unidade V (Pós-Produção)

Nesta unidade final, abordaremos o encerramento do ciclo de vida inicial e a transição para a operação sustentável, focando em garantir que o software seja robusto e lucrativo no longo prazo.

🏗️ Tópicos da Trilha de Aprendizagem:

1. 🛡️ Qualidade de Software: De Crosby e Juran às certificações MPS.BR e CMMI para maturidade de processos.
2. 🧪 Pirâmide de Testes: Diferença entre Testes Unitários, Integração e Sistema (Alfa, Beta e Aceitação).
3. 🔄 Evolução de Software: Tipos de Manutenção (Corretiva, Adaptativa e Evolutiva) e a luta contra a entropia do código.
4. 📦 Gerência de Configuração (Git): Versionamento de artefatos, Controle de Mudanças e Pipelines de CI/CD.

[!NOTE] 💡 A Relevância: Aplicar boas práticas nas fases finais é o que garante que o software não se torne um "peso morto" impossível de manter em poucos anos de uso comercial devido à alta dívida técnica. 🛡️

🛡️ Gestão da Qualidade de Software

A qualidade de software é a satisfação das necessidades funcionais e de desempenho descritas, documentadas e validadas pelo cliente final. Não é um acidente; é o resultado de esforço inteligente.

🏛️ Perspectivas de Qualidade (ISO/IEC)

🏗️ Elementos da Satisfação do Cliente

1. 🏷️ Entidade: O produto digital em si (O Binário/Código que roda).
2. 📝 Necessidades Explícitas: Requisitos de performance e funcionalidade que estão no Contrato/User Story.
3. 🧩 Necessidades Implícitas: Expectativas de UX e Estabilidade que não foram ditas, mas são obrigatórias para o sucesso.

[!IMPORTANT] 💡 A Decisão Estratégica: A escolha de qual norma ou modelo (ISO, CMMI, MPS.BR) aplicar depende do mercado corporativo onde a empresa atua e do ROI (Retorno sobre Investimento) da certificação. 🛡️

🧪 Teste de Software e Automação

Testar é o processo de executar o software com a intenção deliberada de encontrar erros e validar o comportamento esperado. Na Engenharia moderna, os testes são, em sua maioria, automatizados.

🏛️ Pirâmide de Testes (Níveis)

Os testes são organizados por granularidade. Quanto mais baixo na pirâmide, mais rápido e barato é o teste.

graph TD
    A["📦 Teste Unitário - Ex: 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íveis de Validação

[!IMPORTANT] 💡 Axiomas do Teste:

• Testes mostram a presença de erros, nunca a sua ausência total.
• É impossível realizar testes exaustivos (todas as combinações possíveis).
• Princípio de Pareto: 80% dos defeitos estão concentrados em 20% das funcionalidades mais complexas. 🛡️

🔄 Evolução e Manutenção Sustentável

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.

🏗️ Tipos de Manutenção no Ciclo de Vida

[!TIP] 💡 Vigilância da Dívida Técnica: Manutenções feitas às pressas geram "Dívida Técnica". Se não for paga com sessões de Refatoração (Perfectiva), o custo de manter o sistema cresce até se tornar financeiramente inviável. 🛡️

📦 Gerência de Configuração (Git e CI/CD)

O SCM (Software Configuration Management) gerencia as mudanças inevitáveis nos artefatos de software. No mundo moderno, isso é sinônimo de Git e esteiras de automação (DevOps).

🏗️ 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 Requests Review]
    Versao --> Conflito[Merge Conflict Resolution]
    Construcao --> Exec[Continuous Integration]
    Release --> Entrega[Continuous Delivery]

🏗️ Terminologias de Mercado

[!NOTE] 💡 GIT como Padrão: Não saber usar Git hoje em dia é como um engenheiro civil que não sabe usar uma trena. É a ferramenta base que garante que dez desenvolvedores possam mexer no mesmo arquivo sem destruir o trabalho um do outro. 🛡️

🏁 Considerações Finais: Unidade V

Chegamos ao fim da nossa jornada pela Engenharia de Software. Nesta unidade, vimos que o software não é um projeto estático, mas um organismo vivo que exige Qualidade, Testes Automatizados e Governança de Versão para sobreviver.

🏗️ Resumo da Governança

• 🛡️ Qualidade: Conformidade com o negócio e satisfação do usuário (ISO 25010).
• 🧪 Testes: Pirâmide de testes (Unitário -> Integração -> Sistema).
• 🔄 Evolução: Combate à dívida técnica e manutenção (Corretiva/Evolutiva).
• 📦 SCM: Versionamento profissional (Git) e entrega contínua (Releases).

✍️ Atividades de Estudo (Consolidação)

1. 📊 Ciclo de Vida: Por que a Gerência de Configuração deve começar no dia 1 do projeto e não apenas na entrega?
2. 🧪 QA vs Teste: Explique a diferença entre Garantia da Qualidade (Processo) e Teste de Software (Produto).
3. 🌿 Branching Strategy: Pesquise sobre o GitFlow e explique como ele organiza os ramos de Feature, Develop e Main.
4. 🏁 Níveis de Teste: Onde se encaixa o teste de estresse (Performance) na hierarquia de validação?

[!TIP] 💡 Parabéns pela Jornada! Você agora possui as bases conceituais para atuar como um Engenheiro(a) de Software comprometido com o rigor técnico, agilidade e, acima de tudo, a entrega de valor real. 🚀🛡️

📚 Referências de Gestão e Qualidade (Unidade V)

Principais obras e autores consultados para a construção da Unidade de Gerenciamento e Ciclo de Vida.

🏗️ Literatura Fundamental

• PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: Uma Abordagem Profissional. 8. ed. McGraw Hill, 2016.
• MYERS, G. J. The Art of Software Testing. John Wiley & Sons, 1979.
• SOMMERVILLE, I. Engenharia de Software. 9. ed. Pearson Education, 2011.
• CHACON, S.; STRAUB, B. Pro Git. 2. ed. Apress, 2014. (A bíblia do versionamento).

[!NOTE] 💡 Recomenda-se a leitura de Pressman para uma visão holística de como a qualidade deve ser gerenciada em grandes corporações.

✅ Gabarito Comentado (Unidade V)

Resumo das diretrizes técnicas para as atividades de revisão de Gerenciamento e Qualidade.

🏛️ Resolução dos Desafios

[!IMPORTANT] 💡 Nota Final: Se você compreendeu que o teste automatizado é um investimento (e não perda de tempo), você captou a essência da Engenharia de Software Profissional.

🚀 Conclusão Final: O Arquiteto do Amanhã

Neste portal, exploramos a jornada completa da Engenharia de Software, desde seus conceitos fundamentais até as etapas críticas de gestão, qualidade e manutenção profissional. 🛡️🧩

🏛️ Resumo da Nossa Trajetória

Esperamos que este handbook digital sirva como um guia prático e teórico sólido para sua carreira. A Engenharia de Software não é apenas sobre escrever código, mas sobre construir soluções resilientes, escaláveis e de alta qualidade que resolvam problemas reais da humanidade.

Desejamos muito sucesso em sua trajetória como Engenheiro(a) de Software Profissional! 🚀🛡️

Coordenação de Engenharia de Software Moderno