Discussion :

[koktel_dfr]

J'ai beaucoup hésité pour savoir dans quelle section du forum poster... au final celle-ci me semble la plus appropriée.

Je suis actuellement des cours de SQL. Aucun problème avec le SQL jusqu'à maintenant par contre en cours on associe souvent à la requête SQL sont équivalent en algèbre SQL (oui, vous vous rappelez, le truc qui n'a aucune utilité mais qu'il faut parfois apprendre pour avoir un diplôme...).

La requête ci-dessous ne me pose aucun problème (même un enfant de 8 ans aurait pu la faire...) par contre je ne comprends pas grand chose à l'expression algebrique juste au dessus...



Je ne comprends pas ce que viennent faire l'intersection, les renommages et le "<" la dedans... Merci à celui qui arrivera a m'expliquer ça clairement...

[fsmrel]

Bonsoir,


Cela fait près de vingt ans que je n’ai pas utilisé la notation qui vous donne des boutons, mais on va tâcher moyen de démêler l’écheveau.

Remarque préalable : dans la formule hermétique, il apparaît que les parenthèses ne sont pas balancées, mais bon...

Je suppose que l’opérateur ρ sert à renommer la relation Lot (disons en PNL), en faire une relation immatérielle, une image, et pouvoir ainsi effectuer une auto-jointure.

Manifestement Num_Lot→NL correspond à une opération de renommage de l’attribut Num_Lot en NL pour la relation PNL. Même principe pour Loyer_Mensuel qui serait renommé en Loyer. Cette opération permet d’éviter les ambiguïtés du genre Num_Lot = Num_Lot dans l’opération de jointure à suivre.

Sans renommage, on écrirait en effet quelque chose qui embarrasserait l’analyseur syntaxique :

Lot ⋈ Num_Lot = Num_Lot ∧ Loyer_Mensuel < Loyer_Mensuel PNL(...)

Avec renommage, c’est plus clair pour l’analyseur :

Lot ⋈ Num_Lot = NL ∧ Loyer_Mensuel < Loyer PNL(...)

Cette opération de jointure entre les relations Lot et PNL vise à obtenir l’ensemble des lignes de la relation Lot pour lesquelles le loyer est inférieur aux loyers figurant dans les lignes de la relation PNL.

Dans l’expression ci-dessus "Num_Lot = NL ∧ Loyer_Mensuel < Loyer", le symbole « ∧ » correspond au connecteur ET (en SQL : Num_Lot = NL AND Loyer_Mensuel < Loyer).

Toutefois cette expression compare chaque lot seulement avec lui-même et ne correspond pas à la requête SQL (dans laquelle chaque lot est comparé avec chaque lot) et devrait être reformulée ainsi :

Lot ⋈ Loyer_Mensuel < Loyer PNL(...)

Par exemple, si la relation Lot contient les lignes <'lot1', 1000>, <'lot2', 2000>, <'lot3', 3000>, avec l’expression corrigée on aura au résultat : <'lot1', 1000>, <'lot2', 2000>.

N.B. Si on ne modifie pas l'expression, et si la relation Lot contient les lignes <'lot1', 1000>, <'lot2', 2000>, <'lot3', 3000>, ,<'lot3', 3500>, le résultat sera vide...

En tout cas, après modification de l'expression, la projection du résultat sur l’attribut Num_Lot donne : <'lot1'>, <'lot2'>.

Pour connaître le lot ayant le loyer le plus élevé, il suffit d’effectuer une opération de différence ‘symbolisée par « — » entre la projection de la relation Lot sur Num_Lot et la projection précédente. Dans l'exemple, le résultat sera égal à 'lot3'.

Pour résumer :

