SGBD : INTRODUCTION ET ARCHITECTURES 1. Objectifs des SGBD 2. Applications et schémas 3. Définitions 4. Architecture fonctionnelle des SGBD 5. Architectures client-serveur 6. Le marché des SGBD
1. Objectifs des SGBD (1) Garantir l'indépendance des programmes et des données Indépendance physique de la représentation des données et de leur stockage. Des données élémentaires du monde réel sont utilisées pour décrire les objets et les associations entres ces derniers. Le SGBD permet d'en définir une structure naturelle appelée structure canonique. Le schéma interne doit pouvoir être modifié sans induire de modifications du schéma conceptuel. 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. En d'autres termes, le système de gestion de fichiers gère les données sur disque indépendamment du SGBD. Indépendance logique Permet de modifier le schéma externe sans nécessité de modifier le schéma conceptuel. Permet également de modifier les schémas conceptuels et internes des données sans modifier les programmes d'application, donc sans modification des schémas externes. 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. Évite une maintenance coûteuse lors des modifications des structures logiques.
Objectifs des SGBD (2) 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). Efficacité des accès aux données Mesurée par les temps de réponse et le débit global du SGBD. On a défini les benchmarks TPC/A, B, C, D mesurée en TPS (Transactions/S), CPM
Objectifs des SGBD (3) Le support des transactions nécessite les propriétés suivantes (ACID) Atomicité (transaction exécutée complètement ou pas du tout). Cohérence (respect des contraintes d'intégrité) pour protéger la base des mises à jour concurrentes et/ou hors des contraintes. Isolation (non visibilité des mises à jour non commises). Durabilité (garantie des mises à jour commises). Il faut garantir les utilisateurs contres les mises à jour concurrentes et donc garantir le partage et la sécurité des données. Contrôle du nombre maximum d'accès simultanés en lecture/écriture. Gestion des accès transactionnels & décisionnels. Confidentialité (authentification, droits d'accès, cryptage). Restauration après une panne (journalisation, sauvegardes).
Objectifs des SGBD (4) 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 (constitué d'objets de la base, graphiques, applicatifs), description de la spécificité de la base de données d'une entreprise. La sécurité doit être garantie sous toutes ses formes. Outils d'administration Permettre une administration aisée de la base. Audit & optimisation (tunning). Visualisation des plans d'accès à la base. Élaboration de statistiques d'utilisation.
2. Les applications d'un SGBD Caractéristiques OLTP OLAP Opérations typiques Mise à jour Analyse Type d'accès Lecture/Ecriture Lecture Niveau d'analyse Elémentaire Global Ecran Fixe Interactif Quantité d'info échangée Faible Importante Orientation Record Multi-dimensionnel Taille BD 100 MB-GB 1GB - TB Ancienneté des données Récente Récente Historique Future OLTP/OLAP : Objet Langage Transaction/Application Protocol
3. Définitions : les objets Type d'objet (Object type) Ensemble d'objets dotés de propriétés communes sur lesquels opèrent les mêmes opérations. Instance d'objet (Object Instance) Un élément particulier identifiable parmi les objets d'un type donné.
Entité Agrégation (Aggregation) Entité Abstraction consistant à regrouper des objets de base pour constituer des objets composés par une concaténation d'objets. 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. Volnay78 1978 100 Volnay Excellent entité agrégation d'objets élémentaires
Le modèle entité/association Association (Relationship) Lien logique entre deux entités au moins dont le type est défini à partir d'un verbe et d'une liste de propriétés. Attribut Propriété d'une entité ou d'une association caractérisée par un identificateur et un type élémentaire.
Le diagramme entité/association Le diagramme entité/association permet une représentation graphique élégante des schémas de bases de données définis à partir du modèle entité/association. Abus Buveur Vin Nom Type Cru Degré Prénom Date Millésime Adresse Quantité Quantité Qualité
Niveaux d'abstraction : le schéma conceptuel Modèle de description de données Ensemble de concepts et de règles de composition permettant la description des données. Langage de description des données Langage supportant un modèle de description de données et permettant de décrire les données spécifiques d'une base de telle sorte qu'un ordinateur puisse les traiter. 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 à la vision canonique globale de l'entreprise modélisée. C'est la description des entités et des associations du monde réel.
Niveaux d'abstraction : schémas interne et externe 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, des méthodes de stockage et d'accès utilisés pour ranger et accéder à la base sur le disque. C'est donc l'implémentation physique des entités et associations dans les fichiers. 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 vue d'un applicatif ou d'un utilisateur, donc à un arrangement particulier de certaines données.
Exemple Schéma conceptuel Schéma interne Schéma externe (vues-browser) description des entités et des associations du monde réel Schéma interne implémentation physique des entités et associations dans les fichiers Schéma externe (vues-browser) description des entités et associations vues par un utilisateur (ou un groupe d'utilisateurs) Abus Buveurs Vins VINS NV Cru Millésime Index 1 Chablis 1996 2 Volnay 1978 3 Médoc 1984 TOTALBUS NB Nom Total 1 Denis 356 2 Georges 124 3 Cornell 425
4. Architecture fonctionnelle des SGBD Articulée autour du dictionnaire de données. 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. Chacune des parties est constituée des trois niveaux internes, conceptuels et externes.
Architecture ANSI/X3/SPARC d'un SGBD Admin. Entreprise 1 3 3 Admin. Application Admin. BD Processeur de schéma Conceptuel 4 6 2 5 7 Processeur de schéma Externe Processeur de schéma Interne DICTIONNAIRE 14 11 10 Transformateur Interne Stockage Transformateur Conceptuel Interne Transformateur Externe Conceptuel 12 9 Programme d'application Système d'E/S 8 13 Programmeur. d'application
Les interfaces d'accès à un SGBD 1 : LDD format source 2 : LDD conceptuel, format objet ; le (1) compilé 3 : Description conceptuelle des données, 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 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
Premières conclusions Les SGBD doivent assurer la gestion efficace des données partagées et structurées. Trois niveaux de schémas sont y implémentés : conceptuel, interne, externe. Questions Et les fichiers ? Ils sont gérés par le SGF, donc par le système d'exploitation. Certains SGBD peuvent gérer directement ces accès (par exemple Oracle en mode raw).
5. L'architecture Client-Serveur 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. 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.
Pourquoi l'architecture Client/Serveur ? Évolution des besoins de l'entreprise Augmentation de la productivité, rapidité de réactivité souhaitée. Utilisation des micros ordinateurs assurant "flexibilité et faibles coûts". Besoin de décisionnel et transactionnel sur gros volumes de données. É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). 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.
Architecture C&S de 1ière génération SGBD règles OS : NT, UNIX, NOVELL SERVEUR Données OS : GCOS, VMS, MVS REQUETE RESULTAT Windows NT UNIX CLIENTS APPLICATIONS APPLICATIONS APPLICATION
Le Client/Serveur de 2ième génération Procédure stockée Procédure accomplissant une fonction de service sur les données Exemple : entrée ou sortie de stock Architecture orientée services plutôt que requêtes Distribution des traitements. Peut être automatisée. É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 Application Outil Applicatif Client Outil de connectabilité Protocole Réseau Requêtes de services Résultats Protocole Réseau Outil de connectivité Serveur Procédures Stockées Serveur BD base de données
Intérêt du C/S de 2ième génération 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. Distribution automatique des applications Développement sur le poste de travail. Partitionnement par tirer-déposer (drag & drop). 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.
Faiblesses de l'architecture C&S 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. 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).
Vers le C/S Universel (3ième génération) Intégration du Web et du Client-Serveur Navigateur à présentation standard pour le poste client. Possibilité d'exécution de petites applications (applets) sur le poste client. Meilleure portabilité (Réseau Privé Virtuel, Intranet, Internet). 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. Support de l'hypermédia Types de données variées et extensibles (texte, image, vidéo). Hypertexte et navigation entre documents et applications.
Bilan de l'architecture C/S Les SGBD actuels fonctionnent tous en architecture Client/Serveur. Trois niveaux de fonctions sont distinguées : Données (SGBD), Application (L4G), Présentation (Web, Windows, Motif).
6. Le marché des SGBD Aujourd'hui 3 leaders Oracle (UNIX,NT), IBM (DB2), Microsoft (SQL Server sur NT) 1996 1998 source: Dataquest Mars 1998
Source: Gartner Group March 1997 Le choix sur NT . Database Market Share on Windows NT Operating System . . . 45% . MSFT SQL Server 35% Oracle Database 25% . 15% Mais aussi DB2, Informix, … et Sybase 5% 1994 1995 1996 Source: Gartner Group March 1997