1 D'après G. Gardarin SGBD : INTRODUCTION ET ARCHITECTURES l 1. Objectifs des SGBD l 2. Applications et schémas l 3. Définitions l 4. Architecture fonctionnelle.

Présentation au sujet: "1 D'après G. Gardarin SGBD : INTRODUCTION ET ARCHITECTURES l 1. Objectifs des SGBD l 2. Applications et schémas l 3. Définitions l 4. Architecture fonctionnelle."— Transcription de la présentation:

1 1 D'après G. Gardarin SGBD : INTRODUCTION ET ARCHITECTURES l 1. Objectifs des SGBD l 2. Applications et schémas l 3. Définitions l 4. Architecture fonctionnelle des SGBD l 5. Architectures client-serveur l 6. Le marché des SGBD

2 2 D'après G. Gardarin 1. Objectifs des SGBD (1) l Assurer l'indépendance des programmes par rapport aux données.  Indépendance physique de la représentation et du stockage des données. l Les données élémentaires du monde réel sont assemblées pour décrire les objets et les associations entres ces derniers. l Le SGBD permet de décrire une structure naturelle (ou canonique) des données. l Le schéma interne doit pouvoir être modifié sans induire des modification du schéma conceptuel. l L'indépendance physique garantit que l'organisation des données sur mémoire secondaire n'influe pas sur l'organisation canonique des données. l En d'autre terme, le système de gestion de fichiers gère les données sur disque indépendamment du SGBD.

3 3 D'après G. Gardarin Objectifs des SGBD (2) l Indépendance logique : permet de modifier le schéma externe sans modifier le schéma conceptuel  Il est important de permettre une indépendance des données vues par les applications relativement à leur représentation canonique pour garantir aux différentes classes d'utilisateurs d'avoir respectivement accès à leurs propres données à partir de vues spécifiques. l L'indépendance logique est donc la possibilité de modifier un schéma externe sans modifier le schéma conceptuel.  Possibilité de modifier les schémas conceptuels et internes des données sans modifier les programmes d'application, donc sans modification des schémas externes.  Eviter une maintenance coûteuse lors des modification des structures logiques.

4 4 D'après G. Gardarin Objectifs des SGBD (3) l Permettre l'accès et/ou la manipulation de la base par des langages assertionnels, non procéduraux.  Recherche (le quoi et non le comment).  Insertion (en groupes, calculées).  Mise à jour (basée sur la recherche). l Efficacité des accès aux données  Temps de réponse & débit global  Benchmarks TPC/A, B, C, D ==> TPS (Transactions/s), CPM

5 5 D'après G. Gardarin Objectifs des SGBD (4) l Dotés des propriétés ACID pour le support des transactions  Atomicité (transaction totalement exécutée ou pas du tout).  Cohérence (respect des contraintes d'intégrité) pour protéger la base des mises à jour concurrentes et erronées.  Isolation (non visibilité des mises à jour non commises).  Durabilité (garantie des mises à jour commises). l Il faut garantir les utilisateurs contres les mises à jour concurrentes et donc garantir le partage et la sécurité des données.  Nombre maximum d'accès simultanés en lecture/écriture.  Accès transactionnels & décisionnels.  Confidentialité (authentification, droits d'accès, cryptage).  Restauration après une panne (journalisation, sauvegardes).

6 6 D'après G. Gardarin Objectifs des SGBD (5) l Faciliter la conception des applications  Conception visuelle des BD (diagrammes Entité/Relation, objets).  Conception des traitements (diagrammes des flux entre modules).  Conception du dictionnaire de données (objets BD, graphiques, applicatifs), description de la spécificité de la base de données d'une entreprise. l La sécurité doit être garantie sous toutes ses formes. l Outils d'administration  Permettre une administration aisée de la base.  Audit & d'optimisation (tunning).  Visualisation des plans d’accès.  Élaboration de statistiques d'utilisation.

7 7 D'après G. Gardarin 2. Les applications d'un SGBD CaractéristiquesOLTPOLAP Opérations typiquesMise à jourAnalyse Type d'accèsLecture/EcritureLecture Niveau d'analyseElémentaireGlobal EcranFixeInteractif Quantité d'info échangéeFaible Importante OrientationRecord Multi-dimensionnel Taille BD100 MB-GB 1GB - TB Ancienneté des donnéesRécenteRécente Historique Future OLTP/OLAP : Objet Langage Transaction/Application Protocol

8 8 D'après G. Gardarin 3. Définitions : les objets l Type d'objet (Object type)  Ensemble d'objets dotés de propriétés communes sur lesquels opèrent les mêmes opérations. l Instance d'objet (Object Instance)  Un objet particulier identifiable parmi les objets d'un type donné.

