Bases De Données Avancées

(1)

BASES DE DONNÉES AVANCÉES

Jacqueline Konate

(2)

Avant-propos

L’Université Virtuelle Africaine (UVA) est fière de participer à accès à l’éducation dans les pays africains en produisant du matériel d’apprentissage de qualité. Nous sommes également fiers de contribuer à la connaissance globale, pour nos ressources éducatives sont principalement accessibles de l’extérieur du continent africain.

Ce module a été développé dans le cadre d’un programme de diplôme et diplôme en

informatique appliquée, en collaboration avec 18 institutions partenaires dans 16 pays africains.

Un total de 156 modules ont été développés ou traduits pour assurer la disponibilité en anglais, français et portugais. Ces modules sont également disponibles en tant que ressources éducatives ouvertes (OER) à oer.avu.org.

Au nom de l’Université Virtuelle Africaine et notre patron, nos institutions partenaires, la Banque africaine de développement, je vous invite à utiliser ce module dans votre

établissement, pour leur propre éducation, partager aussi largement que possible et participer activement aux communautés AVU de pratique d’intérêt. Nous nous engageons à être à l’avant-garde du développement et de partage ouvert de ressources pédagogiques.

L’Université Virtuelle Africaine (UVA) est une organisation intergouvernementale

panafricaine mis en place par lettre recommandée avec un mandat d’augmenter l’accès à l’enseignement supérieur et de formation de qualité grâce à l’utilisation novatrice des technologies de communication de l’information. Une charte instituant la UVA Organisation intergouvernementale, signée à ce jour par dix-neuf (19) Les gouvernements africains - Kenya, Sénégal, Mauritanie, Mali, Côte d’Ivoire, Tanzanie, Mozambique, République démocratique du Congo, Bénin, Ghana, République de Guinée, le Burkina Faso, le Niger, le Soudan du Sud, le Soudan, la Gambie, la Guinée-Bissau, l’Ethiopie et le Cap-Vert.

Les institutions suivantes ont participé au programme informatique appliquée: (1) Université d’Abomey Calavi au Bénin; (2) University of Ougagadougou au Burkina Faso; (3) Université Lumière Bujumbura Burundi; (4) Université de Douala au Cameroun; (5) Université de

Nouakchott en Mauritanie; (6) Université Gaston Berger Sénégal; (7) Université des Sciences, Techniques et Technologies de Bamako au Mali (8) Institut de la gestion et de l’administration

publique du Ghana; (9) Université des sciences et de la technologie Kwame Nkrumah au Ghana; (10) Université Kenyatta au Kenya; (11) Université Egerton au Kenya; (12) Université d’Addis-Abeba en Ethiopie (13) Université du Rwanda; (14) University of Salaam en Tanzanie Dar; (15) Université Abdou Moumouni Niamey Niger; (16) Université Cheikh Anta Diop au Sénégal; (17) Université pédagogique au Mozambique; E (18) L’Université de la Gambie en Gambie.

Bakary Diallo le Recteur

Université Virtuelle Africaine

(3)

Auteur

Jacqueline Konate

Pair Réviseur

Mohamed Vall

UVA – Coordination Académique

Dr. Marilena Cabral

Coordinateur global Sciences Informatiques Apliquées

Prof Tim Mwololo Waema

Coordinateur du module

Robert Oboko

Concepteurs pédagogiques

Elizabeth Mbasu Benta Ochola Diana Tuel

Equipe Média

Sidney McGregor Michal Abigael Koyier

Barry Savala Mercy Tabi Ojwang

Edwin Kiprono Josiah Mutsogu

Kelvin Muriithi Kefa Murimi

Victor Oluoch Otieno Gerisson Mulongo

(4)

Droits d’auteur

Ce document est publié dans les conditions de la Creative Commons Http://fr.wikipedia.org/wiki/Creative_Commons

Attribution http://creativecommons.org/licenses/by/2.5/

Le gabarit est copyright African Virtual University sous licence Creative Commons Attribution- ShareAlike 4.0 International License. CC-BY, SA

Supporté par

Projet Multinational II de l’UVA financé par la Banque africaine de développement.

(5)

Avant-propos 2

Crédits de Production 3

Droits d’auteur 4

Supporté par 4

Aperçu du cours 9

Prérequis 9

Matériaux 10

Objectifs du cours 10

Unités 10

Évaluation 12

Plan 12

Unité 0. Évaluation diagnostique 14

Objectifs de l’unité 14

Lectures obligatoires 20

Unité 1. Bases de Données Orientées Objet 21

Termes clés 22

Activités d’apprentissage 23

Activité 1.1 –Définition des Termes 23

Introduction 23 Objectifs de l’activité 23 Classe 23 Objets Complexes 24 Conclusion 26 Évaluation 26 Activité 1 2–Architecture des Bases de Données Orientées Objet, leurs Normes et Langages 27

Introduction 27

(6)

Objectifs 27

Caractéristiques de l’Objet 28

Architecture de SGBD Orientés objet 29

Conclusion 30

Evaluation 31

Résumé de l’unité 31

Évaluation de l’unité 31

Unité 2. Traitement de Requête et Optimisation 33

Termes clés 34

Activité 2 1 –Optimisation et traitement des requêtes 35

Introduction 35 Objectifs de l’unité 35 Évaluation 37 Activité 2 2 - Transformer des requêtes SQL en Algèbre Relationnelle 37

Introduction 37 Objectifs de l’unité 37 Conclusion 40 Évaluation 41 Activité 2 3 - Gestion des Transactions 41

Introduction 42 Objectifs de l’unité 42 Surmonter les limites de la sérialisation 52

Alternative 2: Protocole à deux-phases 56 Conclusion 63 Évaluation 63 Résumé de l’unité 63

Évaluation de l’unité . . . 64

(7)

Termes clés 66

Activité 3 1 - Concepts de l’Entrepôt de Données 66

Introduction 66 Objectifs de l’activité 67 Contextualisation 67 Conclusion 71 Évaluation 71 Activité 3 2 - Implémentation d’un Entrepôt de Données et outils de fouille de données 72

Introduction 72 Objectifs de l’activité 72 Conclusion 76 Évaluation 76 Résumé de l’unité 77

Unité 4. Sécurité, Recouvrement de bases de données et Autorisation 78

Termes clés 79

Activité 4 1 - Sécurité des bases de données et sauvegarde 80

Introduction 80

Objectifs de l’activité 80

Sauvegarde 80

Conclusion 84

(8)

Évaluation 84

Activité 4 2–Récupération ou Recouvrement 84

Introduction 84 Objectifs de l’activité 84 Conclusion 87 Évaluation 87 Résumé de l’unité 87

Lectures et autres ressources 88

Évaluation du cours : Evaluation Sommative 89

Références du cours 96

(9)

Aperçu du cours

Bienvenue au module Bases de Données Avancées

Au cœur de tout système important existe en arrière plan un stockage de données. Ce

stockage de données est ce qu’on appelle une base de données. Considérant qu’une base de données constitue le noyau des systèmes, il est nécessaire que les données aient une intégrité et qu’elles soient également disponibles pour utilisation. Les systèmes de base de données, lorsqu’ils sont bien conçus, vont garantir que le système va atteindre ces objectifs. Les

personnes ayant des compétences pour développer et gérer ces bases de données sont donc indispensables dans les systèmes modernes. Le cours « Principes des Systèmes de Base de Données » est nécessaire pour aider à fournir les compétences et les connaissances requises par le niveau débutant analyste ou programmeur systèmes. Ce cours est sur la compréhension et le développement de la logique de l’application dans les bases de données.

La technologie utilisée pour construire un système de gestion de base de données (SGBD) s’applique à tout système qui doit stocker des données persistantes et ayant de multiples utilisateurs. Ainsi, en résumé:

