MCD correspondant à UML avec héritage et composition [Résolu]

thomine · 18/06/2011, 19h14

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 · 19/06/2011, 16h33

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 · 22/06/2011, 21h19

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 · 23/06/2011, 00h43

Bonjour thomine,

Citation:

Envoyé par thomine

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

Oui.

Citation:

Envoyé par thomine

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).

Citation:

Envoyé par thomine

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.

Citation:

Envoyé par thomine

IdB permet de faire le lien entre toutes les tables.

Oui.

Citation:

Envoyé par thomine

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

Oui.

Citation:

Envoyé par thomine

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 · 08/07/2011, 11h21

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 !

18/06/2011, 19h14	#1
thomine Nouveau Membre du Club Inscription : octobre 2004 Messages : 92 Détails du profil Informations forums : Inscription : octobre 2004 Messages : 92 Points : 33 Points : 33	MCD correspondant à UML avec héritage et composition 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 !
	00

19/06/2011, 16h33	#2
fsmrel Expert Confirmé Sénior Spécialiste en bases de données Inscription : septembre 2006 Messages : 2 883 Détails du profil Informations professionnelles : Activité : Spécialiste en bases de données Secteur : Conseil Informations forums : Inscription : septembre 2006 Messages : 2 883 Points : 5 117 Points : 5 117	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). __________________ _ Faites simple, mais pas plus simple ! (A. Einstein) E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire ») => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale ») __________________ Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)
	10

22/06/2011, 21h19	#3
thomine Nouveau Membre du Club Inscription : octobre 2004 Messages : 92 Détails du profil Informations forums : Inscription : octobre 2004 Messages : 92 Points : 33 Points : 33	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 !
	00

08/07/2011, 11h21	#5
thomine Nouveau Membre du Club Inscription : octobre 2004 Messages : 92 Détails du profil Informations forums : Inscription : octobre 2004 Messages : 92 Points : 33 Points : 33	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 !
	10

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email