Discussion :

[campesinos]

Bonjour,

Je suis en train de faire (modestement) un MCD concernant un bordereau de mouvement produit (Entree & Sortie) dans le cadre d'une activité de maintenance.

Mon problème c'est que quand une personne de mon service envoie un produit, il peut tout aussi bien le faire parvenir à un de ses collègue (du même service), qu'à un autre département de l'entreprise ou à un fournisseur externe.

J'ai crée pour cela une entité "bordereau", une "personne" (qui regroupe les personnes de mon service) et une "contacts" (département de l'entreprise et fournisseur). mais j'ai des doutes sur le choix que j'ai fais.

Si quelques personnes pouvaient me dire ce qu'elles en pensent et si mon MCD est correct cela m'aiderai à avancer, car ce qui me dérange c'est le faite que l'expéditeur et le destinataire peut provenir de la même entité ("personne"-->"personne") en plus de la relation entre "personne"-->"contacts" ou "contacts"-->"personne".

je joins mon MCD en attach.

Merci beaucoup.

[Fleur-Anne.Blain]

...
ce qui me dérange c'est le faite que l'expéditeur et le destinataire peut provenir de la même entité ("personne"-->"personne") en plus de la relation entre "personne"-->"contacts" ou "contacts"-->"personne".

Dans ce cas il faut que tu fasses une réflexive sur l'entité personne avec une association emeteur et une récepteur.

@+

[fsmrel]

Bonjour,

D'après votre MCD, un bordereau est émis par un membre du personnel et a pour destinataire un contact qui ne peut pas être membre du personnel.

Une possibilité à court terme, parmi d'autres pour que le personnel puisse être destinataire :

Dans un premier temps, la ternaire ne présente guère d'intérêt du fait de la cardinalité 1,1 : autant la transformer en deux binaires, "Emettre" et "Recevoir".

Dans un 2e temps, remplacer l'entité "Contacts" par une entité "Destinataire", laquelle ne disparaît pas mais change de place.

Ceci est résumé dans la pièce jointe.

Maintenant, il existe d'autres possibilités, si par exemple vous entreprenez la mise en place d'un référentiel Personnes.

[campesinos]

Merci pour vos réponses à tout deux, cela semble résoudre mon problème. Je vais tester ça.

Petite question par contre, le reste de mon MCD vous paraît-il correct ?

Je pensais déplacer l'attribut "Quantité" de l'entité "Produit" vers l'association "Contient" ce qui m'apparaît comme étant plus logique.

[fsmrel]

Je pensais déplacer l'attribut "Quantité" de l'entité "Produit" vers l'association "Contient" ce qui m'apparaît comme étant plus logique.

De fait, si Quantité est une propriété de Produit, alors elle est indépendante du bordereau.

Sinon, ce qui est plus conforme, l'association Contient devient porteuse de Quantité et la relation 1,1 devient 0,N (un produit donné pouvant être en relation avec plusieurs bordereaux).

[fsmrel]

Concernant l’identification des entités-types :

Il est préférable d’éviter d’identifier les entités-types au moyen de leurs propriétés naturelles. Il vaut mieux mettre en œuvre une propriété artificielle à cet effet, non porteuse de signification et invariable (elle ne doit pas être maîtrisée par un système externe à votre système d’information).

Ainsi, vous identifiez Produit par l’attribut Référence : S’il s’agit par exemple d’un EAN13 ou d’une référence maison, vous n’avez aucune garantie de la pérennité de l’identification dans le temps. Accessoirement, votre référence est définie en Varchar(20) : soyez économe car les identifiants devenant clés primaires au niveau tabulaire, vous en retrouvez aussi les valeurs au sein des clés étrangères, dans le mécanisme de l’intégrité référentielle. Un Entier suffit largement. Rien n’empêche de conserver la référence comme point d’entrée dans le système (clé alternée).

Vous auriez peut-être aussi intérêt à déplier votre MCD, en partitionnant les contacts (internes et externes à l’entreprise).

