Discussion :

[Hadzo]

Bonjour,
J'ai un MCD à faire, j'ai réussi la partie article et client mais je n'ai aucune idée de comment continuer.

Plus précisément je sais pas comment faire pour que seul les employés du service télévente puisse gérer les commandes et comment faire pour que les commandes de types "vrac" soit pris en compte.
Voici ce que j'ai fais pour l'instant:

merci d'avance pour voter aide,

[escartefigue]

Bonjour,

Quelques remarques d'ordre général :

Il serait plus confortable de communiquer l'énoncé sous forme de texte au lieu d'une image, ceci pour nous permettre d'en copier/coller des extraits.

il ne faut pas choisir des attributs porteurs de sens comme un code ou un libellé comme identifiants des types d'entité.
En effet, l'identifiant du type d'entité devient clef primaire au stade SQL et se propage donc dans toutes les tables liées au travers des contraintes d'intégrité.
Or un code comme un libellé peuvent changer à tout moment, ce faisant, chaque modification de valeur va se répercuter dans toutes les lignes filles des tables associées. Ca peut représenter des dizaines, des milliers ou des centaines de millions de mises à jour inutiles et couteuses.
Une PK doit être stable, c'est pourquoi on choisit le plus souvent une identifiant technique, dénué de sens, stable et concis, donc performant.
Pour ce besoin, rien de mieux qu'une valeur attribuée par le SGBD (identity, counter, auto_increment, serial ou number selon le SGBD). C'est le SGBD qui en garantit l'unicité et son type integer est ce qu'il y a de mieux pour les performances.
Il semble que vous utilisiez Looping comme logiciel de modélisation, c'est un excellent choix
Dans Looping, pour utiliser un identifiant technique attribué par le SGBD, il faut ajouter une rubrique et choisir le type "compteur" dans la boite de dialogue "rubrique" puis cocher la case "identifiant".

Les codifications utilisées pour les variétés ou les clients seront donc associées à une contrainte UNIQUE, mais ne serviront pas de clef primaire.
Bien évidemment, le prénom de l'employé qui ne saurait être unique (sauf si on s'interdit d'embaucher plusieurs personnes de même prénom ) ne sera en aucun cas une PK, là encore, une colonne technique de valeur attribuée par le SGBD est la solution .


Concernant les employés et la télévente
Ce que ne dit pas votre énoncé, mais qui est implicite, est qu'un même employé peut tout à fait travailler dans un premier temps dans un service S1, puis être muté dans un service S2. Il faudra donc modéliser une association à date entre employé et service (association ternaire donc, "date" étant une entité-type dite fictive).
Vous avez d'ailleurs oublié de modéliser l'entité-type service, "télévente" est un service, mais certainement pas un sous-type d'employé !


Concernant les articles et les variétés
Comme la variété ne peut exister sans l'article, il s'agit de ce qu'on appelle une entité-type faible de l'article. On identifiera donc la variété relativement à l'article (présence du (R) près des cardinalités)
[ARTICLE] 1,n --- (rattacher) --- 1,1(R) [VARIETE]
Dans Looping, pour mettre en œuvre l'identification relative, il faut cliquer sur la "patte" de l'association puis cocher la case "identifiant relatif" à coté de 1,1


Concernant les catégories
Pour les typologies, telles que la catégorie d'articles, il est recommandé d'utiliser une cardinalité minimale de zéro coté typologie. Par exemple [ARTICLE] 1,1 --- (lier) --- 0,n [CATEGORIE]
En effet, à un instant "t" il est possible de n'avoir aucun article dans la catégorie, il ne faut pas que ce soit bloquant.

[Hadzo]

Désolé de la réponse tardive je n'avais pas reçu de mail. Voici l'enoncé au complet:


L’activité de la société Primeurs-passion a pour activité principale la vente de fruits et légumes (dénommés articles).


Les articles :

Chaque variété est codifiée. Exemple : la pomme Golden de calibre 70 a pour code PMGO7001.
Chaque variété est rattachée à un article. Exemple : La variété « Golden » est rattaché à l’article « Pomme ». Pour un
article, il existe souvent plusieurs variétés.
L’article « Pomme » n’est pas codifié. Il est rattaché à la catégorie « Fruits ». Il existe d’autres catégories de fruits tels
que les fruits exotiques, des fruits rouges et des fruits secs. Pour une catégorie, il existe plusieurs articles.
Le prix d’un produit dépend de sa variété, de son calibre et de la catégorie du client qui l’achète. Une catégorie de client
est identifiée par un nom appelé « nomTarif ». Cette dénomination n’est pas claire mais doit être respectée !
Certaines variétés, qui ne sont pas en vente, n’ont pas de prix et sont donc associés à aucune catégorie de client.
Les prix d’achat et de vente des articles évoluent au cours du temps, et notamment en fonction de la saison.

Les clients :

Un client est identifié par un code sur 7 caractères. Le premier caractère est C (comme Client). Les 6 suivants sont
attribués selon le nom du client (Exemples « Abeille Royale » est codifié « CABEROY », « Au mont d’Arbois » est codifié
« CAUMOAR » et « Saperlipopette » est codifié « CSAPERL »).
« Abeille Royale » est un traiteur et bénéficie donc du tarif « Traiteur » (nomTarif).
On mémorise aussi notamment pour chaque client son nom, son adresse et son téléphone…
Quelques exemples de noms de tarifs : Personnel, Boulangerie, Traiteur, Collectivités, Restauration1, Restauration2,
Restauration3… Une catégorie (c’est-à-dire un nom de tarif) est attribuée à chaque client par les commerciaux en
fonction de la notoriété, le chiffre d’affaires, ou les relations des clients. Ces informations ne sont pas mémorisées !
Ce sont les employés du service « Télévente » qui gèrent (Création, suppression, modification) les clients. Le code client
est attribué de façon automatique par l’ordinateur selon le nom du client.

