A Religião dos Dados: Integrando SQL e NoSQL no Desenvolvimento Moderno

Vivemos uma época em que os dados deixaram de ser apenas registros auxiliares de processos computacionais para se tornarem o eixo estruturante das decisões técnicas, econômicas e sociais. Em sistemas distribuídos, aplicações corporativas, plataformas digitais e, mais recentemente, em modelos de inteligência artificial, os dados são tratados como verdade objetiva, frequentemente imune a questionamentos. Esse fenômeno não se refere a uma rejeição da ciência ou da técnica, mas ao uso acrítico de métricas, estatísticas e modelos computacionais como se fossem representações perfeitas da realidade.

No ecossistema de desenvolvimento de software, essa postura se manifesta de forma recorrente em dashboards que substituem análises conceituais, métricas de produtividade que se sobrepõem à qualidade estrutural do código, e modelos estatísticos são tratados como oráculos infalíveis. O objetivo deste artigo é expandir criticamente essas ideias, articulando fundamentos técnicos, epistemológicos e práticos, de forma acessível a estudantes e profissionais de TI, sem perder o rigor conceitual.

1. Dados Não São Realidade, São Observações

Do ponto de vista científico, dados são observações registradas a partir de instrumentos, métodos e modelos conceituais. Eles não existem de forma neutra. Todo dado carrega consigo uma:

• Uma intencionalidade, ou seja que se decidiu medir, filosoficamente, podemos dizer que ela está ligada a uma crença, desejo ou pretensão ou seja, podem ser direcionados para alcançar ou corroborar com um determinado objetivo. Em suma está ligado a um propósito específico;
• Uma instrumentação que detalhe como foi medido ou coletado;
• Um contexto quando, onde e sob quais condições o dado foi obtido;
• Uma interpretação implícita o que se espera inferir, ou qual o objetivo final deste levantamento.

A transação da observação bruta para a representação digital exige que estruturas de dados e esquemas de banco funcionem como um “santuário” onde repousam os deuses. Quando definimos um campo status, estamos, na verdade, codificando os mandamentos de integridade, consistência e coerência que regem aquela entidade. Essa organização não é neutra, o dado deixa de ser um registro inerte para se tornar uma interpretação ativa da realidade, moldada pelas regras de negócio que o aprisionam em tabelas ou o libertam em documentos.

Na distribuição e coleta de dados, essa ontologia se torna ainda mais complexa ao enfrentar o “calvário” da concorrência e da escalabilidade. A coleta massiva para Big Data frequentemente abandona a rigidez das transações ACID em favor da consistência eventual, onde sistemas gerenciadores aceitam um estado de fluxo para processar logs e eventos em grandes quantidades. O desenvolvedor tem que entender que cada formato de serialização ou estratégia de particionamento é uma peça de um mosaico arquitetônico, um grafo para mapear teias de destino ou um banco chave-valor para respostas rápidas como um relâmpago. Ignorar essa camada é cair na tentação de estruturar tudo dentro de um formato rígido.

Quando ignoramos essa camada conceitual, passamos a tratar dados como verdades absolutas, e não como representações parciais. A ciência da computação, enquanto disciplina formal, sempre reconheceu essa limitação. Desde os trabalhos de Turing, Church e Shannon, há uma distinção clara entre o modelo e o fenômeno. A Religião dos Dados surge quando essa distinção é abandonada em favor da conveniência operacional. A transição do modelo relacional ao NoSQL representa, nesse contexto, uma revolução, questionando as práticas estabelecidas e abrindo caminho para novas abordagens.

2. A materialização Técnica dos Dados

2.1 Estruturas, esquemas e normalização

O modelo relacional, com suas Normal Forms (1NF, 2NF, 3NF, etc.), impõe um conjunto rigoroso de regras para a organização dos dados. Essas regras visam eliminar redundâncias, garantir a integridade referencial e facilitar a consistência dos dados. A aplicação dessas formalizações, exige um profundo entendimento das regras e uma aderência estrita, o que por sí só, pode levar a complexidades e, em alguns casos, impactar negativamente a performance, especialmente em aplicações que exigem alta velocidade e flexibilidade. A obsessão pela normalização, como um dogma, pode levar a decisões sub-otimizadas para o desempenho.

O modelo, foi proposto por Edgar F. Codd na década de 1970, e trouxe a promessa de três pilares fundamentais: integridade, consistência e coerência. Apoiado nos pilares, temos toda a estrutura e seus elementos.

As Tabelas ou entidades, funcionam como templos onde os dados residem, representa um conjunto de informações relacionadas entre sí, como dados de um cliente ou de movimentações de conta corrente, elas são organizadas em linhas que dependendo do contexto podem ser chamadas de registros ou de tuplas, estas por sua vez são divididas em colunas que se referem aos atributos ou campos que armazenam um conteúdo nomeado ou especificado. Tecnicamente, são uma estrutura lógica que permite armazenar e recuperar dados de forma organizada e eficiente e com uma certa granularidade, elas são o bloco fundamental dos bancos de dados relacionais.

A estruturação de consultas a esses dados são feitas, majoritariamente, através das linguagem SQL (Structured Query Language) ou em tradução livre linguagem de consulta estruturada, que é composta por Selects e Joins onde estes representam a união de tabelas, ou seja, são uma aplicação prática da Álgebra Relacional, que por sua vez encontra seus alicerces na Teoria dos Conjuntos. Quando realizamos um JOIN, estamos essencialmente definindo como dois domínios de dados (Conjunto A e Conjunto B) devem interagir para produzir uma nova verdade estruturada.