[campesinos]

Pour "Quantité" je vais le rattaché à l'association "Contient". je vais aussi mettre des propriétés artificielle (il est vrai que je n'avais pas envisagé du tout cette problématique).
Le problème que je rencontre par contre avec l'attribut "Référence" de mon entité "Produit" et du choix de la varchar (20) =était que mes produits sont identifiés depuis le début n'importe comment. Cela va effectivement d'une référence interne de type EAN13...., en passant par du code intelligent (EAN13_fabricant_N°_Version_...), du code a 6 digit, d'autre à 15, des références constructeurs,etc...Bref tout ce qui leur passait par la tête. Et je n'ai pas la possiblité de recoder tout les produits.
Je vais je pense me diriger vers un attribut "Id" incrémenté et définie en clé primaire en lieu et place de "Référence" qui restera un simple attribut.

Pour finir j'ai encore un problème avec le MCD que vous me proposez, car je peut relier ma table "Contact" à l'association "Emettre". Or même si ces cas de figures seront rares, ils se produiront.

Merci

[fsmrel]

Je vais je pense me diriger vers un attribut "Id" incrémenté et définie en clé primaire en lieu et place de "Référence" qui restera un simple attribut.

Vu le grand mélange explosif que sont les valeurs prises par l'attribut Référence, définir une clé primaire intègre et propre est une nécessité si vous voulez une base de données saine et robuste. Pour sa part, l'attribut Référence ne devrait être qu'un point d'entrée pour les utilisateurs dans la base de données, point barre.

j'ai encore un problème avec le MCD que vous me proposez, car je peut relier ma table "Contact" à l'association "Emettre".

Si vous souhaitez que tout le monde puisse émettre, ne tirez pas de lien d'association entre Contact et Emettre. La signification de cette association deviendrait alors : "L'émission d'un bordereau implique un membre du personnel ET un contact" (à moins que ce soit ce que vous désiriez).

Dans la série générique, je vous propose le MCD en pièce jointe, sachant qu'il existe d'autres solutions (dont l’extension du MCD que je vous avais proposé, en y ajoutant une seconde relation Emettre).

En tout état de cause, concernant le MCD en PJ, la signification de l'association Emettre devient : "L'émission d'un bordereau implique une personne" (sous-entendu quelle qu'elle soit).

[campesinos]

Bonjour fsmrel,

Excusez ma réponse tardive (petit problème de connexion internet ).
Je vais suivre votre MCD et utiliser la fonction d'heritage qui me permet de résoudre mon problème.

Merci pour votre aide précieuse et rapide.

A bientôt.

[campesinos]

Bonjour,

Je suis actuellement en train de tester mon MCD et le MPD pour voir si la notion d'héritage fonctionne correctement. Hors j'ai quelques soucis avec les clés étrangères et l'héritage qui découle de mon MCD.
Je m'explique, lors de la génération du MPD via poweramc 9.5, il génère un héritage des attributs de l'entité Père vers les Fils. Jusque là pourquoi pas, même si je me pose la question de savoir s'il ne serait pas plus indiqué de faire un héritage inverse (attributs fils vers père) afin de n'avoir qu'une table.
Je lui demande ensuite de générer le code SQL que voiçi :


J'ai testé sous MySQL, et c'est pas jolie, jolie. Je ne comprens pas pourquoi Poweramc ne fait aucune mention de clé étrangère dans le code. Résultat si j'insère des données dans une table fille (ex=contact_interne) il n'y a aucune réplication avec la table père "intervenant", tout les champs se référant à la table père restent vident y compris le champ clé primaire (propre à chaque table au lieu d'être commun).
Résultat, je n'ai aucune relation entre mes différentes tables.
J'ai donc rajouter pour mes tables filles les lignes supplémentaires :

MySQL m'annonce une erreur de syntaxe (#1064).

Bref, je nage un peu dans le potage là. Si quelqu'un peut m'aider à y voir plus clair.

Merci

ps= j'utilse wamp 5 avec MySQL 5.0.27.

ps2= j'oubliais en pj le MCD et le MPD

[tanita-twist]

C'est vrai que ton script généré n'est pas très propre
J'utilise une vieille version de Power AMC, mais c'est surement toujours pareil.
As tu pensé dans les propriétés de l'héritage de bien choisir l'option "hériter identifiant" (et non hériter tout qui est coché par défaut) et de cocher aussi l'exclusion mutuelle entre fils?

[fsmrel]

Bonjour Campesinos,

Il y a manifestement un problème de paramétrage.

1) Au niveau MCD, cliquer sur la lunule d'héritage. Apparaît une fenêtre "Propriétés de l'héritage".

