Discussion :

[ecarbill]

Bonjour. Je suis en train de modéliser une gestion de matériels selon les règles suivantes :
R01 : Chaque matériel peut avoir plusieurs unités de mesure
R02 : Les matériels peuvent être stocker dans un ou plusieurs magasins
R03 : Chaque matériel peut être classé dans une catégorie
R04 : Les entrées et sorties de matériels sont autorisées par un gestionnaire
R05 : Chaque agent formule son besoin (demande de matériel)
R06 : Chaque sortie de matériel se fait au profit d’un agent
R07 : Une sortie n’est pas forcément liée à une demande

Je vous présente ci-joints ma première esquisse pour avoir votre avis:

Le MCD


et le MPD



Exéllente journée à vous

[escartefigue]

Bonjour escarbill

Des règles de gestion ont été formulées, c'est très bien, il faut bien entendu les compléter : chaque "patte" d'association doit être justifiée par une règle, et il peut y avoir des règles supplémentaires.
Par contre, ce qui me gêne, c'est que le vocabulaire employé dans les règles n'est pas le même que celui employé dans le MCD. Du coup on s'y perd.
Par exemple, dans les règles, il est question de "matériel", mais cette notion n'apparaît pas dans le MCD. Je suppose que "Materiel" et "Article" sont en réalité le même individu, mais en ce cas, il est nettement préférable de ne conserver qu'un seul des deux termes.
Même combat pour les "agents" des règles de gestion, s'agit-il des "gestionnaires" du MCD, des "personnes", d'autre chose ?

Pour les associations n-aires qui deviennent des tables, l'usage est plutôt d'utiliser un verbe à l'infinitif, par exemple (convertir) plutôt que (conversion).
Parfois on a un peu de mal à trouver autant de verbes distincts que nécessaires, c'est là qu'un dictionnaire des synonymes s'avère parfois utile .

Pour le reste, ça semble être pas mal du tout, sous réserve de compléter les règles de gestion bien entendu

EDIT : je constate en relisant que certaines entité-type n'ont pas d'identifiant, par exemple [DIRECTION], [SERVICE]

Par ailleurs le type d'entité [RATTACHEMENT] nécessite des explications

[ecarbill]

Bonsoir escartefigue et merci pour le temps accordé à mon post
Pour les observations relatives à l'utilisation de verbes, ou d'harmonisation des nom, je vais m'y atteler

EDIT : je constate en relisant que certaines entité-type n'ont pas d'identifiant, par exemple [DIRECTION], [SERVICE]
Par ailleurs le type d'entité [RATTACHEMENT] nécessite des explications

- En fait une Direction est subdivisée en Sous-Directions eux-mêmes subdivisés en Service.
- Un agent peu être affecté directement à la direction (Par exemple Le directeur, ou la secrétaire du directeur sont rattachés directement à la direction, sans être liés à aucune sous-direction)

Donc en fait j'ai utilisé l'entité [RATTACHEMENT] juste comme un distributeur d'identifiant car ce sont les identifiants de [RATTACHEMENT] qui deviennent identifiant dans [DIRECTION], [SOUSDIRECTION], [SERVICE].

Merci

[escartefigue]

Comme un rattachement peut avoir plusieurs directions, plusieurs sous-directions et plusieurs services, l'identifiant du rattachement seul ne suffit pas.
Avec l'identification relative (matérialisée par les parenthèses dans power-AMC), il faut ajouter un complément à l'identifiant hérité du rattachement.

Par exemple, pour l'entité-type [DIRECTION] on ajoutera un chrono DIR_CHRONO (un entier court suffira très probablement) et au niveau MLD, on aura une table DIRECTION dont la PK sera composée du duo RATTACH_ID + DIR_CHRONO.

Par ailleurs, comme il y a des associations distinctes entre [RATTACHEMENT] et [DIRECTION] d'une part et [RATTACHEMENT] et [SOUS_DIRECTION] d'autre part, on peut établir des associations avec une sous-direction sans rapport avec la direction, est-ce bien ce qui est souhaité ? J'en doute...
Par exemple, votre shéma autorise
RATT_1 ----> DIRECTION_1
...└----------> SOUS_DIRECTION_A ---> DIRECTION_2
Plus probablement, il ne faudrait établir qu'une association entre [RATTACHEMENT] et [SOUS_DIRECTION] , le lien avec la [DIRECTION] se faisant uniquement depuis la [SOUS_DIRECTION].

[ecarbill]

Plus probablement, il ne faudrait établir qu'une association entre [RATTACHEMENT] et [SOUS_DIRECTION] , le lien avec la [DIRECTION] se faisant uniquement depuis la [SOUS_DIRECTION].

:
Cela serait bon si tout agent était rattaché au niveau le plus bas. Mais j'ai expliqué plus haut que par exemple la secrétaire du directeur n'est dans aucune sous-direction, mais elle est rattaché directement à la direction. Donc on est obliger d'avoir une association avec la direction.
De la même façon, la secrétaire d'un sous-directeur est rattaché à la sous-direction, mais n'est rattaché à aucun service.

Comme un rattachement peut avoir plusieurs directions, plusieurs sous-directions et plusieurs services

: En principe un rattachement c'est soit une direction, soit une sous-direction, soit un service. J'ai peut-etre mal modélisé sinon j'essayais de faire comme dans cette discution


