Remplir les colonnes d'une table 2 à partir d'informations présentes dans une table 1

**Gildas 216** · 20/01/2016, 20h23

Bonjour,

Dans mon modèle conceptuel de données, des tables sont liées par des attributs.
Je n'arrive pas à remplir "automatiquement" les attributs (colonnes) qui dépendent de l'autre table.
J'ai essayé la fonction INSERT INTO et ma colonne se remplit mais impossible de la mettre à jour avec UPDATE quand la première table est modifiée.

Par exemple la table EVOLUTION (CodContrat, DateDebutEvol, SalaireActuel, NiveauHierarchique, EvolutionAjout, CodCertif) implique le "remplissage automatique" de l'attribut DateDebutEvol présent dans la table CONTRAT (CodContrat, NiveauHierarchique, SalaireMensuel, TypeContrat, DateDebutEvol, DateDebutContrat).

J'ai utilisé (je code en php):
$query="INSERT INTO CONTRAT (DateDebutEvol) SELECT DateDebutEvol FROM EVOLUTION"; et ma colonne de DateDebutEvol de CONTRAT se remplit.
Or quand je change les dates dans EVOLUTION impossible d'avoir une MàJ dans CONTRAT.. j'ai essayé :
$query="UPDATE CONTRAT SET EVOLUTION.DateDebutEvol=CONTRATO.DateDebutEvol FROM EVOLUTION"; mais rien n'y fait...

Si quelqu'un pouvait m'éclairer, ça m'aiderait grandement !

Merci énormément d'avance!!

**Artemus24** · 21/01/2016, 01h12

Salut à tous.

En MySql, on ne nomme pas cela des attributs mais des colonnes !

Vous avez deux tables, l'une de nom "evolution" et l'autre de nom "contrat".
Vous désirez remplir automatiquement la colonne "DateDebutEvol" de la table "evolution" à partir de la table "contrat". Jusque là, tout va bien !

Envoyé par Gildas 216

Or quand je change les dates dans EVOLUTION impossible d'avoir une MàJ dans CONTRAT...

Votre demande n'est pas très logique !!!

Ce que vous demandez, c'est rendre automatique la modification de la colonne "DateDebutEvol" :
--> soit automatiquement dans le sens "contrat" vers "evolution".
--> soit automatiquement dans le sens inverse, c'est-à-dire de "evolution" vers "contrat".

On ne peut pas le faire automatiquement dans les deux sens.
Il faut choisir laquelle de ces deux tables va servir de référence.

Autrement dit, l'une des tables devra être modifiée manuellement. Ce sera votre table référence.
Et suite à cette modification (de la table référence), il y aura une répercussion automatique vers l'autre table.
La résolution de la répercussion automatique se fait par un trigger.

Avant de vous donner le trigger, vous devez résoudre ce problème logique de conception.

@+

**escartefigue** · 21/01/2016, 09h06

Envoyé par Gildas 216

Dans mon modèle conceptuel de données, des tables sont liées par des attributs.
Je n'arrive pas à remplir "automatiquement" les attributs (colonnes) qui dépendent de l'autre table.

Envoyé par Artemus24

En MySql, on ne nomme pas cela des attributs mais des colonnes !

Gildas parle de son MCD, "attribut" est un synonyme de "propriété" tout a fait approprié dans ce cas
S'il faut ergoter sur le vocabulaire, alors c'est le terme de "table" qui est inadéquat au niveau conceptuel : le MCD ne connait que des entités-type et des relations (ou associations).
Mais je pense que malgré cette entorse (fréquente) aux bons usages, tout le monde aura compris la question

Sur le fond, il y a redondance d'information, le plus simple et le plus propre serait de la supprimer, ainsi la question ne se pose plus, et le modèle de données est propre

**Gildas 216** · 21/01/2016, 10h23

Bonjour,

Merci pour vos réponses! Merci pour cette précision de langage, en effet si je parle me mySql je dois parler de colonne et en MDC d'entité à la place de table.

Envoyé par Artemus24

Autrement dit, l'une des tables devra être modifiée manuellement. Ce sera votre table référence.
Et suite à cette modification (de la table référence), il y aura une répercussion automatique vers l'autre table.
La résolution de la répercussion automatique se fait par un trigger.

