|
Taille: 3949
Commentaire:
|
← Version 35 à la date du 2008-02-21 22:10:00 ⇥
Taille: 4612
Commentaire: converted to 1.6 markup
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| ## page was renamed from Projet/GestionDesUtilisateursDesCampus/SchemaBase/HistoriquePropositionThomas ## page was renamed from Projet/GestionDesUtilisateursDesCampus/SchemaBase |
|
| Ligne 4: | Ligne 6: |
| attachment:base_utilisateurs_campus.png | {{attachment:base_utilisateurs_campus.png}} |
| Ligne 6: | Ligne 8: |
| Version UML (Très Basique) [http://tedia2sql.tigris.org/usingtedia2sql.html http://tedia2sql.tigris.org/usingtedia2sql.html] | |
| Ligne 8: | Ligne 9: |
| Exemple génération SQL: {{{ tedia2sql -t postgres -f -m -v1 -i ./base_utilisateurs_campus_uml.dia -o ./base_utilisateurs_campus.sql }}} |
les sources Dia de ce schéma : [[attachment:base_utilisateurs_campus.dia]] |
| Ligne 13: | Ligne 11: |
| attachment:base_utilisateurs_campus_uml.png | |
| Ligne 15: | Ligne 12: |
| les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia les sources Dia du schéma UML : attachment:base_utilisateurs_campus_uml.dia SQL généré pour PostgreSQL : attachment:base_utilisateurs_campus.sql = Les utilisateurs = |
== Les utilisateurs == |
| Ligne 37: | Ligne 28: |
| . variable : nom de la variable (par exemple : ''courriel_alias'', ''homedir'', ''adresse'', ''téléphone'') | . variable : nom de la variable |
| Ligne 40: | Ligne 31: |
| Tini voudrait tout passer en champ extra ../PropositionTini ... mais... je sais pas, qu'en pensez-vous ? . MS: Pourquoi? Pourquoi tu préfères avoir beaucoup de renseignements dans la table principale et Tini moins? Zavez p'tet des arguments qui sautent pas aux yeux. Sur le principe, ok, pour abonner un utilisateur, on a pas besoin de grand chose, id, nom/prénom, login. Mais à l'usage, on ne prendra jamais le temps de remplir les extras si on ne le fait pas dès le début.(J'imagine que la table principale, tous les champs sont à renseigner, alors qu'en extra non.) . TN : tu as vu juste et je suis d'accord avec ton raisonnement. Moi je préfère que la table de base contienne quand même quelques infos "obligatoires". Par ailleurs pour l'API ça pourrait quand même être plus simple à gérer. En fait, Jérôme avait surtout un soucis avec la prédominance du champ "courriel" sur les possibles champs extra "courriel_forward" et "courriel_alias". Je ne sais pas s'il a avancé dans ses reflexions pendant qu'il dé-spaghettisait le firewall de Niamey ;) . MS : Pourquoi "courriel_forward" et "courriel_alias"? On a besoin d'enregistrer tant d'info sur nos utilisateurs? Un seul mail, celui fournit par le CNF, les utilisations de yahoo/hotmail n'étant pas recommandé. |
. ''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 45: | Ligne 41: |
| = Les groupes = | == Les groupes == |
| Ligne 57: | Ligne 53: |
| = Les abonnements = | == Les abonnements == |
| Ligne 69: | Ligne 65: |
| = Les organismes = | == Les organismes == |
| Ligne 107: | Ligne 103: |
= Archives et idées pour le futur (à ne pas insérer dans la version 0) = == 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.
les sources Dia de ce schéma : base_utilisateurs_campus.dia
Les utilisateurs
- Table utilisateurs
- id
- login
- mot_de_passe
- courriel
- 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
Archives et idées pour le futur (à ne pas insérer dans la version 0)
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: base_utilisateurs_campus_uml.dia
SQL généré pour PostgreSQL : base_utilisateurs_campus.sql
Génération SQL avec tedia2sql :
tedia2sql -t postgres -f -m -v1 -i ./base_utilisateurs_campus_uml.dia -o ./base_utilisateurs_campus.sql