Performances : normalisation ou pas

Bonjours,
je dois créer une DB oracle dans laquelle on effectue plusieurs transactions/seconde, et j'hésite entre utiliser un schéma normalisé (plus pratique pour la maintenance et plus simple pour ajouter des dimensions) et un schéma dénormalisé (plus rapide pour les requêtes).
j'ai peut être une solution, mais je ne connais pas très bien le fonctionnement des views. je me dis que je pourrais utilisé un schéma normalisé, et créer un view dénormalisé.
ma question, est est ce que une view sauvegarde les données quelque part, ou exécute-elle la request sql (select ... pour retrouver les données) à chaque fois qu'on l'appelle?
Merci
AEMAG

Une vue créée avec CREATE VIEW ne stocke que du SQL dans le dictionnaire de la base à la différence d'une vue matérialisée créée avec CREATE MATERIALIZED VIEW qui crée une copie physique des données concernées.

effectivement les normalized views peuvent satisfaire à ton objectif mais avec des contraintes quant à leur mise à jour

je cosidère qu'il n'est pas problématique de dénormaliser le schéma d'une db pour satisfaire aux perfs des requêtes

d'autant que tu t'y atèles au moment de la création .

va également voir au niveau des possibilités qu'offrent les cluster et iot (index organized tables) qui sont tout deux des types d'objets particulier pour stocker efficacement les data

C'est difficile de ce décider par une position de principe. Oracle est quand même conçu pour être performant sur un schéma normalisé. Dénormaliser un schéma ne signifie pas forcément améliorer les performances il faut une réflexion d'ensemble avant. Il faut se concentrer sur les points sensibles, c'est à dire sur quoi portent tes transactions les plus récurentes et surtout quelles sont leurs natures:

- Modification: Alors attention, si la dénormalisation consiste à faire une grosse table avec plein de colonnes, et plein d'index ça risque d'être très couteux

- selection: tu peux faire les choses en 2 temps:
* 1ier temps: créer une simple vue sans toucher au schéma et faire les select sur cette vue (tu peux meme te fixer comme discipline de ne faire des selects que sur des vues)
* 2ieme temps SI tu n'arrives pas à améliorer les perfs de manière standart, alors tu transformes ta vue en vue matérialisée (çad une table) et à ce moment là il faut réfléchir au rafraichissement de cette table (complet, différentiel, au fil de l'eau par batch etc...)

Sur ton application, tu peux aussi te fixer comme discipline de ne passer que par des procédures stockées (avec retour de curseur). Comme ça, tu gardes totalement la main sur ton moteur de base de donnée et tu te reserves la possibilité de dénormaliser ce que tu veux par le PL/SQL.

Mais encore une fois, il n'y a pas de solution miracle toute faite, il faut étudier chaque cas particulier.

Citation:

---

Envoyé par Marc Musette

.
va également voir au niveau des possibilités qu'offrent les cluster et iot (index organized tables) qui sont tout deux des types d'objets particulier pour stocker efficacement les data

---

Je pense qu'il faut aussi regarder ces possibilités de stockage pour les tables sans doute assez méconnues mais parfois bien utiles avant de dénormaliser.

Pour ce que j'en comprend, ce que tu appeles schéma dénormalisé est en fait un schéma en étoile, méthode de stockage de base dans un datawarehouse.

un schéma en étoile est trés performant en requêtage mais difficilement maintenable pour des opérations transactionnelles.

Oracle dispose en effet de nombreuses optimisations pour améliorer les performances de ce type de base de données (index bitmap, star query, query rewrite...).

Les questions à se poser sont :
- est-ce que les utilisateurs ont de la liberté dans leurs requêtes (outils style business objects) ou sont limités par une interface utilisateur maison plus contraignante
- est-ce que j'ai le budget pour maintenir 2 modèles de données (une modif sur l'un impact le second)
- est- ce que la mise à disposition des données peut être différé dans le temps (par exemple, mise à jour quotidienne)


Concernant les vues matérialisées, regarde également les materialized view log qui sont des objets que l'on ajoute aux tables utilisées dans la requête de la vue (ouf...) et qui permettent de faire de l'incrémental... (bien expliqué dans la doc datawarehouse d'oracle).

Si tu poursuit dans la voie datawarehouse, tu peux trouver des infos sur la structure du modèle dans le guide datawarehouse de la doc oracle.
Si tu fait des recherches sur le web, les 2 pères du datawarehousing sont Ralph Kimball et Bill Inmon. Une recherche sur un de ces noms devrait te donner des pistes.
Les autres mots clés sont star schéma (étoile) et flake schéma (flocons). Tu aura peut être aussi des choses avec ROLAP (relationnal - OLAP)

merci à tous pour vos suggestions.
je suis en train d'effectuer des recherches sur les diffénrentes pièces.
AEMAG

est ce que l'utilisation des vues matérielles est compromise si on utilise oracle RAC?
merci

à ma connaissance non.

trois problèmes de contention sont reconnus au niveau du RAC par Oracle :
- l'utilisation de séquences pour générer des key indexs
- undo contention lorsque des SELECT sont lancés sur des données en cours de modification par d'autres transactions exécutées sur d'autres instances
- High Water Mark contention lorsque une application exécute des chargements massifs de données à partir d'instances différentes

Rassure moi 8O

Que veux tu dire quand tu parles de contention au niveau des séquences en RAC ? Cela ne joue que sur les perfs mais n'empeche pas de les utiliser. J'ai beaucoup de mal a imaginer une base Oracle sans séquence.

As tu une doc ou des infos sur le sujet pour que je puisse voir de quel type de contention il s'agit et voir si il y a des précautions a prendre pour les éviter.

Merci,

Bonsoir à tous

Excusez moi de déterrer ce vieux post, mais je suis également très surpris par ce pb de contention au niveau des séquences en RAC pour les PK

est-ce tjs d'actualité ?
en quelle release ce pb a t-il été détecté ?
aujourd'hui sur des RDBMS 10g et 11g faut-il encore s'en préoccuper ?

si oui, bonjour le pb de conception physique qui se pose aujourd'hui pour alimenter une clé informatique versus une clef utilisateur ?

pour ma part je ne suis jamais intervenu en environnement RAC, mais là je tombe un peu sur le cul

Bonjour,

C'est encore valable en 11g !

Voir la doc Officielle

Code:

---

1 2 3 4 5 6

If you use sequence numbers, then always use CACHE with the NOORDER option for optimal sequence number generation performance. With the CACHE option, however, you may have gaps in the sequence numbers. If your environment cannot tolerate sequence number gaps, then use the NOCACHE option or consider pre-generating the sequence numbers. If your application requires sequence number ordering but can tolerate gaps, then use CACHE and ORDER to cache and order sequence numbers in Oracle RAC. If your application requires ordered sequence numbers without gaps, then use NOCACHE and ORDER. This combination has the most negative effect on performance compared to other caching and ordering combinations. #   If you use indexes, then consider alternatives, such as reverse key indexes to optimize index performance. Reverse key indexes are especially helpful if you have frequent inserts to one side of an index, such as indexes that are based on insert date.

---