Pora gerenciar essas relações, são usadas as Chaves Primárias e Estrangeiras que representam votos de fidelidade, elas é que garantem que as entidades se relacionem sem perder sua identidade. Elas é que estruturam as operações matemáticas entre os diferentes conjuntos.

Por fim, temos os índices estruturas que atuam como anjos que aceleram a busca, porém, como tudo cobra o seu preço esse ganho de velocidade na pesquisa significa também um maior tempo para escrita e atualização dos dados, e maior consumo de memória e energia. ou seja, exigem uma manutenção proporcional e o equilibrio dessas estruturas é o diferencial do profissional de TI.

2.2 As Leis da Pureza: Formas Normais

A normalização, ou seja, a aplicação de regras para garantir a correta estruturação e relação das tabelas é o caminho para a pureza dos dados, regida por mandamentos rígidos, onde temos:

Primeira Forma Normal (1FN): Traz a clareza ao eliminar repetições e grupos multivalorados. É o estágio inicial da purificação de dados, cujo dogma central é a clareza para alcançá-la, devemos garantir que cada campo em uma tabela contenha apenas valores atômicos e indivisíveis, removendo colunas que armazenam listas ou conjuntos de informações em uma única célula. Na prática, isso exige que atributos repetitivos sejam movidos para novas tabelas distintas, assegurando que não existam vetores de dados ocultos e que cada registro seja único e identificável por meio de uma chave primária que é usada para identificar exclusivamente um único registro de modo inequívoco. Essa regra deve ser aplicada a TODAS as tabelas do banco de dados.

Segunda Forma Normal (2FN): Estabelece a disciplina, onde a chave primária é a única a ser adorada, é o degrau da dependência funcional, onde ela é estabelecida, combatendo a heresia da redundância. Para que uma tabela alcance este estado, ela deve estar na 1FN e, adicionalmente, garantir que todos os atributos não-chave dependam de toda a chave primária, e não apenas de parte dela. Este problema surge tipicamente em tabelas com chaves compostas, onde uma coluna depende apenas de um dos membros da chave, significando que ela está “fora de lugar” e deve ser transladada para uma nova morada.

Terceira Forma Normal (3FN): Garante a integridade ao ignorar a transitividade e os falsos profetas das dependências indiretas. Para que se alcance este estagio, tudo deve estar na 2FN e, adicionalmente, garantir que nenhum atributo não-chave dependa de outro atributo não-chave. Ou seja, cada coluna deve prestar contas diretamente à Chave Primária, e somente a ela. Para isso, devemos remover os atributos que dependem de outros atributos não-chave e movê-los para a sua própria tabela.

Ao chegar a este ponto podemos dizer que cerca de 90% dos bancos de dados estão totalmente funcionais e sem nenhum risco, mais esses 10% restantes, ainda temos outras soluções e aplicações mais específicas.

BCNF (Boyce-Codd): O “véu do templo” onde todo determinante deve ser uma chave. É uma extensão rigorosa da 3FN e lida com as chaves candidatas compostas que podem se sobrepor. Ou seja, ela deve obedecer a uma regra semântica absoluta: Para toda dependência funcional não trivial (X → Y), X deve ser uma chave candidata. Em termos simples: qualquer coluna (ou grupo de colunas) que determine o valor de outra deve ser, obrigatoriamente, uma chave da tabela. O Cenário de Conflito (Violação da BCNF): Imagine um sistema de consultoria técnica onde 1- Um Cliente pode contratar várias Tecnologias (ex: Python, SQL, Java). 2- Para cada tecnologia contratada, é atribuído um Especialista específico. 3- Cada Especialista trabalha com apenas uma tecnologia.

Está na 3FN pois não há dependências parciais (o Especialista depende de ambos Cliente e Tecnologia para aquela linha) nem dependências transitivas entre colunas não-chave. O Problema (A Dependência Oculta) como cada Especialista só domina uma tecnologia, temos a dependência: Especialista → Tecnologia. A Violação: O “Especialista” determina a “Tecnologia”, mas o Especialista não é uma chave. Isso gera anomalias: se o especialista sair da empresa, perdemos a informação de que ele era o especialista em SQL (Anomalia de Exclusão). SOLUÇÃO devemos decompor a tabela para que cada determinante seja uma chave. Separamos a responsabilidade do especialista da responsabilidade da alocação do cliente.

Quarta Forma Normal (4FN): representa um nível de refinamento que transcende a lógica das chaves e das dependências funcionais, focando-se na resolução de uma heresia específica: a Dependência Multivalorada (MVD). Enquanto a 3FN e a BCNF lidam com atributos que “determinam” outros, a 4FN intervém quando atributos independentes entre si são forçados a coexistir na mesma tabela devido à estrutura de chaves, gerando uma explosão de redundância. Para que uma tabela esteja na 4FN, ela deve primeiro estar na BCNF e não deve possuir dependências multivaloradas não triviais. Imagine um cenário onde um Especialista possui várias Habilidades (ex: Java, Python) e fala vários Idiomas (ex: Inglês, Espanhol). Não existe qualquer relação entre a habilidade e o idioma; o fato de ele saber Java não o obriga a falar Inglês. Se tentarmos colocar tudo numa única tabela com chave composta (Especialista + Habilidade + Idioma), caímos no caos. Para cada nova habilidade que o especialista aprende, temos de inserir múltiplas linhas para cobrir todos os idiomas que ele já fala. Esta é a Dependência Multivalorada. O Especialista determina um conjunto de habilidades e, de forma independente, um conjunto de idiomas. Misturá-los cria um produto cartesiano desnecessário. A solução para alcançar a 4FN é separar as “verdades” independentes em moradas distintas.

