56
Chapitre 4. Optimisation des objets et de la structure de la base de données
d’exécution utilisant l’opérateur de jointure de fusion (merge join), un algorithme de
jointure très rapide, etc.
Citoyens, n’ayez pas peur de la normalisation ! Ne tombez pas dans le piège consistant à croire que l’augmentation du nombre de tables va rendre votre code SQL
compliqué, et va faire baisser les performances. Créer des tables qui ne respectent pas
au moins les trois premières formes normales vous entraînera dans une multitude de
problèmes avec lesquels vous serez obligé de vivre quotidiennement. Prenez dès le
début de bonnes habitudes. En ce qui concerne la complexité, vous pouvez la dissimuler par la création de vues, qui sont, du point de vue du modèle relationnel, conceptuellement identiques aux tables.
Pour aller plus loin, nous vous conseillons de vous procurer un bon ouvrage sur la
modélisation relationnelle, comme par exemple « UML 2 pour les bases de
données », de Christian Soutou.
Modèle OLAP
En 1993, Edward F. Codd publia un livre blanc nommé « Providing OLAP (On-line
Analytical Processing) to User-Analysts: An IT Mandate », dans le but de préciser les
exigences d’applications destinées à l’analyse de vastes volumes de données, ce qu’on
appelle aujourd’hui de plusieurs termes : systèmes d’aide à la décision (decision
support system, DSS), business intelligence, décisionnel, etc. Malgré la légère polémique autour de cet article, commandité par Hyperion (l’entreprise s’appelait alors
Arbor Software) donc peut-être partiel, sans doute plus écrit par ses collaborateurs
que par Codd lui-même, et en tout cas non supporté par Chris Date, l’associé de
Edward Codd, l’écrit popularisa le terme OLAP, par opposition à OLTP. Un système
OLTP (OnLine Transactional Processing) est en perpétuelle modification, les opérations qui s’y exécutent sont encapsulées dans des transactions, ce qui permet un
accès multi-utilisateurs en lecture comme en écriture. C’est pour ce genre de système
que le modèle relationnel, les douze lois de Codd (qui sont en réalité au nombre de
treize) et les formes normales furent conçus.
Un système OLAP (OnLine Analytical Processing) est utilisé principalement en
lecture, pour des besoins d’analyse et d’agrégation de larges volumes de données.
Alors que les requêtes OLTP se concentrent en général sur un nombre réduit de
lignes, les requêtes analytiques doivent parcourir un grand ensemble de données
pour en extraire les synthèses et les tendances. Les systèmes OLAP sont en général
implémentés en relation avec des entrepôts de données (data warehouses) parfois
constitués en « succursales » nommées data marts. Ces entrepôts centralisent toutes
les données (opérationnelles, financières, etc.) de l’entreprise (ou du groupe) – souvent avec une perspective historique – provenant de tous les services, pour offrir une
vision globale de l’activité et des performances (figure 4.5).
Chapitre 4. Optimisation des objets et de la structure de la base de données
d’exécution utilisant l’opérateur de jointure de fusion (merge join), un algorithme de
jointure très rapide, etc.
Citoyens, n’ayez pas peur de la normalisation ! Ne tombez pas dans le piège consistant à croire que l’augmentation du nombre de tables va rendre votre code SQL
compliqué, et va faire baisser les performances. Créer des tables qui ne respectent pas
au moins les trois premières formes normales vous entraînera dans une multitude de
problèmes avec lesquels vous serez obligé de vivre quotidiennement. Prenez dès le
début de bonnes habitudes. En ce qui concerne la complexité, vous pouvez la dissimuler par la création de vues, qui sont, du point de vue du modèle relationnel, conceptuellement identiques aux tables.
Pour aller plus loin, nous vous conseillons de vous procurer un bon ouvrage sur la
modélisation relationnelle, comme par exemple « UML 2 pour les bases de
données », de Christian Soutou.
Modèle OLAP
En 1993, Edward F. Codd publia un livre blanc nommé « Providing OLAP (On-line
Analytical Processing) to User-Analysts: An IT Mandate », dans le but de préciser les
exigences d’applications destinées à l’analyse de vastes volumes de données, ce qu’on
appelle aujourd’hui de plusieurs termes : systèmes d’aide à la décision (decision
support system, DSS), business intelligence, décisionnel, etc. Malgré la légère polémique autour de cet article, commandité par Hyperion (l’entreprise s’appelait alors
Arbor Software) donc peut-être partiel, sans doute plus écrit par ses collaborateurs
que par Codd lui-même, et en tout cas non supporté par Chris Date, l’associé de
Edward Codd, l’écrit popularisa le terme OLAP, par opposition à OLTP. Un système
OLTP (OnLine Transactional Processing) est en perpétuelle modification, les opérations qui s’y exécutent sont encapsulées dans des transactions, ce qui permet un
accès multi-utilisateurs en lecture comme en écriture. C’est pour ce genre de système
que le modèle relationnel, les douze lois de Codd (qui sont en réalité au nombre de
treize) et les formes normales furent conçus.
Un système OLAP (OnLine Analytical Processing) est utilisé principalement en
lecture, pour des besoins d’analyse et d’agrégation de larges volumes de données.
Alors que les requêtes OLTP se concentrent en général sur un nombre réduit de
lignes, les requêtes analytiques doivent parcourir un grand ensemble de données
pour en extraire les synthèses et les tendances. Les systèmes OLAP sont en général
implémentés en relation avec des entrepôts de données (data warehouses) parfois
constitués en « succursales » nommées data marts. Ces entrepôts centralisent toutes
les données (opérationnelles, financières, etc.) de l’entreprise (ou du groupe) – souvent avec une perspective historique – provenant de tous les services, pour offrir une
vision globale de l’activité et des performances (figure 4.5).