Bases de Données - Sylvain BRANDEL

Université Louis Pasteur de Strasbourg
Département informatique
Bases de Données
Sylvain BRANDEL
Pôle API UFR math-info

Boulevard Sébastien Brant 7 rue René Descartes
67 400 ILLKIRCH 67 000 STRASBOURG
bureau C 112 bureau 303
tél : 03 90 24 45 68 tél : 03 90 24 02 47
e-mail : brandel@dpt-info.u-strasbg.fr
Chapitre 1 : BD et SGBD..................................................................................................................................... 3
I. Introduction ..................................................................................................................................................... 3
II. Analyse........................................................................................................................................................... 3
III. Bases de données .......................................................................................................................................... 4
IV. Système de Gestion des Bases de Données (SGBD) .................................................................................... 4
Chapitre 2 : Modèles............................................................................................................................................ 9
I. Le modèle relationnel ...................................................................................................................................... 9
II. Le modèle Entités / Associations.................................................................................................................. 22
Chapitre 3 : Les Schémas................................................................................................................................. 29
I. Le schéma conceptuel.................................................................................................................................... 29
II. Schémas logiques ......................................................................................................................................... 40
III. Schéma physique......................................................................................................................................... 43
Chapitre 4 : Robustesse.................................................................................................................................... 51
I. Sécurité .......................................................................................................................................................... 51
II. Confidentialité .............................................................................................................................................. 55
III. Intégrité ....................................................................................................................................................... 57
IV. Performances .............................................................................................................................................. 57
Chapitre 5 : Annexe – syntaxe des commandes ........................................................................................... 59
I. Langage d'interrogation des données ............................................................................................................. 59
II. Langage de définition de données ................................................................................................................ 61
III. Langage de manipulation de données ......................................................................................................... 64
IV. Schéma logique........................................................................................................................................... 64
V. Schéma physique.......................................................................................................................................... 65
VI. Langage de contrôle des transactions.......................................................................................................... 66
VII. Confidentialité ........................................................................................................................................... 66
–2– Bases de données – master GPI – S. Brandel – 2007

Chapitre 1 : BD et SGBD
Références :
Bases de Données objet et relationnel Introduction aux bases de données, modèle relationnel
Georges Gardarin Richard Grin (support de cours)
éd. Eyrolles Université de Nice Sophia-Antipolis
I. Introduction
Une Base de données (BD ou DB) est un ensemble de données modélisant les objets d'une partie du monde réel
et servant de support à une application informatique.
Une BD est donc un ensemble structuré permettant l'extraction d'informations de manière sélective par plusieurs
utilisateurs.
Un Système de gestion de bases de données (SGBD) est un logiciel permettant d’interagir avec une BD.
II. Analyse
Avant de penser BD, il convient de poser des questions, étudier, analyser les besoins, afin de récolter les
informations (sous forme d'interview en langage "humain") nécessaires à la conception de la BD. La méthode
d'analyse la plus complète est MERISE.
Les grosses applications (banques, VPC…) sont souvent composées d'applications non coordonnées (redondance
élevée, nombreux synonymes, interfaces multiples, difficultés de MAJ), et sont généralement "touffues" (astuces
de programmes, GOTO, optimisations ponctuelles, absence de dossier). Enfin l'absence de concertation peut
conduire à des résultats différents des souhaits.
MERISE est une méthode globale et intégrée, qui permet de repenser l'organisation actuelle en terme de SAI
(Système d'Automatisation de l'Information), et d'intégrer différents utilisateurs.
Une des caractéristiques principales de MERISE est la séparation données / traitements : les analyses sont
conduites séparément puis confrontées. Il s'agit d'une démarche opposée à la philosophie "objet".
3 niveaux de modélisation, classés par ordre d'invariance décroissant (plus le niveau est élevé, et plus le système
est stable) :
• niveau conceptuel
• niveau organisationnel
• niveau technique
Le niveau conceptuel répond à la question "QUOI ?" : que faire ? avec quelles données ? Il comporte le modèle
conceptuel des données (MCD), qui représente l'aspect statique du Système d'Information sous forme de schéma
entité / associations, et le modèle conceptuel des traitements (MCT), qui prend en compte les évènements
externes et internes.
Le niveau organisationnel répond aux questions "QUI, QUAND, OU ?". Il comporte le modèle logique des
données (MLD), qui est la "représentation du MCD en fonction de l'état de l'art technologique" (Tardieu), et le
modèle organisationnel des traitements (MOT), qui permet de modéliser les notions de temps et de durée, les
postes et leur responsabilités, ainsi que les lieux et leurs ressources.
Le niveau technique répond à la question "COMMENT ?", en intégrant les moyens techniques, matériels et
logiciels. Il comporte le modèle physique des données (MPhD), qui propose une solution technique optimale
pour l'implantation physique des données et la description de leurs liens, et le modèle opérationnel des
traitements (MOpT), qui intègre les contraintes techniques dans l'organisation des traitements.
MERISE comporte de nombreux inconvénients : il nécessite de produire beaucoup de documents, est lourd pour
des petites applications. Par rapport aux étudiants, il est lourd sur les exemples pédagogiques et procure un
sentiment de flou : haut niveau d'abstraction, et méthodologie rigoureuse mais non déterministe (possibilité de
production de différents algorithmes).

III. Bases de données
Une BD est une collection de représentation de la réalité sous forme de données inter-reliées. Cette collection
doit être cohérente, structurée, avec une redondance calculée, et, si possible, centralisée.
La redondance pose de nombreux problèmes : volume de données important (moins grave actuellement :
mémoires de masse importantes), temps de saisie et de mise à jour (par exemple, si on dispose de 3 fichiers
clients, la saisie d'un client doit être effectuée trois fois, avec des risques d'erreur), difficultés de tenir à jour les
informations pour "coller" à la réalité.
Il est donc nécessaire de maintenir les données sous forme cohérente : être juste par rapport à une certaine
réalité (intégrité des données). La réalité doit être fixée sous forme de règles ou contraintes d'intégrité. La BD est
cohérente si elle respecte les contraintes d'intégrité énoncées (dépendantes des applications). Les règles
définissant les liens entre les données de la base décrivent la réalité.
La BD doit satisfaire une grande variété de demandes de renseignements exprimée par de nombreux utilisateurs.
Les utilisateurs ont des exigences de réponse qui doivent être compatibles avec leurs conditions de travail. Il est
pour cela nécessaire de gérer une entité commune, centrale, à laquelle accèdent tous les utilisateurs. L'utilisateur
doit pouvoir travailler comme il l'a toujours fait, avec sa propre vision de la BD.
IV. Système de Gestion des Bases de Données (SGBD)

Un SGBD est un ensemble de logiciels permettant aux utilisateurs de manipuler efficacement des données dans
une grande masse d'information partagée avec d'autres utilisateurs.
A. Historique
4 générations. Le début se situe vers 1965 avec le programme Apollo d'IBM.
La 1ère génération (fin des années 60) comporte les modèles réseau ou hiérarchique, organisés autour de types
d'articles constituant les nœuds d'un graphe, les arcs étant des types de pointeurs. Les SGBD de la 1ère génération
sont, par exemple, TOTAL, IDMS.
Dans les modèles hiérarchiques, les données sont représentées sous forme d’une structure arborescente
d’enregistrements. Cette structure est conçue avec des pointeurs et détermine les chemins d’accès aux données.
La structure de donnée est facile à comprendre et les chemins d'accès sont fixes, il y a donc peu de commandes.
Par contre, l'organisation est non naturelle, le contrôle de cohérence est délicat, et la recherche est coûteuse, à
cause de l'unicité du chemin d'accès.
Dans les modèles réseau, la structure peut être visualisée sous forme d’un graphe quelconque. Comme pour le
modèle hiérarchique, la structure est conçue avec des pointeurs et détermine le chemin d’accès aux données. Ce
modèle est moins restrictif, les liaisons sont représentées de manière plus naturelle, et il y a moins de
redondances. Par contre il n'y a pas d'indépendance vis-à-vis des stratégies d'accès.
Dans ces deux modèles, les programmes ne sont pas indépendants de la structure logique de la base et du chemin
d’accès aux données : ils doivent décrire comment retrouver les données (on parle de navigation dans la base) et
si, par exemple, on enlève un index, tous les programmes qui l’utilisaient doivent être réécrits. De plus, le
langage de travail est complexe.
La 2ème génération (fin des années 70) marque le début du modèle relationnel, en partant de la théorie des
ensembles en mathématiques. Les données sont présentées aux utilisateurs sous forme de relations entre
domaines de valeurs, simplement représentées par des tables, et non plus les pointeurs qui figeaient la structure
de la base. Les recherches et mises à jour sont effectuées à l'aide d'un langage non procédural standardisé : SQL
(Structured Query Language), permettant de traduire les requêtes du langage courant. Les SGBD de la 2ème
génération représentent l'essentiel du marché actuel et sont, par exemple, ORACLE, SYBASE, INFORMIX,
DBASE, SQL SERVER.

L’inventeur du modèle relationnel est Codd (IBM). Il a énoncé 12 règles que doivent vérifier les SGBD pour être
relationnels (actuellement aucun SGBD ne les respecte toutes, mais certains tentent de s’approcher de cette
"perfection" relationnelle) :
• règle 1 : toutes les informations sur les données sont représentées au niveau logique et non physique (pas
besoin d’informations sur la façon dont sont enregistrées physiquement les données)
• règle 2 : les données sont accessibles uniquement par la combinaison du nom de la table, de la clé
primaire et du nom de la colonne (pas de chemin à donner)
• règle 3 : une valeur spéciale doit représenter l’absence de valeur (NULL)
• règle 4 : la description de la base de données doit être accessible comme les données ordinaires (un
dictionnaire des données est enregistré dans la base)
• règle 5 : un langage doit permettre de définir les données, définir des vues (visions particulières de la
base, enregistrées comme des relations), manipuler les données, définir des contraintes d’intégrité, des
autorisations de gérer des transactions
• règle 6 : on peut faire des mises à jour par les vues lorsque c’est logiquement possible
• règle 7 : le langage doit comporter des ordres effectuant l’insertion, la mise à jour et la suppression des
données (un seul ordre pour effectuer chacune de ces fonctions)
• règle 8 : indépendance des programmes vis-à-vis de l’implantation physique des données
• règle 9 : indépendance des programmes vis-à-vis de l’implantation logique des données (si les
informations manipulées par les programmes n’ont pas été modifiées ou supprimées
• règle 10 : les contraintes d’intégrité doivent pouvoir être définies dans le langage relationnel et
enregistrées dans le dictionnaire des données
• règle 11 : indépendance vis-à-vis de la répartition des données sur divers sites
• règle 12 : on ne peut jamais contourner les contraintes (d’intégrité ou de sécurité) imposées par le
langage du SGBD en utilisant un langage de plus bas niveau (par exemple le C)
Les structures de données complexes sont éclatées par le modèle relationnel et la reconstruction de la structure
nécessite des opérations (jointures) coûteuses en performances. Pour y palier, les systèmes de la 3ème génération
(fin des années 80), proposent des extensions objet des systèmes relationnels. Ce sont, par exemple, ORACLE 8,
DB2 Universal Database, Informix Universal Server.
Les données et les programmes sont structurés conjointement en types : les données sont enregistrées avec les
procédures qui permettent de les manipuler. Il est de plus possible de définir des sous-types par héritage.
Enfin, la 4ème génération (années 90 et actuellement), qui est plus une extension de la 3ème génération que
vraiment une nouvelle génération, permet de mieux supporter Internet et le Web, les informations mal
structurées, les objets multimédia, l'aide à la décision et l'extraction de connaissances, tout en restant un système
relationnel (domaine actif de recherche Intelligence Artificielle).
Il n’existe pas encore de norme, et ces SGBD sont encore utilisés pour des usages bien spécifiques : le manque
de support et d’uniformité dans les implantations des différents SGBD du marché conduisent à les utiliser avec
prudence.
B. Objectifs des SGBD

Un SGBD doit assurer la sécurité, la confidentialité, l'intégrité et de bonnes performances des données alors que
plusieurs utilisateurs peuvent accéder simultanément à la BD.
Nous verrons tout cela en détail dans le chapitre 4.

C. Architecture des SGBD
Utilisateur LMD Menu Langage hôte
Schéma Schéma
externe A externe B
Niveau
logique
Schéma conceptuel SGBD
Niveau
physique
Schéma interne
SE
BD
Ce type d'architecture (norme ANSI/SPARC) comporte 3 schémas (conceptuel, externe, interne), 2 langages
(LDD et LMD) et gère 3 types d'utilisateurs (administrateur, programmeur, utilisateur final).
1) Schémas
Le schéma conceptuel est le niveau central, il décrit les données et les contraintes d'intégrité qui y sont liées. Il
n'y a qu'un schéma conceptuel.
Les schémas externes sont les visions des données d'un utilisateur ou d'un groupe d'utilisateurs. Ils décrivent
une partie seulement des données (vision parcellaire, incomplète), ce qui permet d'assurer sécurité et
confidentialité des données. Il existe autant de visions externes que d'utilisateurs, mais les visions des différents
utilisateurs vont se recouper (informations communes).
Le schéma interne décrit la manière dont les données sont stockées sur les organes physiques. Dans un SGBD,
l'organisation physique des données est effectuée par le système d'exploitation, ignoré par l'utilisateur. Il peut y
avoir plusieurs modèles physiques pour un même modèle logique.
Il y a indépendance logique si le schéma conceptuel peut être modifié ou enrichi sans que cela affecte les
schémas externes des utilisateurs et leurs programmes d'application, et indépendance physique si on peut
modifier le schéma interne sans affecter le schéma conceptuel. Cela permet de ne pas être lié au matériel ou au
système d’exploitation (seul le niveau interne en dépend).
2) Utilisateurs
L'administrateur est le(s) responsable(s) de tout ce qui touche à la BD : il s'occupe de la création de la base et
des utilisateurs, il définit les droits d'accès, assure le bon fonctionnement en gérant les sauvegardes…
Le programmeur développe des applications utilisant la BD. Il a le droit de créer de nouvelles tables et les
structures associées (vues, index, clusters…). Il définit les droits qui seront accordés aux utilisateurs des
applications qu’il développe.
L'utilisateur final n’a accès qu’aux données qui lui sont utiles. Il a certains droits accordés par l’administrateur :
consultation, ajout, modification, suppression. Généralement il n’a pas le droit de création, de modification ou de
suppression de tables.

3) Langages
Le langage de définition des données (LDD) est utilisé par l'administrateur de la base. Il permet de définir le
schéma conceptuel et les schémas externes, ainsi que les données, liens, contraintes d'intégrité. Il est utilisé lors
de la conception de la base et la modification des schémas.
Le langage de manipulation des données (LMD) sert à interroger et mettre à jour la BD. Les instructions
peuvent être interactives (outils en ligne, interfaces avec des outils de bureautique ou avec le web), insérées dans
un langage de programmation = langage hôte de 3ème génération (C Æ Pro*C) ou de 4ème génération (langages
conçus spécifiquement pour développer des applications qui utilisent des BD), ou encore sous forme de menus
(forms...), de formulaires, d’états imprimés…
D. Exemple de fonctionnement d'un SGBD

Nous allons voir ici comment l’architecture ANSI/SPARC est utilisée lorsqu’un programme d'application,
accédant à la base de données via le schéma externe B, demande la lecture d'une donnée de la base.
Tout d’abord la demande est transmise au SGBD. Ensuite le SGBD analyse la demande puis transfère l'ordre de
lecture au Système d'Exploitation. Le système d’exploitation reçoit l'ordre, l'analyse, puis lance un ordre de
lecture au contrôleur des unités périphériques. Les données sont ensuite placées dans un tampon, puis le SGBD
sélectionne, dans le tampon, les données effectivement demandées et les transmet au tampon du programme
d'application. Le SGBD peut alors prévenir le programme d'application en cas de déroulement anormal.
Finalement, le programme d'application dispose de la donnée demandée.
E. Implantation d'un SGBD

Ce paragraphe décrit les solutions retenues dans l'implantation du SGBD Oracle.
1) Fichiers de la base
Tous les SGBD gèrent eux-mêmes l'enregistrement des données sur les mémoires auxiliaires (disques le plus
souvent). Les performances sont ainsi meilleures que s'ils utilisaient simplement le système d'exploitation et son
système de fichiers. En général, ils se réservent de très gros fichiers du système d'exploitation et ils gèrent eux-
mêmes cet espace pour allouer de la place aux tables, index et autres objets manipulés.
Un autre avantage est la plus grande facilité pour le portage sur des systèmes d'exploitation différents.
2) Processus clients – serveurs

L'utilisation d'un SGBD s'appuie sur le mode client – serveur : les applications des utilisateurs qui accèdent à la
base sont clients de processus serveurs lancés en arrière plan par le SGBD.
Les applications clientes n'ont pas d'accès direct aux données de la base. Elles transmettent leurs requêtes (SQL
pour Oracle et la plupart des SGBD relationnels) aux processus serveurs du SGBD. Un processus serveur peut
prendre en charge l'interface entre la base et un ou plusieurs processus clients. Il y a en général plusieurs
processus serveurs qui fonctionnent en même temps.
Un processus serveur exécute les requêtes des clients dont il a la charge et en particulier
- transmet aux clients les résultats des requêtes de consultation de la base (les données seront lues en
mémoire dans les buffers de la base si elles y sont déjà),
- dépose dans les buffers de la base (en mémoire) les données ajoutées ou modifiées par les requêtes de
manipulation des données.