Não permitimos que dois factos multivalorados independentes partilhem a mesma estrutura. No modelo anterior, se o especialista dominasse 10 habilidades e falasse 5 idiomas, teríamos 50 linhas. Na 4FN, temos apenas 15. Esta forma normal é o guardião da Escalabilidade. Ela ensina que, misturar dimensões independentes apenas para “aproveitar a tabela” é um caminho que leva ao inchaço do armazenamento e à corrupção da lógica de atualização.

Quinta Forma Normal (5FN), também conhecida como Forma Normal de Projeção-Junção (PJ/NF), representa o ápice do refinamento no modelo relacional, a 5FN lida com uma patologia muito mais subtil: as Dependências de Junção (Join Dependencies). Ela ocorre quando um registo só pode ser reconstruído corretamente através da junção de três ou mais tabelas, e a sua decomposição em apenas duas tabelas geraria “dados fantasmas” (registos que não existem na realidade). Para estar na 5FN, uma tabela deve estar na 4FN e não possuir dependências de junção que não sejam implícitas pelas chaves candidatas.

Imagine um cenário de consultoria onde temos três entidades: Especialista, Projeto e Tecnologia. Existe uma regra de negócio complexa: Um especialista só trabalha num projeto se ele dominar a tecnologia que esse projeto exige. Se tentarmos manter tudo numa tabela única, teremos uma redundância cíclica. Se tentarmos decompor isto em apenas duas tabelas (ex: Especialista-Projeto e Projeto-Tecnologia), ao tentar juntá-las novamente via SQL, o banco de dados pode “inventar” que ESPECIALISTA A trabalha no Projeto Beta ou que o ESPECIALISTA B usa SQL no Projeto Beta, o que pode ser falso. É uma relação onde a verdade só é preservada se analisarmos os três componentes simultaneamente.

Para purificar esta estrutura e atingir a 5FN, devemos decompor a tabela original em três tabelas distintas, representando todas as combinações binárias possíveis. A “verdade” total é a intersecção destas três.

1. Tabela A (Especialista + Projeto)

2. Tabela B (Projeto + Tecnologia)

3. Tabela C (Especialista + Tecnologia)

A 5FN é raramente atingida na prática comercial devido à sua extrema complexidade de manutenção e ao custo computacional de realizar múltiplos joins para reconstruir uma simples linha de informação. No entanto, ela é o lembrete de que a estrutura de dados é um reflexo exato da lógica de negócio: se a regra de negócio é ternária, a persistência deve respeitar essa trindade para evitar a corrupção da verdade.

2.3. Encontrando o Equilibrio – Velocidade e Consistência

Contudo, a busca pela pureza extrema (4FN e 5FN) cobra seu preço no “sacrifício da performance”. Modelos excessivamente fragmentados tornam o acesso lento, gerando o primeiro grande dilema Pureza ou Velocidade? Em bancos de dados relacionais, os dados são organizados segundo esquemas rigidamente definidos. Tipos, restrições, chaves e relacionamentos não são apenas detalhes técnicos: eles formalizam hipóteses sobre o domínio do problema.

A Aceleração da Pesquisa pode ser obtida como falamos, com o uso de indices, que funciona como o catálogo de uma biblioteca ou o índice remissivo de um livro. Em vez de o banco de dados realizar um Full Table Scan (percorrer cada linha da “tabela” para encontrar um fiel), ele consulta uma estrutura paralela, geralmente uma B-Tree (Árvore Balanceada), que aponta diretamente para o endereço físico do dado. Redução de I/O: O índice permite que o otimizador ignore grandes volumes de dados irrelevantes, focando apenas nos ponteiros necessários. Complexidade Logarítmica: Em termos algorítmicos, passamos de uma busca linear $O(n)$ para uma busca logarítmica $O(\log n)$, o que significa que, mesmo que a base de dados cresça exponencialmente, o tempo de busca aumenta de forma mínima.

Embora o índice acelere a leitura, ele atua como um “freio” nas operações de modificação (INSERT, UPDATE, DELETE). Isso ocorre porque cada mudança no dado real exige uma atualização correspondente em todos os índices associados. Ao inserir uma nova linha, o banco não apenas escreve na tabela, mas deve encontrar a posição correta na árvore do índice e reordená-la para manter o equilíbrio. Se um campo indexado é alterado, o índice antigo deve ser removido e um novo deve ser inserido na posição correta, duplicando o esforço computacional. Cada índice consome memória, energia e atenção do hardware, tornando o ambiente “pesado” e denso.

Com o tempo, e o uso intenso de inserções e deleções os indices passam a sofrer fragmentação, ou seja, as páginas do índice começam a ficar com espaços vazios ou fora de ordem física, forçando o banco de dados a realizar saltos desnecessários no disco. Por isso, existe a reindexação, ou seja, o processo de reconstruir o índice do zero para eliminar esses espaços vazios e reorganizar os nós da árvore ou rebalancear. Isso restaura a performance original, mas é um processo custoso que pode bloquear o acesso à tabela durante sua execução.

Temos também as estatísticas obsoletas, um mecanismo de otimização dos bancos de dados, que de acordo com a estrutura física, depende de estatísticas para decidir se usará o índice ou não. Se as estatísticas não forem atualizadas, o otimizador pode “cair em tentação” e escolher um caminho ineficiente, levando à perda de performance. Isso aliado a mecanismos de otimização de IO de disco, que por exemplo ao invez de excluir fisicamente alguns registros, somente os marca como excluídos, cria a necessidade de “aspirar” algumas tabelas, o vacuum, de alguns mecanismos faz essa tarefa, reduzindo o tamanho físico do banco em disco e recriando indices e o gerenciador de estatísticas.

