1.1) Définitons :
Avant de commencer à étudier Oracle, rappelons quelques définitions d'ordre général concernant les bases de données.

On appelle LDD (Langage de Définition de Données) le langage qui permet la création, la modification et la suppression des définitions des tables.
On appelle LMD (Langage de Manipulation de Données) le langage qui permet l' ajout, la suppression, la modification et l'interrogation des données.
On appelle LCD (Langage de Contrôle de Données) le langage qui permet La gestion des protections d’accès.

1.2) Remarques
• Une requête SQL dans Oracle se termine par un point virgule (;) et
• Un commentaire est encadré par " /*" et "*/" ou précédé par --

Un SGBD, Oracle par exemple, est un ensemble d'éléments qui permettent aux utilisateurs de disposer de programmes de gestion de données .
Dès qu'on se connecte à une base de données Oracle, on crée une instance oracle et on peut ainsi accéder à la partie physique du serveur de données Oracle. L'objet de notre article est de présenter les deux parties constitutives de la base de données Oracle,qui sont, instance et partie physique.

 

2.1) Q'est ce qu'une Instance Oracle ?
Une instance Oracle est un ensemble de processus (Background process et process Server) et une zone mémoire (SGA - Shared Global Area - et PGA - Private Global Area -) qui est caractérisée par son SID appelé ORACLE_SID ; en général, l' OS de la machine sur laquelle est installée la base de données Oracle positionne le SID parmis les variables d'environnement. Une instance ne peut être associée qu'a une et une seule base de données, par contre une base de données peut utiliser plusieurs instances.

 Toutes les Instances sont indépendantes les unes des autres. A chacune correspond :
Un db_name (nom donné à la base de données dont dépend l'instance)
Un SID (identifiant de l'instance)
Un ORACLE_SID (variable d'environnement précisant l'instance à joindre)
Un Fichier de paramétrage (par défaut initSID.ora)
Un fichier de paramétrage serveur (ou SPFILE). Ce fichier est déterminé 
 physiquement par un fichier binaire, mais aussi logiquement, 
 dans l'instance elle-même, par la commande SQL :

 

2.1.1) Background process(processus d'arrière plan) :
Les processus d'arrière plan(Background process) gérent les transferts de données entre la mémoire et le disque dur et traitent un certain nombre d'opérarations nécessaires au bon fonctionnement de la base de données. Les plus importants d'entre eux sont :

 

2.1.1.1) SMON(System Monitor) :
Le processus SMON vérifie la synchronisation des données et exécute le contenu des REDO LOG FILE Si l'instance échoue. Il nettoie aussi les segments temporaires après leur utilisation et défragmente les fichiers de données et les tablespaces.

 

2.1.1.2) PMON (Process Monitor) :
Le processus PMON gère surtout les processus des utilisateurs. Il annule les transactions d'une session (exemple il annule la session d'un utilisatateur si celle-ci échoue) ; il sert aussi à enlever tous les verrous posés lors d'une session, et à relâcher toutes les ressources mises à la disposition pour la session s'il y a eu un échec du système ou de la session utilisateur.

 

2.1.1.3) DBWn(Database Writer) :
Le processus DBWn est dédié à l'écriture du Database Buffer Cache dans les fichiers de données de la base de données. Ce processus est aussi là pour vérifier en permanence le nombre de blocs libres dans le Database Buffer Cache afin de laisser assez de place disponible pour l'écriture des données dans le buffer.

 
DBWn se déclenchera lors des événements suivants : 
- Lorsque le nombre de bloc dirty atteint une certaine limite
- Lorsqu'un processus sera à la recherche de blocs libres dans le Database Buffer Cache, 
   et qu'il ne sera pas en mesure d'en trouver.
- Lors de timeouts (environ toutes les 3 secondes par défaut)
- Lors d'un checkpoint.

2.1.1.4) LGWR(Log Writer):
Le processus LGWR transcrit les informations contenues dans le REDO LOG Buffer vers les fichiers REDOLOG FILE quand :

