Site A.T.L.A.N.T.I.C-83
COURS = Initiation aux bases de données (Chapitre_5) - VERSION: 1.0 (M.A.J: 26/11/2017)
- AUTEUR(s): Bernard GIACOMONI
Ecran large mobile
Retour
sommaire cours

V.MODÈLE PHYSIQUE DES DONNÉES:

V.1.PASSAGE DU MODÈLE LOGIQUE A L'IMAGE BINAIRE DE LA BASE DE DONNÉES:

V.1.1.POSITION DU PROBLÈME:

Il s'agit maintenant de créer, à partir du Modèle Logique des Données, l'IMAGE BINAIRE de la base de donnée correspondante sur le support d'archivage choisi (en général, celui-ci est un disque dur). Cette IMAGE BINAIRE va représenter à la fois la STRUCTURE de la base de données (la liste des tables et des champs associés à chacune d'elle, les formats de données, les liens et contraintes, etc.) et l'ETAT de cette base de données (les valeurs à un instant t des différents champs des différentes entrées des tables).

V.1.2.JUSTIFICATION DE L'USAGE D'UN S.G.B.D:

Traduire le MLD, qui est un SCHEMA, donc un objet GRAPHIQUE, sous la forme de STRUCTURES LOGICIELLES représentables en binaire est, bien sûr, une tâche assez complexe qui demande des développements logiciels volumineux. Cependant, une base de données relationnelle, telle qu'elle est représentée par le MLD, peut être décrite en utilisant un nombre limité de types d'objets: tables, attributs, clefs, index, contraintes, etc.). Il est donc possible de développer un ensemble de fonctions logicielles complexes mais peu nombreuses permettant à toute application de créer l'image binaire d'une base de données en invoquant ces fonctions (pour être plus précis, celles-ci pourront réaliser des traitements tels que "créer une table", "ajouter une colonne à une table", "définir une clef étrangère", etc.). C'est un tel ensemble de fonctions qu'un Systèmes de Gestion de Bases de Données offre aux utilisateurs.

V.1.3.PRISE EN COMPTE DES ASPECTS "MULTI-UTILISATEURS ET "RÉSEAU":

Une base de données est, dans la plupart des cas, utilisée par plusieurs applications. Celles-ci ne sont pas forcément hébergées sur la même machine que celle qui gère cette Base de données. Ces applications accèdent donc à celle-ci à travers un réseau informatique. Il n'est donc pas possible à celles-ci de faire des appels "procéduraux" aux fonctions du SGBD. Elles communiquent donc avec le SGBD par des MESSAGES RÉSEAU renfermant des REQUÊTES (par exemple, des requêtes SQL). Un interpréteur permet au SGBD de traduire les requêtes envoyées par les utilisateurs en actions sur l'image binaire de la base de données:

V.1.4.ARCHITECTURE PHYSIQUE GÉNÉRALE:

Le schéma ci-dessous détaille les principaux constituants de l'environnement physique d'utilisation d'une base de données:
Menu de commande de l'animations

Relations entre applicatif, SGBD et base de données
COMMENTAIRES:
  • D'un point de vue strictement PHYSIQUE, une base de données se présente comme un ensemble de fichiers hébergés sur un support de masse;
  • Le contenu de ces fichiers décrit sous forme binaire la structure et le contenu de la base de données;
  • L'ensemble de ces données constitue l'IMAGE BINAIRE de la base de données à un instant donné;
  • La base de données est exploité par des applications utilisatrices. Celles-ci ne sont en général pas hébergées par la machine qui gère le support d'enregistrement de la BD.
  • De ce fait, ces applications doivent communiquer avec cette machine par l'intermédiaire de REQUÊTES acheminées sur le réseau informatique vers le SGBD et des COMPTES-RENDUS DE REQUÊTES émis par le SGBD sur ce même réseau;
  • Les requêtes sont interprétées par le Système de Gestion de Bases de Données qui gère la base de données concernée et transformées en ACTIONS sur l'image binaire de cette BD (modifications de la structure ou du contenu);
  • Le SGBD se charge également de retourner aux utilisateurs les comptes-rendus d'exécution des requêtes, et en particulier les données extraites de la base de données;
  • Le schéma ci-dessus indique qu'un utilisateur du SGBD peut être soit une application, sont un opérateur humain dialoguant avec le SGBD par l'intermédiaire d'un interface homme-machine (IHM). Dans les deux cas, la communication se fait par envoi de requêtes. Le plus souvent, l'IHM fait physiquement partie du SGBD.


