Conception d'un systeme de gestion d'appel client

**Andry** · 21/08/2006, 11h22

Salut à tous.
Actuellement je sur en train de créer une base de donnée pour gerer les appels clients.
Alors pour simplifier les choses, j'ai deux table
TABLE TCLIENT qui contient seulement les clients enregistrés auprès du service commerciale.

CLI_ID,
CLI_RS,
CLI_CONTACT
....

TABLE TAPPEL qui contient les données des appels clients.

APL_ID,
APL_DATE,
APL_HEURE,
APL_CORRESPOND,
APL_CLIENT,
.....

Or, des fois, on est amenné à enregistrer des appels venant des particuliers, et les informations de ces clients doivent être aussi enregistrer mais pas dans la table TCLIENT(vu que le contenu de celui ci est seulement les clients enregistrer après de la service commerciale).

Comment faire.

Merci

**KiLVaiDeN** · 21/08/2006, 11h25

Salut,

Si j'étais toi, j'ajouterais un FLAG au niveau de la table CLIENT, qui determinerait si le client est enregistré auprès du service commerciale ou non. Un booléen ferait l'affaire.

A+

**Andry** · 21/08/2006, 11h35

Salut
Cette idée fonctionne mais il y a un hic :
Je ne dois pas toucher la table TCLIENT(Celui ci est importer via SQL Server (SAGE Gescom 100 SQL)).
Et puis, j'aurais un problème au niveau de l'identifiant CLI_ID.

Néammoins, J'ai une ligne dans la table TCLIENTS qui designe les clients particuliers. Celui que le service comm utilise lorsqu'il on affaire à des clients non enregistrer(Qui est très rare).

Mais le souci reste, comment changer TAPPEL pour prendre en charge aussi les clients particluliers.
Merci

**KiLVaiDeN** · 21/08/2006, 14h09

Salut,

Quand tu dis qu'il faut aussi modifier TAPPEL, je ne comprends pas trop; ta modification est une modification au niveau du client non ? Donc il n'y a pas besoin de toucher à TAPPEL.

Si tu ne peux pas ajouter l'information à ta table d'origine, il y a un autre moyen; Ajouter une table externe, liée par l'id_client, qui stockerait toutes les informations supplémentaires dont tu aurais besoin.

J'espère avoir bien compris ton problème, car j'ai l'impression qu'il y a comme un flou quelque part..

A+

**pcaboche** · 22/08/2006, 15h43

Pourquoi ne pas faire 2x2 tables (de même structure)?

TCLIENT, TAPPEL => les clients enregistrés et leurs appels
TPARTICULIER, TAPPEL_PARTICULIER => les particuliers et leurs appels

Comme ça, tu ne touches pas aux tables TCLIENT et TAPPEL et tu peux faire des "vues" qui seront l'union de plusieurs requêtes si tu veux mélanger clients et particuliers.

**Andry** · 22/08/2006, 16h56

Alors, voilà les ennoncés :
On souhaite enregistrer les appels de demande SAV des clients : ceux enregistrés chez nous et ceux du client particulier.Pour ça :
- on a une table des clients enregistrés dont une ligne désigne les clients particuliers.
- on a besoin d'avoir les informations concernant les client particluliers (pour rappel, facturation etc).
- Pour des besoin de la comptabilité (facturation), la table TAPPEL doit renseigner le code client (CLIDIVERS pour les Clients particuliers).

Alors avec des illustration.
Voici actuellement mes 3 entités

Alors, je me suis amusé à créer mon MCD sur le CLIENT_GESCOM :

et avec client particulier :

Si je fait un mixage des 2 et transforme en modèle physique, j'ai ceci :

Est ce que le résultat est cohérent par rapport aux ennoncés ci-dessus

Merci

**pcaboche** · 22/08/2006, 17h14

C'est quoi cette relation à 3 branches? Tes sûr de tes cardinalités? Soit tu nous caches des choses, soit tu t'es emmélé les pinceaux.

Est-ce que les ensembles TCLIENT_GESCOM et TCLIENT_PART sont disjoints ou pas? Pourquoi sont-ils liés dans ta relation? En quoi un client enregistré diffère d'un client particulier? Quelles sont les informations de ces deux entités?

**remi4444** · 31/08/2006, 16h09

et pourquoi tu rajoutes pas une colonne "N°Auto" (id de la table TCLIENT_PART) dans ta table TAPPEL. Ainsi tu aura une colonne pour chaque type d'appel qui sera nulle d'un coté et renseigné de l'autre.

ta relation à 3 branches ne va pas car elle suppose qu'un appel est forcément liés à un client ET un particulier.