- une transaction s'est terminée avec un COMMIT
- le REDO LOG Buffer est au 1/3 plein 
- il y a plus de 1Mo d'informations de log contenues dans le buffer
- Avant que DBWn n'écrive le contenu du Database Buffer Cache dans les fichiers du disque dur

2.1.1.5) CKPT
Ce processus met à jour les en-têtes des fichiers de données ; il met à jour les fichiers CONTROL FILE pour montrer que l'action de CHECKPOINT s'est bien déroulée, par exemple lors d'un changement de groupe de REDO LOG FILE.
Le CHECKPOINT est un évènement qui se déclenche si on a :

- un changement de groupe de REDO LOG FILE.
- un arrêt normal de la base de données (c'est à dire sans l'option ABORT)
- une demande explicite de l'administrateur
- une limite définie par les paramètres d'initialisation 
  LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT, 
  et FAST_START_IO_TARGET

L'évènement CHECKPOINT va ensuite déclencher l'écriture d'un certain nombre de blocs du Database Buffer Cache dans les fichiers de données par DBWn après que LGWR ait fini de vider le REDO LOG Buffer. Le nombre de blocs écrits par DBWn est défini avec le paramètre FAST_START_IO_TARGET si celui-ci a été défini.

 

2.1.1.6) ARCn
Le processus ARCn a comme seule fonction de copier un fichier REDO LOG FILE à un autre emplacement. Cette copie se déclenchera automatiquement en mode ARCHIVELOG lors du changement de groupe de REDO LOG FILE. Quand on est en mode NOARCHIVELOG le processus n'existe pas.

 

 

2.1.2) process Server:
Les processus serveurs (process server) gérent les requêtes des utilisateurs provenant des connections à la base de données; ils sont chargés de la communication entre la SGA et le processus utilisateur. Ils permettent ainsi d'analyser, d'exécuter les requêtes SQL des utilisateurs, de lire les fichiers de données, de placer les blocs de données correspondants dans la SGA et de Renvoyer les résultats des commandes SQL au process utilisateur.

 

2.2) Zone mémoire SGA et PGA
On a bien dit qu' une instance Oracle est composé de processus et de deux grandes zones mémoire principales appelées SGA et PGA; étudions les en détail.

 

2.2.1) SGA (Shared Global Area)
Pour fonctionner, Oracle a besoin de beaucoup de mémoire ; il utilise une partie de cette mémoire appelée SGA pour mettre en place le macanisme de partage d'informations entre ses différents processus ; SGA est composée de quatre grandes parties et chacune d'elles joue un rôle très important :

 

2.2.2) La zone mémoire Shared Pool
La zone mémoire Shared Pool appelée aussi "zone de mémoire partagée", sert à Oracle pour le partage des informations sur les objets de la base de données et sur les droits et privilèges accordés aux utilisateurs. Elle est répartie en deux parties à savoir La Library Cache et Le Dictionnary Cache.

 

2.2.2.1) La zone mémoire Library Cache
La Library Cache stocke les informations sur les ordres SQL récemment exécutés dans une zone SQL Cache qui contiendra le texte de l'ordre SQL, la version compilée de l'ordre et son plan d'exécution. Lorsqu'une requête est exécutée plusieurs fois, Cette zone mémoire sera utilisée pour garder les informations et ainsi Oracle n'aura pas à recréer la version compilée de la requête et le plan d'exécution de la requête.

 

2.2.2.2) La zone mémoire dictionnary Cache
Le Dictionnary Cache, quant à elle, contient les définitions (i.e la structure, les composants, les privilèges liés à cet objet) des objets de la base de données utilisés récemment.
Ains, à chaque exécution d'une requête, Oracle n'aura pas à aller chercher ces informations sur le disque : il les a en mémoire dans la dictionnary cache.
La deuxième partie de la SGA est la Data Buffer Cache

 