1) Mise en œuvre d’une relation immatérielle PNL, image de la relation Lot,
2) Renommage des attributs de cette relation pour lever les ambiguïtés,
3) (Auto-)jointure de Lot et de son image PNL avec pour condition de jointure : "Loyer_Mensuel < Loyer",
4) Projection du résultat sur l’attribut Loyer_Mensuel,
5) Projection de la relation Lot sur l’attribut Loyer_Mensuel,
6) Opération de différence.

[koktel_dfr]

Merci et désolé pour la réponse un peu tardive, j'étais pas mal occupé cette semaine.

En tout cas ton explication est parfaitement claire et détaillée, maintenant je comprends mieux. Ca me parait juste un peu inquiétant que l'expression algébrique ne corresponde pas totalement avec la requête SQL car celle-ci est extraite d'une annale d'examen

Encore merci.

[CinePhil]

Quelle idée d'enseigner un truc pareil et aussi obscur utilisé par personne !

Ou alors au niveau doctorat pour des études purement théoriques, et encore !

[LhIaScZkTer]

Quelle idée d'enseigner un truc pareil et aussi obscur utilisé par personne !

Ou alors au niveau doctorat pour des études purement théoriques, et encore !

Ce que j'en ai retenu de mes cours c'est que l'algèbre relationnel permet de faire abstraction du langage SQL. Par contre, le calcul relationnel est très utile car il permet de trouver une requête d'après l'expression de la réponse. Je regrette vraiment d'avoir oublié cette notation...

En plus, en entretien c'est une excellente manière de briller, on passe pour un VRAI...
Un vrai quoi ? j'en sais rien

[CinePhil]

Ce que j'en ai retenu de mes cours c'est que l'algèbre relationnel permet de faire abstraction du langage SQL.

Je n'en suis pas spécialiste mais il me semble avoir vu dans les messages de fsmrel des truc plus sympas à lire et sans SQL. Tutorial D ?

Par contre, le calcul relationnel est très utile car il permet de trouver une requête d'après l'expression de la réponse.

Jamais eu besoin de ce truc pour faire une bonne requête SQL !

En plus, en entretien c'est une excellente manière de briller, on passe pour un VRAI...
Un vrai quoi ? j'en sais rien

Intello ?
Théoricien ?
Coupeur de cheveux en 4 ?

[LhIaScZkTer]

Intello ?
Théoricien ?
Coupeur de cheveux en 4 ?

Je remplacerai intello par geek, théoricien par autiste. Et pour le coupeur de cheveux en 4, t'es plus indulgent que moi

Ceci dit il y a un cas où cette notation est plus simple à lire... c'est le cas de la division relationnelle

Il y a un logiciel qui permet d'écrire les requêtes avec la notation mathématique, mais là j'ai plus le nom sous la main. Je vais essayer de retrouver le nom.

[fsmrel]

Je réaffiche l’image proposée par koktel, car elle a tendance à disparaître :

Quelle idée d'enseigner un truc pareil et aussi obscur utilisé par personne !

Il ne faut pas oublier que la notation en cause était utilisée à l’époque où SQL n’était qu’un prototype d’IBM, concocté par deux de ses chercheurs, Don Chamberlin et Raymond Boyce (RIP). Personne n’y trouvait à redire et en ces années soixante-dix, quand les chercheurs s’éclataient, et nous simples mortels, transpirions avec des SGBD non relationnels.

Si vous lisez les pages, disons 15 et suivantes de l’entretien accordé en 2009 par Don Chamberlin à Paul McJones, vous retiendrez qu’une bonne idée de Chamberlin fut de vouloir que les requêtes puissent être saisies au clavier, ce qui pose évidemment des problèmes insurmontables avec le langage hermétique, mais intéresse vivement les simples mortels. Et encore, on a échappé à SQUARE, car Chamberlin et Boyce voulurent se rapprocher d’un langage plus proche de la langue naturelle, d’où SEQUEL (renommé en SQL pour des problèmes de copyright).

Je cite Chamberlin et Boyce qui écrivent dans Sequel: A structured english language, en 1974 :

