Discussion :

[madmortal]

je dois realiser une bdd et une appli graphique pour l'utiliser(en java) pour une asoc pour les jeunes qui va lancer une carte à leur intention
la bdd devra supporter environ 10 connexions
je pense utiliser interbase pour faire tourner la base car pas d'admin en permanence

la bdd doit comporter :
les infos concernant les jeunes porteurs de carte, les infos correspondant à la carte en elle meme et de plus dans la base on doit trouver les partenaires qui fournissent les avantages liés à la carte

voila le MCD que j'ai réalisé



le probleme est quand je genere le MPD, je me retrouve avec des tables possede qui comporte plein de clés



tous vos commentaires seront les bienvenus
madmortal

ah oui et j'avais deja posté sur le forum interbase et sql, excusez de m'etre tromper

[Médiat]

Peux-tu préciser comment sont définis tes identifiants.

[madmortal]

j'ai mis a jour mes identifiants sur la 1iere image

voili

[Médiat]

Je ne comprends pas.
l'association correspond 1 ne devrait pas donner naissance à une table, et possede:2 ne devrait contenir que por_id et eml_id, et c'est bien le cas avec le petit essai que j'ai fait (j'ai recréé une partie de ton mcd) !
Quelle version de amc designor utilises_tu ?

[madmortal]

j'utilise la version d'evaluation 10.1

utilise des options particulieres quand tu generes le MPD?

et peut-etre que je me trompe quand je cree les associations.
j'ai crée une asociation possede que je reutilise le nbr de fois necessaire en la prenant dans le menu a droite dans powerAMC
dois je recreer une association differente a cahque fois a la place?

[Médiat]

Je ne connais pas la 10.1;
Essaye de refaire toutes tes associations en en créant de nouvelles à chaque fois, je ne serais pas surpris que tes problèmes viennent de là

[madmortal]

j'ai une question
le code d'une association qui se repete doit-il etre le meme?

[madmortal]

je pense que le probleme venait de la car j'ai maintenant un MPD plus realiste!!!
voir image mis a jour dans le 1ier message

sinon pourriez vous me dire si ce modele vous semble valide?

merci bcp

[Médiat]

Je répète que ne connaissant pas les contraintes c'est difficile de te dire si ton modèle est bon ou non :
par exemple dans ton modèle une même adresse mail (ou N° téléphone) peut appartenir à plusieurs porteur de cartes, cela peut se comprendre (des personnes de la même famille), mais je ne sais pas si cette complexité apporte vraiment quelque chose, mais qu'une même adresse mail (ou téléphone) appartiennent à plusieurs partenaires et/ou à plusieurs magasins je trouve cela très très bizarre, à toi de dire si c'est correct ou non. Tu n'explique pas ce que représente le partenaire vis à vis des magasins qui lui sont associés (est-ce une entité abstraite qui permet de regrouper les magasins d'une même enseigne, est-ce le siège social, a-t-on vraiment besoin du téléphone, ...)
Par contre ce qui est faux c'est d'avoir por_id (resp. par_id) dans info_porteur ( resp. info_part) et inf_id (resp.ifa_id) dans porteur_carte (resp. partenaire). D'ailleurs, je ne vois pas l'intérêt au niveau MCD d'avoir une relation (0,1)---------(1,1), tu peux tous mettre dans porteur_carte (resp. partenaire), les attributs de info_porteur ( resp. info_part) étant alors optionnelle.

[madmortal]

pour les info_porteur et les info_partenaires oui il n'est pas utile d'avoir des tables je comprend.
pour les mails,les telephones c'est peut etre trop compliqué pour les porteurs de carte (surtout qu'il y ait des chances qu'on leur demande uniquement leur numero de portable pour le tel et il est vrai qu'il est rare que meme 2 personnes de la meme famille possede le meme mail) quand aux partenaires et magasin la je ne sais pas.
en fait ca vient peut-etre de ma comprehension de ce que j'ai ressorti avec l'assoc.
je vais donc expliquer plus en detail:la carte forunie aux jeunes keur donne droit à des reductions pour par exemple un livre ou n'importe quoi. Ces reductions ont ete negociés avec un partenaire qui peut-etre soit un magasin dans une ville par exemple, ou une chaine de magasin comme la fnac, ou une société qui n'a pas forcement de magasin genre une banque(pas besoin des adresses de toutes leurs agences)
peut-etre devrais je realiser une entité partenaire et faire hériter plusieurs sous entites? c'est ca que vous suggerez?
si c'est un magasin j'ai besoin de toutes ces coordonnées et de la ou les reduction(mais que je considere comme un partenaire dans mon schema), les partenaires sans magasin sont egalement traités de cette facon, si c'est une enseigne j'ai besoin de la ou les reduction qu'il offre et de leurs coordonnées mais j'ai besoin des coordonnées de chaque magasin associé
c'est pour ca que par exemple le mail d'un magasin n'existe peut-etre pas mais recupere celui du partenaire dont il provient.
ce qui sous entendrait la que je devrais utilisee un heritage? enfin je pense

[madmortal]

je rajouterai que j'ai mis un type mail car pour une societe je peux avoir le mail mais aussi l'url e donc j'ai regroupe ca dans l'entite mail car j'aurais relativement peu d'url compare au nbe de mail et il me paraissait plus simple de faire un type

[Médiat]

peut-etre devrais je realiser une entité partenaire et faire hériter plusieurs sous entites? c'est ca que vous suggerez?

Oui, absolument, il y a plusieurs façons d'implémenter physiquement l'héritage, mais je pense que ce serait une bonne chose de le voir dans le MCD

[madmortal]

j'ai donc implementé l'heritage dans le MCD et pour le MPD je ne transfere que la cle primaire de partenaire et pas tous les attributs

et pour les telephones et mails j'ai mis des cardinalités 0,1 soit au final des relations n..1
le truc cé que quand je genere le MPD moi je m'attendrai quand meme à avoir des tables de jointure et j'a plutot une grosse table telephone et une grosse table mail
voir image mises a jour dans 1ier post

je pense donc avoir une erreur

[Médiat]

Tu peux résoudre ce problème en faisant plusieurs table mails (cela n'a rien de choquant, puisque c'est bien ce que tu avais lorsque tu acceptais plusieurs personnes sur le même mail)

[madmortal]

bon j'ai revu tout mon MCD en creant des tables particulieres de tel pour chaque entité
et sinon normalement on devrai avoir qu'un seul email à gerer par entité donc je me suis dis que c'etait plsu simple de supprimer cette table et de les integrer à chaque entité directement

sinon j'ai une question à propos de la carte
Barbibulle avait justement soulevé le probleme de ci on renouvellait la carte pour vol par exemple un porteur pourrait avoir deux cartes
j'avais donc modifié pour avoir la possibilité qu'un porteur est plusieurs cartes
j'ai donc mis des champs car_valide qui est un booleen et qui nous dit que la carte est la bonne et car_ren pour savoir si c'est une carte renouvellée
je me pose des questions car cela me semble ensuite compliquer à gerer
je pensais à une procedure qui supprimerait au bout d'un certain temps l'ancienne carte
est-ce jouable?

[Médiat]

Tu poses un problème classique d'historisation dans les bases de données, il y a au moins 5 ou 6 solutions en fonctions des besoins fonctionnels, de la volumétrie historisée, etc... (Google)

[madmortal]

en fait il faut que ca reste relativement simple

je pense finalament faire une table genre ANCIENNE_CARTE avec comme attribut le num de carte et l'id du porteur à qui elle a appartenue
et finalement j'enleve l'attribut valide de mon entité carte
avec une procedure qui se charge d'exporter les anciens num de carte vers ANCIENNE_CARTE lorsque l'on modifie le numero de carte

[Médiat]

C'est bien une des solutions connues, à vue de nez je crois que c'est adapté à ton problème, cette partie historique ne servant qu'à des consultations exceptionnelles je suppose.

[madmortal]

voila j'ai remodifié mon modele(-voir 1ier post)

j'ai donc une table ancienne_carte qui comportera tous les anciens numeros et je lui associe un type pour savoir si c'est un renouvellment a cause par exemple d'un vol ou renouvellement a cause fin de validité


dites si ca vous semble viable meme si je sais que sans le contexte c'est difficile à dire

[madmortal]

ah on a poste presque en meme temps

et en effet cela devrait servir relativement peu normalement