Discussion :

[salutagama]

Bonjour,
je poste ce message au sujet du diagramme de classes ci-contre, pour lequel j'ai plusieurs interrogations:
Les mentions PK FK et UK sont elles valides ou dois-je notifier les relations dans les classes d'une autres façon?

Les relations vous semblent-elles bien choisies?(type et nombres associés).

Les formulations choisies pour expliciter ces relations vous semblent-elles correctes ou inappropriées?

Si je souhaite expliquer à qqun l'utilité de tables comme Roles_privileges ou User_roles une fois en BDD:
est-ce valable de dire que ce sont des tables intermédiaires qui sont nécessaire dans le cadre de relation MANYTOMANY ENTRE Role et Privilege et entre User et Role.

Vovez-vous d'autres erreurs à rectifier???

Merci d'Avance Infiniment.
Bonne Journée ou bonne soirée selon quand vous lirez ce message.

[escartefigue]

La PK est représentée par les attributs soulignés alors que la FK est matérialisée par le lien entre les deux classes.

Par ailleurs, le modèle de données est mal conçu (attributs mal placés, de mauvais type...)

[salutagama]

La PK est représentée par les attributs soulignés alors que la FK est matérialisée par le lien entre les deux classes.

Par ailleurs, le modèle de données est mal conçu (attributs mal placés, de mauvais type...)

Merci pour ta réponse.

Donc j'enlève PK et je souligne la clé primaire, j'enlève FK puisque les relations font le travail.