**pcaboche** · 31/08/2006, 17h38

Envoyé par remi4444

Ainsi tu aura une colonne (...) qui sera nulle d'un coté et renseigné de l'autre.

Attention, ici c'est un forum Merise, et dans un MCD, les colonnes "nulles" ne sont pas les bienvenues (ben oui, c'est Merise, c'est comme ça, j'y peux rien...).

Envoyé par remi4444

ta relation à 3 branches ne va pas car elle suppose qu'un appel est forcément liés à un client ET un particulier.

Là, je suis d'accord.

**remi4444** · 31/08/2006, 17h44

désolé, je me suis évadé du forum oracle je recommencerais plus...

Attention, ici c'est un forum Merise, et dans un MCD, les colonnes "nulles" ne sont pas les bienvenues (ben oui, c'est Merise, c'est comme ça, j'y peux rien...).

quand même, c'est pas un forum "merise-fondamentaliste" si

Alors je vais pas dire "colonne nulle", mais relation 0-1, j'ai bon là ?

**pcaboche** · 31/08/2006, 17h52

Envoyé par remi4444

désolé, je me suis évadé du forum oracle je recommencerais plus...

C'est pas grave !

Envoyé par remi4444

quand même, c'est pas un forum "merise-fondamentaliste" si ?

J'en sais rien, ça dépend du chef de projet.

Imagine la situation suivante: un analyste est tout fier du MCD qu'il a pondu, il le montre à son chef de projet qui lui dit:
- c'est quoi cette colonne?
- ben c'est une colonne NULL.
- QUOI? Une colonne NULL dans un MCD? Mais quel est l'imbécile qui a pondu un truc pareil ?!!
- Ben c'est sur developpez, ils m'ont dit que...

Voilà, ça se fait pas.

Donc si c'est pas du Merise 100% dans la norme, faut au moins le préciser.

Envoyé par remi4444

Alors je vais pas dire "colonne nulle", mais relation 0-1, j'ai bon là ?

Je pense, oui (ça fait ajouter une table, c'est ça?)

**remi4444** · 31/08/2006, 21h30

Une relation 0-1 c'est une relation "facultative" qu'un appel peut etre associé à un client ou à 0 client, qu'un appel peut etre associé à un particulier ou à 0 particulier. c'est incompatible avec merise ça ?

**TheLeadingEdge** · 31/08/2006, 21h45

j'ai pas trop envie de bosser, mais j'ai 1 peu envie de troller

- QUOI? Une colonne NULL dans un MCD? Mais quel est l'imbécile qui a pondu un truc pareil ?!!

(et là le grouillot tt content y dit)
- euh Chef écoutez : sur Dvp y a de l'écho :
KWA, 1 colonne ds 1 MCD ?

note de l'integriste : au niveau conceptuel on parle de propriété d'1 entité (ou d'une relation)
table et colonne c'est au niveau physique.

Désolé j'ai pas pu m'en empêcher

Pour me faire pardonner finalement je vais bosser 1 peu qd même :
2 pattes '0,n' donc 1 appel peut avoir deux les 2 FK nulles (je parle physiquement hein

,pas taper pcaboche

). Et tu peux avoir plusieurs clients par appel. Si j'ai compris c'est pas ce que tu veux, tu veux soit l'1, soit l'autre.
Fais 2 relations (0,1) Appel-Gescom et Appel-Part avec 1 exclusion (XT) entre les 2. Ta relation ne deviendra pas 1 table et tu aura 2 FK ds ta table appel dont l'une referencera 1 client et l'autre sera ''null' (re

)

**remi4444** · 31/08/2006, 21h54

Eh bien, c'est exactement ce que je voulais dire, mais vu que je suis un autodicate complet en merise, j'avais des doutes, j'avais peur d'avoir toujours fait du faux merise sans m'en rendre compte... (et pourtant j'étais considéré comme un intégriste dans ma boite...)

Ceci dit, c'est vrai que commencer à poser un problème en parlant de table plutot que d'entité, ça ne pouvait que mal tourner

**pcaboche** · 31/08/2006, 23h57

Envoyé par TheLeadingEdge

