super dicas para melhorar seu relacionamento... e tabela, junção e visão

Às vezes você se sente inseguro... sobre os relacionamentos de dados? Seus colegas fazem chacota e te dizem pra usar bases não-relacionais? Como? não tem diferença entre caçoar e sugerir NoSql?

Não entre em pânico! Aqui você pode acompanhar mais um capítulo da flamewar mais sem base (sacou? sacou?) da história!

Mas antes, um pouco de contexto:

Um pouco depois de sairmos das cavernas e tocarmos o Monolito Negro(tm) (1970 e pouco), uns caras aplicaram o formalismo da lógica matemática de primeira ordem à confusão que era o enorme volume de dados produzidos à época (milhares e milhares de bytes!). Assim nasceu, das entranhas da big bad blue, a algebra relacional, estudada por muitos, odiada por tantos, amada pelos bons.

A partir dessa teoria nasceu uma linguagem que mais tarde veio a se tornar o SQL que todos ouvimos falar. De 79 para 80 houve o "boom" das bases relacionais. E não era para menos: antes os dados eram salvos em arquivos auto-contidos, ocasionalmente relacionados com outros, e o processo para combinar os dados de ambos pra produzir informação útil era penosa e imperativa. Dados duplicados? boa sorte pra identificar e manter atualizado.Só quem gerenciou documentos físicos poderia compreender como era.

Mesmo com as limitações da época (quem nunca viu aquela informação toda em caixa alta e sem acentuação?) uma base relacional foi um grande salto. Sabendo perguntar todo mundo se informa, não é mesmo? Montar uma consulta SQL quase sempre garante satisfação para as crianças.

Outro aspecto valioso é a modelagem de dados. Observe, a grande sacada da algebra relacional é ser capaz de receber como entrada uma orgia de dados do mundo real e dar como saída um modelo relacional normalizado. Isso é valioso porque na hora de combinar os dados pra montar informação (ex. contratos válidos combinando com os contratantes pode nos dizer quais contratantes estão ativos) um modelo normalizado resolve a parte lógica do problema muito facilmente.

Definir dados com sql ou com algebra relacional é uma técnica bem tranquila de aprender e mais ainda de usar. E ela se paga na hora de produzir informação.

Os passos são simples e sempre os mesmos, só a entrada e o resultado que muda:

1. Defina o seu negócio. O que você pretende modelar. É um mercadinho, uma academia, uma agenda de endereços?
2. Identifique os atores (entidades). Quem e o quê está envolvido no negócio? Vendedor, Contrato, Equipamento, Reserva, produto, Cupom?
3. Para cada ator, identifique seus atributos. nome do cliente? data e hora da reserva?
4. Normalize seu modelo de dados. Descubra as suas chaves, crie um relacionamento coeso, capaz de unir as entidades em algo melhor e mais objetivo.
5. Implemente. Só então pense em qual banco usar, como isso irá se comunicar com o programa aplicativo, enfim.

A maioria dos membros da turma do funil se atrapalha ali no terceiro passo.

Como? eles se atrapalham no passo 4? Não, amigo, o pessoal erra é no terceiro mesmo. Explico.

Na algebra relacional, não temos tabelas mas sim relações, e as relações são membros de conjuntos.

Membros de conjunto, na algebra relacional, não se repetem. Posto isso, toda vez que uma tabela tem um nome de coluna igual ao nome de coluna em uma outra tabela, temos aí uma falha que vai morder-lhe o pé lá adiante.

Se você tiver, por exemplo, uma entidade chamada Morador e uma entidade chamada Comunidade, o nome de cada um pode ser qualquer coisa, nomemorador para Morador e nomecomunidade para Comunidade, mas não chame os dois atributos de nome.

Como? sim, sim... Tem muita modelagem assim por aí. Mas as razões para seguir a algebra relacional (que eu sei que você leu a respeito lá nos artigos nos links!) são puramente matemáticas. Há quem diga que é complicado, que é muito rebuscado, que o pessoal salvando arquivo em disco era melhor servido... Esses são os manos do NoSQL.

Ao passo que um esquema de dados bem normalizado permite você fazer natural join, joias como o mongodb delegam aos poderes criativos do programador e da linguagem predileta dele um meio de transformar dado em informação.

Fazendo um pouco de advogado do diabo, este movimento existe porque tinha um problema do mundo real que a modelagem relacional não resolvia rápido: as mudanças de negócio.

É uma abordagem super agradável: você não precisa pensar em banco de dados, só no código do seu aplicativo! Look man! no math!

Como? Se essa promessa de raciocinar pouco e ganhar muito já fez vítimas? Algumas.

Ter um esquema, há muito tempo atrás, era desvantagem se por motivos estratégicos precisávamos mudar ele constantemente. Era demorado. Soluções sem esquema não sofrem tanto com esse problema ainda mais quando os aplicativos atuais podem ser alterados assustadoramente rápido.

Hoje, todavia, sempre comece seu projeto de banco pensando nas evoluções de esquema. Pensar nisso, felizmente, não requer rigor matemático. Basta adotar um esquema de migração de dados, olha que felicidade!

Outra comodidade valiosa é persistir as junções mais comuns do seu banco em visões. Todo banco bacana suporta o uso de visões.   

A evolução do esquema relacional foi um problema sério quando o desenvolvimento de software acelerou de vez, tendo produzido heresias como os ORM's que hoje encantam e assombram tantos. Mas esta é outra flamewar e vou ficar bem longe dessa.

Em realidade, se alguma outra melhoria na especificação do SQL vier a ser apresentada, eu diria que prever as migrações de dados direto na linguagem de definição de dados.

Pra fechar o papo, lembre-se dos passos ao definir um esquema, use sempre que possível natural join, use algum esquema de migração de dados e mantenha-se longe das bases não-relacionais.