• Même si vous n’allez pas construire votre propre SGBD, certains de vos programmes peuvent avoir besoin d’exécuter des fonctions similaires;

• Les théories de base étendues sur les sujets abordés dans les systèmes d’exploitation liés à la concurrence et les transactions.

• Un SGBD est l’un des systèmes logiciels les plus sophistiqués.

• Comprendre comment cela fonctionne en interne vous aide à être un meilleur utilisateur du système.

• Comprendre en interne la de base de données est utile si vous allez effectuer les tâches d’administration de base de données.

• La technologie des bases de données est un élément clé de notre infrastructure informatique qui continuera d’exiger l’innovation dans l’avenir.

Prérequis

Avant de s’embarquer dans ce module, l’apprenant devrait avoir des connaissances suivantes : Principes des Systèmes de Base de Données, Analyse et Conception Orientées Objet,

Cryptographie et Sécurité Informatique.

(10)

Matériaux

Pour un apprentissage effectif, les matériaux suivants sont nécessaires :

• Un ordinateur avec un système de gestion de base de données;

• Un Système de Gestion de Base de Données;

• Une connexion Internet.

Objectifs du cours

À la fin de ce cours, l›étudiant devrait être en mesure de :

• Expliquer l’importance des technologies de base de données et la gestion de base de données ;

• Développer une base de données suivant le paradigme Orienté Objet ;

• Proposer les stratégies pour le traitement des volumes importants de données ;

• Expliquer les différentes stratégies de gestion de transactions dans les bases de données;

• Expliquer et implémenter l’intégration de la sécurité et le recouvrement dans les systèmes de base de données ;

• Implémenter un système simple d’entrepôt de données.

Unités

Unité 0: Évaluation diagnostique

Cette unité est consacrée à la vérification des acquis de l’apprenant pour s’assurer qu’il peut commencer le cours. Il est important de faire ce test de façon sérieuse.

Unité 1: Base de Données Orientée Objet

Un système de gestion de base de données orientée objet (SGBDOO), parfois abrégé en SGBDO pour Système de Gestion de Base de Données Objet, est un système de gestion de base de données (SGBD) qui prend en charge la modélisation et la création de données comme des objets. Cela inclut une sorte de support pour les classes d’objets et de l’héritage des propriétés et méthodes de classe par les sous-classes et leurs objets. Il n’y a actuellement aucune norme largement adoptée pour ce qui concerne les produits SGBDOO et SGBDOO considérés comme encore à leur début. En attendant, le système de gestion de base de données (SGBDR) objet-relationnel est plus couramment rencontré dans les produits disponibles. L’idée est que les concepts de base de données orientées objet peuvent être superposées sur des bases de données relationnelles. Une norme d’interface de base de données orientée objet est mise au point par un groupe de industriel, Object Data Management Group (ODMG).

(11)

L’organisation intitulée Object Management Group (OMG) a déjà normalisé une interface de données de courtage (broking interface) orienté objet entre les systèmes dans un réseau.

Unité 2: Traitement de requête

La performance des Bases de Données nécessite souvent une compréhension plus profonde de la façon dont les requêtes sont traitées et optimisées au sein du système de gestion de base de données. Dans cette unité, nous fournissons un aperçu général de la façon dont les optimiseurs de requêtes à base de règles et ceux à base de coûts fonctionnent et ensuite nous fournissons quelques exemples précis d’optimisation dans les SGBD commerciaux.

Unité 3: Entrepôt de Données et Fouille de Données

Une base de données est constituée d’un ou plusieurs fichiers qui doivent être stockés sur un ordinateur. Dans les grandes entreprises, les bases de données ne sont généralement pas stockées sur les ordinateurs individuels des employés, mais dans un système central. Ce système central se compose généralement d’un ou de plusieurs serveurs informatiques. Un serveur est un ordinateur qui fournit un service sur un réseau.

Dans un cadre typique, les fichiers de la base de données résident sur le serveur, mais ils peuvent être accessibles à partir de plusieurs ordinateurs différents dans l’organisation.

Comme le nombre et la complexité des bases de données s’accroissent, nous commençons à faire référence à l’ensemble comme un entrepôt de données.

Un entrepôt de données est une collection de bases de données qui travaillent ensemble. Un entrepôt de données permet d’intégrer des données à partir de plusieurs bases de données, qui peuvent donner de nouvelles perspectives sur les données. Le but ultime d’une base de données est non seulement de stocker des données, mais d’aider les entreprises à prendre des décisions basées sur ces données. Un entrepôt de données prend en charge cet objectif en fournissant une architecture et des outils pour organiser systématiquement et comprendre les données provenant de plusieurs bases de données.

La fouille des données vient pour rassembler ces données. La fouille de données, également connue sous le nom de découverte de données ou de connaissances, est le processus qui consiste à analyser les données à partir de différents points de vue et à les résumer en informations utiles. Il s’agit d’informations qui peuvent être utilisées pour augmenter les revenus, réduire les coûts, ou les deux. Techniquement, la fouille de données est le processus qui consiste à trouver des corrélations ou des patterns parmi des dizaines de champs dans les grandes bases de données relationnelles.

(12)

Unité 4: Sécurité des Bases de Données et Autorisation

Cette unité traitera des approches utilisées par le sous-système de sécurité et d’autorisation pour la protection de la base de données contre la contrefaçon. Cela concerne l’accès soit à certaines parties d’une base de données, soit à la totalité de la base de données.

Évaluation

Les évaluations formatives (vérification de progrès) sont incluses dans chaque unité.

Les évaluations sommatives (tests et travaux finaux) sont fournies à la fin de chaque module et traitent des connaissances et compétences du module.

Les évaluations sommatives sont gérées à la discrétion de l’établissement qui offre le cours. Le plan d’évaluation proposé est le suivant:

1 Evaluation continue Poids (%)

1.1 Test I 10

1.2 Test II 15

1.3 Devoir à la maison 10

1.4 Travaux pratiques 25

2 Examen Final 40

Total 100

Plan

Unité Activités Temps

estimé Evaluation

diagnostique

Activité 0.1 – Révision sur les systèmes de bases de données

5Heures

Base de données orientées objet

Activité 1.1 – Concepts pour les bases de données orientées objet

Activité 1.2 – Normes, langages des bases de données objet et conception

20 Heures

(13)

Traitement de requête

Activité 2.1 – Traitement de requête et optimisation Activité 2.2 – Transformation des requêtes en algèbre relationnelle

2.3 – Traitement des transactions: Introduction

30 Heures

Entrepôt de données et fouille de données

Activité 3.1 – Entrepôt de Données

Activité 3.2 – Fouille de données & outils de fouille de données

30 Heures

Sécurité bases de données et autorisation

Activité 4.1 – Sécurité des bases de données et sauvegarde

Activité 4.2 – Récupération des données

25 Heures

(14)

Unité 0. Évaluation diagnostique

Introduction à l’unité

Cette unité vous permettra de vérifier les connaissances que vous devez avoir avant de commencer le cours. Vous pouvez faire l’évaluation de l’unité avant de faire des activités d’apprentissage pour aider à rafraîchir vos connaissances.

Objectifs de l’unité

À la fin de cette unité, vous devriez être capable de:

• Evaluer le niveau et comprendre les concepts clés.

• Pre-évaluation: êtes-vous prêt pour ce module?

Apprenants:

Dans cette unité, vous trouverez des questions d’auto-évaluation qui vous aideront à tester votre état de préparation pour affronter ce module. Vous devez vous juger sincèrement et faire l’action recommandée après l’achèvement de l’auto-test. Nous vous encourageons à prendre le temps et à répondre aux questions.

Instructeurs:

