Discussion :

[jejerem]

Bonjour,

n'ayant pas beaucoup de connaissance sur la méthode Merise, je viens crier "HELP PLEASE" par ici !

Soit un MCD, ayant 3 entités : Utilisateur, Manager et Salarie.

J'aimerai modéliser une sorte de hiérarchie, mais je me perds sur les questions à poser pour définir les cardinalités entre ces entités.



Les questions que je me suis posées sont les suivantes :

• Combien d'Utilisateur peuvent-être Manager ? Au mini 0, au maxi N.
• Combien de Manager peuvent-être Utilisateur ? Au mini 0, au maxi N.
• Combien d'Utilisateur peuvent-être Salarie ? Au mini 0, au maxi N.
• Combien de Salarie peuvent-être Utilisateur ? Au mini 0, au maxi N.

Les questions en rouge me paraissent étrange, puisque un Salarie ou un Manager doit forcément être un Utilisateur.
Donc, est-ce que je me plante complétement sur ces questions ?


Merci d'avance pour le temps que vous prendrez.


Cordialement, Jejerem.

[fsmrel]

Bonsoir jejerem,

Pour dire qu’un manager est un utilisateur et qu’un salarié est aussi un utilisateur, vous devez en passer par la spécialisation de l’entité-type UTILISATEUR, comme dans le diagramme ci-dessous :

Cette fois-ci un manager est nécessairement un utilisateur et un salarié est nécessairement un utilisateur. Un utilisateur est soit un manager soit un salarié, soit un autre type d’utilisateur.

Les entités-types MANAGER et SALARIE héritent des propriétés de l’entité-type UTILISATEUR, représentées par les attributs UtilisateurId, UtilisateurNom, UtilisateurPrenom. Cet héritage est symbolisé par le triangle sur lequel viennent se brancher les entités-types.

La croix dans le triangle symbolise l’exclusion entre les entités-types spécialisées MANAGER et SALARIE, c'est-à-dire qu’un utilisateur ne peut pas être à la fois manager et salarié (ce qui laisse entendre qu’un manager n’a pas de salaire, et travaille donc pour des prunes...)

Si un utilisateur ne peut être que manager ou salarié, alors il faut ajouter une contrainte de totalité (ça sera une lettre T dans le triangle), ce qui donne un partitionnement (exclusion et totalité), ce qu’explique brillamment Pierre Dac : « Le monde des uns n’est pas celui des autres, bien que le monde des uns et des autres soit le monde de tout le monde ».

Si le Niveau d’un manager et celui d’un salarié sont de même nature, sémantiquement comparables, alors vous pouvez mettre en oeuvre une entité-type COLLABORATEUR, spécialisation de UTILISATEUR, porteuse de l’attribut Niveau et spécialisable à son tour en MANAGER et SALARIE.Voyez en l’occurrence l’exemple que je propose ici.

Vous utilisez vraisemblablement AnalyseSI : je ne me souviens pas qu’il permette de produire un diagramme comparable à celui que je vous ai proposé. Remplacez-le par JMerise (qui est en cours d’évolution).

Quant à votre diagramme, il dit notamment qu’un utilisateur peut « être » en même temps plusieurs managers et/ou salariés, ce qui évidemment n’a aucun sens (sauf peut-être dans un univers quantique...)

[CinePhil]

D'une manière générale, je vous renvoie sur mon article de blog sur les règles de gestion des données.

[jejerem]

Bonjour fsmrel,

merci pour vos explications, claires et précises.

Le fait qu'un manager n'ait pas de salaire ne pose pas de problème en soit.
Ceci dit, l'exemple donné, avec l'entité Collaborateur, représente mieux la réalité, d'autant plus que, comme vous l'avez souligné, le terme Niveau est en effet identique sémantiquement.

J'ai utiliser AnalyseSI pour le MCD, mais j'ai aussi DBMain. Je testerai JMerise bientôt.

En effet, je me disais bien qu'il y avait un problème !

Je me permet de prendre encore un peu de votre temps :

• J'utilise PostgreSQL, et la doc indique que le support de l'héritage est limité. Il y a t'il un moyen pour contourné ce problème (niveau MCD ou SQL, jointures ou autres) ?
• J'ai eu des retours négatifs sur l'utilisation de l'héritage en SQL. Mais n'ayant pas de connaissances sur le sujet je ne peux en dire plus. Avez-vous un avis sur la question ?

Je m'excuse d'avance si mes questions paraissent un peu bêtes. Mais je dois quand même les posées !

Encore une fois, merci pour votre temps.

EDIT : Bonjour CinéPhil. Merci pour votre lien. Un peu d'exercices ne me ferai pas de mal !

[CinePhil]

J'utilise PostgreSQL, et la doc indique que le support de l'héritage est limité. Il y a t'il un moyen pour contourné ce problème (niveau MCD ou SQL, jointures ou autres) ?

Je préfère ne pas utiliser l'héritage de PostgreSQL et le faire moi même.

Suite au schéma présenté par fsmrel, on aurait les tables suivantes :
utilisateur (UtilisateurId, UtilisateurNom, UtilisateurPrenom)
manager (manager_id_utilisateur, [autres colonnes spécifiques aux managers])
salarie (salarie_id_utilisateur, [autres colonnes spécifiques aux salariés])

Manager et salarie héritent de l'identifiant de l'utilisateur.

Ensuite, vous créez des vues qui permettent de reconstituer l'ensemble des données des managers et des salariés :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE OR REPLACE VIEW v_manager AS
SELECT u.utilisateurId AS managerId,
	u.utilisateurNom AS managerNom,
	u.utilisateurPrenom AS managerprenom,
	-- autres colonnes spécifiques aux managers
FROM manager m
INNER JOIN utilisateur u ON u.utilisateurId = m.manager_id_utilisateur

[jejerem]

Merci pour votre réponse.

Si je comprends bien, avec cette View, il est impossible d'avoir une PK dupliquée. C'est bien ça ? (Bon la question est certainement mal posée, je m'excuse.)

Je m'attèle à la conception d'un MCD en suivant l'exemple figurant dans le lien sur le post de fsmrel (avec les collaborateurs).


Je ne mets pas ce post en résolu pour l'instant et reviens vers vous bientôt.

Merci encore pour vos conseils.

Cordialement, Jejerem.

[CinePhil]

Si je comprends bien, avec cette View, il est impossible d'avoir une PK dupliquée.

On sort du domaine de la modélisation mais...
1) Par définition, une PK (Primary Key) ne peut pas être "dupliquée", si sous ce terme vous signifiez que la même valeur de PK peut être attribuée deux fois.
La clé primaire de la table Utilisateur sera référencée par la clé étrangère de la table manager et par celle de la table salarie. et ces clés étrangères seront elles-mêmes la clé primaire de leur table respective.

2) Une vue (VIEW) n'est qu'une requête enregistrée qui s'interroge comme une table.

[fsmrel]

Bonsoir jejerem et Philippe,

Je m'excuse d'avance si mes questions paraissent un peu bêtes.

On vous excuse d’office car vos questions sont pertinentes, et puis il vaut mieux paraître bête pendant 5 minutes que rester idiot toute sa vie (proverbe chinois) ^^

j'ai aussi DBMain

Concernant DB-MAIN, vous pouvez vous référer à ce que j’ai décrit ici concernant la façon de mettre en oeuvre l’héritage : j’y fais figurer les spécialisations CLIENT et FOURNISSEUR de l’entité-type TIERS.

J'utilise PostgreSQL

Ça tombe bien, voici le code SQL que j’avais généré pour quelques uns de mes tests :

CREATE TABLE SERVICE
(
        ServiceId            SERIAL        NOT NULL
      , ServiceCode          VARCHAR(8)    NOT NULL
     , ServiceLibelle        VARCHAR(32)   NOT NULL
    , CONSTRAINT SERVICE_PK PRIMARY KEY (ServiceId)
    , CONSTRAINT SERVICE_CODE_AK UNIQUE (ServiceCode)    
);

CREATE TABLE PERSONNE
(
        PersonneId           SERIAL        NOT NULL
      , PersonneCode         CHAR(8)       NOT NULL
      , AdresseCourriel      VARCHAR(64)   NOT NULL
    , CONSTRAINT PERSONNE_PK PRIMARY KEY (PersonneId)
    , CONSTRAINT PERSONNE_CODE_AK UNIQUE (PersonneCode)
    , CONSTRAINT PERSONNE_COURRIEL_AK UNIQUE (AdresseCourriel)
);

