Discussion :

[Mikerhinos]

Salut a tous , voila mon soucis , j'aimerais realiser une page web de base de donnees de motos.
J'ai donc recupere tout un tas de docs de ces motos et ai fait mon MCD sur analyseSI , puis genere le mld et script sql.
J'ai importe les donnees dans ma base mysql , mais je me rends compte au remplissage "a la mano" de la 1ere moto (les suivantes seront ajoutees via une page php creee pour l'occasion) que ca ne va pas.

Mon soucis est le suivant : chaque moto a un frein avant et arriere , et un amortisseur avant et arriere.
Plusieurs motos peuvent avoir un frein avant ou arriere , ou un amortisseur avant ou arriere , identique a celui d'un autre modele.
Certaines donnees du frein avant ou amortisseur avant peuvent etre communes a l'arriere (nombre de disque de frein , reglage en compression/detente/precharge possible , debattement d'amortisseur etc...).

Comment puis-je faire pour gerer ce genre de chose ?

D'avance merci pour votre aide

[CinePhil]

A la lecture de ton message, j'ai l'impression que le MCD est mauvais.
Tu nous le montres ?

[Mikerhinos]

Je sens que je vais me faire taper sur les doigts et me faire gronder pour un mcd aussi mal fait mais bon je le post quand meme , j'avoue qu'a la formation que je suis on a fait que 4 jours de merise.

Attention les yeux

[CinePhil]

Effectivement, c'est pas beau !

Principe général pour un MCD : les entités sont des noms communs et les associations sont des verbes. Moto n'est pas un verbe il me semble... Donc moto est une entité et non pas une association. Ce sont bien des motos que ta BDD va gérer non ?

Ecris tes règles de gestion avec des phrases du type :
"Une moto est fabriquée par un et un seul fabricant."

On en déduis aisément les entités et les associations :
"Une moto est fabriquée par un et un seul fabricant."

On en déduis facilement le morceau de MCD :
Moto -1,1----Fabriquer----0,n- Fabriquant

Idem pour le reste.
Pour t'aider, voici quelques liens :
http://sqlpro.developpez.com/cours/modelisation/merise/

Bon courage.

[Mikerhinos]

Oui mon 1er mcd etait de ce genre , avec l'entite moto centrale , et tout un tas de relations avec les autres entitees , mais j'avais du me louper quelques part car analyseSI ne voulait pas de certaines cardinalites qui etaient pourtant bonnes d'apres moi , et une fois que je les ai recitifiees en 0,n pour qu'il accepte de construire le mld , je me suis retrouve avec 46 tables

Bon ben je vais repasser ma journee a tout reprendre a zero en suivant tes conseils , comment je peux faire pour ce probleme de gestion des freins et suspensions qui est mon soucis principal ?

Merci

Edit : mon tout 1er mcd ressemblait a ca :




J'avais tout "eclate" mais je pense qu'il respectait mieux les regles , je peux peut etre m'en servir de base en regroupant un certain nombre d'entites.

[CinePhil]

Règle de gestion :
"Une moto a un et un seul amortisseur avant et un et un seul amortisseur arrière"

MCD :
Moto -1,1----Avoir à l'avant----0,n- Amortisseur
|-1,1----Avoir à l'arrière ---- 0,n---|

Pareil pour les freins.

Allons plus loin avec les tables qui en découlent :
Amortisseurs(A_Id, ...)
Motos(M_Id, M_IdAmortisseurAvant, M_IdAmortisseurArriere, ...)

Edit après ton edit donnant ton premier MCD :
Je vois que tu avais la bonne association 'fabriquer'.
En ce qui concerne l'association 'tourner', je pense plutôt que AngleChasse et Chasse sont directement des attributs de l'entité Moto. Ce sont de simples nombres qui varient d'une moto à l'autre. Idem pour l'empattement, les hauteurs de selle, la longueur et la largeur de la moto...