Onglet "Génération"

Cocher "Générer le parent"
Cocher "Générer les enfants"
Cocher "N'hériter que des attributs primaires"

2) Au niveau MPD

Cliquer sur les liens d'héritage

Onglet Général

Nom : Donner au lien le nom qui vous convient

Onglet Intégrité

Changer éventuellement le nom de la contrainte
Cocher le type de contrainte qui vous convient (Cascade, Restrict, ...)
Vérifier avec l'onglet "Aperçu" si cela vous convient

3) Génération de la base de données

Indépendamment des propriétés physiques (à traiter plus tard, pour ne pas multiplier les problèmes...)

Onglet "Table et vues" : cocher ce qui vous convient

Onglet "Clés & Index" :

Cocher Clés primaires\ création de clé \ Séparément
Cocher Clés étrangères \création de clé \ Séparément
Cocher Clés étrangères \création de clé \ Intégrité déclarative

Ça n'est peut-être pas encore parfait, mais on y arrivera...

[campesinos]

tanita-twist = oui, après mon post j'ai vu dans l'onglet "generation" comment faire. J'ai fait la même procédure donné fsmrel, j'ai aussi coché "enfants mutuellement exclusif".

fsmrel = pour le MCD c'est bon, dans mon MPD les entités enfants héritent uniquement de la clé primaire du père. Par contre ça pioche sur la partie 2, dans l'onglet "intégrité", il m'est impossible de sélectionner "Cascade" ou "Restrict" car les options sont grisées, j'ai beau chercher je ne vois pas pourquoi.

[fsmrel]

"ça pioche sur la partie 2, dans l'onglet "intégrité", il m'est impossible de sélectionner "Cascade" ou "Restrict" car les options sont grisées

Conjugaison de la version d'AMC et du SGBD ? (Par exemple, avec MySQL 3.22, c'est effectivement grisé : j'en déduis que cette version du SGBD n'a pas encore intégré l'intégrité référentielle).

Histoire de voir, essayez en prenant, par exemple, DB2 comme SGBD.

[campesinos]

Effectivement ça passe avec DB2, par défaut tout les paramètres des points 2 et 3 de votre post sont cochés.
je vous joins en attach le résultat de la génération de la base. Les tables ne sont pas générées dans le bon ordre, mais je vais déjà tenté de voir ce que ça donne dans MySQL.


edit : bon et bien ça ne fonctionne pas, même en essayant de n'importer que le code d'une table (intervenant) MySQL me renvoit une erreur de syntaxe 1064 ("MySQL server version for the right syntax to use near 'generated by default as identity,
INTER_SOC VARCHAR(40) ' at line 3").
C'est la syntaxe "generated by default as identity" qu'il n'aime pas, et comme j'ignore précisément son rôle...

[fsmrel]

1) Du moment que les ALTER TABLE de mise en oeuvre des contraintes d'intégrité référentielle se trouvent derrière les CREATE TABLE, peu importe l'ordre dans lequel les tables sont générées.

Dans votre script je n'ai pas vu ces ALTER TABLE. Je rappelle :

Fenêtre "Génération 'une base de données", onglet "Clés & index" :

Cocher Clés étrangères \création de clé \ Séparément
Cocher Clés étrangères \création de clé \ Intégrité déclarative