2.2.3) La zone mémoire database Buffer Cache
Dans cette zone de mémoire on garde les blocs de données qui ont été récemment utilisées ; cette technique permet à Oracle de recupérer la première fois les données à partir du disque dur et, s'il a encore besoin des mêmes données, il les récupère dans la Data Buffer Cache; cela permet un gain de temps non négligeable.
Comme les autres zones définies ci-dessus, Database Buffer Cache a son paramètrage défini dans le fichier de configuration int.ora

 

Remarque
Cette zone mémoire est définie par 2 paramètres du fichier init.ora
DB_BLOCK_SIZE : Ce paramètre, défini lors de la création de la base de données, représente la taille d'un bloc de données Oracle. Celui-ci est défini de manière définitive et ne pourra plus être modifié.
DB_BLOCK_BUFFERS : Ce paramètre défini le nombre de blocs Oracle qui pourront être contenus dans le Database Buffer Cache. Ainsi pour obtenir la taille du Database Buffer Cache on effectuera l'opération qui nous retournera une taille en Kbytes.

 

2.2.4) La zone mémoire Redo Log Buffer
Cette zone mémoire de type circulaire,et dont on pourra changer la taille avec le paramètre LOG_BUFFER (en Bytes), sert exclusivement à enregistrer toutes les modifications apportées sur les données de la base. Le fait que cette zone mémoire soit de type circulaire et séquentielle, signifie que les informations des toutes les transactions sont enregistrées en même temps. Le fait que ce buffer soit circulaire signifie que Oracle ne pourra écraser les données contenues dans ce buffer que si elles ont été écrites dans les fichiers REDOLOG FILE.

 

2.2.5) PGA (Private Global Area )
Contrairement aux autres zones mémoire, celle-ci n'est pas partagée. Elle est seulement utilisée par des processus serveur ou processus d'arrière plan. Elle est allouée lors du démarrage du processus et désallouée lors de l'arrêt du processus.
Elle contient :
- La zone de tri : Appelée SORT AREA, c'est dans cette zone que seront effectués les tris pour les requêtes lancées par l'utilisateur.
- Les informations de sessions : Cette zone contiendra les informations de sessions, les privilèges de l'utilisateur, ainsi que des statistiques de tuning concernant la session.
- L'état des curseurs : Cette zone permettra de connaître l'état des curseurs de l'utilisateur.
- Le Stack Space : Cette zone contiendra toutes les autres variables d'environnement et de session de la session de l'utilisateur.
On peut modifier la taille de la SORT AREA en changeant la valeur du paramètre SORT_AREA_SIZE.

 

2.3) La partie physique(les composants Fichiers)
La partie physique du serveur de données oracle est un ensemble de fichiers :

 

2.3.1) Les fichiers de données
Les fichiers d'extension ".dbf" sont des fichiers de données; ils contiennent les tables, les index, les procédures, les fonctions, etc.., sans oublier le dictionnaire (créé lors de la création d'une base de données).
Les données dont on parle ici ne sont pas toutes des données au sens de données créées ou manipulables par le BDA ou le developpeur.
Les tables, les index, les vues, les synonymes, les databases links, les procédures stockées ne sont pas des données au sens où on le définit dans la base de données. L'écriture dans ces fichiers (au format propriétaire Oracle) est assurée par le processus LGWR (Log Writer) dont nous verons les détails plus tard.

 

