Discussion :

[Sebenf0rce]

Salut à tous, j'aurais besoin de vos avis concernant la conception de ma base de donnée.


J'ai obtenu le résultat suivant :


Est ce que vous voyez des choses incohérentes ou mal conçu ?
J'hésite surtout sur la partie paiement

Merci d'avance

[CinePhil]

Sans lire l'énoncé parce que 3 pages... bon...

1) Généralement, une association ternaire ne contient pas de patte avec des cardinalités 1,1.
Ici, je verrais plutôt deux associations binaires :
ABONNEMENT -1,1----concerner----0,n- SMARTPHONE
|------------------------1,1----concerner----0,n- FORFAIT

2) L'association "associe" est probablement fausse.
En l'état, elle signifie :
Un abonnement associe une seule facture et une facture est associée à un à plusieurs abonnements.
Je vous laisse en déduire ce qu'il faut changer.

3) J'ai un peu de mal à comprendre le sens de la partie Whitelist mais j'ai l'impression qu'il y a peut-être le même genre de souci qu'au point précédent.

4) Il va sans doute y avoir un souci de circularité entre propose et concerne.
Un abonnement peut concerner un smartphone qui n'est pas proposé par le forfait qui est concerné par l'abonnement.

[Sebenf0rce]

Salut, oui je comprends que t'ai pas eu envie de lire l'énoncé (par contre il fait qu'une seule page )

En fait j'ai fais une association ternaire car c'est le couple forfait/smartphone qui définit le prix de l'abonnement. Du coup c'est mieux de faire comme tu m'as dis et mettre l'attribut "prix" dans la table abonnement ?

Une facture est éditée lorsque le client a effectué le paiement pour 1 ou plusieurs smarphone/forfait, peut être je me trompe dans les associations ?

Pour la whitelist, chaque client a une whitelist qui contient ou non une liste de smartphone. C'est pas ce que tu comprends en voyant mon schéma ?

Pour le problème de circularité je vais y réfléchir. Une CIF pourrait faire l'affaire ?

En tout cas merci beaucoup pour tes remarques

[CinePhil]

c'est le couple forfait/smartphone qui définit le prix de l'abonnement. Du coup c'est mieux de faire comme tu m'as dis et mettre l'attribut "prix" dans la table abonnement ?

Si je comprends bien, il y a une notion de tarif des abonnements en fonction des couples (smartphone, forfait).
Un abonnement est souscrit par un client et on lui applique le tarif qui convient en fonction du couple (smartphone, forfait).
Donc il faut modéliser ce tarif et associer l'abonnement au tarif.

Pour la partie facture

... que je n'ai pas étudiée... et je n'ai pas trop le temps maintenant.
Modélise là selon ce que tu penses et je regarderai ça plus tard.

Pour la whitelist, chaque client a une whitelist qui contient ou non une liste de smartphone.

En l'occurrence, tel que tu l'as modélisé, chaque client peut avoir au maximum une whitelist. Ce n'est pas tout à fait pareil que "a une whitelist".

[Sebenf0rce]

Salut, j'ai bien relu le sujet et j'en suis arrivé au résultat suivant :



Pour le prix c'est pas un peu étrange d'avoir une table prix qui contiendra juste un nombre ?

Pour la whitelist je me suis mal exprimé, un client a bien une et une seule whitelist

Par contre je trouve une cardinalité 1.1 entre abonnement et forfait/smartphone. Tu m'as dis que normalement ça ne contenait pas ce type de cardinalité mais je ne vois pas comment faire autrement car un abonnement est associé qu'à un seul forfait et qu'à un seul smartphone.

[CinePhil]

1) L'état civil, c'est un nom, un prénom et, généralement, une civilité (Monsieur, Madame...).
Le choix de tout mettre dans une seule propriété, en plus de type CHAR, est un mauvais choix. Il sera en effet difficile de trouver tous les Dupont si certains sont enregistrés en tant que Jean Dupont et d'autres en tant que Dupont Albert, par exemple. Avec un grand nombre de données, les performances vont vite s'en ressentir.

De plus, il convient d'isoler la civilité dans une table de référence des civilités qui contiendra au moins la civilité en entier et son abréviation. On associe ensuite l'entité-type Civilite à Client.

2) Idem pour l'adresse, en principe composée au moins d'une partie numéro + rue, d'une partie code postal et d'une partie ville.
Il existe une norme pour les adresses mais dans le cadre d'un exercice scolaire, il n'est peut-être pas utile d'aller aussi loin.

En principe, les villes doivent être isolées dans une entité-type séparée pour éviter la même ville écrite sous plusieurs orthographes (Saint-Étienne, Saint Etienne, St Etienne...).

3) En toute rigueur, le "s’ils en possèdent une" (carte) du sujet demanderait une association à cardinalités (0,1 - 1,1) entre client et carte. Mais là encore, dans le cadre d'un exercice scolaire, la solution de la colonne pouvant contenir une chaîne vide est acceptable.

4) La marque du smartphone étant une information répétitive, la bonne pratique veut qu'on l'externalise dans une entité-type séparée pour éviter les saisies sous différentes orthographes.

5) Le choix du code barre en tant qu'identifiant de l'entité-type, donc de clé primaire de la future table, est un mauvais choix. Une bonne clé primaire est un entier auto-incrémenté (ou un groupe d'entiers pour une table associative).

6) Vous n'avez pas modélisé la couleur, pourtant évoquée dans le sujet.

7)

Il peut (...) connaître la liste des forfaits qui lui sont associés

On a donc une association entre smartphone et forfait et, pour le moment, rien d'autre !

8) D'après le sujet, on a donc bien une association entre un abonnement (au sens abonnement numéro A souscrit par le client numéro C) et un forfait... et, pour le moment, rien d'autre !

9) Il faut comprendre que le prix de l'abonnement A souscrit par le client C ne changera pas une fois qu'il aura été souscrit.
Il y a, d'une part, le prix du forfait qui "dépendra de la durée et des avantages offerts par le forfait" et, d'autre part, le prix du smartphone. Il faut donc une propriété prix dans l'entité-type Forfait et une dans l'entité_type Smartphone.
C'est l'ensemble des deux prix au moment de la souscription de l'abonnement qui va définir le "prix de l'abonnement". Il faut donc aussi une association entre Abonnement et Smartphone mais séparée de l'association mentionnée en 8).

10) Il manque dans votre schéma l'association entre Whishlist et forfait.
Au passage, vous avez écrit Whitelist au lieu de Wishlist dans votre MCD.

11) Il y a peut-être une association à définir entre le contenu de la whishlist et la commande.

12) "Le paiement s’effectue par un intermédiaire spécialisé" mais rien ne dit que c'est cet intermédiaire qui établit la facture.
Généralement, pour les achats sur internet, le site de e-commerce utilise les services d'un intermédiaire de confiance pour le paiement (Paypal, Stripe, Paybox...) mais c'est bien le site qui sait ce qui a été acheté et qui établit la facture avec le contenu de la commande. L'intermédiaire de paiement n'a à connaître que le montant à payer, l'identifiant du payeur et l'identifiant du site. Je précise ça en rapport à l'un de vos précédents messages.
Il manque dans votre MCD les notions de commande payée et de numéro de paiement.

[Sebenf0rce]

Merci beaucoup, j'y vois beaucoup plus clair maintenant.
Par contre il y a un point que je ne comprends pas. Au niveau du "11" pourquoi la wishlist devrait être relié à la commande ? Le panier et la wishlist sont deux éléments séparé.

Pour la wishlist je l'ai donc relié à la table forfait ainsi qu'à la table smartphone par des association séparées, mais du coup n'est-il pas possible d'ajouter un forfait qui n'est pas proposé avec le smartphone choisi ?