Discussion :

[azzazzelleio]

salut ... voila mon MCD aider moi a le corriger parce que lorsque je génère la base de données les tables clients filles (client ordinaire et client conventionner) n'accepte pas l'insertion des données a cause de problème de clé Étrangère référencé vers la table parent client ....... comment corriger ce problème.

[CinePhil]

Bonjour

Vous avez un héritage de données de Client vers Client_conventionne et vers Client_ordinaire.

1) Je ne vois pas trop l'utilité de Client_ordinaire puisque cette entité-type ne contient aucun attribut et n'a pas d'association particulière.

2) La génération de votre BDD a donc du créer les tables Client_conventionne et Client_ordinaire avec, chacune, une colonne clé étrangère référençant Client.Num_cl.
Lors de l'insertion des données dans Client_conventionne, vous devez fournir à la colonne clé étrangère une valeur existant dans la table Client. Faute de quoi vous obtenez une erreur.

Il faut donc d'abord insérer les données de la table Client, récupérer l'identifiant créé lors de l'insertion puis utiliser cet identifiant pour insérer les données dans Client_conventionne.

J'explique sur mon blog la démarche avec une procédure pour MySQL et pour Postgresql que vous pourrez adapter à votre cas.

[escartefigue]

Bonjour,

Tout à fait d'accord avec les remarques de Cinéphil.
Je précise que vous avez oublié de définir l'identifiant primaire de l'entité-type client (absence de rectangle typé "pi" en bas de l'entité-type), c'est certainement la cause de votre erreur

Et j'ajoute que vous devriez également choisir un autre type de données que du Varchar pour vos identifiants (cf. facture, contrat et réduction).
Le Varchar est ce qu'on peut choisir de pire pour un identifiant primaire, c'est un type instable par vocation (car le plus souvent sémantique) est très peu performant. Préférez de l'integer.

[azzazzelleio]

Bonjour

Vous avez un héritage de données de Client vers Client_conventionne et vers Client_ordinaire.

1) Je ne vois pas trop l'utilité de Client_ordinaire puisque cette entité-type ne contient aucun attribut et n'a pas d'association particulière.

2) La génération de votre BDD a donc du créer les tables Client_conventionne et Client_ordinaire avec, chacune, une colonne clé étrangère référençant Client.Num_cl.
Lors de l'insertion des données dans Client_conventionne, vous devez fournir à la colonne clé étrangère une valeur existant dans la table Client. Faute de quoi vous obtenez une erreur.

Il faut donc d'abord insérer les données de la table Client, récupérer l'identifiant créé lors de l'insertion puis utiliser cet identifiant pour insérer les données dans Client_conventionne.

J'explique sur mon blog la démarche avec une procédure pour MySQL et pour Postgresql que vous pourrez adapter à votre cas.

merci pour votre aide ..... mais si je supprime le client ordinaire les contraintes sur héritage ce change ou non

[azzazzelleio]

Bonjour,

Tout à fait d'accord avec les remarques de Cinéphil.
Je précise que vous avez oublié de définir l'identifiant primaire de l'entité-type client (absence de rectangle typé "pi" en bas de l'entité-type), c'est certainement la cause de votre erreur

Et j'ajoute que vous devriez également choisir un autre type de données que du Varchar pour vos identifiants (cf. facture, contrat et réduction).
Le Varchar est ce qu'on peut choisir de pire pour un identifiant primaire, c'est un type instable par vocation (car le plus souvent sémantique) est très peu performant. Préférez de l'integer.

merci .... j'ai ajouté le pi sur client conventionner et sa provoque une erreur lors de la conversion en MLD ....... le type de donnees varchar parce que comme exemple l'identifiant de facture est (fac00000001) s'il ya une autre solution dit le moi .... merci

[CinePhil]

mais si je supprime le client ordinaire les contraintes sur héritage ce change ou non

Un client est un client ordinaire. Certains clients sont des clients conventionnés. C'est tout.

j'ai ajouté le pi sur client conventionner et sa provoque une erreur lors de la conversion en MLD

Non. Je vois bien le <pi> sur votre entité-type Client. Je ne comprends pas ce qu'a voulu dire Escartefigue !
Dans le MCD, il ne faut pas mettre de <pi> sur Client_conventionne puisque c'est une entité-type fille qui hérite de Client. Elle n'a pas d'identifiant propre. Lors du passage au MLD, la table aura une colonne clé étrangère référençant Client et qui sera clé primaire de la table.

Client (Num_cl, Nom_cl, Prenom_cl, Date_naiss...)
Client_conventionne (Num_cl, Fonc_cl)

le type de donnees varchar parce que comme exemple l'identifiant de facture est (fac00000001) s'il ya une autre solution dit le moi .... merci

Un numéro peut changer de format. C'est une mauvaise clé primaire. Il vaut mieux créer une clé primaire technique de type Serial et considérer le numéro de facture comme une clé alternative, donc munir la colonne de la table d'une contrainte d'unicité. Idem pour Contrat, Offre et Reduction.

Au passage, quelques remarques complémentaires...
1) Pour nommer votre tables et colonnes, n'utilisez que des caractères simples (lettres non accentuées de a à z, chiffres) et le caractère de soulignement _.
2) Mettez les noms des entités types (et par voie de conséquence des tables) au singulier.
3) Un numéro de facture, de contrat ou d'offre est le cas type du type CHAR (chaîne de caractères de longueur fixe)
4) Vos cardinalités sont toutes à revoir !
Un client ne pourrait-il donc payer qu'une seule facture ? Ne signer qu'un seul contrat ?
5) Vous devriez externaliser les types d'offres qui seront, je suppose, répétitifs. Donc faites une entité-type de référence des types d'offres et associez la à Offre.

[escartefigue]

Non. Je vois bien le <pi> sur votre entité-type Client. Je ne comprends pas ce qu'a voulu dire Escartefigue !

Il faut que l'identifiant primaire (PI) apparaisse en bas de l'entité-type, dans le rectangle inférieur, comme c'est le cas par exemple pour l'ET facture


@azzazzelleio :
Quelques autres remarques :
- vous devriez rédiger les règles de gestion et les numéroter afin de justifier les cardinalités et la contrainte d'intégrité d'inclusion entre "attribuer" et "contient"
- tel que vous avez modélisé la relation "attribuer", le client est une entité-type faible : il est identifié relativement à la carte (parenthèses autour des cardinalités), ça semble très très curieux...
- vous avez modélisé la facture mais pas les lignes de factures
- vous n'avez rien modélisé concernant les paiements et le lettrage, est-ce hors périmètre de votre modèle ?

[CinePhil]

Il faut que l'identifiant primaire (PI) apparaisse en bas de l'entité-type, dans le rectangle inférieur, comme c'est le cas par exemple pour l'ET facture

J'ai l'impression que c'est l'affichage de cette entité-type qui est réduite sur le dessin.

[azzazzelleio]

merci pour vos repenses .... je vais voir ce que peut faire