3) Ecriture des données dans la base
Un seul processus (Data Base Writer, DBWR) a la charge d'enregistrer dans les fichiers de la base les données
déposées dans les buffers par les processus serveurs. Le fait qu'un seul processus soit chargé de cet
enregistrement facilite le maintien de l'intégrité des données.
Pour des raisons de performances cette écriture se fait de manière asynchrone par rapport aux actions des
serveurs. Il y a, par exemple, écriture quand les buffers sont pleins. L'écriture des différentes entrées des buffers
se fait par l'algorithme LRU (Least Recently Used) et ne tient pas compte des COMMIT : les entrées qui sont
enlevées des buffers et enregistrées dans la base sont celles qui ont été le moins récemment utilisées. Une entrée
très utilisée peut donc n'être enregistrée (physiquement sur le disque) dans la bas que longtemps après son
écriture dans les buffers de la base.
4) Fichiers log
Parallèlement à l'enregistrement des données, les processus serveurs enregistrent toutes les actions effectuées sur
les tables de la base (et dans les segments de rollback), dans des fichiers indépendants des fichiers de la base,
appelés fichiers log (redo log dans Oracle).
Comme pour les données de la base, les données enregistrées dans les fichiers redo log sont d'abord déposées en
mémoire dans des buffers et enregistrés dans les fichiers par un seul processus (Log Writer dans Oracle). Ces
enregistrements ont lieu régulièrement, par exemple quand les buffers sont pleins, et au moins dès qu'il y a eu un
COMMIT.
L'enregistrement d'un COMMIT dans les fichiers redo log est l'événement de référence pour la confirmation
d'une transaction. Chaque COMMIT déclenche une écriture immédiate sur le disque des entrées du buffer des
fichiers redo log correspondant à la transaction validée. Cette écriture est rapide car séquentielle alors que
l'écriture des modifications dans la base est même plus lente.
Lorsque les fichiers redo log ont enregistré un COMMIT et qu'une panne survient avant que les données
correspondant à la transaction de la base ne soient écrites dans la base, le SGBD effectue l'enregistrement
physique des données après la reprise. Si par contre c'est un ROLLBACK qui a été enregistré et si des
modifications ont déjà été enregistrées (par exemple parce que les buffers des fichiers redo log étaient pleins),
les données sont remises à leur état précédant la transaction après le redémarrage, à l'aide des segments de
rollback.
5) Segments de rollback
Quand des données sont modifiées dans une base Oracle, toutes les informations qui permettraient de retrouver
les anciennes données (essentiellement les valeurs anciennes des données modifiées) sont enregistrées dans la
base dans ce des segments de rollback.
Ces segments sont utilisés :
- pour annuler une transaction après une instruction ROLLBACK
- tant qu'une transaction n'est pas confirmée par un COMMIT, les modifications qu'elle apporte aux
données ne doivent pas apparaître aux autres transactions (principe de lecture consistante).
6) L'optimiseur de requêtes SQL

SQL est une langage non procédural. Par exemple, une instruction SELECT décrit les données recherchées sans
indiquer la manière d'aller les chercher dans la base.
L'optimiseur est le module du SGBD qui va concevoir un plan pour aller rechercher les données de la manière la
plus efficace possible. Il utilisera généralement pour cela les index.
L'optimiseur utilise des règles de simplification et d'optimisation implantées par les concepteurs du SGBD, et les
données statistiques sur les tables (par exemple, nombre de lignes et nombre de valeurs différentes dans les
colonnes).

Chapitre 2 : Modèles
I. Le modèle relationnel
A. Définitions
Une relation R est sous-ensemble du produit cartésien de n ensembles D1, D2,… Dn appelés domaines ; n est
appelé le degré de la relation. Une relation est constituée de n-uplets de la forme (d1, d2,… dn).
Plusieurs domaines peuvent être identiques. A chaque domaine et associé un nom d’attribut Ai qui est lié à sa
signification sémantique par rapport à la relation.
Pour décrire une relation, on énumère ses attributs et on donne la liste des n-uplets qui lui appartiennent
(définition en extension). On peut aussi définir le prédicat qui permet de juger si un n-uplet appartient à la
relation (on dit parfois définition en intension).
Chaque n-uplet est une occurrence de la relation.
On note la relation R(A1, A2,… An)
Dans la théorie relationnelle, tous les n-uplets doivent être distincts (sinon on ne pourrait les distinguer en tant
qu’éléments d’un ensemble). Une relation a donc au moins un sous-ensemble { A1, A2,… Ak} de l’ensemble des
attributs qui permet d’identifier chacun des n-uplets de la relation (l’ensemble des attributs satisfait cette
condition) : deux éléments de la relation ne peuvent avoir les mêmes valeurs pour tous les attributs de ce sous-
ensemble. S’il est minimal (au sens que, si on retire un des attributs, l’ensemble des attributs restants ne
permettent plus d’identifier les n-uplets de la relation), un tel sous-ensemble d’attribut est appelé une clé
candidate.
Le concepteur choisit une de ces clés candidates comme identifiant privilégié. La clé candidate choisie s’appelle
alors la clé primaire de la relation.
On dira qu’un attribut est non-clé s’il n’appartient à aucune des clés candidates.
Une BD relationnelle est un ensemble de relations de l'utilisateur (relations de table) et de relations de catalogue
(relations système). Le nom d'une relation doit être unique dans l'ensemble des relations de la base, son nombre
de colonnes est fixe, son nombre de lignes quelconque.
Les colonnes sont appelées champ ou attribut. Chaque attribut a un nom unique dans une relation donnée, mais
on peut trouver deux attributs de même nom dans deux relations différentes. L'attribut prend sa valeur dans un
domaine (ensemble des valeurs acceptées). L'ordre des attributs n'a pas d'importance. Le nombre d'attributs
définit le degré de la relation.
Les lignes sont appelées n-uplets (tuples). Les lignes sont supposées toutes différentes, il n'y a pas de doublon
dans une table. L'ordre des lignes n'a pas d'importance, le nombre de n-uplets définit la cardinalité.
Il existe un certain nombre de tables automatiquement gérées par le système (créées par celui-ci), mis à jour par
le SGBD : il s'agit du catalogue. Un utilisateur peut consulter les catalogues (même langage que pour les tables),
mais n'a pas le droit d'écriture.
B. Langages d’interrogation
Principalement trois théories ont donné lieu à différents langages : l’algèbre relationnelle, qui est à la base du
langage SQL, calcul relationnel des tuples, qui a donné lieu au langage QUEL (SGBD "Ingres"), et calcul
relationnel des domaines, à la base du langage QBE (Query By Example) d’IBM
On a pu démontrer qu’ils étaient équivalents dans le sens où ils permettent de désigner les mêmes ensembles de
données.

1) Algèbre relationnelle
Algèbre relationnelle : collection d'opérations formelles qui agissent sur des relations et produisent des relations
en résultat (E.F. Codd).
Les opérations sont classées en deux catégories (Codd) : les opérations de base et les opérations dérivées.
Deux types d'opérations de base : opérations ensemblistes traditionnelles (union, différence et produit cartésien)
et les opérations spécifiques (projection, restriction, jointure).
Les opérations dérivées (intersection, division, complément, éclatement, jointure externe, semi-jointure) peuvent
en général être obtenues par combinaison des opérations de base.
L'union est une opération appliquée à deux relations de même schéma. L'union de deux relations de même
schéma R1 et R2 est la relation R3 ayant pour tuples les tuples de R1 ou ceux de R2. Notation : R1 ∪ R2
La différence est une opération appliquée à deux relations de même schéma. La différence entre deux relations
de même schéma R1 et R2 est la relation R3 ayant pour tuples les tuples de R1 n'appartenant pas à R2. Notation :
R1 − R2. La différence est un opérateur non commutatif.
Le produit cartésien, opération binaire, est la combinaison de deux relations (qui n'ont pas forcément le même
schéma) pour en former une nouvelle qui a tous les attributs des deux relations d'origine. En théorie, les deux
relations ne doivent pas avoir d'attributs en commun. Notation R1 × R2.
La projection (unaire) est une opération spécifique aux relations qui permet de supprimer des attributs d'une
relation, c'est-à-dire sélectionner une ou plusieurs colonnes d'une relation. L'appellation provient du fait qu'on
passe d'une relation n-aire à une relation p-aire, avec p < n (projection d'un espace de dimension n dans un
espace de dimension p). Notation : projY(R), où R est une relation, l'ensemble de ses attributs est X, Y est inclus
dans X.
La restriction (unaire), également appelée sélection, fournit en résultat une relation de même type que la
relation initiale. Le résultat est obtenu en enlevant des tuples à la relation opérande selon un critère de sélection
donné. Notation : R|E, où R est une relation, E est une expression logique.
La jointure (binaire) est la composition de deux relations à l'aide d'un critère de jointure. Elle permet de
calculer, à partir de deux relations R1(X, Y) et R2(Y, Z), une relation R(X,Y,Z) constituée des n-uplets qui sont
combinaison de n-uplets de R1 et de R2 et qui ont même valeur sur l'attribut commun Y. Notation : R1 * R2. Le
θ-produit est défini en remplaçant l'égalité par n'importe quel opérateur de l'ensemble θ.
L'intersection est une opération appliquée à deux relations de même schéma. L'intersection de deux relations de
même schéma R1 et R2 est la relation R3 ayant pour tuples ceux appartenant à la fois à R1 et à R2. Notation :
R1 ∩ R2
La division permet de rechercher dans une relation les sous-tuples complétés par ceux d'une autre relation,
répondant ainsi à des questions de la forme "quel que soit x, trouver y". Notation : R1 ÷ R2.
Le complément d'une relation est l'ensemble des tuples du produit cartésien des domaines d'une relation
n'appartenant pas à cette relation. Les domaines sont supposés finis (sinon on obtient des relations infinies).
Notation : ¬ R
L'éclatement fournit deux relations à partir d'une relation et d'une condition, la première vérifie la relation (=
restriction), la seconde ne la vérifiant pas (= restriction avec l'opposé de la condition).
La jointure externe est une extension de la jointure sans perte d'information (en complétant par des champs nuls
si nécessaire).
La semi-jointure est une jointure sans garder tous les champs des deux relations (= projection du résultat).
– 10 – Bases de données – master GPI – S. Brandel – 2007

2) Propriétés de l'algèbre relationnelle
R0 : Commutativité et Associativité pour le produit cartésien
R×S=S×R
(R × S) × T = R × (S × T)
R1 : Eclatement d'une opération de Sélection – Commutativité des conditions de sélection
Considérons l'opération de sélection R | F où F est une expression de sélection telle que :
F = F1 ∧ F2 ∧ F3 ∧ … ∧ Fk
Eclatement :
R|F = R | (F1 ∧ F2 ∧ F3 ∧ … ∧ Fk)
= (((R | F1) | F2) … | Fk)
Commutativité :
Remarquons que F = F1 ∧ F2 = F2 ∧ F1. D'où
(R | F1) | F2 = (R | F2) | F1
R2 : Regroupement d'une série de projections en une seule opération de projection
Soit U l'ensemble des attributs de la relation R,
Soient X et Y des sous-ensembles de U vérifiant de plus X ⊂ Y.
projX (projY (R)) = projX (R)
R3 : Inversion sélection – projection
Si l'opération de sélection F définie sur les constituants X suit une opération de projection de R sur les
constituants Y, on peut inverser les deux opérations si X ⊂ Y.
projY (R) | F = projY (R | F)
Dans le cas général :
projY (R) | F = projY (projX∪Y (R) | F)
R4 : Inversion sélection – produit cartésien
Si F ne porte que sur des attributs de R :
(R × S) | F = (R | F) × S
Si F = F1 ∧ F2 où F1 n'utilise que des attributs de R et F2 que des attributs de S :
((R × S) | F1 ∧ F2) = ((R | F1) × (S | F2))
Si F = F1 ∧ F2 où F1 n'utilise que des attributs de R mais F2 utilise des attributs des deux relations :
((R × S) | F) = ((R | F1) × S) | F2
R5 : Inversion sélection – union
(R ∪ S) | F) = (R | F) ∪ (S | F)
R6 : Inversion sélection – différence
(R – S) | F = (R | F) – (S | F)
= (R | F) – S
La première solution est plus facile à calculer parce que la relation (S | F) est plus petite que la relation S.
R7 : Inversion projection – produit cartésien
Soit X une liste d'attributs de R, Y une liste d'attributs de S et Z = X ∪ Y. Alors,
projZ (R × S) = projX (R) × projY (S)
Ne marche pas pour la composition.
R8 : Inversion projection – union
projX (R ∪ S) = projX (R) ∪ projX (S)
3) Calcul relationnel
Le calcul relationnel des tuples et le calcul relationnel des domaines reposent sur le calcul des prédicats du
premier ordre. Cette théorie mathématique étudie les formules logiques construites avec un ensemble de
prédicats (c’est-à-dire de propositions qui peuvent être vraies ou fausses dans un certain contexte), les opérateurs
et, ou, négation, implication logique, des variables et les opérateurs ∀ et ∃.
A chaque formule logique correspond l’ensemble des données qui vérifient cette formule. L’interrogation de la
base de données consiste donc à énoncer une formule qui correspond aux données que l’on souhaite extraire de
la base.

La différence essentielle entre le calcul relationnel des tuples et le calcul relationnel des domaines est l’ensemble
dans lequel les variables prennent leurs valeurs :
• tuples : chaque variable prend ses valeurs dans l’ensemble des tuples d’une relation particulière
• domaines : chaque variable prend ses valeurs dans un domaine particulier des attributs de la base.
Opérateurs utilisés :
• prédicats : opérateurs habituels (<, >, ≤, ≥, ≠)
• tuples : on ajoute l’opérateur unaire qui indique qu’une variable prend ses valeurs dans une relation (par
exemple fournisseur (V) indique que la variable V appartient à la relation fournisseur)
• domaines : on ajoute l’opérateur unaire qui indique qu’une variable prend ses valeurs dans un domaine
(par exemple fournisseur(F#.V) indique que la variable V prend ses valeurs dans le domaine de l’attribut
F# de la relation fournisseur)
Exemple :
Nom des fournisseurs (qui fournissent effectivement des pièces) :
tuples : {F.Nom / fournisseur(F) et (∃ R fournit(R) et F.F#= R.F#)}
domaines : {n / ∃ m fournisseur(F# : m, Nom : n) et fournit(F# : m)}
C. Mise en œuvre SQL
1) SQL*Plus
SQL*Plus est interpréteur en ligne de commandes fourni par le SGBD Oracle.
Exécution d’un fichier contenant des requêtes (fichier.sql) : SQL> @fichier
Fin de la saisie dans exécution : insertion d'une ligne blanche
SQL> …
2…
3 <CR>
SQL>
Fin de la saisie avec exécution immédiate :
- point-virgule à la fin de la dernière clause,
- slash : 1er caractère de la dernière ligne du buffer.
Exécution de l'instruction du buffer :
SQL> / ou SQL> RUN
2) Le langage SQL
Le langage SQL, pour Structured Query Language, permet de définir et manipuler des données conformément à
la norme ANSI.
a) Types de données
Chaînes de caractères de longueur fixe (sensible à la casse)
CHAR(size) [BYTE | CHAR] | NCHAR(size) : size facultatif, exprimé en octets ou nombre
de caractères. Max. : 2000 octets pour CHAR, dépendant du jeu de caractère national pour NCHAR,
plafonné à 2000. Min. et Défaut : 1 octet pour CHAR, 1 caractère pour NCHAR.
Chaîne de caractères de longueur variable (sensible à la casse)
VARCHAR2(size) [BYTE | CHAR] | NVARCHAR2(size) : size obligatoire, exprimé en octet
ou nombre de caractères. Max. : 4000 octets pour VARCHAR2, dépendant du jeu de caractère national
pour NVARCHAR2, plafonné à 4000.
LONG : Sans préciser de taille : chaînes de caractères de longueur variable, jusqu'à 2 Go.

Numérique
NUMBER(p,s) : Stockage de nombres positifs ou négatifs dont la magnitude est comprise entre 1.0 x
10-130 et 9.9...9 x 10125 (38 neufs suivis par 88 zéros). p : précision (1 ≤ p ≤ 38), facultatif. s = scale :
nombre de chiffres à droite de la virgule (-84 ≤ p ≤ 127).
NUMBER(p) : équivalent à NUMBER(p,0) (nombres entiers)
NUMBER : nombre réel avec la précision maximale
Date
DATE : toute date valide comprise entre le 1er janvier 4712 av. JC et le 31 décembre 9999 ap. JC,
excluant l'année 0. Format : centenaire + année + mois + jour + heure + min + sec. Type ANSI :
'YYYY-MM-DD'. Type Oracle : 'YY-MON-DD', 'YY-MON-DD:HH24:MI'…
b) Instruction SQL
- insensible à la casse
- instruction sur une ou plusieurs lignes
- ne pas abréger ou couper les mots clés
3) Instruction SELECT simple
a) Requête
SELECT ... (attributs sur lesquels on projette)
FROM ... (relation, ou produit cartésien)
[WHERE ...] (sélection, optionnel)
Projection
SELECT [DISTINCT] { expression [c_alias] | * …]
Expression valide
- [[schema.]table.]attribut exemple : scott.emp.empno
- 'texte' 'travaille à'
- nombre 15
- fonction[(arguments)] UPPER(nom)
- combinaison de ces expressions
Alias pour expression / attribut
- renomme l'entête d'une colonne (affichage ou clause ORDER BY)
- utile si expression calculée
- suit immédiatement l'expression (mot-clé AS facultatif entre attribut et alias)
- à écrire entre guillemets (") si les majuscules et minuscules doivent être différenciées, ou si la chaîne
comporte des espaces ou caractères spéciaux
Produit cartésien
FROM table [t_alias] [, table [t_alias]] …
t_alias : renommage de la table le temps de la requête (Æ raccourci d'écriture)
Restriction
WHERE condition
(clause facultative, si omise, tous les n-uplets sont sélectionnés)

Jointure
SELECT … FROM table1, table2 WHERE table1.attribut1 = table2.attribut2
Préfixer les noms d'attributs si ambiguïté (même nom d'attribut dans plusieurs tables).
Alias indispensable si jointure d'une table sur elle-même :
SELECT E1.nom employé, E2.nom supérieur
FROM Employé E1, Employé E2
WHERE E1.mgr = E2.id
b) Opérateurs
Opérateurs ensemblistes
UNION, INTERSECT, MINUS
Opérateurs arithmétiques (expressions)

+ (unaire), - (unaire), *, /, +, -
Opérateur sur les chaînes (expressions)

|| : concaténation
Opérateurs de comparaison (conditions)

=, >, >=, <, <=, <>
BETWEEN … AND
attributs entre 2 valeurs, bornes incluse
Exemple : … WHERE dpt BETWEEN 20 AND 50 math : 20 ≤ dpt ≤ 50
langage de programmation : 20 <= dpt && dpt <= 50
Exemple : … WHERE nom BETWEEN 'J' AND 'Scott'
IN
test d'appartenance à un ensemble math : variable ∈ { … }
Oracle : attribut IN ( … )
Exemple : … WHERE nom IN ('Adams', 'Smith')
Exemple : … WHERE dpt IN ( SELECT dpt FROM employé WHERE nom = 'Adams')
x [NOT] LIKE y [ ESCAPE z]
x : attribut de type chaîne de caractère Æ correspond à l'expression régulière y
y : contient :
- littéraux : caractères, chiffres
- % : 0 ou plusieurs caractères
- _ (underscore) : 1 et un seul caractère quelconque
Exemple : … WHERE nom LIKE 'Smi%'
Exemple : … WHERE nom LIKE '_A%'
x LIKE '%A\_B%' ESCAPE '\' : recherche des chaînes qui contiennent 'A_B'
Æ échappement d'un des jokers