CREATE TABLE ADRESSE
(
        PersonneId           INT           NOT NULL
      , AdresseId            SERIAL        NOT NULL
      , AdresseLigne2        VARCHAR(64)   NOT NULL
      , AdresseLigne3        VARCHAR(64)   NOT NULL DEFAULT ''
      , AdresseLigne4        VARCHAR(64)   NOT NULL DEFAULT ''
      , AdresseCodePostal    VARCHAR(6)    NOT NULL
    , CONSTRAINT ADRESSE_PK PRIMARY KEY (PersonneId, AdresseId)
    , CONSTRAINT ADRESSE_PERSONNE_FK FOREIGN KEY (PersonneId)
          REFERENCES PERSONNE (PersonneId) ON DELETE CASCADE
);

CREATE TABLE TIERS
(
        PersonneId           INT           NOT NULL
      , NoSiret              CHAR(14)      NOT NULL
      , RaisonSociale        VARCHAR(64)   NOT NULL
    , CONSTRAINT TIERS_PK PRIMARY KEY (PersonneId)
    , CONSTRAINT TIERS_SIRET_AK UNIQUE (NoSiret)
    , CONSTRAINT TIERS_PERSONNE_FK FOREIGN KEY (PersonneId)
          REFERENCES PERSONNE (PersonneId) ON DELETE CASCADE	  
);

CREATE TABLE COLLABORATEUR
(
        PersonneId           INT           NOT NULL
      , ServiceId            INT           NOT NULL
      , Matricule            CHAR(8)       NOT NULL
      , NIR                  CHAR(13)      NOT NULL
      , Nom                  VARCHAR(32)   NOT NULL
      , Prenom               VARCHAR(32)   NOT NULL
      , DateEmbauche         DATE          NOT NULL
      , Salaire              INT           NOT NULL
    , CONSTRAINT COLLABORATEUR_PK PRIMARY KEY (PersonneId)
    , CONSTRAINT COLLABORATEUR_MATRICULE_AK UNIQUE (Matricule)
    , CONSTRAINT COLLABORATEUR_NIR_AK UNIQUE (NIR)
    , CONSTRAINT COLLABORATEUR_SERVICE_FK FOREIGN KEY (ServiceId)
          REFERENCES SERVICE (ServiceId) ON DELETE NO ACTION
    , CONSTRAINT COLLABORATEUR_PERSONNE_FK FOREIGN KEY (PersonneId)
          REFERENCES PERSONNE (PersonneId) ON DELETE CASCADE
);

CREATE TABLE DIRECTEUR
(
        PersonneId           INT           NOT NULL
      , PrimeBilan           INT           NOT NULL
    , CONSTRAINT DIRECTEUR_PK PRIMARY KEY (PersonneId)
    , CONSTRAINT DIRECTEUR_COLLABORATEUR_FK FOREIGN KEY (PersonneId)
          REFERENCES COLLABORATEUR (PersonneId) ON DELETE CASCADE
);

CREATE TABLE EMPLOYE
(
        PersonneId           INT           NOT NULL
      , Profil               VARCHAR(128)  NOT NULL
    , CONSTRAINT EMPLOYE_PK PRIMARY KEY (PersonneId)
    , CONSTRAINT EMPLOYE_COLLABORATEUR_FK FOREIGN KEY (PersonneId)
      REFERENCES COLLABORATEUR (PersonneId) ON DELETE CASCADE
);

Pour simplifier les SELECT, on peut créer des vues par type d’utilisateur. Par exemple, pour les tiers :

CREATE VIEW TIERS_V (PersonneCode, AdresseCourriel, NoSiret, RaisonSociale)
AS 
SELECT PersonneCode, AdresseCourriel, NoSiret, RaisonSociale
FROM   PERSONNE AS x JOIN TIERS AS y ON x.PersonneId = y.PersonneId
;

Dans mon message auquel je vous avais renvoyé, JMerise a généré un code SQL correct, mais les actions de compensation y sont absentes, c'est-à-dire le déclenchement automatique de la suppression en cascade, ce dont j’ai parlé dans le message qui suit :

Commentaires sur le script SQL :

Pour les entités-types spécialisées, à savoir COLLABORATEUR, TIERS, EMPLOYE, DIRECTEUR, vous pouvez générer l’action de compensation ON DELETE CASCADE (clause FOREIGN KEY). En effet, si on supprime la personne Raoul, on le supprime forcément à tous les étages, par définition les spécialisations n’ont pas à s’opposer aux stimuli qui leur parviennent.