La table de référence que je souhaite choisir (où rentrer manuellement les données) est la table EVOLUTION car dans la logique de mon projet, on rentre une évolution qui va se répercuter sur le CONTRAT (augmentation de salaire par exemple..).

Envoyé par escartefigue

Sur le fond, il y a redondance d'information, le plus simple et le plus propre serait de la supprimer, ainsi la question ne se pose plus, et le modèle de données est propre

Je n'ai pas compris ce qu'il faut que je supprime...?

Merci de votre aide,

@+

**escartefigue** · 21/01/2016, 10h36

Envoyé par Gildas 216

Je n'ai pas compris ce qu'il faut que je supprime...?

Vous avez 2 fois la même information dans 2 tables différentes, il ne faut la conserver que dans la table où elle est pertinente

**escartefigue** · 21/01/2016, 17h39

Envoyé par Gildas 216

Bonjour,
La table de référence que je souhaite choisir (où rentrer manuellement les données) est la table EVOLUTION car dans la logique de mon projet, on rentre une évolution qui va se répercuter sur le CONTRAT (augmentation de salaire par exemple..).

Je n'ai pas compris ce qu'il faut que je supprime...?

En complément de mes réponses précédentes, vu ce que j'ai mis en rouge dans votre post précédent ci-dessus, il faut supprimer la colonne "DateDebutEvol" de la table contrat puisque c'est un attribut lié à une évolution particulière et non au contrat en général. C'est même une partie de la clef de votre table évol.
Le fait comme vous le mentionnez qu'une évolution ait des conséquences sur le contrat ne doit pas vous conduire à faire des entorses aux formes normales Merise en dupliquant des attriuts.
Les conséquences sur le salaire ou autres seront gérées par traitement.

