Forum d'entraide PHPFrance

hello world !

Voila je crée un shema de BDD avec mysql workbench !

j'ai encore un peu de mal avec les relation type 1:n et n:n !
je fais un site intranet de gestion de voitures pour un amis voici les tables en bref !

1. table client (nom, prenom,adresse...)
2. table voiture(marque mode, année..)
3. table options(ABS,DA...)
4. une table avec les marques et une autre avec les models

je voudrais savoir si mes relations sont bien pensées ?

client 1:n voiture
voiture 1:n marque
voiture 1:n model
voiture n:n options

je sais pas ce qui est le mieux pour les options sachant que ca viens de checkbox dynamique !

es que si je fais une table avec toute les options genre index -> options puis je crée une table intermediaire entre options et voiture du fais que une voiture peux avoir plusieur options et qu'une options peux apartenir a plusieur voiture ?

j'ai peur que cette table intermediaire devienne vite enorme en fonction des options choisi !

mais peut etre suis je à coté de la plaque lol

Merci pour votre aides !

Tu es à l'envers dans la relation entre voiture et marque : une voiture appartient à une et une seule marque, mais une marque peut avoir plusieurs voitures.

Ceci dit, je dirais que globalement, l'entité "voiture" n'a en fait pas vraiment lieu d'être, et schématiquement, on aura dans l'ordre :
- marque;
- modèle;
- série;
- options;

Et donc :
marque 1:n --- 1:1 modele
modele 1:n --- 1:1 serie
serie 1:n --- 1:n option

Entre série et option, on aura donc une table relationnelle : une série peut avoir 0 à n options, mais on peut retrouver une option sur 1 à n séries.

Par contre le lien entre client et voiture se ferait dans ce cas entre client et série. Dans la mesure où on identifie pas précisément chaque véhicule, on aura une relation :
serie 0:n (1:n)--- 0:n (1:n) client

Ce qui donnera lieu à une table relationnelle entre "serie" et "client".

Merci ta reponse !

en effet tu as raison j'ai inversé la relation voiture - marque

et je crois qu'en effet l'entité voiture peux etre evité !
j'etais parti comme raisonnemant :

un client peux posseder plusieur voitures...

pour resumer :

table client -> 1 | Dupont
table marque -> 1 - renault
table model -> 1 - clio
table serie -> 1 - 1,6

on créer une table series car un model peux avoir plusieurs serie ? genre clio williams ou bien clio 1,6 TD
et je créer une table intermediaire entre serie que je pourrais appeller possede par exemple ?

j'ai encore du mal à comprendre la relation avec client et series

merci d'avance pour ta patience !

Si : il faut considérer qu'une ligne dans "serie" correspond à un véhicule : donc par relation correspond à un modèle et on continue jusqu'à la marque.

Dans MySQL-WB, en ayant une relation n:m entre série et client, il va automatiquement se créer une table relationnelle (nommée automatiquement, mais tu peux la renommer ensuite) qui comprendra en clé primaire une clé composite formée par les clés étrangères des tables "serie" et "client" : dans cette table relationnelle, tu pourras éventuellement ensuite ajouter des éléments propres à un véhicule, prenons par exemple l'immatriculation que tu ne pourrais pas affecter un une série, pas davantage à un client : il faut les deux puisqu'une immatriculation identifie le véhicule d'une personne. Mais tu peux avoir d'autres types de propriétés pour cette table relationnelle. Une date d'acquisition par exemple, et pourquoi pas une date de vente si tu veux garder un historique ou à des fins statistiques.

Bonjour !

DE RETOUR !

je reviens 10 ans après sur le sujet lol j'avais du laisser de coté cette réflexion à cause d'un autre projet !

je voulais savoir si c'est dans la table SERIES que je met par exemple la puissance fiscale,
son type diesel ou essence, le type de transmission ? en faite ce qui ne change pas par rapport à un model

et ce qui change et donc qui ne reste jamais vraiment fixe comme l'immatriculation, le kilométrage,
date d'achat je le met dans la table intermédiaire entre CLIENTS et SERIES si j'ai bien compris ?

merci d'avance !

je voulais savoir si c'est dans la table SERIES que je met par exemple la puissance fiscale,
son type diesel ou essence, le type de transmission ? en faite ce qui ne change pas par rapport à un model