Vous noterez que l’action de compensation ON DELETE CASCADE est bien présente dans le code que j’utilise.

Pour illustrer cela, créons maintenant de façon basique le tiers 'T0000001' :

INSERT INTO PERSONNE (PersonneCode, AdresseCourriel) VALUES ('T0000001', 'dépannage.naudin@abc.fr') ;
INSERT INTO TIERS (PersonneId, NoSiret, RaisonSociale) 
    SELECT PersonneId, '12345678901234', 'Naudin dépannage' FROM PERSONNE WHERE PersonneCode = 'T0000001' ; 

Pour retrouver ce tiers :

SELECT * FROM TIERS_V WHERE PersonneCode = 'T0000001' ;

Pour le supprimer :

DELETE FROM PERSONNE WHERE PersonneCode = 'T0000001' ;

La suppression de ce tiers dans la table PERSONNE a entraîné sa suppression automatique dans la table TIERS. Ceci est la conséquence de l’action de compensation ON DELETE CASCADE prévue dans la déclaration de la table TIERS (CREATE TABLE) ; ainsi il est inutile de procéder en deux temps, en commençant par un DELETE dans la table TIERS puis un DELETE dans la table PERSONNE.


INSERT par le biais de la vue TIERS_V :

La vue TIERS_V est une « vue de jointure ». La norme SQL prévoit que l’on puisse effectuer un insert dans ce genre de vue, mais PostgreSQL (version 10) ne le permet pas : pour pallier, on met en oeuvre un trigger ad-hoc, lequel ventile les données dans les tables (mais pas façon puzzle ^^) :

CREATE FUNCTION TIERS_VUE_INSERT_FN()
    RETURNS TRIGGER
    AS 
        $$
        BEGIN
            INSERT INTO PERSONNE (PersonneCode, AdresseCourriel)
                VALUES (NEW.PersonneCode, NEW.AdresseCourriel) ;
        
            INSERT INTO TIERS (PersonneId, NoSiret, RaisonSociale)  
                SELECT MAX(PersonneId), NEW.NoSiret, NEW.RaisonSociale FROM PERSONNE ;

            RETURN NULL ;  -- on n'a rien à renvoyer
        END
    $$     LANGUAGE plpgsql ;

CREATE TRIGGER TIERS_VUE_INSERT_TR INSTEAD OF INSERT ON TIERS_V 
    FOR EACH ROW EXECUTE PROCEDURE TIERS_VUE_INSERT_FN() ; 

Reprenons les deux inserts précédents :

INSERT INTO PERSONNE (PersonneCode, AdresseCourriel) VALUES ('T0000001', 'dépannage.naudin@abc.fr') ;
INSERT INTO TIERS (PersonneId, NoSiret, RaisonSociale) 
    SELECT PersonneId, '12345678901234', 'Naudin dépannage' FROM PERSONNE WHERE PersonneCode = 'T0000001' ; 

Ces inserts peuvent maintenant être remplacés par celui-ci :

INSERT INTO TIERS_V (PersonneCode, AdresseCourriel, NoSiret, RaisonSociale)
    VALUES ('T0000001', 'dépannage.naudin@abc.fr', '12345678901234', 'Naudin dépannage') ;

Même principe pour EMPLOYE qui hérite de COLLABORATEUR qui hérite de PERSONNE :

CREATE VIEW EMPLOYE_V (PersonneCode, AdresseCourriel, ServiceCode, Matricule, NIR, Nom, Prenom, DateEmbauche, Salaire, Profil) 
AS
SELECT PersonneCode, AdresseCourriel, ServiceCode, Matricule, NIR, Nom, Prenom, DateEmbauche, Salaire, Profil  
FROM   PERSONNE AS x JOIN COLLABORATEUR AS y ON x.PersonneId = y.PersonneId
                     JOIN SERVICE AS z ON y.ServiceId = z.ServiceId
                     JOIN EMPLOYE AS t ON y.PersonneId = t.PersonneId
;

