Discussion :

[Francois_quad]

Salut a vous,

Je suis en DUT Informatique 2ème année et en semaine de partiels ...

J'ai quelques incompréhenssions a propos du cours de SGBD... Pourriez vous m'éclaircir les idées ?

- Index secondaire : Index sur une donnée non discriminante donnant pour chaque valeur de la clé la liste des adresse d'articles ayant cette valeur. Comprend pas vraiment

- Placement : Les articles sont placés en mémoire secondaire en fonction des valeurs d'un attribut ou d'un groupe d'attributs. En gros, les données sont triées et placées par une clé de placement ? C'est quoi une mémoire secondaire ?

Ce sera tout pour le moment !

Merci

[fsmrel]

Bonsoir François,

Personne ne répondant, je m'y colle.

Les données d’une table relationnelle occupant de la place (jusqu’à des téraoctets), elles ne peuvent résider intégralement en mémoire (RAM pour faire court). Un des composants d’un SGBD a pour mission de gérer la mémorisation (ou stockage) de ces données sur disque, donc de procéder aux lectures et écritures des enregistrements, appelés plus pompeusement pages. Une page = unité d’échange dans les entrées/sorties, dont l’ordre de grandeur d’échelonne généralement entre 512 octets et 64 KO (ou plus si affinité...) En conséquence, on qualifie le disque de mémoire secondaire, externe, auxiliaire, ou tout autre qualificatif plus ou moins poétique.

Avec l’index secondaire, on touche au même genre de patois. Dans le cas des SGBD, un index au sens large est généralement un fichier (ou un ensemble de fichiers) organisé en arbre équilibré. Par ailleurs, une table relationnelle est telle que ses lignes ne peuvent doublonner (en effet, une table est un ensemble). Pour garantir l’unicité d’une ligne, on lui associe une clé dite primaire. Par exemple, pour la table des employés, la clé primaire peut être le matricule de l’employé puisque 2 employés ne peuvent avoir même matricule. En descendant au niveau inférieur, celui de la quincaillerie, on assure l’unicité au moyen un index qualifié pour la circonstance de "primaire" (allusion à la clé primaire), dans lequel on ne peut avoir 2 fois même valeur de clé. Les feuilles de l’index hébergent la liste des adresses des pages contenant les données de la table : pour une valeur de clé, donc de matricule, on a une seule adresse, celle de la ligne de l’employé concerné, dont on accède ainsi aux données en moins de temps qu'il faut pour le dire.

Maintenant, pour éviter des accès séquentiels pouvant durer des heures et des heures, quand on recherche par exemple tous les employés nés un 15 janvier 1990, on associe pour cela à la table des employés un index organisé (trié) sur la date de naissance, tel qu’en le traversant verticalement, le SGBD obtienne très rapidement au niveau feuilles la liste des adresses (sur le disque) des pages de la table des employés répondant à la condition. Un tel index est appelé "non primaire" ou "secondaire" (ou ce qu’on veut, lieu, époque, chef, folklore obligent).

[Francois_quad]

Merci beaucoup fsmrel, tu éclaires un peu mon poly de bd !

Si je résume :
Imaginons la table :
Num Nom Métier DateDeNaissance
1 JAQUES BUCHERON 27-12-1986

Le plus logique serait de définir
La clé primaire est 1.
L'index serait la 'table' Num, Nom.
La clé secondaire serait DateDeNaissance ou encore Métier si on veux accéder le plus rapidement au travail.

Et tout cela serait stocké sur un disque dur (mémoire secondaire) car la mémoire primaire (RAM) n'aurait pas assez de place. En gros la mémoire secondaire, c'est un SWAP.

Merci beaucoup du coup de main,

François

[fsmrel]

Bonjour François,

Imaginons la table :
Num Nom Métier DateDeNaissance
1 JAQUES BUCHERON 27-12-1986

Le plus logique serait de définir
La clé primaire est 1.
L'index serait la 'table' Num, Nom.

Si la clé primaire de la table Personne (pour lui donner un nom) est composée du seul attribut Num, alors à son tour la clé de l'index primaire (appelons-le PersonneXP) est composée de ce seul attribut. En outre on déclare cet index comme de type UNIQUE, c'est-à-dire qu'une valeur de clé ne peut pas y figurer plus d'une fois, en sorte qu’au niveau supérieur l’unicité des clés primaires soit assurée.

Ainsi, l’attribut Nom ne peut pas entrer dans la composition de la clé primaire de la table Personne, car l’unicité de Num ne serait plus garantie : rien n’interdirait que pour Num = 1 on ait Nom = "Jacques " et aussi "François".

L'index primaire garantit la rapidité d’accès aux données de la table, mais son objet premier est de garantir une règle d’unicité. Garantir une règle par le biais d'un index n’est pas très propre, car on nous impose d’agir au niveau physique pour assurer une contrainte relationnelle. Mais bon, c’est l’habitude prise par la plupart des éditeurs de SGBD, on s'incline.

La clé secondaire serait DateDeNaissance ou encore Métier si on veux accéder le plus rapidement au travail.

Oui. Pour en revenir au couple {Num, Nom}, rien n’empêche, pour des raisons de performance cette fois-ci, de définir un index secondaire (appelons-le PersonneXnom) ayant pour clé ce couple {Num, Nom}. Considérons la requête SQL :

Select Num, Nom
From Personne
Where Num = 1 ;

On gagnerait un chouia en rapidité si l’on ne s’intéressait qu’à ces données, le SGBD trouvant l’information "Jacques" directement dans l’index PersonneXnom et évitant ainsi un ou deux, ou trois accès (disque) supplémentaires à la table elle-même. Cela dit, le jeu n’en vaut pas la chandelle (au moins dans cet exemple). En effet, non seulement l’index primaire PersonneXP garantit l’unicité, mais en outre il assure aussi la performance. En revanche, la mise en œuvre de l’index PersonneXnom engendrerait des effets secondaires lors des opérations de mise à jour (le système devant prendre le temps de mettre à jour cet index pour qu’il reste synchrone) et il faut donc garder à l’esprit le principe d’économie des ressources du système.

Maintenant, on peut avoir autant d’index secondaires que l’on veut, branchés sur la table Personne. Si effectivement de nombreux utilisateurs cherchent les personnes exerçant un métier donné, alors il devient intéressant, toujours pour des raisons de rapidité du temps de réponse, de définir un index (appelons-le PersonneXmetier) qui ne soit plus de type UNIQUE mais DUPLICATE (puisque plusieurs personnes peuvent exercer le même métier) : cet index a pour clé l’attribut Métier de la table Personne et la requête suivante sera performante (sauf si plus de 50% des personnes sont bucherons...) :

Select Num, Nom
From Personne
Where Métier = "bucheron" ;

Même principe quant à la définition d’un index secondaire dont la clé serait la date de naissance.

Et tout cela serait stocké sur un disque dur (mémoire secondaire) car la mémoire primaire (RAM) n'aurait pas assez de place. En gros la mémoire secondaire, c'est un SWAP.

Je ne connaissais pas l’expression "mémoire primaire", mais plutôt "mémoire principale" : ne vous en souciez pas, je suis d’une autre génération...

Vous avez dit SWAP ? Pourquoi pas ?