Discussion :

[lakika]

Bonjour a tous,

Je me presente je m'appel Kilian et je suis actuellement étudiant en 4ème année d'école de commerce.

J'ai un projet en informatique qui consiste a créer une base de donnée pour une entreprise medicale dont voici les contraintes :

L'entreprise vend des produits médicaux (Stent, cathéter,etc...) et souhaite créer une base de données afin de rassembler diverses données du marché. Elle souhaite connaitre, par pays :

-le nombre d’intervention médicale,
-le Nombre de produits medicaux qu'ils possèdent (Stent, catheter, etc..),
-le prix de vente moyen des produits.

Les produits sont classés dans différente catégories (Cardiovasculaire, Neuro, Endovasculaire, etc...).

J'ai fait ce MCD, mais je ne comprend pas comment faire pour afficher un prix différent du même produit pour different pays.
J'espere que vous saurez m'aider..

Merci d'avance de votre aide !

[escartefigue]

Bonjour,

L'énoncé n'est pas très clair :

- dans le langage usuel, une intervention médicale est un soin (opération, pansement, traitement etc...) et non une vente de matériel, or, vous ne parlez pas de soin, ni de produit pharmaceutique, mais seulement de matériel
- vous ne pouvez pas connaitre le nombre de produits possédés (il me semble que le terme "matériel" ou "équipement" serait plus adéquat que "produit"), car vous ne connaissez que les ventes, il vous manque donc les informations sur le matériel perdu, détruit ou revendu.


Quelques remarques sur votre modèle :

- tout d'abord, une règle fondamentale est que tout attribut doit dépendre fonctionnellement de son identifiant. Or, le prix moyen dépend non seulement du pays mais aussi du produit.
Il faut donc, si le prix est unique pour un pays à un instant "t", définir un attribut prix_de_vente, qui sera une propriété d'une relation entre pays, produit et date (une relation ternaire donc).
Ceci répondra à votre interrogation sur comment connaitre le prix du même produit pour différents pays

- autre règle fondamentale : une donnée calculée ne doit jamais être stockée (à quelques très rares exceptions règlementaires près comme le prix TTC qui est la somme du HT + TVA)
Donc, le prix moyen, ne doit pas être stocké, ce sera une donnée calculée par traitement en fonction de la période à considérer. De même pour le nombre d'interventions par pays (il faudra d'ailleurs préciser ce que vous appelez une "intervention"

- autre règle très importante pour la fiabilité et les performances de votre BDD : ne définissez jamais d'identifiant primaire de format char ou varchar. Idéalement, choisissez des identifiants de type integer et attribués par le SGBD (colonne de type "identifier", certains SGBD parlent "d'auto incrément")

- attention aux noms utilisés pour vos relations, l'usage est d'utiliser des verbes à l'infinitif, et certains sont inadéquats : un pays ne "contient" pas des produit

- pour les cardinalités des relations avec les entités-type qui identifient des typologies, il est préférable de prévoir un minimum de zéro coté typologie.
Par exemple, dans votre cas, si tout produit doit bien avoir une et une seule catégorie, il faut prévoir par contre que certaines catégories n'aient pas forcément de produit.
Les bonnes cardinalités sont donc [PRODUIT] 1,1 --- (Typer) --- 0,n [CATEGORIE]

[CinePhil]

Bonjour,

Il suffit de déplacer la propriété prix_produit dans l'association Contient.

Quelques remarques complémentaires à cette réponse...

1) Les identifiants doivent être de type entier autoincrémentés.

2) Plutôt qu'un type Text, préférez le VARCHAR, sauf si ça doit vraiment contenir un texte long.

3) Que représente PrixMoyen_pays ?
C'est le prix moyen de quoi ?
L'entité type Pays ne devrait comporter que des propriétés concernant le pays

4) Pourquoi avoir mis le pays dans le produit ?
C'est une information que vous obtiendrez grâce à l'association entre pays et produit. Et comme un produit peut être vendu dans plusieurs pays, vous ne pouvez pas indiquer cette information dans produit.

5) Idem pour le nom de produits puisque, d'après votre texte, ça dépend du pays où est vendu le produit.

6) Idem pour la procédure qui est associée au pays et non pas au produit.
D'ailleurs, cette association est-elle pertinente ?
N'est-ce pas une procédure applicable à un produit dans un pays ?

