khana/personnal_docs/UserRequirements.md

User Requirements & Table description

---

Partie GYMNAST

Table GYMNAST

Un gymnaste est défini par les informations suivantes : nom, prénom, date de naissance, adresse, sexe, niss, téléphone (fixe), gsm et email, gsm du « père » et le gsm de la « mère » ainsi qu'une photo (booléen indiquant s’il y a une photo => lie directement avec la photo). A cela il doit être possible d'ajouter des informations en relation directe avec le sport telles que : l'ID de la fédération, Actif (définit si le gymnaste pratique encore ou a arrêté) et une orientation (booléen désignant l’orientation du gymnaste : gauche ou droite)

#####Design :

ID			PK
Nom			Varchar
Prenom		 Varchar
Birthdate	Date
address		Varchar
gender		Bool
niss		Varchar
phone		Varchar
gsm			Varchar
email		Varchar
fedid		Varchar
Gsmm		Varchar
Gsmp		Varchar
Active		Bool
Picture		Bool
Orientation	Bool

Table ACCIDENT

Il est important de pouvoir référencer les accidents qui surviennent afin de pouvoir les analyser et prévenir les prochains. De plus, les accidents font partie du gymnaste et peuvent avoir une influence : peur, doutes, …

Les informations essentielles d’un accident sont la date à laquelle il s’est produit, le gymnaste concerné ainsi que l’objectif sur lequel l’accident s’est produit. Une brève description, optionnelle, peut également être écrit : l’accident y serait détaillé et les mesures à prendre pour éviter que cela se reproduise pourraient y être indiquées.

#####Design :

Id 				Id (PK)
GymID			Int FK
ObjectiveID		Int FK
Date			Date
Information		Text

Table USER

Surtout basée sur la table User de Django.

Partie LOCATION

Table PLACE

L’application doit pouvoir stocker des lieux (compétitions, rassemblements, festivités, …). Il faut donc pouvoir stocker une adresse (rue, CP, ville et pays). En plus de cela le lieu peut avoir un nom (« Sportpalais », « Ancienne Belgique », …) et un champ ‘actif’ afin de pouvoir faciliter les filtres. A cela s’ajoute deux champs « nbkm » et « nbtemps » (calculé automatiquement ou manuellement) afin de pouvoir indiquer le nombre de kilomètres et le temps de parcours séparant le lieu de la salle d’entrainement afin de pouvoir se faire une idée du temps de trajet.

#####Design :

Id		Id (PK)
Name	Varchar(255)
Address	Varchar(3)
Postal	PlaceID (FK)
City	Varchar(255)
Country	Varchar(255)
Nbkm	Integer(3)
Active	Booléen(1)

Table CLUB

Un club porte un nom ainsi qu’un acronyme. Un club doit pouvoir être associé à un ou plusieurs lieux (de la table PLACE) et possède un champ ‘actif’ afin de pouvoir faciliter les filtres.

#####Design :

Id		Id (PK)
Name	Varchar(255)
Acronym	Varchar(3)
Place	ForeignKey(Place)
Active	Booléen(1)

Table COUNTRY

La table country contient les informations ISO de tous les pays de la norme.

#####Design :

Id			Id (PK)
Nameus		Varchar(255)
Namefr		Varchar(255)
nationality	Varchar(255)
Iso2		Varchar(2)
Iso3		Varchar(3)
Isonum		Varchar(3)

---

Partie SCHEDULE

Cette partie de l'application a pour but de gérer toute la notion de plannifications dans la vie du gymnaste (compétition, entrainement, liste de présence, plannification d'objectif, ...).

Table COURSE

La table COURSE permet de représenter les cours donnés dans un club, un cours est donc lié à un club. Un cours devrait en fait être lié à une salle (un lieu) d'un club, car ce dernier peut avoir des cours dans plusieurs salles. Ces cours sont, par ailleurs, définis par : un jour, une heure de début et de fin ainsi qu’une date de début et de fin (du 1er sept au 30 juin, par exemple).

#####Design :

