Discussion :

[Kakashisenc]

Bonjour ,
J'ai un soucis je dois ecrire trois requete en algebre relationnel cependant je ne sais pas si ma methode est bonne .
J'ai le schema relationnel suivant :
Instrument(modele,type,fabricant)
Vendre(nomMag,modele,prix)
Artiste(nom,nationalite,debutC)
Concert(numC,lieu,date,prix)
Joue(numC,nom,modele)

1) le nom des guitariste bresilien
2)le nom des magasins qui vendent des guitares et basse
3) le nom des artistes qui n'ont jamais joué à Paris

1) SELECTION ( Projection(nationalite = ' Bresilien')(Artiste) JOINTURE joue JOINTURE(joue.modele = instrument.modele and type='guitare') Instrument )

2) SELECTION(nomMag) (Vendre) JOINTURE(vendre.modele = instrument.modele AND (type = 'guitare' OR type = 'basse')

3) ?

Merci de m'avoir lu et de votre aide

[fsmrel]

Bonsoir Kakashisenc,


Vous ne fournissez pas la grammaire que vous utilisez, on ne peut donc pas juger de la validité de vos réponses. En tout cas, dans votre 2e réponse, il manque une parenthèse droite.


Quoi qu’il en soit, pour connaître les artistes qui n’ont jamais joué à Paris :

Dans le cadre de la théorie relationnelle, en découpant les opérations :

1) On effectue la projection de la variable joue sur l’attribut nom :

e1 = joue {nom}

La variable e1 représente l’ensemble des noms des artistes.

2) On effectue la restriction de la variable concert sur l’attribut lieu :

e2 = concert WHERE lieu = 'Paris'

La variable e2 représente le sous-ensemble des concerts donnés à Paris.

3) On effectue la jointure de e2 avec la variable joue :

e3 =e2 JOIN joue

On a ainsi le sous-ensemble des artistes ayant joué à Paris.

4) On projette e3 sur l’attribut nom :

e4 = e3 {nom}

On a ainsi le sous-ensemble des noms des artistes ayant joué à Paris.

5) On effectue la différence entre e1 et e4 :

r = e1 MINUS e4

On obtient ainsi l’ensemble des noms des artistes qui n’ont jamais joué à Paris.


En une expression :

r = joue {nom} MINUS (concert WHERE lieu = 'Paris' JOIN joue) {nom}

A adapter en fonction de votre grammaire...



Version SQL (MINUS devient EXCEPT) :

SELECT nom
FROM   joue     

EXCEPT

SELECT nom
FROM   concert JOIN joue ON concert.numC = joue.numC
WHERE  lieu = 'Paris' ;

[StringBuilder]

Autant je comprends qu'on apprenne l'algorythmie avec un pseudo langage algébrique, histoire de ne pas se fausser la tête avec des vocables liés à un langage en particulier (un même algo en C, en VB ou en Java auront des tronches complètement différentes).

Autant pour l'algèbre relationnel... Etant donné que :
- Le SQL est le seul (ou presque) langage, supporté par 100% des SGBD du marché (ou presque)
- Que c'est un langage qui est parfaitement lisible par être humain "SELECT SUM(PRICE) FROM ORDERS WHERE CUSTOMER_ID = 1" : après un court de 5 minutes d'anglais à ma grand-mère de 96 ans, elle est capable de comprendre cette requête

J'ai du mal à comprendre l'intérêt de bourrer le crâne avec une grammaire différente, qui n'a à mon sens pas d'autre but que d'embrouiller complètement les élèves (et éventuellement leur empêcher de repomper des solutions aux exercices sur internet).

Encore un prof qui a de la chance de faire son métier, car dans la vie active, il serait certainement chômeur, ou frustré dans un bureau à côté de la photocopieuse...

[escartefigue]

J'ai du mal à comprendre l'intérêt de bourrer le crâne avec une grammaire différente, qui n'a à mon sens pas d'autre but que d'embrouiller complètement les élèves (et éventuellement leur empêcher de repomper des solutions aux exercices sur internet)

