Discussion :

[projetM]

Salut,
En faisant des requetes sql je rencontre à chaque fois le meme probleme et je commet toujours la meme faute.
mon problème est avec EXISTS. toujours je fait la requete en utilisant des jointures et après avoir vu la correction je tien compte qu'elle se fait avec EXISTS.
Je sais pas s'il y a des personnes qui ont recontré ce probleme. Mais je pense que j'ai pas bien assimilé le role de EXISTS.

Merci d'avance.

[Ora92_IDS]

Vous pouvez nous donner un exemple de requete sur laquelle tu utilise exists

[SheikYerbouti]

EXISTS retourne un booléen indiquant si la clause select contenue entre les parenthèses est vrai ou fausse. ce n'est pas compliqué

Code :

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

1
2
3
Select 1 from dual 
where exists ( select col from the_table where id > 10 )
;

si le sous-select ramène au moins une ligne, exists retourne TRUE sinon il reourne FALSE.

[Magnus]

http://sql.developpez.com/sqlaz/sousrequetes/#L1.5.1

[nuke_y]

remi4444 je t'invoque !

[fsmrel]

Bonsoir ProjetM,

Supposons que nous voulions exprimer en SQL la question :

"Quels développeurs connaissent Oracle ?"

On peut écrire :

Code :

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

1
2
3
4
5
 
SELECT   D.Nom
FROM     Developpeur D, SGBD S 
WHERE    D.SGBD_Id = S.SGBD_Id
   AND   S.Nom = ‘Oracle’ ;

ou de façon équivalente :

Code :

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

1
2
3
4
5
6
7
8
9
 
SELECT D.Nom
FROM   Developpeur D
WHERE EXISTS 
           (SELECT  * 
            FROM    SGBD S
            WHERE   D.SGBD_Id = S.SGBD_Id
               AND  S.Nom = ‘Oracle’ 
           );

C'est-à-dire que les deux instructions fon double emploi et EXISTS pourrait disparaître du langage. Mais, là où il devient intéressant c'est au niveau de la négation :

"Quels développeurs ne connaissent pas Oracle ?"

Code :

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

1
2
3
4
5
6
7
8
9
 
SELECT D.Nom
FROM   Developpeur D
WHERE NOT EXISTS 
           (SELECT  * 
            FROM    SGBD S
            WHERE   D.SGBD_Id = S.SGBD_Id
               AND  S.Nom = ‘Oracle’ 
           );

SQL étant redondant, il y a de nombreuses autres façons de poser les questions...

[fsmrel]

"CHAQUE INFORMATION A UNE SOURCE UNIQUE"

Certes. J’interprète ceci comme : La colonne "Ville" correspond à ce que l’on appelle en Merise une propriété naturelle or, les valeurs prises par ce genre de propriétés sont engrangées dans la base de données à partir de sources externes (programmes et/ou utilisateurs finaux). Il est évident qu’un processus peut transmettre la valeur "Paris" aussi bien que la valeur "Parris" (par exemple parce que l’utilisateur a laissé traîner son doigt sur la touche "r" de son clavier. Votre souci est donc de minimiser au maximum la propagation d’anomalies.

Considérons votre table

Code :

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

1
2
3
4
5
Ville (vil_Id, Nom,        Etat)
        v1     Paris       France
        v2     Paris       Texas
        v3     Toulouse    France

Je suis donc d’accord avec votre utilisation de propriétés artificielles (vil_Id en l’occurrence), sachant que si vil_Id est clé primaire de Ville, Nom doit nécessairement être clé alternée (UNIQUE au sens SQL (Create Table)) puisque vil_Id joue le rôle de substitut contrôlé par le seul système (surrogate dans le Relational Model/Tasmania de Ted Codd).

En passant, la colonne Etat doit elle aussi se conformer à la règle et faire l’objet d’une table, puisqu’à un état peuvent être associées plusieurs villes (Paris et Toulouse dans le cas de la France) :

Code :

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

1
2
3
4
5
6
7
8
9
Ville (vil_Id, Nom,        Etat_Id)
        v1     Paris       e1
        v2     Paris       e2
        v3     Toulouse    e1

Etat  Etat_Id, Nom   )
        e1     France
        e2     Texas

Cela dit, a priori rien n’interdit de retrouver en table la valeur "Parris" (avec deux "r") :

Code :

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

1
2
3
4
5
6
Ville (vil_Id, Nom,        Etat_Id)
        v1     Paris       e1
        v2     Paris       e2
        v3     Toulouse    e1
        v4     Parris      e1

Votre système permet donc très certainement d’évacuer des anomalies, mais ne garantit pas le zéro-erreur. Il présente un intérêt quand on utilise les opérateurs d’agrégation pour traiter des requêtes du genre : "Quel le pourcentage de développeurs habitant Paris", avec le minimum d’erreurs, dans le cas de données de type alphanumérique. Dans le cas de données du type numérique, il me paraît douteux de devoir mettre en œuvre un surrogate par exemple pour le salaire des développeurs, c’est-à-dire de remplacer la colonne salaire par une colonne Salaire_Id qui renvoie à une table des salaires (dans la mesure où la table des développeurs respecte bien sûr la 3e forme normale, c’est-à-dire qu’il n’existe pas de colonne Date_Salaire telle qu’il existe la dépendance fonctionnelle transitive Dev_Id --> Salaire --> Date_Salaire).