note de l'integriste : au niveau conceptuel on parle de propriété d'1 entité (ou d'une relation)
table et colonne c'est au niveau physique.

Oui, tu as raison de me reprendre, ça fait longtemps que je n'ai pas fait du Merise.

Envoyé par TheLeadingEdge

(je parle physiquement hein

,pas taper pcaboche

)

Moi pas taper. Moi pas aimer plus que toi les intégristes de Merise car moi trouver leur méthode un peu lourde. Mon prof de Merise était un vrai intégriste.

C'est vrai quoi: je ne connais pas beaucoup de méthode où dans une phase (MCD) tu fais les choses d'une certaine manière en sachant pertinemment qu'à la phase suivante (MLD) tu vas tout casser et faire autrement. Faut vraiment n'avoir que ça à faire...

Pas étonnant que dans ces conditions on ait surnommé Merise: Méthode Eprouvée pour Retarder Indéfiniment la Sortie des Etudes.

Envoyé par remi4444

Eh bien, c'est exactement ce que je voulais dire, mais vu que je suis un autodicate complet en merise, j'avais des doutes, j'avais peur d'avoir toujours fait du faux merise sans m'en rendre compte...

Mais non. Tu as fait du "vrai" Merise mais du "faux" MCD (en pensant directement en termes d'implémentation).

Merise, c'est comme certaines langues: tu as le Merise "littéraire" avec ses règles compliquées et qui obligent à faire de longs discours, et tu as le Merise "courant" parlé par les analystes qui veulent rendre leur projet à temps.

**remi4444** · 01/09/2006, 00h56

Envoyé par pcaboche

Mais non. Tu as fait du "vrai" Merise mais du "faux" MCD (en pensant directement en termes d'implémentation).

Ah ben elle est forte celle là! dans tous les posts de cette discution, on ne parle que de tables et de colonnes, moi sympa, je m'adapte et on me le reproche maintenant... c'est vraiment trop injuste...

**pcaboche** · 01/09/2006, 01h24

En fait c'est moi: j'arrive sur un forum qui s'appelle "Merise", je vois un sujet dans lequel il est question de MCD et pourtant on parle de "tables", "colonnes", "colonnes nulles" au lieu de parler d' "entités", "propriétés", "relations 0-1". Je me dis alors que j'ai dû me tromper de forum.

Mais bon, c'est juste un détail, je ne connais pas bien les us et coutumes de ce forum particulier. Cependant quelqu'un d'un peu tatillon sur les termes et la méthodologie (du genre de mon ancien prof de Merise) peut vite arriver à la conclusion (fausse, bien sûr) que DVP n'est pas un site sérieux et ça, c'est quelque chose que je souhaite éviter.

Pour en revenir au problème original, il y a certains points qui restent obscurs, notamment concernant les besoins et les contraintes (quelle table/entité ne peut-on pas modifier et pourquoi? Peut-on avoir des exemples de données à représenter dans la base?)

**KiLVaiDeN** · 01/09/2006, 08h50

Salut,

Le problème est depuis le début posé au niveau physique, donc je parle avec des termes du niveau physique

Je n'ai vu mention d'aucun MCD au début, j'ai moi aussi vu des tables et colonnes, donc ça me parraissait logique d'utiliser ce vocabulaire à mon tour.

Cependant, il est vrai qu'en Merise, le niveau physique est directement issue du modèle conceptuel, et donc on ne devrait jamais parler de modifications au niveau physique sans d'abord regarder le niveau conceptuel. Il me semble que les seuls modifications autorisées au niveau physique sont des changements de noms de colonnes et de noms de tables, tout le reste est directement issue des règles de transformations conceptuel -> physique

On a peut-être eu le même prof pcaboche

A+ et bonne journée tout le monde !

**remi4444** · 01/09/2006, 10h04

Je me suis moi-même battu dans mon boulot pour que les informaticiens travaillent sur MCD pendant la conception, mais j'ai constaté ces dernières année que c'était de moins en moins le cas. Il y a aussi de tres grosses applications (notament américaines) qui sont directement conçues en partant du MPD. Il est donc difficile de repprocher aux contributeurs de ce forum de commencer aussi par ce biais, parcequ'à ce moment là, il faudrait un autre forum "design de base physique" séparé du forum merise.

Attention aussi au merisiens fondamentalistes qui n'ont jamais été confronté au problématiques de programmation et surtout d'optimisation, ils ont fait pas mal de dégats, par exemple en ce qui concerne le mélange identifiant/signifiant qui est l'usage en merise alors que c'est contraire à l'évolutivité et l'éfficacité d'un modèle...

Tout ça pour dire que je ne pense pas qu'il faille s'offusquer tant que ça du manque de "pureté" des échanges entres développeurs, les gens qui viennent ici ont souvent la pression de leur chef de projet pour obtenir un résultat trés rapide en se moquant éperdument de la beauté du modèle. Le but de ce site est justement de faire partager des expériences concrètes de développement (d'ou le nom d'ailleur...) plus que d'avoir des débats d'école d'un haut niveau d'abstraction (enfin c'est ce que j'avais compris...)