Conception BDD

Eléphant du PHP | 135 Messages

20 févr. 2009, 20:14

Merci ! Et bien c'est comme ça que la voyais aussi après réflexion!

j'ai aussi réfléchi entre temps pour le coté moteur !

SERIES/MOTEUR c'est bien 1:1 en effet puisque il y'a une motorisation pour une SERIES

et en théorie un moteur est unique à chaque SERIES? puisque la SERIES 1,9 n'es pas le même que celle de la 1,2 TD par exemple et moi j'aurais tendance à dire qu'un moteur appartient à une seul SERIES donc 1:1

après je suis pas un expert de l'automobile je me trompe sûrement qu'en penses tu ?

ensuite est que c'est bien dans l'entité relationnel serie_has_user que je me le prix l'immatriculation ou bien il manque quelque chose que je dois trouver ?

l'avantage c'est que j'en apprend autant sur le MCD que l'automobile lol

[Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur]

Mammouth du PHP | 19672 Messages

21 févr. 2009, 11:12

Salut,
.. en théorie un moteur est unique à chaque SERIES? puisque la SERIES 1,9 n'es pas le même que celle de la 1,2 TD par exemple et moi j'aurais tendance à dire qu'un moteur appartient à une seul SERIES donc 1:1

après je suis pas un expert de l'automobile je me trompe sûrement qu'en penses tu ?
Oui, ça se tient assez bien
ensuite est que c'est bien dans l'entité relationnel serie_has_user que je me le prix l'immatriculation ou bien il manque quelque chose que je dois trouver ?
Oui, au même titre que les dates d'achat/vente. Sommairement, tu te retrouves donc avec une table serie_has_user, quand un utilisateur achète une nouvelle voiture, ça va rajouter une ligne de données dans cette table. On pourrait même pousser un peu en ajoutant dans cette table un troisième élément à la clé primaire : le numéro de série par exemple, numéro qui est unique pour chaque véhicule. En effet, rien n'interdit à un utilisateur d'acheter plusieurs exemplaires d'une même série : or ça poserait un problème d'unicité de données puisqu'on ne pourrait pas avoir deux fois la même paire ser_id/usr_id.

Alors il y aurait une alternative : au lieu d'avoir une relation serie_has_user, on pourrait avoir une entité véhicule avec comme relation:
- user peut avoir 0:n vehicule et vehicule appartient à 1:1 user
- vehicule peut être 1:1 serie et serie correspond à 0:n vehicule
Et dans ce cas, vehicule a sa propre clé primaire veh_id par exemple et on va retrouver en clé étrangère ser_id et usr_id. Et dans cette entité vehicule, tu vas avoir diverses propriétés comme les dates d'achat/vente, l'immatriculation, le numéro de série, le prix d'achat (lorsque l'utilisateur achète le véhicule), le prix de vente (lorsque l'utilisateur revend ce même véhicule)
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse :axe:

Eléphant du PHP | 135 Messages

22 févr. 2009, 13:37

Bonjour et merci Cyrano !

et en théorie un moteur est unique à chaque SERIES? puisque la SERIES 1,9 n'es pas le même que celle de la 1,2 TD par exemple et moi j'aurais tendance à dire qu'un moteur appartient à une seul SERIES donc 1:1
donc je penses que je peux la fusionné avec en series 1:1 motorisation ?

Alors il y aurait une alternative
en effet je penses que je vais opté pour cette solution !

une petite question aussi pour marque, model, serie:

j'ai déjà en catalogue toutes les marques de voitures et les modèles mais pas les serie qui y correspond ca risque d'etre beaucoup de travail de trouver toutes les serie et de plus il n'est pas sur que j'ai besoin de tout ! je penses donc qu'il faut que j'enregistre une serie au cas par cas qu'en penses tu ?

de plus j'ai ajouter une table options (climatisation...)
je devrais créer une entité relationnel entre SERIES et OPTIONS
car l'entité serie peut avoir 0:n options et options appartiens à 1:n series

ca m'a l'air pas mal si je me trompe pas !

Mammouth du PHP | 19672 Messages

22 févr. 2009, 19:54

Salut,
l'idée de l'entité OPTION est effectivement à considérer. Mais c'est avec quelle autre entité tu dois la relier. SERIES serait le premier choix, mais comment pourras-tu déterminer quelles options tel client a dans le véhicule qu'il a acheté ? Ne faudra-t-il pas également relier OPTION et VEHICULE ?

Si on reprend, ça donnerait :
- SERIE propose 0:n OPTION
- OPTION équipe 1:n SERIE
- VEHICULE possede 0:n OPTION
- OPTION est installée dans 0:n VEHICULE
Et dans ce cas, tu vas te retrouver dans le modèle physique avec une table relationnelle entre OPTION et VEHICULE en plus de la relation entre SERIE et OPTION.

Pour l'ajout des séries, tu peux effectivement les rajouter au fur et à mesure, d'autant que les constructeur sortent périodiquement de nouvelles séries ponctuellement pour des modèles existant, voire des nouveaux modèles, moins souvent, mais il faudra pouvoir les ajouter également.
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse :axe:

Eléphant du PHP | 135 Messages

22 févr. 2009, 20:11

l'idée de l'entité OPTION est effectivement à considérer. Mais c'est avec quelle autre entité tu dois la relier. SERIES serait le premier choix, mais comment pourras-tu déterminer quelles options tel client a dans le véhicule qu'il a acheté ? Ne faudra-t-il pas également relier OPTION et VEHICULE ?
en effet tu as raison ! je n'y avais pas pensé !

donc:

SERIE 0:n OPTIONS et OPTIONS 1:n SERIES

et la même pour vehicule !

VEHICULES 0:n OPTIONS et OPTIONS 1:n VEHICULES

Ca se dessine c cool je commence grace à cette exercice à mieux comprendre les relations !

Mammouth du PHP | 19672 Messages

22 févr. 2009, 20:16

Je dirais que ce qu'il est important de retenir dans l'idée général, c'est qu'on répartit les informations de telle sorte qu'on évite les doublons et autres répétitions inutiles, on simplifie de ce fait la maintenance et les mises à jour du contenu. Ensuite, si on a correctement identifié les bonnes entités, on aura très très peu de propriétés permettant des valeurs NULL.

Ça donnera peut-être lieu a un nombre de tables plus important, mais de plus petites tailles et convenablement réparties. Avec les bonnes requêtes et les jointures appropriées, on retrouvera n'importe quelle informations pertinente très rapidement :)
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse :axe:

Eléphant du PHP | 135 Messages

22 févr. 2009, 20:32

c'est vrai !

je vais voir comment faire évoluer cette base avec ce que tu m'as appris !
j'ai sûrement des choses encore à voir au niveau des données à enregistré !


je penses qu'avec cette méthodologie et un peu de pratique sur divers cas je devrais
arriver à faire des bases de données qui tienne la route !

je te remercie pour l'aide que tu m'as apporté ce fut très enrichissant !

Bonne soirée !

++ ^^

[Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur]