Discussion :

[Dave44]

Bonjour ,

J'aimerais faire remonter au sein d'une table nommé "employés"
champs responsable, service

la liste des services pour lesquels des responsables différents apparaissent
Exemple
"Service 1" "Employé 1" "Responsable AB"
"Service 1" "Employé 2" "Responsable AB"

"Service 2" "Employé 3" "Responsable AB"
"Service 2" "Employé 4" "Responsable AC"

Requête ne faisant remonter uniquement le service "2"

Merci par avance pour votre aide :-)

[tatayo]

Bonjour,
Il faut faire une jointure de la table sur elle-même, avec comme critère le même Id de service, mais un responsable différent:

Code sql :

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

1
2
3
4
5
 
select distinct l1.IdService
from LaTable as l1
inner join LaTable as l2
on l1.IdService = l2.IdService and l1.IdResponsable <> l2.IdResponsable

Autre méthode, avec un count():

Code sql :

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

1
2
3
4
5
 
select IdService,count(distinct IdResponsable)
from LaTable
group by IdService
Having count(distinct IdResponsable) > 1

Je pense que la seconde méthode est plus performante, mais à tester.

Tatayo.

[Dave44]

Thanks you for your answer It Works !! I use your second request

[escartefigue]

Bonjour,

Quelques remarques concernant le modèle de données :

L'usage est de nommer les tables au singulier (on se doute bien qu'il y a potentiellement plusieurs employés) et sans caractères spéciaux (sans accents, ligatures ou cédille par exemple). Ceci pour simplifier les requêtes (les délimiteurs de noms d'objets sont ainsi inutiles). Ce faisant, "employe" plutôt que "employés" serait préférable.

De plus, une table nommée "employe" devrait ne contenir que des éléments qui caractérisent les employés, tels que le nom, le prénom, la date de naissance ou le matricule.
Or, le responsable d'un employé ne dépend pas seulement de l'employé mais aussi du service dans lequel cet employé est affecté.
Il faut donc connaître le service d'affectation, qui dépend de la date considérée, et, à cette date, vérifier quel est le responsable du service, le responsable pouvant lui aussi changer en fonction de la date.
À un instant "t" , un personnel n'est affecté qu'à un seul service, et à un instant "t", un service ne peut avoir qu'un seul responsable.

Le modèle conceptuel devrait donc être

[EMPLOYE] 1,n --- (affecter) --> 0,n [SERVICE]
.....0,n.......................│....................0,n
....../.\.....................0,n....................│
.......│....................[DATE].................│
.......│......................0,n....................│
.......│.......................│......................│
.......└-------------- (diriger) -------------┘

La flèche de l'association (diriger) vers l'entité-type [EMPLOYE] matérialise la contrainte selon laquelle un service n'est dirigé que par un seul employé à une date
Et la flèche vers [SERVICE] matérialise la contrainte selon laquelle un employé n'est affecté qu'à un seul service à une date

Ce qui donne les tables suivantes (PK soulignées, FK suffixées par #)
EM_employe(EM_ident, EM_matricule, EM_nom, EM_prenom...)
SE_service(SE_ident, SE_code, SE_libelle...)
AF_affecter(EM_ident#, DA_date#, SE_ident#...)
DI_diriger(SE_ident#, DA_date#, EM_ident#...)


Et on ajoutera une contrainte (difficile à symboliser en mode "texte", désolé, je n'ai pas d'outil de modélisation sur ce poste) pour vérifier qu'un employé qui dirige un service est bien affecté à ce service

Il serait même préférable d'utiliser le terme "PERSONNEL" plus générique que "EMPLOYE" puisque les infos relatives aux employés sont communes avec celles des ouvriers et des cadres.

[Michel.Priori]

Or, le responsable d'un employé ne dépend pas seulement de l'employé mais aussi du service dans lequel cet employé est affecté.
Il faut donc connaître le service d'affectation, qui dépend de la date considérée, et, à cette date, vérifier quel est le responsable du service, le responsable pouvant lui aussi changer en fonction de la date.
À un instant "t" , un personnel n'est affecté qu'à un seul service, et à un instant "t", un service ne peut avoir qu'un seul responsable.

Désolé de m'inscrire en faux par rapport à cette proposition.
La modélisation répond tout d'abord au besoin.
Or je n'ai pas lu le moindre indice permettant de valider que l'historique des affectations est demandé.

[escartefigue]

Qu'il y ait ou pas une expression de besoin claire, avec des règles de gestion claires, le nom d'une table doit correspondre à son contenu. Donc, même si l'historique des affectation n'est pas requis, une table qui contient autre chose que les attributs des employés ne doit pas s'appeler "employe".
De plus, le demandeur mentionne :

J'aimerais faire remonter au sein d'une table nommé "employés"
champs responsable, service

la liste des services pour lesquels des responsables différents apparaissent
Exemple
"Service 1" "Employé 1" "Responsable AB"
"Service 1" "Employé 2" "Responsable AB"

"Service 2" "Employé 3" "Responsable AB"
"Service 2" "Employé 4" "Responsable AC"

Requête ne faisant remonter uniquement le service "2"

Merci par avance pour votre aide :-)

Ce qui signifie qu'il y a eu changement de responsable d'un service, c'est donc bel et bien un historique, même si la date du changement n'apparait pas !
Donc, sauf à violer les formes normales, il faut bien modéliser d'une part les services, d'autre part les employés et enfin l'association d'affectation et l'association de responsabilité.

Ou alors c'est qu'un service peut avoir plusieurs responsables simultanément, ce que je n'ai jamais rencontré dans la vraie vie...

[Séb.]

Ou alors c'est qu'un service peut avoir plusieurs responsables simultanément, ce que je n'ai jamais rencontré dans la vraie vie...

Moi si, malheureusement...

[escartefigue]

Un employé peut avoir simultanément un responsable hiérarchique et un responsable fonctionnel, c'est même assez fréquent.
Mais un service n'a qu'un seul responsable à un instant "t".

[Séb.]

Mais un service n'a qu'un seul responsable à un instant "t".

J'te dis que non, et j'en sais quelque chose je l'ai vécu personnellement