2.3.2) Les fichiers Redo-log
Ces fichiers de journalisation, d'extension ".rdo" ou ou ".log", contiennent l'historique des modifications apportées à la base de données Oracle. Ils enregistrent les modifications successives de la base de données et permettent ainsi sa restauration en cas de défaillance d'un disque dur.
les fichiers Redo-log doivent être archivés avec une fréquence raisonnable (toutes les 3 ou 2 heures) et si c'est possible, sur des disques autres que ceux sur lesquels tourne la base de données Oracle, et pour des raisons de sécutité évidente, on doit avoir au moins deux fichiers Redo-log.
Ces fichiers doivent avoir une taille raisonnable qui permet une reconstruction rapide de la base en cas de crash car, s'ils sont gros, leur archivage est moins rapide.
Remarque :
Le cas échéant, la base de données Oracle est à même de simuler l'ensemble des commandes n'ayant pas été sauvegardées pour rétablir le contenu de la base de données.
Oracle propose également un mode d' archivage permettant la sauvegarde du fichier Redo-log avant sa réutilisation pour restaurer la base. Toutefois, Si ce mode n'a pas été activé, le contenu du fichier Redo Log est supprimé après utilisation. Enfin ces fichiers peuvent être dupliqués dans des répertoires de groupe afin de fournir un maximum de sécurité.

 

2.3.3) Les fichiers de contrôle
Ces fichiers sont créés lors de la création de la base de données et servent à stocker son état. Lors de l'initialisation de la base, ils permettent de savoir si celle-ci a été arrêtée correctement, mais aussi de savoir l'emplacement des fichiers de données et des fichiers Redo Log. Les fichiers de contrôle sont eux-mêmes repérés par le fichier d'initialisation. Le fichier de contrôle contient les informations suivantes :

- Nom de la base de données
- Date et heure de création de la base 
- L'emplacement des fichiers journaux (Redo-Log) 
- Les informations de synchronisation.

le paramètre db_create_online_log_dest_n (si il est configuré) indique où créer les fichiers de contrôle. Si db_create_file_dest se trouve dans le fichier de paramètres, c'est lui qui indiquera à Oracle où créer l'unique fichier de contrôle.

 

2.3.4) Exemple de fichier init.ora
en construction ....

Définitions
Un tablespace est une partition logique contenant un ou plusieurs fichiers. Une base peut être décomposée en plusieurs tablespaces.
Un fichier appartient à un et un seul tablespace. Un tablespace peut s'étendre soit, par ajout (on-line) d'un fichier, soit par auto-extension du fichier du tablespace ; l'ajout ou l'extension automatique se font de la façon suivant :
L'ajout d'un fichier au tablespace se fait par chaînage au premier en procédant de la façon suivante et l' extension en mettant le fichier du tablespace en AUTO extension i.e

 

3.1) Tablespace SYSTEM
Par défaut il existe toujours un tablespace baptisé SYSTEM qui contient le dictionnaire de données et le rollback segment SYSTEM (dans le cas ou il n'existe pas d'UNDO tablespace). On peut également stocker les datas et les index dans ce même tablespace, et on obtient ainsi une base minimale, peu structurée, peu performante et peu sécurisée .
C'est un peu l'équivalent de la table mysql pour la base de données MySQL. Par défaut un tablespace à la création est ON LINE, donc accessible; on peut le mettre OFFLINE (et les fichiers qu'il contient par voix de conséquence) pour en interdire l'accès ou pour certaines opérations de maintenance.

 

3.2) tablespace temporaire
Un tablespace temporaire est un tablespace spécifique aux opérations de tri pour lesquelles la SORT_AREA_SIZE ne serait pas suffisamment grande. Il n'est pas destiné à accueillir des objets de la base de données et son usage est réservé au système. Depuis la version Oracle 9i, on peut définir un tablespace par défaut au niveau base de données(à la création de la base) ou utilisateur ; chaque utilisateur peut avoir son propre tablespace temporaire ce qui est particulièrement pratique s'il existe un utilisateur spécifique pour les gros batchs par exemple.

 

3.3) tablespace UNDO
Le tablespace UNDO, comme son nom l'indique, est réservé exclusivement à l'annulation des commandes DML (UPDATE, INSERT, etc...).
Lorsqu'on exécute l'ordre DELETE par exemple, Oracle commence par copier les lignes à supprimer dans le tablespace UNDO et ensuite indique que les blocs contenant les données dans le tablespace d'origine sont libres.
Un ROLLBACK permet de revenir en arrière alors que le COMMIT supprimera les lignes du tablespace UNDO (on comprend mieux ici pourquoi un DELETE est si long - 2 écritures pour une suppression-). Le tablespace UNDO est unique pour une base de données .

 

3.4) tablespace transportable
Le tablespace transportable, introduit dans la version 8i, sert à copier les données entre deux bases de données. Depuis la 9i, la taille des blocs de la base ne doit plus être nécessairement identique.
Pour qu'un tablespace puisse être transporté, il doit contenir tous les objets interdépendants. On ne pourra pas par exemple transporter un tablespace qui contient une table dont les index seraient créés dans un autre tablespace.

Un segment correspond à l’espace utilisé par une structure logique, par exemple une table ou un index. Un tablespace peut contenir un ou plusieurs segments. Des segments sont créés dans la base de données pour stocker, extraire et gérer des données.
Un segment est un objet occupant de l’espace dans la base de données. Il est constitué d’un ou plusieurs extents. c'est à dire d’un ensemble de blocs contigus permettant de stocker un certain type d’information. Des extents sont ajoutés lorsqu’un segment nécessite davantage d’espace.

Les différents types de segments sont les suivants :
- Table
- Partition de table
- Cluster
- Table organisée en index
- Segment LOB
- Table imbriquée
- Index
- Partition d'index
- Index lob
- Rollback segment
- Segment temporaire
- Segment de démarrage 

.........

Pour les définitions relatives à une table dans une base de données, il faut se repporter au cour général sur les bases de données

 