Les questions de pré-évaluation données ici guident les apprenants pour décider s’ils sont prêts à prendre le contenu présenté dans ce module. Il est fortement recommandé de se conformer aux recommandations formulées sur la base de la note obtenue par l’apprenant.

Comme leur instructeur, vous devriez encourager les apprenants à s’évaluer eux-mêmes en répondant à toutes les questions posées ci-dessous. Plus précisément, les questions testent la compréhension des apprenants par rapport au contenu préalable.

Questions

1. Discuter chacun des concepts suivants dans le cadre du modèle de données relationnel:

a. relation

b. attribut

c. domaine

(15)

d. tuple

e. base de données relationnelle.

Sol.

a. Relation: une table avec des colonnes et des lignes.

b. Attribut: une colonne nommée d’une relation.

c. Domaine: l’ensemble des valeurs allouables pour un ou plusieurs attributs.

d. Tuple: un enregistrement d’une relation.

e. base de données relationnelle : une collection de tables normalisées.

2. Le SGBD agit comme une interface entre quels éléments d’un système de base de données d’entreprise?

a. L’application de base de données et la base de données

b. Les données et la base de données

c. L’utilisateur et l’application de base de données

d. L’application de base de données et SQL

Sol. A

3. Les composants d’une base de données qui suivent sont, à l’exception de ________

a. Données d’utilisateur

b. Métadonnées

c. Rapports

d. Index

Sol. C

4. La commande pour supprimer les lignes d’une table ‘CLIENT’ est:

a. REMOVE FROM CLIENT ...

(16)

b. DROP FROM CLIENT ...

c. DELETE FROM CLIENT WHERE ...

d. UPDATE FROM CLIENT ...

Sol. C

5. La clause SQL WHERE:

a. Limite les données de colonne qui sont retournées.

b. Limite les données de ligne sont retournées.

c. A la fois A et B sont correctes.

d. Ni A ni B sont correctes.

Sol. B

6. Le caractère générique dans une clause WHERE est utile quand

a. Une correspondance exacte est nécessaire dans une instruction SELECT

b. Une correspondance exacte est impossible dans une instruction SELECT.

c. Une correspondance exacte est nécessaire dans une instruction CREATE

d. Une correspondance exacte est impossible dans une instruction CREATE

Sol: B

7. Lequel des éléments suivants n’est pas considéré comment élément d’une base de données d’entreprise?

a. Utilisateurs

b. Applications de base de données

c. SGBD

d. Programme COBOL

(17)

Sol: D

8. Un attribut qui nomme ou identifie des instances d’entité est un(e)?

a. Entité.

b. Attribut.

c. Identifiant.

d. Relation.

Sol: C

9. Les entités d’un type donné sont groupées en un(e): ?

a. Base de données.

b. Classe d’entité.

c. Attribut.

d. ERD.

Sol: B

10. Lequel des éléments suivants n’EST PAS un élément de base de toutes les versions du modèle E-R?

a. Entités

b. Attributs

c. Relations

d. Clé primaires

Sol: D

11. Le schéma de la base de données est écrit en

a. HLL

b. DML

c. DDL

(18)

d. DCL

Sol: C

12. Dans un diagramme E-R les attributs sont représentés par un(e)

a. rectangle.

b. carré

c. ellipse.

d. triangle.

Sol: C

13. Les avantages d’un langage relationnel standard incluent lequel des éléments suivants?

a. Coûts de formations réduits

b. Dépendance accrue à un seul vendeur

c. Les applications ne sont pas nécessaires.

d. Tout ce qui précède.

Sol: A

14. Une clé étrangère est

a. Une clé primaire d’une autre table

b. Une clé secondaire de la même table

c. Une de substitution

Sol: A

15. Dans le modèle relationnel, les attributs peuvent être:

a. Composites.

b. Atomiques.

(19)

c. Composites et atomiques.

Sol: B

16. La jointure de deux relations est possible seulement lorsqu’elles ont:

a. Aucun attribut en commun.

b. Plus d’un attribut en commun.

c. Le même schéma.

d. Au moins, un attribut en commun.

Sol: D

17. L’union de deux relations est possible quand elles ont:

a. Le même nombre de colonnes, les mêmes types de données dans le même ordre.

b. Certains attributs en commun.

c. Les mêmes noms d’attributs.

Sol: A

18. En Algèbre Relationnelle, la projection permet de:

a. Réduire le nombre de tuples.

b. Réduire le nombre de colonnes.

c. Réduire le nombre de colonnes et de typles.

d. Réduire le nombre de colonnes et augmenter le nombre de tuples.

Sol: B

(20)

19. L’opérateur COUNT permet d’obtenir le nombre de

a. Tuples.

b. Colonnes.

c. Attributs.

Sol: A

Lectures obligatoires

• Date, C. J. (2004) : « Introduction aux bases de données », Vuibert, 2004.

• Mathieu, P. : « Des bases de données à l’Internet, Vuibert, 2000.

• Zanella, P., Ligier, Y. et Lazard, E. (2013) : « Architecture et Technologie des Ordinateurs », DUNOD, Paris, 2013.

Lectures optionnelles

• H., Gargia-Molina; J. D., Ullman; J. Widom: « Database Systems: The Complete Book », Pearson Printice Hall, 2008;

• Santini, S. and Jain, R. (1999) Similarity Measures. IEEE Transactions on Pattern Analysis and Machine Intelligence, 21(9), 871-883;

• Elmasrı R., Navathe S.B., (2007), Fundamentals of Database Systems, 5th Ed., Pearson.

(21)

Unité 1. Bases de Données Orientées Objet

Introduction à l’unité