Le type est choisi par l'entreprise lorsqu'il y a un choix entre varchar et entier (par ex pour le siret l'entreprise préfère le varchar au int.
Attributs mal placés, lesquels et comment devraient-ils être mieux?

[escartefigue]

Prenons l'exemple de la classe CUSTOMER

Choisir du varchar pour le SIRET est une erreur : le SIRET c'est toujours 14 caractères, donc il n'y aura jamais de gain avec du varchar et au contraire, il faut ajouter les deux octets de longueur, soit une longueur effective de 16 ! Sans compter que le varchar pénalise certaines opérations (order by, group by, partition by...).
Bref quand la longueur ne change pas ou qu'elle est modeste (inférieure à 20 caractères environ), le CHAR est préférable au varchar.

Positionner l'adresse et le téléphone dans cette classe implique que chaque client ne possède qu'une et une seule adresse et un et un seul téléphone.
Ne devez-vous jamais (et ne devrez jamais à l'avenir) connaitre l'adresse de livraison, de facturation, du siège, du service comptable ou autre ?
Ne devez-vous jamais connaitre le téléphone de tel service, de tel contact ?...
Si un et un seul téléphone suffit et qu'une et une seule adresse suffit, alors on peut placer ces infos dans CUSTOMER, mais il faut a minima utiliser un typage et une longueur adaptés.

Les adresses sont codifiées par la poste. Ce sont 6 lignes de 38 caractères, la dernière pour la ville et le code postal. Et il ne faut pas répéter la ville à chaque client, sinon c'est un risque d'erreur (orthographes différentes pour une même ville) et c'est lourd en cas de changement de nom de ville (ce qui arrive assez souvent pour les toutes petites communes qui fusionnent).
Un seul attribut de type varchar(150) ne convient donc pas du tout.

La présence du fax ici implique que le fax est obligatoire et unique pour tous les clients, or, il est très probable que certains clients n'aient pas de fax, d'autres plusieurs (fax du service comptable, de l'accueil, du service contentieux...)
De plus, pourquoi définir le fax sur 40 caractères alors que le téléphone n'en comporte que 15, c'est incohérent !

Voici un exemple de modélisation pour la gestion des média (téléphone, fax...) et des adresses
Au format Merise



Et au format UML



Pourquoi positionner des données de géolocalisation au niveau du client .
Si vraiment ces données vous intéressent, il faut les positionner au niveau de l'adresse et utiliser les types de données spatiales (geography ou geometry selon l'usage)

L'attribut "motcles", au pluriel donc, est très suspect. S'il s'agit d'une liste de mots clefs stockées dans un attribut unique, alors c'est exactement ce qu'il ne faut jamais faire : c'est un viol de la première forme normale qui crée des redondances potentielles, compromet l'intégrité des données, initerdit l'indexation des recherches...

La notion de TVA n'a rien à faire dans le client, ce devrait être une classe d'entité à part, en lien avec le client

La notion de prospect est probablement une redondance avec l'existence ou pas d'une commande : si commande il y a, alors c'est un client, sinon, c'est un prospect
À confirmer dans votre contexte.

Même démarche à adopter sur les autres classes d'entité : il ne faut avoir dans une même classe que les attributs qui dépendent fonctionnellement de l'identifiant et choisir des types de données adaptés.

[salutagama]

Rebonjour,
j'ai modifié les VARCHAR en CHAR lorsque le nombre de caractères était connu ou faible.
Pour le téléphone, le faxe et l'adresse l'entreprise étant une entreprise de connexion elle n'a besoin que d'un exemplaire de chaque(en terme de nécessite dans ce qu'elle utilise en interne).

J'ai décomposé l'adresse et est extrait certaines données d'autres tables en en créant des nouvelles.

L'attribut "motclés" sert à être envoyés à une API qui ensuite va renvoyer les offres correspondantes à notre application interne qui s'occupe de l'envoie comme de la réception.

Le numéro de TVA du client correspond au numéro de TVA intracommunautaire est-il vraiment utile d'en créer une table à part?
Pour ce qui est du prospect l'entreprise préfère le conserve de cette manière.

[escartefigue]

Bonjour,

Tout d'abord, il ne faut utiliser le bouton "répondre avec citation" quand on répond au message qui précède immédiatement, ça charge inutilement le fil de discussion.
Utilisez de préférence le bouton "répondre", j'ai modifié votre réponse précédente pour supprimer la citation inutile .

Ensuite, il ne faut pas mélanger des termes anglais (customer, created, offer...) et français (abonnement_en_cours, mots_clefs, plateforme...).
Soit votre projet est international, auquel cas l'anglais s'impose, soit il est national, auquel cas la langue nationale ou locale s'impose.
Par ailleurs, pour éviter qu'un nom de table ou de colonne percute avec un mot réservé SQL, j'utilise à titre privé un préfixe différent associé à chaque classe.
Par exemple dans le modèle que j'ai fourni dans ma réponse précédente, la classe des villes est VI_ville, celle des clients et CL_client, etc. Il en va de même pour les attributs respectifs (VI_ident, VI_insee, CL_ident, CL_nom...)
Ainsi, plus de risque de percussion avec les mots réservés SQL et les analyses d'impact sont facilitées.

Je pensais que l'attribut TVA positionné dans le client était le code correspondant au taux de TVA, puisqu'il s'agit du code intracommunautaire, alors il a toute sa place ici .

L'attribut "mot_clefs" doit impérativement être supprimé et remplacé par une classe à part en lien avec le client :
[CL_CLIENT] 0,n --- utiliser --- 0,n[MC_MOT_CLEF]
ainsi on évite les éventuels marqueurs "null" pour les clients n'ayant aucun mot-clef et plus encore, on évite de déroger à la 1re forme normale en n'ayant que des attributs atomiques. Une colonne fourre-tout multi-attributs est une hérésie de modélisation qui interdit toute indexation, crée des redondances, des problèmes d'intégrité...

[salutagama]

Bonjour effectivement je vais éviter de répondre ave citation un maximum.

Ok Je vais revoir pour ce qui est de l'attribut mots-clés, je compte également enlever les annotation FK et UK et rajouter le fait que l'ensemble des attributs sont privées dans le projet (ajout de "-" avant les attributs).

Que penses-tu des tables y'en-a-t-il en trop ou certaines devraient-elles divisées?

Que penses-tu des relations entre les tables (type de relation et choix des nombres associés à celles-ci à leurs extrémités)?

[escartefigue]

Le nombre de tables et les cardinalités des relations sont une conséquence des règles de gestion, rien d'autre.
Sans règles de gestion clairement exprimées, on ne peut pas se prononcer sur la pertinence de celles-ci.

Regardez dans la section schéma ce sujet qui explique comment les règles de gestion impactent le MCD et par conséquent les tables et les cardinalités :

https://www.developpez.net/forums/d2.../#post11812511