« SEQUEL language is equivalent in power to SQUARE, but is intended for users who are more comfortable with an English-keyword format than with the terse mathematical notation of SQUARE. »

Ce que j'en ai retenu de mes cours c'est que l'algèbre relationnel permet de faire abstraction du langage SQL.

Certes. L’algèbre relationnelle a été mise sur pied par Ted Codd en 1969-1970 (chez IBM une fois de plus), tandis que SQL n’en est qu’un avatar conçu en 1974 et revu en 1976.

Par contre, le calcul relationnel est très utile car il permet de trouver une requête d'après l'expression de la réponse. Je regrette vraiment d'avoir oublié cette notation...

Le calcul relationnel ne permet pas a priori de formuler une requête à partir de la réponse. Au départ, il ressort seulement à la logique des prédicats. La première mouture du calcul fit l’objet du langage ALPHA de Codd en 1971 (« A Database Sublanguage Founded on The Relational Calculus ») puis s’est décliné en calcul relationnel de tuples (voyez par exemple le langage QUEL du SGBD INGRES de Mike Stonebraker) et en calcul relationnel de domaines (plus proche de la logique traditionnelle). Toujours en 1971, Codd a montré l’équivalence de l’algèbre et du calcul relationnels (« Relational Completeness of Database Sublanguages »).

Cela dit, vous n’avez pas tout à fait tort, car à partir de 1975, encore un chercheur de chez IBM, Zloof a défini un langage fondamentalement basé sur le calcul relationnel de domaines, langage qu’il a nommé QBE (Query By Example) avec comme idée de base que l’on fasse formuler ses questions à l’utilisateur à l’aide d’une « réponse ». Par exemple, supposons que nous ayons la table suivante des fournisseurs :

F {FourId, Nom, Statut, Ville}

Pour connaître les numéros des fournisseurs résidant à Toulouse et dont le statut est > 2 :

Code :

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

1
2
3
4
 
F | FourId | Nom | Statut | Ville    |
--|--------|-----|--------|----------|
  | P.     |     | > 2    | Toulouse |

(« P. » est l’abréviation de « Merci de me présenter les valeurs correspondant à l’attribut FourId) ».

A noter que Microsoft ACCESS permet d'utiliser QBE aussi bien que SQL.


Bref, merci à Ted Codd d’avoir fait œuvre de vrai théoricien, car sans lui nous serions tous encore à écrire du DL/1, dans le style Codasyl (IDMS, IDS II), en NATURAL style d’époque (ADABAS), et j’en passe...

Je n'en suis pas spécialiste mais il me semble avoir vu dans les messages de fsmrel des truc plus sympas à lire et sans SQL. Tutorial D ?

Yes Sir ! Pour reprendre la requête hermétique, en passant à Tutorial D on peut la formuler ainsi (sans pratiquer pour autant la tétracapilliculture...) :

(LOT WHERE Loyer_Mensuel = MAX (LOT, Loyer_Mensuel)) {Num_Lot}

L’expression entre parenthèses : « LOT WHERE Loyer_Mensuel = MAX (LOT, Loyer_Mensuel) » correspond à une opération de restriction : obtenir toutes les tuples de LOT pour lesquels la valeur de l’attribut Loyer_Mensuel est égale à la plus grande valeur prise par l’attribut Loyer_Mensuel de LOT.

Au résultat de l’opération de restriction on applique une projection sur l’attribut Num_Lot.

N.B. Cette requête peut être très facilement saisie au clavier, la preuve.

[CinePhil]

L'historien encyclopédiste des bases de données a encore frappé et confirme ce que je disais :

Quelle idée d'enseigner un truc pareil et aussi obscur utilisé par personne !