Les fondamentaux des bases de données objets sont des concepts classiques des bases de données avec un accent spécifique sur la modélisation conceptuelle des conceptions de base de données de l’objet. Les principaux concepts sont EER (Enhanced Relation Entity), LINQ (Language Integrated Query, bases de données objet, bases de données orientées objet, bases de données objet-relationnel, UML (Unified Modeling Language).

Une base de données objet (ODB) vise à rendre les objets persistants, en plus soutenir de nombreuses caractéristiques d’un système de base de données. Ces caractéristiques attendues des bases de données comprennent: la gestion efficace des données persistantes; les

transactions, la concurrence et le contrôle de la récupération; un langage de requête, et ainsi de suite. Un ODB doit fournir ces caractéristiques de base de données dans le contexte des complexités introduites par l’orientation objet. Cela pourrait ne pas être évident.

Qu’est-ce qu’un objet? En fait, il fait référence à une notion abstraite qui représente généralement une entité importante dans l’entreprise qui doit être modélisée par une application de base de données. Un objet doit refléter un état et un comportement. L’état de l’objet montre la structure interne de l’objet qui représente les propriétés de l’objet. Nous pouvons voir un étudiant comme un objet, l’état de l’objet doit contenir des informations descriptives comme un identifiant, un nom et une adresse. Le comportement d’un objet est l’ensemble des méthodes qui sont utilisées pour créer l’objet, y accéder et le manipuler. Un objet étudiant, par exemple, peut avoir des méthodes pour créer l’objet, pour modifier l’état de l’objet, et pour supprimer l’objet. L’objet peut aussi avoir des méthodes pour relier l’objet à d’autres objets, tels que l’inscription d’un étudiant dans un cours ou l’attribution d’une note à un étudiant dans un cours. Les objets ayant le même état et le même comportement sont décrits par une classe.

Objectifs de l’unité

À la fin de cette unité, vous devriez être capable de définir et d’expliquer les concepts suivants:

• Définir une base de données objet

• Identifier et décrire les concepts particuliers à une base de données objet.

• Expliquer la différence entre une base de données objet et une base de données relationnelle

• Expliquer les avantages des bases de données objet par rapport aux bases de données relationnelles et vice versa.

(22)

Termes clés

Base de données: ensemble d’informations structurées stockées de manière permanente. Elle peut aussi être vue comme une collection de données organisées utiles à une organisation.

Base de Données orientée Objet: données organisées en des instances de classes hiérarchiques.

Base de Données Relationnelle: données organisées en tables comme des n-uplets. Chaque table (aussi appelée relation) est compose de plusieurs lignes (attributs). Chaque attribut doit être élémentaire.

Classe: type de l’objet où chaque objet est considéré comme une instance de la classe.

Constructeur de l’objet: méthode portant le même nom que la classe de l’objet et qui permet de créer des objets de la classe.

Données: informations, spécifiquement des

informations organisées et représentées dans un format convenable au traitement par un ordinateur.

Encapsulation: procédé par lequel les propriétés d’un objet sont cachées/protégées derrière une interface qui seule permet d’y accéder.

Extensibilité:fait référence à la possibilité d’étendre un système existant sans y introduire de changements.

Héritage: relation du type « EST-UN » entre deux classes d’objets.

Héritage multiple : quand un objet hérite de deux ou plusieurs classes, il y a plusieurs héritages et on parle d’héritage multiple.

Identité de l’objet : identifiant interne de l’objet qui ne peut pas être changé.

Méthode: opération décrivant le comportement d’un objet.

Objets complexes: encore appelés relations

imbriquées, ils sont des objets conçus en combinant des objets simples.

(23)

Persistance:stockage en permanence des valeurs des propriétés d’un objet.

Polymorphisme: capacité d’un objet à réagir différemment au même message.

Liaison tardive: résolution dynamique de la traduction d’un nom d’opération à son implémentation de la méthode appropriée.

Structure de l’objet : ensemble des propriétés qui décrivent l’état de l’objet.

Système de Gestion de Base de Données (SGBD): principal outil de gestion d’une base de données permettant d’insérer, de modifier et de rechercher efficacement des données spécifiques parmi un grand nombre d’informations.

Activités d’apprentissage

Activité 1.1 –Définition des Termes Introduction

Dans cette activité, des concepts fondamentaux de l’approche orientée objet sont présentés.

En effet, les bases de données orientées objet s’appuient sur les mêmes concepts. Ils font la particularité des bases de données objet par rapport aux autres types de bases de données.

Objectifs de l’activité

À la fin de cette activité, vous devriez être capable de:

• Lister et de définir les différents concepts de l’approche orientée objet.

Détails de l’activité

Classe

Une classe définit essentiellement le type de l’objet où chaque objet est considéré comme une instance de la classe. Par exemple, la personne est une classe et Jacqueline est une instance ou un objet de cette classe.

(24)

Objets Complexes

Les objets complexes ou relations imbriquées sont des objets qui sont conçus en combinant des objets simples. Ces objets sont créés par des constructeurs.

Un avion et une voiture sont des exemples d’objets complexes, car ils peuvent être considérés comme un objet de niveau supérieur qui est construit à partir d’objets de niveau inférieur, tels que le moteur et la coque (pour les deux), les ailes et la queue de l’avion, etc. Chacun de ces objets sont leur tour des objets complexes qui sont construits à partir d’autres objets simples ou complexes.

Identité de l’Objet

Une identité d’objet est un identifiant interne de l’objet qui ne peut pas être changé. Une identité d’objet (OID) reste constante pendant la durée de vie de l’objet. Le OID est utilisé par la base de données pour identifier, de manière unique, l’objet dont les attributs peuvent changer contrairement à la base de données relationnelle qui ne permet pas le changement des attributs pour un tuple dans la table. L’identité d’un objet ne dépend pas de la valeur des propriétés, les OID sont des références uniques et elles sont utiles pour construire des objets complexes (Dietrich et Urban, 2011).

Structure de l’Objet

Un objet de classe contient des informations sur l’état décrit, mais aussi les attributs et le comportement autorisé par les méthodes. Un attribut et une méthode qui sont pour les

instances de la classe sont appelés attribut d’instance et méthode d’instance. Par exemple, soit une classe Etudiant avec les attributs suivants: numEt, prenom, nom. Chaque étudiant aura son numEt, prenom, nom. Ainsi, deux objets différents (étudiants) de la classe Etudiant auront des valeurs différentes des attributs d’instance.

Un attribut et une méthode qui sont communs à toutes les instances de la classe sont appelés attribut de classe et méthode de classe. Par exemple, considérons la classe Etudiant définie ci-dessus avec cette fois-ci un attribut supplémentaire “ville”. La valeur par défaut de la ville peut être «Bamako» de sorte que tous les étudiants auront Bamako comme ville de résidence.

Ainsi, deux objets différents (étudiants) de la classe Etudiant auront la même valeur des attributs de classe.

Constructeurs de Type

Aussi appelé le générateur de type, un constructeur de type est un type particulier de méthode dans une classe. Il est appelé à créer un objet de cette classe et initialiser ses attributs. Le constructeur a le même nom que la classe. Contrairement aux méthodes ordinaires, le constructeur n’a pas explicitement le type de retour.

Encapsulation des Opérations

L’encapsulation consiste à recueillir des données et des méthodes au sein d’une structure avec une interface afin de cacher l’implémentation de l’objet. Le but est d’empêcher l’accès aux données par des moyens autres que les services autorisés définis par l’interface.

L’encapsulation garantit donc l’intégrité des données de l’objet. Ainsi, l’implémentation d’une classe peut changer sans affecter l’interface que la classe fournit au reste de l’application.

(25)

L’encapsulation est utile pour séparer le niveau de l’implémentation de celui de la spécification de la classe, ce qui est très important comme approche d’ingénierie logicielle. Les types définis par l’utilisateur permettent queles bases de données objet supportent l’encapsulation (Dietrich et Urban, 2011).

Extensibilité

La propriété d’encapsulation dans un ODB le rend également extensible. “L’extensibilité fait référence à la possibilité d’étendre un système existant sans y introduire de changements”

(Won 1990). Elle permet facilement l’évolution des systèmes, en particulier, ceux qui sont grands et complexes.

L’extensibilité peut être introduite par l’extension du comportement et de l’héritage.

Lorsque l’extension porte sur le comportement de objet, nous ajoutons de nouveaux

programmes pour augmenter ses fonctionnalités de sorte à ne pas dégrader les fonctionnalités anciennes. Par exemple, un nouveau programme nommé “Emprunter” peut être ajouté à l’objet Article dont héritent les livres, les journaux, les CD / DVD. A travers l’extensibilité par réutilisation ou par héritage, le comportement et les attributs définis pour un objet Article peut être réutilisé par les objets spécialisés. Par exemple, un nouvel objet nommé livre peut être défini comme un objet Article spécialisé. L’objet livre hérite (réutilise) le comportement (Emprunter) et les attributs (isbn, nom-auteur) définis pour l’objet Article. En outre, nous pouvons soit ajouter un nouveau comportement / attributs à l’objet Livre ou redéfinir le comportement / attributs existants hérités.

Persistance

Le stockage en permanence des valeurs des propriétés d’un objet est appelé persistance de l’objet. En d’autres termes, la persistance renvoie à la capacité des objets à rester après l’arrêt du processus qui les a créés (Dogac et al., 1994). Les propriétés des objets persistants sont créées et stockés dans la mémoire principale. Les systèmes de bases de données orientées objet sont basés sur le concept d’objets persistants.

Méthodes

Dans l’approche orientée objet, le comportement d’un objet est décrit par un ensemble d’opérations qui sont appelées méthodes. Une méthode a une signature qui décrit le nom, les noms et les types des paramètres de la méthode. Une méthode est une implémentation particulière d’une signature de la méthode. Elles sont définies dans la classe d’objets et permettent de relier différents autres objets et les manipuler.

Hiérarchies de Type & Héritage

Dans l’approche orientée objet, il est possible de définir des hiérarchies de classes et

d’exprimer l’héritage de l’état et du comportement. Les objets hérités sont liés par les relations

«Est-un». Par exemple, le Cercle est une Forme Géométrique, le Triangle est une Forme Géométrique et nous disons que les classes Cercle et Triangle héritent de la classe Forme Géométrique. Une autre classe appelée Triangle équilatéral est un Triangle. Mais nous avons deux niveaux de hiérarchie entre Forme Géométrique et Triangle équilatéral.

Les BDO ont l’avantage de supporter complètement les hiérarchies de classes et l’héritage.

(26)

Polymorphisme

Aussi appelé surcharge, le polymorphisme se réfère à la capacité d’un objet à réagir différemment au même message. Les BDO supportent le polymorphisme. Par exemple, il pourrait y avoir une méthode pour le calcul de la surface comme calculerSurface() pour tous les objets de Forme Géométrique. Cependant, les objets Cercle et Triangle peuvent adapter cette méthode à leur domaine de calcul particulier. Donc, nous aurons la méthode calculerSurface() pour l’objet Cercle et calculerSurface() pour l’objet Triangle. On appelle cela le polymorphisme ou la surcharge.

Héritage Multiple

Quand un objet hérite d’une seule classe, nous avons l’héritage simple. Mais, quand un objet hérite de deux ou plusieurs classes, il y a plusieurs héritages et on parle d’héritage multiple.

Par exemple, une Voiture hybride est à la fois une Voiture à essence et une Voiture électrique.

Donc, il y a double héritage, car Voiture hybride hérite de Voiture à essence et de Voiture électrique.

Liaison tardive

Le polymorphisme est utilisé avec une liaison tardive, ce qui signifie que la traduction d’un nom d’opération à son implémentation de la méthode appropriée doit être résolue dynamiquement, c’est-à-dire au moment de l’exécution (Dietrich et Urban, 2011).

Conclusion

Cette activité décrit les concepts orientés objet nécessaires pour comprendre l’approche des bases de données orientée objet. Ces concepts spécifiques sont la force de l’approche des BDO par rapport aux BD relationnelles: modélisation d’objet complexe, navigation facile, encapsulation, homomorphisme, liaison tardive, etc. En conclusion, malgré les mérites préconisés pour les systèmes de BDO, ils ont du mal à gagner en raison de la résistance des partisans du modèle relationnel qui contrôlent le marché.

Évaluation

1. Définissez les termes suivants :

• Classe

• Objet

• Méthode

• Persistance,

• Extensibilité

• Encapsulation

• Constructeur de type

(27)

• Identité de l’objet

• Hiérarchie de type

• Héritage et héritage multiple

• Liaison tardive

• Polymorphisme

2. Créer une carte de concepts et reliez chacun des concepts ci-dessus avec des relations du type « est-un », « fait-partie-de », « possède », ... Cela permet de savoir si vous pouvez faire la distinction entre certaines notions et si vous connaissez les relations entre elles.

Activité 1.2–Architecture des Bases de Données Orientées Objet, leurs Normes et Langages

Introduction

Cette activité est consacrée à l’architecture aux bases de données orientées objets et base de données objet/relationnelle. Les normes et les langages qui leur sont associés sont également abordés.

Objectifs

A la fin de cette activité, l’apprenant doit avoir des connaissances sur :

• L’Evolution et les tendances actuelles de la technologie de base de données;

• Les caractéristiques de l’objet-relationnel;

• Mise en œuvre et questions connexes pour les systèmes de type étendu Détails de l’activité

Les systèmes de base de données objet combinent les caractéristiques classiques des systèmes de gestion de base de données relationnels (SGBDR), avec de nouvelles caractéristiques supportées par l’objet-orientation. Les caractéristiques traditionnelles comprennent: la gestion du stockage secondaire, la gestion du schéma, le contrôle de la concurrence, la gestion des transactions, la récupération, le traitement de requêtes, l’autorisation d’accès et de contrôle, Sécurité, Sûreté.

Les nouvelles caractéristiques des bases de données objet comprennent:

• Les objets complexes

• Les identités des objets

• Les types définis par l’utilisateur

(28)

• Encapsulation

• Hiérarchie de type / classe avec l’héritage

• Surcharge, remplaçant, liaison tardive, le polymorphisme

La base de données orientées objet est un paradigme différent de l’approche traditionnelle de la base de données relationnelle. L’approche de ces paradigme a provoqué un vif débat entre les partisans des systèmes relationnels(SGBDR), ayant déjà une position forte sur le marché, et les promoteurs des systèmes de gestion de bases de données orientées objet pur (SGBDOO).

Néanmoins, en dépit d’un grand nombre de compromis et de la confusion commerciale, le modèle relationnel a été un succès en tant que base conceptuelle et technique de nombreux systèmes relationnels commerciaux. Le principal domaine de préoccupation constitue les systèmes basés sur SQL.

Cependant, le modèle relationnel et le modèle objet sont essentiellement différentes, et l’assimilation des deux est pas facile. Les bases de données objet-relationnel sont généralement perçues comme mixte, avec beaucoup des solutions ad-hoc, aléatoires, sans base conceptuelle.

Une zone de discussion qui a surgi entre les partisans de SGBD orientés objet pur et SGBD objet-relationnel est le dialogue. Malgré le fait que les différences existent entre eux, il réunit les fournisseurs de SGBDR et SGBDOO contre les partisans du modèle objet pur et ceux du modèle SGBDOO pur. Ceci est le signe montrant où les vendeurs voient le danger réel pour la position commerciale des SGBD relationnels et leurs successeurs. Se reporter à l’unité précédente pour les définitions.

Caractéristiques de l’Objet

Parmi les vues utilisées par le camp relationnel était qu’il n’y avait pas de définition raisonnable du concept de base de données objet. Le manifeste du concept de base de données objet a déterminé les règles de base des systèmes de bases de données objets, qui rejettent le modèle relationnel. Ainsi les caractéristiques d’un SGBDO ont été séparés en trois groupes:

obligatoires, facultatives et ouvertes. Les caractéristiques de base de données objets étaient inacceptables pour la vision conservatrice de l’école de pensée relationnelle.

(29)

Architecture de SGBD Orientés objet

Un des SGBDOO les plus abstraits est l’architecture ANSI/SPARC. Il se compose de couches suivantes: la couche externe de l’utilisateur, la couche d’un schéma conceptuel, et la couche de données physiques. Un autre est l’architecture client/serveur, où les applications de base de données sont subdivisées en deux parties: le serveur de base de données (par exemple l’exécution d’instructions SQL envoyées par les clients) et un ou plusieurs clients envoyant des requêtes vers le serveur. Il y a aussi des architectures plus avancées qui comprennent trois niveaux et l’architecture multi-niveaux. Essentiellement, les niveaux ou couches d’une interface utilisateur et une base de données sont l’architecture séparée par un (ou plusieurs) des

couches consacrées à la logique métier.

Figure 1. L’architecture de SGBDOO (voir Subieta, K Kazimierz travail sur les systèmes de base de données d’objets disponibles

sur http://www.ipipan.waw.pl/~subieta/artykuly/objbases/

ObjBases.html)

Norme ODMG

Se référer au matériel disponible sur https://globis.ethz.ch/files/2015/02/ODMG.pdfp pour la discussion sur Groupe de Gestion de Données Objet (Object Data Management Group : ODMG).

Subieta, K Kazimierz a argumenté que la norme ODMG (version ODMG 2.0 ) consistait en trois parties suivantes: Modèle Objet, Langage de Définition Objet (Definition Language : ODL), Format d’échange objet (Object Interchange Format), Langage de Requête Objet (Object Query Language : OQL), Liaisons aux langages de programmation comme C++, Smaltalk et Java. La norme de données objet de Cattell et Barry (ODMG 3.0) construit et explique ces composants en profondeur (voir le travail complet sur https://globis.ethz.ch/files/2015/02/

ODMG.pdf, dernier accès 24 Février 2016).

SGBD Orienté Objet versus Base de Données traditionnelle

(30)

Il est évident que les produits SGBDOO fournissent des fonctionnalités des bases de données traditionnelles qui comprennent la persistance, la distribution, l’intégrité, la simultanéité et la récupération. S’ils utilisent l’approche objet, cela signifie qu’ils fournissent généralement, des identificateurs d’objets immuables et permanents pour garantir l’intégrité. En outre, les SGBDOO purs fournissent également des fonctionnalités des bases de données distribuées transparentes et d’autres fonctionnalités avancées de SGBD comme le support pour le Web, le support aux groupes de travail, les outils d’administration. Ainsi, les SGBDOO vont au-delà des capacités des bases de données relationnelles et ils sont donc bien adaptés à gérer des données très complexes et interdépendants, en particulier dans un environnement multiplateforme et distribué. Surtout, les SGBDOO purs sont en mesure de faire beaucoup mieux que les SGBDR en raison des nouvelles techniques, telles que de nouvelles méthodes de mise en cache, la manipulation de pointeur, la navigation via des liens de pointeurs au lieu d’effectuer des jointures, le déplacement du traitement du côté du client, et d’autres.

Inconvénients des SGBD Orientés Objet

Il y a plusieurs doutes perçus concernant les SGBDOO. Ils comprennent: la Maturité de la technologie; la Stabilité des vendeurs; la Disponibilité de personnel qualifié et le Coût de la conversion si difficile tirant parti des investissements déjà réalisés dans SGBDR.

Sur les SGBD Objet-Relationnel, s’il vous plaît référez-vous respectivement aux documents du Standard de Données Objet (2.0 et 3.0) (Cattell, Barry & Subieta) aux liens https://globis.ethz.

ch/files/2015/02/ODMG.pdf et

http://www.ipipan.waw.pl/~subieta/artykuly/objbases/ObjBases.html.

Conclusion

Cette activité a examiné le paradigme orienté objet dans les systèmes de base de données.

Il a abordé les questions de l’orientation objet par rapport aux approches traditionnelles de bases de données relationnelles. En outre, l’intégration de base de données orientée objet avec des liens nécessaires aux normes a été fournie. Il peut donc être conclu que, malgré la rivalité objet-relationnel, l’approche orientée objet a son propre succès et donc ne devrait pas être ignorée. Cependant, le convergent de l’orienté objet par rapport à la base de données relationnelle a encore de la pertinence.

(31)

Evaluation

1. Quand est-ce qu’on a besoin d’une base de données objet ? 2. Citez deux différences fondamentales entre les bases de données

orientées objet et les bases de données relationnelles

3. Qu’est-ce qui différencie une base de données orientée objet d’une base de données objet relationnelle ?

4. Citez trois avantages des bases de données orientées objet par rapport aux bases de données relationnelles.

Résumé de l’unité

Dans cette unité, nous avons vu les principaux concepts de l’approche orientée objet. Puis, les bases de données objet ont été introduites, leur architecture et leurs avantages ont également été présentés. Les normes et langages derrière les bases de données objet y ont été aussi abordés.

Évaluation de l’unité

Vérifiez votre compréhension!

Considérons la description du problème ci-dessous.

Un véhicule peut être un train, un camion, une voiture, un car, un bateau, ... Nous allons considérer uniquement les véhicules à moteur car il en existe bien d’autres types. Puisque les véhicules sont des objets complexes, c’est à dire qu’ils sont composés d’autres objets, certaines de leurs propriétés peuvent faire référence à d’autres objets. Ils sont également fabriqués par des compagnies qui emploient plusieurs personnes et fabriquent différentes marques.

1. Construisez le diagramme de classes correspondant à cette situation.

2. Décrivez clairement les relations entre les différents concepts.

Directives

Commencez par identifier les classes, puis les relations entre eux. Se référer au module intitulé

« Principe des bases de données » pour voir la construction d’un diagramme de classes.

(32)

Lectures obligatoires

• Date, C. J. (2004) : « Introduction aux bases de données », Vuibert, 2004.

• Mathieu, P. : « Des bases de données à l’Internet, Vuibert, 2000.

• Roy G. (2007) : « Conception de bases de données avec UML », Presses de l’Université du Québec, 2007.

• Zanella, P., Ligier, Y. et Lazard, E. (2013) : « Architecture et Technologie des Ordinateurs », DUNOD, Paris, 2013.

Autres ressources

• H., Gargia-Molina; J. D., Ullman; J. Widom: « Database Systems: The Complete Book », Pearson Printice Hall, 2008;

• William Stallings, Operating Systems, 4th edition, 2002

• E. Oomoto, K. Tanaka (1993) OVID: Design and Implementation of a Video- Object Database System, IEEE Transaction on Knowledge and Data Engineering 5(4), pp. 629-643.

• Dogac, A., Özsu, M. T., Biliris, T. : « Advances in Object-Oriented Database Systems », Springer-Verlag Heidelberg Gmbh, 1994.

• William Stallings, Operating Systems, 4th edition, 2002

• E. Oomoto, K. Tanaka (1993) OVID: Design and Implementation of a Video- Object Database System, IEEE Transaction on Knowledge and Data Engineering 5(4), pp. 629-643.

• Dogac, A., Özsu, M. T., Biliris, T. : « Advances in Object-Oriented Database Systems », Springer-Verlag Heidelberg Gmbh, 1994.

(33)

Unité 2. Traitement de Requête et Optimisation

Introduction à l’unité

Les requêtes d’une base de données sont soumises à différents processus dont les principaux sont : l’optimisation de requête, la transformation des requêtes SQL en Algèbre Relationnelle, la gestion des transactions. Cette unité est consacrée à la présentation de ces différents processus.

Objectifs de l’unité

À la fin de cette unité, vous devriez être capable de:

• Enumérer et décrire les différentes étapes du traitement de la requête.

• Traduire des requêtes SQL en algèbre relationnelle.

• Utiliser les Heuristiques dans l’optimisation des requêtes.

• Définir les Transactions et ses propriétés.

• Expliquer l’Ordonnancement et la recouvrabilité.

• Expliquer la sérialisabilité des ordonnancements.

• Sérialiser deux transactions.

• Décrire la concurrence et le contrôle de la concurrence.

• Elaborer un graphe de dépendances entre transactions.

• Décrire les politiques qui assurent l’intégrité et la cohérence des données dans une base.

(34)

Termes clés

Algèbre Relationnelle: Outil mathématique qui permet de définir les opérations sur les bases de données.

Anomalie: incohérence dans une base de données.

Arbre de requête: décomposition d’une requête en ses différentes étapes (sous-requêtes) sous forme d’arbre. Les opérateurs sont des nœuds et les feuilles sont des relations (tables).

Atomicité : toutes les modifications de base de

données se font comme une unité; soit tous sont faites ou aucune n’est faite.

Cohérence : une fois que la transaction est exécutée, elle doit soit mettre la base de données dans un état cohérent ou avorter.

Contrôle de concurrence : processus général pour assurer que les opérations de préservation de la cohérence lors de l’exécution simultanée.

Durabilité : les effets de la transaction vont persister après sa validation.

Graphe de dépendance : graphe permettant de déterminer si l’exécution d’une transaction nécessite l’exécution de tout ou partie d’une autre.

Isolation : comportement d’une transaction ne doit pas être affectée par d’autres transactions concurrentes.

Opérations de base de données: requêtes.

Optimisation de requêtes: processus de

transformation des requêtes relativement complexes en des requêtes plus simples.

Ordonnancement : séquence des actions importantes prises par une ou plusieurs opérations

Ordonnancement sérialisable : ordonnancement de transactions qui peuvent s’exécuter en série.

Requête: opération pour avoir une information à partir de la base de données, pour mettre à jour, modifier, supprimer des données or insérer de nouvelles données.

(35)

Sérialisation : procédé par lequel deux transactions/

opérations sont exécutées l’une à la suite de l’autre sans chevauchement.

Transaction : ensemble d’actions qui se produisent sur une base de données cohérente et qui la laissent cohérente.

Verrouillage: réservation d’une ressource par un opérateur tout en empêchant d’autre d’y accéder pour certains usages, selon le type de verrouillage.

Activités d’apprentissage

Activité 2.1 –Optimisation et traitement des requêtes Introduction

Cette unité porte sur le processus d’optimisation et de traitement des requêtes. Les différentes étapes du processus y sont présentées.

Objectifs de l’unité

• Décrire le processus d’optimisation et de traitement des requêtes

• Définir les différents composants du SGBD qui interviennent dans l’optimisation et le traitement de requêtes.

Une requête est une spécification de haut niveau d’un ensemble d’objets d’intérêt venant de la base de données. Elle est généralement spécifiée dans un langage spécial appelé Langage de Manipulation de Données (Data Manipulation Language : DML) qui décrit ce que le résultat doit contenir.

L’Optimisation des requêtes vise à choisir une stratégie efficace pour l’exécution de la requête.

Le traitement de requête dans les bases de données orientées objet est presque le même que dans les bases de données relationnelles avec seulement quelques modifications en raison des différences sémantiques entre les requêtes relationnelles et orientées objet. De plus, toutes les

(36)

techniques applicables aux unes le sont également aux autres. En effet, sans la hiérarchie des classes, les requêtes ont des structures similaires dans les deux bases de données.

Par conséquent, dans le but de simplifier, nous allons voir le traitement des requêtes sans distinction entre les bases de données objet et les bases de données relationnelles.

La requête est traitée en deux phases: la phase d’optimisation de requêtes et la phase de traitement de la requête. Afin de faciliter la compréhension, nous allons ajouter la phase compilation de requête avant les deux phases précédentes, car les requêtes sont vues par l’utilisateur comme des scripts de DML (Data Manipulation Language). Ainsi, la figure 2 présente l’ensemble du processus.

Figure 2. Les étapes du Traitement de requête.

a. Compilation de requêtes: le processeur DML traduit les instructions DML en instructions de bas niveau (requête compilée) que l’optimiseur de requête peut comprendre.

b. Optimisation de requêtes : l’optimiseur génère automatiquement un ensemble de stratégies raisonnables pour traiter une requête donnée, et sélectionne une optimale sur la base du coût attendu de chacune des stratégies générées.

c. Traitement de requêtes : le système exécute la requête en utilisant la stratégie optimale générée.

Dans l’optimisation de requête, une requête SQL est d’abord traduite en une expression d’algèbre relationnelle équivalente en utilisant une structure de données d’arbre de requête avant d’être optimisée. Nous allons donc indiquer ci-après comment passer d’une requête SQL à une expression en algèbre relationnelle.

(37)

Évaluation

1. Qu’est-ce qu’une requête de base de données ? 2. Qu’appelle-t-on optimisation de requête ? 3. A quoi consiste le traitement d’une requête ?

4. Quels sont les composants d’un SGBD qui interviennent dans le processus de d’optimisation et de traitement de requête ?

Activité 2.2 - Transformer des requêtes SQL en Algèbre Relationnelle

Introduction

La transformation des requêtes SQL en Algèbre Relationnelle est une étape importante dans le processus d’optimisation et de traitement des requêtes présenté dans l’activité précédente.

Cette activité va spécifiquement traiter cet aspect, souvent invisible.

Objectifs de l’unité

• Dresser un tableau de correspondance entre les opérations en SQL et les opérations en Algèbre Relationnelle ;

• Transformer toute requête SQL en Algèbre Relationnelle ;

• Appliquer des heuristiques d’optimisation de requêtes

Pour traduire la requête SQL en algèbre relationnelle, nous avons besoin de connaître les différents opérateurs de part et d’autre, et la correspondance entre eux. Dans le module intitulé “Principe des systèmes de base de données”, l’algèbre relationnelle a été présentée en détail. Donc, nous ne reprendrons plus cette présentation à nouveau.

Comme dans la requête d’optimisation, une requête SQL est décomposée en morceaux de requêtes aussi appelées unités élémentaires. Chaque morceau doit être exprimé par les opérateurs algébriques et optimisé. Une unité de requête est une expression unique SELECT- FROM-WHERE-GROUP BY-HAVING-ORDER BY. La requête ayant des requêtes imbriquées est décomposée en unités de requêtes distinctes.

(38)

Exemple:

Table 1: Décomposition d’une requête SQL.

Requête initiale Décomposition

SELECT nom FROM clients

WHERE adresse = (SELECT adresse

FROM clients

WHERE numClient=76);

sousrequete = SELECT adresse FROM clients

WHERE numClient=76;

SELECT nom FROM clients

WHERE adresse = sousrequete;

Parmi les stratégies générées par l’optimiseur de requête pour chaque unité, l’une d’entre elles est choisie. Dans l’exemple ci-dessus, l’unité intérieure ne sera effectuée qu’une seule fois pour obtenir l’adresse du client 76 qui sera utilisée par l’unité extérieure.

Il existe deux types de requêtes imbriquées: décorrélées et corrélées. Les requêtes imbriquées décorrélées seront exécutées séparément et leurs résultats seront utilisés dans la requête externe. Les requêtes imbriquées corrélées ont besoin d’informations (variable tuple) de la requête externe dans leur exécution.

Les premiers sont plus faciles à optimiser par rapport aux secondes. La requête externe de l’exemple ci-dessus est décorrélée, car elle peut être réalisée indépendamment de celle de l’extérieur.

Le tableau suivant présente la correspondance des opérateurs SQL et des opérateurs de l’algèbre relationnelle.

Table 2: D’une requête vers une expression en Algèbre Relationnelle.

Requête SQL Expression en Algèbre Relationnelle

Select * from table ; table(x1, x2, …, xn)

Select * from table1, table2 ; table1(x1, x2, …, xn) ⋅ table2(y1, y2, …, ym) Select Distinct x1, x2 from table; ∠x1,x2table(x1, x2, …, xn)

Select * from table where x1 > x2; ⌠x1,x2table(x1, x2, …, xn) Select * from table1

UNION

Select * from table2;

table1(x1, x2, …, xn) ∗ table2(y1, y2, …, ym)

(39)

Select x1, x2, x3 from table1 EXCEPT

Select y1, y2, y3 from table2;

table1(x1, x2, x3) table2(y1, y2, y3)

Select x1, x2, x3 from table1 INTERSECT

Select y1, y2, y3 from table2;

table1(x1, x2, x3) ) table2(y1, y2, y3)

