Vous avez remplacé l'adresse courriel par le pseudo, donc un attribut fonctionnel par une autre attribut fonctionnel...
Si le pseudonyme du client change, vous tombez dans le même travers des mises à jour en cascade dans les tables filles.
Je le répète, pour l'identifiant primaire, choisissez un identifiant technique comme vous l'avez fait dans les autres types d'entité !
J'imaginais un pseudo invariable. j'ai mis un identifiant technique comme dans mes autres entités.
Prenons l'exemple des statuts, imaginons que vous ayez prévu "ouvert", "annulé", "validé" et "livré"
ces 4 statuts sont possibles, mais à un instant "t" rien n'indique que vous aurez au moins un "shopping cart" pour chacun de ces statuts
Il faut donc prévoir une cardinalité minimale de zéro.
De plus, pour les typologies, prévoyez également un code de type char court (char(4) par exemple).
Pour certains codes, il est conseillé d'utiliser les codifications ISO (par exemple codes pays, codes devises, codes langues, unités de mesure...). La plupart sont accessibles sur le web gratuitement.
Ok, bien compris
Les règles de gestion c'est par exemple
R001a : un client possède au moins une adresse
R001b : une adresse est possédée par un et un seul client
R002a : un article est contenu dans au moins un panier
R002b : un panier contient au moins un article
R002a est conforme à votre MCD mais très suspect : en l'état, vous ne pouvez enregistrer aucun article tant qu'il n'a jamais été réservé au moins une fois dans un panier
Vous voulez dire, que mon entités article devrait être relié à mon entité Administrator, qui lui pourrait enregistrer des articles sur le site?
Y aurai t'il quelque part, des exemples, ou des questions type a se poser avec le client pour bien définir ces règles de gestion?
Je viens de trouvez ça comme exemple, je vois avec mon frère et je reviens dans quelques jours avec des règles de gestion.
https://blog.developpez.com/cinephil...te_g_modelisat
Partager