PROPRIETES D’UN SGBD RELATIONNEL

PROPRIETES D’UN SGBD RELATIONNEL

Langage SQL

SQL (Structured Query Language) a été créé au début dans les années 1970 par la société américaine IBM (International Business Machines) et sa première version commercialisable a vu le jour en 1979. Depuis il a été repris par le groupe ORACLE qui a lancé son premier SGBD Relationnel et a été normalisé par l’Institut de normalisation américaine ANSI en 1986 et ratifié par l’Organisation internationale de normalisation ISO en 1987 [5]. Le langage SQL peut être considéré comme le langage d’accès normalisé aux bases de données. Il est aujourd’hui supporté par la plupart des produits commerciaux que ce soit par les systèmes de gestion de bases de données micro tel qu’Access ou par les produits plus professionnels tels qu’Oracle. Il a fait l’objet de plusieurs normes ANSI/ISO dont la dernière est la norme SQL3 qui a été définie en 1999, et qui a subi plusieurs révisions dont la plus récente date de 2011.

Le succès du langage SQL est dû essentiellement à sa simplicité et au fait qu’il s’appuie sur le schéma conceptuel pour énoncer des requêtes en laissant le SGBD responsable de la stratégie d’exécution. SQL est un langage déclaratif qui permet d’interroger une base de données sans se soucier de la représentation interne (physique) des données, de leur localisation, des chemins d’accès ou des algorithmes nécessaires. A ce titre il s’adresse à une large communauté d’utilisateurs potentiels (pas seulement des informaticiens) et constitue un des atouts les plus spectaculaires des SGBDR [6]. Néanmoins, le langage SQL ne possède pas la puissance d’un langage de programmation : entrées/sorties, instructions conditionnelles, boucles et affectations. Pour certains traitements il est donc nécessaire de coupler le langage SQL avec un langage de programmation plus complet [7].

Bases de données NoSQL

Après avoir exposé les bases de données relationnelles dans le chapitre précédent, et montrer les limites de ce type surtout dans des environnements distribués et a forte charges, nous établirons dans ce chapitre un état de l’art sur les nouveaux systèmes dites NoSQL. Les systèmes NoSQL viennent pour garantir certains critères que les bases de données classiques ont montré des faiblesses. Nous allons voir leur émergence, leurs différents types et nous allons montrer leur utilité face aux nouvelles exigences ainsi un bref aperçu des solutions NoSQL disponibles actuellement sur le marché. Bien que le terme NoSQL soit entendu pour la première fois en 1988 par Carlo Strozzi qui présentait ça comme un modèle de base de donnée plus léger et sans interface SQL, c’est en 2009, lors de la rencontre NoSQL de San Francisco, qu’il prend un essor important. Durant cette conférence, les développeurs ont présenté des projets tels que Voldemort, Cassandra Project, Dynomite, HBase, Hypertable, CouchDB, MongoDB. Cette conférence était considérée comme l’inauguration de la communauté des développeurs de logiciel NoSQL [11]. NoSQL est une combinaison de deux mots : No et SQL. Qui pourrait être mal interprétée car l’on pourrait penser que cela signifie la fin du langage SQL et qu’on ne devrait donc plus l’utiliser. En fait, le « No » est un acronyme qui signifie « Not only », c’est-à-dire en français « non seulement », c’est donc une manière de dire qu’il y a autre chose que les bases de données relationnelles [12].

EMERGENCE DU NOSQL

