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 :

Modéliser ma base


Sujet :

Schéma

  1. #1
    Nouveau Candidat au Club
    Modéliser ma base
    Bonjour

    Nouveau dans le dev j'ai un soucis pour modéliser ma base de données
    Prenons un exemple
    J'ai des assiettes qui ont des caractéristiques communes et des caractéristiques spécifiques
    J'ai plusieurs gammes
    Gamme 1
    Gamme 2
    Gamme 3
    ...
    Chaque gamme a une nom et une description commune a toutes les assiettes de la gamme
    Dans chaque gamme les assiettes ont des tailles en cm différentes et des couleurs différentes
    J'ai besoin de stocker le poids qui est différent selon la taille et le prix qui est différent selon la taille ET la couleur
    Ex
    Gamme 1 assiette 10 cm bleu poids 200g prix 2euros
    Gamme 1 assiette 10 cm rouge poids 200g prix 3 euros
    Gamme 1 assiette 20 cm vert bleu poids 300g prix 5 euros
    Gamme 1 assiette 20 cm bleu poids 300g prix 7 euros

    Etc
    Je n'arrive pas a modéliser une base comment faire les tables et ou stocker le prix le poids...
    Merci d'avance

  2. #2
    Expert éminent sénior
    Bonjour Bettybroute,


    De même qu’on ne se lance pas à l’assaut du Mont Blanc en baskets, il faut être équipé pour construire une base de de données.

    (1) Apprenez à modéliser les données.

    Pour cela il existe fondamentalement l’ouvrage remarquable de D. Nanci et B Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), c’est l’ouvrage de référence. Les chapitres à étudier sont le chapitre 7 (« Modélisation conceptuelle des données ») et un peu plus tard le chapitre 13 (« Modélisation logique des données »)


    (2) Formalisez les règles de gestion, c’est-à-dire les relations quantifiées entre les types d’entités :

    (rg01) Une gamme comporte de 1 à N types assiettes.
    (rg02) Un type d’assiette appartient à au moins et au plus une gamme.
    Etc.



    (3) Utilisez un bon outil de modélisation, à savoir Looping, gracieusement proposé par le professeur Patrick Bergougnoux (merci Paprick !)


    Bon courage !

     
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  3. #3
    Expert éminent sénior
    Bonjour

    Citation Envoyé par Bettybroute Voir le message
    Gamme 1 assiette 10 cm bleu poids 200g prix 2euros
    Gamme 1 assiette 10 cm rouge poids 200g prix 3 euros
    Gamme 1 assiette 20 cm vert bleu poids 300g prix 5 euros
    Gamme 1 assiette 20 cm bleu poids 300g prix 7 euros
    La question est d'autant plus bizarre que tu la donnes, cette satanée table .
    Qu'est-ce qui te gêne dans ton exemple ?
    Cette réponse vous apporte quelque chose ? Cliquez sur en bas à droite du message.

  4. #4
    Expert éminent sénior
    Citation Envoyé par Bettybroute Voir le message
    J'ai besoin de stocker le poids qui est différent selon la taille

    Si le poids est directement fonction de la taille, cela doit faire l’objet d’une règle de gestion formalisée. Par exemple (à vous de rectifier) :

    - A une taille correspond un poids et un seul.
    - A un poids correspond une taille et une seule (ou bien à un poids correspondent de 1 à N tailles).



    Citation Envoyé par Bettybroute Voir le message
    le prix qui est différent selon la taille ET la couleur
    Même principe, formalisez. Mettons tout cela à plat, puis rectifiez quand c’est nécessaire. Par exemple :

    - A une taille correspondent de 1 à N prix ;
    - A un prix correspondent de 1 à N tailles ;
    - A une couleur correspondent de 1 à N prix ;
    - A un prix correspondent de 1 à N couleurs ;
    - A une paire (taille, couleur), correspond un et un seul prix.


    Citation Envoyé par Flodelarab Voir le message
    tu la donnes, cette satanée table

    Laquelle ? C'est un peu prématuré, la modélisation montrera qu'il y en aura plus d’une…


    Bref, on voit que le plus urgent est de disposer des règles de gestion de données car elles conditionnent le reste. Ne mettons pas la charrue avant les bœufs.




     
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  5. #5
    Membre confirmé
    Bonsoir,

    Le modèle conceptuel de données (MCD) représente effectivement la première étape incontournable à tout développement d'une base de données.
    Pour vous familiariser à ce type de modélisation, vous trouverez bon nombre d'exemples intéressants sur ce forum.

    Bon courage !
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  6. #6
    Nouveau Candidat au Club
    Merci à vous
    Je vais regarder tout ça

  7. #7
    Nouveau Candidat au Club
    Bon alors après avoir lu les chapitres sur MERISE
    J'en ai sorti ca :
    Est ce que c'est correcte ?
    Ca me parait bizarre la doublette de l'association sur les entités Product et Size
    Et si c'est correcte (sur un malentendu on sait jamais) comment ca se traduit en BDD au niveau des tables ces relations ?

  8. #8
    Nouveau Candidat au Club
    Ou n'ayant que peu des gammes et en moyenne 3 ou 4 produits par gammes n'est ce pas plus simple de faire ceci (même si c'est redondant)

    Cependant j'aimerais bien connaitre la bonne modélisation avec le MCD précédent

  9. #9
    Expert éminent sénior
    Le produit n'a pas besoin du poids pour avoir une taille. Donc "weight" dans "Measured" me paraît douteux. Pareil pour "reference" et "price".

    Si tu corriges, il n'y a pas de différence entre tes deux schémas, à part que la taille et la couleur sont détaillées dans des tables spécifiques. Et l'intégrité référentielle va empêcher les valeurs de taille impossibles et les couleurs impossibles.

    Si on fait une base de données des délégations pour les jeux olympiques, il est facile de mettre le nom du pays en clé primaire de la table pour empêcher 2 délégations pour un même pays. Mais il faut ajouter une table des pays valides pour empêcher l'enregistrement de la délégation du Developpezpoincomistan. Cette vérification est l'intégrité référentielle. Ceci empêchera tes assiettes de faire 12 mètres de diamètre.
    Cette réponse vous apporte quelque chose ? Cliquez sur en bas à droite du message.

  10. #10
    Expert éminent sénior
    Bonsoir,


    Bettybroute, félicitations pour la lecture des chapitres sur Merise et le passage à Looping !

    Un nouveau concept apparaît dans vos MCD, celui de produit : dont acte. Si l’assiette est un produit, alors selon votre 1er post, ce produit peut avoir plusieurs tailles, plusieurs poids, plusieurs prix, plusieurs couleurs et votre 1er MCD n’est pas en contradiction avec cela, tandis que votre 2e MCD l’est, puisque ce produit n’a alors qu’une seule taille, un seul poids, un seul prix, une seule couleur (et une seule référence).

    Je n’insisterai pas sur votre 2e MCD, qu’on ne peut pas cautionner, puisque comme vous le précisez, la base de données générée comportera des redondances, et la redondance est une ennemie déterminée des base de données et trouve toujours la faille à un moment ou un autre.

    Il faut donc que nous en revenions aux fondamentaux : tant que vous n’aurez pas fourni des règles de gestion précises, dépourvues d’ambiguïté, on ne pourra pas valider vos MCD.

    Toutefois, selon votre 1er MCD, le poids d’un produit est déterminé par sa taille : soit.

    En revanche, ce MCD enfreint la règle selon laquelle le prix ne dépend de la taille et de la couleur. En effet, le fait d’avoir une patte entre l’entité-type PRODUIT et l’association HAD fait que l’identifiant de l’association n’est plus défini par la seule paire {TAILLE, COULEUR}, mais par le triplet {PRODUIT, TAILLE, COULEUR} : le prix dépend alors aussi du produit.

    En l’occurrence, je me suis basé sur que vous aviez écrit dans votre 1er post :

    « J'ai besoin de stocker le poids qui est différent selon la taille et le prix qui est différent selon la taille ET la couleur »


    Ce que je décompose ainsi pour y voir un peu plus clair car la phrase est ambiguë, tout en espérant que mon interprétation coïncide avec la vôtre :

    J'ai besoin de stocker le poids qui est différent selon la taille,

    et j’ai besoin de stocker le prix qui est différent selon la taille ET la couleur.

    Dans votre 1er MCD, il faut donc supprimer la patte délinquante...
    Par contre, il faut établir une association entre PRODUIT et COULEUR. Ainsi, grâce aux associations PRODUIT_TAILLE et PRODUIT_COULEUR (ci-dessous) on obtient les paires (taille couleur) pour un produit donné, mais ces paires doivent exister dans le référentiel des prix (association TAILLE_COULEUR), aussi doit-on mettre en oeuvre une contrainte d’inclusion (I) pour modéliser le fait que les paires PRODUIT_TAILLE, PRODUIT_COULEUR doivent être incluses dans TAILLE_COULEUR. Problème : cette contrainte n’est pas traduite au stade SQL... Si le MCD que je propose est conforme aux règles de gestion, pour combler cette lacune SQL, on passera à une solution alternative permettant quand même la prise en compte automatique de cette contrainte.


     
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  11. #11
    Expert éminent sénior
    Bonjour,

    Un point d'attention
    Si l'assiette bleue de 20 cm est vendue 10€ et l'assiette jaune de même diamètre vendue 12€, le modèle qui précède convient, mais s'il faut aussi tenir compte de panels variés de couleurs (assiette bleue et jaune ; bleue, jaune et rouge, etc.) alors l'affaire se complique sauf si "multicolore" fait l'objet d'une tarification unique et peut alors être considéré comme une couleur.
    À préciser

  12. #12
    Expert éminent sénior
    Bonjour à tous,


    Citation Envoyé par escartefigue Voir le message
    À préciser
    En attendant que Bettybroute donne son avis, je reviens sur ce point en particulier :

    Citation Envoyé par fsmrel Voir le message
    Si le MCD que je propose est conforme aux règles de gestion, pour combler cette lacune SQL, on passera à une solution alternative permettant quand même la prise en compte automatique de cette contrainte.


    Et supposons donc que le MCD en question soit conforme aux règles de gestion. La solution alternative est la suivante, qui permet de prendre en compte la contrainte d’inclusion directement au stade CREATE TABLE, donc de ne pas avoir à injecter de code la garantissant (triggers procédures, etc.) :




    Il ne s’agit pas (quoique...) d’un MCD à présenter à l’utilisateur (maîtrise d’oeuvre), mais en tout cas d’un MCD orienté génération du code SQL. Il s’agit d’établir une association entre une classe d’entités (par exemple PRIX) et l’association TAILLE_COULEUR du MCD précédent. Comme Merise refuse d’associer une association à quoi que ce soit, on commence par transformer TAILLE_COULEUR en classe d’entités, ce que Looping sait faire de lui -même (merci Paprick !). Au passage, renommons TAILLE_COULEUR par exemple en PRIX. Mais maintenant, c’est l’association PRODUIT_TAILLE du MCD précédent qu’on veut associer à PRIX : une fois de plus Merise ne le permet pas, mais même pas grave, on demande à Looping de transformer PRODUIT_TAILLE en classe d’entités et on associe celle-ci à PRIX (association PRODUIT_PRIX). Suite à cela, l’association PRODUIT_COULEUR du MCD précédent devient sans emploi car redondante (donc source d’erreur), on la vire. En effet, la couleur est connue par l’association PRODUIT_PRIX comme le montre le code SQL généré par Looping :

    CREATE TABLE GAMME
    (
       gammeId INT,
       gammeNom VARCHAR(50) NOT NULL,
       CONSTRAINT GAMME_PK PRIMARY KEY(gammeId)
    );
    
    CREATE TABLE PRODUIT
    (
       produitId INT,
       produitNom VARCHAR(50) NOT NULL,
       gammeId INT NOT NULL,
       CONSTRAINT PRODUIT_PK PRIMARY KEY(produitId),
       CONSTRAINT PRODUIT_GAMME_FK FOREIGN KEY(gammeId) REFERENCES GAMME(gammeId)
    );
    
    CREATE TABLE COULEUR
    (
       couleurId INT,
       couleurNom VARCHAR(50) NOT NULL UNIQUE,
       CONSTRAINT COULEUR_PK PRIMARY KEY(couleurId)
    );
    
    CREATE TABLE TAILLE
    (
       tailleId INT,
       taille DECIMAL(4,2) NOT NULL UNIQUE,
       CONSTRAINT TAILLE_PK PRIMARY KEY(tailleId)
    );
    
    CREATE TABLE PRODUIT_TAILLE
    (
       tailleId INT,
       produitId INT,
       poids DECIMAL(4,2) NOT NULL,
       CONSTRAINT PRODUIT_TAILLE_PK PRIMARY KEY(tailleId, produitId),
       CONSTRAINT PRODUIT_TAILLE_TAILLE_FK FOREIGN KEY(tailleId) REFERENCES TAILLE(tailleId),
       CONSTRAINT PRODUIT_TAILLE_PRODUIT_FK FOREIGN KEY(produitId) REFERENCES PRODUIT(produitId)
    );
    
    CREATE TABLE PRIX
    (
       tailleId INT,
       couleurId INT,
       prix INT NOT NULL,
       reference VARCHAR(48) NOT NULL,
       CONSTRAINT PRIX_PK PRIMARY KEY(tailleId, couleurId),
       CONSTRAINT PRIX_TAILLE_FK FOREIGN KEY(tailleId) REFERENCES TAILLE(tailleId),
       CONSTRAINT PRIX_COULEUR_FK FOREIGN KEY(couleurId) REFERENCES COULEUR(couleurId)
    );
    
    CREATE TABLE PRODUIT_PRIX
    (
       tailleId INT,
       couleurId INT,
       tailleId_1 INT,
       produitId INT,
       CONSTRAINT PRODUIT_PRIX_PK PRIMARY KEY(tailleId, couleurId, tailleId_1, produitId),
       CONSTRAINT PRODUIT_PRIX_PRIX_FK FOREIGN KEY(tailleId, couleurId) REFERENCES PRIX(tailleId, couleurId),
       CONSTRAINT PRODUIT_PRIX_PRODUIT_TAILLE_1_FK FOREIGN KEY(tailleId_1, produitId) REFERENCES PRODUIT_TAILLE(tailleId, produitId)
    ); 


    Mais on constate que la structure de la table PRODUIT_PRIX comporte une redondance des colonnes tailleId et tailleId_1, et au lieu d’établir une contrainte pour garantir que les valeurs prises par ces colonnes soit strictement les mêmes (trigger en perspective...), le plus simple est d’en virer une, d’où les ALTER TABLE, permettant de procéder au réglage du tir (noter la structure correcte cette fois-ci de la clé primaire) :

    ALTER TABLE PRODUIT_PRIX
       DROP  CONSTRAINT PRODUIT_PRIX_PRODUIT_TAILLE_1_FK
           , CONSTRAINT PRODUIT_PRIX_PK 
           , COLUMN  tailleId_1 ;
    
    ALTER TABLE PRODUIT_PRIX
       ADD  CONSTRAINT PRODUIT_PRIX_PK 
                    PRIMARY KEY(tailleId, couleurId, produitId)
              , CONSTRAINT PRODUIT_PRIX_PRODUIT_TAILLE_FK
                    FOREIGN KEY(tailleId, produitId)
                        REFERENCES PRODUIT_TAILLE(tailleId, produitId) ;
    
    En passant, cette façon de procéder vaut dans le cas général, c’est-à-dire quand des classes d’entités sont impliquées dans une boucle (TAILLE, PRODUIT_TAILLE, PRIX dans le cas présent), c’est-à-dire virer une des deux colonnes redondantes.

     
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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