On n'externalise dans les entités que les attributs candidats qui peuvent engendrer une redondance de données et qui peuvent être des données à gérer séparément. Le fabriquant de la moto en est un bon exemple. Tu pourrais te contenter de mettre le nom du fabriquant en tant qu'attribut de la moto mais si tu fais une erreur de saisie (Yahama au lieu de Yamaha), le jour où tu voudras compter toutes les motos de Yamaha, il t'en manquera. De plus, tu peux ajouter d'autres informations concernant le constructeur qui sont indépendantes de la moto (Pays du constructeur, date de création de la société...).

Dans ton MCD, il y a beaucoup d'entités qui sont en fait des attributs de la moto. J'en ai donné certains ci-dessus, il y en a d'autres.

[Mikerhinos]

Merci beaucoup pour ces precieux conseils

J'avais externalise tout ce qui est dimensions etc... car certains modeles de moto existent par exemple en 600cm3,750cm3 et 1000cm3 et ont beaucoup de ces caracteristiques en commun , mais bon en reunissant le plus possible de donnees dans les meme tables je me simplifierais beaucoup plus la vie au moment de tout remplir et de creer les scripts dans ma page php

Encore merci , comme dirait chantal lauby tu me retires une fiere chandelle du pied :p


Edit : avant d'aller manger je viens de faire un essai de l'entite "moto" et "amortisseur" avec les relations "avoir a l'avant" et "avoir a l'arriere" , et a la creation du mld je me retrouve avec les tables :

amort(id_amort)
moto(id_moto, id_amort, id_amort)

Comment reconnaitre l'avant de l'arriere ?

[Mikerhinos]

Petit update , je pense que c'est pas trop mal , j'ai du modifier pour les pneus/amortisseurs/freins histoire de pouvoir les differencier .



-croise les doigts-

[CinePhil]

avant d'aller manger je viens de faire un essai de l'entite "moto" et "amortisseur" avec les relations "avoir a l'avant" et "avoir a l'arriere" , et a la creation du mld je me retrouve avec les tables :

amort(id_amort)
moto(id_moto, id_amort, id_amort)

Comment reconnaitre l'avant de l'arriere ?

Ben comme je l'avais fait dans mon précédent message !

Quand tu dis "je me retrouve", tu veux dire génération automatique par Analyse SI ? Et après tu ne peux pas modifier les noms des colonnes générées automatiquement ?

Fondamentalement, je ne pense pas qu'il y ait une différence de concept entre un frein avant et arrière, entre un pneu avant et arrière... donc ton éclatement (pas du pneu hein, des entités ! ) est conceptuellement une erreur qui complique inutilement le schéma. Tu vas même probablement te retrouver avec les mêmes lignes dans les deux tables de pneus ou de freins.

[Mikerhinos]

Comme les donnees seront recuperees sur une page php dans un tableau , j'aurais besoin de differencier le frein avant du frein arriere car ils seront dans une colonne differente , pareil pour les pneus et les suspensions , donc j'ai tout eclate peut etre que j'aurais pu gerer ca d'une autre facon.

