Discussion :

[fsmrel]

Bonsoir,

Je n'ai pas très bien compris le role de l'entité "PARENTE" alors qu'il y a une entité "LIEN_PARENTE", aussi les relations que vous avez mis pour cette entité.

Quand vous écrivez « aussi les relations que vous avez mis pour cette entité », parlez-vous de la relation entre LIEN_PARENTE et PARENTE, ou des relations entre EMPLOYE et PROCHE ?

En attendant, voici pourquoi j’ai modélisé l’entité-type PARENTE (lire PARENTÉ bien sûr). Vous avez défini une association-type avoir_3 qui établit une relation de plusieurs à plusieurs entre les entités-types Personnel et Proche_Famille (votre association-type avoir_3 correspond à ce que j’ai appelé LIEN_PARENTE, et vos entités-types Personnel et Proche_Famille correspondent respectivement à ce que j’ai appelé EMPLOYE et PROCHE). Du fait de la relation de plusieurs à plusieurs entre un proche et un employé, en toute rigueur on ne sait pas à quel employé associer le dossier de maladie du proche, il y a une indétermination ; en conséquence de quoi, parce que c’est elle qui a pour rôle de définir les paires <proche, employé>, c’est bien l’entité-type LIEN_PARENTE qui permet de connaître la nature du lien de parenté entre le proche et l’employé, ça n’est pas le rôle de l’entité-type PROCHE.

Dans ce contexte, toujours en toute rigueur, pour un dossier de maladie d’un proche, on doit aussi connaître l’employé auquel il se rattache, auquel cas on ne peut pas établir de relation entre DOSSIER et PROCHE, puisqu’il peut y avoir plusieurs employés associés à un proche. On ne peut pas non plus établir un lien direct entre DOSSIER et PARENTE, car au niveau logique il y aurait génération d’un attribut EmployeId dans l’en-tête de la table DOSSIER, attribut qui n'aurait pas de sens quand c'est un employé qui est malade. C’est pourquoi je définis une entité-type PARENTE, permettant d’établir un pont entre DOSSIER et LIEN_PARENTE, c'est-à-dire de connecter proprement ces deux entités-types.

Les cardinalités portées par l’association-type connectant DOSSIER et PARENTE se lisent ainsi :

