Data Science Lab

SQL é a linguagem comum nas equipes de Ciência de Dados

Hoje vou fazer um resumo do material disponível no curso de ciência de dados, na disciplina de Modelagem de Banco de Dados.

Quando pensamos em Ciência de Dados, é comum o foco ir direto para Python, notebooks e modelos de Machine Learning. Mas, na prática, a linguagem “comum” que une cientistas de dados, analistas, engenheiros e DBAs ainda é o SQL, rodando em cima de bancos de dados relacionais.

---

Tendo como ponto de partida os requisitos de informação e as regras de negócio inerentes a um determinado domínio de problema, com ferramentas de modelagem, procuramos atender a uma série de critérios de qualidade.

De forma simplificada, podemos pensar um Banco de Dados (BD) como:

BD -> Estrutura + Comportamento + Estado + Persistência + Consistência + Transação

Onde:

Estrutura – É o esquema do banco: tabelas, colunas, tipos de dados, chaves primárias, chaves estrangeiras e índices.
Ex.: tabela Empregado(id, nome, salario, id_departamento).

Estado – São os valores armazenados nas tabelas em um certo instante. Se você tirar um “snapshot” hoje da tabela Empregado, isso é o estado atual do banco.

Comportamento – É como o estado muda ao longo do tempo: inserts, updates, deletes, execuções de stored procedures, gatilhos (triggers) etc.

Persistência – Significa que os dados sobrevivem ao término do programa e a desligamentos do sistema. Ou seja, os dados são gravados em disco/SSD de forma durável.

Consistência – O banco precisa respeitar as regras de integridade (chaves primárias/estrangeiras, restrições, regras de negócio). Não pode permitir, por exemplo, funcionário sem departamento válido se isso for proibido pelo modelo.

Transações – Alterações relevantes são agrupadas em transações. Uma transação é um conjunto de operações que deve ser executado como uma unidade lógica (tudo ou nada).

Uma forma mnemônica de lembrar as características do banco transacional é usando a famosa sigla ACID:

1. Atomicidade (A)
   Ou tudo é confirmado ou tudo é desfeito.
   • Ex.: transferir dinheiro de uma conta para outra envolve dois updates. Ou os dois ocorrem, ou nenhum ocorre.
2. Consistência (C)
   Cada transação leva o banco de um estado consistente para outro estado consistente, respeitando regras de negócio e integridade referencial.
3. Isolamento (I)
   Transações concorrentes não devem interferir de forma incorreta umas nas outras.
   • Idealmente, é como se cada transação rodasse “sozinha” no banco.
4. Durabilidade (D)
   Uma vez que a transação foi confirmada (COMMIT), suas mudanças são permanentes, mesmo em caso de falhas (queda de energia, crash do servidor etc.).

Requisitos de Informação

Representam as necessidades de informação dos processos da empresa, expressos no projeto do banco de dados. São as perguntas que o sistema precisa responder…

Por exemplo, o usuário do sistema deseja saber quais os dados do Empregado chefe de um determinado Departamento.

A modelagem dos dados deve estar preparada para atender aos requisitos de informação.

Para que isso seja possível, precisamos:

• uma entidade/tabela Empregado;
• uma entidade/tabela Departamento;
• algum campo ou relacionamento que indique quem é o chefe daquele departamento (por exemplo, Departamento.id_chefe como chave estrangeira para Empregado.id).

Esses requisitos guiam a modelagem conceitual e depois a modelagem lógica.

Regras de negócio e integridade

Representam as restrições com que devem ser conduzidos os processos da empresa.

Exemplo de regra: um chefe não deve ganhar menos que seus chefiados.

Essa regra pode ser implementada em:

• nível de banco: com triggers, constraints, procedures capazes de validar salários antes de confirmar uma transação;
• nível de aplicação: o sistema valida antes de gravar;
• ou, idealmente, em ambos.

Essa restrição deve estar implementada paga garantir a integridade do banco de dados. Quando regras importantes não são aplicadas no banco, abre-se espaço para inconsistências se outro sistema/aplicativo gravar dados diretamente.

Modelagem de dados: do conceito ao físico.

Modelo Conceitual – DER (Diagrama Entidade-Relacionamento)

É a visão de alto nível do domínio, frequentemente usando DER:

Atributos: características das entidades (nome, data_nascimento, ip, num_serie etc.).

Entidades: objetos principais de interesse (por ex.: Pessoa, PC, Departamento, Empregado).

Relacionamentos: como as entidades se relacionam, com cardinalidades (1:1, 1:N, N:M).

Por exemplo:

(E) (R) (E)

Pessoa – usa – PC

Nome Data Num Serie

Sexo Hora IP

Modelo Lógico – Modelo de Dados Relacional
Transformamos o DER em tabelas relacionais:

• tabelas (Pessoa, PC, possivelmente Pessoa_PC se o relacionamento for N:M),
• chaves primárias,
• chaves estrangeiras,
• tipos de dados.

Aqui, já começamos a falar em SQL (CREATE TABLE, PRIMARY KEY, FOREIGN KEY).

Modelo Físico – Implementação no SGBD

Finalmente, mapeamos o modelo lógico para um SGBD específico:

• Oracle
• SQL Server
• PostgreSQL
• MariaDB / MySQL
• SQLite
• etc.

No modelo físico, entram detalhes como:

• tipos específicos (VARCHAR2, NUMERIC, TIMESTAMP etc.)
• tuning de desempenho.
• índices
• partições
• parâmetros de armazenamento,

Normalização e redução de redundâncias

Redundâncias provocam inconsistência. Para resolver esse problema devemos aplicar a normalização do banco de dados.

A ideia central da normalização é organizar as tabelas para:

• minimizar redundâncias desnecessárias, e
• evitar anomalias de inclusão, alteração e exclusão.

Resumo das Formas Normais mais usadas:

1. Primeira Forma Normal (1FN)
   • Não há atributos multivalorados ou repetidos.
   • Cada coluna armazena um único valor “atômico” (sem listas/arrays dentro da mesma coluna).
2. Segunda Forma Normal (2FN)
   • Estar em 1FN e
   • todos os atributos não-chave dependem da chave inteira, e não de parte dela (caso a chave seja composta).
3. Terceira Forma Normal (3FN)
   • Estar em 2FN e
   • não existir dependência transitiva (atributo não-chave não depende de outro atributo não-chave).

Em projetos grandes, também se fala em BCNF (Forma Normal de Boyce-Codd), que é uma versão um pouco mais rigorosa que a 3FN.

Na prática, em sistemas OLTP (transacionais), a normalização é quase sempre usada. Em Data Warehouses, às vezes aceitamos certa desnormalização para facilitar consultas analíticas e melhorar desempenho.

Por que SQL ainda é muito usado ?

Na prática, quase todo projeto de Ciência de Dados começa no banco de dados, não no notebook de Python. Os dados de vendas, clientes, produtos, acessos ao site, transações financeiras… tudo isso costuma estar em bancos relacionais (PostgreSQL, SQL Server, Oracle, MySQL) ou data warehouses que também falam SQL (BigQuery, Snowflake, Redshift).

Imagine um caso real: uma equipe de dados quer prever churn — quais clientes têm maior chance de cancelar um serviço de assinatura (por exemplo, uma plataforma de cursos online). Antes de treinar qualquer modelo em Python, alguém precisa:

• juntar informações de clientes, planos, pagamentos e uso da plataforma;
• gerar métricas agregadas (ex.: quantas aulas o cliente assistiu nos últimos 30 dias);
• marcar no histórico quais clientes cancelaram em determinado período (rótulo de churn).

Isso ainda é feito, em grande parte, com SQL !

Dica de alguns livros clássicos e úteis para estudar mais:

1. “Fundamentals of Database Systems” – Ramez Elmasri, Shamkant Navathe
   • Bastante completo, cobrindo modelagem conceitual, relacional, normalização, SQL e tópicos mais avançados.
   • Bom como referência “para a vida toda”.
2. “Database System Concepts” – Abraham Silberschatz, Henry Korth, S. Sudarshan
   • Forte tanto em conceitos quanto em implementação de SGBD.
   • Excelente para entender por trás dos panos (como o banco “funciona” internamente).
3. Livros do C. J. Date (por exemplo, “An Introduction to Database Systems”)
   • Foco muito forte em teoria relacional.
   • Recomendado se você quiser uma compreensão mais formal e rigorosa do modelo relacional.

Por hoje é isso! Até o próximo post !!