Entrée Sortie

Bonjour, je viens de réaliser un MCD que je veux traduire sur access, j'aimerais m'assurer tout d'abord qu'il soit correct, et de plus j'en profite pour demander comment je pourrais traduire l'héritage et la contrainte d'implication présente, il me semble logique que je ne pourrais traduire la contrainte que sur du code vba, mais pour l'héritage...

Voilà mon MCD, ma grosse lacune est de déterminer les entités faibles, en fait je ne vois pas trop la différence, par exemple une livraison est réalisée par un et un seul fournisseur, je doute qu'une livraison soit une entité faible.
Je ne me vois pas créer une table REALISER dans ma base de donnée et y mettre seulement la Référence du fournisseur et la référence du produit, mais plutôt insérer une clé étrangère #RefFournisseur# dans la table LIVRAISON.

Voilà mon MCD, j'y est inséré qu'une entité faible, donc je doute pour toutes les autres cardinalités 1.1

http://img85.imageshack.us/img85/2231/diagramme.th.jpg


Si vous avez des éléments de réponse, d'avance merci.

Lisons le MCD...

1) Entité Fournisseur
Personnellement, j'externaliserais la ville afin d'éviter les saisies multiples d'une même ville, potentiellement avec des orthographes différentes (Saint-Etienne, St Etienne...)

2) Entité Livraison
Qu'est censé contenir l'attribut LibLivraison ?

3) Entité Entree
Idem pour LibEntree
RefLivraison est une clé étrangère faisant référence à la livraison et ne doit pas figurer dans le MCD. Elle n'apparaîtra qu'au moment de la génération du MLD.

Cette entité Entree ne serait-elle pas plutôt par anticipation une table issue d'une association entre Livraison et Article ?
Livraison -1,n----Contenir----0,n- Article
L'association Contenir serait ici porteuse des données QteEntree et PrixAchat.

4) Entité Article
Idem pour RefFamille : clé étrangère à supprimer du MCD.

Les attributs PrixMoyenPondere, Solde et QuantiteArticle me semble des attributs calculables qui ne devraient donc pas être enregistrés, du moins à la première modélisation.

5) Entité Sortie
Idem pour LibSortie.
Idem que pour Entree, n'est-pas réductible à une association porteuse de données entre Facture et Article ?
Facture -1,n----Concerner----0,n- Article

6) Héritage Client
Les attributs de l'entité Client laissent supposer que tous les clients sont des personnes physiques. Par contre, l'entité fille Responsable laisse supposer qu'il s'agit du responsable chez un client de type personne morale (entreprise, association, organisme public...), impression renforcée par la présence de l'entité fille Particulier.
Il vaudrait donc mieux mettre le nom et le prénom dans l'entité fille Particulier. Par contre, le téléphone et l'adresse devraient figurer dans l'entité mère Client, avec une association vers l'entité supplémentaire que j'ai suggérée, Ville.

Il y a eu récemment dans ce forum des exemples de modélisation d'héritage de Personne vers Personne_Morale et Personne_Physique. Une petite recherche vous y conduira je pense assez facilement.

À noter qu'un fournisseur est aussi une société, donc généralisable en tant que personne morale. Ce fournisseur peut d'ailleurs être également client, cas classique.

Ceci dit, à la réflexion, votre modélisation du rattachement de la facture à l'interlocuteur client, qu'il soit particulier ou responsable d'une société est intéressante.
Attendez d'autres avis avant de modifier cette partie.

7) Entité Societe
L'activité devrait être externalisée, pour la même raison que la ville.

Citation:

---

il me semble logique que je ne pourrais traduire la contrainte que sur du code vba

---

Dans un vrai SGBDR, ce serait le boulot d'une contrainte CHECK de vérifier que la remise ne peut être accordée au client que s'il a une carte de fidélité. Dans Access, je ne pense pas, de mémoire, que cette contrainte existe. Mais ça fait très longtemps que je n'ai plus touché à Access. Voir dans le forum adéquat.

Pour traduire l'héritage, vous allez créer, si on en reste à votre modèle, les deux tables Particulier et Responsable qui auront pour clé primaire l'identifiant du client en tant que clé étrangère.
Client (IdClient, NomClient, PrenomClient, TelClient)
Particulier (IdClientParticulier, AdresseParticulier, CodePostalParticulier, VilleParticulier)
Responsable (IdClientResponsable, FaxResponsable, EmailResponsable, IdEntrepriseResponsable)