Idéalement, supprimez la colonne de la table contrat, à défaut, (si vous n'avez pas les droits pour modifier la structure de la table) ne l'utilisez pas et demandez sa suppression à la personne en charge.

De plus, il est préférable d'avoir une clef non sémantique et stable : si vous n'êtes pas certains que le date de début d'évol ne peut pas changer, il est préférable d'utiliser une clef technique (par exemple un chrono attribué automatiquement) et gérer la date d'évolution comme un attribut non clef.

**Gildas 216** · 23/01/2016, 19h00

Envoyé par escartefigue

Idéalement, supprimez la colonne de la table contrat, à défaut, (si vous n'avez pas les droits pour modifier la structure de la table) ne l'utilisez pas et demandez sa suppression à la personne en charge.

Merci Escartefigue pour ces précisions, c'est vrai que c'est une mauvaise traduction du MDC aux tables.. je vais donc le supprimer de contrat. Merci de cette correction.

Envoyé par escartefigue

De plus, il est préférable d'avoir une clef non sémantique et stable : si vous n'êtes pas certains que le date de début d'évol ne peut pas changer, il est préférable d'utiliser une clef technique (par exemple un chrono attribué automatiquement) et gérer la date d'évolution comme un attribut non clef.

J'ai pas tout compris... sur mon MDC c'est le code contrat croisé avec la date d'évol qui fait la clé primaire.. mais du coup dans ma table Evol c'est seulement le code contrat la clé primaire...
C'est possible d'avoir le code contrat comme clé primaire de plusieurs tables??

Merci de ton temps et de tes précisions qui me sont très utiles!
@+

**Artemus24** · 21/01/2016, 20h08

Salut à tous.

Et voici le trigger qui va répercuter la modification de la colonne 'dateDebutEvol' de la table 'evolution' vers 'contrat'.
C'est juste quelque chose de très basique. Si tu veux ajouter plus de contrôle, tu peux me formuler ta demande.

Code :

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
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE IF NOT EXISTS `base`
        DEFAULT CHARACTER SET `latin1`
        DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `evolution`
--------------
 
--------------
CREATE TABLE `evolution`
(
  `codContrat`         int UNSIGNED   NOT NULL PRIMARY KEY,
  `dateDebutEvol`      date           NOT NULL,
  `salaireActuel`      decimal(10,2)  NOT NULL,
  `niveauHierarchique` char(10)       NOT NULL,
  `evolutionAjout`     char(10)       NOT NULL,
  `codCertif`          char(01)       NOT NULL
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
insert into `evolution` (`codContrat`, `dateDebutEvol`, `salaireActuel`, `niveauHierarchique`, `evolutionAjout`, `codCertif`) values
  (15, '2015-05-01', 1800.0, 'employé', '???', '+'),
  (75, '2015-10-01', 3500.0, 'chef',    '???', '+')
--------------
 
--------------
select * from `evolution`
--------------
 
+------------+---------------+---------------+--------------------+----------------+-----------+
| codContrat | dateDebutEvol | salaireActuel | niveauHierarchique | evolutionAjout | codCertif |
+------------+---------------+---------------+--------------------+----------------+-----------+
|         15 | 2015-05-01    |       1800.00 | employé            | ???            | +         |
|         75 | 2015-10-01    |       3500.00 | chef               | ???            | +         |
+------------+---------------+---------------+--------------------+----------------+-----------+
--------------
DROP TABLE IF EXISTS `contrat`
--------------
 
--------------
CREATE TABLE `contrat`
(
  `codContrat`         int UNSIGNED   NOT NULL PRIMARY KEY,
  `niveauHierarchique` char(10)       NOT NULL,
  `salaireMensuel`     decimal(10, 2) NOT NULL,
  `typeContrat`        char(04)       NOT NULL,
  `dateDebutEvol`      date           NOT NULL,
  `dateDebutContrat`   date           NOT NULL
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
insert into `contrat` (`codContrat`, `niveauHierarchique`, `salaireMensuel`, `typeContrat`, `dateDebutEvol`, `dateDebutContrat`) values
  (15, 'employé', 1500.0, 'cdi', '2015-05-01', '2012-05-01')
--------------
 
--------------
select * from `contrat`
--------------
 
+------------+--------------------+----------------+-------------+---------------+------------------+
| codContrat | niveauHierarchique | salaireMensuel | typeContrat | dateDebutEvol | dateDebutContrat |
+------------+--------------------+----------------+-------------+---------------+------------------+
|         15 | employé            |        1500.00 | cdi         | 2015-05-01    | 2012-05-01       |
+------------+--------------------+----------------+-------------+---------------+------------------+
--------------
DROP TRIGGER IF EXISTS `modif_dateDebutEvol`
--------------
 
--------------
CREATE TRIGGER `modif_dateDebutEvol`
BEFORE update ON `evolution`
FOR EACH ROW BEGIN
  update contrat set dateDebutEvol = new.dateDebutEvol;
END
--------------
 
--------------
update `evolution` set `dateDebutEvol` = '2016-01-01' where codContrat = 15
--------------
 
--------------
select * from `evolution`
--------------
 
+------------+---------------+---------------+--------------------+----------------+-----------+
| codContrat | dateDebutEvol | salaireActuel | niveauHierarchique | evolutionAjout | codCertif |
+------------+---------------+---------------+--------------------+----------------+-----------+
|         15 | 2016-01-01    |       1800.00 | employé            | ???            | +         |
|         75 | 2015-10-01    |       3500.00 | chef               | ???            | +         |
+------------+---------------+---------------+--------------------+----------------+-----------+
--------------
select * from `contrat`
--------------
 
+------------+--------------------+----------------+-------------+---------------+------------------+
| codContrat | niveauHierarchique | salaireMensuel | typeContrat | dateDebutEvol | dateDebutContrat |
+------------+--------------------+----------------+-------------+---------------+------------------+
|         15 | employé            |        1500.00 | cdi         | 2016-01-01    | 2012-05-01       |
+------------+--------------------+----------------+-------------+---------------+------------------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
 
Appuyez sur une touche pour continuer...

@+

**Gildas 216** · 23/01/2016, 19h38

Envoyé par Artemus24

Et voici le trigger qui va répercuter la modification de la colonne 'dateDebutEvol' de la table 'evolution' vers 'contrat'.
C'est juste quelque chose de très basique. Si tu veux ajouter plus de contrôle, tu peux me formuler ta demande.

Merci Artemus24 pour le trigger!!
C'est vrai que ce problème a été résolu par le fait que cet attribut était dupliqué dans deux tables!
Mais du coup, j'ai quand même une autre demande :

[Revoilà mes tables corrigées :
EVOLUTION (CodContrat, DateDebutEvol, SalaireActuel, NiveauHierarchique, EvolutionAjout, CodCertif)
CONTRAT (CodContrat, NiveauHierarchique, SalaireMensuel, TypeContrat, DateDebutContrat)]

Quand je rentre une évolution, je dois rentrer le SalaireActuel et j'aimerais qu'il me donne celui qui a été rentré dans contrat initialement (càd le SalaireMensuel) ... c'est possible ça ?
Et qu'après dans la table CONTRAT soit "remplacé" (ou calculé) le SalaireMensuel par le : SalaireActuel+EvolutionAjout.

Déjà, est-ce possible de le faire et ensuite?
Avec un tag comme :
INPUT INTO CONTRAT (SalaireMensuel) VALUES (SELECT SUM(SalaireActuel,EvolutionAjout) FROM EVOLUTION);

Merci pour votre aide,
@+

**Artemus24** · 23/01/2016, 20h57

Salut Gildas_216

Reprenons le problème. Ce qui me dérange, c'est que tu as deux tables, l'une "contrat" et l'autre "evolution" alors que tu pourrais en faire une seule.

Ce que tu nommes "evolution" est en fait un "avenant". Et un avenant, c'est ni plus ni moins qu'un nouveau contrat, que l'on a fait évolué.
Alors ma question, c'est pourquoi ne pas créer une nouvelle ligne dans la table contrat, qui serait du genre "annule et remplace le précédant contrat" ?
Bien sûr, la table evolution n'existe plus.

Code :

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

1
2
EVOLUTION (CodContrat, DateDebutEvol, SalaireActuel,  NiveauHierarchique,                                EvolutionAjout, CodCertif) 
CONTRAT   (CodContrat, DateDebutEvol, SalaireMensuel, NiveauHierarchique, TypeContrat, DateDebutContrat).

J'ai cadrer tes colonnes de tes deux tables, et tu as quatre colonnes communes.

Je propose plutôt ceci :

Code :

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

1
2
 
CONTRAT   (CodContrat, rang, DateDebutContrat, SalaireMensuel, NiveauHierarchique, TypeContrat, CodCertif).

--> Rang : permet de numéroter pour le même contrat, les diverses ajouts.
Rang=1, désigne le contrat d'origine. Les autres rang sont les évolutions de ton contrat précédent.
Autrement dit, rang=3, vient en annulation et en remplacement de rang=1 et rang=2.

--> DateDebutEvol a été remplacée par la colonne "DateDebutContrat".
Si rang=1, c'est la date d'entrée dans la société.
Pour le même contrat, et pour rang>1 ce sont des avenants, mais l'employé est toujours présent dans la société.
Donc cette colonne a deux significations, celle de la date d'entrée dans la société, et celle de la modification de son contrat.

--> SalaireMensuel, c'est le salaire de l'avenant. Même singification que "SalaireActuel".
Si l'employé a une promotion, genre il passe d'employé à chef, il a un nouveau contrat, avec un nouveau salaire.

--> NiveauHierarchique, gérer comme avant.

--> TypeContrat, gérer comme avant.

--> EvolutionAjout ne sert à rien.
S'il n'y a pas d'avenant alors dans la table, pour un contrat donné, il n'y a qu'une ligne --> RANG=1.
S'il y a un ou plusieurs avenant, alors RANG > 1.

--> CodCertif, j'ai pas compris à quoi sert cette colonne.

Il manque la date de fin du contrat, pour signifier que l'employé n'appartient plus à la société.
Peut-être créer un nouvel avenant de RANG=n avec une "dateDebutContrat" à null, pour signifier que c'est la fermeture du contrat.

Donc pour répondre à ta question, il suffit de récupérer la dernière ligne de ton contrat et ensuite de la modifier avant de l'insérer en faisant rang=rang+1.
Cela évite de faire des triggers qui viennent alourdir le traitement sans raison valable.

Une mauvaise modélisation de ta base de données va créer une usine à gaz dans tes traitements.

@+

**escartefigue** · 24/01/2016, 09h59

Envoyé par Gildas 216

C'est vrai que ce problème a été résolu par le fait que cet attribut était dupliqué dans deux tables

En effet, le respect des règles Merise de base évite bien des soucis

Envoyé par Artemus24

Une mauvaise modélisation de ta base de données va créer une usine à gaz dans tes traitements

Vous y voilà, vous rejoignez ce que j'indique depuis mon 1er post : il ne faut pas dupliquer l'information que ce soit par des triggers ou autrement
Ce faisant ce n'est pas cohérent avec vos votes
Le vote ne doit pas refléter une mauvaise humeur passagère, mais la pertinence de la réponse par rapport à la question souhaitée

**Artemus24** · 25/01/2016, 14h56

Salut Escartefigue.

Envoyé par Escartefigue

Vous y voilà, vous rejoignez ce que j'indique depuis mon 1er post : il ne faut pas dupliquer l'information que ce soit par des triggers ou autrement

Je ne dis pas le contraire.
Dans mon premier message, j'ai indiqué que cela me paraissait bizarre de faire des aller-retour entre deux tables, pour gérer une colonne.
Ensuite, j'ignore le niveau de compétence de Gildas 216, ni les contraintes fonctionnelles qu'il a. Et toute la question est là !

La demande du sujet consiste à trouver une solution à son problème, le mieux est de lui donner un semblant de réponse ! le trigger.

Ma grande interrogation concerne les conseils que l'on peut lui donner et qui ne correspondent pas à sa première attente.
Si la solution consiste à refaire de fond en comble son MCD, il sera forcément déçu par notre intervention. Et ce n'est pas le genre de réponse qu'il attend.
Il se trouve aussi (mais j'en sais rien), qu'il a ni la possibilité de le faire, ni le temps nécessaire, ni les moyens de procéder à ce changement.
Faire un changement de fond en comble à la fin d'un projet, ce n'est pas ce qu'il y a de plus opportun comme façon de faire.

En gros, ta réponse me semble être un hors sujet, même si tu as raison !

Envoyé par Escartefigue

Ce faisant ce n'est pas cohérent avec vos votes

Je ne me suis pas mis un '-1' à mes propres messages !

Si tu n'es pas d'accord, au lien de me mettre un '-1', tu expliques le pourquoi et le comment.
Il est bien plus constructif de montrer où se trouve l'erreur que de venir simplement critiquer telle approche.
Et je ne voie pas en quoi ton opinion serait meilleur que la mienne.
Si tu veux débattre de telle approche, je suis ouvert à toute proposition, car au final se débat va nous enrichir de chaque expérience.
Et je pense sans trop me tromper que c'est le but des forums, échanger nos connaissances !

Je considère que mal noter sans justifier le pourquoi n'est pas très constructif comme approche, d'où ma réaction.
Alors éviter de mal noter, sans te justifier.

Envoyé par Escartefigue

Le vote ne doit pas refléter une mauvaise humeur passagère, mais la pertinence de la réponse par rapport à la question souhaitée

A bon ??? Nous ne devons pas avoir la même définition de ce qui est pertinent.

Quand quelqu'un pose une question, le mieux est de répondre dans le sens qu'il attend.
J'ai souligné qu'il y avait quelque chose de bizarre et j'attendais sa réponse à ce sujet.
J'ai donné un semblant de réponse pour voir sa réaction.

J'ai eu tort d'aller dans ton sens car j'ai bien compris que ce n'est pas du tout ce qu'attendait Gildas_216 comme réponse.

Envoyé par Gildas_216

Quand je rentre une évolution, je dois rentrer le SalaireActuel et j'aimerais qu'il me donne celui qui a été rentré dans contrat initialement (càd le SalaireMensuel) ... c'est possible ça ?

En fait, il y a deux problèmes à ta demande.

L'une d'elle repose sur la conception de ta base de données et comme je l'ai indiqué dans mon dernier message, il n'est pas nécessaire d'avoir deux tables pour gérer l'évolution des contrats pour un employé donné.
Un avenant, puisqu'il s'agit de cela, consiste à reprendre le contrat et venir le modifier.
Quand la modification est faite, tu la stockes dans la table "contrat".

En ce qui concerne ta demande, pour initialiser un formulaire, le mieux est de récupérer les données dont tu as besoin, en faisant un "select" depuis la table "contrat".

Envoyé par Gildas_216

Et qu'après dans la table CONTRAT soit "remplacé" (ou calculé) le SalaireMensuel par le : SalaireActuel+EvolutionAjout.

Il s'agit de faire un update sur une table, en jointure sur une seconde table. Voici un exemple :

Code :

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
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE `base`
    DEFAULT CHARACTER SET `latin1`
    DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `evolution`
--------------
 
--------------
CREATE TABLE IF NOT EXISTS `evolution`
( `CodContrat`     integer unsigned not null,
  `SalaireActuel`  decimal (5, 2)   not null,
  `EvolutionAjout` decimal (5, 2)   not null,
  Primary Key (`codContrat`)
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
INSERT INTO `evolution` (`CodContrat`, `SalaireActuel`, `EvolutionAjout`) values
  (125, 75.47, 24.53), (347, 221.50, 125.50)
--------------
 
--------------
select * from evolution
--------------
 
+------------+---------------+----------------+
| CodContrat | SalaireActuel | EvolutionAjout |
+------------+---------------+----------------+
|        125 |         75.47 |          24.53 |
|        347 |        221.50 |         125.50 |
+------------+---------------+----------------+
--------------
DROP TABLE IF EXISTS `contrat`
--------------
 
--------------
CREATE TABLE IF NOT EXISTS `contrat`
( `CodContrat`      integer unsigned not null,
  `SalaireMensuel`  decimal (5, 2)   not null,
  Primary Key (`codContrat`)
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
INSERT INTO `contrat` (`CodContrat`, `SalaireMensuel`) values
  (125, 0), (225, 0)
--------------
 
--------------
select * from contrat
--------------
 
+------------+----------------+
| CodContrat | SalaireMensuel |
+------------+----------------+
|        125 |           0.00 |
|        225 |           0.00 |
+------------+----------------+
--------------
update     `contrat`    as c
inner join `evolution`  as e
on    e.CodContrat = c.CodContrat
 
set   c.SalaireMensuel = e.SalaireActuel + e.EvolutionAjout
where c.CodContrat = 125
--------------
 
--------------
select * from contrat
--------------
 
+------------+----------------+
| CodContrat | SalaireMensuel |
+------------+----------------+
|        125 |         100.00 |
|        225 |           0.00 |
+------------+----------------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
 
Appuyez sur une touche pour continuer...

@+

**Gildas 216** · 25/01/2016, 16h58

Bonjour,

Merci à tous les deux pour vos conseils et vos remarques qui me sont utiles et qui m'aident à avancer..
Je vous joins mon MDC pour que vous puissiez avoir une vision plus globale du projet...

La table contrat et celle évolution sont liées par une relation multiple à multiple du coup... je sais pas si j'ai le droit de supprimer complétement la table évolution...

Modelli per Di Carlo V5 pdf.pdf

**escartefigue** · 25/01/2016, 17h28

Envoyé par Gildas 216

La table contrat et celle évolution sont liées par une relation multiple à multiple du coup... je sais pas si j'ai le droit de supprimer complétement la table évolution...

Non : quand une association est en cardinalité n de part et d'autre, elle ne peut pas être supprimée. Vous aurez donc une table ayant pour clef l'identifiant de chaque patte de la relation

**Artemus24** · 25/01/2016, 18h31

Salut Gildas_216.

Même en regardant ton MCD (en italien), je ne comprends pas trop l'intérêt de dissocier les contrats et les évolutions (les avenants au contrat).
Pour moi, un avenant (ce que tu nommes évolution) et un contrat, c'est la même chose.

Il y a des petites différences, mais ne justifie pas une séparation en deux tables.
Tu conserves la cardinalité 1-N de "contrat" vers "évolution".
Mais comme ces deux tables sont de même nature, il n'y a aucune raison de les dissocier.

Comme je l'ai dit (peut-être que tu n'as pas bien compris ce que j'ai essayé de dire), la première ligne de la table correspond au contrat d'embauche.
Les autres lignes sont les évolutions de ce même contrat au cours du temps. Donc, tu retrouves les mêmes colonnes avec une évolution dans le temps.

Surtout que par la suite, tu fais en sorte de reporter les évolutions dans le contrat. Deux problèmes :

1) tu vas faire des allez-retour entre ces deux tables, juste pour stocker des informations qui vont être redondantes.
Escartefigue ou moi-même, nous sommes d'accord sur l'inutilité de cette façon de faire.
Et faire un trigger pour automatiser ces correction est une erreur !

2) en modifiant la table contrat, tu vas perdre les informations d'origine, celle du contrat d'embauche.
Il faut mieux conserver une trace de l'évolution du contrat, en n'intervenant que sur la dernière ligne.
Celle que tu vas entrer dans la nouvelle table contrat.

Et pour distinguer le contrat d'origine et les évolutions, tu ajoutes une nouvelle colonne, de nom 'rang'.
La première ligne d'un contrat aura 'rang=1', la suivante aura 'rang=2' et ainsi de suite.

Une de tes questions concerne l'initialisation de la nouvelle ligne "evolution".
Pour cela, il suffit de reprendre la ligne précédente.
Autrement dit, si tu rentres la ligne 'rang=5', et bien tu récupères la dernière stockée qui est 'rang=4'.
Et bien sûr, pour le même contrat.

@+

**Gildas 216** · 26/01/2016, 09h39

Bonjour,

Merci pour vos réponses.

J'ai tout de même quelques problèmes notamment avec le rang que Artemus24 veut insérer. Nous avons des requêtes à effectuer pour ce projet et une d'entre elles est de calculer la somme des salaires de tous les employés pour l'année actuelle, il nous faudrait donc une base commune.

Or, avec le système de rang, un employé rentré dans l'entreprise en 2011 a pu évoluer 5 fois, soit être au rang 6 en 2016 et un arrivé en 2014 ayant évolué 1 fois et être au rang 2 en 2016. Ainsi, faudrait-il ajouter une date associée au rang ? Et si un employé n'a pas évolué d'une année à l'autre (entre 2015 et 2016), comment reporter son salaire de 2015 vers 2016 par exemple, pour que la requête fonctionne ?

Merci d'avance pour le temps que vous nous accorderez, vous nous aidez vraiment dans notre projet !

@+

**Artemus24** · 26/01/2016, 20h21

Bonjour Gildas_216.

Il n'y a aucune complication avec le rang.
A priori, un employé qui est présent dans ta société possède obligatoirement un contrat d'embauche et éventuellement une ou plusieurs évolutions.

Peu importe quand il est rentré dans la société, peu importe si la dernière évolution date de plusieurs années, il te suffit de prendre le rang le plus élevé pour un numéro de contrat donné.

Autrement dit, tu récupères la dernière évolution. Il n'est pas nécessaire de créer une ligne pour chaque année.

Le problème qui se pose concerne le calcul du salaire.
Je te propose d'indiquer le salaire réel et non la variation du salaire entre deux évolutions. Cela va t'éviter de faire des calculs pour rien.

Voici un exemple de ce que tu peux obtenir pour la table des contrats :

Code :

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

1
2
3
4
5
6
7
8
+---------+------+---------------+-----------+--------------+---------+-----------+---------------+
| contrat | Rang | Date embauche |  Salaire  |    Niveau    |  Type   | Evolution |     Code      |
|         |      | / évolution   |  Mensuel  | Hiérarchique | contrat |   Ajout   | Certification |
+---------+------+---------------+-----------+--------------+---------+-----------+---------------+
|  123456 |   1  |   2010-09-01  |  1.000,00 |    Employé   |   CDI   |     0,00  |  bla bla bla  |
|  123456 |   2  |   2012-05-01  |  1.200,00 |    chef      |   CDI   |   200,00  |  bla bla bla  |
|  123456 |   3  |   2015-10-01  |  1.500,00 |  super-chef  |   CDI   |   300,00  |  bla bla bla  |
+---------+------+---------------+-----------+--------------+---------+-----------+---------------+

Nous sommes en 2016, tu récupères la dernière ligne pour un contrat donnée, soit le RANG=3.

Si une nouvelle évolution vient à se faire sur cet employé, il te suffit de récupérer la dernière ligne et de la modifier.
Et ensuite, tu l'insères dans la table en mettant RANG=4.

Envoyé par Gildas_216

Ainsi, faudrait-il ajouter une date associée au rang ?

Cette date existe déjà, c'est la date embauche / évolution. Elle a la signification de date d'embauche que pour RANG=1.

A vrai dire, le rang est superflue et fait double emploi avec cette date.
Ta clef primaire sur cette table est composé soit de (contrat ; rang) ou (contrat ; date embauche / évolution).

Envoyé par Gildas_216

comment reporter son salaire de 2015 vers 2016 par exemple, pour que la requête fonctionne ?

Comme je l'ai dit, il te suffit de récupérer la dernière ligne.

Code :

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

1
2
3
4
5
6
7
select *
from contrat as tb1
where rang = (select max(rang)
              from   contrat as tb2
              where  tb2.contrat = tb1.contrat
			  group  by tb2.contrat
             );

Envoyé par Gildas_216

vous nous aidez vraiment dans notre projet !

Un projet évolue en fonction des contraintes que l'on rencontre.
Il est parfois nécessaire de faire des retours en arrière sur des choix qui s'avèrent faux ou incomplets.
Le mieux est d'en discuter et c'est dans la confrontation des idées que jaillis la solution.

@+

**Gildas 216** · 28/01/2016, 20h29

Bonsoir,

Envoyé par Artemus24

Ta clef primaire sur cette table est composé soit de (contrat ; rang) ou (contrat ; date embauche / évolution).

Merci Artemus24 pour ces conseils concernant la table contrat.
J'ai donc modifié les attributs de cette table dans MySQL mais une question m'est venue.. comment je fais pour dire à mon serveur que la clé primaire est l'association des deux attributs (contrat ; rang).. pour l'instant ma clé primaire était le code contrat mais celui ci ne va plus suffire lorsque je vais ajouter un rang...

Merci de votre temps et de vos réponses qui me permettent d'avancer ce projet!!
@+

**Artemus24** · 29/01/2016, 00h18

Salut Gildas 216.

1) pour dire à ta table MySql que ta clef primaire utilise deux colonnes, et bien tu ajoutes ceci :

Code :

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

Primary key (`col1`, `col2`)

Et bien entendu, le primary key que tu avais placé sur la même ligne que la colonne "contrat", tu le supprimes.

2) je ne sais pas si tu vas utiliser la colonne 'rang' dans ta table, pour distinguer les différentes évolutions de ton contrat.
Cette colonne est juste technique et a pour vocation de créer une primary key qui ne produit pas de doublon.
Tu dois créer un trigger comme ci-après :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
-- ===================
-- Trigger `increment`
-- ===================
 
DROP TRIGGER IF EXISTS `increment`;
 
DELIMITER $$
CREATE TRIGGER `increment`
BEFORE INSERT ON `test`
FOR EACH ROW BEGIN
  SET NEW.rang=ifnull((select max(rang)+1 from test where val=NEW.contrat),1);
END$$
 
DELIMITER ;

Dans cet exemple, le nom de la table est 'test'.

La colonne que je dois incrémenter se nomme 'rang'. L'autre colonne se nomme 'contrat'.
Les autres colonnes ne sont pas modifiés dans ce trigger. Seul 'rang' va être modifié.

Que fait ce trigger ?
Pour un 'contrat' donné, il va rechercher la plus haute valeur de la colonne 'rang'.
La première fois, comme ce 'rang' n'existe pas, il va te retournet un 'null'.
D'où l'utilité de la fonctionne 'ifnull()' qui va tester si le select te retourner une valeur connue ou un null (pour dire j'ai pas trouvé).
Le new.rang, c'est la nouvelle valeur que tu vas stocker dans ta table.
Par analogie, l'ancienne valeur est dans old.rang.

Tu n'as pas besoin de mettre un type genre 'bigint' car le nombre de tuple pour un contrat ne doit pas dépasser les 255.
Donc tu peux mettre 'tinyint unsigned'. Si tu vois plus grand, mets 'smallint unsigned'.

Le nom du trigger doit être unique dans ta base de données.

J'espère que j'ai été suffisamment clair dans mes explications.

[quote="Gildas 216"]Merci de votre temps et de vos réponses qui me permettent d'avancer ce projet!!(/quote]
Je suis là pour ça. N'hésite pas si tu ne comprends pas quelque chose.

@+

**Gildas 216** · 29/01/2016, 18h02

Bonjour Artemus 24,

Merci encore pour votre aide précieuse.

Nous avons donc créé l'association de rang et du code contrat pour en faire la clé primaire dans la table contrat. Mais le problème qui se pose maintenant est à propos de la modification des données de la table contrat ... Nous avions créé un form en langage php pour modifier les contrats sauf que notre code actuel ne fonctionne plus, étant donné que "CodContratto" n'est plus clé primaire de la table. Voici l'extrait:

Code :

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

$query="SELECT * FROM CONTRATTO WHERE CodContratto='".$_REQUEST["CodContratto"]."";

Comment pouvons-nous faire ?

En vous remerciant par avance,

@+

Remplir les colonnes d'une table 2 à partir d'informations présentes dans une table 1

Requêtes MySQL

Vue hybride

Discussions similaires

Partager

Partager