9 9 D'après G. Gardarin Définitions : modèles et schéma l Modèle de description de données  Ensemble de concepts et de règles de composition de ces derniers permettant la description des données. l Langage de description des données  Langage supportant un modèle et permettant de décrire les données d'une base de telle sorte qu'un ordinateur puisse les traiter. l Description à partir d'un langage déterminé d'un ensemble de données spécifiques.

10 10 D'après G. Gardarin Niveaux d'abstraction : le schéma conceptuel l Schéma conceptuel (Conceptual Schema)  Description des données (par exemple d'une entreprise) en terme de types d'objets et de liens logiques indépendante de toute représentation sur un ordinateur, correspondant à une vision canonique globale de l'entreprise modélisée. l C'est la description des entités et des associations du monde réel.

11 11 D'après G. Gardarin Niveaux d'abstraction : le schéma interne l Schéma interne (Internal schema)  Description des données d'une base en terme de représentation physique en machine, correspondant à une spécialisation des structures de mémorisation et des méthodes de stockage et d'accès utilisés pour ranger et accéder à la base sur le disque. l C'est l'implémentation physique des entités et associations dans les fichiers.

12 12 D'après G. Gardarin Niveaux d'abstraction : le schéma externe l Schéma externe (External schema)  Description d'une partie de la base de données extraite ou calculée à partir de la base réelle stockée, correspondant à une vision d'un applicatif ou d'un utilisateur, donc à un arrangement particulier de certaines données.

13 13 D'après G. Gardarin Buveurs Abus Vins NV 1 1996 Chablis 21978Volnay 31984Médoc CruMillésime VINS Index NB 1 356 Denis 2124Georges 3425Cornell NomTotal TOTALBUS Exemple l Schéma conceptuel  description des entités et des associations du monde réel l Schéma interne  implémentation physique des entités et associations dans les fichiers l Schéma externe (vues-browser)  description des entités et associations vues par un utilisateur (ou un groupe d’utilisateurs)

14 14 D'après G. Gardarin Le modèle entité/association l Agrégation (Aggregation)  Abstraction consistant à grouper des objets de base pour constituer des objets composés d'une concaténation d'objets composants. l Entité  Modèle d'objet identifié du monde réel dont le type est défini par une agrégation d'objets élémentaires, un nom et une liste de propriétés.

15 15 D'après G. Gardarin Le modèle entité/association Volnay78 1978100VolnayExcellent Exemple d'agrégation de valeurs

16 16 D'après G. Gardarin Le modèle entité/association l Association (Relationship)  Lien logique entre au moins deux entités dont le type est défini à partir d'un verbe et d'une liste éventuelle de propriétés. l Attribut  Propriété d'un entité ou d'une association caractérisée par un identificateur et un type élémentaire.

17 17 D'après G. Gardarin Le diagramme entité/association l Le modèle entité/association permet une représentation graphique élégante des schémas de bases de données. Buveur Abus Vin Degré Cru Date Type Nom Prénom Adresse Quantité Qualité Quantité Millésime

18 18 D'après G. Gardarin 4. Architecture fonctionnelle des SGBD l Articulée autour du dictionnaire de données. l Constituée de deux parties  Ensemble de modules (appelés processeurs) permettant d'assurer la description des données et donc la constitution du dictionnaire de données.  Une partie permettant d'assurer la manipulation des données, à savoir les interrogations et mises à jour de la base.

19 19 D'après G. Gardarin Admin. Entreprise Admin. BD Admin. Application Processeur de schéma Conceptuel Processeur de schéma Interne Processeur de schéma Externe DICTIONNAIRE Transformateur Conceptuel Interne Transformateur Interne Stockage Transformateur Externe Conceptuel Programme d’application Système d’E/S Programmeur. d’application Architecture ANSI/X3/SPARC 1 3 3 6 4 2 7 5 14 1110 12 13 9 8

20 20 D'après G. Gardarin Interfaces d'accès  1 : LDD format source  2 : LDD conceptuel, format objet ; le (1) compilé  3 : Description des données conceptuel, format d'édition.  4 : LDD externe format source  5 : LDD externe format objet  6 : LDD interne format source  7 : LDD interne format objet  8 : LMD externe format source  9 : LMD externe format objet  10 : LMD conceptuel format objet  11 : LMD interne format objet

21 21 D'après G. Gardarin Interfaces d'accès  12 : Langage de stockage de données, format objet  13 : Interface avec la mémoire secondaire  14 : Interface d'accès au dictionnaire de données

22 22 D'après G. Gardarin Premières conclusions l Les SGBD assurent la gestion efficaces des données partagées et structurées l Trois niveaux de schémas implémentés :  conceptuel,  interne,  externe, l Questions  Et les fichiers ?

23 23 D'après G. Gardarin 5. L'architecture Client-Serveur l Définition  Modèle d'architecture applicative où les programmes sont répartis entre processus clients et serveurs communiquant par des requêtes avec réponses. l Une répartition hiérarchique des fonctions  Données sur le serveur partagées entre N clients.  Interfaces graphiques sur la station de travail personnelle.  Communication par des protocoles standardisés/normalisés.  Distribution des programmes applicatifs pour minimiser les coûts.

24 24 D'après G. Gardarin Pourquoi l’architecture Client/Serveur ? l Évolution des besoins de l'entreprise  Augmentation de la productivité, rapidité de réactivité souhaitée.  Utilisation des micros assurant "flexibilité et faibles coûts".  Besoin de décisionnel et transactionnel sur gros volumes de données. l Évolution des technologies  Systèmes ouverts permettant l'usage de standards.  Environnements de développement graphiques.  Explosion de la puissance des micros et des serveurs (parallélisme). l Solutions techniques séduisantes  Les données partagées sont (enfin) accessibles simplement.  Mise en commun des services (règles de gestion, procédures).  Gestion de transactions et fiabilité au niveau du serveur.

25 25 D'après G. Gardarin Architecture C&S de 1 ière génération Windows NTUNIX CLIENTS APPLICATIONS REQUETE RESULTAT règles SGBD OS : NT, UNIX, NOVELL OS : GCOS, VMS, MVS APPLICATIONS SERVEUR APPLICATION Données

26 26 D'après G. Gardarin Application Outil Applicatif Outil de connectabilité Protocole Réseau Serveur BD base de données Client Requêtes de services Résultats Serveur Protocole Réseau Outil de connectivité Procédures Stockées Le Client/Serveur de 2 ième génération l Procédure stockée  Procédure accomplissant une fonction de service sur les données  Exemple : entrée ou sortie de stock l Architecture orientée services plutôt que requêtes  Distribution des traitements.  Peut être automatisée. l Évolution et passage à l'échelle  Possibilité de serveurs multiples, avec redondances de la base (lecture)  Possibilité de données privées sur les postes client

27 27 D'après G. Gardarin Intérêt du C/S de 2 ième génération l Réduction des transferts de données sur les réseaux  Non nécessité de charger les données dans le poste client pour les modifier.  Appel de services plus compact. l Distribution automatique des applications  Développement sur le poste de travail.  partitionnement par tirer-déposer (drag & drop). l Simplification des outils de développement  Principe de la fenêtre unique.  Modélisation uniforme des objets applicatifs.  Invisibilité du modèle de données à l'extérieur du serveur.

28 28 D'après G. Gardarin Faiblesses de l’architecture C&S l Une mise en œuvre difficile  Nécessité de disposer de spécialistes réseaux, base de données, PC, stations.  Des outils souvent propriétaires hétérogènes et peu portables (Microsoft).  Des évolutions difficiles. l Des arguments contre  Accroissement des coûts (40% ?), notamment de maintenance.  Des interfaces graphiques hétérogènes (Windows, Motif, Mac).  Des difficultés de passage à l'échelle (dimensionnement, performance).

29 29 D'après G. Gardarin Vers le C/S Universel (3 ième génération) l Intégration du Web et du Client-Serveur  Navigateur à présentation standard pour le poste client.  Possibilité de petites applications (applets) sur le poste client.  Meilleure portabilité (Réseau Privé Virtuel, Intranet, Internet). l Architecture à 3 strates (3-tiered)  Base de données avec procédures stockées.  Services applicatifs partagés.  Présentation hypertexte multimédia avec applets. l Support de l'hypermédia  Types de données variées et extensibles (texte, image, vidéo).  Hypertexte et navigation entre documents et applications.

30 30 D'après G. Gardarin Bilan de l’architecture C/S l Les SGBD actuels fonctionnent tous en architecture Client/Serveur. l Trois niveaux de fonctions sont distinguées :  Données (SGBD),  Application (L4G),  Présentation (Web, Windows, Motif).

31 31 D'après G. Gardarin source: Dataquest Mars 1998 6. Le marché des SGBD l Aujourd’hui 3 leaders  Oracle (UNIX,NT), IBM (DB2), Microsoft (SQL Server sur NT) 1996 1998

32 32 D'après G. Gardarin Source: Gartner Group March 1997 Database Market Share on Windows NT Operating System 5% 15% 25% 35% 45% 199419951996 MSFT SQL Server Oracle Database...... Mais aussi DB2, Informix, … et Sybase Le choix sur NT