Tout d'abord merci beaucoup !

Comme vous êtes modérateur je vous fais part que j'ai le même post dans la catégorie schéma, et comme je n'avais aucune réponse, je l'ai recréé ici et je ne sais pas comment supprimer l'ancien.

Pour le MCD :

A la suite de votre analyse, je commence à mieux comprendre le fonctionnement du MCD, ainsi je créé une nouvelle entité ville, j'ai hésité cependant pour l'activité d'une entreprise vu que le nombre d'entreprise est censé être faible.

L'attribut LibLivraison était censé contenir un Libellé me rappelant rapidement ce que contient cette livraison, mais vous raison je me contenterais des ID.

En effet l'entrée et la sortie sont mieux à leur place dans les associations, d'autant que leur libellé respectif était un doublon de libellé produit.

Solde et somme ne sont pas nécessaire, je pense cependant garder le prix moyen pondéré pour éviter de faire systématiquement une recherche sur toutes les entrées, qu'en pensez vous ?

Pour l'héritage client, j'ai soit un particulier (personne physique), où j'ai besoin de connaitre son adresse, soit un responsable(personne physique), où j'ai besoin du minimum car ce qui m'intéresse est de pouvoir le contacter et non de connaitre son domicile.

Le fournisseur a peu de chance d'être client, de plus je ne passe pas par un représentant pour un fournisseur, mais j'ai tout de même essayé de modéliser un modèle conceptuel. Vu la complication de la chose, ne serait ce pas mieux que je privilégie la rareté des doublons du fournisseur client ?

Voilà deux nouveaux MCD, le premier ne tient pas compte qu'un fournisseur peut être client.

Merci :ccool:

MCD1 :
http://photomaniak.com/upload/out.ph..._Diagramme.jpg

MCD2:
http://photomaniak.com/upload/out.ph...Diagramme2.jpg

Bonjour,

Je trouve que le diagramme2 s'éloigne du sujet en ce qui concerne la facturation.

La facture concerne 1 Personne qui, au final est un Particulier, un Responsable, une Société ou un Fournisseur. Il y a équivalence entre Responsable et Société (1,1 des deux côtés). Donc, dire que la facture concerne un Responsable ou une Société est équivalent. Plusieurs questions se posent alors.

Dans quels cas la facture concerne-t-elle le Responsable et dans quels cas concerne-t-elle la Société ? Comment choisir ? Cela dépend-il de la société ?

De plus, pour deux factures F1 et F2 d'une même société, on pourra rattacher F1 au Responsable et F2 à la société. Ce n'est pas très cohérent.

Puisque le Responsable = Société, autant choisir une bonne fois pour toutes que les factures concernent systématiquement le responsable (ou la société). De ce point de vue, le diagramme1 est plus cohérent.



Autre différence entre les deux MCD : dans le diagramme2, une facture peut concerner un fournisseur alors que ce n'est pas le cas dans le diagramme1. Ce rattachement risque de poser de sérieux problèmes de gestion : il faudra systématiquement vérifier que l'on ne facture pas au fournisseur un article qu'il a lui-même fourni.
De plus, l'identification d'une entreprise sous le même ID en tant que client et fournisseur est à double tranchant. Par exemple la mention "vos références" comportera le même ID, qu'il s'agisse d'un retour d'article défectueux ou d'une facture à régler. Le fournisseur risque de se poser des questions.
Là encore, je penche pour le diagramme1.

Bonjour, oui effectivement le diagramme 2 pose pas mal de problème, je l'ai réalisé trop rapidement pour tester l'héritage de personne devenant personne physique et personne morale afin de bénéficier de quelques propriétés existante et de résoudre le problème du fournisseur pouvant être client, mais comme vous l'avez constater ce diagramme n'est vraiment pas correcte.

De mon côté je devais programmer assez rapidement l'application, donc je l'ai modifié par rapport au diagramme 1, un jour peut être j'envisagerais une meilleur solution.

En tout cas merci beaucoup pour vos avis, ils m'ont été très utiles.