CREATE FUNCTION EMPLOYE_VUE_INSERT_FN()
    RETURNS TRIGGER
    AS 
        $$
        BEGIN
            INSERT INTO PERSONNE (PersonneCode, AdresseCourriel)
                VALUES (NEW.PersonneCode, NEW.AdresseCourriel) ;

            INSERT INTO COLLABORATEUR (PersonneId, ServiceId, Matricule, NIR, Nom, Prenom, DateEmbauche, Salaire)  
                SELECT MAX(PersonneId),(SELECT ServiceId FROM SERVICE WHERE ServiceCode = NEW.ServiceCode)
                     , NEW.Matricule, NEW.NIR, NEW.Nom, NEW.Prenom, NEW.DateEmbauche, NEW.Salaire
                FROM PERSONNE ;

            INSERT INTO EMPLOYE (PersonneId, Profil)  
                SELECT MAX(PersonneId), NEW.Profil
                FROM PERSONNE ;

            RETURN NULL ;  
        END
    $$ 
    LANGUAGE plpgsql ;
    
CREATE TRIGGER EMPLOYE_VUE_INSERT_TR INSTEAD OF INSERT ON EMPLOYE_V 
    FOR EACH ROW EXECUTE PROCEDURE EMPLOYE_VUE_INSERT_FN() ;

Pour créer l’employé 'P0000001', au choix :

Soit :

INSERT INTO PERSONNE (PersonneCode, AdresseCourriel) VALUES ('P0000001', 'pascal@citron.fr') ;

INSERT INTO COLLABORATEUR (PersonneId, ServiceId, Matricule, NIR, Nom, Prenom, DateEmbauche, Salaire) 
    SELECT PersonneId, (SELECT ServiceId FROM SERVICE WHERE ServiceCode = 'DSI'), 'MAT00056', '1300450012003', '', 'Pascal', '1963-12-05', 6000 
    FROM PERSONNE WHERE PersonneCode = 'P0000001' ;

INSERT INTO EMPLOYE (PersonneId, Profil)
    SELECT PersonneId, 'Première gâchette' FROM PERSONNE WHERE PersonneCode = 'P0000001' ; 

Soit :

INSERT INTO EMPLOYE_V (PersonneCode, AdresseCourriel, ServiceCode, Matricule, NIR, Nom, Prenom, DateEmbauche, Salaire, Profil)
    VALUES ('P0000001', 'pascal@citron.fr', 'DSI', 'MAT00056', '1300450012003', '', 'Pascal', '1963-12-05', 6000, 'Première gâchette') ; 

Pour supprimer l’employé 'P0000001' :

DELETE FROM PERSONNE WHERE PersonneCode = 'P0000001' ; 

la doc indique que le support de l'héritage est limité. Il y a t'il un moyen pour contourner ce problème (niveau MCD ou SQL, jointures ou autres) ?

Le MCD que je vous avais présenté et ceux auxquels je vous renvoie ne sont pas concernés par les problèmes d’héritage, il y a tout ce qu’il faut. Quant à SQL, les scripts ci-dessus montrent qu’on traite sans problème de l’héritage tant en ce qui concerne les consultations que les mises à jour. Quant au support natif par PostgreSQL, je n’ai jamais testé, mais je vais essayer de regarder ça.

[fsmrel]

L’héritage selon PostgreSQL

Sur le plan du vocabulaire, il y a une différence radicale entre l’héritage tel qu’on l’a vu jusqu’ici et la façon dont PostgreSQL le perçoit :

Au vu de mes précédents messages, une personne peut être un collaborateur ou un tiers, un collaborateur peut être un employé ou un directeur, un tiers peut être un client ou un fournisseur.

Un employé est un collaborateur, un collaborateur est une personne, etc.

On utilise ici exclusivement le verbe être, on est dans logique du « une ellipse peut être un cercle » et « un cercle est une ellipse ».

Maintenant, je cite PostgreSQL version 10 :

PostgreSQL implements table inheritance [...] Use of INHERITS creates a persistent relationship between the new child table and its parent table(s).

Une table peut avoir des enfants et une table enfant a une mère. Attention c’est le verbe avoir qui est de mise ici : on est dans une logique d’héritage complètement différente de celle de l’approche conceptuelle, ou de celle de la théorie relationnelle, ou de celle l’approche objet, une ellipse n’est plus un cercle, mais une ellipse a un cercle...

Par ailleurs, nous avons évité la redondance (toujours redoutable), et cette fois-ci dans la logique PostgreSQL, elle devient obligatoire :

One convenient way to create a compatible table that will later be made a new child is to use the LIKE clause in CREATE TABLE. This creates a new table with the same columns as the source table. If there are any CHECK constraints defined on the source table, the INCLUDING CONSTRAINTS option to LIKE should be specified, as the new child must have constraints matching the parent to be considered compatible.