Id			Id (PK)
daynumber	Numéro du jour de la semaine (0 = lundi, 6 = dimanche)
Dbegin		Date
Hbegin		Time
Dend		Date
Hend		Time
clubid		Int FK (Club)

Le but est de pouvoir lier des gymnastes à des cours pour pouvoir faire des listes de précences, des statistiques (nombre d'heure de présence, d'absence, total, …), … etc. Les cours sont donnés sous forme d'ensemble sécable ou insécable suivant le groupe du gymnaste.

Table GROUP

Certains cours sont insécables. Par exemple : les gymnastes faisant partie d’un groupe A (e.g. : D2) ont automatiquement les cours W, X, Y et Z. Ils ne peuvent pas (sauf exception) ne venir à X et Y mais pas à W et Z, … Cela introduit la notion de groupe. Un groupe est un ensemble d’entrainements sur une semaine. Les gymnastes se trouvent dans des groupes et chacun de ces groupes est lié à un ensemble d'entrainement. La problème est que cet ensemble peut être sécable (groupe de "D3" à cours 2 ou 3 fois par semaine : le lundi, vendredi et samedi) ou insécable (le groupe "D2 à cours 4 fois par semaine : le lundi, le mercredi, le vendredi et le samedi).

Comment représenter cela ? Dans le cadre d'un ensemble sécable, le nombre d'entrainement maximum possible est différent du nombre d'entrainement minimum possible, ce qui n'est pas le cas dans un ensemble insécable. On pourrait donc stocker ces deux informations et se baser dessus. Le problème c'est que cela ne nous donne pas encore la possibilité de lié (fortement) un gymnaste à un cours (précis).

La solution est de créer une table "Sous-groupe" listant, pour chaque groupe, toutes les combinaisons possibles :

a) insécable (cf. D2)

• 1 seul sous-groupe possible : srgp0 : 4x/sem (L, M, V, S)

b) sécable (cf. D3) plusieurs sous-groupe possibles :

• sgrp1 : 3x/sem (L, V et S)
• sgrp2 : 2x/sem (L et V)
• sgrp3 : 2x/sem (L et S)
• sgrp4 : 2x/sem (V et S)

Un gymnaste appartenant à un groupe devrait suivre l’ensemble de ces entrainements. Cela nous donnerait une table GROUP telle que :

Id		Id (PK)
club	ID (FK)
label	Varchar(255)
acronym	Varchar(10)
active	Booléen

Table SUBGROUP

Chaque sous-groupe appartien à un (et un seul groupe).

#####Design :

id		id (PK)
group	id group (FK)
label	Varchar(255)
acronym	Varchar(255)
active	Booléen

Une table de liaison (n,n ???) entre COURSE et SUBGROUP et une table de liaison (n,n ???) entre SUBGROUP et GYMNAST permettraient de lier les gymnastes avec les cours au travers de groupes et des sous-groupes.

Table UNAVAILABILITY

Cette table va permettre de stocker des dates pour lesquelles il n'y aura pas cours. De manière plus précise, cette table sert à indiquer qu'une salle ne sera pas acessible ou, même si elle l'est, que le cours s'y donne habituellement ne s'y donne pas. Lie-t-on au cours ou lie-t-on à la salle ? Lier à la salle peut impliquer de donner des informations fausses (salle qui serait inaccessible alors que non) mais permettrait de gerer des changements de salle (salle inaccessible mais cours donné dans une autre salle). Lier au cours permet de ne pas donner de fausses informations (salle pas réellement inaccessible) mais ne permet pas de gerer le remplacement du cours par un autre cours (one shot, …). Une idée ?

Design :

ID			ID (PK)
datebegin	date
dateend		date
information	text

Table TRAINING

Cette table permet de lier un gymnaste à un cours, indiquant ainsi que qu’un gymnaste est venu à un cours. En plus de ces deux ID (Gym et cours), une date est stockée afin de pouvoir établir des feuilles de présence ainsi que calculer au mieux le nombre d’heure de cours qu’a eu un gymnaste pendant une période donnée.

Design :

Id			Id (PK)
GymID		Int FK (Gym)
CourseID	Int FK (Course)
date		Date

La liste de présence a priori est proposée sur base de la liaison entre les gymnaste et les cours passant par les groupes et sous-groupe. La liste de présence a posteriori est basée sur les informations de cette table-ci

Table EVENT

Cette table permet de définir un événement : un nom, une date et une heure de début, une date et une heure de fin, le type (liaison par FK) ainsi que des informations (champs texte) relatives à cet événement.

Un événement est bien souvent organisé par un club, mais pas toujours. Il est possible que ce soit une fédération qui organise un événement, une firme, etc. On ne peut toujours pas obliger de liaison entre un événement et un club. Cependant un événement se déroule toujours dans un lieu précis, on doit dont pouvoir lier un événement à un lieu (PLACE).

Design :

Id			Id (PK)
PlaceID		Int FK (PLACE)
TypeID		Int FK (EVENTTYPE)
Dbegin		DateTime
Dend		DateTime
Information	Text

Table EVENTTYPE

Plusieurs type d’événement existe (démonstration, compétition qualificative, compétition finale, stage, … → dictionnaire fini). Ces types sont caractérisés par un label et un acronyme (en plus d’un ID).

Design :

Id		Id (PK)
Label	VarChar(255)
Acronym	VarChar(255)

Table TO_DO

(Description/requirements à venir)

Table PLANING

(Description/requirements à venir)

Table CAN_DO

La table CAN_DO a pour but de signifier qu’un gymnaste SAIT FAIRE (parce qu’on l’a déjà vu, constaté) un objectif. Le but (long terme) est d’introduire une intelligence dans le programme afin que ce dernier puisse nous proposer des listes de travail :

• des choses à travailler pour tendre vers des objectifs que l’élève ne sait pas encore réalise ; r
• des choses à travailler pour améliorer la réalisation d’objectifs qu’il sait déjà réalise mais incorrectement ;r
• …

---

Partie OBJECTIVE

Table TOUCH_POSITION

Cette table sert de dictionnaire et contient les informations nécessaires pour définir les positions d’arrivée/départ d’un saut.

Design :

LandingId		ID (PK)
Label			Varchar. Le nom (ventre, Genoux, 4 pattes, debout, …)
InCompetition	Booléen
Default			Booléen

Le champ « InCompetition» définit si l’arrivée est autorisée en compétition ou non. Cela aura pour conséquence que toute série comportant un mouvement (SKILL) dont l’arrivée et/ou le départ n’est pas autorisée, ne sera pas autorisée en compétition.

Le champ « Default » définit la position par défaut. A la création d’un nouveau mouvement, si la position de départ n’est pas fournie, il faudra par déduction aller trouver soit la position d’arrivée du précédent mouvement (dans le cas d’un enchaînement), soit la position par défaut dans la table de la base de données…

Il ne peut y avoir qu’une et une seule position par défaut dans toute la table ARRIVAL/POSITION. En plus, avec ce champ, on saurait quelle position ne doit pas être affichée dans le nom des mouvements.

Table SKILL

En trampoline ce sont les mouvements qui ont un nom. Ces mouvements peuvent impliquer un départ particulier et/ou une arrivée particulière (assis, dos, ventre, …). Le « ventre » est le nom d’un mouvement allant jusqu’au ventre. Le mouvement dépendra donc du contexte (i.e. du mouvement précédent) :

• ventre : debout – tomber ventral, ¼ de rotation
• dos – ventre : du dos aller jusqu’au ventre, 2/4 de rotation
• ¾ arrière : de debout aller jusqu’au ventre, en arrière, ¾ de rotation transversale
• Cody, ventre : du ventre, faire un salto arrière jusqu’au ventre, 4/4 de rotation
• Salto avant, ventre : de debout, salto avant jusqu’à un tomber ventral, 5/4 de rotation
• …

Le mouvement le plus simple (comportant le moins de ¼ de rotation) comportant une arrivée particulière prend, par convention, le nom de cette arrivée :

