B BD Support Coursbd6assurepareac

Conservatoire National des Arts et Métiers
CNAM
Bases De Données B6
Chapitre 2
INTRODUCTION A LA MODELISATION
CONCEPTUELLE DES DONNEES
Le modèle E-R de base /
le modèle E-R Etendu (EER)
2-1 Rappel : DONNEES ET TRAITEMENTS DANS UN
SYSTEME D’INFORMATION
Les données représentent l’aspect statique du système

d’information: Ce qui est. Les données présentent, dans
leur signification, une certaine stabilité et une invariance
dans le temps. Cette signification (sémantique) est
essentiellement déterminée par le type d’activité de
l’entreprise.
Les traitements représentent l’aspect cinématique du

système d’information: Ce qui se fait. Les traitements, et en
particulier leur organisation, présentent une plus grande
variabilité, en fonction essentiellement des besoins. Par
abus de langage on parlera de dynamique plutôt que de
cinématique.
2-1 Rappel : DONNEES ET TRAITEMENTS DANS UN
SYSTEME D’INFORMATION (suite)
L’analyse de données d’une part et celle des traitements

d’autre part ne s’effectue pas dans une ignorance
mutuelle: lorsque le concepteur analyse et spécifie les
données, il doit garder présent à l’esprit que la justification
d’une information est issue des traitements, sans pour cela
conditionner sa structuration.
Inversement, lors de l’analyse de la spécification des

traitements, le concepteur s’intéressera essentiellement au
fonctionnement du système d’information, sans
systématiquement associer les informations utilisées.
2-2 : OBJECTIFS
Le Modèle Conceptuel de Données (MCD) est un

moyen très efficace pour :
représenter de manière structurée, synthétique et fidèle les
données du système d’information indépendamment de
son implantation physique.
comprendre le fonctionnement du système d'information.
communiquer entre les différents acteurs
construire le référentiel de l ’entreprise ou du projet
(dictionnaire des données).
documenter le système d ’information.
2-3 Le modèle E-R
Un modèle conceptuel de données
Modèle Entité-Relation ou modèle Entité-Association
Proposé par P. Chen en 1976
Différentes extension ont été proposées
L’ANSI choisit le modèle E-R comme standard en 1988

REGLES DE CONSTRUCTION
Le Modèle E-R comprend:
des entités,
de relations ou associations
des propriétés / attributs - valeurs
des contraintes.
dans les définitions qui suivent, les différents synonymes

acceptés sont indiqués
ENTITE
objet ayant une existence dans le monde réel, et

identifiable CLIENT COMMANDE FOURNISSEUR
synonymes: Individu
PRODUIT ANNEE DATE LIVRAISON
BUDGETAIRE
Attention à la modélisation du TEMPS:

seuls les objets temporels correspondant réellement à une REFERENCE et
utiles au pilotage du système doivent être modélisés comme individus (ex:
Année Budgétaire, Journée à Planifier)
ceux qui concrétisent un EVENEMENT de gestion ne deviennent pas des
individus (ex: Date Livraison)
RELATION ou ASSOCIATION
association entre entités précisant un fait naturel

CLIENT relation COMMANDE
PASSE
0,N 1,1
pattes
cardinalités
Une relation est composée de pattes.
Chaque patte est associée à un individu et permet d'indiquer
le rôle joué par celui-ci dans la relation
RELATION : Particularités
Relation binaire MARIAGE
c ’est une relation entre deux

entités
Relation n-aire 1,1
CONCLUENT
possède n pattes, avec n>2.
0,N 0,N
Une relation ternaire possède 3 HOMME FEMME
pattes (ternaire), quaternaire 4
pattes, ...
Relation récursive associe un
individu à lui-même EST SOUS-TRAITE
FOURNISSEUR 0,N
les 2 pattes de la relation sont SOUS-TRAITE
liées au même individu
EST SOUS-TRAITANT
0,N
Occurrence / cardinalité
Occurrence:
élément d'un individu ou d'une relation
synonymes: ligne, tuple, enregistrement
LEFEVRE COMMANDE #4
MARTIN/#4
MARTIN COMMANDE #3
MARTIN/#3 COMMANDE #2
DURAND
DUPOND DUPOND/#2 COMMANDE #1
CLIENT DUPOND/#1 COMMANDE
PASSE
0,N 1,1
Cardinalité d'une relation:

nombre de fois minimum et maximum où une occurrence
d'un individu participe à une relation
RELATION
(exemples de cardinalités 1/2)
POSTE FACTURE LIGNE FOURNISSEUR

COMMANDE
1,1 1,1 1,1 1,N

PORTE SUR EST DETAILLE EN FOURNIT
EST AFFECTE
1,1 0,1 0,N 0,N
EMPLOYE COMMANDE COMMANDE PRODUIT
A 1 Poste 1 Commande peut 1 Commande 1 Fournisseur délivre

est TOUJOURS affecté donner lieu à 1 Facture peut être composée de plusieurs Produits,
1 et 1 seul Employé, (ce n'est pas obligatoire). aucune ou plusieurs Lignes AU MOINS 1.
et inversement Chaque Facture correspond (ce n'est pas obligatoire). Chaque Produit peut
à 1 et 1 seule Commande Chaque Ligne correspond être fourni par aucun
à 1 et 1 seule Commande. ou plusieurs Fournisseurs.
cardinalité MIN: 0 ou 1 cardinalité MAX: 1 ou N
RELATION
(exemples de cardinalités 2/2)
ARBORESCENCE:
PERE
toute Personne
MEMBRE est Enfant MARIAGE TERNAIRE:
DEV1/DEV2 0,N
EST PERE DE de 0 (=Adam 1 Homme (ou 1 Femme)
& Eve) peut n'avoir conclu
ou 1 seul Père, aucun Mariage, ou
ENFANT
et peut lui-même plusieurs.
0,1 être Père d'aucun Mais 1 Mariage est
ou plusieurs 1,1 toujours conclu entre 1
Enfants Homme et 1 Femme.
CONCLUENT
RESEAU:
PLUS toute Personne
AGE 0,N 0,N
MEMBRE peut n'avoir
DEV1/DEV2 0,N
aucun
EST AMI DE HOMME FEMME
ou plusieurs
PLUS Amis
JEUNE plus âgés
0,N ou plus jeunes,
et inversement.
cardinalités de relations réflexives et n-aires
RELATION
(stabilité de la cardinalité)
PRODUIT PRODUIT PRODUIT PRODUIT
0,N 1,N 1,N 0,N

FOURNIT EST FOURNI PAR FOURNIT PRODUIT PEUT FOURNIR
1,N 0,N 1,N 0,N

FOURNISSEUR FOURNISSEUR FOURNISSEUR FOURNISSEUR
Le Produit doit Le Fournisseur doit Le Produit Produit/Fournisseur

OBLIGATOIREMENT OBLIGATOIREMENT ET le Fournisseur peuvent être
PRE-EXISTER au Fournisseur PRE-EXISTER au Produit doivent créés/suppr.
1) création Produit 1) création Fournisseur TOUJOURS INDEPENDAMMENT
2) création Fournisseur 2) création Produit
et raccrochage
être puis être raccrochés
et raccrochage
SIMULTANE au Produit SIMULTANE au Fournisseur créés/supprimés à tout moment
cardinalité MIN:
3) suppression du Fournisseur
AVANT son dernier Produit 0Produitou
AVANT1
3) suppression du
cardinalité
son dernier Fournisseur MAX:
SIMULTANEMENT 1 ou N
les cardinalités doivent être vérifiées A TOUT INSTANT
PROPRIETE
(d’entité ou de relation)
caractéristique élémentaire décrivant un individu ou

une relation CLIENT COMMANDE
- Raison sociale PASSE - N° Commande

