Discussion :

[Chumbatta]

Je suis en train de lire l'ouvrage qu'a mentionné CinePhil - que je remercie au passage pour le lien donné. Je n'ai donc pas encore toutes les clés en main pour procéder correctement aux MCD, MLD, MPD.

Ceci dit, la table MLD que vous présentez JPhi33, comment pourrait-elle s'organiser dans SQL ? Je comprends que les cles 1_vet et age se retrouvent dans la table d'association 2_age. Là où je bloque, c'est le passage de ce modèle dans SQL...

Si on y effectue la création d'une table vet et d'une table age distinctes (plutôt qu'une colonne age dans la table vet, vu qu'il ne faut pas mettre plusieurs valeurs dans une même colonne), se rapprocherait-on d'une optimisation du SGBDR ? Or, si c'est oui, j'aurai donc une table age avec très peu de données (ce qui apparemment est en contradiction avec les préceptes indiqués pour élaborer une bdd, non ?) ; et toujours, si c'est oui, il faudra alors que je pige comment mettre en relation ces deux tables, ou plus exactement les données entre elles afin de reformer les correspondances que je souhaitais mettre en place. Si c'est non, euh... eh bien, ça se passerait comment alors ?

[Nohant]

Ceci dit, la table MLD que vous présentez JPhi33, comment pourrait-elle s'organiser dans SQL ? Je comprends que les cles 1_vet et age se retrouvent dans la table d'association 2_age. Là où je bloque, c'est le passage de ce modèle dans SQL...

Juste une précision SQL est le langage permettant de manipuler une base de donnée et non la base de donnée elle-même

[Chumbatta]

Juste une précision SQL est le langage permettant de manipuler une base de donnée et non la base de donnée elle-même

Oui, bien sûr, je ne l'entendais pas différemment, je faisais allusion au SGBD que je mentionnais plus bas. Désolé pour cette imprécision qui a été cause de confusion.

[JPhi33]

Bonjour,

Si on y effectue la création d'une table vet et d'une table age distinctes (plutôt qu'une colonne age dans la table vet, vu qu'il ne faut pas mettre plusieurs valeurs dans une même colonne), se rapprocherait-on d'une optimisation du SGBDR ?

Non, il ne s'agit pas d'une optimisation mais des règles normales de construction d'une BDD dans un SGBDR.

Or, si c'est oui, j'aurai donc une table age avec très peu de données (ce qui apparemment est en contradiction avec les préceptes indiqués pour élaborer une bdd, non ?)

D'où ces préceptes viennent-ils ? La construction d'une base de données ne préjuge pas de la volumétrie des données (nombre de lignes contenues à terme dans les tables), tout au moins dans les phases conceptuelle (MCD) et logique (identification des tables - MLD). Au niveau physique (MPD), on se préoccupe effectivement de cette volumétrie et on peut procéder à des optimisations mais pas avant.

et toujours, si c'est oui, il faudra alors que je pige comment mettre en relation ces deux tables, ou plus exactement les données entre elles afin de reformer les correspondances que je souhaitais mettre en place.

Prenons l'exemple déjà vu des vêtements et des âges et descendons la démarche complète jusqu'à obtention de la base de données.

1. Cahier des charges
Chaque type de vêtement s'adresse à une ou plusieurs catégories d'âge.

2. Dictionnaire des données

Code :

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

1
2
3
4
5
6
7
Code           Désignation                     Format
-------------- ------------------------------- -----------------
vetementType   Type de vêtement                littéral 50 car.
vetementTypeId Identifiant du type de vêtement numéro séquentiel
ageCateg       Catégorie d'âge                 littéral 20 car.
ageCategId     Identifiant de Catégorie d'âge  numéro séquentiel

3. MCD

