Discussion :

[dorian53]

Bonjour,

Contexte
Un utilisateur peut être une personne dans le système d'information mais pas obligatoirement.
L'utilisateur est le compte informatique avec identifiant, mot de passe...

Une personne peut être un utilisateur dans le système d'information mais pas obligatoirement.
La personne est une simple donnée du SI à laquelle sont rattachées d'autres données de la solution de gestion.

L'identité permet de partager les informations suivantes : nom, prénom, email, ...

Question
Conceptuellement, comment garantir que les deux entités "enfant" liées héritent bien du même parent ?



Merci,
Dorian

[fsmrel]

Bonsoir Dorian,


Selon votre diagramme, une identité est soit un utilisateur, soit une personne qui n’est pas un utilisateur.

La question que vous posez est ambiguë. Pourriez-vous illustrer avec deux ou exemples d’acteurs de ce système ?

Que cherchez-vous à exprimer par le lien entre UTILISATEUR et PERSONNE ?

[dorian53]

Bonsoir Dorian,

Bonjour fsmrel,

Selon votre diagramme, une identité est soit un utilisateur, soit une personne qui n’est pas un utilisateur.

Ce sont plutôt UTILISATEUR et PERSONNE qui portent une fk vers IDENTITE.

La question que vous posez est ambiguë. Pourriez-vous illustrer avec deux ou exemples d’acteurs de ce système ?

Un exemple détaché de mon contexte réel.

Le SI référence 900 étudiants d'un établissement, ils sont tous enregistrés dans PERSONNE qui hérite de IDENTITE.
Parmi les 900 d'étudiant, seuls 5 peuvent se connecter à la solution, les 5 sont enregistrés dans UTILISATEUR qui hérite aussi de IDENTITE.

Que cherchez-vous à exprimer par le lien entre UTILISATEUR et PERSONNE ?

Que les 5 étudiants dans UTILISATEUR (qui se connectent à la solution) correspondent aussi à 5 des 900 étudiants dans PERSONNE (au niveau métier).


En espérant que cela permette de mieux de comprendre.

[fsmrel]

Bonsoir Dorian,

Ce sont plutôt UTILISATEUR et PERSONNE qui portent une fk vers IDENTITE.

Le concept de clé étrangère (fk) se situe au niveau relationnel, mais votre diagramme se situe à un autre niveau, c’est un diagramme de classes, selon lequel une identité est formellement soit un utilisateur, soit une personne qui n’est pas un utilisateur. Par défaut, les sous-classes sont exclusives, s’il y a chevauchement il faut le préciser :





Cela dit, il n’y a pas contradiction entre ces deux niveaux : UTILISATEUR et PERSONNE sont des sous-classes d’IDENTITE, et une dérivation sous forme tabulaire (disons SQL) donnera lieu aux tables UTILISATEUR et PERSONNE, chacune dotée d’une clé étrangère faisant référence à la table IDENTITE.

Les 5 étudiants dans UTILISATEUR (qui se connectent à la solution) correspondent aussi à 5 des 900 étudiants dans PERSONNE.

Le diagramme peut évoluer ainsi :

Un utilisateur correspond à exactement une personne, et une personne correspond parfois à un utilisateur :

Mais on peut aussi avoir la représentation suivante, selon laquelle un utilisateur est une personne spécialisée :





Et pourquoi ne pas fondre PERSONNE et IDENTITE ?





Au stade SQL, cette fusion donnerait :

CREATE TABLE PERSONNE
(
        psn_id                INT              NOT NULL
      , psn_nom               VARCHAR(32)      NOT NULL
      , psn_prenom            VARCHAR(32)      NOT NULL
      , psn_adr_courriel      VARCHAR(64)      NOT NULL
    , CONSTRAINT PERSONNE_PK PRIMARY KEY (psn_id)      
) ;

CREATE TABLE UTILISATEUR
(
        utilisateur_id                INT              NOT NULL
      , utilisateur_login             VARCHAR(32)      NOT NULL
      , utilisateur_mot_de_passe      VARCHAR(32)      NOT NULL
    , CONSTRAINT UTILISATEUR_PK PRIMARY KEY (utilisateur_id)
    , CONSTRAINT UTILISATEUR_PERSONNE_FK FOREIGN KEY (utilisateur_id)
          REFERENCES PERSONNE (psn_id) ON DELETE CASCADE 
) ;

Un début de jeu d’essai :

