Discussion :

[Superkoala42]

Bonjour à tous,

Je me présente Alexandre ROUX, étudiant en informatique.

Dans le cadre de ma formation je dois réaliser une application de développement pour mon entreprise.

Aujourd’hui, nos commerciaux utilisent un fichier Excel pour renseigner un tas d’informations sur les lignes de fabrication de nos clients.

Voici le contexte :
Une ligne de fabrication à divers aspects techniques (que je renseignerais dans une Entité « Ligne de Fab »).
Une ligne de fabrication appartient à un client, et un client peux avoir plusieurs lignes de fabrications (création d’une entité « Client »).
Une ligne de fabrication à un Contact Commerciaux et un Contact technique de mon entreprise, et un contact de l'entreprise client.


Je suis en train de réaliser la partie analyse de ce sujet, et notamment le modèle conceptuel.
Je galère un peu avec la création du MCD, même si le sujet semble facile, je n’arrive pas à modéliser l'entitée "Contact".

En terme de développement, je dirais qu’une entité « Contact » serait parent de deux entités « Contact – Client », « Contact – MonEntreprise ».

L’entitié « Contact – MonEntreprise », serais parent de deux entités :
- « Contact – MonEntreprise - Commerciaux».
- « Contact – MonEntreprise - Techniciens ».
Mais je n’arrive pas à modéliser tout ça.


Je suis pas développeur de formation, j’aimerais (si possible) un peu d’aide afin de trouver une solution à ce problème et me permettre un bon démarrage avec ce MCD.

Merci d’avance pour toute aide.

Cordialement.

[fsmrel]

Bonsoir Alexandre,


Un scénario concernant les contacts pourrait être le suivant :



AGL utilisé : PowerAMC. Mais on peut utiliser MySQL Workbench (gratuit) pour réaliser le contrôle de la contrainte de chemin, car de LIGNE_FABICATION, pour une ligne donnée, un 1er chemin peut conduire au client Raoul et un 2e chemin conduire au client Fernand : danger !

[Superkoala42]

Tout d'abord, merci fsmrel pour ta réponse.

Je trouve ton scénario très bien.
Je me permets de le commenter afin d'être sûr d'avoir bien compris ta démarche (et la démarche Merise).

Pour commencer le plus simple, entre l'entité CLIENT et LIGNE_FABRICATION.

Un client peut avoir 0 ou N lignes de FAB.
Une ligne de FAB appartient à 1 et 1 seul client.
Si je ne me trompe pas, dans le MLD, une clé étrangère IdClient viendra s'ajouter dans la table LIGNE_FABRICATION, afin de savoir à quel client appartient cette ligne??

Pour la gestion des contacts, tu as préféré gérer les contacts clients via CONTACT_CLIENT, qui appartiennent à la fois à CLIENT et LIGNE_FABRICATION.

Dans le MLD, la table CONTACT_CLIENT, se verra attribuée 2 clés étrangères.

Pour les contacts liés à mon entreprise, il sont directement liés à la ligne de FAb, ce qui est juste, et seront gérés dans COLLABORATEUR.

Dans le MLD, la table COLLABORATEUR, se verra attribuer 2 clés étrangères.


Tout ça m'à l'air très bien, j'aimerais néanmoins proposer un choix (Je pense que je me trompe, mais j'aimerais comprendre pourquoi) :




http://imagik.fr/view-rl/73584

Pourquoi ne serait t'il pas possible de tout gérer dans une table contact avec une association de N to N entre CONTACT et LIGNE_FABRICATION, puisque dans ce cas là :

Une ligne de FAB pourrait avoir plusieurs contacts (de différent types).
les contacts pourraient être affectés à plusieurs lignes de FAB (pouvant appartenir à plusieurs clients).

Mon raisonnement est peut-être faux...

Merci de votre aide.

Bonne journée.

[dde63]

Bonjour,

Ton MCD me conviendrait assez bien sauf sur 2 points :

L'entité type de Contact concerne le Contact lui-même : il est soit commercial soit technicien.
Quant au contact Client je le verrais bien défini dans l'entité Ligne de fabrication


Bonne journée

[fsmrel]

Bonsoir Alexandre et Dominique,

Si je ne me trompe pas, dans le MLD, une clé étrangère IdClient viendra s'ajouter dans la table LIGNE_FABRICATION, afin de savoir à quel client appartient cette ligne ?

L’en-tête de la table LIGNE_FABRICATION comportera effectivement une colonne ClientId, participant à la clé étrangère {ClientId} faisant référence à la clé (primaire) de la table CLIENT. C’est ce qui apparaît dans le MLD (LIGNE_FABRICATION, clé étrangère <fk1>) :




Version MySQL Workbench :



Clé étrangère :