5.1) Création d'une table avec Oracle
syntaxe: Le Type des données est l'un des types suivants:
• NUMBER(n) : Entier à n chiffres
• NUMBER(n, m) : Réel à n chiffres au total
(virgule comprise), m après la virgule
• VARCHAR(n) : Chaîne de n caractères (entre ‘ ’)
• DATE : Date au format ‘JJ-MM-AAAA’
Détaillons les différents éléments ci-dessus:
la requête sql CREAT TABLE est suivie du nom de la table que l'on veut créer; ensuite, viennent entre parenthèses les différents attributs, chacun avec son TYPE.
Ensuite viennent les contraintes(s'il y en a); on verra un peu plus loin comment elles sont définies.
Un nom de table doit être unique et ne doit pas être un mot clé SQL. Une table doit contenir au minimum une colonne et au maximum 254 colonnes.

 

Définition de colonne
La définition élémentaire d'une colonne consiste à lui attribuer un nom et un type.

 

exemple
Imaginons une entreprise qui veut mettre dans une base de données les informations concernant ses employés ; on commence par créer une table qu' on peut appeler par exemple Employes ; cette table Employee représente les employés et voici son shéma :
Employes(NumCli,Nom, DateNaissance, Salaire, NumEmp).
La création, comme on l'a dit un peut plus haut, se fait de la façon suivante:

Quant on a défini les généralités des bases de données, on a vu que les contraintes permettent d'assurer le maintien de la cohérence des données de la base. Ces contraintes sont associées à la description de la BD lors de la définition des tables. Cinq types de contraintes peuvent être définis :

- caractère obligatoire ou facultatif,
- unicité des lignes,
- clé primaire,
- intégrité référentielle,
- contrainte de valeurs.

Les contraintes peuvent s'exprimer soit au niveau colonne (local) soit au niveau table (contraintes globales).
A chaque expression de contrainte est affectée un nom de contrainte, soit de façon implicite par le SGBD, soit de façon explicite par la clause CONSTRAINT

Les contraintes comme clé primaire, clé étrangère, ( voir cours sur les Bases des données en général) sont des contraintes sur les colonnes de la table ; une contrainte, quand elle porte sur une colonne de la table, peut-être définie au moment où on définit la colonne par le mot prédéfini CONSTRAINT placé devant le nom de la colonne ; illustrons notre propos dans la création de la table articles suivante :

comme on l'a dit un peut plus haut, on peut distinguer deux catégories de contraintes:
- contraintes sur les colonnes
- contraintes sur les tables

 

 

Contrainte sur les colonnes
Il est possible de spécifier des contraintes d'intégrité au niveau des colonnes lors de la phase de création de la table. Si la table est déja créée, il est possible d'utiliser l'instruction ALTER TABLE. Une contrainte d'intégrité est spécifiée juste après le type de la colonne, et il est possible d'en définir plusieurs. La syntaxe générale est:

Le mot CONSTRAINT est optionnel et permet d'attribuer un nom à la contrainte à définir. Ainsi si on nomme la contrainte C1, il y aura sauvegarde au niveau du dictionnaire de données d'un objet de type contrainte nommé C1 avec sa définition.
Par défaut Oracle attribut comme nom de contrainte SYS_Cn, où n est un entier.

Le mot NULL permet à la colonne d'avoir des valeur nulles. Pour interdire cela on peut spécifier la contraint NOT NULL.
Exemple:
Si on désire imposer d'avoir toujours une valeur dans l'attribut pnom de la table pièce P ci-dessus, on peut écrire lors de la définition de cette colonne:
CREATE TABLE P (..., pnom varchar(20) CONSTRAINT C_pnom NOT NULL,...)

La clause UNIQUE impose l'unicité des valeurs d'une colonne. Deux occurences ne peuvent pas avoir la même valeur pour cette colonne. Les valeurs nulles sont autorisées sauf si une contrainte NOT NULL est spécifiée. L'utilisation de cette clause fait qu'Oracle crée automatiquement un index relatif à cette colonne.

La clause PRIMARY KEY indique que la colonne est une clé primaire de la table. Cette contrainte est la même que UNIQUE sauf qu'elle interdit les valeurs nulles. Il y a automatiquement création d'index relatif à cette colonne.

Le mot REFERENCES indique que les valeurs de cette colonne doivent être les mêmes que celles dont le nom suit le mot references. Il s'agit d'une contrainte d'intégrité referentielle par rapport à une clé unique ou primaire.

La clauses ON DELETE CASCADE permet de supprimer automatiquement les valeurs d'une clef étrangère dépendant d'une autre clef unique ou primaire si une valeur de cette dernière vient d'être supprimée. Le mot clef CHECK est utilisé pour forcer la vérification de la condition qui le suit à chaque valeur insérée. Le mot clef DISABLE désactive une contrainte car elle sont par défaut activée par Oracle.

 

 

Contrainte sur les tables
Jusqu'à présent nous avons présenté les contraintes spécifiées au niveau d'une colonne, cependant on peut avoir besoin de spécifier une contraine relative à deux ou plusieurs colonnes. C'est le cas quand on a une clé primaire composée de deux colonnes ; on parle alors de contrainte d'intégrité de table. La syntaxe générale est: Le mot FOREIGN KEY permet de spécifier une ou plusieurs colonnes comme une clef étrangère.

 

Remarque : clé primaire et clé étrangère composite
...... à suivre

 

Intégrité de domaine
...... à suivre

Les tables initiales, appelées tables de base (voir la défintion ci-dessus) existent de façon indépendantes. Une table qui est obtenue à partir des tables de base au moyen d'une expression relationnelle est appelée table dérivée.
Dans les SGBD relationnels, la notion de schéma externe correspond au concept de table dérivée. On distingue deux types de tables dérivées : les vues et les instantannés. Une vue ou table virtuelle n'a pas d'existence propre : sa consommation en ressources consiste seulement en sa description dans le dictionnaire de données.
On parle de "vue" car il s'agit simplement d'une représentation des données dans le but d'une exploitation visuelle. Les données présentes dans une vue sont définies grâce à une clause SELECT

les opérations sur une vue sont appliquées en remplaçant les références à cette vue par l'expression qui définit cette vue. La commande CREATE VIEW permet de créer une vue en spécifiant la requête constituant la définition de la vue et en voilà un exemple: Les vues ainsi créées peuvent être l'objet de nouvelles requêtes en précisant le nom de la vue au lieu d'un nom de table dans un ordre SELECT...
La spécification des noms des colonnes de la vue est facultative. Par défaut, les colonnes de la vue ont pour nom les noms des colonnes résultat de la requête.

L'option WITH READ ONLY indique qu'il est impossible de réaliser des mises à jour sur la vue.
La clause WITH CHECK OPTION empêche que l'utilisateur ajoute ou modifie dans une vue des lignes non conformes à la définition de la vue.
Mais, pour faire une mise à jour au travers d'une vue, il doit être possible de propager la mise à jour sur les tables source. La mise à jour d'une vue ne peut se faire donc que si :
- La clause FROM ne fait référence qu'à une seule table ou à une vue accessible en mise à jour,
- Elle ne comporte pas de DISTINCT ou de fonction sur colonne (SUM, COUNT : : : ), De manière simplifiée, on peut dire que les ordres INSERT, DELETE et UPDATE ne peuvent s'appliquer qu'à une vue n'utilisant qu'une seule table avec restrictions et projections.
Une vue peut être détruite par la commande :

 

Lister les vues :

Un snapshot est une relation nommée et dérivée. Cependant contrairement à une vue, un cliché n'est pas virtuel mais réel c'est à dire :
a) le résultat est conservé dans la base de données comme une seule relation accessible en lecture seulement ;
b) périodiquement, l'instantanné est rafraîchi c'est à dire, sa valeur courante est écartée, la requête est exécutée à nouveau et le résultat devient la nouvelle valeur de l'instantanné. Cette technique permet de créer sur une base distante un cliché d'une table complète ou partielle ou même un cliché du résultat d'une requête complexe effectuée sur la base maître.
La création se fait par : où
FAST définit un mode de rafraîchissement rapide qui met à jour uniquement les lignes modifiées de la base maître.
COMPLETE définit un mode rafraîchissement complet qui ré-exécute la requête du cliché
FORCE (par défaut) effectue un rafraîchissement rapide si possible, sinon effectue un rafraî- chissement complet
START WITH définit la date du premier rafraîchissement
NEXT définit l'intervalle entre deux rafraîchissements.

