Discussion: Entreprise médicale

  1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Territoire de Belfort (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : septembre 2017
    Messages : 14
    Points : 1
    Points
    1

    Par défaut Entreprise médicale

    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.Nom : mcd_database.png
Affichages : 71
Taille : 32,8 Ko
    J'espere que vous saurez m'aider..

    Merci d'avance de votre aide !

  2. #2
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 966
    Points : 6 525
    Points
    6 525
    Billets dans le blog
    1

    Par défaut

    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]

  3. #3
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 974
    Points : 28 810
    Points
    28 810
    Billets dans le blog
    4

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  4. #4
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Territoire de Belfort (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : septembre 2017
    Messages : 14
    Points : 1
    Points
    1

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    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 !

    Citation Envoyé par CinePhil Voir le message
    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 ?Nom : mcd_database.png
Affichages : 66
Taille : 34,0 Ko

  5. #5
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 974
    Points : 28 810
    Points
    28 810
    Billets dans le blog
    4

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  6. #6
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Territoire de Belfort (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : septembre 2017
    Messages : 14
    Points : 1
    Points
    1

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    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..

  7. #7
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 251
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 251
    Points : 39 953
    Points
    39 953
    Billets dans le blog
    1

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  8. #8
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Territoire de Belfort (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : septembre 2017
    Messages : 14
    Points : 1
    Points
    1

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    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 ? Nom : mcd_database.png
Affichages : 54
Taille : 34,0 Ko

  9. #9
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 966
    Points : 6 525
    Points
    6 525
    Billets dans le blog
    1

    Par défaut

    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

  10. #10
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Territoire de Belfort (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : septembre 2017
    Messages : 14
    Points : 1
    Points
    1

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    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.Nom : mcd_database.png
Affichages : 51
Taille : 38,8 Ko
    Merci d'avance.

  11. #11
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 966
    Points : 6 525
    Points
    6 525
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par lakika Voir le message
    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.

    Citation Envoyé par lakika Voir le message
    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

  12. #12
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Territoire de Belfort (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : septembre 2017
    Messages : 14
    Points : 1
    Points
    1

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    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 ?

  13. #13
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 966
    Points : 6 525
    Points
    6 525
    Billets dans le blog
    1

    Par défaut

    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)

  14. #14
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Territoire de Belfort (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : septembre 2017
    Messages : 14
    Points : 1
    Points
    1

    Par défaut

    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é)

    Nom : mcd_database.png
Affichages : 49
Taille : 52,1 Ko

    Est-ce que ca vous parait correcte ?

  15. #15
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 966
    Points : 6 525
    Points
    6 525
    Billets dans le blog
    1

    Par défaut

    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

  16. #16
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Territoire de Belfort (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : septembre 2017
    Messages : 14
    Points : 1
    Points
    1

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    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 ?
    Nom : mcd_database.png
Affichages : 44
Taille : 52,3 Ko

  17. #17
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 966
    Points : 6 525
    Points
    6 525
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par lakika Voir le message
    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

  18. #18
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Territoire de Belfort (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : septembre 2017
    Messages : 14
    Points : 1
    Points
    1

    Par défaut

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

    J'ai pensé à cela, qu'en dites-vous ?Nom : mcd_database.png
Affichages : 36
Taille : 58,4 Ko

  19. #19
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 966
    Points : 6 525
    Points
    6 525
    Billets dans le blog
    1

    Par défaut

    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]

  20. #20
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2017
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : France, Territoire de Belfort (Franche Comté)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : septembre 2017
    Messages : 14
    Points : 1
    Points
    1

    Par défaut

    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 ?
    Nom : mcd_database.png
Affichages : 31
Taille : 57,0 Ko

Discussions similaires

  1. Réponses: 1
    Dernier message: 02/02/2007, 10h29
  2. projet et base de donnée
    Par treejar dans le forum Accès aux données
    Réponses: 1
    Dernier message: 10/01/2007, 17h52
  3. Réponses: 13
    Dernier message: 12/12/2006, 21h44
  4. Réponses: 12
    Dernier message: 17/05/2006, 16h32
  5. [base de données]partage d'une base de données
    Par Scrusher dans le forum JDBC
    Réponses: 4
    Dernier message: 02/06/2004, 13h33

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo