Discussion :

[CinePhil]

Bonjour,

Soit une entité Utilisateur. Ceux-ci peuvent être de 3 types (Étudiant, Gestionnaire, Administrateur) ayant chacun des droits différents sur les fonctions du logiciel.

Le MCD donne donc ceci :

Utilisateur -1,1----Typer----0,n- Type_Utilisateur -0,n----Accéder----0,n- Fonction

Maintenant, seul le type Étudiant a un attribut différent et des associations avec d'autres entités. Je suis donc tenté de faire un seul héritage :
Etudiant -(1,1)----Etre----0,1- Utilisateur -1,1----Typer----0,n- Type_Utilisateur -0,n----Accéder----0,n- Fonction

Est-ce correct de conserver le Type_Utilisateur alors que pour l'étudiant on le connaît et de ne pas faire figurer les deux autres types d'utilisateur en héritage, lesquels seraient des entités vides d'attributs ?

Pour ce projet je modélise en UML et la tendance "naturelle" irait plutôt dans le sens des 3 héritages, ce qui voudrait dire aussi 3 associations avec les fonctions et ça me semble plus lourd et redondant.

[Oishiiii]

Bonjour,

Utilisateur -1,1----Typer----0,n- Type_Utilisateur -0,n----Accéder----0,n- Fonction

Si les types d'utilisateurs n'avaient pas de spécifités (aucun attribut supplémentaire) ce MCD conviendrait, sinon c'est de l'héritage.

Maintenant, seul le type Étudiant a un attribut différent et des associations avec d'autres entités. Je suis donc tenté de faire un seul héritage :
Etudiant -(1,1)----Etre----0,1- Utilisateur -1,1----Typer----0,n- Type_Utilisateur -0,n----Accéder----0,n- Fonction

En descendant au MLD, MPD, SQL, la clé primaire de la table Type_Utilisateur apparaîtra dans la table Utilisateur.
Si l'utilisateur est un étudiant on en sera informé deux fois; une fois dans la table Utilisateur et une fois dans la table Etudiant. Ça n'est pas "terrible".

Est-ce correct de conserver le Type_Utilisateur alors que pour l'étudiant on le connaît et de ne pas faire figurer les deux autres types d'utilisateur en héritage, lesquels seraient des entités vides d'attributs ?

Moi je ferai du simple héritage, il est tout a fait possible d'avoir des entités "enfant" sur un héritage qui n'ont pas d'attributs. Ce n'est pas choquant.

Pour ce projet je modélise en UML et la tendance "naturelle" irait plutôt dans le sens des 3 héritages, ce qui voudrait dire aussi 3 associations avec les fonctions et ça me semble plus lourd et redondant.

Ça ne me semble ni lourd ni redondant, mais justifié.

[pfortin]

Bonjour,

De toute façon, les 2 solutions sont réalistes.

Mais je suis du même avis que Oishiiii :
La prudence pousse à créer les 3 tables. Ca semble être l'alternative la plus pérenne.
Il arrive souvent que des attributs apparaissent tardivement (évolution du besoin, oubli).
Le fait de créer ces entités spécialisées prépare l'avenir.

Cordialement,

[fsmrel]

Hello,

Je me garderai de donner un avis péremptoire, mais je propose une réflexion sur le problème posé.

Supposons que la solution de l’héritage soit retenue. Quels problèmes se posent quand au lieu de trois types d’utilisateurs, tout à coup on vous annonce qu’il y en a une quinzaine ? J’ai vécu cela (dans le monde de l’assurance), alors que selon le dossier de conception, il y avait trois types d’intervenants dans un sinistre : disons l’assuré, le tiers et je ne sais plus quel autre intervenant (ma mémoire est infidèle, mais cela se passait il y a vingt ans...) En tout cas, un beau jour, la typologie des intervenants fut « enrichie » d’une douzaine d’intervenants secondaires, tels que le témoin, le voleur de passage, l’ambulancier, le pompier, le commissaire, etc. Madame Merise faillit en faire une dépression, car elle était partie bille en tête pour mettre en oeuvre autant de sous-types (on aurait dû lui parler d’abord de l’heuristique du Papou : Comment comptent les Papous ? Réponse : un, deux, beaucoup....) La solution mise en place fut bâtarde, mais fonctionna : on conserva le surtype Intervenant ainsi que les sous-types principaux. Pour le reste, on se contenta de définir un sous-type Intervenant secondaire :

Intervenant ---0,1-- (relation d’héritage) --1,1--Intervenant secondaire -1,1----Typer----0,n- Type Intervenant

Le sous-type Intervenant secondaire était simplement doté d’un attribut de type Bloc-notes qui permettait à l’utilisateur d’y consigner ce qu’il voulait.

