Bases de Données Avancées: Nouvelles Perspectives

Présentation au sujet: "Bases de Données Avancées: Nouvelles Perspectives"— Transcription de la présentation:

1 Bases de Données Avancées: Nouvelles Perspectives
Rim Samia Kaabi 16 avril 2017

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 SGBD relationnel Langage SQL 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, …

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 2067 Dupont 0456 Martin 0278 Martin 0789 Blanc

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 Généralités sur les SGBD-OR
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 Extension du modèle relationnel Extension de SQL
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 OBJET Polymorphisme RELATIONNEL Types utilisateurs Domaine Table Attribut Clé Référence Collections Opération Identifiant Héritage 8 8 29

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 Conducteur Age Accident Rapport Photo 24 Paul Paris Paul 45 134 Robert 17 219 037 Objet Police 38

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) 12 39 13

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 12 40 13

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 12 41 13

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 12 42 13

43 SQL3 – Les composants Part 1: Framework Part 2: Foundation
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 13 43 14

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 14 44 15

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 15 45 16

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 16 46 17

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 17 47 18

48 Quelques exemples Un type avec référence Un type sans 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) 18 48 19

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 constructeurs additionnels stack, queue, array, etc non intégrés dans le langage 19 49 20

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 20 50 21

51 SQL3 - Les tables Caractéristiques
une table peut posséder des attributs d'un type abstrait un tuple contient des références ou des valeurs complexes un attribut peut être de type référence (REF <type> ou with OID) Possibilité d'utiliser un type prédéfini CREATE TABLE cars OF car ; Possibilité de définir un nouveau type Le type est celui des tuples de la table CREATE TABLE Constructors OF NEW TYPE Constructor (name VARCHAR, total MONEY) ; Possibilité de définir des sous-tables CREATE TABLE FrenchConstructors UNDER constructors(taxe MONEY) 21 51 22

52 L'appel de fonctions et opérateurs
SELECT r.name FROM emp j, emp r WHERE j.name = 'Joe' and distance (j.location,r.location) < 1 ; Appel d'opérateurs FROM emp, emp r WHERE emp.name = 'Joe' and contained(r.location, circle(emp.location,1)) ; 22 52 23

53 Le parcours de référence
Possibilité d'appliquer les fonctions Ref et DeRef (implicite) CREATE TABLE cars OF TYPE car SELECT c.Owner.name FROM cars c WHERE color = 'red' Possibilité de cascader la notation pointée SELECT dname FROM dept WHERE 1985 IN auto.years Généralisation possible aux chemins multiples SELECT dname FROM dept WHERE autos.(year=1985 and name = 'Ford') 23 53 24

54 Exemple de tables imbriquées
Services N° Chef Adresse Employés Dépenses Nom Age NDep Montant Motif 24 Paul Versailles Livres Mission Portable 134 Pierre 45 Marie 37 219 037 Nom Age NDep Montant Motif Livres Mission Eric 42 25 Patrick Paris Julie 51 185 54

55 Comparaison avec le relationnel
Accès en relationnel Accès en objet-relationnel select p.effdate, p.name, p.vehicleyr from policy p where p.carmodel.make = ‘ferrari’ select effdate, name, vehicleyr from policy, customers, vehicles where policy.custno = customers.custno and policy.vehicleno = vehicles.vehicleno and model = ‘ferrari’ 55

56 Exemple d'application Images Type Library
Différents formats : TIFF,GIF,JPEG, … Fonctions : rotate(image,angle) returns image transpose(image) returns image flip(image) returns image enhance(image), oil_painting(image) plus(image,image), minus(image,image) intersection(image,image), union(image,image) histogram(image) returns(table) similarity(image,image) 25 56 28

57 Généralités sur les SGBDOO
Plan Généralités sur les SGBDOO

58 Introduction Un SGBDOO doit d’abord supporter les fonctionnalités d’un SGBD: Persistance des objets Concurrence d’accès Fiabilités des objets Facilité d’interrogation + un ensemble de fonctionnalités OO: Support d’objets atomiques et complexes Identité d’objets Héritage simple polymorphisme 6 58 6

59 Les SGBDOO Modèle objet «pur» • Persistance
• langages : C++, Smalltalk, Java / OQL • Produits: O2, ObjectStore, Ontos, Objectivity, Jasmine • Niches technologiques: CAO, SIG, Gestion de Données Techniques, ...

60 Concept du modèle objet ODMG
Objet, attribut, association Opérations (méthodes), exceptions Héritage Multiple Clé Identité, nommage et durée de vie des objets Valeurs (litéraux) atomiques, structurées, collection Collections list, set, bag, array Transactions, Contrôle de Concurrence, Verrouillage 5 60 5

61 Les standards ODMG • Spécification Procédural
• ODL - Object Definition Language • OIF - Object Interchange Format • Manipulation • Non-Procédural OQL - Object Query Language Procédural OML - Object Manipulation Language 5 61 5

62 OQL- Object Query Language
Langage déclaratif d’interrogation compatibilité avec l ’ordre SELECT de SQL-92 proposé par O2 Technology Fonctionnalités générales • tous les types ODMG et identité d’objet • requête select … from … where … • polymorphisme de collections sources • imbrication de requêtes, requêtes nommées • appel d’opérateurs et de méthodes • opérateurs ensemblistes (union, intersect, except) • opérateur universel (for all) • quantifieur existentialiste (exists) • order by, group by, fonctions d ’agrégat (count, sum, min, max, avg) 6 62 6

63 Exemple Exercice: A quelle question répond cette requête ?
select cl.name, paid from ( select x from Companies c, c.clients x where c.address.city = "New York« ) cl where count (cl.orders) > 2 order by paid: sum ( select o.price from cl.orders o ) Exercice: A quelle question répond cette requête ? 6 63 6

64 Un Standard En Evolution
PROPOSITION CONCURRENTE DE L'ODMG Accord entre constructeurs de SGBD Objets Support du modèle pur objet de l'OMG Variation de SQL traitant des collections imbriquées Accord ANSI X3 H2 et ODMG Définition d'un langage d'interrogation intégrant relationnel et objet Convergence relationnel-objet vers SQL3 De nombreux points restent à fixer Visibilité des OID ? Chemins multivalués ? Cohérence ? 26 64 29

65 Généralités sur les BD déductives
Plan Généralités sur les BD déductives

66 Concept et motivation L'idée est de coupler une base de données a un ensemble de règles logiques qui permettent d'en déduire de l'information. Cela pourrait se faire dans le contexte d'un langage de programmation, mais on souhaite un couplage plus direct qui permet de manipuler les données au niveau de la base de données. Les questions qui se posent sont les suivantes: Quelles est la forme des règles que l'on souhaite utiliser? Comment les interpréter ? Les requêtes exprimées en SQL peuvent-elles être exprimées par des règles ? Les règles peuvent-elles exprimer plus ? 26 66 29

67 Définition Une base de données déductive (BDD) est constituée:
d'un ensemble de prédicats (relations), dits de base ou extensionnels , dont l'extension est conservée explicitement dans la base de données: la base de données extensionnelle d'un ensemble de prédicats (relations), dits dérivés ou intentionnels , dont l'extension est définie par des règles déductives : la base de données intentionnelle 26 67 29