sgbd - Free

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
‹#›
D'après G. Gardarin
1. Objectifs des SGBD (1)

Assurer l'indépendance des programmes par rapport aux
données.
 Indépendance physique de la représentation et du stockage des
données.





‹#›
Les données élémentaires du monde réel sont assemblées pour décrire les objets et les
associations entres ces derniers.
Le SGBD permet de décrire une structure naturelle (ou canonique) des données.
Le schéma interne doit pouvoir être modifié sans induire des modification 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'autre terme, le système de gestion de fichiers gère les données sur disque
indépendamment du SGBD.
D'après G. Gardarin
Objectifs des SGBD (2)

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'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.
‹#›
D'après G. Gardarin
Objectifs des SGBD (3)

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
 Temps de réponse & débit global
 Benchmarks TPC/A, B, C, D ==> TPS (Transactions/s), CPM
‹#›
D'après G. Gardarin
Objectifs des SGBD (4)

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).

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).
‹#›
D'après G. Gardarin
Objectifs des SGBD (5)

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.


La sécurité doit être garantie sous toutes ses formes.
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.
D'après G. Gardarin
2. Les applications d'un SGBD
Caractéristiques
OLTP
OLAP
Opérations typiques
Type d'accès
Niveau d'analyse
Ecran
Quantité d'info échangée
Orientation
Taille BD
Ancienneté des données
Mise à jour
Lecture/Ecriture
Elémentaire
Fixe
Faible
Record
100 MB-GB
Récente
Analyse
Lecture
Global
Interactif
Importante
Multi-dimensionnel
1GB - TB
Récente Historique
Future
OLTP/OLAP : Objet Langage Transaction/Application Protocol
‹#›
D'après G. Gardarin
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 objet particulier identifiable parmi les objets d'un type donné.
‹#›
D'après G. Gardarin
Définitions : modèles et schéma

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.

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.

Description à partir d'un langage déterminé d'un ensemble
de données spécifiques.
‹#›
D'après G. Gardarin
Niveaux d'abstraction : le schéma conceptuel

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.

C'est la description des entités et des associations du
monde réel.
‹#›
D'après G. Gardarin
Niveaux d'abstraction : le schéma interne

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.

C'est l'implémentation physique des entités et associations
dans les fichiers.
‹#›
D'après G. Gardarin
Niveaux d'abstraction : le schéma externe

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.
‹#›
D'après G. Gardarin
Exemple

Schéma conceptuel
 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
1
Chablis
2
Volnay
1996
1978
3
Médoc
1984
TOTALBUS
NB
Nom
Total
1
Denis
2
Georges
356
124
3
Cornell
425
D'après G. Gardarin
Le modèle entité/association

Agrégation (Aggregation)
 Abstraction consistant à grouper des objets de base pour
constituer des objets composés d'une concaténation d'objets
composants.

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.
‹#›
D'après G. Gardarin
Le modèle entité/association
Volnay78
Volnay
1978
Excellent
100
Exemple d'agrégation de valeurs
‹#›
D'après G. Gardarin
Le modèle entité/association

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.

Attribut
 Propriété d'un entité ou d'une association caractérisée par un
identificateur et un type élémentaire.
‹#›
D'après G. Gardarin
Le diagramme entité/association

Le modèle entité/association permet une représentation
graphique élégante des schémas de bases de données.
Abus
Buveur
Nom
Vin
Type
Cru
Prénom
Adresse
Quantité
Date
Millésime
Qualité
‹#›
Degré
Quantité
D'après G. Gardarin
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.
‹#›
D'après G. Gardarin
Architecture ANSI/X3/SPARC
Admin.
Entreprise
3
Admin.
BD
6
7
Processeur
de schéma
Interne
Processeur
de schéma
Conceptuel
2
3
5
DICTIONNAIRE
Admin.
Application
4
Processeur
de schéma
Externe
14
Transformateur
Interne
Stockage
12
11
Transformateur
Conceptuel
Interne
10
Transformateur
Externe
Conceptuel
9
Système
Programme
d’E/S
d’application
13
‹#›
1
8
Programmeur.
d’application
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
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
‹#›
D'après G. Gardarin
Premières conclusions


Les SGBD assurent la gestion efficaces des données partagées et
structurées
Trois niveaux de schémas implémentés :
 conceptuel,
 interne,
 externe,

Questions
 Et les fichiers ?
‹#›
D'après G. Gardarin
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.
D'après G. Gardarin
Pourquoi l’architecture Client/Serveur ?

É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.

É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.
‹#›
D'après G. Gardarin
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
APPLICATION
‹#›
NT
APPLICATIONS
UNIX
CLIENTS
APPLICATIONS
D'après G. Gardarin
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
l'échelle
et
passage
Outil Applicatif
Client
Outil de connectabilité
Protocole Réseau
Requêtes de services
Résultats
à
 Possibilité de serveurs multiples, avec
redondances de la base (lecture)
 Possibilité de données privées sur les
postes client
‹#›
Application
Protocole Réseau
Outil de connectivité
Serveur BD
Procédures
Stockées
base de données
D'après G. Gardarin
Serveur
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.
‹#›
D'après G. Gardarin
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).
‹#›
D'après G. Gardarin
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é 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.
‹#›
D'après G. Gardarin
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).
‹#›
D'après G. Gardarin
6. Le marché des SGBD

Aujourd’hui 3 leaders
 Oracle (UNIX,NT), IBM (DB2), Microsoft (SQL Server sur NT)
O ra c le
24
2 4 ,9
IB M
M ic ro s o ft
S y bas e
6 ,1
5 ,7
2 7 ,2
1 2 ,1
27,5
4,4
Sybase
4,5
14,9
27,2
1998
source: Dataquest Mars 1998
‹#›
IBM
Microsoft
In fo rm ix
A u tre s
1996
Oracle
21,5
D'après G. Gardarin
Informix
Autres
Le choix sur NT
Database Market Share on Windows NT Operating System
.
45%
35%
25%
15%
.
.
..
MSFT SQL Server
Oracle Database
.
5%
1994
Mais aussi DB2, Informix,
… et Sybase
1995
1996
Source: Gartner Group March 1997
‹#›
D'après G. Gardarin