Est-ce correct de conserver le Type_Utilisateur alors que pour l'étudiant on le connaît et de ne pas faire figurer les deux autres types d'utilisateur en héritage, lesquels seraient des entités vides d'attributs ?

En relation avec ce qui précède, je dirais que si le sous-type Etudiant se justifie, on le met en œuvre, mais pour éviter les redondances (sous-type Etudiant et rôle Etudiant), vous pourriez peut-être aussi définir un deuxième sous-type du genre Utilisateur_Autre (correspondant à l’intervenant secondaire ci-dessus), en relation avec Type_Utilisateur (cette entité-type ne concernant donc que les rôles 'gestionnaire' et 'administrateur').

En descendant au MLD, MPD, SQL, la clé primaire de la table Type_Utilisateur apparaîtra dans la table Utilisateur.
Si l'utilisateur est un étudiant on en sera informé deux fois; une fois dans la table Utilisateur et une fois dans la table Etudiant. Ça n'est pas "terrible".

Pourquoi voulez-vous que le type de l’utilisateur apparaisse en tant qu’attribut dans la table Etudiant ?

Il arrive souvent que des attributs apparaissent tardivement (évolution du besoin, oubli).
Le fait de créer ces entités spécialisées prépare l'avenir.

Il est vrai qu'au cours de la vie des bases de données, des attributs apparaissent tardivement. Maintenant, que faire s'il s’agit d’une rafale de sous-types ? (cf. la mésaventure de Madame Merise...) Je reconnais que ça n’est pas fréquent, mais il est bon de réfléchir à une telle éventualité.

[CinePhil]

J'attendais la réponse du grand expert fsmrel pour répondre...

Dans le cas présent, il s'agit d'une (future) application qui a un périmètre précis mais dont des parties pourraient dans l'avenir être réutilisées pour des applications similaires, à tel point qu'on pense rendre le plus indépendant possible une fonction ouverte à l'étudiant.

Pour être plus précis, il s'agit pour le moment d'une application qui permettra à des étudiants admis à un concours de s'inscrire à un stage parmi une liste de stages proposés. Mais ce principe d'inscription pourrait tout aussi bien être appliqué à un cours à la carte, une conférence, un colloque... Donc effectivement, il est possible que les futures applications dérivées de celle-ci voient apparaître de nouveaux types d'utilisateurs (chercheurs, intervenants, professeurs...).

Il en résulte que je vais creuser l'idée de fsmrel de faire un 'Utilisateur_Autre' qui sera typé.

L'idée serait donc dans l'avenir de ne spécialiser de nouveaux types d'utilisateurs que s'ils ont des attributs et/ou des associations différentes des utilisateurs généraux.

Encore une fois, merci François et bien le bonjour à Madame Merise !

[f-leb]

bonjour à tous,

En relation avec ce qui précède, je dirais que si le sous-type Etudiant se justifie, on le met en œuvre, mais pour éviter les redondances (sous-type Etudiant et rôle Etudiant), vous pourriez peut-être aussi définir un deuxième sous-type du genre Utilisateur_Autre (correspondant à l’intervenant secondaire ci-dessus), en relation avec Type_Utilisateur (cette entité-type ne concernant donc que les rôles 'gestionnaire' et 'administrateur').

Sauf qu’il faut bien indiquer les fonctions accessibles à chaque type d’utilisateur, y compris l’étudiant , non ?:
Type_Utilisateur---0,n---accéder---0,n---Fonction

Mais en conservant ainsi les trois rôles dans Type_Utilisateur, dans le bout de schéma :
Utilisateur_Autre---1,1---typer---0,n---Type_Utilisateur
Il faudrait alors prendre garde que l’utilisateur autre ne puisse référencer le type 'étudiant' …

[fsmrel]

J'attendais la réponse du grand expert fsmrel pour répondre...
[...]et bien le bonjour à Madame Merise !

Je me doutais que vous attendiez une réponse... Il manque quand même celle de JPhi33.
Ne me considérez pas comme un grand expert de la modélisation Merise, mais plutôt comme un vieux cyclotouriste avec des sacoches accrochées à son vélo pleines de souvenirs...
Il y a des lustres que je n’ai pas vu Madame Merise, mais si je la croise un jour, je lui ferai volontiers une bise de votre part.

Sauf qu’il faut bien indiquer les fonctions accessibles à chaque type d’utilisateur, y compris l’étudiant, non ?:
Type_Utilisateur---0,n---accéder---0,n---Fonction

Je suppose que CinePhil a son idée à ce sujet. Mais en attendant :

Étant donné que — pour les raisons de redondance signalées (sous-type Etudiant et rôle Etudiant) — je propose que le rôle 'étudiant' ne soit pas une occurrence de l’entité-type Type_Utilisateur, l’association-type Accéder ne permet de connaître que les fonctions accessibles aux seuls administrateurs et gestionnaires.

A CinePhil maintenant de préciser son besoin. Si l’ensemble des fonctions pouvant être exercées par les étudiants est disjoint de l’ensemble des fonctions exercées par les administrateurs et des gestionnaires, une entité-type FonctionEtudiant est à définir. Si ces fonctions ne sont pas disjointes, on peut définir une entité-type FonctionEtudiant qui serait sous-type de l’entité-type Fonction et qui correspondrait aux fonctions exercées par les seuls étudiants. Pour des raisons de symétrie, on pourrait se soucier des fonctions ne pouvant pas être exercées par les étudiants. A creuser...

[JPhi33]

Bonsoir à tous,

J'ai à peu près la même vision que vous tous de ce problème.

Pour résumer, nous avons une population d'utilisateurs dont 3 ont un type bien défini (Étudiant, Gestionnaire, Administrateur), un seulement est spécialisé (Étudiant) et tous les autres sont non typés, leur type étant inconnu aujourd'hui, mais candidats à l'être, voire candidats à être spécialisés. Selon la formule consacrée, c'est l'avenir qui nous le dira !

L'enjeu du problème est donc de préparer ces futures évolutions du S.I. afin de ne pas subir les déboires relatés par fsmrel. CinePhil ayant déjà identifié des types émergents (chercheurs, intervenants, professeurs, ...), on n'est pas dans de la pure fiction.


Sur les types
Chaque utilisateur identifié dans le système doit-il être typé ? Je dirais que CinePhil a le choix :

[ Utilisateur ]--x,1----( )----0,n->[ Type_Utilisateur ]

x=0, évite de s'obliger à typer des utilisateurs sans type. Si x=1, il faut créer un type "Autre" ou "Inconnu".
Dans un cas comme dans l'autre, la particularité de gestion est la "promotion" d'un utilisateur banal en utilisateur typé :
- si x=0, on lui rattache le Type_Utilisateur approprié
- si x=1, on modifie son Type_Utilisateur (de "Autre" à celui qui convient)

A noter que ceci n'a pas d'incidence sur :

[ Type_Utilisateur ]--0,n----(accéder)----0,n--[ Fonction ]

Il suffit d'associer 0 Fonction au type "Autre".


Sur les spécialisations
On est plutôt habitué à traiter ce genre de spécialisations :


ce qui correspond au diagramme :

dans lequel les X représentent les occurrences des entités. On remarque qu'il n'existe aucune occurrence dans l'entité GENERALISATION hormis celles contenues dans SPECIALISATION1 et SPECIALISATION2. Autrement dit, toute occurrence de GENERALISATION est soit occurrence de SPECIALISATION1, soit occurrence de SPECIALISATION2.


Ici, le type de spécialisation auquel on est confronté se représente par le diagramme :

dans lequel on constate :
- que les utilisateurs non spécialisés appartiennent à l'entité généralisée Utilisateur
- que parmi les utilisateurs non spécialisés, on distingue des types différents (occurrences en rouge, bleu et vert, par exemple : les gestionnaires, les administrateurs et les chercheurs) et des utilisateurs sans type (occurrences en noir)

ce qui se traduit par le MCD :


Il n'est donc pas nécessaire de créer un sous-type Utilisateur_Autre dans la mesure où ces utilisateurs sont ceux appartenant à l'entité Utilisateur sans appartenir à l'entité Etudiant.


Si une population d'utilisateurs (non étudiants) se spécialise, par apparition de propriétés ou d'associations spécifiques, il est toujours temps de créer une nouvelle entité spécialisée qui l'accueillera. Techniquement, après création de la table, l'opération se résumera à un ensemble d'INSERT portant sur les lignes de la table Utilisateur sélectionnées d'après leur type (restera quand même à valoriser le spécifique, attributs ou clés étrangères).

[CinePhil]

Je suis globalement d'accord avec tout ce que tu dis JPhi33.

Juste un détail :

Sur les types
Chaque utilisateur identifié dans le système doit-il être typé ? Je dirais que CinePhil a le choix :

[ Utilisateur ]--x,1----( )----0,n->[ Type_Utilisateur ]

x=0, évite de s'obliger à typer des utilisateurs sans type. Si x=1, il faut créer un type "Autre" ou "Inconnu".
Dans un cas comme dans l'autre, la particularité de gestion est la "promotion" d'un utilisateur banal en utilisateur typé :
- si x=0, on lui rattache le Type_Utilisateur approprié
- si x=1, on modifie son Type_Utilisateur (de "Autre" à celui qui convient)

A noter que ceci n'a pas d'incidence sur :

[ Type_Utilisateur ]--0,n----(accéder)----0,n--[ Fonction ]

Il suffit d'associer 0 Fonction au type "Autre".

