Discussion :

[digaburla]

Aprés avoir suivi le tuto "initiation-merise", je viens vous montrer mon MCD et prendre vos avis.

Voici le cahier des charges :
Des articles (contenu texte) sont proposés pour présenter les services
Un service (catégorie) propose plusieurs produits qui eux même on des options spécifiques
Un client peut faire une commande (ce n'est pas un site e-commerce a proprement parler, il achête un prestation pas un produit réel / physique) : il choisi son produit et ses options
Un user peut faire une commande (au même titre que le client) sauf qu'il est loggé (client connu)
Chaque User a un profil particulier

Voici le MCD que j'ai réalisé et pour lequel j'aimerai avoir vos avis




Merci

[ZenZiTone]

Bonjour,

Un user peut faire une commande (au même titre que le client) sauf qu'il est loggé (client connu)

Pour moi, cette règle traduit une association entre User et Client. En effet, un User est un Client (d'ailleurs, beaucoup de champs sont égaux dans les deux entités). Cela te permettrait donc de retirer l'association entre le User et la Commande.

Un service (catégorie) propose plusieurs produits qui eux même on des options spécifiques
Un client peut faire une commande (ce n'est pas un site e-commerce a proprement parler, il achête un prestation pas un produit réel / physique) : il choisi son produit et ses options

Qu'entends-tu par "Service"? Pour ma part quand je vois ça, je me dit que c'est ce qui est vendu au client. Hors, la commande se fait sur le produit. Pourrais-tu expliciter?

Sinon pour les cardinalités je ne me souviens plus exactement dans quel sens les lire en Merise En tous cas une me semble incorrecte : tu as du 1,1 entre commande et produit. Ce qui induit qu'un produit peut être commandé qu'une seule fois?

[digaburla]

Bonjour et merci pour ce retour,

Pour ce qui est de User & Client
J'ai séparer en 2 entités car le site fonctionnerait avec des User (partenaire client qui propose les prestations) et les clients (particulier) qui souhaite profiter de la prestation et qui sont censé aller jusqu'à la commande. MAIS suite a-t-on message, et la réflexion qu'il a suscité, le partenaire (USER) va se servir du système d'estimation de COMMANDE sans passer de commande, il n'a donc finalement pas d'association avec l'entité COMMANDE.
=> J'ai donc supprimé l'association entre USER et COMMANDE

Qu'entends-tu par "Service"?

En fait SERVICE pourrait s'appeler CATÉGORIE. La COMMANDE se fait sur le PRODUIT qui fait partie d'un SERVICE (catégorie).
En gros le service : numérisation audio, le produit : cassette audio - > donc la COMMANDE se fait sur le produit cassette audio qui représente la prestation de numérisation K7 audio

Un produit peut être commandé qu'une seule fois?

Oui un produit (prestation) peut-être commandé qu'un seule fois par commande.
1 prestation / commande

Est-ce plus clair ?

[ZenZiTone]

En fait SERVICE pourrait s'appeler CATÉGORIE. La COMMANDE se fait sur le PRODUIT qui fait partie d'un SERVICE (catégorie).
En gros le service : numérisation audio, le produit : cassette audio - > donc la COMMANDE se fait sur le produit cassette audio qui représente la prestation de numérisation K7 audio

C'est plus clair ainsi

Oui un produit (prestation) peut-être commandé qu'un seule fois par commande.
1 prestation / commande

Dans ce cas je pense que la cardinalité indiqué n'est pas correcte. En effet, si je comprend bien, la prestation peut apparaître dans une ou plusieurs commande. Alors que la commande ne concerne qu'une et une seule prestation. Il devrait donc y avoir un 0,n à un endroit (mais je ne sais plus dans quel sens ils sont notés en Merise )

[escartefigue]

Dans ce cas je pense que la cardinalité indiqué n'est pas correcte. En effet, si je comprend bien, la prestation peut apparaître dans une ou plusieurs commande. Alors que la commande ne concerne qu'une et une seule prestation. Il devrait donc y avoir un 0,n à un endroit (mais je ne sais plus dans quel sens ils sont notés en Merise )

Si une commande ne concerne qu'un et un seul produit, et qu'un produit peut être commandé plusieurs fois, alors la modélisation qui convient est
COMMANDE 1,1 --- concerner --- 0,n PRODUIT

J'ajoute que la plupart des entité-type n'ont pas d'identifiant, c'est un point important à corriger
Si vous pouviez afficher les types et longueurs des attributs, ce serait mieux

Pour les options, il est probable que les prix varient dans le temps, il faudrait donc faire intervenir une date
vous gérez des notions de commande et de prix, mais rien concernant la facturation et le paiement, est-ce normal ?

A quoi sert l'entité-type PARTENAIRE qui n'entre dans aucune relation ?

[digaburla]

En fonction de vos remarques, voici le fameux



Pour les types et longueurs des attributs, je suis en train de découvrir MySQL Benchmark qui me permet de compléter (entre autres) ces informations.

Je ne comprend pas votre proposition de rajouter "date" dans l’entité option.
Pour reprendre mon exemple précédent :
En gros le service : numérisation audio, le produit : cassette audio, l'option : une copie supplémentaire - > donc la COMMANDE se fait sur le produit cassette audio qui représente la prestation de numérisation K7 audio + une copie (option)

Effectivement il n'est pas question de facturation et de paiement. Je propose juste la prestation, une fois que j'ai déterminé le besoin du client, je renvoi vers un partenaire (mais là ce n'est plus une logique logiciel - c'est moi qui aiguille)

L'entité PARTENAIRE est autonome : j'enregistre ici tous mes partenaires

La logique globale vous parrait-elle cohérente ?

Encore merci pour vos retours constructifs et rapides

[escartefigue]

Je ne comprend pas votre proposition de rajouter "date" dans l’entité option.

Ce n'est pas du tout ce que je dis, je propose de mettre en relation l'entité-type OPTION avec une entité-type CALENDRIER de sorte à ce que la relation, appelons la Tarifer, possède comme attribut un prix
Le prix est une conséquence de la relation entre une option et une date. La table issue de cette relation aura pour identifiant, l'identifiant de l'option + la date

Pour le reste de votre nouveau diagramme, je reviendrai vers vous plus tard, je n'ai pas le temps ce soir, désolé

[digaburla]

Re,
Je comprend l'architecture que vous proposer, mais je n'en comprend pas la logique calendrier - date. Mais il me manque des connaissances dans ce domaine.
Bonne soirée

[escartefigue]

Bonjour,

Concernant la partie centrale, commande, produits et options, voici ce que vous pourriez faire

Au niveau conceptuel :
Pièce jointe 225613
Quelques remarques concernant ce MCD

• j'ai ajouté des identifiants primaires non fonctionnels dans chaque entité-type, avec la méthode la plus simple, à savoir des identifiants techniques attribués par le SGBD
  L'avantage est de garantir la stabilité de ces identifiants, ce qui est essentiel pour un id primaire, et aussi de favoriser la performance future de la base de données, grâce au type de données associé.
• pour les options, j'ai utilisé l'identification relative, matérialisée par les parenthèses autour des cardinalités (1,1). L'identification relative a également un impact positif sur les performances futures de la base de données. Elle se matérialisera dans le modèle logique par la présence de l'identifiant produit en tant que composante de l'identifiant primaire de l'option.
• l'entité-type date est ajoutée pour permettre de gérer des tarifs de produits et d'option à date, j'ai considéré que tout produit devait avoir un prix (d'où la cardinalité mini de 1) mais que certaines options pouvaient être gratuites (card mini de zéro). Corrigez si nécessaire bien sur.

Ce qui donne les tables suivantes :
Pièce jointe 225619
Remarquez que je n'ai pas demandé de générer de table pour l'entité-type CALENDRIER. En effet, la date n'est utile ici que pour contribuer à identifier les occurrences des relations tarif.
Notez aussi que la dérivation du MPD a positionné la date en 1er dans l'identification d'un tarif pour une option. L'ordre des colonnes identifiantes dans la table issue d'une association est aléatoire, c'est au DBA ou au concepteur de rectifier. Commencer par l'Id produit serait plus judicieux ici.

[digaburla]

Bonjour, votre expertise est poussé eu égard mes connaissances. Je continu donc a potasser notamment :"identifiants primaires non fonctionnels", et comprendre le lien avec la performance.
Pour situé plus précisément mon besoin : c'est une BDD destinée à un site internet dans lequel sera proposé des prestations de numérisation.
Pour gérer la modification tarifaires des Options et Produits, un attribut UPDATE ne suffit-il pas ?
Merci.

[escartefigue]

Bonjour, votre expertise est poussé eu égard mes connaissances. Je continu donc a potasser notamment :"identifiants primaires non fonctionnels", et comprendre le lien avec la performance.

Pour ce qui concerne la performance :
Un identifiant primaire de type "identity" attribué par la base de donnée, est une colonne de type integer (small, integer ou bigint), c'est à dire le format de donnée le plus optimal, qui permet le plus grand nombre de valeurs pour un minimum d'encombrement. Le type integer par exemple permet plus de 4 milliards de valeurs pour seulement 4 octets. Si vous utilisez un processeur 32 bits ou 64 bits, cet identifiant est traité en un seul cycle CPU. si vous utilisez un identifiant de type char ou varchar, vous allez très rapidement devoir effectuer plusieurs cycles CPU si vous avez de nombreuses entrées dans la table. Donc identifiant technique = économie disque + économie CPU + économie réseau
De plus, les types char, varchar et text sont sensibles à la collation, ce qui nécessite des opérations supplémentaires pour ranger les valeurs dans l'ordre souhaité. Et si vous avez la même valeur dans 2 tables différentes dont la collation est différente, le résultat des instructions comme ORDER BY, DISTINCT, GROUP BY sera différent

Pour ce qui concerne la stabilité de l'identifiant :
Un identifiant fonctionnel peut changer dans le temps, par exemple un nom mal orthographié qui est corrigé, un code attribué par une nomenclature qui change etc...
Or les identifiants primaires sont ceux qui sont propagés dans les tables via les contraintes d'intégrité, dans certains cas, ce sont des millions ou des milliards de lignes qui contiennent ces identifiants. Si une valeur d'identifiant primaire devait être changée, le coût de mise à jour (nombre de lignes impactées) peut facilement devenir excessif (plusieurs heures) voire, bloquer complètement la base de données. C'est pourquoi une identifiant primaire doit être asémantique, pour garantir sa stabilité.
Les identifiants fonctionnels (nom, numéro de sécurité sociale, code siren, numéro de compte bancaire...), doivent donc être des identifiants secondaires.

Pour situé plus précisément mon besoin : c'est une BDD destinée à un site internet dans lequel sera proposé des prestations de numérisation.
Pour gérer la modification tarifaires des Options et Produits, un attribut UPDATE ne suffit-il pas ?
Merci.

Bien sur, un update suffit, sauf si vous voulez pouvoir gérer des prix à date : conserver l'historique des prix, permettre d'anticiper un changement de tarif etc...

[digaburla]

Bonjour,
Voici mon MLD que j'ai fait évolué en fonction de vos commentaires.
J'ai rajouté des identifiants fonctionnels et primaires à chacune des mes entités
Je n'ai pas pris en compte la suggestion de calendrier pour le prix date, mais bien gardé en tête le concept.



Qu'en pensez-vous ?

J'ai également une question plus précise quant à l'organisation des Utilisateurs :
Il y a donc 2 catégories d'USER :

• Les clients (qui sont des particuliers) et qui peuvent passer commande
• Les partenaires (qui sont des collaborateurs qui auront un espace partenariat dédié) et qui peuvent passer commande (pour leur propre client)

Dois-je selon-vous créer une entité CLIENT spécifiques ou simplement l'entité PROFIL me permettra de distinguer les 2 ? Ce qui fait qu'au final je n'aurais qu'une seule table pour tous mes enregistrements USER ?

Merci

[escartefigue]

C'est pas mal du tout

Quelques remarques :
- l'id de la table option, s'appelle id_p, étrange peut être un copier-coller malheureux ?
- n'utilisez pas le type float pour des prix : float est fait pour stocker des valeurs très grandes au format puissance de 10, la valeur décimale est approximative vous auriez des risques de litiges avec les clients à cause des prix non fiables !
- il vaut mieux éviter le varchar pour les colonnes de petite taille, char(10) est préférable à varchar(10), car le varchar présente certains inconvénients techniques et comme il y a un attribut longueur qui prend déjà 2 octets, le gain pour les petites colonnes est marginal, voire pire c'est plus encombrant que du char (typiquement le varchar(1)).
- vous n'avez pas retenu ma proposition d'identification relative pour les options, c'est dommage d'un point de vue perfs, mais ce n'est bien sur pas bloquant
- pour les adresses, il y a matière à amélioration, d'une part je vous recommande d'utiliser la norme postale (de mémoire 6 lignes de 35 caractères, à vérifier) d'autre part vous pouvez éventuellement créer une entité-type adresse en relation avec l'entité-type client, ce qui vous permettra de gérer plusieurs adresses par client. C'est souvent utile, par exemple quand un client a une adresse postale, mais souhaite se faire livrer à une autre adresse.

Pour les clients et les partenaires, vu que les uns comme les autres peuvent passer des commandes, et que les attributs des uns et des autres sont très proches vous pouvez procéder par sous-type :
Créez une entité-type pour tout ce qui est commun aux 2, puis, si nécessaire, un sous-type client et un sous-type partenaire pour ce qui est particulier à l'un et l'autre. En ce cas les 3 entités-type partageront un identifiant commun

[digaburla]

Merci pour ces remarques et commentaires.

Pour en revenir au User et Client, la colonne me permettant de distinguer les 2 entités est Password. En effet seul les Partenaires pourront se loggé sur un espace pro. De plus, l'entité PROFILE permet de distinguer dans colonne ROLE : admin - utilisateur - partenaire - client.
D'un point de vue performance ( c'est votre spécialité me semble-t-il ?) cela ne suffit pas ?


De plus, je réfléchie à rajouter une table CONNECTE pour afficher en Administration les stats CONNEXION live.

Je peaufine tout cela, en prenant note de vos précédente remarque.

Un très bon week-end !

[escartefigue]

D'un point de vue performance ( c'est votre spécialité me semble-t-il ?) cela ne suffit pas ?

