Discussion :

[kochfet]

salut,

svp, j'ai besoin de connaitre la différence entre la jointure et la navigation dans les bases des données objet.

Merci d'avance.

[fsmrel]

Bonjour kochfet,


La jointure est un opérateur relationnel qui permet d’exprimer le Quoi.

Exemple :

Soit deux variables relationnelles (tables en SQL) A et B, la jointure « A JOIN B » permet d’obtenir les tuples de A et B qui ont la même valeur, pour les attributs de l’en-tête de A et B ayant même nom (voyez An Introduction to Database Systems de C. J. Date).

Plus généralement, si A, B, ..., Z sont des variables relationnelles impliquées pour produire un résultat, on écrit :

JOIN (A, B, ..., Z)

On est au niveau algébrique (théorie des ensembles) : produit cartésien + restriction, avec commutativité, associativité et toutes ces sortes de choses.

Par contraste, la navigation permet d’obtenir le même résultat à partir du paradigme du Comment, c'est-à-dire en suivant les pointeurs à un niveau inférieur (pointer-chasing), comme au bon vieux temps des systèmes pré-relationnels(qui ont pratiquement disparu, et pour cause) :

On va de A à Z en passant d'abord par B, puis par C, etc.

Pour en savoir plus, voyez le chapitre 25, « Object Databases » de An Introduction to Database Systems.

[kochfet]

Merci pour votre réponse

[kochfet]

svp jai une autre question :

Quelles avantages peut on avoir en utilisant la navigation (traversée par les pointeurs) pour traverser une expression du chemin?

[fsmrel]

Bonjour kochfet,

Pourriez-vous illustrer à partir d’un exemple concret (diagramme de classes ou MCD merisien ou MLD ou diagramme NIAM, ou autre) ce que vous attendez ?

[kochfet]

Tout d'abord merci pour la rapidité de votre réponse.

Ensuite, j'essaye de clarifier ma question.

Dans les bases de données objet, on a le concept "expression du chemin". Par exemple, j'ai une base des données composée de 3 classes C1 C2 et C3. j'ai une requête qui a un prédicat de la forme suivante : C1.a1.a2.attr="valeur" ou ai est un attribut de la classe Ci qui fait référence aux objets de la classe Ci+1 et attr est un attribut de la classe C3 qui a pour domaine un type littéral. L’évaluation de ce prédicat peut être faite :

-soit par un navigation via les références(ai)
-soit en utilisant des jointure successives entre Ci et Ci+1

Mon problème est que je n'ai pas compris les deux méthodes d’évaluation de ce prédicat.
Aussi, pouvez vous m'expliquer comment se déroule le transfert des pages entre le disque et la mémoire en exécutant ce prédicat avec les deux méthodes?

[fsmrel]

Pour citer Wittgenstein :

« Tout ce qui peut proprement être dit peut être dit clairement, et sur ce dont on ne peut parler, il faut garder le silence. »

Or si j’ai beaucoup chahuté les SGBD de 2e génération (hiérarchiques, navigationnels) puis les SGBD relationnels, je suis sec quant aux SGBD objets, aussi garderai-je le silence à leur propos...

Concernant l’échange entre le disque et la mémoire, chaque SGBD a sa stratégie. Pour fixer les idées, partons d’abords d’une traduction en relationnel des classes dont vous avez fait mention :

VAR C1 BASE RELATION {c1Id, ..., a1, ...}
    KEY {c1Id} ;

VAR C2 BASE RELATION {c2Id, ..., a1, a2, ...}
    KEY {c2Id} ;

VAR C3 BASE RELATION {c3Id, ..., a2, a3, attr, ...}
    KEY{c3Id} ; 

Votre requête est traduisible ainsi en relationnel :

JOIN {C1, C2, (C3 WHERE attr = 'valeur')}

Ce qui est une jointure naturelle des variables C1, C2, avec la restriction de C3 dotée de sa condition de restriction. Voilà pour le QUOI.

En ce qui concerne le COMMENT, j’illustrerai avec DB2 :