Bref, tout est à revoir !

Pour vous aider, lisez mon article de blog sur les règles de gestion des données.

[lakika]

Bonjour,

L'énoncé n'est pas très clair :

- dans le langage usuel, une intervention médicale est un soin (opération, pansement, traitement etc...) et non une vente de matériel, or, vous ne parlez pas de soin, ni de produit pharmaceutique, mais seulement de matériel
- vous ne pouvez pas connaitre le nombre de produits possédés (il me semble que le terme "matériel" ou "équipement" serait plus adéquat que "produit"), car vous ne connaissez que les ventes, il vous manque donc les informations sur le matériel perdu, détruit ou revendu.


Quelques remarques sur votre modèle :

- tout d'abord, une règle fondamentale est que tout attribut doit dépendre fonctionnellement de son identifiant. Or, le prix moyen dépend non seulement du pays mais aussi du produit.
Il faut donc, si le prix est unique pour un pays à un instant "t", définir un attribut prix_de_vente, qui sera une propriété d'une relation entre pays, produit et date (une relation ternaire donc).
Ceci répondra à votre interrogation sur comment connaitre le prix du même produit pour différents pays

- autre règle fondamentale : une donnée calculée ne doit jamais être stockée (à quelques très rares exceptions règlementaires près comme le prix TTC qui est la somme du HT + TVA)
Donc, le prix moyen, ne doit pas être stocké, ce sera une donnée calculée par traitement en fonction de la période à considérer. De même pour le nombre d'interventions par pays (il faudra d'ailleurs préciser ce que vous appelez une "intervention"

- autre règle très importante pour la fiabilité et les performances de votre BDD : ne définissez jamais d'identifiant primaire de format char ou varchar. Idéalement, choisissez des identifiants de type integer et attribués par le SGBD (colonne de type "identifier", certains SGBD parlent "d'auto incrément")

- attention aux noms utilisés pour vos relations, l'usage est d'utiliser des verbes à l'infinitif, et certains sont inadéquats : un pays ne "contient" pas des produit

- pour les cardinalités des relations avec les entités-type qui identifient des typologies, il est préférable de prévoir un minimum de zéro coté typologie.
Par exemple, dans votre cas, si tout produit doit bien avoir une et une seule catégorie, il faut prévoir par contre que certaines catégories n'aient pas forcément de produit.
Les bonnes cardinalités sont donc [PRODUIT] 1,1 --- (Typer) --- 0,n [CATEGORIE]

Bonjour Escartefite,

Tout d'abord merci de votre réponse,

Concernant vos interrogations sur l'ennoncé :

- Le nombre d'interventions correspond aux interventions qui utilisent le même type de produit que l'entreprise vend dans ce pays. (Exemple : Le nombre d'angioplastie pratiqué ,car ils y utilisent des stents)
- C'est vrai que c'est très général, je voulais dire le nombre de produit que l'entreprise a vendu selon le pays.

A propos du modèle :

- Ah oui d'accord la relation ternaire.. Je vais donc corriger ca.

- Oui pour les clefs primaire j'en suis conscient, d'ailleurs je dois créer la base de données sur access après et je sais que le numeroAuto est bien mieux, voir indispensable.

-je vais mettre a jouer les relations et les cardinalités aussi,

Merci beaucoup de votre aide !

Bonjour,

Il suffit de déplacer la propriété prix_produit dans l'association Contient.

Quelques remarques complémentaires à cette réponse...

1) Les identifiants doivent être de type entier autoincrémentés.

2) Plutôt qu'un type Text, préférez le VARCHAR, sauf si ça doit vraiment contenir un texte long.

3) Que représente PrixMoyen_pays ?
C'est le prix moyen de quoi ?
L'entité type Pays ne devrait comporter que des propriétés concernant le pays

4) Pourquoi avoir mis le pays dans le produit ?
C'est une information que vous obtiendrez grâce à l'association entre pays et produit. Et comme un produit peut être vendu dans plusieurs pays, vous ne pouvez pas indiquer cette information dans produit.

5) Idem pour le nom de produits puisque, d'après votre texte, ça dépend du pays où est vendu le produit.

6) Idem pour la procédure qui est associée au pays et non pas au produit.
D'ailleurs, cette association est-elle pertinente ?
N'est-ce pas une procédure applicable à un produit dans un pays ?