V.2.LA NOTION DE MODÈLE PHYSIQUE DES DONNÉES:

Alors que les notions de modèle conceptuel et de modèle logique sont bien identifiées dans la littérature spécialisée (il s'agit de constructions intellectuelles que l'on peut représenter par des graphiques), la plupart des auteurs définissent le modèle physique comme "l'implantation du modèle logique dans un Système de Gestion de Bases de Données", ce qui est beaucoup moins précis: s'agit-il de l'image binaire de la BD sur son support d'archivage, de la traduction du MLD en langage de requêtes ou bien d'autre chose?
Comme l'idée de MODÈLE suggère plus la description d'un objet que l'objet lui-même, nous choisirons dans le cadre de ce document de définir le MPD comme l'ensemble des REQUÊTES qu'il faut envoyer au SGBD pour que celui-ci crée effectivement l'image binaire de la base de données décrite par le modèle logique. Défini ainsi, le modèle physique des données peut donc être assimilé à un PROGRAMME (ou un fragment de programme) écrit dans un langage accepté par le SGBD et dont l'exécution par celui-ci provoque la CRÉATION de la base de données.
Pour illustrer ce qui précède, voici une partie du modèle physique de la base de données BIBLIOTHÈQUE étudiée précédemment, programmé en langage SQL:
	CREATE DATABASE IF NOT EXISTS `bibliotheque` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
	USE `bibliotheque`;
	
	CREATE TABLE IF NOT EXISTS `abonnes` 
	(
		`id_ab` int(8) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Id. des abonnés',
		`nom_ab` varchar(100) NOT NULL COMMENT 'nom de l''abonné',
		`prenoms_ab` varchar(100) NOT NULL COMMENT 'prénoms de l''abonné, séparés par des virgules',
		`adresse_postale_ab` varchar(255) NOT NULL COMMENT 'adresse postale de l''abonné',
		`e_mail_ab` varchar(30) NOT NULL COMMENT 'adresse e_mail de l''abonné',
		`telephone_ab` int(30) NOT NULL COMMENT 'numéro de téléphone de l''abonné',
		PRIMARY KEY (`id_ab`)
	) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Table des abonnée' AUTO_INCREMENT=1 ;

	CREATE TABLE IF NOT EXISTS `auteurs` 
	(
		`id_au` int(8) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Clef auteurs',
		`nom_au` varchar(100) NOT NULL COMMENT 'Nom de l''auteur',
		`prenoms_au` varchar(100) NOT NULL COMMENT 'prénoms de l''auteur, séparés par des virgules',
		`biographie_au` text NOT NULL COMMENT 'biographie de l''auteur', 
		PRIMARY KEY (`id_au`)
	) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='Table des auteurs' AUTO_INCREMENT=1 ;
			
Dans ce fragment de code, nous pouvons distinguer quatre requêtes SQL: la requête CREATE DATABASE qui permet de déclarer la création d'une nouvelle base de données (bibliothèque), la requête USE qui permet de déclarer que les requêtes qui suivent s'adressent à cette nouvelle base de données et les deux requêtes CREATE TABLE qui permettent de définir les tables abonnés et auteurs ainsi que leurs attributs et d'autres caractéristiques comme leurs clefs primaires ou le type de moteur de base de données à utiliser (directives ENGINE=InnoDB).
NOTA:Ce fragment de code est donné uniquement pour permettre au lecteur de "matérialiser" ce qu'est un modèle physique de données du point de vue informatique: le langage SQL sera étudié plus loin.


V.3.PROBLÉMATIQUES DE LA GESTION DYNAMIQUE DES BASES DE DONNÉES PAR LES APPLICATIONS:

La gestion dynamique d'une base de données présente diverses contraintes et caractéristiques qui sont prises en compte par les systèmes de gestion des bases de données:

V.3.1.COORDINATION ET SÉCURISATION DES ACCES:

Comme nous l'avons vu précédemment, une base de données a en général de nombreux utilisateurs qui n'ont pas forcément de rapports entre eux (par exemple, une base de données incluse dans un Système d'Information d'entreprise pourra être utilisée par le service ressources humaines, mais aussi par la sécurité ou certains services commerciaux: les accès de ces différents services ne sont absolument pas coordonnés temporellement). Ces utilisateurs interrogent cette base de données à travers un Réseau informatique (public ou privé). De ce fait:
  • D'une part, les demandes des différents utilisateurs ne pouvant être coordonnées dans le temps, le volume du flux à traiter est totalement aléatoire;
  • D'autre part, pour éviter toute perte de données ou de cohérence de ces données, dûs à des accès intempestifs ou malveillants, les droits des différents utilisateurs doivent être contrôlés.
