Méthode unifiée d’audit des systèmes de gestion de base de données

Méthode unifiée d’audit des systèmes
de gestion de base de données

Généralités sur les bases de données 

Une base de données est un ensemble organisé d’informations avec un objectif commun. Plus précisément, on appelle base de données un ensemble structuré et organisé permettant le stockage de grandes quantités d’informations afin d’en faciliter l’exploitation (ajout, mise à jour, recherche et consultations de données). Ainsi la notion de base de données est généralement couplée à celle des réseaux informatiques afin de pouvoir mettre en commun les informations d’où le nom de « base ». On parle souvent de système d’information pour désigner toute structure regroupant les moyens mis en place pour partager les données. Une base de données doit répondre aux trois critères suivants :  L’exhaustivité : C’est la présence dans cette base de tous les enseignements qui ont trait aux applications en question.  Le non redondance des données : Non répétition d’une donnée plusieurs fois.  La structure : C’est l’adaptation du mode de stockage de données au traitement ; la structuration que la base doit avoir est liée à l’évolution de la technologie. La gestion et l’accès à une base de données sont assurés par un ensemble des programmes et des langages de commande appelé système de gestion de base de données (SGBD). Ce dernier permet de :  Définir des « bases de données », et des relations entre les éléments de chaque base ;  Spécifier le traitement de ces données : interrogations, mises à jour, calculs, extractions… Le SGBD reçoit des commandes aussi bien des programmes d’application que des utilisateurs : il commande les manipulations de données, généralement par l’intermédiaire d’un SGF. Les définitions sont cependant de peu d’intérêt pour déterminer si un système est vraiment un SGBD ou s’il s’agit simplement d’un système d’information classique ou d’un système de fichiers. 10 Méthode unifiée d’audit des systèmes de gestion de base de données

 Les objectifs d’un SGBD 

Pour pallier aux inconvénients des méthodes classiques de gestion de fichiers, les SGBD visent quatre objectifs : intégration et corrélation, flexibilité (indépendance), disponibilité, sécurité. Ces objectifs exigent une distinction nette entre les données et les procédures de manipulation de ces données : aux données, on associera une fonction d’administration des données, aux procédures de manipulation une fonction de programmation. 

Intégration et corrélation

 Dans les systèmes classiques, chaque application gère ses données dans ses propres « fichiers”, d’où : Un risque de redondance, et un danger d’incohérence des données.  La même donnée peut appartenir à plusieurs applications, induisant une déperdition de stockage.  Toute modification de cette donnée est à enregistrer plusieurs fois : si cette mise à jour multiple n’est pas effectuée correctement, les données deviennent incohérentes.  Le coût de la mise à jour augmente du fait de la multiplication des entrées-sorties physiques. Une difficulté pour créer de nouveaux traitements  Les nouvelles applications entraînent des duplications supplémentaires de données.  Leur intégration avec les applicatifs en exploitation entraîne des modifications importantes. Dans l’approche SGBD, un « réservoir » commun (intégration) est constitué, représentant une modélisation (corrélation) aussi fidèle que possible de l’organisation réelle de l’entreprise :  Toutes les applications puisent dans ce réservoir, les données qui les concernent, évitant ainsi les duplications.  Mais le partage des données entre les utilisateurs pose le problème de la synchronisation des accès concurrents. 

Flexibilité ou indépendance 

Dans les systèmes classiques, tout changement intervenant dans le stockage des données (support, méthode d’accès physique) entraîne des modifications lourdes des applications correspondantes. L’approche SGBD poursuit trois objectifs, pour assurer l’indépendance des données par rapport aux traitements : 11 Méthode unifiée d’audit des systèmes de gestion de base de données  Indépendance physique: tout changement de support, de méthode d’accès reste transparent au niveau de l’utilisateur.  Indépendance logique : les programmes d’application sont rendus transparents à une modification dans l’organisation logique globale, par la définition de sous-schémas couvrant les besoins spécifiques en données.  Indépendance vis-à-vis des stratégies d’accès : l’utilisateur n’a plus à prendre en charge l’écriture des procédures d’accès aux données. Il n’a donc pas à intégrer les modifications tendant à optimiser les chemins d’accès (ex: création d’index). 

 Disponibilité 

Le choix d’une approche SGBD ne doit pas se traduire par des temps de traitement plus longs que ceux des systèmes antérieurs. L’utilisateur doit ignorer l’existence d’utilisateurs concurrents. L’aspect « performance » est donc crucial dans la mise en œuvre d’une base de données. Un tel objectif ne peut être atteint que si la conception d’une base de données est menée de façon rigoureuse avec un découpage fonctionnel adéquat. Les règles et contraintes inhérentes sont évoquées lors de l’apprentissage d’une méthodologie d’analyse (exemple MERISE).

Sécurité 

