Discussion :

[laminekane]

Bonjour tout le monde,
j'ai d'abord posté sur la section MySQL et j'ai orienté vers MERISE.
c'est avec humilité que je me tourne vers vous à la recherche d'un conseil pour la création d'une base de données avec MySQL.
Déjà sachez que je suis un statisticien qui s'est formé tout seul en MySQL, à travers le net notamment, dans l'espoir d'orienter ma carrière professionnelle dans le domaine des bases de
données et de la programmation web avec PHP.
Afin de consolider les connaissances acquises, et surtout me mettre en confiance, j'ai imaginé un petit projet qui consiste à concevoir une base de données avec MySQL, couplée à une interface
web développée avec PHP.
Concernant la base de données, je dispose actuellement d'un fichier excel contenant plusieurs onglets, classés par thème. Dans chaque onglet il y'a une ou plusieurs tables, avec des données mensuelles allant de 1980 à 2015 par exemple. Et c'est de là que vient la difficulté. Car chaque table contient plus de 300 champs, qui sont en fait une répétition des 12 mois de l'année (janvier, février, ... , décembre). D'où ma question: comment créer une telle table avec MySQL? Mon idée est de créer une table pour chaque année. Ainsi chaque table aura 12 champs ( janvier, ..., décembre). Et il y'aura autant de tables que d'années. l'inconvénient de cette méthode est que l'on va se retrouver rapidement avec plus d'une centaine de tables!
Il y'aura sans nul doute un problème d'optimisation.
Quant à l'interface web; elle permettra à un utilisateur de choisir une table et de visualiser ses données sur une période choisie, par exemple entre 2000 et 2010.
Je sollicite votre aide pour trouver la bonne méthode de conception de cette base de données.
merci d'avance

[Diablo_22]

Bonjour,

peux tu poster ton fichier excel sur le forum

[laminekane]

je vous remercie de m'accorder du temps. vous trouverez la base en pièce jointe.
ce sont des données publiées chaque mois.

[fsmrel]

Bonsoir laminekane,

je me tourne vers vous à la recherche d'un conseil pour la création d'une base de données avec MySQL.

Faisons référence au titre de votre message : « Conseil pour la conception base de données ».

Quand on traite de la conception, on ne parle pas encore de SGBD, MySQL en l’occurrence (a fortiori de PHP). C’est comme lorsqu’on dresse les plans d’une maison, on ne parle pas encore du maçon qui la réalisera.

chaque table contient plus de 300 champs, qui sont en fait une répétition des 12 mois de l'année (janvier, février, ... , décembre).

On va ramener ça à quelques tables de l'ordre de 4 ou 5 attributs chacune (en passant, en conception, de préférence au terme champ, on utilise celui d’attribut ou de propriété, voire de caractéristique).

Dans le contexte de la modélisation (modèle conceptuel des données ou diagramme de classes), il est d’usage de ne pas représenter de façon horizontale les données répétitives, mais de façon verticale (nombre de lignes quelconque), en leur associant un nom d’attribut. Par exemple, la partie « Cours matières premières » peut être modélisée ainsi (j’utilise ici DB-MAIN, gratuit) :





On est en présence de trois entités-types (types d’entités) : MATIERE, UNITE, MATIERE_COURS.

(1) MATIERE a pour attributs matiereId et matiereNom :

— matiereId est ce qu’on appelle un identifiant, permettant de distinguer chaque instance (occurrence) de MATIERE, c'est-à-dire que deux instances ne peuvent pas avoir la même valeur pour cet identifiant (interdiction des doublons) ;

— matiereNom permet d’affecter un nom : « Huile d'arachide », « Huile de palme », etc.

Exemple tabulaire :

matiereId    matiereNom 
        1    Huile d'arachide
        2    Huile de palme
      ...    ...
        7    Pétrole
      ...    ...

(2) UNITE a pour attributs uniteId (identifiant) et uniteLibelle :