Une occurrence de PARENTE est toujours associée à exactement une occurrence de DOSSIER et une occurrence de DOSSIER est associée à au plus une occurrence de PARENTE (c'est-à-dire que seul le dossier concernant un proche est associé, le dossier d’un employé lui-même malade n’étant évidemment pas concerné).

Dans l’exemple que j’ai fourni dans mon message du 16/03/2011 à 03h26, Driss est un proche de l’employé Hassnaa, il fait donc l’objet d’une occurrence de PARENTE, tandis que fsmrel qui est un employé ne fait pas l’objet d’une telle occurrence.

Maintenant, si vous êtes certain que c’est l’entité-type PROCHE qui est porteuse de l’attribut correspondant au type de lien de parenté, alors pourquoi ne pas remplacer la relation de plusieurs à plusieurs entre PROCHE et EMPLOYE par une relation de un à plusieurs ? En effet, l’entité-type (associative) PARENTE ne se justifierait plus puisqu’on connaîtrait sans ambiguïté l’employé associé au proche qui a un dossier.

[Driss35]

Bonjour,

Vous trouverez ci-joint les MCD, MLD et MPD que j'ai fait.
Merci de me donner votre avis et vos remarques.


Comment vous avez mis sur la relation entre parente et dossier un "(D)" sur le MCD ?


Merci d'avance.

[fsmrel]

Bonjour Driss,


Je vais regarder votre modélisation. En attendant je réponds déjà à la question suivante :

Comment vous avez mis sur la relation entre parente et dossier un "(D)" sur le MCD ?

Le but de la manœuvre est de demander à Power AMC d’éviter de pondre au stade du MLD un cycle mal venu entre les entités-types PARENTE et DOSSIER.

Pour cela (avec Power AMC V11) :

• Clic droit sur le lien entre PARENTE et DOSSIER,
• Choisir "Propriétés", onglet "Détails" pour avoir accès à la fenêtre "Propriétés de la relation",
• Cocher la case "Dépendant" ci-dessous, et définir un rôle dominant dans le sens DOSSIER -> PARENTE.

Avec la V15 de Power AMC, je suppose qu’on devrait avoir accès à une fenêtre du même genre. Vous me direz...

[fsmrel]

Bonjour à nouveau,


Concernant le MCD :

Ajouter le rôle dominant de PARENTE par rapport à DOSSIER, sujet que nous venons d’évoquer.

Attention : il faut identifier le dossier relativement à la personne. Ceci est fondamental pour la garantie de l’intégrité des données concernant le proche. En procédant ainsi, l’identifiant du proche est propagée jusqu’à PARENTE et donc on peut ainsi garantir que le proche qui fait l’objet du dossier est bien le proche participant à la clé primaire de la table LIEN_PARENTE.

Sinon, avec votre MLD, on peut avoir la situation suivante, dans laquelle le dossier d1 concerne fsmrel :

Code :

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

1
2
3
4
5
6
7
8
9
DOSSIER (DossierId  PersonneId  ...)
                d1      fsmrel  ...

LIEN_PARENTE (ProcheId  EmployeId  ...)
               Hassnaa      Driss  ... 

PARENTE (DossierId  ProcheId  EmployeId  ...)
                d1   Hassnaa      Driss  ...    // aïe !

Avec la modélisation que je vous ai proposée, cette situation ne peut pas se produire :

Code :

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

1
2
3
4
5
6
7
8
9
DOSSIER (PersonneId  DossierId  ...)
             fsmrel         d1  ...

LIEN_PARENTE (ProcheId  EmployeId  ...)
               Hassnaa      Driss  ... 

PARENTE (ProcheId  DossierId  EmployeId  ...)
          Hassnaa         d1      Driss  ...     // impossible !

En effet, comme le dossier d1 concerne fsmrel et non pas Hassnaa, le tuple ci-dessus est rejeté par le SGBD en raison du contrôle de l'intégrité référentielle.


Rappel : MLD attendu




J’ai des observations à faire concernant l’historique, mais on pourra en traiter quand le reste sera d’équerre.

[Driss35]

Bonjour,

Vous voulez dire que je dois modifier le MLD généré automatiquement à partir du MCD par le logiciel ? Ou bien il y a une erreur dans le MCD de base ?

Merci d'avance.

[fsmrel]

Bonjour Driss,


Reprenons le MCD que je vous ai proposé, dans lequel l’entité-type DOSSIER est identifiée relativement à l’entité-type PERSONNE :

Power AMC me génère le MLD le suivant :

Bien que ce ne soit pas nécessaire, je préfère renommer certains attributs.
En effet, vous noterez que Power AMC a été obligé de prendre certaines initiatives. Prenons le cas de la table LIEN_PARENTE : elle fait référence aux tables EMPLOYE et PROCHE qui toutes les deux ont pour clé primaire {PersonneId} : la table LIEN_PARENTE ne pouvant pas comporter deux attributs ayant le même nom, à savoir PersonneId, l’outil en a renommé un en Colonne_3, lequel fait référence à l’attribut EmployeId de la table EMPLOYE. Ce nom de Colonne_3 ne me plaît pas et je modifie donc le MLD en renommant Colonne_3 en EmployeId. Pour être en phase, je renomme aussi en EmployeId l’attribut PersonneId de la table EMPLOYE :

Pour plus de clarté et pour qu’il n’y ait pas de jaloux, dans les tables PROCHE et LIEN_PARENTE je renomme l’attribut PersonneId en ProcheId (et bien que ce ne soit pas nécessaire, je fais passer ProcheId en tête dans la table LIEN_PARENTE) :

L’harmonie n’est pas parfaite entre les noms des attributs dans les tables LIEN_PARENTE et PARENTE, par exemple l’attribut Colonne_4 de la table PARENTE fait référence à l’attribut ProcheId de la table LIEN_PARENTE :

Bien que cela ne soit pas nécessaire, mais toujours pour plus de clarté, je procède donc à certains changements de noms dans la table PARENTE :

1) Je renomme l’attribut PersonneId (qui fait référence à l’attribut ProcheId de la table LIEN_PARENTE) en ProcheId ;

2) Je renomme l’attribut Colonne_3 (qui fait référence à l’attribut EmployeId de la table LIEN_PARENTE) en EmployeId ;

3) Je renomme l’attribut Colonne_4 (qui fait référence à l’attribut PersonneId de la table DOSSIER) en PersonneId :

Pour être phase avec la table LIEN_PARENTE, je permute dans la table PARENTE la position des attributs EmployeId et ProcheId :