La sécurité des données recouvre deux aspects :  L’intégrité, ou protection contre l’accès invalide (erreurs ou pannes), et contre l’incohérence des données vis-à-vis des contraintes de l’entreprise.  La confidentialité, ou protection contre l’accès non autorisé ou la modification illégale des données. Pour ne pas trop affecter les performances, la sécurité doit également être prise en compte dès la phase de conception. 

Les SGBD relationnels

 Les bases de données relationnelles sont conçues pour fonctionner sur la base de transactions informatiques et doivent respecter les propriétés ACID afin de garantir les propriétés d’une transaction informatique ce qui limite l’approche d’informatique distribuée : 12 Méthode unifiée d’audit des systèmes de gestion de base de données  Atomicity (Atomicité) : la propriété d’atomicité impose que l’ensemble des actions qui composent la transaction soit réalisé ; dans le cas contraire, la transaction est annulée et les données doivent être remises dans leur état initial avant la transaction. L’atomicité doit être respectée pour chaque situation, panne matérielle, ou toute interruption de service inattendue.  Consistency (Cohérence) : Avant et après l’exécution d’une transaction, l’ensemble des données de la base doit passer dans un état valide à un autre état valide ou cohérent. Tout changement de donnée doit répondre aux règles définies de contraintes d’intégrité.  Isolation (Isolation) : Une transaction s’effectue de manière isolée, c’est-à-dire que toute transaction doit s’effectuer comme si elle était seule sur le système. Aucune dépendance entre les transactions.  Durability (Durabilité) : Une transaction réussie est définitive ; c’est-à-dire que lorsqu’une transaction est confirmée, celle-ci est permanente même en cas de panne. 

 Architecture

 Les SGBD relationnels fonctionnent sur une architecture Client-Serveur qui met en œuvre un ou plusieurs ordinateurs (Clients), qui exécutent un programme applicatif, communiquant avec un ordinateur distant (Serveur) qui traite leurs requêtes. Dans ce modèle, la communication des requêtes et des résultats entre le programme applicatif du client et le SGBDR, qui se trouve sur le serveur, est assurée par un réseau informatique. Figure 1: Archietcture des SGBD relationnel 13 Méthode unifiée d’audit des systèmes de gestion de base de données Serveur : On appelle logiciel serveur un programme qui offre un service sur le réseau. Le serveur accepte des requêtes, les traite et renvoie le résultat au demandeur. Le terme serveur s’applique à la machine sur lequel s’exécute le logiciel serveur. (Gère les données partagées et exécute le code du SGBD). Clients : On appelle logiciel client un programme qui utilise le service offert par un serveur. Le client Communiquent avec le serveur envoie une requête et reçoit la réponse. Le client peut être raccordé par une liaison temporaire. 

Avantages et inconvénients  

Avantage :  La technologie est mature (création il y a plusieurs dizaines d’années) ce qui fait qu’aujourd’hui le SQL est un langage standard et normalisé  On a une garantie que les transactions sont atomiques, cohérentes, isolées et durables : principe ACID (Atomic, Consistent, Independant, Durable)  La possibilité de mettre en œuvre des requêtes complexes (croisement multiple des données)  Du fait du nombre d’années d’existence, un large support est disponible et il existe également de fortes communautés  Inconvénients :  La modification du modèle établi peut être couteuse  L’évolutivité des performances est privilégiée de manière verticale (augmentation des ressources du serveur) bien qu’une évolutivité horizontale soit possible, cette dernière reste plus coûteuse (environnement type cluster)  Sur un très grand volume de données (centaines-milliers de Teraoctets) le modèle peut atteindre des limites en termes de performance  Pour certains éditeurs, le prix de licence est élevé 14 Méthode unifiée d’audit des systèmes de gestion de base de données 

 Exemple de solutions  Oracle Database  PostgreSQL  Microsoft SQL Sever  Oracle MySQL

Les SGBD non relationnels 

Tout particulièrement pour les SGBD, le modèle des bases de données relationnelles a été remis en cause par de fortes limitations en matière d’architecture distribuée. Dans ce contexte, de nouveaux paradigmes ont fait évoluer les SGBD. Cette réflexion, qui est basée sur une informatique distribuée, a donné naissance aux moteurs de base de données NoSQL (Not only SQL) Qui commencent à être présent dans les applications d’entreprise au travers plusieurs solutions. 

Architecture

 Nous verrons principalement deux types d’usages pour les moteurs NoSQL : Pour des applications orientées performance : certains moteurs NoSQL ont pour but d’optimiser les performances de manipulation des données, soit en offrant un espace de cache en mémoire intermédiaire lors d’une requête d’un SGBDR, soit en tant que SGBD à part entière. Ces améliorations sont possibles grâce à différents mécanismes :  Utilisation de la mémoire RAM pour stocker les données : la Même Table permet une exécution et manipulation des données directement depuis la mémoire RAM