Discussion :

[MDA_1602]

Bonjour à Tous

Concernant l'entité faible forte je l'ai vu sur ce forum
Les explications sont succintes

https://sqlpro.developpez.com/cours/...ees-mpd#LV-A-2

Quant à la possibilité de supprimer un client en effet cela doit être interdit et c'est le cas dans mon entreprise dans certains systèmes
Un client doit être désactivé et non supprimé afin de conserver l'historique .

FSMRel en effet j'ai un peu de mal à comprendre ces nouveaux concepts mais je ne perds pas espoir de finir par comprendre
Merci pour votre aide

[escartefigue]

L'envie d'apprendre est la meilleure façon d'y arriver, donc tout va bien :cool:

Il y a une exception à la règle n°1 formulée dans le lien (Tuto de SQLPro) :

Règle n°1 : toute entité doit être représentée par une table.

Cette règle n'est pas vérifiée quand on modélise une entité-type dite "fictive" dont la vocation n'est justement pas de devenir une table, mais de faire participer son identifiant à une table associative, le plus souvent dans une relation de dimension 3 ou plus.
C'est fréquent avec l'entité-type date.

[fsmrel]

Bonjour,

MDA, à propos de l’article de Fred sur la méthode Merise, merci pour le lien vers le paragraphe V-A-2. Relation de type 1:n (maître et esclave).
La relation maître/esclave, est donc due à Fred, qui est un bon camarade, que je considère comme faisant autorité en matière de SQL Server, mais certainement pas en ce qui concerne Merise. Certes, il connaît le sujet, mais il est approximatif quant à la terminologie. Dans son article, s’il avait fait référence à Hubert Tardieu qu’il cite (cf. le paragraphe I de l’article de Fred), il aurait appris que sa définition de l’entité n’est pas valide.

Référence :

La méthode Merise, tome 1 : Principes et outils de R. Colletti, A. Rochfeld et H. Tardieu (5e impression, juin 1991)
Collection : Ingénierie des systèmes d'information

Je cite TRC (Tardieu, Rochfeld, Colletti) (page 135) :

« Un individu (ou entité) est un objet abstrait ou concret dans l’univers du discours. »

Une entité n’est donc pas un type ! Je cite à nouveau TRC (page 136) :

« Un type est une classe d’objets similaires. »

« Un type d’individu ou individu-type est une classe d’individus qui ont en commun un ensemble de propriétés. »

Fermez le ban.

Pour aller plus loin, lisez l’ouvrage de Paprick, Modélisation conceptuelle de données, auteur du remarquable Looping. Pour sa part, Paprick n’utilise pas les termes Individu-type ou Entité-type, mais le terme particulièrement pertinent Classe d’entités, ce qui ne pose évidemment aucun problème (TRC utilisant aussi le terme de classe, voyez ci-dessus).

[MDA_1602]

Je me suis basée entre autre sur ce lien pour comprendre les Entités et les cardinalités, s'il s'avère que certaines informations sont incorrectes je n'ai pas le recul nécessaire pour en juger.
Je vais en effet commander le livre de Paprick d'autant qu'il fait une belle action merci à lui !


Concernant la table client je vais encore revenir dessus au risque de vous faire tourner en bourrique, j'ai malheureusement le défaut de ne pas lâcher tant que je n'ai pas compris
donc si l'impatience vous gagne n'hésitez pas à me le dire je cesserais mes questions

Un client est déclaré payeur s'il existe une association réflexive d'un client vers ce client.
Voici un exemple de contenu de la table des clients (dans laquelle j'ai ajouté une colonne nom, pour faciliter la lecture)

Dans cet exemple, le client "Ducran, Lapoigne et Cie" payera les factures pour lui même et pour le client "Gaston SARL", et le client "Prunelle" payera lui même ses factures.
Quand on devra facturer un chantier dont le donneur d'ordre est Gaston SARL, on ira rechercher son client payeur dans la table client, et comme ce client payeur est "Ducran, Lapoigne et Cie", le traitement de facturation émettra la facture à ce nom et l'enverra à l'adresse de facturation associée à ce client payeur. Bien entendu, la facture mentionnera aussi la commande du client "Gaston SARL" justifiant cette facture.

Il est donc question d'associer un Donneur d'ordre à un payeur > comment je fais si je ne connais pas le client payeur au moment de la création du Donneur d'ordre ?
En pratique on créé le client DO, il n'est indiqué à aucun endroit que c'est un payeur. Dans la base client on sait juste que c'est un client société, particulier ou adresse chantier.
Il est taggé payeur lorsqu'il y a eu facturation.


Un donneur d'ordre peut être associé à un ou plusieurs payeurs > est ce possible dans le cas de l'association réflexive ?
exemple : une commune X pourra avoir différents payeurs suivant le service qui paiera. Donc une commune (donneur d'ordre créé en société publique) sera recréé en payeur avec autant de services payeur qu'il existe.
Donc la commune X ID 100 sera associés à ID101, ID 102, ID103

Tu peux avoir un cas de figure où le client te demande pour cette commande particulière de facturer à un Payeur Y alors même que le donneur d'ordre est associé à un autre payeur et que cette association existante peut servir à un autre cas de figure
Tu dois être en capacité de maintenir des associations différentes suivant la demande du client
Il est possible que la cardinalité sur l'association réflexive ne soit pas la bonne côté payeur


Je pense qu'il faut tenir comptes de deux points :
Est ce que je peux l'utiliser en tant que payeur sur ma commande ? cela dépendra par exemple de son statut d'immatriculation pour une société
Est ce qu'il est vraiment payeur ? à savoir a t-on des factures pour ce client
Je me pose la question de créer une Entité Rôle associé au client

Entité Rôle _1-n____ associer_1-n___ Clients
Rôle Donneur d'ordre > contrainte doit être créé dans un CRM
Rôle Payeur > contrainte doit être immatriculée
Rôle adresse chantier > contrainte ne peut être ni payeur ni Donneur d'ordre

Me taper pas dessus c'est juste une réfléxion

[fsmrel]

Concernant la table client je vais encore revenir dessus au risque de vous faire tourner en bourrique, j'ai malheureusement le défaut de ne pas lâcher tant que je n'ai pas compris
donc si l'impatience vous gagne n'hésitez pas à me le dire je cesserais mes questions

Vous avez pu constater que notre patience n'a guère de limites Vous vous accrochez et c'est bien !

Personnellement je n'ai pas encore examiné votre MCD et les règles de gestion qui l'accompagnent
Cela dit si vous pouviez nous fournir une V2 de ces choses là, alors je lirai.

Me taper pas dessus c'est juste une réfléxion

Ma maman m'a appris qu'on ne tapait jamais sur une dame, même avec une rose

A vous revoir, gente MDA

[MDA_1602]

Bonjour à tous

J'ai refais le MCD en espérant qu'il n'y ait pas trop de bêtises de faites
Bonne lecture !!!

Ci-dessous le process et les règles de gestion
Une société de prestation de service réalise des contrôles règlementaires comme par exemple une vérification de conformité d’une installation électrique, contrôle d’un ascenseur, diagnostic amiante qui sont répertoriés dans un catalogue de missions
Des techniciens sont affectés aux missions afin de réaliser des interventions sur le site en question.

EDIT Un contact est un employé d'une société, ou un particulier.
Si c'est un contact d'une société (Personne morale) il sera créé dans la table contact et rattaché au compte client créé en société à laquelle il appartient.
Un contact peut être une personne physique et donc rattaché au client particulier
Le contact est important car c'est à son adresse mail que le rapport pourrait être envoyé
Il existe différents type de contacts : ceux pour la production, ceux pour la facturation (en cas de dématérialisation des factures)...



Un client à l’origine de la demande d’un contrôle de conformité électrique sera ce que l’on appelle le donneur d’ordre =DO
Ce client va indiquer qui va payer la facture (lieu payeur =LP)
Il indiquera où doit avoir lieu le contrôle électrique (Site d’intervention car c’est là qu’intervient le technicien =SI)
Le client va donc être identifié sous différents rôles qui sont : DO, LP, SI
Les rôles doivent être renseignés dans l’offre commercial (=commande) ou dans le contrat.
Dans l’offre Commerciale ou le contrat on retrouvera les missions à réaliser, les tarifs, le LP, DO, SI, les conditions générales de ventes…
Une offre commerciale est envoyée au client, une fois signée on peut alors mettre en production c'est à dire programmer la prestation et planifier les interventions avec le client.
Une fois l’intervention réalisée un rapport est envoyé au client, on peut alors déclencher la facturation.

Clients
R001_CL : Un client peut être une société (Publique ou privé) ou un particulier
R002_CL : Une société à un siège social
R003_CL : Une société peut avoir 0 ou plusieurs établissements secondaires
R003_CL : Un client peut être uniquement Donneur d’ordre
R004_CL : Un client peut être uniquement payeur
R004_CL : Un client peut être à la fois payeur et donneur d’ordre
R005_CL : Un client DO peut être associé à plusieurs payeurs
R006_CL : Un client payeur peut être associés à plusieurs DO
R007_CL : Un client société ne peut être payeur s’il n’est pas immatriculé EDIT
R008_CL : Un client sans siren est en statut 'en cours d'immatriculation' (Siren vide + siret vide) > non payeur
R009_CL : Un client sans siret est en statut 'sans immatriculation' (Siren non vide + siret vide) > Payeur
R010_CL : Un client avec siren + siret renseigné est en statut 'Immatriculé' (Siren non vide+ siret non vide) > Payeur


Adresse
R001_AD : Une adresse peut situer plusieurs clients
R001_AD : Une adresse peut typer un ou plusieurs types d’adresse

Type adresse
R001_TA : un type d’adresse peut typer une ou plusieurs adresses

Contact
R001_CO : Un contact représente à un ou plusieurs clients
R002_CO : Un client est représenté par un ou plusieurs contacts

Offre commerciale
R001_OF : Un contact demande une ou plusieurs offres commerciales
R002_OF : Une Offre Comm. est demandée par un seul contact
R003_OF : Un client peut signer une ou plusieurs Offre Comm.
R004_OF : Une Offre Comm. est signée par un seul client
R005_OF : Une Offre Comm signé devient un contrat
R006_OF : Une offre Comm est envoyé par le prestataire de service
R007_OF : Une offre commerciale est signé par le contact au nom de la société dont il dépend


Contrat
R001_CT : Un contrat signé est rattaché à 0 ou une offre commerciale
R002_CT : Un contrat est signé par un seul client
R003_CT : Un client peut signer un ou plusieurs contrats
R004_CT : Le contrat programme une ou plusieurs prestations

La prestation
R001_PR : Une prestation est programmée par un seul contrat
R002_PR : Une prestation est programmée par année et mois
R003_PR : Une prestation est produite par une ou plusieurs interventions
R004_PR : Une prestation répertorie une ou plusieurs missions

Mission
R001_MI : Une mission est répertoriée dans une ou plusieurs prestations
R002_MI : Une mission requiert une ou plusieurs qualifications
R003_MI : Une mission porte sur 0 ou plusieurs matériels

Matériel
R001_MA : Un matériel est porté sur une ou plusieurs missions

Qualification
R001_QA : une ou plusieurs qualifications sont requises pour une ou plusieurs missions
R002_QA : une ou plusieurs qualifications sont détenus par un ou plusieurs Employés

Employé
R001_EM : Un ou plusieurs employés détiennent une ou plusieurs qualifications

Intervention
R001_IN : Une intervention produit une seule prestation
R002_IN : Une intervention est réalisée sur un seul site
R003_IN : Une intervention est affectée à un ou plusieurs techniciens
R004_IN : Une intervention doit être planifiée à une date validée par le client
R005_IN : Une intervention peut faire l’objet d’un ou plusieurs RDV

Planification
R001_PL : Un RDV concerne une intervention ou plusieurs interventions

Rapport
R001_RA : Un client peut recevoir un ou plusieurs rapports
R002_RA : Un rapport fait l’objet d’une seule facturation

Facturation
R001_FA : Un client peut recevoir une ou plusieurs factures
Je ne l’ai pas modélisé cette Entité va dépendre de différents paramètres

Pièce jointe 648566Pièce jointe 648571

[fsmrel]

Bonsoir MDA et Escartefigue, en ce dernier jour de l’année !

MDA, dans votre MCD, vous avez écrit au pluriel le nom de certaines entités-types (par exemple "Clients").
Par référence à TRC, Nanci, Paprick et Cie, je rappelle qu’une entité-type est une classe et non pas un ensemble de classes. Le nom d’une entité-type est donc à écrire au singulier.

Merci de fournir votre définition du terme "Contact". Je suppose qu’il s’agit d’un employé de la société de prestation de service, du genre démarcheur commercial, mais toute précision rigoureuse est bonne à prendre...

Un contact demande une ou plusieurs offres commerciales

A priori le verbe demander serait à remplacer par celui de proposer.


Une précision concernant la règle de gestion suivante :

R007_CL : Un client société ne peut être payeur s’il n’est pas immatriculé.

Si on vous suit dans votre exemple :

Une société immatriculée (Attribut Siren renseigné)

Alors du fait de l’obligation du SIREN, on est en droit d’affirmer qu’un établissement secondaire (dépendant donc de son siège social), et n’ayant donc qu’un SIRET ne peut pas être payeur. Mieux préciser la règle de gestion correspondante.

Par ailleurs, au vu de la règle de gestion R003_CL, on est en droit de penser que les établissements secondaires sont parties prenantes dans la modélisation. Si c’est le cas (cf. votre MCD précédent), le MCD doit prendre à nouveau cela en compte, sinon une règle de gestion doit préciser que ces établissements sont hors sujet (autrement dit, ils ne peuvent donc pas être donneurs d’ordres).

Je note que dans le MCD précédent en question, un siège social a au moins un établissement secondaire. Comment positionnez-vous les entreprises individuelles dans ce contexte ?

je suis conscient que la modélisation des clients n’est pas très simple dans le cas général, mais devient quelque chose de délicat dans votre contexte. Néanmoins la rigueur et l’exhaustivité sont de mise, pas de poussière sous le tapis...

=> Complétez les règles de gestion, ne fournissez pas pour le moment de MCD, on y reviendra quand il y aura consensus du trio MDA, escartefigue, fsmrel (et autres si affinité). Après un bon coup de tampon sur ces fichues règles, alors alea jacta erunt.

[MDA_1602]

Bonsoir à tous

FSM j'ai déjà corrigé certaines choses sur mon MCD notamment les entités au pluriel, l'ajout des ets secondaires et principal
Je te laisse re vérifier à l'occasion

Je vais corriger les règles et apporter les précisions nécessaire


Une très bonne année à tous

[escartefigue]

Bonjour MDA, bonjour François et meilleurs voeux à tous

EDIT Un contact est un employé d'une société, ou un particulier.
Si c'est un contact d'une société (Personne morale) il sera créé dans la table contact et rattaché au compte client créé en société à laquelle il appartient.
Un contact peut être une personne physique et donc rattaché au client particulier
Le contact est important car c'est à son adresse mail que le rapport pourrait être envoyé
Il existe différents type de contacts : ceux pour la production, ceux pour la facturation (en cas de dématérialisation des factures)...

D'après le MCD c'est le CONTACT qui envoie la proposition commerciale, je suppose que c'est plutôt votre société de prestation de service qui émet cette proposition et que c'est le contact qui la signe pour le client qu'il représente.
À préciser dans les règles de gestion
Toujours d'après le MCD c'est le contrat qui signe l'offre commerciale , d'ailleurs, il me semble que nous avions convenu précédemment qu'on pouvait se contenter d'un statut pour distinguer une offre non signée d'un contrat.
Aussi, d'après votre MCD, un client peut tout à fait signer un contrat qui concerne une offre pour un autre client (mais nous verrons ce genre de points plus tard )
Enfin, attention au choix des verbes dans les règles de gestion, plutôt que :

R001_CO : Un contact appartient à un ou plusieurs clients
R002_CO : Un client peut appartenir à un ou plusieurs contacts

Il est préférable de dire

R001_CO : Un contact représente un ou plusieurs clients
R002_CO : Un client est représenté par un ou plusieurs contacts

Un client à l’origine de la demande d’un contrôle de conformité électrique sera ce que l’on appelle le donneur d’ordre =DO
Ce client va indiquer qui va payer la facture (lieu payeur =LP)
Il indiquera où doit avoir lieu le contrôle électrique (Site d’intervention car c’est là qu’intervient le technicien =SI)
Le client va donc être identifié sous différents rôles qui sont : DO, LP, SI
Les rôles doivent être renseignés dans l’offre commercial (=commande) ou dans le contrat.
Dans l’offre Commerciale ou le contrat on retrouvera les missions à réaliser, les tarifs, le LP, DO, SI, les conditions générales de ventes…
Une offre commerciale est envoyée au client, une fois signée on peut alors mettre en production c'est à dire programmer la prestation et planifier les interventions avec le client.
Une fois l’intervention réalisée un rapport est envoyé au client, on peut alors déclencher la facturation.

Nous avions vu précédemment (réponse n°15 du 20-12) qu'un contrat pouvait comporter une à plusieurs prestations (contrôle électrique, de gaz, d'un ascenseur...), chaque prestation pouvant concerner une adresse différente et une à plusieurs interventions. D'après votre dernier modèle, c'est l'intervention qui est liée à l'adresse et non plus la prestation, ça signifie que concrètement, le contrôle électrique pour un même contrat peut être fait une première fois à Melun et une autre fois à La Rochelle. À préciser dans les règles de gestion.



À propos de ces règles :

Clients
R007_CL : Un client société ne peut être payeur s’il n’est pas immatriculé EDIT
R008_CL : Un client sans siren est en statut 'en cours d'immatriculation' (Siren vide + siret vide) > non payeur
R009_CL : Un client sans siret est en statut 'sans d'immatriculation' (Siren non vide + siret vide) > Payeur
R010_CL : Un client avec siren + siret renseigné est en statut 'Immatriculé' (Siren non vide+ siret non vide) > Payeur

Une première remarque : le SIRET c'est le SIREN (9 caractères) augmenté du NIC (5 caractères), le NIC caractérise l'établissement, tous les établissements d'une même société partagent le même SIREN, mais leur NIC les distingue.
Ensuite,

• je suppose que le "d'" et la mention "Payeur" que j'ai mis en rouge ci-dessus sont une coquille ?
• pour les clients société, le payeur peut-il avoir un SIREN différent de celui du donneur d'ordre ?
• toujours pour les clients société, la règle R010_CL telle que rédigée semble impliquer que tout client en statut immatriculé (SIREN+NIC renseignés) est un client payeur, ce qui me surprend : il est fréquent que les établissements soient donneurs d'ordre mais que le paiement soit centralisé au siège ou dans un établissement particulier. À confirmer dans les règles de gestion.

[fsmrel]

Bonjour à vous deux, MDA, Capitaine, et meilleurs voeux à mon tour.

MDA, ça doit bouillonner ! Mais vous y arriverez, nonobstant les remarques percutantes du Capitaine

Bon courage.

[MDA_1602]

Bonjour et bonne année à vous

Oui ça bouillonne

Je me dis que l'on devrait peut être pour l'instant se focaliser jsute sur la partie base clients qui est déjà bien assez lourde à gérer
Je pensais que ce serait un MCD qui serait un résumé simple mais je me rend compte que c'est pas possible de le faire car toutes les règles ont un impact sur le MCD

Sur la partie clients je n'ai pas donnée toutes les règles pensant que ce serait pas utiles mais je me rends compte qu'on ne peut pas avancer sans
Il va falloir que je revois cela encore une fois

Désolé de vous faire perdre votre temps !

PS j'ai commandé le livre de Paprick

[escartefigue]

Oui c'est une très bonne chose de commencer par un sous-ensemble, quand celui-ci sera stabilisé, on pourra élargir le périmètre

[fsmrel]

Oui c'est une très bonne chose de commencer par un sous-ensemble, quand celui-ci sera stabilisé, on pourra élargir le périmètre

Je confirme

[MDA_1602]

Ok donc je vais détailler les règles pour la partie Clients et contacts en plus c'est surtout cette partie qui m'intéresse

Pour info il y a deux bases clients interconnectées celle du CRM et la base client Locale
Les contacts sont également dans les deux systèmes avec des règles de gestions différentes sinon ce serait pas drôle !
Les clients j'ai aussi des règle de gestion différentes je pense.


@Escartefigue j'ai vu que tu as participé au fil sur ma question SQL_contrainte
Est ce que l'on peut en discuté ici ou tu préfères que je continue sur l'autre fil ?
J'aimerais ton avis sur ce sujet

Merci

[fsmrel]

Pour info il y a deux bases clients interconnectées celle du CRM et la base client Locale
Les contacts sont également dans les deux systèmes avec des règles de gestions différentes sinon ce serait pas drôle !
Les clients j'ai aussi des règle de gestion différentes je pense.

S'il y a deux jeux de règles, il y a donc deux univers du discours, ne les mélangeons pas, prudence. On en étudie un 1er puis l'autre ensuite. A défaut ça peut être la foire, la contradiction et j'en passe. La fusion, si elle est possible ne pourra être envisagée qu'après tout cela...

[escartefigue]

@Escartefigue j'ai vu que tu as participé au fil sur ma question SQL_contrainte
Est ce que l'on peut en discuté ici ou tu préfères que je continue sur l'autre fil ?

Si c'est juste un aparté, ouaille note, mais il ne faut pas polluer ce fil avec des digressions surabondantes

[MDA_1602]

S'il y a deux jeux de règles, il y a donc deux univers du discours, ne les mélangeons pas, prudence. On en étudie un 1er puis l'autre ensuite. A défaut ça peut être la foire, la contradiction et j'en passe. La fusion, si elle est possible ne pourra être envisagée qu'après tout cela...

Ok on commencera par le Local
J'ai commencé à rédiger les règles de gestion mais j'ai du mal avec les verbes, Escartefigue va me tomber dessus à bras raccourci

Si c'est juste un aparté, ouaille note, mais il ne faut pas polluer ce fil avec des digressions surabondantes

Pas de pollution je vais reprendre le fil déjà ouvert

[SQLpro]

L'envie d'apprendre est la meilleure façon d'y arriver, donc tout va bien :cool:

Il y a une exception à la règle n°1 formulée dans le lien (Tuto de SQLPro) :

Cette règle n'est pas vérifiée quand on modélise une entité-type dite "fictive" dont la vocation n'est justement pas de devenir une table, mais de faire participer son identifiant à une table associative, le plus souvent dans une relation de dimension 3 ou plus.
C'est fréquent avec l'entité-type date.

Et la je ne suis pas d'accord.... Tout simplement parce que cela va poser le problème de la recherche inverse... Les dates absentes !

A +

[SQLpro]

Bonjour,

MDA, à propos de l’article de Fred sur la méthode Merise, merci pour le lien vers le paragraphe V-A-2. Relation de type 1:n (maître et esclave).
La relation maître/esclave, est donc due à Fred, qui est un bon camarade, que je considère comme faisant autorité en matière de SQL Server, mais certainement pas en ce qui concerne Merise. Certes, il connaît le sujet, mais il est approximatif quant à la terminologie. Dans son article, s’il avait fait référence à Hubert Tardieu qu’il cite (cf. le paragraphe I de l’article de Fred), il aurait appris que sa définition de l’entité n’est pas valide.

C'est le problème de la simplification pour faire venir les choses au cerveau petit à petit... On commence par Newton, qui est faux, pour faire comprendre Einstein, qui n'est pas tout à fait vrai, pour arriver à Louis de Broglie...

A +

[Paprick]

Bonjour, et tous mes vœux pour cette nouvelle année !

Et la je ne suis pas d'accord.... Tout simplement parce que cela va poser le problème de la recherche inverse... Les dates absentes !A +

En fait, tout dépend du contexte :

• Si chaque date a du sens pour le SI, y compris les dates non utilisées, alors la classe d'entités "Calendrier" ne doit pas être fictive et donne donc lieu à une table.
• Si, par contre, seules les dates utilisées sont stockées (le plus souvent dans un soucis d'historisation avec une association ternaire), alors une classe d'entités "fictive" prend tout son sens et disparait au niveau MLD (et donc pas de table au niveau SQL).

La décision appartient au concepteur dans le cadre de la modélisation de son SI.
Ce qui est sûr, c'est que le principe (et la définition) d'une classe d'entités "fictive" est justement de ne pas donner lieu à la création d'une table... mais une classe de type "Calendrier" ne doit pas forcément être fictive.