En héritant de la table PERSONNE, la table TIERS devrait en reprendre la structure intégrale : je m’abstiendrai, mais je ne pourrai pas empêcher PostgreSQL de probablement dupliquer les données. Quoi qu’il en soit, PostgreSQL fait par ailleurs mention de lacunes dans son traitement de l’héritage, dans le genre :

If we declared cities.name to be UNIQUE or a PRIMARY KEY, this would not stop the capitals table from having rows with names duplicating rows in cities.

Blurps ? Et il conclut :

These deficiencies will probably be fixed in some future release, but in the meantime considerable care is needed in deciding whether inheritance is useful for your application.

Conclusion : on évitera de mettre en oeuvre l’héritage proposé par PostgreSQL, d’autant que lui-même nous engage à nous en passer.

A titre de vérification voyons voir avec le code SQL suivant (repris de celui de mon message précédent), dans lequel la table TIERS « hérite » (INHERITS) de la table PERSONNE :

CREATE TABLE PERSONNE
(
        PersonneId           SERIAL        NOT NULL
      , PersonneCode         CHAR(8)       NOT NULL
      , AdresseCourriel      VARCHAR(64)   NOT NULL
    , CONSTRAINT PERSONNE_PK PRIMARY KEY (PersonneId)
    , CONSTRAINT PERSONNE_CODE_AK UNIQUE (PersonneCode)
    , CONSTRAINT PERSONNE_COURRIEL_AK UNIQUE (AdresseCourriel)
);

CREATE TABLE TIERS
(
        PersonneId           INT           NOT NULL
      , NoSiret              CHAR(14)      NOT NULL
      , RaisonSociale        VARCHAR(64)   NOT NULL

    , CONSTRAINT TIERS_PK PRIMARY KEY (PersonneId)
    , CONSTRAINT TIERS_SIRET_AK UNIQUE (NoSiret)
    , CONSTRAINT TIERS_PERSONNE_FK FOREIGN KEY (PersonneId)
          REFERENCES PERSONNE (PersonneId) ON DELETE CASCADE
)
    INHERITS (PERSONNE)
;

Effectuons des ajouts dans la table PERSONNE :

INSERT INTO PERSONNE (PersonneCode, AdresseCourriel) VALUES ('T0000001', 'dépannage.naudin@abc.fr') ;
INSERT INTO PERSONNE (PersonneCode, AdresseCourriel) VALUES ('T0000002', 'volfoni-freres@xyzt.fr') ;
INSERT INTO PERSONNE (PersonneCode, AdresseCourriel) VALUES ('N0000001', 'f.naudin@abc.fr') ;

Un coup d’oeil à la table PERSONNE :

Jusqu’à présent, pas de problème. Effectuons maintenant un insert du tiers 'T0000001' dans la table TIERS. Dans l’instruction INSERT on est obligé de mentionner toutes les colonnes de la table PERSONNE en plus de celles de la table TIERS, sinon, comme prévu on est jeté. Bon, admettons... et recopions les données du tiers 'T0000001', car que faire d’autre qui ait un sens et conserve la cohérence ?

INSERT INTO TIERS (PersonneId, PersonneCode, AdresseCourriel, NoSiret, RaisonSociale) 
    SELECT PersonneId, PersonneCode, AdresseCourriel, '12345678901234', 'Naudin dépannage' FROM PERSONNE WHERE PersonneCode = 'T0000001' ; 

Un coup d’oeil à la table TIERS, dont j’ai conservé la structure initiale mais que PostgreSQL étend pour les besoins de la cause :

Avec la vue TIERS_V (cf. message précédent), on sait faire. Maintenant, si on regarde le contenu de la table PERSONNE, on constate que la clé primaire n’a pas tenu son rôle, car elle contient des doublons (la clé alternative aussi du reste), bref il y a viol de l’intégrité d’entité :

Gérer des tables en double, voire en triple (cas des employés, lesquels sont des collaborateurs, lesquels sont des personnes) pouvant à l’occasion être volumineuses, et en plus voir violer l’intégrité d’entité : ça ne passe pas, je refuse. D’autant que ce que j’ai présenté dans mon précédent message fonctionne très bien.

Je préfère ne pas utiliser l'héritage de PostgreSQL et le faire moi même.

Heu... Tu n’as pas tort !

