# 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 ????
__________________________