Pour moi c'est un peu comme si on enseignait les hiéroglyphes à l'école. Pas forcément inintéressant (j'avais commencé la lecture de Champollion mais sans la couleur on y perd car elle a une signification) et ça permet de comprendre un peu plus ce qu'il y a sur les murs des temples égyptiens quand on va faire un voyage là-bas mais c'est totalement inutile pour 99% des gens dans la vie courante.

La vieille algèbre pré-SQL est aujourd'hui inutile pour 99% des informaticiens, hormis donc peut-être les chercheurs. Alors à moins que koktel_dfr ne soit proche du doctorat et se destine à faire de la recherche sur les bases de données et leur histoire, je trouve ça sadique d'enseigner un truc pareil !

[fsmrel]

La vieille algèbre pré-SQL est aujourd'hui inutile pour 99% des informaticiens, hormis donc peut-être les chercheurs.

Vous êtes sévère. Je pense que l’auteur de la formule hermétique a volontairement shunté l’opérateur d’agrégation MAX. Pour comparer des choses comparables, il faudrait reformuler la requête SQL en se passant de MAX et des facilités du genre TOP et compagnie.

Je n’ai pas les moyens de vérifier si la requête suivante est parfaitement valide, mais en utilisant MAX, la formule hermétique prend un visage moins hiéroglyphique, du genre :



σ est l’opérateur de restriction (alias sélection), exprimé en SQL par WHERE.
π est l’opérateur de projection, exprimé en SQL par SELECT.

N.B. Il n’y a pas de vieille algèbre, l’algèbre sera toujours l’algèbre. Par contre, il y a plusieurs façons de la formuler et seulement dans ce cas on peut préférer une notation plutôt qu’une autre.

Accessoirement, voici comment ACCESS traduit en quasi QBE la requête SQL initiale :



Mais je pense que Zloof n'aurait pas apprécié de voir apparaître les mots SELECT et WHERE du langage concurrent...

[koktel_dfr]

Alors à moins que koktel_dfr ne soit proche du doctorat et se destine à faire de la recherche sur les bases de données et leur histoire, je trouve ça sadique d'enseigner un truc pareil !

Ho non, j'en suis loin, je vise un diplôme d'ingénieur mais je prépare juste une licence en cours du soir pour le moment !

Cela dit quand on parle d'éducation nationale l'algèbre SQL est loin d'être la seule chose enseignée et inutile plus tard dans la vie professionnelle de 99% des gens... Il n'y a qu'a regarder tous les maths qu'on se tape jusqu'au bac, personnellement je n'utilise pas le quart du quart du quart (et encore je compte large ^^) du contenu de mes cours de math de l'époque... quand je vois le nombre de jeunes qui ratent leurs études ou se voient aiguillés dans des filières exotiques juste parce qu'ils ont du mal à maitriser certaines notions quasi inutiles je trouve ça grave...

Après ça reste des trucs très intéressants mais plus pour la culture générale. Je trouve ça juste grave de risquer de planter des études à cause de ce genre de choses.

[CinePhil]

Bien d'accord avec toi, même si certains diront que le fait de maîtriser telle ou telle notion mathématique est le gage de pouvoir assimiler d'autres notions qui seront utilisées dans la profession visée.

Ça m'étonnerait quand même que ceux qui gèrent le contrat de nettoyage du musée Guggenheim à Bilbao, fussent-ils ingénieurs, utilisent les intégrales pour calculer la surface à nettoyer !

Ça risque de partir en troll cette discussion...

[fsmrel]

Vous aurez observé que la requête hermétique n'utilise pas l'opérateur MAX. On peut transformer la requête SQL de telle sorte qu'elle aussi se limite strictement aux opérateurs de base. Pour ma part, je propose :

Code :

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

1
2
3
4
5
6
7
SELECT Num_Lot
FROM   LOT
EXCEPT 
SELECT x.Num_Lot
FROM   LOT AS x JOIN LOT AS y
         ON  x.Num_Lot <> y.Num_Lot 
         AND x.Loyer_Mensuel < y.Loyer_Mensuel ;

A tester. Si vous avez d’autres solutions...