Merci

[ecarbill]

En principe un rattachement c'est soit une direction, soit une sous-direction, soit un service. J'ai peut-etre mal modélisé sinon j'essayais de faire comme dans cette discution

Y a t-il quelque chose a changer dans les cardinalités pour que ca marche ?

[escartefigue]

D'après votre MCD, l'entité-type [RATTACHEMENT] ne possède aucun attribut à part son identifiant.
C'est donc une entité-type fictive.
De plus, comme une personne n'est liée qu'à un seul rattachement, mais qu'un rattachement peut être lié à plusieurs directions, une personne peut donc par transitivité être liée à plusieurs directions. Ce qui ne convient pas.

La solution est de faire disparaître l'entité-type fictive [RATTACHEMENT] et de faire 3 associations avec une contrainte de partition (=exclusion + totalité) entre elles.

Ce qui donne le MCD ci-dessous que j'ai réalisé avec Looping, n'ayant pas Power-AMC sous la main :



Et ce MCD produit le script suivant (ici décliné pour SQL server que j'ai choisi arbitrairement) :
Notez la contrainte check en fin de script qui permet de vérifier la partition

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
CREATE TABLE DIR_direction(
   DIR_ident INT IDENTITY,
   DIR_code CHAR(4) NOT NULL,
   DIR_libelle VARCHAR(128) NOT NULL,
   PRIMARY KEY(DIR_ident),
   UNIQUE(DIR_code)
);
 
CREATE TABLE SDI_sous_direction(
   DIR_ident_SDI INT,
   SDI_chrono SMALLINT,
   SDI_code CHAR(6),
   SDI_libelle VARCHAR(128) NOT NULL,
   PRIMARY KEY(DIR_ident_SDI, SDI_chrono),
   UNIQUE(SDI_code),
   FOREIGN KEY(DIR_ident_SDI) REFERENCES DIR_direction(DIR_ident)
);
 
CREATE TABLE SVC_service(
   SVC_ident INT IDENTITY,
   SVC_code CHAR(6) NOT NULL,
   SVC_libelle VARCHAR(128) NOT NULL,
   DIR_ident_SDI INT NOT NULL,
   SDI_chrono SMALLINT NOT NULL,
   PRIMARY KEY(SVC_ident),
   UNIQUE(SVC_code),
   FOREIGN KEY(DIR_ident_SDI, SDI_chrono) REFERENCES SDI_sous_direction(DIR_ident_SDI, SDI_chrono)
);
 
CREATE TABLE PRS_personne(
   PRS_ident INT IDENTITY,
   PRS_nom VARCHAR(50) NOT NULL,
   PRS_prenom VARCHAR(50) NOT NULL,
   SVC_ident INT,
   DIR_ident_SDI INT,
   SDI_chrono SMALLINT,
   DIR_ident INT,
   PRIMARY KEY(PRS_ident),
   FOREIGN KEY(SVC_ident) REFERENCES SVC_service(SVC_ident),
   FOREIGN KEY(DIR_ident_SDI, SDI_chrono) REFERENCES SDI_sous_direction(DIR_ident_SDI, SDI_chrono),
   FOREIGN KEY(DIR_ident) REFERENCES DIR_direction(DIR_ident)
);
 
alter table PRS_personne 
add constraint PRS_CHK_RATT    
check (   (DIR_ident is not null and DIR_ident_sdi is null and SVC_ident is null)
       or (DIR_ident is null and DIR_ident_sdi is not null and SVC_ident is null)
       or (DIR_ident is null and DIR_ident_sdi is null and SVC_ident is not null))

[ecarbill]

Bonjour escartefigue,
Et merci pour le temps accordé pour réfléchir a mon problème.
Je vais faire un peu de lecture pour voir comment mettre en œuvre la contrainte de partition sous PowerAMC.

Par contre je ne saisi pas très bien le de SD_Chrono, et pour ce chrono n'est pas dans Direction ni dans Service ?

Excellente journée à vous

[escartefigue]

Concernant SDI_chrono :
J'ai considéré qu'une sous-direction ne pouvait pas exister sans sa direction de rattachement : si la direction disparait, ses sous-directions disparaissent aussi. C'est pourquoi j'ai identifié la sous-direction relativement aux directions (R) près des cardinalités.
Ce faisant, au niveau tabulaire, la PK de la sous-direction est composée de l'identifiant de la direction et d'un chrono, qui n'est pas unique pris seul, mais qui l'est pour une direction.
À l'inverse, j'ai considéré qu'un service survivait si une direction disparaissait, qu'il serait en ce cas rattaché à une autre direction en passant par une autre sous-direction.

Concernant la mise en oeuvre des contraintes avec Power-AMC :
il y a quelques années que je n'ai plus utilisé ce logiciel payant, mais de mémoire, les contraintes déclarées dans le MCD ne produisent aucun script SQL.
Il faut donc coder le script après avoir généré le DDL.
Sur ce point, Looping est bien plus pratique, puisqu'on peut coder le script dans l'objet contrainte du MCD

N'hésitez pas à voter pour les réponses qui vous ont mis sur la voie

[ecarbill]

Merci infiniment pour ces précieux conseils

[escartefigue]

N'oubliez pas de compléter les règles de gestion (à minima une par "patte" d'association) pour justifier l'ensemble du MCD