Bref, tout est à revoir !

Pour vous aider, lisez mon article de blog sur les règles de gestion des données.

Merci de votre réponse,

Je débute dans les bases de données, je ne savais même pas que l'on pouvait faire cela, c'est pour ca que je n'y ai pas pensé

Concernant vos remarques :

1) Identifiant entier, c'est noté je modifie ca tout de suite,
2) Varchar a la place de texte, merci du conseil,
3) Le Prix moyen est le prix moyen des produtis de la concurrence dans ce pays
4) Très bonne question..
5) D'accord, je vais corriger tout ca
6) Oui on peut dire que une procedure est applicable a un produit dans un pays.. J'avais juste penser que la procédure etait réaliser dans un pays avec un produit, ce qui explique la relation.. Mais votre analyse est plus pertinente

Oui tout est à revoir, mais je vous remercie de votre aide, j'éspère qu'on arrivera a construire quelque chose qui tient la route

Voici donc le nouveau MCD, qu'en pensez vous ?

[CinePhil]

En même temps, ce n'est pas de votre faute de ne pas savoir tout ce qu'on vous dit :

étudiant en 4ème année d'école de commerce

La conception de base de données est un métier différent de celui que vous apprenez. C'est même un peu étonnant qu'on vous demande de faire ça en stage d'école de commerce.

[lakika]

En même temps, ce n'est pas de votre faute de ne pas savoir tout ce qu'on vous dit :

La conception de base de données est un métier différent de celui que vous apprenez. C'est même un peu étonnant qu'on vous demande de faire ça en stage d'école de commerce.

Aha oui c'est vrai, mais l'école veut que l'on possède un minimum de connaissances en informatique et en base de données..

[SQLpro]

En ce qui concerne le prix, il faut toujours distinguer le prix "catalogue" qui peut effectivement être par pays et le prix de vente réel.
En effet, ce prix de vente réel dépend du pays, du client et du "contrat" de vente.
Si le client A achetè 100000000 cathéters, votre entreprise lui fera sans doute un prix bien plus remisé que si le client A n'est achète qu'un !

A +

[lakika]

En ce qui concerne le prix, il faut toujours distinguer le prix "catalogue" qui peut effectivement être par pays et le prix de vente réel.
En effet, ce prix de vente réel dépend du pays, du client et du "contrat" de vente.
Si le client A achetè 100000000 cathéters, votre entreprise lui fera sans doute un prix bien plus remisé que si le client A n'est achète qu'un !

A +

Oui je suis bien d'accord avec vous, mais pour le moment je pense que je vais rester dans le cas ''simple'' ou l'entreprise vend ces produits aux même prix pour tout le monde dans un pays.

EDIT : Sinon, que pensez-vous de ce nouveau MCD ?

[escartefigue]

bonjour,

Vous n'avez pas tenu compte de certaines remarques déjà formulées

Dans l'entité-type Pays :
- le nom en numérique ne convient pas
- encore une fois, une donnée calculée comme le prix moyen ne doit pas être stockée, je l'ai déjà expliqué précédemment

Dans l'ET matériel :
- le type matériel doit être supprimé, il faut créer une autre entité-type "TYPE_MATERIEL" et créer une relation avec "MATERIEL"
- là encore, le nombre de matériel vendu ne doit pas être stocké, mais calculé

Dans l'ET procédure :
- un identifiant ne doit jamais être en varchar

Dans la relation ternaire DATE+PAYS+PRODUIT :
- l'entité-type "DATE" n'est la que pour permettre à la table issue de la relation d'hériter de la date dans sa PK.
Pour ce faire, il faut que l'identifiant primaire de l'entité-type "DATE" soit justement la date, et non un identifiant attribué par le SGBD !

Dans toutes vos relations :
- choisissez un verbe à l'infinitif pour nommer les relations.
Vendu_dans_des ==> vendre
Exécuté_avec ==> exécuter
Appartient ==> appartenir

Pensez aussi à afficher la longueur des attributs

[lakika]

bonjour,

Vous n'avez pas tenu compte de certaines remarques déjà formulées

Dans l'entité-type Pays :
- le nom en numérique ne convient pas
- encore une fois, une donnée calculée comme le prix moyen ne doit pas être stockée, je l'ai déjà expliqué précédemment

