salut à tous ! je fais en ce moment une base de donnée dans laquelle je vais stocker des produits informatiques...

j'ai une table produits qui se présente de cette façon :

produits(id,nom,caractéristique,prix,#marque,#categorie)

vous l'aurez compris la marque et la categorie sont des clefs etrangères... mon problème le voici :
- suivant le type de produits les caractéristiques associées sont forcément différents exemple :
pour une webcam je vais stocker le nombre d'image par seconde, la resolution etc... pour un graveur la lecture d'écrite, lecture etc... je voudrais savoir si il y a un moyen de présenté tout cela différemment en fonction justement du produit (en fonction de la categorie à laquelle il appartient plus précisemment !)

Merci bien !

Pour concevoir ta base, prends une grande feuille de papier et un crayon et fais une liste de toutes les données que tu vas devoir manipuler. Après ça, fait un classement par entité/propriété : c'est à dire par exemple, un entité prix aura un montant HT, donc l'entité, c'est le prix qui va devenir une table prix et la propriété c'est montant qui va devenir un champ de cette table.

On appelle ça créer un dictionnaire de données. Oublie pendant cette phase le problème de clés primaires ou étrangères, ça viendra dans la phase suivante.

à partir du dictionnaire tu pourras concevoir une base structurée sans doublons ni problème de savoir comment répartir quelle donnée dans quelle table. Tu établiras alors des clés primaires dans tes tables et ensuite, en fonction des relations entre les différentes tables, tu crées les clés étrangères.

salut cyrano ... tout ça c'est fait !
je fais de l'analyse informatique (merise) donc je connais tout ça je voulais juste savoir si il n'y avait pas une façon différente de présenter les caractéristiques dans mes produits... j'ai fais mon DDD, MLD, MCD je voulais un conseil pour voir si il y avait possibilité de gérer ça autrement !

merci

Good, enfin quelqun qui me regardera pas avec des yeux de merlan frits que je parlerai de MCD

Bon, revenons à ton problème : selon le produit, les caractéristiques sont différentes, mais la formulation de ces caractétistiques diffère-t-elle suffisament pour obliger à une modification de la base ?

Si un produit doit avoir deux types d'informations et un autre quatre types, alors il faut peut-être envisager une table type d'info et une table infos_tout_court.

Si la future base va là où je pense (pour un magasin d'info, le nombre de référence peut être conséquent) tu n'as pas vraiment le droit à l'erreur parce qu'une re-structuration après coup sera un cauchemard...

héhé ! bon bien bien ! J'ai des produits qui possèdent des types d'informations qui peuvent varier en effet ! t'as bien résumé la situation en fait :p bon la table type d'infos... je vois pas comment tu peux gérer correctement les propriétées de l'entitée... sans faire de la redondance ou autres
tu voudrais bien me donner un exemple d'occurence pour voir ce que ça donerait stp ! merci !
oui j'ai pas envie de recommencer ma base c'est la phase la plus importante avant la conception web donc... je m'applique

L'idée générale est la suivante:
Type d'infos:
- caractéristiques techniques
- dimensions (qu'on peut subdiviser
- Poids
- compatibilité Win/Max/Linux
- Description sommaire
- Description détaillée
- prix HT
- illustration (photo)

Cette entité pourrait être une relation entre la table produit et les autres tables parce que tu pourrais subdiviser les informations, mais dans plusieurs cas, tu vas avoir des cardinalités 0-n/0-n
Chacun des points énumérés plus haut peut dans certains cas être subdivisé, supprimé ou modifié dans ta conception, je ne fais qu'énoncer une idée globale
Tu vas avoir des informations que tu auras toujours pour tous les produits, donc relation directe possible et cardinalité 1-1/1-1, mais dans certains cas, par exemple la compatibilité, ça ne s'applique pas obligatoirement. Mais si tu mets tout dans la table produit, tu auras plusieurs champs avec des valeurs NULL ce qui est à éviter autant que possible.

hey ! oue en fait voici mon schéma relationnel pour le moment :

categorie(id,nom)
marque(id,nom,url,logo)
produit(id,nom,description,caratéristique,prix,photo,#categorie,#marque)
client(id,nom,prenom,adresse,adresse_livraison,code_postal,ville)
// CIM
COMMANDER(#client,#produit,#date,quantité)

je vais voir comment intégrer correctement ce que tu m'as énnoncé plus haut... en espérant que mon schéma soit correct

c'est pareil j'aimerais bien rajouter le type de paiment (cb,chèque,...) pour une commande pour pouvoir récapituler les différentes commandes du client et son type de paiement lorsqu'il se connectera à son compte... si je le place dans COMMANDER à la suite de quantité je pense que c'est bon (arf pb de rédondance quand mm la )

Pour le paiement, il te faut une table paiement avec un champ de type ENUM et en clé étrangère l'id_client et éventuellement une autre FK id_commande.

Enfin bon, je vois ça comme ça.

Tu as raison de prendre ton temps, c'est un sacré casse-tête et on a toujours la crainte d'avoir oublié un truc suffisament important pour devoir restructurer tout. Le dictionnaire de données est pour ça un outil très précieux

Et visiblement, le dictionnaire des données a été oublié ou alors il est particulièrement incomplet :
- pas de gestion des stocks ;
- pas de gestion des commandes ;
- pas de gestion des factures ;
- pas de gestion du client (adresse email).
Et ca, c'est avec 30s de réflexions.

Je pense donc qu'il te faut tout remettre à plat au niveaux des données pour être sur de ne rien avoir oublié.

hola les gens en effet j'avais oublier quelques trucs quand meme ! c'est un nouveau projet... j'ai pas encore tous les éléments en main mais j'essaie de faire un début de MCD voila le résultat ... il manquerait quoi à premiére vue ? svp

http://membres.lycos.fr/madeinitalia/beta.png

en ce qui concerne ta remarque plj c'est mon association commander qui va me servir pour gérer les commandes... le stocks j'ai ajouté une quantité de produits dans l'entité produit que je mettrais à jour quand une commande sera effectué... le mail est ajouté c'est vrai je l'avais complétement zappé !
pour la facture par contre je vois pas trop comment procéder... je vais voir pour rajouter le paiement comme la dit précédemment cyrano voila merci !

Pourquoi une entité date à part : ça pourrait très bien être une propriété de "Commander" : chaque commande aura obligatoirement une date. Si tu procèdes comme ça, ton modèle physique va générer une clé étrangère date dans la table Commander ce qui à mon sens ne sert pas à grand chose de plus.

Bon, faut dire que j'ai toujours eu horreur des "3 pattes" et je me suis toujours arrangé pour les éviter

lol cyrano

bah oué au final ça revient au mm je peux en effet mettre date dans commander et le rendre obligatoire

rien d'autre à signaler par hasard ?

si on pousse un poil plus loin, j'aurais rajouté une entité "telephone" à coté de client avec en propriétés :
- id_tel Int auto_increment <PK>
- num_tel varchar(10)
- type_tel enum('domicile','portable','bureau','fax')
Mais à part parce qu'un client peut avoir plusieurs numéros. et le numéro en varchar parce que sinon le zéro initial sera bouffé à l'enregistrement.

À la rigueur, le num_tel étant unique, il pourrait servir de clé primaire.

exact le numéro de tél :/ mouarf les truc basiques je l'ai oublie ! c'est dingue ça !

Ha si tiens, il manque encore un truc: comment vas-tu déterminer que le client est celui à qui on facture ou celui à qui on expédie la commande ?

Première idée : un champ enum dans la relation "Commander"