Pour les freins , certaines motos ont un frein avant compose de 2 disques , d'autres de 1 seul , certaines ont des etriers radiaux d'autres non , le nombre de pistons varie , ainsi que le diametre des disques (que j'avais oublie et que j'ai ajoute a la table detail_frein d'ailleurs ) , pour les frein arriere a part le diametre du disque il n'y a pas grand chose qui les differencie entre chaque moto par contre donc la aussi je n'ai peut etre pas choisi la meilleur solution.

[CinePhil]

Comme les donnees seront recuperees sur une page php dans un tableau , j'aurais besoin de differencier le frein avant du frein arriere car ils seront dans une colonne differente , pareil pour les pneus et les suspensions

Mais ils seront dans deux colonnes différentes de la table Motos ! Mais ces deux clés étrangères font référence à la même table des freins ou des pneus ou des suspensions.

Je t'avais donné le principe pour les amortisseurs :

Allons plus loin avec les tables qui en découlent :
Amortisseurs(A_Id, ...)
Motos(M_Id, M_IdAmortisseurAvant, M_IdAmortisseurArriere, ...)

[Mikerhinos]

Donc j'ai la possibilite de renommer la cle etrangere identique dans la table mysql "moto" pour la differencier , et pour les select il faudra que je fasse par exemple "select * from amortisseur join moto on amortisseur.id_amort = moto.id_amort_avant where id_amort_avant=1" ?

Desole pendant nos cours on a pas appris que l'on pouvait faire ce genre de chose mais si tel est le cas c'est vrai que ca me supprimerait quelques tables

[CinePhil]

Exemple avec les pneus :
Quels sont les pneus avant et arrière de la moto n° 12 ?

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
SELECT p1.id_pneu AS id_pneu_avant, 
  p1.larg_pneu AS largeur_pneu_avant,
  p1.diam_pneu AS diametre_pneu_avant,
  p1.haut_pneu AS hauteur_pneu_avant,
  p2.id_pneu AS id_pneu_arriere, 
  p2.larg_pneu AS largeur_pneu_arriere,
  p2.diam_pneu AS diametre_pneu_arriere,
  p2.haut_pneu AS hauteur_pneu_arriere
FROM motos m
INNER JOIN pneus p1 ON m.id_pneu_avant = p1.id_pneu
INNER JOIN pneus p2 ON m.id_pneu_arriere = p1.id_pneu
WHERE m.id_moto = 12

[Mikerhinos]

Oula ca va me faire faire des requetes de compet' pour mon ptit niveau de debutant

Je vais modifier le mcd en consequence et je pense que je pourrais creer les tables et attaquer la partie php pour le remplissage , le probleme Merisien est donc clos , merci beaucoup pour toutes ces aides et conseils

[JPhi33]

Bonjour,

Je me permets une petite remarque d'ordre général sur la démarche de modélisation.

Comme les donnees seront recuperees sur une page php dans un tableau , j'aurais besoin de differencier le frein avant du frein arriere car ils seront dans une colonne differente , pareil pour les pneus et les suspensions

Mais ils seront dans deux colonnes différentes de la table Motos ! Mais ces deux clés étrangères font référence à la même table des freins ou des pneus ou des suspensions.

Je t'avais donné le principe pour les amortisseurs :

Allons plus loin avec les tables qui en découlent :
Amortisseurs(A_Id, ...)
Motos(M_Id, M_IdAmortisseurAvant, M_IdAmortisseurArriere, ...)

Il est souvent inapproprié, voire dangereux, de se baser sur des éléments propres au MLD (i.e. les colonnes, les tables, ...) pour concevoir le MCD. Si ces étapes sont séparées et si le MCD se construit avant le MLD, c'est bien qu'il y a une raison. Au stade de la modélisation conceptuelle, on ne peut que supposer ce que sera le futur MLD.

La modélisation conceptuelle doit se baser uniquement sur les concepts et doit les utiliser pour en déduire des entités et des associations. Prendre à témoin des tables, des colonnes ou, pire, des requêtes pour concevoir un MCD est toujours une erreur... que l'on peut payer au prix fort.

Un exemple

Le spécialiste interrogé dit qu'une moto a une roue av et une roue ar différentes. Les caractéristiques sont le diamètre, le type de jante (rayons, monobloc) et la section. Comme le concepteur/développeur est malin et qu'il voit loin, notamment la base de données avec ses tables et ses colonnes, il se dit qu'une table est suffisante (mêmes colonnes). Il modélise donc ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
    +--1,1----(roule av)----0,n--+
    |                            |
[ Moto ]                      [ Roue ]
    |                            |
    +--1,1----(roule ar)----0,n--+

Une fois la base de données et le logiciel opérationnels, le spécialiste souhaite une évolution : il veut rajouter le type de pignon et le nombre de dents de la roue... arrière (sans être spécialiste de moto, je crois savoir qu'une roue avant n'a pas de pignon). Le concepteur/développeur n'a alors que deux options :
a) il crée une nouvelle table (qu'il devra remplir avec une partie des lignes de la 1e table) et... modifie probablement une grande partie des requêtes concernant les roues
b) il conserve l'existant (tant pis, il y aura des Null dans les nouvelles colonnes pour les lignes des roues av) et... modifie probablement une grande partie des requêtes concernant les roues

Pourtant, le spécialiste avait bien dit qu'une roue avant est différente d'une roue arrière...


JPhi33

[CinePhil]

Il est souvent inapproprié, voire dangereux, de se baser sur des éléments propres au MLD (i.e. les colonnes, les tables, ...) pour concevoir le MCD.

Je suis partiellement d'accord.
Oui on fait le MCD avant le MLD puisque normalement le MLD découle du MCD.
Par contre, un MCD est un ensemble d'entités composé d'attributs et d'associations entre les entités. Les associations sont éventuellement porteuses de données donc d'attributs supplémentaires. Elles sont de plus munies de cardinalités.
Les attributs du MCD deviendront des colonnes des tables de la BDD.
Sans préjuger du SGBD qui sera utilisé, quand on met les attributs dans les entités et les associations porteuses de données, on pense en fait déjà au MLD et à la future BDD physique.

Si ces étapes sont séparées et si le MCD se construit avant le MLD, c'est bien qu'il y a une raison. Au stade de la modélisation conceptuelle, on ne peut que supposer ce que sera le futur MLD.

Oui là-dessus.

Prendre à témoin des tables, des colonnes ou, pire, des requêtes pour concevoir un MCD est toujours une erreur... que l'on peut payer au prix fort.

Il s'agissait ici, et comme je le fais souvent sur ce forum, d'expliquer par un morceau de MCD l'enchaînement logique qui va du MCD au MLD et aux tables. N'ayant pas forcément sous la main de logiciel de modélisation rapide à utiliser pour mettre un joli schéma, je met le MLD sous forme plutôt de tables.

Un exemple

Le spécialiste interrogé dit qu'une moto a une roue av et une roue ar différentes. Les caractéristiques sont le diamètre, le type de jante (rayons, monobloc) et la section. Comme le concepteur/développeur est malin et qu'il voit loin, notamment la base de données avec ses tables et ses colonnes, il se dit qu'une table est suffisante (mêmes colonnes). Il modélise donc ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
    +--1,1----(roule av)----0,n--+
    |                            |
[ Moto ]                      [ Roue ]
    |                            |
    +--1,1----(roule ar)----0,n--+

Une fois la base de données et le logiciel opérationnels, le spécialiste souhaite une évolution : il veut rajouter le type de pignon et le nombre de dents de la roue... arrière (sans être spécialiste de moto, je crois savoir qu'une roue avant n'a pas de pignon). Le concepteur/développeur n'a alors que deux options :
a) il crée une nouvelle table (qu'il devra remplir avec une partie des lignes de la 1e table) et... modifie probablement une grande partie des requêtes concernant les roues
b) il conserve l'existant (tant pis, il y aura des Null dans les nouvelles colonnes pour les lignes des roues av) et... modifie probablement une grande partie des requêtes concernant les roues

Pourtant, le spécialiste avait bien dit qu'une roue avant est différente d'une roue arrière...

On peut aussi utiliser l'héritage pour différencier les particularités des roues avant et arrière.
RoueAvant -1,1----Etre----0,1-Roue
RoueArriere -1,1----Etre----0,1--|

Ainsi on n'est pas obligé de toucher au MCD d'origine.

[Mikerhinos]

Mes donnees de pneus sont dans l'entite "pneus" reliees a l'entite moto par une relation "roule a l'av" et une autre relation "roule a l'arr" , idem pour les freins , qui sont dans une entite reliee par 2 relations av-arr.
Il ne serait pas possible et plus simple de creer une entite "pignon-courronne" reliee a "moto" par la relation "entraine" ?
Dans le mld cela ajoutera simplement l'id_pignon en cle etrangere dans la table moto , on aura donc qu'a remplir la table pignon et indiquer l'id dans les motos existantes ce qui n'est pas tres laborieux.

Pour en revenir au mcd global , j'ai fais quelques petites bourdes qui font qu'il y a quelques redondances , exemple pour les cadres : j'aurais du separer les types et les matieres , car il y a 3 matieres principales (acier , acier haute resistance , aluminium) et 5-6 types qui peuvent etre de n'importe laquelle de ces matieres.
Enfin c'etait simplement un exercice que je m'etais impose pour m'entrainer avant mon stage qui commence ce lundi dans lequel je vais faire un site web de creation de factures facile avec gestion d'utilisateurs/profils, par contre je voulais ne pas utiliser de javascript car personnellement je surf via firefox avec l'addon noscript et je pense ne pas etre le seul a les filtrer , mais sur ma page web de l'exercice moto , on se rends vite compte que le serveur galere un peu parfois entre les requetes enormes avec multiples jointures et les scripts en php

Edit : erreurs de tete dans le c.. du samedi matin lol

[JPhi33]

Bonjour,

Sans préjuger du SGBD qui sera utilisé, quand on met les attributs dans les entités et les associations porteuses de données, on pense en fait déjà au MLD et à la future BDD physique.

Dans un MCD, on se situe au niveau conceptuel. Les entités et associations contiennent des propriétés conceptuelles et non pas des attributs. Il ne s'agit pas que d'une différence de terminologie (ce débat n'aurait aucun intérêt) : une propriété conceptuelle porte avant tout une définition sémantique (consignée dans le dictionnaire de données). On peut lui associer une famille ou classe de donnée (nom, libellé, quantité, nombre, code, etc.) qui préfigure le format de donnée qui sera défini plus précisément dans le MLD.

Donc je maintiens mes conseils aux futurs concepteurs, particulièrement ceux qui travailleront dans de grandes entreprises : au stade de la modélisation conceptuelle, on ne pense pas au MLD et encore moins à la base de données. Chaque modèle a ses propres préoccupations et objectifs.

Par contre, dans le cadre de travaux plus modestes (projets personnels comme celui de Mikerhinos ou projets de micro entreprises), on peut prendre des raccourcis car :
- le concepteur, le développeur et le DBA sont souvent la même personne, les "aller-retour" entre les 3 niveaux (conceptuel, logique, physique) sont donc plus faciles à faire
- les erreurs de conception révélées en phase d'utilisation peuvent être corrigées sans mettre en péril des mois.homme (voire des années.homme) de travail ni des gigaoctets de données.

On peut aussi utiliser l'héritage pour différencier les particularités des roues avant et arrière.
RoueAvant -1,1----Etre----0,1-Roue
RoueArriere -1,1----Etre----0,1--|

Ainsi on n'est pas obligé de toucher au MCD d'origine.

Effectivement, il faut penser au principe de généralisation/spécialisation dans ce cas. Mais ça ne dispense pas de devoir quand même toucher au MCD : l'entité Moto doit être associée à RoueAvant et RoueArriere.
En effet, si Moto reste associée à Roue, on dira, au niveau conceptuel, que "ce n'est pas sémantiquement correct" (je vous laisse le soin de vérifier pourquoi). Cette expression, qui pourrait passer pour anecdotique, a en fait des répercussions directes au niveau opérationnel (base de données et codage). Elle permet, entre autres, de ne pas devoir contrôler systématiquement qu'on n'attribue pas 2 roues avant (ou arrière) à une même moto.

Ne serait-ce que pour cette raison, la modélisation correcte est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
+------+                                   +------+
|      |--1,1----( )----0,n--[ RoueAV ]===>|      |
| Moto |                                   | Roue |
|      |--1,1----( )----0,n--[ RoueAR ]===>|      |
+------+                                   +------+

===> : relation "est-un"

JPhi33