Jusqu’ici, on n’a fait que rendre plus lisible le MLD et comme dirait l'autre « c'est de la cosmétique », mais venons-en à la partie importante : dans la table PARENTE, les attributs PersonneId et ProcheId désignent tous deux en réalité un même proche. Pour satisfaire à cette contrainte, il faut modifier manuellement le MLD :

Soit définir une contrainte d’égalité (simultanéité) : ProcheId = PersonneId, ce qui est n’est pas la meilleure solution (à supposer qu’on puisse le faire) ;

Soit, bien plus intéressant, supprimer un des deux attributs, par exemple PersonneId et signifier que l’attribut ProcheId fait non seulement référence à l’attribut ProcheId de la table LIEN_PARENTE, mais aussi à l’attribut PersonneId de la table DOSSIER (colonne de la table enfant au sens Power AMC) comme ci-dessous :

Ceci fait, l’attribut ProcheId se substitue à l’attribut PersonneId dans la composition de la clé primaire de la table PARENTE :




L’attribut PersonneId ne joue désormais plus aucun rôle, c’est une branche morte que l’on peut couper. On en profite pour réordonner les autres attributs :

Désormais, la situation suivante (cf. mon message précédent) devient impossible, le malade fsmrel n’est pas un des proches de l’employé Driss et le dossier de fsmrel ne peut donc pas être rattaché à Driss :

Code :

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

1
2
3
4
5
6
7
8
9
DOSSIER (PersonneId  DossierId  ...)
             fsmrel         d1  ...

LIEN_PARENTE (ProcheId  EmployeId  ...)
               Hassnaa      Driss  ... 

PARENTE (ProcheId  DossierId  EmployeId  ...)
          Hassnaa         d1      Driss  ...     // impossible !

Au rebours, dans votre MCD l’entité-type DOSSIER est identifiée de façon absolue :



D’où le MLD :

Cette fois-ci, il n’est pas possible d’empêcher le rattachement du dossier du malade fsmrel à l’employé Driss alors qu’ils n’ont aucun lien de parenté :

Code :

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

1
2
3
4
5
6
7
8
9
DOSSIER (DossierId  PersonneId  ...)
                d1      fsmrel  ...

LIEN_PARENTE (ProcheId  EmployeId  ...)
               Hassnaa      Driss  ... 

PARENTE (DossierId  ProcheId  EmployeId  ...)
                d1   Hassnaa      Driss  ...    // aïe !

En conclusion et pour répondre à votre question :

1) Votre MCD n’est pas faux, mais il doit être amélioré (identification relative de l’entité-type DOSSIER par rapport à l’entité-type PERSONNE).

2) Ceci fait, le MLD doit être modifié manuellement : aménagement de la table PARENTE pour que les deux attributs qui font double emploi ne fassent qu’un.

[Driss35]

Bonjour,

Après avoir fait les modification que vous avez indiqué, j'ai procéder à une vérification du modèle par le logiciel et il m'a affiché 2 avertissements :



Que me conseillez-vous de faire ? et pour la partie historique ?

Merci beaucoup pour votre aide précieuse.

[fsmrel]

Bonsoir,



La structure de votre table PARENTE n’est pas identique à la mienne :

En effet, chez moi l’attribut ProcheId précède l’attribut DossierId, alors que chez vous c’est l’inverse.


Comme vous avez affiché le message de POWER AMC là où il ne faut pas, c'est-à-dire en plein milieu du modèle, je ne vois pas tout, donc j’aimerais voir un MCD dans lequel les tables soient toutes bien visibles.

Après avoir fait les modification que vous avez indiqué, j'ai procéder à une vérification du modèle par le logiciel et il m'a affiché 2 avertissements

Ça n’est pas grave. Power AMC se situe déjà au niveau physique, celui de la plomberie et de la tuyauterie, mais nous n’en sommes pas encore là. Les index sont faits pour rendre performantes les requêtes et l’AGL vous dit que là où vous avez deux index, par exemple Dossier.Dossier_PK et CONCERNE_FK, un seul suffit, en l’occurrence le 1er nommé.

Si vous voulez ne pas voir le message « Inclusion de l’index », parce que vous n’en êtes pas encore au stade de la tuyauterie, il vous suffit de ne pas cocher la case « Index de table » au moment de la vérification du modèle :





Vous pouvez par ailleurs anticiper sur le niveau physique et supprimer les index qui ne servent à rien, c'est-à-dire ceux dont la clé est incluse dans une autre, à savoir CONCERNE_FK et AVOIR_FK :

Menu > Modèle > Index :

Vous obtenez la liste des index. Vous supprimez les deux index accusés à juste titre d’être inclus, inutiles.

Comme votre table DOSSIER est masquée, je vais conjecturer au sujet du double emploi : disons que la clé de l’index Dossier.Dossier_PK est constituée du couple {PersonneId, DossierId} alors que la clé de l’index CONCERNE_FK est constituée du singleton {PersonneId}. Le singleton, n’a donc pas de valeur ajoutée en termes d’indexation, la performance ne sera pas améliorée (au contraire du reste, car à l’occasion des mises à jour de la table DOSSIER, les index seront mis à jour eux aussi).

On discutera plus tard de la table HISTORIQUE. Mais déjà, on peut dire que :

1) Date est un mot réservé, donc on va renommer l’attribut Date en DateHistoDossier.

2) Vous avez établi une contrainte référentielle (clé étrangère) entre les tables DOSSIER et HISTORIQUE, ce qui suppose que si un dossier figure dans la table HISTORIQUE, il doit nécessairement figurer aussi dans la table DOSSIER. S’il en est ainsi, cela veut dire que certaines données d’un dossier peuvent changer dans le temps, en l’occurrence la nature (au fait, à quoi correspond cette donnée ?) Si un dossier ne peut pas figurer en même temps dans les deux tables, le lien doit être rompu, auquel cas on peut établir une relation entre HISTORIQUE et PERSONNE (ou EMPLOYE).

3) L’attribut HistId n’apporte rien et doit être supprimé. On verra l’organisation la clé en fonction de votre réponse à cette question :

Quelle est la finalité précise de l’historisation des dossiers ? Quelles sont les raisons pour lesquelles un dossier va se retrouver dans la table HISTORIQUE ? Merci de fournir des exemples concrets.

[Driss35]

Bonjour,

Pour répondre à vos remarques :
1) Modification faite sur le MCD.

2) En fait, la nature qui est renseigné dans la table DOSSIER n'est pas la même que celle de l'historique, d'ailleurs j'ai renommé celle de la table HISTORIQUE en "Type". Les dossiers peuvent être de natures différentes (maladie, soins dentaires, optique,...).

3) L'objectif de la table HISTORIQUE est d'enregistrer toutes les opérations éffectués sur un dossier, c-à-d : saisi, envoi, retour, remboursement, rejet...
Un dossier doit être saisi, puis envoyé. Il peut être retourné pour manque de pièces et après l'avoir complété, il sera renvoyé. Après, il peut être remboursé ou rejeté. Je veux donc retracer le chemin parcouru par le dossier.

J'ai mis ci-joint le MCD final.

Est ce que ça ne pose pas de problème que la table proche ne contienne pas d'attributs ?

Merci d'avance.

[fsmrel]

Bonsoir,

Est ce que ça ne pose pas de problème que la table proche ne contienne pas d'attributs ?

Ne confondez par entité-type et table. Dans votre MCD, l’entité-type PROCHE ne comporte pad d’attribut, mais après génération du MLD, la table PROCHE en comporte un, nommé ProcheId, voyez ci-dessous :


Pour la petite histoire, la relation (au sens du Modèle Relationnel de Données et dont la table SQL est une approximation) qui comporte zéro attribut et un tuple s’appelle TABLE_DEE, tandis que la relation qui comporte zéro attribut et zéro tuple s’appelle TABLE_DUM.

J'ai mis ci-joint le MCD final.

Il faudrait aussi le MLD.


Entité-type HISTORIQUE

Il faudrait changer le nom de l’entité-type HISTORIQUE, car elle n’a pas les caractéristiques exactes d’un historique et ce nom est trompeur. Un historique de dossiers peut vivre sa vie, sans relation avec les dossiers actifs. Qui plus est, un historique est caractérisé par des périodes (par exemple, telle personne a vécu dans telle ville de telle date à telle date, puis dans telle autre ville de telle autre date à telle autre date, etc.) Un nom comme ETAT_DOSSIER, SITUATION_DOSSIER, SUIVI_DOSSIER, TRACE, EVENEMENT ou un nom de ce genre serait plus approprié.

Par ailleurs, cette entité-type n’est pas autonome, elle dépend viscéralement de l’entité-type DOSSIER, elle en est une propriété multivaluée et doit donc être identifiée relativement à DOSSIER (tout comme cette entité-type est elle-même identifiée relativement à PERSONNE, on est dans la même logique).

Divers :

Certaines entités-types de votre MCD comportent des attributs dont les valeurs peuvent être facultatives : un défi important est de marquer chaque attribut comme obligatoire. En effet, si un attribut est marqué facultatif au niveau du MCD, cela veut dire qu’au niveau du MLD, les attributs des tables dérivées pourront être marqués NULL, or le bonhomme NULL prend un malin plaisir à chercher à rendre fausses les bases de données et inhiber les facultés des moteurs des SGBD.

[fsmrel]

Un nom comme ETAT_DOSSIER, SITUATION_DOSSIER, SUIVI_DOSSIER, TRACE, EVENEMENT ou un nom de ce genre serait plus approprié.

STATUT_DOSSIER serait peut être mieux.

[Driss35]

Bonjour,

J'ai fait des modification sur le MCD, ça me semble plus simple comme ça.
Dans la table DOSSIER, j'ai l'EmployeId à qui appartient le dossier et le PersonneId qui est le malade.
Qu'en pensez-vous ?
J'ai choisi le nom TRACEDOSSIER pour l'entité HISTORIQUE pour que ça soit plus clair, car le statut du dossier est stocké dans l'attribut Etat de la table DOSSIER. Quand je génère le MLD je remarque que le logiciel met aussi PersonneId et EmployeId dans la table TraceDossier. Pour quel raison ? Est-ce que je dois enlever la dépendance de DOSSIER envers EMPLOYE et PERSONNE ?

Merci beaucoup pour vos remarques et suggestions.

[fsmrel]

Bonsoir,

J'ai fait des modification sur le MCD, ça me semble plus simple comme ça.
Dans la table DOSSIER, j'ai l'EmployeId à qui appartient le dossier et le PersonneId qui est le malade.
Qu'en pensez-vous ?

J’en pense que c’est trop simple et que ça ne marche pas, car vous avez fait sauter la protection assurée par l’entité-type PARENTE.

Supposons en effet que Hassnaa (qui est un proche de l’employé Driss) soit malade et possède donc un dossier de maladie. Selon votre MCD, rien n’interdit que ce dossier soit rattaché à fsmrel via la relation Appartient entre DOSSIER et EMPLOYE : autant dire que l’entité-type LIEN_PARENTE compte pour du beurre dans cette affaire. Avec la version précédente du MCD, il est impossible que le dossier de Hassnaa soit rattaché à l’employé fsmrel.

Faites le test suivant (attention, le type des attributs tels que PersonneId ne sont pas au format numérique, mais c’est pour être plus parlant) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
CREATE TABLE PERSONNE (
   PersonneId           CHAR(08)             NOT NULL,
   Nom                  VARCHAR(48)          NOT NULL,
   CONSTRAINT PERSONNE_PK PRIMARY KEY  (PersonneId)
) ;
CREATE TABLE EMPLOYE (
   PersonneId           CHAR(08)             NOT NULL,
   Matricule            INT                  NOT NULL,
   Etc                  CHAR(10)             NOT NULL,
   CONSTRAINT EMPLOYE_PK PRIMARY KEY  (PersonneId),
   CONSTRAINT EMPLOYE_AK UNIQUE (Matricule),
   CONSTRAINT EMPLOYE_PERSONNE_FK FOREIGN KEY (PersonneId)
      REFERENCES Personne (PersonneId)
);
CREATE TABLE PROCHE (
   PersonneId           CHAR(08)             NOT NULL,
   CONSTRAINT PROCHE_PK PRIMARY KEY  (PersonneId),
   CONSTRAINT PROCHE_PERSONNE_FK FOREIGN KEY (PersonneId)
      REFERENCES Personne (PersonneId)
);
CREATE TABLE LIEN_PARENTE (
   ProcheId             CHAR(08)                  NOT NULL,
   EmployeId            CHAR(08)                  NOT NULL,
   LienParente          VARCHAR(16)               NOT NULL,
   CONSTRAINT LIEN_PARENTE_PK PRIMARY KEY  (ProcheId, EmployeId),
   CONSTRAINT LIEN_PARENTE_EMPLOYE_FK FOREIGN KEY (EmployeId)
      REFERENCES Employe (PersonneId),
   CONSTRAINT LIEN_PARENTE_PROCHE_FK FOREIGN KEY (ProcheId)
      REFERENCES Proche (PersonneId)
);
CREATE TABLE DOSSIER (
   PersonneId           CHAR(08)             NOT NULL,
   DossierId            INT                  NOT NULL,
   DossierNo            INT                  NOT NULL,
   Etc                  CHAR(10)             NOT NULL,
   CONSTRAINT DOSSIER_PK PRIMARY KEY  (PersonneId, DossierId),
   CONSTRAINT DOSSIER_AK UNIQUE (DossierNo),
   CONSTRAINT DOSSIER_PERSONNE_FK FOREIGN KEY (PersonneId)
      REFERENCES Personne (PersonneId)
);
CREATE TABLE PARENTE (
   ProcheId             CHAR(08)                  NOT NULL,
   DossierId            INT                       NOT NULL,
   EmployeId            CHAR(08)                  NOT NULL,
   CONSTRAINT PARENTE_PK PRIMARY KEY  (ProcheId, DossierId),
   CONSTRAINT PARENTE_LIEN_PARENTE_FK FOREIGN KEY (ProcheId, EmployeId)
      REFERENCES Lien_parente (ProcheId, EmployeId),
   CONSTRAINT PARENTE_DOSSIER_FK FOREIGN KEY (ProcheId, DossierId)
      REFERENCES Dossier (PersonneId, DossierId)
);
 
INSERT INTO PERSONNE VALUES ('Hassnaa', 'Hassnaa66') ;
INSERT INTO PERSONNE VALUES ('Driss',   'Driss35') ;
INSERT INTO PERSONNE VALUES ('fsmrel',  'fsmrel du Relationland') ;
 
INSERT INTO EMPLOYE VALUES ('Driss',  123456,  '2003-03-20') ;
INSERT INTO EMPLOYE VALUES ('fsmrel', 234567,  '2005-05-01') ;
 
INSERT INTO PROCHE VALUES ('Hassnaa') ;
 
INSERT INTO LIEN_PARENTE VALUES ('Hassnaa', 'Driss', 'cousine') ;
 
INSERT INTO DOSSIER VALUES ('Hassnaa', 1, 123456789, '2011-01-01') ;
INSERT INTO DOSSIER VALUES ('fsmrel',  2, 234567890, '2011-03-01') ;
 
--INSERT INTO PARENTE VALUES ('Hassnaa', 1, 'fsmrel') ; -- Viol d'Intégrité référentielle détecté par le SGBD.
INSERT INTO PARENTE VALUES ('Hassnaa', 1, 'Driss') ; -- OK.

Quand je génère le MLD je remarque que le logiciel met aussi PersonneId et EmployeId dans la table TraceDossier. Pour quel raison ?

Etant donné que vous avez identifié l’entité-type DOSSIER relativement à PERSONNE d’une part et EMPLOYE d’autre part, il est normal que DOSSIER hérite de identifiant de l’une et de l’identifiant de l’autre. De même, comme vous avez identifié TRACE_DOSSIER relativement à DOSSIER (ce qui cette fois-ci est normal), alors au niveau du MLD, la clé de la table TRACE_DOSSIER est le quadruplet {PersonneId, EmployeId, DossierId, HistId}. Sans la relation identifiante Appartient entre DOSSIER et EMPLOYE, la clé aurait été le triplet {PersonneId, DossierId, HistId}, c'est-à-dire la clé de DOSSIER augmentée de l’attribut HistId qui ne sert qu’à dédoublonner les statuts du dossier.

Est-ce que je dois enlever la dépendance de DOSSIER envers EMPLOYE et PERSONNE ?

Il faut supprimer la relation Appartient entre DOSSIER et EMPLOYE et remettre en place l’entité-type PARENTE...

A noter que les attributs qui composent les clés primaires sont en principe invisibles pour l’utilisateur. Si celui-ci gère des numéros de dossier, alors il faut ajouter un attribut ad-hoc dans l’entité-type DOSSIER qui comporte donc une clé alternative (voyez mon jeu d’essai), puisque deux dossiers ne peuvent pas avoir le même numéro.

[Driss35]

Bonjour,

Ah ben oui, c'était trop simple pour être vrai :d

Prenant le cas d'un employé Driss qui n'est pas marié et n'a pas d'enfant, donc il n'a aucun lien de parenté avec un proche (les liens de parenté ne peuvent être que pour conjoint ou enfant). Il a constitué un dossier pour lui même qui était malade. Si je comprend bien, dans ce cas, la table parenté ne contiendra aucun enregistrement. Il suffira donc de vérifier le PersonneId de la table DOSSIER par rapport à EmployeId de la table EMPLOYE ?