Nota: Ter índices demais é tão perigoso quanto não ter nenhum, pois o excesso consome IOPS e CPU do seu servidor. A normalização, por exemplo, parte do princípio de que redundância excessiva gera inconsistência. Porém, em sistemas analíticos modernos (data warehouses e data lakes), frequentemente se opta pela desnormalização, privilegiando desempenho e simplicidade de consulta. Essa escolha técnica impacta diretamente a forma como os dados serão interpretados e utilizados.

2.4 Dados em sistemas distribuídos – Teorema CAP

Em arquiteturas distribuídas, os dados são fragmentados, replicados e eventualmente consistentes. O Teorema CAP demonstra que não é possível garantir simultaneamente consistência forte, disponibilidade e tolerância a particionamento.

Na prática, isso significa que o dado pode estar temporariamente incorreto, que leituras diferentes podem retornar valores distintos e que a noção de “verdade” é contextual e temporal. Ignorar essas propriedades e tratar os dados como uma fonte absoluta de verdade é um erro conceitual grave, com impactos diretos em sistemas financeiros, de saúde e de infraestrutura crítica.

O Teorema CAP, também conhecido como Teorema de Brewer, é um dos pilares fundamentais para quem trabalha com sistemas distribuídos e arquitetura de dados. Ele postula que é matematicamente impossível para um sistema de dados distribuído fornecer simultaneamente mais de duas das três garantias seguintes:

1. Consistência (Consistency): Todos os nós (servidores) veem os mesmos dados ao mesmo tempo. Se escreveres um dado no Nó A, qualquer leitura feita imediatamente a seguir no Nó B deve retornar esse novo dado. É o equivalente a ter uma “verdade única” em todo o sistema.

2. Disponibilidade (Availability): Cada pedido recebido por um nó (que não esteja em falha) deve gerar uma resposta (sucesso ou erro), sem a garantia de que contém a escrita mais recente. Em suma, o sistema está sempre “online” e funcional, mesmo que alguns nós falhem.

3. Tolerância a Partições (Partition Tolerance):O sistema continua a operar apesar de quebras de comunicação (partições de rede) entre os nós. Num mundo onde as redes não são perfeitas, esta é uma realidade inevitável para qualquer sistema distribuído.

A Escolha Inevitável: O Dilema do Arquiteto

O teorema afirma que, quando ocorre uma partição de rede (a letra P), o sistema precisa escolher entre C ou A:
– CP (Consistência + Tolerância a Partições): Se a rede falha, o sistema bloqueia as escritas e leituras até que a consistência seja garantida novamente. Escolhes a “verdade” em vez da disponibilidade.  Exemplos: MongoDB, HBase, Redis (em certas configurações).
– AP (Disponibilidade + Tolerância a Partições): O sistema permite que os nós continuem a responder, mesmo que não consigam comunicar entre si. Isso pode levar a dados divergentes entre os nós (consistência eventual). Escolhes a “presença” em vez da verdade imediata. Exemplos: Cassandra, DynamoDB, CouchDB.
– CA (Consistência + Disponibilidade): Teoricamente, um sistema que não tolera falhas de rede. Na prática, sistemas distribuídos não podem ser puramente CA, pois as falhas de rede são inevitáveis. Um banco de dados relacional tradicional (como um PostgreSQL num único servidor) é tecnicamente CA até ser distribuído.

O Teorema CAP é a “lei da física” que impede a criação de um sistema perfeito. Ele obriga o engenheiro de software a atuar como um filósofo: onde deve decidir, num momento de crise, se o sistema deve permanecer fiel à última informação gravada (CP) ou se deve continuar a servir o utilizador, mesmo que a informação esteja ligeiramente desatualizada (AP).

3. Métricas, KPIs e a ilusão da objetividade

3.1 Métricas de software

Métricas como lines of code(linhas de código), velocity (velocidade), lead time (latencia), coverage(cobertura) e story points são amplamente utilizadas para avaliar desempenho de equipes e qualidade de software. No entanto, cada uma dessas métricas mede apenas um aspecto parcial do sistema. Como o aumento de coverage não garante testes significativos, a alta velocity pode mascarar dívida técnica, a redução de lead time pode comprometer robustez arquitetural.

As métricas de software funcionam como os rituais de autoavaliação dentro do ecossistema de desenvolvimento, permitindo que a “saúde” de um projeto seja quantificada de forma objetiva. Métricas como a Complexidade Ciclomática de McCabe são fundamentais: elas medem o número de caminhos linearmente independentes através do código-fonte, servindo como um indicador direto de quão difícil será testar ou manter um algoritmo. Se a complexidade é excessiva, o código torna-se um “labirinto de heresias” onde erros se escondem facilmente, exigindo que o arquiteto intervenha para simplificar a estrutura e restaurar a clareza técnica. Quando essas métricas passam a orientar decisões estratégicas sem análise crítica, elas deixam de ser instrumentos e se tornam dogmas.

No contexto específico dos sistemas de bases de dados, as métricas de software funcionam como um “termómetro” da persistência, permitindo quantificar a eficiência com que o código interage com o armazenamento. Uma das métricas mais críticas é a Latência de Consulta (Query Latency), que mede o tempo entre a invocação do SQL e a revelação do resultado. Elevadas latências são frequentemente sintomas de “pecados” arquiteturais, como a ausência de índices adequados ou a existência de scans completos em tabelas massivas. Monitorizar o Buffer Cache é igualmente vital, pois indica o percentual de vezes que o sistema encontrou a verdade na memória ultra-rápida, sem precisar de idas lentas do disco rígido, servindo como um indicador direto da maturidade da configuração do SGDB.

