Bases de Donnees Avancees

Introduction & Rappel

Conception et Modelisation
Thierry Hamon
Bureau H202 - Institut Galil
ee
T
el. : 33 1.48.38.35.53
Bureau 150 LIM&BIO EA 3969
Universit
e Paris 13 - UFR L
eonard de Vinci
74, rue Marcel Cachin, F-93017 Bobigny cedex
T
el. : 33 1.48.38.73.07, Fax. : 33 1.48.38.73.55
thierry.hamon@univ-paris13.fr
http://www-limbio.smbh.univ-paris13.fr/membres/hamon/BDA-20112012

INFO2 BDA

1/62

Introduction

Sources des transparents

M.P. Dorville/F. Goasdoue, LRI, Universite Paris Sud

V. Mogbil, LIPN, Universite Paris Nord
J. Ullman http://infolab.stanford.edu/~ullman/
C. Rouveirol, LIPN, Universite Paris Nord
F. Boufares, LIPN, Universite Paris Nord

2/62

Introduction
Pr
esentation du cours

Presentation du cours

Objectif du cours (12 seances de 1h30) :

Des Bases de Donnees aux Entrep
ots de Donnees
Exploitation Intelligente des Donnees
Travaux Pratiques (12 seances de 1h30) :
Mise en uvre de concepts vus en cours (PL/SQL, UML
SQL2/3, integrite des donnees, etc.)

3/62

Introduction
Pr
esentation du cours

Programme des enseignements

Rappels de SQL
Conception & Modelisation de Bases de Donnees
Meta-Modelisation, Formalismes utilises (ER, EER, UML, ...)
Expression & Coherence des contraintes (SQL2/3, PL/SQL,
OCL, ...)

Implantation de Bases de Donnees