Il n’en demeure pas moins vrai que dans un univers du discours réel, votre remarque reste tout à fait pertinente, surtout quand les concepteurs déclinent Ville en : Ville du client, Ville du fournisseur, Ville du développeur, Ville de ceci, Ville de cela...

"L'IDENTIFIANT NE DOIT PAS ETRE UN SIGNIFIANT" ...
Pourtant, les merisiens pur sucre d'il y a quelques années étaient je crois pour le principe inverse considérant que si une combinaison de propriétés désignaient de manière unique un objet, alors pas besoin de rajouter une autre colonne, et c'est cette clef candidate qui faisait office d'indentifiant. Cette methode à conduit à quelques catastrophes par le manque de souplesse des modèles générés.

Que l’identifiant ne soit pas un signifiant, nous sommes parfaitement en phase. Par ailleurs, ce ne sont quand même pas tous les merisiens pur sucre qui ne tiennent pas compte de cette règle de bon sens. Par exemple, dans les années quatre-vingts, Yves Tabourier écrivait dans De l’autre côté de MERISE (Les éditions d’organisation, 1986), page 80 :

Considérer l’identifiant comme une propriété particulière est donc, selon moi, un abus de langage, malgré l’usage consacré par de nombreux auteurs. Une raison plus profonde pour laquelle l’identifiant «a l’aspect d’une propriété mais n’est pas une propriété» est que la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques. L’expérience montre d’ailleurs que l’usage des «identifiants significatifs» (ou «codes significatifs») a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets.

Je rappelle aussi ce que j’ai écrit sur ce site :

Je me souviens du système préconisé par les concepteurs dans une grande banque pour identifier les entreprises : leur numéro Siren, fourni par un organisme extérieur, à savoir l’INSEE. Par ailleurs, le Siren était propagé dans toute la base de données par le jeu des liens clé primaire - clé étrangère. J’ai fait observer que l’INSEE envoyait tous les mois les nombreux correctifs modifiant le Siren des entreprises. Aussitôt, l’identifiant de l’entreprise fit l’objet d’une propriété nouvelle et artificielle, Entreprise_Id. Le numéro de Siren devint un simple point d'entrée dans la table, à usage de l'utilisateur.

Cf. message #19, http://www.developpez.net/forums/sho...=225898&page=2

Ce principe de séparation entre l'identifiant et le "désignant" rejoint le principe philosophique du mot et de la chose.

Certes, et le grand philosophe et logicien Willard Van Orman Quine a écrit des choses importantes sur le sujet ("Word and Object"), mais qui risqueraient de nous emmener bien au-delà de ce débat (qui avait initialement EXISTS pour thème...) J’effleure quand même le thème un peu plus loin dans ce message.

comment savoir si les 2 mots "Paris" se rapporte à la même chose, peut etre y a-t-il Paris au Texas et Paris en France.

Il est évident que dans le cas de ma table Développeur (Dev_Id, Nom, SGBD, Ville), je ne me suis sans doute limité aux villes texanes (Why not?) auquel cas la notion d’état n’a pas lieu d’être prise en considération. Mon exemple est simpliste, car l’objet n’était pas de modéliser un univers du discours réel, lequel aurait conduit à ce que Ville et SGBD fissent l’objet de propriétés dans des entités-types dédiées.

Typage des données

Tant qu’à essayer d’éliminer le plus possible les anomalies des la base de données, je suis partisan du typage des données tel que le propose le Modèle relationnel, c’est-à-dire en y développant des contraintes.
Supposons que nous définissions le type Ville pour les noms de villes et que la contrainte définie par le concepteur soit : "Le nom de la ville doit mesurer au moins 2 caractères, le 1er caractère doit être une majuscule et les suivants des minuscules" (on peut évidemment raffiner la contrainte, mais notre objet n’est pas là, nous voulons simplement illustrer par un exemple simple).

Le type Ville peut être ainsi défini :

Code :

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

1
2
3
4
5
6
7
8
TYPE Ville POSSREP {X CHAR CONSTRAINT
                               IF LENGTH(X)>1 THEN
                                     IS_UPPERCASE SUBSTR (X,1,1) 
                                     AND IS_LOWERCASE SUBSTR (X,2,LEN(X)-1)
                               ...
                               END IF
                   } ;

Dans ce modeste exemple, IF et END IF font partie de la grammaire. LENGTH, SUBSTR IS_UPPERCASE et IS_LOWERCASE sont des fonctions définies par le SGBD ou développées par nous-mêmes.

Ne vous préoccupez pas du mot-clé POSSREP (possible representation), qui permet au développeur d’utiliser différentes représentations pour un type donné (cas du type POINT pour lequel on voudrait représenter les coordonnées d’un point aussi bien sous forme de coordonnées cartésiennes que polaires).

