|
Taille: 2257
Commentaire:
|
Taille: 4156
Commentaire:
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| Voici ma (ThomasNoël) proposition pour la base de donnée des utilisateurs. = Idées générales = * des utilisateurs, des groupes et des abonnements qui permettent de dire que tel utilisateur est dans tel groupe de telle à telle date * la base n'est pas destinée à être utilisée telle quelle pour l'authentification ou la gestion système : des ''backends'' sont disponibles pour créer, à partir de cette base, les données système nécessaires (fichiers ''passwd+shadow'', base MySQL-auth, arbre LDAP, htpasswd, etc). * par défaut la base ne contient pas de données purement "système" : ces données (comme le shell, la homedir, etc) sont calculées par les backend, éventuellement en fonction de conditions locales (exemple: homedir du type /home/a/n/antoine). * un mecanisme de champ "extra" permet d'étendre les tables en associant des variables à un utilisateur, un groupe ou autre (merci JérômeSantini pour cette chouette idée) * la gestion des organismes d'appartenance est hierarchisée (par exemple université->faculté->département). Ainsi, si une personne est de tel département, on sait qu'elle est aussi de telle fac et de telle université. |
Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs. |
| Ligne 12: | Ligne 4: |
| = Base = | attachment:base_utilisateurs_campus.png |
| Ligne 14: | Ligne 6: |
| == Table utilisateurs == | Version UML (Très Basique) [http://tedia2sql.tigris.org/usingtedia2sql.html http://tedia2sql.tigris.org/usingtedia2sql.html] |
| Ligne 16: | Ligne 8: |
| * '''id''' * '''login''' * '''mot_de_passe''' * '''courriel''' * '''nom''' * '''prénom''' * '''genre''' * '''date_naissance''' * '''adresses''' * '''téléphones''' * '''id_organisme''' * '''fonction''' * '''commentaires''' |
Exemple génération SQL: {{{ tedia2sql -t postgres -f -m -v1 -i ./base_utilisateurs_campus_uml.dia -o ./base_utilisateurs_campus.sql }}} |
| Ligne 30: | Ligne 13: |
| == Table utilisateurs_extra == | attachment:base_utilisateurs_campus_uml.png |
| Ligne 32: | Ligne 15: |
| * '''id_utilisateur''' : utilisateur concerné * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') * '''valeur''' |
les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia |
| Ligne 36: | Ligne 17: |
| == Table groupes == | les sources Dia du schéma UML : attachment:base_utilisateurs_campus_uml.dia |
| Ligne 38: | Ligne 19: |
| * '''id''' * '''nom''' * '''commentaires''' |
SQL généré pour PostgreSQL : attachment:base_utilisateurs_campus.sql |
| Ligne 42: | Ligne 21: |
| == Table groupes_extra == | = Les utilisateurs = |
| Ligne 44: | Ligne 23: |
| * '''id_groupe''' * '''variable''' * '''valeur''' |
Table utilisateurs:: . id . login . mot_de_passe . courriel . nom_complet . nom . prénom . genre . date_naissance . commentaires |
| Ligne 48: | Ligne 35: |
| == Table abonnements == | 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: |
| * '''id_utilisateur''' * '''id_groupe''' * '''date_debut''' * '''date_fin''' * '''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.) . 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é. . TN : parce que ça serait bien dommage de s'en priver, et que y'a toujours des cas particuliers à gérer... Ne serait-ce que pour les mails @auf.org (on a tous deux adresses : @XX.auf.org et @auf.org) |
| Ligne 56: | Ligne 46: |
| == Table organismes == | = Les groupes = |
| Ligne 58: | Ligne 48: |
| * '''id''' * '''nom''' * '''adresses''' * '''telephones''' * '''id_parent''' : pointe vers un id_organisme (0 pour la racine) * '''commentaires''' |
Table groupes:: . id . nom . commentaires |
| Ligne 65: | Ligne 53: |
| == Table organismes_extra == | Table groupes_extra:: . id_groupe . variable . valeur |
| Ligne 67: | Ligne 58: |
| * '''id_organisme''' * '''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.)
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é.
- TN : parce que ça serait bien dommage de s'en priver, et que y'a toujours des cas particuliers à gérer... Ne serait-ce que pour les mails @auf.org (on a tous deux adresses : @XX.auf.org et @auf.org)
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