Relationnel-etendu, Oriente Objet (de UML `a SQL2/3, JDBC,
Java, PL/SQL J...)
Optimisation de Requetes, Evaluation de Requetes
Architecture de SGBD, Administration de BD

Autres (Bases de Donnees, Entrep

ots de donnees, XML)
Gros volumes de donnees / Entrep
ots de donnees / Donnees
MultiDimensionnelles
Donnees Homog`enes & Heterog`enes,
Donnees Reparties/Web, Donnees de type documents, ...

4/62

Introduction
Pr
esentation du cours

Des bases de donnees aux Entrepots de donnees

5/62

Introduction
Historique

Historique
Indpendance physique
Portabilit

Volume de donnes
Type de donnes

Generations de SGBD

SGBD4/5
Avancs

2004/5 2010

SGBD 3
Avancs

1980 1990 2000

SGBD 2
Relationnels

1970 1980 1990

SGBD 1
Hirarchies, Rseaux

1960 1970 1980

Puissance
Performance
Cohrence

6/62

Introduction
Historique

Historique
Exemples de SGBD

Indpendance physique
Portabilit

Volume de donnes
Type de donnes

SGBD4/5
ORACLE 9i, 10g, 11
DB2, ...
XML, ...

SGBD 3

SGBD 2
ORACLE 5/6
INGRES,
DB2, ...

SGBD 1
COADSYL,
SOCRATE,
...

ORACLE 7/8,
INGRES, DB2, Sybase,
Verssant Enjin (O2),
ObjectStore, Orlent,
MySQL, PostGreSQL,
SQLServer, ACCESS, ...

Bases de donnes
Entrepts de donnes
Intgration de Donnes

Puissance
Performances
Cohrence

7/62

Introduction
Historique

Historique

Type de donnes

Volume de donnes

Applications BD, ED, FD

Fouille de donnes
(Analyse du comportement des clients, etc.)

Entrepts de donnes (grosses masses de donnes)

Intgration de plusieurs systmes dinformation nationaux et internationnaux)
(milliers de tables de quelques millions de lignes) > 100 Go

Applications : Gestion des risques, Analyse des ventes

(100 tables de quelques millions de lignes) 2 Go

Applications : Paie, Marketing, Financire

(50 tables de quelques milliers de lignes) 50 Mo

8/62

Bases de Donnes
Entrepts de Donnes
Intgration de Donnes

Performance

Introduction
Historique

Historique

Type de donnes

Volume de donnes

Applications BD, ED, FD

Entrepts de donnes
(OLTP : < 10 secondes) (OLAP < 1 heure)
( MV : agrgation, ...) (Batch : Quotidien ou mensuel < 1h)
Grosse volumtrie : travail doptimisation et suivi des activits
du DWh ncssaire
Par exprience, certains traitements ne se terminent pas
au bout de quelques jours
Ncessit de modifications techniques et fonctionnelles
Applications : Gestion des risques, Analyse des ventes
(Batch : < 1 heure)

Applications : Paie, Marketing, Financire

(OLTP: quelques secondes) (Batch : < 1 heure)

9/62

Bases de Donnes
Entrepts de Donnes
Intgration de Donnes

Performance

Introduction
Historique

Historique
Relationnelle
& objet

Indpendance physique
Portabilit

Volume de donnes
Type de donnes

Structure et type de donnees

Relations

Hirarchique
& Rseau

Structure HIERARCHIQUE
des donnes

Type de donnes
COMPLEXE

Structure de donnes
TABULAIRE

Structure de donnes
en RESEAU

Puissance
Performance
Cohrence

10/62

Rappels de SQL

Commandes SQL

Plusieurs sortes de commandes SQL parmi lesquelles :

LDD (langage de definition de donnees),
LMD (langage de manipulation des donnees) cest-`a-dire du
LMJ (langage de mise `a jour) et du LID (langage
dinterrogation des donnees),
LCD (langage de contr
ole des donnees).

11/62

Rappels de SQL
Le Langage de D
efinition de Donn
ees : LDD

Le Langage de Definition de Donnees (LDD)

Ensemble de commandes qui definit une base de donnees et

les objets qui la composent
la definition dun objet inclut
sa creation: CREATE
sa modification ALTER
sa suppression DROP

12/62

Rappels de SQL
Le langage de manipulation de donn
ees : LMD

Le langage de manipulation de donnees : LMD

Ensemble de commandes qui permet la consultation et la mise

`a jour des objets crees par le langage de definition de donnees
Consultation : SELECT
La mise `a jour inclut :
linsertion de nouvelles donnees : INSERT
la modification de donnees existantes : UPDATE
la suppression de donnees existantes : DELETE

13/62

Rappels de SQL
Le langage de manipulation de donn
ees : LMD

Le langage de manipulation de donnees : LMD

Exemple

SELECT < l i s t e champ ( s )> FROM < l i s t e n o m t a b l e ( s )>

[WHERE c o n d i t i o n ( s ) ] [ o p t i o n s ] ;
INSERT INTO <n o m t a b l e > [( < l i s t e champ ( s ) >)]
VALUES (< l i s t e v a l e u r s >);
UPDATE <n o m t a b l e > SET <champ> = <e x p r e s s i o n >
[WHERE < l i s t e c o n d i t i o n ( s )> ] ;
DELETE FROM <n o m t a b l e > [WHERE < l i s t e

14/62

c o n d i t i o n ( s )> ] ;

Rappels de SQL
Le langage de contr
ole de donn
ees : LCD

Le langage de controle de donnees : LCD

Ensemble de commandes de contr

ole dacc`es aux donnees
Le controle dacc`es inclut :
lautorisation `a realiser une operation : GRANT
linterdiction de realiser une operation : DENY
Annulation dune commande de contr
ole precedente : REVOKE
lautorisation `a modifier des enregistrements : UPDATE
linterdiction de modifier des enregistrements : READ
(consultation en lecture seulement)
lautorisation `a supprimer des enregistrements : DELETE

15/62

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Conception, Developpement, Utilisation, Administration

1

Etape conceptuelle : Conception et Modelisation de bases de

donnees
Utilisation de
Methodes, Mod`eles, Formalismes
Mod`ele Entite-Association E/A / Mod`ele Entite-Association
etendu
Mod`eles Objet, Formalisme UML

Power AMC, Power Designer WinDev, Oracle Designer

Rational Rose, ...
2

Etape logique : Implantation dune base de donnees

Mod`ele Relationnel / Mod`ele Objet-Relationnel / Mod`ele
Objet
Optimisation du schema (Normalisation, Denormalisation ...)

16/62

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Conception, Developpement, Utilisation, Administration

Etape physique :
SGBD Relationnel / SGBD Objet-Relationnel / SGBD Oriente
Objet
Langages ( SQL, PL/SQL, PRO*C, JDBC, Java, ...)
Optimisations (Groupement, Index, ...)
Administration

Oracle, DB2, My SQL

4

17/62

Logiciels (SGBD, Interfaces, ...) & Materiels

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Conception du schema des bases

Une des taches essentielles des developpeurs de bases de

donnees
Objectif : structuration du domaine dapplication afin de
de le representer sous forme de types et de tables
daccompagner ces structures de contraintes sur les donnees
afin de tirer plus de semantique

18/62

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Conception du schema des bases

La representation doit etre :

juste pour eviter les erreurs semantiques, notamment dans les
reponses aux requetes ;
compl`ete pour permettre le developpement des programmes
dapplication souhaites ;
evolutive afin de supporter la prise en compte rapide de
nouvelles demandes.

19/62

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Etapes de conception
Demarche de conception traditionnelle :
par abstractions successives
en descendant depuis les probl`emes de lutilisateur vers le
Syst`eme de Gestion de Bases de Donnees.
Cinq etapes :

Perception du monde reel et capture des besoins

Elaboration
du schema conceptuel

Conception du schema logique

Affinement du schema logique

Elaboration
du schema physique

20/62

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Remarques

Etape
1 : plutot relative au domaine du genie logiciel

Etapes
2, 3, 4 et 5 : relative au domaine des bases de donnees

21/62

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Etape 1 : Perception du monde reel et capture des besoins

Etude des probl`emes des utilisateurs
Comprehension de leurs besoins
Mise en place dentretiens, danalyses des flux dinformation et
des processus metier
Difficulte : comprehension du probl`eme dans son ensemble
Realisation des etudes de cas partiels par les concepteurs
Resultat : ensemble de vues ou schemas externes devant etre
integres dans letape suivante
Vues exprimees dans un mod`ele de de donnees : de type
entite-association ou objet, selon la methode choisie

22/62

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Etape 2 : Elaboration
du schema conceptuel
Integration des schemas externes obtenus `a letape precedente
Chaque composant est un schema conceptuel : diagramme
entite-association ou diagramme de classes
Resultat : mod`ele de probl`eme representant une partie de
lapplication
Difficulte : integration de toutes les parties dans un schema
conceptuel global complet, non redondant et coherent
NB : des allers et retours avec letape precedente sont souvent
necessaires

23/62

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Etape 3 : Conception du schema logique

Transformation du schema conceptuel en structures de donnees
supportees par le syst`eme choisi : le schema logique.
Avec un SGBD relationnel : passage `a des tables.
Avec un SGBD relationnel-objet : Generation de types et de
tables,
NB : les types sont reutilisables
Avec un SGBD objet : generation de classes et de associations
NB : Cette etape peut etre compl`etement automatisee.

24/62

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Etape 4 : Affinement du schema logique

Verification : le schema logique est-il un

bon

schema ?

Definition en premi`ere approximation : un  bon schema

est un schema sans oublis ni redondances dinformations

Plus precisement : un schema est  bon  si le mod`ele

relationnel associe respecte au moins la troisi`eme forme
normale et la forme normale de Boyce-Codd (voir plus loin)
Objectif en relationnel : regrouper ou decomposer les tables
de mani`ere `a representer fid`element le monde reel modelise

25/62

Conception & Mod

elisation de Bases de Donn
ees
Introduction

Etape 5 : Elaboration
du schema physique

Etape necessaire pour obtenir de bonnes performances

Prise en compte de toutes les transactions concernant les
applications traitees
Permet de determiner les acc`es frequents
Choix des bonnes structures physiques : groupement ou
partitionnement de tables, index, etc.
point essentiel pour obtenir de bonnes performances

26/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Elaboration
du schema conceptuel
Modelisation du probl`eme en utilisant les specifications des besoins
obtenues `a letape 1 (capture des besoins)
Deux possibilites :
utilisation du formalisme Entite Relation (ou Entite
Association)
production dun diagramme ER/EA
utilisation du formalisme UML
production de classe
Independance du mod`ele conceptuel par rapport au schema
physique

27/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Phases delaboration du schema conceptuel

Identification des entites ou classes

Identification des associations
Identification des attributs pour chacune des entites ou classes
Definition des identifiants

28/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Identification des entites ou classes

Entites : element abstrait ou concret (objet, ev`enement, etc.)
reconnu distinctement
Exemples : Jean Dupont, Michel Durant
Type-entites : Ensemble des entites ayant les memes
caracteristiques
Exemple : Personne(nom, prenom)

NB : Par abus de langage, on parle souvent dentites `a la

place de type-entites
Dans letape 1, il sagit de la description des elements

29/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Identification des associations

Association : Lien logique entre deux entites
Type-Association : Ensemble dassociation ou de relations
poss`edant les memes caracteristiques.

Association/type-association : meme abus de langage

A letape 1 : une phrase simple reliant deux entites
Exemple : un professeur est en charge de cours (lien entre
les entites professeur et cours)
Plusieurs types dassociation existent

30/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Types dassociation
unaire : relation au sein dune meme entite
Exemple : un employ
e supervise un employ
e
binaire : relation entre deux entites (differentes)
Exemple : un client passe plusieurs commandes
ternaire : relation entre trois entites (differentes)
Exemple : un internaute note un film `a differentes date (on
veut conserver lhistorique des notes)

31/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Cardinalite dun type-association

Cardinalite : nombre minimal et maximal de fois quune entite
peut intervenir dans une association de ce type
Exemple : un client peut commander 1 `a n produits
Remarques :
la cardinalite minimal doit etre inferieure `a la cardinalite
maximale
la cardinalite doit etre associee `a chaque patte de la relation

32/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Cardinalite minimale/maximale
Cardinalite minimale :
0 : une entite peut exister tout en etant impliquee dans
aucune association
1 : une entite ne peut exister que si elle est impliquee dans au
moins une association
n : une entite ne peut exister que si elle est impliquee dans
plusieurs associations (cas rare,`a eviter car cela pose des
probl`emes)

Cardinalite maximale :
0 : une entite ne peut pas etre impliquee dans une association
(normalement inexistant sinon probl`eme de conception)
1 : une entite peut etre impliquee dans au maximum une
association
n : une entite peut etre impliquee dans plusieurs associations

33/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Identification des attributs

Attribut : caracteristique associee `a une entite
Exemples : nom, prenom, age

Domaine associe `a un attribut : ensemble des valeurs possibles

Chaque attribut doit poss`eder une valeur compatible avec son
domaine
Remarque : Eviter absolument les attributs calcules.
Toujours utiliser des donnees primaires les attributs qui
servent `a les calculer

34/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Definition de lidentifiant
Identifiant : liste des attributs devant avoir une valeur unique
chaque entite
Exemple : numero dimmatriculation dune voiture, numero de
securite sociale
Remarques :
On utilise plut
ot le terme cl
e que identifiant
Chaque type doit poss`eder un identifiant (forme dun ou
plusieurs attributs)
Lidentifiant dune association est la concatenation des
identifiants des entites lies
NB : on peut definir un identifiant plus naturel

35/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Remarques sur la conception

Un attribut ne peut etre partage entre deux entites ou
associations (probl`eme de redondance)
En cas de difficulte `a choisir entre entite et association (par
exemple, mariage) : utiliser le contexte pour y repondre
En cas de difficulte `a trouver un identifiant pour un
type-entite : ne sagirait-il pas une association ?
Association dont toutes les pattes ont une cardinalite 1,1 :
lassociation et les entites liees ne correspondraint-ils pas `a
une seule entite ?

36/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Entite-relation et UML
Formalisme ER :

Formalisme UML :

37/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Retour sur les cardinalites

interpretation Formalisme ER

(une des cardinalites est volontairement absente)

Tout etudiant participe au moins une fois `a lassociation est inscrit.

Tout etudiant est inscrit dans au moins une formation
Autrement dit : `a une instance detudiant peut etre associe `a
plusieurs formations

38/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

Retour sur les cardinalites

Generalisation

Formalisme ER :

Interpretations :
A est lie 0 `a n fois `a B
La connaissance de B permet de definir A
La cle de B definit linstance de A
Formalisme UML :

39/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema conceptuel

ER ou UML ?
Si conception de bases de donnees : utilisation du mod`ele
entite/relation
On mets laccent sur le syst`eme dinformation (stockage,
traitement, reception, diffusion de linformation)
Si conception objet et programmation : utilisation de UML(2
incluant lheritage)
On mets lacent sur les structures de donnees et la
programmation

40/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema logique

Elaboration
du schema logique
Transformation du mod`ele conceptuel en une structure de donnees
basee sur un mod`ele de donnees specifique (par exemple, mod`ele
relationnel)
Realisation de la transformation `a laide de r`egles formelles
Possibilite dautomatisation de cette etape (Objecteering,
Rational Rose)
Independant de la couche physique
Resultat : mod`ele logique de la base de donnees

41/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema logique

Passage au relationnel
Implementation des entites et associations sous forme de
tables
Les attributs correspondent aux colonnes des tables
le nom de lattribut est le nom de la colonne
lensemble des valeurs possibles est le domaine

Exemple :
Professeur(numProf, nom, prenom)
Cours(nomCours, nom, nbheures)
Charge(numProf, numCours)

42/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema logique

Passage au relationnel
Traduction des associations :
R`egle de base : representation des associations par une table
dont
le schema est le nom de lassociation
la liste des cles des entites participantes suivie des attributs de
lassociation

Amelioration : Regrouper les associations 1..n avec la classe

cible
Exemple :
Voiture(numV, Marque, modele)
Possede(numProp, numV, Date)
les deux tables peuvent etre regroupees si toutes les
voitures nont quun et un seul proprietaire

43/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Affiner les requetes

respecter les formes normales

Pourquoi normaliser ?
pour limiter les redondances de donnees
pour limiter les pertes de donnees
pour limiter les incoherences au sein des donnees
pour ameliorer les performances des traitements

44/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Formes normales
8 formes normales :
Formes normales 1 `a 3
Forme normale de Boyce-Codd
Formes normales de 4/5(/6)
Forme normale de domaine-cle
Objectifs des trois premi`eres formes normales : permettre la
decomposition de relations sans perdre dinformations
Une relation en forme normale de niveau N est forcement de forme
normale de niveau N 1

45/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Premi`ere forme normale (1FN)

Une relation est en premi`ere forme normale si tous ses attributs

contiennent des valeurs
simples et non-decomposables (utiliser une liste ou une table
externe)
non-repetitives
constantes dans le temps (date de naissance plutot que lage)

46/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Premi`ere forme normale (1FN)

Vol(NoVol*, CodeAeroDep#, CodeAeroArr#, HeureDep,
HeureArr, Jours)
devient
Vol(NoVol*, CodeAeroDep#, CodeAeroArr#, HeureDep,
HeureArr)
Vol(NoVol*, Jour)

47/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Deuxi`eme forme normale (2FN)

Une relation est en deuxi`eme forme normale si et seulement si :
elle est en premi`ere forme normale
tout attribut non cle est totalement dependant de toute la cle
Autrement dit, une des trois conditions doit etre respectee :
La cle primaire nest formee que dun seul attribut
La cle primaire contient tous les attributs de la table
Si la cle a plus dun attribut, une dependance fonctionnelle ne
doit jamais exister entre une partie seulement de la cle et un
autre attribut de la table.

48/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Deuxi`eme forme normale (2FN)

Avion(Constr*, Mod`ele*, Conso, Capacite, VitesseMax)

il y a une dependance fontionnelle entre Mod`ele et Capacite
On divise la table en deux :
Avion(Constr*, Mod`ele*)
ModeleAvion(Mod`ele*, Conso, Capacite, VitesseMax)

49/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Troisi`eme forme normale (3FN)

Une relation est en troisi`eme forme normale si et seulement si :

elle est en deuxi`eme forme normale
tout attribut nappartenant pas `a une cle ne depend pas dun
attribut non cle
les dependances fonctionnelles entre deux attributs ordinaires
(ne faisant par partie de la cle) ne sont pas autorisees

50/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Troisi`eme forme normale (3FN)

Exemple :
Enseignant(Nom*, Categorie, Classe, Salaire)
Le salaire depend de la categorie et de la classe
devient
Enseignant(Nom*, Categorie#, Classe#)
Salaire(Categorie*, Classe*, Salaire)

51/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Forme normale de Boyce-Codd (BCNF)

Extension plus rigide de la troisi`eme forme normale (definie
par R.F. Boyce et E.F. Codd en partant du constat que la
3FN comportait certaines anomalies)
Une relation est en forme normale de Boyce-Codd si et
seulement si :
aucun attribut faisant partie de la cle ne depend
dun attribut ne faisant pas partie de la cle primaire
Remarques :
Un mod`ele relationnel en FNBC est considere comme etant de
qualite suffisante pour une limplantation
Les cas de relations en 3FN qui ne sont pas dej`a en FNBC
sont tr`es rares

52/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Forme normale de Boyce-Codd (BCNF)

Exemple 1 :
R(A, B*, C*, D)
Avec les dependances : B,C A, B,C D, D B,
(ce qui entraine de nombreuses redondances)
On propose les relations :
R(A, B*, C*)
R (D*, B)

53/62

Conception & Mod

elisation de Bases de Donn
ees
Affinement des requ
etes

Forme normale de Boyce-Codd (BCNF)

Exemple 2 :
ReservationCourtTennis(NomCourt*, HeureDebut*,
HeureFin, ClasseTauxHoraire)
La classe du taux horaire (SILVER, GOLD, PREMIUM) determine
les courts disponibles.
On propose les relations :
ReservationCourtTennis(NomCourt*, HeureDebut*,
HeureFin)
ClasseCourt(ClassTauxHoraire*, NomCourt)

54/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema physique

Elaboration
du schema physique

Objectifs :
Rechercher de bonnes performances
Prendre en compte les transactions
Indexer, denormaliser, grouper, partitionner les tables
Resultat : mod`ele physique optimise de la base de donnees

55/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema physique

Exemple
Schema relationnel

COURS ( NUM COURS, NOMC, NBHEURES, ANNEE )

PROFESSEURS ( NUM PROF, NOMP, SPECIALITE , DATE ENTREE ,
DER PROM, SALAIRE BASE , SALAIRE ACTUEL )
CHARGE( NUM PROF , NUM COURS )

56/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema physique

Schema physique (SQL2)

c r e a t e t a b l e COURS
(NUM COURS
NUMBER( 2 )
NOT NULL ,
NOMC
VARCHAR( 2 0 )
NOT NULL ,
NBHEURES
NUMBER( 2 ) ,
ANNE
NUMBER( 1 ) ,
c o n s t r a i n t PK COURS p r i m a r y key (NUM COURS) ) ;
c r e a t e t a b l e PROFESSEURS
(NUM PROF
NUMBER( 4 )
NOT NULL ,
NOMP
VARCHAR2( 2 5 )
NOT NULL ,
SPECIALITE
VARCHAR2( 2 0 ) ,
DATE ENTREE
DATE,
DATE,
DER PROM
SALAIRE BASE
NUMBER,
SALAIRE ACTUEL
NUMBER,
c o n s t r a i n t PK PROFESSEURS p r i m a r y key (NUM PROF) ) ;

57/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema physique

Schema physique (SQL2)

c r e a t e t a b l e CHARGE
(NUM PROF
NUMBER( 4 )
NOT NULL ,
NUM COURS
NUMBER( 4 )
NOT NULL ,
c o n s t r a i n t PK CHARGE p r i m a r y key (NUM COURS, NUM PROF) ) ;
a l t e r t a b l e CHARGE
add c o n s t r a i n t FK CHARGE COURS
f o r e i g n key (NUM COURS)
r e f e r e n c e s COURS (NUM COURS ) ;
a l t e r t a b l e CHARGE
add c o n s t r a i n t FK CHARGE PROFESSEUR
f o r e i g n key (NUM PROF)
r e f e r e n c e s PROFESSEURS (NUM PROF ) ;

58/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema physique

Schema physique (SQL2)

Ajout de contraintes
c r e a t e t a b l e COURS
(NUM COURS
NUMBER( 2 ) ,
NOMC
VARCHAR( 2 0 ) ,
NBHEURES
NUMBER( 2 ) ,
ANNE
NUMBER( 1 ) ,
c o n s t r a i n t PK COURS p r i m a r y key (NUM COURS) ,
c o n s t r a i n t NN COURS NOMC c h e c k (NOMC I S NOT NULL ) ) ;
c r e a t e t a b l e PROFESSEURS
NUMBER( 4 ) ,
(NUM PROF
NOMP
VARCHAR2( 2 5 ) ,
SPECIALITE
VARCHAR2( 2 0 ) ,
DATE ENTREE
DATE,
DER PROM
DATE,
SALAIRE BASE
NUMBER,
SALAIRE ACTUE
NUMBER,
c o n s t r a i n t PK PROFESSEURS p r i m a r y key (NUM PROF) ,
c o n s t r a i n t NN PROFESSEURS NOMP c h e c k (NOMP I S NOT NULL ) ) ;

59/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema physique

Schema physique (SQL2)

Ajout de contraintes

c r e a t e t a b l e CHARGE
(NUM PROF
NUMBER( 4 ) ,
NUMBER( 4 ) , ,
NUM COURS
c o n s t r a i n t PK CHARGE p r i m a r y key (NUM COURS, NUM PROF) ) ;
a l t e r t a b l e CHARGE
add c o n s t r a i n t FK CHARGE COURS
f o r e i g n key (NUM COURS)
r e f e r e n c e s COURS (NUM COURS ) ;
a l t e r t a b l e CHARGE
add c o n s t r a i n t FK CHARGE PROFESSEUR
f o r e i g n key (NUM PROF)
r e f e r e n c e s PROFESSEURS (NUM PROF ) ;

60/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema physique

Schema relationnel-objet

COURS ( NUM COURS, NOMC, NBHEURES, ANNEE )

PROFESSEURS ( NUM PROF, NOMP, SPECIALITE , DATE ENTREE ,
DER PROM, SALAIRE BASE , SALAIRE ACTUEL ,
Ensemblede (COURS) )

61/62

Conception & Mod

elisation de Bases de Donn
ees

Elaboration
du sch
ema physique

Schema physique SQL3

create
type c o u r s t y p e as o b j e c t
( n u m c o u r s number ( 2 ) , nomc v a r c h a r 2 ( 2 0 ) , n b h e u r e s number ( 2 ) ,
a n n e e number ( 1 ) )
/
create
type l e s c o u r s t y p e as t a b l e of c o u r s t y p e
/
create
type p r o f e s s e u r t y p e as o b j e c t
( n u m p r o f number ( 4 ) , nom v a r c h a r 2 ( 2 5 ) , s p e c i a l i t e v a r c h a r 2 ( 2 0 ) ,
cours lescours type . . . )
/
create table professeur of professeur type
( p r i m a r y key ( n u m p r o f ) )
n e s t e d t a b l e c o u r s s t o r e a s tabemp
/

62/62