Cardinalité dans le diagramme ER

Question

J'ai fait un projet qui est essentiellement une librairie en ligne où l'on peut acheter des livres et passer la commande.

Ma base de données contient différentes tables comme:

• user
• user_shipping_address
• user_payment_mode
• user_order
• order_shipping_address
• order_billing_address
• order_payment_details

J'ai essayé de construire le diagramme de EERD pour cela, mais je suis confus au sujet d'une chose: Un user_order ne peut avoir une adresse d'expédition. J'ai créé une clé étrangère order_id dans le tableau order_shipping_address qui fait référence à la clé primaire order.id. J'ai également une clé étrangère shipping_address_id dans la table order qui référence order_shipping_address.id. Lorsque j'essaie de générer le diagramme ER, cela me donne deux relations différentes. Une relation 1: 1 entre le order et l'adresse de livraison et une relation 1: M de l'adresse de livraison à la commande. Je ne sais pas comment structurer les contraintes de clé étrangère parce que je pense que la table de commande devrait contenir le shipping_address_id et l'adresse de livraison devrait contenir le order_id, non? Cela a juste rendu tout plus confus.

Aidez-moi s'il vous plaît à ce sujet.

Voici mon EERD:

Answer 1

Cela se produit parce que votre conception actuelle signifie qu'il est possible pour plusieurs user_order lignes à la même référence unique shipping_address ligne.

Vous devez modifier la conception de manière à ce qu'il soit impossible pour plusieurs lignes user_order de référencer la même ligne .

Il existe au moins deux solutions possibles:

1. Ajouter une contrainte UNIQUE sur user_order.shipping_address_id
2. Ou: inverser la relation (ce mon option préférée, car elle élimine les clés de substitution non nécessaires):
   1. Supprimez la colonne user_order.shipping_address_id.
   2. changement shipping_address.id à shipping_address.order_id, de sorte que c'est une clé étrangère de user_order.id
   3. Faire shipping_address.order_id la nouvelle clé primaire de shipping_address.

Notez que ces deux options sont une dénormalisation empêche le partage des adresses de livraison entre les différentes commandes (par exemple, si le même client fait le même ordre de répétition d'un lot) si cela peut être intentionnel - si que si la future adresse d'un utilisateur change, il ne sera pas involontairement mis à jour rétroactivement les anciens documents d'expédition de commande.

Quelques conseils:

• Pensez à utiliser int plutôt que bigint pour vos identités - je doute que vous aurez plus de 2 milliards de lignes dans chaque table.
• Ne pas utiliser aveuglément varchar(255) pour toutes les colonnes de texte - l'utiliser pour appliquer des contraintes raisonnables sur la longueur des données, par exemple state n'a pas besoin d'être plus de 2 caractères si vous stockez les abréviations, ditto zipcode qui peut être varchar(10) Si vous utilisez ZIP + 4.
• NE PAS ENREGISTRER LES NUMÉROS COMPLÈTES DE CARTES DE CRÉDIT DANS VOTRE BASE DE DONNÉES! (tel que vu dans votre tableau payment) - Ceci est une violation des règles PCI, une responsabilité massive et probablement une négligence illégale dans votre juridiction. Votre processeur de paiement vous fournira une valeur de jeton opaque de remplacement (ou quelque chose de similaire) pour identifier les cartes de paiement et appliquer les frais futurs aux détails de paiement stockés - le maximum que vous pouvez raisonnablement stocker est les 4 derniers chiffres. Que votre cryptage des données soit ou non largement hors de propos.