Avec l’augmentation de la bande passante sur internet, ainsi que la diminution des coûts des matériels informatiques, de nouvelles possibilités ont vu le jour dans le domaine de l’informatique distribuée. Le passage au 21ème siècle par la révolution du WEB 2.0 a vu le volume de données augmenter considérablement. Ces données proviennent essentiellement de réseaux sociaux, base de données médicales, indicateurs économiques, etc. La gestion de ces volumes de données est donc devenue un problème que les bases de données relationnelles n’ont plus été en mesure de gérer. Le NoSQL. regroupe donc de nombreuses bases de données qui ne se reposent donc plus sur une logique de représentation relationnelle. Il n’est toutefois pas simple de définir explicitement ce qu’est une base de données NoSQL étant donné qu’aucune norme n’a encore été instaurée. Le besoin fondamental auquel répond le NoSQL est la performance. Afin de résoudre les problèmes liés à la gestion de grandes quantités de donnée « Big data », les systèmes NoSQL sont optimisés pour la scalabilité horizontale. Un autre aspect important du NoSQL est qu’il répond au théorème de CAP qui est plus adapté pour les systèmes distribués. Servant à manipuler de gros volumes de données, il est donc destiné aux grandes entreprises. Dès 2010, le NoSQL a commencé à s’étendre vers les plus petites entreprises n’ayant pas les moyens d’acquérir des licences Oracle qui ont donc développé leurs propres SGBD en imitant les produits Google et Amazon [11].

Modèle de données

Le modèle relationnel est basé est sur un modèle mathématique qui est celui de la notion des ensembles. Chaque ensemble ici est représenté par une table, et ces attributs sont quant à eux représentés par des colonnes. L’un des principes fondamentaux est justement cette notion de relation entre tables à l’aide de cardinalités, clés primaires et clé étrangères, ceci implique au préalable une étude minutieuse sur la modélisation du schéma de la base de données pour identifier les tables dont le système aura besoin, ses attributs, les relations possibles entre différentes tables, etc. Une fois ce modèle mis en place dans un SGBD Relationnel, il est difficile de changer la structure de celui-ci et ceci pose par conséquent des problèmes lors de sa réingénierie. Le mouvement NoSQL lui est plus pragmatique, basé sur des besoins de stockage de données ainsi qu’une liaison plus forte avec les différents langages clients. La plupart des moteurs de base de données NoSQL n’utilisent pas de schémas prédéfinis à l’avance, d’où l’appellation « schema-less », ce qui signifie sans schéma. Ainsi le moteur de la base de données n’effectue pas de vérification et n’impose pas de contrainte de schéma, les données étant organisées du coté code de client. Toutefois le principe « schema-less » est théorique et ne se vérifie pas entièrement en pratique. Le maintien d’une structure de données homogènes est important, pour des questions d’indexation, de recherche par critère ou tout simplement pour des raisons de logique.

Gestion de la valeur NULL

En SQL, lors de la définition d’une table, il est possible de décider si un attribut peut contenir une valeur ou non lors de l’enregistrement d’un tuple en définissant la colonne à «Null» ou «Not Null». Ceci est utile pour contraindre l’utilisateur à renseigner sur certains attributs que l’administrateur de la base de données considère comme indispensables. Cela dit, dû au fait de sa représentation en deux dimensions (ligne, colonne) et de sa rigidité dans sa structure, il est indispensable de signaler l’absence de valeur à l’aide d’un marqueur Null, ce qui coûte en espace mémoire. Un autre souci du Null est sa gestion dans le langage SQL. Etant donné que le Null n’est pas une valeur, il ne peut donc pas être comparable. En voici une illustration avec la clause «WHERE» : L’exemple ci-dessus démontre qu’il faut explicitement citer la valeur Null dans la requête. En effet, le test sur une valeur Null ne retourne pas TRUE ou FALSE mais la valeur UNKNOW. Dans nos 2 premiers tests il va donc sélectionner les produits qui répondront TRUE à leur requête respective. Dans le troisième test il faut explicitement signaler une valeur Null possible pour que la valeur Null soit prise en considération. Dans des bases de données NoSQL il n’y a pas une gestion spécifique du Null, étant donné que dans des bases de type document ou clé-valeur la notion de schéma n’existe pas, si l’on veut exprimer qu’un attribut n’a pas de valeur il suffit de ne pas le mettre. Même chose dans les bases de type colonne, les colonnes étant dynamiques, elles ne seront présentes qu’en cas de nécessité.