Além da performance pura, métricas de Concorrência e Contenda (Lock Contention) revelam como o sistema lida com o livre-arbítrio de múltiplos utilizadores a tentar aceder ao mesmo registo simultaneamente. Em sistemas de alta transacionalidade, a densidade de deadlocks ou o tempo médio de espera por trincas (lock wait time) podem indicar que a estrutura de dados está a sofrer de uma normalização excessiva ou insuficiente, causando “engarrafamentos espirituais” no fluxo de informação. Ao analisar estas métricas em conjunto com a Taxa de Crescimento de Dados, o arquiteto de dados deixa de operar por intuição e passa a governar o santuário de dados com base em ciência exata, antecipando a necessidade de purificações (reindexação) ou de expansões (sharding) antes que o sistema entre em colapso.

3.2 Goodhart e a otimização disfuncional

A Lei de Goodhart afirma que: quando uma métrica se torna um alvo, ela deixa de ser uma boa métrica. Em sistemas computacionais, isso é amplamente observável. No afã de otimizar sistemas, administradores e programadores focam-se muitas vezes em indicadores isolados, como tempo de resposta de uma consulta específica, o objetivo da equipa passa a ser apenas “manter o cache”, o sistema pode ser artificialmente inflado com consultas repetitivas e inúteis apenas para mascarar a métrica, ignorando que a verdadeira saúde do banco de dados reside na integridade e na utilidade dos dados para o negócio, e não apenas em números de performance num dashboard.

Esta distorção estende-se à utilização de índices e à normalização, quando a métrica de sucesso é a “velocidade de leitura” a qualquer custo, o sistema pode ser inundado com índices redundantes que, embora satisfaçam a métrica de consulta rápida, degradam silenciosamente a performance de escrita e a consistência transacional. O desenvolvedor ou engenheiro de dados, deve estar sempre alerta para este fenómeno e ao transformarmos a ferramenta (a métrica) no altar da nossa adoração, perdemos a visão ontológica do sistema. Um SGDB deve ser medido pelo equilíbrio entre a sua capacidade de representar a realidade e a sua eficiência operacional, e não por alvos numéricos que incentivam comportamentos técnicos “míopes” e prejudiciais à arquitetura de longo prazo.

Algoritmos otimizados exclusivamente para métricas específicas tendem a explorar falhas no modelo de medição, produzindo resultados tecnicamente corretos, porém semanticamente vazios.

4. Machine Learning e o Culto ao Modelo

4.1 Dados de treinamento e viés

Modelos de aprendizado de máquina são tão bons quanto os dados que os alimentam. Viés estatístico, amostras incompletas e dados historicamente enviesados produzem modelos que reproduzem e amplificam essas distorções. A redução de viés (bias) em modelos de Machine Learning é um dos maiores desafios da IA moderna, pois o viés pode estar presente em múltiplas etapas, desde a coleta de dados até o pós-processamento dos resultados. Tecnicamente, a mitigação é dividida em três frentes principais:

1. Pré-processamento (Dados): O foco é “curar” os dados antes que eles cheguem ao algoritmo. Reponderação atribui-se pesos diferentes às amostras para compensar o desequilíbrio entre grupos privilegiados e não privilegiados, sem alterar os dados originais. Supressão ou remoção de atributos sensíveis como gênero ou raça. No entanto, isso raramente basta, pois outras variáveis podem servir como atalhos ou proxies por exemplo CEP pode estar correlacionado à bairros de mais alta ou mais baixa renda. A Otimização de Pré-processamento pode transformar os dados em uma nova representação que remova a correlação com o atributo sensível, mas preserve a utilidade da informação para a tarefa de predição.

2. In-processing (Algoritmo e Treinamento): Nesta fase, alteramos o “objetivo” do modelo para que ele aprenda a ser justo durante o treinamento. Debiasing Adversário onde utiliza-se uma arquitetura baseada em Redes Adversárias (GANs). Enquanto um modelo tenta prever o resultado, um “adversário” tenta prever o atributo sensível a partir das predições do primeiro. O objetivo do modelo principal é maximizar a precisão e, simultaneamente, minimizar a capacidade do adversário de adivinhar o atributo sensível. Restrições onde são adicionadas penalidades (regularização) à função de perda (Loss Function) que pune o modelo se ele violar métricas de equidade, como a Paridade Demográfica ou Igualdade de Oportunidades.

3. Pós-processamento (Resultados): A intervenção ocorre após o modelo estar treinado, ajustando suas predições finais. Equalized Odds Post-processing onde se ajusta o limiar (threshold) de decisão de forma independente para cada grupo. Por exemplo, se o modelo é mais rigoroso com um grupo específico, o threshold para esse grupo é reduzido para equilibrar as taxas de falsos positivos e falsos negativos entre todos os grupos.

Reduzir o viés não é apenas uma questão ética, mas uma necessidade de integridade técnica. Tratar o viés exige que o desenvolvedor veja além do obvio e entenda a ontologia dos dados. Se o conjunto de treinamento é um espelho de preconceitos históricos, o modelo será apenas um “automator” de desigualdades.

4.2 Explicabilidade e opacidade

Modelos complexos, como redes neurais profundas, oferecem alto desempenho preditivo, mas baixa interpretabilidade. Isso cria um paradoxo técnico: confiamos em sistemas que não conseguimos explicar plenamente. Como as redes neurais profundas e os Large Language Models (LLMs), refletem uma tensão fundamental entre a eficácia estatística e a transparência algorítmica, enquanto modelos lineares tradicionais permitem rastrear cada decisão até uma variável específica, as arquiteturas de deep learning operam em espaços de altíssima dimensionalidade, onde milhões de parâmetros interagem de forma não linear.

Em sistemas de recomendação e algoritmos de predição de preferências, essa opacidade significa que, embora o sistema possa prever com precisão cirúrgica qual produto um usuário deseja, ele não consegue explicitar o “porquê” dessa escolha, essa “caixa-preta” representa um desafio à soberania do desenvolvedor, que passa a atuar mais como um observador de fenômenos emergentes do que como um arquiteto de lógica determinística.

A integração desses modelos com bases de dados massivas potencializa o paradoxo, pois a qualidade da predição torna-se indissociável da vastidão dos dados de treino, por isso LLMs modernos, não apenas consultam bases de dados, mas internalizam trilhões de conexões linguísticas e conceituais durante o treinamento, transformando-se em repositórios vivos de conhecimento probabilístico. Quando um algoritmo de predição sugere uma rota financeira ou uma preferência de consumo, ele está processando padrões que escapam à cognição humana e o risco reside em tratar esses resultados como verdades absolutas (dogmas), ignorando que a base de dados subjacente pode conter correlações espúrias ou vieses históricos que o modelo, pela sua própria complexidade e falta de interpretabilidade, acaba por amplificar de forma silenciosa.

Para mitigar essa “fé cega” tecnológica, a área de TI tem recorrido a técnicas de XAI (Explainable AI), que tentam lançar luz sobre o santuário que vem sendo erguido. Métodos como SHAP (Lundberg & Lee) (SHapley Additive exPlanations) é baseado na teoria dos jogos cooperativos que visa atribuir a cada característica de um modelo a sua contribuição exata para uma previsão específica. Ele utiliza os “Valores de Shapley” para garantir que a diferença entre a previsão real e a previsão média seja distribuída de forma justa entre todos os atributos de entrada. A grande vantagem técnica do SHAP é a sua consistência teórica e a capacidade de oferecer tanto uma interpretação local (explicando uma única decisão) quanto uma visão global (identificando quais variáveis são mais importantes para o modelo como um todo), garantindo que a soma das contribuições de cada variável resulte exatamente no valor da saída do modelo.

Já o LIME LIME (Local Interpretable Model-agnostic Explanations), por outro lado, foca estritamente na interpretabilidade local ao tentar explicar previsões individuais de qualquer modelo de “caixa-preta”. Ele funciona perturbando os dados de entrada em torno de uma instância específica e observando como essas mudanças afetam a saída do modelo. A partir dessas perturbações, o LIME treina um modelo substituto muito mais simples e inerentemente interpretável, como uma regressão linear ou uma árvore de decisão que aproxima o comportamento do modelo complexo apenas naquela vizinhança. Embora não possua a mesma fundamentação matemática global que o SHAP, o LIME é extremamente flexível e computacionalmente eficiente para gerar explicações rápidas sobre por que uma imagem foi classificada de certa forma ou por que um crédito foi negado a um indivíduo específico.

Ambos os algoritmos buscam aproximar o comportamento de modelos complexos através de explicações locais simplificadas, tentando traduzir o caos das redes neurais em uma ontologia compreensível. No entanto, o dilema persiste pois ao simplificar o modelo para torná-lo interpretável, corremos o risco de perder a nuance técnica que o tornou eficiente em primeiro lugar. O desafio para o profissional do futuro não é apenas construir modelos potentes, mas projetar sistemas que equilibrem a performance com a responsabilidade técnica, garantindo que o “código interno” da inteligência artificial permaneça, em última instância, auditável e subordinado ao julgamento da lógica humana.

5. Engenharia de Software Orientada a Dados

5.1 Observabilidade e telemetria

Logs, métricas e traces são essenciais para sistemas modernos. Contudo, observabilidade não é sinônimo de onisciência. Instrumentar tudo não garante compreensão. O excesso de dados pode gerar ruído cognitivo, dificultando a identificação de causas raiz.

No contexto da Engenharia de Dados e da Engenharia de Software, a telemetria é um processo fundamental de coleta e transmissão de sinais brutos emitidos pelos sistemas, como logs de execução de pipelines, métricas de latência de escrita e eventos de mudança de esquema (schema drift). Em arquiteturas modernas, a telemetria não se limita apenas a saber se um servidor está “vivo”, mas abrange a saúde dos dados em si, capturando estatísticas sobre o volume de registros processados e o tempo de resposta das consultas SQL e sem uma telemetria robusta, o engenheiro opera no escuro, tratando falhas de integração como eventos aleatórios em vez de padrões rastreáveis em um fluxo de valor.

A observabilidade, por sua vez, transcende a simples coleta de dados feita pela telemetria, ela é a capacidade de entender o estado interno de um ecossistema de dados complexo apenas a partir de suas saídas externas. Em sistemas orientados a dados, isso se traduz em ferramentas que permitem realizar o “data lineage” (linhagem de dados), identificando exatamente onde um erro de cálculo foi introduzido em uma cadeia de transformações ETL. Enquanto o monitoramento diz que um pipeline falhou, a observabilidade permite questionar por que ele falhou, correlacionando picos de utilização de CPU com a chegada de arquivos malformados, garantindo que a integridade da informação seja mantida mesmo em ambientes de escala massiva e alta volatilidade tronando-se a essência.

5.2 Arquiteturas orientadas a eventos

