Discussion :

[thomine]

Bonjour,

Voici un diagramme UML avec 4 classes :

• B est abstraite
• C hérite de B
• D hérite de B
• C est composée de 0 à N B

Il existe pas mal de façon de modéliser le schéma de base de données correspondant.
J'aurais tendance à ne créer que 3 tables (A, C et D), mais je trouve que ça fait pas mal de clés étrangères qui seront parfois vides...
Quelle serait votre proposition de schéma de BD ?
Par avance, merci pour votre aide !

[fsmrel]

Bonjour thomine,


Une proposition :

Du point de vue de la théorie relationnelle (ou Modèle Relationnel de Données), B mérite de faire l’objet d’une variable relationnelle (relvar, dont la table SQL est un avatar). En effet, cette théorie ne peut s’accommoder du bonhomme NULL, dont on se débarrassera en procédant ainsi. Par ailleurs, a vue de nez, votre système a un côté nomenclature prononcé, d’où le diagramme logique que je vous propose :




Selon votre diagramme de classes, seul un objet C peut être composé. En conséquence, la contrainte (exprimée en Tutorial D) signifie : Une valeur de l’attribut IdbParent de la table N ne peut pas être une valeur de l’attribut IdB de la table D.
Si vous utilisez SQL, la contrainte fera l’objet d’une assertion (ou d’un trigger si votre SGBD ne connaît pas l’instruction CREATE ASSERTION).

[thomine]

Bonjour fsmrel et merci pour votre réponse intéressante.
J'ai tardé à répondre mais j'avoue avoir eu du mal à bien comprendre les explications, certaines notions me faisant défauts (avatar, bonhomme null, nomenclature prononcée...) .
Bref, en étudiant plus attentivement le schéma, je crois avoir compris la logique. Pour reformuler avec mes mots :

• Comme dans le modèle objet, B permet essentiellement de gérer les attributs communs à C et D.
• N permet de gérer la composition et la relation parent / enfant entre C et B. On aurait pu mettre le champ IdBParent dans la table B mais si je comprends bien on crée cette table pour éviter d'avoir des null.
• IdB permet de faire le lien entre toutes les tables.
• La contrainte permet de vérifier qu'un objet D n'a pas d'enfant.

Merci de me corriger si je me trompe...
En tout cas je n'aurais pas pensé à cette solution qui me plait bien, la mienne étant plus basique et moins élégante.
Si quelqu'un a une autre solution et souhaite contribuer, je suis preneur !

[fsmrel]

Bonjour thomine,

Comme dans le modèle objet, B permet essentiellement de gérer les attributs communs à C et D.

Oui.

N permet de gérer la composition et la relation parent / enfant entre C et B.

Oui, mais D est traité exactement comme C (symétrie parfaite, d’où la nécessité de la contrainte, permettant de garantir la dissymétrie apparaissant dans votre diagramme de classes).

On aurait pu mettre le champ IdBParent dans la table B mais si je comprends bien on crée cette table pour éviter d'avoir des null.

Oui. Un SGBD relationnel digne de ce nom utilise un optimiseur qui est un système expert, donc basé sur la logique et qui utilise des tables de vérité. Mais le bonhomme NULL vient ficher la zoubia dans tout ça, c’est un inhibiteur d’optimiseur. Recherchez "tables de vérité" dans le message où Naf-Naf est à l’ouvrage.

N.B. Attention au vocabulaire, le terme champ est disqualifié. En SQL on utilise celui de colonne et en Tutorial D (conforme à la théorie relationnelle), on utilise le terme attribut.

IdB permet de faire le lien entre toutes les tables.

Oui.

La contrainte permet de vérifier qu'un objet D n'a pas d'enfant.

Oui.

j'avoue avoir eu du mal à bien comprendre les explications, certaines notions me faisant défauts (avatar, bonhomme null, nomenclature prononcée...)

Attention, ça n’est pas la nomenclature qui est prononcée, mais le côté... Je voulais dire qu’on subodore que votre système héberge une nomenclature...

Si vous avez des questions sur le reste, n’hésitez pas à les poser.


Bonne route !

[thomine]

Bonjour fsmrel.
Je n'avais pas encore vu ta réponse. Merci beaucoup pour ces explications très complètes et instructives (la modélisation d'une BD, ça s'improvise pas !) et le temps passé.
Les explications sont claires, je passe en résolu !