Les commandes :
Les clients passent des commandes exclusivement par téléphone en appelant le service « Télévente ». Les employés
du service « Télévente » saisissent les commandes : Produits commandés, quantités, date de livraison prévue. Sont
ajoutés automatiquement les informations suivantes : date et heure de la saisie de la commande et identifiant de la
personne qui saisit la commande.
Attention, on ne peut commander que des produits dont la quantité en stock permet d’assurer la livraison.

Préparation de la commande et livraison :
Chaque commande est affectée à un préparateur. Le préparateur est la personne qui lit la commande et met les produits
dans des colis. Un colis est un regroupement d’articles ou un article (Exemples : 1 sac de pommes de terre de 25 kg
constitue 1 colis, 1 carton de bananes de 18kg constitue 1 seul colis, 1 colis appelé « Vrac » peut être rempli de 1 kg de
fraises, 3 kg de poivrons verts et 2 kg de tomates).
Lorsque le préparateur prépare la commande, il pèse chaque produit qui peut un peu différer du poids indiqué sur la
commande. C’est le poids réel qui apparaît sur la facture et le prix correspondant à ce poids.
Une étiquette est collée sur chaque colis ; l’étiquette contient les informations suivantes :
- N° de commande
- Nom et code du client
- Numéro de tournée (Le numéro de tournée est un nombre compris entre 1 et 15 et qui correspond au numéro
de camion qui va faire la tournée).
- Préparateur de la commande
- Nombre total d’étiquettes (de colis) constituant la commande

Factures :
Les factures sont imprimées chaque jour et données au client en même temps que la livraison. Même si le montant de la
facture peut être recalculée à tout moment (grâce aux prix unitaires des articles et de leurs quantités), on choisit de
mémoriser le montant afin de pouvoir gérer d’éventuelles remises et/ou de pouvoir faire des vérifications ultérieures.

Anomalies :
Les anomalies constatées sont : produit non conforme, mauvais destinataire, quantité erronée, articles refusés (mauvais
état), livraison non effectuée.
Toutes les anomalies sont gérées soit par des commandes et donc des factures complémentaires, soit par un retour des
articles et donc des avoirs. Les avoirs sont gérés comme les factures mais leur montant est négatif. Une commande (ou
un avoir) peut donc être la suite d’une autre commande !

Employés de l’entreprise
Les employés sont tous identifiés par leur prénom. Ils ont chacun une fonction (vendeur, préparateur, livreur, acheteur).
Un client n’est pas un employé de l’entreprise ! Actuellement, aucun employé ne porte le même prénom mais si c’est le
cas, il faut prévoir de différencier les salariés en leur ajoutant la 1ère lettre de leur nom de famille (Exemple : Pierrec pour
Pierre Chamot). On mémorise aussi pour chaque employé son nom, sa date de naissance, sa date d’embauche et le
type de son contrat de travail (CDI, CDD, intérimaire, vacataire…).

Concernant les remarque que vous avez faite :
Déjà merci pour votre retour, mon professeur a dit que je peux continuer à utiliser les codes ou noms comme pk car on n'a pas utiliser l'outil de looping pour cela.
J'avais fais quelque modifications avant de voir votre message:




j'aimerais que quelqu'un m'aide pour la parties factures, anomalie et préparation de commande ou je suis complètement perdu.

[escartefigue]

Bonjour Hadzo

Je n'aurai probablement pas le temps de me repencher sur ce sujet ce WE, toutes mes excuses, mais j'y reviendrai.

Concernant cette remarque :

mon professeur a dit que je peux continuer à utiliser les codes ou noms comme pk car on n'a pas utiliser l'outil de looping pour cela.

Le choix de l'identifiant au niveau conceptuel, qui deviendra la PK au niveau SQL, n'a absolument rien à voir avec l'utilisation ou pas d'un logiciel de modélisation !
Un identifiant doit être choisi selon plusieurs critères :

1. il doit être unique : sa vocation est d'identifier de façon certaine une seule occurrence de l'entité, y compris s'il s'agit de jumeaux parfait
2. il doit être non nullable : sa valeur est obligatoire
3. il doit être stable : son contenu ne doit pas changer dans le temps
4. il doit être irreductible : une partie seulement de l'identifiant ne peut suffire à déterminer de façon certaine une seule occurrence

Et, facultativement, mais c'est fortement recommandé, il doit être concis pour des raisons de performances.

Or si vous choisissez un nom comme identifiant, c'est une valeur qui est ni stable (il peut changer, par exemple en cas d'erreur orthographique Dupond devient Dupont, ni unique (plusieurs personnes peuvent s'appeler Dupont), ni concise (chez les malgaches par exemple, les noms à rallonge sont monnaie courante).

Si vous choisissez un code, c'est un poil mieux, car plus concis qu'un nom, mais toujours pas stable. Les codes pays changent de temps à autre, les codes devise aussi, même les codes département (voyez la corse n° 20 devenue 2A et 2B).

Comme la PK se propage dans les tables liées au travers des contraintes d'intégrité, la modification d'un code ou d'un nom peut provoquer la modification en cascade de milliers, voire de millions de lignes dans les tables filles ! D'où l'intérêt d'un identifiant technique type chrono.
Le plus souvent, on laisse le SGBD attribuer ce chrono, il sont tous dotés de types faits pour ça qui sont performants et fiables (identity, sequence, auto_increment...)