Performance Des Données

Ingres Performance des données
I. L'OPTIMISATION DU MLD............................................................................................................................3
A. UTILISATION D'ATTRIBUTS DÉRIVÉS (CALCULÉS).......................................................................................................3
B. REDONDANCE D'INFORMATIONS..............................................................................................................................4
C. REDONDANCE DE RELATIONS.................................................................................................................................4
D. TABLES ET SOUS-ENTITÉS.....................................................................................................................................5
1. Regroupement dans une seule table..........................................................................................................6
2. Une table pour chaque sous-ensemble......................................................................................................6
3. Une table pour les données communes et répartition dans d'autres tables des données spécifiques de
chacun des sous-ensembles............................................................................................................................7
4. Une table avec un attribut "indicateur".....................................................................................................7
E. LES RELATIONS DE DEGRÉ N:M...............................................................................................................................7
F. LES ATTRIBUTS DE SYNTHÈSE.................................................................................................................................8
G. LE DÉCOUPAGE VERTICAL OU HORIZONTAL D'UNE TABLE..........................................................................................10
1. Le découpage vertical..............................................................................................................................10
2. Le découpage horizontal..........................................................................................................................11
H. LE TRONC COMMUN DE DONNÉES.........................................................................................................................11
I. OPTIMISATION DU NOMBRE DE LIGNES OU DU NOMBRE DE COLONNES...........................................................................13
II. L'OPTIMISATION DU MODÈLE PHYSIQUE..........................................................................................14
A. RÉPARTITION DES DONNÉES DANS UNE OU PLUSIEURS BASES.....................................................................................14
B. LES DIFFÉRENTS TYPES DE DONNÉES.....................................................................................................................15
1. Les types de données caractères..............................................................................................................15
2. Les types de données numériques............................................................................................................16
3. Le type date..............................................................................................................................................16
4. Le type money..........................................................................................................................................16
5. Le type logical key...................................................................................................................................17
C. LA VALEUR NULL...........................................................................................................................................18
D. UTILISATION DES SCHÉMAS ÉTENDUS....................................................................................................................18
1. Elaboration d'un bilan CLMS..................................................................................................................19
2. Interprétation et utilisation des résultats.................................................................................................21
E. LES STRUCTURES DE STOCKAGE............................................................................................................................22
1. La structure Heap....................................................................................................................................22
2. La structure Hash....................................................................................................................................24
3. La structure ISAM....................................................................................................................................26
4. La structure Btree....................................................................................................................................28
5. Le débordement de pages........................................................................................................................31
6. Tableau récapitulatif...............................................................................................................................32
F. UTILISATION DES CLÉS........................................................................................................................................34
1. La duplication ou l'unicité des clés..........................................................................................................34
2. La longueur des clés................................................................................................................................34
3. Utilisation des clés composites................................................................................................................35
4. Les clés de substitution............................................................................................................................35
G. UTILISATION DES INDEX SECONDAIRES..................................................................................................................37
1. Création d’un index.................................................................................................................................38
2. Modification d’un index...........................................................................................................................39
3. Suppression d’un index............................................................................................................................41
H. L’UTILISATION DES VUES....................................................................................................................................42
I. LA COMMANDE SYSMOD.......................................................................................................................................43
III. L'OPTIMISEUR DE REQUÊTES...............................................................................................................44
A. PRÉSENTATION DE L'OPTIMISEUR..........................................................................................................................44
B. UTILISATION DES STATISTIQUES............................................................................................................................46
1. Définition.................................................................................................................................................46
2. La commande optimizedb........................................................................................................................46
3. La commande statdump...........................................................................................................................47
C. UTILISATION DES QEP......................................................................................................................................48
1. Définition.................................................................................................................................................48
2. Interprétation des QEP............................................................................................................................48
D. LES MESURES DE PERFORMANCES.........................................................................................................................53
DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 1/70

1. Les différentes mesures............................................................................................................................53

2. Le coût des mesures de performances.....................................................................................................54
IV. ANALYSE DE REQUÊTES COMPLEXES................................................................................................55
A. RECOMMANDATIONS..........................................................................................................................................55
B. LE LISSAGE DES REQUÊTES..................................................................................................................................55
C. LISSAGE DES REQUÊTES CORRÉLÉES AVEC AGRÉGAT................................................................................................57
D. LES REQUÊTES COMPLEXES..................................................................................................................................58
1. Utilisation de la clause HAVING............................................................................................................58
2. Utilisation des agrégats fusionnés...........................................................................................................61
V. LES PROCÉDURES BASE DE DONNÉES..................................................................................................62
A. DÉFINITION......................................................................................................................................................62
B. CRÉATION D'UNE PROCÉDURE BASE DE DONNÉES.....................................................................................................62
C. INTÉRÊT DE L'EMPLOI D’UNE PROCÉDURE :.............................................................................................................64
D. OCTROI DES PERMISSIONS D'UTILISATION DES PROCÉDURES BASE DE DONNÉES.............................................................67
E. DESTRUCTION D'UNE PROCÉDURE BASE DE DONNÉES................................................................................................67
VI. LES RÈGLES..................................................................................................................................................68
A. DÉFINITION......................................................................................................................................................68
B. CRÉATION D'UNE RÊGLE......................................................................................................................................69
C. DESTRUCTION D'UNE RÈGLE.................................................................................................................................70

Introduction
Ce cours a pour but de présenter les différentes possibilités permettant

d'obtenir du SGBDR Ingres les meilleures performances possibles, notamment
en ce qui concerne la rapidité d'accès à l'information. Cette recherche
d'optimisation va s'orienter vers 4 axes principaux :
- L'étude du Modèle Logique des Données

- L'étude du Modèle Physique des Données
- L'étude des requêtes
- L'utilisation des procédures base de données et des rêgles
I. L'optimisation du MLD
La construction du MLD est une opération quasi automatique à partir d’un
MCD ou en application des règles de normalisation. Mais la conception d'une
base de données n'est pas une science exacte et, selon les cas, il peut être
nécessaire, toujours dans un souci d'optimisation, de modifier le résultat de
cette opération.
Avertissement : ce paragraphe présente différentes situations dans lesquelles
vous pouvez être conduit à dénormaliser le modèle de données. Ce serait une
erreur de prendre en compte ces considérations dès l’élaboration d’un modèle
conceptuel : celui-ci doit rester représentatif de l’organisation réelle des
données sans souci des performances. Ils vous appartient de distinguer
nettement ces deux étapes de la construction d’une structure de données.
D’autre part, les observations ou hypothèses qui vous conduisent à
dénormaliser le modèle de données doivent être rigoureusement enregistrées.
Il se peut en effet que la situation évolue au cours de l’optimisation et que les
raisons évoquées pour une modification ne soient plus valides. Vous devrez
alors effectuer d’autres choix.
A. Utilisation d'attributs dérivés (calculés)

Un attribut dérivé est calculé à partir d'autres attributs. (ex : PrixTTC = PrixHT
+ TVA). Normalement cet attribut, étant redondant, n'est pas stocké dans la
base. Cependant, si cet attribut est très souvent interrogé ou si le calcul exige
beaucoup de temps processeur, il sera alors conseillé de conserver le résultat de
ce calcul dans la base. Dans ce cas, en revanche, il faudra prévoir une

procédure de recalcul du prix TTC en cas de modification soit du prix HT soit

de la TVA.
B. Redondance d'informations
En reprenant l'exemple des deux tables :
factures (nfac, ncli*, date)
clients (ncli, nomcli, prénomcli, ruecli, villecli)
Après étude des transactions à effectuer, on s'aperçoit qu'à chaque lecture d'une
facture, on a besoin du nom et du prénom du client. Pour éviter donc à chaque
fois d'accéder aux deux tables, les attributs nom_c et prénom_c vont être
dupliqués dans la table facture :
factures (nfac, ncli*, nomcli, prénomcli, date)
On évite ainsi un accès aux deux tables à chaque consultation. Par contre, la
redondance de l’information est coûteuse en espace disque et modifie
l’opération de création d’une facture (obligation de lire la table clients).
C. Redondance de relations
Considérons le MLD suivant :
Constat : tout rapprochement d’informations entre un site et un projet ou entre

un département et un projet ne peut s’obtenir que par jointure via la table des
employés, ce qui peut être pénalisant.
Si l’on a besoin de répondre aux questions suivantes :
- Quels sont les projets d'un site ?

- Quels sont les projets d'un département ?

il faut alors caractériser les relations entre département et projet et entre site et
projet.
Le cas le plus favorable, un projet ne concerne qu’un département et un seul

site, vous conduit à introduire les clés primaires de site et de département dans
projet. On obtient alors :
projet (num_proj, proj, idsite*, iddept*)
D. Tables et sous-entités
Deux cas peuvent se présenter :
- Les données sont stables et appartiendront toujours au même sous-ensemble

- Les données sont volatiles. Nombreux passages d'un sous-ensemble à un

autre.
Exemple : les commerciaux d’une société sont payés à la commission, les
autres employés sont payés au mois.
Trois solutions sont envisageables :
1. Regroupement dans une seule table

Cette solution élimine la dispersion des lignes entre les différentes tables, évite
les unions si les données des différents sous-ensembles sont accédées en même
temps, évite les jointures et facilite l'écriture des requêtes.
Par contre, cette solution entraîne une forte taille de la table, un fort
pourcentage de valeurs nulles et augmente le risque d'accès concurrents.
Exemple :
Emp (nemp, nom,prenom,salaire,commission)
2. Une table pour chaque sous-ensemble

Ce qui entraîne une diminution des problèmes d'accès concurrents, permet de
varier les structures de stockage. Les tables sont plus petites (si répartition
équilibrée entre les deux) ce qui permet d'accélérer les opérations de
maintenance (restructuration, construction des index, sauvegardes, …). Pas de
valeurs NULL.
En revanche, les requêtes et les transferts entre tables seront plus complexes.
Exemple :
Emp (nemp,nom,prenom,salaire)
Com(ncom,nom,prenom,commission)

3. Une table pour les données communes et répartition dans d'autres

tables des données spécifiques de chacun des sous-ensembles
Cette solution est intéressante si les colonnes communes sont les plus
fréquemment consultées.
Exemple :
Emp(nemp, nom, prenom)
Salaire(nemp, salaire)
Com(nemp, com)
4. Une table avec un attribut "indicateur".

Une seule table à laquelle on ajoute un attribut qui indique la position de
l'employé (salarié ou commercial).
Emp(nemp, nom, prenom, s/c, montant)
E. Les relations de degré n:m

Lorsqu’une relation est presque toujours de degré 1:1/1:n et rarement de degré
1:n/1:n, il est possible de générer un modèle logique traitant le cas général de la
façon la plus simple.
Exemple : - 95% des employés appartiennent à un seul département
- 5% travaillent dans plusieurs départements.
La façon la plus classique de modéliser ce cas est représentée ci-dessous :
Le modèle relationnel compte alors les 3 tables :

Employé(idemp, nom)
Département(iddept, nom)
Appartenir(idemp, iddept, date)

L’autre solution proposée consiste à traiter séparément le cas général et le cas

particulier. On obtient alors le MCD suivant :
Et le modèle relationnel :
Employé(idemp, nom, iddept*, date)
Département(iddept, nom)
AutreAffectation(idemp, iddept, date)
La façon de traiter 95% des employés est ainsi facilitée. La relation

AutreAffectation ne sera employée que dans 5% des cas.
F. Les attributs de synthèse

Les 3 cas présentés ci-dessous peuvent vous conduire à regrouper plusieurs
propriétés en un seul attribut dit de synthèse. De tels attributs représentent alors
plusieurs informations (ils ne respectent donc pas la première forme normale).
Il existe 3 types d’attributs de synthèse :
- L'attribut codé ou concaténé : code intégré qui décrit une information non
représentée directement par l'attribut . (Ex : le numéro d'un livre d'une
bibliothèque est fonction du sujet (entre 1 et 999 : policier)) ou attribut
construit sur un domaine composite par concaténation de plusieurs codes (Ex :
un numéro de police d'assurance composé du CodeTypePolice, du CodeRégion
et du CodeClient)

- L'attribut avec recouvrement : attribut dont les valeurs ne s'excluent pas.

Exemple : - il existe 2 types de batiments (bureau, production)
- un batiment peut être de type production, bureau ou les deux.
Le modèle relationnel théorique est donc :

Batiment(numbat, …)
TypeBatiment(type, …)
Appartenir(type, numbat)
Dans certains cas ce modèle peut être amélioré en créant une nouvelle
occurrence de type de batiment : bureau et production. Dans ces conditions, un
batiment n’appartient plus qu’à un seul type : bureau ou production ou bureau
et production, et le MLD est simplifié :
Batiment(numbat, …, type*)
TypeBat(type, …)
- L'attribut alterné : Attribut dont la signification change selon la valeur d'un

autre attribut. (Ex : la paie d'un professeur est un salaire brut mensuel alors que
celle d'un vacataire est un taux horaire.
Avantages des attributs de synthèse :

- Création d’une clef multicolonne avec un seul attribut
- Economie de place disque
- Simplification des jointures (elles ne portent plus que sur 1 attribut)
- Représentation d’une information que l'utilisateur veut manipuler.
Inconvénients :
- Ces attributs qui ne respectent pas la première forme normale peuvent
poser des problèmes de codage et de décodage. Ils sont inintéressants si
les accès à une partie de l'attribut sont fréquents.

G. Le découpage vertical ou horizontal d'une table
1. Le découpage vertical
Dans une base normalisée, tous les attributs d'une entité seraient placés dans
une table unique. Le découpage vertical consiste à répartir ces attributs dans
des tables séparées.
Employés(NumEmp, Nom, Dépt, Tél, Fonction, CV)
Si la consultation du CV est rare, on peut envisager cette solution :

Employés(NumEmp, Nom, Dépt, Tél, Fonction)
EmpCV(NumEmp, CV)
Avantages :
- Tables plus petites (en nombre d'attributs) donc plus faciles à trier et à
restructurer.
- Réduction du temps d'exécution des requêtes lorsque l'une des tables contient
les informations les plus demandées et l'autre les informations plus rarement
manipulées.
- Moins de problèmes d'accès concurrents lorsque les utilisateurs mettent à jour
simultanément des sous-ensembles de colonnes répartis dans des tables
différentes.
- Possibilité de varier les structures de stockage selon les tables.
Inconvénients :
- Des jointures supplémentaires seront plus souvent nécessaires même dans des
requêtes simples
- Les mises à jour peuvent nécessiter des transactions multi-requêtes.

2. Le découpage horizontal
Ce découpage correspond au partage d'une entité en plusieurs sous-entités,
même si leurs attributs sont identiques.
Ex :
Romans (NumCatalogue, Isbn, Titre, …)
Essais (NumCatalogue, Isbn, Titre, …)
Avantages :
Pas besoin de préciser le type d'ouvrage.
Tables plus petites donc plus rapides à trier et à restructurer.
Evite les problèmes d'accès concurrents lors de requêtes simultanées sur des
sous-entités différentes.
Possibilité de varier les structures de stockage selon les tables.
Diminution faible de la profondeur des index (nombre de niveaux d’index à
parcourir pour atteindre une occurrence. La profondeur d’index dépend du
nombre d’occurrences de la table et de la taille des index).
Inconvénient :
Des requêtes simples vont parfois nécessiter une union.
H. Le tronc commun de données

Un tronc commun consiste à rassembler dans une table unique les attributs de
même nature et de même format de tables différentes.
Exemple :
Pièce (NumPiece, NomPiece, QteStock, CommentPiece)
Client(NumCli, NomCli, PrenomCli, AdresseCli, CommentCli)
Projet(NumProj, NomProj, DateProj, CommentProj)
La modification consiste ici à créer une nouvelle table commentaire dont

chaque occurrence sera le commentaire d’une pièce, d’un client ou d’un projet.

On obtient alors :
Pièce (NumPiece, NomPiece, QteStock)
Client(NumCli, NomCli, PrenomCli, AdresseCli)
Projet(NumProj, NomProj, DateProj)
Commentaire (NumComment, Comment)
Attention, dans ce cas il faudra veiller à utiliser des numérotations différentes

pour les pièces, les clients et les projets.
p1 à pn pour les pièces, c1 à cn pour les clients, etc...
1 à 100 pour les pièces, 101 à 200 pour les clients, etc…
Sinon il faudra utiliser une clé étrangère par table tronquée. Dans chaque
occurrence une seule sera renseignée, les deux autres seront à NULL :
Commentaire (NumPiece,NumCli,NumProj, Comment)
Avantage :
- Permet de diminuer le volume des tables tronquées, notamment si les attributs
des champs communs sont de tailles importantes.
Inconvénients :
- Peut conduire à une très grosse table.
- Peut causer des problèmes d'accès concurrents sur la table tronc commun.
- Structure et requêtes plus complexes.

I. Optimisation du nombre de lignes ou du nombre de colonnes
Si l'on veut limiter le nombre de colonnes, on choisira une structure du style :

Production (RéfPièce, Année, Mois, Quantité)
Si par contre on veut limiter le nombre de lignes, on choisira une structure telle
que :
Production (RéfPièce, Année, Qjanvier, Qfévrier, …, Qdécembre)
Cette solution contredit la 1ère forme normale mais divise le nombre

d’occurrence par 12.
Avantages d'un nombre de lignes limité :

- Les données apparentées sont généralement voisines
- Economie d'espace disque (les informations d'identification de chaque ligne
sont moins nombreuses).
- Tables plus petites, donc tri, indexation et restructuration plus rapides.
Avantages du nombre de colonnes limité :

- Facilite la consultation.
- Améliore les performances de certaines requêtes en réduisant le nombre des
OR.
- Standardise les traitements : une quantité est traitée de façon identique
quelque soit le mois.

II. L'optimisation du modèle physique
Ce chapitre a pour objectif de présenter les différentes possibilités

d’organisation physique des données afin de les utiliser au mieux. Bien entendu,
cette démarche se situe après l’optimisation du MLD. Ici, encore, il est
indispensable de noter la justification de chaque choix et d’en vérifier
régulièrement la pertinence.
A. Répartition des données dans une ou plusieurs bases
La solution idéale serait de stocker toutes les informations de l'entreprise dans

une seule base. En effet, il n'est pas nécessaire de créer des bases de données
séparées selon le sujet traité, le nombre d'utilisateurs ou la structure des objets
manipulés. Mais dans certains cas cette solution est impossible car :
- l'entreprise est répartie géographiquement sur plusieurs sites.
- la base de données deviendrait trop volumineuse pour être sauvegardée
dans des délais raisonnables.
- la base de données deviendrait trop volumineuse pour être sauvegardée
sur le support de sauvegarde existant.
- des problèmes stratégiques sur la propriété des données pourraient
apparaître.
Exemple : Base de données Emploi du Temps de l’ESAT :

SAUPHIE (Mise à jour) et LUCETE (Consultation) = 1 base par semaine.

B. Les différents types de données
Le choix des types de données peut influer sensiblement sur les performances,
mais aussi sur l'espace disque utilisé.
1. Les types de données caractères

On trouve 3 types de données caractères : char, varchar et long varchar.
Le type char permet de stocker des chaînes de caractères de longueur fixe en

les complétant si nécessaire par des blancs. La longueur peut varier de 1 à 2000
caractères. Le type char peut recevoir tous les caractères ASCII, y compris le
caractère nul (/0). Ce type est conseillé pour les attributs de faible taille.
Le type varchar permet de stocker des chaînes de caractères de longueur

variable. La longueur maxi étant de 1998 caractères. Les deux premiers octets
servant à conserver la longueur effective de la chaîne.
Ce type est obligatoire si l'on veut utiliser des blancs significatifs en fin de
chaîne (extrêmement rare).
Le type long varchar est similaire au type varchar mais sa longueur maxi
passe à 2 giga-octets. Ce qui impose quelques contraintes :
Les colonnes de ce type ne peuvent pas faire partie d'une clé ou d'un index
secondaire.
Elles ne peuvent pas être utilisées dans une clause ORDER BY.
Elles ne peuvent pas être prises en compte dans les statistiques d'optimisation.
Elles ne peuvent être comparées à d'autres chaînes de caractères qu'après
conversion.
On ne peut pas utiliser les fonctions de manipulation de chaînes de caractères :
LOCATE, PAD, SHIFT, SQUEEZE, TRIM, NOTRIM et CHAREXTRACT.

2. Les types de données numériques

On trouve ici 6 types de données séparées en 2 catégories :
- Les types numériques exacts : Integer, Smallint, Integer1 et Decimal.

Les 3 premiers permettent de stocker des valeurs entières respectivement sur 4,
2 ou 1 octet.
Le type Decimal permet de représenter des valeurs définies par un nombre de
chiffres pour la partie entière et d'un autre nombre de chiffres pour la partie
décimale.
- Les types numériques approximatifs : Float et Float4

Ces 2 types sont utilisés pour stocker des valeurs numériques décimales selon
une représentation flottante (mantisse et exposant) en utilisant respectivement 8
ou 4 octets.
Ces types sont, si possible, à éviter.
3. Le type date
Utilisé pour stocker des données représentant la date, l'heure ou la combinaison
des deux. Ces données sont conservées sur 12 octets quelque soit l’utilisation
qui en est faite.
L’emploi de ce type de données n'est intéressant que si l’on utilise cette date
dans des calculs, sinon il vaut mieux opter pour un type caractères pour le
stockage ou même un type integer (date système).
4. Le type money
Ce type est utilisé pour les valeurs monétaires. Le symbole monétaire, le
séparateur de décimales et le nombre de décimales sont des paramètres
modifiables (variables système).
Il utilise 8 octets et n'est donc pas plus économique qu'un integer ou qu'un float
mais son utilisation évite les conversions.

5. Le type logical key

Certaines tables (toutes en théorie) ont besoin d’une clé unique, mais il arrive
qu’aucun attribut ne puisse jouer ce rôle. On peut alors utiliser un attribut
incrémenté automatiquement à chaque création d’occurrence.
Ingres propose pour cela 2 types de clés logiques :
- object key : identifie de manière unique une ligne dans la base (16 octets).
- table key : identifie de manière unique une ligne dans la table (8 octets).
Ces clés logiques peuvent être gérées de deux façons différentes :

system_maintained : l'unicité des valeurs attribuées est assurée par le système.
not_system_maintained : l'unicité est gérée par l'applicatif.
Avantages :
- clés artificielles générées automatiquement
- unicité gérée automatiquement
Inconvénients :
- pas d'affichage possible de la valeur d'une clé logique
- si l'on utilise les commandes unloaddb ou copydb, les colonnes
system_maintained sont recalculées au rechargement des données. Ce qui
peut poser un grave problème si cette clé logique est utilisée comme clé
étrangère dans une autre table.

C. La valeur NULL
La valeur NULL peut représenter 2 types d'informations :

- soit une valeur provisoirement manquante ou inconnue
- soit un cas non applicable (ex : les employés non commerciaux ne
touchent pas de commission)
Attention : sous SQL, à la création d'une table, toutes les colonnes acceptent
par défaut les valeurs NULL à l’exception des attributs composant la clé
primaire.
Avantage de l'utilisation des NULL :

- les NULL sont ignorés dans les agrégats
Inconvénients :
- les NULL doivent être traités explicitement dans les clauses de restriction
des requêtes SQL, ce qui complique le code.
- impossibilité de faire des jointures sur des valeurs NULL car
NULL != NULL
- dans les tris, les valeurs NULL sont considérées comme supérieures aux
autres.
Il est conseillé de réserver l'utilisation des valeurs NULL aux données

numériques. Pour les chaînes de caractères il sera souvent plus simple
d'utiliser une chaîne vide.
D. Utilisation des schémas étendus

Les schémas étendus vont permettre de matérialiser sous forme graphique un
certain nombre d'informations concernant les accès aux données, les
traitements les plus fréquemment appliqués à ces données, la quantité
prévisible de données. Cette opération sera, plus tard, d'un grand secours pour
la construction du Modèle Physique des Données.

1. Elaboration d'un bilan CLMS

L'opération consiste ici à recenser, pour les opérations courantes sur la base,
toutes les lectures et écritures générées sur les tables.
Exemple : produits(nprod, nomprod, qtestock, prix)
clients(nclient, nomcli, prénomcli, ruecli, villecli)
factures(nfac, nclient*, date)
details(nfac, nprod, qté)
L'élaboration d'une facture va donc entraîner :

- N lectures de la table produits (selon le nombre de produits achetés)
- Une lecture de la table clients
- N modifications de la table produits (mise à jour de qtestock)
- Une écriture dans la table factures
- N écritures dans la table détails (selon le nombre de produits achetés)
N peut être estimé à un nombre moyen de produits achetés par un client. Reste
à estimer le nombre moyen de clients par jour.
Dans notre exemple nous allons prendre comme

- nombre moyen de produits achetés par facture : 3
- nombre moyen de factures par jour : 50
Ce qui nous donne pour un traitement le tableau suivant :
Bilan CLMS : élaboration d’une facture

Nombre Opération Table concernée
d’opérations CLMS
1 lecture clients 50 L clients
N lectures produits 150 L produits
1 création factures 50 C factures
N créations détails 150 C détails
N modifs produits 150 M produits
CLMS : Création, Lecture, Modification, Suppression

Tous les traitements peuvent ensuite être regroupés dans un tableau de

synthèse
Facturation Gestion Produits Traitement n Total

Fréquence 50/jour 10/jour
Qté moyenne 3/client 10/opération
Table produits C = 0 C = 50 C = 50
L = 150 L=0 L = 150
M = 150 M=0 M = 150
S=0 S = 50 S = 50
Table clients C=0 C=0 C=0
L = 50 L=0 L = 50
M=0 M=0 M=0
S=0 S=0 S=0
Table factures C = 50 C=0 C = 50
L=0 L=0 L=0
M=0 M=0 M=0
S=0 S=0 S=0
Table détails C = 150 C=0 C = 150
L=0 L=0 L=0
M=0 M=0 M=0
S=0 S=0 S=0
Ce tableau va donc nous permettre de dégager plusieurs constatations :

Si l'on regarde la table produits on s'aperçoit tout d'abord que c'est une table
qui sera très souvent accédée en lecture et en modification. D'autre part, si l'on
compare le nombre de créations et le nombre de suppressions on peut en
déduire que la taille de la table devrait rester stable.
Au contraire si l'on observe maintenant les résultats pour les tables factures et
détails, on voit immédiatement que ces deux tables vont avoir un
accroissement très important.
Ces constatations vont permettre notamment de choisir les structures de
stockages à adopter pour chacune des tables (cf § II-F-5).

2. Interprétation et utilisation des résultats
2.1. La taille prévisible des tables

Pour la construction du MPD, il est également intéressant de connaître la
taille approximative des futures tables (longueur d'un enregistrement *
nombre d'enregistrements). Cette opération peut être aisée dans certains cas
(ex : table des départements français) mais peut s'avérer beaucoup plus
compliquée dans d'autres cas.
2.2. La volatilité des données

Il est aussi important de connaître pour une table donnée quelle sera la
fréquence et l'importance des mises à jour dont elle fera l'objet. Une table peut
ainsi être :
- statique aucune modification n'y sera apportée
- stable peu de modifications, d'ajouts ou de suppressions
- en croissance nombreux ajouts
- volatile nombreux ajouts, modifications ou suppressions
L'utilisation d'un bilan CLMS apporte donc un certains nombre d'informations

qui vont influer notamment sur le choix de la structure de stockage à adopter
pour chacune des tables.

E. Les structures de stockage
Ingres sait gérer 4 types de structures :
1. La structure Heap
Dans cette structure les données sont stockées séquentiellement, les unes
derrière les autres. Les opérations d'insertions sont donc extrèmement rapides.
Il n’y a qu’une page principale ; toutes les autres sont des pages de
débordement.
Cette structure est recommandée pour :
Les tables de petite taille.
Les tables consultées sans opération de tri.
Le chargement de données dans une table vide.
Attention, la récupération des espaces libres générés par des suppressions n'est
pas gérée dans cette structure.

Représentation d’une table HEAP

2. La structure Hash
Avec cette structure, l’emplacement (la page) de chaque occurrence de la
table est calculé par un algorithme bâti sur la valeur de la clé. Il appartient au
constructeur d’élaborer un algorithme gérant l’unicité de l’emplacement
(algorithme de hachage). C'est la structure qui offre les meilleurs résultats
pour les opérations de recherche sur la valeur exacte de la clé. Il n’y a pas de
lecture d’autres enregistrements, ni d'index pour accéder à l'enregistrement
recherché.
Par contre, lorsque la recherche utilise des requêtes de type :
caractères jokers
intervalle de valeurs (BETWEEN)
une partie de la clé seulement (dans le cas d'une clé composée)
Ingres ne dispose pas des éléments de calcul de l’emplacement. Il est alors
obligé de parcourir entièrement la table comme il le ferait avec une structure
heap. La structure hash est donc déconseillée dans le cas de consultations
fréquentes et variées.
La structure hash gère l'espace libéré par des suppressions de données.

Représentation d’une table HASH

3. La structure ISAM
La structure ISAM utilise également une clé. Elle utilise des pages d'index qui
contiennent un intervalle de clés et des adresses qui pointent, soit sur d'autres
pages d'index, soit sur des pages de données correspondant aux valeurs de
l'index.
La méthode ISAM ne lit pas toute la table si l'on utilise la clé ou au moins sa
partie gauche comme critère de recherche. Autrement, il y a lecture complète
comme avec la méthode Heap.
Cependant, ISAM offre de bonnes performances lors de recherches utilisant :
- des caractères jokers
- des intervalles de valeurs portant sur la clé
- la partie gauche de la clé
Cette structure n'est pas conseillée pour :

- les tables qui s'accroissent rapidement
- les tables de grande taille qui subissent des modifications
- les requêtes qui portent toujours sur des clés exactes.
ISAM gère la récupération de l'espace libéré dans les pages de données.

Représentation d’une table ISAM
Le nombre de pages d’index et de pages de données est limité lors de la

création. Le débordement s’effectue essentiellement sur la dernière page, en
particulier pour les index de type compteur.

4. La structure Btree
C'est la structure la plus répandue parmi les SGBD. Elle offre un accès par clé
et permet les recherches par intervalle de valeurs et par caractères jokers. Les
index de la méthode Btree sont dynamiques et évoluent en volume avec la
table correspondante.
La structure Btree est la plus souple des structures de stockage. Elle convient
particulièrement pour :
- une table dont le volume s'accroît rapidement
- l'utilisation des caractères jokers dans les recherches
- l'utilisation d'intervalles de valeurs pour les recherches
Par contre, la structure Btree est à éviter dans le cas de tables relativement
statiques et de petite taille.
Récupération de l'espace libéré dans les pages de données mais pas dans les
pages d'index.

Représentation d’une table BTREE

Table Btree après l’ajout d’un 17ème enregistrement :

5. Le débordement de pages
Les pages de débordement sont créées lorsque des données sont ajoutées à
une table et que les pages principales sont pleines. On peut ainsi avoir
plusieurs dizaines de pages de débordement associées à une seule page
principale. L’algorithme de recherche est donc obligé de parcourir toutes ces
pages de débordement, même s’il existe un index primaire ou un index
secondaire, pour répondre à une requête. On perd ainsi les avantages liés à la
structure.
La réorganisation régulière d’une telle table est donc fortement conseillée si
l’on veut conserver des performances acceptables.
C’est le cas notamment pour les tables ISAM et HASH qui génèrent toutes
deux énormement de pages de débordement.
Par contre, les pages de débordement en HEAP sont normales puisqu’il n’y a
qu’une page principale.
En BTREE les pages de débordement ne concernent que le niveau feuille
(LEAF) ou les cas de clés dupliquées.

6. Tableau récapitulatif
Le tableau ci-dessous affecte une note à chaque type de structure selon les
besoins de l'application.
Exigences de l'application Hea Hash Isam Btree

p
Utilisation des caractères jokers * * **** ****
Lecture Utilisation d'intervalles de valeur * * **** ****
Recherche avec égalité de clé intégrale * **** *** ***
Mises à jour concurrentielles * **** **** ***
Suppression fréquente de données * **** **** **
MAJ Modification fréquente de données * **** **** ***
Insertion de données sans *** ** ** ****
modifications
Ajout de données à clé séquentielle **** *** * ****
Chargement initial de données **** *** *** ***
Table statique non croissante **** **** ***
Évolution Table peu croissante avec mises à jour **** **** ***
Table très croissante avec mises à jour ** ** ** ****
Taille Table de petite taille (<15 pages) *** **** **** **
Table de taille moyenne * **** **** ****
Total : 23 44 47 46
* Mauvais
** Acceptable
*** Bon
**** Excellent
Ce tableau nous permet de constater que dans la majeure partie des cas, les
structures ISAM et Btree sont les mieux adaptées.

Schéma décisionnel
C h o iixx dd ee l a
s tt r uu c ttuu r ee
d ee ss ttoo cc kk aa gg ee
O N
In c e rtitu d e ?
T rè s p e tit
M oyen O
ou
tr è s g ro s ?
O C le f N P e tit
s é q u e n tie lle ? G ro s?
N D i s p o n i b l eO
O R e c h erc h e su r 2 4 h /2 4 ? ? HEAP
p la g e d e v a le u rs ? p lu s in d e x
s e c o n d a ir e
N L es données
d o iv e n t re s te r
N g ro u p é es? O HEAP
H A SH
N S ta tiq u e ?
BTREE IS A M

F. Utilisation des clés
1. La duplication ou l'unicité des clés

3 cas peuvent se présenter :
- Forte duplication ou faible unicité :
Plusieurs occurrences de la même valeur dans une colonne (ex : une table
contenant 6 millions de lignes avec une colonne n'ayant que 5 valeurs
différentes)
Cette colonne ne doit absolument pas être utilisée comme clé primaire.
- Faible duplication ou forte unicité :

Presque toutes les valeurs sont différentes.
Cette colonne est donc une excellente candidate pour devenir clé primaire
ou index secondaire.
- Duplications irrégulières :
Un mélange de faibles et de fortes duplications.
La colonne est alors une mauvaise candidate pour devenir une clé
primaire, mais peut éventuellement être utilisée comme index secondaire.
2. La longueur des clés

Plus une clé est courte et plus les performances seront bonnes.
En Hash, plus la clé est longue, plus la fonction de hachage sera lente.
En Isam et Btree, plus la clé est longue, plus on augmente la profondeur des
index et donc le nombre des entrées/sorties. En effet plus la clé est longue et
moins la page peut en contenir. Il faudra donc fréquemment rajouter des
niveaux d’index.
On recommande en général : LongueurClé <= 10% longueurLigne
Si aucune colonne ne peut remplir cette condition, on pourra faire appel à une
clé de substitution (cf §II-F-4).

3. Utilisation des clés composites

Le premier inconvénient des clés composites est que l'optimisation des
requêtes est basée sur des statistiques construites au niveau de chacune des
colonnes individuellement.
D'autre part en cas de recherche sur une partie seule de la clé, en hash on
utilisera alors une méthode séquentielle. En mode Btree ou Isam, la clé ne
sera utilisée que jusqu'à la première inégalité rencontrée.
Ex : COL1, COL2,COL3 sont les trois colonnes qui composent la clé.
Requête :
…WHERE col1 = 1 and col2 >2 and col3 = 3
La recherche s'effectuera séquentiellement à partir de :
col1 = 1
Il aurait été judicieux ici de dire :
…WHERE col1 = 1 and col3 = 3 and col2 >2
On pourra ici aussi, dans certains cas, faire appel à une clé de substitution.
4. Les clés de substitution

C'est une clé artificielle, introduite pour remplacer une clé dont l'utilisation
serait trop lourde. On trouve 4 types de clés de substitution :
- La clé de substitution séquentielle :

Elle peut être gérée automatiquement par Ingres, mais elle peut générer des
'trous' car même en cas de ‘rollback’ le numéro attribué par Ingres est
considéré comme utilisé.
Si elle n'est pas gérée automatiquement, cela engendre des transactions multi-
requêtes et peut provoquer un goulot d'étranglement sur la table.
Ex : Pour calculer la nouvelle clé, on a besoin de lire la table pour récupérer la
valeur maxi de la clé, d’incrémenter cette valeur et enfin d’écrire le nouvel
enregistrement.
En BTREE et surtout en ISAM, il existe un risque de goulot d'étranglement sur
la dernière page de données, puisque les clés se suivent.

- La clé de substitution chronologique :

Basée sur la date et l'heure système, son unité est la seconde. Il est conseillé de
ne pas utiliser le type date pour stocker cette clé, mais plutôt un type caractère
ou entier. C'est une clé facile à gérer, mais il faudra s'assurer que des tables
dépendantes utilisent bien le même référentiel de temps.
- La clé de substitution aléatoire :

Il est possible d'utiliser un générateur de nombres aléatoires. Ce système
nécessite de vérifier l'unicité de la clé à l'insertion.C'est une solution bien
adaptée à une structure HASH.
- La clé de substitution codée :

Cette clé va contenir des sous-ensembles d'information significatifs (Ex : n°
d’INSEE). Cet attribut sera donc non atomique. C'est une clé facile à gérer
mais qui nécessite également une vérification de l'unicité.
Avantages des clés de substitution :

Taille réduite donc amélioration des performances.
Profondeur d'index moins importante pour les types Isam et Btree, donc
moins d'opérations d'entrées/sorties.
Moins de place perdue par les clés dans les tables dépendantes et les
associations.
Puisque la clé est ici mono-colonne, les statistiques de l'optimiseur sont plus
efficaces.
Comme le contenu de la clé est sans signification, jamais de modifications sur
la clé.
Inconvénients des clés de substitution :

Complexité des traitements si l'on a besoin de décoder la clé.
Tendance à l'augmentation du nombre de clés secondaires.
Nécessité d'un mécanisme de génération de clé.
La clé ne constitue pas un critère significatif. Les données dépendent d’une
valeur qui n’a aucune signification fonctionnelle pour l’utilisateur.
Besoin fréquent d'utilisation des règles lors de la création de lignes.

G. Utilisation des index secondaires
Créer un index secondaire sur un ou plusieurs attributs d’une table correspond

à la création d’une 2ème structure de stockage pour cette table, ne contenant
que les valeurs possibles de l’attribut indexé.
Exemple :
Individu (NumInd, Nom, Prenom, …)
En créant un index sur l’attribut Nom on obtient :
L’existence de ce fichier d’index permettra d’accéder directement à un

enregistrement de la table en connaissant la valeur d’un nom.
Cette solution accroît les performances en lecture mais ralentit les opérations
d'écriture.
On peut créer un nombre quelconque d'index secondaires par table. Un index
pourra contenir jusqu'à 32 attributs. Mais plus ce nombre sera petit meilleures
seront les performances. Un index peut utiliser n'importe quelle structure de
stockage sauf la structure heap. Les index sont indépendants logiquement et
physiquement des données. Ils contiennent les valeurs des colonnes indexées
et les adresses des enregistrements correspondant à ces colonnes.

1. Création d’un index

Syntaxe :
CREATE [UNIQUE] INDEX nom_index
ON nom_table (nom_colonne {, nom_colonne})
[WITH with_clause {, with_clause}]
with_clause permet de définir les paramètres de stockage de l’index :

- STRUCTURE = HASH | ISAM | BTREE :
structure de stockage de l’index. Par défaut : ISAM.
- KEY = (nom_colonne {, nom_colonne}) :
spécifie les colonnes de la table qui serviront de clé d’accès. Doit être un
sous-ensemble de la clause ON présenté dans le même ordre. Par défaut la
clé d’accès de la table d’index est constituée des colonnes de la clause ON.
- FILLFACTOR = n :
facteur de remplissage des pages de données (entre 1 et 100). C’est le
pourcentage de remplissage des pages au moment de la création. Il existe
une valeur par défaut pour chaque type de structure de stockage.
- MINPAGES = n :
nombre mini de pages à la création d’un index de structure HASH. Par
défaut : 16.
- MAXPAGES = n :
nombre maxi de pages à la création d’un index de structure HASH. Par
défaut : infini.
- LEAFFILL = n :
facteur de remplissage des pages ‘leaf’ en % pour les index de structure
BTREE.
- LOCATION = (nom_localisation {, nom_localisation}) :
localisation de l’index.
- ALLOCATION = n :
spécifie le nombre de pages attribuées initialement à l’index.
- EXTEND = n :
spécifie le nombre de pages attribuées à chaque accroissement de l’index.
- COMPRESSION [=([[NO]KEY] [,[NO]DATA])] | NOCOMPRESSION :
détermine si l’index est compressé ou non.

- UNIQUE_SCOPE = STATEMENT | ROW :

indique pour un index unique si l’unicité est vérifiée ligne par ligne ou
globalement après une insertion ou une modification. Par défaut : Row.
- PERSISTENCE | NO PERSISTENCE :
précise le comportement de l'index lors d'une commande MODIFY sur la
table d'origine. Si PERSISTENCE les index sont conservés.
2. Modification d’un index

La modification de la structure d’un index se fait de la même façon que pour
une table avec la commande MODIFY.
La commande SQL modify permet de modifier la structure, la localisation ou
la clé d'une table ou d'un index. Attention, avant d'utiliser cette commande, il
faudra s'assurer d'avoir assez d'espace disponible sur le disque. En effet, la
structure source ne sera détruite qu'après construction complète de la structure
cible et selon de cette structure cible, l'espace nécessaire sera de 1 à 2 fois la
taille de la structure source. D'autre part, cette opération devra se faire dans
une période 'creuse' car durant toute l'opération, un verrou exclusif sera posé
sur la table source.
Syntaxe de la commande modify :

MODIFY table | index TO
struct_stock | verbe [UNIQUE]
[ON nomcolonne [ASC|DESC]{, …}]
[WITH [FILLFACTOR = n] [, MINPAGES = n] [, MAXPAGES = n]
[, LEAFFILL = n] [, NONLEAFFILL = n]
[, NEWLOCATION = (localisation {, localisation})]
[, OLDLOCATION = (localisation {, localisation})]
[, LOCATION = (localisation {, localisation})]
[, COMPRESSION [= ([[NO|YES] [, [NO]DATA])] | NOCOMPRESSION]
[, ALLOCATION = n] [, EXTEND = n]
[, [NO]PERSISTENCE]
[, UNIQUE_SCOPE = ROW | STATEMENT]

struct_stock : Heap, Hash, Isam ou Btree

verbe : Merge, truncated, relocate, reorganize
Merge permet de reconstruire la structure des index d'une structure Btree
avec récupération de l’espace libre dans les pages feuilles (leaf).
Truncated détruit toutes les lignes de la table. L'espace résultant est récupéré
et la structure de stockage est automatiquement convertie en Heap.
Relocate permet de déplacer une table ou une partie de table depuis les
localisations spécifiées par OLDLOCATION vers les localisations spécifiées
par NEWLOCATION.
Reorganize répartit le contenu de la table dans les localisations spécifiées.
UNIQUE permet de spécifier l'unicité de la clé pour les structures Hash, Isam
et Btree.
FILLFACTOR indique un pourcentage de remplissage des pages (nombre de
lignes à stocker dans une page divisé par le nombre de lignes que peut
contenir la page). L'espace libre est utilisé pour les mises à jour. Il est donc
recommandé d'utiliser un FILLFACTOR important pour les tables statiques et
de petite taille. En revanche, des tables importantes devront avoir un
FILLFACTOR faible pour réduire les contentions de verrouillage et
augmenter les accès concurrents.
Les valeurs par défaut sont les suivantes :
HEAP CHEAP HASH CHASH ISAM CISAM BTREE CBTREE

100 % 100 % 50 % 75 % 80 % 100 % 80 % 100 %
CHEAP, CHASH, CISAM et CBTREE sont des structures compressées.
LEAFFILL n'est utilisé que pour les structures Btree et permet d'indiquer un
coefficient de remplissage des pages feuilles. Par défaut : 70 %
NONLEAFFILL n'est utilisé que pour les structures Btree et permet
d'indiquer un coefficient de remplissage des pages d'index. Par défaut : 80 %.
MINPAGES et MAXPAGES ne sont utilisés que pour les structures Hash.
Permettent de spécifier un nombre mini et un nombre maxi de pages
principales. Au-delà de ce nombre le système crée des pages de débordement.

COMPRESSION indique que les données et/ou les index seront compressés.
En Isam et en Hash, les index ne sont pas compressibles. Ce sont les valeurs
NULL et les caractères non significatifs des chaînes de caractères qui sont
compressés. Ceci a pour avantage d'économiser de l'espace disque et des
opérations d'entrées/sorties. Mais, en contrepartie, cela augmente d'environ 30
% le temps CPU.
ALLOCATION permet d'allouer à nouveau de l'espace de la structure cible
aux pages ou aux index. Le nombre d'allocations est exprimé en pages Ingres
(4 Ko) et doit être compris entre 4 et 8 388 607. Le système arrondit la valeur
spécifiée à un multiple de 16. La commande échoue s'il n'y a pas
suffisamment d'espace disque.
EXTEND permet de spécifier l'espace à allouer pour une extension de la
table. La taille indiquée doit être comprise entre 1 et taille_max, taille_max
étant le nombre maxi de pages que peut contenir une table Ingres (8 388 607)
moins la taille spécifiée dans ALLOCATION
PERSISTENCE permet de programmer la recréation automatique de l'index
lorsque la structure de la table est modifiée. Par défaut NOPERSISTENCE est
employé.
UNIQUE_SCOPE détermine le moment où le contrôle d'unicité sera effectué
pendant le modify. Si = ROW, pour chaque ligne. Si STATEMENT en fin de
modification globale.
Attention lors de la restructuration d'une table, les index secondaires, s'ils

existaient, sont supprimés et donc à recréer.
3. Suppression d’un index

La suppression d’un index se fait avec la commande DROP nom_index. Les
index associés à une table sont également supprimés si la table est modifiée
ou supprimée.

H. L’utilisation des vues
Une vue est une représentation logique des données d’une ou de plusieurs
tables ou d’autres vues. Même si à l’utilisation elle est perçue comme une
table, elle diffère de celle-ci au niveau du stockage des données : seule la
définition de la vue est stockée dans le dictionnaire de données.
Les vues permettent de :

- sécuriser les données d’une table (en ligne et en colonne)
- cacher une certaine complexité due à la structure relationnelle des
tables (jointures)
- simplifier la formulation de requêtes
- présenter les données d’une table d’une façon différente sans avoir à
modifier la structure de la table
- sauvegarder de façon indirecte des requêtes complexes et répétitives.
Inconvénients :
- gestion des permissions sur les tables concernées plus complexe
- aucun gain en matière de performances pures.

I. La commande sysmod
Cette commande va remplacer la commande modify pour les catalogues
systèmes et les tables de IIDBDB
Syntaxe de sysmod :
sysmod [-s] [+|-w] dbname [iirelation][iiindex] […]
L'option -s indique que l'on exécute la commande sur IIDBDB. (Seul

l’administrateur Ingres peut le faire).
L'option +w indique que l'on attend que tous les utilisateurs soient
déconnectés de la base pour exécuter la commande. En effet, durant le
déroulement de sysmod, la base est totalement verrouillée.
Cette commande va reconstruire les catalogues systèmes en fonction des
structures de stockage prédéfinies. Elle doit être exécutée périodiquement
pour maintenir des performances acceptables.
La restructuration d'une base de donnée ne peut être effectuée que par
l'administrateur de la base ou par un super utilisateur Ingres.
Il est possible de préciser le nom des tables à restructurer.

III. L'optimiseur de requêtes
En partant d'un exemple simple, nous allons voir que très souvent, dans la
construction des requêtes, plusieurs stratégies sont possibles. Seule, une
connaissance approfondie de la base permettra de déterminer quelle est la
meilleure solution. C'est le rôle de l'optimiseur de requêtes.
A. Présentation de l'optimiseur
Exemple : Afficher les noms, services et adresses professionnelles de tous les

employés qui travaillent en Bretagne et gagnent 20 000 F :
SELECT nom, service, adr_pro FROM emp,batiment,service
WHERE emp.service = service.service_nom
AND service.batiment = batiment.batiment
AND batiment.region = 'Bretagne'
AND emp.salaire = 20000;

Deux stratégies possibles :

- chercher les employés avec un salaire de 20 000 F, faire la jointure
avec la table service, puis faire la jointure avec la table batiment, puis
faire la restriction sur la région Bretagne.
- chercher les batiments de Bretagne, faire la jointure avec la table
service, puis faire la jointure avec la table emp.
Pour choisir, il faut connaître :

- le nombre de batiments en Bretagne
- le nombre d'employés qui gagnent 20 000 F
- le nombre de services dans chaque batiment
- le nombre d’employés par service.
Le choix s'orientera vers la solution qui éliminera le plus d'occurrences dès la

première opération, afin de restreindre au maximum le champ des recherches.
L'optimiseur de requêtes va donc construire le meilleur plan d'exécution (QEP)

pour une requête donnée en utilisant des informations élémentaires telles que la
taille des tables et leur nombre d'occurrences.
L'optimiseur arrête la recherche du QEP dès que le temps écoulé est supérieur au
temps d'exécution estimé.

B. Utilisation des statistiques
1. Définition
Pour fonctionner, l'optimiseur à besoin de statistiques sur les tables. Ces
statistiques peuvent être collectées, à la demande, par la commande
optimizedb. La commande statdump permet de visualiser ces statistiques.
2. La commande optimizedb
Syntaxe de la commande optimizedb :
optimizedb [-zffilename] [-zv] [-zh] [-zx] [-zk] [-zs#] [-zc] [-zu#] [-zr#]
[-ifilename] dbname {-rtablename {-acolumn}}
-zf : nom du fichier qui contient tous les paramètres de la commande. (C’est
une solution pratique si vous lancez souvent la commande avec les mêmes
paramètres).
-zv : affichage d'informations sur l'exécution de la commande
-zh : affichage des pourcentages
-zx : statistiques réduites : valeur mini et valeur maxi de la colonne
-zk : statistiques sur toutes les colonnes clés ou les index
-zs# : statistiques sur un échantillon de données (# %)
-zc : statistiques pour les catalogues systèmes
-zu# : nombre de cellules pour des histogrammes sur valeur exacte
-zr# : nombre de cellules pour des histogrammes sur intervalles
-ifilename : lit les statistiques depuis le fichier donné plutôt que depuis la table
-rtablename : spécifie le nom d'une table
-acolumn : spécifie le nom d'une colonne dans la table
On exécute optimizedb lorsque :

- la distribution des valeurs de données change
- l'on vient d'ajouter de nouvelles tables
- l'on vient d'ajouter des colonnes à une table
- l'on vient de créer de nouveaux index

optimizedb peut collecter des statistiques sur :

- les valeurs mini et maxi d'une colonne
- le nombre de valeurs distinctes (en moyenne) dans une même colonne
- les valeurs ou les intervalles de valeurs si les valeurs possibles sont trop
nombreuses
Il faut toujours utiliser la commande sysmod après une commande optimizedb

pour reconstruire les catalogues systèmes.
3. La commande statdump
La commande statdump permet de visualiser ou de détruire des statistiques.
Syntaxe :
statdump [-zq] [-zc] [-zdl] [-o filename] dbname
[{-rtablename{-acolumnname}}]
-zq : mode quiet : affiche uniquement les statistiques minimales mais pas les
histogrammes
-zc : affiche les statistiques sur les tables utilisateurs mais également les
statistiques sur les catalogues systèmes
-zdl : permet de détruire des statistiques
-ofilename : redirige la sortie de statdump vers le fichier ASCII spécifié
-rtablename : permet de préciser une table
-acolumnname : permet de préciser une colonne d'une table.

C. Utilisation des QEP
1. Définition
Un QEP (Query Execution Plan) ou plan d'exécution de requête représente la
stratégie adoptée par l'optimiseur pour exécuter une requête. Cette stratégie a
été choisie en fonction des statistiques obtenues par la commande optimizedb.
2. Interprétation des QEP

Il peut être interessant d'étudier les QEP pour essayer d'améliorer les
performances :
- La table est-elle balayée entièrement ? Un index pourrait-il l'éviter ?
- Le coût CPU est-il important ?
- Le nombre d'entrées/sorties est-il important ?
- Quelle partie de la requête consomme le plus de ressources ?
- La structure de stockage et les index secondaires sont-ils bien utilisés ?
- Le nombre de lignes résultat estimé est-il raisonnable ?
2.1. L'obtention des QEP

On peut obtenir les QEP de plusieurs manières :
Sous ISQL :
SET QEP puis avec l'option file, sauvegarder le QEP dans un fichier.
Depuis une application ABF ou W4GL :
SET QEP
Depuis le système d'exploitation :
setenv ING_SET "set qep"
Avec la commande :
setenv II_EMBED_SET “printtrace”
le résultat des traces est enregistré dans un fichier (par défaut :
iiprttrc.log)
SET OPTIMIZEONLY permet d'afficher le QEP sans exécuter la
requête.
2.2. La lecture d'un QEP

La lecture d’un QEP commence en bas à gauche. Chaque feuille contient des
informations sur une table. Il faut commencer par lire la branche de gauche
puis la branche de droite et enfin remonter vers le nœud racine.
Tous les nœuds (les feuilles exceptées) ont une branche gauche. Seuls les
nœuds de jointure ont une branche droite et gauche.
Les nombres D (dio : nombre d'entrées/sorties) et C (temps CPU) sont
cumulatifs en remontant vers la racine. Pour des requêtes à QEP multiples, ils
sont passés au QEP suivant.
Les requêtes à QEP multiples sont les requêtes qui utilisent :
- des sous-requêtes
- des agrégats
- des unions
- des vues.
On trouve 4 types de nœuds dans un QEP :

- Les feuilles : Elles concernent les tables ou les index secondaires utilisés dans
la requête. On y trouve le nom de la table ou de l'index, l'alias éventuel, la
structure de stockage, le nombre de lignes et de pages.
- Les nœuds de projection/restriction : Ces nœuds ne conservent que les
lignes et les colonnes indispensables pour minimiser le volume de données
traitées ultérieurement dans la requête
- Les nœuds de tri : Lors de l’utilisation de distinct, order by, unions, sous-
requêtes.
- Les nœuds de jointures :
FSM join (Full Sort Merge) : jointure sur une colonne préalablement triée
dans les deux tables.
PSM join (Partial Sort Merge) : jointure sur une colonne préalablement triée
dans au moins une des deux tables.
K-join : jointure avec accès sur clef primaire.
T-join : jointure avec accès par index secondaire.
Card-Prod : exécution d’un produit cartésien.
SE join : requêtes imbriquées non lissées.

Exemples de QEP :
Exemple n° 1 :
1> select * from vin

********************************************************************
QUERY PLAN 1,1, no timeout, of main query
Proj-rest
Sorted(ref_vin)
Pages 4 Tups 134
D6 C1
vin
B-Tree(NU)
Pages 11 Tups 134
********************************************************************
On part donc de la table vin qui est de type Btree.

(NU) = Not Use : indique que Ingres n’utilise pas la structure Btree dans
l’exécution de la requête. La table vin est donc lue séquentiellement.
La table contient 11 pages et 134 tuples.
La deuxième partie du QEP (partie supérieure) montre que Ingres fait une
projection/restriction sur la table vin. Puis il constate que les données sont
triées (Sorted) sur la clé ref_vin et stocke le résultat dans une table temporaire
(toujours de type HEAP ce qui explique la diminution du nombre de pages
pour le même nombre de tuples).
L’opération a demandé 6 entrées/sorties disque et 1 milliseconde de temps
processeur.

Exemple n° 2 : equi-jointure (sans statistiques)
1> select * from vin,cru

where vin.ref_cru = cru.ref_cru
and cru = 'BORDEAUX'
********************************************************************
FSM Join(ref_cru)
Heap
Pages 1 Tups 13
D9 C17
/ \
Proj-rest Proj-rest
Sorted(ref_cru) Sort on(ref_cru)
Pages 1 Tups 1 Pages 4 Tups 134
D3 C1 D6 C1
/ /
cru vin
B-Tree(NU) B-Tree(NU)
********************************************************************
A noter ici l’estimation faite par l’optimiseur :

13 tuples en résultat, ce qui équivaut à 10% des 134 tuples de départ. Ce
pourcentage est utilisé par défaut en l’absence de statistiques.
Au second niveau de ce QEP, pour la table cru, nous avons Tups = 1 ce qui
veut dire que Ingres n’a conservé que l’enregistrement où cru =
‘BORDEAUX’.
On voit aussi que Ingres trie la table vin (Sort on) sur l’attribut ref_cru.

Exemple n° 3 : equi-jointure (avec statistiques)
1> select * from vin,cru

where vin.ref_cru = cru.ref_cru
and cru = 'BORDEAUX'
********************************************************************
FSM Join(ref_cru)
Heap
Pages 1 Tups 2
D9 C17
/ \
Proj-rest Proj-rest
Sorted(ref_cru) Sort on(ref_cru)
D3 C1 D6 C1
/ /
cru vin
B-Tree(NU) B-Tree(NU)
********************************************************************
La seule différence avec l’exemple précédent, est l’estimation faite par Ingres :
2 tuples en résultat.

D. Les mesures de performances
1. Les différentes mesures

Il est possible d’obtenir des informations sur une session avec la commande
select dbmsinfo (‘paramètre’)
Les paramètres possibles sont :
_cpu_ms : consommation cpu en millisecondes.
_et_sec : temps écoulé en secondes depuis le début de la session.
_dio_cnt : nombre d’entrées/sorties directes.
_bio_cnt : nombre d’entrées/sorties bufferisées.
Ces mesures doivent être pondérées notamment en raison de l’utilisation d’un

cache et de la charge du système.
D’autre part, lors des requêtes courtes, il faut tenir compte du temps pris par les
opérations de mesure. Pour les requêtes répétées (mot réservé : repeated) le
temps utilisé à la compilation et à l’optimisation de la requête n’est pris en
compte que lors de la première mesure.
Nota : Le mot repeated est utilisé en SQL pour que le QEP d’une requête ne
soit calculé qu’à la première exécution de la requête. Le QEP est ensuite
conservé en mémoire pour la durée de la session et réutilisé lorsque l’on répète
la requête.
Exemple : REPEATED UPDATE emp SET salaire = salaire*0.05
Pour obtenir une précision maximum, il est recommandé d’exécuter plusieurs

fois la même requête, puis de faire une moyenne des différentes mesures.

2. Le coût des mesures de performances

Lorsque l’on interroge le temps CPU, cela augmente la consommation
d’environ 10%. Ce surcoût est apporté à toutes les sessions en cours tant
qu’une session au moins effectue la mesure. Seule une déconnection de la base
interrompt la mesure.
Le faît d’interroger le nombre d’entrées/sorties (_dio_cnt) n’entraîne pas de

surcoût. Par contre, des résultats précis sont difficiles à obtenir avec
l’utilisation des tâches d’écriture asynchrone. (Procédé qui permet d’écrire les
données dans la base non pas lorsque l’utilisateur le demande mais lorsque le
système est libre pour le faire. Ceci offre une grande amélioration des temps de
réponse.)

IV. Analyse de requêtes complexes
A. Recommandations
Dans les requêtes SQL, il est recommandé d’utiliser les équi-jointures

(jointure basée sur une égalité) aussi souvent que possible. En effet une équi-
jointure est plus performante qu’une inéqui-jointure (jointure basée sur une
inégalité) ou qu'une sous-interrogation.
En rêgle générale d’ailleurs, il vaut mieux éviter != lorsque = est possible.
Les colonnes qui contiennent des valeurs nulles diminuent les performances.
Il est donc conseillé de les éviter.
Il faut veiller, dans la mesure du possible, lors de la construction de la table, à
ce que la colonne de gauche des clés multi-colonnes soit la plus restrictive.
Dans certains cas, un UNION sera plus performant qu’un OR.
Exemple :
SELECT * FROM table WHERE col1 = x or col2 = y
pourra être remplacé par :

SELECT * FROM table WHERE col1 = x
UNION
SELECT * FROM table WHERE col2 = y
B. Le lissage des requêtes

Le lissage des requêtes, appelé également Querry Flattening, est une
opération exécutée par l’optimiseur. Elle permet l’étude de la requête afin
d’en améliorer les performances. Ainsi, toutes les sous-requêtes seront
transformées en jointures par l’optimiseur.

Exemple :
Emp(eno, nom, prenom, salaire)
Dept(deptno,mgrno*,budget)
Question posée : Quels sont les employés managers d’un ou plusieurs

départements ?
SELECT * FROM emp WHERE eno IN (SELECT mgrno FROM dept);
Cette requête va être convertie par l’optimiseur :

SELECT DISTINCT emp.* FROM emp, dept WHERE emp.eno = dept.mgrno;
L’optimiseur va générer le même QEP pour ces deux requêtes

sémantiquement équivalentes mais de syntaxe différente.
Ce lissage va donc permettre d’améliorer la performance de la plupart des
requêtes.
Explication :
3 employés dans la table emp.
3 divisions dans la table dept.
Le département 1 est dirigé par l’employé 1
On voit donc ici la nécessité du DISTINCT si l’on ne veut pas de doublons.
S’il n’y avait pas de lissage on aurait eu :

Création d’une table temporaire en heap à partir de la sous-requête.
Pour chaque ligne de la requête externe, recherche une ligne
correspondante dans la requête interne. Ceci peut être très long si la table
temporaire est grande.

C. Lissage des requêtes corrélées avec agrégat.
Question posée : Quels sont les employés qui ont le plus gros salaire dans
chaque département ?
SELECT * FROM emp e
WHERE e.salaire =
(SELECT MAX (e1.salaire) FROM emp e1
WHERE e1.dno = e.dno)
Dans une telle requête, le système n’est pas en mesure d’évaluer la requête
interne puis d’en utiliser le résultat pour restreindre la requête externe. En
effet, la requête interne dépend d’une valeur de la requête externe (e.dno). A
chaque occurrence de la requête externe correspond une valeur différente de
la requête interne.
Si la requête externe est peu restrictive et que la requête interne n’est pas
indexée, cela peut demander beaucoup de temps.
Considérons le jeu d’essai suivant :
Table emp
Eno Dno salaire
1 1 9000
2 1 10000
3 2 8000
4 2 9000
5 2 10000
- Le système traite la 1ère occurrence d’emp : son dno vaut 1.

- La requête interne peut alors être évaluée. Quel est le plus grand salaire
dans le département 1 ? La réponse est 10000.
- Le système peut alors traiter la requête externe et comparer le salaire
du 1er employé à 10000 et ainsi de suite.

Le lissage effectué par le système va consister à scinder la requête en deux :

- Création d’une table T qui donne le plus grand salaire par département.
CREATE TABLE t AS
SELECT dno, MAX(salaire) FROM emp
GROUP BY dno
- Recherche des employés ayant le même salaire et le même n° de

département que ceux de la table T
SELECT emp.* FROM emp, t
WHERE emp.salaire = t.salaire
AND emp.dno = t.dno
On constate donc la création d’une table temporaire chargée de récupérer les

résultats de la première requête. Cette première requête est la plus restrictive
puisqu’elle recherche le salaire maxi de chaque département.
D. Les requêtes complexes
1. Utilisation de la clause HAVING

Si l’on a la requête suivante :
SELECT ref_cru, COUNT(ref_vin) FROM vin
GROUP BY ref_cru
HAVING ref_cru < 115;
Il vaut mieux écrire :

SELECT ref_cru, COUNT(ref_vin) FROM vin
WHERE ref_cru < 115
GROUP BY ref_cru;
En effet plus le WHERE sera restrictif, plus le GROUP BY sera rapide.

Le WHERE effectue une restriction sur les tables d'origine.
Le HAVING effectue une restriction sur un résultat.
Si l’on compare les 2 QEP, on constate que le temps CPU passe de 17 à 2 en
adoptant cette seconde solution. Cette différence est uniquement due à la
position de la restriction sur ref_cru.

1> set qep
2> select ref_cru,count(ref_vin) from vin

group by ref_cru
having ref_cru < 115
********************************************************************
QUERY PLAN 1,2, no timeout, of function aggregate

producing temporary table T1
aggregate expression ->

T1A2 =
count
(ref_vin)
by expression attribute -> T1A1

= ref_cru
Sort Keep dups

Pages 1 Tups 134
D6 C15
/
Proj-rest
Sorted(ref_vin)
Pages 1 Tups 134
D6 C1
vin
B-Tree(NU)
Pages 11 Tups 134
Proj-rest
Sorted(T1A1 ref_cru,
T1A2 ref_vin)
Pages 1 Tups 13
D7 C17
T1
Heap
Pages 1 Tups 134
********************************************************************

1> set qep
2> select ref_cru,count(ref_vin) from vin

where ref_cru < 115
group by ref_cru
********************************************************************
QUERY PLAN 1,2, no timeout, of function aggregate

producing temporary table T1
aggregate expression ->

T1A2 =
count
(ref_vin)
by expression attribute -> T1A1

= ref_cru
Sort Keep dups

Pages 1 Tups 13
D6 C2
Proj-rest
Sorted(ref_vin)
Pages 1 Tups 13
D6 C1
vin
B-Tree(NU)
Pages 11 Tups 134
Proj-rest
Sorted(T1A1 ref_cru,
T1A2 ref_vin)
Pages 1 Tups 13
D7 C2
T1
Heap
Pages 1 Tups 13
********************************************************************

2. Utilisation des agrégats fusionnés

Si l’on recherche le nombre d’employés du département 1 ainsi que ceux du
département 2 :
SELECT COUNT(*) FROM emp
WHERE dno = 1;
SELECT COUNT(*) FROM emp
WHERE dno = 2;
Ces 2 requêtes vont provoquer 2 balayages de la table. Il vaut donc mieux

écrire :
SELECT dno, COUNT(*) FROM emp
WHERE dno IN (1,2)
GROUP BY dno;
Cette requête sera d’autant plus efficace s’il n’y a que peu de valeurs
concernées par le GROUP BY.

V. Les procédures base de données
A. Définition
Une procédure base de données est un traitement qui pourra être exécuté sur
une table. Une procédure base de données est composée d’ordres SQL. Les
ordres de définition de données (ALTER, CREATE, …) ne sont pas autorisés
dans ces procédures. On y trouvera donc essentiellement des ordres de
manipulation de données (SELECT, UPDATE, INSERT, DELETE) ou des
ordres de contrôle de transaction (COMMIT, ROLLBACK).
Une procédure base de données peut être appelée directement depuis une
application ou indirectement par le déclenchement automatique d’une rêgle.
L’appel d’une procédure peut se faire depuis n’importe quel applicatif Ingres
(SQL, ISQL, ESQL, 4GL, OpenRoad, …).
L’utilisation des procédures base de données permet de réduire le code
applicatif au niveau du client. Les mêmes procédures peuvent être utilisées
par différentes applications. Les évolutions de code ne se font qu’une fois au
niveau du serveur sans diffusion à chaque client. Le trafic réseau est moins
dense.
B. Création d'une procédure base de données

Pour créer une procédure, l’utilisateur doit posséder les permissions
nécessaires pour exécuter les opérations spécifiées sur les tables ou/et les
vues. Les tables et les vues référencées doivent exister lors de la création de la
procédure.
Une procédure base de données est composée de 3 parties :
La définition de la procédure : consiste à donner le nom de la procédure et
la liste des paramètres.
La déclaration des variables : liste des variables locales utilisées par la
procédure.
Le corps de la procédure : contient les ordres SQL, les structures de contrôle
éventuelles et la gestion des erreurs.

Syntaxe :
CREATE PROCEDURE nom_procédure

[{,nom_paramètre_reçu = type_donnée [WITH | NOT DEFAULT]
[WITH | NOT NULL]}]
= | AS
[{,variable_locale = type_donnée [WITH | NOT DEFAULT]
[WITH | NOT NULL]}]
BEGIN
{, ordres SQL[;]}
END
A noter qu’il n’y a aucune différence entre l’utilisation du ‘=’ ou du ‘as’
Liste des ordres SQL utilisables dans une procédure base de données
Manipulation Contrôle des Contrôle du Communications

des données transactions flux
SELECT COMMIT IF…THEN…ELSE RAISE ERROR
INSERT ROLLBACK WHILE MESSAGE
UPDATE EXECUTE PROCEDURE
DELETE

Exemple de procédure base de données :

Cette procédure permet de vérifier la validité d’une date de naissance. Si cette
date est invalide la procédure renvoie une erreur, sinon calcule l’âge.
PROCEDURE p_com_age (DateNaissance = INTEGER NOT NULL)

=
age = INTEGER;
BEGIN
IF DATE(‘today’) < DATE(:DateNaissance) THEN
MESSAGE (‘Date de naissance invalide’);
RETURN (-1);
ELSE
age=INT4(INTERVAL(‘year’,DATE(‘today’)-DATE(:DateNaissance)));
RETURN(:age);
ENDIF
END
C. Intérêt de l'emploi d’une procédure :
DEPT (nom_dept, division, budget, batiment, etage, nb_emp)
Les règles de gestion sont :

Lors de l’ajout d’un enregistrement dans la table dept :
- batiment doit exister dans la table batiment
- budget doit être NULL ou compris entre 500 000 et 5 000 000
- les changements dans la table dept doivent être enregistrés dans la table
dept_chg.

Schéma de l’opération gérée par une application
On s’aperçoit ici que pour chacune des opérations, l’application envoie une
requête au serveur de données qui l’exécute puis redonne la main à
l’application. Les échanges client/serveur sont donc nombreux.

Schéma de l’opération gérée par une procédure base de données
On voit donc qu’en utilisant une procédure base de données, on diminue

fortement les communications entre clients et serveur. En effet, l’application
appelle la procédure par un CALL puis l’envoie au serveur de données qui
l’exécute dans son intégralité avant de rendre la main à l’application.
D’autre part, le QEP est sauvé à la création de la procédure base de données.
Il n’a donc pas à être recalculé à chaque utilisation de la procédure.
A noter également que la modification d’une procédure base de données ne
nécessite pas la recompilation des applications.

D. Octroi des permissions d'utilisation des procédures base de données
C’est l’administrateur de la base de données qui peut accorder le droit execute

pour les procédures qui lui appartiennent :
GRANT EXECUTE ON PROCEDURE nomproc
TO identifiant d'autorisation;
Les utilisateurs qui peuvent exécuter la procédure n’ont pas obligatoirement

les droits sur les tables ou les vues référencées dans la procédure. Ils ne
peuvent donc manipuler les données qu’à travers la procédure, ce qui
augmente la sécurité.
E. Destruction d'une procédure base de données
Pour détruire une procédure base de données :

DROP PROCEDURE nom_procedure;
A noter que si la procédure est utilisée au moment de la destruction, son

exécution continue jusqu’à la fin.

VI. Les règles
A. Définition
Une règle définit un traitement additionnel à effectuer lorsqu’une écriture est

faite dans une table. Quand une requête SQL effectue l’opération spécifiée, la
règle est déclenchée.
L’utilisation la plus classique des règles consiste à gérer l’intégrité
référentielle. Mais elles peuvent servir également pour la réplication des
données, la gestion d’une base miroir.
Une règle est composée de trois éléments :
- Le nom de la table concernée
- L’événement déclencheur : insertion d’une ligne, modification d’une ligne
ou suppression d’une ligne.
- Appel à une procédure base de données qui sera exécutée automatiquement
après l’apparition de l’événement déclencheur.
Une même table peut être controlée par plusieurs règles en cascade.
Un même événement peut être associé à plusieurs règles.
Une même règle peut être déclenchée par plusieurs événements différents.

B. Création d'une rêgle
Syntaxe :
CREATE RULE nom_regle condition_sur_la_table
EXECUTE PROCEDURE nom_procedure
[{(,nom_param=valeur)}]
condition_sur_la_table :
AFTER action
ON | OF | FROM | INTO nom_table
[REFERENCING [OLD AS ancien_enreg]
[NEW AS nouv_enreg]
[WHERE condition]
les actions possibles sont :

INSERT
UPDATE
DELETE
Le seul ordre SQL autorisé dans une règle est EXECUTE PROCEDURE.
Le créateur de la règle doit être propriétaire de la table et avoir les
permissions sur les procédures de bases de données associées. Ces mêmes
procédures doivent exister lors de la création de la règle.
Attention : la commande COPY ne déclenche pas de règles.
Il est possible de créer des règles imbriquées (profondeur d’imbrication : 20

par défaut) ou des règles récursives.

Exemple de règle :
CREATE RULE chk_ins_dept_rule

AFTER INSERT INTO dept
EXECUTE PROCEDURE ins_dept_proc
(new_budget = new.budget,
new_bati = new.bati,
new_num_emp = new.num_emp);
Cette règle va déclencher la procédure ins_dept_proc à chaque ajout de ligne

dans la table dept en transmettant à cette procédure les paramètres
new_budget, new_bati et new_num_emp.
Pour que les règles d’une base puissent être activées, l’administrateur de la
base doit exécuter la commande SQL : set rules. Au contraire, pour désactiver
le déclenchement des règles, il devra utiliser la commande : set no rules.
L’utilisateur qui déclenche la règle n’a pas besoins de posséder des droits sur
les procédures base de données que la règle exécute, ni sur les tables et vues
utilisées dans ces procédures.
C. Destruction d'une règle
Pour supprimer une règle utiliser la commande SQL :

DROP RULE nom_rule
Si la règle est en exécution lors de sa suppression, cette exécution continue
jusqu’à son terme.

Performance Des Données

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Performance Des Données

Uploaded by

Copyright:

Available Formats

Ingres Performance des données

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 1/70

1. Les différentes mesures............................................................................................................................53

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 2/70

Ce cours a pour but de présenter les différentes possibilités permettant

- L'étude du Modèle Logique des Données

A. Utilisation d'attributs dérivés (calculés)

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 3/70

procédure de recalcul du prix TTC en cas de modification soit du prix HT soit

Considérons le MLD suivant :

Constat : tout rapprochement d’informations entre un site et un projet ou entre

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 4/70

- Quels sont les projets d'un département ?

Le cas le plus favorable, un projet ne concerne qu’un département et un seul

projet (num_proj, proj, idsite*, iddept*)

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 5/70

- Les données sont volatiles. Nombreux passages d'un sous-ensemble à un

Trois solutions sont envisageables :

1. Regroupement dans une seule table

2. Une table pour chaque sous-ensemble

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 6/70

3. Une table pour les données communes et répartition dans d'autres

4. Une table avec un attribut "indicateur".

E. Les relations de degré n:m

Le modèle relationnel compte alors les 3 tables :

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 7/70

L’autre solution proposée consiste à traiter séparément le cas général et le cas

La façon de traiter 95% des employés est ainsi facilitée. La relation

F. Les attributs de synthèse

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 8/70

- L'attribut avec recouvrement : attribut dont les valeurs ne s'excluent pas.

Le modèle relationnel théorique est donc :

- L'attribut alterné : Attribut dont la signification change selon la valeur d'un

Avantages des attributs de synthèse :

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 9/70

G. Le découpage vertical ou horizontal d'une table

Employés(NumEmp, Nom, Dépt, Tél, Fonction, CV)

Si la consultation du CV est rare, on peut envisager cette solution :

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 10/70

H. Le tronc commun de données

La modification consiste ici à créer une nouvelle table commentaire dont

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 11/70

Attention, dans ce cas il faudra veiller à utiliser des numérotations différentes

Commentaire (NumPiece,NumCli,NumProj, Comment)

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 12/70

I. Optimisation du nombre de lignes ou du nombre de colonnes

Si l'on veut limiter le nombre de colonnes, on choisira une structure du style :

Cette solution contredit la 1ère forme normale mais divise le nombre

Avantages d'un nombre de lignes limité :

Avantages du nombre de colonnes limité :

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 13/70

II. L'optimisation du modèle physique

Ce chapitre a pour objectif de présenter les différentes possibilités

A. Répartition des données dans une ou plusieurs bases

La solution idéale serait de stocker toutes les informations de l'entreprise dans

Exemple : Base de données Emploi du Temps de l’ESAT :

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 14/70

B. Les différents types de données

1. Les types de données caractères

Le type char permet de stocker des chaînes de caractères de longueur fixe en

Le type varchar permet de stocker des chaînes de caractères de longueur

DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 15/70

2. Les types de données numériques

projet (num_proj, proj, idsite, iddept)