conception base de donnees [Résolu]

[jean clode]

Bonjour,

je dois realiser une base de donnees pour l'entreprise dans laquelle je travaille.
Que pensez vous de cette base (voir piece jointe)?
Y a t il des redondaces, des incoherences...?

merci
jean clode

[timoth]

Ca sent le souffre ton affaire ! Je te mets qq remarques:

- La hierarchie a gauche me choque. Pour une adresse, on a une infinité de CustomerID et pour un customerID, on a une infinité de Customer. Est-ce vraiment ce que tu veux? Pourquoi pas une seule et meme table avec CustomerID, Customer Address et Customer avec une seule clé: Customer No.
- Pour les contacts dans l'entreprise (Customer Contact), je pense que la meilleure idée est de pouvoir rentrer plusieurs contacts pour un client. Dans ce cas, dans ta table contact, tu auras tes champs classiques (numero de tel, email etc..., une clé primaire ET un champ [Customer No] qui fait reference a ton client, avec une relation 1(sur la table Customer)-Infini(sur ta table contact)).
- PAreil sur les communications, tu auras plusieurs communications pour un client. Dans ton cas, tu as une communication pour plusieurs clients. C'est pas fort logique !
- Pareil avec ta table Customer Offer. Une offre a plusieurs Customer ? Non, je dirais le contraire, un Customer peut avoir plusieurs offres... La relation doit etre inversée. C'est dans ta table Customer Offer qu'il faut que tu aies un champ Customer No. Qu'est-ce que le champ Customer Offer No vient faire dans ta table Customer ???
- Pareil avec la table History. Il te faut plusieurs historiques pour une offre non????
- En haut a droite, c'est bien: Un client a plusieurs ordres. Un ordre peut avoir plusieurs produits et un produit peut avoir plusieurs odres. Pareil pour le lien Produits/Fournisseurs, ca me parait bon.
- Le lien description/produit, je ne comprends pas. Pourquoi pas dans la meme table ? Une description peut avoir plusieurs produits? Oui, en effet, pourquoi pas...

Je te conseille de revoir tout ca de fond en comble, sinon, c'est ton coiffeur qui va se plaindre de ne plus avoir grand chose a couper !

[jean clode]

Bonjour,

j'ai pris note de tes conseils.

J'ai commence une base de donne pour un PRODUIT, je voudrai etre sur de partir sur de bonne base, mon schema (minuscule) est il coherent?

Si je rajoute dans la table PRODUCT l'attribut SIZE, cela est il inutile (redondance)?

nb : si quelqu'un connait l'adresse de site ou je pourrais trouver des schemas sur les tables produits...

merci
jean

[timoth]

Oui, ca me parait bien comme ça !

Je vois bien l'intéret de la table intermédiaire Produit/Matiere dans le sens ou un produit peut etre constitué de bois, acier, plastique etc...
Est-ce aussi nécessaire pour le lien produit/Fournisseur ? Un produit enregistré dans ta table Produit peut-il avoir plusieurs fournisseurs ou vient-il nécessairement d'un fournisseur en particulier (auquel cas, un lien 1-Infini de produit vers fournisseur est suffisant)?
Je ne connais pas tes besoins, je me permets juste de demander ...

Par contre, a priori, je ne vois pas trop l'intéret de la table Size et de la table Product/Size ?
Un produit a une taille (Longueur, largeur, diam et epaisseur), pourquoi ne pas mettre directement ces champs dans ta table produit ?
La table intermédiaire n'aurait d'intéret que si tes produits de ta table produit peuvent avoir plusieurs dimensions (1 Produit = Plusieurs tailles possibles). Encore, est-ce requis dans ton cas.

Si je rajoute dans la table PRODUCT l'attribut SIZE, cela est il inutile (redondance)?

Oui, il y aurait redondance ! A quoi servirait ta table intermédiaire sinon? Si tu cherches a mettre la reference de la taille dans la table produit, c'est parce que tu n'as bien qu'une taille par produit, par conséquent, je te conseille d'intégrer tes tailles directement dans la table produit ou alors de supprimer définitivement ta table Taille/Produit qui ne sert a rien.

A +

[jean clode]

Pour la table Product/Supplier, j'ai un produit qui peut etre fabrique par plusieurs fournisseurs et un fournisseur peut fabriquer differents produits. Je vais donc la garder.