[fsmrel]

Bonjour,

Prenant le cas d'un employé Driss qui n'est pas marié et n'a pas d'enfant, donc il n'a aucun lien de parenté avec un proche (les liens de parenté ne peuvent être que pour conjoint ou enfant). Il a constitué un dossier pour lui même qui était malade. Si je comprend bien, dans ce cas, la table parenté ne contiendra aucun enregistrement.

Reprenons l’exemple que je vous ai fourni dans ma réponse du 25/03/2011, 17h33. Dans cet exemple, c’est l’employé fsmrel qui est malade : vous constaterez que fsmrel ne figure pas dans la table PARENTE, puisque cette table sert de protection contre des erreurs d’affectation des dossiers de proches.

Code :

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

1
2
3
4
5
6
7
8
9
DOSSIER (PersonneId  DossierId  ...)
             fsmrel         d1  ...

LIEN_PARENTE (ProcheId  EmployeId  ...)
               Hassnaa      Driss  ... 

PARENTE (ProcheId  DossierId  EmployeId  ...)
          Hassnaa         d1      Driss  ...

Ceci confirme l’association entre les entités-types DOSSIER et PARENTE du MCD que je vous ai fourni précédemment (message du 28/03/2011, 18h20) :



Pour forcer les employés à figurer dans la table PARENTE, il aurait fallu modifier le MCD :

Il suffira donc de vérifier le PersonneId de la table DOSSIER par rapport à EmployeId de la table EMPLOYE ?

Oui. Et au niveau SQL, on peut même prévoir un trigger pour empêcher de faire figurer un employé dans la table PARENTE lors des INSERT.


Ici le temps est bien maussade, mais je vous souhaite beaucoup de soleil.

[Driss35]

Bonjour,

Bon je crois que j'ai bien compris maintenant (enfin).

J'ai mis e pièce-jointe les MCD et MLD finaux (je l'espère).
J'apréci beaucoup votre aide, merci beaucoup.

Ici le temps est très chaud, ce n'est pas le soleil qui manque par ici

[fsmrel]

Bonsoir,


Souvenez-vous de ce que j’ai écrit à propos de l’entité-type TraceDossier (ex HISTORIQUE) :

cette entité-type n’est pas autonome, elle dépend viscéralement de l’entité-type DOSSIER, elle en est une propriété multivaluée et doit donc être identifiée relativement à DOSSIER (tout comme cette entité-type est elle-même identifiée relativement à PERSONNE, on est dans la même logique).

MCD et MLD :


Et comme il n’y a pas de petits profits, en conséquence au niveau physique cette fois-ci, vous gagnerez en performance des requêtes, et les mises à jour seront moins coûteuses en temps et en place (un index de gagné).

Ainsi, il arrive que la sémantique et le fer à souder aillent dans le même sens (j’en profite pour rappeler ce qu’écrivit Maurice Nivat, un des meilleurs spécialistes mondiaux en informatique théorique : « L’informatique est la rencontre de la logique formelle et du fer à souder...»)

J’avais aussi écrit :

Certaines entités-types de votre MCD comportent des attributs dont les valeurs peuvent être facultatives : un défi important est de marquer chaque attribut comme obligatoire. En effet, si un attribut est marqué facultatif au niveau du MCD, cela veut dire qu’au niveau du MLD, les attributs des tables dérivées pourront être marqués NULL, or le bonhomme NULL prend un malin plaisir à chercher à rendre fausses les bases de données et inhiber les facultés des moteurs des SGBD.

Je vous recommande vivement de ne pas laisser les choses en l'état.



Selon votre MCD, il n’y a qu’un utilisateur qui puisse accéder aux données de la ta table TraceDossier. Question : Comment les choses se passent-elles si l’utilisateur est absent (en arrêt maladie ) ? On attend son retour ? Le login est-il partagé entre certains utilisateurs ?

Merci d'envoyer un peu de soleil...

[Driss35]

Bonjour,

Concernant les attributs que j'ai marqué facultatifs, je ne comprends pas pourquoi je devrais les mettre en obligatoires puisqu'ils ne vont pas toujours être saisi par l'utilisateur. Par exemple, la date de départ d'un employé ne vas être saisi que lors du départ de celui-ci. Si je les met en obligatoire, Comment vais-je remplir ces champs lors de la création d'un enregistrement ?

