Un peu d'aide, Ligne de Fabrication

Version imprimable

03/02/2014, 12h40
Superkoala42

Un peu d'aide, Ligne de Fabrication

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.
03/02/2014, 18h19
fsmrel

Bonsoir Alexandre,

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

http://www.fsmwarden.com/developpez_...abrication.png

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 !
04/02/2014, 10h27
Superkoala42

Revoir le sujet V2

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/thumb/73584.jpeg

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.
04/02/2014, 12h18
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

Bonsoir Alexandre et Dominique,

Citation:

Envoyé par Superkoala42

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>) :

http://www.fsmwarden.com/developpez_...cation_MLD.png

Version MySQL Workbench :

http://www.fsmwarden.com/developpez_...cation_MWB.png

Clé étrangère :

http://www.fsmwarden.com/developpez_...NE_CLI_MWB.png

Citation:

Envoyé par Superkoala42

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 :

http://www.fsmwarden.com/developpez_...CT_CLI_MWB.png

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

Contacts clients :

http://www.fsmwarden.com/developpez_...ct_Cli_MWB.png

Contacts commerciaux :

http://www.fsmwarden.com/developpez_...t_Cial_MWB.png

Contacts techniques :

http://www.fsmwarden.com/developpez_...t_Tech_MWB.png

Citation:

Envoyé par Superkoala42

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

http://www.fsmwarden.com/developpez_...oala42_MCD.png

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.

Citation:

Envoyé par dde63

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.

Citation:

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:

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.

04/02/2014, 18h47
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
05/02/2014, 14h52
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...

Citation:

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).

Citation:

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 :mrgreen:!!
06/02/2014, 14h13
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.
06/02/2014, 14h58
fsmrel

Bonjour Alexandre,

Citation:

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 » ?
06/02/2014, 15h16
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?

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:

http://www.fsmwarden.com/developpez_...cation_MWB.png
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:

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.

24/02/2014, 16h52
Superkoala42

2 pièce(s) jointe(s)

Des news

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) :

Pièce jointe 138855

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

Citation:

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?

Pièce jointe 138859

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.

Bonsoir Alexandre,

Citation:

Envoyé par Superkoala42

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.

Citation:

Envoyé par Superkoala42

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.

Citation:

Envoyé par Superkoala42

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.

Citation:

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?

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:

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:

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:

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:

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 ;
Citation:

Envoyé par Superkoala42

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.

Citation:

Envoyé par Superkoala42

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 ?

27/02/2014, 16h19
Superkoala42

1 pièce(s) jointe(s)

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.

Citation:

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

Citation:

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 :

Pièce jointe 139147

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 :

Citation:

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 :D.
27/02/2014, 22h52
fsmrel

Bonsoir Alexandre,

Citation:

Envoyé par Superkoala42

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...:P

Citation:

Envoyé par Superkoala42

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) :

http://www.fsmwarden.com/developpez_...n_MWB_by_S.png

Citation:

Envoyé par Superkoala42

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 :

http://www.fsmwarden.com/developpez_...ateurs_MWB.png

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

Citation:

Envoyé par Superkoala42

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... :koi:
28/02/2014, 11h49
Superkoala42

Bonjour François,

Citation:

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).

Citation:

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 :).

Citation:

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..

Bonsoir Alexandre,

Citation:

Envoyé par Superkoala42

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. »

Citation:

Envoyé par Superkoala42

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é :

http://www.fsmwarden.com/developpez_...eurs_MWB_2.png

Avec les INSERT dans les tables SQL correspondantes :

Table CLIENT
Code:

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:

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:

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:

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:

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:

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:

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:

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
Citation:

Envoyé par Superkoala42

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:

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:

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:

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 /