Un index est un objet complémentaire (mais non indispensable) à la base de données ; il permet dans certains cas, d' indexer des colonnes de la base de données et d'améliorer l'accès aux données ; cela permet des fois de gagner beaucoup de temps .
Si on crée un index sur une colonne d'une base de données, il faut toujours avoir à l'esprit qu'il utilise de l'espace mémoire, et, étant donné qu'il est mis à jour à chaque modification de la table à laquelle il est rattaché, il peut alourdir le temps de traitement du SGBDR lors de la saisie de données.
La création d'index doit être justifiée et les colonnes sur lesquelles il porte doivent être judicieusement choisies pour minimiser les doublons et le temps d'accès.

 

8.1) Structure d'un index
Les index sont des structures permettant de retrouver une ligne dans une table à partir de la valeur d'une colonne ou d'un ensemble de colonnes. Un index contient la liste triée des valeurs des colonnes indexées avec les adresses des lignes (numéro de bloc dans la partition et numéro de ligne dans le bloc) correspondantes.
Tous les index oracle sont stockés sous forme d'arbres équilibrés (btree) ; cette une structure arborescente permet de retrouver rapidement dans l'index la valeur de clé cherchée, et donc l'adresse de la ligne correspondante dans la table.
Dans un tel arbre, toutes les feuilles sont à la même profondeur, et donc la recherche prend approximativement le même temps quelle que soit la valeur de la clé.
Lorsqu'un bloc d'index est plein, il est éclaté en deux blocs ; en conséquence, tous les blocs d'index ont un taux de remplissage variant de 50% à 100%.
Remarque :
Sans index on balaie séquentiellement toute la table quelle que soit la position de l'élément recherché.

 