Em sistemas event-driven, os dados representam fatos ocorridos no passado. Eventos não são comandos nem intenções; são registros históricos. Confundir esses conceitos leva a arquiteturas frágeis e semanticamente inconsistentes.

As Arquiteturas Orientadas a Eventos (EDA – Event-Driven Architecture) representam uma mudança de paradigma na engenharia de dados, movendo o foco do processamento de estados estáticos para a captura de fluxos contínuos de mudanças. Em vez de depender de processos batch tradicionais que extraem dados em intervalos fixos, a EDA utiliza eventos ou notificações de alterações significativas no sistema como uma  unidade fundamental de informação.

Na engenharia de dados, isto traduz-se na implementação de pipelines de streaming utilizando ferramentas como Apache Kafka ou RabbitMQ, onde cada inserção, atualização ou clique do utilizador é tratado como um evento imutável que alimenta o ecossistema em tempo real, permitindo uma reatividade que as arquiteturas monolíticas não conseguem alcançar. O conceito de “Single Source of Truth” (Fonte Única de Verdade) através do Event Sourcing, e uma abordagem onde, a base de dados não armazena apenas o estado atual, mas sim o histórico completo de eventos que levaram a esse estado.

Para o engenheiro de dados, isto significa que a linhagem de dados (data lineage) é preservada nativamente, facilitando auditorias e a reconstrução de estados passados. Além disso, a arquitetura orientada a eventos permite o desacoplamento de sistemas através do padrão Publish-Subscribe, onde novos consumidores de dados como modelos de Machine Learning ou dashboards analíticos podem ser adicionados sem impactar os sistemas produtores, criando um fluxo de dados resiliente, escalável e perfeitamente alinhado com as necessidades de baixa latência da computação moderna.

6. Aspectos Éticos e Sociais

A chamada “era de culto aos dados” transformam os dados em uma espécie de “divindade moderna” e ao lidar com isso criamos uma blindagem técnica que dificulta a contestação ética. Os principais pontos de fricção onde essa visão técnica colide com a realidade social são na Ilusão da Neutralidade pois muitas vezes, acreditamos que algoritmos são imparciais porque “usam números”, no entanto, dados são artefatos históricos.

Se um sistema de justiça utiliza dados de prisões passadas para prever reincidência, ele pode estar apenas automatizando preconceitos estruturais pré-existentes, impactando um viés que deixa de ser uma opinião individual e passa a ser uma “verdade estatística”.

Ao delegar decisões críticas a sistemas automatizados, surge o fenômeno da diluição de responsabilidade e se um algoritmo de saúde nega um tratamento, quem é o responsável? O desenvolvedor, a empresa que vendeu o software, ou o gestor que o implementou? A consequência dessa “sacralização” faz com que o erro seja visto como uma falha técnica a ser corrigida, e não como uma injustiça ética a ser reparada.

A visão de “dados como verdade absoluta” afeta diferentes setores, por exemplo o setor de crédito pode estar usando padrões de consumo periféricos e causando a exclusão de grupos mais vúlneraveis. Na justiça, Algoritmos de “policiamento preditivo” pode criar a vigilância excessiva em bairros específicos. Na saúde uma priorização de atendimento baseada em custos e dados históricos pode aprofundar a desigualdade no acesso à vida. Em políticas públicas, uma gestão baseada em métricas quantificáveis pode causar o abandono de necessidades humanas que não geram números.

Para contrabalançar a sacralização, a governança de dados moderna sugere a “divida ética” onde a auditabilidade dita que sistemas não podem ser caixas pretas, o raciocínio deve ser rastreável. A decisão final em contextos sensíveis deve sempre envolver o julgamento humano e a transparência radical deve informar ao cidadão quais dados estão sendo coletados e como estão sendo usados para moldar a vida dele, além de como contestá-los.

Tratar dados como “verdades absolutas” é ignorar que eles são apenas representações limitadas da realidade, e não a realidade em si.

7. Caminhos para uma prática crítica baseada em dados

Adotar uma postura crítica não significa rejeitar dados, mas integrá-los a um processo reflexivo que inclua:

