Le niveau externe - UML 2: Pour les bases de donnees - page 216

précision lottante comme REAL ou FLOAT , induirait fatalement des erreurs de calcul du
fait que les données sont mises à jour par différence et non par recalcul (erreurs d'écart
d'arrondi).
Bien que les vues indexées ou matérialisées soient d'une puissance phénoménale
lorsqu'elles sont judicieusement utilisées, il ne faut pas les systématiser. En effet, le but
d'une telle vue n'est pas de fournir l'exacte réponse à une requête, mais de participer à la
simpliication d'une partie de la requête inale…
Ainsi, il ne faut pas chercher à créer autant de vues indexées qu'il y a de requêtes
« lourdes », mais trouver quels sont les dénominateurs communs de ces lourdes requêtes
et factoriser le point dur par une vue matérialisée.
En effet, et comme toujours dans les bases de données, l'excès d'utilisation d'un système,
même très alléchant, peut conduire à l'effet inverse, car n'oublions pas que de telles vues
stockant les données constituent de la redondance, plombent le volume global de la base,
et plus encore, encombrent le cache des données…
Les vues objet (SQL3)
Présente avec Oracle et IBM DB2, une vue objet ( object view ) est une vue relationnelle étendue.
Les vues objet permettent de construire dynamiquement des objets analogues aux structures
C, classes C++ ou Java. Ce procédé bénéicie de la technologie du cache objet côté client et
réduit ainsi le traic réseau (données extraites et modiiées) entre la base et le programme d'ap-
plication. Il est possible de déinir une vue objet à partir de tables (elles-mêmes relationnelles
ou objet) ou de vues (relationnelles, objet ou matérialisées).
Figure 4-8 . Vues objet