Valeur NULL
Valeur indéterminée, inconnue.
A différencier de 0, caractère blanc, chaîne vide.
Peut apparaître dans toute colonne sauf CI NOT NULL et PRIMARY KEY.
Une expression arithmétique contenant une valeur NULL est évaluée comme NULL.
Division par O Æ erreur
Division par NULL Æ NULL
Opérateur IS NULL
Teste si la valeur est indéterminée.
Ne pas utiliser le test = NULL : une valeur inconnue ne peut être comparée à une valeur quelconque.
Fonction NVL
Pour convertir une valeur NULL
Concerne les types : caractères, chaînes de caractères, date, données numériques
Compatibilité de type :
S'il y a des valeurs NULL dans la colonne
Exemple : NVL(commission, 0)
commission, elles sont remplacées par des zéros
NVL(embauche,'01-JAN-05')
NVL(job,'sans emploi')
Exemple : SELECT nom, sal, com, (sal*12)+NVL(com,0) …
ANY, SOME
Compare une valeur à chaque valeur d'une liste ou d'une requête imbriquée.
A combiner avec un opérateur de comparaison : θ ANY
en math : ∃
La condition est vraie si elle est vraie pour au moins un élément quelconque de la liste (OU)
Exemple : … WHERE sal = ANY (SELECT sal FROM emp WHERE dpt = 30)
Exemple : … WHERE sal < ANY (SELECT sal …)
Exemple : … WHERE id = ANY(1, 2, 3) Æ toutes les lignes telles que id = 1 ou id = 2 ou id = 3
= ANY : IN
< ANY : inférieur au maximum
> ANY : supérieur au minimum
ALL
Compare une valeur à toutes les valeurs d'une liste ou d'une requête imbriquée.
A combiner avec un opérateur de comparaison : θ ALL
en math : ∀
La condition est vraie si elle est vraie pour tous les éléments de la liste (ET)
Exemple : … WHERE sal = ALL (SELECT sal FROM emp WHERE dpt = 30)
= ALL : n'a aucun sens
<> ANY : NOT IN
< ALL : inférieur au minimum
> ALL : supérieur au maximum

Opérateurs logique (condition)
Par ordre de priorité : NOT, AND, OR
Tables de vérité :
NOT V F NULL AND V F NULL OR V F NULL

F V NULL V V F NULL V V V V
F F F F F V F NULL
NULL NULL F NULL NULL V NULL NULL
c) Exercices employé / participe / projet

Soit la base de données mémorisant les informations au sujet des employés des différents services d'une
entreprise et leur participation aux projets. Chaque employé appartient à un seul service ; on ne mémorisera pas
l'historique de sa carrière. Il participe à un ensemble de projets avec différents rôles. Toutefois au sein d'un
projet, un employé ne peut avoir plusieurs rôles.
Les attributs de la base sont :
nom de l'attribut type descriptif

nS entier numéro de service
nomS chaîne nom de service
nE entier numéro de l'employé
nomE chaîne nom de l'employé
nomR chaîne rôle de l'employé dans un projet
nP entier numéro de projet
nomP chaîne nom de projet
coût réel coût estimé d'un projet, éventuellement NULL
Les relations sont :
Service (nS, nomS) clé : nS
Employé (nE, nomE, nS) clé : nE
Projet (nP, nomP, coût) clé : nP
Participe (nE, nP, nomR) clé : (nE, nP)
avec les contraintes d'intégrité référentielles :
projnS (Employé) ⊆ projnS (Service)
projnE (Participe) ⊆ projnE (Employé)
projnP (Participe) ⊆ projnP (Projet)
Donner les expressions en algèbre relationnelle et en SQL :
1. Liste de tous les triplets (nP, nomP, coût) de tous les projets dont le coût est supérieur à 1M d’Euros.
2. Liste de tous les triplets (nE, nomE, nS) des employés qui travaillent dans le service numéro 1, 5 ou 8.
3. Liste de tous les rôles tenus par les employés.
4. Liste de tous les numéros de projets.
5. Liste de tous les noms et numéros des employés de la société.
6. Nom des employés qui travaillent dans le service numéro 45.
7. Numéros des employés qui travaillent pour le projet 72.
8. Noms des employés qui travaillent pour le projet 98.
9. Noms et numéros de service des employés dont le rôle est "chef de projet" quel que soit le projet
considéré.
10. Noms d'employés et numéros de service pour les employés travaillant dans un projet dont le nom est
"station d'épuration".

11. Noms des employés travaillant dans un projet de coût inférieur à 1M d'Euros.
12. Numéros des employés qui ont le même rôle que celui occupé par l'employé 103 dans le projet 60.
4) Fonctions
On distingue deux types de fonctions : les fonctions single row, et les fonctions multiple row.
Nous verrons ici les fonctions single row (les fonctions multiple row seront vues au paragraphe suivant).
Caractéristiques des fonctions single row :
- appliquée sur chaque ligne renvoyée par la requête
- renvoie un résultat par ligne
- le type de résultat peut être différent de celui sur lequel elle s'applique
- autorisée dans les clauses SELECT, WHERE et ORDER BY
- peut être imbriquée
a) Fonctions numériques
- ABS, MOD, ROUND, TRUNC, SIGN
- CEIL, FLOOR
- COS, SIN, TAN
- COSH, SINH, TANH
- EXP, LN, LOG
- POWER, SQRT
Exemples
SELECT MOD(1600, 300) FROM dual; Æ 100
SELECT ROUND(45.926, 2) FROM dual; Æ 45.93
SELECT ROUND(45.923, -1) FROM dual; Æ 50
SELECT TRUNC(45.926, 2) FROM dual; Æ 45.92
b) Fonctions sur les chaînes de caractères

Chaîne : le premier symbole est un caractère.
Fonctions renvoyant une chaîne
- LOWER : tous les caractères en minuscules.
- UPPER : tous les caractères en majuscules.
- INITCAP : 1er caractère en majuscules, les autres en minuscules.
- CONCAT : équivalent à ||.
- SUBSTR(chaîne, m, [, n]) : extraction sous chaîne (m : position de la sous chaîne, n : longueur de la
sous chaîne).
- …
Exemples
SELECT * FROM Emp WHERE UPPER(nom)='ADAMS';
SELECT UPPER(nom) || ' est ' || LOWER(job) ||
' au département ' || dpt AS "Job des employés"
FROM Emp;
Æ Job des employés
--------------------------------------------------
ADAMS est manager au département 30
...
Fonctions renvoyant un nombre

- INSTR : position d'un caractère donné : INSTR('String', 'r') = 3
- LENGTH : longueur de la chaîne : LENGTH('String') = 6

c) Fonctions sur les dates
Arithmétique
- date +/- number : ajoute / soustrait un nombre de jours à une date ; résultat : une date.
- date1 – date2 : intervalle entre deux dates ; résultat : un nombre de jours.
- date +/- number/24 : ajoute / soustrait un nombre d'heures à une date ; résultat : une date.
Fonctions
- SYSDATE : date et heure courante.
- MONTHS_BETWEEN(d1,d2) : d1-d2 en nombre de mois (résultat réel, positif ou négatif).
- ADD_MONTHS(d,±n) : ajout n mois (entier) à la date d.
- NEXT_DAY(d,'c') : date du 1er jour de la semaine 'c' qui suit d.
- LAST_DAY(d) : date du dernier jour du mois contenu dans d.
- NEW_TIME(d, z1, z2) : changement de fuseaux horaires.
- ROUND(d [,format]) : arrondi.
- TRUNC(d [,format]) : troncature.
d) Conversions
TO_NUMBER TO_DATE
NUMBER CHAR DATE
TO_CHAR TO_CHAR
- TO_CHAR(number | date [, format])

- TO_NUMBER(char)
- TO_DATE(char [, format])
format : format de conversion ; format par défaut pour une date : 'DD-MON-YY'.
Conversion date – char

Format
- YYYY, YYY, YY, Y : année complète ou 3, 2, dernier(s) chiffres
- MM : mois sur 2 chiffres
- MONTH : nom du mois, 9 caractères
- MON : Nom du mois, abrégé sur 3 caractères
- DDD, DD, D : jour dans l'année, le mois ou la semaine
- DAY : nom du jour, 9 caractères
- DY : nom du jour, abrégé sur 3 caractères
- J : calendrier julien
- / . , - : ponctuation reproduite telle quelle
- "of the" : chaîne reproduite telle quelle
Exemples
SELECT SYSDATE "aujourd'hui" FROM Dual; Æ 20-FEB-02
SELECT TO_CHAR(SYSDATE,'DD/MM/YYYY') today FROM Dual; → 20/02/2002

SELECT TO_CHAR(SYSDATE,' "the " DD "of " MONTH, yyyy') today FROM Dual;
→ the 20 of february , 2002
SELECT TO_DATE('12/25/95','MM-DY-YY') FROM Dual; → 25-DEC-95

Conversion char - number
Format
- 9 : Représente un chiffre
- 0 : Zéro à afficher
- $ : met un signe $
- . : Imprime un point décimal
- , : Imprime un indicateur des milliers (mode US)
Exemples
TO_CHAR(1234,'999999') → 1234
TO_CHAR(1234,'099999') → 001234
TO_CHAR(1234,'$999999') → $1234
TO_CHAR(1234,'999999.99') → 1234.00
TO_CHAR(1234,'999,999') → 1,234
5) Compléments au SELECT
SELECT attribut, group_function(attribut)
FROM table
[ WHERE condition ]
[ GROUP BY group_by_expression ]
[ HAVING group_condition ]
[ ORDER BY attribut]
a) Ordonnancement
ORDER BY {attribut | expression | c_alias} [ASC | DESC]
Spécifie l'ordre d'affichage du résultat.
Cette instruction vient forcément en fin de requête.
Exemple
SELECT * FROM Emp ORDER BY nom, job;
b) Fonctions d'agrégation
Nous utiliserons ici les fonctions multiple row, encore appelées fonctions de groupe ou fonctions d'agrégation
(multiple row functions ou group functions sont des appellations Oracle).
Ces fonctions sont :
- autorisée dans les clauses SELECT, HAVING
- non autorisée dans la clause WHERE
Fonctions sur des données numériques :
- AVG : moyenne
- STDDEV : déviation standard
- SUM : somme
- VARIANCE : variance
Fonctions avec des données quelconques :
- COUNT : cardinal
- MAX : maximum
- MIN : minimum

COUNT( { * | [DISTINCT ] expression } )
- COUNT(*) : toutes les lignes, y compris les valeurs NULL et les doublons
- COUNT(expression) : toutes les lignes pour lesquelles expression est différent de NULL, doublons non
éliminés
- COUNT(DISTINCT expression) : toutes les lignes pour lesquelles expression est différent de NULL,
doublons éliminés (comptabilisés une seule fois)
Exemples
SELECT COUNT(*)FROM Emp;
SELECT MAX(id) FROM Emp;
SELECT AVG(salaire) FROM Emp;
SELECT COUNT(*)FROM Emp WHERE job='manager';
c) GROUP BY
Dans les exemples précédents il y avait un seul groupe :
- la relation toute entière
- une sous relation (clause WHERE)
Æ Réponse avec un seul n-uplet.
Il est possible de manipuler plusieurs groupes dans une même requête : clause GROUP BY
Æ Réponse avec autant de n-uplets qu'il y a de groupes.
Exemple Emp id nom job mgr dpt
18 Smith Directeur --- 30
26 Adams Vendeur 18 30
27 Scott Monteur 35 20
32 Miller Caissier 35 10
35 Ryan Directeur --- 10
Emp GROUP BY dpt Æ 3 groupes (G1 : lignes 1 et 2, G2 : ligne 3, G3 : lignes 4 et 5)

Emp GROUP BY job Æ 4 groupes (G1 : lignes 1 et 5, G2 ; ligne 2, G3 : ligne 3, G4 : ligne 4)
SELECT COUNT(*) card card SELECT dpt, COUNT(*) card card dpt
FROM Emp FROM Emp
GROUP BY dpt; 2 GROUP BY dpt; 2 30
1 1 20
2 2 10
Règles du GROUP BY
Les expressions de la clause GROUP BY ne sont pas impérativement dans la clause SELECT (cf. exemple
précédent)
La clause GROUP BY peut comporter plusieurs expressions séparées par des virgules :
Exemple : ... GROUP BY mgr, dpt
Restriction clause SELECT : SELECT suivi uniquement de :

- expressions de la clause GROUP BY
- appels à des fonctions d'agrégation
Exemple
SELECT nom, count(*) nbre INTERDIT ! (c'est nom qui pose problème)
FROM Emp
GROUP BY dpt;

Inversement : clause SELECT suivie d'une combinaison :
- expressions (nom d'attributs) et
- appels à des fonctions d'agrégation
Æ clause GROUP BY obligatoire
Exemple
SELECT nom, count(*) nbre INTERDIT !
FROM Emp;
Restrictions pour les groupes : clause HAVING

Exemple
SELECT deptno, AVG(sal)
FROM Emp INTERDIT !
WHERE AVG(sal) > 2000
GROUP BY deptno;
SELECT deptno, AVG(sal)
FROM Emp
GROUP BY deptno
HAVING AVG(sal) > 2000;
Ordre d'exécution
1. WHERE : sélection des n-uplets
2. GROUP BY: calcul des groupes
3. HAVING : calcul des fonctions d'agrégation, élimination des groupes qui ne remplissent pas la
condition
4. ORDER BY : tri
Æ Affichage
Exemples
Appels imbriqués de fonctions
SELECT MAX(AVG(sal))
FROM Emp
GROUP BY deptno;
Clause HAVING et requêtes imbriquées

SELECT deptno, MIN(sal)
FROM Emp
GROUP BY deptno
HAVING MIN(sal) > (SELECT MIN(sal)
FROM Emp
WHERE deptno=20);

II. Le modèle Entités / Associations
Modèle plus intuitif que le modèle relationnel, le modèle E/A est à la base de MERISE. Les concepts sont
voisins, le passage de l'un à l'autre est immédiat.
A. Eléments du modèle
1) Entité
Une entité est un objet concret ou abstrait qui peut être distinctement identifié dans l'esprit du concepteur et qui
présente un intérêt particulier. En général, une entité représente le nom dans une phrase.
Représentation graphique :
<nom-classe>
2) Association
Une association est une relation entre une ou plusieurs entités. L'association représente généralement le verbe
d'une phrase.
Représentation graphique : il en existe de nombreuses, il faut en choisir une.
classe d'ass. classe d'ass. classe d'ass. classe d'ass.
Un type d'association ne peut pas être directement relié avec un autre type d'association.
Un type d'entité de peut être relié à un autre type d'entité que par un lien d'association.
Il n'y a pas de restriction sur le nombre de types d'associations entre types d'entités.
Une occurrence d'association associe plusieurs entités : une et une seule entité par classe d'entités intervenant
dans le type d'association.
3) Cardinalités et fonctionnalités
Cardinalité min et max reportées sur le graphique :
a,b c,d
Personne Possède Voiture
a = nombre min d'occurrences de B liées à l'occurrence de A par A - B (∈ {0,1})

b = nombre max d'occurrences de B liées à l'occurrence de A par A - B (∈ {1,n})
c = nombre min d'occurrences de A liées à l'occurrence de B par A - B (∈ {0,1})
d = nombre max d'occurrences de A liées à l'occurrence de B par A - B (∈ {1,n})
Cardinalité : couple (a,b) ou (c,d). 4 alternatives pour les deux couples (a,b) et (c,d) :
• 0,1
• 0,n
• 1,1
• 1,n
Pas d'autre choix possible.
Fonctionnalité : couple (b,d). 3 alternatives :
• 1x1
• 1xn
• n x m (= n x n car les deux n peuvent être différents, il s'agit du max des 2 cardinalités)

Concept de dimension (ou ordre ou degré) du type d'association : c'est le nombre de types d'entités distinctes qui
interviennent dans le type d'association.
4) Attribut
Un attribut est la propriété d'un type d'entité ou d'association. Une propriété a une valeur.
Exemple :
Personne Personne
id - id
nom Autre notation :
- nom
âge - âge
adresse - adresse
Les attributs prennent obligatoirement des valeurs simples, (pas de structure, pas d'ensemble). Les valeurs
peuvent être définies facultatives ou obligatoires.
Les attributs peuvent être : des identifiants (clés, soulignés dans la représentation graphique), ou des descripteurs
(tous les autres).
Les attributs du type d'association regroupent les clés de chacun des types d'entités de l'association + des attributs
propres à l'association :
Fournisseur Produit
0,n 0,n
Id-fourn Ligne catalogue Id-produit
Nom Désignation
Prix
Clé de l'association : a priori, elle est constituée de toutes les clés de l'ensemble des clés des entités qui
interviennent dans l'association :
5) Passage du modèle E/A au modèle relationnel

Une entité Æ une relation
Une association Æ soit intégrée dans une relation existante (card max 1)
soit donne lieu a une nouvelle relation
Exemple étudiant
ETUDIANT <net, nom, âge, adresse>

PRIX <âge, tarif>
ENSEIGNEMENT <matière, enseignant>
NOTE <net, matière, moyenne>

Passage du modèle relationnel au modèle E/A :
Etudiant Enseignement
0,n 0,n
net Note Matière
Nom Enseignant
Adresse
1,1
Agé de
0,n Tarif
1,1 0,n
Année Détermine Id-tarif
Age
Ou encore :
Etudiant Enseignement
0,n 0,n
net Note Matière
Nom Enseignant
Adresse
1,1
Prix
0,n
Paie Age
Tarif
B. Concepts complémentaires
1) Agrégation
Homme Marié à Femme
Problème
Comment exprimer que le couple possède un logement ? Il faudrait relier deux classes d'associations entre elles
("Marié à" et "Possède"), ce qui est interdit dans le modèle entités – associations.
D'où l'agrégation :
Homme Marié à Femme

Couple
0, n
Possède Une occurrence de "Couple" = une occurrence de "Marié à"

0, 1
Logement
L'agrégation permet de contourner l'interdiction d'avoir deux classes d'associations directement reliées.

Dans un agrégat, une classe d'association est vue comme une classe d'entités mais n'a pas le droit de posséder des
attributs propres.
2) Généralisation / spécialisation
♦ Généralisation : regrouper les différents types d'entité en faisant abstraction de leurs différences.
Æ type générique (mise en facteur des attributs communs).
♦ Spécialisation : pour un type donné, on définit des sous-types en mettant en évidence leurs particularités.
Exemple :
Personne
Personne
id
id nom
nom
sexe
Homme Femme
service militaire nom jeune fille Homme Femme
service militaire nom jeune fille
Il y a héritage des attributs du type générique :
Exemple : Homme < id, nom, service militaire > (id et nom proviennent de Personne).
♦ Dans ce modèle, il n'y a plus de raison d'admettre des attributs à valeur nulle.
♦ Il peut y avoir N niveaux d'abstraction : Véhicule
Terrestre Aérien
Diesel Essence
Atmosphérique Compressé Carburation Injection
Sur N critères :
Personne
Homme Femme Majeur Mineur
Association à tous les niveaux : Employé Travaille
Programmeur Chef de projet Secrétaire
Dirige Dispose Voiture
Berline Monospace

3) Contraintes d'intégrité
Intégration d'informations supplémentaires dans le modèle E/A :
- partition (+) : disjonction + couverture (l'un ou l'autre mais pas les deux) (pas autre chose)
- totalité (T) : ¬ disjonction + couverture (l'un ou l'autre ou les deux) (pas autre chose)
- exclusion (×) : disjonction + ¬ couverture (l'un ou l'autre mais pas les deux) (autre chose)
Fait appel aux notions de :
- Couverture : ensemble recouvrant tous les éléments.
- Disjonction : pas d'éléments commun à deux sous-ensembles.
Représentation graphique
Partition : +
Totalité : T
Exclusion : ×
Exemple (partition entre type et sous-type)
Personne
Homme Femme
Personne Homme Femme

Couverture : Personne = Homme OU Femme (et pas autre chose)
Exemple (totalité entre type et sous-type) Personne
id-pers
nom
Chanteur Musicien
Personne Chanteur Musicien voix instrument
Exemple (exclusion pour une association)

0, n
0, n Etudiant Université
Personne ×
0, n 0, n
Salarié Entreprise
Une personne ne peut pas être à la fois étudiant dans une (ou plusieurs) université(s) et salarié dans une (ou
plusieurs) entreprises.
Certaines personnes ne sont ni l'un ni l'autre.
0, n Etudiant 0, n
Personne × Cours
0, n
Enseignant 0, n
Une personne ne peut pas être à la fois étudiant et enseignant dans le même cours.

Autres contraintes
- Inclusion (|)
- Egalité (=)
- Unicité (1) : autre notation pour une DF
Exemple (contrainte d'inclusion)
0, n Membre 1, n
Personne | Association
0, n
Président 1, 1
Le président d'une association est choisi parmi les membres de cette association.
Exemple (contrainte d'unicité)
Personne Date
0, n 0, n
1 Occupe
0, n
Fonction
Une personne à une date donnée ne peut occuper qu'une et une seule fonction.
4) Généralisation : passage au modèle relationnel

Personne Oeuvre
id-pers Interprète id-oeuvre
0, n 0, n
nom auteur
Cours
Chanteur Musicien
Donne id-cours
voix instrument 0, n 1, 1
intitulé

C. Conclusion
1) Limites du modèle E/A

Le modèle E/A est un modèle de données et non de traitement, qui ne permet pas de prendre en compte l’aspect
dynamique des données, les modalités de déclenchement d'une opération ainsi que la façon dont la modification
est réalisée.
2) Inconvénients du modèle E/A

Le concepteur éprouve des difficultés à faire des choix parce qu'il ne discerne pas toujours les conséquences des
décisions prises. Il y souvent des ambiguïtés entre entité et attribut, ce qui pousse parfois à devoir créer des types
d'entités artificiels. Enfin il manque d’un support formel pour contrôler la qualité du schéma.
3) Avantages du modèle E/A

L’approche paraît plus naturelle : obtention directe de résultats de synthèse, simplicité du support graphique,
outil de communication efficace, la représentation graphique est accessible à tous les intéressés, qu’il s’agisse
des utilisateurs finaux, des partenaires du processus de conception ou des informaticiens responsables de la mise
en œuvre technique.

Chapitre 3 : Les Schémas
I. Le schéma conceptuel
A. Dépendances fonctionnelles
Tout est construit à partir des Dépendances fonctionnelles (DF), qui sont des contraintes d'intégrité très fortes. Le
traitement sera différent suivant qu'il y a une ou plusieurs réponses à la question posée.
1) Définition
Soit R une relation dont les attributs sont U = {u1, u2, ..., un} et X ⊂ U, Y ⊂ U. On dit que dans la relation, Y
dépend fonctionnellement de X, ou X détermine Y, si :
∀ u ∈ R, ∀ v ∈ R, projX (R | u) = projX (R | v) ⇒ projY (R | u) = projY (R | v).
Plus simplement, un attribut Y dépend fonctionnellement d'un attribut X si, étant donnée une valeur de X, il lui
correspond une valeur unique de Y (quel que soit le n-uplet considéré).
Notation : X → Y
2) Règles d'inférence
Notation : ├. Il est généralement possible de déduire de nouvelles DF à partir des DF existantes. Les trois
premières règles sont les axiomes d'Armstrong (1974), les trois suivantes en sont déduites.
Notons X, Y, Z et W des sous-ensembles d'attributs de la relation R.
Réflexivité. Tout ensemble d'attributs détermine lui-même ou une partie de lui-même.
Y⊆X├X→Y
Augmentation. Si X détermine Y, les deux ensembles d'attributs peuvent être enrichis par un troisième.
X →Y ├ X, Z → Y, Z
Z ⊆ W et X → Y ├ X, W → Y, Z
Transitivité. Le composé de deux fonctions dont l'image de l'une est le domaine de l'autre, est une fonction.
X → Y et Y → Z ├ X → Z
Union.
X → Y et X → Z ├ X → Y, Z
Pseudo-transitivité.
X → Y et Y, W → Z ├ X, W → Z
Décomposition.
X → Y et Z ⊆ Y ├ X → Z (parce que Z ⊆ Y ├ Y → Z)
3) Manipulation des DF
a) Fermeture
Soit F un ensemble de DF. Il est possible de composer par les règles d'inférence les DF de F. La fermeture
transitive de F, notée F+, est l'ensemble de toutes les DF résultant de l'application des règles d'inférence sur les
DF de F.
L'application d'une règle d'inférence construit F1 à partir de F, puis F2, ..., puis Fn. On s'arrête lorsque Fn+1 = Fn, et
donc F+ = Fn (= Fn+1).

Deux ensembles de DF F1 et F2 sont équivalents s'ils ont la même fermeture, c'est-à-dire F1+ = F2+
F1 ⇒ F2 F1+ ⊇ F2+
F2 ⇒ F1 F2+ ⊇ F1+
b) Couverture
Il est intéressant de déterminer un sous-ensemble minimal de DF permettant de générer toutes les autres : c'est la
couverture minimale d'un ensemble de DF. Le calcul de la couverture permet de faire baisser le nombre de
vérifications qui sont à faire.
La couverture minimale de F est l'ensemble F0 tel que : F0+ = F+.
Notation : ^F
c) DF élémentaires
Une DF X → Y est pleine ou élémentaire s'il n'existe pas de sous-ensemble strict X' de X (X' ⊂ X et X' ≠ X) tel
que X' → X.
On dira que Y est pleinement dépendant de X.
d) Clé de relation
Il est possible de donner une définition formelle de la notion de clé à partir des DF : une clé est un ensemble
minimal d'attributs qui détermine tous les autres.
Autrement dit, X est un clé (ou un identifiant) de la relation R si X → U est une DF élémentaire.
Un ensemble d'attributs qui inclut une clé est appelé superclé.
Il peut y avoir plusieurs clés pour une relation, mais on en choisit une comme clé primaire.
Notation : <Numéro, Nom> (la clé est Numéro).
Lorsque deux attributs forment la DF élémentaire : <Num1, Num2, Nom> (la clé est le couple). La notation
<Num1, Num2, Nom> est identique.
4) Passage DF - schéma relationnel

Une base de données sur les gîtes d'une région donnée comporte les attributs et les hypothèses suivants :
nom de l'attribut type descriptif

nom chaîne nom de l'hôtel (unique dans une région donnée)
catégorie entier nombre d'étoiles de l'hôtel
nb-chambres entier nombre total de chambres pour un hôtel donné
num-chambre entier numéro de chambre
type entier type de chambre
prix réel prix d'une chambre
nbre-lits entier nombre de lits
douche booléen vrai si la chambre comporte une douche privée
baignoire booléen vrai si la chambre comporte une baignoire privée
lib-div chaîne libellé des divertissements proposés par l'hôtel
gratuit booléen indique si un divertissement proposé par un hôtel est gratuit ou payant
saison {'H','B'} H : haute saison, B : basse saison

Le type de chambre détermine les commodités offertes : nombre de lits, présence de douche, de baignoire
indépendantes. Le prix d'une chambre dépend du type de la chambre. Ainsi, dans un hôtel donné, toutes les
chambres de même type auront le même prix. Cette hypothèse n'est pas vraie pour deux hôtels différents. Le prix
d'une chambre dépend également de la saison : haute ou basse.
Les dépendances fonctionnelles vous semblent-elles correctes ?
1. nom → catégorie, nb-chambres
2. num-chambre → type
3. type → prix
4. type → nbre-lits
5. type, prix → douche, baignoire
6. nom, catégorie → nb-chambres
7. nom, num-chambre →type, douche, baignoire
8. nom, gratuit → lib-div
9. catégorie, lib-div → gratuit
10. nom, saison, type → nbre-lits
B. Normalisation de relation
On part de deux ensembles : une relation universelle (relation unique qui contient tous les attributs de
l'application), et l'ensemble F des DF sous forme minimale.
On décompose la relation universelle en utilisant F pour obtenir un ensemble de relations pour une certaine
forme normale (FN) choisie à l'avance : 1ère, 2ème, 3ème, 3.5ème (forme normale de Boyce Codd), 4ème et 5ème.
Les trois premières FN ont été définies par Codd (1972).
• 1FN : la plus simple, évite les domaines composés de plusieurs valeurs.
• 2FN : beaucoup de redondances Æ coût élevé de MAJ.
• 3FN : peu de redondances Æ coût faible de MAJ, mais beaucoup de jointures.
Sur l'exemple employés < matricule, nom, dpt, nom-dpt > avec la DF dpt → nom-dpt, il y a des anomalies lors
de modifications des données :
• Anomalies d'insertion : on ne peut pas ajouter de nouveaux départements (numéro et nom) si le
département ne comporte pas d'employé.
• Anomalies de modification : si on change le nom d'un département, on doit le changer dans toutes les
lignes des employés de ce département.
• Anomalies de suppression : si on supprime le dernier employé d'un département, on perd l'information
(numéro et nom) du département.
D'où la nécessité de découper les tables en formes normales.
1) 1ère forme normale (1FN)

Justifiée par la simplicité et l'esthétique, la 1FN consiste à éviter les domaines constitués de plusieurs valeurs.
On dit qu'une relation est en 1FN si tous ses attributs sont de types élémentaires : char, string, int, float.
Les attributs de type structure, ensemble et liste sont interdits. Si on a besoin d'une structure, soit on la met à
plat, soit on crée une nouvelle relation.
2) 2ème forme normale (2FN)

La 2FN permet d'éliminer certaines redondances en assurant qu'aucun attribut n'est déterminé par une partie
seulement de la clé.
Une relation est en 2FN si et seulement si :
• elle est en 1FN
• les attributs qui ne sont pas clé sont pleinement dépendants de chaque clé.

Exemple typique de relation NON en 2FN :
R: X Y Z W
La clé est le couple X, Y. Donc X, Y → Z, W. Or Y détermine à lui seul W : Y → W. Donc W dépend d'une
partie de la clé. Il faut donc décomposer R en : R1 <X, Y, Z> et R2 <Y, W>.

La 3FN permet d'assurer l'élimination des redondances dues aux dépendances transitives.
Une relation est en 3FN si et seulement si :
• Elle est en 2FN.
• Tout attribut n'appartenant pas à une clé ne dépend pas d'un autre attribut non clé. Autrement dit, tous les
attributs n'appartenant à aucune clé sont directement et non transitivement dépendants d'une clé.
Exemple typique de relation NON en 3FN :
R: X Y Z W
La clé de la relation est X. Donc X → Y, Z, W. Or Y détermine à lui seul W : Y → W. Donc W dépend d'un
attribut non clé. Il faut donc décomposer R en : R1 <X, Y, Z> et R2 <Y, W>.
4) Arrêt de la décomposition
On arrête la décomposition lorsque la FN souhaitée est obtenue.
5) Forme normale de Boyce-Codd

La 2FN élimine les anomalies créées par des DF entre parties de clé et attribut non clé.
La 3FN élimine les anomalies créées par des DF entre les attributs non clés.
Et les DF de parties de clés entre elles ou d'attributs non clé vers une partie de clé ?
Æ 3FN insuffisante Î FNBC.
Une relation est en FNBC si et seulement si les seules DF élémentaires sont celles dans lesquelles une clé entière
détermine un attribut.
En clair, pas de DF autres que K → A, K étant la clé et A un attribut non clé.
Exemple typique de relation NON en FNBC :
R: X Y Z W
La clé est le couple X, Y. Donc X → Z, W. Or W détermine X : W → X. Donc une partie de la clé dépend d'un
attribut non clé. Il faut donc décomposer R en : R1 <X, Y, Z> et R2 <W, X>.

Utilisation des dépendances multivaluées (DM, notées X →→ Y), pour supprimer certaines redondances.
Exemple : base étudiant
Soit la relation :
net matière sport

1 BD escalade
1 BD tennis
1 Algo escalade
1 Algo tennis
2 Algo VTT
clé : net, cours, sport

Il est possible de suivre plusieurs matières et de pratiquer plusieurs sports. Les redondances apparaissent
clairement, mais il n'est pas possible de décomposer parce qu'il n'y a pas de DF le permettant. On utilise pour
cela les dépendances multivaluées : indépendance entre deux ensembles d'attributs corrélés par un troisième.
La 4FN est obtenue en décomposant la relation à partir des DM.
DM : { net →→ matière
net →→ sport }
COURS <net, cours>
La relation est décomposée en : SPORT <net, sport>

Utilisation des dépendances de jointure (DJ), pour supprimer certaines redondances.
Exemple : base vins
buveur cru producteur

Meyer Edel Claude
Meyer Edel André
Meyer Gewurtz André
Brandel Edel André
En 4FN parce qu'il n'existe pas de DM (par exemple buveur →→ cru est faux parce qu'il n'existe pas le tuple
(Meyer, Gewurtz, Claude)).
Il reste encore des redondances : on apprend deux fois que Meyer boit de l'Edel et que André produit de l'Edel.
Mais il est impossible de décomposer de deux relations.
Les DM permettent de décomposer une relation en deux, les DJ permettent de décomposer une relation en N
relations.
On obtient alors le schéma :
buveur cru buveur producteur cru producteur
Meyer Edel Meyer Claude Edel Claude
Meyer Gewurtz Meyer André Edel André
Brandel Edel Brandel André Gewurtz André
En 5FN.

C. Perte de données et de dépendances
Les pertes de données ou de dépendances peuvent survenir lors des décompositions des relations.
Une décomposition en plusieurs relations est dite sans perte de données si la jointure des relations obtenues
dans la décomposition redonne la relation de départ (c'est à dire sans données manquantes ou superflues). Il faut
évidemment ne jamais faire de décomposition avec pertes de données car les informations contenues dans la
base sont alors fausses et il est impossible de rétablir les bonnes données.
Soit une relation R(A,B,C), où A, B, C sont des ensembles d'attributs disjoints, avec la DF B → C. On peut
démontrer que la décomposition de R en R1(A,B) et R2(B,C) est sans perte de données.
Exemple.
EMPLOYE <matr, nom-emp, salaire, dpt, nom-dpt>
DF = { matr → nom-dpt,
dpt → nom-dpt }
Cette relation peut être décomposée en :
EMP <matr, nom-emp, salaire>

DPT <dpt, nom-dpt, salaire>
mais c'est une décomposition avec perte de données (qui est ici un surplus de données parasites) car la jointure
de ces deux relations donne plus de n-uplets que la relation de départ si plusieurs employés ont le même salaire.
Ceci est dû au fait que l'attribut commun (salaire) n'est pas source d'une DF vers les autres attributs des deux
relations de la décomposition.
Une décomposition sans perte de données est par exemple :
EMP <matr, nom-emp, salaire, dpt>

DPT <dpt, nom-dpt>
dans laquelle l'attribut commun (dpt) est la source de la DF dpt → nom-dpt, et donc on n'a pas de perte de
données.
Soit une relation R décomposée en deux relations R1 et R2. La projection de l'ensemble des dépendances de R
sur la relation R1 s'obtient en ne gardant des dépendances de départ de R que celles dont les attributs (de la
source et du but) sont des attributs de la relation R1.
Une décomposition en plusieurs relations est dite sans perte de dépendances si on peut retrouver logiquement
(par exemple par transitivité) les dépendances de départ à partir de la projection de l'ensemble des dépendances
de départ sur les relations de la décomposition.
Si on décompose une relation en plusieurs relations avec perte de dépendances, one ne peut travailler
indépendamment dans chacune des relations de la décomposition sans s'occuper des autres relations. Lors des
mises à jour, on ne peut en effet s'assurer que les dépendances perdues sont vérifiées qu'en consultant les autres
relations, ce qui peut s'avérer coûteux.
Lorsqu'on a le choix entre plusieurs décompositions, il faut évidemment choisir celles qui préservent les
dépendances. Mais une perte de données est plus grave qu'une perte de dépendance et il peut arriver qu'il faut
choisir entre une perte de dépendance et une perte de normalisation. En effet, on peut démontrer qu'il est toujours
possible de normaliser un schéma en 3FN sans perte de données et de dépendances. Mais il n'est pas toujours
possible de conserver les dépendances si on veut normaliser un schéma avec uniquement des relations en FNBC,
4FN ou 5FN.

Exemple.
EMP <matr, nom-emp, poste, date-emb, salaire, commission, dpt>

DPT <dpt, nom-dpt, lieu>
PROJET <code-pr, nom-pr>
PARTICIPE <matr, code-pr, fonction>
On veut ajouter la règle "deus personnes d'un même département ne peuvent participer à un même projet". Cette
règle de gestion implique la DF dpt, code-pr →matr. Pour tenir compte de la nouvelle règle, le schéma devient :
EMP <matr, nom-emp, poste, date-emb, salaire, commission, dpt>
DPT <dpt, nom-dpt, lieu>
PROJET <code-pr, nom-pr>
PARTICIPE2 <dpt, code-pr, matr, fonction>
On ne peut enlever l'attribut dpt de la relation EMP malgré son ajout dans PARTICIPE2, car on perdrait le
département des employés qui ne participent à aucun projet.
La relation PARTICIPE2 est en 3FN mais elle n'est pas en FNBC à cause de la DF matr → dpt. Pour obtenir un
schéma en FNBC, une solution est de décomposer PARTICIPE2 en R1 < code-pr, matr, fonction >, et
R2 < matr, dpt >. R2 est redondante avec EMP, et R1 n'est autre que PARTICIPE. On se retrouve ainsi avec le
schéma initial. Cette décomposition est sans perte de données comme on peut le vérifier aisément (il est évident
que l'on retrouve exactement la relation PARTICIPE2 à partir de R1 et R2 grâce à la DF matr → dpt), mais pas
sans perte de dépendance : la projection des dépendances ne contient que les DF matr → dpt et
code-pr, matr → fonction, on ne peut en déduire la dépendance dpt, code-pr → matr.
Cette perte de dépendance est due au fait que l'on ne peut pas vérifier la nouvelle règle de gestion en travaillant
seulement sur une des relations. On est obligé de refaire une jointure (même partielle) des deux trables
PARTICIPE2 et EMP pour vérifier la contrainte, par exemple, si on veut changer un employé de projet, ou
ajouter un nouvel employé.
Il faut donc faire un choix entre la perte de dépendance si l'on éclate la relation en deux relations en FNBC et les
problèmes éventuels dus au fait que la relation PARTICIPE2 n'est pas en FNBC. Par exemple, si on travaille
avec PARTICIPE2, et si un employé qui participe à plusieurs projets change de département, il faudra changer le
département dans toutes les lignes de PARTICIPE2 qui concernent cet employé.
La relation PARTICIPE2 est un exemple de relation "atomique" qui ne peut être décomposée sans perte de
dépendance.
D. Mise en œuvre SQL
1) Définition des données

Schéma conceptuel :
- CREATE TABLE : création d'une relation,
- ALTER TABLE : modification de la structure d'une relation,
- DROP TABLE : suppression de la relation (lignes comprises),
- RENAME : renommage d'une relation existante.
a) Création de tables
Syntaxe
CREATE TABLE nom-table (colonne [, colonne…] [, contrainte-de-relation] [, contrainte-de-relation…])
colonne = nom-col type-de-données [défaut] [contrainte-de-colonne]

nom-table, nom-col :
- chaîne de caractères (donc doit commencer par une lettre) simple (par exemple etudiant), ou composé
(un nom de schéma suivi d'un nom de table, par exemple crous.etudiant),
- longueur : de 1 à 30 caractères,
- doit uniquement comporter les caractères A-Z, a-z, 0-9, _, $, # (ces trois derniers déconseillés),
- ne doit pas être le nom d'un autre objet propriété du même utilisateur, ou un mot réservé Oracle.
type-de-données : chaîne de caractère de longueur fixe ou variable, numérique, date (déjà vu)
défaut : DEFAULT val
val est la valeur fournie à l'attribut lorsque l'utilisateur n'en fournit pas dans l'instruction INSERT.
val peut être :
- littéral
- expression
- fonction SQL
Restriction :
- cohérence de type
- ne peut pas contenir de référence à une autre colonne
- ne peut pas contenir de date non complètement spécifiée
contrainte-de-colonne : CI et CI-réf portant sur un seul attribut.
[ CONSTRAINT contrainte ]
{ [ NOT ] NULL
| UNIQUE
| PRIMARY KEY
| REFERENCES [schéma.] nom-table [(nom-col)] [ ON DELETE CASCADE ]
| CHECK (condition)
} [DISABLE]
contrainte-de-relation : CI et CI-réf portant sur une ou plusieurs colonnes.
[ CONSTRAINT contrainte ]
{ UNIQUE ( nom-col [, nom-col…] )
| PRIMARY KEY (nom-col [, nom-col…] )
| FOREIGN KEY (nom-col [, nom-col…] )
REFERENCES [schéma.] nom-table [ (nom-col [, nom-col…] )]
[ ON DELETE CASCADE ]
| CHECK (condition)
} [DISABLE]
Contraintes
Définies lors de la création de la table ou modification ultérieure de la table.
Possèdent un nom unique donné par l'utilisateur ou généré automatiquement par Oracle (SYS_Cn).
NOT NULL : valeur NULL impossible
- uniquement en contrainte de colonne
PRIMARY KEY : attribut(s) constituant la clé primaire
- la valeur NULL n'est pas autorisée sur les attributs de la clé primaire, il est donc inutile de rajouter la
contrainte NOT NULL
- une seule clé primaire est autorisée par table (v7 et v8)
- création d'un index
- si plusieurs clé primaires pour une même relation : 1ère clé : PRIMARY KEY, autres clés : UNIQUE
- si plusieurs attributs, alors obligatoirement contrainte de relation
UNIQUE : attribut(s) dont la valeur est unique pour toute la table
- NULL est autorisé sauf si on précise le contraire (contrainte NOT NULL explicitement demandée)
- si la valeur NULL est autorisée, plusieurs lignes peuvent avoir la valeur NULL sur cet attribut (unicité
pour le NULL non vérifiée)
- création d'un index

FOREIGN KEY : attribut(s) constituant une clé étrangère
- NULL accepté
- REFERENCES : la précision d'attributs est optionnelle si identique aux attributs référencées
CHECK (condition) : la condition peut être vérifiée avec
- nom-col θ val, θ ∈ {=, <>, <, <=, >, >=}
- prédicat d'intervalle : BETWEEN … AND …
- prédicat de comparaison de texte : LIKE
- test de nullité : NULL
- test d'appartenance : IN
- interdit : référence à des pseudo colonnes (CURRVAL, NEXTVAL, …), appel à certaines fonctions
(SYSDATE, …), requêtes à des valeurs d'autres lignes
Activation des contraintes
ENABLE : contrainte active (par défaut), toutes les données doivent la vérifier
DISABLE : contrainte inactive
Il est possible de préciser le statut d'une contrainte :
- lors de la création de la contrainte
- avec une clause ENABLE CONSTRAINT contrainte ou DISABLE CONSTRAINT contrainte, auquel
cas il faut connaître le nom de la contrainte, nom qu'on trouve dans le dictionnaire
(USER_CONSTRAINTS)
Création et insertion immédiate
CREATE TABLE nom-table [ (nom-col [défaut] [contrainte-de-colonne]
[, nom-col [défaut] [contrainte-de-colonne] …] ) ]
AS subquery
Nouvelle relation crée avec :
- nom des attributs donnés et les lignes issus de la requête SELECT
- la définition des attributs peut ne comporter que le nom et la valeur par défaut
- si la spécification des attributs est donnée, il doit y avoir le même nombre de colonnes que de colonnes
issues de la sous-requête
- si aucune spécification d'attribut n'est donnée, les noms des attributs sont identiques à ceux issus de la
sous-requête.
- le nom et le type sont récupérés, aucune CI n'est recopiée donc pas la contrainte d'attribut clé
Exemple
CREATE TABLE Prix ( age NUMBER (2) PRIMARY KEY,
tarif CHAR (2) DEFAULT 'T1',
CHECK (age > 25) ) ;
CREATE TABLE Etudiant ( net NUMBER (2),
facultatif
nom VAR CHAR 2 (30),
age NUMBER (2) REFERENCES prix.age,
adresse VAR CHAR 2 (60),
PRIMARY KEY (net), ou
FOREIGN KEY (age) REFERENCES prix.age) ;
b) Modification de tables
Modifications autorisées :
- ajouter un attribut : on ne peut pas spécifier l'endroit où doit apparaître la colonne, elle sera
impérativement en dernière position ; si la relation est non vide lors de l'ajout d'un nouvel attribut, la
valeur de la nouvelle colonne est initialement NULL pour toutes les lignes existantes, même si on
définit une valeur par défaut

- redéfinir un attribut (type, taille, valeur par défaut) ; la modification de la valeur par défaut ne
concernera que les insertions futures
- ajouter / supprimer une CI
- activer / désactiver une CI
- modifier les caractéristiques de stockage
Impossible de :
- supprimer directement un attribut
- modifier directement une CI
Syntaxe
ALTER TABLE nom-table { clause-add | clause-modify | clause-drop …}
clause-add : Ajout d'attribut(s) et / ou de CI
ADD ( colonne | contrainte-de-relation [ colonne | contrainte-de-relation…] )
clause-modify : Permet de modifier le type, la taille et la valeur par défaut d'un attribut
MODIFY ( nom-col [type] [DEFAULT expr] [ NULL | NOT NULL] …)
Il est possible de :
- augmenter la largeur ou la précision d'un attribut de type numérique
- diminuer la largeur d'un attribut si cet attribut ne comporte que des valeurs NULL ou si la table ne
comporte pas de lignes
- changer le type si l'attribut contient des valeurs NULL
- convertir un attribut de type CHAR vers VERCHAR2 ou réciproquement si l'attribut contient des
valeurs nulles ou si la taille n'est pas modifiée
clause-drop : Suppression de la vérification de la contrainte et de son stockage dans le dictionnaire des données.
DROP [ PRIMARY KEY | UNIQUE (nom-col [, nom-col…] ) | CONSTRAINT contrainte ]
[ CASCADE ]
CASCADE : suppressions en cascade des CI qui dépendent de la CI supprimée (clés étrangères par ex.)
c) Suppression de tables
Syntaxe
DROP TABLE nom-table [CASCADE CONSTRAINTS]
Supprime la table du dictionnaire ainsi que toutes ses lignes, index, blocs physiques, vues…
CASCADE CONSTRAINTS : pour demander la suppression de toutes les CI dans les autres tables de la base
qui font référence à la clé primaire et aux clés uniques de la table supprimée ; si on ne précise pas CASCADE et
s'il y a des références, alors message d'erreur
d) Renommage de tables
Syntaxe
RENAME ancien_nom TO nouveau_nom
Tous les liens (CI-réf) sont mis à jour.
2) Manipulation de données
Travail sur le contenu des tables :
- INSERT : insertion de lignes
- DELETE, TRUNCATE : suppression de lignes
- UPDATE : modification de lignes

a) Insertion de données
Syntaxe
INSERT INTO nom-table [ ( nom-col [, nom-col…] ) ]
{ VALUES ( constante [constante…] ) | subquery }
La liste des colonnes :
- contient des noms d'attributs de la table
- si un attribut de la table est omis dans la liste, il prend la valeur par défaut, NULL sinon (si autorisé)
- si aucun nom d'attribut n'est donné, la clause VALUES ou la sous requête doit fournir une valeur pour
chaque attribut de la table suivant l'ordre du schéma
Clause VALUES : spécifie un n-uplet de valeurs à insérer dans la relation
- appel à des pseudo-colonnes, fonctions (sysdate, to_date,…) autorisées
- avec cette clause, un seul n-uplet peut être inséré à la fois
- sous requête : instruction SELECT qui renvoie les n-uplets à insérer
- correspondance en nombre et type des attributs et expressions
Exemple
INSERT INTO Etudiant (net, nom, age, adresse)
VALUES (1, 'Meyer', 28, 'Strasbourg')
INSERT INTO Prix
VALUES SELECT DISTINCT age FROM Etudiant WHERE…
b) Suppression de données
Syntaxe
DELETE FROM nom-table [ WHERE condition ]
Suppression des lignes qui satisfont la condition. Pas de condition Æ suppression de toutes les lignes.
Exemple
DELETE FROM Etudiant WHERE nom LIKE 'Meyer' OR age > 36
DELETE FROM Prix
Syntaxe
TRUNCATE TABLE table
Suppression de tous les n-uplets et libération espace mémoire allouée à la table.
Opération irréversible (de type LDD) qui nécessite un privilège particulier.
c) Mises à jour
Syntaxe
UPDATE nom-table
SET { nom-col = { expression | (subquery) } | (nom-col [, nom-col…]) = (subquery) }
[ WHERE condition ]
Mise à jour des attributs cités des lignes qui vérifient la condition, ou de toutes les lignes si la condition est
ommise.
Exemple
UPDATE Prix SET tarif = 'T12' WHERE age = 30
UPDATE Etudiant SET age = age + 1 WHERE nom = 'Meyer'
UPDATE Etudiant SET (age, adresse) = (SELECT age, adresse FROM…)
Interdit : SET (age, adresse) = (25, 'Strasbourg')

II. Schémas logiques
Niveau logique :
- vues,
- droits d'accès.
Nous ne verrons ici que les vues, les droits d'accès seront abordés dans le chapitre suivant.
A. Concepts
Vues :
- fenêtre dynamique sur la base,
- ses données proviennent d'autres tables ou d'autres vues.
Exemple table emp
id nom job dpt
1234 Alan manager 30
vue empv1
numéro nom emploi
4321 Smith caissier

4322 Meyer monteur
Les vues peuvent comporter :

- des restrictions,
- des projections,
- des jointures.
B. Mise en œuvre SQL
1) Syntaxe
CREATE [OR REPLACE] [ FORCE | NOFORCE ] VIEW view [ ( alias [,alias]…)]
AS subquery
[ WITH CHECK OPTION [CONSTRAINT constraint ] ]
[ WITH READ ONLY ]
subquery :
- SELECT complexe autorisé : join, GROUP BY, select imbriqué ;
- pas de ORDER BY (sera demandé dans la sélection si besoin)
Mots-clés :
- OR REPLACE : change la définition de la vue si elle existe déjà. Evite de supprimer, re-créer, redéfinir
les privilèges accordés au préalable.
- FORCE : création de la vue sans tenir compte tenir si les relations de base existent ou non.
- NOFORCE (valeur par défaut) : création de la vue uniquement si les relations de base existent.
- alias : spécifie les noms pour les expression sélectionnées dans la sous-requête. Le nombre d'alias doit
correspondre en nombre avec ces expressions.
- subquery: instruction SELECT qui peut contenir des c-alias.
- WITH CHECK OPTION : spécifie que seules les lignes accessible par la vue peuvent être insérées ou
modifiées.
- constraint : nom assigné à la contrainte WITH CHECK OPTION.
- WITH READ ONLY : garantit qu'aucune opération du LMD (insert, update, delete) ne peut être
exécutée sur cette vue

2) Exemples
CREATE VIEW empv1
AS SELECT id, nom, job FROM emp WHERE dpt = 10
Création avec alias
CREATE VIEW empv2
AS SELECT id numéro, nom, job emploi FROM emp WHERE dpt = 10
CREATE VIEW empv3 (numéro, nom, emploi)
Sélection ultérieure : emploi des noms d'alias.
Jointure, group by
CREATE VIEW empdpt
AS SELECT E.*, D.nom nomdpt, D.localisation FROM emp E, dept D WHERE E.dpt = D.id
CREATE VIEW statdpt
AS SELECT D.nom, count(*) personnel FROM emp E, departement D WHERE E.dpt = D.id
GROUP BY D.id, D.nom
Modification de vue
CREATE OR REPLACE VIEW empv1 (numéro, nom, emploi)
La définition de la vue est modifiée, par contre les droits d'accès sont maintenus.
3) Sélection
Une vue peut être interrogée comme une relation ordinaire.
Exemple
SELECT * FROM empv1 WHERE emploi='manager'
Mise en œuvre de la sélection par le serveur Oracle
- recherche de la définition de la vue : catalogue USER_VIEWS,
- vérification des droits d'accès sur la (les) table(s) de base,
- conversion de la requête sur la vue en une requête sur table(s) de base.
4) Vues complexes
Nombre de tables vue simple 1 vue complexe 1 ou plusieurs
Contient fonction non oui
Contient des groupes non oui
LMD sur la vue oui pas toujours
Suppression
Suppression d'un n-uplet interdite si la définition de la vue comporte :
- fonction d'agrégation,
- clause GROUP BY,
- mot clé DISTINCT.
Modification
Modification d'un n-uplet interdite si la définition de la vue comporte :
- clause GROUP BY, idem suppression
- mot clé DISTINCT,
- colonnes définies à l'aide d'expressions.

Insertion
Insertion d'un n-uplet interdite si la définition de la vue comporte :
- clause GROUP BY,
idem modification
- mot clé DISTINCT,
- colonnes définies à l'aide d'expressions,
- existence de colonnes NOT NULL dans une des tables de base et qui n'est pas sélectionnée dans la vue.
Clause WITH CHECK OPTION
Pour assurer que toutes les opérations de MAJ des données de la vue restent dans le domaine de la vue.
Exemple
CREATE OR REPLACE VIEW empv1
AS SELECT * FROM emp WHERE dpt = 10 WITH CHECK OPTION CONSTRAINT empv1_ck
Le numéro de département ne peut être modifié via la vue → erreur.
Clause WITH READ ONLY
Aucune opération insert, delete, update autorisée.
Exemple
CREATE OR REPLACE VIEW empv1
AS SELECT * FROM emp WHERE dpt = 10 WITH READ ONLY
DELETE FROM empv1 WHERE id = 103 → erreur
5) Suppression d'une vue

Exemple
DROP VIEW empv1
Conséquences
- suppression de la définition dans le dictionnaire,
- invalidation des vues et applications qui y sont liées,
- aucune suppression de données dans les tables.
6) Conclusion
Vue dérivée de données de tables, vues sous-jacentes.
Avantages fournis :
- restriction des accès à la base,
- simplification des requêtes,
- perception des données propre à chaque utilisateur,
- peut être supprimée sans qu'il y ait suppression des données sous-jacentes.

III. Schéma physique
A. Index
ENAME JOB DEPTNO

ALLEN Salesman 10
SMITH Clerck 10
WARD Salesman 20
JONES Manager 30
MARTIN Salesman 20
BLAKE Manager 20
CLARK Manager 10
… … …
Un moyen de retrouver la ou les lignes pour lesquelles deptno est égal à 20 est de balayer toute la table.
Un tel moyen d'accès conduit à des temps de réponse prohibitifs pour des tables dépassant quelques centaines de
lignes.
Une solution offerte par tous les systèmes de gestion de bases de données est la création d'index, qui permettra
de satisfaire aux requêtes les plus fréquentes avec des temps de réponse acceptables.
Un index est une structure arborescence permettant d’accéder directement à une ligne d’une table, à partir d’une
valeur d’index, appelée clé. Cette clé est une valeur d’une ou plusieurs colonnes. Si par exemple l’index est crée
sur la colonne deptno de emp, pour chaque valeur de deptno l’ensemble des lignes sera accessible directement
(chaque feuille de l’index est un deptno plus la liste des lignes correspondant).
Index B-arbre
Chaque feuille stocke une liste de ROWID.
Reverse key
Lors d'utilisation de clés automatiques (incrémentales), il y a un risque d'embouteillage dans l'index parce que
toutes les insertions sont faites au même endroit de l'arbre. L'inversion des octets permet de mieux balancer.
Index bitmap
Chaque feuille stocke une bitmap à la place d'une liste de ROWID. Chaque bit correspond à un ROWID, et si le
bit est à 1, alors ce ROWID désigne une ligne qui contient la clé.
B. Limites des tables classiques et solutions

Dans une table classique (régulière) l’utilisateur a un contrôle très limité de la manière dont les lignes sont
distribuées.
Quand la table est créée, les lignes sont généralement insérées dans un segment démarrant avec le premier bloc
du premier extent.
Mais après diverses opérations DML, plusieurs facteurs (ordre des blocs dans la free list, migrations de lignes…)
rendent difficiles de contrôler l’ordre des lignes au sein de la table.
Les clusters offrent plusieurs degrés de contrôle sur l’ordre de stockage des lignes.
Quand un cluster est utilisé, le serveur Oracle stocke toutes les lignes qui ont la même valeur de clé dans le
même bloc, si possible.
Lors de l’utilisation d’index-organized tables (IOT, ou encore tables organisées index), l’utilisateur maîtrise
encore plus le contrôle de l’ordre des données.

C. Cluster
Le cluster est une organisation physique des données qui consiste à regrouper physiquement (dans un même
bloc) les lignes d'une ou plusieurs tables ayant une caractéristique commune (une même valeur dans une ou
plusieurs colonnes) constituant la clé du cluster.
La mise en cluster a trois objectifs :
- accélérer la jointure selon la clé de cluster des tables mises en cluster,
- accélérer la sélection des lignes d'une table ayant même valeur de clé, par le fait que ces lignes sont
regroupées physiquement,
- économiser de la place, du fait que chaque valeur de la clé du cluster ne sera stockée qu'une seule fois.
Le regroupement en cluster est totalement transparent à l'utilisateur : des tables mises en cluster sont toujours
vues comme des tables indépendantes.
1) Différences entre clustered et unclustered tables

Dans des tables régulières, ORD et ITEM sont stockées dans des segments différents. Ce qui fait que une table
utilise ses propres ensembles de blocs (un bloc utilisé pour stocker des lignes de ORD ne peut pas contenir des
lignes de ITEM).
Si les tables ORD et ITEM sont stockées dans un cluster, elles partagent le même segment de cluster. Donc une
bloc de ce segment peut stocker des lignes des deux tables.
Si une table est stockée dans un cluster, le cluster devient l’unité de stockage physique et les tables deviennent
des entités logiques, c'est-à-dire une partie du cluster.
Caractéristiques des clusters
- un cluster possède une clé de cluster (cluster key), utilisée pour identifier les lignes qui y seront
stockées (ord_no sur l’exemple)
- la clé consiste en une ou plusieurs colonnes
- les tables d’un cluster ont des colonnes qui correspondent à la clé de cluster
- le clustering est un mécanisme transparent pour l’application qui utilise les tables : les données d’une
clustered table sont manipulées comme si elles étaient stockées dans une table régulière
- la mise à jour d’une ou plusieurs colonnes de la clé de cluster peut entraîner des déplacements
physiques de lignes
- le clé de cluster est indépendante de la clé primaire : les tables d’un cluster peuvent avoir un clé
primaire qui peuvent être la clé de cluster ou un autre ensemble de colonnes
- les clusters sont généralement créés pour augmenter les performances : l’accès aléatoire données dans
un cluster sont plus rapides, mais le parcours complet d’une table dans un cluster est généralement plus
lent
2) Types de clusters
Deux types de clusters : index clusters et hash clusters.
a) Cluster indexé
Utilise un index (l’index de cluster) pour gérer les données dans le cluster.
- L’index doit être disponible pour stocker, accéder et gérer les données dans le cluster.
- L’index est utilisé pour retrouver le bloc contenant les lignes correspondant à une clé donnée.
- La structure d’un tel index est similaire à la structure d’un index normal :
o Par contre cet index peut stocker des valeurs NULL (un index normal non).
o Une seule entrée (bloc de lignes) pour chaque clé d’un index de cluster.
o Normalement plus petit qu’un index normal pour le même ensemble de valeurs.
- Pour stocker ou retrouver des lignes dans un cluster, le serveur Oracle utilise l’index pour retrouver le
bloc et donc la première ligne correspondant à la clé donnée, et donc pour retrouver les lignes
correspondant à la clé donnée.

- Si plusieurs lignes dans un cluster indexé ont la même clé de cluster, la clé de cluster n’est pas répétée
pour chaque ligne. Dans une table avec un grand nombre de ligne par clé, utiliser un cluster indexé peut
réduire la quantité d’espace utilisée (la clé n’est jamais répétée).
b) Cluster haché
Utilise une fonction pour calculer l’emplacement d’une ligne. La fonction de hachage utilise la clé de cluster et
peut être soit définie par l’utilisateur, soit générée par le système.
Quand une ligne est insérée dans une table d’un cluster haché :
- les colonnes de la clé de hachage sont utilisées pour calculer la valeur de hachage
- la ligne est stockée selon la valeur de hachage
La fonction de hachage est utilisée pour localiser la ligne correspondant à la donnée de la table de hachage.
Quand applicable, un hash cluster procure de meilleures performances qu’un cluster indexé.
3) Création de clusters
a) Création d'un cluster indexé

3 étapes :
1. Créer le cluster
2. créer l’index
3. créer les tables dans le cluster
Il est possible de créer les tables dans le cluster avant de créer l’index.
Les trois étapes doivent être effectuées avant d’insérer des données dans les tables.
1. Création du cluster
cluster : nom du cluster
column : nom d’une clé de colonne
datatype : type de donnée et taille de la clé de colonne
SIZE : espace requis par toutes les lignes correspondant à une clé (octets, kilo ou méga)
INDEX : cluster indexé
Remarque
Si SIZE n’est pas précisé, sa valeur par défaut est la taille d’un bloc.
Le serveur Oracle utilise cette valeur pour estimer le nombre max de clés (et des données correspondant à cette
clé) qui peuvent être placées dans chaque bloc du cluster.
Sur l’exemple SIZE vaut 200.
Pour une taille de block de 2048, après allocation de l’entête, jusqu’à 1900 bytes sont disponibles dans le block
pour stocker des données.
Ainsi, un bloc pourra stocker au maximum 1900 / 200 = 9 clés et les données correspondant à ses clés.
2. Création de l’index de cluster
Les colonnes de clés n’ont pas besoin d’être précisées pour un index de cluster parce qu’elles ont déjà été
définies à la création du cluster.
Il est recommandé de placer l’index de cluster dans un tablespace différent de celui utilisé pour créer le cluster.
3. Création de tables dans le cluster
Il suffit de préciser le nom du cluster pour créer des tables dans le cluster.
La clause CLUSTER précise que la table doit être placée dans un cluster.
Remarque
Une table placée dans un cluster ne peut pas avoir d’attributs physiques spécifiques parce qu’elle n’est pas
définie dans un segment propre mais est une partie du cluster.

b) Création d'un hash cluster
Deux étapes :
1. Création du hash cluster
2. Création de tables dans le cluster
La clause HASHKEYS indique que le cluster est un cluster haché.
Le serveur Oracle utilise le nombre premier immédiatement supérieur à la valeur de HASHKEYS comme
nombre de clés différentes.
La clause (optionnelle) HASH IS permet d’utiliser une fonction de hachage définie par l’utilisateur.
Paramètre SIZE
Le paramètre SIZE définit l’espace utilisé par toutes les lignes pour une clé donnée.
Sur l’exemple de cluster indexé :
- si chaque ordre (order) a 10 lignes (items)
- si une ligne de la table ORD est 20 octets
- si une ligne de la table ITEM est 18 octets
Alors SIZE est défini par la formule :
1 ligne de ORD x 20 octets/ligne + 10 lignes de ITEM x 18 octets/ligne = 200 octets
Pour les cluster hachés, il est conseillé de préciser une valeur de SIZE légèrement plus grande pour réduire les
risques de collisions (détaillé plus loin dans ce chapitre).
HASHKEYS
Le mot-clé HASHKEYS précise le nombre de clés espéré pour un cluster haché.
Ce paramètre, tout comme SIZE, est utilisé par le serveur Oracle pour estimer la taille initiale du cluster.
L’espace alloué pour le cluster pendant sa création est défini par la formule :
CEIL ( HASHKEYS / TRUNC(Available block space / SIZE) )
où Available block space = (DB_BLOCK_SIZE – Header) x (1 – PCTFREE/100)
(CEIL=plafond, le dénominateur est le nombre de clés possibles par bloc)
Les extents sont alloués comme défini dans la clause de stockage jusqu’à ce que la taille totale d’extents alloués
est égale ou supérieure à la valeur calculée.
HASH IS
La fonction choisie doit considérer la distribution des clés et doit :
- fournir la distribution max de lignes parmi les valeurs de hachage
- tenter de minimiser le nombre de collisions (une collision arrive si plusieurs clés différentes fournissent
le même résultat par hachage ; quand ça arrive et qu’il n’y a plus assez de place pour ranger toute les
lignes dans le même bloc, un pointeur est placé dans le bloc, et les nouvelles lignes sont placées dans un
overflow block)
- Calculer un nombre entier positif
La fonction de hachage peut contenir toute instruction SQL valide ne contenant pas d’expressions
« temporaires » telles que SYSDATE et USER.
Les fonctions user-defined ne peuvent pas être des parties de la fonction de hachage.
Modification
Possible de changer par ALTER CLUSTER, pour les deux types de clusters :
- paramètres d’utilisation des blocks
- clauses de stockage sauf INITIAL
- allouer des extents
- désallouer l’espace inutilisé
Uniquement pour les clusters indexés, par ALTER CLUSTER :
- changer SIZE

Uniquement pour les clusters indexés, par TRUNCATE CLUSTER :
- libérer de l’espace
- réutiliser de l’espace
Les commandes ALTER CLUSTER, TRUNCATE CLUSTER et ANALYZE CLUSTER suivent la même
syntaxe que les commandes correspondant pour les tables.
4) Suppression d’un cluster

Un cluster peut être supprimé après que toutes les tables du cluster ont été supprimées.
Cela peut être fait par l’option INCLUDING TABLES dans la commande DROP CLUSTER ou en supprimant
les tables avant de supprimer le cluster.
La clause CASCADE CONSTRAINT doit être utilisée si une table du cluster est référencée par une contrainte
de clé étrangère dans une table qui ne fait pas partie du cluster.
5) Quand utiliser un cluster ?

Il faut considérer deux aspects lors de l’implémentation des clusters :
a) Nature des données

Distribution des valeurs de clés :
Les clusters sont intéressants quand le nombre d’occurrences correspondant aux clés est uniforme. Sur l’exemple
des ordres, si les ordres comportent généralement un nombre constant d’items, les clusters sont intéressants. Si
par contre certains ordres ont un ou deux items et d’autres plusieurs centaines, un cluster n’est pas justifié.
Intervalle des valeurs de clés et leurs étendues :
Les clés dispersées dans un intervalle ne sont pas intéressantes pour les implémentations de clés de hachage
parce qu’elles provoquent un gros gaspillage d’espace dans le cluster. Un algorithme de hachage bien pensé peut
résoudre ce problème, mais dans de nombreux cas il est très difficile de développer une fonction de hachage
appropriée.
b) Activité des données dans les tables

Fréquence de MAJ des colonnes de clés :
Quand une clé d’un cluster est MAJ, la ligne peut être physiquement déplacée vers un autre bloc. Cela risque de
dégrader les performances. Les colonnes souvent MAJ ne sont donc pas de bonnes candidates pour être des
parties de clés de cluster.
Fréquence des jointures :
Les tables souvent jointes dans des requêtes utilisant des relations de clés étrangères sont intéressantes à placer
dans un cluster. Comme les lignes correspondant à une clé donnée sont stockées ensembles, un cluster peut
réduire le nombre de blocs lus pour répondre à la requête.
Dans de nombreuses situations il est intéressant de ne pas placer toutes les tables dans le cluster. Si par exemple
les employés sont souvent recherchés par département et que la table département est souvent entièrement
scannée, il vaut mieux ne mettre que la table employés dans le cluster.
Estimation du nombre de clés
Dans un hash cluster, la fonction de hachage est basée sur les paramètres précisés par l’utilisateur lors de la
création du cluster. S’il est difficile de prévoir les clés ou leurs tailles à cause de la volatilité des données, un
mauvais choix pour HASHKEYS ou SIZE peut entraîner de nombreux dépassements ou perte d’espace.
L’utilisation de hachage n’est intéressante que si SIZE et HASHKEYS sont prévisibles.

Condition de requête
La fonction de hachage ne peut être utilisée pour retrouver des données que si les clés sont connues. Pour cette
raison, une recherche d’intervalle ne peut pas utiliser de fonction de hachage. Le hachage est intéressant pour les
requêtes utilisant l’égalité sur les clés. Il est par contre possible de créer un index sur la clé de hachage si de
nombreuses requêtes recherchent des intervalles sur les colonnes de clés de hachage.
Information sur les clusters
La colonne FUNCTION de DBA_CLUSTERS peut prendre les valeurs :
- DEFAULT2 : fonction interne du serveur Oracle
- COLUMN : si la colonne de clé elle-même est spécifiée dans la clause HASH IS
- HASH EXPRESSION : une fonction définie par une expression utilisateur
D. Tables organisées index
1) Structure de stockage
Une table organisée-index conserve toutes les données d’une table dans un B-arbre.
L’index B-arbre, basé sur la clé primaire de la table, est organisé comme un index.
Dans cette structure, le block-feuille contient les colonnes non-clés, à la place du ROWID, comme le second
élément de l’entrée de la feuille de l’index.
Ainsi, l’utilisation d’une table organisée-index élimine le fait d’avoir deux segments séparés, un pour la table et
un pour l’index.
2) Accès d’une table organisée-index

Dans une table régulière, l’accès d’un index nécessite
- la lecture d’un block d’index (ou plus) pour retrouver le ROWID, et
- l’E/S sur la table à partir du ROWID.
Par opposition, la lecture d’une table organisée-index ne nécessite que la lecture du block d’index parce que
toute la ligne est disponible dans la feuille.
On peut accéder à une table organisée-index en utilisant soit la clé primaire soit une combinaison de colonnes
constituant une partie de la clé primaire.
Des instructions DML n’affectent que l’index.
3) Différences entre tables régulières et table organisée-index

- Une ligne d’une table régulière est identifiée de manière unique par ROWID alors qu’une ligne d’une
table organisée-index est identifiée par sa clé primaire.
- Une table régulière peut avoir plusieurs index qui stockent le ROWID correspondant à la clé. Comme
les tables organisées-index n’ont pas de ROWID, des index secondaires ne peuvent pas être créés. Une
requête SQL essayant de retrouver le ROWID dans une table organisée-index provoquera l’erreur ORA-
02031 : no ROWID for fixed tables or for index-organized tables.
- L’ordre des lignes n’est pas prévisible lors du scan complet d’une table régulière (Full Table Scan).
Dans une table organisée-index, l’ordre des lignes est l’ordre de la clé primaire.
- Une table organisée-index supporte toutes les contraintes sauf UNIQUE
- Une table organisée-index ne peut pas être utilisée dans une transaction distribuée, ne peut pas être
partitionnée ou répliquée.
4) Création
Une organisation sous forme d’index est intéressante pour une table souvent accédée par sa clé primaire et qui
n’a que peu de colonnes non clés.

PCTTHRESHOLD : pourcentage d’espace réservé dans le block d’index pour une ligne organisée-index (si une
ligne dépasse la taille calculée à partir de cette valeur, toutes les colonnes après la colonne précisée dans la
clause INCLUDING sont déplacées dans le segment de dépassement ; si OVERFLOW n’est pas précisé, les
lignes dépassant le seuil (threshold) sont rejetées ; la valeur défaut de PCTTHRESHOLD est 50 et sa valeur doit
être comprise entre 0 et 50)
INCLUDING : colonne à laquelle une ligne organisée-index est divisée entre index et zone de dépassement
(toutes les colonnes suivant column sont stockées dans le segment de dépassement ; si non précisé et que la taille
d’une ligne dépasse PCTTHRESHOLD, toutes les colonnes sauf la clé primaire sont déplacées dans le segment
de dépassement ; la colonne est soit le nom de la dernière colonne de la clé primaire ou toute colonne non-clé)
OVERFLOW : les données des lignes dépassant le seuil précisé sont placées dans le segment défini par
segment_attribut_clause, qui définit le tablespace et les paramètres d’utilisation des blocks
Restrictions
Une clé primaire doit être précisée pour ne table organisée-index. Une tentative de création d’une table
organisée-index sans clé primaire provoque l’erreur ORA-25175: no PRIMARY KEY constraint found.
Si PCTTHRESHOLD est défini et qu’un segment de dépassement n’est pas défini, les lignes dépassant le seuil
sont rejetées avec le message ORA-01429: Index-organized table: no data segment to store overflow row-pieces.
ROW OVERFLOW
Une grande ligne dans une table organisée-index peut détruire le stockage dense des lignes de l’index. Ce
problème est résolu par l’utilisation de zones de dépassement.
Segments créés pour une table organisée-index
Quand une table organisée-index est crée en précisant la clause OVERFLOW, les éléments suivants sont créés :
- une table « logique » avec le même nom que celui précisé dans la commande CREATE TABLE
(comme toutes les lignes sont stockées dans l’index, aucun segment ne correspond à cette table)
- un index avec le même nom que la contrainte de clé primaire, dans le tablespace défini dans la
commande CREATE TABLE, utilisant le stockage et les paramètres d’utilisation de block précisés
- une table pour ranger les lignes trop grandes : cette table s’appelle SYS_IOT_OVER_n, n étant le
OBJECT_ID de la table organisée-index (visible dans la vue DBA_OBJECTS)
5) Opérations sur les tables organisées-index

Une table organisée-index peut être utilisée comme une table régulière.
Toutes les commandes, comme ALTER TABLE, ANALYZE TABLE, TRUNCATE TABLE, DROP TABLE, et
toutes les instructions DML sont supportées par les tables organisées-index.
6) Information
DBA_TABLES, DBA_INDEXES

Chapitre 4 : Robustesse
Voyons ici comment les objectifs des SGBD (sécurité, confidentialité, intégrité) sont respectés.
I. Sécurité
A. Sécurité de fonctionnement
Suite à un incident matériel ou logiciel, il convient de redémarrer le système et de remettre la BD en état
cohérent, en utilisant l'archivage (copie de sauvegarde sur un autre support : CD, DAT, disquette...) et la
journalisation (un journal mémorise toutes les transactions effectuées sur la BD ; en cas de panne de courant, le
système lit le journal).
Durant une transaction (ensemble de modifications de la base qui forme un tout indivisible), des opérations sont
effectuées sur la BD, qui est donc non cohérente temporairement, ce qui est risqué, si un autre utilisateur y
accède à ce moment.
La transaction doit être terminée ou non exécutée. Une transaction est terminée soit par une validation qui
entérine les modifications, soit par une annulation qui remet la base dans son état initial. Deux transactions ne
peuvent se chevaucher. L’utilisateur peut à tout moment valider la transaction en cours (COMMIT en SQL), les
modifications deviennent alors définitives et visibles à l’ensemble des utilisateurs.
Tant que la transaction n’est pas validée, les modifications qu’elle contient n’apparaissent qu’à l’utilisateur qui
l’exécute. Tous les autres utilisateurs voient la base dans l’état où elle était avant le début de la transaction.
L’utilisateur peut annuler la transaction en cours (ROLLBACK en SQL), les modifications effectuées depuis le
début de la transaction sont alors annulées.
B. Gestion de la concurrence d'accès

Un autre problème à résoudre est celui de la concurrence d'accès : lorsque plusieurs personnes travaillent
simultanément sur la même donnée, il faut éviter que le travail de l'une écrase celui de l'autre.
Le mécanisme des verrous est le plus couramment utilisé : il interdit l'accès à une donnée (table ou partie de
table) tant que celle-ci est utilisée. Le verrou est posé pendant un temps minimal, généralement transparent (tous
les utilisateurs ont l'impression de travailler seuls sur la donnée).
Mais cela peut conduire à un interblocage de processus (deadlock) :
Transaction 1 Transaction 2
Verrouiller la table A
Verrouiller la table B
Verrouiller la table B
(attente) Verrouiller la table A
(attente)
Ce type d’interblocage ne peut pas arriver si tous les utilisateurs bloquent les tables dans le même ordre.

Lecture inconsistante ou lecture impropre. Une transaction T2 lit une valeur donnée par une autre transaction
T1. Ensuite la transaction T1 annule son affection de V Æ la valeur lue par T2 est fausse :
V = 100
Lire V
ROLLBACK
Ce cas ne peut pas arriver si les modifications effectuées par une transaction ne sont visibles par les autres
qu’après validation (COMMIT) de la transaction.
Lecture non répétitive, ou non reproductible, ou incohérente. Une transaction lit deux fois une même valeur
et ne trouve pas la même valeur les deux fois.
Lire V
V = V + 100
COMMIT
Lire V
Pour éviter ce cas, T1 devra bloquer les données qu’il veut modifier suffisamment longtemps pour empêcher les
autres transactions de les modifier.
Lignes fantômes. Une sélection de lignes récupère des lignes qui sont modifiées par une autre transaction et ne
vérifient plus le critère de la sélection. La même sélection lancée une seconde fois ne retrouve donc plus ces
lignes.
Sélectionner les lignes avec V = 10

V = 20 pour toutes les lignes
Sélectionner les lignes avec V = 10
Là encore la solution est le blocage explicite des lignes en question.

Traitement des accès concurrents par le SGBD. Les SGBD gèrent automatiquement les accès concurrents de
plusieurs utilisateurs sur les mêmes lignes des tables.
Dans Oracle, si une donnée est en cours de modification, les autres utilisateur peuvent lire la donnée telles
qu’elle était avant cette modification (jamais de délai d’attente pour la lecture), ou sont bloqués automatiquement
s’ils veulent modifier la donnée.
Oracle assure une lecture consistante des données pendant l’exécution d’un ordre SQL : par exemple, un ordre
SELECT ou UPDATE va travailler sur les lignes telles qu’elles étaient au moment du début de l’exécution de la
commande, même si entre-temps un autre utilisateur a confirmé (COMMIT) des modifications sur certaines de
ces lignes.

C. Résistance aux pannes
Les sauvegardes permettent de réparer les dommages créés par des pannes. Le SGBD enregistre
automatiquement toutes les instructions exécutées sur la base dans des fichiers de log (fichiers utilisés lors du
redémarrage après la panne). L’administrateur sauvegarde régulièrement les BD et les fichiers utilisés par le
SGBD et enregistre les fichiers de log sur des médias stables (bandes, CD). Le système s'en voit ralenti mais est
plus fiable en cas de panne.
Les pannes peuvent être d'origine logicielle (SGBD ou applications qui accèdent aux données), d'origine
matérielle (le plus souvent les disques, mais aussi pannes de courant…), ou dues au réseau en cas de BD
distribuées.
Le traitement est différent selon que la panne a laissé la base dans un état cohérent (interruption logicielle) ou si
elle a été endommagée et ne peut plus être utilisée (crash disque).
Après un accident, si les fichiers de la base n'ont pas été endommagés, les fichiers de log sont utilisés : les
modifications validées (COMMIT) mais non enregistrées réellement (pour des raisons d’écriture asynchrone)
sont réexécutées ; les transactions annulées (ROLLBACK) ou non confirmées (COMMIT) avant la panne sont
annulées.
Si les fichiers de la base ont été endommagés, l’administrateur doit recharger la dernière sauvegarde. Si toutes
les modifications ont été archivées (fichiers de log), il peut relancer leur exécution jusqu’à la panne, ou tout au
moins jusqu’à la dernière archive valide. Sinon, il faudra relancer à la main toutes les transactions exécutées
entre la dernière sauvegarde et la panne.
Les fichiers de log ne servent pas seulement à la réparation en cas de panne, mais sont utilisés pour des raisons
de performances : lors d’un COMMIT, les données ne sont pas directement écrites mais leur modification est
inscrite dans les fichiers de log. Une écriture séquentielle, plus efficace, est ensuite effectuée.
D. Mise en œuvre SQL
1) Gestion des transactions
a) Début transaction
Implicite :
- 1ère instruction SQL exécutable qui suit une connexion à la base
- fin de transaction précédente (COMMIT, ROLLBACK)
- après instruction du LDD (COMMIT implicite après chaque instruction du LDD)
Explicite : SET TRANSACTION
- SET TRANSACTION READ ONLY
- SET TRANSACTION READ WRITE
- SET TRANSACTION USE ROLLBACK SEGMENT segment
b) Point de sauvegarde
SAVEPOINT savepoint
Nom d'un point de sauvegarde de la transaction.
Nom unique pour la transaction courante, si le nom existait déjà, le 1er point de sauvegarde est écrasé.
c) Annulation de toute la transaction

Explicite : ROLLBACK
- finit la transaction courante
- défait toutes les instructions de la transaction courante
- supprime tous les points de sauvegarde de la transaction
- libère les verrous de la transaction
Implicite : lors de sortie anormale de la session

d) Annulation partielle
ROLLBACK TO [SAVEPOINT] savepoint
- défait toutes les instructions qui suivent le point de sauvegarde
- supprime tous les points de sauvegarde postérieurs à celui donné
- libère les verrous acquis après le point de sauvegarde donné
e) Validation
Explicite : COMMIT
- finit la transaction courante
- tous les changements sont permanents et deviennent visibles aux autres utilisateurs
- supprime tous les points de sauvegarde
- libère les verrous
Implicite :
- avant et après chaque instruction du LDD
- lors de sortie normale de la session (exit)
f) Exemple
sqlplus scott/tiger
SQL > INSERT … transaction 1
SQL > CREATE TABLE … transaction 2
SQL > DELETE … transaction 3
SQL > COMMIT …
SQL > INSERT …
SQL > SAVEPOINT save1
SQL > OPDATE …
transaction 4
SQL > ROLLBACK TO save1
SQL > UPDATE …
SQL > EXIT
Validation automatique
Variable AUTOCOMMIT (SQL*Plus)
SET AUTOCOMMIT OFF : par défaut
SET AUTOCOMMIT ON :
- un COMMIT suit toutes les modifications
- ROLLBACK n'a plus d'effet
2) Gestion des verrous
a) Syntaxe
LOCK TABLE [schema .] { table | view } [, [schema .] { table | view } …] IN lockmode MODE [NOWAIT];
Si on met un verrou sur une vue, Oracle bloque la (les) table(s) de base.
lockmode :
- ROW SHARE (= SHARE UPDATE) : accès concurrents autorisés, mais les autres utilisateurs ne
peuvent pas bloquer l'objet pour un accès exclusif.
- ROW EXCLUSIVE : comme ROW SHARE mais interdit les blocages concurrents en mode SHARE.
Ce mode est automatiquement obtenu lors d'opérations de LMD.
- SHARE : requêtes concurrentes autorisées, mais pas de MAJ.
- SHARE ROW EXCLUSIVE : autorise les requêtes d'autres utilisateurs mais empêche qu'ils bloquent
en mode SHARE ou MAJ (utilisé pour parser toute la table de manière consistante).
- EXCLUSIVE : autorise d'autres requêtes mais pas d'autre activité.

NOWAIT : si la table / vue est déjà verrouillée, alors message d'erreur (pas d'attente). Si NOWAIT n'est pas
précisé et que la table / vue est verrouillée, alors on est mis en attente.
b) Exemple
LOCK TABLE emp IN EXCLUSIVE MODE NOWAIT
c) Remarques
Le privilège système LOCK ANY TABLE permet de bloquer toute table.
Pas de commande UNLOCK… (pour débloquer : COMMIT, ROLLBACK, EXIT)
II. Confidentialité
A. Contrôle de l’accès à la base
L’accès à la base est contrôlé par une gestion des droits d'accès des différents utilisateurs (mots de passe) et des
privilèges (les utilisateurs n’ont pas tous les mêmes droits).
B. Contrôle de l’accès aux données

Les données d’une table appartiennent au créateur de la table, qui peut donner aux autres utilisateurs des droits
sur cette table (par exemple consulter, ajouter…)
Les vues fournissent également des restrictions d’accès aux données. Une vue est une table virtuelle constituée
de colonnes qui appartiennent à des tables réelles. On peut donner le droit d’accès à une vue sans donner le droit
d’accès aux tables sous-jacentes.
On peut aussi donner des droits sur une partie seulement des lignes ou des colonnes d’une table.
C. Mise en œuvre SQL
1) Privilège
- droit d'exécuter certaines instructions SQL
- l'administrateur de la base a les privilèges les plus élevés
- instructions
o GRANT : transmission de privilèges
o REVOKE : suppression de privilèges
Types de privilèges :
- système : droit d'accès à la base
- objet : manip. du contenu des objets de la base
- schéma : collections objets : table, vue, séquence
Privilèges système : administrateur
L'administrateur de la base a les droits nécessaires pour :
- créer de nouveaux utilisateurs
- supprimer des utilisateurs
- supprimer des tables (quel que soit le schéma)
- créer des rôles
- effectuer le back up de n'importe quelle table
- …

2) Création d'un nouvel utilisateur
CREATE USER user IDENTIFIED BY password
L'utilisateur user est créé, mais il n'a encore aucun privilège (pas même le droit de se connecter)
Transmission de privilège :
GRANT privilège [, privilège…] TO user [, user…]
Privilèges système : utilisateur
L'administrateur peut accorder des privilèges système à un utilisateur :
- CREATE SESSION : connexion à une base
- CREATE TABLE : création de tables dans le schéma de l'utilisateur
- CREATE VIEW : création de vues dans le schéma de l'utilisateur
- …
Exemple
Pour chacun d'entre vous, l'administrateur de la base ROSA a exécuté :
- CREATE USER étudiant IDENTIFIED BY étudiant ;
- GRANT CREATE SESSION, CREATE TABLE, CREATE SEQUENCE, CREATE VIEW TO
etudiant ;
Remarque : les privilèges
- peuvent être accordés en une ou plusieurs instructions GRANT
- sont immédiatement opérationnels
3) Rôle
Un rôle est un groupe de privilèges
- auquel on a donné un nom et
- qui peut être attribué à un utilisateur
Permet de faciliter la gestion des privilèges : pour un grand nombre d'utilisateur, il est plus simple de leur
affecter un rôle plutôt que plusieurs privilèges.
Création du rôle : CREATE ROLE rôle ;
Assignation de privilèges au rôle : GRANT privilège [, privilège…] TO rôle ;
Affection de rôles aux utilisateurs : GRANT rôle TO user1 [, user2…] ;
4) Privilège sur les objets

Les privilèges variables suivant les objets concernés (table, vue, séquence, procédure) :
- ALTER autorisé sur : table séquence
- DELETE table vue
- EXECUTE procédure
- INDEX table
- INSERT table vue
- REFERENCES table
- SELECT table vue séquence
- UPDATE table vue
L'utilisateur est le propriétaire des objets de son schéma :
- il a automatiquement tous les privilèges "objets"
- il peut attribuer des privilèges spécifiques aux autres utilisateurs
GRANT { priv_obj [, priv_obj…] | ALL } [ (col)]
ON objet
TO { user | rôle | PUBLIC }
[ WITH GRANT OPTION ]

- ALL : tous les privilèges objets
- col : colonnes d'une table ou vue pour lesquelles le privilège est accordé
- TO : désigne le bénéficiaire du privilège
- PUBLIC : privilège accordé à tous les utilisateurs
- WITH GRANT OPTION : le bénéficiaire du privilège (user ou PUBLIC) peut à son tour transmettre le
privilège obtenu à d'autres utilisateurs ou rôles. Les cycles sont interdits dans la propagation des
privilèges. L'instruction GRANT peut être exécutée par :
o propriétaire de l'objet
o un bénéficiaire du privilège, ayant obtenu le privilège avec l'option WITH GRANT OPTION
Exemples
GRANT select ON employé TO adams, manager
GRANT update (nom, job) ON employé TO scott
GRANT select, insert ON département TO scott WITH GRANT OPTION
GRANT select ON projet TO PUBLIC
Suppression de privilèges objets
REVOKE { priv [, priv…] | ALL
ON objet
FROM { user [, user…] | rôle | PUBLIC }
[ CASCADE CONSTRAINTS ]
CASCADE CONSTRAINTS : nécessaire pour supprimer toutes les CI référentielles demandées sur l'objet à
l'aide du privilège qui avait été accordé
L'instruction REVOKE peut être exécutée à tout moment.
Suppression du privilège :
- pour l'utilisateur nommé dans REVOKE
- aux autres utilisateurs de la base à qui l'utilisateur nommé avait propagé le privilège (en utilisant son
droit WITH GRANT OPTION)
III. Intégrité
A. Contraintes d'intégrité
Les opérations doivent respecter les contraintes d'intégrité implicitement. Les commandes qui ne respectent pas
ces contraintes sont automatiquement annulées (toute la commande est annulée si une seule des lignes ne
respecte pas une contrainte d’intégrité).

Cf. gestion des contraintes d'intégrité (CREATE TABLE…)
IV. Performances
A. Accès aux données
Les langages d’utilisation des SGBD relationnels ne font pas référence au cheminement à suivre pour accéder
aux données. Il y a donc un risque de performances dégradées (données non contiguës, isolées…).
Pour y remédier, il est possible de définir des index sur une rubrique qui permettent d'accélérer l’accès aux lignes
qui ont une certaine valeur ou accélérer le tri des lignes dans l’ordre de rangement de l’index, ou des clusters
(rangement physique de plusieurs tables dans un même espace) permettant d'accélérer les jointures sur ces tables
en partageant des colonnes entre plusieurs tables.

Cf. Organisation physique des données

Chapitre 5 : Annexe – syntaxe des
commandes
I. Langage d'interrogation des données
A. SELECT
select::= subquery [for_update_clause];
subquery::= [ subquery_factoring_clause ]
SELECT [ { DISTINCT | UNIQUE } | ALL ] select_list
FROM table_reference [, table_reference]...
[ WHERE condition ]
[ group_by_clause ]
[ HAVING condition ]
[ { UNION | UNION ALL | INTERSECT | MINUS } ( subquery )]
[ order_by_clause ]
subquery_factoring_clause::= WITH query_name AS ( subquery ) [, query_name AS ( subquery )
]...
select_list::= { *
| { query_name.*
| [schema.] { table | view | materialized view } .*
| expr [[AS] c_alias]
}
[, { query_name.*
| [schema.] { table | view | materialized view } .*
| expr [[AS] c_alias]
}
]...
}
table_reference::= { ONLY query_table_expression
| query_table_expression [t_alias]
| ( joined_table )
| joined_table
}
query_table_expression::= { query_name
| [schema .] { table | view | materialized view } [@ dblink]
| ( subquery [subquery_restriction_clause] )
}
subquery_restriction_clause::= WITH { READ ONLY | CHECK OPTION [CONSTRAINT constraint] }
joined_table::= table_reference
{ [join_type] JOIN table_reference
{ ON condition | USING ( column [, column]... ) }
| { CROSS JOIN | NATURAL [join_type] JOIN table_reference }
}
join_type::= { INNER | { LEFT | RIGHT | FULL } [OUTER] }
group_by_clause::= GROUP BY expr [, expr]...
[ HAVING condition ]
order_by_clause::= ORDER BY
{ expr | position | c_alias } [ ASC | DESC ] [ NULLS FIRST | NULLS LAST ]
[, { expr | position | c_alias } [ ASC | DESC ] [ NULLS FIRST | NULLS LAST ]]...
for_update_clause::= FOR UPDATE
[OF [[schema .] { table | view } .] column
[, [[schema .] { table | view } .] column]...
]
[ NOWAIT | WAIT integer ]

B. Condition
condition::= { simple_comparison_condition | group_comparison_condition
| membership_condition
| range_condition
| null_condition
| exists_condition
| like_condition
| compound_condition
}
simple_comparison_condition::= { expr { = | != | ^= | <> | > | < | >= | <= } expr
| expr [, expr ]... { = | != | ^= | <> } ( subquery )
}
group_comparison_condition::= { expr
{ = | != | ^= | <> | > | < | >= | <= }
{ ANY | SOME | ALL }
( { expression_list | subquery } )
| expr [, expr ]...
{ = | != | ^= | <> }
{ ANY | SOME | ALL }
( { expression_list [, expression_list ]...
| subquery } )
}
expression_list::= { expr [, expr ]... | ( expr [, expr]... ) }
membership_condition::= { expr [NOT] IN ( { expression_list | subquery } )
| ( expr [, expr]... [NOT] IN ( { expression_list [, expression_list ]...
| subquery } )
}
range_condition::= expr [NOT] BETWEEN expr AND expr
null_condition::= expr IS [NOT] NULL
exists_condition::= EXISTS ( subquery )
like_condition::= char1 [NOT] {LIKE | LIKEC | LIKE2 | LIKE4} char2 [ESCAPE esc_char]
compound_condition::= { ( condition )
| NOT condition
| condition { AND | OR } condition
}
C. Expressions
expr::= { simple_expression
| compound_expression
| datetime_expression
| interval_expression
| object_access_expression
}
simple_expression::= { [ query_name .
| [schema .] { table . | view . | materialized view . }
] { column | ROWID }
| ROWNUM
| text
| number
| sequence . { CURRVAL | NEXTVAL }
| NULL
}
compound_expression::= { ( expr )
| { + | - | PRIOR } expr
| expr { * | / | + | - | || } expr
}
datetime_expression::= datetime_value_expr AT
{ LOCAL
| TIME ZONE { ' [ + | - ] hh:mm' | DBTIMEZONE | SESSIONTIMEZONE | 'time_zone_name' | expr
}
}

interval_expression::= interval_value_expr { DAY TO SECOND | YEAR TO MONTH }
object_access_expression::= { table_alias . column . | object_table_alias . | (expr) . }
{ attribute [. attribute]... [. method ( [argument [, argument]...] ) ]
| method ( [argument [, argument]...] )
}
II. Langage de définition de données

A. Types de données
datatypes::= { Oracle_built_in_datatypes
| ANSI_supported_datatypes
}
Oracle_built_in_datatypes::= { character_datatypes
| number_datatypes
| long_and_raw_datatypes
| datetime_datatypes
| large_object_datatypes
| rowid_datatypes
}
character_datatypes::= { CHAR ( size [ BYTE | CHAR ] )
| VARCHAR2 ( size [ BYTE | CHAR ] )
| NCHAR ( size )
| NVARCHAR2 ( size )
}
number_datatypes::= NUMBER [ ( precision [, scale] ) ]

long_and_raw_datatypes::= { LONG | LONG RAW | RAW ( size ) }
datetime_datatypes::= { DATE
| TIMESTAMP [( fractional_seconds_precision )] [WITH [LOCAL] TIME ZONE] )
| INTERVAL YEAR [( year_precision )] TO MONTH
| INTERVAL DAY [( day_precision )] TO SECOND [( fractional_seconds_precision )]
}
large_object_datatypes::= { BLOB | CLOB | NCLOB | BFILE }
rowid_datatypes::= { ROWID | UROWID [( size )] }
ANSI_supported_datatypes::= { CHARACTER [VARYING] ( size )
| { CHAR | NCHAR } VARYING ( size )
| VARCHAR ( size )
| NATIONAL { CHARACTER | CHAR } [VARYING] ( size )
| { NUMERIC | DECIMAL | DEC } [( precision [, scale] )]
| { INTEGER | INT | SMALLINT }
| FLOAT [( size )]
| DOUBLE PRECISION
| REAL
}
Principaux types de données

Chaînes de caractères de longueur fixe :
CHAR(size) [BYTE | CHAR] | NCHAR(size) : size facultatif, exprimé en octets ou nombre
de caractères. Max. : 2000 octets pour CHAR, dépendant du jeu de caractère national pour NCHAR,
plafonné à 2000. Min. et Défaut : 1 octet pour CHAR, 1 caractère pour NCHAR.
Chaîne de caractères de longueur variable :
VARCHAR2(size) [BYTE | CHAR] | NVARCHAR2(size) : size obligatoire, exprimé en octet
ou nombre de caractères. Max. : 4000 octets pour VARCHAR2, dépendant du jeu de caractère national
pour NVARCHAR2, plafonné à 4000.
LONG : Sans préciser de taille : chaînes de caractères de longueur variable, jusqu'à 2 Go.

Numérique :
NUMBER(p,s) : Stockage de nombres positifs ou négatifs dont la magnitude est comprise entre 1.0 x
10-130 et 9.9...9 x 10125 (38 neufs suivis par 88 zéros). p : précision (1 ≤ p ≤ 38), facultatif. s = scale :
nombre de chiffres à droite de la virgule (-84 ≤ p ≤ 127).
NUMBER(p) : équivalent à NUMBER(p,0) (nombres entiers)
NUMBER : nombre réel avec la précision maximale
Date :
DATE : toute date valide comprise entre le 1er janvier 4712 av. JC et le 31 décembre 999 ap. JC,
excluant l'année 0. Format : centenaire + année + mois + jour + heure + min + sec. Type ANSI :
'YYYY-MM-DD'. Type Oracle : 'YY-MON-DD', 'YY-MON-DD:HH24:MI'…
B. Création de tables
create_table::= relational_table
relational_table::= CREATE [GLOBAL TEMPORARY] TABLE [schema .] table
[( relational_properties )] [ON COMMIT { DELETE | PRESERVE } ROWS]
[physical_properties];
relational_properties::= { column datatype [DEFAULT expr]
[ inline_constraint [inline_constraint]...]
| out_of_line_constraint
}
[, { column datatype [DEFAULT expr]
[ inline_constraint [inline_constraint]...]
]...
inline_constraint::= [CONSTRAINT constraint_name]
{ [NOT] NULL
| UNIQUE
| PRIMARY KEY
| references_clause
| CHECK ( condition )
} [constraint_state]
out_of_line_constraint::= [CONSTRAINT constraint_name]
{ UNIQUE ( column [, column]... )
| PRIMARY KEY ( column [, column]...
| FOREIGN KEY ( column [, column]... references_clause
| CHECK ( condition )
} [constraint_state]
references_clause::= REFERENCES [schema .] { object_table | view } [ (column [, column]...) ]
[ON DELETE { CASCADE | SET NULL }] [constraint_state]
constraint_state::= [ [[NOT] DEFERRABLE] [INITIALLY { IMMEDIATE | DEFERRED }]
| [INITIALLY { IMMEDIATE | DEFERRED }] [[NOT] DEFERRABLE]
]
[ ENABLE | DISABLE ]
[ VALIDATE | NOVALIDATE ]
physical_properties::= { segment_attributes_clause [data_segment_compression]
| ORGANIZATION
{ HEAP [segment_attributes_clause] [data_segment_compression]
| INDEX [segment_attributes_clause] index_org_table_clause
}
| CLUSTER cluster ( column [, column]... )
}
segment_attributes_clause::= { TABLESPACE tablespace | logging_clause }
[TABLESPACE tablespace | logging_clause ]...
data_segment_compression::= { COMPRESS | NOCOMPRESS }
logging_clause::= {LOGGING | NOLOGGING}
index_org_table_clause::= [{ mapping_table_clauses | PCTTHRESHOLD integer | key_compression }
[ mapping_table_clauses | PCTTHRESHOLD integer | key_compression ]...
]
[index_org_overflow_clause]

mapping_table_clauses::= { MAPPING TABLE | NOMAPPING }
key_compression::= { COMPRESS [integer] | NOCOMPRESS }
index_org_overflow_clause::= [INCLUDING column_name] OVERFLOW [segment_attributes_clause]
C. Modification de tables
alter_table::= ALTER TABLE [schema .] table
{ column_clauses
| constraint_clauses
}
[{ enable_disable_clause | { ENABLE | DISABLE } { TABLE LOCK | ALL TRIGGERS } }
[ enable_disable_clause | { ENABLE | DISABLE } { TABLE LOCK | ALL TRIGGERS } ]...
]
;
column_clauses::= { { add_column_clause | modify_column_clause | drop_column_clause }
[ add_column_clause | modify_column_clause | drop_column_clause ]...
| rename_column_clause
}
add_column_clause::= ADD { ( column datatype [DEFAULT expr]
[inline_constraint [inline_constraint]...]
) }
[, { ( column datatype [DEFAULT expr] [inline_constraint [inline_constraint]...] ) }
]...
modify_column_clause::= MODIFY modify_col_properties
modify_col_properties::= ( column [datatype] [DEFAULT expr]
[ inline_constraint [inline_constraint]... ]
[, column [datatype] [DEFAULT expr] [ inline_constraint [inline_constraint] ... ] ]
)
drop_column_clause::= { SET UNUSED { COLUMN column | ( column [, column]... ) }
[{ CASCADE CONSTRAINTS | INVALIDATE } [ CASCADE CONSTRAINTS | INVALIDATE ]...]
| DROP { COLUMN column | ( column [, column]... ) }
[{ CASCADE CONSTRAINTS | INVALIDATE } [ CASCADE CONSTRAINTS | INVALIDATE ]...]
| DROP { UNUSED COLUMNS | COLUMNS CONTINUE }
}
rename_column_clause::= RENAME COLUMN old_name TO new_name
constraint_clauses::= { ADD {out_of_line_constraint [out_of_line_constraint]... }
| MODIFY CONSTRAINT constraint constraint_state
| RENAME CONSTRAINT old_name TO new_name
| drop_constraint_clause
}
drop_constraint_clause::= DROP
{ { PRIMARY KEY | UNIQUE ( column [, column]... ) }
[CASCADE] [{ KEEP | DROP } INDEX]
| CONSTRAINT constraint [CASCADE]
}
enable_disable_clause::= { ENABLE | DISABLE } [ VALIDATE | NOVALIDATE ]
{ UNIQUE ( column [, column]... )
| PRIMARY KEY
| CONSTRAINT constraint
}
D. Suppression de tables
drop_table::= DROP TABLE [schema .] table [CASCADE CONSTRAINTS];
truncate_table::= TRUNCATE TABLE [schema .] table [{ DROP | REUSE } STORAGE];

III. Langage de manipulation de données
A. Insertion de données
insert::= INSERT single_table_insert;
single_table_insert::= insert_into_clause { values_clause | subquery }
insert_into_clause::= INTO dml_table_expression_clause [t_alias] [( column [, column]... )]
values_clauses::= VALUES ( { expr | DEFAULT } [, { expr | DEFAULT }]... )
dml_table_expression_clause::= { [schema .]
{ table | view | materialized view } [ @ dblink ]
| ( subquery [subquery_restriction_clause] )
}
B. Mises à jour
update::= UPDATE
{ dml_table_expression_clause | ONLY ( dml_table_expression_clause ) }
[t_alias] update_set_clause [where_clause];
update_set_clause::= SET
{ { ( column [, column]... ) = ( subquery )
| column = { expr | ( subquery ) | DEFAULT }
}
[, { ( column [, column]... ) = ( subquery )
| column = { expr | ( subquery ) | DEFAULT }
}
]...
| VALUE ( t_alias ) = { expr | ( subquery ) }
}
where_clause::= WHERE condition
C. Suppression de données
delete::= DELETE [FROM]
{ dml_table_expression_clause | ONLY ( dml_table_expression_clause ) }
[t_alias] [where_clause];
IV. Schéma logique

A. Création d'une vue
create_view::= CREATE [OR REPLACE] [[NO] FORCE] VIEW [schema .] view
[ ( { alias [inline_constraint [inline_constraint]...]
}
[, { alias inline_constraint [inline_constraint]...
}
]...
)
]
AS subquery [subquery_restriction_clause];

B. Modification d'une vue
alter_view::= ALTER VIEW [schema .] view
{ ADD out_of_line_constraint
| MODIFY CONSTRAINT constraint { RELY | NORELY }
| DROP { CONSTRAINT constraint | PRIMARY KEY | UNIQUE ( column [, column]... ) }
| COMPILE
}
;
C. Suppression d'une vue

drop_view::= DROP VIEW [schema .] view [CASCADE CONSTRAINTS];
V. Schéma physique
A. Création
create_index::= CREATE [ UNIQUE | BITMAP ] INDEX [schema .] index ON
{ cluster_index_clause | table_index_clause | bitmap_join_index_clause };
cluster_index_clause::= CLUSTER [schema .] cluster index_attributes
table_index_clause::= [schema .] table [t_alias]
( index_expr [ ASC | DESC ] [, index_expr [ ASC | DESC ]]... )
[ index_attributes ]
bitmap_join_index_clause::= [schema .] table
( [schema .] [table] column [ ASC | DESC ]
[, [schema .] [table] column [ ASC | DESC ]]...
)
FROM [schema .] table [, [schema .] table]... WHERE condition
index_attributes
index_attributes::= [{ | logging_clause
| ONLINE | COMPUTE STATISTICS
| TABLESPACE { tablespace | DEFAULT }
| key_compression
| { NOSORT | REVERSE }
}
[ logging_clause
| ONLINE | COMPUTE STATISTICS
| TABLESPACE { tablespace | DEFAULT }
| key_compression
| { NOSORT | REVERSE }
]...
]
index_expr::= { column | column_expression }
create_cluster::= CREATE CLUSTER [schema .] cluster ( column datatype [, column datatype]... )
[{ SIZE integer [ K | M ]
| TABLESPACE tablespace
| { INDEX | [SINGLE TABLE] HASHKEYS integer [HASH IS expr] }
}
[ SIZE integer [ K | M ]
| TABLESPACE tablespace
| { INDEX | [SINGLE TABLE] HASHKEYS integer [HASH IS expr] }
]...
];
B. Suppression
drop_index::= DROP INDEX [schema .] index [FORCE];
drop_cluster::= DROP CLUSTER [schema .] cluster [INCLUDING TABLES [CASCADE CONSTRAINTS]];

VI. Langage de contrôle des transactions
commit::= COMMIT [WORK] [ COMMENT 'text' | FORCE 'text' [, integer] ];
rollback::= ROLLBACK [WORK] [ TO [SAVEPOINT] savepoint | FORCE 'text' ];
set_transaction::= SET TRANSACTION
{ { READ { ONLY | WRITE } | USE ROLLBACK SEGMENT rollback_segment } [NAME 'test']
| NAME 'test'
};
save_point::= SAVEPOINT savepoint;
lock_table::= LOCK TABLE
[schema .] { table | view } [, [schema .] { table | view } ]...
IN lockmode MODE [NOWAIT];
VII. Confidentialité
grant::= GRANT { grant_system_privileges | grant_object_privileges } ;
grant_system_privileges::= { system_privilege | role | ALL PRIVILEGES }
[, { system_privilege | role | ALL PRIVILEGES }]...
TO grantee_clause [IDENTIFIED BY password] [WITH ADMIN OPTION]
grant_object_privileges::= { object_privilege | ALL [PRIVILEGES] } [( column [, column]... )]
[, { object_privilege | ALL [PRIVILEGES] } [( column [, column]... )]]...
on_object_clause
TO grantee_clause
[WITH GRANT OPTION] [WITH HIERARCHY OPTION]
on_object_clause::= [ schema ] . object
grantee_clause::= { user | role | PUBLIC } [, { user | role | PUBLIC }]...
revoke::= REVOKE { revoke_system_privileges | revoke_object_privileges }
[, { revoke_system_privileges | revoke_object_privileges } ]...;
revoke_system_privileges::= { system_privilege | role | ALL PRIVILEGES }
[, { system_privilege | role | ALL PRIVILEGES }]...
FROM grantee_clause
revoke_object_privileges::= { object_privilege | ALL [PRIVILEGES] } [( column [, column]... )]
[, { object_privilege | ALL [PRIVILEGES] } [( column [, column]... )]]...
on_object_clause FROM grantee_clause [CASCADE CONSTRAINTS] [FORCE]
create_role::= CREATE ROLE role
[ NOT IDENTIFIED
| IDENTIFIED { BY password | USING [schema .] package | EXTERNALLY | GLOBALLY }
]
;
create_user::= CREATE USER user IDENTIFIED
{ BY password | EXTERNALLY | GLOBALLY AS 'external_name' }
[{ DEFAULT TABLESPACE tablespace
| TEMPORARY TABLESPACE tablespace
| QUOTA { integer [ K | M ] | UNLIMITED } ON tablespace
[QUOTA { integer [ K | M ] | UNLIMITED } ON tablespace]...
| PROFILE profile
| PASSWORD EXPIRE
| ACCOUNT { LOCK | UNLOCK }
}
[ DEFAULT TABLESPACE tablespace
| TEMPORARY TABLESPACE tablespace
| QUOTA { integer [ K | M ] | UNLIMITED } ON tablespace
[QUOTA { integer [ K | M ] | UNLIMITED } ON tablespace]...
| PROFILE profile
| PASSWORD EXPIRE
| ACCOUNT { LOCK | UNLOCK }
]...
]
;

Bases de Données - Sylvain BRANDEL

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Bases de Données - Sylvain BRANDEL

Transféré par

Droits d'auteur :

Formats disponibles

Université Louis Pasteur de Strasbourg

Pôle API UFR math-info

–2– Bases de données – master GPI – S. Brandel – 2007

–3– Bases de données – master GPI – S. Brandel – 2007

IV. Système de Gestion des Bases de Données (SGBD)

–4– Bases de données – master GPI – S. Brandel – 2007

B. Objectifs des SGBD

–5– Bases de données – master GPI – S. Brandel – 2007

Utilisateur LMD Menu Langage hôte

Schéma conceptuel SGBD

–6– Bases de données – master GPI – S. Brandel – 2007

D. Exemple de fonctionnement d'un SGBD

E. Implantation d'un SGBD

2) Processus clients – serveurs

–7– Bases de données – master GPI – S. Brandel – 2007

6) L'optimiseur de requêtes SQL

–8– Bases de données – master GPI – S. Brandel – 2007

–9– Bases de données – master GPI – S. Brandel – 2007

– 10 – Bases de données – master GPI – S. Brandel – 2007

– 11 – Bases de données – master GPI – S. Brandel – 2007

C. Mise en œuvre SQL

– 12 – Bases de données – master GPI – S. Brandel – 2007

3) Instruction SELECT simple

– 13 – Bases de données – master GPI – S. Brandel – 2007

Opérateurs arithmétiques (expressions)

Opérateur sur les chaînes (expressions)

Opérateurs de comparaison (conditions)

– 14 – Bases de données – master GPI – S. Brandel – 2007

– 15 – Bases de données – master GPI – S. Brandel – 2007

NOT V F NULL AND V F NULL OR V F NULL

c) Exercices employé / participe / projet

nom de l'attribut type descriptif

– 16 – Bases de données – master GPI – S. Brandel – 2007

b) Fonctions sur les chaînes de caractères

Fonctions renvoyant un nombre

– 17 – Bases de données – master GPI – S. Brandel – 2007

NUMBER CHAR DATE

- TO_CHAR(number | date [, format])

Conversion date – char

SELECT TO_CHAR(SYSDATE,'DD/MM/YYYY') today FROM Dual; → 20/02/2002

SELECT TO_DATE('12/25/95','MM-DY-YY') FROM Dual; → 25-DEC-95

– 18 – Bases de données – master GPI – S. Brandel – 2007

– 19 – Bases de données – master GPI – S. Brandel – 2007

Emp GROUP BY dpt Æ 3 groupes (G1 : lignes 1 et 2, G2 : ligne 3, G3 : lignes 4 et 5)

Restriction clause SELECT : SELECT suivi uniquement de :

– 20 – Bases de données – master GPI – S. Brandel – 2007

Restrictions pour les groupes : clause HAVING

Clause HAVING et requêtes imbriquées

– 21 – Bases de données – master GPI – S. Brandel – 2007

classe d'ass. classe d'ass. classe d'ass. classe d'ass.

a = nombre min d'occurrences de B liées à l'occurrence de A par A - B (∈ {0,1})

– 22 – Bases de données – master GPI – S. Brandel – 2007

5) Passage du modèle E/A au modèle relationnel

ETUDIANT <net, nom, âge, adresse>

– 23 – Bases de données – master GPI – S. Brandel – 2007

Homme Marié à Femme

Homme Marié à Femme

Possède Une occurrence de "Couple" = une occurrence de "Marié à"

– 24 – Bases de données – master GPI – S. Brandel – 2007

Atmosphérique Compressé Carburation Injection

Homme Femme Majeur Mineur

Association à tous les niveaux : Employé Travaille

Programmeur Chef de projet Secrétaire