Conception UML, relations entre tables

Bonjour,

Je dois créer une base de donnée pour une société de courtage d'assurance. Je suis bloqué à un endroit :
Pièce jointe 634168

Un devis possède un niveau de garantie, un niveau de garantie possède 0 à plusieurs options et un devis peut avoir 0 à plusieurs options du niveau de garantie auquel il est lié.
Je ne sais pas comment forcer le fait qu'une option liée à un devis (ligne dans DevisAssuranceOption) soit forcément liée au même produit (ProduitNiveauGarantie) que le Devis.

Quelqu'un aurait-il une idée?

Merci d'avance!

UML est une notation totalement incomplète pour gérer une modèle relationnel de bases de données. Intéressez vous à Maris et aux contraintes du modèle.

A +

L'énoncé est incomplet : les associations ne sont décrites que dans un seul sens, or il faut décrire chaque sens.

Par exemple (en rouge, les précisions qui manquent dans l'énoncé et que j'ai complétées grâce à votre diagramme)

R001a : un devis inclus un et un seul niveau de garantie
R001b : un niveau de garantie est inclus dans zéro à plusieurs devis

R002a : une garantie propose zéro à plusieurs options
R002b : une option est proposée par une et une seule garantie

Il est donc inutile de créer une association entre devis et option, puisqu'une devis c'est une et une seule garantie, on obtient par transitivité les options concernées. On est donc dans un cas simple où il n'est pas nécessaire de mettre en oeuvre un contrainte.

S'il avait fallu utiliser une contrainte, je rejoins SQLPro : le formalisme Merise aurait été bien plus parlant que le formalisme UML.

Citation:

---

Envoyé par escartefigue

L'énoncé est incomplet : les associations ne sont décrites que dans un seul sens, or il faut décrire chaque sens.

[...]

Il est donc inutile de créer une association entre devis et option, puisqu'une devis c'est une et une seule garantie, on obtient par transitivité les options concernées. On est donc dans un cas simple où il n'est pas nécessaire de mettre en oeuvre un contrainte.

S'il avait fallu utiliser une contrainte, je rejoins SQLPro : le formalisme Merise aurait été bien plus parlant que le formalisme UML.

---

Merci de votre réponse. Oui en effet j'ai mal décrit ce que je devais faire (ce n'est pas un vrai énoncé).
Un devis peut inclure toutes les options d'un niveau de garantie, mais pas forcément. Du coup il faudrait que j'enregistre qu'elles options un devis possède mais comment?

Citation:

---

Envoyé par SQLpro

UML est une notation totalement incomplète pour gérer une modèle relationnel de bases de données. Intéressez vous à Maris et aux contraintes du modèle.

A +

---

Merise aurait pu en effet permettre de détailler tout ça, mais ce schéma est surtout fait pour moi-même et est temporaire (je ne souhaitais pas y passer trop de temps).

Citation:

---

Envoyé par stova

Merci de votre réponse. Oui en effet j'ai mal décrit ce que je devais faire (ce n'est pas un vrai énoncé).
Un devis peut inclure toutes les options d'un niveau de garantie, mais pas forcément. Du coup il faudrait que j'enregistre qu'elles options un devis possède mais comment?

---

Tout simplement comme ceci, selon le formalisme Merise :

Pièce jointe 634217


Ce qui donne selon le formalisme UML :

Pièce jointe 634216

L'option est une entité-type faible de la garantie, du coup elle est identifiée relativement à la garantie.
Ce faisant, la PK de l'option hérite de l'identifiant de la garantie il est donc très simple de vérifier que l'option sélectionnée pour le devis est bien une option proposée par la garantie ;)

cf. le script DDL produit pour le SGBD SQL Sever, on y voit bien la contrainte FOREIGN KEY dans la table SE_selectionner qui effectue cette vérification :
FOREIGN KEY(GA_ident, OP_seq) REFERENCES OP_option(GA_ident, OP_seq)
DDL complet :

Code:

---

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

CREATE TABLE GA_garantie( GA_ident INT IDENTITY, GA_code CHAR(6) NOT NULL, GA_libelle VARCHAR(128) NOT NULL, PRIMARY KEY(GA_ident), UNIQUE(GA_code) );   CREATE TABLE OP_option( GA_ident INT, OP_seq SMALLINT, OP_libelle VARCHAR(50) NOT NULL, PRIMARY KEY(GA_ident, OP_seq), FOREIGN KEY(GA_ident) REFERENCES GA_garantie(GA_ident) );   CREATE TABLE DE_devis( DE_ident INT IDENTITY, DE_numero CHAR(8) NOT NULL, DE_date DATE NOT NULL, GA_ident INT NOT NULL, PRIMARY KEY(DE_ident), UNIQUE(DE_numero), FOREIGN KEY(GA_ident) REFERENCES GA_garantie(GA_ident) );   CREATE TABLE SE_selectionner( DE_ident INT, GA_ident INT, OP_seq SMALLINT, PRIMARY KEY(DE_ident, GA_ident, OP_seq), FOREIGN KEY(DE_ident) REFERENCES DE_devis(DE_ident), FOREIGN KEY(GA_ident, OP_seq) REFERENCES OP_option(GA_ident, OP_seq) );

---

Citation:

---

Envoyé par escartefigue

Tout simplement comme ceci, selon le formalisme Merise :

[...]

L'option est une entité-type faible de la garantie, du coup elle est identifiée relativement à la garantie.
Ce faisant, la PK de l'option hérite de l'identifiant de la garantie il est donc très simple de vérifier que l'option sélectionnée pour le devis est bien une option proposée par la garantie ;)

cf. le script DDL produit pour le SGBD SQL Sever, on y voit bien la contrainte FOREIGN KEY dans la table SE_selectionner qui effectue cette vérification :
FOREIGN KEY(GA_ident, OP_seq) REFERENCES OP_option(GA_ident, OP_seq)[...]
[/CODE]

---

Merci ça semble résoudre le problème.
Saurais-tu par hasard comment réaliser cette configuration avec Doctrine?

Non, je ne connais pas "doctrine", mais si c'est un outil de modélisation, vous pouvez télécharger l'excellent "Looping" avec lequel j'ai réalisé les schémas communiqués précédemment. Son apprentissage est très intuitif et il est performant et gratuit :ccool:

Doctrine est un ORM PHP, il n'a donc pas grand chose à voir avec un outil de modélisation tel que Looping. Une fois votre modèle complet et le SQL correspondant généré, vous pouvez utiliser l'approche Database First de Doctrine pour générer le mapping correspondant en PHP, mais c'est une toute autre problématique ( et dans une autre partie du forum) que la correcte modélisation de votre problème.

Quelques pistes pour commencer tout de même :

• Getting Started - Database First
• Association Mapping

Citation:

---

Envoyé par Chou-ette

Doctrine est un ORM PHP, il n'a donc pas grand chose à voir avec un outil de modélisation tel que Looping. Une fois votre modèle complet et le SQL correspondant généré, vous pouvez utiliser l'approche Database First de Doctrine pour générer le mapping correspondant en PHP, mais c'est une toute autre problématique ( et dans une autre partie du forum) que la correcte modélisation de votre problème.

Quelques pistes pour commencer tout de même :

• Getting Started - Database First
• Association Mapping

---

Merci de votre réponse. Si je souhaite continuer le sujet en intégrant Doctrine au problème, mieux vaut-il que je recréer un sujet? Ou je peux continuer ici?

Si les autres questions concernent la modélisation des données, elles ont leur place ici, si elles concernent PHP ou Doctrine, il faut les poser dans un nouveau sujet ouvert dans le forum ad hoc