Bases de Données Avancées: Nouvelles Perspectives

1. Bases de Données Avancées: Nouvelles Perspectives Rim Samia Kaabi 3 juin 2014

2. Introduction • Rappeler les fonctionnalités essentielles des SGBD • Présenter l’évolution des SGBD • Présenter les axes de recherche dans le domaine • Présenter l’ensemble du cours

3. Problématique

4. Combien de fois avez-vous accédé à une BD aujourd’hui?

5. Accéder à des ensembles de données 􀂄 Accéder à différents ensembles de données - La météo - Les informations boursières - Les vols disponibles pour votre prochain voyage - Des informations sur la population de la Tunisie - Votre dossier étudiant à l’ISI - Vos dossiers au bureau - Vos photos et vidéos familiales 􀂄Avec différents équipements et depuis différents endroits - Avec votre PC chez vous - A l’université avec votre ordinateur portable - Au restaurant avec votre téléphone cellulaire

6. Quelle forme ont ces données, où sont-elles stockées • Des données non structurées • -Données stockées dans des fichiers sans structure définie ou explicite ( un fichier .doc, un courriel) • Des données semi-structurées • -Données stockées dans des fichiers avec une représentation explicite de leur structure (un fichier XML contenant la description des cours de l’ISI • Des bases de données: • -Ensemble de données ayant une certaine cohérence entre • elles; • - Données stockées dans des structures déterminées; • - Accessible et gérables grâce à des outils logiciels spécifiques: SGBD mais aussi grâce à des outils moins élaborés comme des tableurs

7. Nouveaux problèmes, nouvelles perspectives 􀂄 Traditionnellement: - Les SGBD ont été conçus pour répondre aux besoins des applications traditionnelles d’affaire - Et avec l’ensemble des données stockées dans une ou plusieurs bases de données gérées par des outils équivalents; 􀂄 Aujourd’hui - Les données sont partout, pas seulement dans des BD, leur structure n’est pas toujours définie, ni même complètement définie; - Les usagers veulent accéder, partager, manipuler et intégrer des ensembles de données de toutes provenances. 􀂄 Nouvelles perspectives - Des fonctionnalités de base toujours nécessaires mais une ouverture, une flexibilité et une adptabilité plus grandes.

8. Evolution des SGBD 1955-1960: SGF 1960-1980: SGBD hiérarchiques SGBD réseaux 1970-1990 SGBD relationnel Langage SQL 1985-1990 SGBD objet Depuis 1995 BD et internet BD et applications décisionnelles

9. ODMG • Groupe de normalisation des SGBD OO • Norme finale publiée en 2001 • A regroupé de nombreux vendeurs de SGBO OO et des constructeurs, des utilisateurs, des chercheurs, … • www.odmg.org

10. SGBD relationnels • le modèle relationnel • repose sur la définition de domaines et de relations entre ces domaines • toutes les données sont représentées sous forme de tables • l’algèbre relationnelle permet la manipulation du contenu des tables • langages de manipulation • dits "assertionnels", l'utilisateur spécifie ce qu'il veut obtenir et non comment l'obtenir • langage de définition et de manipulation de données intégrés et normalisés : SQL • langage interactif de définition et de manipulation • fournisseurs :Oracle, IBM, Microsoft, Sybase • produits commercialisés dans les années 80

11. SGBD objets • modèle de données objet: • modèle de données plus riche sémantiquement • distinction entre les concepts d'entités, d'associations • distinction entre différents types d'associations • langages : • langages de manipulation combinant requêtes associatives de requêtes navigationnelles • intégration langage de programmation et langage bases de données • produits : • produits commercialisés à la fin des années 80 (1989) ObjectStore, GemStone, Versant, Objectivity

12. Depuis 1995… • Bases de données et internet • Accès distant au contenu des BD • Fédération et inter-opération des BD • Transformations des données et des requêtes • Bases de données et décisionnel • Entreposage de données • Analyse de données • Qualité des données • Gestion de données volumineuses • Données multimédia • Flots de données

13. Axes de recherche de ces quinze dernières années • Bases de données objet : • intégrer les concepts objets dans les SGBD (classe, héritage) • Bases de données déductives : • enrichir les SGBD de possibilités de déduction • Bases de données multimédia : • intégrer dans un SGBD la gestion de données textuelles, graphiques, images, sons etc..

14. Axes de recherche de ces quinze dernières années • Bases de données réparties : • Permettre d’intégrer, d’interroger et de mettre à jour des données provenant de sites répartis géographiquement • Systèmes d'aide à la décision: • Générer de nouvelles informations à partir de l'analyse de gros volumes de données; entreposer et accéder les "vieilles" données • Bases de données et web: • Étendre les possibilités des SGBD pour répondre aux applications fonctionnant dans l’environnement web

15. Concept BD = ensemble de données permanentes, intégrées, partagées, en accès simultané • Intégrité • Sécurité: protection contre les accès non autorisés • Atomicité des transactions • Fiabilité: protection contre les pannes • Langages de requêtes et de mises à jour déclaratifs • Performances : techniques de stockage, optimisation des requêtes

16. SGBDR : avantages • • E. Codd, 1970 • • Basé sur la théorie des ensembles • • Indépendant de toute implémentation • • Basé sur la notion de relation • • Standard de fait • • Facile à comprendre : "relation = tableau" • • Indépendance entre les programmes d'applications et la représentation interne des données • •Fournit une base solide pour traiter les problèmes d'incohérence et de redondance • langage déclaratif standard SQL2

17. Exemple de relation EMPLOYE NoEmp Nom Année NoDep Entiers Caractères Entiers Entiers 1045 Dupond 1978 03 2067 Dupont 1965 06 0456 Martin 1981 03 0278 Martin 1987 05 0789 Blanc 1981 06

18. Relationnel : Normalisation Processus récursif permettant d’obtenir des tables qui seront "sans problèmes" lors de l’utilisation Les tables sont dites en 1ère, 2ème ou 3ème FN  Avantage majeur de l’approche relationnelle

19. Relationnel : Formes Normales • 1ère FN : une relation est en 1FN si tous les attributs qui la compose sont non décomposables • 2ème FN : une relation est en 2FN si elle est en 1FN et si toutes les DFs entre la clé et les autres attributs sont élémentaires. • 3ème FN : une relation est en 3FN si elle est en 2FN et si toutes les DFs entre la clé et les autres attributs sont élémentaires et directes.

20. Relationnel : Formes Normales • 1ère FN : Personne (numP, patronyme)  Personne(numP, nom, prenom) • 2ème FN : Employé(numE, numP, nomE, temps) • Employé(numE, nomE), • TempsProjet(numE, numP, temps) • 3ème FN : fournisseur(numF, nomF, NumP, prixP)  fournisseur(numF, nomF, NumP), Produit(NumP, prixP)

21. Relationnel : Faiblesses • Absence de pointeurs visibles • Jointure par valeurs à éviter: opération lourde et coûteuse • Chaînage direct des données: à considérer • Non support de domaines composés • 1FN inadaptée aux objets complexes • Introduction des BLOB et CLOB est insuffisante • Non intégration des opérations

22. Applications "nouvelles": Caractéristiques • des structures d’objets plus complexes, • des transactions de durée plus longue, • de nouveaux types de données pour le stockage d’images ou de gros documents de texte, • la possibilité de définir des opérations non standards qui sont spécifiques aux applications,

23. L’objet-relationnel et l’orienté-objet constituent une tentative de réponse à (certains de) ces besoins nouveaux

24. C'est un système qui intègre les fonctionnalités d'un SGBFR et les caractéristiques d'un langage objet • Modélisation : • intégration des concepts des modèles de données objets complexes • conception homogène des données et des programmes concept de classe et notions d'héritage

25. Approches •  SGBD Objet •  SGBD relationnel-objet

26. Deux approches en BD

27. Plan Généralités sur les SGBD-OR

28. Modèle objet relationnel • Le modèle objet-relationnel (OR) reprend le modèle relationnel en ajoutant quelques notions qui peuvent être très utiles dans certaines circonstances • La compatibilité est ascendante : les anciennes applications relationnelles fonctionnent dans le monde OR • La norme SQL99 (SQL3) reprend beaucoup d’idées du modèle OR

29. L'objet-relationnel OBJET Polymorphisme RELATIONNEL Types utilisateurs Domaine Table Attribut Clé Référence Collections Opération Identifiant Héritage • Extension du modèle relationnel • attributs multivalués : structure, liste, tableau, ensemble, ... • héritage sur relations et types • domaine type abstrait de données (structure cachée + méthodes) • identité d'objets • Extension de SQL • définition des types complexes avec héritage • appels de méthodes en résultat et qualification • imbrication des appels de méthodes • surcharge d'opérateurs

30. Pourquoi étendre le modèle relationnel? • La reconstitution d’objets complexes éclatés sur plusieurs tables relationnelles est coûteuse car elle occasionne de nombreuses jointures • Pour échapper aux éclatements jointures, l’OR réhabilite • les références qui permettent d'implanter des structures complexes • les attributs multivaluées (tableaux, ensembles ou listes)

31. Pourquoi étendre le modèle relationnel? • SQL92 ne permet pas de créer de nouveaux types •  manque de souplesse et une interface difficile avec les applications orientées objet • L’OR (et SQL99) permet de définir de nouveaux types utilisateur simples ou complexes (User data type), avec des fonctions ou procédures associées comme dans les • classes des langages objet • L’OR supporte l’héritage de type pour profiter du polymorphisme et faciliter la réutilisation

32. Pourquoi ne pas passer directement aux SGBD OO? • Le relationnel a ses avantages, en particulier • sa grande facilité et efficacité pour effectuer des recherches complexes dans des grandes bases de données • la facilité de spécifier des contraintes d’intégrité sans programmation • une théorie solide et des normes reconnues

33. Pourquoi ne pas passer directement aux SGBD OO? • Inertie de l’existant : de très nombreuses bases relationnelles en fonctionnement • Manque de normalisation pour les SGBDO ; • trop de solutions propriétaires • SGBDOO moins souple que le relationnel pour s’adapter à plusieurs applications • Peu d’informaticiens formés aux SGBDO • Le modèle OR peut permettre un passage en douceur

34. Nouvelles possibilités de l’OR • Définir de nouveaux types complexes avec des fonctions pour les manipuler: NF2 • Une colonne peut contenir une collection (ensemble, sac, liste) • Ligne considérée comme un objet avec un objet, identificateur (Object Identifier OID) • Utilisation de références aux objets • Extensions du langage SQL (SQL3) pour la recherche et la modification des données

35. Exemple type REGION = [NOMR : Chaine, POPUR : Entier, DPTS : { [ NOMD : Chaine, SUPER : Entier, POPUD : Entier ] } ] => une relation est définie comme une variable REGIONS de type {REGION}

36. Les problèmes de l’OR • Ne s’appuie pas sur une théorie solide comme le modèle relationnel • Manque de standard de fait : implantations différentes, et encore partielles, dans les divers SGBDs

37. SQL99 (SQL3) • SQL3 étend le SQL aux concepts Objet. • • Cependant la « relation » reste fondamentale dans la manipulation des données • Les SGBD basés sur SQL3 sont appelés Objet-Relationnels • • Informix, Oracle, Sybase, IBM/DB2, CA-OpenIngres, • PostGres ...

38. Exemple de table et objet (Oracle8) Num Nom Adresse Conducteurs Accidents Age Conducteur Accident Rapport Photo 24 Paul Paris Paul 45 134 Robert 17 219 037 Objet Police

39. Principe Typage fort Type = Données + Méthodes La création de type ne crée pas d’objets Les objets d’un type sont persistants que lors ils sont insérés dans des tables déclarées (CREATE TABLE)

40. Vue d’ensemble de SQL3 De multiples facettes : Un langage de définition de types Un langage de programmation Un langage de requêtes Un langage temporel ... Pour gérer des données complexes dans le cadre de système objet-relationnel Nouveaux Illustra, UniSQL, ODB II, Versant Relationnels étendus ("universels") Ingres, Oracle, DB2 UDB, Informix

41. Concepts • • Extensibilité des types de données • – Définition de types abstraits • – Possibilité de types avec ou sans OID • • Support d’objets complexes • – Constructeurs de types (tuples, set, list, …) • • Héritage • – Définition de sous-types • – Définition de sous-tables

42. Le modèle SQL3 • Extension objet du relationnel, inspiré de C++ • – type = type abstrait de donnée avec fonctions • – fonction • • associée à une base, une table ou un type • • écrite en SQL, SQL3 PSM (Persistent Stored Module) ou langage externe (C, C++, Java, etc.) • – collection = constructeur de type • table, tuple, set, list, bag, array • – sous-typage et héritage • – objet = instance de type référencée par un OID (défaut) • – association = contrainte d'intégrité inter-classe

43. SQL3 – Les composants • Part 1: Framework • Une description non-technique de comment le document est structuré. • Part 2: Foundation • Le noyau de specification, incluant les types de données abstraits. • Part 3: SQL/CLI • l’interface d’appel client. • Part 4: SQL/PSM • le langage de spécifications de procédures stockées • Part 5: SQL/Bindings • les liens SQL dynamique et “embedded” SQL repris de SQL-92. • Part 6: SQL/XA • Une spécification de l’interface XA pour moniteur transactionnel. • Part 7: SQL/Temporal • Le support du temps dans SQL3

44. SQL3 - Les triggers • Création des triggers • événement = INSERT, UPDATE, DELETE • possibilité de déclencher avant ou après l'événement • action = opération sur table avec éventuelle condition • possibilité de référencer les valeurs avant ou après mise à jour

45. SQL3 - Les procédures (PSM) • Langage de programmation de procédures • déclaration de variables • assignation • conditionnels CASE, IF • boucles LOOP, FOR • exceptions SIGNAL, RESIGNAL • possibilité de procédures et fonctions externes • Possibilité de structuration en modules

46. SQL3 - Les Objets • Extensibilité des types de données • Définition de types abstraits • Possibilité de types avec ou sans OID • Support d’objets complexes • Constructeurs de types (tuples, set, list, …) • Utilisation de référence (OID) • Héritage • Définition de sous-types • Définition de sous-tables

47. SQL3 - Les types abstraits • CREATE TYPE <nom ADT> <corps de l’ADT> • <corps de l’ADT> • <OID option> ::= WITH OID VISIBLE • objets sans OID par défaut • <subtype clause> ::= UNDER <supertype clause> • possibilité d’héritage multiple avec résolution explicite • <member list> • <column definition> : attributs publics ou privés • <function declaration> : opérations publiques • <operator name list> : opérateurs surchargés • <equals clause>, <less-than clause> : définition des ordres • <cast clause> : fonction de conversion de types

48. Quelques exemples • Un type avec référence • CREATE TYPE WITH OID phone (country VARCHAR, area VARCHAR, number int, description CHAR(20)) • Un type sans référence • CREATE TYPE person (ncin INT, nom VARCHAR, tel phone) • Un sous-type • CREATE TYPE student UNDER person (major VARCHAR, year INT)

49. Les constructeurs de types • Les types paramétrés • possibilité de types paramétrés (TEMPLATE) • généricité assurée par le compilateur ... • Les constructeurs de base • collections SET(T), MULTISET(T), LIST(T) • CREATE TYPE person (cin INT, nom VARCHAR, prénoms LIST(varchar), tel SET(phone)) • Les références • possibilité de référencer un objet créé “without OID” • CREATE TYPE car (number CHAR(9), color VARCHAR, owner REF(person)) • Les constructeursadditionnels • stack, queue, array, etc • non intégrés dans le langage

50. SQL3 - Les fonctions • Définition des fonctions • [<function type>] : CONSTRUCTOR, DESTRUCTOR • FUNCTION <function name> <parameter list> RETURNS <function results> <SQL procedure> | <file name> END FUNCTION • Peuvent être associées à une base, un type, une table, … • Exemple CREATE FUNCTION sell (c Ref(Constructor), amount MONEY) UPDATE Constructor SET total = total + amount WHERE Ref(Constructor) = c END FUNCTION