uniteId    uniteLibelle
      1    $/t
      2    BRENT $/bl
    ...    ...

(3) MATIERE_COURS a pour identifiant le triplet {R.MATIERE, annee, mois}, c'est-à-dire le triplet {matiereId, annee, mois}, où matiereId est hérité de MATIERE via l’association VALOIR :

matiereId    annee    mois    valeur
        1    2006     01         930
        1    2006     02         921
      ...    ...      ...        ...
        1    2006     12        1173
        1    2007     01        1180
      ...    ...      ...        ...
        2    2006     01         424
      ...    ...      ...        ...
        7    2015     04        60.8
      ...    ...      ...        ...

 

Vous noterez en passant que, contrairement à ce qui se passe dans le cas d’Excel, au lieu d’avoir à ajouter des attributs au fil du temps, on se bornera à ajouter des instances : la structure n’est pas touchée, elle reste la suivante :

{matiereId, annee, mois, valeur}.

Dans le diagramme, les ovales permettent de représenter les associations entre entités-types :

— Une matière est exprimée selon une unité (association EXPRIMER) et une même unité peut être utilisée pour plusieurs matières.

— Une matière prend plusieurs valeurs dans le temps (association VALOIR) et une valeur de MATIERE_COURS fait référence à une seule matière.

On peut aussi modéliser un cran en dessous du modèle conceptuel (j’utilise ici MySQL Workbench), en utilisant un diagramme « relationnel ». J’utilise ici MySQL Workbench (gratuit) :



Diagramme dans lequel les associations entre objets sont ici matérialisées par la recopie dans l’entité-type « référençante » du nom de l’identifiant l’entité-type (table à ce stade) « référencée » :

L’attribut uniteId de l’entité-type UNITE est recopié dans l’entité-type MATIERE et l’attribut matiereId de l’entité-type MATIERE es recopié dans l’entité-type MATIERE_COURS.



Même principe pour les monnaies, etc., par exemple :






MySQL Workbench permet de produire le script de création des tables. Exemple des matières premières :

CREATE TABLE UNITE
(
        uniteId          INT            NOT NULL
      , uniteLibelle     VARCHAR(32)    NOT NULL 
    , CONSTRAINT UNITE_PK PRIMARY KEY (uniteId)  
) ;

CREATE TABLE MATIERE
(
        matiereId          INT            NOT NULL
      , matiereNom         VARCHAR(32)    NOT NULL
      , uniteId            INT            NOT NULL
    , CONSTRAINT MATIERE_PK PRIMARY KEY (matiereId) 
    , CONSTRAINT MATIERE_UNITE_FK FOREIGN KEY (uniteId) REFERENCES UNITE (uniteId) 
) ;

CREATE TABLE MATIERE_COURS
(
        matiereId          INT            NOT NULL
      , annee              INT            NOT NULL
      , mois               INT            NOT NULL
      , valeur             INT            NOT NULL
    , CONSTRAINT MATIERE_COURS_PK PRIMARY KEY (matiereId, annee, mois) 
    , CONSTRAINT MATIERE_COURS_FK FOREIGN KEY (matiereId) REFERENCES MATIERE (matiereId) 
) ;

Ceci fait, on peut valoriser les tables :

INSERT INTO UNITE (uniteId, uniteLibelle) VALUES 
    (1, '$/t'), (2, 'BRENT $/bl') ;

INSERT INTO MATIERE (matiereId, matiereNom, uniteId) VALUES 
    (1, 'Huile d''arachide', 1) 
  , (2, 'Huile de palme', 1)
  , (3, 'Riz', 1)
  , (4, 'Maïs', 1)
  , (5, 'Coton', 1)
  , (6, 'Phosphate', 1)
  , (7, 'Pétrole', 2)  
;

