Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2934 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  dans un sujet d'examen (SQL)

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

dans un sujet d'examen (SQL)

n°1347841
zoheir_hm
Posté le 16-04-2006 à 21:07:03  profilanswer
 

bonjour a tous;
j'ai trouvé dans un sujet d'examen cette question
 
 Donner le numéro, nom et prénom des employés qui figurent comme chef
 
la table utilisé est :
EMPLOYEES ( EMPLOYEE_ID NUMBER (6) NOT NULL, FIRST_NAME VARCHAR2(20), LAST_NAME VARCHAR2(20) NOT NULL, EMAIL VARCHAR2(25 NOT NULL, PHONE_NUMBER VARCHAR2(20), HIRE_DATE DATE NOT NULL, JOB_ID VARCHAR2(10) NOT NULL, SALARY NUMBER (8,2), COMMISSION_PCT NUMBER (2,2), MANAGER_ID NUMBER(6), DEPARTMENT_ID NUMBER(4) );
 
j'ai pas compris bien cette question , est ce que chaque employé à le MANAGER_ID  c'est sont chef, et est ce que le cher à sont EMPLOYEE_ID =MANAGER_ID ?????
 
j'ai trouvé comme solution :
SELECT DISTINCT manager.employee_id, manager.last_name, manager.first_name FROM employees worker, employees manager  
WHERE worker.manager_id = manager.employee_id;
 
j'ai pas compris la solution
 
 :pfff:  :bounce:  :pfff:  
 

mood
Publicité
Posté le 16-04-2006 à 21:07:03  profilanswer
 

n°1347863
olivthill
Posté le 16-04-2006 à 21:34:47  profilanswer
 

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;


 

n°1347878
zoheir_hm
Posté le 16-04-2006 à 21:50:18  profilanswer
 

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;



 
 
merci pour tes explication , alors le manager_id c'est que pour les chefs , il peut etre nul,
alors cette solution est fausse:
 
SELECT DISTINCT manager.employee_id, manager.last_name, manager.first_name FROM employees worker, employees manager  
WHERE worker.manager_id = manager.employee_id;  
 
a cause de la derniere ligne: WHERE worker.manager_id = manager.employee_id;
 
j'ai pas compris cette egalité worker.manager_id = manager.employee_id;
 
remarque: j'ai trouvé cette solution comme une correction du sujet
 

n°1347893
olivthill
Posté le 16-04-2006 à 22:10:21  profilanswer
 

Ca y est je viens de comprendre la solution proposée.
 
Le morceau, "FROM employees worker, employees manager", est très important, et je l'avais lu un peu trop vite.
En fait, la requête utilise deux fois la table employees en entrée. Pour distinguer ces deux fois, des alias sont nécéssaires, en l'occurence worker et manager.
 
Contrairement à ce que j'avais pensé, il n'existe pas de table des managers séparés. Le manager_id n'est pas une référence vers une table externe, mais c'est une référence vers le champ employee_id de la table elle-même.
 
La solution présentée est un peu tirée par les cheveux, mais elle est presque équivalente à ma première solution. Le champ employee_id ne sera jamais nul (par définition), et donc les enregistrements qui répondront aux critères seront des enregistrements pour lesquels manager_id est non nul. De plus, il faudra que manager_id soit présent parmi les employe_id, ce qui est une contrainte supplémentaire que je n'avais pas considérée.


Message édité par olivthill le 16-04-2006 à 22:11:33

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  dans un sujet d'examen (SQL)

 

Sujets relatifs
[Mainframe OS390] SQL et date dans un JCLperdu pr mon sujet de stage
[VBS] Probleme avec SQL - timeout[SQL] comment specifier la longueur d'une donnée ?
enieme sujet sur onchange / ListBoxComment gérer un code retour d'une procédure SQL serveur en VB
Site multilangue et base SQL ...probleme calcul taille SQL
[SQL] question de cours sur requêtes SQLQuestion sur sauvegarde de BDD SQL chez Online
Plus de sujets relatifs à : dans un sujet d'examen (SQL)


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR