IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Gifts


Sujet :

Schéma

  1. #1
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut Gifts
    Bonjour,

    Humble programmeur devant faire de l'administration de DB, je viens chercher quelques conseils pour l'élaboration d'un MCD.

    Je ne sais pas si c'est une information nécessaire mais j'utilise la notation UML.

    Un peu de contexte...
    Je travaille pour une chaine de magasin et nous (mon collègue et moi) allons devoir réécrire un programme existant pour la gestion de gift-cheque et gift-card.

    Je me suis donc attaqué au mcd. Là où j'ai un doute, c'est pour la classe Store. Elle possède juste un ID et un LIBELLE.

    Un store peut envoyer des gifts vers d'autres magasins. J'ai donc une relation ENVOYER réflexive sur cette classe.

    Ma question est :
    Dois-je également créer la relation RECEVOIR également réflexive sur cette même classe ?
    Kropernic

  2. #2
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Un store peut envoyer des gifts vers d'autres magasins. J'ai donc une relation ENVOYER réflexive sur cette classe.
    Les "gifts" ne sont-ils pas modélisés ?
    Ne devraient-ils pas intervenir dans cette association ? Ce qui donnerait une association ternaire.
    store -0,n----envoyer----0,n- gift
    |--------0,n---------|

    Ma question est :
    Dois-je également créer la relation RECEVOIR également réflexive sur cette même classe ?
    Non. Une seule suffit.
    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 !

  3. #3
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    Les "gifts" ne sont-ils pas modélisés ?
    Ne devraient-ils pas intervenir dans cette association ? Ce qui donnerait une association ternaire.
    store -0,n----envoyer----0,n- gift
    |--------0,n---------|
    Vous avez parfaitement raison. J'étais tellement focalisé sur ma question que j'en ai oublié de mettre un p'tit schéma de relation.

    Mais en fait, c'est un peu plus compliqué...
    Le temps de changer d'ordi pour basculer sur mon ordi de développement et je poste une image du MCD actuel.

    EDIT :

    Voilà donc une image du MCD en pièce jointe auquel je dois encore ajouter quelque chose pour l'adresse des clients (je débute avec power amc, j'espère avoir utilisé les bons outils ).

    Comme on le voit, l'entité Store n'est pas liée directement à l'entité Gift. Il y a, au milieu, une entité History qui est sensée permettre de retracer toute la vie d'un gift.
    L'entité Action définissant les différents types d'action possible dont notamment l'envoi et la réception de gift dans un magasin.

    En l'état, je peux facilement savoir dans quel magasin a été effectuée une action de réception ou d'envoi mais pas encore savoir l'origine ou la destination.

    Dans un monde parfait, je dirais que cela suffit car si j'ai une action d'envoi pour un gift, l'action suivante sera forcément une réception et me fournira la destination de l'envoi (et réciproquement l'origine de la réception).
    Mais si une erreur (disons humaine) survient et que mon gift se retrouve dans un autre magasin que celui auquel il était destiné à la base, en l'état, je n'en saurai jamais rien.

    Si je vous ai bien suivi, vous établiriez une relation ternaire entre store, store et history ?

    Etant débutant en la matière, je me suis offert le livre UML 2 pour les bases de données ( de Christian Soutou auquel (notre cher) sqlpro a collaboré) et il y est conseillé de décomposé les relations ternaires en relations binaires mais j'avoue avoir du mal.

    Pourriez-vous m'aider ?

    Sinon, d'un point de vue général, que pensez-vous du schéma ?
    Images attachées Images attachées  
    Kropernic

  4. #4
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut je pense avoir trouvé..
    Je pense être arrivé à quelque chose de correct (cfr shema en pièce jointe).

    J'ai également utilisé la notion d'héritage au niveau du client.

    Par contre, je n'arrive pas à déterminer les cardinalités de la relation ternaire...

    Pourrais-je avoir l'avis d'un des experts trainant dans le coin ?

    Merci d'avance !

    P.S. : Il est évident que je dois ajouter quelque chose pour gérer les adresses de livraison/facturation/courrier et que l'entité pays sera en liaison avec ces dernières plutôt avec client.
    Images attachées Images attachées  
    Kropernic

  5. #5
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Je regarde le premier schéma, qui est un petit mélange de "Entity/Relationship diagram" façon MySQL Workbench, et de MCD merisien puis qu'il comporte une association classique d'un MCD.

    Et justement, cette association "T_COMMANDEDETAIL_CDT" me semble fausse.

    Je la reproduis ci-dessous :
    T_COMMANDE_COM -0,n----T_COMMANDEDETAIL_CDT----0,n- T_GIFT_GFT

    Traduisons-là en français :
    "Une commande peut avoir plusieurs gifts et un gift peut être inclus dans plusieurs commandes."

    Comme on voit par ailleurs qu'un gift est doté d'un numéro de série (GFT_SERIAL), chaque gift semble donc unique et un gift ne peut pas être inclus dans plusieurs commandes.

    La bonne règle de gestion serait à mon avis celle-ci :
    "Une commande peut avoir plusieurs gifts et un gift appartient à une seule commande."

    MCD qui en découle :
    T_COMMANDE_COM -0,n----T_COMMANDEDETAIL_CDT----1,1- T_GIFT_GFT

    Et ici il n'y a plus de table associative T_COMMANDEDETAIL_CDT.

    Si un gift peut être créé indépendamment de la commande, on modifie alors la règle de gestion de cette manière :
    Une commande peut avoir plusieurs gifts et un gift peut être inclus dans une seule commande.

    MCD qui en découle :
    T_COMMANDE_COM -0,n----T_COMMANDEDETAIL_CDT----0,1- T_GIFT_GFT

    Ici par contre, il faut une table associative.

    À la lecture de ce premier schéma, je ne comprends pas bien le sens de la partie HISTORY, STORE et ACTION.

    Il y a, au milieu, une entité History qui est sensée permettre de retracer toute la vie d'un gift.
    L'entité Action définissant les différents types d'action possible dont notamment l'envoi et la réception de gift dans un magasin.

    En l'état, je peux facilement savoir dans quel magasin a été effectuée une action de réception ou d'envoi mais pas encore savoir l'origine ou la destination.
    Pourquoi donc ?
    HISTORY est typé par une ACTION, est effectué par un STORE et historise un GIFT. On peut donc retrouver toutes les actions d'un GIFT, envoi et réception.

    Par contre, le danger de ce schéma est que rien n'empêche un GIFT de faire l'objet de plusieurs envois et de plusieurs réceptions. Est-ce voulu ?

    Quel est le cycle de vie normal d'un gift ? Quels sont ses éventuels cycles de vie alternatifs ?

    Dans un monde parfait, je dirais que cela suffit car si j'ai une action d'envoi pour un gift, l'action suivante sera forcément une réception et me fournira la destination de l'envoi (et réciproquement l'origine de la réception).
    Mais si une erreur (disons humaine) survient et que mon gift se retrouve dans un autre magasin que celui auquel il était destiné à la base, en l'état, je n'en saurai jamais rien.
    Encore une fois, il me semble que, au contraire, puisqu'on peut trouver toutes les actions relatives à un gift, on trouvera éventuellement l'envoi vers un magasin M1 puis la réception par le magasin M2 de ce gift, ce qui permet de détecter l'erreur de livraison.

    Si je vous ai bien suivi, vous établiriez une relation ternaire entre store, store et history ?
    C'était une supposition que j'émettais suite à la formulation incomplète de la règle de gestion :
    Un store peut envoyer des gifts vers d'autres magasins.
    Dans cette phrase, je voyais trois éléments concernés : strore, gift et magasin, c'est à dire un autre store. D'où l'idée qu'il s'agirait plutôt d'une association ternaire.

    Etant débutant en la matière, je me suis offert le livre UML 2 pour les bases de données ( de Christian Soutou auquel (notre cher) sqlpro a collaboré) et il y est conseillé de décomposé les relations ternaires en relations binaires mais j'avoue avoir du mal.
    En l'occurrence, ici, vous n'utilisez pas le langage UML !
    Comme dit plus haut, votre schéma est du formalisme "Entity/Relationshp diagram" avec un soupçon de MCD merisien.

    Je n'ai pas lu ce livre mais je pense que ce que l'auteur a voulu dire est que, lorsqu'on dessine une association ternaire, il faut essayer de voir si on peut la décomposer en plusieurs associations binaires.

    Je vais prendre un autre exemple...
    Expression de la règle de gestion en français simple :
    Un projet peut faire travailler plusieurs personnes, chacune exerçant sur ce projet une à plusieurs fonctions.

    On aboutira au MCD suivant (association ternaire) :
    personne -0,n----travailler----0,n- projet
    fonction -0,n----------|

    Si vous essayez de découper, il manquera toujours une information :
    personne -0,n----travailler----0,n- projet
    => On ne sait pas quelle fonction exerce la personne sur le projet.

    personne -0,n----travailler----0,n- fontion
    => On ne sait pas à quoi s'applique la fonction de la personne.

    fonction -0,n----travailler----0,n- projet
    => On sait quelles fonctions interviennent sur le projet mais on ne sait pas quelles personnes assument ces fonctions.

    Je passe au second schéma...

    J'ai également utilisé la notion d'héritage au niveau du client.
    L'héritage est une bonne chose, si effectivement vous avez des clients particuliers et professionnels. Par contre, sur le plan de la symbolique, il me semble qu'il ne devrait y avoir qu'un seul demi-cercle à croix pour indiquer qu'un client est soit de l'un, soit de l'autre type. Voir avec les spécialistes de Power AMC comment résoudre ça.

    Pour ce qui est de la partie history, store, action, repartez du début en écrivant vos règles de gestion de façon claire, de manière à déduire le MCD (ou le diagramme entité/association) qui convient. À première vue, j'ai l'impression que l'association ternaire que vous avez ajoutée est redondante par rapport à l'ancien schéma.

    Par contre, je n'arrive pas à déterminer les cardinalités de la relation ternaire...
    Il n'y a pas beaucoup de question à se poser pour une association d'arité supérieure à 2. La cardinalité maxi sur toutes les branches est à n, sinon ce n'est pas une vraie association ternaire. Ce serait le cas typique d'association à décomposer en binaires !

    Le plus souvent, la cardinalité mini est de 0 sur toutes les branches car toutes les entités types participant à l'association ont en principe leur vie propre en dehors de l'association.
    Pour reprendre mon exemple avec les projets, je peux créer le projet avant de savoir quelles fonctions seront nécessaires à sa réalisation et quelles personnes y participeront.
    Aucune personne de l'entreprise ne travaillera sur tous les projets et il pourra y avoir des projets qui n'utilisera pas toutes les fonctions enregistrées en BDD.
    => Généralement, sur une ternaire, mettez 0,n sur toutes les branches !
    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
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    Je regarde le premier schéma, qui est un petit mélange de "Entity/Relationship diagram" façon MySQL Workbench, et de MCD merisien puis qu'il comporte une association classique d'un MCD.
    Merise ou UML, j'avoue que si on me montrait 1 schéma et que je devais dire de quel type il est, statistiquement, je me planterais une fois sur deux . Ma volonté est d'utiliser UML. Dans la pratique avec Power AMC (je viens tout juste de télécharger la version d'évaluation), je n'ai probablement pas utilisé les bons outils pour représenter ce que je voulais...

    Et justement, cette association "T_COMMANDEDETAIL_CDT" me semble fausse.

    Je la reproduis ci-dessous :
    T_COMMANDE_COM -0,n----T_COMMANDEDETAIL_CDT----0,n- T_GIFT_GFT

    Traduisons-là en français :
    "Une commande peut avoir plusieurs gifts et un gift peut être inclus dans plusieurs commandes."

    Comme on voit par ailleurs qu'un gift est doté d'un numéro de série (GFT_SERIAL), chaque gift semble donc unique et un gift ne peut pas être inclus dans plusieurs commandes.

    La bonne règle de gestion serait à mon avis celle-ci :
    "Une commande peut avoir plusieurs gifts et un gift appartient à une seule commande."

    MCD qui en découle :
    T_COMMANDE_COM -0,n----T_COMMANDEDETAIL_CDT----1,1- T_GIFT_GFT

    Et ici il n'y a plus de table associative T_COMMANDEDETAIL_CDT.

    Si un gift peut être créé indépendamment de la commande, on modifie alors la règle de gestion de cette manière :
    Une commande peut avoir plusieurs gifts et un gift peut être inclus dans une seule commande.

    MCD qui en découle :
    T_COMMANDE_COM -0,n----T_COMMANDEDETAIL_CDT----0,1- T_GIFT_GFT

    Ici par contre, il faut une table associative.
    Un gift peut bel et bien exister en dehors d'une commande (lorsqu'il est simplement en stock par exemple).

    À la lecture de ce premier schéma, je ne comprends pas bien le sens de la partie HISTORY, STORE et ACTION.


    Pourquoi donc ?
    HISTORY est typé par une ACTION, est effectué par un STORE et historise un GIFT. On peut donc retrouver toutes les actions d'un GIFT, envoi et réception.

    Par contre, le danger de ce schéma est que rien n'empêche un GIFT de faire l'objet de plusieurs envois et de plusieurs réceptions. Est-ce voulu ?

    Quel est le cycle de vie normal d'un gift ? Quels sont ses éventuels cycles de vie alternatifs ?
    Un gift peut effectivement faire l'objet de plusieurs envois/réceptions.
    Voici comment cela se passe :
    - la centrale fait une commande de X gift (des gifts-cards par exemple) à son fournisseur (et je me rends compte que cette partie n'est pas reprise dans mon MCD. Il va falloir que je demande si cette opération doit faire l'objet d'une sauvegarde)
    - la centrale répartit les gifts dans les différents magasins (X dans le premier, Y dans le second, Z dans le troisième, etc.).
    - le magasin réception les gifts
    - le magasin vend les gifts
    - le magasin renvoie les invendus vers la centrale

    Voilà le schéma classique du point de vue store, la centrale étant considéré comme un magasin également (après bien sûr, un gift, ici une gift-card, peut être utilisé, rechargé, volé, détruit, perdu (je crois que c'est tout)).
    Si pour une raison X ou Y, la centrale envoi trop de gifts dans un magasin, ce magasin retournera l'excédant à la centrale qui pourra les envoyer vers un autre magasin. Il peut donc y avoir un nombre indéfini d'aller et retour de gifts entre magasins.

    Encore une fois, il me semble que, au contraire, puisqu'on peut trouver toutes les actions relatives à un gift, on trouvera éventuellement l'envoi vers un magasin M1 puis la réception par le magasin M2 de ce gift, ce qui permet de détecter l'erreur de livraison.
    Ici je ne vous suis pas. Comment détectez-vous l'erreur de livraison si la destination de l'envoi n'est pas indiquée quelque part ?

    C'était une supposition que j'émettais suite à la formulation incomplète de la règle de gestion :

    Dans cette phrase, je voyais trois éléments concernés : strore, gift et magasin, c'est à dire un autre store. D'où l'idée qu'il s'agirait plutôt d'une association ternaire.
    Ok je comprends.

    En l'occurrence, ici, vous n'utilisez pas le langage UML !
    Comme dit plus haut, votre schéma est du formalisme "Entity/Relationshp diagram" avec un soupçon de MCD merisien.
    Même remarque qu'au début ^^.

    Je n'ai pas lu ce livre mais je pense que ce que l'auteur a voulu dire est que, lorsqu'on dessine une association ternaire, il faut essayer de voir si on peut la décomposer en plusieurs associations binaires.

    Je vais prendre un autre exemple...
    Expression de la règle de gestion en français simple :
    Un projet peut faire travailler plusieurs personnes, chacune exerçant sur ce projet une à plusieurs fonctions.

    On aboutira au MCD suivant (association ternaire) :
    personne -0,n----travailler----0,n- projet
    fonction -0,n----------|

    Si vous essayez de découper, il manquera toujours une information :
    personne -0,n----travailler----0,n- projet
    => On ne sait pas quelle fonction exerce la personne sur le projet.

    personne -0,n----travailler----0,n- fontion
    => On ne sait pas à quoi s'applique la fonction de la personne.

    fonction -0,n----travailler----0,n- projet
    => On sait quelles fonctions interviennent sur le projet mais on ne sait pas quelles personnes assument ces fonctions.
    Non non, il conseille bien d'éviter de les utiliser. Bien entendu, il précise également que dans certains, il sera impossible de s'en passer. Le cas que vous décrivez doit en faire partie.

    Je passe au second schéma...


    L'héritage est une bonne chose, si effectivement vous avez des clients particuliers et professionnels. Par contre, sur le plan de la symbolique, il me semble qu'il ne devrait y avoir qu'un seul demi-cercle à croix pour indiquer qu'un client est soit de l'un, soit de l'autre type. Voir avec les spécialistes de Power AMC comment résoudre ça.
    De nouveau un problème de représentation. Je sais comment résoudre cela (je sais quelle case j'ai coché pour mettre cette croix^^). Par contre, je m'interroge. La case à cocher en question porte le texte suivant : "Mutually exclusive children"
    Etant donné qu'il y a cette case dans chacune des "relations" générées par l'héritage, je me suis dis qu'il fallait coché les deux. De la façon dont je comprends la chose, le fait de cocher cette case indique, comme vous le préciser, qu'un client est soit un particulier, soit une entreprise. Cela est vrai pour le lien vers chaque enfant non ?

    Pour ce qui est de la partie history, store, action, repartez du début en écrivant vos règles de gestion de façon claire, de manière à déduire le MCD (ou le diagramme entité/association) qui convient. À première vue, j'ai l'impression que l'association ternaire que vous avez ajoutée est redondante par rapport à l'ancien schéma.
    Je vais tacher de réanalyser cette partie.


    En tout cas, un grand merci pour ce temps qui m'est consacré.
    Kropernic

  7. #7
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Je viens de vérifier... Dans power amc, j'ai choisi "Conceptual diagram" au lieu de "UML class diagram"

    Et lorsque je veux recréer mon schéma en choisissant la bonne option, plus moyen d'indiquer tel attribut est l'identifiant de ma classe '-_-

    Les joies de l'informatique
    Kropernic

  8. #8
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Pour modéliser une BDD, je préfère largement le MCD merisien au diagramme de classes UML.
    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 !

  9. #9
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    Pour modéliser une BDD, je préfère largement le MCD merisien au diagramme de classes UML.
    Mes maigres cours de modélisation remontant à loin, lorsque j'ai vu que sqlpro (qui est pour moi une des références de DVP en matière de DB) avait collaborer sur un bouquin traitant de modélisation, je me suis dit que cela ne pouvait être que bien.

    Du coup, je me le suis procuré et au final bah... Vu qu'il y a souvent le parallèle avec Merise, je vais continuer en Merise (donc avec mon schéma actuel) car cela me semble plus "naturel".

    Mais bon, les exemples sont transposables j'imagine et si j'ai bien lu, la principale différence avec merise se situerait dans le sens de lecture des cardinalités et la manière de représenté différentes symboliques.

    Bref, rien de bien transcendant jusqu'ici (je ne suis néanmoins qu'à la page 50).

    Puisque vous semblez avoir encore un peu de temps à me consacrer, pourriez-vous préciser votre penser concernant le suivi des envois de votre précédent message ? J'avoue ne pas vous suivre (cfr mon message en réponse au votre).
    Kropernic

  10. #10
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Un gift peut effectivement faire l'objet de plusieurs envois/réceptions.
    Voici comment cela se passe :
    - la centrale fait une commande de X gift (des gifts-cards par exemple)
    Si j'ai bien compris, il va donc y avoir création de X lignes dans la table des gifts ?

    - la centrale répartit les gifts dans les différents magasins (X dans le premier, Y dans le second, Z dans le troisième, etc.).
    - le magasin réception les gifts
    - le magasin vend les gifts
    - le magasin renvoie les invendus vers la centrale
    Là nous avons différents mouvements que vous appelez des types d'actions dans votre schéma et ces différents mouvements feront l'objet, pour chaque gift concerné, d'autant de lignes HISTORY.
    Comme toutes les lignes HISTORY sont horodatées, il est possible de retrouver le cycle de vie d'un gift.

    Par contre, le schéma est piégeux en l'état car un gift G1 peut être envoyé à un magasin M1 et c'est en fait le magasin M2 qui va vendre le gift G1 alors qu'il n'y a pas de mouvements de ce G1 entre M1 et M2.

    L'application peut contrôler pas mal de choses et éviter les erreurs mais la base de données ne sera pas d'une solidité à toute épreuve. Je ne sais pas a priori si des éléments de modélisation supplémentaires permettraient de parer à certains risques mais en tout cas il conviendrait de réaliser des procédures stockées et autres triggers pour solidifier la BDD.
    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 !

  11. #11
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Citation Envoyé par CinePhil Voir le message
    Si j'ai bien compris, il va donc y avoir création de X lignes dans la table des gifts ?


    Là nous avons différents mouvements que vous appelez des types d'actions dans votre schéma et ces différents mouvements feront l'objet, pour chaque gift concerné, d'autant de lignes HISTORY.
    Comme toutes les lignes HISTORY sont horodatées, il est possible de retrouver le cycle de vie d'un gift.

    Par contre, le schéma est piégeux en l'état car un gift G1 peut être envoyé à un magasin M1 et c'est en fait le magasin M2 qui va vendre le gift G1 alors qu'il n'y a pas de mouvements de ce G1 entre M1 et M2.

    L'application peut contrôler pas mal de choses et éviter les erreurs mais la base de données ne sera pas d'une solidité à toute épreuve. Je ne sais pas a priori si des éléments de modélisation supplémentaires permettraient de parer à certains risques mais en tout cas il conviendrait de réaliser des procédures stockées et autres triggers pour solidifier la BDD.

    Dans ce cas, il y a eu un malentendu quelque part puisque nous sommes d'accord à propos de ce problème. Et c'est bien à ce problème que je cherche une solution.

    Sinon, concernant les règles de gestions, voici ce j'ai :

    - Un magasin peut envoyer plusieurs gifts et un gift peut être envoyé par plusieurs magasins
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     MCD : store-0,n----envoyer----0,n-gift
    - Un magasin peut recevoir plusieurs gifts et un gift peut être reçu par plusieurs magasins
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     MCD : store-0,n----recevoir----0,n-gift
    - Un magasin peut vendre plusieurs gifts et un gift est vendu par un magasin
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     MCD : store-0,n----vendre----0,1-gift
    N.B.: Pas de notion de client ici car on parle de vente à la caisse. La notion de client n'est présente que lors de grosses commandes qui sont passées directement à la centrale (d'où la table commande de mes schémas)

    - Un magasin peut détruire plusieurs gifts et un gift peut être détruit par un magasin
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     MCD : store-0,n----détruire----0,1-gift
    N.B.: Il n'y a que la centrale qui est autorisée à détruire des gifts. Faut-il créer une entité centrale pour rendre compte de cela ou bien faut-il le faire via un autre moyen ? (contrainte?)

    - Un magasin peut commander plusieurs gifts et un gift est commandé par un magasin
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     MCD : store-0,n----commander----1,1-gift
    N.B.: Aussi une action uniquement effectuée par la centrale...

    Déjà rien que là, j'ai 5 règles concernant les 2 mêmes objets. Je fais 5 relations entre 2 entités ? Je suis novice mais cela me semble tout de même étrange...


    A côté de ces règles "au format classique" tel que décrit dans votre billet, j'ai aussi :

    - un gift peut être utilisé (dans un magasin)
    - un gift peut être perdu (signaler dans un magasin)
    - un gift peut être retrouvé (signaler dans un magasin)

    Ce sont des états dont il faut également garder une trace.

    Est-ce que le fait de ne pas pouvoir formuler "l'aller-retour" déjà en français serait le signe que je serais en présence d'un attribut plutôt que d'une relation ?

    Comment auriez-vous procédé ?
    Kropernic

  12. #12
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    On va mettre de côté cette partie :
    La notion de client n'est présente que lors de grosses commandes qui sont passées directement à la centrale (d'où la table commande de mes schémas)

    - Un magasin peut détruire plusieurs gifts et un gift peut être détruit par un magasin
    Code :
    Sélectionner tout - Visualiser dans une fenêtre à part

    MCD : store-0,n----détruire----0,1-gift

    N.B.: Il n'y a que la centrale qui est autorisée à détruire des gifts. Faut-il créer une entité centrale pour rendre compte de cela ou bien faut-il le faire via un autre moyen ? (contrainte?)

    - Un magasin peut commander plusieurs gifts et un gift est commandé par un magasin
    Code :
    Sélectionner tout - Visualiser dans une fenêtre à part

    MCD : store-0,n----commander----1,1-gift

    N.B.: Aussi une action uniquement effectuée par la centrale...
    Tout le reste, il me semble, concerne des actions réalisées par store à propos de gift.

    Nous pourrions alors peut-être résumer tout ça à :
    1) Un store peut effectuer plusieurs actions et une action est effectuée par un store.
    2) Une action est d'un seul type et un type d'action peut typer plusieurs actions.
    3) Une action concerne un seul gift et un gift peut être concerné par plusieurs actions

    Ce n'est pas une association ternaire mais une entité type "action" qui est en association avec les trois entités types "store", "gift" et (pour rester en Glish ) "action_type".

    MCD :
    store -0,n----effectuer----1,1- action -1,1----typer----0,n- action_type
    gift -0,n----concerner----1,1-------|

    Ça ressemble furieusement à votre modèle non ?
    Il suffit de remplacer mon "action" par votre "history".

    Mais ceci est conforme pour l'aspect statique des données.
    Il y a aussi des contraintes fonctionnelles à envisager. Par exemple :
    Un store ne peut effectuer l'action de type "vendre" que sur les gift pour lesquels il a effectué l'action "réception" et qu'il n'a pas encore vendus.

    Ce genre de contrainte est soluble en BDD via l'utilisation d'un trigger à l'insertion dans la table "action".

    L'autre solution est de supprimer la partie "action-type"... et de détailler chaque type d'action dans les associations adéquates. Ça multiplie les associations et donc potentiellement les tables associatives, mais ça peut être plus simple à gérer.

    Tu peux attendre peut-être l'avis de fsmrel sur le sujet, qui de plus pourra te guider éventuellement dans l'utilisation de PowerAMC.

    Bon courage !
    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 !

  13. #13
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Ah mais j'étais dans le bon alors ! Ca fait plaisir ça

    Sinon, niveau nommage, c'est vrai que action et type_action, c'est plus clair. Je vais adopter ça (j'ai été biaisé car la DB existante utilise le terme history^^).

    Et je vais donc également attendre l'avis de fmsrel si se sent l'envie de le donner.

    Encore un grand merci !!
    Kropernic

  14. #14
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 966
    Points : 30 778
    Points
    30 778
    Billets dans le blog
    16
    Par défaut
    Bonsoir Kropernic,


    Citation Envoyé par Kropernic Voir le message
    Et je vais donc également attendre l'avis de fmsrel si se sent l'envie de le donner.
    Pas de problème pour donner un avis si je le peux... Mais comme je n’ai pas suivi la discussion, pourriez-vous exposer précisément ce qui vous pose un problème ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  15. #15
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Je vais citer Cinéphil pour le problème :
    Par contre, le schéma est piégeux en l'état car un gift G1 peut être envoyé à un magasin M1 et c'est en fait le magasin M2 qui va vendre le gift G1 alors qu'il n'y a pas de mouvements de ce G1 entre M1 et M2.
    Donc la question est : Comment faire pour connaître la destination/origine d'une action de type envoi/réception ? (par rapport au premier schéma, l'entité history représente les actions et l'entité action représente le type d'action... Je dois les renommer)


    J'avais pensé ajouter une colonne dans l'entité action qui reprendrait cette info mais vu qu'elle est dépend du type d'action, ce n'est pas le bon endroit. Et la mettre dans l'entité type d'action ne me semble pas non plus. C'est pour cela que j'étais arrivé à la entité/association du 2e schéma. Mais plus par "instinct" que par une réelle réflexion.
    Kropernic

  16. #16
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Donc la question est : Comment faire pour connaître la destination/origine d'une action de type envoi/réception ?
    Est-ce qu'un store simple peut envoyer des gifts à un autre store simple directement ?
    J'ai l'impression que les magasins doivent commander à la centrale mais peut-être ai-je mal compris ?

    Si l'action "envoi" se fait toujours de la centrale vers un store, on peut considérer que le store figurant dans l'association envoyer est le store destinataire. Ceci bien sûr si on conserve les associations détaillées (gift -0,n----envoyer----0,n- store) et non pas la généralisation (store -0,n----effectuer----1,1- action).

    Plus j'y pense et plus je me dis que les associations détaillées seront plus faciles à utiliser que la généralisation. Au niveau représentation graphique, tu pourras ainsi mettre en oeuvre des contraintes entre les associations sur le MCD.
    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 !

  17. #17
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Vous feriez donc des associations détailles pour envoyer et recevoir.

    Mais si on fait ça pour ces deux actions, il faut alors faire pareil pour le reste non ?

    Donc pour détruire (la centrale peut détruire plusieurs gifts et un gift peut être détruit par la centrale) et vendre (un magasin peut vendre plusieurs gifts et un gift peut être vendu par plusieurs magasin).
    N.B.: La centrale étant la seule à pouvoir effectuer certaines actions, faut-il la considérer comme une entité à part entière ou bien puis-je simplement exprimer cela par une ou plusieurs contraintes ?

    Reste encore voler et perdre que je n'arrive pas à formuler de la sorte.

    Néanmoins, cela ne fait pas beaucoup (trop?) d'associations entre les entités store et gift ?
    Kropernic

  18. #18
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Citation Envoyé par Kropernic Voir le message
    Vous feriez donc des associations détailles pour envoyer et recevoir.

    Mais si on fait ça pour ces deux actions, il faut alors faire pareil pour le reste non ?
    Oui.

    Donc pour détruire (la centrale peut détruire plusieurs gifts et un gift peut être détruit par la centrale) et vendre (un magasin peut vendre plusieurs gifts et un gift peut être vendu par plusieurs magasin).
    N.B.: La centrale étant la seule à pouvoir effectuer certaines actions, faut-il la considérer comme une entité à part entière ou bien puis-je simplement exprimer cela par une ou plusieurs contraintes ?
    S'il n'y a qu'une centrale, je représenterais des contraintes sur les associations réservées à la centrale pour indiquer que le store participant à cette association est celui nommé "centrale" (nom de la propriété et sa valeur à déterminer selon ta préférence.

    Reste encore voler et perdre que je n'arrive pas à formuler de la sorte.
    On peut peut-être dire qu'un store peut déclarer une perte ou un vol d'un gift et qu'un gift peut être déclaré perdu ou volé par un store.
    Ça ne fait qu'une association porteuse d'une propriété declaration_type pouvant prendre l'une des valeurs 'P' pour perte et 'V' pour vol par exemple.

    Néanmoins, cela ne fait pas beaucoup (trop?) d'associations entre les entités store et gift ?
    Conceptuellement, ça ne pose pas de problème.
    Au niveau du dessin du schéma par contre ça peut être un peu fouilli. Je ne sais pas quelle liberté offre PowerAMC dans le positionnement des liaisons des associations.

    Bon courage !
    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 !

  19. #19
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    J'arrive alors à ceci (voir pièce jointe).

    J'en arrive à me poser des questions quant à l'utiliser de l'entité commande...

    Quelques précisions :
    Les ventes en grande quantité sont faites uniquement par la centrale et dans ce cas, un dossier de commande est ouvert le client concerné.
    Les ventes à l'unité sont faites directement à la caisse dans les magasins et dans ce cas, aucune info sur le client n'est disponible et donc évidemment, il n'y a pas de dossier de commande.

    Seulement avec ce mcd, quand je regarde le mld généré, je retrouve l'identifiant de commande dans gift. Alors qu'un gift peut ne pas avoir fait l'objet d'une commande.

    Bref, je m'interroge à propos de quelque chose qui me semblait tombé sous le sens...
    Images attachées Images attachées  
    Kropernic

  20. #20
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    Juillet 2006
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : Juillet 2006
    Messages : 3 932
    Points : 4 239
    Points
    4 239
    Par défaut
    Je crois que je vais rester avec la généralisation et ajouter un attribut store dans l'entité action qui, dans certains cas sera null, dans d'autres indiquera l'origine et dans les cas restants la destination.

    Je suis conscient que ce n'est pas optimal (et ça m'énerve d'ailleurs) mais je ne vois pas comment faire cela de manière simple et élégante.

    Déjà que mon collègue me fait presque une scène parce que je refuse de lui ajouter un attribut status dans l'entité gift car cela ajoute de la redondance alors si je lui file un schéma avec toutes ces relations, je vous raconte pas le bordel .

    Maintenant si vous avez une jolie idée, je suis preneur.

    Et je reste bien entendu ouvert aux critiques.

    Encore un grand merci au temps que vous m'avez consacré. (j'espère un jour être en mesure d'en faire autant)
    Kropernic

Discussions similaires

  1. Problème install de giFT-0.11.6
    Par MysticKhal_0 dans le forum Applications et environnements graphiques
    Réponses: 5
    Dernier message: 28/07/2004, 23h07

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