Comme chaque type d'utilisateur aura accès à certaines fonctions du logiciel et pas à d'autres, je pense que je suis obligé de typer chaque utilisateur. Mais à partir du moment où un utilisateur devient spécialisé, il perd son type puisque celui-ci est déterminé par son appartenance à une spécialisation.
Ainsi, dans ma première application, gestionnaires et administrateurs seraient typés et étudiant ne le serait que par son existence au sein de l'entité-type fille (tu vois François, je fais des efforts sur le vocabulaire Merisien ) des étudiants.
Dès lors, pour savoir à quelles fonctions du logiciel un étudiant aura accès, il faut associer Etudiant et Fonction.
Par la suite, au fur et à mesure que mes utilisateurs vont se spécialiser, j'aurai autant d'associations 'Accéder' que de spécialisations + 1 pour les utilisateurs non spécialisés. Correct ?

[JPhi33]

Mais à partir du moment où un utilisateur devient spécialisé, il perd son type puisque celui-ci est déterminé par son appartenance à une spécialisation.

Je me rends compte que je n'ai pas été assez précis dans mon explication.

Ce que je voulais dire c'est que, à mon avis, chaque utilisateur doit être typé (étudiant, gestionnaire, administrateur, chercheur, etc.) sauf les utilisateurs dont le type est inconnu et pour lesquels tu as le choix entre les cardinalités 0,1 et 1,1 (côté Utilisateur de l'association avec Type_Utilisateur) :
0,1 ---> les utilisateurs dont le type est inconnu ne sont pas liés à Type_Utilisateur
1,1 ---> les utilisateurs dont le type est inconnu ont le type "Autre" (ou "Inconnu"). Personnellement, je préfère cette alternative.

Dans la vision que j'ai de ce problème, le type n'est pas déterminé par l'appartenance à une entité spécialisée. Par conséquent, il n'est pas question qu'un utilisateur typé ("chercheur", par exemple) devenant spécialisé (parce qu'on crée l'entité spécialisée Chercheur) perde sont type. Pourquoi ?

Parce qu'associer chaque entité spécialisée avec Type_Utilisateur est une redondance sémantique et, à ce titre, doit être éliminée. Une analogie avec les propriétés permet de l'expliquer.

A partir du moment où l'on est dans une démarche de généralisation-spécialisation, une même propriété se trouvant dans les entités spécialisées doit être "factorisée" : elle disparaît des entités spécialisées pour se retrouver dans l'entité généralisée. Pour les associations, c'est la même chose. Par conséquent, les associations "accéder" des entités spécialisées doivent subir la même démarche de généralisation et disparaître au profit d'une seule association "accéder" dans l'entité générale.

Nous avons donc maintenant deux associations "accéder" :

(1) [ Utilisateur ]--1,1----(accéder)----0,n->[ Fonction ]
(2) [ Type_Utilisateur ]--1,1----(accéder)----0,n->[ Fonction ]

La question à se poser est : Est-ce l'utilisateur ou le type d'utilisateur qui accède à une fonction ? La réponse est donnée dans l'énoncé et aboutit à l'élimination de l'association (1).

[CinePhil]

C'était mon idée de modélisation au départ mais si j'ai correctement interprété sa pensée, ce n'est pas l'avis de fsmrel qui, il me semble, dit au contraire que les utilisateurs spécialisés sont typés de fait par leur spécialisation et n'ont pas à être typés en plus par un type_utilisateur.

C'était l'objet de mon premier message et je vois que les avis sont partagés sur la question !

Ce qui est sûr, c'est que je n'aurai pas d'utilisateur de type inconnu. Ils seront tous typés d'une manière ou d'une autre, ne serait-ce, dans une future application dérivée de celle qui m'occupe actuellement, qu'en tant que visiteur (donc typés 'visiteur').

Merci en tous cas pour ces réponses détaillées.

[fsmrel]

tu vois François, je fais des efforts sur le vocabulaire Merisien

Bravo ! mais l’adjectif associé au nom vocabulaire n’a pas droit à la majuscule...

C'était mon idée de modélisation au départ mais si j'ai correctement interprété sa pensée, ce n'est pas l'avis de fsmrel qui, il me semble, dit au contraire que les utilisateurs spécialisés sont typés de fait par leur spécialisation et n'ont pas à être typés en plus par un type_utilisateur.

En effet, soyons parcimonieux. La redondance est la source de bien des erreurs dans le contenu des bases de données si on n’impose pas au SGBD une vigilance de tous les instants (triggers et tout le toutim). Ce ne sont pas des contrôles au sein des programmes qui peuvent assurer cette vigilance permanente, car il n’est pas rare que l’on exécute des requêtes ou que l’on passe par des utilitaires sans demander leur avis aux programmes en question...