INSERT INTO PERSONNE (psn_id, psn_nom, psn_prenom, psn_adr_courriel) VALUES
  (1, 'Naudin', 'Fernand', 'fernandnau@flingueurs.fr') 
, (2, 'Volfoni', 'Raoul', 'rvolfoni@citron.fr') 
, (3, 'Volfoni', 'Paul', 'paulovolfoni@flingueurs.fr') 
, (4, 'Champo', 'Maurice', 'momo@patate.fr') 
, (5, 'Trancène', 'Jean', 'jeantranc@navets.fr') 
, (6, 'Mavallée', 'Colette', 'cmavallee@pamplemousse.fr') 
, (7, 'Mavallée', 'Berthe', 'bmavallee@pamplemousse.fr') 
;  

INSERT INTO UTILISATEUR (utilisateur_id, utilisateur_login, utilisateur_mot_de_passe) VALUES
  (1, 'fernau', '************') 
, (2, 'ravolf', '************') 
, (3, 'paulo', '************') 
;

Pour le confort du développeur, une vue permettant de visualiser les utilisateurs :

CREATE VIEW UTILISATEUR_V (id, nom, prenom, adr_courriel, login, mot_de_passe) 
AS 
    SELECT psn_id, psn_nom, psn_prenom, psn_adr_courriel, utilisateur_login, utilisateur_mot_de_passe
    FROM   PERSONNE JOIN UTILISATEUR ON psn_id = utilisateur_id
;

Utilisation de la vue :

SELECT * FROM UTILISATEUR_V ;

Au résultat :

id     nom        prenom    adr_courriel                  login     mot_de_passe
--     -------    ------    --------------------------    ------    ------------
1      Naudin     Fernand   fernandnau@flingueurs.fr      fernau    ************
2      Volfoni    Raoul     rvolfoni@citron.fr            ravolf    ************
3      Volfoni    Paul      paulovolfoni@flingueurs.fr    paulo     ************

A l'occasion, vous pouvez voter pour les messages qui ont pu vous apporter une aide...

[dorian53]

Bonjour fsmrel,

Le diagramme peut évoluer ainsi :

Un utilisateur correspond à exactement une personne, et une personne correspond parfois à un utilisateur :

Je suis d'accord avec ce diagramme.

Mais on peut aussi avoir la représentation suivante, selon laquelle un utilisateur est une personne spécialisée :

Dans mon contexte, un UTILISATEUR peut ne pas être un étudiant (PERSONNE), donc cette représentation n'irait pas.

Et pourquoi ne pas fondre PERSONNE et IDENTITE ?

Un peu pour la même raison, PERSONNE a vraiment un sens métier avec plusieurs associations vers d'autres entités et un UTILISATEUR peut être juste quelqu'un qui utilise la solution sans faire partie du SI dans PERSONNE.


Au final, la première représentation semble bien celle qui correspond le mieux au besoin avec la problématique initiale : conceptuellement, comment garantir que les deux entités "enfant" liées héritent bien du même parent ?
Est-ce qu'il n'y a pas de solution, est-ce au code métier de s'en assurer ?

Merci pour ta contribution.
Dorian

[Luckyluke34]

Bonjour,

Pourquoi un héritage entre Utilisateur/Personne et Identité et pas une simple composition ?

Je n'ai pas très bien compris si on parle de modèle objet ou de modèle de données, mais quand on crée des abstractions, on a trop souvent tendance à faire de rapides assimilations superficielles sans se demander comment les concepts vont évoluer. Est-ce que l'identité d'une personne et d'un utilisateur sont une seule et même notion ? Ne risquent-ils pas d'évoluer différemment, au risque d'introduire des champs qui ne seront pas remplis dans un cas, et donc d'embrouiller le code avec des branchements conditionnels ?

A partir du moment où on ne mutualise pas un comportement mais juste des données comme ça semble être le cas, on peut se demander s'il y a un réel bénéfice. Celui-ci se constate essentiellement lors du renommage/ajout/retrait de champs qui évite effectivement de modifier le code à deux endroits, mais est-ce un effort si important par rapport au risque de mal identifier et assimiler deux concepts différents ?

[fsmrel]

Bonsoir,

Dans mon contexte, un UTILISATEUR peut ne pas être un étudiant (PERSONNE), donc cette représentation n'irait pas.

Ah ! Voilà qui change la donne ! Mais dans le diagramme ci-dessous, un utilisateur correspond au moins et au plus une personne, ce qui est en contradiction avec la règle que vous venez de fournir :





