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

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

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

?? PASSO 1: O Modelo de Privilégios

?? Hierarquia de Acesso

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

Tipos de Privilégios SQL

?? PASSO 2: Criando Usuários

?? MySQL 8.4

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

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

?? PostgreSQL 17

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

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

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

?? MySQL 8.4

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

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

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

-- Aplicar as alterações
FLUSH PRIVILEGES;

?? PostgreSQL 17

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

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

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

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

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

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

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

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

?? PostgreSQL 17 (Suporte nativo a Roles)

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

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

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

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

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

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

?? Modelo de Roles

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

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

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

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

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

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

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

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

??? EVOLUÇÃO E ARQUITETURAS MODERNAS

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

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

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

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

?? Ciclo de Adaptação

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

?? MySQL 8.4 (MODIFY)

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

?? PostgreSQL 17 (ALTER TYPE)

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

?? PASSO 2: JSON em Bancos Relacionais

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

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