Pour la gestion des contacts, tu as préféré gérer les contacts clients via CONTACT_CLIENT, qui appartiennent à la fois à CLIENT et LIGNE_FABRICATION.
Dans le MLD, la table CONTACT_CLIENT, se verra attribuée 2 clés étrangères.

En fait, dans le MCD initial, j’ai utilisé l’identification relative (convention PowerAMC : la cardinalité 1,1 portée par la patte connectant l’entité-type CONTACT_CLIENT et l’association CONTACT_DU_CLIENT est mise entre parenthèses) : l’entité-type CONTACT_CLIENT est identifiée relativement à l’entité-type CLIENT, ce qui se traduit au niveau MLD par une clé primaire {ClientId, ClientContactId} pour la table CONTACT_CLIENT.

Par contre, la table CONTACT_CLIENT ne possède qu’une seule clé étrangère :




Et la table LIGNE_FABRICATION possède 4 clés étrangères dont 3 en ce qui concerne les contacts :

Contacts clients :




Contacts commerciaux :




Contacts techniques :

J'aimerais néanmoins proposer un choix (Je pense que je me trompe, mais j'aimerais comprendre pourquoi)

Selon vos règles de gestion, une ligne de fabrication doit avoir exactement 3 contacts, un chez le client et deux chez le fournisseur (un commercial et un technique). Il faudrait déjà remplacer la cardinalité 1,N portée par la patte connectant LIGNE_FABRICATION et TYPE_CONTACT par une cardinalité 3,3, d’où une contrainte à gérer applicativement (assertion SQL, trigger...)

Si Raoul, Paul et Fernand sont 3 contacts pour la ligne LF1, rien n’empêche qu’ils jouent tous le même rôle, par exemple celui de commercial (je suppose en l’occurrence que l’attribut IdType est synonyme de rôle).

Rien n’empêche que Raoul soit contact client pour les lignes LF1 et LF2, mais ça craint si LF1 est une ligne du client C1 et LF2 du client C2 !

Qu’est-ce que l’attribut DesignationId ?

En tout cas avec votre MCD, il y aura beaucoup de contrôles à effectuer applicativement.

L'entité type de Contact concerne le Contact lui-même : il est soit commercial soit technicien.

Rien n’empêche qu’Alexandre utilise la table CONTACT pour les contacts clients, mais avec les risques signalés précédemment.

Quant au contact Client je le verrais bien défini dans l'entité Ligne de fabrication

Si l’on vous suit et si Pascal est un contact du client Volfoni, on pourrait se retrouver dans la configuration suivante :

Code :

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

1
2
3
4
5
LigneFabId    LigneFabLibelle    ClientId    ClientContactId    ClientContactNom....ClientContactAdrCourriel
        11    Ligne truc               40                  1    Pascal              Bastien@Volfoni.xy
       ...
        57    Ligne machin             40                  1    Pascal              Bastien@Volfoni.xy

D’où un viol de 3NF se traduisant par une redondance mal venue et à entretenir à l’octet près.

[dde63]

Bonsoir à tous,

Le Contact Client est une donnée qui si elle est gérée comme Objet introduit un nombre de règles que devront prendre en compte les gestionnaires : identification, contrôle d'existence etc.

Cette information peut-être introduite au niveau de la ligne de fabrication sans violation de la 3iBNF ; encore faut-il s'entendre sur Ligne de fabrication? Chaque ligne est-elle indépendante l'une de l'autre ou bien faut-il les considérer comme un tout? Dans ce dernier cas il faut un Objet 'Demande de fabrication' regroupant des Lignes de fabrication. Et c"est dans l'Objet "Demande ' qu'il faudra préciser le contact Client selon les informations fournies par ledit Client.

Bonne soirée

[Superkoala42]

Bonjour à tous.

Je voudrais vous remercier pour l'aide apporté à ce sujet, notamment car tout ça me permet d'apprendre plein de choses .

Je suis d'accord sur toute la première partie, relative au modèle proposé par fsmrel (Mise en place des clés étrangères et explication de tout le modèle).

Je pense que je vais partir sur ce modèle.

Mais j'aimerais avant tout comprendre pourquoi le modèle que je propose me ferais effectuer beaucoup de contrôles en développement...

Si Raoul, Paul et Fernand sont 3 contacts pour la ligne LF1, rien n’empêche qu’ils jouent tous le même rôle, par exemple celui de commercial (je suppose en l’occurrence que l’attribut IdType est synonyme de rôle).

Rien n’empêche que Raoul soit contact client pour les lignes LF1 et LF2, mais ça craint si LF1 est une ligne du client C1 et LF2 du client C2 !

Pour répondre et comprendre ces deux faits, je vais créer deux BDD avec les deux modèles et faire des test via un jeu d'essaie pour comprendre.

Je reviens vers vous dès que j'aurais effectué cette étape !!

[Superkoala42]

