Discussion :

[KristofNancy]

Bonjour
Voila un résumé de ce que je veux faire : Dans une entreprise, les salariés peuvent bénéficier de plusieurs prestations que ce soit à leur titre ou au titre de certains de leurs enfants (mineurs en l'occurence). Mais tous les enfants sont dans la base.
Voici le modèle que j'ai fait
Mais j'avoue que cela bien longtemps que je n'en ai réalisé. J'ai l'impressiosn qu'il n'est pas bon (on peut passer de salariés à prestations de 2 façons: notion de transitivé je crois)


Alors si quelqu'un pouvait me donner une idée car c'est la clé de départ de mon modèle
Merci

[Soutou]

Ton schéma est presque bon totalement, je mettrai 0,1 côté Prestations car une prestation sera ou pour un salarié ou au titre d'un enfant.
Entre les 2 associations liées à Prestation, il faudrait mettre une contrainte de partition qui dit qu'il n'existe aucune prestation pas reliée, et aucune reliée à la fois à salarié et enfant en même temps.

[KristofNancy]

je crois que je dois garder 11 entre la prestation et l'agent. Parce que même si elle est du au titre d'un enfant, elle doit être reliée à l'agent car c'est à lui qu'elle va être payée.
Je donne un exemple : la participation de l'entreprise aux activités de l'agent et des enfants.

[Soutou]

Mais non car si tu connais l'enfant tu connais le parent : tu as mis (1,1) en identifiant relatif. Mais ça enlève la contrainte de partition par contre.

[JPhi33]

Pour moi, les deux modélisations sont possibles. Elles proposent une perception de la réalité aussi valable l'une que l'autre.

Celle de Soutou est correcte à condition, comme il le précise, d'ajouter une contrainte de partition (toute prestation est obligatoirement perçue et ce, soit par un salarié, soit par un enfant). Dans le cas d'une prestation perçue au titre d'un enfant, on connait le salarié par la connaissance de l'enfant qui perçoit la prestation.

Celle de KristofNancy est correcte : une prestation est toujours perçue par un salarié. Lorsqu'il la perçoit au titre d'un de ses enfant, c'est l'association "Percevoir au titre de" qui permet de le savoir et qui indique au titre de quel enfant elle est perçue.
Par contre, il est impératif de rajouter une contrainte d'inclusion de "Percevoir au titre de" dans "Percevoir" pour garantir que c'est l'un des enfants du salarié qui est concerné et non pas l'enfant d'un autre salarié. Sans cette contrainte rien n'empêcherait le cas suivant :

Prestation1 --> Salarié1
Prestation1 --> Enfant21 --> Salarié2



Encore une preuve qu'il n'y a pas de vérité absolue en matière de modélisation statique de SI.

JPhi33

[KristofNancy]

Bonsoir,
Merci pour vos infos. Effectivement je tiens à garder la relation 11 pour "percevoir" car je veux un lien entre mon agent qui perçoit toutes les prestations.
Concernant les contraintes de partition et d'inclusion, je ne connais pas . J'utilise Merise et à priori c'est du merise modèle 2. J'ai cherché sur le net mais si vous pouviez m'en dire plus.
Par exemple si on fait figurer ces contraintes avec un outil qui les propose. Que se passe t'il lors de la génération du mpd et des srcipts ?
Moi j'ai modilisé avec power amc qui ne propose pas tout cela.

[fsmrel]

Concernant les contraintes de partition et d'inclusion, je ne connais pas . J'utilise Merise et à priori c'est du merise modèle 2. J'ai cherché sur le net mais si vous pouviez m'en dire plus.
Par exemple si on fait figurer ces contraintes avec un outil qui les propose. Que se passe t'il lors de la génération du mpd et des srcipts ?
Moi j'ai modilisé avec power amc qui ne propose pas tout cela.

Il est vrai que les contraintes de partitionnement et d’inclusion font quelque part partie de Merise 2. Mais vous utilisez Power AMC : étant donné que cet outil ne connaît pas ces contraintes, une façon de vous en sortir consiste alors à ne pas utiliser la notation Merise mais la notation Entité/Relation qui permet au moins de résoudre facilement la contrainte d’inclusion, à condition d’intervenir "un petit peu" au niveau MLD.

Pour commencer, vous identifiez Prestation relativement à Salarié. En effet, une prestation sans salarié en face n’a pas grande signification, même si celle-ci est perçue au bénéfice de l’enfant du salarié.

Dans un 2e temps, puisque le MCD fera l’objet d’un MLD et qu’un défi majeur est de ne pas générer de valeurs nulles parce qu’elles sont bannies de la théorie relationnelle (quoi que puissent en dire ceux qui ne connaissent pas les méfaits de la logique trivaluée), notamment concernant les clés étrangères, vous définirez une entité-type associative entre Prestation et Enfant (appelons-la, par exemple, PrestationEnfant). Cette entité-type associative est dépourvue d'attributs.

Vous noterez que l’onglet Détail de la relation entre Prestation et PrestationEnfant comporte une option "Rôle dominant" : vous retiendrez "Prestation -> PrestationEnfant", ce qui évitera une 1re redondance de clés étrangères lors de la dérivation du MCD. Ceci est matérialisé par le symbole "(D)" au dessus du lien entre Prestation et PrestationEnfant.

MCD résultant :




Dans un 3e temps, vous interviendrez au niveau du MLD pour résoudre le problème évoqué à juste titre par Jphi33, et empêcher la situation :

Prestation1 --> Enfant21 --> Salarié2

C'est-à-dire que, dans la table PrestationEnfant, vous éliminerez manuellement une des deux colonnes redondantes SalarieId pour n’en conserver qu’une.

MLD :




Le résultat SQL doit ressembler à ceci :

Code :

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
Create Table Salarie (
   SalarieId            Int                  Not null,
   Nom                  Varchar(48)          Not null,
   Constraint Salarie_PK Primary Key  (SalarieId)
)
;

Create Table Prestation (
   SalarieId            Int                  Not null,
   PrestationId         Smallint             Not null,
   Montant              Int                  Not null,
   Constraint Prestation_PK Primary Key  (SalarieId, PrestationId),
   Constraint Prestation_Salarie_1 Foreign Key (SalarieId)
      References Salarie (SalarieId)
)
;

Create Table Enfant (
   SalarieId            Int                  Not null,
   EnfantId             Smallint             Not null,
   Nom                  Varchar(48)          Not null,
   DateNaissance        Char(10)             Not null,
   Constraint Enfant_PK Primary Key  (SalarieId, EnfantId),
   Constraint Enfant_Salarie_1 Foreign Key (SalarieId)
      References Salarie (SalarieId)
         On Update cascade
)
;

Create Table PrestationEnfant (
   SalarieId            Int                  Not null,
   PrestationId         Smallint             Not null,
   EnfantId             Smallint             Not null,
   Constraint PrestationEnfant_PK Primary Key  (SalarieId, EnfantId),
   Constraint PrestationEnfant_Enfant_1 Foreign Key (SalarieId, EnfantId)
      References Enfant (SalarieId, EnfantId),
   Constraint PrestationEnfant_Prestation_2 Foreign Key (SalarieId, PrestationId)
      References Prestation (SalarieId, PrestationId)
         On Delete Cascade
)
;

Good luck!

[KristofNancy]

Merci pour toutes ces informations.
Je ne connais pas trop le modèle entité relation mais surtout je dois présenter un modèle Merise dans mon dossier de Conception générale. Ceci dit je pense m'en sortir. Surtout que je viens d'obtenir une règle qui semble me faciliter la tâches. L'enfant n'existe en base que s'il y a prestation. Il y a donc plutot une notion de client qui englobe les agents et les enfants (et pourquoi pas le conjoint ultérieurement). je verrais bien la dépendance
Agents ----> Clients ----> Prestations.

Par contre , ce qui me gêne c'est que je reviens d'une formation J2EE : et la on m'a parlé de notion de clé métier et de clé base de donnée. la clé métier est la clé style identifant, etc... et la clé base de donnée c'est une clé unique numérique style identity . Il parait c'est ce qu'il faut faire maintenant et surtout ne pas avoir de clé primaire composée et ne pas avoir de chaines de caractères dans une clé etc....
Qu'en pensez vous?

[fsmrel]

ce qui me gêne c'est que je reviens d'une formation J2EE : et la on m'a parlé de notion de clé métier et de clé base de donnée. la clé métier est la clé style identifant, etc... et la clé base de donnée c'est une clé unique numérique style identity . Il parait c'est ce qu'il faut faire maintenant

Je reprends un exemple dont je me sers de temps en temps : il s’agit du système préconisé par les concepteurs dans une très grande banque pour identifier les entreprises : leur numéro Siren, fourni par un organisme extérieur, à savoir l’INSEE. Ce Siren était propagé dans toute la base de données par le jeu des liens clé primaire - clé étrangère. Les concepteurs avaient prévu une énorme usine à gaz pour maintenir la cohérence, parce que l’INSEE envoyait tous les mois les nombreux correctifs modifiant les numéros de Siren erronés. Je leur suggérai que l’identifiant de l’entreprise fît l’objet d’une propriété nouvelle et artificielle, invariante et sans signification, EntrepriseId, le numéro Siren devenant une propriété comme une autre mais conservant sa spécificité : être unique et pouvant subir toutes les avanies de la part de l’utilisateur. Au niveau SQL, l’ex clé primaire, le numéro Siren devint clé alternée, point d'entrée dans la table, permettant à l'utilisateur d’accéder aux données de chaque entreprise, la suite des opérations se passant de façon transparente, encapsulée pour utiliser un jargon à la mode, grâce à la nouvelle clé primaire EntrepriseId : du point de vue de l’utilisateur et des règles fonctionnelles, rien de changé, mais l’usine à gaz disparut en fumée et tout le monde fut content.

ne pas avoir de chaines de caractères dans une clé

Comme je l’ai dit ci-dessus, une clé primaire doit être invariante et non significative. Sinon, que l’on ait des chaînes de caractères ou des nombres, peu importe (sauf évidemment à ne pas définir des clés alphanumériques de taille exagérée, afin de ne pas provoquer d’inflation dans la hauteur des arbres des index et un encombrement gênant). Les gens qui recommandent d’éviter le type chaîne des caractères sont sans doute psychorigides, superstitieux ou répètent ce que qui se dit au café du commerce (depuis fort longtemps !)

surtout ne pas avoir de clé primaire composée.

Qu’entendez-vous par clé primaire composée ? Je vais supposer que vous faites référence aux clés comportant plus d’un attribut. Prenons le cas de la commande et de la ligne de commande faisant l’objet respectivement d’une table Commande et d’une table LigneCommande. La seconde n’est jamais qu’une propriété multivaluée de la première, autrement dit l’identifiant de LigneCommande est relatif à celui de commande. De la même façon si une ligne de commande se décline en engagements sur ligne de commande, on aura une table Engagement identifiée relativement à LigneCommande, etc. Dans toute cette affaire, il y a un élément "racine" toujours présent dans les clés de ces tables, à savoir l’identifiant de Commande (voire l’identifiant de Client, si l’on souhaite remonter en amont, ce qui est mon cas...) S’agit-il d’un caprice de ma part ? Suis-je superstitieux ? Est-ce que je marche à l’émotion ? En réalité, j’ai tiré les leçons de l’expérience, après avoir transpiré dans la soute, dans les tréfonds de l’étude de la performance des "very large" bases de données.

Voici ce que j’ai déjà écrit ici :
"Je peux vous garantir que lorsqu’on manipule par jointure des tables comportant des dizaines de millions de lignes, la présence d’une clé "racine" est déterminante. Imaginez un ensemble de tables : Commande, Ligne de commande, Engagement sur ligne de commande, Partie de commande livrable, tel que chaque table corresponde à une propriété multivaluée d’une autre (entité forte / entité faible). Si je propage en cascade le n° de commande, alors je ne connaîtrai pas l’angoisse de "l’I/O bound" (processeur au chômage technique pour cause d’attente de fin de lecture/écriture sur disque). Les lignes de commande d’une commande se trouveront physiquement dans une même page (ou des pages contiguës), même chose pour les engagements et les parties livrables. En une seule entrée/sortie, on récupère un maximum de données et les temps de traitement (batch ou TP lourd) sont divisés par 10 (pour fixer un ordre de grandeur moyen). Évidemment pouvoir agir ainsi dépend du SGBD, mais pour le plus puissant d’entre eux, DB2, les résultats sont spectaculaires et donc j’use sans modération de l’identification relative au niveau conceptuel pour que l’AGL propage la clé racine (en l’occurrence celle de la table commande) jusqu’au tréfonds de la plus petite des poupées russes (Partie de commande livrable). Je n’ai jamais été déçu par l’identification relative quant à son impact sur la rapidité d’exécution des requêtes."

Bref, ceux qui préconisent qu’un identifiant ne doit pas comporter plus d’un attribut feraient bien d’aller passer une nuit ou deux dans la soute, y compter les "I/O bound". Ils pourraient changer d’avis.

[KristofNancy]

Bonjour
En tout cas merci pour toutes vos infos et arguments qui sont , on ne peut plus clairs et convaincants.
J'ai débuté sur du gros systèmes mais plutot bases hierarchiques (Bull IDS2) pour passer par le client serveur et BD relationnelles pour arriver à l'INET maintenant. J e me rends compte que les expressions changent (encapsultation comme vous le dites, classes métiers, classes persistantes), les modes aussi .

Code :

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

Qu’entendez-vous par clé primaire composée ? Je vais supposer que vous faites référence aux clés comportant plus d’un attribut

Oui c'est tout a fait cela : un client qui commande différents produits : le N° de client se propageant sur la table commande et ligne, le N° de commande (s'il est géré au niveau du client) se propageant sur la table ligne (donc ici , 3 attributs pour la clé primaire).

[fsmrel]

Bonjour,

Je me rends compte que les expressions changent (encapsultation comme vous le dites, classes métiers, classes persistantes), les modes aussi.

Eh oui... Mais les modes de pensée du passé refont surface : les pointeurs (qui n'ont aucun sens dans le cadre du modèle relationnel dont le paradigme est le quoi,) sont à nouveau à l'honneur. Vous qui avez pratiqué IDS2 (pour ma part c'était son frère de lait IDMS) vous saurez jongler avec, même s'ils ne s'appellent plus NEXT, PRIOR, OWNER et si le set est déguisé en une sorte de path. Allons-y, naviguons et suivons sagement les pointeurs pour retrouver une par une les prestations des salariés...