Select * from table1, table2 where x1 y1; x1 y1(table1(x1, x2, x3) table2(y1, y2, y3)) Select * from table1, table2 where x1=y1; x1=y1(table1(x1, x2, x3) table2(y1, y2, y3)) Select count(*) from table group by x1; Countx1(table(x1, x2, x3))

Select SUM(x2) from table group by x1; Sumx1(table(x1, x2, x3), x2) Utilisation des Heuristiques dans l’Optimisation de Requêtes

Il y a plusieurs heuristiques dans l’optimisation des requêtes. Certaines d’entre elles sont des règles heuristiques qui commandent les opérations dans une requête, et la comparaison des coûts des différentes stratégies afin de choisir celle qui a un coût minime. Certains systèmes utilisent seulement les heuristiques, car cela est plus facile et d’autres combinent les heuristiques avec une optimisation partielle en fonction des coûts. Seules les règles heuristiques sont présentées ici.

Lorsque nous avons une requête relativement complexe, les opérations unaires (SELECTION et PROJECTION) doivent être effectuées en premier. Ensuite, les opérations binaires (PRODUIT, JOINTURE, UNION, DIFFERENCE ...) peuvent être effectuées. En effet, la taille du résultat d’une opération binaire est le produit de la taille des deux opérandes. D’un autre côté, les opérations unaires ont tendance à réduire la taille du résultat. Par conséquent, les opérations unaires doivent être appliquées avant toute opération binaire.