Pose-toi la question suivante : est-ce que pour une même série on peut avoir plusieurs puissances fiscales différentes ? Si oui, alors selon quels critères ? Et par déduction, tu sauras si la puissance fiscale dépend de l'entité "serie"(série = toujours la même puissance fiscale) ou d'une autre entité à définir, voire d'une combinaison à travers une relation, par exemple, serie//motorisation.

merci !

je dirais qu'il y'a plusieurs puissance par série puisque qu'il peux y avoir la golf3 version diesel ou essence et donc la puissance fiscale n'est pas la même !

j'opterais pour la solution d'un table motorisation et la relation serais n:n puisque un série peut avoir de 1:n puissance et que un puissance fiscale peut avoir 1:n serie

Es bon ?

par contre je vais donc avoir aussi d'autre donnée qui risque d'être redondante genre si c'est essence, diesel, type de transmission que je peux peut être inséré dans la table motorisation...

À ce stade, ne réfléchis pas en terme de "tables" et de "colonnes" : pense en terme d'entité et de propriétés.

Tu as un certain nombre de données à manipuler, certaines sont des entités, d'autres sont des propriétés de ces entités. C'est le tri que tu dois opérer en premier lieu en établissant les cardinalités entre les entités, c'est à dire si le lien entre deux entités est 0:1, 1:1, 0:n, 1:n ce qui en d'autres termes veut dire "entité A correspond 0 ou 1 fois à entité B" (remplace le 0 et le 1 par les autres possibilités de combinaisons citées juste avant)

C'est comme ça que tu obtiendras un modèle de données cohérent et surtout pérenne.

Merci pour cet éclaircissement comme tu l'as dis j'ai tendance à pensé table etc
faut que je prenne cette habitude c'est pas toujours évident mais avec de l'entrainement...
par contre j'ai des difficultés avec le mot cardinalités il est pas encore bien ancré dans mon cerveau lol!

je vais faire quelque recherche la dessus !

Hello !

bon j'ai lu se cours sur le MCD:
http://sqlpro.developpez.com/cours/mode ... ge=base#L2

en plus de tes conseils

voila comment je vois la chose pour la base !

je vois donc pour commencer USER, MARQUE, MODEL, SERIES, MODEL, MOTORISATION, ENERGIES

une MARQUE peut avoir de 1 à n MODEL
un MODEL peut avoir de 1 à n SERIES
une SERIES peut avoir de 1 à n MOTORISATION
une MOTORISATION peut avoir qu'un seul type d'energie mais je créer une entité pour avoir à evité de le réenregistré !

ensuite je peux faire comme tu me la conseillé une table relationnel entre USER et SERIES ce
qui me permetrais d'enregistrer les informations qui ne peuvent pas etre ni dans SERIES ni dans USERS!

comme l'immatriculation, une date d'acquisition éventuellement le prix, si c'est une première main... parce qu'elle peut par notre intermédiaire être revendu !

je peux aussi créer une entité SERIE_CATEGORY puisque une serie peut avoir une category du style berline, break, coupé etc ! la aussi je préfère séparé pour évité les redondances...

Salut,

je vois donc pour commencer USER, MARQUE, MODEL, SERIES, MODEL, MOTORISATION, ENERGIES

une MARQUE peut avoir de 1 à n MODEL
un MODEL peut avoir de 1 à n SERIES
une SERIES peut avoir de 1 à n MOTORISATION
une MOTORISATION peut avoir qu'un seul type d'energie mais je créer une entité pour avoir à evité de le réenregistré !

Tu en oublies une partie : tu indiques en effet les relations dans un seul sens : et dans l'autre ?
Donc, il faut établir les deux sens :

• MARQUE peut comprendre 1 à n MODEL et MODEL correspond à 1 et 1 seul MARQUE;
• MODEL peut comprendre 1 à n SERIES et SERIES correspond à 1 et 1 seul MODEL;
• SERIES peut comprendre 1 à n MOTORISATION et MOTORISATION correspond à 1 et n SERIES : attention ici, un même moteur peut être utilisé pour différent véhicules d'un même constructeur;
• MOTORISATION utilise 1 et 1 seul ENERGIE et ENERGIE alimente 0 à n MOTORISATION : mais là aussi, attention, tu auras assez peu de valeurs à enregistrer pour cette entité. Il existe un type ENUM avec MySQL et certains autres SGBDR pour un nombre limité de valeurs. Au bureau, j'ai même trouvé une astuce sous Oracle qui ne connait pas le type ENUM et j'ai fait sauter deux tables comme ça. Donc dans ce cas, je privilégierais cette option plutôt qu'une entité;