2) "by default as identity" : c'est du DB2
____________________

3) Divers :

Code Postal numérique : vous aurez du mal à intégrer la Corse.

Tél, fax : respecter les normes ? +33 (0) x xx xx xx xx

[campesinos]

Bon, voilà ça semble fonctionner plus ou moins après bricolage.

Quand j'utilisais le script, MySQL m'indiquait des erreurs de syntaxe dès la 1ère commande (drop index EMETTRE_FK.

J'ai donc copier table par table, en faisant en sorte de les générer dans le bon ordre (d'ou mon erreur qui consistait à croire que poweramc me générait un script n'importe comment).
Au niveau de mes tables enfants aucunes clés étrangères n'était définies. J'ai donc utilisé la fonction "gestion des relations" dans phpmyadmin.

j'ai exporté le script sql pour voir ce qu'il donne, je sais pas ce que vous en penser mais moi il me parait pas trop mal.
je suis preneur de toutes critiques, surtout que je préfère partir sur de bonnes bases.
Bon il s'agit d'une ébauche encore, je dois revoir plusieurs choses (nom de champ, tél, code postal, etc...).
Je me pose aussi la question de savoir s'il ne serait finalement pas plus simple de créer une seul table "intervenants" regroupant les champs des 3 tables enfants, sachant qu'au total cela devrait, au pire, à peine dépasser la cinquantaine de contacts.

Merci pour votre aide quoiqu'il en soit. C'est toujours appréciable de se faire aider quand on débute.

[fsmrel]

Je me pose aussi la question de savoir s'il ne serait finalement pas plus simple de créer une seul table "intervenants" regroupant les champs des 3 tables enfants, sachant qu'au total cela devrait, au pire, à peine dépasser la cinquantaine de contacts

Il est des mauvaises habitudes à ne pas prendre. Votre intuition vous pousse à ne faire qu’une seule table Intervenant, regroupant Contact_Interne, Contact_Externe et Personnel : je vous conseille de n’en rien faire. En effet, si le MCD est en l'occurrence modeste, donc que vous le dominez, un jour vous aurez peut-être à bâtir (je vous le souhaite !) une architecture de plus de 1000 ou 2000 entités donnant lieu à des tables comportant des dizaines, voire des centaines de millions de lignes. A "replier" le MCD, non seulement vous perdrez une dimension sémantique, mais en plus vous serez confronté à des problèmes de performance, le système devant crapahuter dans des tables inutilement obèses, vous devrez gérer soigneusement les valeurs nulles qui sont les sables mouvants des bases de données (même si vous pensez maîtriser une telle logique, SQL se prend les pieds dans le tapis avec une logique à 3 états : vrai, faux, inconnu). Si l’utilisateur veut ne voir qu’une table, rien n’empêche de lui fabriquer une vue (mais attention aux valeurs nulles...)

Concernant le métabolisme des données

Si l’utilisateur supprime un intervenant, la règle CASCADE associée à la contrainte référentielle établie entre Intervenant et Personnel fait que la suppression d’une ligne de la table Intervenant entraîne la suppression de la ligne correspondante dans la table Personnel. Ceci est logique, puisqu’en fait un membre du personnel est un intervenant. Même chose concernant les contacts.
En revanche, si vous supprimez un intervenant, toujours avec la règle CASCADE associée à la contrainte référentielle établie entre Intervenant et Bordereau, vous supprimez aussi les bordereaux qui sont liés à l’intervenant, ce qui est peut-être dangereux : à vous de juger s’il n’est pas alors plus prudent d’être restrictif et d’utiliser la règle RESTRICT (ou NO ACTION, selon votre SGBD) pour la contrainte entre Intervenant et Bordereau.

En ce qui concerne le lien entre Bordereau et Contenir, CASCADE paraît raisonnable. En ce qui concerne le lien entre produit et Contenir, CASCADE l’est nettement moins, etc.

Il ne faut pas non plus passer d’un excès à l’autre, à savoir passer du tout CASCADE au tout RESTRICT (ou NO ACTION) : dans ce dernier cas, votre base de données serait pétrifiée, statufiée. Il faut donc raisonner au cas par cas, sachant qu’il y a un filet : si par exemple, vous supprimez un intervenant ayant des bordereaux qui lui sont associés avec une règle restrictive, un SGBDR normalement constitué annulera complètement l’opération, c’est-à-dire que du côté Personnel ou contact, la suppression ne se fera pas non plus. Le SGBD doit marcher par tout ou rien mais ne pas faire les choses à moitié.

[campesinos]

Bonjour,

Autant j'ai compris la nécessité de bien choisir la règle à appliquer entre mes tables, autant quelques interrogations subsistent du fait de mon ignorance et d'une difficulté à comprendre le fonctionnement de ma base.

Par exemple, mes clés étrangères doivent-elles être "null" ou "not null" ? Dois-je remplir manuellement ce champs en reprenant la valeur inscrite dans ma table père ? Pour être plus clair,admettons que je décide de créer un contact "personnel". Je renseigne les différent champs de ma table "intervenant", l'id auto-increment est de 1 , est-ce que dans ma table "personnel", qui utilise cet id en clé étrangère, je dois inscrire la valeur de 1 pour établir la correspondance ?
Ou puis-je passer par une vue spécifique pour ma table "personnel" qui regrouperait les champs des tables "intervenant" et "personnel" à renseigner tout en inscrivant automatiquement cette valeur ?

Mon problème c'est que plus j'en apprends sur le fonctionnement des SGBD plus les doutes m'assaillent.

[fsmrel]

Bonjour Campesinos,

Un membre du personnel, disons Tintin est un intervenant. Dans la mesure où les attributs de Tintin sont répartis dans deux tables distinctes Intervenant et Personnel, il vous faut un Insert dans la table Intervenant suivi aussitôt d’un Insert synchronisé dans la table Personnel pour que Tintin soit intégralement présent dans la base de données. Il est clair que si la valeur de clé primaire de Tintin est égale à 314 (attribut ID) dans la table Personnel il est impératif que la valeur de clé primaire dans Personnel soit aussi égale à 314 (attribut ID), ce qui permet d’assurer la cohérence pour Tintin dans les 2 tables, grâce à la clé étrangère hébergée par l’attribut ID de la table Personnel (intégrité référentielle).

Considérons le schéma de la table Intervenant :

Intervenant (ID, A1, A2, A3, ..., Am)

et celui de la table Personnel :

Personnel (ID, B1, B2, B3, ..., Matricule, ..., Bn)

Lors de la création d’une ligne pour Tintin dans la table Intervenant, vous récupérez la valeur 314 affectée par le SGBD à l’attribut ID et vous créez une ligne dans la table Personnel avec cette même valeur pour l’attribut ID de Personnel.

Par la suite, pour retrouver la synchro, en supposant que vous vouliez tout dire à l’utilisateur sur Tintin qui a pour matricule "007" (attribut Matricule) :

Code :

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

1
2
3
4
5
Select I.A1, I.A2, I.A3, ..., I.Am, P.B1, P.B2, P.B3, ..., P.Matricule, ..., P.Bm
From Intervenant As I, Personnel As P
Where Intervenant.ID = Personnel.ID      /* jointure sur ID */
  And P.Matricule = "007"

Vous noterez qu’au niveau de la jointure, si Intervenant.ID = 314, alors le SGBD ira chercher dans Personnel les données de la ligne pour laquelle Personnel.ID = 314 : il vaut mieux que ce soit les données de Tintin plutôt que celles de Rastapopoulos...

Concernant les vues : rien ne vous empêche de récupérer le Select ci-dessus pour l’incorporer à une vue :

Create View Vx As (Select ....)

Vous observerez qu’au niveau de la ligne Select, je n’ai pas fait figurer les attributs ID car l’utilisateur n’est pas concerné par la valeur de ID : en revanche, c’est bien l’élément de jointure entre tables.