olivthill a écrit :
La table n'a pas été construite en respectant pas les lois concernant les bases relationnelles édictées par E. Codd. Il n'est donc pas étonnant que la question soit difficile à comprendre. En théorie, le champ MANAGER_ID ne devrait pas faire partie de cette table. Mais, en pratique, la présence de ce champ ici peut faciliter certains traitements.
Une autre difficulté vient de l'anglais. Le mot "salarié" n'existe pas en anglais. On utilise à la place le mot "employee", qui désigne donc à la fois les cadres et les non-cadres. En français, le mot "employé" n'englobe généralement pas les chefs.
Il faut remarquer que le champ MANAGER_ID peut être nul.
MANAGER_ID sera rempli avec un identifiant de manager, qui est probablement une clef externe vers une table des managers. A contrario, MANAGER_ID sera nul pour tous les salariés qui ne sont pas des managers.
Pour donner le numéro, nom et prénom des employés qui figurent comme chef, j'utiliserais la requête suivante :
SELECT employees.employee_id, employees.last_name, employees.first_name
FROM employees WHERE employees.manager_id IS NOT NULL;
|
Le distinct n'est pas nécéssaire car employee_id garantit l'unicité.
Cette requête présente l'inconvénient d'obliger le moteur de la base de données à balayer toute la table des employés.
S'il existe une table des managers, il est sans doute préférable de faire la requête suivante :
SELECT employees.employee_id, employees.last_name, employees.first_name
FROM employees, manager
WHERE employees.manager_id = manager.manager_id;
|
|