Discussion :

[momedalhouma]

Bonjour ,

Je me dirige vers vous pour une question qui me parait assez dificile , surtout que je trouve pas assez d'information su r le sujet.

La question est la suivante :

Soit S le schéma S = {R[B, C, E], S[A, B], T[A, D], U[D, F], V [A, B, C, D]}. càd nos tables

Supposons que l’on souhaite calculer la jointure de ces cinq relations. Puisque l’opérateur ✶ est commutatif et associatif, le résultat final ne dépend pas de l’ordre dans lequel on effectue les opérations.(operation de jointure)
Cependant, l’ordre peut être important d’un point de vue pratique.
1. Illustrez à l’aide d’une base de données concrète pourquoi l’expression suivante pose un problème pratique, même si aucun tuple de la base n’est dangling :
((((R ✶ S) ✶ T) ✶ U) ✶ V ).
Notez que les parenthèses fixent l’ordre dans lequel on effectue les opérations.
2. Donnez une expression (un ordre) qui évite ce problème. Expliquez comment vous trouvez cette
expression.

pourriez vous me dire plus de commentaires sur le sujet?avec un exemple ça serait plus interessant.



Merci

[SergioMaster]

Bonjour,

les questions ressemblent tellement à un exercice que je doute du bienfondé du sujet !

ce que je vois dans l'expression et que ça ne sert à rien de commencer par une jointure de R avec S puisque y'a aucune colonne qui est commune dans les deux tables.

je ne suis pas très pour des trucs totalement théorique et encore moins s'ils semblent mal écrit car moi je vois une colonne commune entre R et S : la colonne B

même si aucun tuple de la base n’est dangling

quant au dangling ça mériterait une traduction/explication !

[escartefigue]

Le résultat final ne dépend pas de l’ordre dans lequel on effectue les opérations.(operation de jointure)
Cependant, l’ordre peut être important d’un point de vue pratique.

En effet, et ce d'autant moins que de toutes façon, l'optimiseur fera bien ce qu'il voudra, sans tenir compte de l'ordre dans lequel les jointures ont été citées, ni des parenthèses qui auront été placées.
Du coup le titre de votre sujet est mal choisi, quelque soit l'ordre d'écriture des jointures, ce sera sans impact sur l'optimisation (au sens performances lors de l'exécution) puisque c'est l'optimiseur qui fera les choix

l’expression suivante pose un problème pratique

C'est quoi un problème pratique si on sait écrire la requête qui correspond au besoin et ici c'est tout à fait possible, alors il n'y a pas de problème pratique

[momedalhouma]

SergioMaster

vous aviez raison pour votre remarque , je n'ai pas fait attention.

pour le mot dangling tuple :

se sont les tuples qui vont jamais etre choisi dans la réponse finale :

exemple:

R=
A|B
1 2
3 4


S=
B|C
2 5
2 6
7 8



R join S=
A|B|C
1 2 5
1 2 6

on voit bien que le tuple 3 4 de la table R ne sera pas dans la réponse , la même chose pour le tuple 7 8 , donc on les appelle des dangling tuple.

donc l'idée d'un optimisation ça serait de ne pas passer du temps à faire des operation de jointure pour rien, et il faut choisir un ordre bien précis.

si je prends un autre exemple pour expliquer la mauvais caractere d'un tuple dangling le voici :



R=
A|B
1 2
2 2
3 2
4 2
5 2
6 2


S=
B|C
2 5

T=
C|D
4 1




R join S =
A|B|C
1 2 5
2 2 5
3 2 5
4 2 5
5 2 5

R join S join T =
A|B|C|D


on voit bien que malgré on a pas de réponse on a fait tout un long travail dans la première opération de jointure.

mais si on a inversé l'ordre de l'operation de jointure on aurais par exemple : T join S = rien puis on aurait pas besoin de faire l'autre jointure (join R).

l'idée ressemble à ce que j'ai expliqué mais j'ai des doutes et j'ai pensé trouvé de gens qui ont un bon background dans la théorie.

je suis ouvert à toute autre explication.

Merci

[escartefigue]

Comme expliqué plus haut, ce que vous mentionnez est un faux problème, l'optimiseur se charge de faire les jointures intelligemment, indépendamment de l'ordre selon lequel vous avez écrit les jointures

[SergioMaster]

Bonjour,

j'ai pensé trouver de gens qui ont un bon background dans la théorie.

ce qui n'est pas mon cas. De plus je suis d'accord avec le bourreau de service (escartefigue) le SGBD par l'intermédiaire de l'optimiseur risque de n'en faire qu'à sa tête de toute manière.
Pour moi, le sujet n'a pas vraiment sa place dans Autres SGBD
S'il s'agissait de créer un optimiseur pour un nouveau SGBD encore (bon courage)

Mais je pense plutôt qu'il s'agit d'un exercice scolaire destiné à faire réfléchir sur l'hypothétique comportement d'un optimiseur de requête.

D'ailleurs pourquoi vous occuper de dangling tuples (j'ai vraiment horreur de ce franglais) alors que dans l'intitulé de la question on vous indique de ne pas y faire attention !

même si aucun tuple de la base n’est dangling

une piste de bon sens serait de "ranger" les tables en fonctions du nombre de relations entre elles
par exemple : V à 2 relations avec S, R et T
il y a des colonnes "inutiles" R(E), U(F)

[momedalhouma]

SergioMaster


ben pour ce qui concerne le dangling tuple , j'ai répondu à votre requête et j'ai mis une explication de ce mot technique.

oui ,effectivement la question ou le sujet concerne la théorie qui est ensegnée en université.

bon c'est pas grave je chercherais ailleurs.

Merci

[SergioMaster]

Bonjour,

ben pour ce qui concerne le dangling tuple , j'ai répondu à votre requête et j'ai mis une explication de ce mot technique.

oh mais j'avais compris le terme, ce qui me consterne c'est l'utilisation de ce dernier comme si la langue française n'avait pas un terme adéquat comme, par exemple, tuple orphelin, isolé ....

oui ,effectivement la question ou le sujet concerne la théorie qui est enseignée en université.

encore plus consternant pour cet anglicisme !

bon c'est pas grave je chercherais ailleurs.

Comme je l'ai écrit, je ne pense pas que le sujet soit vraiment à sa place ici, c'est plus de l’algorithmie ou des mathématiques des ensembles que de la SGBD d'où la réaction d'escartefigue : "l'optimiseur se charge du boulot", au niveau du SQL ce n'est donc qu'une partie "esthétique"
, c'est à dire d'aide à la lecture, qu'autre chose.

Mes mathématiques, surtout des ensembles, sont très très loin