La performance se niche en bien des endroits
Même si en principe le MCD n'est pas sensé gérer la performance, dans les faits, certains choix sont cruciaux sur ce chapitre, essentiellement
- le respect des formes normales, pour éviter les redondances et les tables obèses : par exemple le cas des adresses, à sortir des clients et partenaires
- le choix du type de données, principalement celui des identifiants primaires
- l'utilisation de l'identification relative

Dans le cas d'un héritage, il est parfois difficile de choisir entre les différentes solutions, si effectivement la différence entre deux sous-types porte sur une seule colonne, on peut accepter de ne considérer qu'une seule entité-type et par voie de conséquence, tolérer une colonne nullable. Toutefois, identifier le type de personne au moyen du mot de passe n'est ni pratique ni évolutif.
Pourquoi pas une nouvelle entité-type "TYPE-PERSONNE" et une relation vers cette nouvelle ET.

[digaburla]

Bonjour,

Voici les modifications que j'ai apporté.
J'ai rajouté une entité "connected" pour afficher en admin les connexions live.

Pour ce qui est de votre proposition de l'entité "TYPE-PERSONNE", l'entité "PROFILE" rempli ce rôle grâce à l'attribut "role".

Enfin, vous me suggérez de créer une entité "ADRESSE" :

Je penses que vous proposez cela dans une logique ou un client peut-être partenaire ainsi il y aurait doublon. Mais ce n'est pas le cas. Un client ne peut pas être partenaire et inversement. Mais dans le cas ou ce n'est pas pour cette raison, l'entité ADRESSE doit-elle contenir que les adresses ou également les coordonnées téléphonique par exemple.

