Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Bases de données objet Introduction Références bibliographiques Georges GARDARI

Bases de données objet Introduction Références bibliographiques Georges GARDARIN, “Bases de données”, Editions Eyrolles Jeffrey ULLMAN, http://www-db.stanford.edu/~ullman A quoi servent les bases de données ? Stockage des informations : • sur un support informatique • pendant une longue période • de taille importante • accès multi-utilisateurs Il faut donc : • gérer de manière efﬁcace les accès aux disques • proposer une déﬁnition structurée des données • éviter les redondances Le Système de Gestion des Bases de Données (SGBD) : • simpliﬁe la gestion des données avec : - une représentation intuitive (modèle relationnel en général) - un langage dédié (SQL) • gère les aspects système : - sécurité - accès aux ﬁchiers de données - aspect multi-utilisateurs Plan du cours Bases de données objet • Objectifs • Principe • Mise en œuvre Aspects systèmes des bases de données classiques • Fichiers • Indexation • Transaction M1 Info 2005 / 2006 — Université d’Angers — Bases de données objet 1 Historique rapide des SGBD Première génération (années 60) • Séparation de la description des données et des programmes d’application • Traitement de ﬁchiers reliés par des structures de graphe • SGBD IDMS Deuxième génération (années 70) • Simpliﬁcation du SGBD externe • Modèle relationnel • Langage non procédural • SGBD ORACLE, INFORMIX, … Troisième génération (années 80) • SGBD objet - SGBD Relationnel objet : ORACLE 8 - SGBD orienté objet : O2 Quatrième génération (années 90) • Bases de données et internet • Entrepôts de données (data warehouse) • Fouille de données (data mining) Pourquoi des SGBD objet ? Rappels sur le modèle relationnel • le schéma déﬁnit la structure de la relation • les n-uplets représentent les différents éléments Les tables respectent des propriétés déﬁnies sur les dépendances fonctionnelles ( en général, troisième forme normale (3NF) ) Avantages du modèle relationnel et des SGBD relationnels • Organisation structurée des données • Permanence des données • Accessibilité par des utilisateurs concurrents • Bien implanté dans le monde professionnel. Faiblesses du modèle relationnel • Absence de pointeurs visibles : pour lier des données qui se correspondent, on a besoin de faire des jointures (opérations coûteuses) • Non support des domaines composés : on ne peut pas avoir pas exemple un attribut qui correspond à une adresse avec le numéro de la rue, le nom de la rue, la ville, … Impossible à cause de la première forme normale, qui impose l’atomicité des attributs • Pas d’opérations déﬁnies sur les données On veut donc un SGBD capable de traiter • des éléments de structure complexe • des opérations sur les éléments • des pointeurs reliant les éléments (pour de l’héritage par exemple) Ces notions correspondent à la philosophie objet : il nous faut des SGBD objet. M1 Info 2005 / 2006 — Université d’Angers — Bases de données objet 2 Deux manières d’utiliser l’objet dans les SGBD On part des langages objet dans lesquels on intègre les notions des SGBD (persistance des données, aspect multi-utilisateurs, …). Ce sont les SGBD orientés objet : O2 (basé sur C++) On part des SGBD relationnels dans lesquels on insère des notions objet. Ce sont les SGBD relationnels objet : ORACLE 8 (SQL 3) On peut constater que • les SGBDOO sont plus “propres” du point de vue objet et les mieux adaptés pour traiter les objets mais ils sont complètement absents du monde professionnel • les SGBDRO sont basés sur des SGBD robustes et éprouvés répandus dans le monde pro- fessionnel mais qui ne sont pas prévus pour gérer l’objet Jusqu’à présent, les améliorations qui ont été développées pour les SGBD se sont fondus dans les SGBD existants. Dans le monde professionnel, les concepteurs et les utilisateurs de bases de données ne sont pas prêts à remettre en cause leurs savoirs et à redévelopper toutes leurs applications sur de nouveaux systèmes. On va privilégier les SGBDRO. Caractéristiques du modèle relationnel objet On veut un modèle qui intègre des éléments de structure complexe Une relation sera en NF2 (Non First Normal Form) et pourra contenir un attribut composé d’une liste de valuers ou de plusieurs attributs. Exemple de table et de n-uplet (assurance d’un véhicule) N° contrat Nom Adresse Conducteurs Accidents 1111 J. CHIRAC Elysée 75000 PARIS … … … … … Par rapport au modèle relationnel standard : • on a moins besoin d’aplatir les données, ici on a une seule table avec des tables imbri- quées au lieu de 3 tables • on a moins besoin de faire des jointures pour récupérer les informations sur les accidents du contrat 1111, on accède simplement à l’attribut accidents. M1 Info 2005 / 2006 — Université d’Angers — Bases de données objet 3 N° contrat Personne Date 375 Nicolas 2005 789 Lionel 2002 Nom Age Bernadette 70 Claude 75 I. Bases de données objet Les types utilisés dans les BDO sont • les types standards existant dans les BD classiques : VARCHAR, NUMBER… • les types utilisateurs - déﬁnis par le concepteur de la base - utilisés comme des types standards On appelle aussi ces types utilisateurs des types objet car ils ont une structure complexe et peuvent contenir des opérations (méthodes). Exemple de création de type objet CREATE TYPE t_adresse AS OBJECT ( num NUMBER, rue VARCHAR(30), ville VARCHAR(20), codepostal CHAR(5) ) ; On peut ensuite utiliser ce type objet (ou type utilisateur) • soit pour déﬁnir une table relationnelle standard • soit pour déﬁnir une table relationnelle objet (ou table objet relationnelle) • soit pour déﬁnir d’autres types objet qui contiennet cette structure. Exemple d’objet de type t_adresse t_adresse (2, ‘Bd Lavoisier’, ‘ANGERS’, ‘49000’) <constructeur de type> ( <valeurs des différents champs du type t_adresse>) Utilisation du type dans un autre type CREATE TYPE t_personne AS OBJECT ( nom VARCHAR(30), prenom VARCHAR(30), adresse t_adresse ) ; Utilisation d’un type utilisateur dans une table relationnelle standard Dans une table relationnelle, on l’utilise comme un type prédéﬁni standard. Exemple CREATE TABLE employes ( num NUMBER, dept NUMBER, salaire NUMBER, adresse t_adresse, -- type objet nom VARCHAR(30), PRIMARY KEY num -- on peut déﬁnir des contraintes habituelles sur la table ) ; M1 Info 2005 / 2006 — Université d’Angers — Bases de données objet 4 Insertion dans une table relationnelle (on procède comme habituellement) INSERT INTO employes VALUES (1000, 15, 2000, t_adresse (2, ‘Bd Lavoisier’, ‘ANGERS’, ‘49000’), ‘toto’) ; -- On utilise le constructeur d’objet t_adresse pour écrire l’adresse Interrogation dans une table relationnelle (on procède aussi comme habituellement) SELECT * FROM employes ; -- On obtient la table suivante : num dept salaire adresse (num, rue, ville, cp) nom 1000 15 2000 t_adresse (2, ‘Bd Lavoisier’, ‘ANGERS’, ‘49000’) toto SELECT e.adresse FROM employes e ; -- Préciser un alias de table adresse (num, rue, ville, cp) t_adresse (2, ‘Bd Lavoisier’, ‘ANGERS’, ‘49000’) SELECT e.adresse.num FROM employes e ; adresse.num 2 Utilisation d’un type objet dans une table relationnelle Un table objet relationnelle est une table qui contient des éléments de type objet. Chaque élément est identiﬁé par un numéro appelé OID (Object Identiﬁer). Exemple avec le type t_adresse CREATE TABLE adresses OF t_adressse ; On a une relation dont chaque élément est un objet de type t_adresse. On peut voir la relation de deux manières différentes : vision objet t_adresse(…) OID1 | num1 | rue1 | ville1 | cp1 OID2 | num2 | rue2 | ville2 | cp2 … vision relationnelle num rue ville cp OID1 num1 rue1 ville1 cp1 OID2 num2 rue2 ville2 cp2 … … … … … M1 Info 2005 / 2006 — Université d’Angers — Bases de données objet 5 Remarque On peut écrire des contraintes comme en relationnel standard lors de la création de la table, on peut déﬁnir des clés, etc. CREATE TABLE adresses OF t_adresse (ville DEFAULT ‘ANGERS’) ; Insertion dans une table objet relationnelle On a deux manières d’insérer des n-uplets : • soit avec le constructeur de type (vision objet) INSERT INTO adresses VALUES ( t_adresse(30, ‘Bd Foch’, ‘ANGERS’, ‘49000’) ) ; -- on insère un objet avec constructeur de type et valeurs des champs du type objet • soit en précisant chacun des champs (vision relationnelle) INSERT INTO adresses VALUES (30, ‘Bd Foch’, ‘ANGERS’, ‘49000’) ; -- on précise les valeurs des différents attributs de la table relationnelle Les deux requêtes sont équivalentes : • on insère un n-uplet • un OID lui est attribué lors de l’insertion Interrogation dans une table objet relationnelle On peut accéder aux valeurs comme dans le cas du relationnel standard. SELECT * FROM adresses ; SELECT a.num, a.rue, a.ville, a.cp FROM adresses a ; -- a est un alias de table On peut accéder aux objets. SELECT VALUE(a) FROM adresse a ; -- a est un alias de table et VALUE est un mot clé pour récupérer les objets On peut accéder aux OID SELECT REF(a) FROM adresse a ; -- a est un alias de table et REF est un mot clé pour récupérer les OID Qu’obtient on comme relations avec ces requêtes ? En accédant aux valeurs uploads/Geographie/ bd-objet.pdf