Pour la table Size, un produit peut avoir plusieurs taille (du moins dans mon cas) donc je vais supprimer la table Product/Size mais garder la table Size.

nb 1 : grace a tes remarques je commence a comprendre certaines choses, merci.

nb 2 : je voudrai rajouter la table couleur (je n'ai que deux couleurs rouge et jaune), un produit est soit jaune soit rouge. Pour n'importe quel produit le client doit choisir entre ces deux couleurs.
Pour cela je dois creer la table Product/Color et la table Color?ou uniquement une table Color?

Si je rajoute simplement un champ color dans la table Product, cela voudra dire que mon produit ne peur avoir qu'une seule couleur?

merci
jean

[timoth]

Attends, si tu as plusieurs tailles pour 1 produit, il faut que tu gardes la table intermédiaire Product/Size (tu ne pourras stocker qu'une seule taille par produit si tu l'enleves).
EX: Le produit xyz, stockée dans ta table produit, doit-on pouvoir lui associer une taille 1x2x2 ET une taille 4x6x6 ? Si oui, garde Product/Size, sinon tu l'enleves, tu stockeras ta reference de taille directement dans ta table produit.

Tu as une table intermédiaire quand un enregistrement de ta table A peut etre associé à plusieurs enregistrement de la table B ET quand un enregistrement de la table B peut etre associé a plusieurs enregistrements de la table A. Dans les autres cas, une jointure 1-Infini entre les deux tables est suffisante.

Dans le cas de tes couleurs, une couleur de la table [Couleur] peut avoir plusieurs produits MAIS un produit ne peut avoir qu'une couleur => Jointure 1-Infini entre couleur et produit.

Ça commence à venir ??

[jean clode]

ca commence a venir...lol

j'ai encore une petite question...(promis c'est la derniere)

j'ai un produit qui est mis dans un emballage individuel (INDIVIDUAL PACKING).
Un produit peut etre emballe dans differents types d'emballages selon le choix du client, et un type d'emballage peut etre utilise pour differents produits, j'ai donc une relation infini-inifini? J'ai un doute.

Ensuite, j'ai un pack (CASE PACK) qui contient plusieurs emballages (INDIVIDUAL PACKING), un carton (MASTER CARTON) qui contient plusieurs pack (CASE PACK).
Par exemple, un pack (CASE PACK) a plusieurs tailles (SIZE) : puis je relie CASE PACK avec SIZE grace a une table intermediaire CASE PACK/SIZE?

De meme pour INDIVIDUAL PACKING et MASTER CARTON?

Ca risque d'etre la pagaille!
Si je cree une table CASE PACK SIZE et une table intermediaire... ca ne serait pas mieux?

encore merci
jean

[timoth]

Salut,

j'ai un produit qui est mis dans un emballage individuel (INDIVIDUAL PACKING).
Un produit peut etre emballe dans differents types d'emballages selon le choix du client, et un type d'emballage peut etre utilise pour differents produits, j'ai donc une relation infini-inifini? J'ai un doute.

Dire que les produits peuvent avoir plusieurs emballage n'est pas comme dire qu'un produit peut avoir plusieurs emballages. Ce qui compte c'est est-ce qu'une ligne de ta table produit peut avoir plusieurs emballages (si oui, alors en effet Infini-Infini), sinon 1produit=1type d'emballage alors relation 1-Infini (simple lien entre Produit et Emballage)

Par contre, je ne suis pas sur de bien comprendre ton truc avec les cartons/packs/emballages. Ca veut dire que dans un MASTER CARTON, tu mets des CASE PACK qui eux meme contiennent les INDIVIDUAL PACKING ?

[jean clode]

oui, c'est ca...
Un carton contient plusieurs packs et chaque pack contient plusieurs emballages.

Je voudrais juste savoir si je peux utiliser la table SIZE avec emballage, pack et carton ou si je dois creer une nouvelle table SIZE?

jean

[timoth]

j'avais pas vu ta copie d'écran, dslé.

Je ne vois pas tres bien pourquoi tu as besoin de relier ta table Size avec les tables individual packing / case pack / carton / palette. Je pense que c'est inutile, tu vas te créer des ennuis.

A bientot