Discussion :

[Frenchguy]

Bonjour,
J'utilise analyseSi pour faire un chema MCD de ma base de donnée.
Or, ce logiciel ne semble vouloir lier que des tables avec des associations.
On ne peut donc pas lier deux tables directement...
pareil pour relier deux asso entre elles.. pas possible...

Cela est du au fait que dans un MCD, on ne peut pas lier deux tables entre elles???


ou alors ça tient du fait que ce logiciel ne le permet pas, afin de pouvoir creer ensuite automatiquement le MLD et le SQL ???


J'ai une structure, ou plusieurs tables sont liés à la suite...
Prospect s'attache à une Zone qui regroupe des Régions de France qui rergoupent eux des Departements

en mettant ensuite un filtre sur ma zone (1, 2... ça me donne les départements correspondant, puis les prospects correspondant à ces departements!)

comment je dois representer cela?? en MCD???

si vous desirez jettez un oeil à mes relations...
http://www.fotolog.com/frenchguy/

Merci!

[cafeine]

Regarde mon topic sur les comptes bancaires, tu verras ce qu'on peut faire avec AnalyseSI.

(lien dans ma signature)

[Frenchguy]

Merci pour l'exemple, j'ai pris ton fichier AnalyseSI, et ke l'ai ouvert, et j'ai fait le model de MLD, voir ce que ça donne...

Le MPD doit il montrer toutes les tables du futur projet???

Quel est l'intérêt de mettre toutes ces associations, entre chaque table, alors qu'elles n'ont aucun attribut???

De plus, j'ai un exemple partivulier, ou j'utilise ce qui pour moi est une association.
J'ai une table Revendeurs avec une clé Num_Revendeur
et une table Departements avec comme clé Num_departement

J'ai donc mis une table charniere entre les deux, pour assigner des departements à mes revendeurs.
Soit une table Zone_revendeur qui a comme attribut uniquement
Num_revendeur
Num_Departement

Donc, si je traduit ça en MCD, vu qu'on ne met pas les clés étrangeres dans un MCD, ma table ZOne_Revendeur doit prendre la forme d'une association avec juste un titre!!!??

OR, une fois traduit mon schema en MLD, cette table aura disparut???
Ou alors le MLD est encore different de ce qu'on a dans la réalité, mais alors je ne vois plus le sens de tout ces trucs abstraits...

Je vais encore essayer, de faire un trtuc rationnel avec mes tables, et à la limite je vous le montre...
MERCI

[Tofalu]

Au niveau du MCD, toutes les entités sont reliées entres elles par des associations.

Au niveau du MPD, cela se traduit soit par une clé étrangère, soit par une nouvelle table suivant les cas.

Dans ton exemple tu auras :

Entités : revendeur, département
Association : Rattaché à, avec comme cardinalité : 1,n de chaque coté (voire 0,n coté departement)

De ce fait cela sera traduit en MPD par 3 tables :

Revendeur(Numrevendeur, Nom, etc.)
Departement(NumDept,NomDept)
Rattacher(NumDept#,NumRevendeur#)

[Frenchguy]

Bon, j'ai remarqué que le type des relations modifiaient ou pas la suppression de l'association lors du passage vers le MLD...


Par contre, je ne sais pas quelles arguments donner à mes liens...

Par exemple, j'ai mis dans mon MLD

[Table] (Association) [Table]
Prospects--------1,1-------Habite_dans-----1,1-------departements

Car chaque prospect habite quelque part, et à partir du momment ou il habite quelque part, c'est forcément dans un et un seul départment...

Donc, traduit en MLD ça me donne:

Prospects <------------------->Departements
que je traduit apr "a chaque prospect equivaut un departement??

est-ce exact???


a, p***** j'ai vérifié, le résultat est aps trop mal, sauf qu'il m'a créé la clé etrangere dans la table departement et pas dans la table prospects!!

Comment inverser cela, sachant que l'association est symétrique?? 1,1--1,1 , sur quoi se base le logiciel pour mettre la clé etrangere dans l'une ou l'autre table??? (la tailled e cette table???)

[Tofalu]

Au niveau tu MCD tu auras :

Prospect--------1,1-------Habite_dans-----0,n-------departement

Il peut y avoir plusieurs prospects dans un département et un département peut ne pas disposer de prospects/


Au niveau du MPD

Prospect(NumProspect,NomProspect, NumDepartement#)
Departement(NumDepartement, NomDepartement)

[Frenchguy]

Merci, Tofalu!! ta methode fonctionne pour passer la clé etrangere dans ma table Prospects. par contre je saisie pas toute la logique du 0,N ...
En fait il faut lire en symétrie, par rapport a l'association??

ce qui se traduirait plus par n departments peuvent correspondre a 0 associations...



Sinon voila le MCD que j'ai réalisé!
http://ledindonchafouin.free.fr/Stockage/monMCD.jpg

et ça me donne le MLD suivant:
http://ledindonchafouin.free.fr/Stockage/monMPD.jpg

(bien que je l'ai nommé MPD, betement! )

si vous voulez jetter un oeil! et mle dire s'il y a des abérations...
MERCI

[Tofalu]

Non, on lit par :

Un prospect réside dans un et un seul département,
Dans un département, il peut résider aucun, un ou plusieurs prospects

[Tofalu]

Au niveau de ton MCD, plusieurs choses me choc :

On distingue des blocs dans l'entité Prospect. A priori, un prospect est attaché à un vendeur. Il devrait y avoir une association entre les deux.

Un devis contient des produits, l'entité Détails est superflue. C'est justement l'association produit/devis qui sera apparenté à une ligne détail du devis.

Attention au code postal. L'entité département et le code postal du prospect font une redondance. Dans la table propsect, il ne faudrait stocker que les 3 derniers chiffres du CP.

Le propsect établit des devis, mais le revendeur, il fait quoi ?

[Frenchguy]

SAlut!!
Merci d'avoir jeté un oeil, déjà!!

des "blocs" dans l'entité prospect... tu veux dire toute s les options qui sont nommées sur la meme base... OUI, c pour la clarté, car ces champs sont en relation! en bloc...

Sinon, le vendeur est bien relié au prospect, le lien existe, mais n'est aps direct...
en fait le prospect appartient a un departement, dans une region, et enfin dans une zone, et j'associe le commercial que je veux à la zone que je veux, ensuite!


Pour le devis, detail_devis et produits !! un bon samaritain du forum m'a donné la structure.
La table détail_devis stocke le prix du devis... et les différents produit que le devis va contenir...
ça permet que si le tarif du produit change, le prix du devis reste comme il etait quand on l'a réalisé...

(Le prix devis n'est pas stocké.. c'est juste la somme des quantité*prix de la table detail...)

Le code postal??? redondance avec le code departement.... hmm, oui!
mais c juste génant pour la quantité de données stockées?? ça boufferait pas plus de perfs de faire un concaténation pour afficher le code postal complet dans le formulaire??
La c'est de la ultra optimisation, je vais rester modeste!!
(surtout que j'ai une table commune, qui donne le CP quand on choisit la ville...)

Le revendeur... il ne fait rien...
En fait dans la boite, on associe nos prospects à des revendeurs, qui servirons d'interemediaire, et qui assurent le service de proximité...
(on choisit nos revendeurs... )
Donc il faut pouvoir savoir dans quel departmeent peu agir chaque revendeur, pour pouvoir le mettre en relation a un prospect du meme departement!


Sinon, le MCD serait bon!!??
Mon collegue, en formation aussi a fait la base client, lui, pour son projet d'etude, et il a fait un MCD sans mettre d'associations??
il a tort?? je lu idit de corriger, ou ce sera bon aussi pour lui?

MERCI

[Tofalu]

Donc si le vendeur est associé au propsect, il manque bien le lien entre les deux.

D'autre part, je persiste, pour moi, le devis n'est pas correct.

Il faut une entité produit, une entité devis, et une association contenir. Un devis contient un ou plusieurs produits (on stockera le prix du produit pour le devis en propriété de l'association). Un produit quant à lui peut figurer dans 0,1 ou plusieurs devis.

Enfin,

OUI, c pour la clarté, car ces champs sont en relation

Justement, pour être correct dans un MCD chque attribut (champ) doit dépendre uniquement de l'identifiant de l'entité, et non d'un autre champ !

Quand je vois revendeur_assoice dans la table prospect, cet attribut ne dépend pas que du prospect mais aussi du revendeur, idem pour revendeur_associe_date.
Les doc_et_demo... devraient à mon avis trouver place dans une entité à part.

A la lecture de ce MCD, je pense qu'il n'est pas correct. En tout cas, je serais incapable de traduire la structure du système d'information qui se cache derrière.

MCD sans mettre d'associations

Un MCD sans associations, ce n'est pas un MCD.

Au sujet du code postal :

mais c juste génant pour la quantité de données stockées??

Non, c'est génant au niveau de la cohérence des données. Que se passe t'il si mon prospect a le code postal 01000 et comme département rattaché 69 ? Cette règle est t'elle possible ? Comme compte tu gérer cette contrainte au niveau de la base de données ?

surtout que j'ai une table commune, qui donne le CP

Et si je te donne comme ville LYON, tu me retournes quoi comme CP ? Une ville peut avoir plusieurs CP, et un CP peut correspondre à plusieurs villes. Enfin, cette table ne figure pas dans ton MCD, pourtant une ville appartient à un département.

Bref, y a encore du boulot