par
Cyrano » 20 févr. 2009, 15:31
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 :
Code : Tout sélectionner
ALTER TABLE "NOM_SCHEMA"."NOM_TABLE"
ADD CONSTRAINT "NOM_CONTRAINTE"
CHECK (
LOWER(NOM_DE_LA_COLONNE)
IN ('valeur possible 1','valeur possible 2','valeur possible 3')
) ENABLE;
Enjoy !
Salut,
[quote="hi-logik"]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é ![/quote]
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 :
[list]
[*]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é;[/list]
[quote="hi-logik"]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![/quote]
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.
[quote="hi-logik"]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 ![/quote]
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
[quote="hi-logik"]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...[/quote]
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 :
[code]ALTER TABLE "NOM_SCHEMA"."NOM_TABLE"
ADD CONSTRAINT "NOM_CONTRAINTE"
CHECK (
LOWER(NOM_DE_LA_COLONNE)
IN ('valeur possible 1','valeur possible 2','valeur possible 3')
) ENABLE;[/code]
Enjoy ! ;)