INSERT INTO MATIERE_COURS (matiereId, annee, mois, valeur) VALUES
    (1, 2006, 1, 930), (1, 2006, 2, 921), (1, 2006, 3, 902), (1, 2006, 4, 899), (1, 2006, 5, 892), (1, 2006, 6, 898)
  , (1, 2006, 7, 928), (1, 2006, 8, 944), (1, 2006, 9, 959), (1, 2006, 10, 1068), (1, 2006, 11, 1120), (1, 2006, 12, 1173) 
  
  , (1, 2007, 1, 1180), (1, 2007, 2, 1173), (1, 2007, 3, 1157), (1, 2007, 4, 1202), (1, 2007, 5, 1159), (1, 2007, 6, 1209)
  , (1, 2007, 7, 1342), (1, 2007, 8, 1414), (1, 2007, 9, 1445), (1, 2007, 10, 1486), (1, 2007, 11, 1691), (1, 2007, 12, 1777) 
  
  , (2, 2006, 1, 424), (2, 2006, 2, 445), (2, 2006, 3, 440), (2, 2006, 4, 439), (2, 2006, 5, 440), (2, 2006, 6, 437)
  , (2, 2006, 7, 471), (2, 2006, 8, 510), (2, 2006, 9, 498), (2, 2006, 10, 506.92), (2, 2006, 11, 547.03), (2, 2006, 12, 582.94) 
  
  , (2, 2007, 1, 599.21), (2, 2007, 2, 605), (2, 2007, 3, 622), (2, 2007, 4, 710), (2, 2007, 5, 772), (2, 2007, 6, 805)
  , (2, 2007, 7, 811), (2, 2007, 8, 821), (2, 2007, 9, 835), (2, 2007, 10, 881), (2, 2007, 11, 952), (2, 2007, 12, 950) 
  ;

 

Visualisation des tables :

Table UNITE :

uniteId    uniteLibelle
      1    $/t
      2    BRENT $/bl

Table MATIERE :

matiereId    matiereNom         uniteId
        1    Huile d'arachide         1
        2    Huile de palme           1
        3    Riz                      1
        4    Maïs                     1
        5    Coton                    1
        6    Phosphate                1
        7    Pétrole                  2

Table MATIERE_COURS

matiereId    annee    mois   valeur
        1     2006       1      930
        1     2006       2      921
        1     2006       3      902
        1     2006       4      899
        1     2006       5      892
        1     2006       6      898
        1     2006       7      928
        1     2006       8      944
        1     2006       9      959
        1     2006      10     1068
        1     2006      11     1120
        1     2006      12     1173
        1     2007;      1     1180
        1     2007       2     1173
        1     2007       3     1157
        1     2007       4     1202
        1     2007       5     1159
        1     2007       6     1209
        1     2007       7     1342
        1     2007       8     1414
        1     2007       9     1445
        1     2007      10     1486
        1     2007      11     1691
        1     2007      12     1777
        2     2006       1      424
        2     2006       2      445
        2     2006       3      440
        2     2006       4      439
        2     2006       5      440
        2     2006       6      437
        2     2006       7      471
        2     2006       8      510
        2     2006       9      498
        2     2006      10      507
        2     2006      11      547
        2     2006      12      583
        2     2007       1      599
        2     2007       2      605
        2     2007       3      622
        2     2007       4      710
        2     2007       5      772
        2     2007       6      805
        2     2007       7      811
        2     2007       8      821
        2     2007       9      835
        2     2007      10      881
        2     2007      11      952
        2     2007      12      950

Etc.

Il serait souhaitable que vos étudiiez la modélisation avant de vous lancer dans l’échafaudage des tables. Voyez par exemple l’ouvrage de Michel Diviné : Parlez-vous Merise ?, gratuit et téléchargeable (Merci Michel !)

[laminekane]

