Professional Documents
Culture Documents
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
Introduction
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.
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
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
Et le modèle relationnel :
Employé(idemp, nom, iddept*, date)
Département(iddept, nom)
AutreAffectation(idemp, iddept, date)
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, …)
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.
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.
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.
On obtient alors :
Pièce (NumPiece, NomPiece, QteStock)
Client(NumCli, NomCli, PrenomCli, AdresseCli)
Projet(NumProj, NomProj, DateProj)
Commentaire (NumComment, 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.
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)
Le choix des types de données peut influer sensiblement sur les performances,
mais aussi sur l'espace disque utilisé.
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.
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.
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
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.
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.
N peut être estimé à un nombre moyen de produits achetés par un client. Reste
à estimer le nombre moyen de clients par jour.
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.
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.
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é
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.
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.
* 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
- 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.
On pourra ici aussi, dans certains cas, faire appel à une clé de substitution.
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 :
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.
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.
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] […]
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
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
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.
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.
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.
DMSI/ANALYSE/LCY/ le 10/11/2009 23241727.doc Page 48/70
Ingres Performance des données
Exemples de QEP :
Exemple n° 1 :
Proj-rest
Sorted(ref_vin)
D6 C1
vin
B-Tree(NU)
********************************************************************
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.
FSM Join(ref_cru)
Heap
Pages 1 Tups 13
D9 C17
/ \
Proj-rest Proj-rest
D3 C1 D6 C1
/ /
cru vin
B-Tree(NU) B-Tree(NU)
********************************************************************
********************************************************************
FSM Join(ref_cru)
Heap
Pages 1 Tups 2
D9 C17
/ \
Proj-rest Proj-rest
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.
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.
A. Recommandations
Exemple :
Emp(eno, nom, prenom, salaire)
Dept(deptno,mgrno*,budget)
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
********************************************************************
/
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
********************************************************************
********************************************************************
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
********************************************************************
Cette requête sera d’autant plus efficace s’il n’y a que peu de valeurs
concernées par le GROUP BY.
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.
Syntaxe :
Liste des ordres SQL utilisables dans une procédure base de données
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.
A. Définition
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.
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]
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.
Exemple de règle :
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.