Soutenance mémoire
L’utilisation des systèmes d’informations se généralise de plus en plus dans le monde. D’innombrables personnes sont connectées à Internet et souhaitent accéder aux services les plus élémentaires sur la toile. Désormais, on voudrait consulter le solde de son compte bancaire, faire des achats, faire ses consultations sanitaires et surtout se connecter en permanent sur des réseaux sociaux sur Internet.
Durant les trois dernières décennies, les systèmes de gestion de bases de données relationnelles régnaient sur le marché des bases de données. Cependant, ces dernières années, le Web a connu une révolution démesurée, avec l’avènement des sites web à fort trafic tels que Facebook, Google, Amazon, Twitter, LinkedIn et autres. Ces grands acteurs du web ont été rapidement limités par les dits systèmes pour deux raisons majeures à savoir la volumétrie et la montée en charge. N’ayant pas trouvé de solution sur le marché répondant à ces problèmes, ces géants du web décidèrent de développer chacun à l’interne leurs propres SGBD (Système de Gestion de Base de Données). Ces produits développés de manières distinctes, ont apparu très rapidement sous le nom de base de données NoSQL (Not only Structured Query Language) ou de base de données non relationnelle, c’est-à-dire les moteurs de données qui n’utilisent pas le standard SQL.
BASES DE DONNEES RELATIONNELLES
Les technologies de bases de données relationnelles et transactionnelles, qu’on résumera ici par « Technologies SQL », règnent en maîtres pour le stockage et la manipulation de données depuis plus de 20 ans. Elles consisteront à stocker les informations décomposées et organisées dans des matrices appelées relations ou tables conformément au modèle de données relationnel. Le contenu de la base de données peut ainsi être synthétisé par des opérations d’algèbres relationnelles telles que l’intersection, la jointure ou le produit cartésien.
Définitions et concepts de base
Base de données
Une base de données (BD) représente l’ensemble (cohérent, intégré, partagé) des informations nécessaires au fonctionnement d’une entreprise mémorisées sur un support permanent, dont la gestion est assurée par un logiciel appelé système de gestion de bases de données. [1] Une base de données permet de stocker et de retrouver l’intégralité de données brutes ou d’informations en rapport avec un thème ou une activité ; celles-ci peuvent être de natures différentes et plus ou moins reliées entre elles. [2] [3] Dans la très grande majorité des cas, ces informations sont très structurées, et la base est localisée dans un même lieu et sur un même support. Ce dernier est généralement informatisé.
La base de données est au centre des dispositifs informatiques de collecte, mise en forme, stockage et utilisation d’informations. Le dispositif comporte un SGBD : un logiciel moteur qui manipule la base de données et dirige l’accès à son contenu.
SGBD
Un SGBD peut être défini comme un ensemble de logiciels prenant en charge la structuration, le stockage, la mise à jour et la maintenance des données. Autrement dit, il permet de décrire, modifier, interroger et administrer les données. C’est, en fait, l’interface entre la base de données et les utilisateurs.
Principes de fonctionnement
La gestion et l’accès à une base de données sont assurés par un ensemble de programmes qui constituent le système de gestion de base de données. Un SGBD doit permettre l’ajout, la modification et la recherche de données. Un système de gestion de bases de données héberge généralement plusieurs bases de données, qui sont destinées à des logiciels ou des thématiques différentes. [4] Actuellement, la plupart des SGBD fonctionnent selon un mode client/serveur. Le serveur (sousentendu la machine qui stocke les données) reçoit des requêtes de plusieurs clients et ceci de manière concurrente. Le serveur analyse la requête, la traite et retourne le résultat au client. Le modèle client/serveur est assez souvent implémenté au moyen de l’interface des sockets ; le réseau étant Internet. Une variante de ce modèle est le modèle ASP. Dans ce modèle, le client s’adresse à un mandataire (broker) qui le met en relation avec un SGBD capable de résoudre la requête. La requête est ensuite directement envoyée au SGBD sélectionné qui résout et retourne le résultat directement au client.
Objectifs
Des objectifs principaux ont été fixés aux SGBD dès l’origine de ceux-ci et ce, afin de résoudre les problèmes causés par la démarche classique. Ces objectifs sont les suivants [4] :
✘ Indépendance physique : La façon dont les données sont dé nies doit être indépendante des structures de stockage utilisées.
✘ Indépendance logique : Un même ensemble de données peut être vu différemment par des utilisateurs différents. Toutes ces visions personnelles des données doivent être intégrées dans une vision globale.
✘ Accès aux données : L’accès aux données se fait par l’intermédiaire d’un Langage de Manipulation de Données (LMD). Il est crucial que ce langage permette d’obtenir des réponses aux requêtes en un temps « raisonnable ».
✘ Administration centralisée des données (intégration) : Toutes les données doivent être centralisées dans un réservoir unique commun à toutes les applications. En effet, des visions différentes des données (entre autres) se résolvent plus facilement si les données sont administrées de façon centralisée.
✘ Non redondance des données : Afin d’éviter les problèmes lors des mises à jour, chaque donnée ne doit être présente qu’une seule fois dans la base.
✘ Cohérence des données : Les données sont soumises à un certain nombre de contraintes d’intégrité qui définissent un état cohérent de la base. Elles doivent pouvoir être exprimées simplement et vérifiées automatiquement à chaque insertion, modification ou suppression des données. Les contraintes d’intégrité sont décrites dans le Langage de Description de Données (LDD).
✘ Partage des données : Il s’agit de permettre à plusieurs utilisateurs d’accéder aux mêmes données au même moment de manière transparente. Si ce problème est simple à résoudre quand il s’agit uniquement d’interrogations, cela ne l’est plus quand il s’agit de modifications dans un contexte multi-utilisateurs car il faut : permettre à deux (ou plus) utilisateurs de modifier la même donnée « en même temps » et assurer un résultat d’interrogation cohérent pour un utilisateur consultant une table pendant qu’un autre la modifie.
✘ Sécurité des données : Les données doivent pouvoir être protégées contre les accès non autorisés. Pour cela, il faut pouvoir associer à chaque utilisateur des droits d’accès aux données.
✘ Résistance aux pannes : Que se passe-t-il si une panne survient au milieu d’une modification, si certains fichiers contenant les données deviennent illisibles ? Il faut pouvoir récupérer une base dans un état « sain ». Ainsi, après une panne intervenant au milieu d’une modification deux solutions sont possibles : soit récupérer les données dans l’état dans lequel elles étaient avant la modification, soit terminer l’opération interrompue.
Quelques SGBD connus et utilisés
Il existe de nombreux systèmes de gestion de bases de données, en voici une liste: PostgreSQL, MySQL, Oracle, IBM DB2, Microsoft SQL, Sybase.
|
Table des matières
INTRODUCTION GENERALE
CHAPITRE 1 BASES DE DONNEES RELATIONNELLES
1.1 Introduction
1.2 Définitions et concepts de base
1.2.1 Base de données
1.2.2 SGBD
1.2.2.1 Principes de fonctionnement
1.2.2.2 Objectifs
1.2.2.3 Quelques SGBD connus et utilisés
1.3 Principe de fonctionnement de SGBDR
1.3.1 Présentation du modèle relationnel
1.3.2 Principes fondamentaux du modèle relationnel
1.4 Langages de manipulations de données relationnelles
1.4.1 Algèbre relationnelle
1.4.2 Calcul des tuples
1.4.3 Exemple
1.5 Langage SQL
1.5.1 Présentation
1.5.2 Facettes intégrées
1.6 Principe d’acidité
1.6.1 Atomicité
1.6.2 Consistance
1.6.3 Isolation
1.6.4 Durabilité
1.7 Limites des SGBDR
1.7.1 Problème lié au partitionnement vertical de données
1.7.2 Problème lié à l’application des propriétés ACID en milieu distribué
1.7.3 Problème de requête non optimale dû à l’utilisation des jointures
1.7.4 Problème lié au Théorème du CAP
1.7.4.1 Consistency
1.7.4.2 Availibility
1.7.4.3 Partition tolerance
1.7.5 Problème lié à la gestion des objets hétérogènes
1.7.6 Problème lié à la surchage sémantique
1.7.7 Problème lié à la contrainte d’intégrité
1.8 Conclusion
CHAPITRE 2 GÉNÉRALITÉS ET CARACTERISTIQUES DE NoSQL
2.1 Introduction
2.2 NoSQL
2.2.1 Technologie NoSQL
2.2.2 Enjeux des bases NoSQL
2.2.2.1 Big Data en France
2.2.2.2 Facebook : Incroyables chiffres
2.2.2.3 Google : Pionier du Big Data en pérpétuelle évolution
2.3 Big Data
2.3.1 Volume
2.3.2 Vitesse
2.3.3 Variété
2.4 Concepts forts de NoSQL
2.4.1 Scalabilité maîtrisée à travers le partitionnement horizontal
2.4.2 Flexibilité du schéma de données
2.4.3 Propriétés de BASE
2.4.4 Administrateur de bases de données (DBA) moins indispensable
2.5 Types de bases de données NoSQL
2.5.1 Les bases de données clé-valeur
2.5.1.1 Description
2.5.1.2 Stockage
2.5.1.3 Recherche d’une ressource
2.5.1.4 Points forts
2.5.1.5 Points faibles
2.5.1.6 Acteurs
2.5.2 Les bases de données orientées documents
2.5.2.1 Description
2.5.2.2 Illustration
2.5.2.3 Stockage
2.5.2.4 Différence entre relationnelle et orienté document
2.5.2.5 Points forts
2.5.2.6 Points faibles
2.5.2.7 Acteurs
2.5.3 Les bases de données orientées colonnes
2.5.3.1 Description
2.5.3.2 Illustration
2.5.3.3 Concepts
2.5.3.4 Exemple concret
2.5.3.5 Points forts
2.5.3.6 Points faibles
2.5.3.7 Acteurs
2.5.4 Les bases de données orientées graphes
2.5.4.1 Description
2.5.4.2 Illustration
2.5.4.3 Concepts
2.5.4.4 Points forts
2.5.4.5 Points faibles
2.5.4.6 Acteurs
2.6 Distribution des données
2.6.1 Sharding
2.6.2 Réplication point à point
2.6.3 Maître / Esclave
2.7 MapReduce
2.7.1 Définition
2.7.2 Principe
2.8 Conclusion
CHAPITRE 3 MODELISATION MULTIDIMENSIONNELLE NoSQL
3.1 Introduction
3.1.1 Entrepôt de données
3.1.2 OLAP
3.1.2.1 MOLAP
3.1.2.2 ROLAP
3.1.2.3 HOLAP
3.2 Modélisation conceptuelle multidimensionnelle
3.2.1 Schéma en constellation
3.2.2 Fait
3.2.3 Dimension
3.2.4 Hiérarchie
3.2.5 Exemple
3.3 Modélisation logique NoSQL
3.3.1 Modélisation multidimensionnelle orientée documents
3.3.1.1 Modèle NoSQL orienté documents
3.3.1.2 Processus de traduction plate en orienté documents
3.3.1.3 Processus de traduction par imbrication en orienté documents
3.3.1.4 Processus de traduction hybride en orienté documents
3.3.2 Modélisation multidimensionnelle orientée colonnes
3.3.2.1 Modèle NoSQL orienté colonnes
3.3.2.2 Processus de traduction plate en orienté colonnes
3.3.2.3 Processus de traduction par imbrication en orienté colonnes
3.3.2.4 Processus de traduction hybride en orienté colonnes
3.4 Synthèse des processus de traduction d’un schéma conceptuel vers les schémas logiques orientés documents et colonnes
3.5 Conclusion
CONCLUSION GENERALE