[CinePhil]

Je n'avais pas développé mon impression sur l'héritage à la PostgreSQL parce que j'en avais un vague souvenir lors de mes premières découvertes de ce SGBD et j'en étais en effet arrivé à la même conclusion de redondance des données de la table mère dans la table fille.

J'ai l'impression que l'héritage à la PosgreSQL ressemble davantage à l'héritage en programmation orientée objet (POO).
En POO, si une classe Personne a les propriétés Nom et Prenom, et sa classe fille Utilisateur a les propriétés Login et Password, je peux directement accéder aux propriétés Nom et Prénom de la classe mère à partir de la classe fille :
[CODEPHP]$objUser = new Utilisateur;
$nom = $objUser->Nom;[/CODE]

C'est ce qui fait dire ou croire à certains que PostgreSQL serait une "base de données objet" (si tu te souviens de notre conversation à propos de la migration d'une BDD Codasyl en PostgreSQL, François, tu vois ce que je veux dire ! )

Pour que ce soit possible dans une BDD SQL, il faut passer par une vue qui rassemble les données de la personne et de l'utilisateur.

Avec une BDD relationnelle, on peut, par un ensemble de vues masquant la structure réelle de la BDD, constituer une sorte de "modèle objet". J'ai souvenir d'avoir lu ou entendu aussi la notion de "Modèle Opérationnel des Données" en rapport avec Merise, qui serait donc le modèle constitué des vues de la BDD. Mais je parle là de mémoire...

[jejerem]

Bonjour à vous deux !

Je m'excuse pour le retard de réponse, j'ai eu un petit soucis de santé.

Merci pour vos réponses. J'ai encore à apprendre !

CinéPhil :
1) Par définition, une PK (Primary Key) ne peut pas être "dupliquée", si sous ce terme vous signifiez que la même valeur de PK peut être attribuée deux fois.

Oui, c'est bien ce que je voulais dire.
J'aurai dû utiliser le terme "doublon".
Fsmrel illustre bien ce que je voulais éviter dans son exemple avec le mot clé "INHERITS" dans son dernier message.

Je me permet de rajouter le MCD que j'ai produit en me basant sur vos liens.



Le but n'est pas de faire me faire un cours ici, alors je vais essayer de faire court :

Si j'ai bien compris :

• La contrainte d'exclusion (symbole D) indique qu'un Utilisateur peut être... un Utilisateur seulement OU un Collaborateur OU un Administrateur OU un Moderateur.
• La contrainte de partitionnement indique qu'un Collaborateur DOIT être (totalité) OU un Manager OU un Employe, mais jamais les deux (exclusion).

Au niveau SQL je peux donc créer une Vue comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE VIEW view_manager AS
	SELECT u.id, u.nom, u.prenom,
		c.codeEtabl, c.nivAcces,
		m.autres_infos 
	FROM utilisateur u
	INNER JOIN collaborateur c 
	ON u.id = c.id
	INNER JOIN manager m 
	ON c.id = m.id

pour voir la liste de tous mes managers.

De même pour créer un Manager :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
INSERT INTO UTILISATEUR (id, mdp, nom, prenom) VALUES (511, 'motdepassehashé', 'Driver', 'Jejerem');

INSERT INTO COLLABORATEUR (id, codeEtabl, nivAcces) 
	SELECT p.id, '00112', 3 
	FROM UTILISATEUR AS p WHERE p.id = 511;

INSERT INTO MANAGER(id, autres_infos)
	SELECT c.id, 'Mes autres infos' FROM COLLABORATEUR AS c WHERE c.id = 511;

Ainsi, la valeur de la colonne id de la table Personne Utilisateur (ici, 511) prendra place dans la colonne id de la table Collaborateur, cette dernière prendra place à son tour dans la colonne id de la table Manager.
(Pour chaque table la colonne id étant une PK.)

Si j'ai fais des erreurs, n'hésitez pas !

J'ai pu apprendre aussi que les triggers sont fort utile pour insérer des données simplement. Merci !
Mais si je peux les éviter pour l'instant, ça me va !

Encore une fois, désolé du retard de réponse et merci pour vos retours.

[fsmrel]

Hello !

la valeur de la colonne id de la table Personne (ici, 511) prendra place dans la colonne id de la table Collaborateur

Au vu de votre INSERT :

