Discussion :

[aemag]

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

[pifor]

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.

[Marc Musette]

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

[remi4444]

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.

[pifor]

.
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.

[Hugues_78]

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)

[aemag]

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