|
Taille: 2257
Commentaire:
|
Taille: 2207
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 == | les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia |
| Ligne 16: | Ligne 8: |
| * '''id''' * '''login''' * '''mot_de_passe''' * '''courriel''' * '''nom''' * '''prénom''' * '''genre''' * '''date_naissance''' * '''adresses''' * '''téléphones''' * '''id_organisme''' * '''fonction''' * '''commentaires''' |
= Les utilisateurs = |
| Ligne 30: | Ligne 10: |
| == Table utilisateurs_extra == | Table utilisateurs:: . id . login . mot_de_passe . courriel (Tini voudrait le sortir d'ici et le passer en champ extra... mais... je sais pas, qu'en pensez-vous ?) . nom_complet . nom . prénom . genre . date_naissance . commentaires |
| Ligne 32: | Ligne 22: |
| * '''id_utilisateur''' : utilisateur concerné * '''variable''' : nom de la variable (par exemple : ''courriel_alias'', ''homedir'') * '''valeur''' |
Table utilisateurs_extra:: . id_utilisateur : utilisateur concerné . variable : nom de la variable (par exemple : ''courriel_alias'', ''homedir'', ''adresse'', ''téléphone'') . valeur |
| Ligne 36: | Ligne 27: |
| == Table groupes == | = Les groupes = |
| Ligne 38: | Ligne 29: |
| * '''id''' * '''nom''' * '''commentaires''' |
Table groupes:: . id . nom . commentaires |
| Ligne 42: | Ligne 34: |
| == Table groupes_extra == | Table groupes_extra:: . id_groupe . variable . valeur |
| Ligne 44: | Ligne 39: |
| * '''id_groupe''' * '''variable''' * '''valeur''' |
= Les abonnements = |
| Ligne 48: | Ligne 41: |
| == Table abonnements == | Un abonnement signifie qu'on place un utilisateur dans un groupe pendant un certain laps de temps. Un drapeau "interruption" permet de signaler si l'abonnement est momentannément interrompu (idée de SebastienDornano). |
| Ligne 50: | Ligne 43: |
| * '''id_utilisateur''' * '''id_groupe''' * '''date_debut''' * '''date_fin''' * '''commentaires''' |
Table abonnements:: . id_utilisateur . id_groupe . date_debut . date_fin . interruption : mis à ''vrai'' si l'abonnement est interrompu temporairement . commentaires |
| Ligne 56: | Ligne 51: |
| == Table organismes == | = Les organismes = |
| Ligne 58: | Ligne 53: |
| * '''id''' * '''nom''' * '''adresses''' * '''telephones''' * '''id_parent''' : pointe vers un id_organisme (0 pour la racine) * '''commentaires''' |
Ils sont hiérarchisés (arbre simple : un parent peu avoir plusieurs fils). |
| Ligne 65: | Ligne 55: |
| == Table organismes_extra == | Table organismes:: . id . nom . adresses . telephones . id_organisme_parent : pointe vers un id_organisme (0 pour la racine) . commentaires |
| Ligne 67: | Ligne 63: |
| * '''id_organisme''' * '''variable''' * '''valeur''' |
Table organismes_extra (utilité à trouver):: . 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 organisme. Table fonction:: . id . nom . commentaires Table fonction_extra (utilité à trouver):: . id_fonction . variable . valeur Table utilisateur_organisme_fonction:: . id_utilisateur . id_organisme . id_fonction . commentaires |
Voici ma (ThomasNoël) proposition pour le schéma de la BD de gestion des utilisateurs.
- attachment:base_utilisateurs_campus.png
les sources Dia de ce schéma : attachment:base_utilisateurs_campus.dia
Les utilisateurs
- Table utilisateurs
- id
- login
- mot_de_passe
- courriel (Tini voudrait le sortir d'ici et le passer en champ extra... mais... je sais pas, qu'en pensez-vous ?)
- 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
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. Un drapeau "interruption" permet de signaler si l'abonnement est momentannément interrompu (idée de SebastienDornano).
- Table abonnements
- id_utilisateur
- id_groupe
- date_debut
- date_fin
interruption : mis à vrai si l'abonnement est interrompu temporairement
- commentaires
Les organismes
Ils sont hiérarchisés (arbre simple : un parent peu 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 (utilité à trouver)
- 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 organisme.
- Table fonction
- id
- nom
- commentaires
- Table fonction_extra (utilité à trouver)
- id_fonction
- variable
- valeur
- Table utilisateur_organisme_fonction
- id_utilisateur
- id_organisme
- id_fonction
- commentaires