Discussion :

[M_Dandouna]

bonjour,
j'ai le shéma relationnel suivant:

Code :

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

1
2
3
4
5
6
 
Client (nom, age, genre, nc)
// le genre vaut ‘M’ ou ‘F’, nc est le n° de client
Commande (nc, produit, date, lieu, montant)
Télévente (nc, vendeur, date, résultat)
// démarchage par téléphone

La taille des données de chaque relation en nombre de blocs disque.
Client : 100 000 blocs
Commande : 2 000 000 blocs
Télévente : 300 000 blocs
On observe la charge suivante sur la base de données, nommée charge1 :
10% des requêtes sélectionnent une valeur de Cient.nc (i.e., de l’attribut nc de Cient)
30% ‘‘ ‘‘ ‘‘ Client.nom
35% ‘‘ ‘‘ ‘‘ Commande.produit
10% ‘‘ ‘‘ ‘‘ Télévente.vendeur
15% ‘‘ ‘‘ ‘‘ Télévente.date
Toutes les requêtes sont de type ciblé ou multi-point. On suppose que l’usage d’un index réduit le nombre de blocs à lire par rapport à une lecture séquentielle.
On suppose que l’espace disque disponible permet de créer seulement deux index.
Le problème est d'indiquer les 2 index qui permettent d'apporter un gain d’efficacité maximal et puis de quantifier ce gain.

est ce que dans ce cas l'usage d'un index de hachage sur l'attribut produit et d'un autre index B+tree sur l'attribut nc de la relation client permettent de procurer un gain d'efficacité maximale?
est ce qu'il existe déja une formule pour calculer le gain d'efficacité d'utilisation d'un index.

[Michel SALAIS]

Une formaule non!
Mais je dirai qu'il faut acheter des disques dans ce cas

Est-ce bien des blocs et non des lignes? Si oui alors quel est le nombre de blocs inutilisés dans chaque table actuellement?

Vous avez dit bloc disque? pas blocs Oracle?

[M_Dandouna]

c'est bien nombre de blocs disque.
En fait c'est un problème théorique , j'ai pas cré réellement les tables.
je dispose pas d'information sur le nombre de blocs inutilisés.

[Michel SALAIS]

Il s'agit donc d'une estimation préalable (en négligeant - éventuellement - la taille du bloc Oracle). De plus, cette estimation ne dit pas si ces chiffres sont pour ici et maintenant ou plutôt s'ils seront valables dans un an, deux ans ou peut être dix ans.

En tout cas, et en oubliant la question des formules, on peut considérer les deux points suivants:

- plus la tables est grande, plus l'index sera efficace
- plus la requête est fréquente, plus l'index sera utile

Alors, ces deux points votent sans discussion pour l'index sur la table "Commande". Quant au reste, juste le petir calcul suivant:

Prenons une durée de 10h de travail de la base avec cette application. 15% vaut alors 1h30 avec l'hypothèse "erronnée" d'égalité de temps d'exécution. Imaginer maintenant juste un instant que chacune des requêtes double son temps d'exécution alors à la place de 1h30 ce traitement occupera 3h00! La question est alors : Est-ce-que l'application est capable de maintenir les taux annoncées à l'origine?
Evidemment, l'utilisation d'un index peut réduire le temps d'exécution avec un taux qui dépasse de loin la proportion du simple au double.

Encore un autre point : une requête exécutée très fréquemment et en interactif doit retourner le résultat très rapidement.

Donc, un conseil : Penser dès maintenant à acheter des disques supplémentaires!

[M_Dandouna]

merci je prendrai en compte votre conseil