Modifications entre les versions 4 et 22 (s'étendant sur 18 versions)
⇤ ← Version 4 à la date du 2006-10-31 16:16:15 →
Taille: 1243
Éditeur: ThomasNoël
Commentaire: plusieurs organismes par utilisateur, ça serait mieux non ?
← Version 22 à la date du 2006-11-07 09:09:18 → ⇥
Taille: 3230
Éditeur: MatthieuSchneider
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''' <i> 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:
== Table utilisateurs_extra == Version UML (Très Basique) [http://tedia2sql.tigris.org/usingtedia2sql.html http://tedia2sql.tigris.org/usingtedia2sql.html]
Ligne 21: Ligne 8:
 * '''id_utilisateur''' : utilisateur concerné
 * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'')
 * '''valeur'''		 Exemple génération SQL:
{{{
   tedia2sql -t postgres -f -m -v1 -i ./base_utilisateurs_campus_uml.dia -o ./base_utilisateurs_campus.sql
}}}
Ligne 25: Ligne 13:
== Table groupes ==   attachment:base_utilisateurs_campus_uml.png
Ligne 27: Ligne 15:
 * '''id'''
 * '''nom'''
 * '''commentaires'''		 les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia
Ligne 31: Ligne 17:
== Table groupes_extra == les sources Dia du schéma UML : attachment:base_utilisateurs_campus_uml.dia
Ligne 33: Ligne 19:
 * '''id_groupe'''
 * '''variable'''
 * '''valeur'''		 SQL généré pour PostgreSQL : attachment:base_utilisateurs_campus.sql
Ligne 37: Ligne 21:
== Table abonnements == = Les utilisateurs =
Ligne 39: Ligne 23:
 * '''id_utilisateur'''
 * '''id_groupe'''
 * '''date_debut'''
 * '''date_fin'''
 * '''commentaires'''		  Table utilisateurs::
  . id
  . login
  . mot_de_passe
  . courriel
  . nom_complet
  . nom
  . prénom
  . genre
  . date_naissance
  . commentaires
Ligne 45: Ligne 35:
== Table organismes ==  Table utilisateurs_extra::
  . id_utilisateur : utilisateur concerné
  . variable : nom de la variable (par exemple : ''courriel_alias'', ''homedir'', ''adresse'', ''téléphone'')
  . valeur
Ligne 47: Ligne 40:
 * '''id'''
 * '''nom'''
 * '''adresses'''
 * '''telephones'''
 * '''id_parent''' : pointe vers un id_organisme (0 pour la racine)
 * '''commentaires'''		 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 54: Ligne 43:
== Table organismes_extra == = Les groupes =
Ligne 56: Ligne 45:
 * '''id_organisme'''
 * '''variable'''
 * '''valeur'''		  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

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

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