Vous êtes sur la page 1sur 67

Conception de bases de données

©Tarek Beldi
Département d’Informatique
Université Time
Plan

z Objectif de ce chapitre
– Présenter les grandes lignes lors de la conception d’une BD
• Étape 1: Identification des besoins
• Étape 2: Élaboration du schéma conceptuel
• Utilisation du modèle UML
• Les critères à prendre en compte dans l’élaboration du
schéma physique de la BD
– Ce chapitre n’est pas
• Exhaustif,
• Formel
• Complet
– Ce n’est pas un cours sur UML !

(c) Beldi 2
Historique

Avant 1970 1970 – 1980 1980 - 1992 Depuis 1992

Technologie

Applications

Méthodes
Méthodes
Méthodes Dossiers
d’analyse- systémiques
Méthodes
d’exploitation orientées objet
programmation

(c) Beldi 3
Méthodologie

Conduite et suivi de projet Schéma directeur

UML

Merise
Conception de
systèmes d’information SA-RT

SADT

Développement
SGBD Java Delphi PB …

(c) Beldi 4
Vision complète

Système Système
Stratégie Processus
d’information informatique

(c) Beldi 5
Problématique: Taille et complexité des logiciels

z Complexité fonctionnelle (exemples)


1. Le SI : mémoriser et stocker l’information mais en
plus traiter de façon sophistiquée pour l’aide à la
décision (Entrepôt de données "DataWhareHouse ).
2. Logiciels développés séparément et avec des
démarches différentes et appelés à être interfacés
pour les besoins de l’entreprise.
z Évolutions technologiques permanentes
z Complexité architecturale : Client/serveur, n-
tiers,Intranet, Corba (Common Object Request Broker
Architecture), Systèmes distribués…

(c) Beldi 6
Solutions
z Découpage du processus de développement :
• phase d'analyse : aspects
• phase de réalisation : aspects
technologiques et architecturaux.
z Découpage du système en sous systèmes :
– diminution de la complexité par répartition
du travail et réutilisation de composants
z Utilisation d’une technologie de haut niveau :
– découpage naturel du système .

(c) Beldi 7
Démarche de construction d’une application

z Méthode : guide de description d’une forme de modèle à une autre.


z Formalisme : langage de représentation graphique.
z les différentes étapes :
; Expression des besoins
; Spécification
; Analyse
; Conception
; Implémentation
; Tests de vérification
; Validation
; Maintenance et évolution

(c) Beldi 8
Les différentes étapes

z Expression des besoins : Données + traitements


z Spécification : Ce que le système doit être et comment il peut
être utilisé.

z Analyse : L’objectif est de déterminer les éléments intervenant dans


le système à construire, ainsi que leur structure et leurs relations. Elle
doit décrire chaque objet selon 3 axes :
– Axe fonctionnel : savoir-faire de l’objet.
– Axe statique : structure de l’objet.
– Axe dynamique : cycle de vie de l’objet au cours de
l’application (États et messages de l’objet).

Ces descriptions ne tiennent pas compte de contraintes techniques


(informatiques).

(c) Beldi 9
Les différentes étapes (suite)

z La conception : elle consiste à apporter des solutions techniques


aux descriptions définies lors de l’analyse : architecture technique ;
performances et optimisation ; stratégie de programmation.
– On y définit les structures et les algorithmes.
– Cette phase sera validée lors des tests

z L’implémentation : C’est la réalisation de la programmation


z Les tests de vérification : Ils permettent de réaliser des
contrôles pour la qualité technique du système.
– Il s’agit de relever les éventuels défauts de conception et de
programmation (revue de code, tests des composants,...).
– Il faut instaurer ces tests tout au long du cycle de développement
et non à la fin pour éviter des reprises conséquentes du travail
(programmes de tests robustes ; Logiciels de tests).

(c) Beldi 10
Les différentes étapes (suite)

z Validation :
¾ Le développement d’une application doit être lié à un
contrat ayant une forme de cahier de charges, où
doivent se trouver tous les besoins de l’utilisateur. Ce
cahier de charge doit être rédigé avec la collaboration
de l’utilisateur et peut être par ailleurs complété par la
suite.
¾ Tout au long des ces étapes, il doit y avoir des
validations en collaboration également avec
l’utilisateur.
¾ Une autre validation doit aussi être envisagée lors de
l’achèvement du travail de développement, une fois que
la qualité technique du système est démontrée. Elle
permettra de garantir la logique et la complétude du
système.
(c) Beldi 11
z Maintenance et évolution: Deux sortes de maintenances
sont à considérer :
Une maintenance corrective, qui consiste à traiter les
“buggs ”.

Une maintenance évolutive, qui permet au système


d’intégrer de nouveaux besoins ou des changements
technologiques.

(c) Beldi 12
Les cycles de vie

z Deux cycles de vie sont utilisées dans les approches traditionnelles:


1. le modèle linéaire
2. le modèle en “ V ”.
z Le modèle linéaire
Expression des Spécification A nalyse Conception
besoins

Tests M aintenance
Im plém entation de V alidation et
vérification évolution

z Le principe de cette démarche est que chaque phase est traitée


complètement avant que la suivante ne soit entamée.
– Ce qui renvoie les tests de vérification et la validation en fin du
processus de développement.
– S’il y a des erreurs, les retours seront compliqués et coûteraient
chers.

(c) Beldi 13
Les cycles de vie (suite)

Expression des besoins


Validation des
besoins

Spécifications fonctionnelles
Validation fonctionnelle

Conception du
système Tests du
système

Conception des composants Tests des


composants

Implémentation

(c) Beldi 14
Le modèle en "V"

z Le modèle en “V” permet une organisation modulaire.


– A chaque étape de l’analyse et de la conception correspond une étape de
tests ou de validation.
– A chaque étape fonctionnelle correspond ainsi une étape technique.
z Le processus s’accomplit en deux phases :
– Une phase descendante : de spécifications et de conception.
– Une phase ascendante : de tests et de validation.

Comme pour le modèle linéaire, l’inconvénient est que la
validation et les tests interviennent tardivement.
z Dans un projet Objet, le cycle de vie répond à 3 caractéristiques
essentielles :
™ La traçabilité entre les étapes
™ Un cycle itératif
™ Un cycle incrémental

(c) Beldi 15
Cycle de vie: traçabilité entre les étapes

• Les concepts utilisés au cours des différentes étapes


sont quasiment identiques (Classes, Objets, Attributs,
Méthodes, Héritage, Polymorphisme, ...).
z Ceci permet de conserver le même discours lors de
toutes les étapes :
– « Analyse - Conception - Implémentation ».
z Ce qui n’est pas le cas dans les approches
traditionnelles, où l’on utilise une méthode d’analyse et
de conception avec des concepts et un langage de
programmation avec d’autres concepts.

(c) Beldi 16
Cycle de vie: cycle itératif

Validation des besoins

Tests de vérification Expression des besoins

Implémentation Spécifications fonctionnelles

Conception
Analyse

(c) Beldi 17
Cycle de vie: cycle itératif

# Lors du développement, une maquette doit


être réalisée pour valider l’ergonomie de
l’application et l’enchaînement des écrans.
# Plusieurs versions peuvent être
développées. Lors de chacune d’elle,
chaque fonctionnalité est améliorée
jusqu’à optimisation rendant ainsi le
système progressivement robuste.

(c) Beldi 18
Différents niveaux d’abstraction

z Le système d'information n'est pas perçu de la même manière par


tous les utilisateurs de l'entreprise.

schémas externes

schéma conceptuel

schéma logique

schéma physique

(c) Beldi 19
Étapes de conception

z Étape 1: Identification des besoins


z Étape 2: Élaboration du schéma
conceptuel
z Étape 3a: Conception du schéma logique
z Étape 3b: Raffinement du schéma logique
z Étape 4: Élaboration du schéma physique

(c) Beldi 20
Étape 1: Identification des besoins

z Étudier les problèmes des utilisateurs


z Comprendre leurs besoins:
– Données à stocker dans la future BD
– Principales résultats attendues (requêtes, états)
z Modéliser le domaine de l'application
– On parle de l’aspect « METIER »
z Résultat de l'étape : Ensemble de schémas externes
– En principe, chaque schéma externe décrit une partie de la
future BD qui identifie les besoins d’un groupe d’utilisateurs
(services, directions, etc.)

(c) Beldi 21
Étape 2: Élaboration du schéma conceptuel

z Intégrer les schémas externes élaborés à l'étape


1
– Problème assez complexe (domaine de
recherche)
– L'intégration est souvent difficile
– Des retours fréquents à l'étape 1 sont
nécessaires
z Résultat de l'étape:
schéma conceptuel du domaine de l'application
décrit selon un modèle conceptuel donné c
(dans notre cas, ça sera UML ).
(c) Beldi 22
Étape 3a: Conception du schéma logique

z A ce niveau, le SGBD est choisi


– Dans le cadre de ce cours, on se place dans le cadre d’un SGBD
z Objectif de cette étape:
– Transformer le schéma conceptuel en structure de données
conformes au SGBD choisi ou Schéma Logique
– Le schéma logique dépend donc du SGBD choisi
z Cette étape peut être automatisée:
– Un ensemble de règles permettent de faire ce passage « schéma
conceptuel -- schéma logique »
z Résultat de l'étape : schéma logique de la BD
– Dans notre cas, le schéma logique est un schéma relationnel

(c) Beldi 23
Étape 3b: Raffinement du schéma logique

z Objectif de l’étape: Répondre à la question suivante:


– Est-ce que le schéma logique obtenu dans l’étape
précédente est « bon » ou non ?
z Intuitivement, un « bon » schéma est un schéma
– Sans oubli
– Sans redondances anarchiques
– Sans d’anomalies de mises à jour
z La théorie de la normalisation apporte quelques
réponses à ce sujet
z Résultat de l'étape:
– schéma logique raffiné

(c) beldi 24
Étape 4: Élaboration du schéma physique

z Rechercher de bonnes performances


z Prendre en compte les transactions
z Indexer, dénormaliser, grouper, partitionner les tables
z Résultat de l'étape:
– schéma physique « optimisé » de la BD

(c) Beldi 25
Étape 1
Identification des besoins
Rappel Sur le modèle UML
Rappels des concepts de base UML

z Classe
– Une classe modélise un ensemble d'objets ayant les mêmes
propriétés au niveau des attributs, des relations et du
comportement
– Exemple: Personne, Véhicule, Client, Commande
z Association
– Une association modélise les liens entre objets
– Exemple: possède, passeCommande
z Attribut
– Un attribut représente une caractéristique commune à un
ensemble d'objets
– Exemple: Id_personne, No_client, Nom, quantité
z Opération (méthode)
– Une opération modélise un comportement commun à un
ensemble d'objets

(c) Beldi 27
Classes et Objets

classe
CLASSE VOITURE
privé -noVehicule
attributs -km
+démarrer()
opérations public +rouler(km)
objet +arrêter()

objet:CLASSE #12:VOITURE

noVehicule=4562
attributs km = 54789

(c) Beldi 28
Association et cardinalités

Min Max

0..*
passe
CLIENT COMMANDE

Min Max

1..1 passe
CLIENT COMMANDE

(c) Beldi 29
Différentes associations et cardinalités

ternaire
Degré binaire

Min..Max
1..1 Agrégation
1..1
0..* 0..*
Tout Partie
1..*
Cardinalité 1..n
Composition
0..1 1..1 0..*
0..1 Tout Partie

0..*
0..n

(c) Beldi 30
Exemple

MAGASIN PRODUIT

1..1 1..1

passe
référence

0..* 0..*
composée de 1..*
COMMANDE LIGNE_COMMANDE

(c) Beldi 31
Types d'association

z Trois types d'association


– Fonction des cardinalités maximales de l'association
z Remarquer que les associations n’ont pas de noms !!

1:1
0..1 0..1
EMPLOYÉ STATIONNEMENT

1:n
1..1 0..*
CLIENT COMMANDE

m:n
0..* 0..*
ÉTUDIANT COURS

(c) Beldi 32
Attributs d'une classe

z Simple
z Composé
z Mono-valué Simple EMPLOYÉ

z Multi-valué idEmploye:integer
Mono-valué dateNaissance:date
z Dérivé
adresse:Adresse
téléphones:Collection
Multi-valué \age Composé
Dérivé
ADRESSE

rue:string
ville:string
codePostal:string
province:string

(c)Beldi 33
Classe « association »

z En UML, quand une association possède des attributs, il faut créer


une classe spéciale dite classe association pour stocker ses
attributs
z Exemple

0..* 0..*
ÉTUDIANT COURS

ÉVALUATION

noteIntra
noteFinale

(c) Beldi 34
Hiérarchie ou Agrégation

z hiérarchie: Une classe (super classe) peut avoir plusieurs sous-


classes
– Chaque sous-classe hérite des attributs, des relations et des
méthodes
z Sous classes avec Participation Totale ou Partielle
z Sous classes Disjoints ou non Disjoints
disjoint
non disjoint EMPLOYÉ

EMPLOYÉ partielle totale


{Disjoint, Complete}
{Overlapping, Incomplete}

ACTIONNAIRE SYNDIQUÉ PERMANENT CONTRACTUEL

(c) Beldi 35
Diagramme de classes

La voiture

0..n possède 1..1


VOITURE PERSONNE
possesion propriétaire
noVéhicule NAS
couleur nom
km ACHAT prénoms
rouler(km) adresse
prix
date
1..1 cote déménager(adresse)
acheter()
vendre()

1..1

MOTEUR

noMoteur
type
puissance
démarrer()
arrêter()

(c) Beldi 36
Notion de Paquetage

La vie

0..n habite 1..1


PERSONNE ADRESSE

NAS rue
nom ville
prénoms codePostal
dateNaissance province

1..1
EMPLOYE SPORTIF
superviseur
fonction sport
salaire niveau
augmenter() supervisé changerNiveau()
1..n

(c) Beldi 37
Étape 2
Élaboration du schéma conceptuel
Conflits lors de l’intégration des schémas externes

z Au niveau des classes


– noms différents pour des classes équivalentes
– noms identiques pour des classes différentes
– Inclusion de l'une dans l'autre
– Intersection non vide
z Au niveau des attributs
– noms différents pour des attributs équivalents
– noms identiques pour des attributs différents
– Types différents
– Compositions différentes
z Au niveau des associations
– noms différents pour des associations équivalentes
– noms identiques pour des associations différentes
– cardinalités différentes

(c) Beldi 39
Conflits sur le plan de la modélisation

z Classe ou Attribut
– significations identiques
– compositions similaires
z Association ou Attribut
– association versus référence
– cardinalités incompatibles

(c) Beldi 40
Intégration des schémas externes
Le modèle conceptuel

0..n possède 1..1 0..n habite 1..1


VOITURE PERSONNE ADRESSE
possesion propriétaire
noVehicule NAS rue
couleur nom ville
ACHAT
km prénoms codePostal
prix dateNaissance province
rouler(km)
date
cote Déménager()
1..1
acheter()
vendre()

1..1
1..1
MOTEUR EMPLOYE SPORTIF
superviseur
noMoteur fonction sport
type salaire niveau
puissance augmenter() supervisé changerNiveau()
démarrer() 1..n
arrêter()

(c) Beldi 41
Sommaire

Nous avons vu:


– 4 étapes de conception
– Modélisation avec le modèle UML
– Intégration des schémas externes
z Reste à voir (hors du cadre de ce cours)
– les autres diagrammes UML
– L’exploitation de ces diagrammes dans le cycle de
développement d’une application de BD

(c) Beldi 42
Exercice

z Faire le diagramme de classes pour l’énoncé suivant:


z Soit une entreprise mettant à disposition de ses clients du personnel
qualifié. Chaque intervention donne lieu à un contrat. Les principales
informations du contrat sont:
– la description succincte de l'intervention,
– la date du début de l'intervention,
– la qualification précise de chaque intervenant,
– le nombre de jours/personnes prévu pour chacune des qualifications.
z À chaque qualification correspond un tarif journalier. L'entreprise s'accorde
en interne une certaine souplesse sur la détermination précise de la
qualification de son personnel en procédant de la manière suivante:
– chaque personne possède à priori une qualification de base,
– à chaque intervention il est possible de réajuster la qualification dite
d'intervention par rapport à la qualification de base. La qualification
d'intervention est déterminée pour un contrat donné. La qualification
retenue doit toujours appartenir à l'ensemble des qualifications
standards.

(c) Beldi 43
Étapes de conception (Rappel)

z Étape 1: Capture des besoins (ok)


z Étape 2: Élaboration du schéma
conceptuel (ok)
z Étape 3a: Conception du schéma logique
z Étape 3b: Raffinement du schéma logique
z Étape 4: Élaboration du schéma physique

(c) Beldi 44
Étape 3a
Conception du schéma logique
Du schéma conceptuel au schéma logique
Modèle conceptuel de départ

0..n possède 1..1 0..n habite 1..1


VOITURE PERSONNE ADRESSE
possesion propriétaire
noVehicule NAS rue
couleur nom ville
ACHAT
km prénoms codePostal
prix dateNaissance province
rouler(km)
date
cote Déménager()
1..1
acheter()
vendre()

1..1
1..1
MOTEUR EMPLOYE SPORTIF
superviseur
noMoteur fonction sport
type salaire niveau
puissance augmenter() supervisé changerNiveau()
démarrer() 1..n
arrêter()

(c) Beldi 46
Les règles de transformation

z Règle 1: Une classe est représentée par une table de même nom
ayant pour attributs les attributs de la classe.

VOITURE PERSONNE ADRESSE

noVehicule NAS idAdresse


couleur nom rue
km prénoms ville
dateNaissance codePostal
province

EMPLOYE SPORTIF

NAS NAS
MOTEUR nom nom
prénoms prénoms
noMoteur dateNaissance dateNaissance
type fonction sport
puissance salaire niveau

(c) Beldi 47
Les règles de transformation
(suite)
z Règle 2: Une association est représentée par une table de même
nom ayant pour attributs la liste des clés des classes participantes
et les attributs de l'association

PERSONNE ADRESSE
VOITURE
ACHAT HABITE idAdresse
idVehicule NAS
idVehicule rue
couleur nom NAS
NAS ville
km prénoms idAdresse
date codePostal
dateNaissance
prix province
cote
CONTIENT

idVehicule
idMoteur SPORTIF
EMPLOYE

NAS SUPERVISE NAS


MOTEUR nom nom
prénoms NASsuperviseur prénoms
idMoteur dateNaissance NASsupervisé dateNaissance
type fonction sport
puissance salaire niveau

(c) Beldi 48
Les règles de transformation
(suite)
z Règle 3: Si une association a pour cardinalité 1:1 ou 1:n, la table
correspondante peut être fusionnée.

VOITURE PERSONNE ADRESSE

idVehicule NAS HABITE idAdresse


couleur ACHAT nom rue
km prénoms NAS ville
idMoteur idVehicule dateNaissance idAdresse codePostal
NAS idAdresse province
CONTIENT date
idVehicule prix
cote EMPLOYE SPORTIF
idMoteur
NAS NAS
MOTEUR SUPERVISE nom nom
prénoms prénoms
idMoteur NASsuperviseur dateNaissance dateNaissance
type NASsupervisé fonction sport
puissance salaire niveau

(c) Beldi 49
Les règles de transformation

z Règle 4a (Spécialisation): La clé du supertype est uniquement


répétée dans les sous-tables. L'héritage est réalisé par jointure.

VOITURE PERSONNE ADRESSE

idVehicule NAS idAdresse


couleur ACHAT nom rue
km prénoms ville
idMoteur idVehicule dateNaissance codePostal
NAS idAdresse province
date
prix
cote EMPLOYE SPORTIF

NAS NAS
MOTEUR SUPERVISE nom
fonction nom
sport
prénoms
salaire prénoms
niveau
idMoteur NASsuperviseur dateNaissance dateNaissance
type NASsupervisé fonction sport
puissance salaire niveau

(c) Beldi 50
Les règles de transformation
(suite)
z Règle 4b (spécialisation): La super table est supprimée et
reconstituée par une vue avec projections et unions sur les sous-
classes.
PERSONNE

NAS
nom
prénoms
VOITURE PERSONNE dateNaissance ADRESSE
idAdresse
idVehicule NAS idAdresse
couleur ACHAT nom rue
km prénoms ville
idMoteur idVehicule dateNaissance codePostal
NAS idAdresse province
date
prix
cote EMPLOYE SPORTIF

NAS NAS
MOTEUR SUPERVISE nom nom
prénoms prénoms
idMoteur NASsuperviseur dateNaissance dateNaissance
type NASsupervisé fonction sport
puissance salaire niveau

(c) Beldi 51
Les règles de transformation
Spécialisation
z Règle 4c
Les sous-tables sont fusionnées dans la super table. Les
attributs non pertinents ont la valeur NULL.

VOITURE PERSONNE ADRESSE

idVehicule NAS idAdresse


couleur ACHAT nom rue
km prénoms ville
idMoteur idVehicule dateNaissance codePostal
NAS idAdresse province
date fonction
prix salaire
cote EMPLOYE
sport SPORTIF
niveau
NAS NAS
MOTEUR SUPERVISE nom nom
prénoms prénoms
idMoteur NASsuperviseur dateNaissance dateNaissance
type NASsupervisé fonction sport
puissance salaire niveau

(c) Beldi 52
Les règles de transformation
contraintes d'intégrité

z Règle 5 (Contraintes d’intégrité): Toute association non fusionnée


engendre deux contraintes d'intégrité référentielle.

PERSONNE ADRESSE
VOITURE
NAS idAdresse
idVehicule
ACHAT nom rue
couleur
prénoms ville
km
idVehicule dateNaissance codePostal
idMoteur
NAS idAdresse province
date fonction
prix salaire
cote sport
niveau

MOTEUR SUPERVISE FOREIGN KEY (idVehicule) REFERENCES VOITURE(IdVehicule)


FOREIGN KEY (NAS) REFERENCES PERSONNE(NAS)
idMoteur NASsuperviseur
type NASsupervisé FOREIGN KEY (NASsuperviseur) REFERENCES PERSONNE(NAS)
puissance FOREIGN KEY (NASsupervisé) REFERENCES PERSONNE(NAS)

(c) Beldi 53
Les règles de transformation
(suite)
z Règle 6 (contraintes d’intégrité): Toute association de cardinalité 1:1
ou 1:n engendre une contrainte d'intégrité référentielle.

VOITURE ACHAT PERSONNE ADRESSE

idVehicule idVehicule NAS idAdresse


couleur NAS nom rue
km date prénoms ville
idMoteur prix dateNaissance codePostal
cote idAdresse province
fonction
salaire
sport
niveau

SUPERVISE
MOTEUR NASsuperviseur FOREIGN KEY (idAdresse) REFERENCES ADRESSE(idAdresse)
NASsupervisé
idMoteur
type
puissance

(c) Beldi 54
Étape 3b
Raffinement du schéma logique
Suppression des redondances et des anomalies de mise à
jour
z Basée sur les dépendances fonctionnelles et les formes normales
(voir chapitre sur la normalisation des BD)
z Définition (rappel)
Un attribut (ou groupe d'attributs) Y dépend fonctionnellement
d'un attribut (ou groupe d'attributs) X si la connaissance de X
implique celle de Y (notation X Æ Y)
z Exemple
VOITURE(idVehicule, type, couleur, marque, puissance)
idVehicule → type
idVehicule → couleur, marque, puissance
type → marque
type → puissance

(c) Beldi 56
1 Forme normale
(Rappel)
z Une relation est en première forme normale si tout attribut contient
une valeur atomique.
z Exemple :
PERSONNE
PERSONNE NAS
nom
PERSONNE NAS dateNaissance
nom idAdresse
NAS prénom1 fonction
nom prénom2 salaire
Prénoms: Multi-valué prénom3 sport
dateNaissance dateNaissance niveau
idAdresse idAdresse
fonction fonction
salaire salaire PRENOM
sport sport
niveau niveau NAS
prénom

Solution 1
Solution 2

(c) Beldi 57
2eme Forme Normale
(rappel)
z Une relation est en deuxième forme normale si et seulement si:
– Elle est en première forme normale
– Tout attribut n'appartenant pas à une clé ne dépend pas d'une
partie d’une clé.
z Exemple :

ACHAT

idVehicule
NAS
ACHAT COTE
idVehicule → cote
date
idVehicule prix idVehicule
NAS cote
date
prix
cote

(c) Beldi 58
3eme Forme normale
(Rappel)
z Une relation est en troisième forme normale si et seulement si:
– Elle est en deuxième forme normale
– Tout attribut Non premier ne dépend pas d'un autre attribut
non clé.
z Exemple :

ADRESSE CODE_POSTAUX
codePostal → ville
ADRESSE
idAdresse codePostal
idAdresse
codePostal → province
rue ville
rue codePostal province
ville
codePostal
province

(c) Beldi 59
Étape 4
Élaboration du schéma physique
Techniques de modélisation

z Paramètres
– Fréquence et volume des données des requêtes
– Types de requêtes (SELECT, UPDATE, …)
– Configuration du SGBD (disque, cache, …)
z Modèle analytique
– Utilisation de formules (de coût) paramétrées
z Modèle simulé
– mesures sur une BD réduite avec un générateur de
transactions

(c) Beldi 61
Principales techniques d'optimisation

z Diminuer le nombre de jointures


– Dé-normalisation
– Groupement (Clustering)
z Diminuer le volume de données échangées
en cas de distribution par
– Partitionnement vertical et/ou
– Partitionnement horizontal

(c) Beldi 62
Dé-normalisation

z La dénormalisation consiste à implanter la jointure de


deux tables (ou plus) à la place des tables initiales.
z Inconvénients de la dénormalisation:
– redondances
– valeurs nulles supplémentaires
– gestion des mises à jour
z Illustrer ces inconvénients avec l’exemple suivant:
– Fusion des tables COMMANDE et
DET_COMMANDE

(c) Beldi 63
Groupement

z Le groupement consiste à regrouper dans une même


page (secteur du disque) ou des pages voisines les tuples
de deux tables (ou plus) selon un critère de jointure.
z Inconvénients du groupement
– Les sélections sur l'une ou l'autre table sont
pénalisées.
z Exemple :
– Groupement des tables COMMANDE et
DET_COMMANDE
– Les lignes de la table commande sont placées dans la
même page que l'en-tête.

(c) Beldi 64
Partitionnement vertical

z Le partitionnement vertical consiste à décomposer une


table par projection en deux tables (ou plus) en répétant
la clé dans chacune des tables pour pouvoir recomposer
la table initiale par jointure.
z Inconvénient du partitionnement vertical
– Les sélections sur la table initiale sont pénalisées.
z Avantage :
– permet de réduire la taille d'une table en éloignant
les attributs peu utilisés

(c) Beldi 65
Partitionnement horizontal

z Le partitionnement horizontal consiste à décomposer


une table par sélection en deux tables (ou plus).
– La table initiale est reconstruite par union.
z Inconvénients du partitionnement horizontal
– Les sélections sur la table initiale sont pénalisées.
z Avantage
– permet de réduire la taille d'une table en la
découpant.
z Exemple :
– DET_COMMANDE est découpée en douze tables: une
table par mois.

(c) Beldi 66
Exercice

z Concevoir le schéma logique de la BD de l’exercice précédent et


donner les commandes SQL de création des tables correspondantes

(c) Beldi 67