Discussion :

[kuntagp]

Bonjour à tous, je voudrais votre aide pour verifier un schema qui correspond à une activité d'achat de metal (recuperation) au cours du jour.
J'utilise un logiciel qui s'appel Analysesi.

[CinePhil]

Bonjour,

1) Que sont clt_type_piece et clt_num_piece dans la table client ?

2) La ville devrait être externalisée, c'est une donnée répétitive et il y a risque d'avoir plusieurs fois la même ville avec des orthographes différentes.
client -1,1----résider----0,n- ville -1,1----situer----0,n- pays

Idem pour la ville du magasin et la ville du reçu.

3) Vu que le client a un nom et un prénom, la récupération de métal ne s'opère que chez des particuliers ?
D'ailleurs, vous parlez d'une activité d'achat de métal ; que viennent faire les clients dans ce schéma ?

4) En principe, on utilise des verbes à l'infinitif pour les associations.

5) Si ach_typ veut dire "type d'acheteur", c'est une donnée répétitive à externaliser :
acheteur -1,1----typer----0,n- type_acheteur

Pour le reste, difficile de se prononcer sans connaître les règles de gestion et un minimum du processus de ce système.

[kuntagp]

1) clt_type_piece c'est le type de piece d'identité du client.
clt_num_piece le numero de la picece d'identitè.

2)je peux externaliser la ville mais le client n'est pas forcement dans son pays d'origine donc le lien entre ville et pays ne doit pas etre automatique.

3)paradoxalement les clients nous vendent le métal.

4)j'en prends note ;-)

5) effectivement il peut y avoir des acheteurs en ressourceries (comptoir) ou des acheteurs mobiles.


nous achetons des metaux sur sites ou les clients viennent au depôt, nous devons recuperer le cours du metal dans la base de données avant la transaction, le client peut être de type particulier ou entreprise, nous avons l'obligation légale d'avoir tous les renseignements sur le client(du aux nombreux vols de metaux), la ville de la transaction n'est pas forcement celle du magasin.

Est ce mieux ainsi?

[CinePhil]

2)je peux externaliser la ville mais le client n'est pas forcement dans son pays d'origine donc le lien entre ville et pays ne doit pas etre automatique.

Peu importe, la ville ne change pas de pays !
Ma remarque consistait à éviter d'avoir dans la même colonne Saint-Étienne, Saint Etienne, St. Etienne, St-Etienne... pour la même ville.
Mais ta réponse veut-elle dire que l'association entre le pays et le client est le pays d'origine du client ? Son pays de naissance ?
Dans ce cas, tu peux conserver l'association mais nomme là plus précisément.
client -1,1----naitre----0,n- pays

le client peut être de type particulier ou entreprise

Je ne vois pas cette distinction dans ton MCD. Ça n'a pas d'importance ? Tu ne dois conserver que les données relatives à la personne physique qui te vend le métal ?

Dans ton MCD corrigé, vu que tu as externalisé mla ville, il faut retirer les propriétés ville des autres entités en association avec l'entité ville.

Tout comme la ville, le magasin ne voyage pas ! L'association que j'avais donnée entre ville et pays reste pertinente et dans le cas du magasin, l'association avec le pays n'est plus utile puisqu'on retrouvera le pays via la ville.

C'est un détail mais l'emploi du verbe "ficher" dans l'association entre pays et client me choque un peu !

Un acheteur achète un reçu ? Le verbe approprié ne serait-il pas plutôt "émettre" ?

Pourquoi y a t-il la ville dans le reçu ? Est-ce la ville où a lieu la vente de métal ? Donc la ville où est édité le reçu ?

Les cardinalités de l'association "évaluer" sont probablement fausses. Ou alors il faut envisager de fusionner matiere et cours !

[kuntagp]

La ville du recu est la ville d'edition, le "ficher" c'était de l'humour par rapport à tous ce que l'on nous demande comme renseignements .
Par contre j'ai du mal à trouver un verbe pour la ligne de recu et la matiere de la ligne un petit coup de main svp .
C'est mieux la?

[kuntagp]

j'ai apporté quelques modifications et je pense être à la version finale si quelqu'un pouvait me confirmer qu'il n'y a aucune erreur ce serait gentil (le diable se cache dans les détails).

[CinePhil]

Ton idée d'une entité pour les cours des matières n'était pas mauvaise ; je suggérais d'abord de changer les cardinalités :
matiere -1,n----evaluer----1,1- cours
En ajoutant la date du cours car sinon tu perds l'historique des cours et tu ne sais plus à quel cours a été acheté le métal. À moins que la propriété lig_recu_pnet corresponde au cours de la matière au moment de l'achat ? Dans ce cas, effectivement, plus besoin de la table des cours ; l'information du cours en vigueur serait simplement mise à jour régulièrement dans la table des matières.

Appelle l'association "ligne_du_recu" avec le verbe "contenir" :
recu -1,n----contenir----1,1- ligne_recu

Appelle l'association "mat_de_ligne" avec le verbe "concerner" :
ligne_recu -1,1----concerner----0,n- matiere

Allons jusqu'au bout de l'externalisation des données répétitives en externalisant aussi clt_titre qui, je suppose, correpond à Monsieur (M.), Madame (Mme), Mademoiselle (Mle)...

Le reste me semble OK, même si je ne comprends pas tous les noms des propriétés.

[kuntagp]

L'historique du cours n'est pas important le principal c'est que le cours soit mis à jours manuellement à 08h00 et 12h00.

Merci pour client titre je me demandais si ce n'aurait pas été trop lourd de l'externaliser j'ai la réponse de quelqu'un eminement plus compétent que moi dans le domaine .

Voila le mcd avec les corrections apportées et le sql généré à partir du mcd, en te remerciant d'avance (le mot est faible).