Pour résoudre ces problèmes, les bases de données sont dans la plupart des cas gérées par un SGBD encapsulé dans un SERVEURS. L'accès à ce SGBD est donc de type CLIENT-SERVEUR et l'accès contrôlé par un couple "identificateur-mot de passe".

V.3.2.GESTION DE LA CONCURRENCE DES ACCES:

En général, une base de données peut être utilisée SIMULTANÉMENT et CONCURREMMENT par plusieurs utilisateurs (clients). Comme le traitement de chaque requête exige un certain temps, les requêtes de ces différents clients entrent fatalement en concurrence pour l'accès à la base de données. Par exemple, un site web marchand peut être amené à traiter simultanément des demandes d'achats de très nombreux clients portant sur le même article: la gestion de cette concurrence d'accès doit donc être traitée avec beaucoup de rigueur pour éviter toute "collision" génératrice d'incohérence dans les valeurs stockées dans la base.
Les SGBD prennent en charge la gestion de cette concurrence et en dipensent donc les applications utilisatrices.

V.3.3.EVOLUTION DE LA STRUCTURE D'UNE BASE DE DONNÉES:

Rien n'empêche de modifier d'une manière permanente la structure d'une base de données après sa création (ajouter, supprimer une table ou une colonne, modifier les paramêtres généraux, ajouter ou supprimer des contraintes, etc.). Cependant, il ne faut pas oublier qu'une base de données gérée par un SGBD est une ressource qui peut être PARTAGÉE entre plusieurs UTILISATEURS: une telle modification de structure peut donc impliquer une évolution chez tous ces utilisateurs. La modification de la STRUCTURE d'une base de données n'est donc pas une opération banale: elle intervient plutôt dans le cadre d'un changement de version du système d'information.
On peut donc distinguer plusieurs phases dans la gestion d'une base de données:
  • La phase de CRÉATION, qui permet d'implanter sur le support de données les fichiers représentant la structure et le contenu de la base de données à l'état INITIAL, au moyen des requêtes représentant le Modèle Physique des Données;
  • Les phases d'EXPLOITATION, pendant lesquelles les différentes applications utilisatrices vont GÉRER DYNAMIQUEMENT le CONTENU des tables (lecture, écriture de données dans les tables), par l'envoi de requêtes au SGBD et l'exploitation des comptes-rendus de ces requêtes.
  • Les phases de CHANGEMENT DE VERSION de la base de données qui correspondent à des modifications de la structure destinées à accompagner les évolutions du système d'information (par exemple, ajout d'une colonne "pays" dans une table "clients" pour prendre en compte les clients de l'entreprise domiciliés à l'étranger.
REMARQUE: Certaines requêtes peuvent amener la création TEMPORAIRE de tables (c'est le cas par exemple pour les opérations de JOINTURE) mais ces tables ne "survivent" pas à l'exécution de la requête qui les a créées.


V.4.COMPOSANTS LOGICIELS DES SYSTÈMES DE GESTION DE BASES DE DONNÉES:

V.4.1.GÉNÉRALITÉS:

Du point de vue informatique, un SGBD relationnel est un LOGICIEL qui met à disposition d'utilisateurs un certain nombre de fonctions qui permettent à ces utilisateurs de créer et modifier la structures et le contenu des bases de données que ce SGBD gère ou encore de récupérer sélectivement les valeurs des données contenues dans les tables constituant ces bases de données. Ces utilisateurs peuvent être:
  • Soit des APPLICATION INFORMATIQUE (programmes utilisateurs), qui communiquent avec le SGBD par l'intermédiaire d'une INTERFACE DE PROGRAMMATION (ou Application Programming Interface-API);
  • Soit des OPÉRATEUR HUMAIN qui communiquent avec le SGBD soit par des COMMANDES EN LIGNE, soit par l'intermédiaire d'un INTERFACE HOMME-MACHINE (IHM) graphique.
Les SGBD les plus répandus (MySQL, ORACLE, SQL SERVER, POSTGRE, etc.) intègrent un IHM graphique qui permet aux utilisateur de créer, modifier, détruire "manuellement" les bases de données par l'intermédiaires de formulaires. Ces IHM offrent également de saisir des commandes en ligne (requêtes de gestion).
En revanche, l'API dépend à la fois du SGBD et du langage utilisé par l'application informatique utilisatrice. Pour un même SGBD, on aura donc une API pour le langage C, un autre pour JAVA, etc. De ce fait, les API ne sont pas intégrées au SGBD.
Schéma général SGBD-BD
COMMENTAIRES:
Le schéma ci-dessus représente les différents éléments qui composent un système de gestion de bases de données: son MOTEUR DE BASE DE DONNÉES et son Interface Homme Machine (IHM) de gestion) ainsi que les composants matériels et logiciels qui travaillent en relation avec lui: l'interface de programmation(API) qui permet aux logiciels d'utiliser ses services, le poste de travail par lequel des administrateurs peuvent gérer "manuellement" les bases de données et le support d'archivage des fichiers composant la BD (ici, un disque dur).
  • Le MOTEUR DE BASE DE DONNÉES regroupe toutes les fonctions du logiciel SGBD qui permettent d'accéder à la structure et aux données de la base de données. Il interprête les requêtes transmises par les utilisateurs, effectue les actions correspondantes sur la structure et le contenu de la BD et retourne vers les utilisateurs les données ou comptes-rendus d'action correspondant aux requêtes traitées;
  • L'IHM interne du SGBD permet à un OPÉRATEUR HUMAIN d'administrer les bases de données à partir de FORMULAIRES: il transforme les commandes et données saisies par l'opérateur en requêtes qu'il envoie au moteur de base de données et affiche les résultats de ces requêtes;
  • L'API (Application Programming Interface - Interface de programmation) est une bibliothèque de fonctions qui permet à un LOGICIEL D'APPLICATION de transmettre des requêtes au moteur de bases de données et de récupérer les données ou comptes-rendus correspondants.

