O que é transitividade na prática
Transitividade é a propriedade de uma relação onde, se A se conecta a B e B se conecta a C, então A necessariamente se conecta a C. Soa óbvio até você tentar implementar isso em produção e descobrir que a maioria dos casos reais não se encaixa nesse padrão limpo. Em bancos de dados relacionais, a transitividade aparece principalmente como dependência transitiva durante a normalização. Se a chave primária determina um campo non-chave, e esse campo non-chave determina outro campo, você tem uma dependência transitiva que quebra a Terceira Forma Normal. O problema é que muitos desenvolvedores identificam isso só quando o banco já está cheio de dados inconsistentes.
O que e transitividade fora do contexto acadêmico
No dia a dia com modelagem de dados, eu lidei recentemente com um caso em que uma tabela de preços tinha uma dependência transitiva escondida: o código do produto determinava a categoria, e a categoria determinava a margem de lucro. Parecia inocente até percebemos que categorias diferentes podiam ter evoluído suas margens em épocas distintas, e a tabela única acabava servindo margens desatualizadas para produtos novos apenas porque herdam a média da categoria. A solução foi separar a tabela de categorias da tabela de produtos e tratar margem como uma entidade própria com histórico, não como dado estático anexado. Esse tipo de problema é comum em migrações de sistemas legados. Você assume que a transitividade existe porque os relatórios sempre funcionaram, mas na realidade os dados têm exceções que nunca foram documentadas.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Como identificar transitividade em um modelo existente
O método mais direto é mapear todas as dependências funcionais a partir das chaves conhecidas. Você pega cada coluna não-chave e verifica se ela depende exclusivamente da chave primária ou se há intermediários criando cadeias. Ferramentas como o DBML ou até scripts Python com SQLAlchemy podem gerar um grafo de dependências automaticamente, mas nada substitui a verificação manual nos casos ambíguos. A partição mais difícil é distinguir entre dependência direta e transitiva quando há colunas calculadas ou views no meio. Um campo como "total_com_desconto" pode parecer uma dependência direta, mas se ele é derivado de "preco_base" multiplicado por "fator_desconto", e "fator_desconto" por sua vez depende da "regiao_venda", então tecnicamente existe uma transitividade indireta que precisa ser decomposta.
Quando a transitividade não se aplica
O erro mais frequente é tratar toda relação hierárquica como transitiva. Grafos de permissões de acesso, por exemplo, muitas vezes têm regras excepcionais que quebram a transitividade propositalmente. Um usuário pode ter acesso a um recurso via grupo A e outro recurso via grupo B, mas o grupo B não herda automaticamente tudo do grupo A porque existem políticas de least privilege sendo aplicadas. Tentar aplicar normalização transitiva nesses casos gera inconsistências sérias. Outro ponto onde a transitividade falha sistematicamente é em dados temporais. Se você diz que "o preço de hoje foi determinado pelo preço de ontem" e "o preço de ontem foi determinado pelo preço anteontem", a transitividade parece válida, mas na prática cada snapshot temporal é uma entidade separada. O que vale em T1 não vale em T2, e misturar essas camadas é o que causa duplicação de dados e atualizações incompletas que todos nós já enfrentamos.
A transitividade é uma ferramenta útil de análise, não uma lei universal. O melhor resultado vem quando você a usa para detectar anomalias no modelo, não como regra de modelagem absoluta.