J'ai conçu la table TRACEDOSSIER pour enregistrer les différents statuts dont passe les dossier et aussi l'utilisateur qui a fait l'opération, d'où la relation avec la table UTILISATEUR. Tout utilisateur peut accéder aux opération effectuées sur un dossier quelque soit l'utilisateur qui les a effectué.

Aujourd'hui, il pleut. Peut-être le soleil sera de retour durant cette semaine...

[fsmrel]

Bonsoir,

Concernant les attributs que j'ai marqué facultatifs, je ne comprends pas pourquoi je devrais les mettre en obligatoires puisqu'ils ne vont pas toujours être saisi par l'utilisateur. Par exemple, la date de départ d'un employé ne vas être saisi que lors du départ de celui-ci. Si je les met en obligatoire, Comment vais-je remplir ces champs lors de la création d'un enregistrement ?

J’ai écrit précédemment qu’il y avait là un défi. Puisque seuls certains employés sont partis à la retraite, on relève le défi en spécialisant les employés en actifs d'une part et retraités d'autre part :



D’où le MLD :



Supposons maintenant que seuls les employés actifs soient autorisés à saisir des dossiers. Dans ces conditions, au niveau du MLD (MPD au sens Power AMC), on créera une vue des employés habilités, c'est-à-dire seulement ceux qui sont actifs. Appelons cette vue EMP_HABILITE :



En SQL :

Code SQL :

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

1
2
3
4
5
CREATE VIEW EMP_HABILITE (EmployeId, Matricule, DateEmbauche, Etc) 
  AS
    SELECT  x.EmployeId, x.Matricule, x.DateEmbauche, x.Etc
    FROM    EMPLOYE AS x, EMP_ACTIF AS y
            ON x.EmployeId = y.EmployeId ;

Et les programmes utilisés pour la saisie des dossiers par les employés utiliseront cette vue. Seuls les employés actifs pourront saisir des dossiers.

Ceci est plus pour vous un sujet de réflexion, puisque les retraités auraient bien du mal à saisir des dossiers, à moins que par Internet ?


Il apparaît que l’attribut NAdhes (table EMPLOYE) peut ne pas être renseigné lui aussi. A supposer qu’il ne soit à renseigner que dans le cas des employés actifs, il doit alors être transféré dans l’entité-type EMP_ACTIF. Sinon, pourquoi peut-il ne pas être renseigné ?


Cas de l’entité-type DOSSIER

Les attributs de type Réel sont des montants ? des indicateurs ?

J'ai conçu la table TRACEDOSSIER pour enregistrer les différents statuts dont passe les dossier et aussi l'utilisateur qui a fait l'opération, d'où la relation avec la table UTILISATEUR. Tout utilisateur peut accéder aux opération effectuées sur un dossier quelque soit l'utilisateur qui les a effectué.

D’accord, mais si le statut du dossier a été saisi par l’utilisateur U1, on a donc une ligne L1 de la table qui a le statut S1. Si U1 tombe malade et qu’il faille effectuer une modification portant sur la ligne L1, que fait-on ? On attend le retour de U1 ? On lui téléphone pour lui demander son mot de passe ? Un autre utilisateur U2 crée une ligne L2 avec le même statut S1 ?


On a eu un peu plus de soleil (ou moins de bouillasse), mais il ne fait pas chaud...

[Driss35]

Bonjour,

Le champs NAdhes c'est le numéro d'adhésion de l'employé à la mutuelle. Les nouveaux employés n'ont pas leur numéro d'adhésion qu'après une période donnée, mais pendant cette période ils peuvent constituer des dossiers.

Les attributs de type réel dans l'entité-type DOSSIER sont des montants qui sont renseigné selon le cas traité par le dossier, Bon pour ça je peux mettre des 0 dans les valeurs qu'on renseigne pas.

Par contre les champs MtRemb (Montant remboursé) et TypeRemb (Type de remboursement) ne sont normalement renseigné qu'au moment du remboursement du dossier, s'il est remboursé. Sinon il est rejeté.

Le champs Remarque dans TRACEDOSSIER est fait pour saisir des remarques supplémentaires facultatives en cas d'un retour ou un rejet du dossier.

Concernat l'entité-type TRACEDOSSIER, je veux que tout utilisateur puisse voir toutes les opération effectué sur un dossier et par quel utilisateur elles ont été faites.

Merci encore pour tout.

On a plus de soleil et de chaleur depuis hier...