Bonjour à tous .

Voici quelques nouvelles suite à mon dernier message.

J'ai monté une archi de test équivalente à ce que je vais utiliser pour ce projet, SQL Server 2005 Express + Management Studio.
Tout fonctionne correctement.

Je vais maintenant pouvoir créer deux bases de données (Une pour chaque modèle, afin de tester un jeu d'essaie, et de me rendre compte des contraintes).

Par contre, est-ce qu'un outil (du style workbench) peux être utilisé pour créer un MLD et importer le tout pour créer la BDD??

Merci d'avance.

Et bonne journée.

[fsmrel]

Bonjour Alexandre,

est-ce qu'un outil (du style workbench) peux être utilisé pour créer un MLD et importer le tout

Qu’entendez-vous par « importer le tout » ?

[Superkoala42]

Je cherche un outil me permettant de réaliser le modèle logique de données, et via ce modèle la génération des tables et contraintes de la base.

Je saute peut-être une étape?

[fsmrel]

MySQL Workbench est fait pour produire des MLD. L’étape MCD est court-circuitée, mais ça n’est pas peccamineux, et ça m’arrive quand le MCD (contraint par des carcans vieillots et gênants, du genre « Tu n’établiras pas d’association en association avec autre chose ») que je produirais ne pourrait pas être dérivé en un MLD valide sans retouches importantes.

Pour générer les tables, reportez-vous au paragraphe 8 de mon article.

Pour reprendre l’exemple que j’ai donné dans le message #5 ci-dessus:


Vous suivrez les étapes du paragraphe 8. Arrivé à la figure 8.5, vous copiez le résultat dans un fichier texte que vous pourrez soumettre à SQL Server après nettoyage qui s’impose : virer les « ` », les « IF NOT EXISTS » et toutes ces choses propres à MySQL et non reconnues par SQL Server.

Exemple (pour SQL Server) nettoyé et enrichi en 5 minutes à partir du code généré par MySQL Workbench :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
use temp
 
SET DATEFORMAT ymd
 
 
IF EXISTS(SELECT name FROM sysobjects WHERE type='U' AND name = 'LIGNE_FABRICATION')
   DROP TABLE LIGNE_FABRICATION ; 
 
IF EXISTS(SELECT name FROM sysobjects WHERE type='U' AND name = 'CONTACT_CLIENT')
   DROP TABLE CONTACT_CLIENT ; 
 
IF EXISTS(SELECT name FROM sysobjects WHERE type='U' AND name = 'COLLABORATEUR')
   DROP TABLE COLLABORATEUR ; 
 
IF EXISTS(SELECT name FROM sysobjects WHERE type='U' AND name = 'CLIENT')
   DROP TABLE CLIENT ; 
---------------------------------------------------------------------------------------------
 
-- -----------------------------------------------------
-- Table CLIENT
-- -----------------------------------------------------
CREATE TABLE CLIENT (
  ClientId INT NOT NULL,
  ClientRaisonSociale VARCHAR(64) NOT NULL,
  PRIMARY KEY (ClientId));
 
-- -----------------------------------------------------
-- Table COLLABORATEUR
-- -----------------------------------------------------
CREATE TABLE COLLABORATEUR (
  CollabId INT NOT NULL,
  CollabNom VARCHAR(64) NOT NULL,
  PRIMARY KEY (CollabId));
 
-- -----------------------------------------------------
-- Table CONTACT_CLIENT
-- -----------------------------------------------------
CREATE TABLE CONTACT_CLIENT (
  ClientId INT NOT NULL,
  ClientContactId INT NOT NULL,
  ClientContactNom VARCHAR(64) NOT NULL,
  PRIMARY KEY (ClientId, ClientContactId),
  CONSTRAINT CONTACT_CLIENT_CLIENT_FK
    FOREIGN KEY (ClientId)
    REFERENCES CLIENT (ClientId));
 
-- -----------------------------------------------------
-- Table LIGNE_FABRICATION
-- -----------------------------------------------------
CREATE TABLE LIGNE_FABRICATION (
  LigneFabId INT NOT NULL,
  ClientId INT NOT NULL,
  LignrFabLibelle VARCHAR(64) NOT NULL,
  ClientContactId INT NOT NULL,
  CollabCialId INT NOT NULL,
  CollabTecId INT NOT NULL,
  PRIMARY KEY (LigneFabId),
  CONSTRAINT LIGNE_FABRICATION_CLIENT_FK
    FOREIGN KEY (ClientId)
    REFERENCES CLIENT (ClientId),
  CONSTRAINT LIGNE_FABRICATION_COLLABORATEUR_CIAL_FK
    FOREIGN KEY (CollabCialId)
    REFERENCES COLLABORATEUR (CollabId),
  CONSTRAINT LIGNE_FABRICATION_COLLABORATEUR_TEC_FK
    FOREIGN KEY (CollabTecId)
    REFERENCES COLLABORATEUR (CollabId),
  CONSTRAINT LIGNE_FABRICATION_CONTACT_CLIENT_FK
    FOREIGN KEY (ClientId, ClientContactId)
    REFERENCES CONTACT_CLIENT (ClientId, ClientContactId));
 
-------------------------------------------------------------------------------------------
IF EXISTS(SELECT name FROM sysobjects WHERE type='U' AND name = 'LIGNE_FABRICATION')
   DROP TABLE LIGNE_FABRICATION ; 
 
IF EXISTS(SELECT name FROM sysobjects WHERE type='U' AND name = 'CONTACT_CLIENT')
   DROP TABLE CONTACT_CLIENT ; 
 
IF EXISTS(SELECT name FROM sysobjects WHERE type='U' AND name = 'COLLABORATEUR')
   DROP TABLE COLLABORATEUR ; 
 
IF EXISTS(SELECT name FROM sysobjects WHERE type='U' AND name = 'CLIENT')
   DROP TABLE CLIENT ;

La production d'un MCD ou d'un diagramme de classes vous est-elle imposée ?

N.B. N'oubliez pas de voter pour les réponses qui vous ont été utiles.

[Superkoala42]

Bonjour à tous.

Tout d'abord, j'aimerais remercier les users du forum pour toutes ces réponses (J'ai UP vote les plus intéressantes).

Ensuite, je suis désolé de répondre tardivement, ce projet m'intéresse grandement, mais étant étudiant en alternance, j'ai passé les deux dernières semaines en formation.



Pour commencer ce post, je trouvais important de reproduire le MLD de François moi même afin de connaitre Workbench.
Votre aide en ligne m'a été d'une GRANDE utilité (MERCI pour cette SUPER contribution).


Voici les deux modèles que j'ai réalisé :

- Le 1er est identique au votre (A peu de choses près) :



J'ai du mal à comprendre une chose, la relation entre CONTACT_CLIENT et CLIENT et notamment la propriété "Identifying Relationship":

En fait, dans le MCD initial, j’ai utilisé l’identification relative (convention PowerAMC : la cardinalité 1,1 portée par la patte connectant l’entité-type CONTACT_CLIENT et l’association CONTACT_DU_CLIENT est mise entre parenthèses) : l’entité-type CONTACT_CLIENT est identifiée relativement à l’entité-type CLIENT, ce qui se traduit au niveau MLD par une clé primaire {ClientId, ClientContactId} pour la table CONTACT_CLIENT.

Par contre, la table CONTACT_CLIENT ne possède qu’une seule clé étrangère :

Dans ma façon de résonner (et dans le peu de compréhension de Merise que j'ai pu acquérir pour le moment, une association de 1 TO 1.N, donne forcément une FK.
Si je clique sur "Identifying Relationship, cette FK ce transforme en PK.
Mais nous avons toujours une FK dans la table (comme vous nous l'avez montré).
Le soucis c'est que là.. Je suis perdu.




- Le 2ème a subit quelques changements

En effet, j'ai pu récolter quelques avis sur ce modèle auprès de mes collègues de formation.
Ces personnes m' ont suggérées de ne pas faire de boucle dans un modèle (Comme pour CONTACT_CLIENT, CLIENT, LIGNE_FAB). Vrai ou FAUX?

Il faudrait apparemment enlever la relation entre CONTACT_CLIENT et CLIENT puisque pour retrouver à quel CLIENT appartient un CONTACT_CLIENT, la relation passant par LIGNE_FAB suffirait.

Qu'en pensez vous?



Un collaborateur (CONTACT_BI) est toujours commerciale ou toujours technique peu importe les lignes de productions. J'ai donc rajouté le type collaborateur dans la table CONTACT_BI.



Je vais ensuite mettre en BDD ces modèles sous SQL Server 2005 sur ma VM, et y insérer un jeux d'essais, tester les relations et contraintes, voir comment tout ça fonctionne.

Autre question : Comment réaliser un jeux d'essaie cohérent avec un nombre d'enregistrement cohérent??

Bonne journée à tous.

[fsmrel]

Bonsoir Alexandre,

une association de 1 TO 1.N, donne forcément une FK.

Oui. Prenons le cas de l’association entre CLIENT et CONTACT_CLIENT : cette association est rendue possible, matérialisable, grâce à la présence de l’attribut ClientId dans l'en-tête de chacune de ces deux tables (un en-tête est la liste des attributs d’une table). Comme l’attribut ClientId appartient à la clé primaire {ClientId} de la table CLIENT, et qu’il faut garantir l’intégrité référentielle, l’attribut ClientId de l’en-tête de la table CONTACT_CLIENT doit faire l’objet d’une clé étrangère {ClientId} au sein de cette table.

Si je clique sur "Identifying Relationship, cette FK ce transforme en PK.

Il n’y a pas transformation de la clé étrangère {ClientId} en clé primaire, par contre, en plus d’appartenir à cette clé étrangère, l’attribut ClientId appartient aussi à la clé primaire {ClientId, ClientContactId), de la table CONTACT_CLIENT.

c'est que là... Je suis perdu.

Je suppose que vous avez cru qu’un attribut ne pouvait pas participer à la fois à une clé primaire et à une clé étrangère au sein d’une table donnée : c’es pardonnable, car il est vrai qu’en 1975 ce fut la thèse que soutint Chris Date dans la 2e édition de An Introduction to Database Systems, mais il comprit ensuite très vite que les concepts de clé primaire et étrangère étaient indépendants et que sa thèse ne tenait pas debout. Pratiquement quarante ans se sont écoulés... Bref, je rappelle qu’un attribut peut appartenir simultanément à tous types de clés.

j'ai pu récolter quelques avis sur ce modèle auprès de mes collègues de formation.
Ces personnes m' ont suggérées de ne pas faire de boucle dans un modèle (Comme pour CONTACT_CLIENT, CLIENT, LIGNE_FAB). Vrai ou FAUX?

Vos collègues propagent des mythes quadragénaires. Posez-leur la question : « Quels sont les motifs objectifs, pertinents, pour empêcher les cycles ? » En réalité, selon le modèle que je vous ai proposé, on se rend compte qu’il y a deux chemins possibles permettant de « naviguer » entre les tables CLIENT et LIGNE_FABRICATION. On pourrait donc m’objecter qu’à partir de la ligne de fabrication "Ligne 1", on peut « remonter » directement au client « Ets Naudin » grâce au lien connectant les deux tables, mais aussi en prenant le chemin des écoliers, c'est-à-dire en passant par la table CONTACT_CLIENT. En fait, dans l’autre sens, avec le diagramme que je propose, on établit la liste des contacts chez chaque client, et seulement après on choisira parmi ces contacts celui qui sera retenu pour telle ligne de fabrication, et il ne sera pas possible qu’un contact du client Dubicobit soit associé à une ligne de fabrication qui ne soit pas pour Dubicobit : en effet, l’attribut ClientId ne figure qu’une fois dans l’en-tête de la table LIGNE_FABRICATION.

Ainsi, essayez d’associer un contact Dubicobit et une ligne de fabrication Naudin, par exemple avec le jeu d’essai qui suit, en association avec les tables SQL que j’ai proposées dans mon message précédent.

Table CLIENT

Code SQL :

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

1
2
3
4
INSERT INTO CLIENT (ClientId, ClientRaisonSociale) VALUES (1, 'Ets Naudin') ;
INSERT INTO CLIENT (ClientId, ClientRaisonSociale) VALUES (2, 'Dubicobit SA') ;
 
SELECT '' AS CLIENT, * FROM CLIENT ;

Table COLLABORATEUR

Code SQL :

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

1
2
3
4
5
6
7
INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (1, 'Freddy') ;
INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (2, 'Tomate') ;
INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (3, 'Léon') ;
INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (4, 'Mado') ;
INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (5, 'Vincent') ; 
 
SELECT '' AS COLLABORATEUR, * FROM COLLABORATEUR ;

Table CONTACT_CLIENT

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (1, 1, 'Me Folace') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (1, 2, 'Pascal') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (1, 3, 'Bastien') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (1, 4, 'Jean') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (1, 5, 'Henri') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (2, 1, 'Albert') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (2, 2, 'Bernard') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (2, 3, 'Carole') ;
 
SELECT '' AS CONTACT_CLIENT, * FROM CONTACT_CLIENT ;

Table LIGNE_FABRICATION

Code SQL :

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

1
2
3
4
5
6
7
8
9
INSERT INTO LIGNE_FABRICATION (LigneFabId, ClientId, LigneFabLibelle, ClientContactId, CollabCialId, CollabTecId) 
       VALUES (1, 1, 'Ligne 1', 1, 1, 2) ;
 
SELECT ClientRaisonSociale, LigneFabLibelle, ClientContactNom AS ContactClient, t.CollabNom AS CollabCommercial, u.CollabNom AS CollabTechnique
FROM   LIGNE_FABRICATION AS x 
           INNER JOIN CONTACT_CLIENT AS y ON x.ClientId = y.ClientId AND x.ClientContactId = y.ClientContactId
           INNER JOIN CLIENT AS z ON x.ClientId = z.ClientId 
           INNER JOIN COLLABORATEUR AS t ON x.CollabCialId = t.CollabId
           INNER JOIN COLLABORATEUR AS u ON x.CollabTecId = u.CollabId ;

Il faudrait apparemment enlever la relation entre CONTACT_CLIENT et CLIENT puisque pour retrouver à quel CLIENT appartient un CONTACT_CLIENT, la relation passant par LIGNE_FAB suffirait.

Oui, mais c’est plutôt du travail sans filet : il devient facile d’associer Pascal (de chez Naudin) au client Dubicobit, via un branchement à tort de Pascal sur une ligne de fabrication Dubicobit. Avec ce système, il faut avoir une très grande confiance en la rigueur de l’utilisateur, c’est un peu un acte de foi, sinon de la dynamite.

Un collaborateur (CONTACT_BI) est toujours commerciale ou toujours technique peu importe les lignes de productions.

Selon votre 1er message, pour une ligne de fabrication on a un contact commercial et un contact technique. Selon votre dernier diagramme, il n’y a plus désormais qu’un seul contact : soit commercial soit technique. Est-ce bien ce que vous voulez ?

[Superkoala42]

Bonjour à tous .

Je viens de me faire avoir par le Forum après plus d'une heure de rédaction, j'ai par malchance ouvert ma pièce jointe en prévisu puis fermé la fenêtre.. Ce qui ne m'a pas ramené sur mon post en cours d'édition.

Tanpis on reprend les mêmes et on recommence.

Tout d'abord merci François pour ces réponses constructives.

Envoyé par Superkoala42
une association de 1 TO 1.N, donne forcément une FK.

Envoyé par Superkoala42
j'ai pu récolter quelques avis sur ce modèle auprès de mes collègues de formation.
Ces personnes m' ont suggérées de ne pas faire de boucle dans un modèle (Comme pour CONTACT_CLIENT, CLIENT, LIGNE_FAB). Vrai ou FAUX?

Avec vos explications et lors de la création en BDD du modèle j'ai pu m’apercevoir que l'attribut ClientId à la fois PK et FK de CONTACT_CLIENT était essentiel au bon fonctionnement de la BDD.
En effet, si cette relation n'existe pas, un contact_client peut à la fois appartenir à une ligne de fabrication d'un CLIENT 1 et à une ligne de fabrication d'un CLIENT 2.

Voir Imprime Ecran :



J'ai par contre une petite zone d'ombre sur la table CONTACT_BI (Anciennement COLLABORATEUR).
Via une requête SQL il n'est apparement pas possible de savoir si un CONTACT_BI est un commercial ou un technicien. Je me trompe peut-être.

En rapport avec tout cela, j'ai du mal à comprendre ceci :

SELECT ClientRaisonSociale, LigneFabLibelle, ClientContactNom AS ContactClient, t.CollabNom AS CollabCommercial, u.CollabNom AS CollabTechnique
FROM LIGNE_FABRICATION AS x
INNER JOIN CONTACT_CLIENT AS y ON x.ClientId = y.ClientId AND x.ClientContactId = y.ClientContactId
INNER JOIN CLIENT AS z ON x.ClientId = z.ClientId
INNER JOIN COLLABORATEUR AS t ON x.CollabCialId = t.CollabId
INNER JOIN COLLABORATEUR AS u ON x.CollabTecId = u.CollabId ;

Dernière chose, dans la table LIGNE_FAB est t'il possible d'avoir une PK composé de LigneFabId et ClientId.
Dans la table, CONTACT_CLIENT il est intéressant d'avoir :

Client 1 - Contact 1
Client 1 - Contact 2
Client 2 - Contact 1
Client 2 - Contact 2
Client 2 - Contact 3
Client 3 - Contact 1

Il serait intéressant d'avoir la même chose pour ligne de fabrication :

Client 1 - ligneFab 1
Client 1 - ligneFab 2
Client 2 - ligneFab 1

Qu'en pensez vous??

Bonne journée à tous et merci de votre aide .

[fsmrel]

Bonsoir Alexandre,

En effet, si cette relation n'existe pas, un contact_client peut à la fois appartenir à une ligne de fabrication d'un CLIENT 1 et à une ligne de fabrication d'un CLIENT 2.

Il faudra expliquer cela à vos collègues de formation, ça pourra leur servir...

J'ai par contre une petite zone d'ombre sur la table CONTACT_BI (Anciennement COLLABORATEUR).
Via une requête SQL il n'est apparemment pas possible de savoir si un CONTACT_BI est un commercial ou un technicien. Je me trompe peut-être.

Selon votre dernier diagramme, l’en-tête de la table CONTACT_BI contient un attribut TypeContactBI qui devrait vous permettre de savoir de quel type est le seul et unique contact « maison » (si vous avez défini cet attribut pour cela) :

En rapport avec tout cela, j'ai du mal à comprendre ceci :

SELECT ClientRaisonSociale, LigneFabLibelle, ClientContactNom AS ContactClient, t.CollabNom AS CollabCommercial, u.CollabNom AS CollabTechnique
FROM LIGNE_FABRICATION AS x
INNER JOIN CONTACT_CLIENT AS y ON x.ClientId = y.ClientId AND x.ClientContactId = y.ClientContactId
INNER JOIN CLIENT AS z ON x.ClientId = z.ClientId
INNER JOIN COLLABORATEUR AS t ON x.CollabCialId = t.CollabId
INNER JOIN COLLABORATEUR AS u ON x.CollabTecId = u.CollabId ;

Il s’agit de la requête qui permet de tout savoir sur chaque ligne de fabrication, notamment qui en est le contact commercial (CollabCialId) et qui en est le contact technique (CollabTecId), sur la base du diagramme que je vous ai déjà fourni, selon lequel on a un contact commercial et un contact technique :





Pour savoir qui est le contact commercial :

FROM LIGNE_FABRICATION AS x ... INNER JOIN COLLABORATEUR AS t ON x.CollabCialId = t.CollabId

Pour savoir qui est le contact technique :

FROM LIGNE_FABRICATION AS x ... INNER JOIN COLLABORATEUR AS u ON x.CollabTecId = u.CollabId

Il serait intéressant d'avoir la même chose pour ligne de fabrication :

Client 1 - ligneFab 1
Client 1 - ligneFab 2
Client 2 - ligneFab 1

Aucun problème, il suffit de rendre identifiante l’association connectant les tables CLIENT et LIGNE_FABRICATION.


N.B. En passant, n’hésitez pas à voter quand ne réponse vous a apporté quelque chose, sinon on se demande si on n'est pas parfois un peu trop hermétique...

[Superkoala42]

Bonjour François,

Selon votre dernier diagramme, l’en-tête de la table CONTACT_BI contient un attribut TypeContactBI qui devrait vous permettre de savoir de quel type est le seul et unique contact « maison » (si vous avez défini cet attribut pour cela) :

Ma question fessait référence à votre diagramme :

Pièce jointe 139210

Si je me place dans la table CONTACT_BI, il m'est apparemment impossible de connaître le type de chaqu'un des contacts.
A savoir qu'il est possible qu'un CONTACT_BI change de statut entre "Technique" et "Commercial".

Par contre si je me place dans mon modèle avec l'attribut TypeContactBI, comme vous venez de me le dire, il est possible de connaître le type de chaque contact directement dans la table.
Mais je ne vois pas comment associer à LIGNE_FAB deux FK pour le commercial et pour le technique.

Autre chose, il serait peut-être possible que pour un petit client, seulement un commercial sois affecté à une LIGNE_FAB (Au lieu d'un commercial et d'un technicien).
Je pense que ceci est actuellement géré par la cardinalité 0-N côté ligne de fabrication sur votre modèle (Je n'ai pas encore testé en BDD).

Aucun problème, il suffit de rendre identifiante l’association connectant les tables CLIENT et LIGNE_FABRICATION.

Pas de soucis, je vais faire tout ça .

N.B. En passant, n’hésitez pas à voter quand ne réponse vous a apporté quelque chose, sinon on se demande si on n'est pas parfois un peu trop hermétique...

Pas de soucis mais j'avais pourtant bien fait attention à UP Vote..

[fsmrel]

Bonsoir Alexandre,

Ma question faisait référence à votre diagramme :
Pièce jointe 139210

Il y a un problème de lien, j’ai droit à un message : « Pièce jointe spécifié(e) non valide. »

Si je me place dans mon modèle avec l'attribut TypeContactBI, comme vous venez de me le dire, il est possible de connaître le type de chaque contact directement dans la table.
Mais je ne vois pas comment associer à LIGNE_FAB deux FK pour le commercial et pour le technique.

Je reprends le diagramme que je vous ai déjà proposé :




Avec les INSERT dans les tables SQL correspondantes :

Table CLIENT

Code SQL :

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

1
2
3
4
5
6
INSERT INTO CLIENT (ClientId, ClientRaisonSociale) VALUES (1, 'Ets Naudin') ;
INSERT INTO CLIENT (ClientId, ClientRaisonSociale) VALUES (2, 'Dubicobit SA') ;
INSERT INTO CLIENT (ClientId, ClientRaisonSociale) VALUES (3, 'Cours Sautrot') ;
INSERT INTO CLIENT (ClientId, ClientRaisonSociale) VALUES (4, 'fsmrel') ;
 
SELECT '' AS CLIENT, * FROM CLIENT ;

Table CONTACT_CLIENT

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (1, 1, 'Me Folace') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (1, 2, 'Pascal') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (1, 3, 'Bastien') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (1, 4, 'Jean') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (1, 5, 'Henri') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (2, 1, 'Albert') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (2, 2, 'Bernard') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (2, 3, 'Carole') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (3, 1, 'Mimile') ;
INSERT INTO CONTACT_CLIENT (ClientId, ClientContactId, ClientContactNom) VALUES (4, 1, 'fsmrel') ;
 
SELECT '' AS CONTACT_CLIENT, * FROM CONTACT_CLIENT ;

Table COLLABORATEUR

Code SQL :

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

1
2
3
4
5
6
7
INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (1, 'Freddy') ;
INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (2, 'Tomate') ;
INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (3, 'Léon') ;
INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (4, 'Mado') ;
INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (5, 'Vincent') ; 
 
SELECT '' AS COLLABORATEUR, * FROM COLLABORATEUR ;

Lignes de fabrication :

Pour la ligne de fabrication 1 (« Ligne droite »), le client est « Ets Naudin », le contact du client est Me Folace, le commercial de la maison est Freddy, le technicien est Tomate :

Table LIGNE_FABRICATION

Code SQL :

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

1
2
INSERT INTO LIGNE_FABRICATION (LigneFabId, ClientId, LigneFabLibelle, ClientContactId, CollabCialId, CollabTecId) 
       VALUES (1, 1, 'Ligne droite', 1, 1, 2) ;

Pour la ligne de fabrication 2 (« Ligne courbe »), le client est « Cours Sautrot », le contact du client est Mimile, le commercial de la maison est Mado, le technicien est aussi Mado :

Table LIGNE_FABRICATION

Code SQL :

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

1
2
INSERT INTO LIGNE_FABRICATION (LigneFabId, ClientId, LigneFabLibelle, ClientContactId, CollabCialId, CollabTecId) 
       VALUES (2, 3, 'Ligne courbe', 1, 4, 4) ;

Pour la ligne de fabrication 3 (« Ligne bleue »), le client est « Dubicobit SA », le contact du client est Albert, le commercial de la maison est Freddy, le technicien est Vincent :

Table LIGNE_FABRICATION

Code SQL :

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

1
2
INSERT INTO LIGNE_FABRICATION (LigneFabId, ClientId, LigneFabLibelle, ClientContactId, CollabCialId, CollabTecId) 
       VALUES (3, 2, 'Ligne bleue', 1, 1, 5) ;

Avec la requête suivante :

Code SQL :

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

1
2
3
4
5
6
SELECT ClientRaisonSociale, LigneFabLibelle, ClientContactNom AS ContactClient, t.CollabNom AS CollabCommercial, u.CollabNom AS CollabTechnique
FROM   LIGNE_FABRICATION AS x 
           INNER JOIN CONTACT_CLIENT AS y ON x.ClientId = y.ClientId AND x.ClientContactId = y.ClientContactId
           INNER JOIN CLIENT AS z ON x.ClientId = z.ClientId 
           INNER JOIN COLLABORATEUR AS t ON x.CollabCialId = t.CollabId
           INNER JOIN COLLABORATEUR AS u ON x.CollabTecId = u.CollabId ;

Au résultat :

Code :

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

1
2
3
4
5
6
 
ClientRaisonSociale    LigneFabLibelle    ContactClient    CollabCommercial    CollabTechnique
-------------------   ----------------    -------------    ----------------    ---------------
Ets Naudin             Ligne droite       Me Folace        Freddy              Tomate
Cours Sautrot          Ligne courbe       Mimile           Mado                Mado
Dubicobit SA           Ligne bleue        Albert          Freddy               Vincent

Il serait peut-être possible que pour un petit client, seulement un commercial soit affecté à une LIGNE_FAB (Au lieu d'un commercial et d'un technicien).

On peut ajouter un collaborateur « fantôme » :

Code SQL :

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

INSERT INTO COLLABORATEUR (CollabId, CollabNom) VALUES (0, '/') ;

Pour la ligne de fabrication 5 (« Ligne rouge »), le client est fsmrel (qui est en même temps contact), le collaborateur commercial est Mado et il n’y a pas de contact technique :

Table LIGNE_FABRICATION

Code SQL :

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

1
2
INSERT INTO LIGNE_FABRICATION (LigneFabId, ClientId, LigneFabLibelle, ClientContactId, CollabCialId, CollabTecId) 
       VALUES (4, 4, 'Ligne rouge', 1, 4, 0) ;

Au résultat du SELECT précédent :

Code :

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

1
2
3
4
5
6
7
 
ClientRaisonSociale    LigneFabLibelle    ContactClient    CollabCommercial    CollabTechnique
-------------------   ----------------    -------------    ----------------    ---------------
Ets Naudin             Ligne droite       Me Folace        Freddy              Tomate
Cours Sautrot          Ligne courbe       Mimile           Mado                Mado
Dubicobit SA           Ligne bleue        Albert           Freddy              Vincent 
fsmrel                 Ligne rouge        fsmrel           Mado                /