[ TYPE_VETEMENT ]--1,n----( s'adresser )----0,n--[ CATEGORIE_AGE ]

avec (identifiants soulignés) :

TYPE_VETEMENT
vetementTypeId
vetementType

CATEGORIE_AGE
ageCategId
ageCateg

4. MLD

[TYPE_VETEMENT]<------[S_ADRESSER]------>[CATEGORIE_AGE]

avec (clés soulignées) :

TYPE_VETEMENT
vetementTypeId
vetementType

CATEGORIE_AGE
ageCategId
ageCateg

S_ADRESSER
vetementTypeId
ageCategId

5. MPD

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
 
CREATE TABLE TYPE_VETEMENT
(
   vetementTypeId   Int           NOT NULL,
   vetementType     Varchar(50)   NOT NULL,
   CONSTRAINT TYPE_VETEMENT_PK PRIMARY KEY (vetementTypeId)
) ;
 
CREATE TABLE CATEGORIE_AGE
(
   ageCategId   Int           NOT NULL,
   ageCateg     Varchar(20)   NOT NULL,
   CONSTRAINT CATEGORIE_AGE_PK PRIMARY KEY (ageCategId)
) ;
 
CREATE TABLE S_ADRESSER
(
   vetementTypeId   Int   NOT NULL,
   ageCategId       Int   NOT NULL,
   CONSTRAINT S_ADRESSER_PK PRIMARY KEY (vetementTypeId, ageCategId),
   CONSTRAINT S_ADRESSER_TYPE_VETEMENT_FK FOREIGN KEY (vetementTypeId)
      REFERENCES TYPE_VETEMENT (vetementTypeId),
   CONSTRAINT S_ADRESSER_CATEGORIE_AGE_FK FOREIGN KEY (ageCategId)
      REFERENCES CATEGORIE_AGE (ageCategId)
) ;

Dans le code SQL ci-dessus, les correspondances sont établies dans la table S_ADRESSER grâce aux contraintes de type FOREIGN KEY.
Voila comment la table S_ADRESSER permet de mettre en relation les types de vêtements et les catégories d'âge.

Exemple de contenu des tables :

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
TYPE_VETEMENT
vetementTypeId vetementType
-------------- ------------
             1 mini-jupe
             2 fourreau

CATEGORIE_AGE
ageCategId ageCateg
---------- ----------
         1 Jeune
         2 Adolescent
         3 Adulte
         4 Mûr


S_ADRESSER
vetementTypeId ageCategId
-------------- ----------
             1          1
             1          2
             1          3
             2          2
             2          3
             2          4

Ce n'est pas parce que la table CATEGORIE_AGE ne contient que 4 lignes qu'elle doit disparaître. Il s'agit d'une table de références, essentielle dans la gestion du système d'information. Grâce à elle, on pourra ajouter de nouvelles catégories d'âges (ex. : 5 Bébé), ou modifier le libellé d'une catégorie (ex. : changer Mûr en Senior) sans impact sur l'existant.

[Chumbatta]

D'où ces préceptes viennent-ils ? La construction d'une base de données ne préjuge pas de la volumétrie des données (nombre de lignes contenues à terme dans les tables), tout au moins dans les phases conceptuelle (MCD) et logique (identification des tables - MLD). Au niveau physique (MPD), on se préoccupe effectivement de cette volumétrie et on peut procéder à des optimisations mais pas avant.

Ah, cette étape d'optimisation de la volumétrie dans le MPD est une précieuse information ! Merci !

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE S_ADRESSER
(
   vetementTypeId   Int   NOT NULL,
   ageCategId       Int   NOT NULL,
   CONSTRAINT S_ADRESSER_PK PRIMARY KEY (vetementTypeId, ageCategId),
   CONSTRAINT S_ADRESSER_TYPE_VETEMENT_FK FOREIGN KEY (vetementTypeId)
      REFERENCES TYPE_VETEMENT (vetementTypeId),
   CONSTRAINT S_ADRESSER_CATEGORIE_AGE_FK FOREIGN KEY (ageCategId)
      REFERENCES CATEGORIE_AGE (ageCategId)
) ;

Cette partie code m'était inconnue. Bien qu'il soit plus judicieux d'apprendre SQL (mais je manque un peu de temps pour m'atteler à fond à ce langage), existe-t-il un outil ou une appli capable d'extraire automatiquement le MLD ?