V.4.2.LES INTERFACES DE PROGRAMMATION DES BASES DE DONNÉES:

Comme il a été dit plus haut, ces interfaces sont des bibliothèque de fonctions qui permettent à un LOGICIEL D'APPLICATION de transmettre des requêtes au moteur de bases de données et de récupérer les données ou comptes-rendus correspondants. L'API dépend du SGBD et du langage de l'application: par exemple, si l'application est écrite en PHP et si le SGBD utilise SQL, il faudra utiliser l'API MYSQL du langage PHP.
Schéma de la relation entre API et SGBD-BD

V.4.3.LES INTERFACES HOMME-MACHINE DES SGBD:

GÉNÉRALITÉS:

Ces I.H.M sont, en général, intégrés à la fourniture du SGBD. Ils offrent un interface graphique qui permet de créer des bases de données relationnelles et d'en gérer le contenu. Les principales fonctions supportées sont:
  • La création ou la suppression d'une BASE DE DONNÉES, la définition et la modification de ses paramètres généraux;
  • La création ou la suppression d'une TABLE, la définition et la modification de ses paramètres généraux;
  • La gestion du CONTENU D'UNE TABLE : ajout ou suppression d'entrées, définition, modification des types et des contenus des champs, ajout, modification, suppression de champs, définition de clefs primaires et d'index, etc.
  • La définition, la modification ou la suppression de CONTRAINTES ENTRE LES ENTRÉES DE TABLES (clefs étrangères);
  • La consultation des données contenues dans les champs des tables;
  • La sauvegarde totale ou partielle des bases de données gérées par le SGBD sous la forme de fichiers de textes de différents formats (la sauvegarde peut concerner toutes les bases de données ou seulement une, ou une table en particulier);
  • La réinstallation de bases de données ou de tables dans un SGBD à partir de leur fichier de sauvegarde
  • Différentes fonctions de tri des entrées des tables
  • Etc.
Ces différentes actions peuvent être effectuées par l'intermédiaires de FORMULAIRES GRAPHIQUES. La validation de ces formulaires entraîne l'émission vers le moteur de base de données des requêtes correspondant au contenu du formulaire validé.
En général, les IHM permettent également de saisir directement les requêtes à adresser au moteur de base de données.

EXEMPLE - L'IHM DE MYSQL:

A titre d'exemple, quatre formulaires de l'IHM MySQL sont décrits ci-après: ils permettent de créer, modifier ou supprimer une base de données. L'étude de ces quatre formulaires (les plus importants de l'IHM), dans l'ordre où elle est effectuée permet de suivre la procédure de création d'une base de données (avec définition des tables et des attributs de ces tables) par l'intermédiaire de l'IHM MYSQL, permet de suivre la procédure de création d'une base de données en mode "manuel". Le lecteur pourra expérimenter ces manipulations en installant le logiciel libreLAMP LAMP (sur un système UNIX) ou le logiciel WAMP (sur un système WINDOW). L'installation (très facile) de ces logiciels permet de disposer en local d'un serveur APACHE muni d'un SGBD MySQL avec un IHM qui supporte les formulaires en question.
PREMIER FORMULAIRE:
Le premier formulaire s'affiche lorsqu'un utilisateur se connecte à la base de données:
Menu de commande de l'animations

