khana/personnal_docs/RulesEngine.md

118 lines
3.5 KiB
Markdown

# Gestion des contraintes
Dans un circuit de compétition les séries imposées sont soumises à des contraintes. Certaines sont simples, d'autre pas.
## Contraintes Simples
Dans les contraintes **simples** nous avons :
- l'age minimum pour etre dans le niveau/catégorie
- l'age maximum pour être dans le niveau/catégorie
- le nombre de point nécessaire à la qualificaiton pour la phase suivante
- x sauts avec y degré de rotation minimum
Ces contraintes sont simples car facile a exprimer mais surtout elles sont présentes sous la même forme pour chaque série imposée. Elle peuvent donc être stocker au niveau de la table NIVEAU.
## Contraintes semi-complexes
Dans les contraintes **semi-complexes**, nous retrouvons :
- (3/4 arrière OU 3/4 avant ) ET barani tendu ET salto arrière tendu ET (cody OU bo OU bbo)
ou
- enchainement de Arrière Tendu, Barani carpé, arrière carpé
Ces contraintes semi-complèxes peuvent être séparées en contraintes atomiques. Exemple avec la première :
- 3/4 arrière
- OU 3/4 avant
- ET barani tendu
- ET arrière tendu
- ET cody
- OU bo
- OU bbo
La contrainte totale est la liaison (par `ET` et `OU`) des contraintes atomiques, c'est de la récursivité.
Exemple avec la seconde :
- série composée de :
- 1 - Arrière Tendu
- 2 - Barani Carpé
- 3 - Arrière carpé
Dans ce cas ci, c'est une série (enchainement de saut ordonnés).
Si l'on utilise deux table ces règles peuvent être modélisée.
### tables RULES
Cette tabe servirait de "mère" et générerait un ID. Elle aurait également comme champs : l'id d'une mère et d'un pere ainsi qu'un opérateur, permettant ainsi de lier par un `ET`ou un `OU` deux record déjà existant
ruleid ID (PK)
motherid ID (FK)
fatherid ID (FK)
operator Enum('AND', 'OR')
### tables CONSTRAINTS
Cette table, fille, récupérerait l'ID de la mère et posséderait les champs suivant :
ruleid ID (PK, FK)
label Varchar(255)
educativeid ID (FK)
##### Exemple
- 3/4 arrière
- OU 3/4 avant
- ET barani tendu
- ET arrière tendu
- ET cody
- OU bo
- OU bbo
Est modélisé par :
table RULES :
| ruleid | motherid | fatherid | operator |
|---------|-------------|------------|-------------|
| 1 | null | null | null |
| 2 | null | null | null |
| 3 | null | null | null |
| 4 | null | null | null |
| 5 | null | null | null |
| 6 | null | null | null |
| 7 | null | null | null |
| 8 | 1 | 2 | OR |
| 9 | 8 | 3 | AND |
| 10 | 9 | 4 | AND |
| 11 | 5 | 6 | OR |
| 12 | 11 | 7 | OR |
| 13 | 10 | 12 | AND |
table CONSTRAINTS :
| ruleid | label | educid |
|-----------------|-----------------|------------------|
| 1 | 3/4 arrière | x |
| 2 | 3/4 avant | y |
| 3 | barani tendu | z |
| 4 | arriere tendu | a |
| 5 | cody | b |
| 6 | bo | c |
| 7 | bbo | d |
## Contraintes complexes
- une récéption sur le dos/ventre ET une départ du dos/ventre (en combinaison) ET un double salto avant ou arrière avec ou sans vrille ET un saut avec minimum X degré de vrille et Y degré de salto.
On ne retrouve plus de lien vers des educatifs précis mais plutôt vers une description partielle :
- arrivée/départ ventre/dos
- double salto avant ou arrière avec ou sans vrille
- saut avec minimum X degré de vrille et Y degré de salto
Ici on attaque plus un educatif (saut) précis mais une caractèristique d'un saut (éducatif). Une arrivée ou un départ, c'est un record d'une autre table, mais une quantité de rotation, c'est un attribut d'une educatif (saut).
_______________________________________
### Comment réussir à modéliser cela correctement ????
__________________________