Quant à cet exemple de démarche, franchement, un grand merci, j'y vois beaucoup plus clairement !

[CinePhil]

Tu modélises ta BDD avec un logiciel de modélisation tel que :
- PowerAMC ; la Rolls mais chère, disponible quand même en version d'évaluation je crois ;
- Open Modelsphere - assez complet et gratuit mais demande d'adapter les scripts SQL générés à ton SGBD.
- MySQL WorkBench - comme son nom l'indique est un outile dédié à MySQL et ne passe pas par l'étape MCD, on modélise directement en schéma Entity/Relations. L'avantage est qu'il te génère les scripts de création de la BDD aux petits oignons pour MySQL.

[Chumbatta]

Très bien CinePhil, je vais consulter ces logiciels, merci.

Pour info, je n'ai pas lu entièrement le livre que vous m'aviez indiqué (l'auteur spécifie d'ailleurs quels passages peuvent être écartés momentanément) mais j'ai bien évidemment concentré ma lecture sur la partie MCD. Elle contient des explications plus fournies, plus détaillées que celles d'autres documents que j'avais consultés. Mais, sur la forme, c'est parfois un peu confus, brouillon, avec des schémas qui chevauchent des analyses d'exemples sans rapport entre eux (cf. page 57-58). Les termes utilisés me semblent aussi désuets : on parle aujourd'hui d'entité et non pas d'individu, d'association réflexive - expression qui n'est pas employée pas dans l'ouvrage. Ou bien ces derniers sont-ils justement inappropriés ? Bon, ça, ce n'est pas très important. Par contre, j'ai quelques interrogations sur le fond. L'auteur prend l'exemple d'un message secret inclus dans l'entité Document et établit le modèle suivant (page 56) :
[document] ---1, n ---signer--- 0, n ---- personne

--- 0, n ---- rôle

Et je cite : "un rôle peut être utilisé en signant de zéro à N fois. Une occurrence de patte part de l'occurrence Emetteur (un rôle peut ne pas participer ou participer N fois à la relation signer)."
Je ne vois pas trop pourquoi un ROLE ne serait pas nécessairement indiqué dans la signature à partir du moment où le document existe. Quelle en est la justification ? Cela me laisse assez perplexe, d'autant qu'on ne sait pas trop de quoi parle l'auteur : que sont ces rôles "responsable, contrôleur, rédacteur", que faut-il comprendre par "message secret", dans quel cadre sommes-nous ? Comme c'est assez équivoque, pourquoi, dans ce cas, une association de type "occuper" avec PERSONNE ne pourrait-elle pas aussi exister de cette façon : ROLE ---1, n---jouer---1, n---PERSONNE ?

[JPhi33]

Je ne vois pas trop pourquoi un ROLE ne serait pas nécessairement indiqué dans la signature à partir du moment où le document existe. Quelle en est la justification ?

Il s'agit d'une règle de gestion du cas décrit. Il faut l'accepter telle quelle. Elle ne nécessite aucune justification. L'auteur montre comment la modéliser.

pourquoi, dans ce cas, une association de type "occuper" avec PERSONNE ne pourrait-elle pas aussi exister de cette façon : ROLE ---1, n---jouer---1, n---PERSONNE ?

Oui, c'est tout à fait possible mais il s'agit là d'une autre règle qui conduira probablement (il faudrait vérifier pour en être certain) à une autre modélisation.

[Chumbatta]

Je crois avoir obtenu les réponses à la plupart de mes interrogations, je remercie encore tous les participants qui ont eu la patience et l'amabilité d'avoir bien voulu consacré du temps à mon égard.