Bases de données orientées colonnes

Les bases de données orientées colonnes ont été conçues par les géants du web afin de faire face à la gestion et au traitement de gros volumes de données s’amplifiant rapidement de jours en jours. Elles intègrent souvent un système de requêtes minimalistes proche du SQL. Bien qu’elles soient abondamment utilisées, il n’existe pas encore de méthode officielle ni de règles définies pour qu’une base de données orientée colonnes soit qualifiée de qualité ou non. Les bases de données orientées colonnes ne diffèrent pas beaucoup des bases SQL classique du point de vue architectural. La principale différence est la façon dont les données sont stockées en mémoire : dans une base de données relationnelles les données sont stockées par ligne, de ce fait une requête portant sur peu de lignes mais beaucoup de colonnes sera rapide car le système n’aura pas à beaucoup se déplacer en mémoire, alors que dans une base orientée colonnes les données sont stockées par colonnes, de ce fait le système sera beaucoup plus rapide de parcourir les lignes d’une table. Concrètement cela signifie que, contrairement aux bases orientées lignes, les utilisateurs qui souhaitent des informations précises n’auront pas à s’encombrer des informations inutiles des autres colonnes. En effet les bases orientées lignes se doivent de lire entièrement les lignes avant de sélectionner les colonnes désirées par la requête.

Ce type de structure permet d’être plus évolutif et flexible ; cela vient du fait qu’on peut ajouter à tout moment une colonne ou une super-colonne (une super-colonne est une colonne contenant d’autres colonnes) à n’importe quelle famille de colonnes. Autrement dit, et contrairement à une base de données relationnelle ou les colonnes sont statiques et présentes pour chaque ligne, celles des bases de données orientée colonnes sont dite dynamiques et présentes donc uniquement en cas de nécessité. De plus le stockage d’un « Null » est inexistant. Prenons l’exemple de l’enregistrement d’un client nécessitant son nom, prénom et adresse. Dans une base de données relationnelle il faut donc au préalable créer le schéma (la table) qui permettra de stocker ces informations. Si un client n’a pas d’adresse, la rigidité du modèle relationnel nécessite un marqueur Null, signifiant une absence de valeur qui coûtera toutefois de la place en mémoire. Dans une base de données orientée colonne, la colonne adresse n’existera tout simplement pas [16].

Table des matières