Il faut donc revoir la modélisation. On peut partir sur la base d’un diagramme de classes dans lequel on met en évidence les utilisateurs qui sont des étudiants :






Diagramme relationnel correspondant :





Code SQL :

CREATE TABLE IDENTITE (
   identite_id                Int                  Not null,
   identite_nom               Varchar(32)          Not null,
   identite_prenom            Varchar(32)          Not null,
   identite_adr_courriel      Varchar(64)          Not null,
   CONSTRAINT IDENTITE_PK PRIMARY KEY (identite_id)
) ;

CREATE TABLE PERSONNE (
   personne_id              Int                  Not null,
   CONSTRAINT PERSONNE_PK PRIMARY KEY (personne_id),
   CONSTRAINT PERSONNE_IDENTITE_FK FOREIGN KEY (personne_id)
      REFERENCES IDENTITE (identite_id)
) ; 
CREATE TABLE UTILISATEUR (
   utilisateur_id             Int                  Not null,
   utilisateur_login          Varchar(32)          Not null,
   utilisateur_mot_de_passe   Varchar(32)          Not null,
   CONSTRAINT UTILISATEUR_PK PRIMARY KEY (utilisateur_id),
   CONSTRAINT UTILISATEUR_AK UNIQUE (utilisateur_login),
   CONSTRAINT UTILISATEUR_IDENTITE_FK FOREIGN KEY (utilisateur_id)
      REFERENCES IDENTITE (identite_id)
) ; 
CREATE TABLE UTILISATEUR_ETUDIANT (
   utilisateur_id             Int                  Not null,
   CONSTRAINT UTILISATEUR_ETUDIANT_PK PRIMARY KEY (utilisateur_id),
   CONSTRAINT UTILISATEUR_ETUDIANT_PERSONNE_FK FOREIGN KEY (utilisateur_id)
      REFERENCES PERSONNE (personne_id),
   CONSTRAINT UTILISATEUR_ETUDIANT_UTILISATEUR_FK FOREIGN KEY (utilisateur_id)
      REFERENCES UTILISATEUR (utilisateur_id)
) ;

CREATE TABLE UTILISATEUR_NON_ETUDIANT (
   utilisateur_id             Int                  Not null,
   CONSTRAINT UTILISATEUR_NON_ETUDIANT_PK PRIMARY KEY (utilisateur_id),
   CONSTRAINT UTILISATEUR_NON_ETUDIANT_UTILISATEUR_FK FOREIGN KEY (utilisateur_id)
      REFERENCES UTILISATEUR (utilisateur_id)
) ;

conceptuellement, comment garantir que les deux entités "enfant" liées héritent bien du même parent ?
Est-ce qu'il n'y a pas de solution, est-ce au code métier de s'en assurer ?

Selon le diagramme de classes, on peut naviguer de IDENTITE vers PERSONNE en empruntant deux parcours :

(1) IDENTITE > PERSONNE ;

(2) IDENTITE > UTILISATEUR > UTILISATEUR_ETUDIANT > PERSONNE.

Ainsi, rien n’interdit que, partant de l’identité I1, on atteigne d’un côté la personne P1, et que de l’autre côté on atteigne la personne P2.

Au stade relationnel (donc SQL), selon le diagramme relationnel ci-dessus, si l’attribut utilisateur_id prend la valeur P1 (table UTILISATEUR_ETUDIANT) :

(3) Contrainte d’intégrité référentielle oblige, P1 (table UTILISATEUR_ETUDIANT) fait d’une part nécessairement référence à P1 (table PERSONNE), donc à P1 (table IDENTITE) ;

(4) P1 (table UTILISATEUR_ETUDIANT) fait d’autre part nécessairement référence à P1 (table UTILISATEUR), donc à P1 (table IDENTITE).

Il n’y a donc rien à programmer pour garantir la contrainte de chemin.

Par contre, la contrainte de partitionnement devra faire l’objet d’une contrainte d’exclusion (instruction CREATE ASSERTION, ou CREATE TRIGGER si le SGBD ne propose pas la 1re instruction).

[fsmrel]

Bonsoir à nouveau,

Pourquoi un héritage entre Utilisateur/Personne et Identité et pas une simple composition ?

Bien entendu, on peut étudier le scénario COMPOSITION : merci à vous de proposer le diagramme (de classes) qui va bien.