8.2) Utilisation des index
L'adjonction d'un index à une table ralentit les mises à jour (insertion, suppression, modification de la clé) mais accélère beaucoup la recherche d'une ligne dans la table.
L'index accélère la recherche d'une ligne à partir d'une valeur donnée de clé, mais aussi la recherche des lignes ayant une valeur d'index supérieure ou inférieure à une valeur donnée, car les valeurs de clés sont triées dans l'index.

 

8.3) La création d'un index
La création d'index en SQL se fait grâce à la clause INDEX précédée de la clause CREATE. Elle permet de définir un index désigné par son nom, portant sur certains champs d'une table. La syntaxe est la suivante: L'option UNIQUE permet de définir la présence ou non de doublons pour les valeurs de la colonne et les options ASC/DESC permettent de définir un ordre de classement des valeurs présentes dans la colonne

9.1) Exemple 1: Bibliothèque
On va proposer des entités-associations qui modélisent le cas ci-dessous tout en précisant en français les contraintes .
La bibliothèque d'une petite ville possède deux points de prêt. Ces 2 centres disposent d'ordinateurs personnels interconnectés qui permettent de gérer les emprunts.
En dialoguant avec les bibliothécaires on a déterminé les faits suivants:
- un client qui s'inscrit à la bibliothèque verse une caution. Suivant le montant de cette caution il aura le droit d'effectuer en même temps de 1 à 10 emprunts;
- les emprunts durent au maximum 8 jours;
- un livre est caractérisé par son numéro dans la bibliothèque (identifiant), son éditeur et son (ses) auteur(s);
- on veut pouvoir obtenir, pour chaque client les emprunts qu'il a effectué (nombre, numéro et titre du livre, date de l'emprunt) au cours des trois derniers mois;
- toutes les semaines, on édite la liste des emprunteurs en retard :
nom et adresse du client, date de l'emprunt, numéro(s) et titre du (des) livre(s) concerné(s);
- on veut enfin pouvoir connaître pour chaque livre sa date d'achat et son état.
Notre démarche consiste à élaborez un diagramme entité-association pour la base de données de la bibliothèque en précisant les contraintes d'intégrité.
exemple de contrainte : pour chaque livre la date d'achat doit être antérieure aux dates d'emprunt.

 

9.2) Exemple 2: Editeur
Un éditeur souhaite installer une base de données pour mémoriser les informations suivantes :
- les livres sont identifiés par leur n° ISBN. Un livre possède un titre et un prix de vente. - Il est écrit par un ou plusieurs auteurs.
- Chaque livre est tiré en une ou plusieurs éditions, datées et identifiées par leur ordre (première édition, seconde édition, etc.). - Chaque édition comporte un certain nombre d'exemplaires. Un livre peut être primé (Goncourt, Fémina etc.).
- les auteurs sont identifiés par leur nom et prénom et peuvent avoir un pseudonyme. - Pour chaque livre, un auteur perçoit des droits d'auteur, calculés comme un pourcentage du prix de vente (il est aussi fonction du nombre d'auteurs, du tirage, etc.).
- les libraires (identifiés par leur nom et adresse complète) peuvent envoyer des commandes d'un ou plusieurs livres en quantité quelconque.

SQL permet de comparer une expression ou une colonne au résultat d'une autre requête select. Cette condition est dite condition de sous requête et les deux requêtes sont dites requêtes imbriquées. Les formes générales des sous-requêtes suivent généralement le WHERE et elles se présentent comme:
Remarques:
- Les sous-requêtes situées après les mots-clé IN, ALL, ANY et SOME doivent avoir le même nombre de colonnes que celui spécifié dans l'expression.
- Ces sous-requêtes peuvent rendre plusieurs valeurs qui seront évaluées en fonction de l'opérateur de comparaison: ALL/ANY/SOME:
la condition est vraie si la comparaison est vraie pour chacune des valeurs retournées par la sous-requête.