IHM MySQL: Formulaire d'accueil
COMMENTAIRES:
  • La liste qui apparaît dans la partie gauche représente les différentes bases de données gérées par le SGBD: dans cette liste, on remarque une base de donnée nommée "bibliothèque";
  • Le bandeau supérieur de la partie droite donne accès à différentes fonctions: bases de données (créer, supprimer ou modifier les privilèges d'accès, importer ou exporter (sauvegarder toutes les bd sous forme de fichiers textes ou les réinstaller à partir de ces fichiers, fixer des paramètres généraux, etc;
  • En dessous du bandeau supérieur apparaîssent des zones qui permettent de fixer certains paramètres généraux ou de gérer le mot de passe d'accès au SGBD.
DEUXIEME FORMULAIRE:
Le deuxième formulaire s'affiche lorsqu'un utilisateur active le bouton "bases de données" du premier formulaire:
Menu de commande de l'animations

IHM MySQL: Formulaire de gestion des bases de données
COMMENTAIRES:
  • Ce formulaire permet de créer une nouvelle base de données, de supprimer une base de données existante ou de gérer les privilèges d'accès;
  • La sélection d'une base de données par un double clic danss la liste de gauche ou celle de droite permet d'afficher le troisième formulaire.
TROISIEME FORMULAIRE:
Le troisième formulaire s'affiche lorsqu'un utilisateur sélectionne une base de données dans le deuxième formulaire:
Menu de commande de l'animations

IHM MySQL: Formulaire de gestion d'une base de données
COMMENTAIRES:
  • La liste apparaîssant dans la partie gauche représente les différentes bases de données gérées par le SGBD: dans cette liste, on voir apparaître un base de donnée nommée "bibliothèque";
  • La sélection d'une de ces bases de données fait apparaître dans la partie droite du formulaire la liste des différentes tables composant cette base de donnée. Dans l'exemple ci-dessus, nous avons sélectionné la base de données "bibliothèque". De ce fait, nous avons dans la partie droite des lignes qui correspondent aux tables de cette base: abonnés, auteurs, auteurs-livres, etc. Ce sont les tables définies dans le MLD de la bibliothèque étudié précédemment;
  • La liste des tables est surmontées d'un bandeau permettant de choisir un certain nombre d'options d'affichage ou de gestion. Les fonctions importer et exporter s'adressent à la base de données si aucune table n'est sélectionnée ou la table sélectionnée s'il en existe une;
  • Chacune des lignes correspondant aux tables de la BD sélectionnée met à disposition des utilisateurs des fonctions de gestion de la table correspondante: Afficher (le contenu de la table), Structure (afficher la structure de la table), Rechercher (une entrée particulière), Insérer (une entrée), Vider (le contenu de la table), Supprimer (la table);
  • En bas de la partie de droite, trois champs de saisie permettent de créer une nouvelle table;
QUATRIEME FORMULAIRE:
Sélectionnons alors dans la partie droite du troisième formulaire et dans la ligne correspondant à la table "auteurs", l'option "structure": la structure de la table "auteurs" s'affiche alors dans la partie droite:
Menu de commande de l'animations

IHM MySQL: Formulaire de gestion d'une table
COMMENTAIRES:
  • La liste apparaîssant dans la partie gauche représente toujours les différentes bases de données gérées par le SGBD;
  • Dans cette liste, on a sélectionné la base de données "bibliothèque", puis on a sélectionné, dans la ligne corresondant à la table "auteurs", l'option "structure": la description des attributs de la table s'affiche alors;
  • Nous voyons ainsi apparaître les lignes correspondant aux attributs de la table "auteurs": id_au, nom_au, prenoms_au, biographie_au
  • Ces lignes affichent les propriétés de ces attributs (format, interclassement, auto-incrémentation, etc.);
  • Elles affichent aussi des fonctions de gestion de l'attribut: modifier (le format), supprimer, déclarer l'attribut clef primaire, etc.
  • La fonction "ajouter" permet d'ajouter un nouvel attribut (une nouvelle colonne) à la table;
  • Ces quatre formulaires que nous venons d'étudier permettent donc de définir entièrement une base de données.



Retour accès aux cours Retour sommaire cours
FormateurGaucheRepos FormateurGaucheActif FormateurDroitRepos FormateurDroitActif