• debout, tomber ventral -> ventre
• debout, tomber dorsal -> dos
• debout, tomber quadrupédique -> 4 pattes
• debout, tomber assis -> assis
• debout, tomber curviligne ouvert -> ventre ouvert
• debout, tomber genoux -> genoux

Un mouvement, c’est :

• une position de départ,
• un mouvement aérien,
• une position d’arrivée.

La position de départ est omise si elle est logique ou déductible (ex : salto avant → départ debout, salto avant, arrivée debout). On pourrait donc, dans l’interface, n’afficher que les positions de départ autre que debout.

La position d’arrivée est parfois omise si elle est logique ou déductible (ex : 4 pattes – salto avant → sous-entend : 4 pattes – salto avant, arrivé debout). On pourrait donc, dans l’interface, n’afficher que les positions de départ autre que debout.

Le mouvement aérien est, lui, composé de :

• un nom long,
• un nom court,
• un nombre de ¼ de rotation transversale
• un nombre de ½ de rotation longitudinale
• un type de rotation (avant/arrière)
• une position

Nom long et nom court : Le nom long d’un mouvement est composé de la position de départ (long label), le nom long du mouvement aérien (long label) et du nom long de la position d’arrivée (long label), ces trois informations étant séparés par une virgule. Pour le nom court, il en est de même avec le nom court des positions d’arrivée/de départ et du mouvement aérien.

Par exemple : Nom du mouvement aérien : tomber Nom long : départ debout, tomber, 4 pattes Nom court : tomber, 4 pattes

Nom du mouvement aérien : salto avant Nom long : départ 4 pattes, salto avant, arrivé debout Nom court : 4 pattes, salto avant.

Question : dois-je stocker les noms courts et noms longs ou les générer à la volée en cas de besoin ? Je pense à les stocker car certains noms courts et longs sont particuliers, ils doivent donc pouvoir être personnalisables. Dois-je stocker le nom du mouvement aérien ? S’il ne me sert qu’à générer le nom court et/ou le nom long, cela ne sert à rien.

Certains mouvements ont des noms propres :

• Roller : Assis – vrille, assis (départ non défini, tomber assis – départ assis, vrille complète, retomber assis)
• Cattwist : Dos – vrille, dos (départ non défini, tomber dos – départ dos, vrille complète, retomber dos)
• Ball out : Dos – salto avant, arrivé debout (départ non défini, tomber dos – départ dos, salto avant, retomber debout)
• …

Ces noms seront alors stockés dans le label long ou court du mouvement. Sinon, De manière générale, le nom du mouvement est composé de la position d’arrivée concaténée au mouvement aérien (et de la position d’arrivée si elle est particulière).

Certains mouvements ne sont pas autorisés en compétition parce que le départ ou l’arrivée ne sont pas acceptés par le règlement. Il faut pouvoir distinguer ces mouvements. Pour cela, il suffit de distinguer les arrivées non autorisées.

L’autorisation d’une arrivée étant contenue dans la table TOUCH_POSITION l’autorisation d’un mouvement peut-être déduit de l’autorisation de l’arrivée :

1. 4 pattes : pas autorisé → 4 pattes – salto avant : ne sera pas autorisé
2. ATR : pas autorisé → dos – ATR : ne sera pas autorisé
3. Ventre : autorisé → Salto avant, arrivée ventre : 5/4 de rotation avant composés de ‘salto avant’ directement lié à un tomber ventral (autorisée), le mouvement sera autorisé.

Cette déduction automatique vient du fait que chaque mouvement est lié (par le arrivalID) à une arrivée/départ (i.e. : ventre, dos, genoux, …)

Niveau, rang et difficulté

Difficulté

Le calcul de la difficulté d'un saut est définit dans le règlement technique international : 0,1pt par 1/4 de rotation salto ou par 1/2 vrille. A cela s'ajoute des bonus de positions (carpé ou tendue pour des salto simple sans vrille ou salto multiple) ou de réalisation de salto multiples (triple, quadruple).

Rang

En plus de la difficulté, chaque figure est réliée à d'autre(s) par les méthodologie d'apprentissage : il y a un ordre dans l'apprentissage basé sur la part méthode, sur des similitudes de forme, ... Un élève apprend, par exemple, le 4 pattes avant le ventre, le ventre avant le 3/4 arrière, et ainsi de suite. Il est donc possible de créer un*arbre d'apprentissag* sorte d'arbre généalogique d'un mouvement. Ainsi, il est possible, pour chaque élément, connaitre son rang (son*étag* dans l'arbre) et ainsi de pouvoir identifier pour un rang X l'ensemble de ses éléments de ce rang et de les travailler en même temps. Cela permet de s'assurer que l'élève avance de manière équivalente dans toutes les directions.

Niveau

La difficulté (à l'heure actuelle) ne prend pas tout en compte : un mouvement en position carpé ou tendu possède la même valeur de difficulté. Pourtant, ne serait ce que d'un point de vue biomécanique (et donc forces mises en jeu) un mouvement en position tendue est plus complexe et contraignant qu'un mouvement en position carpée.

Le rang quant à lui, s'il apporte une information supplémentaire importante, est aussi victime du nombre d'éducatif qui existe entre deux étapes. Prenons deux touches A et B, si pour aller à A il y a 4 étapes alors que pour aller à B il y en a 10, A sera de rang 5 alors que B sera de rang 11. Pourtant A et B pourraient être similaires (ex: A est salto avant groupé, B est salto arrière groupé. Tout les deux 4 quarts de rotation salto, sans vrille, départ des pieds, arrivée sur les pieds, même position, ...). On ne peut donc pas être entièrement satisfait par le rang.

Le but de ce champs est donc de mélanger les deux concepts : la notion de difficulté telle que définie par le règlement technique et les considérations physique/biomécanique et de pouvoir classer les figure entre elles par difficilté de réalisation, le tout en tenant également compte du rang. Cela devrait donner une sorte de rang "ventilé".

Design

En dehors de tout cela, un mouvement (complet) possède :

• nom long
• nom court
• position (0, o, <, / ou //)
• type de rotation (avant/arrière/NA)
• nombre de ¼ de rotation (salto)
• nombre de ½ rotation longitudinale (vrille)
• difficulté
• notation (code numérique du mouvement)
• notation simplifiée
• niveau
• rang
• educative
• prerequisite

Design :

Skillid				Id (PK)
longName			Varchar(50)
shortName			Varchar(25)
Position			Enum (ou varchar(2)). Position du mouvement aérien.
rotationType		Enum. Type de la rotation : avant, arrière ou sans objet.
nbRotation			Int. Nombre de ¼ de rotation transversale
nbTwist				Int. Nombre de ½ tour
Difficulty			Float(3,1). Coefficient de difficulté
Notation			Varchar(15). Notation alpha-numérique officielle internationnale.
simplyNotation		Varchar(10). Notation alpha-numérique simplifiée.
level				Int. Niveau du mouvement.
rank				Int. Rang du mouvement.
educative			FK(self)
prerequisite		FK(self)
departurePosition	arrivalID.
arrivalPosition		arrivalID.

Table EDUCATIVES

Un éducatif est un mouvement ou un enchainement de mouvements (plusieurs mouvements donc) qui va créer chez l’élève un schéma corporel et/ou physiologique et/ou psychologique … pour lui permettre d’approcher un autre mouvement.

Exemple :

• « culbute avant » est l’éducatif du salto avant
• « petit piqué » est l’éducatif du salto avant
• « 4 pattes – salto avant » est l’éducatif du salto avant

Chaque éducatif peut être lié à un (ou n) mouvement(s). Chaque mouvement peut avoir un (ou n) éducatifs. Chaque éducatif peut avoir un ou plusieurs éducatif. → Nous avons donc une relation n,n entre mouvements et éducatifs. → Nous avons également une relation n,n entre éducatifs

Les éducatifs d’un mouvement (s’il y en a plusieurs) peuvent (mais ne doivent pas forcément) avoir un ordre (partiel/flou). Un éducatif possède également un ‘niveau’. L’ordre de plusieurs éducatifs pour un même saut peut être approximé en utilisant le niveau comme rang.

Table ROUTINE

Cette table a pour but de pouvoir stocker des séries. Une série est un enchainement de saut (SKILL). Dans une série/enchaînement, la position de départ du mouvement n+1 est, logiquement, la position d’arrivée du mouvement n. Il pourrait donc être envisagé que lorsque l’interface affiche un enchaînement de réduire les informations affichées :

• La position de départ du premier mouvement de toute série de mouvements est d’office « Debout ». Cette position peut donc ne pas être affichée.
• Pour les mouvements suivants :
  • n’afficher les arrivées que si elles sont différentes de « debout » puisque flaggée « Default »
  • ne pas afficher les positions de départs puisque c’est la position d’arrivée du mouvement précédent. Donc un mouvement a une représentation textuelle ; une série de mouvements a une représentation textuelle également, basée sur les mouvements dont elle est composée.

Exemple : Départ debout, tomber, 4 pattes – départ 4 pattes, salto avant, arrivé debout. On a donc bien un enchainement de deux mouvements, représenté chacun par une occurrence dans la table Skill :

1. Skill A : Départ debout, tomber, 4 pattes
2. Skill B : départ 4 pattes, salto avant, arrivé debout.

Cet enchaînement peut, par simplification évoquée ci-avant, s’écrire : 4 pattes – salto avant

La représentation de A est la suivante :

• Debout est ignoré car c’est la position par défaut
• Tomber quatre pattes est la représentation textuelle

La représentation de B est la suivante :

• Quatre pattes est ignoré, car B n’est pas le premier mouvement de l’enchaînement (donc B.Departure = A.Arrival)
• La position d’arrivée (debout) est ignorée car c’est la position par défaut
• Salto avant reste la valeur textuelle.

En concaténant les deux, il reste : « Tomber quatre pattes, salto avant ».

Explications :

• On omet la position du départ du mouvement ‘tomber 4 pattes’ car elle est logique (départ debout).
• On omet la position du départ du ‘salto avant’ car elle est logique par rapport au mouvement d’avant (départ 4 pattes).
• On omet la position d’arrivée du ‘salto avant’ car elle est logique (arrivée debout).

Problème : comment noter les tombers ? Ici le « tomber 4 pattes » n’a que deux informations : la position de départ et la position d’arrivée. Peut-être pourrait-on dire que le mouvement est le « tomber ». On aurait alors : « Départ debout, tomber, 4 pattes » Tel que : « Position de départ, mouvement, position d’arrivée ».

Une série est un enchainement de mouvements (n’ayant pas de but direct ou indirect d’éducatif). Les séries sont, en grande généralité, des exercices de compétition (10 sauts, que des arrivées autorisées, …) mais pas toujours : elles peuvent aussi avoir pour but un travail précis (hauteur, vrille, …) et utiliser des mouvements comportant des arrivées et/ou des départs non autorisés, elles peuvent comporter un nombre non limité de sauts, …

Les mouvements de séries ont obligatoirement un ordre à l’intérieur de celle-ci : il y a le mouvement 1, le mouvement 2, … le mouvement n.

Une série possède :

• un nom court,
• un nom long,
• un coefficient de difficulté (somme des coefficients de difficulté des mouvements composant la série),
• un niveau,
• une date qui, si elle est remplie, indique à partir de quand la série n’est plus valable.

Dans le cas de compétition, il y a deux séries : imposé et libre. La libre est différente pour chacun mais elle doit répondre à certains critères définis avec (en même temps) que l’imposé : un minimum de difficulté, un maximum de difficulté et minimum (de point) de qualification. Ces trois informations sont donc, par convention, associées à la « série imposée » et non à la « série libre ».

De plus, une série imposée peut comporter des limite d’âge (âge min, âge max) qu’il est important de connaître afin de na pas attribuer une série à un gym qui ne correspondrait pas aux critères d’âge.

Une série imposée doit donc pouvoir être (re)connue comme telle.

GT Réflexion : Un imposé est « imposé » dans un circuit de compétition X. X et Y sont deux circuits de compétitions différents, mais n’ont pas forcément les mêmes imposés. Ne serait-il pas intéressant de référencer les différents circuits de compétitions et d’y associer les séries imposées et les exigences (âge, diff, …) ? Si oui, comme faire cela ? (et quand faire cette étape sachant que ce n’est pas la plus importante).

La date est là pour indiquer si une série « imposée » est encore active ou pas. Cela permet de garde un historique des séries qui, un jour, seront associés à des élèves et/ou des compétitions. => lien avec le pays & la période/saison (période de dates) ?

Table OBJECTIVES

Un objectif est un but à atteindre, une étape à franchir (pas forcément obligatoire) par l’élève. Un objectif peut être :

• un mouvement (record de la table SKILL),
• un éducatif (record de la table EDUCATIVE) ou
• une série (record de la table ROUTINE).

A terme, un objectif devra pouvoir être associé à un élève (via une fonction de planning, de liste de tache/todo, …)

La table OBJECTIVE est donc la table mère dans un héritage. Les tables héritant d’elle sont : SKILL, EDUCATIVE et ROUTINE.

---

Partie COMPETITION

Table COMPETITION

Un circuit de compétition est enregistré dans cette table. Il est définit par un nom, une saison (?) et un règlement. Le règlement, sous forme d’un fichier PDF, sera enregistrer par le site.

Design :

ID			ID (PK)
Label		Varchar. Nom du circuit de compétition
Acronym		Varchar. Acronyme du circuit de compétition
Reglement	File. Fichier PDF du réglèment du circuit

Table DIVISION

Un circuit de compétition se compose de 1 à N divisions. Chaque division se subdivise en niveau basé sur l’âge ou sur d’autre critère. Afin de représenter cela nous allons utiliser une table division.

Design :

ID				ID (PK)
CompetitionID	ID (FK)
Name			Varchar. Nom de la division
Acronym			Varchar. Acronyme de la division

Table NIVEAU

Un niveau est composé d’une série imposé (ou libre à exigence) ainsi que des contraintes :

• nombre de points qu’il faut pour être qualifié pour la phase suivante,
• une difficulté minimale (et parfois maximale aussi),
• un âge minimum (et parfois maximum aussi)

La série imposée est soit :

• totalement imposé : 10 sauts sont imposé ainsi que leur ordre.
• partiellement imposé :
  • certains sauts sont imposés totalement (avec des ET ou des OU) ou partiellement (obligation d’une arrivée ou d’un départ spécifique)
  • un ordre peut être imposé (pour ces sauts)
  • un nombre de saut ayant une certain quantité de rotation (en degré) est imposé (ex : « 5 saut de 270° de rotation minimum »)

Design :

ID	ID (PK)
DivisionID	ID (FK)
Name		Varchar. Nom du niveau
Acronym		Varchar. Acronyme du niveau
Agemin		Int. Age minimum
Agemax		Int. Age maximum
QualifPoint	Double(6,3). Point pour être qualifié pour la phase suivante

Pour le reste de la table, je dois encore réfléchir.

---

 

Partie UTILISATEURS

Avec ce programme je souhaite pouvoir gérer mes gymnastes : leurs présence, leur participation à des évènements, leur objectifs, … Je souhaite également permettre aux moniteurs avec qui je travaille d’avoir accès à ces informations.

Cependant comme je travaille dans plusieurs clubs, il faudrait que je puisse –moi- voir tous les gymnastes mais que les moniteurs se connectant ne puissent voir les gymnastes que de leur club. Il faudrait donc lier un utilisateur à un club et les gymnastes à un club. La liaison gym <-> club peut se faire grâce aux tables COURSE et TRAINING. Pour les Utilisateurs, il faudrait une table USER (déjà générée par Django) et une table de liaison entre la table CLUB et cette table USER. Est-ce possible ?