INSERT INTO COLLABORATEUR (id, codeEtabl, nivAcces) 
       SELECT p.id, '00112', 3 
       FROM UTILISATEUR AS p WHERE p.id = 1;

Et au vu du WHERE, sous réserve qu’il existe dans la table UTILISATEUR un utilisateur pour lequel id = 1, alors « SELECT p.id FROM UTILISATEUR » fournira la valeur 1 et non pas 511 pour la colonne id de la table collaborateur.

Au résultat, au lieu de <511, '00112', 3>, vous obtiendrez <1, '00112', 3>...

Il y a un certain nombre de techniques pour récupérer cette valeur 511 (voir par exemple ici) : fonctions MAX(), currval(), lastval(), clause RETURNING de l’instruction INSERT, mais attention aux mises à jour concurrentes qui peuvent fausser le résultat...

En attendant, pour créer le manager Jejerem, vous pouvez coder :

INSERT INTO UTILISATEUR (id, mdp, nom, prenom) VALUES (511, 'motdepassehashé', 'Driver', 'Jejerem') ;

INSERT INTO COLLABORATEUR (id, codeEtabl, nivAcces) VALUES (511, '00112', 3) ;

INSERT INTO MANAGER (id, autres_infos) VALUES (511, 'Mes autres infos') ;

Cent fois sur le métier remettons notre ouvrage...

[jejerem]

Oui, j'ai modifier mon dernier post entre temps.

C'est bien un WHERE id=511 que je voulais écrire.

Merci pour les astuces, j'ignorai les mots clés curval et lastval.

Edit : Je passe en résolu, gardant dans un coin de ma tête

Cent fois sur le métier remettez votre ouvrage ...

(Bon j'avoue, j'ai mis du temps à comprendre !)


Merci pour votre temps et pour vos conseils !

[CinePhil]

Un détail sur votre dernier MCD : les entité-type filles Collaborateur, Administrateur, Moderateur, Manager et Employe n'ont pas de propriété id dans le MCD. Puisqu'il s'agit d'héritages, C'est au niveau du MLD que l'id sera créé en en tant que clé étrangère référençant Utilisateur et comme clé primaire.

Autre chose : L'exclusion se représente par un X et la totalité par un T.

[fsmrel]

Un détail sur votre dernier MCD : les entité-type filles Collaborateur, Administrateur, Moderateur, Manager et Employe n'ont pas de propriété id dans le MCD. Puisqu'il s'agit d'héritages, C'est au niveau du MLD que l'id sera créé en en tant que clé étrangère référençant Utilisateur et comme clé primaire.

Le dernier MCD a été réalisé avec DB-MAIN, lequel ne manque évidemment pas de produire un MLD avec l’attribut id bien présent pour les clés (primaires et étrangères).

Autre chose : L'exclusion se représente par un X et la totalité par un T.

C’est AGL dépendant : par exemple, avec DB-MAIN on symbolise l’exclusion par la lettre « D », la totalité par « T » et le partitionnement par « P ».

Je pense que jejerem a bien tout compris...

[jejerem]

Merci pour vos retours !

En effet, les id dans mes entités (hormis Utilisateur) n'ont pas lieux d'être.
Erreur d'inattention, je regarderai mieux les exemples donnés la prochaine fois !

fsmrel :
C’est AGL dépendant : par exemple, avec DB-MAIN on symbolise l’exclusion par la lettre « D », la totalité par « T » et le partitionnement par « P ».

Oui, d'ailleurs sans votre tutoriel sur DB-Main, j'aurai été bien perdu avec ses trois lettres !

D'ailleurs, pourquoi DB-Main n'est pas standard à ce niveau ? (Bon cela dit, on sort du cadre de ma question initiale !)

Bonne soirée à vous !

[fsmrel]

pourquoi DB-Main n'est pas standard à ce niveau ?

Parce qu’en Merise, il n’y a pas de « standard » officiel (en passant, le terme français est plutôt « norme »), seulement des coutumes et des recommandations dans le genre de celles du Groupe 135 de l’Afcet. Dans l’ouvrage de référence « La Méthode Merise, principes et outils », on trouve une sorte de grammaire, mais qui est muette quant aux contraintes. Jean-Luc Hainaut (Université de Namur), cité dans la FAQ Merise, un des précurseurs du modèle E/R (il y a 45 ans ! ) et père de DB-MAIN, utilise non pas « X » mais « D » comme « Disjoint » : Pourquoi pas ?