Discussion :

[jeromep13]

Bonjour,

Je suis plutôt débutant sur les SGBD.
J'ai commencé à développer une application Client/Serveur dont le but est la gestion d'une (toute) petite entreprise.

Cette entreprise a des fournisseurs, des clients professionnels (sociétés) et particuliers. Rien de particulier en sorte.

Mais je voulais intégrer les points suivants:
- les clients (pro ou particuliers) pourront avoir plusieurs adresses postales (domicile, adresses de livraison, adresses de facturation,..)
- on peut avoir plusieurs contacts physiques au sein d'une société (acheteur, chargé d'affaires,...), qui eux même peuvent être des clients à titre personnel.
- une société peut être un client et un fournisseur à la fois.
Le but étant de gérer ensuite les devis, les commandes, les devis, les factures, ...

J'ai donc réalisé l'analyse suivante pour déjà cette partie, mais avant d'aller plus loin je souhaiterai avoir vos avis car je ne suis pas sûr de mon coup d'autant que je n'ai pas vu de décomposition de la sorte dans les différents liens que j'ai pus suivre.
Où:
- Entité est un numéro représentant soit une société soit un particulier
- Société, c'est une société (je n'ai pas mis tous les champs encore)
- personne, c'est une personne physique qui peut être un client à titre privé ou un contact au sein d'une société (ou les 2)
- contact_pro, représente des personnes au sein d'une société
- adresse est la liste de toutes les adresses des entités, donc des personnes et des sociétés (pour info je compte faire pareil pour les téléphones)



Est-ce que je suis complétement à côté de la plaque ou bien je peux poursuivre dans ce sens avec éventuellement des recommandations ?
Merci pour vos réponses

Jerome

[fsmrel]

Bonsoir Jérôme,


C’est pas mal pour un débutant.

Vous évoquez les fournisseurs, mais manifestement vous vous cantonnez à modéliser les clients. En ce qui concerne ces derniers, votre diagramme paraît correct. Je vous engage toutefois à utiliser un outil de modélisation plus précis que le vôtre (quel est-il ?), car le diagramme est muet en ce qui concerne les cardinalités. Je vous conseille MySQL Workbench (en passant, vous retrouverez au paragraphe 6 de cet article les concepts de tiers (client, fournisseur), personne physique adresse).

Question : Quel rôle joue l’attribut id_categorie de la table entite ?

Remarque : il faudrait mettre en œuvre une table TYPE_ADRESSE (domiciliation, livraison, facturation, etc.) référencée par la table ADRESSE.

[jeromep13]

Bonsoir Jérôme,


C’est pas mal pour un débutant.

Vous évoquez les fournisseurs, mais manifestement vous vous cantonnez à modéliser les clients. En ce qui concerne ces derniers, votre diagramme paraît correct. Je vous engage toutefois à utiliser un outil de modélisation plus précis que le vôtre (quel est-il ?), car le diagramme est muet en ce qui concerne les cardinalités. Je vous conseille MySQL Workbench (en passant, vous retrouverez au paragraphe 6 de cet article les concepts de tiers (client, fournisseur), personne physique adresse).

Question : Quel rôle joue l’attribut id_categorie de la table entite ?

Remarque : il faudrait mettre en œuvre une table TYPE_ADRESSE (domiciliation, livraison, facturation, etc.) référencée par la table ADRESSE.

Bonjour,

A n'avoir qu'une réponse à ma question, je suis content que ce soit la vôtre. Merci.
J'utilise l'outil fourni dans Postgresql Maestro Pro et effectivement il n'indique pas les cardinalités. Je viens de lire le paragraphe 6, et c'est ressemblant à ce que je veux mettre en oeuvre.

L'attribut id_catégorie de la table entité indique seulement si l'entité est de type "société" ou "personne physique" via la table "categorie_entité".
Ensuite soit je complète la table "société", ou "personne".

Une "personne" pouvant être :
- un client particulier rattaché à aucune société,
- ou un contact dans une "société" (fournisseur ou client) sans qu'à titre personnel il soit un client -> la table contact_pro fait le lien
- ou à la fois un contact dans une société (peu importe s'il s'agit d'une société cliente ou fournisseur), et qu'à titre personnel il soit également un client.

Chaque "entité" ("société" ou "personne physique") peut donc avoir une multitude d'adresses, de téléphones, d'emails, (voir schéma ci-joint). Chacun de ces éléments n'appartement qu'à une seule entité.

En fait une "société" pourra être un client, un fournisseur, un fabricant, ou une combinaison de ces possibilités. Je l'ai matérialisé par des booléens dans société.
Je comptais donc par la suite créer des tables "fournisseur", "client_pro" et éventuellement "fabricant", afin d'ajouter en fonction des cas, les champs propres à chacune de ces catégories.
Comme ce qui est fait par "client" (=mon "client_pro) et "fournisseur" rattachés à "tiers" (=mon "société") dans votre exemple chapitre 6.

Pour ce qui est "type adresse" effectivement il le faut, mais je verrais plus tard s'il doit être une clé étrangère vers une autre table répertoriant les possibilités (domiciliation, livraison, facturation,...), ou un simple champ de saisie permettant d'indiquer de quel type il s'agit, pour pouvoir écrire directement "domiciliation et facturation et livraison" par exemple.

Est-ce plus clair et pensez-vous que ce soit cohérent pour poursuivre dans ce sens, car ça diffère de votre schéma au 6.3 ?




Puisque je vous ai , je débute ma réflexion sur la modélisation de mes produits.
En effet, ils peuvent être de simples produits ou des kits composés d'autres produits référencés dans la même table.

Par ex. très (trop) simplifié:
Table Produits
id_P1, Produit1
id_P2, Produit2
id_P3, Produit3
id_P4, Produit4
id_P5, Kit n°1
id_P6, Kit n°2
Avec id_P =pk


Table detail_kit
id_P5, id_P1, qté=1,....
id_P5, id_P4, qté=5,....
id_P6, id_P2, qté=3,...
id_P6, id_P3, qté=2,...
id_P6, id_P5, qté=1,... //donc un kit composé lui même d'un autre kit pour compliquer la chose lol
avec (id_Px,id_Py) = pk, id_Px= fk, id_Py= fk

Afin de m'éviter de réinventer la poudre, car ce cas est peut-être déjà "typique" pour des experts en SGBD, y-a-t-il une modélisation ou une base de modélisation déjà préétablie ?

Merci pour vos conseils éclairés.

Jérôme

[fsmrel]

Bonsoir Jérôme,

L'attribut id_catégorie de la table entité indique seulement si l'entité est de type "société" ou "personne physique" via la table "categorie_entité".

A la lecture du paragraphe 6 de l’article, vous avez pu observer que je n’utilise pas ce genre d’attribut « indicateur ». En effet il s’agit d’une redondance et, par distraction, précipitation ou autre, on a vite fait de valoriser id_catégorie à "personne physique" tandis qu’on valorise par ailleurs la table SOCIETE. La redondance est un des principaux ennemis des tables à l’occasion de leur mise à jour...

En contrepartie, au stade SQL, on définit des vues pour que l’utilisateur accède aux personnes et aux sociétés. Exemple des clients, pour reprendre le paragraphe 6 :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE VIEW CLIENTV (NoSiret, RaisonSociale, CondTarifaire)
AS
    SELECT NoSiret, RaisonSociale, CondTarifaire
    FROM   TIERS AS x JOIN CLIENT AS y ON x.PersonneId = y. PersonneId
;

ou un simple champ de saisie permettant d'indiquer de quel type il s'agit, pour pouvoir écrire directement "domiciliation et facturation et livraison".

D’expérience, c’est « casse-gueule », je ne peux que vous recommander la mise en œuvre de la table TYPE_ADRESSE.

Afin de m'éviter de réinventer la poudre

Vous pouvez déjà consulter le paragraphe 7 de l’article, où l’on s’intéresse à la composition des ailes d’avion en rivets, via les composants tels que le longeron, l’aileron, etc. Pour compter les rivets, voyez le post ici. A l’occasion, jetez un coup d’œil sur cet autre post. La discussion traitant de la classification botanique pourrait aussi vous intéresser (en passant, j’aime beaucoup le résultat obtenu.)

[jeromep13]

Bonsoir fsmrel,

Bonsoir Jérôme,
A la lecture du paragraphe 6 de l’article, vous avez pu observer que je n’utilise pas ce genre d’attribut « indicateur ». En effet il s’agit d’une redondance et, par distraction, précipitation ou autre, on a vite fait de valoriser id_catégorie à "personne physique" tandis qu’on valorise par ailleurs la table SOCIETE. La redondance est un des principaux ennemis des tables à l’occasion de leur mise à jour...

En contrepartie, au stade SQL, on définit des vues pour que l’utilisateur accède aux personnes et aux sociétés. Exemple des clients, pour reprendre le paragraphe 6 :

Effectivement je n'y avais pas pensé, et je croyais me simplifier la chose pour mes tris, quand je voulais agir sur les pros ou les particuliers.
J'avais envisagé de gérer en automatique le remplissage du id_categorie au niveau de l'appli en fonction d'un clic sur "nouvelle personne" ou "nouvelle société".

D’expérience, c’est « casse-gueule », je ne peux que vous recommander la mise en œuvre de la table TYPE_ADRESSE.

Je pensais bien aussi. Mais en utilisant une table TYPE_ADRESSE, je vais rajouter un champ commentaire à la table ADRESSE pour rajouter une précision dans le cas de plusieurs adresses de même type.
Ce sera le même principe pour les tables "téléphone", et "email"

Vous pouvez déjà consulter le paragraphe 7 de l’article, où l’on s’intéresse à la composition des ailes d’avion en rivets, via les composants tels que le longeron, l’aileron, etc. Pour compter les rivets, voyez le post ici. A l’occasion, jetez un coup d’œil sur cet autre post. La discussion traitant de la classification botanique pourrait aussi vous intéresser (en passant, j’aime beaucoup le résultat obtenu.)

Je vais approfondir ça car a priori c'est exactement ce que je cherchais, et avec les exemples de requêtes SQL, c'est encore mieux. Merci beaucoup.

Jérôme

[fsmrel]

Bonsoir Jérôme,


Donc pour le moment, tout a l'air d'aller, bonne pêche aux rivets et longerons !