Example:

Soient les trois relations qui suivent:

• Affectation(codeProj, numEmp, heure),

• Employé(numEmp, nomEmp)

• Emploi(poste, taux).

La requête suivante peut être traitée de quatre façons différentes décrites dans le tableau ci-dessous: Q = les noms et le nombre d’employés qui travaillent sur le projet Pr40 et ayant plus de 10000 comme taux horaire.

(40)

Table 3: Arbres d’exécution de larequête Q.

Requête 1 Requête 2

Requête 3 Requête 4

Selon les règles heuristiques précédentes, les requêtes ci-dessus peuvent être ordonnées à partir de la plus optimale à la moins optimale comme suit: Requête 4, Requête 3, Requête 2, Requête 1.

Conclusion

(41)

Cette activité est axée sur le traitement de requête. Elle a présenté les différentes étapes du processus, dont les principaux sont l’optimisation des requêtes et le traitement des requêtes.

En outre, la traduction des requêtes SQL dans les expressions relationnelles Algèbre a été traitée. Elle a fini avec les heuristiques utilisées pour l’optimisation des requêtes. Il peut donc être conclu que, malgré la diversité de décompositions du processus de traitement de requête, les étapes principales sont la l’optimisation de requête et le traitement de requête, et le moyen d’optimisation de requête le plus utilisé constitue les règles heuristiques.