Encore merci pour vos remarques

[escartefigue]

J'ai rajouté une entité "connected" pour afficher en admin les connexions live.

Je ne comprends pas ce que vous voulez dire, désolé

Enfin, vous me suggérez de créer une entité "ADRESSE" :
Je penses que vous proposez cela dans une logique ou un client peut-être partenaire ainsi il y aurait doublon. Mais ce n'est pas le cas. Un client ne peut pas être partenaire et inversement. Mais dans le cas ou ce n'est pas pour cette raison, l'entité ADRESSE doit-elle contenir que les adresses ou également les coordonnées téléphonique par exemple.

Non, les raisons d'être de l'entité-type adresse sont
- un client peut ne pas avoir d'adresse
- un client peut avoir plusieurs adresses
- une adresse ne peut pas être identifiée par un identifiant client seul, il manque le type adresse
La première raison vous expose à des attributs nuls, la deuxième vous limite fonctionnellement à une seule adresse, la 3ème vous évite de répéter les valeurs ce qui enfreint les formes normales et vous conduirait à des tables dites "obèses".

Vous comprendrez aisément qu'il faut d'une part une entité-type ADRESSE accompagnée d'une entité-type TYPE_ADRESSE, et d'autre part, une entité-type TELEPHONE accompagnée de l'ET TYPE_TEL
Ce qui donne :
CLIENT 0,n --- Adresser --- 1,1 ADRESSE 1,1 --- TyperA -- 0,n TYPE_ADRESSE
et
CLIENT 0,n --- Telephoner --- 1,1 TELEPHONE 1,1 --- TyperT -- 0,n TYPE_TEL

