|
Taille: 3910
Commentaire:
|
Taille: 3230
Commentaire:
|
| 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''' |
attachment:base_utilisateurs_campus.png |
| Ligne 19: | Ligne 6: |
| . 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) . Cédric : mon exemple était mauvais. Certains utilisateurs ont plusieurs fonctions (vice-recteur de l'université, enseignant de telle faculté...) qu'il serait bon je trouve d'avoir dans nos bases, afin de profiter de cet outil pour mettre en place un annuaire informatisé des universités (quitte à ce que ça fasse doublon avec le SI de l'université : dans ce cas c'est à l'admin sys du CNF de savoir quel SI privilégier ou promouvoir...) |
Version UML (Très Basique) [http://tedia2sql.tigris.org/usingtedia2sql.html http://tedia2sql.tigris.org/usingtedia2sql.html] |
| Ligne 24: | Ligne 8: |
| == Table utilisateurs_extra == | Exemple génération SQL: {{{ tedia2sql -t postgres -f -m -v1 -i ./base_utilisateurs_campus_uml.dia -o ./base_utilisateurs_campus.sql }}} |
| Ligne 26: | Ligne 13: |
| * '''id_utilisateur''' : utilisateur concerné * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') * '''valeur''' |
attachment:base_utilisateurs_campus_uml.png |
| Ligne 30: | Ligne 15: |
| == Table groupes == | les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia |
| Ligne 32: | Ligne 17: |
| * '''id''' * '''nom''' * '''commentaires''' |
les sources Dia du schéma UML : attachment:base_utilisateurs_campus_uml.dia |
| Ligne 36: | Ligne 19: |
| == Table groupes_extra == | SQL généré pour PostgreSQL : attachment:base_utilisateurs_campus.sql |
| Ligne 38: | Ligne 21: |
| * '''id_groupe''' * '''variable''' * '''valeur''' |
= Les utilisateurs = |
| Ligne 42: | Ligne 23: |
| == Table abonnements == | Table utilisateurs:: . id . login . mot_de_passe . courriel . nom_complet . nom . prénom . genre . date_naissance . commentaires |
| Ligne 44: | Ligne 35: |
| * '''id_utilisateur''' * '''id_groupe''' * '''date_debut''' * '''date_fin''' * '''commentaires''' |
Table utilisateurs_extra:: . id_utilisateur : utilisateur concerné . variable : nom de la variable (par exemple : ''courriel_alias'', ''homedir'', ''adresse'', ''téléphone'') . valeur |
| Ligne 50: | Ligne 40: |
| == Table organismes == | 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.) |
| Ligne 52: | Ligne 43: |
| * '''id''' * '''nom''' * '''adresses''' * '''telephones''' * '''id_parent''' : pointe vers un id_organisme (0 pour la racine) * '''commentaires''' |
= Les groupes = |
| Ligne 59: | Ligne 45: |
| == Table organismes_extra == | Table groupes:: . id . nom . commentaires |
| Ligne 61: | Ligne 50: |
| * '''id_organisme''' * '''variable''' * '''valeur''' |
Table groupes_extra:: . id_groupe . variable . valeur |
| Ligne 65: | Ligne 55: |
| = Les abonnements = | |
| Ligne 66: | Ligne 57: |
| = La suite ne fait pas partie de la proposition de Thomas ;) = | Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps. |
| Ligne 68: | Ligne 59: |
| 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 |
|
| Ligne 69: | Ligne 67: |
| . 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 organismes = |
| Ligne 73: | Ligne 69: |
| . 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. . Cédric : oui ! on pourrait même faire des fichiers de configuration comme dans le paquet auf-asterisk, qui prennent les dates de fin de chaque formation et qu'on met à jour à chaque dist-upgrade. OK pour les sortir de la base, donc |
Ils sont hiérarchisés (arbre simple : un parent peut avoir plusieurs fils). |
| Ligne 76: | Ligne 71: |
| == 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 organismes:: . id . nom . adresses . telephones . id_organisme_parent : pointe vers un id_organisme (0 pour la racine) . commentaires |
| Ligne 80: | Ligne 79: |
| == Table defauts_groupes_extra == * '''id_groupe''' * '''id_variable''' * '''id_defaut''' (ou : on pourrait ajouter cette colonne dans la table '''groupes_extra''') |
Table organismes_extra:: . ''note : je ne suis pas sûr de l'utilité de ces extras'' . id_organisme . variable . valeur |
| Ligne 85: | Ligne 85: |
| 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'' |
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 |
Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs.
- attachment:base_utilisateurs_campus.png
Version UML (Très Basique) [http://tedia2sql.tigris.org/usingtedia2sql.html http://tedia2sql.tigris.org/usingtedia2sql.html]
Exemple génération SQL:
tedia2sql -t postgres -f -m -v1 -i ./base_utilisateurs_campus_uml.dia -o ./base_utilisateurs_campus.sql
- attachment:base_utilisateurs_campus_uml.png
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
- 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 (par exemple : courriel_alias, homedir, adresse, téléphone)
- valeur
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.)
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