cette colonne est une interface humaine, un commentaire, donc un truc imparfait possiblement éroné ou imprécis, instable, bref un truc sur lequel il ne faut pas trop compter

J’en sais quelque chose, puisque pour l’INSEE Albert habite 12 B BAGNEUX, alors qu’en réalité il habite 12 bis, rue de Bagneux...

voici un jeu de questions / réponses à propos de ce mini modèle de données à 2 lignes:
"Quels sont les SGBD ?" -> il n'y a qu'Oracle
"Quelles sont les villes ?" -> il n'y a que Paris
"Quels sont les développeurs" -> il y a Albert et Albert
La réponse à la troisieme question est importante car elle dit qu'il y a bien 2 personnes mais qu'ils s'appellent tous les 2 Albert. En revanche, on s'attends à ce que la liste des villes ne nous renvoit qu'un élément puisqu'une seule ville est concernée par la table. Mais comment le SQL va-t-il deviner qu'il ne pas faut répondre "Paris et Paris" alors qu'on trouve normal qu'il réponde "Albert et Albert". Dans tintin "Dupond et Dupond" ça signifiait quelque chose non ? (ok je sais que ça s'écrivait pas pareil mais j'aimais trop l'exemple )

Je pense que vous voulez en faire dire plus à la base de données qu’elle ne peut le faire. Personnellement, pour en revenir à mes instances de la logique des prédicats, je dirai que mon univers est composé de deux instances de développeurs lesquels ont même nom, utilisent le même SGBD et sont localisés dans la même ville. "Albert" reste une chaîne de caractères, contrairement à Albert. En outre, selon l’utilisateur, l’information importante de la table n’est peut-être pas le nom des développeurs, mais le fait de savoir qu'il peut présenter à ses clients des gens qui connaissent le SGBD Oracle.

Quant au mot et au nom, pour citer à nouveau Quine :

Lorsque nous écrivons :

Le quatrième mot de «L’invitation au voyage» rime avec le huitième

nous mentionnons les mots 'sœur' et 'douceur', mais utilisons des noms de ces mots. Nous écrivons 'rime avec' non entre des mots qui riment mais entre leurs noms. Nous pouvons également écrire :

'sœur' rime avec 'douceur',

mais ici à nouveau nous utilisons des noms pour les mots assurant la rime — les noms étant alors formés par l’adjonction de guillemets simples. Il ne serait pas seulement erroné, mais contraire à la grammaire et dépourvu de sens d’écrire :

Sœur rime avec douceur.

En poussant le bouchon comme le font D & D (je veux dire Date et Darwen plutôt que Dupond et Dupont...) le mot 'table' en SQL est ambigu et doit faire l’objet d’un dédoublement : 'variable de table' et 'valeur de table'. Quand vous écrivez 'Create Table Développeur...', vous définissez la variable de table Développeur, prenant pour valeur l’ensemble vide. Après une opération réussie de mise à jour telle qu’'Insert Into Table Développeur...', la variable a pris une autre valeur. Il en est de même à chaque fois que je modifie au moins un bit dans la table.

[nuke_y]

Qui se dévoue pour synthétiser tout ce qui a été dit ici dans un tutoriel ?

[remi4444]

Bonjour,
ça me démange de faire une longue réponse argumentée mais j'ai pas le temps malheureusement... et je reviendrai plus tard sur la question des données numériques (salaires) et aussi des dates.

Pour aller à l'essentiel, je rebondirai simplement sur l'argument suivant:

je dirai que mon univers est composé de deux instances de développeurs lesquels ont même nom, utilisent le même SGBD et sont localisés dans la même ville. "Albert" reste une chaîne de caractères, contrairement à Albert. En outre, selon l’utilisateur, l’information importante de la table n’est peut-être pas le nom des développeurs, mais le fait de savoir qu'il peut présenter à ses clients des gens qui connaissent le SGBD Oracle.

Pour moi ces 3 informations n'ont pas la meme nature. Du moment que l'application n'a pas pour but de faire des stats sur les usages de prénoms ou de noms, alors l'information "nom" n'est qu'un commentaire, une explication attachée à l'employé et à rien d'autre. Lorqu'on parle de la ville ou du SGBD, et dans la mesure ou on compte faire recherches ou comptages sur ces données, alors implicitement, on fait référence à des choses ayant leurs existances propres indépendement de celles des employés. Si on dit "roger et albert travaillent dans la même ville", c'est dire qu'il font référence à la meme chose-ville, donc que quelque part il y a une référence des villes. Peu importe si l'identifiant de ville est signifiant ou non, peu importe qu'il soit de type numérique majuscule minuscule, c'est un identifiant donc il doit etre le meme pour la meme ville et différent pour 2 villes différentes. Si on ne faisait pas cette référence implicite alors on dirais "roger travaille dans une ville portant le meme nom que la ville dans laquelle travaille albert" nuance...
En revanche "albert" et "albert" travaillent dans la même ville, dupond et dupond sont parti dans la même fusée dans l'album "on a marché sur la lune"...