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 ?

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