Mon programme comporte une instruction EXEC SQL SELECT. Lors de la compilation cette instruction est traduite sous forme d’un appel (CALL) à DB2. A l'exécution, le RDS (Relational Data System) prend le contrôle est examine ma requête (SELECT). Disons que le RDS est le mathématicien de la bande, il décortique la requête et la transforme en instructions compréhensibles par son compère l’informaticien (le Data Manager). A son tour, le Data Manager organise les instructions qu’il reçoit en instructions compréhensibles par le gestionnaire de la mémoire (le Buffer Manager) qui — si besoin est — sous-traite à VSAM (Virtual Sequential Access Method) qui est un des gestionnaires du disque de z/OS (système d’exploitation avec lequel DB2 collabore la mano en la mano). Un point important : le Data Manager est responsable du COMMENT, c'est-à-dire que c’est lui — avec l'aval du RDS — qui pilotera les accès aux données (par index, par hachage et autres joyeusetés), tandis que le Relational Data System réécrira, optimisera les requêtes que j'aurai plus ou moins habilement rédigées, sans que je sois au parfum des subtilités de la fermeture transitive et tout ça...)

Tout se passe donc sous le capot, peut-être des milliers d’instructions y sont exécutées de façon de plus en plus performante au fil des ans, car d’une version du SGBD à l’autre les composants de DB2 évoluent, que ce soit d’un point de vue algorithmique ou technologique. Et bien sûr, il existe d’autres composants que ceux que j’ai représentés, mais on ne va pas rentrer à fond dans la structure du SGBD. Quoi qu’il en soit, si ma requête a été écrite en 1986, elle n’a pas eu à être modifiée depuis ce temps-là.

En tout état de cause l’opérateur JOIN est par définition ensembliste, donc la notion de navigation est en l’occurrence parfaitement étrangère. Si navigation il y a c’est au binôme Data Manager / Buffer Manager de s’en occuper. C’est pourquoi, lorsque vous écrivez :

- soit par une navigation via les références(ai)

Alors j’ai le sentiment de revenir 40 ans en arrière. De même, quand je lis :

- soit en utilisant des jointures successives entre Ci et Ci+1

J'espère que vous m'excuserez, mais j’ai alors le sentiment d’être face à une contradiction, car la jointure est une opération ensembliste, tandis que le qualificatif « successif » nous ramène à nouveau à une époque révolue, celle du séquentiel et du pointer chasing...

[alassanediakite]

WAOU!!! fsmrel
Voici un bon moment que je fais de recherche sur ce coté là: transferts des données depuis le support au SGBD.
Voulez-vous que je vous envoie quelques unes de mes notes?
Deux questions (svp):
1->le tri (ORDER BY) se fait-il à l'étape 1 ou 2?
2->pour le cas de MySQL, MySQL et à l'étape 2 et le moteur de stockage (MyISAM, InnoDB...) est à l'étape 1?
@+

[fsmrel]

Voulez-vous que je vous envoie quelques unes de mes notes?

C’est gentil à vous, mais je suis inondé d’ouvrages théoriques ainsi que de docs techniques traitant des composants du moteur de DB2, et je ne vais certainement pas me lancer dans les internes de chaque SGBD (ça bouge dans le temps), je n'en ai ni l'envie ni le courage !

le tri (ORDER BY) se fait-il à l'étape 1 ou 2?

Pour les SGBD en général je n’en sais rien. Pour ce qui est de DB2 en particulier, je dirais : « Les deux mon général !» Le RDS (stage 1) supervise, pilote, synchronise les opérations de tri nécessitées par les fonctions SQL telles que la jointure, ORDER BY, DISTINCT, GROUP BY, mais il sous-traite au DM (stage 2) la réalisation des opérations (constitution des fichiers temporaires et tout ça).

pour le cas de MySQL

Pour appliquer la consigne de Wittgenstein, sur ce dont je ne peux parler, je garde le silence.

[alassanediakite]

Salut
Grand merci de la réponse. Je continue les recherches!
@+