0,N 1,1
- Nom - Date Commande
- Adresse - Date Livraison
synonymes: attribut, - Téléphone
rubrique PRODUIT 1,N
COMPREND
Attention aux propriétés polysèmes et synonymes: - Réf Produit 0,N - Quantité
- Désignation - Prix
Polysèmes: des propriétés possédant le même nom peuvent désigner des notions différentes
(ex: Date,...)
Synonymes: des propriétés possédant des noms différents peuvent désigner une notion
identique
TYPES DE PROPRIETE
Propriété naturelle
Nom d’un employé
Propriété composée:
Numéro INSEE: sexe+année+mois+département+ commune+chrono
Adresse : No-rue, rue, code postal, ville, ...
On peut opter pour deux modélisations différentes:
Considérer cette propriété «construite» comme une propriété normale ayant
une signification intrinsèque et globale.
Considérer cette propriété comme une concaténation des propriétés et chaque
composant possède une signification propre.
Propriété artificielle
Propriétés inventés par le concepteur pour identifier une entité (No.
séquentiel, codes, etc. en sont l’illustration).
CLE
(d'individu ou de relation)
combinaison minimale de FOURNISSEU

Clé Clé
COMMANDE
R
propriétés permettant - Catégorie
Composée Simple - N° Commande
de reconnaître UNE - Pays

- N° Fournisseur
occurrence d'individu / -Adresse
- Date Commande
- Date Livraison
relation de manière 0,N

1,N
unique
FOURNIT COMPREND
synonymes: identifiant - Quantité Min

- Quantité Max - Quantité
- Délai - Prix
0,N
la clé d'une relation est - Catégorie 0,N
constituée à partir des clés - Pays
- N° Fournisseur
PRODUIT
- N° Commande
des individus participant à
la relation +
- Réf Produit - Réf Produit
+
- Réf Produit
- Désignation
CARACTERISTIQUES D’UNE CLE
Univaluée :
à une occurrence correspond une seule valeur pour une clé donnée
Discriminante :
à une valeur correspond une seule occurrence de l’entité;
Stable :
Pour une occurrence donnée d’entité, une fois affectée une valeur à son
identifiant, cette valeur doit être conservée jusqu’à la destruction de
l’occurrence.
Minimale :
S’agissant d’un identifiant composé, la suppression d’un de ces
composants lui ferait perdre son caractère discriminant.
CLE CANDIDATE
un individu/relation peut posséder une ou plusieurs clés

distinctes, appelées clés candidates.
synonymes: clé équivalente
Ces clés peuvent avoir des propriétés en commun ou non.

Clé primaire: clé candidate le plus souvent utilisée
EMPLOYE LIGNE Autre

Clé Primaire COMMANDE Clé Candidate
Clé Primaire Autre - N° Commande
- N° Matricule
- N° Sécurité Sociale
Clé Candidate + - Réf Produit
+
- Nom - N° Ligne dans la
- Prénom Commande
Les mécanismes d ’abstraction
Classification
Regrouper dans une classe les objets du monde réel
caractérisés par des propriétés communes
Agrégation
Définir une classe à partir d ’autres classes composantes
Généralisation
Définit une relation d ’inclusion entre deux classes (n ’est pas
utilisé dans les modèles classiques E-R de base)
Sous types
VEHICULE
Un SOUS-TYPE correspond à la
spécialisation d’un INDIVIDU
VOIITURE MOTO
Il permet par exemple de

particulariser les RELATIONS
1,1 0,1
0,2 0,2
DIRIGE ACCOLE A
liées à cet INDIVIDU 0,2
PAIRE 0,1
0,1
TRAIN AVANT
VOLANT SIDE-CAR
TRAIN AVANT
0,1 0,1
0,1
ROUE
SOUS-TYPE de RELATION
De la même manière, on peut avoir des SOUS-TYPES

de RELATION, afin de particulariser les différents cas
d’association
COMMANDE
FERME
0,N
1,N
COMMANDE CLIENT
1,N CONTIENT 0,N
1,N 0,N
COMMANDE
NON FERME
CONTRAINTE INTER RELATIONS
(Définition)
Formalisme INCLUSION (I): si une occurrence de l’Individu1

INDIVIDU 2 participe à la relation A, elle participe à la
Individu impliqué dans
relation B ( mais pas réciproquement)
la contrainte SIMULTANEITE(S): Toute occurrence de
l’Individu1 participant à la relation A participe
simultanément à B
A
EXCLUSION(X): Si une occurrence de l’Individu1
INDIVIDU 1
participe à la relation A, elle ne peut pas
participer à B (avec possibilité d’orientation de cette exclusion)
TOTALITE(T) :Toute occurrence de l’Individu1
B participe au moins à l’une des deux relations A
ou B
EXCLUSION et TOTALITE(XT): Toute occurrence
INDIVIDU 3 de l’Individu1 participe au moins soit à A, soit à
Type de
contrainte
B, mais pas aux deux à la fois
MCD:
LA DEMARCHE DE CONSTITUTION
Employé Fonction
1,1 a pour fonction 0,n
Non Navigant Navigant
Administratif Mécanicien Steward Hôtesse Copilote Pilote
0,n
0,n
0,n
est Steward ou Hôtesse du vol

Ville
0,n 0,n est Copilote du vol

0,n
0,n 0,n
0,n 0,n
départ prévu de départ réel de est Pilote du vol
E
étape prévue à étape réelle à
retour prévu à retour réel à
0,n
1,1
1,1 1,1
0,n
1,1 1,1
1,1 0,n
Catalogue Vol Prévu Vol Réel
est décrit par est basé sur
0,n 1,1 0,n 0,n
0,n 1,1 1,1
1,n 1,1
est planifié pour se déroule le
Vol Catalogue
0,n 0,n
Date
0,n
I
Jour Hebdomadaire peut utiliser utilise effectivement
0,n Avion
0,n
1,1 0,n
a pour type a subi
0,n 1,1
Type Avion Révision
DEMARCHE DE CONSTITUTION
D’UN MCD (1/3)
Une démarche DEDUCTIVE qui s’appuie sur

l’existence préalable
d’une liste
d’informations
à structurer
le discours est décortiqué en informations élémentaires.
Une démarche INDUCTIVE qui

met rapidement en évidence
les différents concepts
évoqués dans le discours
puis les décrit par des informations.
D’UN MCD (2/3)
Ces deux approches

ne sont nullement antagonistes
et coexistent alternativement
dans la pratique.
La démarche déductive est plus lourde. Le concepteur doit d’abord
constituer une liste quasi exhaustive de données.
La démarche inductive est plus efficace. Le concepteur peut

directement, à l’aide du formalisme, construire le MCD.
D’UN MCD (3/3)
Dans les deux cas,

la base essentielle reste
le discours (parlé ou écrit) de l’utilisateur,
exprimé en langue naturelle.
Les mots utilisés comprennent les termes usuels de la
langue, mais aussi des termes spécialisés du domaine.
Les phrases fournissent, après analyse grammaticale, les

principaux individus et associations entre individus
CONSTITUTION D’UNE LISTE D’INFORMATIONS (1/2)
Deux procédés:
Ratisser, au gré des entretiens, les informations
présentes sur quelques documents papiers
(imprimés) ou dans des fichiers.
Exprimer les messages associés aux événements
et résultats, et spécifiés dans le MCT.
Dans ce cas, confronté à des événements/résultats traduisant un flux
physique ou monétaire (bon de commande, facture, règlement, ...), le
concepteur doit le traduire en terme d’informations (d’où un choix de
représentation).
CONSTITUTION D’UNE LISTE D’INFORMATIONS (2/2)
Pour chaque information recueillie, le concepteur doit, avant

de l’ajouter à la liste déjà établie, répondre aux questions
suivantes:
La nouvelle information n’a-t-elle pas déjà été répertoriée (code client par
exemple)?
La nouvelle information a été déjà répertoriée mais sous une appellation
différente.
===> SYNONYME (référence dossier et no. police par ex.)
Une appellation identique existe déjà pour la nouvelle information mais
associée à une signification différente. ===> POLYSEME (date de
livraison par exemple: date de livraison demandée ou date de livraison
effective?).
Chapitre 3
Introduction au modèle relationnel

et passage du modèle E-R au
modèle relationnel
3-1 Introduction au modèle relationnel
Proposé par CODD (Université Saint José) en 1971

Caractéristiques principales
simplicité des concepts
facilité d ’utilisation
standardisation du langage de définition des données et du
langage d ’interrogation: SQL
pauvreté sémantique due au fait qu ’il n ’y a qu ’un seul
concept: la relation (ou table) pour représenter une entité,
une association ou une sous classe
pas de représentation graphique
existence d ’une théorie sous-jacente
3-2 Le modèle relationnel
Les concepts de base
Concepts structuraux
Le modèle relationnel s’appuie sur trois concepts structuraux de base: le
domaine, la relation (ou table) et l’attribut.
Le domaine est un ensemble de valeurs caractérisé par un nom.
Exemples: le domaine des entiers E= {0,+/- 1, +/-2, ...}; le domaine
des booléens D1= {0,1}; le domaines des couleurs possibles D2=
{vert, bleu,blanc,rouge}; le domaine des caractères...
La relation, concept central du modèle, peut être définie
grossièrement comme un tableau de données à deux dimensions.
Les colonnes de ce tableau sont appelées attributs. Les lignes de
ce tableau, occurrence de la relation, seront appelées tuples ou n-
uplets
Chaque attribut peut prendre des valeurs dans un domaine.
(suite)
Schéma de relation : Nom de la relation suivi de la liste des

attributs et de la définition de leurs domaines.
Schéma relationnel: Ensemble des schémas de relation
Clés
Clé candidate : Ensemble d’attributs minimal dont la
connaissance des valeurs permet d’identifier un tuple unique de
la relation considérée.
Clé primaire : Elle est choisie parmi les clés candidates.
Clé étrangère : C’est un constituant ou un ensemble de
constituants d’une table apparaissant comme une clé primaire
dans une autre relation.
(suite)
Contraintes d’intégrité :
Est un prédicat que doit vérifier un sous ensemble de la base afin que l’on puisse
considérer les informations comme cohérentes. Le rôle des contraintes
d’intégrité est d’assurer la cohérence des données.
On peut isoler plusieurs types de contraintes d’intégrité :
Contrainte de domaine : Concerne le contrôle syntaxique et sémantique d’une
donnée, et fait référence au type de définition du domaine.
Contrainte déclarative : Contrainte imposée sur des attributs (valeur nulle, valeur
par défaut, clé primaire, liste de valeurs,.)
Contrainte référentielle : Impose que le valeur d’un attribut dans une relation
apparaisse comme valeur de clé dans une autre relation (Clé étrangère --> Clé
primaire).
Contrainte d’entité : Contrainte d’intégrité imposant que toute relation possède
une clé primaire et que tout attribut participant à cette clé primaire soit non
nul.
Les concepts additionnels
Valeur nulle : Valeur conventionnelle introduite dans une relation pour

représenter une information inconnue ou inapplicable.
Agrégat : Partitionnement horizontal d’une relation en fonction des valeurs
d’un groupe d’attributs, suivi d’un regroupement par application d’une
fonction de calcul sur ensemble.
Les fonctions de calcul sur ensemble les plus souvent proposées sont les
suivantes :
Somme (SUM) permettant de calculer la somme des éléments d’un ensemble;
Moyenne (AVG) permettant de calculer la moyenne des éléments d’un ensemble;
Minimum (MIN) permettant de sélectionner l’élément minimum d’un ensemble;
Maximum (MAX) permettant de calculer l’élément maximum d’un ensemble;
Compte (COUNT) permettant de compter les éléments d’un ensemble.
(suite)
Expression d’attributs : Expression arithmétique construite à partir d’attributs

d’une relation et de constantes, par application de fonctions arithmétiques
successives.
exemples :
Salaire = Salaire * 1,10,
Revenu-Annuel = (Salaire-Mensuel * 13,5) + (Commission / 120)
Vue (View) : Une vue est une table virtuelle (c ’est-à-dire non stockée telle
qu ’elle) regroupant les données dont un utilisateur a besoin.
Une vue est donc virtuelle, elle n’a donc pas d’existence physique, au moins
lorsqu’elle n’est pas accédée.
Elle peut être obtenue à partir soit par sélection des attributs d ’une ou des
plusieurs tables (jointure)
Elle peut être interrogée comme une table normale de la base.
(suite)
Réflexe (Trigger) : Evénement déclenché suite à l’apparition d’une condition

particulière dans la base de données provoquant l’exécution d’un
programme de traitement de la base composé d’une ou plusieurs requêtes.
Un trigger peut être déclenché en réaction à une opération sur donnée (mise à
jour d’une table, d’un tuple) ou suite au passage à vrai d’une condition sur
valeurs de données (critère de sélection ou de jointure).
Un trigger est défini au niveau du schéma de la base. Il permet d’intégrer
certains traitements constituant des règles communes à la base, par
exemple le maintien des contraintes d’intégrité ou des données
redondantes.
Procédures : Programme écrit en pseudo-langage procédural offert par le
SGBD. Il est stocké dans le dictionnaire de données après compilation.
Les résultats de la phase de “parsing” et de la phase de détermination du
chemin d’accès sont stockés avec le procédure permettant une meilleure
performance.
Convention de formalisme
Formalisme
La table, ses attributs et sa clé primaire
EMPLOYES
Matricule Notons que, dans cette représentation, le ou les

Nom attributs composants la clé primaire sont soulignés
Date_emb
Code_dept
Contraintes d’intégrité référentielle
EMPLOYES DEPARTEMENT
Code-dept de la table Employés
Matricule est clé étrangère et pointe vers Code-dept
Nom l’attribut Code-dept clé primaire
de la table Département Nom
Date_emb Adresse
Code_dept
3-5 Du modèle E-R au modèle Relationnel
La démarche
Employé Fonction
1,1 a pour fonction 0,n
Non Navigant
R1(...........)
Navigant
Administratif Mécanicien Steward Hôtesse Copilote Pilote

R2(...........)
0,n
0,n
0,n
R3(...........)
0,n
Ville
0,n
est Steward ou Hôtesse du vol
est Copilote du vol

R4(...........)
.
0,n
0,n 0,n
0,n 0,n
départ prévu de départ réel de est Pilote du vol
E
.
étape prévue à étape réelle à
retour prévu à retour réel à
1,1
1,1
0,n
0,n
1,1
1,1
0,n
1,1
1,1
.
Catalogue Vol Prévu Vol Réel
est décrit par est basé sur
0,n 1,1 0,n 0,n
0,n 1,1 1,1
1,n 1,1
est planifié pour se déroule le
.
Vol Catalogue
0,n 0,n
Date
0,n
Rm(...........)
I
Rn(...........)
Jour Hebdomadaire peut utiliser utilise effectivement
0,n Avion
0,n
1,1 0,n
a pour type a subi
0,n 1,1
Type Avion Révision
Du modèle E-R au modèle Relationnel
Règles de construction
Toute entité du modèle E-R est traduite en une relation du modèle

relationnel avec les attributs correspondants
Toute association 1-N est traduite par le report de l ’identifiant
côté 1 (ensemble d ’arrivée) dans l ’association traduisant
l ’autre entité côté N (ensemble de départ), (c ’est une
application mathématique)
Toute relation M-N est traduite par une association spécifique
avec les identifiants des entités participantes et les attributs
propres à l ’association.
Les associations 1-1 sont tantôt fusionnées, tantôt traduites par
des reports d ’identifiants (2ème règle), ou encore par une
relation spécifique (3ème règle) selon des considérations de
manipulation et de volume.
Relation binaire (0,n) - (1,1) ou (1,n) - (1,1)
PERSONNE MAISON
(0,n) ou (1,1)
Id-A POSSEDER Id-B
(1,n)
Formalisme Entité-Relation
PERSONNE MAISON
Id-A Id-B
POSSEDER
Id-A
Formalisme graphique relationnel

(suite)
Relation binaire (0,n) - (0,1) ou (1,n) - (0,1)

PERSONNE VOITURE
(0,n) ou (1,n) POSSEDER (0,1)
Id-A Date-acquisition Id-B

Solution 1: POSSEDER
Id-B
PERSONNE Id-A VOITURE
date-acquisition
Id-A Id-B
Solution 2:
PERSONNE VOITURE
POSSEDER Id-B
Id-A
Id-A
(suite)
Relation binaire (0,1) - (1,1)
EDIFICE MAISON
(0,1) (1,1)
Id-A Est-un Id-B
EDIFICE MAISON
Id-A Id-B
Est-un
Id-A

(suite)
Relation binaire (0,1) - (0,1)
ENTREPRISE TIERS
(0,1) (0,1)
Id-A CORRESPONDRE Id-B
Solution 1
ENTREPRISE TIERS
Id-A Id-B
CORRESPONDRE
Id-A

(suite)
Solution 2
ENTREPRISE TIERS
Id-A Id-B
CORRESPONDRE
Id-B
Solution 3
CORRESPONDANCE
ENTREPRISE TIERS
Id-A Id-A Id-B
Id-B
Solution 4 idem solution 3 en inversant les clés

(suite)
Relation binaire (*,n) - (*,n)
COMMANDE ARTICLE
(*,n) PORTER (*,n)
Id-A Qté-cdée Id-B
PORTER
COMMANDE Id-A ARTICLE
Id-A Id-B
Id-B
Qté-cdée

(suite)
Relation binaire réflexive
TACHE (*,1) Suit

Id-A
PRECEDER
(*,n) Précède
Solution 1 Solution 1 associée à un choix

TACHE
d’optimisation : accepter des
Id-A
Id-A-précède valeurs nulles sur l’attribut
..... migrant.

(suite)
Relation binaire réflexive

Solution 2
TACHE PRECEDER
Précède
Id-A Id-A
Id-A
....... Id-A-précède
Id-A-suit
.....
....
Suit

(suite)
Relation binaire réflexive (*,n) - (*,n)
TRAVAUX (*,n) Elément

Id-A
DECOMPOSER
(*,n) Ensemble
TRAVAUX DECOMPOSER
Ensemble
Id-A Id-A
..... Id-A-Ensemble
Elément

(suite)
Relation ternaire ou supérieure

MAISON 0;n ENTREPRISE
id-A 0;n id-B
..... REALISER ......

0;n
TYPE-TRAVAUX
MAISON ENTREPRISE
id-C REALISER
.... id-A id-B
..... id-A ......
id-B
id-C
.....
TYPE-TRAVAUX
id-C
....
(suite)
SPECIALISATION Solution 2 Personne

Formalisme Entité-Relation Id-A
Personne Etudiant X Enseignant
Id-A Id-A Id-A
x X X
Y Z
Etudiant Enseignant
Y Z Solution 3
Etudiant Enseignant
Id-A Id-A
X X
Solution 1 Personne Y Z
Id-A
X Solution 4 Personne
Etudiant Enseignant Id-A
Id-A
Id-A Z
X
Y Y
Type-personne
(suite)
GENERALISATION
Rappel: les sous types ont leurs propres identifiants
TIERS
Id-A Formalisme graphique relationnel
x TIERS
Client Fournisseur Id-A
Id-B Id-C X
Y Z Fournisseur
Client
Id-B
Id-B
Y
Y
Id_A
Id_A
x
x
(suite)
Identifiant relatif
Rappel: Certaines entités ont une existence totalement
dépendante d’autres entités
exemple: Formalisme Entité-Relation
Projet Tranche
No. projet 1,N Comporter 1,1
No.ordre
X Y

Projet Tranche
No. projet Comporter
No.projet
X No.ordre
Y
Cas particulier : Historisation
Historisation
Historisation de propriété
Propriété portant le caractère historisable (H) au niveau du
non de la propriété concernée
Historisation d’entité
Entité portant le caractère historisable (H) au niveau du
nom de l’entité concernée
Historisation de relation
Relation portant le caractère historisable (H) au niveau du
nom de la relation concernée
Historisation de propriété
PERSONNE PERSONNE H-adresse-personne
No-personne No-personne No-personne
nom nom Date-Histo
adresse (H) adresse adres-antérieure
Historisation d’entité
PERSONNE(H) PERSONNE Histo-Personne
No-personne No-personne No-personne

nom nom Date-histo
adresse adresse nom
adresse
Historisation de relation
Personne Logement
Personne No.personne Adresse
No.personne nom surface
nom adresse nb-pièces
adresse
0,N Louer
Adresse
Louer (H) No.personne
Loyer-mensuel
Loyer-mensuel
0,N Histo-Louer
Logement
Adresse Adresse
surface No.personne
nb-pièces Date-histo
Loyer-mensuel
Cas particulier : contraintes inter associations
Contraintes inter associations (inclusion, exclusion,

simultanéité, ...)
Ces contraintes seront prises en compte au niveau logique
des traitements par l’écriture des TRIGGER spécifiques par
exemple.
1 BUG dans 1 programme
1 Programme impacté
1 Donnée N programmes
Erronée impactés
Chapitre 6
Structure logique et physique

d ’une base de données
relationnelle (Oracle)
6-1 Introduction
Selon l’architecture ANSI/SPARC, une base de données est représentée en

trois niveaux :
- le niveau conceptuel (logique),
- le niveau physique ,
- le niveau externe.
Cette séparation permet, d’une part, une indépendance entre la sémantique
des données et leur implémentation physique, et, d’autre part, de donner
des visions restreintes et adaptées à chaque type d’utilisateur.
L’un des principaux rôles du SGBDR est de permettre la description de chacun
de ces trois niveaux et d’assurer la correspondance entre eux.
ORACLE, SYBASE, ... respectent cette architecture. Toute base de données a
ainsi une structure logique et une structure Physique. Les utilisateurs
peuvent avoir des visions partielles de la structure logique à travers des
vues.
La description de ces trois niveaux et la correspondance entre eux est faite à
travers un dictionnaire de données.
6-2 Rappel : Schéma de la base de données Oracle
Un schéma est un ensemble de structures logiques de données qui

appartiennent à un utilisateur de la base de données et porte son nom. De
ce fait, un utilisateur ne peut avoir qu’un seul schéma.
Les objets qui peuvent être manipulés dans un schéma sont les suivants :
Table : une table est une structure relationnelle qui maintient les données d’une
base de données relationnelle. Une table représente une entité du monde réel
ou une relation entre deux entités.
Index : un index est une structure contenant l’adresse physique de chaque ligne
d’une table ou d’un cluster. Un index permet l’accès direct à l’information.
Vue : CF. Cours “ Le modèle relationnel ”.
Trigger (déclencheur) : CF. Cours “ Le modèle relationnel ”.
Procédure : une procédure est un ensemble nommé de commandes PL/SQL qui
sont stockées dans la base de données.
Fonction : une fonction est un ensemble nommé de commande PL/SQL. Elle
retourne une valeur à l’appelant contrairement à une procédure.
Schéma de la base de données Oracle
(suite)
Package : un package est une collection de fonctions, de procédures et d’autres

objets stockés ensemble au sein d’une base de données.
Séquence : une séquence est un objet de la base de données à partir duquel
plusieurs utilisateurs peuvent générer des entiers uniques.
Snapshot : un snapshot (cliché) est une table qui contient le résultat d’une requête
définie sur une ou plusieurs tables ou vues localisées sur une base de données
appelée “ base maître ”. Les snapshots sont utilisés dans le contexte réparti et
permettent de maintenir des copies de données de la base distante sur le noeud
local en lecture seulement.
Cluster : un cluster (groupement) est un objet du schéma contenant une ou
plusieurs tables qui ont une ou plusieurs colonnes communes. Un cluster est
une structuration de données dans une ou plusieurs tables pour permettre un
accès rapide aux lignes issues d’une jointure.
Lien de base de données (Database link) : un lien de base de données est un
objet dans la base locale qui permet l’accès à une base de données distante.
6-3 Structure logique
La structure logique d’une base de données ORACLE est composée des tablespaces,
des segments, des extensions, des blocs et des objets de schéma.
Les tablespaces, les segments et les extensions permettent de définir la façon dont la
base de données (avec ses objets de schéma) est organisée physiquement. Ils
permettent donc d’effectuer le lien entre le niveau physique et le niveau logique de la
base de données.
Notion de tablespace : Une base de données est composée d’un ensemble d’unités
logiques appelées tablespaces.
Un tablespace est utilisé pour regrouper un ensemble d’objets logiques. Chaque objet
logique doit être associé à un et à un seul tablespace.
On peut utiliser cette notion de tablespace pour regrouper, par exemple, des objets
logiques d’une application (tables, index, séquences, procédures, etc.) de façon
que des opérations telles la sauvegarde et la restauration de données soient
effectuées d’une façon efficace.
Une base de données doit avoir au moins un tablespace appelé SYSTEM qui contient le
dictionnaire de données. Il est fortement conseillé de définir au moins un deuxième
tablespace pour stocker les objets de la base.
Structure logique
(suite)
La création de tablespace doit se faire avec la commande suivante :

CREATE TABLESPACE nom-tablespace
DATAFILE spécif-fichier [, spécif-fichier,...]
[DEFAULT STORAGE (spécif-stockage)]
[ONLINE | OFFLINE]
nom-tablespace : nom du tablespace à créer
spécif-fichier : spécification du fichier physique de données (nom, taille)
spécif-stockage : Paramètres applicables par défaut à tous les objets affectés à ce
tablespace. Cf. paragraphe “ EXTENSION ” : clause STORAGE .
ONLINE : le tablespace est actif dès qu’il est créé.
OFFLINE : le tablespace est inactif après sa création
Exemple : CREATE TABLESPACE ts_logistique
DATAFILE ‘/usr1/base/fichier1.dbf’ SIZE 1 M
‘/usr2/base/fichier2.dbf’ SIZE 1 M
DEFAULT STORAGE (INITIAL 100K NEXT 100K
MINEXTENT 1 MAXEXTENT 5 PCTINCREASE 50)
Structure logique
(suite)
Segment, Extension et Bloc .

Lors de la création d’un fichier, Oracle réserve tout l’espace qui lui est associé. A
l’intérieur de ce fichier, l’espace disque est géré dynamiquement au fur et à
mesure de l’utilisation de la base de données.
Cette gestion dynamique se fait selon trois niveaux de granularité : le segment,
l’extension et le bloc.
Le niveau le plus fin de granularité est le bloc. Il est composé d’un certain nombre
d’octets. Sa taille est définie au moment de la création de la base de données.
l’extension (l’extent) constitue le deuxième niveau de granularité. C’est une suite de
blocs contigus alloués simultanément et utilisés pour le stockage d’un type
spécifique de données.
Structure logique
(suite)
Segm ent - Extension - Blocs

SEGM ENT 1
Extension 1 Extension2
BLOC
Un segment correspond à un ensemble d’extensions allouées à une structure

logique (DATA SEGMENT, INDEX SEGMENT, ROLLBACK SEGMENT,
TEMPORARY SEGMENT,
Structure logique
Bloc de données
Un bloc de données est la plus petite unité logique d’entrée/sortie utilisée par
Oracle. il est également appelé bloc logique ou page. Cette notion de bloc
de données est différente de celle de bloc physique utilisé par les systèmes
d’exploitation.
La taille d’un bloc de données est variable selon les systèmes d’exploitation.
Elle peut varier généralement de 2 à 4 Ko. La modification de la taille par
défaut des blocs logiques se fait à travers le paramètre DB_BLOCK_SIZE
dans le fichier d’initialisation (INIT.ORA).
Les blocs de données sont organisés de la même façon, quel que soit leur
contenu : données, Index ou Cluster.
Structure logique
Extension
L’extension est une unité logique d’allocation d’espace composée d’un ensemble
contigu de blocs allouées simultanément à un segment. Tout segment est
initialement créé avec au moins une extension. Cette extension est appelée
extension initiale . Lorsque l’espace d’un segment est complètement utilisé, Oracle
lui attribue une nouvelle extension (extension supplémentaire).
Paramètres relatifs à l’utilisation des extensions : Ces paramètres sont définis à
l’aide de clause STORAGE.
STORAGE (INITIAL n1 EXTENT n2 MINEXTENT m1 MAXEXTENT m2
PCTINCREASE p)
avec
n1 : Taille en octet de la première extension allouée lorsqu’un segment est créé.
n2 : Taille en octets de la deuxième extension allouée au segment.
m1 : Nombre d’extensions allouées à la création du segment.
m2 : Nombre total d’extensions pouvant être allouées à un segment.
p : Pourcentage d’accroissement de la taille du segment i+1 par rapport à celle du
segment i (i>2).
Structure logique
Extension
Exemple :
STORAGE (INITIAL 100K NEXT 100K MINEXTENT 1 MAXEXTENT 5 PCTINCREASE 50)
La taille des différentes extensions est la suivante :
1ère extension : 100 K
2ème extension : 100 K
3ème extension : arrondi (100*1,5) = 150 K
4ème extension arrondi (150*1,5) = 225 K
5ème extension arrondi (225*1,5) = 337 K
Remarque : La clause STORAGE peut être utilisée dans des différentes commandes de création ou
de modification d’objets Oracle (tables, index, etc.). Si cette clause est définie à différents
niveaux, l’ordre de priorité est le suivant :
Tout paramètre défini au niveau d’un objet Oracle remplace celui défini au niveau du tablespace.
A tout paramètre non défini au niveau d’un objet Oracle est appliquée par défaut la valeur définie au niveau
tablespace.
En cas d’absence de définition de paramètres au niveau du tablespace, Oracle applique des valeurs par
défaut.
Si des paramètres sont modifiés, les nouvelles valeurs s’appliquent uniquement aux extensions non encore
allouées.
Structure logique
Segment
Un Segment est un ensemble d’une ou plusieurs extensions contenant les

données d’une structure logique dans un tablespace. A une table, par
exemple, est allouée une ou plusieurs extensions.
Il existe cinq types de segments :
Segments de données,
Segments d’index,
Segments d’annulation (rollback),
Segments temporaires,
Segments d’amorçage (bootstrap).
SEGMENTS DE DONNEES
Les segments de données servent à stocker les données des tables utilisateurs et système
ainsi que celles des tables groupées (cluster).
Chaque table a un et un seul segment qui contient toutes les données de la table. Ce
segment est créé automatiquement lors de la création de la table.
La manière dont les extensions sont allouées dans un segment est précisée à l’aide des
paramètres de stockage explicités lors de la création d’une table ou d’un cluster.
Structure logique
Segment
SEGMENTS D’INDEX
Les segments d’index servent à stocker les données d’index séparément des données. Chaque index est
contenu dans un segment distinct. Ce segment est créé automatiquement lors de la création d’index.
Lors de la création d’index, on peut préciser le tablespace dans lequel sera créé le segment d’index. Ce
tablespace peut être différent (fortement recommandé) de celui du segment de données de la table
associée
SEGMENTS TEMPORAIRES
Les segments temporaires sont utilisés pour effectuer le traitement des commandes SQL nécessitant un
espace disque temporaire (ORDER BY, GROUP BY, SELECT DISTINCT, UNION, MINUS,...).
Si aucun tablespace temporaire n’a été défini, c’est le tablespace SYSTEM qui est utilisé par défaut (Très
mauvais).
SEGMENTS D’AMORCAGE (BOOTSTRAP)
Le segment d’amorçage est créé dans le tablespace SYSTEM au moment de la création d’une base de
données. Il contient les définitions du dictionnaire de données qui sont chargées au moment de
l’ouverture de la base de données.
SEGMENTS D’ANNULATION (ROLLBACK)
Les segments d’annulation (rollback segment) permettent d’enregistrer les actions effectuées par les
transactions. Ils contiennent les données avant modification par les transactions, permettant ainsi
d’annuler leur effet en cas de besoin.
6-4 Structure Physique
La structure physique d’une base de données est composée d’un

ensemble de fichiers qui constituent le support physique de
stockage de données. Une base de données Oracle est
composée physiquement d’un ou plusieurs fichiers.
Les structures logiques déjà étudiées sont stockées dans ces
fichiers.
Types de fichiers :
Fichiers de données (Data files)
Fichiers de reprise (Redo Log Files)
Fichiers de contrôle (Control files)
Structure Physique
(suite)
Fichiers de données
Lors de la création de tablespace le ou les fichiers de
données seront spécifiés :
CREATE TABLESPACE ts_logistique
DATAFILE ‘/usr1/base/fichier1.dbf’ SIZE 1 M
‘/usr2/base/fichier2.dbf’ SIZE 1 M
DEFAULT STORAGE (INITIAL 100K NEXT 100K MINEXTENT
1 MAXEXTENT 5 PCTINCREASE 50)
Ces fichiers assurent le stockage des objets créés par les utilisateurs
(tables, clusters, index,...) ainsi que ceux nécessaires au
fonctionnement d’Oracle. Lors de création d’une base de données, il
doit y avoir au moins un fichier pour stocker le dictionnaire de données.
Structure Physique
(suite)
Fichiers de reprise
Les fichiers de reprise (Redo log) contiennent les modifications des
données les plus récentes. Ils sont au moins deux et sont utilisés d’une
façon circulaire. S’ils sont deux, par exemple, Oracle enregistre les
modifications dans le premier fichier et, lorsqu’il est plein, il passe au
second. Lorsque les deux fichiers sont pleins, il revient au premier, et
ainsi de suite.
Oracle offre la possibilité d’archiver un fichier de reprise plein avant sa
réutilisation (Archived redo log).
De même, Oracle offre la possibilité de dupliquer le fichier de reprise pour
que les informations de reprise soient écrites simultanément sur
plusieurs fichiers. Le risque de perte de ces informations est ainsi réduit.
Structure Physique
(suite)
Fichiers de contrôle
Pour pouvoir démarrer une base de données, il doit y avoir au moins un

fichier de contrôle. Il contient les informations relatives à la structure
physique d’une base de données : nom de la base de données, ainsi
que les noms et la localisation des fichiers de données et de reprise.
Ce fichier est mis à jour automatiquement chaque fois qu’un fichier de

données ou de reprise est créé ou renommé.
6-5 Correspondance entre les structures physique et
logique
Base d e d onn ées O R A CL E
Tablespa ces SY S TE M U SE R S
Fichiers D B S1 .O R A U SE R S1 .O RA U SER S2 .O R A
Segments Do nné es In dex Ro llba ck B oo ts tra p T em por aire D onn ées I ndex
Extensions
Blocs logiques
Blocs physiques
6-6 Architecture fonctionnelle d ’un SGBDR
Introduction
Architecture fonctionnelle d'un SGBDR

R e q uête
Tables Vues
A na ly se
Index Cluster
C o rre s po n da n c e
P ro céd u re s
M é m o ir e O ptim isa tio n Architecture à 3 niveaux

C a che ANSI/SPARC im plantée
so us fo rm e de DD
G e stio nn a ire d e d o nn é e s
SGB DR
BD
Architecture fonctionnelle d ’un SGBDR
Introduction (suite)
De façon générale, le SGBDR a pour fonction principale de stocker des données dans
la base de données et de les restituer à la demande.
Le stockage des données a été abordé dans les précédents paragraphes.
Pour restituer des données,
il est essentiel que le SGBDR soit tout d’abord capable de comprendre ce que
l’utilisateur demande. Cette étape est une étape de vérification syntaxique de la
requête, en adéquation avec le langage SQL.
puis, il doit s’assurer que ces données soient disponibles à l’utilisateur, ce qui représente
une étape sémantique.
Il doit ensuite rechercher où se trouvent les données et comment il devra les retrouver
en analysant les différents chemins d’accès aux données.
Ces fonctions sont donc réparties dans le SGBDR sous la forme de deux grands modules
fonctionnels communiquant entre eux :
un analyseur de requête, dont le rôle est d’assurer la vérification syntaxique,
sémantique de la requête et de connaître où se trouvent les données impliquées dans
la requête.
un gestionnaire de données, chargé d’exécuter proprement dit la requête.
Architecture fonctionnelle d ’un SGBDR
Introduction (suite)
L’analyseur de requêtes a comme objectif final de fournir donc le chemin

d’accès optimal aux données en transformant la requête SQL en un plan
d’accès aux données. Pour ce faire, après analyse syntaxique, il doit
étudier la correspondance entre les vues externes (vues Utilisateurs =
Requêtes) et la structure conceptuelle/logique (étape de vérification
sémantique) de la base de données, puis étudier la correspondance entre
la structure conceptuelle/logique et la structure physique (interne) de la
base de données.
Cette dernière étape doit fournir le meilleur moyen pour retrouver l’adresse
des blocs physique qui contiennent les données impliquées dans la
requête. Ce travail est effectué par un optimiseur de requêtes.
6-7 Les optimiseurs de requêtes
Rôles
L’optimiseur de requêtes constitue la première grande fonction que le SGBDR doit

assurer lors de l’exécution de requêtes en provenance de l’utilisateur (requêtes
interactives ou programme d’application).
Son rôle est déterminant, il doit permettre l’exécution la plus rapide possible de la
requête SQL. Il doit donc fournir d’une part la stratégie optimale d’exécution de la
requête, appelée le plan d’exécution de la requête et libérer d’autre part le
programmeur de la connaissance du fonctionnement des opérateurs SQL (méfiance
quand même ?).
La requête de l’utilisateur sera donc analysée dans le détail et “ brassée ” jusqu’à
l’obtention du meilleur plan pour son exécution, c’est à dire celui qui nécessitera le
moins d’Entrées / Sorties disques, en inspectant les tables système du dictionnaire
de données (DD).
La qualité d’un optimiseur de requêtes est l’un des critères qui permet de juger de la
performance du SGBDR tout entier, aussi bien en terme de temps de réponse que
de charge de travail. En effet, il ne faudrait pas que l’exécution des travaux de
préparation de l’optimiseur soit plus longue que l’exécution de la requête non
optimisée !.
Les optimiseurs de requêtes
Stratégie d’exécution des plans “d’exécution”
Systèmes compilés :
Certains optimiseurs compilent les plans d’exécution des requêtes afin de pouvoir les réutiliser par
la suite et éviter ainsi de recommencer le travail d’optimisation. Dans ce cas, au moment de la
nouvelle exécution d’une requête dont le plan a déjà été compilé puis sauvegardé, l’optimiseur
vérifie si le plan est toujours valide et, dans ce cas, le plan est exécuté à nouveau. Cette
approche est valable pour les requêtes définies dans des procédures stockées ou cataloguées.
Systèmes interprétés :
A l’inverse, les systèmes interprétés effectuent une optimisation à chaque exécution de la requête.
De façon générale, l’interprétation s’avère intéressante dans le cas où :
les requêtes SQL sont ad-hoc, c’est-à-dire non prévues à l’avance ou lorsque les
applications contiennent des ordres SQL dynamiques, c’est-à-dire dans lesquelles les
paramètres de la requêtes sont à saisir par l’utilisateur au moment de l’exécution de la requête.
En effet, il y a alors peu de chance pour que le même plan puisse être exécuté à nouveau, la
requête manipulant généralement des volumes de données différents à chaque fois;
le schéma ou le contenu de la base change fréquemment; dans ce cas, les plans
d’exécution des requêtes seront souvent rendus caducs et la perte de temps lors de la
compilation ne s’avère donc pas justifiée.
Stratégie d’exécution des plans “d’exécution”
Systèmes mixtes :
Certains optimiseurs interprétés sauvegardent quand même des résultats pour les utiliser
ultérieurement (systèmes mixtes). L’optimiseur conserve alors en mémoire centrale les
plans qu’il a exécutés récemment et essaie, lorsqu’une nouvelle requête arrive, de trouver
un plan équivalent. Si cette recherche échoue, du fait d’une requête plus complexe, il
essaie alors de trouver des morceaux de plans qui pourraient être repris pour composer le
plan final de la requête.
Modes d’évaluation du coût d’une requête
Optimisation basée sur les statistiques :

La méthode statistique est disponible dans plusieurs SGBDR du marché. Cette méthode se base sur des
statistiques relatives aux tables pour déterminer le meilleur chemin d’accès. Ces statistiques
concernent le volume des tables (nombre de lignes), le nombre de blocs alloués à la table, le nombre
de valeurs distinctes de chaque colonne, les valeurs minimale et maximale des colonnes, la
distribution de la clé, le nombre de valeurs différentes d’un index.
Ces statistiques sont mises à jour automatiquement (ce qui requiert du temps),
ou à la demande de l’Administrateur de la base de données, ou encore lorsqu’un événement apparaît (de
type “ trigger ” par exemple), par modification des tables système correspondant
Optimisation basée sur les heuristiques :
Le coût d’une requête peut être également obtenu en utilisant des heuristiques, c’est-à-dire un ensemble
des règles permettant de guider l’évaluation.
L’utilisation d’heuristiques fournit un plan contenant la liste classée des opérations à effectuer pour
satisfaire la requête. Cette liste est obtenue par consultation des coûts relatifs de chaque opération.
Cette solution est très intéressante dans le cas où la distribution des données suit les heuristiques, car elle
permet d’éviter l’évaluation des fonctions de coûts.
Par ailleurs, certains optimiseurs utilisent des techniques d’intelligence artificielle et emploient des
heuristiques de nature différente, représentant des règles de savoir-faire. Celles-ci permettent
d’éliminer certains plans jugés trop longs après l’expérience que l’optimiseur possède. En général, ces
règles de savoir-faire sont figées dans le SGBDR.
Limites
Limites de l’optimiseur
Tout optimiseur a des limites qu’il est bon de pouvoir cerner : limites en
nombre maximal de tables manipulées, de jointures, de sous-requêtes
imbriquées.
Informations fournies par l’optimiseur

Il est essentiel que l’optimiseur soit capable de fournir des renseignements
sur la façon dont il a calculé (déterminé) le plan d’exécution de la
requête. En effet, ces informations sont capitales pour l’administrateur
de la base de données pour ajuster l’organisation de la base de
données et pour le programmeur pour ajuster la structure de ses
requêtes.
L’utilitaire le plus connu dans ce domaine est la commande EXPLAIN.
6-8 Gestion des transactions
Définition
Une transaction est la plus petite unité logique de traitements regroupant un ensemble d’opérations
élémentaires (commandes SQL). Ces opérations doivent être exécutées entièrement, soit pas du tout,
permettant ainsi à la base de données de passer d’un état cohérent à un nouvel état cohérent.
Exemple : Transfert bancaire d’un compte à un autre
Pourquoi une transaction ?

Supposons maintenant que nous soyons dans un environnement défaillant, dans ce cas, les mises à jour déjà effectuées
seront prises en compte, mais le programme ne pourra pas être en mesure de redémarrer là où il s’était arrêté.
Exemple du Transfert bancaire d’un compte à un autre
Lire compte courant de M. TOTO
Retrancher 5000 FF
Ecrire résultat dans compte courant
PANNE
Lire compte livret de M. TOTO
Ajouter 5000 FF
Ecrire résultat dans compte livret
Dans cet exemple, si aucune précaution n’est prise, la mise à jour du compte courant est enregistré
avant que celle du compte livret ne le soit.
Bilan : M. TOTO a perdu 5000 FF sans les avoir dépensés !
6-8 Gestion des transactions
Propriétés
La transaction est validée lorsque toutes ses opérations ont été prises en
compte. Cette validation a lieu lorsque la transaction est terminée (état
connu par le système grâce au mot clé END TRANSACTION) ou lorsque le
programme contient l’ordre de validation COMMIT.
Si au contraire, une panne se produit, ou si la transaction n’arrive pas jusqu’à
la fin, la transaction est avortée (ABORT) déclenchant ainsi un retour
arrière dynamique (ROLLBACK).
Ce retour arrière a pour effet de “ défaire ” toutes les opérations effectuées par
la transaction jusqu’au dernier COMMIT de celle-ci (s’il existe) ou sinon
jusqu’au début de la transaction.
Le gestionnaire des transactions un identifiant unique pour chacune des
transaction permettant de les repérer et attache ensuite cet identifiant à
toutes les opérations contenues dans celle-ci.
6-9 Gestion des accès concurrents
L’une des fonctions du noyau d’un SGBDR est d’assurer la gestion des accès concurrents
dans les environnements multi-utilisateurs. Selon la norme ANSI/ISO du langage SQL, la
gestion des accès concurrents consiste à assurer la sérialisation des transactions
multiples accédant simultanément aux mêmes données. Cette sérialisation consiste à
s’assurer que l’exécution simultanée d’un ensemble de transactions accédant aux
mêmes données fournit le même résultat que leur exécution en série.
La gestion des accès concurrents est basée sur les concepts d’intégrité, de
concurrence et de consistance de données. Elle utilise essentiellement la technique de
verrouillage de données.
Intégrité des données :
L’intégrité des données est assurée en respectant les différentes contraintes d’intégrité définies lors
de la création de la base de données. En particulier, cette intégrité doit être assurée suite à une
mise à jour de mêmes données par différents utilisateurs. La base de données doit passer d’un
état cohérent avant les mises à jour à un autre état cohérent après les mises à jour.
Concurrence des données :
La concurrence des données consiste à assurer une coordination des accès concurrents de
plusieurs utilisateurs aux mêmes données. Plus le nombre d’utilisateurs pouvant accéder
simultanément aux mêmes données, plus le degré de concurrence devient important.
Gestion des accès concurrents
(suite)
Consistance des données :

La consistance des données est assurée lorsque ces données restent inchangées jusqu’à la fin d’une
opération de mise à jour ou de lecture, c’est-à-dire que, lorsqu’un utilisateur utilise ces données en
lecture ou en mise à jour, elles doivent rester dans un état consistant (inchangé) jusqu’à la fin de
l’opération même si d’autres transactions essaient de la modifier.
Consistance des données en lecture (READ CONSISTENCY)
Lors du traitement d’une commande de mise à jour, le SGBDR donne pendant tout le temps de
traitement de cette commande la même image des données prise au début de son exécution. Les
modifications effectuées par cette commande ne deviennent visibles qu’après sa validation.
Exemple :
Utilisateur 1 Temps Utilisateur2
Mise à jour table T t1
t2 Lecture table T
Validation de la MAJ de T t3
t4 Lecture table T
La lecture effectuée sur la table T à l’instant t2 par l’utilisateur 2 ne voit pas les
modifications apportées par l’utilisateur 1. Par contre, la lecture effectuée à l’instant t4 voit les
modifications apportées par l’utilisateur 1 car il y a eu lieu validation à l’instant t3.
6-10 Verrouillage des données
Concepts de base
Pour que l’exécution simultanée de plusieurs transactions donne le même résultat qu’une exécution
séquentielle, la solution utilisée consiste à verrouiller momentanément les données utilisées par une
transaction jusqu’à la fin de la mise à jour. Les autres transactions demandant ces données sont mises en
attente jusqu’à leur libération (déverrouillage). Cette technique de verrouillage permet d’éviter les
interactions destructives des transactions, c’est-à-dire les opérations n’assurant pas l’intégrité des données.
Le cas typique destructive est la perte de mise à jour
La figure suivante donne un exemple de perte de mise à jour.
Transaction 1 Temps Transaction 2
Lecture A (A=50) t0
Calcul A = A + 10 t1 Lecture A (A=50)
Ecriture A (A=60) t2 Calcul A = A+20
t3 Ecriture A (A=70)
Validation T1 t4
t5 Validation T2
L’absence de verrouillage de données a pour conséquence la perte de la mise à jour faite par la
transaction T1. Au lieu que D1 ait comme résultat final la valeur 80 (50+10+20), elle n’a que 70, car la mise à
jour effectuée par T1 n’a pas été prise en compte.
Le verrouillage s’applique d’une façon générale à une ressource. Une ressource peut correspondre aux
objets créés par les utilisateurs tels que les tables (ou uniquement quelques lignes d’une table), ainsi qu’aux
objets système tels que les éléments du dictionnaire et la mémoire.
Verrouillage des données
Granule de verrouillage
Un paramètre important qui affecte les performances est le

niveau de verrouillage des données, appelé aussi granule de
verrouillage. Ce granule peut être logique (une table, une
ligne) ou physique (segment, extension, bloc, fichier). La taille
du granule influence le degré de concurrence. Un petit granule
favorise la concurrence, mais il entraîne des contrôles plus
importants.
Généralement les petits granules (ligne) sont mieux adaptés aux

transactions courtes ne manipulant qu’un faible volume de
données (quelques lignes), alors que des granules plus
importants sont mieux adaptés aux transactions lourdes.
Types de verrouillage
Oracle par exemple utilise deux niveaux de verrouillage des

données : verrouillage des lignes (row locks) et verrouillage
des tables. La combinaison de ces deux niveaux de
verrouillage donne lieu aux cinq modes de verrouillage
suivants
Mode lignes partagées (Row Share ou RS)
Mode lignes exclusives (Row eXclusive ou RX)
Mode table partagée (Share ou S)
Mode partage exclusif de lignes (Share Row
Exclusive ou SRX)
Mode table exclusive (Exclusive ou X)
Compatibilité entre les modes de verrouillage
Compatibilité (O/N)
avec les autres modes
de verrouillage
Mode de verrouillage Commandes SQL RS R S SR X
correspondantes X X
RS : Lignes partagées - Select ...from ... for update
- Lock table ... in row share O O O O N
mode
- Insert into ...
- Update ...
- Delete from ...
RX : Lignes exclusives O O N N N
- Lock table ... in row exclusive
mode
S : Table partagée - Lock table ... in share mode O N O N N
SRX : Partage exclusif - Lock table ... in share O N N N N
de lignes exclusive mode
X : Table exclusive Lock table ... in exclusive mode N N N N N
6-11 Gestion de reprise après incident
Journal des transactions
Nécessité d’un journal des transactions

Il est essentiel qu ’on puisse conserver la trace des modifications
effectuées sur toutes les données. En effet, les données étant modifiées
en mémoire centrale ou secondaire, il est impossible de récupérer une
base cohérente en cas de panne que ce soit de la mémoire volatile ou
non volatile.
La technique unanimement reconnue pour enregistrer l’ensemble des
modifications effectuées sur une base est celle du JOURNAL DES
TRANSACTIONS (ou Log file en terminologie anglo-saxonne). Le
journal des transactions est constitué de un ou plusieurs fichiers, dont
l’objectif est de dresser un historique de l’exécution des transactions.
Le journal des transactions doit être organisé de façon séquentielle, afin
de conserver la notion d’ordre d’exécution des différentes opérations.
Gestion de reprise après incident
Approches
Deux approches sont envisagées dans le SGBDR commercialisés pour conserver cet
historique :
Journal des transactions physique
Journal des transactions logique
Journal des transactions physiques
En partant du principe qu’une opération d’écriture sur une donnée lit un bloc de données, le
modifie et l’écrit, le journal des transactions prend une “ photographie ” du bloc avant la
modification et une photographie du bloc après la modification. Ces “photographies” sont
appelées des Images Avant (Before Image) et les Images Après (ou After Image). Un tel
journal des transactions est dit physique.
Journal des transactions physiques

Ou partant du principe qu’une transaction affectant une donnée lit un bloc de données puis lui
applique une séquence d’opérations, le journal des transactions enregistre les images
avant et les opérations de haut niveau appliquées sur ce bloc, c’est-à-dire la logique de la
transaction elle-même. Un tel journal des transactions est dit logique.
Gestion de reprise après incident
Nature des pannes
Plusieurs problèmes peuvent arrêter le déroulement normal d’une opération

sur la base de données ou même affecter l’écriture des données sur le
disque.
Certaines pannes ne nécessitent pas d’intervention de l’administrateur, car le
système assure lui-même la restauration dite reprise à chaud. D’autres
pannes sévères nécessitent l’intervention de l’administrateur, qui doit
restaurer la base (reprise à froid) à partir d’une sauvegarde récente.
Exemples de pannes
Erreur accidentelle : suppression de tables ou d’autres objets de la base.
Panne sur une commande SQL : problème d’allocation d’extension ou autres
Panne d’un processus SGBDR : il peut arriver qu’un processus du SGBDR
s’arrête brutalement sans avoir validé ou annulé les transactions en cours.
Panne réseau : une panne réseau peut interrompre l’exécution normale d’une
application cliente et provoquer une panne du processus.
Panne matérielle (disque,…)
Chapitre 7
Approches à la gestion des bases

de données réparties
ou fédérées
8-1 Pourquoi une gestion répartie de données
Raisons économiques :
Coût élevé d’acquisition et de maintenance des ordinateurs “main frame”
Raisons techniques :
Les développements remarquables de domaines :
Réseaux de communication
Mini et micro-ordinateurs
Bases de données relationnelles
Le développement croissant des applications
Multimédias (Données alphanumérique, Texte, Image, Son)
Infocentre (Orienté Utilisateur)
L’offre remarquable des Outils de développement sur PC.
L’exigence des entreprises d’avoir un système évolutif / progressif pour supporter les besoins
de logiciels.
Raisons organisationnelles :
Décentralisation des activités
Délégation du pouvoir
8-2 Définition
Intuitivement, une base de données répartie est une collection de

données logiquement corrélées et physiquement réparties sur
plusieurs machines interconnectées par un réseau de
communication.
Définition :
Une Base de données répartie est un ensemble de bases
de données coopérants, chacune résidant sur un site
différent, vu et manipulé par l’utilisateur comme une seule
base de données centralisée.
===> Transparence à la localisation des données .
8-3 Typologies de systèmes d ’informations réparties
Base primaire centrale, mises à jour directes sur site primaire

C’est le cas d’architecture la plus simple, les données de référence (information primaire) sont sur le site
central, les mises à jours sont faites en direct par les utilisateurs sur ce site central (en client/serveur à
travers le réseau) et les données dupliquées sont transportées vers des sites secondaires utilisés
uniquement en consultation par les utilisateurs.
Base primaire centrale, mises à jour indirectes via transaction asynchrones :
Même scénario que le premier, mais les mises à jour se font en local sur les sites locaux et grâce à des
procédures asynchrones déclenchées automatiquement que la base primaire centrale sera mise à jour.
L’utilisateur est alors indépendant de la disponibilité du site central pour faire ses mises à jour.
Multiples bases primaires, base centrale dupliquées pour consolidation
Dans ce cas, plusieurs sites primaires possèdent chacun sa propre base de données et on repercute dans
la base centrale les mises à jour des tables faites en local soit en mode synchrone soit en mode
asynchrone.
Le site central contient donc des tables globales représentant l’union des tables des bases
primaires.
En terme du contenu des tables, deux variantes sont possibles :
la base locale ne possède que ses propres données,
la base locale possède ses données ainsi celles des autres sites pour consultation uniquement.
8-4 Conception d ’une BD répartie
Nécessité d ’une démarche méthodologique
La nécessité de l’utilisation d’une méthode pour concevoir et mettre en oeuvre un système

d’information n’est plus à démontrer.
Cependant lors de conception d’un système d’informations réparties, certains points
deviennent très importants :
Cohérence des traitements de l’Entreprise :
Plus les traitements sont autonomes, et plus le problème de la cohérence se pose. c’est un véritable
enjeu
Propriété des données :
Le problème de la propriété des données va pair de pair avec celui de la cohérence des traitements :
- Qui peut mettre à jour les données ? Qui en est responsable ? Qui peut y accéder ?
Les performances :
la productivité des utilisateurs locaux doit être optimisée parce qu’ils travaillent avec des données
locales et considèrent que les accès distants sont occasionnels.
La manipulation des seules données affectées, au lieu du remplacement de tables entières, doit
optimiser l’utilisation des réseaux.
La sécurité (fiabilité) :
Les sites locaux doivent mieux résister aux phénomènes de pannes parce qu’ils ne sont plus
tributaires d’une défaillance survenant en n’importe quel point du système
8-5 Techniques utilisées dans la répartition des
données
Technique de fragmentation
Il y a deux façons possibles de diviser une relation en plus petites
relations, horizontalement et verticalement, ce qui donne trois
types de fragments:
Horizontale
Verticale
Mixte
Afin de préserver la cohérence sémantique de la base de données
répartie, la fragmentation d’une relation doit obéir à trois règles :
Décomposition sans perte
Reconstruction
Non duplication
Technique de replication (duplication)
Technique de fragmentation
Fragmentation horizontale directe (s ):

La fragmentation horizontale définit le partitionnement d’une relation selon
ses tuples. Les différents fragments sont obtenus par application de
prédicats de restriction.
La reconstruction d’une relation horizontalement fragmentée s’obtient par
la somme ou l’union ( È ) de ses fragments .
Fragmentation horizontale indirecte ( ´ ):

La fragmentation horizontale indirecte définit la fragmentation horizontale
d’une relation selon les valeurs d’attributs d’une autre relation.
Les fragments sont obtenus par l’application de prédicats de semi-
jointure..
Technique de fragmentation (suite)
Fragmentation verticale (p ) :
La fragmentation verticale définit le partitionnement d’une relation selon
ses attributs.
Les fragments sont obtenus par des projections appliquées sur la
relation initiale.
Il est nécessaire de dupliquer dans chaque fragment le ou les
attributs clés pour pouvoir reconstruire la relation.
La reconstruction est obtenue par la jointure des fragments selon les
attributs communs.
Fragmentation mixte :
La fragmentation mixte combine la fragmentation horizontale et la
fragmentation verticale.
ATTENTION : Le choix de la fragmentation est un problème complexe car
il est dépendant des besoins d ’accès des applications
Technique de replication
L’unité de la duplication est le fragment, ou la relation si la fragmentation

n’est pas supportée. Une duplication est matérialisée par des copies,
chacune résidant sur un site différent.
Une telle duplication, contrôlée par le système, fournit :
- une grande disponibilité des données
- une meilleure résistance aux pannes
- un parallélisme dans les consultations
- une diminution du trafic réseau
Les avantages apportés par la duplication sont à comparer avec la
complexité et les coûts supplémentaires de maintenance des copies qui
doivent, en théorie, rester identique à tout moment.
Un compromis entre performance d’accès et cohérence des données à

tout instant rend difficile le choix du niveau de duplication.
8-6 Objectifs des SGBD réparties
(12 règles de DATE)
R1- Autonomie locale :

Tout site d’un système réparti doit être aussi autonome que possible. Les
données d’un noeud sont gérés par l’utilisateur qui est sur ce noeud.
L’autonomie des sites est un objectif récent qui permet à chaque site
opérationnel de contrôler et de manipuler ses données locales indépendamment
des autres sites, cependant, la coopération entre sites doit être coordonnée par
les administrateurs locaux.
R2- Pas de couplage fort avec les autres sites :
Pour une meilleure optimisation d’exécution des requêtes et de résistance
aux pannes, chaque site doit viser à privilégier la manipulation par l’utilisateur de
sa base locale, et considère que l’accès à d’autres bases est
occasionnel.
R3- Règles des opérations continues :
On doit pouvoir interrompre un noeud sans interrompre les autres noeuds du
réseau.
Objectifs des SGBD réparties
R4- Indépendance à la localisation des données :

Le but recherché est que la réorganisation physique de la base de
données répartie, qui peut conduire à transférer des relations d’un site à un
autre, est sans impact sur les programmes d’application qui accèdent à la
BD répartie.
R5- Indépendance à la fragmentation :

La fragmentation augmente les performances d’une base de données
répartie car elle permet de favoriser les accès locaux.
L’indépendance à la fragmentation des données cache à l’utilisateur le
fait qu’une relation conceptuelle est divisée en plus petites sous-relations
appelées fragments, pouvant être stockées à des sites différents.
R6- Indépendance à la duplication :

Les avantages escomptés sont :
- une grande disponibilité des données
- une meilleure résistance aux pannes
- un parallélisme dans les consultations
- une diminution du trafic réseau
Les avantages apportés par la duplication sont à comparer avec la complexité et
les coûts supplémentaires de maintenance des copies qui doivent, en théorie, rester
identique à tout moment.
Un compromis entre performance d’accès et cohérence des données à tout instant rend
difficile le choix du niveau de duplication
R7- Traitement réparti des requêtes :

L’évaluation de requêtes réparties, émises par les utilisateurs et invoquant la Base de
données répartie est divisée en quatre étapes:
- décomposition (traduction d’une requête SQL en une requête intermédiaire dans une
variation de l’algèbre relationnelle)
- localisation (transformation en fonction du schéma de placement d’une
requête répartie équivalente exprimée sur des fragments).
- optimisation (détermination de l’ordonnancement “ optimal ” des opérations
relationnelles, ainsi que les algorithmes d’accès aux données).
- exécution (Le plan d’exécution fournit toute l’information nécessaire à l’exécution des
traitements locaux et à leur synchronisation globale).
Remarque : Par comparaison à l’évaluation de requêtes dans un contexte centralisé,
l’évaluation de requêtes répartie est compliquée par plusieurs facteurs :
- Les possibilités de fragmentation de relations et de duplication de fragments offrent un plus grand nombre de
stratégies d’exécution d’une requête globale.
- L’utilisation des techniques de simplification conduisant à éliminer au plus tôt les stratégies de mauvaises
performances.
- L’optimisation doit prendre en compte le coût supplémentaire de communication et les avantages du parallélisme.
- Le choix du site d’exécution ou du mode d’échange de données inter-sites.
R8- Gestion de transactions réparties :

Une transaction répartie est constituée de plusieurs sous-transactions, chacune
s’exécutant à un site différent. En général, l’information locale concernant une
sous transaction est insuffisante afin de décider de la validation ou de l’abandon
des mises à jour locales. La seule solution est de gérer une information globale,
ce qui induit un coût de communication et de traitement supplémentaire.
L’environnement réparti affecte tous les aspects délicats de la gestion de
transactions : contrôle de concurrence, gestion de la fiabilité et traitement de la
validation .
- Contrôle de concurrence : Deux approches de base sont utilisées :
Estampillage (Timestamp) et Verrouillage
- Gestion de la fiabilité : Adaptation des techniques de journalisation et
points de reprise connues dans l’environnement centralisé.
- Validation de transaction : Utilisation du protocole de validation en
deux étapes (Two-Phase Commit).
R9- Indépendance aux matériels
R10- Indépendance aux Operating System (OS)
R11- Indépendance aux SGBD

c’est l’objectif particulier des bases de données réparties
hétérogènes. Il reste très difficile à atteindre totalement.
R12- Indépendance aux réseaux de communication

8-7 Etat de l ’art
Sybase avec Replication Server
Oracle avec Symmetric Replication

Chapitre 8
Administration et optimisation
d ’une base de données
relationnelle
8-1 Introduction
L ’administration de bases de données nécessitent des compétences qui se

situent à l’intersection de plusieurs domaines :
L’entreprise et la conception du système d’information
Il faut maîtriser la signification des informations manipulées dans la base de
données et les règles de gestion associées.
Le SGBD
Il faut maîtriser le système technique (SGBD) utilisé pour gérer les données du
système d’information, autrement dit :
maîtriser ses possibilités (fonctionnalités);
maîtriser ses contraintes et ses limites;
maîtriser ses outils de surveillance et d’administration de bases de données;
maîtriser l’utilité et l’impact des principaux paramètres de réglage (tuning);
maîtriser les langages de description et manipulation de données ainsi que le pseudo langage
procédural offert par le SGBD.
L’architecture technique
Il faut connaître le fonctionnement technique des systèmes matériels
supportant le SGBD (Operating System, mémoires, etc.).
8-2 Niveaux d ’administration
4 niveaux d ’administration
Niveau logique de la base de données
Niveau physique de la base de données
Niveau applicatif
Niveau système
Niveaux d ’administration
Niveau logique
Gérer le dictionnaire de données (Création, modification ou

suppression des objets du dictionnaire). Le DBA est le seul habilité à
mettre à jour le dictionnaire de données;
Gérer les droits des utilisateurs (personnalisation par utilisateur ou par
profil utilisateurs);
Définir les fédérations inter-bases;
Définir les vues, les procédures et les trigger;
Fournir les informations volumétriques permettant le dimensionnement
de la base de données
Assurer le support logiciel pour les équipes de développement;
Arbitrer le choix des index, de la clusterisation des données ,du niveau
de dénormalisation / stockage des résultats de calcul dans la base
Niveau physique
Répartition physique des données;

Dimensionnement de la base de données
détermination des valeurs des paramètres de stockage sur disque (nombre de blocs
initialement alloués aux données ou aux index, nombre de blocs alloués en sus lorsque
l’espace initial est plein, nombre minimal et maximal d’extensions que le système peut
faire, le pourcentage d’espace à conserver libre dans le bloc pour les mise à jour
futures,...)
détermination de la taille de la mémoire cache (cache disque);
détermination des valeurs d’autres paramètres nécessaires au bon fonctionnement optimal de
la Base de données (Nombre de verrous, nombre de curseurs ouverts simultanément,
taille de buffer cache,...)
Détermination du type de fichier physique devant recevoir les données des tables et des
index (File system ou un Raw device si OS= UNIX);
Vérification du bon fonctionnement de la BD
Exécution des Benchmarks
Mise en place de l’environnement Base de données de production, d’intégration et de
développement et de la stratégie de la sauvegarde et la reprise des données
Niveau applicatif
Participation à l’élaboration et à la maintenance évolutive des

modèles conceptuel et logique de données ;
Élaboration du modèle physique de données;
Analyser les besoins de transactions (index, vue, stockage des
résultats de calcul, normalisation utile, analyse des plans
d’exécution des requêtes, procédure cataloguée, ...);
Optimisation des ordres SQL
Vérification des choix pris au niveaux logique (index ,
clusterisation, procédures cataloguées, trigger, fédérations,…)
Réorganisation du plan de stockage des données;
Analyser les plans d’exécution des requêtes;
Niveau système
Installation des logiciels du SGBD;

Installation des nouvelles versions . Avant toute installation il doit
étudier l’impact de celle-ci sur l’existant , prendre les
précautions nécessaires et définir l’environnement adéquat;
Paramétrage initial des logiciels du SGBD (mot de passe,
répertoires de travail, protocole de communication, taille de la
page en blocs OS, ...)
Coordination avec les ingénieurs système et réseau
Interlocuteur privilégié du fournisseur du SGBD
Veille technologique
Support aux équipes de développement
8-3 Optimisation et amélioration des performances
Introduction
Les bonnes ou mauvaises performances d’une base de données relationnelle ne se relèvent pas seulement de la bonne ou
mauvaise définition de sa structure physique.
Il est important de rappeler que, avant de définir la structure physique d’une base de données, une définition de sa
structure logique est obligatoire.
Cette structure logique est la clé, le garant de la bonne définition d’une structure physique de la base de données (cf.
cours Structures logique et physique d’une base de données relationnelle).
Il ne faut surtout pas oublier qu’en terme de modélisation de données, cette structure logique est le fruit d’un long et
fastidieux travail d’analyse et de conception du système d’information à automatiser.
Il est à rappeler aussi, que la finalité d’une base de données est d’être utilisée (exploitée) par des requêtes, des programmes
faisant des recherches (accès en lecture) ou des mises à jour des données dans la base. Ces recherches ou mises à jour
s’effectuent à l’aide des commandes SQL. Si ces dernières sont mal formulées et ne tiennent pas compte des contraintes
imposées par les optimiseurs, les conséquences peuvent être dramatiques en terme des performances du système.
L’expérience prouve que le gain que nous pouvons espérer en améliorant la structure physique d’une base de données existante
(revoir la répartition des fichiers sur plusieurs axes, gérer plus efficacement la mémoire centrale, etc.) est de l’ordre de 15 à
25 %.
On déduit donc, qu’au moins 75% de gain des performances dépendent fortement de la bonne définition de la
structure logique de la base de données
définir un bon schéma de la base de données : Tables normalisées ou non , Cluster sur tables, Index pour tables, Index pour
Clusters, tablespaces, etc...,
définir les valeurs de paramètres de stockage en fonction de l’évolution des objets dans la base de données dans le temps,...)
et de la bonne utilisation des commandes SQL dans les programmes applicatifs.
C’est pour cette importante raison que mettons l’accent dans ce chapitre sur l’optimisation des requêtes SQL et sur le choix des
index.
Optimisation et amélioration des performances
rappel des méthodes d ’accès
Parcours de toute la table (Full Table Scan)

Les donnés sont cherchées directement dans la table. Les blocs qui contiennent les données
de la table sont lus d’une manière séquentielle. Toutes les lignes de la table sont lues, et,
pour chacune d’elles, la condition spécifiée dans la clause WHERE (s’il y en une) est
évaluée.
Accès par ROWID
Les données sont cherchées directement dans la table. Le ROWID spécifie l’adresse
physique de la ligne. Il est composé de l’identifiant du fichier, le bloc dans le fichier et puis
la localisation de la ligne dans le bloc. Ce ROWID est soit citée dans la clause WHERE,
soit obtenu en accédant à l’un des index définis pour la table.
La localisation d’une ligne par son ROWID constitue le moyen le plus rapide pour retrouver la
ligne.
Parcours de l’index (Index Scan)
Cette méthode permet de retrouver les données en se basant sur les valeurs d’une ou
plusieurs colonnes de l’index. Si la commande SQL spécifie seulement des valeurs de
colonnes faisant partie de l’index, Oracle recherche directement les données à partir de
l’index qui servent par la suite à retrouver les lignes elles-mêmes grâce au ROWID.
rappel des méthodes d ’accès (suite)
Parcours du cluster (Cluster Scan)

Dans un cluster indexé, les lignes qui ont la même valeur de la clé du
cluster sont stockées dans les mêmes blocs. Cette méthode permet de
retrouver les lignes qui ont la même valeur de la clé. Pour ce faire,
Oracle obtient le ROWID des lignes sélectionnées à partir de l’index du
cluster, qui servent par la suite à retrouver les lignes elles-mêmes.
Parcours par hachage

Dans un cluster par hachage, toutes les lignes qui ont la même valeur de
hachage sont stockées dans les mêmes blocs.
Pour obtenir les lignes, Oracle applique une fonction de hachage à la
valeur de la clé du cluster (spécifiée dans la commande SQL), puis
retrouve les blocs de données contenant la valeur de hachage.
performance des méthodes d ’accès
Les exemples suivants sont ordonnés selon le degré de performance de la méthode

employée (de plus performant vers le moins performants)
Cas 1 : accès à une seule ligne par ROWID
Disponible si la clause WHERE contient une identification de la ligne par son
Rowid
Exemple : SELECT *
FROM Client
WHERE ROWID = ‘xxxxxxxxxxxxx’;
Cas 2 : accès à une seule ligne par jointure des clusters join
Disponible pour une opération de jointure de deux tables stockées dans le même
cluster et les deux conditions sont vérifiées :
1- la clause contient la condition d’égalité entre les deux tables selon la
colonne clé du cluster
2- la clause WHERE contient une condition assurant l’unicité du résultat.
Exemple : SELECT *
FROM Client, Commande
WHERE Client. Code_cli = Commande.Code_cli
AND Date_cde = ‘01-AUG-95’,
performance des méthodes d ’accès (suite)
Cas 3 : jointure clusterisée

Disponible pour une opération de jointure de deux tables et si la clause
WHERE contient des conditions d’égalité entre chaque colonne de la clé du
cluster avec la colonne du cluster correspondante de l’autre table.
Exemple : SELECT *
WHERE Client. Code_cli = Commande.Code_cli;,
Cas 4 : Clé de cluster indexé
Disponible si la clause WHERE utilise toutes les colonnes de la clé
cluster indexé dans une condition d’égalité. Pour une clé composée du
cluster, les conditions d’égalité doivent être combinées avec des opérateurs
AND. Oracle retrouve la valeur du ROWID avec laquelle il effectue un accès
par cluster.
Exemple : SELECT *
FROM Commande
WHERE Num-cde = ‘AB1234’ ;
Cas 5 : Clé de cluster indexé

Disponible si la clause WHERE utilise toutes les colonnes de la clé
cluster hasch dans une condition d’égalité. Pour une clé composée du
cluster, les conditions d’égalité doivent être combinées avec des opérateurs
AND. Oracle applique la fonction de hachage à la clé pour retrouver la valeur
avec laquelle il accède aux lignes de la table.
Exemple : SELECT *
FROM Commande
WHERE Num_cde = ‘MNP654’;
Cas 6 : accès à une seule ligne par clé unique ou clé primaire
Disponible si la clause WHERE contient une condition d’égalité avec
toutes les colonnes d’une clé unique ou clé primaire.
Exemple : SELECT *
FROM Produit
WHERE Code_prod = 6656;
Cas 7 : index composé

Disponible si la clause WHERE utilise toutes les colonnes de l’index
combinées avec des opérateurs AND. Oracle effectue un accès par index au
ROWID, puis utilise les valeurs des ROWID pour accéder aux données de la
table.
Exemple : SELECT *
FROM Detail_commande
WHERE Num_cde = ‘AGH6754’
AND Code_prod = 6656;
Cas 8 : Recherche bornée sur colonnes indexées
Disponible si la clause WHERE contient des conditions qui utilisent soit
la colonne d’un index unique, soit plusieurs colonnes qui constituent une
partie d’un index composé.
Exemple : SELECT *
FROM Produit
WHERE Code_prod BETWEEN 1000 AND 6656;
Cas 9 : Recherche non bornée sur colonnes indexées

Disponible si la clause WHERE contient l’une des conditions suivantes qui
utilise une colonne d’un index unique ou bien une partie d’un index
composé.
Exemple : SELECT *
FROM Produit
WHERE Code_prod > 6656;
Cas 10 : Jointure avec tri et fusion
Disponible pour une opération de jointure de deux tables qui ne sont pas
stockées dans un cluster, si la clause WHERE utilise des colonnes de
chaque table dans des conditions d’égalité. Oracle utilise un tri et fusion pour
exécuter la requête.
Exemple : SELECT *
WHERE Client. Code_cli = Commande.Code_cli;
Cas 11 : MAX et MIN de colonnes indexés

Disponible si les deux conditions sont vérifiées :
1- la requête utilise MAX et MIN pour des colonnes (index unique) ou une colonne d’un index composé.
2- il n’y a pas d’autres expressions dans la clause SELECT
3- la commande n’a pas de clause WHERE ni de clause GROUP BY
Exemple : SELECT MAX(Num_cde)
FROM Commande;
Cas 12 : Order by sur une colonne indexée
Disponible si la condition est vérifiée :
il doit y avoir une clé primaire ou une contrainte d’intégrité NOT NULL qui garantit qu’au moins une des
colonnes indexées dans ORDER BY ne contient pas de NULL.
Exemple : SELECT *
FROM Detail_commande
ORDER BY Code_prod;
Cas 13 : Parcours séquentiel total de la table (Full Table Scan)
Disponible pour tout ordre SQL :
Exemple : SELECT *
FROM Produit;
Choix des index
Les index sont créés pour :

accélérer l’accès aux données
assurer l’unicité des clés primaire ou candidate.
Pour cela :
toujours indexer les clés primaires des tables > 100 lignes (inutile si la clause PRIMARY KEY
a été utilisée dans l’ordre de création de la table;
indexer les colonnes intervenant dans des jointures entre tables (clés étrangères par
exemple);
Indexer les colonnes intervenants dans des clauses ORDER BY. L’une des colonnes au
moins doit être déclarée en NOT NULL;
Indexer les colonnes intervenants dans des clauses GROUP BY ou utilisées dans les
fonctions MIN, MAX, AVG, etc.
-Ne jamais indexer :
les colonnes contenant peu des valeurs distinctes (en règle générale lorsque 20 % ou plus
des occurrences d’une satisfont le critère de recherche, il vaut mieux se passer de l’index);
les colonnes très souvent modifiées et très peu utilisées lors de consultation.
Quelques astuces
1- Vérifier l’adéquation des valeurs de paramètres de

stockage des objets du schéma de la base par rapport à
leur réelle évolution dans la base.
2- Vérifier la répartition physique des fichiers sur disques
évitant ainsi le goulot d’étranglement des E/S disque.
3- Utiliser les cluster si nécessaire.
4- Réajuster la taille et la répartition de la mémoire centrale
(SGA, PGA, etc.).
5- Réajuster la taille du bloc de données (page).
6- Procéder à une dénormalisation des tables très souvent
sollicitées en jointure définies dans des requêtes
fréquemment exécutées.
Chapitre 9
CONCLUSION

B BD Support Coursbd6assurepareac

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

B BD Support Coursbd6assurepareac

Transféré par

Droits d'auteur :

Formats disponibles

Conservatoire National des Arts et Métiers

Les données représentent l’aspect statique du système

Les traitements représentent l’aspect cinématique du

L’analyse de données d’une part et celle des traitements

Inversement, lors de l’analyse de la spécification des

Le Modèle Conceptuel de Données (MCD) est un

Un modèle conceptuel de données

Modèle Entité-Relation ou modèle Entité-Association

Proposé par P. Chen en 1976

Différentes extension ont été proposées

L’ANSI choisit le modèle E-R comme standard en 1988

Le Modèle E-R comprend:

dans les définitions qui suivent, les différents synonymes

objet ayant une existence dans le monde réel, et

Attention à la modélisation du TEMPS:

association entre entités précisant un fait naturel

Relation binaire MARIAGE

c ’est une relation entre deux

Cardinalité d'une relation:

POSTE FACTURE LIGNE FOURNISSEUR

1,1 1,1 1,1 1,N

1,1 0,1 0,N 0,N

EMPLOYE COMMANDE COMMANDE PRODUIT

A 1 Poste 1 Commande peut 1 Commande 1 Fournisseur délivre

PRODUIT PRODUIT PRODUIT PRODUIT

0,N 1,N 1,N 0,N

1,N 0,N 1,N 0,N

Le Produit doit Le Fournisseur doit Le Produit Produit/Fournisseur

caractéristique élémentaire décrivant un individu ou

- Raison sociale PASSE - N° Commande

rubrique PRODUIT 1,N

combinaison minimale de FOURNISSEU

de reconnaître UNE - Pays

relation de manière 0,N

synonymes: identifiant - Quantité Min

un individu/relation peut posséder une ou plusieurs clés

Ces clés peuvent avoir des propriétés en commun ou non.

EMPLOYE LIGNE Autre

Il permet par exemple de

liées à cet INDIVIDU 0,2

De la même manière, on peut avoir des SOUS-TYPES

1,N CONTIENT 0,N

Formalisme INCLUSION (I): si une occurrence de l’Individu1

Non Navigant Navigant

Administratif Mécanicien Steward Hôtesse Copilote Pilote

est Steward ou Hôtesse du vol

0,n 0,n est Copilote du vol

retour prévu à retour réel à

0,n 1,1 1,1

a pour type a subi

Une démarche DEDUCTIVE qui s’appuie sur

Une démarche INDUCTIVE qui

Ces deux approches

La démarche inductive est plus efficace. Le concepteur peut

Dans les deux cas,

Les phrases fournissent, après analyse grammaticale, les

Pour chaque information recueillie, le concepteur doit, avant

Introduction au modèle relationnel

Proposé par CODD (Université Saint José) en 1971

Schéma de relation : Nom de la relation suivi de la liste des

Valeur nulle : Valeur conventionnelle introduite dans une relation pour

Expression d’attributs : Expression arithmétique construite à partir d’attributs

Réflexe (Trigger) : Evénement déclenché suite à l’apparition d’une condition

Relation binaire (,n) - (,n)

Relation binaire réflexive (,n) - (,n)