ensuite je peux faire comme tu me la conseillé une table relationnel entre USER et SERIES ce
qui me permetrais d'enregistrer les informations qui ne peuvent pas etre ni dans SERIES ni dans USERS!

Ce n'est pas la bonne raison d'avoir une table relationnelle : la bonne raison, c'est le type de relation :
USER peut posséder 0 à n SERIES, SERIES appartient à 1 et 1 seul USER : donc en principe, tu ne devrais pas avoir de table relationnelle.

comme l'immatriculation, une date d'acquisition éventuellement le prix, si c'est une première main... parce qu'elle peut par notre intermédiaire être revendu !

Voilà la raison qui modifie l'assertion précédente : SERIES appartient à 1 à n USER «dans le temps», on introduit là une notion d'historique qui justifie une relation n:n

je peux aussi créer une entité SERIE_CATEGORY puisque une serie peut avoir une category du style berline, break, coupé etc ! la aussi je préfère séparé pour évité les redondances...

Là, c'est comme pour le carburant : tu auras assez peu de valeurs différentes, donc ça peut rester une propriété de l'entité SERIES de type ENUM.

Je précise pour les curieux qui utiliseraient Oracle et se demandent comment j'ai procédé : je n'ai rien inventé et une recherche sur le net vous donnerait la même chose.

Dans la table, au lieu d'une clé étrangère, mettez une colonne de type Chaine-de-caractère d'une longueur appropriée. Ajoutez ensuite une contrainte du genre : Enjoy !

Tout abord merci pour ton aide !

merci de m'avoir repris sur les relations je penserais à l'avenir à donner les relations dans les 2 sens dans ma tête c'est explicite mais c'est vrai que sa doit être explicite pour tous le monde, afin de me mieux me faire comprendre !

SERIES peut comprendre 1 à n MOTORISATION et MOTORISATION correspond à 1 et n SERIES : attention ici, un même moteur peut être utilisé pour différent véhicules d'un même constructeur;

si une motorisation connais ça SERIES qui connais son MODEL jusqu'a la MARQUE si je dis bon
ou dois je faire attention ?
que me conseille tu par rapport à ce cas de figure ?

pour ce qui est de l'entité USERS et la table relationnelle et SERIES justement je me suis aussi posé la question!

car comme tu l'a citer un USER peut posséder de 0 à n SERIES et une SERIES appartiens qu'a un seul USER c'est donc la notion d'historique qui justifie cette table c'est à dire la date qui me permet d'archiver par exemple ?

merci aussi pour l'astuce ENUM je connaissais pas ça chez MYSQL je vais l'etudier de plus près sur leur doc !

L'histoire des motorisation est en réalité un petit piège.

Je vais te laisser y réfléchir, mais avec un indice toutefois : dans la description des relations que je t'ai faite plus tôt, il manque une relation avec la motorisation, par contre celle que j'ai indiquée est fausse. SERIES utilise 1:1 MOTORISATION, et MOTORISATION équipe 1:n SERIES. Mais MOTORISATION est également reliée à une autre entité du modèle de données. C'est ce qui va te permettre de relier USER à un véhicule bien précis équipé d'un moteur précis également, enfin si je me suis pas gouré et j'ai un doute à ce propos. Faudra que j'y revienne dans la soirée, là je suis au bureau, j'ai pas trop le temps de m'arrêter dessus.

C'est une bonne gymnastique intellectuelle, je te l'accorde, mais ne vas pas une seule seconde penser que c'est une perte de temps

C'est une bonne gymnastique intellectuelle, je te l'accorde, mais ne vas pas une seule seconde penser que c'est une perte de temps

bien au contraire je trouve que c'est très instructif !

et c'est comme ça que j'apprendrais le mieux !

je vais donc méditer sur la question et reviendrais pour y répondre en espérant trouvé le piège que tu m'as tendu mdrrr

thanks !

Re,
bon ben après réflexion, je n'étais pas loin, mais la première idée était plus juste.

Sommairement, le quelette de base de ton modèle de données devrait ressembler à ceci :