Dans type adresse, vous pouvez avoir : adresse de livraison, de facturation, de correspondance, de comptabilité, du siège...
dans la relation Adresser vous pouvez éventuellement avoir des dates de début et de fin (exemple livraison à l'adresse 1 jusqu'en mars, puis vers l'adresse 2), et/ou des notions de priorité

De même, dans type téléphone, vous pouvez avoir fixe travail, portable travail, portable astreinte, fixe domicile...
Et également des relations avec dates et/ou priorité : appeler prioritairement sur tel téléphone, puis sur tel autre si pas de réponse...

Encore merci pour vos remarques

N'hésitez pas à voter +1 sur les réponses qui ont pu vous aider, ou -1 dans le cas contraire, en ce cas avec des explications svp, comprendre c'est progresser

[digaburla]

Je ne comprends pas ce que vous voulez dire, désolé

J'ai créé cette entité dans le but d'afficher dans un tableau les personnes qui sont connectées sur le site. Cela me permettra d'avoir quelques statistiques.
En gros, dans la partie admin de mon site j'aurais une page stats dans laquelle je verrais qui est en train de consulter mon site.

une adresse ne peut pas être identifiée par un identifiant client seul, il manque le type adresse

Du coup là c'est moi qui ne comprend pas.

Enfin pour les adresses et les téléphones, ce que vous proposez est effectivement optimal pour un service de e-commerce par exemple. Les exemple que vous donnez sont utiles mais pas dans le fonctionnement du site que je souhaite créer. En effet, l'application web ne servira qu' à mettre en relation mes partenaires avec mes clients. Je n'aurais donc pas à me préoccuper de la livraison (puisque le client se rendra directement chez mon partenaire) et pas de la facturation (le client paye direct le partenaire). Je ne suis qu'un lien :/

Cependant là ou je vous rejoins pour l'optimisation :
Je dois enregistrer l'adresse complète de mes partenaire : adresse - cp - numéro de tel... (toutes les coordonnées me sont utiles)

En revanche le client aura l'obligation de me donner (simplement) via un formulaire : son nom - son mail - et son code postal (tous les autres attributs seront optionnels)
Ainsi il y aura bien des attributs null, dont address,adress2,adress3, telephone, ville par exemple

Effectivement il me semble que seule l’entité ADRESSE (voir COORDONNÉE (on peut rajouter téléphone par exemple)) sera utilise dans mon cas.

Toutes vos réponses sont toutes bénéfiques et je vous en remercie

[escartefigue]

J'ai créé cette entité dans le but d'afficher dans un tableau les personnes qui sont connectées sur le site. Cela me permettra d'avoir quelques statistiques.
En gros, dans la partie admin de mon site j'aurais une page stats dans laquelle je verrais qui est en train de consulter mon site.

S'il s'agit de visualiser une situation à un instant "t" , alors, la réponse n'est pas dans le modèle de données, mais dans les traitements
Si par contre vous voulez conserver un trace de toutes les connexions avec des infos annexes, il faut effectivement intervenir au niveau MCD

Enfin pour les adresses et les téléphones, ce que vous proposez est effectivement optimal pour un service de e-commerce par exemple. Les exemple que vous donnez sont utiles mais pas dans le fonctionnement du site que je souhaite créer. En effet, l'application web ne servira qu' à mettre en relation mes partenaires avec mes clients. Je n'aurais donc pas à me préoccuper de la livraison (puisque le client se rendra directement chez mon partenaire) et pas de la facturation (le client paye direct le partenaire). Je ne suis qu'un lien :/

De deux choses l'une, soit vous n'avez pas du tout besoin d'adresse, auquel cas supprimez les attributs correspondants de votre modèle, soit vous avez besoin d'adresse(s), même unique, auquel cas il est préférable de modéliser comme je vous le propose. Le respect des formes normales (en tout cas des 3 premières) ne souffre aucune exception croyez moi, même si vous n'y voyez pas d'intérêt immédiat.

Cependant là ou je vous rejoins pour l'optimisation :
Je dois enregistrer l'adresse complète de mes partenaire : adresse - cp - numéro de tel... (toutes les coordonnées me sont utiles)
En revanche le client aura l'obligation de me donner (simplement) via un formulaire : son nom - son mail - et son code postal (tous les autres attributs seront optionnels)
Ainsi il y aura bien des attributs null, dont address,adress2,adress3, telephone, ville par exemple

Attention, le(s) téléphone(s) n'a rien à faire dans l'adresse., cf. mon pos précédent
Quand vous dites les autres attributs sont optionnels, pourquoi proposer une saisie d'adresse si elle est facultative et que vous ne l'utilisez pas ?

[escartefigue]

Toutes vos réponses sont toutes bénéfiques et je vous en remercie

C'est gentil, mais en ce cas utilisez le vote en bas des réponses pour enregistrer ce soutien