Modifications entre les versions 7 et 28 (s'étendant sur 21 versions)
⇤ ← Version 7 à la date du 2006-11-02 12:14:42 →
Taille: 3216
Éditeur: ThomasNoël
Commentaire:
← Version 28 à la date du 2006-11-14 15:30:23 → ⇥
Taille: 4364
Éditeur: ThomasNoël
Commentaire: comment parler pour ne rien dire...
Texte supprimé. Texte ajouté.
Ligne 3: Ligne 3:
== Table utilisateurs ==
Ligne 5: Ligne 4:
 * '''id'''
 * '''login'''
 * '''mot_de_passe'''
 * '''courriel'''
 * '''nom'''
 * '''prénom'''
 * '''genre'''
 * '''date_naissance'''
 * '''adresses'''
 * '''téléphones'''
 * '''id_organisme''' <!> plusieurs organismes, ça serait mieux non ? (faire une table de correspondance ''1,n'' à part)
 * '''fonction'''
 * '''commentaires'''

 . CédricProtière : oui amha pour plusieurs organismes (donc ajouter tables '''organismes''' et '''utilisateurs_organismes''')
Je crois qu'il en est de même pour la fonction (on peut par exemple être enseignant chercheur et étudiant foad en même temps...) => il faut alors aussi créer les tables '''fonction''' et '''utilisateur_fonction'''
 . Thomas : s'il y a plusieurs organismes possible on peut effectivement imaginer une fonction pour chaque organisme. Ensuite, pour la notion d'étudiant FOAD, c'est pas pareil (ça sera vu au niveau que le gars est dans le groupe "FOAD", par exemple)

== Table utilisateurs_extra ==

 * '''id_utilisateur''' : utilisateur concerné
 * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'')
 * '''valeur'''

== Table groupes ==

 * '''id'''
 * '''nom'''
 * '''commentaires'''

== Table groupes_extra ==

 * '''id_groupe'''
 * '''variable'''
 * '''valeur'''

== Table abonnements ==

 * '''id_utilisateur'''
 * '''id_groupe'''
 * '''date_debut'''
 * '''date_fin'''
 * '''commentaires'''

== Table organismes ==

 * '''id'''
 * '''nom'''
 * '''adresses'''
 * '''telephones'''
 * '''id_parent''' : pointe vers un id_organisme (0 pour la racine)
 * '''commentaires'''

== Table organismes_extra ==

 * '''id_organisme'''
 * '''variable'''
 * '''valeur'''		   attachment:base_utilisateurs_campus.png
Ligne 65: Ligne 7:
= La suite ne fait pas partie de la proposition de Thomas ;) = les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia
Ligne 68: Ligne 10:
 . CédricProtière : Nous pourrions créer des règles de gestion pour les défauts (par exemple : email = identifiant@pays.refer.org par défaut), ces règles pouvant être stockées dans le code ou mieux en base.
D'autres défauts seraient statiques (ne dépendent pas de règles, mais du choix de la personne qui a créé un groupe)
je propose de créer les tables '''defaut''' pour certaines tables ci-dessus, par exemple les tables suivantes :		 = Les utilisateurs =
Ligne 72: Ligne 12:
 . Thomas : mon idée, c'est que les config du systèmes seront dans des fichiers de config. Je ne suis pas partisan de "tout" mettre dans la base.  Table utilisateurs::
  . id
  . login
  . mot_de_passe
  . --(courriel)-- ''passe en extra... temporairement ?''
  . nom_complet
  . nom
  . prénom
  . genre
  . date_naissance
  . commentaires
Ligne 74: Ligne 24:
== Table defauts_groupes ==
 * '''id_defaut'''
 * '''fin_abonnement''' ''date de fin de l'abonnement prérenseignée par défaut lors de l'abonnement d'un utilisateur à ce groupe''		  Table utilisateurs_extra::
  . id_utilisateur : utilisateur concerné
  . variable : nom de la variable
  . valeur
Ligne 78: Ligne 29:
== Table defauts_groupes_extra ==
 * '''id_groupe'''
 * '''id_variable'''
 * '''id_defaut''' (ou : on pourrait ajouter cette colonne dans la table '''groupes_extra''')		   . ''Exemples de variables extra :''
   . adresse (qui ne sera pas celle de l'organisme avec lequel la personne est relié, cf plus bas)
   . téléphone
   . courriel_canonique (adresse de réécriture en sortie)
   . courriel (n fois)
   . courriel_transfert (forward, quoi. à utiliser si l'adresse de contact != refer)
   . repertoire_courriels (forme serveur:/repertoire)
   . repertoire_fichiers (le HOME, par exemple sous la forme serveur:/repertoire)
   . acces_shell (0/1)
Ligne 83: Ligne 39:
Si on est forts, on peut même créer une syntaxe pour les règles (pourquoi pas type balises SPIP), qui permettraient de faire des tables du type :
== Table defauts_utilisateurs ==
 * '''id_utilisateur'''
 * '''regle_courriel''' ''pourrait contenir : ''#IDENTIFIANT@#PAYS.refer.org''
 * '''defaut_fonction''' ''etudiant''		 = Les groupes =

 Table groupes::
  . id
  . nom
  . commentaires

 Table groupes_extra::
  . id_groupe
  . variable
  . valeur

= Les abonnements =

Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps.

 Table abonnements::
  . id_utilisateur
  . id_groupe
  . date_debut
  . date_fin
  . suspendu : mis à ''vrai'' si l'abonnement est interrompu temporairement (idée de SébastienDornano)
  . commentaires

= Les organismes =

Ils sont hiérarchisés (arbre simple : un parent peut avoir plusieurs fils).

 Table organismes::
  . id
  . nom
  . adresses
  . telephones
  . id_organisme_parent : pointe vers un id_organisme (0 pour la racine)
  . commentaires

 Table organismes_extra::
  . ''note : je ne suis pas sûr de l'utilité de ces extras''
  . id_organisme
  . variable
  . valeur

Chaque utilisateur peut être rattaché à un ou plusieurs organismes. A chaque rattachement on indique la fonction de l'utilisateur dans l'organisme, via un triplet { utilisateur, organisme, fonction }. On peut donc imaginer qu'un utilisateur puisse avoir plusieurs fonctions au sein d'un même organisme.

 Table fonction::
  . id
  . nom
  . commentaires

 Table fonction_extra::
  . ''note : je ne suis pas sûr de l'utilité de ces extras''
  . id_fonction
  . variable
  . valeur

 Table utilisateur_organisme_fonction::
  . id_utilisateur
  . id_organisme
  . id_fonction
  . date_debut (idée pompée sur la proposition de Seb)
  . date_fin
  . commentaires

= Suivi =

Django dispose d'un système de suivi, mais ne sera-t-il pas trop générique pour nos utilisations ? Permettra-t-il par exemple de trouver simplement le taux de réabonnement des utilisateurs ? Il faudrait peut-être travailler à une table "suivi" très générique qui disposera d'une API utilisable par tous les autres objets... Ca "surclasse" un peu Django, mais ça rendra aussi notre base de donnée utilisable par un autre système que Django, un jour...

 Table action_suivi::
  . id
  . nom (par exemple ''nouvelabonnement'', ''reabonnement'', ...)

 Table suivi::
  . type_objet
  . id_objet
  . date
  . id_action_suivi
  . donnees (permet de définir des détails sur l'action, par exemple "mensuel" pour un réabonnement)

Peut-être que quelque chose d'encore plus générique serait nécessaire ? (pas d'id_action_suivi mais juste des donnees, par exemple "reabonnement:mensuel" ou "nouvelabonnement:annuel")

 Notes::
 :: l'exemple des ré-abonnements est assez mal choisi car on pourra les calculer autrement et bien plus précisément via la table ''abonnements''.
 :: ... et comme je ne vois pas d'autre usage, je propose de laisser tomber ce suivi parallèle à Django ; on verra ça "plus tard" !

= UML (très basique) =

Note à OusmaneWilane : j'ai descendu ce schéma qui n'est plus synchro avec le reste.

 . source Dia du schéma UML: attachment:base_utilisateurs_campus_uml.dia
 . SQL généré pour PostgreSQL : attachment:base_utilisateurs_campus.sql

Génération SQL avec [http://tedia2sql.tigris.org/usingtedia2sql.html tedia2sql] :
{{{
   tedia2sql -t postgres -f -m -v1 -i ./base_utilisateurs_campus_uml.dia -o ./base_utilisateurs_campus.sql
}}}

Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs.

  • attachment:base_utilisateurs_campus.png

les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia

Les utilisateurs

Table utilisateurs
  • id
  • login
  • mot_de_passe

  • courriel passe en extra... temporairement ?

  • nom_complet
  • nom
  • prénom
  • genre
  • date_naissance
  • commentaires
Table utilisateurs_extra
  • id_utilisateur : utilisateur concerné
  • variable : nom de la variable
  • valeur

  • Exemples de variables extra :

    • adresse (qui ne sera pas celle de l'organisme avec lequel la personne est relié, cf plus bas)
    • téléphone
    • courriel_canonique (adresse de réécriture en sortie)
    • courriel (n fois)
    • courriel_transfert (forward, quoi. à utiliser si l'adresse de contact != refer)
    • repertoire_courriels (forme serveur:/repertoire)
    • repertoire_fichiers (le HOME, par exemple sous la forme serveur:/repertoire)
    • acces_shell (0/1)

Les groupes

Table groupes
  • id
  • nom
  • commentaires
Table groupes_extra
  • id_groupe
  • variable
  • valeur

Les abonnements

Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps.

Table abonnements
  • id_utilisateur
  • id_groupe
  • date_debut
  • date_fin

  • suspendu : mis à vrai si l'abonnement est interrompu temporairement (idée de SébastienDornano)

  • commentaires

Les organismes

Ils sont hiérarchisés (arbre simple : un parent peut avoir plusieurs fils).

Table organismes
  • id
  • nom
  • adresses
  • telephones
  • id_organisme_parent : pointe vers un id_organisme (0 pour la racine)
  • commentaires
Table organismes_extra

  • note : je ne suis pas sûr de l'utilité de ces extras

  • id_organisme
  • variable
  • valeur

Chaque utilisateur peut être rattaché à un ou plusieurs organismes. A chaque rattachement on indique la fonction de l'utilisateur dans l'organisme, via un triplet { utilisateur, organisme, fonction }. On peut donc imaginer qu'un utilisateur puisse avoir plusieurs fonctions au sein d'un même organisme.

Table fonction
  • id
  • nom
  • commentaires
Table fonction_extra

  • note : je ne suis pas sûr de l'utilité de ces extras

  • id_fonction
  • variable
  • valeur
Table utilisateur_organisme_fonction
  • id_utilisateur
  • id_organisme
  • id_fonction
  • date_debut (idée pompée sur la proposition de Seb)
  • date_fin
  • commentaires

Suivi

Django dispose d'un système de suivi, mais ne sera-t-il pas trop générique pour nos utilisations ? Permettra-t-il par exemple de trouver simplement le taux de réabonnement des utilisateurs ? Il faudrait peut-être travailler à une table "suivi" très générique qui disposera d'une API utilisable par tous les autres objets... Ca "surclasse" un peu Django, mais ça rendra aussi notre base de donnée utilisable par un autre système que Django, un jour...

Table action_suivi
  • id

  • nom (par exemple nouvelabonnement, reabonnement, ...)

Table suivi
  • type_objet
  • id_objet
  • date
  • id_action_suivi
  • donnees (permet de définir des détails sur l'action, par exemple "mensuel" pour un réabonnement)

Peut-être que quelque chose d'encore plus générique serait nécessaire ? (pas d'id_action_suivi mais juste des donnees, par exemple "reabonnement:mensuel" ou "nouvelabonnement:annuel")

Notes

l'exemple des ré-abonnements est assez mal choisi car on pourra les calculer autrement et bien plus précisément via la table abonnements.

... et comme je ne vois pas d'autre usage, je propose de laisser tomber ce suivi parallèle à Django ; on verra ça "plus tard" !

UML (très basique)

Note à OusmaneWilane : j'ai descendu ce schéma qui n'est plus synchro avec le reste.

  • source Dia du schéma UML: attachment:base_utilisateurs_campus_uml.dia
  • SQL généré pour PostgreSQL : attachment:base_utilisateurs_campus.sql

Génération SQL avec [http://tedia2sql.tigris.org/usingtedia2sql.html tedia2sql] : 

   tedia2sql -t postgres -f -m -v1 -i ./base_utilisateurs_campus_uml.dia -o ./base_utilisateurs_campus.sql

Projet/GUIA/SchemaBase/HistoriquePropositionThomas (dernière édition le 2008-02-21 22:10:00 par localhost)