Discussion :

[johnny3]

Bonjour,

j'ai passé au moins 2 heures sur cette requête et je ne comprends toujours pas son corrigé.

J'ai crée une base de données simple pour tester la réponse et le résultat est celui attendu.

La table est fréquenter (buveur, bar)

J'ai créé une table très simple:

Code :

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

1
2
3
4
5
6
7
8
9
Buveur    Bar
Toto       Mistral
Toto       Les amis
Tata       Mistral
Bubu       Les amis
Baba       Les amis
Bibi         Mistral
Bibi         Les amis
Bibi         ABC

La requête est: donner les buveurs qui fréquentent tous les bars

La seule réponse est: Bibi, qui fréquente les 3 bars.

Je suis parvenu à identifier les résultats données par les différentes parties de la requête, mais je ne comprends toujours pas le corrigé.

Code :

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

1
2
3
4
5
6
7
8
9
SELECT buveur
FROM frequenter
WHERE buveur not in       (on a donc Toto, Tata, Bubu, Baba et Bibi)
           (SELECT F1.buveur
            FROM frequenter F, frequenter F2
            WHERE F1.buveur not in  (on a à nouveau les 5 buveurs)
                             (SELECT buveur
                              FROM frequenter
                              WHERE bar = F2.bar)); (C'est Bibi)

Cette partie là

Code :

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

1
2
3
4
5
6
(SELECT F1.buveur
            FROM frequenter F, frequenter F2
            WHERE F1.buveur not in  (on a à nouveau les 5 buveurs)
                             (SELECT buveur
                              FROM frequenter
                              WHERE bar = F2.bar)

donne Toto, Tata, Bubu et Baba

Et donc, le seul qui ne soit pas dans cette liste est Bibi, qui fréquente bien tous les bars.

Mais je ne comprends pas comment on obtient Bibi dans cette sous requête

Code :

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

1
2
3
SELECT buveur
FROM frequenter
WHERE bar = F2.bar

Quelqu'un pourrait-il m'éclairer, s'il vous plait? Je rame sur cette requête.

Merci par avance,
Johnny3

[fsmrel]

Bonjour,


Votre problème relève de la division relationnelle.

Vous trouverez peut-être ce que vous cherchez en épluchant les échanges suivants, dans lesquels certains ont fait part de leurs états d'âme :

http://www.developpez.net/forums/sho...d.php?t=350388

http://www.developpez.net/forums/sho...d.php?t=360501

http://www.developpez.net/forums/sho...d.php?t=438011

http://www.developpez.net/forums/sho...d.php?t=539241


Vous trouverez un exposé complet sur la division :

http://sqlpro.developpez.com/cours/divrelationnelle/


Bonne lecture


Nota Bene : vous utilisez NOT IN, alors que dans les messages cités, c'est plutôt NOT EXISTS, mais ça ne change rien à l'approche du problème.

[johnny3]

merci, je vais tenter de regarder cela.

Une question: pourquoi la division existe-t-elle en algèbre relationnelle si l'on ne peut l'implémenter en sql?

[fsmrel]

pourquoi la division existe-t-elle en algèbre relationnelle si l'on ne peut l'implémenter en sql?

L’algèbre relationnelle est un composant du Modèle Relationnel de Données, inventé en 1969 par Ted Codd, chercheur à l’époque chez IBM. SQL date de 1976 (équipe de Chamberlin, IBM), c’est une interprétation incomplète et pas particulièrement conforme du Modèle relationnel. Aujourd’hui, SQL fait l’objet d’une norme et ceux qui font cette norme pourraient très bien proposer l’opérateur DIVIDEBY, mais ils ont sans doute des sujets plus prioritaires à traiter.

[SQLpro]

En fait l'opérateur de division à bien été demandé au comité de normalisation de SQL... Mais rejeté (Date, 6e édition de Introduction to Database Systems, opérateur DIVIDE BY ... PER). En effet il faudrait pour cela déstructurer le principe même de structuration du code SQL (le S de SQL voulant dire Structured).
Je m'explique. Une division relationnelle peut être approchée (laisser un reste) ou exacte (pas de reste). La requête pour produire un tel résultat n'est pas la même. Voir l'article que j'ai écrit à, ce sujet :
http://sqlpro.developpez.com/cours/divrelationnelle/
le problème est que :

• soit il faudrait introduire deux opérateurs de division
• soit il faut interdire une des divisions
• soit il faut que l'opérateur de division produise une ou deux tables suivant le cas (le résultat et éventuellement le reste)

Vous conviendrez j'en suis sûr que quelque soit la menière de faire, ceci heurte la logique même du langage SQL !

A +

[fsmrel]

Une division relationnelle peut être approchée (laisser un reste) ou exacte (pas de reste).

Quand on traite de la division arithmétique, on aime bien savoir à quoi ressemble le reste. Concernant l’opérateur DIVIDEBY de l’algèbre relationnelle, seul le quotient figure, jamais le reste, ce qui n’empêche évidemment pas de l’évoquer et de le calculer au besoin.

Du reste, Ullman appelle un chat un chat et renomme DIVIDEBY en QUOTIENT en définissant ainsi cet opérateur :

Soit R et S des relations d’arités respectives r et s, avec r > s et S ≠ ∅. R ÷ S est alors l’ensemble des (r-s)-tuples tels que pour tous les s-tuples u éléments de S, le tuple tu est élément de R.

(J.D. Ullman. Principles of DATABASE SYSTEMS, Second Edition. Computer Science Press. 1982).

Quoi qu’il en soit, quand Date propose une extension de DIVIDEBY en DIVIDEBY PER, le reste de la division n’est pas plus impliqué pour autant. L’objet de DIVIDEBY PER est de pouvoir traiter de la division par ∅, et non pas de faire comme Ullman qui botte en touche.

Pour sa part, si Codd évoque le reste de la division, c’est juste pour dire que le calcul du reste ne pose pas de problème particulier (E. F. Codd. The Relational Model for Database Management: Version 2 (Reading, Mass.: Addison-Wesley, 1990), pages 83 et suivantes). Pour mémoire, il formule la division ainsi :

Q ← S [A, B / C ] T.

La relation S représente le dividende, la relation T le diviseur, la relation Q le quotient. B et C sont des attributs respectifs de S et T utilisés comme éléments de comparaison (comparand columns). A est un attribut de S, source des valeurs pour le quotient.

Pour en revenir à l’utilisation de EXISTS, Codd rappelle que le quantificateur universel de la logique des prédicats correspond à la division relationnelle et il souligne que SQL ne le propose malheureusement pas, imposant ainsi au développeur une charge supplémentaire dont celui-ci se passerait volontiers.

le problème est que :

● soit il faudrait introduire deux opérateurs de division
● soit il faut interdire une des divisions
● soit il faut que l'opérateur de division produise une ou deux tables suivant le cas (le résultat et éventuellement le reste).

Vous conviendrez j'en suis sûr que quelque soit la menière de faire, ceci heurte la logique même du langage SQL !

Si je vous suis, le Modèle SQL se départit du Modèle relationnel, puisque ce dernier se désintéresse du quotient. Peu importe, à chacun sa logique. Le SQLland n’est évidemment pas le Relationland où est strictement respectée la logique des prédicats issue des travaux de Frege, et poursuivis par ceux de Peirce, Whitehead, Russel et successeurs.

En fait l'opérateur de division à bien été demandé au comité de normalisation de SQL... Mais rejeté (Date, 6e édition de Introduction to Database Systems, opérateur DIVIDE BY ... PER).

Pourriez-vous m’indiquer la page de l’ouvrage cité, où il serait fait mention du rejet de l’opérateur de division par le comité, car je n’ai rien trouvé à ce sujet.



Note

Maintenant, est-il vraiment nécessaire de disposer de l’opérateur de division ?
Je traduis Date (An Introduction to Database Systems, 8th edition. (Pearson: Addison-Wesley (International Edition), 2004), page 189) :

"Vous pourriez avoir le sentiment que la comparaison relationnelle est plus simple d’emploi. En fait, on peut se poser la question, à savoir dans quelle mesure DIVIDEBY aurait vu le jour si le modèle relationnel avait en premier lieu inclus les comparaisons relationnelles — mais il ne le fit pas."

La comparaison relationnelle : voiilà un sujet intéressant.

[SQLpro]

Pourriez-vous m’indiquer la page de l’ouvrage cité, où il serait fait mention du rejet de l’opérateur de division par le comité, car je n’ai rien trouvé à ce sujet.

Il faudrait demander à Jim Melton, l'actuel rapporteur de la norme. je ne pense pas que c'était lui à l'époque, mais peut être il saura. De mémoire, je pense que c'est Peter Gulutzan qui m'en avait parlé !

A +

[fsmrel]

Bonsoir,

En fait l'opérateur de division à bien été demandé au comité de normalisation de SQL... Mais rejeté (Date, 6e édition de Introduction to Database Systems, opérateur DIVIDE BY ... PER).

Pourriez-vous m’indiquer la page de l’ouvrage cité, dans laquelle serai fait mention du rejet de l’opérateur de division par le comité, car je n’ai rien trouvé à ce sujet.

Il faudrait demander à Jim Melton, l'actuel rapporteur de la norme. je ne pense pas que c'était lui à l'époque, mais peut être il saura. De mémoire, je pense que c'est Peter Gulutzan qui m'en avait parlé !

A défaut, par le canal d’Internet, j’ai retrouvé un article de l’inévitable Joe Celko, traitant de la division relationnelle et qui écrit ceci :

In the sixth edition of his book, Introduction to Database Systems, Chris Date defined another operator (DIVIDEBY ... PER) which produces the same result as my query, but with more complexity.

Celko s’avance beaucoup quand il prétend que l’utilisation de l’opérateur de Date est plus complexe. Est-ce parce que cet opérateur prend en compte le diviseur égal à ∅ ? En tout état de cause, les deux requêtes que Celko propose comme solutions de l’énoncé :

Donner les noms des pilotes qui peuvent faire voler tous les avions se trouvant dans le hangar

sont quand même incomparablement plus compliquées que la suivante :

PilotSkills {pilot} DIVIDEBY Hangar {plane} PER PilotSkills {pilot, plane} ;

Requête qui, au vu de la structure des tables, peut du reste être ramenée à :

PilotSkills {pilot} DIVIDEBY Hangar PER PilotSkills ;

En tout cas, comme diraient les Dupondt, c’est mon opinion et je la partage...


A propos de Peter Gulutzan, on peut dire que le garçon n’est pas très regardant quant à l'Histoire de France. Dans son ouvrage "SQL-99 Complete, Really "(R&D Books, Miller Freeman, 1999, ISBN: 0-87930-568-1), au début du chapitre 30 "Searching with join", page 575, je relève un bel anachronisme : il fait jouer aux cartes René Descartes (mort en 1650), en compagnie de Madame du Barry (née en 1743).

Incidemment, quant à ce qu’il écrit à propos de la capitalisation des lettres, il n’y va pas non plus de main morte. Ainsi, il affirme tranquillement (page 98) « In France, the uppercase of the word "résumé" is "RESUME" ». Je renvoie Gulutzan à l’ouvrage de Maurice Grevisse, référence s’il en est, « Le bon usage » au paragraphe 86. Grevisse encourage à ne pas se relâcher dans l’utilisation des capitales accentuées. Si l’on ne veut pas passer pour un rustre, on doit faire de son mieux pour respecter la langue française.

Dans le même sens, et pour l'anecdote, pour expliquer que le nombre de retraités augmente, un journal ne doit certainement pas titrer « LES RETRAITES AUGMENTENT » (on peut rêver), pas plus que « UN POLICIER TUE » quand un policier a été tué. Si vous me proposez des PETITS FOURS SALES, j’y regarderai à deux fois avant d’y toucher... Dans la série des grands titres, il y a aussi « LES ENFANTS LEGITIMES », « LES MINISTRES INTEGRES » (même WORD repère ces ambiguïtés, mais pas toutes : « DOMINIQUE S’EST TUE », « LA SAISON DES CONGRES », « LE MINISTRE RESTE FERME »...) Liste non exhaustive.

[SQLpro]

Sur les majuscules je suis bien d'accord.. Il faut des accents. Voire la célèbre phrase :
LE COUP DE DE DE DE GAULLE !

Ne pas oublié que nos confrère d'outre manche, aiment bien la France (c'est quand même La Fayette qui les as aidé à se libérer du joug anglais) mais en ont une vision très approximative (voir "sacré français" / "sacré américains" de Ted Stanger).
Or après guerre, les premiers journaux ont reparus sans accents dans les capitales parce que les linotypes venait des US. Il a fallut attendre les années 60 pour que ces derniers retrouvent des majuscules accentués.

A +

[pacmann]

Quand on traite de la division arithmétique, on aime bien savoir à quoi ressemble le reste. Concernant l’opérateur DIVIDEBY de l’algèbre relationnelle, seul le quotient figure, jamais le reste, ce qui n’empêche évidemment pas de l’évoquer et de le calculer au besoin.

Bonjour,

Tout à fait d'accord !

En fait, je dirais que ça va un peu plus loin : quand on parle d'opérateur, on entend (je le pense très fort) loi de composition interne.
SQLPro, si vous entendez retourner un couple de résultats, vous n'êtes absolument plus dans le concept d'algèbre, puisque la "stabilité" est malgré tout son principe de base...

La division arithmétique n'est pas un opérateur de l'ensemble Z, c'est une opération.
Maintenant, on peut réfléchir au lien entre l'opérateur de division relationnelle, et les différent opérateurs de divisions usuels...
Mais j'ai la sensation qu'il est à priori difficile de définir l'opérateur de division relationnelle, restreint à un certain sous ensemble de l'ensemble des relations, comme l'opérateur réciproque d'un quelconque autre opérateur... (le produit cartésien ??)

PS : Fsmrel, j'ai commencé à imprimer et lire votre pavé, merci !
Juste par curiosité : l'avez-vous lu en entier ?

[fsmrel]

Hello,

Mais j'ai la sensation qu'il est à priori difficile de définir l'opérateur de division relationnelle, restreint à un certain sous ensemble de l'ensemble des relations, comme l'opérateur réciproque d'un quelconque autre opérateur... (le produit cartésien ??)

Ma foi...

Je vous invite à voir la définition donnée par Codd de la division relationnelle, dans son papier de 1972 Relational completeness of data base sublanguages. Il est un fait que cette division est définissable en termes des opérations que Codd a déjà introduites, dont le produit cartésien (expanded cartesian product).
Je vous renvoie aussi au papier dans lequel Date commente le papier de Codd (Thirty Years of Relational - Codd's Relational Algebra), dans lequel Date propose (pour S non vide) :

(R TIMES S) DIVIDEBY S ≡ R

N.B. Si le 2e lien ne donne rien, il suffit de proposer le titre de l'article au moteur de recherche.

j'ai commencé à imprimer et lire votre pavé, merci !
Juste par curiosité : l'avez-vous lu en entier ?

Je suppose que vous faites allusion aux Principia ?
Si tel est le cas, je l’ai trouvé il n’y a pas longtemps et n’ai bien sûr fait que feuilleter. Je dirais même qu’avant d’aborder sérieusement et humblement la somme, je commencerai par relire les "Méthodes de logique" de Quine.

[johnny3]

merci pour toutes ces réponses! Je vois que c'est plus compliqué que je ne le pensais.