Modelar dados e relações de negócio

1. Começar pela pergunta de negócio

Uma equipa fictícia precisa de saber que interveniente pode executar cada ação em cada carteira. Um organograma mostra quem pertence à equipa, mas não responde necessariamente à pergunta. Um mapa de requisitos identifica dependências, mas também representa outro objeto. Define primeiro os conceitos, a identidade e a distinção que a decisão precisa de preservar. Nesta aula, carteira é apenas o nome de um objeto de negócio do exercício, sem regras financeiras implícitas.

O modelo usa intervenientes A, B e C, carteiras F1 e F2 e ações read e submit. Uma atribuição relaciona os três elementos. Os identificadores distinguem objetos neste contexto; nomes parecidos não autorizam uma fusão. O modelo conceptual não escolhe tabelas, índices ou uma tecnologia de armazenamento. Deve permitir discutir factos e regras antes dessas decisões. Pergunta, por exemplo: pode um interveniente estar registado sem atribuições? Pode ter ações diferentes em carteiras diferentes? Qual informação pertence à atribuição específica? As respostas orientam o modelo e os exemplos de aceitação.

2. Ler mínimos e máximos nos dois sentidos

Uma relação tem perguntas distintas em cada sentido: quantas carteiras pode ter um interveniente e quantos intervenientes pode ter uma carteira? Não deduzas uma resposta da outra. No contrato do exercício, um interveniente pode não ter atribuições. Uma carteira em rascunho também pode existir sem submitter. Uma carteira ativa exige pelo menos um interveniente distinto com submit, e qualquer carteira admite no máximo dois submitters na configuração base. São regras deste exemplo, não políticas universais.

Conta pessoas distintas no papel indicado. B/read, B/submit, C/read e C/submit em F1 representam quatro atribuições, dois intervenientes e dois submitters. O máximo de dois submitters é respeitado. Contar quatro linhas alteraria a unidade da regra. A presença de B/read também não satisfaz, por si, a exigência de submit. Regista a condição de ativação junto da regra: desenhar um mínimo de um em todas as carteiras impediria o estado de rascunho autorizado. Um diagrama pode precisar de uma regra adicional para exprimir esta condição.

3. Colocar cada atributo no facto que descreve

No exercício, maxItems é um inteiro positivo de 1 a 100 e pertence à atribuição completa. A/read/F1 tem limite 20; A/submit/F2 tem limite 10. Guardar apenas limite 20 em A perde a distinção. Também não basta guardar o limite na carteira se diferentes intervenientes ou ações podem ter valores diferentes. A identidade da atribuição é o conjunto interveniente, carteira e ação. Assim, B/read/F1 e B/submit/F1 podem coexistir com limites próprios.

Uma regra diferente pode colocar um atributo noutro nível. Num exemplo conceptual separado, o negócio define uma única moeda de serviço por carteira, independentemente das atribuições. Duas linhas da mesma carteira com moedas diferentes contradizem essa regra no mesmo instante. A solução não é declarar automaticamente duas carteiras nem escolher a última linha. Clarifica o facto e representa a sua unicidade no nível adequado. A decisão depende do significado confirmado, não de uma preferência genérica por menos ou mais tabelas. O programa desta aula não modela moedas nem armazenamento físico.

4. Preservar o facto conjunto

O ficheiro base contém exatamente quatro atribuições: (A,F1,read), (A,F2,submit), (B,F1,submit) e (C,F2,read). O conjunto é completo por construção. Uma proposta guarda apenas pares interveniente/carteira e carteira/ação. Em F1 aparecem A e B, e aparecem read e submit; recombinar esses pares produz quatro triplos. O mesmo sucede com A e C em F2. A proposta reconstrói oito triplos, embora só quatro tenham sido estabelecidos.

(A,F1,submit) é um contraexemplo: A pertence a F1 através de read, e submit existe em F1 através de B. Esses dois factos não estabelecem submit para A em F1. Nenhum dos pares precisa de estar errado para a conclusão estar errada. Explica a perda através deste exemplo antes de discutir uma implementação. O programa chama spurious aos triplos reconstruídos que não constam da relação direta. A palavra identifica informação acrescentada pela recombinação; não é uma observação de acesso real nem uma acusação sobre um utilizador.

5. Mais pares podem continuar a perder significado

A proposta acrescenta agora pares interveniente/ação. B só tem submit e C só tem read, pelo que as combinações adicionais B/read/F1 e C/submit/F2 desaparecem. Contudo, A tem read em F1 e submit em F2. O terceiro conjunto de pares continua a admitir (A,F1,submit) e (A,F2,read). Restam seis triplos, com dois acrescentados à relação direta. Acrescentar mais uma vista não demonstra, por si, que a distinção original foi recuperada.

Há uma forma mais forte de mostrar a perda: compara a relação original de quatro triplos com outra que também inclui esses dois triplos adicionais. As duas produzem exatamente os mesmos três conjuntos de pares, mas respondem de forma diferente à pergunta sobre submit de A em F1. Um leitor que recebe apenas esses pares não consegue identificar qual das duas relações foi fornecida. Esta conclusão decorre do exemplo finito; não afirma que qualquer decomposição seja sempre inadequada. Se outras restrições assegurarem uma reconstrução fiel, é necessário explicitá-las e verificar o seu efeito.

6. Verificar estruturas e regras separadamente

O programa distingue uma entrada mal formada de dados compreensíveis que violam uma regra de negócio. Uma referência a um interveniente inexistente, uma identidade de atribuição repetida ou maxItems=true são rejeitados. true não representa o inteiro 1 neste contrato. Já uma carteira ativa sem submitter é uma situação bem formada que o relatório identifica como incumprimento da regra. Não a preenche automaticamente nem transforma ausência de atribuição em aprovação.

Regras de classificação também precisam de contexto. Num exemplo conceptual separado, a mesma organização pode ser cliente e fornecedora. Um desenho que impõe classes mutuamente exclusivas impediria um caso permitido. Não concluas exclusividade apenas porque os nomes são diferentes. Igualmente, se a amostra atual mostra uma carteira por interveniente mas a necessidade confirmada admite duas, a amostra não estabelece um máximo de uma. Usa exemplos permitidos e proibidos para desafiar o modelo. Estes exemplos de classificação não são funções implementadas no exercício Python; complementam o raciocínio de modelação.

7. Distinguir situação atual e perguntas históricas

Uma relação atual pode responder quem tem hoje uma atribuição, sem responder quem a tinha ontem. Imagina dois históricos: no primeiro, A tinha submit em F1 ontem e foi substituído por B; no segundo, B já tinha essa atribuição ontem. Ambos acabam na mesma relação atual. Um campo com a data da última alteração não contém necessariamente a relação anterior. Se a decisão exige responder à pergunta histórica, identifica quais factos e períodos devem continuar representados. Não inventes o histórico a partir da situação atual.

A mesma cautela aplica-se à completude. No ficheiro didático, a lista direta é declarada completa, pelo que uma combinação ausente não está atribuída nesse modelo. Num extrato real incompleto, ausência pode significar apenas que a informação não foi recolhida. Esclarece população, instante e fonte antes de transportar a interpretação. O programa compara a relação fornecida e não implementa histórico temporal, recolha de dados ou controlo de acesso. Uma conclusão útil explicita a pergunta respondida e a informação que falta para responder a outra.

8. Exercício: construir um contraexemplo útil

Descarrega o exercício, extrai todos os ficheiros para uma pasta e lê case-data.json antes de executar python3 explore.py. Desenha os quatro triplos e prevê as combinações reconstruídas por dois e três conjuntos de pares. Explica o caso (A,F1,submit), incluindo por que razão a recombinação não fornece um maxItems confirmado para ele. Depois compara a tua previsão com o JSON. python3 check_model.py executa as verificações locais do pacote.

Numa cópia, retira (A,F2,submit). Enquanto F2 permanece em rascunho, não há mínimo de submitter nessa carteira. Torná-la ativa introduz uma violação, sem mudar as atribuições. Noutra cópia da base, acrescenta C/submit/F1: F1 passa a ter dois submitters, dentro do máximo. Acrescentar também A/submit/F1 leva o total distinto a três e viola o máximo de dois. Regista regra, exemplo, conclusão e decisão necessária. Os ficheiros incluem doze tarefas e resoluções nos dois idiomas. A enumeração compara modelos num domínio pequeno; não confirma que estas regras satisfazem um serviço real nem concede autorização operacional.

Separar eficácia e conhecimento histórico

Antes de escolher campos ou uma base de dados, escreve as perguntas que o modelo deve responder. Numa política fictícia, o dia em que uma taxa se aplica e o dia em que essa taxa ficou registada podem divergir. O registo de 1 de março indica taxa 10 desde esse dia.

Uma correção registada em 12 de março autoriza taxa 12 desde 5 de março. Para uma operação de 8 de março, o conhecimento atual aponta para 12; um relatório produzido com informação até 10 de março só podia conhecer 10. Nenhuma resposta apaga a outra: têm limites de conhecimento diferentes.

Desenha dois eixos e coloca cada versão em ambos. Conserva o início de eficácia, o momento de registo e a relação de substituição; considera também os fins de intervalo quando o conjunto de regras os exigir. Verifica exemplos anteriores à correção, dentro do período retroativo e após o seu registo.

Um modelo que conserva apenas a última taxa perde a reconstrução histórica; usar a data de registo como eficácia perde a retroatividade autorizada. O exemplo não estabelece regras fiscais ou legais. Ensina a especificar significado temporal e a escolher uma representação que preserve as perguntas acordadas.

Armadilhas comuns

Trocar os dois sentidos da cardinalidade; contar linhas como pessoas; colocar um atributo da atribuição no interveniente; recombinar pares como se estabelecessem o facto conjunto; inferir histórico ou completude sem evidência.