• Compreensão do Domínio é a fase fundamental onde o cientista de dados mergulha no contexto específico do problema para entender não apenas os números, mas as regras de negócio, os processos e as nuances que geram esses dados. Sem esse conhecimento, corre-se o risco de realizar análises estatisticamente corretas, mas irrelevantes ou perigosas, pois é a visão do domínio que permite identificar variáveis confusas, validar a lógica dos resultados e garantir que a solução técnica responda a uma necessidade real da sociedade ou da organização. Em essência, é o que transforma o “processamento de dados” em “geração de valor e inteligência”, servindo como a âncora ética e estratégica que evita que os algoritmos operem em um vácuo de significado.
• Validação Qualitativa que é o processo de submeter os resultados de um modelo ou análise ao crivo de especialistas e usuários finais, buscando compreender o “porquê” por trás dos padrões identificados, em vez de focar apenas no “quanto” as métricas sim acertivas. Diferente da validação quantitativa, que utiliza testes estatísticos e funções de perda, a qualitativa investiga a coerência lógica, a utilidade prática e os possíveis impactos éticos da saída do sistema no mundo real. Essa etapa funciona como uma salvaguarda essencial contra a sacralização dos dados, pois permite identificar correlações espúrias ou comportamentos enviesados que os números sozinhos poderiam mascarar, garantindo que a tecnologia sirva ao propósito humano com segurança e interpretabilidade.
• Revisão Contínua de Modelos é o processo de monitoramento e ajuste sistemático de um sistema após sua implementação, reconhecendo que modelos de dados não são estáticos e podem sofrer “degradação” à medida que a realidade social e os comportamentos humanos mudam. Essa prática é vital para combater o determinismo tecnológico, pois exige que os desenvolvedores reavaliem periodicamente se o algoritmo ainda é justo, preciso e relevante frente a novos contextos ou mudanças nos dados de entrada (fenômeno conhecido como data drift). Ao estabelecer ciclos de auditoria recorrentes, a revisão contínua transforma o sistema em um organismo vivo e sujeito à correção humana, impedindo que decisões automatizadas obsoletas ou injustas se perpetuem indefinidamente sob o pretexto de uma “verdade técnica” imutável.
• Transparência Técnica refere-se à abertura e acessibilidade dos mecanismos internos de um sistema, permitindo que o funcionamento de seus algoritmos, a procedência dos dados e os critérios de decisão sejam passíveis de auditoria e compreensão por terceiros. Em vez de tratar o modelo como uma “caixa preta” protegida por segredo industrial, a transparência técnica promove a documentação rigorosa, como com o uso de Model Cards e a utilização de técnicas de IA Explicável (XAI), que traduzem cálculos matemáticos complexos em justificativas inteligíveis para humanos. No contexto social, ela é o antídoto contra o arbítrio tecnológico, pois garante que qualquer pessoa afetada por uma decisão automatizada possa entender os fundamentos dessa escolha e, se necessário, contestá-la com base em evidências técnicas claras.
• A Responsabilidade Ética em ciência de dados é o compromisso de garantir que o desenvolvimento e a aplicação de sistemas automatizados priorizem a dignidade humana e o bem-estar social acima da simples eficiência técnica. Ela exige que cientistas e organizações assumam a autoria moral pelas consequências de seus algoritmos, abandonando a ideia de que a tecnologia é “neutra” ou que o resultado de um modelo é uma fatalidade matemática fora de controle. Praticar a responsabilidade ética significa antecipar danos potenciais, mitigar ativamente vieses que possam marginalizar grupos e assegurar que existam mecanismos de reparação e intervenção humana sempre que uma decisão automatizada falhar ou causar injustiça.

A maturidade profissional em TI não está em aceitar dados como dogma, mas em questioná-los de forma sistemática.

Conclusão

Em última instância, este artigo sustenta que dados, por mais precisos, volumosos ou sofisticadamente processados que sejam, não constituem a realidade em si, mas sim recortes parciais, condicionados por instrumentos, modelos conceituais e escolhas humanas. A chamada “religião dos dados” emerge quando essas mediações são esquecidas e quando métricas, esquemas, dashboards ou modelos estatísticos passam a ocupar o lugar de verdades ontológicas, imunes à crítica. No campo da computação e da engenharia de software, isso se manifesta na absolutização de normalizações, índices, KPIs, arquiteturas distribuídas ou modelos de machine learning, como se fossem leis naturais, e não construções técnicas sujeitas a trade-offs, vieses e limites epistemológicos.

Ao percorrer desde a modelagem relacional e o Teorema CAP até métricas de software, observabilidade e inteligência artificial, torna-se evidente que toda decisão técnica carrega implicações semânticas, sociais e éticas. A estrutura de um banco de dados codifica hipóteses sobre o mundo; uma métrica redefine comportamentos; um modelo de ML cristaliza padrões históricos; uma arquitetura distribuída relativiza a noção de verdade no tempo. Ignorar esses aspectos equivale a terceirizar o julgamento humano para sistemas formais que não possuem consciência, responsabilidade ou senso moral, apenas otimização matemática dentro de limites previamente definidos.

Assim, a maturidade profissional em TI não reside na rejeição dos dados, tampouco na sua veneração acrítica, mas na capacidade de integrá-los a uma prática reflexiva, tecnicamente rigorosa e eticamente responsável. Questionar dados, modelos e métricas não é um sinal de fraqueza científica, mas de profundidade intelectual e compromisso com a realidade que se pretende representar e transformar. Em um mundo cada vez mais orientado por sistemas automatizados, preservar essa postura crítica é o que impede que a técnica se converta em dogma — e que a eficiência silenciosamente substitua a verdade, a justiça e o sentido.

Leituras e referências para aprofundamento

• Projetando Sistemas Distribuídos: Padrões e paradigmas para sistemas escaláveis e confiáveis usando Kubernetes – Brendan Burns (https://amzn.to/4qltybi)
• Domain-Driven Design: Atacando as Complexidades no Coração do Software – Eric Evans, Martin Fowler (https://amzn.to/3LIgayR)
• Estatística Prática Para Cientistas de Dados: +50 Conceitos Essenciais Usando R e Python – Peter Bruce, Andrew Bruce, Peter Gedeck (https://amzn.to/4sMhmSB)
• Sistema de Banco de Dados – Abraham SILBERSCHATZ, S. KORTH Henry F. SUDARSHAN (https://amzn.to/49G82qN)
• Introdução a Sistemas de Bancos de Dados – C. J. Date (https://amzn.to/4jOBGyG)
• Sistemas de Banco de Dados – Ramez Elmasri, Shamkant B. Navathe (https://amzn.to/4r4S9RT)
• Técnicas de Machine Learning – André Samartini, Nelson Lerner Barth (https://amzn.to/3Niyak2)
• Inteligência Artificial e Aprendizagem de Máquina: Aspectos Teóricos e Aplicações – Oscar Gabriel Filho (https://amzn.to/3LkwRR1)
• Reconhecimento de Padrões: um Estudo Dirigido – Rogério Galante Negri (https://amzn.to/4qpwSC9)