Le relationnel-objet - Cours (Stéphane Crozat)

Conception de bases
de données III
NF17
Cours (Approfondissements)
Stéphane Crozat
Paternité - Pas d'Utilisation Commerciale - Partage des Conditions Initiales à
l'Identique : http://creativecommons.org/licenses/by-nc-sa/4.0/fr/
Publiée le 11 février 2015
Table des
matières
I - Le relationnel-objet
5
1. Introduction : R, OO, RO ............................................................................................................ 5
1.1.
1.2.
1.3.
1.4.
1.5.
Les atouts du modèle relationnel ..............................................................................................................
Les inconvénients du modèle relationnel ....................................................................................................
Les SGBDOO .........................................................................................................................................
Les SGBDRO .........................................................................................................................................
Exercice ..................................................................................................................................................
5
5
6
7
7
2. Le passage conceptuel vers relationnel-objet ................................................................................ 8
2.1. Classe .................................................................................................................................................... 8
2.2. Exercice : Un film classe .......................................................................................................................... 8
2.3. Attributs et méthodes .............................................................................................................................. 9
2.4. Exercice : Un film avec des attributs .......................................................................................................... 9
2.5. Exercice : Un film méthodique ................................................................................................................... 9
2.6. Exercice : Un film vraiment méthodique ................................................................................................... 10
2.7. Association 1:N et 1 :1 .......................................................................................................................... 10
2.8. Exercice : Un film associatif .................................................................................................................... 10
2.9. Association N:M ................................................................................................................................... 10
2.10. Exercice : Un film très associatif ............................................................................................................ 11
2.11. Exercice : Un film très associatif, le retour ............................................................................................. 11
2.12. Composition ........................................................................................................................................ 12
2.13. Exercice : Un film bien composé ............................................................................................................ 12
2.14. Héritage .............................................................................................................................................. 12
2.15. Exercice : RO sans fil ........................................................................................................................... 12
3. Introduction au SQL3 et aux types utilisateurs ......................................................................... 13
3.1. Types utilisateurs .................................................................................................................................. 13
3.2. Déclaration des types utilisateurs en SQL3 (extension au LDD) ................................................................ 13
3.3. Exercice ................................................................................................................................................ 14
4. Exemples RO .............................................................................................................................. 14
4.1. Exemple RO : Gestion de cours .............................................................................................................. 15
4.2. Exemple : Gestion de cours simplifiée (version avec OID) ......................................................................... 17
5. Synthèse : Le relationnel-objet ................................................................................................... 19
6. Bibliographie commentée sur le relationnel-objet ....................................................................... 20
II - La gestion des transactions
21
1. Principes des transactions .......................................................................................................... 21
1.1.
1.2.
1.3.
1.4.
1.5.
Problématique des pannes et de la concurrence ........................................................................................
Notion de transaction ............................................................................................................................
Déroulement d'une transaction ...............................................................................................................
Propriétés ACID d'une transaction .........................................................................................................
Journal des transactions ........................................................................................................................
21
22
22
22
23
2. Fiabilité et transactions .............................................................................................................. 23
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
2.9.
Les pannes ...........................................................................................................................................
Point de contrôle ...................................................................................................................................
Ecriture en avant du journal ..................................................................................................................
Reprise après panne ..............................................................................................................................
Exercice : Mini-TP : Simulation d'une panne sous PostgreSQL ..................................................................
Exemple : Transfert protégé entre deux comptes .......................................................................................
Exercice ................................................................................................................................................
Exercice : Super-héros sans tête ...............................................................................................................
Complément : Algorithme de reprise UNDO-REDO ..................................................................................
23
24
24
24
25
26
26
27
28
3. Concurrence et transactions ....................................................................................................... 29
3.1. Trois problèmes soulevés par la concurrence. ........................................................................................... 30
3.2.
3.3.
3.4.
3.5.
3.6.
Le verrouillage ......................................................................................................................................
Le déverrouillage ...................................................................................................................................
Inter-blocage .........................................................................................................................................
Exercice : Mini-TP : Simulation d'accès concurrents sous PostgreSQL .......................................................
Solution aux trois problèmes soulevés par la concurrence. .........................................................................
32
33
33
34
35
3.7. Exercice ............................................................................................................................................... 36
3.8. Exercice : Films en concurrence .............................................................................................................. 37
3.9. Complément : Protocole d'accès aux données. .......................................................................................... 38
4. Synthèse : Les transactions ........................................................................................................ 39
5. Bibliographie commentée sur les transactions ............................................................................ 39
III - L'optimisation
40
1. Introduction à l'optimisation du schéma interne ........................................................................ 40
1.1. Schéma interne et performances des applications .....................................................................................
1.2. Évaluation des besoins de performance ....................................................................................................
1.3. Indexation ............................................................................................................................................
1.4. Exercice ................................................................................................................................................
1.5. Dénormalisation ....................................................................................................................................
1.6. Les trois principes à respecter pour introduire de la redondance dans une base de données ..........................
1.7. Exercice ................................................................................................................................................
1.8. Partitionnement de table ........................................................................................................................
1.9. Exercice ................................................................................................................................................
1.10. Vues concrètes ....................................................................................................................................
40
41
42
43
43
44
44
45
46
46
1.11. Exercice : Film concret ......................................................................................................................... 47
1.12. Exercice : Super-lents ........................................................................................................................... 47
1.13. Complément : Groupement de tables ...................................................................................................... 48
2. Mécanismes d'optimisation des moteurs de requêtes .................................................................. 49
2.1.
2.2.
2.3.
2.4.
2.5.
Exercice : Calcul du coût d'une requête ....................................................................................................
Principe de l'optimisation de requêtes .....................................................................................................
Techniques pour l'optimisation de requêtes ..............................................................................................
Collecte de statistiques pour le moteur d'optimisation ...............................................................................
Jointures et optimisation de requêtes ......................................................................................................
49
49
50
50
51
3. Synthèse : L'optimisation ........................................................................................................... 51
4. Bibliographie commentée sur l'optimisation ............................................................................... 51
IV - Au delà des bases de données relationnelles
52
1. Introduction aux datawarhouses ................................................................................................ 52
1.1. Présentation du décisionnel .................................................................................................................... 52
1.2. Présentation du data warehousing ........................................................................................................... 53
1.3. Différence entre un DW et un système transactionnel ............................................................................... 53
1.4. Implémentation du DW avec un SGBDR ................................................................................................. 54
1.5. Présentation de la modélisation en étoile ................................................................................................. 54
1.6. L'ETL .................................................................................................................................................. 55
1.7. SGBD orientés décisionnel ..................................................................................................................... 55
2. Introduction à XML ................................................................................................................... 56
2.1. Définition du XML ................................................................................................................................ 56
2.2.
2.3.
2.4.
2.5.
2.6.
Exemple : Un document XML ................................................................................................................
Document bien formé ............................................................................................................................
Balise ...................................................................................................................................................
Notion de document valide .....................................................................................................................
Document Type Definition .....................................................................................................................
57
57
57
58
58
3. Introduction aux bases de données XML ................................................................................... 59
3.1. XML comme format d'échange ............................................................................................................... 59
3.2. Stocker du XML en BD ......................................................................................................................... 59
3.3. Introduction à XPath ............................................................................................................................. 62
4. Brève introduction aux bases de données NoSQL ...................................................................... 62
V - Ouvrage de référence conseillé
64
Contenus annexes
65
Glossaire
77
Abréviations
78
Bibliographie
79
Webographie
80
Le relationnel-objet
Le relationnel-objet
I
Introduction : R, OO, RO
5
Le passage conceptuel vers relationnel-objet
8
Introduction au SQL3 et aux types utilisateurs
13
Exemples RO
14
Synthèse : Le relationnel-objet
19
Bibliographie commentée sur le relationnel-objet
20
Si le modèle logique relationnel a prouvé sa puissance et sa fiabilité au cours des 20 dernières années,
les nouveaux besoins de l'informatique industrielle ont vu l'émergence de structures de données
complexes mal adaptées à une gestion relationnelle. La naissance du courant "orienté objet" et des
langages associées (Java et C++ par exemple) ont donc également investi le champ des SGBDSGBD
- p.78 > afin de proposer des solutions pour étendre les concepts du relationnel et ainsi mieux
répondre aux nouveaux besoins de modélisation.
*
1. Introduction : R, OO, RO
Objectifs
Comprendre les limites du modèle relationnel
Comprendre pourquoi et comment le modèle relationnel peut être étendu
1.1. Les atouts du modèle relationnel
Fondé sur une théorie rigoureuse et des principes simples
Mature, fiable, performant
Indépendance programme et données
SGBDRSGBDR- p.78 > : les plus utilisés, connus, maîtrisés
SQLSQL- p.78 > une implémentation standard du modèle relationnel, avec des APIAPI- p.78 >
pour la plupart des langages de programmation
Les SGBDR incluent des outils performants de gestion de requêtes, de générateurs
d'applications, d'administration, d'optimisation, etc.
*
*
*
1.2. Les inconvénients du modèle relationnel
La structure de donnée en tables est pauvre d'un point de vue de la modélisation logique
Le mapping MCDMCD- p.78 > vers MLDMLD- p.78 > entraîne une perte de sémantique
La manipulation de structures relationnelles par des langages objets entraîne une
impedance mismatch, c'est à dire un décalage entre les structures de données pour le
stockage et les structures de données pour le traitement (ce qui implique des conversions
*
*
5
Stéphane Crozat - UTC
Le relationnel-objet
constantes d'un format à l'autre)
La 1NF1NF- p.78 > est inappropriée à la modélisation d'objets complexes
La normalisation entraîne la genèse de structures de données complexes et très
fragmentées, qui peuvent notamment poser des problèmes de performance ou
d'évolutivité
Le SQL doit toujours être combiné à d'autres langages de programmation pour être
effectivement mis en œuvre
La notion de méthode ne peut être intégrée au modèle logique, elle doit être gérée au
niveau de l'implémentation physique
Les types de données disponibles sont limités et non extensibles
*
1.3. Les SGBDOO
Introduction
Les SGBDOOSGBDOO- p.78 > ont été créés pour gérer des structures de données complexes, en
profitant de la puissance de modélisation des modèles objets et de la puissance de stockage des
BDBD- p.78 > classiques.
*
*
Objectifs des SGBDOO :
Offrir aux langages de programmation orientés objets des modalités de stockage
permanent et de partage entre plusieurs utilisateurs
Offrir aux BD des types de données complexes et extensibles
Permettre la représentation de structures complexes et/ou à taille variable
Avantages des SGBDOO :
Le schéma d'une BD objet est plus facile à appréhender que celui d'une BD relationnelle
(il contient plus de sémantique, il est plus proche des entités réelles)
L'héritage permet de mieux structurer le schéma et de factoriser certains éléments de
modélisation
La création de ses propres types et l'intégration de méthodes permettent une
représentation plus directe du domaine
L'identification des objets permet de supprimer les clés artificielles souvent introduites
pour atteindre la 3NF3NF- p.78 > et donc de simplifier le schéma
Les principes d'encapsulation et d'abstraction du modèle objet permettent de mieux
séparer les BD de leurs applications (notion d'interface).
*
Inconvénient des SGBDOO :
Gestion de la persistance et de la coexistence des objets en mémoire (pour leur
manipulation applicative) et sur disque (pour leur persistance) complexe
Gestion de la concurrence (transactions) plus difficile à mettre en œuvre
Interdépendance forte des objets entre eux
Gestion des pannes
Complexité des systèmes (problème de fiabilité)
Problème de compatibilité avec les SGBDR classiques
Fondamental
Les SGBDOO apportent des innovations sur des aspects que les SGBDR ne savent pas faire, mais
sans être au même niveau sur ce que les SGBDR savent bien faire.
6
Stéphane Crozat - UTC
Le relationnel-objet
1.4. Les SGBDRO
Introduction
Les SGBDROSGBDRO- p.78 > sont nés du double constat de la puissance nouvelle promise par les
SGBDOOSGBDOO- p.78 > et de l'insuffisance de leur réalité pour répondre aux exigences de
l'industrie des BDBD- p.78 > classiques. Leur approche est plutôt d'introduire dans les
SGBDRSGBDR- p.78 > les concepts apportés par les SGBDOO plutôt que de concevoir de
nouveaux systèmes.
*
*
*
*
Objectifs des SGBDRO
Gérer des données complexes (temps, géo-référencement, multimédia, types utilisateurs,
etc.)
Rapprocher le modèle logique du modèle conceptuel
Réduire l'impedance mismatchImpedance mismatch- p.77 §
Réduire les pertes de performance liées à la normalisation et aux jointures
*
Définition : Modèle relationnel-objet
Modèle relationnel étendu avec des principes objet pour en augmenter les potentialités.
Synonymes : Modèle objet-relationnel
Fondamental : Type utilisateur
Le concept central du RO est celui de type utilisateur, correspondant à la classe en POOPOO- p.78 > ,
qui permet d'injecter la notion d'objet dans le modèle relationnel.
*
Les apports principaux des types utilisateurs sont :
La gestion de l'imbrication (données structurées et collections)
Les méthodes et l'encapsulation
L'héritage et la réutilisation de définition de types
L'identité d'objet et les références physiques
Attention : Tables imbriquées et tables objets
Le modèle RO apporte deux nouveautés distinctes et indépendantes à ne pas confondre :
Les tables imbriquées (nested model) qui permettent de dépasser les limites de la première
forme normale et de limiter la fragmentation de l'information ;
Les tables objets qui permettent d'ajouter les identifiants d'objets (OID), les méthodes et
l'héritage aux tables classiques.
Avec un SGBDRO on peut ne pas utiliser ces deux extensions (on reste alors en relationnel), utiliser
l'une des deux ou bien les deux conjointement.
1.5. Exercice
Parmi les assertions suivantes, lesquelles expriment des limites des SGBDR qui justifient l'évolution
du modèle relationnel classique vers le modèle relationnel-objet ?
Le principe d'atomicité des attributs d'une relation (première forme normale) empêche de
disposer de propriétés structurant plusieurs valeurs dans un type complexe.
La séparation des données et des traitements empêche l'intégration des méthodes au modèle.
La représentation de données complexes conduit à une fragmentation importante de
l'information en de multiples relations et à des chutes de performance.
Le modèle relationnel ne permet pas d'exécuter correctement des transactions en réseau.
7
Stéphane Crozat - UTC
Le relationnel-objet
Il n'est pas possible de créer des types de données personnalisées.
Il n'est pas possible d'exécuter des instructions SQL1 ou SQL2 à partir d'un langage objet tel
que Java, alors que c'est possible avec SQL3.
L'héritage n'est pas représentable directement.
2. Le passage conceptuel vers relationnel-objet
Objectifs
Savoir déduire un modèle logique relationnel-objet depuis un modèle conceptuel
E-A ou UML.
Intégrer les apports du modèle relationnel-objet par rapport au relationnel dans
ce processus.
Cette partie permet de traiter la traduction d'un modèle conceptuel UMLUML- p.78 > ou E-AE-A- p.78 >
en modèle relationnel-objet. Le modèle E-A étendu est bien plus adapté au relationnel-objet que le
modèle E-A classique.
*
*
2.1. Classe
Pour chaque classe (ou entité), créer un type d'objet avec les attributs de la classe (ou entité).
Créer une table d'objets de ce type pour instancier la classe (ou entité), en ajoutant les
contraintes d'intégrité.
Remarque : Table d'objet
La fait d'instancier la classe (l'entité) via une table d'objets plutôt qu'une relation classique, permet
l'accès à l'héritage de type, à l'implémentation des méthodes et éventuellement à l'usage d'OIDOID
- p.78 > à la place de clés étrangères classiques.
*
Si aucun de ces aspects n'est utilisé, il est possible d'instancier directement la classe (l'entité) en
table. Mais le passage par un type est a priori plus systématique.
Remarque : Mapping des méthodes
Si le modèle conceptuel autorise l'expression de méthodes ( UMLUML- p.78 > ou extension de E-AE-A
- p.78 > ), alors on ajoute la définition de ces méthodes sur le type d'objet créé pour de chaque classe
(ou entité).
*
*
2.2. Exercice : Un film classe
Question
Proposer un modèle RO correspondant au modèle UML.
Film (classe)
8
Stéphane Crozat - UTC
Le relationnel-objet
2.3. Attributs et méthodes
Attributs composites
Pour chaque type d'attribut composé, créer un type d'objet.
Attributs multi-valués
Pour chaque attribut multi-valué créer une collection du type de cet attribut.
Remarque : Attributs composites multi-valués
Si l'attribut multi-valué est composite, alors créer une collection d'objets.
Attributs dérivés te méthodes
Pour chaque attribut dérivé et chaque méthode créer une méthode associée au type d'objet de la
classe (l'entité).
2.4. Exercice : Un film avec des attributs
Question
Proposer un modèle RO correspondant au modèle UML.
Film (attribut multi-valué)
2.5. Exercice : Un film méthodique
Question
Proposer un modèle RO correspondant au modèle UML.
Film (méthode)
9
Stéphane Crozat - UTC
Le relationnel-objet
2.6. Exercice : Un film vraiment méthodique
Question
Proposer une implémentation SQL3 sous Oracle correspondant au modèle UML. La méthode
DureeTournage sera implémentée de façon à retourner un nombre entier de jours.
Film (méthode)
Indices :
On pourra utiliser une fonction duree(debut,fin) qui retourne le nombre de jours entre deux
dates.
On fera un usage explicite de SELF.
2.7. Association 1:N et 1 :1
Les associations 1:N et 1:1 sont gérées comme en relationnel.
On peut néanmoins favoriser l'usage d'objets pour les clés étrangères composées de plusieurs
attributs, ainsi que pour les attributs des classes d'association.
Il est aussi possible de gérer la clé étrangère avec un OID à la place d'une clé étrangère
classique.
2.8. Exercice : Un film associatif
Question
Proposer un modèle RO correspondant au modèle UML, en utilisant les OID.
Film (association 1:N)
2.9. Association N:M
Les associations N:M peuvent être gérées comme en relationnel.
Il est aussi possible de gérer ces relations, en utilisant une collection de références (une collection
de clés étrangères) (NB : on favorise ainsi une des deux relations).
10
Stéphane Crozat - UTC
Le relationnel-objet
Il est aussi possible de gérer ces relations en utilisant un OID comme clé étrangère.
Il est aussi possible de gérer ces relations en utilisant une collection de référence OID.
Remarque : Collection de clés étrangères
Oracle n'autorise pas (à ma connaissance ...) la spécification de contraintes d'intégrité référentielle
dans une table imbriquée. Ce qui limite l'utilisation de telles tables pour gérer des relations N:M avec
des collections de clés étrangères.
Par contre cela fonctionne avec des références à des OID.
2.10. Exercice : Un film très associatif
Question
Proposer un modèle RO correspondant au modèle UML, en utilisant les OID, mais pas de table
imbriquée.
Film (association M:N)
2.11. Exercice : Un film très associatif, le retour
Question
Proposer un modèle RO correspondant au modèle UML, en utilisant les OID et en utilisant une
table imbriquée.
Film (association M:N)
Indice :
Les films étant le centre de notre BD, c'est dans cette table que l'on imbriquera les références.
11
Stéphane Crozat - UTC
Le relationnel-objet
2.12. Composition
En RO, les compositions sont gérées avec le modèle imbriqué, à l'instar des attributs composés
et multi-valués : en effet par définition l'élément composant ne peut être partagé par plusieurs
composites, le modèle imbriqué n'introduit donc pas de redondance.
1. Créer un type correspondant au schéma de la table des composants
2. Créer une collection de ce type
3. Imbriquer cette collection dans la table des composites
2.13. Exercice : Un film bien composé
Question
Proposer un modèle RO correspondant au modèle UML.
Film (composition)
2.14. Héritage
L'héritage est géré comme en relationnel classique.
En cas d'héritage par les classes filles, l'on peut profiter de l'héritage de type pour éliminer
la redondance dans la définition des schémas.
2.15. Exercice : RO sans fil
[30 minutes]
L'on souhaite réaliser une base de données permettant de gérer tous les relais Wifi sur un
site d'entreprise. Chaque relais est identifié par une coordonnée géographique (de type
CooT, dont le code est fourni ci-après) et fait référence à un modèle. On associe également
à chaque relais son prix d'achat. Chaque modèle est décrit par une marque et un type et
possède une puissance.
1 CREATE TYPE CooT AS OBJECT (
2 latitude real,
3 longitude real
4 );
Question 1
Proposez une implémentation RO SQL3 sous Oracle exploitant les tables-objets et le modèle imbriqué
(vous pouvez faire un MCD et un MLD préalablement pour vous aider).
12
Stéphane Crozat - UTC
Le relationnel-objet
Question 2
Insérer les données suivantes dans votre base de données :
Un modèle de marque SuperWif et de type X1, puissance 25mW
Deux relais de ce modèle respectivement aux coordonnées (48.853 ; 2.35) et (48.978 ; 3.01), achetés
chacun 100€.
Question 3
Écrivez deux requêtes permettant de renvoyer respectivement :
La puissance du relais situé à la coordonnée (47.5 ; 1.5)
La moyenne des prix des relais pour chaque modèle (type et marque)
3. Introduction au SQL3 et aux types utilisateurs
Objectifs
Connaître les caractéristiques principales du modèle relationnel-objet
Connaître l'extension du LDD pour la déclaration de type (CREATE TYPE)
3.1. Types utilisateurs
Définition : Type utilisateur
Type de données créé par le concepteur d'un schéma relationnel-objet, qui encapsule des données et
des opérations sur ces données. Ce concept est à rapprocher de celui de classe d'objets.
Synonymes : Type de données utilisateur, Type de données abstrait
Syntaxe : Niveau logique
1 Type nom_type : <
2 attribut1:typeAttribut1,
3 attribut2:typeAttribut2,
4 ...
5 attributN:typeAttributN,
6 =methode1:(paramètres) typeRetourné1,
7 =methode2:(paramètres) typeRetourné2,
8 =...
9 =methodeN:(paramètres) typeRetournéN
10 >
Fondamental
Les types des attributs (ou des méthodes) d'un type peuvent également être des types utilisateurs.
C'est ce principe qui permet l'imbrication de données relationnelles.
3.2. Déclaration des types utilisateurs en SQL3 (extension au LDD)
Syntaxe : Déclaration de type
1 CREATE TYPE nom_type AS OBJECT (
13
Stéphane Crozat - UTC
Le relationnel-objet
2 nom_attribut1 type_attribut1
3 ...
4 MEMBER FUNCTION nom_fonction1 (parametre1 IN|OUT type_parametre1, ...) RETURN
type_fonction1
5 ...
6 ) [NOT FINAL];
7/
8 CREATE TYPE BODY nom_type
9 IS
10 MEMBER FUNCTION nom_fonction1 (...) RETURN type_fonction1
11 IS
12 BEGIN
13 ...
14 END ;
15 MEMBER FUNCTION nom_fonction2 ...
16 ...
17 END ;
18 END ;
19 /
Syntaxe : Héritage de type
1 CREATE TYPE sous_type UNDER sur_type (
2 Déclarations spécifiques ou surcharges
3) ;
Remarque : NOT FINAL
Pour être héritable, un type doit être déclaré avec la clause optionnelle NOT FINAL.
Remarque : Type retourné par une méthode
« The datatype cannot specify a length, precision, or scale. »
http://docs.oracle.com/cd/B13789_01/server.101/b10759/statements_5009.htm
3.3. Exercice
Parmi les possibilités de modélisation logique suivantes, lesquelles peuvent être réalisées en
relationnel-objet mais pas en relationnel.
Associer des méthodes aux tables
Mettre plusieurs valeurs dans un enregistrement
Référencer un enregistrement depuis un autre enregistrement
Définir ses propres types de données
4. Exemples RO
14
Stéphane Crozat - UTC
Le relationnel-objet
4.1. Exemple RO : Gestion de cours
Modèle conceptuel
Modèle conceptuel en UML
Modèle logique
1 Type Bureau : <
2 poste:entier,
3 centre:chaîne,
4 bâtiment:chaîne,
5 numéro:entier,
6 =coordonnées():chaîne
7>
8 Type Personne : < nom:chaîne, prénom:chaîne >
9 Type Intervenant hérite de Personne : < bureau:Bureau >
10 tIntervenant de Intervenant (#nom, #prénom)
11 Type RefIntervenant : <nom:chaîne, prénom:chaîne>
12 Type ListeRefIntervenants: collection de <RefIntervenant>
13 Type Cours(semestre:chaîne, num:entier, titre:chaîne, type:enum,
contenu:chaîne, lIntervenant:ListeRefIntervenant)
14 tCours de Cours (#semestre, #num)
Remarque : Méthode coordonnées()
On a choisi de mettre la méthode coordonnées au niveau du type Bureau plutôt que du type
Personne, pour augmenter les possibilités de réutilisabilité (car d'autres entités que Intervenant
pourraient utiliser le type Bureau). C'est une possibilité offerte par le fait que les attributs composés
donnent naissance à des types utilisateurs (on décide donc de remonter certaines méthodes qui ne
concerne que cet attribut composé au niveau de ce type).
Implémentation
1 CREATE TYPE Bureau AS OBJECT (
2 poste number(4),
3 centre char(2),
15
Stéphane Crozat - UTC
Le relationnel-objet
4 batiment char(1),
5 numero number(3),
6 MEMBER FUNCTION coordonnees RETURN varchar2
7 );
8 CREATE TYPE BODY Bureau
9 IS
10 MEMBER FUNCTION coordonnees RETURN varchar2
11 IS
12 BEGIN
13 RETURN centre||batiment||numero||' - poste '||poste;
14 END;
15 END;
16
17 CREATE TYPE Personne AS OBJECT(
18 pkNom varchar2(50),
19 pkPrenom varchar2(50)
20 ) NOT FINAL ;
21
22 CREATE TYPE Intervenant UNDER Personne (
23 aBureau Bureau
24 );
25
26 CREATE TABLE tIntervenant OF Intervenant (
27 PRIMARY KEY(pkNom,pkPrenom)
28 );
29
30 CREATE TYPE RefIntervenant AS OBJECT (
31 nom varchar2(50),
32 prenom varchar2(50)
33 );
34 CREATE TYPE ListeRefIntervenants AS TABLE OF RefIntervenant;
35
36 CREATE TYPE Cours AS OBJECT(
37 pkSemestre char(5),
38 pkNum number(2),
39 aTitre varchar2(50),
40 aType char(2),
41 aContenu varchar2(300),
42 lIntervenant ListeRefIntervenants
43 );
44
45 CREATE TABLE tCours OF Cours (
46 PRIMARY KEY(pkSemestre, pkNum),
47 CHECK (aType='C' or aType='TD' or aType='TP')
48 )
49 NESTED TABLE lIntervenant STORE AS ntCoursIntervenants;
Initialisation
1 INSERT INTO tIntervenant VALUES ('CROZAT', 'Stéphane',
Bureau('4287','R','A',108));
2 INSERT INTO tIntervenant VALUES ('JOUGLET', 'Antoine',
Bureau('4423','R','C',100));
3
4 INSERT INTO tCours VALUES ('P2003',1,'Conception','C','E-A et UML',
ListeRefIntervenants(RefIntervenant('CROZAT','Stéphane')));
5 INSERT INTO tCours VALUES ('P2003',5,'Access','TP','Initiation',
ListeRefIntervenants(RefIntervenant('CROZAT','Stéphane'),
RefIntervenant('JOUGLET','Antoine')));
16
Stéphane Crozat - UTC
Le relationnel-objet
Question (méthode)
1 SELECT t.pkNom||' '||t.pkPrenom AS Qui, t.aBureau.coordonnees() AS Ou
2 FROM tIntervenant t;
3
4 QUI
OU
5 ------------------------------------6 CROZAT Stéphane
R A108 - poste 4287
7 JOUGLET Antoine
R C100 - poste 4423
Question (nested table)
1 SELECT c.pkSemestre AS Quand,c.aTitre AS Quoi,ci.Nom AS Qui
2 FROM tCours c, TABLE(c.lIntervenant) ci;
3
4 QUAND QUOI
QUI
5 -----------------------------6 P2003 Conception CROZAT
7 P2003 Access
CROZAT
8 P2003 Access
JOUGLET
Question (jointure)
1 SELECT c.pkSemestre AS Quand,c.aTitre AS Quoi,i.pkNom AS
Qui,i.aBureau.coordonnees() AS Ou
2 FROM tCours c, TABLE(lIntervenant) ci, tIntervenant i
3 WHERE ci.nom=i.pkNom AND ci.prenom=i.pkPrenom;
4
5 QUAND QUOI
QUI
OU
6 ------------------------------------------------7 P2003 Conception CROZAT
R A108 - poste 4287
8 P2003 Access
CROZAT
R A108 - poste 4287
9 P2003 Access
JOUGLET
R C100 - poste 4423
4.2. Exemple : Gestion de cours simplifiée (version avec OID)
4.2.1. Modèle conceptuel
Modèle conceptuel en UML
4.2.2. Modèle logique
1 Type Intervenant : < nom:chaîne, prénom:chaîne >
2 tIntervenant de Intervenant (#nom)
17
Stéphane Crozat - UTC
Le relationnel-objet
3 Type Cours(num:entier, titre:chaîne, fkIntervenant =>o tIntervenant)
4 tCours de Cours (#num)
4.2.3. Implémentation
1 CREATE TYPE Intervenant AS OBJECT (
2 pkNom varchar2(50),
3 aPrenom varchar2(50)
4 );
5
6 CREATE TABLE tIntervenant OF Intervenant (PRIMARY KEY (pkNom));
7
8 CREATE TYPE Cours AS OBJECT (
9 pkNum number(2),
10 aTitre varchar2(50),
11 fkIntervenant REF Intervenant
12 );
13
14 CREATE TABLE tCours OF Cours (
15 SCOPE FOR (fkIntervenant) IS tIntervenant,
16 PRIMARY KEY(pkNum)
17 );
4.2.4. Initialisation de la table d'objets tIntervenant
1 INSERT INTO tIntervenant
2 VALUES ('CROZAT', 'Stéphane');
4.2.5. Insertion de données dans la table d'objets tCours (SQL)
1 INSERT INTO tCours
2 SELECT 2, 'Modélisation', REF(i)
3 FROM tIntervenant i
4 WHERE pkNom='CROZAT';
4.2.6. Insertion de données dans la table tCours (PL/SQL)
1 DECLARE
2 ri REF Intervenant;
3 BEGIN
4 SELECT REF(i) INTO ri
5 FROM tIntervenant i
6 WHERE i.pkNom='CROZAT';
7 INSERT INTO tCours
8 VALUES (1,'Conception',ri);
9 END;
4.2.7. Sélection : Clé étrangère sous forme d'OID
1 SELECT * FROM tCours;
2
3 PKNUM ATITRE FKINTERVENANT
4 -----------------------------------------------------------5 1 Conception
0000220208DE4BD8F3191044589847E31E64B83EBB5807280A335B44C4AD958EDF20D185B5
6 2 Modélisation
0000220208DE4BD8F3191044589847E31E64B83EBB5807280A335B44C4AD958EDF20D185B5
18
Stéphane Crozat - UTC
Le relationnel-objet
4.2.8. Sélection : Jointure sur l'OID
Contre-exemple : ce qu'il ne faut pas faire !
1 SELECT c.pkNum, i.pkNom
2 FROM tCours c, tIntervenant i
3 WHERE c.fkIntervenant=REF(i);
4
5 PKNUM PKNOM
6 ------------------------7 1 CROZAT
8 2 CROZAT
4.2.9. Sélection : Navigation d'objets
1 SELECT pkNum, c.fkIntervenant.pkNom
2 FROM tCours c
3
4 PKNUM PKNOM
5 ------------------------6 1 CROZAT
7 2 CROZAT
5. Synthèse : Le relationnel-objet
Types
Pré-définis
Domaines classiques
Chaîne, Entier, Date, Booléen, etc.
Domaines avancés
CLOB, BLOB, etc.
Définis par l'utilisateur
Relation
Comme dans le modèle relationnel classique
Objets
Types utilisateurs
Collections
Tables imbriquées
Modèle RO
Modèle imbriqué
Table d'objets
CREATE TYPE
CREATE TABLE OF
Collection
NESTED TABLE
Type utilisateur
OID
REF
SCOPE FOR
19
Stéphane Crozat - UTC
Le relationnel-objet
Héritage de type
NOT FINAL
Méthode
MEMBER FUNCTION
CREATE TYPE BODY
6. Bibliographie commentée sur le relationnel-objet
Complément : Synthèse SQL3 sous Oracle 8i
SQL2 SQL3, applications à OracleDelmal01- p.79 ¨
*
On consultera les chapitre 11 et 12 pour avoir une description des extensions SQL3 et de ses
implémentations et extensions sous Oracle (version 8i).
20
Stéphane Crozat - UTC
La gestion des transactions
La gestion des
transactions
II
Principes des transactions
21
Fiabilité et transactions
23
Concurrence et transactions
29
Synthèse : Les transactions
39
Bibliographie commentée sur les transactions
39
Les transactions sont une réponse générale aux problèmes de fiabilité et d'accès concurrents dans les
BD, et en particulier dans les BD en mode client-serveur. Elles sont le fondement de toute
implémentation robuste d'une BD. Des systèmes comme Oracle ne fonctionnent nativement qu'en
mode transactionnel.
1. Principes des transactions
Objectifs
Comprendre les principes et l'intérêt des transactions
1.1. Problématique des pannes et de la concurrence
Une BDBD- p.78 > est un ensemble persistant de données organisées qui a en charge la
préservation de la cohérence de ces données. Les données sont cohérentes si elles respectent
l'ensemble des contraintes d'intégrité spécifiées pour ces données : contraintes de domaine,
intégrité référentielle, dépendances fonctionnelles...
*
La cohérence des données peut être remise en cause par deux aspects de la vie d'une BD :
La défaillance
Lorsque le système tombe en panne alors qu'un traitement est en cours, il y a un risque
qu'une partie seulement des instructions prévues soit exécutée, ce qui peut conduire à des
incohérences. Par exemple pendant une mise à jour en cascade de clés étrangères suite au
changement d'une clé primaire.
La concurrence
Lorsque deux accès concurrents se font sur les données, il y a un risque que l'un des deux
accès rende l'autre incohérent. Par exemple si deux utilisateurs en réseau modifient une
donnée au même moment, seule une des deux mises à jour sera effectuée.
La gestion de transactions par un SGBDSGBD- p.78 > est à la base des mécanismes qui permettent
d'assurer le maintien de la cohérence des BD. C'est à dire encore qu'il assure que tous les
contraintes de la BD seront toujours respectées, même en cas de panne et même au cours
d'accès concurrents.
*
21
Stéphane Crozat - UTC
La gestion des transactions
1.2. Notion de transaction
Définition : Transaction
Une transaction est une unité logique de travail, c'est à dire une séquence d'instructions, dont
l'exécution assure le passage de la BDBD- p.78 > d'un état cohérent à un autre état cohérent.
*
Fondamental : Cohérence des exécutions incorrectes
La transaction assure le maintien de la cohérence des données que son exécution soit correcte ou
incorrecte.
Exemple : Exemples d'exécutions incorrectes
L'exécution d'une transaction peut être incorrecte parce que :
Une panne a lieu
Un accès concurrent pose un problème
Le programme qui l'exécute en a décidé ainsi
1.3. Déroulement d'une transaction
1. DEBUT
2. TRAITEMENT
Accès aux données en lecture
Accès aux données en écriture
3. FIN
Correcte : Validation des modifications
Incorrecte : Annulation des modifications
Fondamental
Tant qu'une transaction n'a pas été terminée correctement, elle doit être assimilée à une tentative
ou une mise à jour virtuelle, elle reste incertaine. Une fois terminée correctement la transaction ne
peut plus être annulée par aucun moyen.
1.4. Propriétés ACID d'une transaction
Une transaction doit respecter quatre propriétés fondamentales :
L'atomicité
Les transactions constituent l'unité logique de travail, toute la transaction est exécutée
ou bien rien du tout, mais jamais une partie seulement de la transaction.
La cohérence
Les transactions préservent la cohérence de la BDBD- p.78 > , c'est à dire qu'elle transforme
la BD d'un état cohérent à un autre (sans nécessairement que les états intermédiaires
internes de la BD au cours de l'exécution de la transaction respectent cette cohérence)
L'isolation
Les transactions sont isolées les unes des autres, c'est à dire que leur exécution est
indépendante des autres transactions en cours. Elles accèdent donc à la BD comme si
elles étaient seules à s'exécuter, avec comme corollaire que les résultats intermédiaires
d'une transaction ne sont jamais accessibles aux autres transactions.
La durabilité
Les transactions assurent que les modifications qu'elles induisent perdurent, même en cas
de défaillance du système.
*
22
Stéphane Crozat - UTC
La gestion des transactions
Remarque
Les initiales de Atomicité, Cohérence, Isolation et Durabilité forme le mot mnémotechnique ACID.
1.5. Journal des transactions
Définition : Journal
Le journal est un fichier système qui constitue un espace de stockage redondant avec la BDBD- p.78 > .
Il répertorie l'ensemble des mises à jour faites sur la BD (en particulier les valeurs des
enregistrements avant et après mise à jour). Le journal est donc un historique persistant (donc en
mémoire secondaire) qui mémorise tout ce qui se passe sur la BD.
*
Le journal est indispensable pour la validation (COMMIT), l'annulation (ROLLBACK) et la reprise
après panne de transactions.
Synonymes : Log
2. Fiabilité et transactions
Objectifs
Appréhender la gestion des pannes dans les SGBD.
Comprendre la réponse apportée par la gestion des transactions.
2.1. Les pannes
Une BDBD- p.78 > est parfois soumise à des défaillances qui entraînent une perturbation, voire un
arrêt, de son fonctionnement.
*
On peut distinguer deux types de défaillances :
Les défaillances système
ou défaillances douces (soft crash), par exemple une coupure de courant ou une panne
réseau. Ces défaillances affectent toutes les transactions en cours de traitement, mais pas
la BD au sens de son espace de stockage physique.
Les défaillances des supports
ou défaillances dures (hard crash), typiquement le disque dur sur lequel est stockée la
BD. Ces défaillances affectent également les transactions en cours (par rupture des accès
aux enregistrements de la BD), mais également les données elles-mêmes.
Remarque : Annulation des transactions non terminées
Lorsque le système redémarre après une défaillance, toutes les transactions qui étaient en cours
d'exécution (pas de COMMIT) au moment de la panne sont annulés (ROLLBACK imposé par le
système).
Cette annulation assure le retour à un état cohérent, en vertu des propriétés ACIDACID- p.78 > des
transactions.
*
Remarque : Ré-exécution des transactions terminées avec succès
Au moment de la panne certaines transactions étaient peut-être terminées avec succès (COMMIT)
mais non encore (ou seulement partiellement) enregistrées dans la BD (en mémoire volatile, tampon,
etc.). Lorsque le système redémarre il doit commencer par rejouer ces transactions, qui assurent un
état cohérent de la BD plus avancé.
23
Stéphane Crozat - UTC
La gestion des transactions
Cette reprise des transactions après COMMIT est indispensable dans la mesure où c'est bien
l'instruction COMMIT qui assure la fin de la transaction et donc la durabilité. Sans cette gestion,
toute transaction pourrait être remise en cause.
Remarque : Unité de reprise
Les transactions sont des unités de travail, et donc également de reprise.
Remarque : Défaillance des supports
Tandis que la gestion de transactions et de journal permet de gérer les défaillances systèmes, les
défaillances des supports ne pourront pas toujours être gérés par ces seuls mécanismes.
Il faudra leur adjoindre des procédures de sauvegarde et de restauration de la BD pour être capable
au pire de revenir dans un état antérieur cohérent et au mieux de réparer complètement la BD (cas
de la réplication en temps réel par exemple).
2.2. Point de contrôle
Définition : Point de contrôle
Un point de contrôle est une écriture dans le journal positionnée automatiquement par le système qui
établit la liste de toutes les transactions en cours (au moment où le point de contrôle est posé) et
force la sauvegarde des données alors en mémoire centrale dans la mémoire secondaire.
Le point de contrôle est positionné à intervalles de temps ou de nombre d'entrées.
Le dernier point de contrôle est le point de départ d'une reprise après panne, dans la mesure où c'est
le dernier instant où toutes les données ont été sauvegardées en mémoire non volatile.
Synonymes : Syncpoint
2.3. Ecriture en avant du journal
Fondamental
On remarquera que pour que la reprise de panne soit en mesure de rejouer les transactions, la
première action que doit effectuer le système au moment du COMMIT est l'écriture dans le journal
de cette fin correcte de transaction. En effet ainsi la transaction pourra être rejouée, même si elle n'a
pas eu le temps de mettre effectivement à jour les données dans la BD, puisque le journal est en
mémoire secondaire.
2.4. Reprise après panne
Introduction
Le mécanisme de reprise après panne s'appuie sur le journal et en particulier sur l'état des
transactions au moment de la panne et sur le dernier point de contrôle.
Le schéma ci-après illustre les cinq cas de figure possibles pour une transaction au moment de la
panne.
24
Stéphane Crozat - UTC
La gestion des transactions
États d'une transaction au moment d'une panne
Transactions de type T1
Elles ont débuté et se sont terminées avant tc. Elles n'interviennent pas dans le processus
de reprise.
Transactions de type T2
Elles ont débuté avant tc et se sont terminées entre tc et tf. Elles devront être rejouées
(il n'est pas sûr que les données qu'elles manipulaient aient été correctement inscrites en
mémoire centrale, puisque après tc, or le COMMIT impose la durabilité).
Transactions de type T3
Elles ont débuté avant tc, mais n'était pas terminées à tf. Elles devront être annulées
(pas de COMMIT).
Transactions de type T4
Elles ont débuté après tc et se sont terminées avant tf. Elles devront être rejouées.
Transactions de type T5
Elles ont débuté après tc et ne se sont pas terminées. Elles devront être annulées.
Remarque
Les transactions sont des unités d'intégrité.
2.5. Exercice : Mini-TP : Simulation d'une panne sous PostgreSQL
1. Se connecter à une base de données : psql mydb
2. Créer une table test : CREATE TABLE test (a integer);
Question
1.
2.
3.
4.
5.
Commencer une transaction : BEGIN TRANSACTION;
Insérer les deux valeurs 1 et 2 dans la table : INSERT INTO...
Vérifier que les valeurs sont bien dans la table : SELECT * FROM ...
Simuler un crash en fermant le terminal : ROLLBACK du système
Se reconnecter et vérifier que les valeurs ne sont plus dans la table : SELECT * FROM ...
25
Stéphane Crozat - UTC
La gestion des transactions
2.6. Exemple : Transfert protégé entre deux comptes
Exemple : Transfert entre deux comptes en SQL standard sous PostgreSQL
1 BEGIN;
2 UPDATE Compte1 SET Solde=Solde+100 WHERE Num=1;
3 UPDATE Compte2 SET Solde=Solde-100 WHERE Num=1;
4 COMMIT;
5/
Exemple : Transfert entre deux comptes en PL/SQL sous Oracle
1 CREATE OR REPLACE PROCEDURE myTransfC1C2
2 IS
3 BEGIN
4 UPDATE Compte1 SET Solde=Solde+100 WHERE Num=1;
5 UPDATE Compte2 SET Solde=Solde-100 WHERE Num=1;
6 COMMIT;
7 END;
8/
Exemple : Transfert entre deux comptes en VBA sous Access
1 Sub myTransfC1C2
2 BeginTrans
3 CurrentDb.CreateQueryDef("", "UPDATE Compte1 SET Solde=Solde+100 WHERE Num=1")
.Execute
4 CurrentDb.CreateQueryDef("", "UPDATE Compte2 SET Solde=Solde-100 WHERE Num=1")
.Execute
5 CommitTrans
6 End Sub
Fondamental : Transfert protégé
Pour les trois exemples ci-avant le transfert est protégé au sens où soit les deux UPDATE seront
exécutés , soit aucun.
En cas de panne pendant la transaction, le transfert sera annulé ( ROLLBACK système), mais en
aucun cas un des deux comptes ne pourra être modifié sans que l'autre le soit (ce qui aurait entraîné
une perte ou un gain sur la somme des deux comptes).
2.7. Exercice
Pour faire un transfert sécurisé d'un point de vue transactionnel de 100€ du compte bancaire C1
vers le compte bancaire C2 pour le compte numéro 12, quelle est la série d'instructions correcte (en
mode autocommit off)?
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
ROLLBACK;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12
ROLLBACK;
26
Stéphane Crozat - UTC
La gestion des transactions
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
COMMIT;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
ROLLBACK;
UPDATE C2 SET Solde=Solde-100 WHERE Numero=12;
ROLLBACK;
2.8. Exercice : Super-héros sans tête
[10 minutes]
Les usines GARVEL construisent des figurines de super-héros à partir des données
présentes dans la base de données PostgreSQL de l'entreprise. Un gros problème est
survenu le mois dernier, lorsque l'usine en charge d'une nouvelle figurine, Superchild, a
livré un million d'exemplaires sans tête. À l'analyse de la base il a en effet été observé que
la base contenait un tuple "Superchild" dans la table Personnage, et cinq tuples associés
dans la table Membre, deux pour les bras, deux pour les jambes et un pour le torse, mais
aucun pour la tête.
Le service qui a opéré la saisie du nouveau personnage assure, sans ambiguïté possible, que
la tête a pourtant été saisie dans la base. En revanche, l'enquête montre des instabilités de
son réseau à cette période.
L'extrait du modèle UML utile au problème est proposé ci-après, ainsi que le code SQL
exécuté via le client psql lors de l'insertion de la nouvelle figurine.
Modèle UML Figurines GARVEL (extrait)
1 \set AUTOCOMMIT on
2 INSERT INTO Personnage (designation, prix, identite_secrete, genre) VALUES (
'Superchild','12','Jordy','superhéros') ;
27
Stéphane Crozat - UTC
La gestion des transactions
3 INSERT INTO
'bleu') ;
4 INSERT INTO
'bleu') ;
5 INSERT INTO
'bleu') ;
6 INSERT INTO
'bleu') ;
7 INSERT INTO
) ;
8 INSERT INTO
Membre (propriétaire, nom, couleur) VALUES ('Superchild','bras droit',
Membre (propriétaire, nom, couleur) VALUES ('Superchild','bras gauche',
Membre (propriétaire, nom, couleur) VALUES ('Superchild','jambe gauche',
Membre (propriétaire, nom, couleur) VALUES ('Superchild','jambe droite',
Membre (propriétaire, nom, couleur) VALUES ('Superchild','torse','rouge'
Membre (propriétaire, nom, couleur) VALUES ('Superchild','tete','rose') ;
Question 1
Expliquer la nature du problème qui est probablement survenu. Proposer une solution générale pour que
le problème ne se renouvelle pas, en expliquant pourquoi.
Soyez concis et précis : La bonne mobilisation des concepts du domaine et la clarté de la rédaction
seront appréciées.
Question 2
Illustrer la solution proposée en corrigeant le code SQL de l'insertion de "Superchild".
2.9. Complément : Algorithme de reprise UNDO-REDO
Introduction
L'algorithme suivant permet d'assurer une reprise après panne qui annule et rejoue les
transactions adéquates.
1 1. SOIT deux listes REDO et UNDO
2 1a. Initialiser la liste REDO à vide
3 1b. Initialiser la liste UNDO avec toutes les transactions en cours au
dernier point de contrôle
4
5 2. FAIRE une recherche en avant dans le journal, à partir du point de
contrôle
6 2a. SI une transaction T est commencée ALORS ajouter T à UNDO
7 2b. SI une transaction T est terminée avec succès alors déplacer T de UNDO à
REDO
8
9 3. QUAND la fin du journal est atteinte
10 3a. Annuler les transactions de la liste UNDO (reprise en arrière)
11 3b. Rejouer les transactions de la liste REDO (reprise en avant)
12
13 4. TERMINER la reprise et redevenir disponible pour de nouvelles instructions
28
Stéphane Crozat - UTC
La gestion des transactions
Exemple
États d'une transaction au moment d'une panne
Transactions de type T1
Non prises en compte par l'algorithme.
Transactions de type T2
Ajoutées à la liste UNDO (étape 1b) puis déplacée vers REDO (étape 2b) puis rejouée (étape
3b).
Transactions de type T3
Ajoutées à la liste UNDO (étape 1b) puis annulée (étape 3a).
Transactions de type T4
Ajoutées à la liste UNDO (étape 2a) puis déplacée vers REDO (étape 2b) puis rejouée (étape
3b).
Transactions de type T5
Ajoutées à la liste UNDO (étape 2a) puis annulée (étape 3a).
* *
*
On voit que la gestion transactionnelle est un appui important à la reprise sur panne, en ce qu'elle assure
des états cohérents qui peuvent être restaurés.
3. Concurrence et transactions
Objectifs
Appréhender la gestion de la concurrence dans les SGBD.
Comprendre la réponse apportée par la gestion des transactions.
29
Stéphane Crozat - UTC
La gestion des transactions
3.1. Trois problèmes soulevés par la concurrence.
Introduction
Nous proposons ci-dessous trois problèmes posés par les accès concurrents des transactions aux
données.
3.1.1. Perte de mise à jour
Tableau 1 Problème de la perte de mise à jour du tuple T par la transaction A
Les transaction A et B accèdent au même tuple T ayant la même valeur respectivement à t1 et
t2. Ils modifient chacun la valeur de T. Les modifications effectuées par A seront perdues
puisqu'elle avait lu T avant sa modification par B.
Exemple
Tableau 2 Doucle crédit d'un compte bancaire C
Dans cet exemple le compte bancaire vaut 1010 à la fin des deux transactions à la place de 1110.
30
Stéphane Crozat - UTC
La gestion des transactions
3.1.2. Accès à des données non validées
Tableau 3 Problème de la lecture impropre du tuple T par la transaction A
La transaction A accède au tuple T qui a été modifié par la transaction B. B annule sa
modification et A a donc accédé à une valeur qui n'aurait jamais dû exister (virtuelle) de T.
Pire A pourrait faire une mise à jour de T après l'annulation par B, cette mise à jour inclurait
la valeur avant annulation par B (et donc reviendrait à annuler l'annulation de B).
Exemple
Tableau 4 Annulation de crédit sur le compte bancaire C
Dans cet exemple le compte bancaire vaut 1110 à la fin des deux transactions à la place de 1010.
3.1.3. Lecture incohérente
Tableau 5 Problème de la lecture non reproductible du tuple T par la transaction A
Si au cours d'une même transaction A accède deux fois à la valeur d'un tuple alors que ce
dernier est, entre les deux, modifié par une autre transaction B, alors la lecture de A est
inconsistente. Ceci peut entraîner des incohérences par exemple si un calcul est en train d'être
fait sur des valeurs par ailleurs en train d'être mises à jour par d'autres transactions.
31
Stéphane Crozat - UTC
La gestion des transactions
Remarque
Le problème se pose bien que la transaction B ait été validée, il ne s'agit donc pas du problème
d'accès à des données non validées.
Exemple
Tableau 6 Transfert du compte C1 au compte C2 pendant une opération de calcul C1+C2
Dans cet exemple la somme calculée vaut 210 à la fin du calcul alors qu'elle devrait valoir 200.
3.2. Le verrouillage
Introduction
Une solution générale à la gestion de la concurrence est une technique très simple appelée
verrouillage.
Définition : Verrou
Poser un verrou sur un objet (typiquement un tuple) par une transaction signifie rendre cet objet
inaccessible aux autres transactions.
Synonymes : Lock
Définition : Verrou partagé S
Un verrou partagé, noté S, est posé par une transaction lors d'un accès en lecture sur cet objet.
Un verrou partagé interdit aux autres transaction de poser un verrou exclusif sur cet objet et donc
d'y accéder en écriture.
Synonymes : Verrou de lecture, Shared lock, Read lock
Définition : Verrou exclusif X
Un verrou exclusif, noté X, est posé par une transaction lors d'un accès en écriture sur cet objet.
Un verrou exclusif interdit aux autres transactions de poser tout autre verrou (partagé ou exclusif)
sur cet objet et donc d'y accéder (ni en lecture, ni en écriture).
32
Stéphane Crozat - UTC
La gestion des transactions
Synonymes : Verrou d'écriture, Exclusive lock, Write lock
Remarque : Verrous S multiples
Un même objet peut être verrouillé de façon partagée par plusieurs transactions en même temps. Il
sera impossible de poser un verrou exclusif sur cet objet tant qu'au moins une transaction
disposera d'un verrou S sur cet objet.
Méthode : Règles de verrouillage
Soit la transaction A voulant poser un verrou S sur un objet O
1. Si O n'est pas verrouillé alors A peut poser un verrou S
2. Si O dispose déjà d'un ou plusieurs verrous S alors A peut poser un verrou S
3. Si O dispose déjà d'un verrou X alors A ne peut pas poser de verrou S
Soit la transaction A voulant poser un verrou X sur un objet O
1. Si O n'est pas verrouillé alors A peut poser un verrou X
2. Si O dispose déjà d'un ou plusieurs verrous S ou d'un verrou X alors A ne peut pas poser de
verrou X
Tableau 7 Matrice des règles de verrouillage
Remarque : Promotion d'un verrou
Une transaction qui dispose déjà, elle-même, d'un verrou S sur un objet peut obtenir un verrou X
sur cet objet si aucune autre transaction ne détient de verrou S sur l'objet. Le verrou est alors promu
du statut partagé au statut exclusif.
3.3. Le déverrouillage
Définition : Déverrouillage
Lorsqu'une transaction se termine (COMMIT ou ROLLBACK) elle libère tous les verrous qu'elle a
posé.
Synonymes : Unlock
3.4. Inter-blocage
Définition : Inter-blocage
L'inter-blocage est le phénomène qui apparaît quand deux transactions (ou plus, mais généralement
deux) se bloquent mutuellement par des verrous posés sur les données. Ces verrous empêchent
chacune des transactions de se terminer et donc de libérer les verrous qui bloquent l'autre
transaction. Un processus d'attente sans fin s'enclenche alors.
Les situations d'inter-blocage sont détectées par les SGBDSGBD- p.78 > et gérées, en annulant l'une,
l'autre ou les deux transactions, par un ROLLBACK système. Les méthodes utilisées sont la
détection de cycle dans un graphe d'attente et la détection de délai d'attente trop long.
*
Synonymes : Deadlock, Blocage, Verrou mortel
Définition : Cycle dans un graphe d'attente
Principe de détection d'un inter-blocage par détection d'un cycle dans un graphe représentant quelles
transactions sont en attente de quelles transactions (par inférence sur les verrous posés et les verrous
causes d'attente). Un cycle est l'expression du fait qu'une transaction A est en attente d'une
transaction B qui est en attente d'une transaction A.
33
Stéphane Crozat - UTC
La gestion des transactions
La détection d'un tel cycle permet de choisir une victime, c'est à dire une des deux transactions qui
sera annulée pour que l'autre puisse se terminer.
Synonymes : Circuit de blocage
Définition : Délai d'attente
Principe de décision qu'une transaction doit être abandonnée (ROLLBACK) lorsque son délai
d'attente est trop long.
Ce principe permet d'éviter les situations d'inter-blocage, en annulant une des deux transactions en
cause, et en permettant donc à l'autre de se terminer.
Synonymes : Timeout
Remarque : Risque lié à l'annulation sur délai
Si le délai est trop court, il y a un risque d'annuler des transactions en situation d'attente longue,
mais non bloquées.
Si le délai est trop long, il y a un risque de chute des performances en situation d'inter-blocage (le
temps que le système réagisse).
La détection de cycle est plus adaptée dans tous les cas, mais plus complexe à mettre en œuvre.
Remarque : Relance automatique
Une transaction ayant été annulée suite à un inter-blocage (détection de cycle ou de délai d'attente)
n'a pas commis de "faute" justifiant son annulation. Cette dernière est juste due aux contraintes de
la gestion de la concurrence. Aussi elle n'aurait pas dû être annulée et devra donc être exécutée à
nouveau.
Certains SGBDSGBD- p.78 > se charge de relancer automatiquement les transactions ainsi annulées.
*
3.5. Exercice : Mini-TP : Simulation d'accès concurrents sous
PostgreSQL
1. Se connecter deux fois à une même base de données dans deux terminaux ( term1 et
term2) :
psql mydb
psql mydb
2. Créer une table test : CREATE TABLE test (a integer);
Question 1
1. term1 Insérer une valeur : INSERT ... (COMMIT implicite)
2. term2 Vérifier que la valeur est visible : SELECT ...
Question 2
1.
2.
3.
4.
5.
6.
term1
term1
term1
term2
term1
term2
Commencer une transaction : BEGIN TRANSACTION;
Insérer la valeur 2 dans la table : INSERT INTO...
Vérifier que la valeur est bien dans la table : SELECT * FROM ...
Vérifier que la valeur n'est pas visible : SELECT * FROM ...
Valider la transaction : COMMIT;
Vérifier que la valeur est visible : SELECT * FROM ...
34
Stéphane Crozat - UTC
La gestion des transactions
Question 3
1.
2.
3.
4.
5.
6.
term1 Commencer une transaction : BEGIN TRANSACTION;
term1 Exécuter une mise à jour (multiplier toutes les valeurs par 2) : UPDATE...
term2 Exécuter une mise à jour concurrente (multiplier les valeurs par 3) : UPDATE...
term2 Observer la mise en attente
term1 Valider la transaction : COMMIT;
term2 Vérifier le déblocage et que les deux mises à jour ont bien été effectuées (a multiplié par
6) : SELECT...
7. term1 Vérifier que les deux mises à jour ont bien été effectuées (a multiplié par 6) : SELECT...
3.6. Solution aux trois problèmes soulevés par la concurrence.
Introduction
Le principe du verrouillage permet d'apporter une solution aux trois problèmes classiques
soulevés par les accès aux concurrents aux données par les transactions.
3.6.1. Perte de mise à jour
Tableau 8 Problème de la perte de mise à jour du tuple T par la transaction A
Remarque
Le problème de perte de mise à jour est réglé, mais soulève ici un autre problème, celui de
l'inter-blocage.
35
Stéphane Crozat - UTC
La gestion des transactions
3.6.2. Accès à des données non validées
Tableau 9 Problème de la lecture impropre du tuple T par la transaction A
3.6.3. Lecture incohérente
Tableau 10 Problème de la lecture non reproductible du tuple T par la transaction A
Remarque
La lecture reste cohérente car aucune mise à jour ne peut intervenir pendant le processus de lecture
d'une même transaction.
3.7. Exercice
Soit l'exécution concurrente des deux transactions ci-dessous (on pose qu'aucune autre transaction
ne s'exécute par ailleurs).
NB : Le tableau fait état des temps auxquels les instructions sont soumises au serveur et non
auxquels elles sont traitées.
36
Stéphane Crozat - UTC
La gestion des transactions
Tableau 11 Transactions concurrentes
De combien le champ TABLE1.A a-t-il été augmenté à t6 du point de vue de la transaction 2 ?
NB : Si vous pensez que le résultat ne peut être déterminé à cause d'une perte de mise à jour ou
d'un inter-blocage, répondez 0.
3.8. Exercice : Films en concurrence
Soit la table Film suivante définie en relationnel permettant d'enregistrer le nombre d'entrées des
films identifiés par leur ISAN.
1 Film(#isan:char(33),entrees:integer)
Soit l'exécution concurrente de deux transactions TR1 et TR2 visant à ajouter chacune une entrée
au film '123' :
Temps
Transaction TR1
t0
Transaction TR2
BEGIN
t1
BEGIN
t2
UPDATE
Film
entrees=entrees+1
isan='123'
SET
WHERE
t3
t4
UPDATE
Film
entrees=entrees+1
isan='123'
SET
WHERE
t5
t6
COMMIT
t7
t8
COMMIT
Transaction parallèles TR1 et TR2 sous PostgreSQL
37
Stéphane Crozat - UTC
La gestion des transactions
NB :
Les instructions sont reportées au moment où elles sont transmises au serveur
Aucune autre transaction n'est en cours d'exécution entre t0 et t8.
Exercice
De combien les entrées du film 123 ont-t-elles été augmentées à t3 du point de vue de la transaction
TR1 ?
Exercice
De combien les entrées du film 123 ont-t-elles été augmentées à t3 du point de vue de la transaction
TR2 ?
Exercice
De combien les entrées du film 123 ont-t-elles été augmentées à t5 du point de vue de la transaction
TR1 ?
Exercice
De combien les entrées du film 123 ont-t-elles été augmentées à t5 du point de vue de la transaction
TR2 ?
Exercice
De combien les entrées du film 123 ont-t-elles été augmentées à t7 du point de vue de la transaction
TR1 ?
Exercice
De combien les entrées du film 123 ont-t-elles été augmentées à t7 du point de vue de la transaction
TR2 ?
3.9. Complément : Protocole d'accès aux données.
Méthode : Règles de verrouillage avant les lectures et écritures des données
Soit la transaction A voulant lire des données d'un tuple T :
1. A demande à poser un verrou S sur T
2. Si A obtient de poser le verrou alors A lit T
3. Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en empêchent soient
levés)
Soit la transaction A voulant écrire des données d'un tuple T :
1. A demande à poser un verrou X sur T
2.
38
Stéphane Crozat - UTC
La gestion des transactions
2. Si A obtient de poser le verrou alors A écrit T
3. Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en empêchent soient
levés)
Soit la transaction A se terminant (COMMIT ou ROLLBACK) :
1. A libère tous les verrous qu'elle avait posé
2. Certaines transactions en attente obtiennent éventuellement le droit de poser des verrous
Remarque : Liste d'attente
Afin de rationaliser les attentes des transactions, des stratégies du type FIFOFIFO- p.78 > sont
généralement appliquées et donc les transactions sont empilées selon leur ordre de demande.
*
4. Synthèse : Les transactions
Transaction
Unité logique de travail pour assurer la cohérence de la BD même en cas de pannes ou d'accès
concurrents.
Panne
Même en cas de panne, la BD doit rester cohérente.
Défaillances système
Coupure de courant, de réseau, etc.
Défaillances du support
Crash disque (dans ce cas les transactions peuvent être insuffisantes).
Concurrence
Dimension relevant de la conception d'application.
Perte de mise à jour
Accès à des données non valides
Lecture incohérente
Programmation
Un programme peut décider de l'annulation d'une transaction.
ROLLBACK
Instruction SQL d'annulation d'une transaction.
5. Bibliographie commentée sur les transactions
Complément : Synthèses
Les transactionsw_developpez.com/hcesbronlavau- p.80 ¨
*
Une bonne introduction courte au principe des transactions avec un exemple très bien choisi. Des
exemples d'implémentation sous divers SGBD (InterBase par exemple)
SQL2 SQL3, applications à OracleDelmal01- p.79 ¨
*
Une bonne description des principes des transactions, avec les exemples caractéristiques,
l'implémentation SQL et une étude de cas sous Oracle 8 (chapitre 5).
Tutoriel de bases de données relationnelles de l'INT Evryw_int-evry.fr- p.80 ¨
http://www-inf.int-evry.fr/COURS/BD/BD_REL/SUPPORT/poly.html#RTFToC30
*
(
Un aperçu général de l'ensemble de la problématique des transactions, de la concurrence et de la
fiabilité.
Programmation SQLMata03- p.79 ¨
*
Un exemple d'exécution de transactions (pages 20-23)
39
Stéphane Crozat - UTC
L'optimisation
L'optimisation
III
Introduction à l'optimisation du schéma interne
40
Mécanismes d'optimisation des moteurs de requêtes
49
Synthèse : L'optimisation
51
Bibliographie commentée sur l'optimisation
51
La conception des SGBDR exige qu'une attention particulière soit portée à la modélisation
conceptuelle, afin de parvenir à définir des modèles logiques relationnels cohérents et manipulables.
De tels modèles relationnels, grâce au langage standard SQL, présentent la particularité d'être
implémentables sur toute plate-forme technologique indépendamment de considérations physiques.
Néanmoins l'on sait que dans la réalité, il est toujours nécessaire de prendre en considération les
caractéristiques propres de chaque SGBDR, en particulier afin d'optimiser l'implémentation. Les
optimisations concernent en particulier la question des performances, question centrale dans les
applications de bases de données, qui, puisqu'elles manipulent des volumes de données importants,
risquent de conduire à des temps de traitement de ces données trop longs par rapport aux besoins
d'usage.
Chaque SGBDR propose généralement des mécaniques propres pour optimiser les implémentations,
et il est alors nécessaire d'acquérir les compétences particulières propres à ces systèmes pour en
maîtriser les arcanes. Il existe néanmoins des principes généraux, que l'on retrouvera dans tous les
systèmes, comme par exemple les index, les groupements ou les vues matérialisées. Nous nous
proposerons d'aborder rapidement ces solutions pour en examiner les principes dans le cadre de ce
cours.
Nous aborderons également quelques techniques de conception, qui consistent à revenir sur la
structure proposée par l'étape de modélisation logique, pour établir des modèles de données plus
aptes à répondre correctement à des questions de performance. La dénormalisation ou le
partitionnement en sont des exemples.
1. Introduction à l'optimisation du schéma interne
Objectifs
Assimiler la problématique de la performance en bases de données
Connaître les grandes classes de solutions technologiques existantes aux
problèmes de performance
Connaître et savoir mobiliser les techniques
d'optimiser les performances d'une BD
de
conception
permettant
1.1. Schéma interne et performances des applications
La passage au schéma interne (ou physique), i.e. l'implémentation du schéma logique dans un
SGBDSGBD- p.78 > particulier, dépend de considérations pratiques liées aux performances des
*
40
Stéphane Crozat - UTC
L'optimisation
applications.
Les possibilités d'optimisation des schémas internes des BDBD- p.78 > dépendent essentiellement
des fonctions offertes par chaque SGBD.
*
On peut néanmoins extraire certains principes d'optimisation des schémas internes suffisamment
généraux pour être applicables dans la plupart des cas.
Proposition de solutions
Parmi les solutions d'optimisation existantes, on pourra citer :
L'indexation
La dénormalisation
Le partitionnement vertical et horizontal
Les vues concrètes
Le regroupement (clustering) de tables
...
Méthode : Démarche d'optimisation
1. Des problèmes de performance sont identifiés,
2. des solutions d'optimisation sont proposées,
3. les solutions sont évaluées pour vérifier leur impact et leur réponse au problème posé.
1.2. Évaluation des besoins de performance
Éléments à surveiller
Pour optimiser un schéma interne, il est d'abord nécessaire de repérer les aspects du schéma
logique qui sont susceptibles de générer des problèmes de performance.
On pourra citer à titre d'exemple les paramètres à surveiller suivants :
Taille des tuples
Nombre de tuples
Fréquence d'exécution de requêtes
Complexité des requêtes exécutées (nombre de jointures, etc.)
Fréquence des mises à jour (variabilité des données)
Accès concurrents
Distribution dans la journée des accès
Qualité de service particulière recherchée
Paramétrabilité des exécutions
etc.
Évaluation des coûts
Une fois les éléments de la BDBD- p.78 > à évaluer repérés, il faut mesurer si oui ou non ils
risquent de poser un problème de performance.
*
L'évaluation des performances peut se faire :
Théoriquement
En calculant le coût d'une opération (en temps, ressources mémoires, etc.) en fonction de
paramètres (volume de données, disparité des données, etc.). En général en BD le nombre
de paramètres est très grand, et les calculs de coûts trop complexes pour répondre de
façon précise aux questions posées.
Empiriquement
En réalisant des implémentations de parties de schéma et en les soumettant à des tests
de charge, en faisant varier des paramètres. Ce modèle d'évaluation est plus réaliste que
le calcul théorique. Il faut néanmoins faire attention à ce que les simplifications
d'implémentation faites pour les tests soient sans influence sur ceux-ci.
41
Stéphane Crozat - UTC
L'optimisation
1.3. Indexation
Définition : Index
Un index est une structure de données qui permet d'accélérer les recherches dans une table en
associant à une clé d'index (la liste des attributs indexés) l'emplacement physique de l'enregistrement
sur le disque.
Les accès effectuées sur un index peuvent donc se faire sur des structures optimisées pour la
recherche (liste triée, B-tree...) au lieu de se faire par parcours séquentiel et intégral des
enregistrements.
Exemple
Consulter une vidéo montrant la construction
http://www.youtube.com/embed/coRJrcIYbF4
d'un
index
B-tree
sur :
Méthode : Cas d'usage des index de type B-Tree
Les index doivent être utilisés sur les tables qui sont fréquemment soumises à des recherches. Ils sont
d'autant plus pertinents que les requêtes sélectionnent un petit nombre d'enregistrements (moins de
25% par exemple).
Les index doivent être utilisés sur les attributs :
souvent mobilisés dans une restriction (donc une jointure)
très discriminés (c'est à dire pour lesquels peu d'enregistrements ont les mêmes valeurs)
rarement modifiés
Attention : Inconvénients des index
Les index diminuent les performances en mise à jour (puisqu'il faut mettre à jour les index en
même temps que les données).
Les index ajoutent du volume à la base de données et leur volume peut devenir non
négligeable.
Syntaxe : Créer un index en SQL
1 CREATE INDEX nom_index ON nom_table (NomColonneClé1, NomColonneClé2, ...);
Remarque : Index implicites
La plupart des SGBDSGBD- p.78 > créent un index pour chaque clé (primaire ou candidate). En effet la
vérification de la contrainte d'unicité à chaque mise à jour des données justifie à elle seule la présence
de l'index.
*
Attention : Attributs indexés utilisés dans des fonctions
Lorsque les attributs sont utilisés dans des restrictions ou des tris par l'intermédiaire de fonctions,
l'index n'est généralement pas pris en compte. L'opération ne sera alors pas optimisée. Ainsi par
exemple dans le code suivant, le restriction sur X ne sera pas optimisée même s'il existe un index sur
X.
1 SELECT *
2 FROM T
3 WHERE ABS(X) > 100
Cette non prise en compte de l'index est logique dans la mesure où, on le voit sur l'exemple
précédent, une fois l'attribut soumis à une fonction, le classement dans l'index n'a plus forcément de
sens (l'ordre des X, n'est pas l'ordre des valeurs absolues de X).
Lorsqu'un soucis d'optimisation se pose, on cherchera alors à sortir les attributs indexés des
fonctions.
Notons que certains SGBD, tels qu'Oracle à partir de la version 8i, offrent des instructions
d'indexation sur les fonctions qui permettent une gestion de l'optimisation dans ce cas particulier
SQL2 SQL3, applications à OracleDelmal01- p.79 ¨ .
*
42
Stéphane Crozat - UTC
L'optimisation
1.4. Exercice
Soit les deux tables créées par les instructions suivantes :
1 CREATE TABLE T2 (
2 E char(10) Primary Key);
3
4 CREATE TABLE T1 (
5 A number(5) Primary Key,
6 B number(2) Not Null,
7 C char(10) References T2(E),
8 D char(5));
Soit une requête dont on cherche à optimiser les performances :
1 SELECT A
2 FROM T1, T2
3 WHERE C=E AND Abs(B)>50
4 ORDER BY D;
Sachant que tous les attributs sont très discriminés (c'est à dire que les enregistrements contiennent
souvent des valeurs différentes les uns par rapport aux autres) et que les deux tables contiennent un
grand nombre d'enregistrements, quelles sont les instructions de création d'index qui vont permettre
d'optimiser l'exécution de cette requête ?
CREATE INDEX idxA ON T1(A);
CREATE INDEX idxB ON T1(B);
CREATE INDEX idxC ON T1(C);
CREATE INDEX idxD ON T1(D);
CREATE INDEX idxE ON T2(E);
1.5. Dénormalisation
Rappel
La normalisation est le processus qui permet d'optimiser un modèle logique afin de le rendre non
redondant. Ce processus conduit à la fragmentation des données dans plusieurs tables.
Définition : Dénormalisation
Processus consistant à regrouper plusieurs tables liées par des références, en une seule table, en
réalisant statiquement les opérations de jointure adéquates.
L'objectif de la dénormalisation est d'améliorer les performances de la BDBD- p.78 > en recherche sur
les tables considérées, en implémentant les jointures plutôt qu'en les calculant.
*
Remarque : Dénormalisation et redondance
La dénormalisation est par définition facteur de redondance. A ce titre elle doit être utilisée à bon
escient et des moyens doivent être mis en œuvre pour contrôler la redondance créée.
Méthode : Quand utiliser la dénormalisation ?
Un schéma doit être dénormalisé lorsque les performances de certaines recherches sont insuffisantes et
que cette insuffisance à pour cause des jointures.
Attention : Inconvénients de la dénormalisation
La dénormalisation peut également avoir un effet néfaste sur les performances :
En mise à jour
Les données redondantes devant être dupliquées plusieurs fois.
En contrôle supplémentaire
43
Stéphane Crozat - UTC
L'optimisation
Les moyens de contrôle ajoutés (triggers, niveaux applicatifs, etc.) peuvent être très coûteux.
En recherche ciblée
Certaines recherches portant avant normalisation sur une "petite" table et portant après sur
une "grande" table peuvent être moins performantes après qu'avant.
Fondamental : Redondance et bases de données
La redondance volontaire est autorisée dans une base de données à trois conditions :
1. avoir une bonne raison d'introduire de la redondance (améliorer des performances dans le cas
de la dénormalisation)
2. documenter la redondance en explicitant les DF responsables de la non 3NF
3. contrôler la redondance par des mécanismes logiciels (triggers par exemple)
1.6. Les trois principes à respecter pour introduire de la redondance dans
une base de données
Fondamental
La redondance volontaire est autorisée dans une base de données à condition de respecter trois
principes :
1. il faut avoir une bonne raison d'introduire de la redondance (améliorer des performances
dans le cas de la dénormalisation)
2. il faut documenter la redondance en explicitant les DFDF- p.78 > responsables de l'absence
de 3NF
3. il faut contrôler la redondance par des mécanismes logiciels qui vont assurer que la
redondance n'introduit pas d'incohérence (triggers par exemple)
*
1.7. Exercice
Soit les deux tables créées par les instructions suivantes :
1 CREATE TABLE T2 (
2 C char(10) Primary Key,
3 E char(10));
4
5 CREATE TABLE T1 (
6 A char(10) Primary Key,
7 B char(10),
8 C char(10) References T2(C),
9 D char(10));
Parmi les instructions suivantes qui viendraient remplacer les deux créations précédentes, lesquelles
implémenteraient une dénormalisation ?
CREATE TABLE T3 (
B char(10) Primary Key,
D char(10));
CREATE TABLE T2 (
C char(10) Primary Key,
E char(10));
CREATE TABLE T1 (
A char(10) Primary Key,
B char(10) References T3(B),
C char(10) References T2(C));
44
Stéphane Crozat - UTC
L'optimisation
CREATE TABLE T1 (
A char(10) Primary Key,
B char(10),
C char(10) Unique Not Null,
D char(10),
E char(10));
CREATE TABLE T1 (
A char(10) Primary Key,
B char(10),
C char(10),
D char(10),
E char(10));
CREATE TABLE T5 (
E char(10) Primary Key);
CREATE TABLE T4 (
D char(10) Primary Key);
CREATE TABLE T3 (
B char(10) Primary Key);
CREATE TABLE T2 (
C char(10) Primary Key,
E char(10) References T5(E));
CREATE TABLE T1 (
A char(10) Primary Key,
B char(10) References T3(B),
C char(10) References T2(C),
D char(10) References T4(D));
1.8. Partitionnement de table
Définition : Partitionnement de table
Le partitionnement d'une table consiste à découper cette table afin qu'elle soit moins volumineuse,
permettant ainsi d'optimiser certains traitements sur cette table.
On distingue :
Le partitionnement vertical, qui permet de découper une table en plusieurs tables, chacune ne
possédant qu'une partie des attributs de la table initiale.
Le partitionnement horizontal, qui permet de découper une table en plusieurs tables, chacune
ne possédant qu'une partie des enregistrements de la table initiale.
Définition : Partitionnement vertical
Le partitionnement vertical est une technique consistant à implémenter des projections d'une
table T sur des tables T1, T2, etc. en répétant la clé de T dans chaque Ti pour pouvoir recomposer
la table initiale par jointure sur la clé (Bases de données : objet et relationnelGardarin99- p.79 ¨ ).
*
Remarque
Ce découpage équivaut à considérer l'entité à diviser comme un ensemble d'entités reliées par des
45
Stéphane Crozat - UTC
L'optimisation
associations 1:1.
Méthode : Cas d'usage du partitionnement vertical
Un tel découpage permet d'isoler des attributs peu utilisés d'autres très utilisés, et ainsi améliore les
performances lorsque l'on travaille avec les attributs très utilisés (la table étant plus petite).
Cette technique diminue les performances des opérations portant sur des attributs ayant été répartis
sur des tables différentes (une opération de jointure étant à présent requise).
Le partitionnement vertical est bien entendu sans intérêt sur les tables comportant peu d'attributs.
Définition : Partitionnement horizontal
Technique consistant à diviser une table T selon des critères de restriction en plusieurs tables
T1, T2... et de telle façon que tous les tuples de T soit conservés. La table T est alors recomposable
par union sur les Ti (Bases de données : objet et relationnelGardarin99- p.79 ¨ ).
*
Méthode : Cas d'usage
Un tel découpage permet d'isoler des enregistrements peu utilisés d'autres très utilisés, et ainsi
améliore les performances lorsque l'on travaille avec les enregistrements très utilisés (la table étant
plus petite). C'est le cas typique de l'archivage. Un autre critère d'usage est le fait que les
enregistrements soient toujours utilisés selon un partitionnement donné (par exemple le mois de
l'année).
Cette technique diminue les performances des opérations portant sur des enregistrements ayant été
répartis sur des tables différentes (une opération d'union étant à présent requise).
Le partitionnement horizontal est bien entendu sans intérêt sur les tables comportant peu
d'enregistrements.
1.9. Exercice
Soit la table suivante contenant des listes de références produits :
1 CREATE TABLE Tref (
2 ref1 char(100) Primary Key,
3 ref2 char(100) Unique Not Null,
4 ref3 char(100) Unique Not Null,
5 ref4 char(100) Unique Not Null,
6 ref5 char(100) Unique Not Null,
7 ref6 char(100) Unique Not Null,
8 ref7 char(100) Unique Not Null);
On cherche à optimiser la requête suivante ("_" et "%" sont des jokers qui signifient
respectivement "1 caractère quelconque" et "0 à N caractères quelconques") :
1 SELECT ref1
2 FROM Tref
3 WHERE (ref2 like 'REF42%' or ref2 like 'REF__7%' or ref2 like 'REF_78%');
Quelles sont les opérations de partitionnement qui permettront d'optimiser cette requête de façon
maximale (indépendamment des conséquences pour d'éventuelles autres requêtes) ?
Un partitionnement horizontal
Un partitionnement vertical
1.10. Vues concrètes
Un moyen de traiter le problème des requêtes dont les temps de calcul sont très longs et les
fréquences de mise à jour faible est l'utilisation de vues concrètes.
Définition : Vue concrète
Une vue concrète est un stockage statique (dans une table) d'un résultat de requête.
46
Stéphane Crozat - UTC
L'optimisation
Un accès à une vue concrète permet donc d'éviter de recalculer la requête et est donc aussi rapide
qu'un accès à une table isolée. Il suppose par contre que les données n'ont pas été modifiées (ou que
leur modification est sans conséquence) entre le moment où la vue a été calculée et le moment où elle
est consultée.
Une vue concrète est généralement recalculée régulièrement soit en fonction d'un événement
particulier (une mise à jour par exemple), soit en fonction d'un moment de la journée ou elle n'est
pas consultée et où les ressources de calcul sont disponibles (typiquement la nuit).
Synonymes : Vue matérialisée
Complément : Voir aussi
Vue matérialisée sous Oracle - p.74
*
1.11. Exercice : Film concret
Soit le schéma relationnel suivant :
1 Film (#isan:char(33), titre:varchar(25), entrees:integer, nomReal=>Realisateur(nom),
prenomReal=>Realisateur(prenom))
2 Realisateur (#nom:varchar(25), #prenom:varchar(25), ddn:date)
Soit la requête suivante portant sur ce schéma implémenté sous PostgreSQL :
1 SELECT f.titre AS film, r.ddn AS real
2 FROM Film f, Realisateur r
3 WHERE f.nomReal=r.nom AND f.prenomReal=r.prenom
Question
Proposer une optimisation de cette requête sous la forme de la vue matérialisée vTopFilms.
1.12. Exercice : Super-lents
[10 minutes]
L'entreprise GARVEL propose des figurines de super-héros à acheter en ligne sur un site
Internet adossé à sa base de données. Son catalogue a atteint cette année le million de
modèles. Depuis quelques temps, et la récente forte augmentation des modèles au catalogue,
les performances des consultations ont beaucoup chuté, entraînant des temps d'accès lents
(plusieurs secondes) et une baisse des actes d'achat.
La requête la plus utilisée par l'application Web sert à lister tous les super-héros avec
toutes leurs caractéristiques, avec leurs véhicules et leurs repaires (et également toutes
leurs caractéristiques) et à la trier par ordre de prix.
Modèle UML Figurines GARVEL
47
Stéphane Crozat - UTC
L'optimisation
Soyez concis et précis dans vos réponses ; La bonne mobilisation des concepts du domaine
et la clarté de la rédaction seront appréciées.
Question 1
Expliquer pourquoi cette requête peut poser des problèmes de performance, lorsque la base comprend de
nombreux enregistrements.
Question 2
Proposer et justifier une première solution d'optimisation à mettre en œuvre qui sera utile dans tous les
cas et n'aura que peu d'effets indésirables. Puis, expliquer pourquoi le passage en relationnel-objet de la
base de données, combiné à la solution précédente, peut améliorer considérablement les performances.
Question 3
Proposer deux solutions alternatives qui, si l'on reste en relationnel, permettraient d'améliorer
considérablement les performances. Vous en poserez les avantages, inconvénients et les mesures à prendre
pour contenir ces inconvénients.
1.13. Complément : Groupement de tables
Définition : Groupement de table
Un groupement ou cluster est une structure physique utilisée pour stocker des tables sur lesquelles
doivent être effectuées de nombreuses requêtes comprenant des opérations de jointure.
Dans un groupement les enregistrements de plusieurs tables ayant une même valeur de champs
servant à une jointure (clé du groupement) sont stockées dans un même bloc physique de la mémoire
permanente.
Cette technique optimise donc les opérations de jointure, en permettant de remonter les tuples joints
par un seul accès disque.
Définition : Clé du groupement
Ensemble d'attributs précisant la jointure que le groupement doit optimiser.
Syntaxe : Syntaxe sous Oracle
Il faut d'abord définir un groupement, ainsi que les colonnes (avec leur domaine), qui constituent sa
clé. On peut ainsi ensuite, lors de la création d'une table préciser que certaines de ses colonnes
appartiennent au groupement.
1 CREATE CLUSTER nom_cluster (NomColonneClé1 type, NomColonneClé2 type, ...);
2
3 CREATE TABLE nom_table (...)
4 CLUSTER nom_cluster (Colonne1, Colonne2, ...);
Remarque
Le clustering diminue les performances des requêtes portant sur chaque table prise de façon isolée,
puisque les enregistrements de chaque table sont stockés de façon éclatée.
Remarque : Groupement et dénormalisation
Le groupement est une alternative à la dénormalisation, qui permet d'optimiser les jointures sans
créer de redondance.
48
Stéphane Crozat - UTC
L'optimisation
2. Mécanismes d'optimisation des moteurs de requêtes
Objectifs
Comprendre les principes de fonctionnement du moteur d'optimisation interne
aux SGBD
2.1. Exercice : Calcul du coût d'une requête
Soit deux relations t1(a:char(8),b:integer) et t2(b:integer) de respectivement 100 et
10 lignes.
Soit la requête SELECT * FROM t1 INNER JOIN t2 ON t1.b=t2.b WHERE t2.b=1.
Soit n1 le nombre de tuples tels que b=1 dans t1 ; n1 [0..100]
Soit n2 le nombre de tuples tels que b=1 dans t2 ; n2 [0..10]
Soit n3 le nombre de tuples tels que t1.b=t2.b ; : n3 [0..1000]
Question 1
Il existe plusieurs façons de traduire cette requête en algèbre relationnel, proposer quelques exemples.
Question 2
Calculer le nombre d'instructions de chaque exemple d'expression relationnelle :
en considérant que les restrictions sont effectuées par un parcours intégral dans des listes non triées
(comme si c'était effectué avec des boucles de type FOR) ;
en considérant que chaque opération est effectuée séparément.
Effectuer les calculs pour trois valeurs de n1,n2 et n3 (une valeur minimum, une valeur maximum et une
valeur intermédiaire). Donner un intervalle [min..max] indépendant de n1, n2 et n3.
Question 3
Conclure en indiquant quelle opération nécessite le moins d'instructions.
2.2. Principe de l'optimisation de requêtes
L'exécution d'une requête SQL suit les étapes suivantes :
1. Analyse syntaxique : Vérification de la correction syntaxique et traduction en opérations
algébriques
2. Contrôle : Vérification des droits d'accès
3. Optimisation : Génération de plans d'exécution et choix du meilleur
4. Exécution : Compilation et exécution du plan choisi
Définition : Plan d'exécution
L'analyse de la requête permet de produire un arbre d'opérations à exécuter.
Or il est possible de transformer cet arbre pour en obtenir d'autres équivalents, qui proposent des
moyens différents pour arriver au même résultat, on parle de différents plans d'exécution.
Définition : Optimisation de la requête
L'optimisation de la requête est une opération informatique visant à réécrire l'arbre d'exécution de la
requête en vue de choisir le plan d'exécution le plus performant.
49
Stéphane Crozat - UTC
L'optimisation
2.3. Techniques pour l'optimisation de requêtes
Restructuration algébrique
Il existe des propriétés permettant de modifier l'ordre des opérateurs algébriques, afin d'obtenir
des gains de performance par exemple :
Le groupage des restrictions : Il permet d'effectuer plusieurs restrictions en un seul
parcours de la table, au lieu d'un par restriction
Restriction (Restriction (t,x=a), x=b) <=> Restriction (t,x=a ET
x=b)
La commutativité des restrictions et Jointures : Elle permet d'appliquer les restrictions
avant les jointures
L'associativité des jointures : Elle permet de changer l'ordre des jointures, afin d'utiliser
des algorithmes plus performants dans certains cas
...
Heuristiques d'optimisation
Le moteur d'optimisation de la base de données va poser des règles de réécriture pour produire
des arbres d'exécutions et choisir les moins coûteux.
Il va typiquement appliquer d'abord les opérations réductrices (restrictions et
projections).
informations statistiques (modèle de coût)
Une des actions du moteur est d'ordonner les jointures (et les opérations ensemblistes) afin de :
traiter le moins de tuples possibles ;
mobiliser les index existants au maximum ;
utiliser les algorithmes les plus performants.
Pour cela le moteur d'optimisation a besoin de connaître le contenu de la BD : nombre de tuples
dans les tables, présence ou non d'index, ...
Le moteur de la BD met à sa disposition des informations statistiques répondant à ces besoins.
2.4. Collecte de statistiques pour le moteur d'optimisation
Le moteur d'optimisation d'une BD a besoin de collecter des informations sur les tables qu'il a à
manipuler afin de choisir les meilleurs plans d'exécution, sur la taille des tables typiquement.
Il est nécessaire de commander au moteur de collecter ces statistiques lorsque des changements
de contenu importants ont été effectués dans la BD.
Syntaxe : PostgreSQL : Analyse d'une table
1 ANALYSE <table> ;
Syntaxe : PostgreSQL : Analyse de toute la base
1 ANALYSE;
Syntaxe : PostgreSQL : Récupération des espaces inutilisés et analyse de toute la
base
1 VACUUM ANALYZE ;
Complément : Exemple de données collectées
nombre de lignes
volume des données
50
Stéphane Crozat - UTC
L'optimisation
valeurs moyennes, minimales, maximales
nombre de valeurs distinctes (indice de dispersion)
nombre d'occurrences des valeurs les plus fréquentes (notamment pour les colonnes pourvues
d'index...)
http://sqlpro.developpez.com/cours/sqlaz/fondements/#L2.1
2.5. Jointures et optimisation de requêtes
Algorithmes
Il existe plusieurs algorithmes pour réaliser une jointure :
Jointures par boucles imbriquées (nested loop) : chaque tuple de la première table est
comparé à chaque tuple de la seconde table.
Jointure par tri-fusion (sort-merge) : les deux tables sont d'abord triées sur l'attribut de
jointure, puis elles sont fusionnées.
Jointure par hachage (hash join) : les deux tables sont hachées, puis jointes par fragment.
3. Synthèse : L'optimisation
Optimisation
Modification du schéma interne d'une BD pour en améliorer les performances.
Techniques au niveau physique
Indexation
Regroupement physique
Vue concrète
Techniques de modélisation
Dénormalisation
Partitionnement
Horizontal
Vertical
4. Bibliographie commentée sur l'optimisation
Complément : Synthèses
SQL2 SQL3, applications à OracleDelmal01- p.79 ¨
*
Une bonne description des index (page 79) et clusters (page 81) par l'image. Une description
intéressante d'une fonction (sous Oracle 8i) qui permet d'indexer des fonctions, ce qui répond à un
problème important d'optimisation (page 84). Une description des vues matérialisées, leur
implémentation sous Oracle, des exemples d'usage dans le domaine du datawarehouse.
Bases de Données Relationnelles et Systèmes de Gestion de Bases de Données Relationnels, le Langage
SQLw_supelec.fr/~yb
- p.80 ¨
*
Des informations générales sur les index et sur les clusters.
51
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
Au delà des bases de
données relationnelles
IV
Introduction aux datawarhouses
52
Introduction à XML
56
Introduction aux bases de données XML
59
Brève introduction aux bases de données NoSQL
62
1. Introduction aux datawarhouses
Objectifs
Comprendre ce qu'est et à quoi sert un datawarehouse.
Comprendre les différences entre un datawarehouse et une base de données
transactionnelle.
1.1. Présentation du décisionnel
Définition
Le système d'information décisionnel est un ensemble de données organisées
de façon spécifiques, facilement accessibles et appropriées à la prise de
décision [...].
La finalité d'un système décisionnel est le pilotage d'entreprise.
Les systèmes de gestion sont dédiés aux métiers de l'entreprise [...].
Les systèmes décisionnels sont dédiés au management de l'entreprise [...].
(Goglin, 2001, pp21-22)- p.79 ¨
*
Synonymes : informatique décisionnelle, business intelligence, BIBI- p.78 >
*
52
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
1.2. Présentation du data warehousing
Définition : Définition historique de Inmon
A data warehouse is a subject-oriented, integrated, nonvolatile, and
time-variant collection of data in support of management's decisions. The
data warehouse contains granular corporate data.
(Inmon, 2002, p31)- p.79 ¨
*
Définition
Un data warehouse (DWDW- p.78 > ) est une base de données construite par copie et réorganisation de
multiples sources (dont principalement le système transactionnel de l'entreprise), afin de servir de
source de données à des applications décisionnelles :
*
il agrège de nombreuses données de l'entreprise (intégration) ;
il mémorise les données dans le temps (historisation) ;
il les organise pour faciliter les requêtes de prise de décision (optimisation).
(Goglin, 2001, p27)(Goglin, 2001)- p.79 ¨
*
Synonymes : entrepôt de données, base de données décisionnelle
Fondamental
L'objectif du data warehouse est de permettre des requêtes sur de grands ensembles des données, la
plupart du temps sous forme d'agrégats (GROUP BY) afin d'en obtenir une vision synthétique
(propre à la prise de décision).
Remarque
Le data warehouse dédié au décisionnel est séparé du système transactionnel dédié à la gestion
quotidienne.
Complément : Voir aussi
Data warehouse et data mart - p.66
*
1.3. Différence entre un DW et un système transactionnel
BD transactionnelle
Une base données classique est destinée à assumer des transactions en temps réel :
Ajout, mise à jour suppression de données
Questions sur des données identifiées ou questions statistiques
Datawarehouse
Un DWDW- p.78 > est uniquement destiné à l'exécution de questions statistiques sur des
données statiques (ou faiblement dynamiques).
*
53
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
Un changement d'approche, extrait de (Inmon, 2002, p15)
1.4. Implémentation du DW avec un SGBDR
Fondamental
Les deux problématiques fondamentales des DWDW- p.78 > sont l'optimisation et la simplification :
comment rester performant et lisible avec de très gros volumes de données et des requêtes portant
sur de nombreuses tables (impliquant beaucoup de jointures) ?
*
On utilise massivement :
Les vues concrètes : Un data warehouse procède par copie depuis le ou les systèmes
transactionnels
La dénormalisation : Un data warehouse est hautement redondant
Fondamental
Le caractère statique du data warehouse efface les inconvénients de ces techniques lorsqu'elles sont
mobilisées dans des systèmes transactionnels.
Rappel
Dénormalisation - p.67
*
Vues concrètes - p.75
*
1.5. Présentation de la modélisation en étoile
Définition : Le modèle en étoile
Le modèle en étoile est une représentation fortement dénormalisée qui assure un haut niveau de
performance des requêtes même sur de gros volumes de données.
54
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
Exemple
Exemple de modèle dimensionnel en étoile
Complément : Modèle en flocon
Le modèle en flocon est aussi un modèle dénormalisé, mais un peu moins que le modèle en étoile : il
conserve un certain niveau de décomposition pour chaque dimension prise isolément.
Complément : Voir aussi
Modélisation en flocon - p.73
*
1.6. L'ETL
Définition : ETL
L'ETL (Extraction Transformation Loading) est le processus de copie des données depuis les tables
des systèmes transactionnels vers les tables du modèle en étoile du data warehouse.
Exemple
Exemple de modèle dimensionnel en étoile
Remarque
Les tables du modèle dimensionnel peuvent être vues comme des vues concrètes sur le systèmes
transactionnel, à la nuance que des transformations (correction d'erreur, extrapolation...) peuvent
avoir été apportées dans le processus ETL.
1.7. SGBD orientés décisionnel
Il est possible d'utiliser une base relationnelle classique pour implémenter un entrepôt de
données modélisé en étoile (c'est même aujourd'hui encore la forme la plus largement mobilisée).
55
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
Il existe également des technologies dédiées (qui s'appuient généralement in fine sur une base
relationnelle).
Les principes de modélisation dimensionnels sont indépendants de la technologie choisie pour
l'implémentation.
Définition : Bases de données massivement parallèles
SGBD capable de faire exécuter une requête par plusieurs machines en parallèle, afin d'en accélérer le
traitement.
Exemple : Teradata
SGBD
OS dédié (Unix)
Machines dédiées
Complément
Entrepôts de données : guide pratique de modélisation dimensionnelle(Kimbal, Ross, 2003)- p.79 ¨ ,
Voir
p.14.
*
2. Introduction à XML
2.1. Définition du XML
Définition : XML
L'eXtensible Markup Language XMLw_w3c.org/XML- p.80 ¨ est un méta-langage permettant de définir
des langages à balises.
*
Il standardisé comme une recommandation par le W3CW3C- p.78 > depuis 1998.
*
Exemple
LaTeX et HTML sont des langages à balises (mais ce ne sont pas des langages XML)
XHTML est un langage XML
Fondamental
En tant que méta-langage XML sert à définir des formats informatiques, c'est à dire des façons de
représenter de l'information.
Les bonnes caractéristiques d'XML - non-ambiguïté, lisibilité, passivité - en font un très bon
candidat pour de très nombreux usages, il est donc utilisé dans des secteurs très variés de
l'informatique.
On distingue généralement deux grandes catégories d'utilisation : les langages orientés données
et les langages orientés documents.
Complément : Versions de XML
La version historique de XML est la version 1.0, qui reste aujourd'hui la plus largement utilisée.
Il existe également une version 1.1 de XML, qui propose des différences mineures et nécessaires
uniquement dans des contextes particuliers. Cette nouvelle version a été nécessaire pour des raisons
de compatibilité des outils existants. Les évolutions principales de XML 1.1 sont de nouveaux
caractères permis pour les noms d'éléments (pour suivre l'évolution d'Unicode depuis 1998), de
nouvelles conventions pour les caractères de fin de ligne (pour la compatibilité avec des ordinateurs
main frame) et de nouveaux caractères de contrôle dans le contenu.
Complément : Voir aussi
XML : Un langage à balise - p.75
*
XML : un méta-langage - p.76
*
56
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
Langages XML orientés données - p.72
*
Langages XML orientés documents - p.71
*
Caractéristiques recherchées pour un format XML - p.66
*
2.2. Exemple : Un document XML
Exemple : Un mail
1 <?xml version='1.0' encoding='iso-8859-1'?>
2 <mail>
3 <de>[email protected]</de>
4 <a>[email protected]</a>
5 <objet>Demande d'information</objet>
6 <date>01-03-2001</date>
7 <corps>
8 <paragraphe>Bonjour Fabrice,</paragraphe>
9 <paragraphe>Peux tu m'expliquer ce qu'est le langage XML ?</paragraphe>
10 <paragraphe>Il me faudrait en effet ton avis éclairé sur le sujet.</paragraphe>
11 <paragraphe>J'attends ta réponse, à bientôt</paragraphe>
12 </corps>
13 </mail>
2.3. Document bien formé
Définition
Un document est dit bien formé lorsqu'il respecte les règles syntaxiques du XMLXML- p.78 > .
*
Fondamental
XMLXML- p.78 > ne pose pas de sémantique à priori mais uniquement des règles syntaxiques.
*
Syntaxe
Les règles syntaxiques à respecter sont :
Il n'existe qu'un seul élément père par document, cet élément contenant tous les autres. Il est
également appelé racine.
Tout élément fils est inclus complétement dans son père (pas d'éléments croisés).
Attention
XML ne définit pas le comportement ni la manière dont doit être traité un document, mais
uniquement un format.
2.4. Balise
Définition : Balise
Les balises sont les composants fondamentaux permettant l'écriture de documents XMLXML- p.78 > .
*
Elles se distinguent du contenu en utilisant les caractères <, > et /. Elles n'ont pas de présentation
ou de signification définie par le langage mais elles auront un sens pour les applications et/ou le
lecteur.
Syntaxe
Il existe trois types de balises :
balise d'ouverture : <nom_balise>
balise de fermeture : </nom_balise>
balise vide : <nom_balise/>
57
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
Exemple : Exemple de balise XML
1 <adresse>12, rue de Paris</adresse>
2.5. Notion de document valide
Définition : Schéma
Un schéma est une description de la structure que doit respecter un document lui faisant référence,
c'est à dire qu'il établit la liste des éléments XML autorisés (avec leurs attributs), ainsi que
l'agencement possible de ces éléments.
On parle aussi de grammaire, au sens où le schéma définit l'enchaînement autorisé des balises et
vient en complément de la syntaxe XML (qui elle est indépendante d'un schéma particulier).
Définition : Document valide
Un document XMLXML- p.78 > bien formé est dit valide pour un schéma donné s'il respecte les règles
structurelles imposées par ce schéma.
*
Ce contrôle de la structure permet :
De s'assurer l'homogénéité structurelle des documents de même type.
Le traitement automatique d'un ensemble de documents de même type (mise en forme,
stockage, extraction d'informations...).
La création de formats standard et leur respect.
Exemple : Exemples de langages de schéma
Il existe plusieurs langages de définition schéma, mais les trois principaux sont :
Document Type Définition (W3C) : Un langage hérité de SGML qui fait partie du standard
XML
W3C XML Schema (W3C) : Une alternative aux DTD destiné à moderniser et compléter ce
langage historique
Relax NG (OASIS, ISO) : Une autre alternative, compromis entre W3C XML Schema et DTD
2.6. Document Type Definition
Le formalisme de définition de schéma DTD est le premier qui a été introduit dès la première
version du standard XML. Il est en fait intégré au standard W3C de XML.
Il est directement hérité de la norme SGML.
Les DTDs utilisent un langage spécifique (non XML) pour définir les règles structurelles. Un
fichier de DTD peut contenir principalement deux types de déclarations :
des déclarations d'éléments,
indiquent les éléments pouvant être inclus dans un document et l'organisation du contenu
de chaque élément (éléments fils ou texte).
des déclarations d'attributs,
définissent les attributs pouvant être associés à un élément ainsi que leur type.
Exemple : Exemple de DTD
1 <!ELEMENT document (paragraphe+)>
2 <!ATTLIST document type CDATA #REQUIRED>
3 <!ELEMENT paragraphe (#PCDATA)>
Exemple : Exemple de document XML valide
1 <?xml version='1.0' encoding='iso-8859-1'?>
2 <!DOCTYPE document SYSTEM "document.dtd">
58
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
3 <document type='memo'>
4 <paragraphe>Xxxxxxxxx</paragraphe>
5 <paragraphe>Xxxxxxxxx</paragraphe>
6 <paragraphe>Xxxxxxxxx</paragraphe>
7 </document>
8
3. Introduction aux bases de données XML
3.1. XML comme format d'échange
XML est un excellent candidat à l'échange de données entre bases de données
Il est plus explicite que CSV (balises)
Il y a une correspondance possible entre schéma XML et schéma de base de données (
mapping)
Il permet d'exporter des données relationnel-objet (arborescence)
Il est plus verbeux, mais en général ce n'est pas un problème (sauf optimisation des
transferts)
3.2. Stocker du XML en BD
SGBDR ou RO
1. Mapping XML-Relationnel (en 1NF)
Chaque élément XML est extrait et stocké dans un attribut
Fonctionne pour les schémas simples, engendre des schémas très complexes et très
fragmentés sinon, et la chute des performances
2. En BLOB
Les contenus XML sont stockés en BLOB (ou CLOB)
Des attributs dérivés de description peuvent être automatiquement extraits
Les BD n'est plus en 1NF, mais des fonctions de parsing fournies par le SGBD
XML peuvent redonner accès à l'intérieur du contenu XML
Redondance entre les attributs dérivés et le BLOB, mais les attributs peuvent être
recalculés à chaque mise à jour du contenu XML (ou implémentés comme des
méthodes en RO)
Bases XML natives
Basées sur un modèle logique de document XML et non plus un niveau logique
relationnel
Stockage physique spécifique (fichier XML, DOM persistant, ...)
Gestionnaire offrant une logique transactionnelle orientée document XML
Langage d'interrogation propre : XPath, XSL-XSLT, XQuery
Plutôt pour les documents (volumineux) que les données
Exemple : eXists
Base de données native XML Open Source
http://exist.sourceforge.net/
59
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
Exemple : Requête XQuery
The MONDIAL Database - http://www.dbis.informatik.uni-goettingen.de/Mondial/mondial.xml
1 let $country := /mondial/country[name = 'France']
2 for $province in $country/province
3 order by $province/name
4 return $province/name
60
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
http://demo.exist-db.org/exist/sandbox/
Complément
http://peccatte.karefil.com/software/RBourret/xmlBD.htm
61
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
3.3. Introduction à XPath
Définition : Expression XPath
XPath est un langage d'expressions permettant de pointer sur n'importe quel élément d'un arbre
XML depuis n'importe quel autre élément de l'arbre.
Une expression XPath peut-être absolue (sa résolution est indépendante d'un contexte ou
nœud courant : elle commence dans ce cas par /.
Une expression XPath peut-être relative (sa résolution est dépendante d'un contexte ou
nœud courant : elle ne commence dans ce cas pas par /, elle peut commencer par ./ (syntaxe
développée).
Fondamental
Une expression XPath renvoie
un node-set, ou ensemble de nœuds, c'est à dire un sous-arbre de l'arbre du document
une chaîne de caractères
un booléen
un réel
Exemple : Exemples d'expressions XPath
1 /document/entete/identification/titre
2 /document/@modele
3 corps//contenu
4 contenu/*
5 contenu/remarque[1]
6 ../paragraphe
7 @type
Complément : Types de nœuds XPath
root nodes
element nodes
text nodes
attribute nodes
namespace nodes
processing instruction nodes
comment nodes
http://www.w3.org/TR/xpath/#data-model
Complément
Pour une introduction à XPath : Brillant07Brillant07- p.79 ¨ pp.123-129
*
4. Brève introduction aux bases de données NoSQL
Définition
Le NoSQL regroupe de nombreuses bases de données, récentes pour la
plupart, qui se caractérisent par une logique de représentation de données
non relationnelle et qui n'offrent donc pas une interface de requêtes en SQL.
Attention
NoSQL signifie Not Only SQL et non pas No SQL, il s'agit de compléments aux SGBDR pour des
besoins spécifiques et non de solutions de remplacement.
62
Stéphane Crozat - UTC
Au delà des bases de données relationnelles
Exemple
BD
BD
BD
BD
orientée
orientée
orientée
orientée
clé-valeur
graphe
colonne
document (BD XML)
Complément
http://blog.xebia.fr/2010/04/21/nosql-europe-tour-dhorizon-des-bases-de-donnees-nosql/
63
Stéphane Crozat - UTC
Ouvrage de référence conseillé
Ouvrage de référence
conseillé
V
SQL2 SQL3, applications à OracleDelmal01- p.79 ¨
*
Cet ouvrage aborde tous les thèmes du cours de façon claire et illustrée, en dehors de la phase
de modélisation.
64
Stéphane Crozat - UTC
Ressources annexes
Contenus annexes
> Architecture des chaînes éditoriales XML
Architecture classique
Graphique 1 Architecture classique d'une chaîne éditoriale XML
L'approche classique pour réaliser une chaîne éditoriale XML est la suivante :
1. Formalisation du schéma documentaire, avec un langage de modélisation de
schéma XML (XML Schema, Relax NG, etc.)
2. Utilisation d'un éditeur XML standard et stylage de cet éditeur (il existe de très
nombreux éditeurs XML, plus ou moins graphiques, qui se paramètrent
automatiquement lorsqu'on leur fournit un schéma : Oxygen, XMetal, Epic
Arbortext, etc.).
3. Utilisation de serveurs de fichiers XML pour la gestion centralisée des contenus
(pour les projets les plus importants surtout).
4. Réalisation de moteurs de transformation avec les technologies XSL-XSLT,
combinées avec des langages de rendu ( XSL-FOXSL-FO- p.77 § pour le papier,
XHTML pour l'écran, etc.)
*
L'ensemble est en général intégré avec un langage applicatif tiers (Java, PHP, etc.).
> Balises et poignées de calcul
L'ingénierie documentaire met à profit deux thèses complémentaires :
le contenu est numérisé dans sa forme signifiante : il est manipulable par la
machine mais indépendamment du sa signification qui lui reste inaccessible ;
le contenu est enrichi par des balises qui sont connues syntaxiquement et
sémantiquement par la machine ; elle sait quoi en faire.
Fondamental
Le principe du balisage consiste à enrichir un contenu numérisé (dans sa forme sémiotique),
sans l'altérer, pour lui ajouter des poignées qui vont être manipulables par l'ordinateur
(logiquement).
65
Stéphane Crozat - UTC
Contenus annexes
Remarque
Le contenu est donc interprétable par l'homme et la machine, chacun via ce qui lui est destiné
:
l'humain interprète le contenu signifiant numérisé ;
la machine interprète les balises ;
Exemple : XML
XML est une illustration de ce principe, puisque l'on va coupler une information sémiotique
(texte, image, etc.) destinée à l'interprétation humaine, avec un ensemble de balises qui
permettent de décrire formellement une structure documentaire qui sera alors manipulable par
le calcul.
> Caractéristiques recherchées pour un format XML
Fondamental : Non ambiguïté
Les règles syntaxiques strictes d'XML rendent son interprétation informatique univoque.
Fondamental : Lisibilité
Un format XML a pour objectif d'être lisible par un être humain, afin de plus facilement en
appréhender le langage.
Fondamental : Passivité
Un format XML est passif, il dépend de programmes informatiques qui le transforment.
> Data warehouse et data mart
Un data warehouse et un data mart se distinguent par le spectre qu'il recouvre :
Le data warehouse recouvre l'ensemble des données et problématiques d'analyse
visées par l'entreprise.
Le data mart recouvre une partie des données et problématiques liées à un métier
ou un sujet d'analyse en particulier
Un data mart est fréquemment un sous-ensemble du data warehouse de l'entreprise,
obtenu par extraction et agrégation des données de celui-ci.
Graphique 2 Datawarehouse et datamarts
66
Stéphane Crozat - UTC
Contenus annexes
Pourquoi des data marts ?
Les data marts sont destinés à pré-agréger des données disponibles de façon plus détaillée
dans les data warehouse, afin à traiter plus facilement certaines questions spécifiques,
critiques, etc.
Exemple : Ticket de caisse
Si un data warehouse enregistre un ensemble de ventes d'articles avec un grain très fin, un
data mart peut faciliter une analyse dite de ticket de caisse (co-occurrence de ventes de
produits par exemple) en adoptant un grain plus grossier (le ticket plutôt que l'article).
Complément : Ticket de caisse
L a
l e c t u r e
d e
Entrepôts de données : guide pratique de modélisation dimensionnelle(Kimbal, Ross, 2003)- p.79 ¨ est
recommandée pour la modélisation dimensionnelle des tickets de caisse (en particulier pages
31-60 sur la grande distribution).
*
> Définition de XSL-XSLT
Définition : XSL-XSLT
XSL-XSLT est une partie du standard W3C XSL qui a trait à la transformation des
documents XML (l'autre partie étant XSL-FO).
XSL-XSLT est un langage de programmation déclaratif écrit en XML (un programme
XSL-XSLT est un document XML).
XSL-XSLT est langage de manipulation de document XML (fondé sur XPath et sur le
modèle arborescent de représentation des documents XML)
XSl-XSLT est utilisé pour transformer un document XML source dans un autre format,
typiquement HTML, mais aussi tout autre format codé sur des caractères dont la
syntaxe est connue.
XSL-XSLT est aussi utilisé pour faire des changements de schéma XML (export d'un
XML vers un autre XML structuré différemment) par exemple pour échanger des
données selon un standard.
Remarque : XSL-XSLT, XSL-FO, XSLT, XSL, FO
On parle souvent (par simplification) de XSL ou de XSLT pour désigner XSL-XSLT et de FO
pour désigner XSL-FO.
XSL utilisé seul désigne donc par convention XSL-XST (et non XSL-FO).
> Dénormalisation
Rappel
La normalisation est le processus qui permet d'optimiser un modèle logique afin de le rendre
non redondant. Ce processus conduit à la fragmentation des données dans plusieurs tables.
Définition : Dénormalisation
Processus consistant à regrouper plusieurs tables liées par des références, en une seule table, en
réalisant statiquement les opérations de jointure adéquates.
L'objectif de la dénormalisation est d'améliorer les performances de la BDBD- p.78 > en
recherche sur les tables considérées, en implémentant les jointures plutôt qu'en les calculant.
*
Remarque : Dénormalisation et redondance
La dénormalisation est par définition facteur de redondance. A ce titre elle doit être utilisée à
bon escient et des moyens doivent être mis en œuvre pour contrôler la redondance créée.
67
Stéphane Crozat - UTC
Contenus annexes
Méthode : Quand utiliser la dénormalisation ?
Un schéma doit être dénormalisé lorsque les performances de certaines recherches sont
insuffisantes et que cette insuffisance à pour cause des jointures.
Attention : Inconvénients de la dénormalisation
La dénormalisation peut également avoir un effet néfaste sur les performances :
En mise à jour
Les données redondantes devant être dupliquées plusieurs fois.
En contrôle supplémentaire
Les moyens de contrôle ajoutés (triggers, niveaux applicatifs, etc.) peuvent être très
coûteux.
En recherche ciblée
Certaines recherches portant avant normalisation sur une "petite" table et portant
après sur une "grande" table peuvent être moins performantes après qu'avant.
Fondamental : Redondance et bases de données
La redondance volontaire est autorisée dans une base de données à trois conditions :
1. avoir une bonne raison d'introduire de la redondance (améliorer des performances dans
le cas de la dénormalisation)
2. documenter la redondance en explicitant les DF responsables de la non 3NF
3. contrôler la redondance par des mécanismes logiciels (triggers par exemple)
> Documents structurés et documents formatés
Définition : Document formaté
On appelle document formaté un document dont le fichier informatique source décrit la façon
de le mettre en forme. C'est la façon la plus courante de traiter avec les documents
informatiques, telle qu'elle est mise en œuvre dans les traitements de texte ou sur le Web avec
HTML.
Un document formaté nécessite un logiciel capable d'en interpréter le format pour permettre
de le lire.
XML est un excellent candidat à la sérialisationSérialisation- p.77 § de documents formatés.
*
Exemple : Document formaté (format OpenDocument : extrait simplifié )
1 <document-content>
2 <automatic-styles>
3 <style name="P1" family="paragraph"><text-properties font-name="Times New
Roman" fo:font-size="12pt"/></style>
4 <style name="P2" family="paragraph"><text-properties font-name="Times New
Roman" fo:font-size="16pt" fo:font-weight="bold"/></style>
5 <style name="P3" family="paragraph"><paragraph-properties
fo:text-align="center"/><text-properties font-name="Times New Roman"
fo:font-size="18pt" fo:font-weight="bold" /></style>
6 <style name="P4" family="paragraph"><text-properties font-name="Times New
Roman" fo:font-size="12pt" fo:font-style="italic"/></style><style name="T1"
family="text"><text-properties font-name="Verdana"/></style>
7 </automatic-styles>
8 <body>
9 <text>
10 <p style-name="P2">As We May Think</p>
11 <p style-name="P1"><span style-name="T1">By Vannevar Bush</span></p>
12 <p style-name="P4">As Director of the Office of Scientific Research and
Development, Dr. Vannevar Bush ...</p>
13 <p style-name="P1">This has not been a scientist's war ...</p>
14 <p style-name="P3">1</p>
15 <p style-name="P1">Of what lasting benefit has been man's use of science
...</p>
68
Stéphane Crozat - UTC
Contenus annexes
16 <p style-name="P3">2</p>
17 <p style-name="P1">A record if it is to be useful to science
18 </text>
19 </body>
20 </document-content>
...</p>
Visualisation dans OpenOffice.org Writer de l'extrait de l'article "As We May Think"
Définition : Notion de documents structurés
On appelle document structuré un document dont la structure logique est décrite plutôt que la
mise en forme physique (Structured documentsAndré89- p.79 ¨ , p.7).
*
Après SGML qui avait été inventé pour cela, XML est aujourd'hui le candidat quasi-unique
pour la réalisation de documents structurés.
Exemple : Document structuré (format DocBook, légèrement simplifiée)
1 <article xmlns="http://docbook.org/ns/docbook">
2 <info>
3 <title>As we may think</title>
4 <author><personname>Vannevar Bush</personname></author>
5 </info>
6 <epigraph><para>As Director of the Office of Scientific Research and
Development, Dr. Vannevar Bush ...</para></epigraph>
7 <para>This has not been a scientist's war ...</para>
8 <sect1>
9 <para>Of what lasting benefit has been man's use of science ...</para>
10 </sect1>
11 <sect1>
12 <para>A record if it is to be useful to science ...</para>
13 </sect1>
14 </article>
Définition : Transformation des documents structurés
Un document structuré n'est pas destiné à être directement utilisé pour la lecture humaine, il
doit être d'abord transformé dans un document formaté pour être utilisé (visualisé, imprimé,
...).
69
Stéphane Crozat - UTC
Contenus annexes
Processus de transformation d'un document structuré en document formaté
Remarque : Chaîne XML complète
La technologie XML peut en fait être utilisée tout au long de la chaîne :
Langage XML orienté document structuré en amont (DocBook, DITA, TEI, langage
local, ...)
Langage XML de programmation pour la transformation (XSL-XSLT)
Langage XML orienté document formaté pour l'aval (OpenDocument, XHTML, ...)
Complément : Voir aussi
La structuration logique - p.72
*
Exemple de structuration logique - p.70
*
Architecture des chaînes éditoriales XML - p.65
*
Un langage pour publier les documents XML - p.74
*
Définition de XSL-XSLT - p.67
*
Complément : Bibliographie
Technologie de la GED(Dupoirier, 1995)- p.79 ¨ : Structure logique et structure physique (pp58-61)
*
> Exemple de structuration logique
Exemple : Un exercice structuré logiquement
Soit la structuration logique d'un exercice :
1
2
3
4
5
6
Exercice
avec
Enonce =
Question
Indice =
Solution
= {Enonce, Question, Indice, Solution}
Soit un triangle rectangle disposant d'un angle de 30 degrés.
= Donner la valeur des autres angles du triangle.
La somme des angles d'un triangle est égale à 180 degrés.
= 90 et 60 degrés.
Il est possible à partir de cette représentation de calculer différentes présentations. Pour
l'écran on peut générer une présentation HTML, en laissant la solution en hyperlien cliquable.
Pour le papier on peut générer une présentation PDF, en affichant la solution sur une page
séparée de l'énoncé. Pour un usage multimédia on pourra générer une présentation SMIL, avec
affichage de l'énoncé, lecture de la question, et affichage de la solution après un temps de
pause.
Notons que si l'on avait choisi une des représentations physiques, plutôt que la représentation
logique, il n'aurait pas été possible de générer les autres représentations.
70
Stéphane Crozat - UTC
Contenus annexes
Exemple : Un exercice mis en forme
Soit la mise en forme en HTML du même exercice :
1
2
3
4
5
6
7
8
<HTML>
<BODY>
Soit un triangle rectangle disposant d'un angle de 30 degrés. </BR>
<B> Donner la valeur des autres angles du triangle. </B> </BR>
<A HREF="ex001i01.html"> Vous avez besoin d'aide ? </A> </HR>
<A HREF="ex001s01.html"> Vérifier votre réponse ! </A>
</BODY>
</HTML>
On voit que dans ce format la structure logique n'apparaît plus explicitement et qu'il n'est
plus possible d'identifier l'énoncé, la question et la solution sans comprendre le contenu.
Fondamental
L'exemple montre que l'on peut calculer la mise en forme à partir de la structure logique,
mais non l'inverse.
> Langages XML orientés documents
Définition
Ils permettent de représenter informatiquement des documents numériques. Les formats de
documents faisant appel à des représentations fortement arborescentes, XML est un candidat
idéal pour cet usage. En fait SGML, l'ancêtre de XML, a été inventé pour l'informatique
documentaire. Aujourd'hui la très grande majorité des formats de représentation de document
sont en XML.
Définition : Langages XML orienté documents formatés
Ils définissent des formats de mise en forme de document (structure physique), en général pour
un support donné.
Exemple : Langages XML orientés documents formatés
XHTML
XSL-FO
SMIL
OpenDocument
OOXML
...
Définition : Langages XML orientés documents structurés
Ils définissent des formats de structuration de document (structure logique), en général pour
un métier donné, plus ou moins précis selon la généralité du langage.
Exemple : Langages XML orientés documents structurés
DocBook
TEI
DITA
...
Exemple : Format local orienté document structuré
1 <?xml version="1.0" encoding="UTF-8"?>
2 <document type="Lorem ipsum">
3 <paragraphe>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Pellentesque sit amet
4 libero ac mauris egestas venenatis nec vitae sapien.</paragraphe>
5 <paragraphe>Donec a lectus sed augue pellentesque accumsan eu ac justo.
Etiam est urna, sagittis
71
Stéphane Crozat - UTC
Contenus annexes
6 ac cursus nec, placerat quis velit.</paragraphe>
7 </document>
Complément : Voir aussi
Documents structurés et documents formatés - p.68
*
> Langages XML orientés données
Définition
Ils permettent d'enregistrer et de transporter des données informatiques structurées (comme
par exemple des données gérées par des bases de données) selon des formats ouvert (c'est à
dire dont on connaît la syntaxe) et facile à manipuler (les structures arborescentes XML étant
plus riches que des fichiers à plat par exemple).
Les langages XML orientées données servent surtout à l'échange ou la sérialisationSérialisation
- p.77 § des données des programmes informatiques.
*
Remarque
L'utilisation d'XML est en fait ici assez accessoire, d'autres formalismes s'y substituent sans
difficulté, souvent moins explicites pour la manipulation humaine et souvent plus performant
pour la manipulation informatique : CSV, JSON, ... (voir par exemple :
http://www.xul.fr/ajax-format-json.html pour une comparaison JSON / XML).
Remarque : Format verbeux
XML est en général plus verbeux que ses alternatives (il contient plus de caractères), c'est
pourquoi il est plus explicite pour un humain (ce qui n'est pas toujours utile), et moins
performant informatiquement (ce qui n'est pas toujours un problème).
Exemple : Formats XML orientés données standards
MathML, ChemML, ...
ATOM, RSS
Dublin Core
RDF, OWL
SVG
...
Exemple : Formats XML orientés données locaux
XML est utilisé pour de très nombreux langages orientés données locaux, en fait chaque fois
qu'un format XML est défini pour les besoins spécifique d'un programme.
1 <myVector>
2 <x>5</x>
3 <y>19</y>
4 </myVector>
Complément : Langages XML de programmation
Le formalisme XML est également utilisé pour définir des langages de programmation, à
l'instar du C ou du Java. Les langages de programmation écrits en XML sont généralement à
vocation déclarative et adressent le plus souvent des traitements eux mêmes liés à XML.
XSL-XSLT est un exemple de langage de programmation écrit en XML. On peut également
citer par exemple le langage de script ANT ( http://ant.apache.org/) ou XUL pour la
réalisation d'IHM (http://www.xul.fr/)
72
Stéphane Crozat - UTC
Contenus annexes
> La structuration logique
Un document peut être décrit comme une collection d'objets
comportant des objets de plus haut niveau composés d'objets
plus primitifs. Les relations entre ces objets représentent les
relations logiques entre les composants du document. Par
exemple [...] un livre est divisé en chapitres, chaque chapitre en
sections, sous-sections, paragraphes, etc. Une telle organisation
documentaire est appelée représentation de document structuré
. (traduit depuis la préface de Structured documents- p.79 ¨ )
*
Définition : Structuration logique
On appelle structuration logique d'un contenu une inscription explicitant la structure de ce
contenu en fonction de son organisation et des attributs intrinsèques qui le caractérisent et
non en fonction de propriétés de présentation sur un support.
Définition : Document abstrait
Un document décrit par sa structure logique est appelé document abstrait, on parle aussi de
document structuré.
Définition : Structuration physique
On appelle structuration physique ou mise en forme d'un contenu une inscription décrivant la
façon dont ce contenu doit être présenté sur un support donné.
Définition : Document formaté
Un document décrit par sa structure physique est appelé document formaté, c'est en général
également ce dont on parle quand on parle simplement de document.
Remarque
Il est possible de calculer une ou plusieurs structurations physiques pour une même
structuration logique. Il est possible de calculer d'autant plus de structurations physiques que
la structuration logique est indépendante de ses supports de présentation.
Remarque
La structuration logique est associée au fond du contenu, tandis que la structuration physique
est associée à sa forme sur un support.
Complément : Voir aussi
Langages XML orienté documents - p.71
*
> Modélisation en flocon
Définition
Un modèle en flocon est un modèle pour lequel chaque dimension est représentée avec
plusieurs tables. Il est donc plus normalisé (moins redondant) qu'un modèle en étoile.
73
Stéphane Crozat - UTC
Contenus annexes
Exemple de dimension représentée en flocon (Kimball, Ross, 2008, p.55)
Attention
Les
représentation
en
flocon
sont
(Kimball, Ross, 2008, p.56)(Kimball, Ross, 2008)- p.79 ¨ :
déconseillées
en
général
*
Le modèle en flocon est plus complexe et son appréhension par l'utilisateur difficile
Les performance en requête sont diminuées par les jointures
Le gain en espace disque est faible (les dimensions sont peu volumineuses relativement
aux faits)
Méthode
La normalisation partielle est préconisée lorsqu'il y a des répétitions très nombreuses sur un
grand nombre de colonnes (Kimball, Ross, 2008, p.153)(Kimball, Ross, 2008)- p.79 ¨ .
*
Exemple de cas pertinent de représentation en flocon d'une dimension (Kimball, Ross, 2008,
p.153)
> Un langage pour publier les documents XML
XML lorsqu'il est utilisé pour définir des formats documentaire métier est un format de
représentation de l'information, et non un format de publication (de présentation) de
cette information : donc un tel fichier XML n'est pas utilisable tel que par un
lecteur.
XML ne peut donc être utilisé pour des langages abstrait que si l'on est capable de
transformer les documents sources en document publiés lisibles grâce à un format de
présentation : HTML par exemple dans le cas de publication Web, ou PDF pour
l'impression.
74
Stéphane Crozat - UTC
Contenus annexes
> Vue matérialisée sous Oracle
Introduction
Oracle 9i propose une extension au LDD SQL pour créer explicitement des vues
matérialisées plutôt que la gestion manuelle classique consistant à créer une table et à
l'alimenter manuellement avec une requête de type INSERT.
Rappel
Une vue matérialisée est un stockage statique (dans une table) d'un résultat de requête. Il
permet donc d'anticiper des requêtes complexes en pré-calculant tout ou partie du résultat.
Vues concrètes - p.75
*
Syntaxe : Déclaration de vue matérialisée
1 CREATE MATERIALIZED VIEW nom_vue
2 [PARTITION BY ...]
3 BUILD IMMEDIATE -- quand la construire (alt. : DEFERED)
4 REFRESH FORCE -- mode de rafraîchissement (alt. : COMPLETE, FAST)
5 ON DEMAND -- quand la rafraîchir (alt. : COMMIT)
6 ENABLE QUERY REWRITE -- utilisable pour l'optimisation automatique de
requêtes (alt. : DISABLE)
7 AS
8 SELECT ...
Syntaxe : Rafraîchissement manuel de la vue
Si le rafraîchissement de la vue peut être programmé, il est néanmoins parfois nécessaire de
procéder à un rafraîchissement manuel.
1 EXECUTE dbms_mview.refresh('nom_vue');
Optimisation des requêtes
La déclaration d'une vue matérialisée dans Oracle, permettra à l'optimiseur de l'utiliser
pour effectuer la requête correspondante plutôt que d'interroger les tables sources.
Attention
Oracle ne pourra pas toujours inférer automatiquement que des vues matérialisées sont
utilisables à la place des tables originales. Il est donc nécessaire dans ce cas de réécrire
soi-même les requêtes concernées. En pratique c'est souvent le cas si les vues sont complexes.
Raffraîchissement de la vue matérialisée
La déclaration d'une vue matérialisée sous Oracle 9i permet également de planifier
automatiquement les modalités de rafraîchissement de la vue, plutôt que de devoir gérer
un rafraîchissement uniquement manuel.
Remarque
Une vue matérialisée peut être indexée ou partitionnée comme toute table Oracle.
> Vues concrètes
75
Stéphane Crozat - UTC
Contenus annexes
> XML : un langage à balise
Définition : Langage à balises
Une balise est un descripteur ajouté au contenu en vue d'un traitement informatique.
Un langage à balises est un langage permettant d'associer à un contenu (généralement du
texte) des balises explicites (par exemple pour rendre compte de la structure du texte).
Exemple : Balises Lambda
1 <lambda>
2 <body>
3 <p>This is an example</p>
4 </body>
5 </lambda>
Ici le texte est "This is an example", il est balisé afin d'ajouter les informations suivantes :
c'est est un paragraphe (balise p) du corps (balise body) d'un document Lambda (balise
lambda).
Complément : Voir aussi
Balises et poignées de calcul - p.65
*
> XML : un méta-langage
Définition : Méta-langage
Un méta-langage est un langage permettant de définir d'autres langages, les langages ainsi
définis permettent à leur tour la description d'informations respectant ces langages.
Exemple : Langage Lambda
Si l'on désire définir informatiquement un langage Lambda, en disant qu'il peut contenir un
élément de type body qui lui même contient des éléments de type p, il faut spécifier les
contraintes de ce langage grâce à un méta-langage permettant donc de définir :
Le vocabulaire : lambda, body, p
La grammaire : lambda contient exactement un body qui contient un ou plusieurs p
XML en tant que méta-langage ne contient pas les mots du langage Lambda, en revanche il
dispose des mécaniques permettant de les définir.
Définition : Notion de schéma
La définition d'un langage XML particulier se fait grâce à un schéma qui permet de lister les
mots du langage (vocabulaire) et de définir leur utilisation (grammaire).
On parle également de format.
Exemple : Schéma Lambda
1 <!ELEMENT lambda (body) >
2 <!ELEMENT body (p+) >
3 <!ELEMENT p (#PCDATA) >
Ce code exprime formellement (avec la syntaxe DTD) le langage, ou format, Lambda.
76
Stéphane Crozat - UTC
Questions de synthèse
Glossaire
API
Une API est une définition d'un ensemble de fonctions ou méthodes (en programmation objet)
dont l'appel paramétré permet de piloter une application. Une API permet donc d'utiliser un
librairie informatique sans avoir besoin d'en connaître le fonctionnement interne.
Client
Un client est un programme informatique qui a pour fonction d'envoyer des requêtes à un autre
programme informatique, appelé serveur, d'attendre le résultat de cette requête et de traiter le
résultats de la requête. Notons qu'un programme peut-être client vis à vis d'un programme et
serveur vis à vis d'un autre. On ne prend pas ici le terme client dans son acception matérielle, qui
signifie alors un ordinateur qui a pour fonction d'héberger des programmes clients.
Impedance mismatch
Le terme d'impedance mismatch renvoie au décalage qui peut exister entre le niveau d'abstraction
de deux langages qui ont à travailler sur des structures de données communes, par exemple un
langage applicatif objet et un langage de données relationnel. L' impedance mismatch a des
conséquences négatives en terme de complexification de l'implémentation et en terme de
performance, puisqu'il faut constamment passer d'une structure de données à l'autre.
Sérialisation
Processus consistant à enregistrer des données en mémoire vive (par exemple des objets) sous une
forme permettant leur persistance, typiquement sur une mémoire secondaire.
Serveur
Un serveur est un programme informatique qui a pour fonction de recevoir des requêtes d'un autre
programme, appelé client, de traiter ces requêtes et de renvoyer en retour une réponse. Notons
qu'un programme peut-être serveur vis à vis d'un programme et client vis à vis d'un autre. On ne
prend pas ici le terme serveur dans son acception matérielle, qui signifie alors un ordinateur qui a
pour fonction d'héberger des programmes serveurs.
XSL-FO
XSL-FO (FO pour Formatting Objects) est la seconde partie du standard W3C « Extensible
Stylesheet Language Family ». Il propose un langage XML de mise en forme de documents
imprimables.
Exemple d'extrait de code FO :
<fo:block font-family="Times" font-size="12pt">Ceci est un paragraphe en police Times
de taille 12pt</fo:block>.
77
Stéphane Crozat - UTC
Abréviations
Abréviations
1NF : First Normal Form
3NF : Third Normal Form
ACID : Atomicity, Consistency, Isolation, Durability
API : Application Program Interface
BD : Base de Données
BI : Business Intelligence
DF : Dépendance Fonctionnelle
DW : Data Warehouse
E-A : Entité-Association
FIFO : First In First Out
MCD : Modèle Conceptuel de Données
MLD : Modèle Logique de Données
OID : Object Identifier
POO : Programmation Orientée Objet
SGBD : Système de Gestion de Bases de Données
SGBDOO : Système de Gestion de Bases de Données Orientées Objets
SGBDR : Système de Gestion de Bases de Données Relationnelles
SGBDRO : Système de Gestion de Bases de Données Relationnelles-Objets
SQL : Structured Query Language
UML : Unified Modeling Language
VBA : Visual Basic for Application
W3C : World Wide Web Consortium
XML : eXtensible Markup Language
78
Stéphane Crozat - UTC
Bibliographie
Bibliographie
Goglin J.-F. (2001, 1998). La construction du datawarehouse : du datamart au dataweb. Hermes, 2ème
édition.
Inmon W.-H. (2002, 1990). Building the data warehouse. Wiley Publishing, 3rd edition.
Gérard Dupoirier, Technologie de la GED : Techniques et management des documents électroniques,
Hermes, 1995.
Kimball R., Ross M. (2003). Entrepôts de données : guide pratique de modélisation dimensionnelle.
Vuibert.
Kimball R., Ross M. (2008, 2002). The Data Warehouse Toolkit: The Complete Guide to Dimensional
Modeling. Wiley Publishing, second edition.
Jacques André, Richard Furuta, Vincent Quint, Structured documents, Cambridge University Press, 1989.
Alexandre Brillant, XML : Cours et exercices, Eyrolles, 2007 [ISBN 978-2212126914]
Delmal Pierre. SQL2 SQL3, applications à Oracle. De Boeck Université, 2001.
Dubois Paul, Hinz Stefan, Pedersen Carsten. MySQL : Guide officiel. ISBN 2-7440-1782-5. Paris :
CampuPress, 2004. 702 p.
Ford Andrew. Apache précis et concis. ISBN 2-84177-11. France : O'REILLY, 2000. 125 p. Précis et
concis.
Gardarin Georges. Bases de données : objet et relationnel. Eyrolles, 1999.
Lerdof Rasmus. PHP précis et concis. ISBN 2-84177-249-7. France : O'REILLY, 2002.
Mata-Toledo Ramon A., Cushman Pauline K.. Programmation SQL. Ediscience, 2003.
Thibaud Cyril. MySQL 4 : Installation, mise en oeuvre et programmation. Editions ENI, 2003. Collection
Ressources Informatiques.
Wong Clinton, HTTP précis et concis, O'REILLY, 2000 [ISBN 2-84177-1].
79
Stéphane Crozat - UTC
Webographie
Webographie
Cesbron-Lavau Henry, Les transactions, http://www.developpez.com/hcesbronlavau/Transactions.htm,
2002.
Defude Bruno, Tutoriel de bases de données relationnelles de l'INT Evry,
http://www-inf.int-evry.fr/COURS/BD/, consulté en 2009.
Roegel Denis, Oracle : SQL, http://www.loria.fr/~roegel/cours/iut/oracle-sql.pdf, 1999.
Roegel Denis, Le langage procédural PL/SQL, http://www.loria.fr/~roegel/cours/iut/oracle-plsql.pdf, 1999.
Hubiche Maxence, Comprendre les jointures dans Access,
http://mhubiche.developpez.com/Access/tutoJointures/, consulté en 2009.
Stanford University, Notes on the Oracle DBMS, http://www-db.stanford.edu/~ullman/fcdb/oracle.html,
consulté en 2004.
Bourda Yolaine, Bases de Données Relationnelles et Systèmes de Gestion de Bases de Données
Relationnels, le Langage SQL, http://wwwsi.supelec.fr/~yb/poly_bd/, consulté en 2009.
University of Alberta, Computing Science 291/391 : Laboratory Manual,
http://ugweb.cs.ualberta.ca/~c391/manual/title.html, 1995.
XML, http://www.w3.org/XML.
80
Stéphane Crozat - UTC