Dans l'ET matériel :
- le type matériel doit être supprimé, il faut créer une autre entité-type "TYPE_MATERIEL" et créer une relation avec "MATERIEL"
- là encore, le nombre de matériel vendu ne doit pas être stocké, mais calculé

Dans l'ET procédure :
- un identifiant ne doit jamais être en varchar

Dans la relation ternaire DATE+PAYS+PRODUIT :
- l'entité-type "DATE" n'est la que pour permettre à la table issue de la relation d'hériter de la date dans sa PK.
Pour ce faire, il faut que l'identifiant primaire de l'entité-type "DATE" soit justement la date, et non un identifiant attribué par le SGBD !

Dans toutes vos relations :
- choisissez un verbe à l'infinitif pour nommer les relations.
Vendu_dans_des ==> vendre
Exécuté_avec ==> exécuter
Appartient ==> appartenir

Pensez aussi à afficher la longueur des attributs

Bonjour Escartefigue,

Merci de ta rapidité ! Effectivement je n'ai pas tenu compte de certaines remarques.. Mais c'est parce que je ne comprend pas vraiment, que dois-je faire avec les nombres si "une donnée calculée comme le prix moyen ou le nombre d'interventions ne doit pas être stockée" ? De plus, ces chiffres ne sont pas vraiment calculés, ils sont donné directement par les différentes équipes de l'entreprise. Je ne sais pas si il y a une difference mais j'aimerais donc savoir comment faire pour remedier à ce problème.

Concernant la longueur des attributs, ils sont tous réglé à 25 par défaut.

Voici le nouveau schama en attendant de savoir comment ne pas stocké les donnée calculées.
Merci d'avance.

[escartefigue]

De plus, ces chiffres ne sont pas vraiment calculés, ils sont donné directement par les différentes équipes de l'entreprise. Je ne sais pas si il y a une difference mais j'aimerais donc savoir comment faire pour remedier à ce problème.

En ce cas c'est différent, mais ce n'est de toutes façons pas dans le pays que vous devez stocker l'info, car le prix moyen change chaque année, le nombre de ventes aussi

Ce que vous pouvez faire, c'est créer un sous-ensemble dédié aux éléments statistiques externes dont vous avez besoin, ce qui donnerait ceci :
[CRITERE] 0,n --- (valoriser) --- 0,n [PERIODE]

Avec
- CRITERE(id, code, libellé)
- PERIODE en fonction de vos besoin, l'année seule par exemple
- valoriser (valeur, unité_de_mesure)
Valoriser deviendra une table qui aura pour identifiant le couple id du critère + l'année (si c'est à l'année) et pour autres attributs la valeur et son unité de mesure.

Concernant la longueur des attributs, ils sont tous réglé à 25 par défaut.

Ca ne va pas, c'est trop court pour un nom, et trop long pour un code, les longueurs doivent être déterminées pour chaque attribut

[lakika]

En ce cas c'est différent, mais ce n'est de toutes façons pas dans le pays que vous devez stocker l'info, car le prix moyen change chaque année, le nombre de ventes aussi

Ce que vous pouvez faire, c'est créer un sous-ensemble dédié aux éléments statistiques externes dont vous avez besoin, ce qui donnerait ceci :
[CRITERE] 0,n --- (valoriser) --- 0,n [PERIODE]

Avec
- CRITERE(id, code, libellé)
- PERIODE en fonction de vos besoin, l'année seule par exemple
- valoriser (valeur, unité_de_mesure)
Valoriser deviendra une table qui aura pour identifiant le couple id du critère + l'année (si c'est à l'année) et pour autres attributs la valeur et son unité de mesure.


Ca ne va pas, c'est trop court pour un nom, et trop long pour un code, les longueurs doivent être déterminées pour chaque attribut

D'accord... Je vous ai perdu je crois Je le relie à quoi le sous-ensemble ? Il me permettra de trouver le nombre d'interventions, de produits et le prix des produits dans le pays ?

Du coup vous me conseiller quoi pour les longueurs des attributs ?

[escartefigue]

Tout dépend de ce dont dépend chacun des montants que vous avez à saisir, ce qu'il faut c'est que les identifiants soient cohérents avec ces montants.
Si le prix saisi (et non calculé ) est indépendant du matériel, et ne dépend que du pays et de l'année, alors c'est un attribut de la relation entre pays et année
Si le prix saisi est lié à un pays, un matériel et une année, alors il faut une nouvelle relation ternaire entre ces trois Entité-Type, et ce prix sera un attribut de cette relation
Le prix de vente par contre, dépend du pays, du materiel et de la date, c'est donc bien ce que vous avez modélisé (puisque vous ne gérez pas de remise, ristourne et autres rabais sur volume d'affaires)

[lakika]

D'accord merci, donc voici le nouveau MCD. (J'ai rajouté la population du pays aussi, j'avais oublier ce petit détails dans l'ennoncé)



Est-ce que ca vous parait correcte ?

[escartefigue]

Si nombre_matériel _vendu est la somme des ventes, alors il faut déplacer l'attribut dans la relation vendre et calculer la somme quand nécessaire
Si c'est une donnée statistique saisie au titre d'un matériel, alors cette donnée dépend probablement de l'année voire d'autres critères ? a préciser

Pensez à supprimer l'attribut "type_materiel" de l'ET materiel puisque c'est la relation avec l'ET type_materiel qui permet de connaitre cette info

Vous avez mis 0,1 de materiel vers type, ça signifie que certains matériels ne sont pas typés, Est-ce volontaire ?
A l'inverse, de type vers matériel, il est préférable de mettre 0,n plutôt que 1,n

Qu'est ce que l'attribut nombre_procedure ?

Pour le reste c'est beaucoup mieux

[lakika]

Si nombre_matériel _vendu est la somme des ventes, alors il faut déplacer l'attribut dans la relation vendre et calculer la somme quand nécessaire
Si c'est une donnée statistique saisie au titre d'un matériel, alors cette donnée dépend probablement de l'année voire d'autres critères ? a préciser

Pensez à supprimer l'attribut "type_materiel" de l'ET materiel puisque c'est la relation avec l'ET type_materiel qui permet de connaitre cette info

Vous avez mis 0,1 de materiel vers type, ça signifie que certains matériels ne sont pas typés, Est-ce volontaire ?
A l'inverse, de type vers matériel, il est préférable de mettre 0,n plutôt que 1,n

Qu'est ce que l'attribut nombre_procedure ?

Pour le reste c'est beaucoup mieux

C'est une donnée statistique et cela dépend donc de l'année, et même du mois si possible.
Oui merci j'avais oublier de l'enlever
C'etait volontaire mais c'etait une faute, je voulais dire que un materiel ne peut avoir qu'une seule categorie et qu'une categories peut avoir plusieurs materiels.

L'attribut nombre de procedure correspond au nombre de procedure qui ont eu lieu dans le pays avec le type de materiel dit.

Voici le MCD avec les quelques corrections, mais comment faire pour que le nombre de materiel vendu soit dependant de l'année ou du mois du coup ?

[escartefigue]

L'attribut nombre de procedure correspond au nombre de procedure qui ont eu lieu dans le pays avec le type de materiel dit.

Du coup, compte tenu de nos discussions qui précèdent, vous devriez être en mesure de voir ce qui ne va pas avec cet attribut

[lakika]

Aha je n'en suis pas si sur...

J'ai pensé à cela, qu'en dites-vous ?

[escartefigue]

On y est presque, l'attribut "nombre_procédure" devrait être une propriété de la nouvelle relation.

La démarche est la suivante :
Je me pose la question : est-ce que l'identifiant "id_procédure" seul, permet de connaitre à coup sur l'occurrence de l'attribut "nombre_procédure" ?
Oui ==> l'attribut doit être propriété de l'entité-type procédure
Non ==> l'attribut doit être déplacé. Ici c'est bien la relation "exécuter" qui deviendra une table qui possèdera les 3 identifiants requis

Exemple courant dans beaucoup de MCD :
Le n° de téléphone est il un attribut de l'entité-type personne, est ce que l'identifiant personne seul permet de connaitre à coup sur son n° de téléphone ?
La réponse est non, car certaines personnes ont plusieurs numéro de téléphone, d'autres n'ont pas de téléphone
Il faut donc modéliser ce cas d'espèce ainsi
[PERSONNE] 0,n ---(posseder) --- 1,n [TELEPHONE] 1,1 --- (typer) --- 0,n [TYPE TEL]

[lakika]

Super ! Merci pour tous vos conseils !

J'ai donc déplacé le nombre de procedure dans la relation "executer".
Ca donne ceci Vous en pensez quoi ?