je te remercie infiniment.
Effectivement, il semble que la modélisation constitue la majeur partie du travail. Mais j'ai très bien compris votre raisonnement, et il me donne envie d'étudier l'ouvrage de Michel.
j'ai déjà téléchargé le livre. Merci Michel!!!
A présent je vais prendre le temps de maîtriser la modélisation. Merci de m'avoir proposé cette solution.
bonne journée

[laminekane]

Bonjour,
je Up la discussion, car après avoir trouvé un parfait MCD, concernant le sujet de la semaine dernière: http://www.developpez.net/forums/d15...s-economiques/
J'ai essayé d'adapter cette méthode à ce modèle ci, mais, sans succès.
En effet, dans le modèle actuel, on se retrouve avec 4 tables (matieres_cours, monnaie_cours, taux_interet_nominal, prix_conso) qui contiennent les attributs {année, mois, valeur}. Donc, il y'a une redondance.
J'ai pensé à modéliser les données de cette façon:
MCD:


MLD:

Quelques exemples tabulaires:

Mais, je bloque au niveau de la table "Matiere". je ne sais pas encore, quoi mettre dedans!

merci d'avance de votre aide.

[escartefigue]

Bonjour,

A minima vous aurez le libellé de la matière

Quelques mots d'explications sur la vocation de votre application seraient les bien venus et permettraient de mieux vous guider

[laminekane]

Bonjour escartefigue,

ci dessous, une description de la table Matère.

Je te précise également que c'est une discussion que j'avais entamé au mois d'août dernier avec fsmrel. Nous sommes parvenu à modéliser un tableau de données excel, la semaine dernière (http://www.developpez.net/forums/d15...s-economiques/). L'objectif à présent est d'essayer d'adapter cette méthode à un autre tableau de données excel (voir pièce jointe).
Si tu as besoin d'informations sur les données n'hésite pas, suis à ta disposition.

[fsmrel]

Bonsoir Lamine,

Dans le modèle actuel, on se retrouve avec 4 tables (matieres_cours, monnaie_cours, taux_interet_nominal, prix_conso) qui contiennent les attributs {année, mois, valeur}. Donc, il y'a une redondance.

Hum... Il y aurait redondance si on apprenait par exemple deux fois qu’en janvier 2006, l’huile d’arachide représentait 930 $/t. Le fait d’avoir 4 tables veut seulement dire qu’on 4 fois la même structure, une par domaine, nuance... Qui plus est, on pourrait mettre en œuvre une vue qui serait l’union des 4 tables, c'est-à-dire une table, virtuelle certes, mais manipulable comme une table de base au moins pour les SELECT (pour les mises à jour, avec MySQL c’est différent...)


Maintenant, souvenez-vous, Lamine, de l’image figurant ici :





L’en-tête de la table SECTEUR comporte 3 attributs, à savoir idSecteur, secteurLibelle, idUnite. Désormais, conformément à votre nouvelle modélisation, il faudrait compléter cet en-tête avec les attributs idPays et idMonnaie :

SECTEUR
idSecteur	libelleSecteur	idUnite	idPays	idMonnaie
1	Cours matières premières	1 ; 2
2	Changes (par rapport au CFA)
3	Taux d’intérêt nominal (long terme)
4	Prix à la consommation

Mais ! Mais ! Le MCD correspond-il à ce qu’on attend ? Par exemple, si l’on examine le fichier Excel, pour le secteur « Cours matières premières », il y a deux unités possibles, "$/t" et "$/bl", donc deux valeurs dans la cellule idUnite correspondante, ce qui est peccamineux en relationnel ! (viol de la première forme normale) : dans ces conditions, deux cas de figure :

— Soit on met en oeuvre un secteur « Cours matières premières en $/t » et un secteur « Cours matières premières en $/bl » ;

— Soit c’est l’entité-type MATIERE qu’on associe à l’entité-type UNITE, comme c’était le cas au mois d’août dernier...

Dans le 2e cas, on en arrive peut-être à la limite à ce que les attributs idUnite, idPays et idMonnaie migrent aussi, tout ou partie, de SECTEUR vers MATIERE, c'est-à-dire au tableau suivant :

MATIERE
idSecteur	idMatiere	libelleMatierere	idUnite	idPays	idMonnaie
1	1	Huile d'arachide	1
1	2	Huile de palme	1
1	3	Riz	1
1	4	Maïs	1
1	5	Coton	1
1	6	Phosphate	1
1	7	Pétrole Brent	2
2	8	Cours du DTS
2	9	Cours de l’euro
2	10	Cours du dollar
2	11	Cours de l’euro / cours du dollar
3	12	France
3	13	USA
3	14	Allemagne
3	15	Japon
4	16	USA
4	17	Japon
4	18	Allemagne
4	19	France
4	20	Royaume-Uni
4	21	Zone euro

En effet, selon votre diagramme MySQL Workbench, les associations entre SECTEUR et UNITE, PAYS et MONNAIE sont facultatives, mais en est-il vraiment ainsi, alors que selon le MCD elles sont obligatoires ? Pour qu’on soit en phase, et pour éclairer ma lanterne, merci de compléter les colonnes idUnite, idPays et idMonnaie pour les deux tableaux ci-dessus, et préciser « s/o » (sans objet) pour les cellules où l’information est inapplicable.

Ceci fait, on pourra voir quelle tactique adopter, mais on devrait arriver à ne mettre en œuvre qu’une seule table QUANTITE, sous réserve du remplissage précis des deux tableaux.


Quel temps fait-il à Dakar ? A Paris, on est dans la brume (et dans les grèves)...

[laminekane]

Bonjour fsmrel,

Hum... Il y aurait redondance si on apprenait par exemple deux fois qu’en janvier 2006, l’huile d’arachide représentait 930 $/t. Le fait d’avoir 4 tables veut seulement dire qu’on 4 fois la même structure, une par domaine, nuance... Qui plus est, on pourrait mettre en œuvre une vue qui serait l’union des 4 tables, c'est-à-dire une table, virtuelle certes, mais manipulable comme une table de base au moins pour les SELECT (pour les mises à jour, avec MySQL c’est différent...)

Effectivement, ce n'est pas tout à fait une redondance. Je voulais simplement éviter de renseigner l'année et le mois dans 4 tables différentes.
Même si après mûre réflexion, je vois que cette structure est vraiment la meilleure. Donc, il n'y a pas de raison d'essayer de tout mettre dans une seule table QUANTITE.
J'ai apprécié ton aide, pour la modélisation de ces deux tableaux de données, qui sont en fait, les deux types de tableaux contenues dans ma base de données. Par conséquent, je peux finir aisément la modélisation de toute la base.
Comment faire pour vous soutenir? Y'a t il, par exemple des livres à acheter?
Coté climat, c'est notre hiver en ce moment! les températures varient entre 23° et 27°.
Dommage que vous ne preniez plus l'avion!
bonne journée

[fsmrel]

Hello l’ami Lamine!

je peux finir aisément la modélisation de toute la base.

Attention, il y a peut-être des pièges tendus par le bonhomme Null, et différents scénarios pour le dégager manu militari... C’est pour cela que le remplissage des tableaux permettrait de s’assurer de la meilleure solution (en tout cas de la moins mauvaise...) Ne m’en veuillez pas d’insister

Des températures qui varient entre 23° et 27, c’est bon ça ! °J’ai un ami qui revient du Cameroun où il a passé les fêtes : les températures varient entre 37° et > 40°: j’en mourrais...

[laminekane]

C’est pour cela que le remplissage des tableaux permettrait de s’assurer de la meilleure solution (en tout cas de la moins mauvaise...)

Effectivement, j'ai bien compris que le remplissage des tables est crucial pour tester la rigidité du modèle. Le bonhomme NULL aura très vite de mes nouvelles.