Modelo de processo de desenvolvimento RAD (Rapid Application Development), fase 2: Modelagem dos Dados. É isto que nos ensinam na escola, desde o primeiro momento. E é isto que tantas vezes esquecemos no nosso dia-a-dia de programadores. Not this time.

Quando comecei a desenvolver aplicações para jogos de loto, estas eram extremamente restritivas, apenas para o Euromilhões ou apenas para o Totoloto… Qualquer outro concurso obrigaria a uma reestruturação do código e a uma nova release do software, exclusiva para esse concurso. Como é bom de ver, isso é um bocadinho estúpido – a menos que se tenha em mente uma estratégia de venda ou de branding: continua a ser estúpido dum ponto de vista de desenvolvimento, mas é uma excelente ideia a nível de marketing, sempre são mais produtos para vender. Como não é o meu caso, esqueçam: é só estúpido.

O código, passo a passo, foi sendo melhorado para ser escalável, como deveria ter sido desde o início. O mesmo foi acontecendo à estrutura de dados, abstraindo cada vez mais a mesma duma visão centrada num dado concurso, primeiro, e nos concursos portugueses, depois. Se do Euromilhões para o Totoloto, por exemplo, já há diferenças de estruturação (o Euromilhões é, na realidade, constituído por dois jogos, por exemplo), para totolotarias de outros países havia diferenças abismais. Por exemplo, há uma totolotaria nos Estados Unidos cuja última bola sorteada tem um significado especial e deve ser tratada como um jogo à parte, à semelhança das estrelas no nosso conhecido Euromilhões. Mas há um catch: essa bola é do mesmo pote de onde saíram as outras (cinco ou seis… ou sete, não sei bem). E isto, ainda a procissão vai no adro…

O truque é aplicar uma regra velhinha da estruturação de dados: normalizar até doer, desnormalizar até funcionar. Explicar o que é a normalização é complexo sem alguma experiência prévia na matéria, pelo que prefiro reencaminhar para o artigo sobre normalização na Wikipedia. Seja como for, retenham isto: sempre que achem que uma entidade pode ter mais do que um valor numa propriedade, essa propriedade deve ir para outra entidade, nem que tenha de se criar uma entidade de propósito.

Um exemplo rápido: quantos números são sorteados no Euromilhões? Cinco – e as estrelas? Ah, então sete – separados como? Ok, a propriedade números leva o valor cinco e a propriedade estrelas leva o valor dois – possível (aliás, é assim que funciona o motor do SisRedEM v2), mas continua errado: quando aparecesse um concurso com três jogos, alterava-se a estrutura, métodos de criação, alteração e tratamento?

Adiante. A estrutura que fiz, até ver, permite todas as situações que eu conheço. O diagrama entidade-associação (avançado) que coloco abaixo corresponde à implementação de base de dados que irei usar em todos os projectos relacionados com jogos de loto.

[ a imagem foi retirada, ver este post ]

Algumas notas sobre a estrutura:

• A estrutura deve ser interpretada começando na entidade concursos, é o ponto de entrada para todas as outras entidades;
• Os concursos, como podem ver, tem apenas duas propriedades directas, a periodicidade e a última data de referência. Isto servirá, entre outras coisas, para controlar quando os dados relativos aos sorteios estão em atraso;
• Todas as entidades *_local contêm os dados localizados. Por exemplo, um concurso que abranja vários países tem vários conjuntos desses dados localizados;
• Os jogos, como devem ter percebido pelo exemplo anterior, são as várias partes de um concurso, podendo ser apenas uma (como no caso do Totoloto). Como podem reparar, o outro exemplo que dei do tal concurso norte-americano é controlado pela propriedade depende do precedente;
• A entidade boletins e as entidades com ele relacionadas guardam dados relacionados com o posicionamento, para efeitos de impressão. Notem que a relação entre a entidade concursos local e boletins é de um-para-muitos, o que abre a opção de vários boletins para um mesmo concurso. A primeira coisa que nos vem à cabeça é o caso dos vários países do Euromilhões, mas é preciso pensar também em períodos de transição entre boletins antigos e boletins novos (embora por cá, essa transição tenha sido do tipo tough love, hoje registas com este boletim, para a semana tem de ser com os novos);
• Uma última nota para a entidade especiais – guarda os dados relativos a opções especiais dos boletins. Por exemplo, opção de cinco semanas no Totoloto, o Super 14 no Totobola ou o joker. You name it. Há sempre um especial, que não pode ser eliminado, que é onde constará a numeração do boletim, pela ordem de impressão. Isso já é uma característica do SisRedEM v2.

Qualquer alteração que achem que deve constar, estão à vontade.

Daqui a uns dias falarei sobre o motor de BD onde pretendo manter estes dados, assim como da implementação específica em C#.