2

Je suis en train de concevoir un modèle qui permet à un utilisateur d'être acheteur et vendeur avec un seul compte, mais certains enseignants m'ont dit que ce diagramme est faux parce qu'il a une redondance.Schéma d'entité-relation Redondance: magasin, produit, commandes, catégories

J'avais passé en revue le diagramme mais je n'ai pas trouvé un moyen de résoudre cette redondance. Dans le tableau orders j'ai besoin de savoir qui est un acheteur, donc pour cette raison, je n'ai pas supprimé cela de la table. Quelques idées?

enter image description here

+1

Il n'y a aucun utilisateur dans ce diagramme. Voulez-vous dire 'Orders.buyer' et' Product.seller' référence tous les deux TBL_store? Comme ceci est un modèle de vente d'entreprise à entreprise? Je ne vois aucune redondance là-bas. Vous devriez demander à votre enseignant de clarifier quelle partie a une redondance, ou peut-être pourrait-il décrire une anomalie qui pourrait survenir en raison de la redondance. –

+0

Oui, il est b à b, Merci pour votre commentaire. – AndresChika

+1

Sans rapport avec votre question - mais vous voudrez peut-être ajouter des quantités à 'Product' et' OrderProduct'. Et le cas où 2 ou plusieurs 'vendeur' existent pour un produit –

Répondre

4

La seule chose qui sont « redondantes » (non normalisée pour être exact) dans votre régime est la suivante:

link table

Vous n'avez pas besoin de faire une carte d'identité spéciale, un PK composite est suffisant.

------------------- 
| ORDERPRODUCT | 
------------------- 
| PK | PRODUCT_ID | 
| PK | ORDER_ID | 
------------------- 

ADD CONSTRAINT pk 
PRIMARY KEY (PRODUCT_ID, ORDER_ID); 
+0

Les ID n'ont rien à voir avec la normalisation, que ce soit à 1NF ou plus. – philipxy

0

En plus de ce que @Blag a dit, pour Categories, vous avez 2 champs qui pourraient faire la même chose: categoryname et description. Vous avez déjà un identifiant avec PK_IdCategory, donc l'un de ceux-ci pourrait être inutile