Évaluation

Soient les tables suivantes :

note(idnote, idEtudiant, idUE, idEvaluation, note, anneescolaire) ; evaluation(idEvaluation, dateEvaluation, type, annee) ;

etudiant(idEtudiant, numEtudiant, prenom, nom, scolarite, idFiliere, niveau, anneescolaire) ;//

scolarité renseigne sur le nombre d’années de scolarité de l’étudiant.

classe(idClasse, nom, idFiliere, niveau, anneescolaire) ; filliere(idFiliere, codeFiliere, nom, responsable) ;

enseignant(IdEnseignant, nom, prenom, idDepartement) ; departement(IdDepartement, idChefDept, nomDepartement) ;

ue(idUE, codeUE, nomUE, semestre, idFiliere, idEnseignant).// semestre fait référence au numéro de semestre allant de 1 à 6.

Optimisez les requêtes suivantes :

1. La liste des étudiants de niveau 3 qui ont tout validé et qui ont3 ans de scolarité.

2. Le nom des responsables des UE validées par l’étudiant de numEtudiant=ET1415.

3. Donnez le nom de la classe des étudiants qui ont validé une matière du semestre 5 de l’année 2015-2016.

Activité 2.3 - Gestion des Transactions

(42)

Introduction

L’exécution des requêtes sur une base de données doit suivre des règles qui préservent l’intégrité et la cohérence des données. La gestion des transactions d’occupe des questions.