INTRODUCTION GENERALE
CHAPITRE 1 : Bases de données relationnelles et leurs limites
1.INTRODUCTION
2.DEFINITIONS ET CONCEPTS DE BASES
2.1 Définition d’une base de données
2.2 Définition d’un système de gestion de base de données
3.OBJECTIFS DES SGBD
3.1 Administration facilitée des données
3.2 Efficacité des accès aux données …
3.3 Redondance contrôlée des données
3.4 Cohérence des données
3.5 Partage des données
3.6 Sécurité des données
4.PROPRIETES D’UN SGBD RELATIONNEL
5.CONCEPTS PRINCIPAUX
5.1 Table et Attribut
5.2 Clés
5.2.1 Clés primaires
5.2.2 Clés étrangères
6.LANGAGES DE MANIPULATION DES DONNEES RELATIONNELLES
6.1 Introduction
6.2 Langage SQL
6.3 SQL au sein d’un SGBD
7.PROPRIETES ACID
8.LIMITES DE SGBD RELATIONNELS
8.1 Modélisation des entités réelles
8.2 Surcharge sémantique
8.3 Contraintes d’intégrité
8.4 Langage de manipulation
8.5 Scalabilité limitée
8.6 Propriétés ACID en milieu distribue
8.7 Limites face aux usages
CONCLUSION
CHAPITRE 2 : Bases de données NoSQL
1.INTRODUCTION
2.HISTORIQUE
3.EMERGENCE DU NOSQL
4.DIFFERENCES ENTRE LE NOSQL ET LE RELATIONNEL
4.1 Caractéristiques du modèle relationnel
4.1.1 Modèle de données
4.1.2 Gestion de la valeur NULL
4.2 Transactions
4.2.1 Scalabilité
4.3 Cohérence contre disponibilité
5.THEOREME DE CAP
6.PROPRIETES B.A.S.E
7.TYPES DE BASES DE DONNEES NOSQL
7.1 Bases de données clé-valeur
7.2 Bases de données orientées colonnes
7.3 Bases orientées document
7.4 Bases orientées graphes
8.AVANTAGES DU NoSQL
8.1 Scalabilité horizontale (élasticité, sharding automatique)
8.2 Solution économique
8.3 Gestion de gros volume de données
8.4 Administrateur de bases de données moins indispensable
8.5 Les schémas de la base ne sont pas figés « shémaless »
8.6 Gestion de données hétérogènes
8.7 Fiabilité lors du stockage de données dites critiques
8.8 Haute disponibilité
RAISONS D’ADOPTATION D’UNE SOLUTION NOSQL
CONCLUSION
CHAPITRE 3 : Réalisation
PARTIE 1 : Domaine d’étude et choix du système NoSQL
1.INTRODUCTION
2.DOMAINE D’ETUDE
2.1 Daïra de Sebdou
2.2 Service des passeports biométrique
2.2.1 Organisation de Service
2.2.2 Principaux objectifs de la plateforme technique déployée au niveau de la daïra
2.3 Motivation du choix d’un tel domaine
3.JUSTIFICATION DU CHOIX DE MONGODB
3.1 Convenance des types des systèmes NoSQL au projet
3.1.1 bases clé/valeur
3.1.2 Bases de données orientées document
3.1.3 Bases en colonnes
3.1.4 Bases orientées graphes
3.2 Critère favorisant la consistance dans le théorème de CAP
3.3 Critère de dernier classement annuel des SGBD
3.4 Synthèse
4.MongoDB
4.1 Introduction
4.2 Représentation de Documents
4.3 Collections de documents
4.4 Requêtes avec Mongodb
4.4.1 Opérations CRUD
4.4.2 Critères de recherche
4.4.3 Projections
4.4.4 Jointures
4.5 Scalabilité
4.5.1 Définition
4.6 Réplication et reprise sur panne
4.6.1 Intérêt de la réplication
4.6.2 Techniques de réplication
4.7 Cohérence des données
4.8 Réplication dans MongoDB
4.8.1 Replica set
4.9 Partitionnement
4.9.1 Principes généraux
4.9.2 Clé de partitionnement
4.9.3 Structures
PARTIE 2 : Implémentation et mise en oeuvre de la migration
1.TABLES CENTRALES ORACLE DE LA BIOMETRIE
2.ENVIRONNEMENT DE TRAVAIL
2.1 Environnement hard
2.2 Langage de programmation
2.3 Outil de développement
2.4 Système de gestion de base de données
2.5 Format de données communiquées
3.INSTALLATION ET CONFIGURATION DE MONGODB
3.1. Préparation et installation
3.2. Lancement des services MongoDB sous Ubuntu 16.04
3.3. Lancement des services MongoDB sous Windows 7
4.INSTALLATION ET CONFIGURATION DE L’ENVIRONNEMENT DISTRIBUE
4.1. Configuration des Shards MongoDB
4.2 Configuration du Serveur de Config MongoDB
4.3. Configuration du Serveur Mongos
5.Migration des données Oracle vers mongodb
5.1. Génération de fichier JSON (Application oracle-json)
5.2. Import des données JSON vers MongoDB
6.Exploitation dans l’environnement distribué
6.1. Test et exploitation du Sharding
6.2 Résultats de comparaison performance
CONCLUSION
CONCLUSION GENERALE
REFERENCES BIBLIOGRAPHIQUES
Liste des Figures
Liste des Tableaux

Télécharger le rapport complet