Je plussoie avec énergie, ça ne sert absolument à rien hors cadre scolaire
D'ailleurs la logique n'est pas complètement respectée, car il ne faudrait pas écrire
"SELECTION(nomMag) (Vendre) JOINTURE(vendre.modele = instrument.modele AND (type = 'guitare' OR type = 'basse')"
mais
SELECTION(nomMag) (Vendre) JOINTURE(vendre.modele = instrument.modele et plus encore (type = 'guitare' ou alors type = 'basse')
Ce n'est plus de l'informatique mais de la litérature

[Kakashisenc]

Merci pour vos reponse j'ai reussis a faire l'exo .
Sql s'est construit sur de l'algebre relationnel , comprendre l'algebre relationnel permet une utilisation plus intelligente des base de données. C'est toujours plus interessant de savoir comment on a construit ce qu'on utilise que d'utiliser la chose d'autruit sans chercher a comprendre enfin c'est mon avis et surement celui de ma fac .

[fsmrel]

Bonsoir,

Sql s'est construit sur de l'algebre relationnel

Faux ! Historiquement les choses se sont passées ainsi :

En 1971, Ted Codd (père du modèle relationnel de données) a proposé ALPHA, langage calé sur le calcul relationnel (implémentation du calcul des prédicats). Voici le résumé qu’il donne dans son article A Data Base Sublanguage Founded on the Relational Calculus :

« Three principal types of language for data base manipulation are identified: the low-level, procedure-oriented (typified by the CODASYL-proposed DML), the intermediate level, algebraic (typified by the Project MAC MacAIMS language), and the high level, relational calculus-based data sublanguage, an example of which is described in this paper. The language description is informal and stresses concepts and principles. Following this, arguments are presented for the superiority of the calculus-based type of data base sub-language over the algebraic, and for the algebraic over the low-level procedural. These arguments are particularly relevant to the questions of inter-system compatibility and standardization. »

Ainsi, pour Codd le calcul relationnel est supérieur à l’algèbre relationnelle car le calcul permet de déclarer le QUOI de façon non procédurale, c'est-à-dire en une fois, en vertu de quoi l’optimiseur d’un SGBD pourra estimer la meilleure séquence des opérations à effectuer sous le capot pour obtenir le résultat dans les meilleurs délais. En revanche, l’algèbre étant procédurale, le processus d’optimisation est du ressort de l’utilisateur, ce qui n’est pas idéal, car car telle séquence d'opérations peut avoir de bonnes performances aujourd’hui et catastrophiques le lendemain, nécessitant une intervention manuelle (voyez Pénélope !). Le seul avantage qu’offre l’algèbre est que l’on n’a pas à utiliser les quantificateurs nécessaires au calcul (∀, ∃). Calcul et algèbre sont décrits dans l’article de Codd Relational completeness of data base sublanguages (1972).

En 1973, dans leur article Specifying Queries as Relational Expressions: The SQUARE Data Sublanguage des collègues de Codd chez IBM, Raymond Boyce (mort trop tôt en 1974 d’une rupture d’anévrisme) et Donald Chamberlin proposèrent le langage SQUARE, non algébrique (pour les raisons évoquées ci-dessus), mais orienté ALPHA, débarrassé toutefois des quantificateurs, des variables liées et autres joyeusetés du calcul (tandis qu’à l’époque, le langage QUEL de M. Stonebraker et E. Wong reste conforme au calcul). Je cite :

« SQUARE is intended for use by the nonprogramming professional »

En même temps, Boyce et Chamberlin proposèrent SEQUEL, je cite à nouveau :

« An unsophisticated user would feel more comfortable with an English-like notation. Therefore, a block-structured English-keyword syntax, based like SQUARE on the concept of mapping, has been developed. This syntax, called SEQUEL, is described elsewhere. A direct translation of most SQUARE queries to SEQUEL is possible, as illustrated below by several examples. A prototype implementation of the SEQUEL language is now operational at the IBM Research Laboratory in San Jose, California. »

Vous retrouverez tout ça dans l’article rafraîchi et paru en 1975 (Specifying Queries as Relational Expressions: The SQUARE Data Sublanguage). Plus tard, pour des problèmes de copyright, SEQUEL a perdu ses voyelles pour devenir SQL, mais ça c’est une autre histoire...

Vous aurez remarqué que vos réponses à l’exercice sont déclaratives et non pas procédurales, votre langage mime donc SEQUEL, lequel, comme on vient de le voir, n’a manifestement pas été conçu pour être un langage algébrique.

CQFD