Dans cette activité seront présentés les différents concepts à sous-jacents à gestion des transactions et les techniques y afférentes.

Objectifs de l’unité

• Définir une transaction et les différents concepts y afférents ;

• Décrire le processus de gestion des transactions ;

• Tracer le graphe de dépendances des transactions ;

• D’identifier les transactions sérialisables simples ;

• Appliquer des techniques de sérialisation des transactions ;

• Décrire les protocoles de gestion de transaction dans les cas simples.

Transaction

Un système informatique, comme tout autre système, est soumis à diverses défaillances comme une panne de courant. Dans ce cas, la perte de données peut être catastrophique. Le SGBD doit proposer un mécanisme permettant la reprise d’un traitement interrompu lors de l’exécution.

De toute évidence, il ne convient pas, en cas d’opération de mise à jour interrompue, de lancer à nouveau la nouvelle requête parce que, dans ce cas, les tuples modifiés avant l’échec seront modifiés deux fois. En outre, il est impossible d’abandonner son traitement. Dans ces deux cas, la base de données deviendra incohérente.

Un des exemples classiques est une application de réservation de billets de voyages où le nombre de places libres doit être mis à jour en soustrayant le nombre de billets vendus b, et le nombre de places réservées doit être mis à jour aussi. L’une des contraintes du système est de toujours vérifier que la somme du nombre de sièges disponibles et le nombre de sièges réservés est constante avant et après chaque opération de réservation. Ceci est la façon de veiller à ce qu’aucun siège ou un billet soit perdu. Les ordres suivants doivent être exécutés:

(43)

update sieges_disponibles set nbsieges = nbsieges – b where num_vol = V1;

update sieges_disponibles set nbsieges = nbsieges + b where num_vol = V1;

Si la contrainte est bien respectée avant et après ces deux ordres, la base de données passera par une phase d’inconsistance entre les deux ordres de UPDATE. Un échec entre les exécutions de ces ordres serait dramatique. La règle à suivre est que: la base de données doit être toujours dans un état cohérent. Il est donc nécessaire de définir une séquence d’opérations considérées par le système comme atomique. Cela signifie que soit toutes les actions de cette séquence sont exécutées, soit aucune n’est effectuée. De cette façon, la base de données peut rester cohérente en fonction de la contrainte ci-dessus. Lors de l’exécution de ces opérations, un autre utilisateur pourrait ne pas voir le changement de données, mais seulement à la fin de l’exécution: cela constitue l’isolation. Toutes ces propriétés conduisent au concept de transaction qui vise à préserver la cohérence des bases de données.

Transaction et Contrôle de Concurrence

D’une manière générale, une transaction est une opération sur un système de base de

données. Mais, lorsque deux opérations sont en cours de traitement sur une base de données en même temps, elles sont appelées transactions concurrentes. Bien que cela puisse la simultanéité des transactions soit apparente aux yeux des utilisateurs, cela n’est pas vraiment possible parce que le CPU de la machine qui traite la base de données peut exécuter une seule instruction à la fois. En règle générale, les transactions sont intercalées, ce qui signifie que le système d’exploitation commute les services CPU parmi les tâches de sorte qu’une partie de chaque transaction est effectuée dans un intervalle donné.

L’exécution simultanée des transactions est source d’incohérence dans les systèmes en raison de l’entrelacement des étapes des transactions de la base de données. Ainsi, la planification des différentes étapes des différentes transactions doit être réglementée d’une certaine manière par un composant du SGBD appelé ordonnanceur (cf. Figure 5). Afin de préserver l’exactitude de la base de données dans les processus d’exécution simultanés, la transaction est vue comme un ensemble d’actions qui se produisent sur une base de données cohérente et qui la laissent cohérente. Le Contrôle de concurrence est le processus général pour assurer que les opérations de préservation de la cohérence lors de l’exécution simultanée.

Un ordonnancement est une séquence des actions importantes prises par une ou plusieurs opérations. Les actions importantes de lecture et d’écriture ont lieu dans les tampons de la mémoire principale, pas sur le disque.