Admin CliCours
Télécharger le fichier original (Mémoire de fin d’études)
Définition et historique DE BASE DE DONNEES
Définition
Une base de données est un « conteneur » stockant des données telles que des chiffres, des dates ou des mots, pouvant être retraités par des moyens informatiques pour produire une information ; par exemple, des chiffres et des noms assemblés et triés pour former un annuaire. Les retraitements sont typiquement une combinaison d’opérations de recherches, de choix, de tri, de regroupement, et de concaténation.
C’est la pièce centrale d’un système d’information ou d’un système de base de données (ou base de données tout court), qui régit la collecte, le stockage, le retraitement et l’utilisation de données. Ce dispositif comporte souvent un logiciel moteur (cf. paragraphe suivant), des logiciels applicatifs, et un ensemble de règles relatives à l’accès et l’utilisation des informations.
Le système de gestion de base de données est une suite de programmes qui manipule la structure de la base de données et dirige l’accès aux données qui y sont stockées. Une base de données est composée d’une collection de fichiers ; on y accède par le SGBD qui reçoit des demandes de manipulation du contenu et effectue les opérations nécessaires sur les fichiers. Il cache la complexité des opérations et offre une vue synthétique sur le contenu. Le SGBD permet à plusieurs usagers de manipuler simultanément le contenu, et peut offrir différentes vues sur un même ensemble de données.
Le recours aux bases de données est une alternative au procédé classique de stockage de données, par lequel une application place des données dans des fichiers manipulés par l’application. Il facilite le partage des informations, permet le contrôle automatique de la cohérence et de la redondance des informations, la limitation de l’accès aux informations et la production plus aisée des informations synthétiques à partir des renseignements bruts. La base de données a de plus un effet fédérateur : dans une collectivité utilisant une base de données, une personne unique
– l’administrateur de bases de données organise le contenu de la base d’une manière bénéfique à l’ensemble de la collectivité, ce qui peut éviter des conflits dus à des intérêts divergents entre les membres de la collectivité.
Une base de données nécessite généralement plus d’espace disque, le large éventail de fonctions offertes par les SGBD rend les manipulations plus complexes, et les pannes ont un impact plus large et sont plus difficiles à rattrape
Historique
Les disques durs, mémoire de masse de grande capacité, ont été inventés en 1956. L’invention du disque dur a permis d’utiliser les ordinateurs pour collecter, classer et stocker de grandes quantités d’informations de façon plus souple et plus performante que le support antérieur : la bande magnétique.
Le terme database (base de données) est apparu en 1964 pour désigner une collection d’informations partagées par différents utilisateurs d’un système d’informations militaire.
Les premières bases de données hiérarchiques sont apparues au début des années 1960. Les informations étaient découpées en deux niveaux de hiérarchie : un niveau contenait les informations qui sont identiques sur plusieurs enregistrements de la base de données. Le découpage a ensuite été étendu pour prendre la forme d’un diagramme en arbre.
En 1965, Charles Bachmann conçoit l’architecture Ansi/Sparc encore utilisée de nos jours. En 1969, il créa le modèle de données réseau au sein du consortium CODASL pour des applications informatiques pour lesquelles le modèle hiérarchique ne convient pas Charles Bachman a reçu le prix Turing en 1973 pour ses « contributions exceptionnelles à la technologie des bases de données ».
En 1968, Dick Pick crée Pick, un système d’exploitation contenant un système de gestion de base de données « multivaluée » (SGBDR MV).
En 1970, Edgar F. Codd note dans sa thèse mathématique sur l’algèbre relationnelle qu’un ensemble d’entités est comparable à une famille définissant une relation en mathématiques et que les jointures sont des produits cartésiens. Cette thèse est à l’origine des bases de données relationnelles. Edgar F. Codd a reçu le prix Turing en 1981.
Le modèle entité-association a été inventé par Peter Chen en 1975 ; il est destiné à clarifier l’organisation des données dans les bases de données relationnelles
Dans le modèle relationnel, la relation désigne l’ensemble des informations d’une table, tandis que l’association, du modèle entité-association, désigne le lien logique qui existe entre deux tables contenant des informations connexes.
Les premières bases de données étaient calquées sur la présentation des cartes perforées : réparties en lignes et colonnes de largeur fixe. Une telle répartition permet difficilement de stocker des objets de programmation ; en particulier, elles ne permettent pas l’héritage entre les entités, caractéristique de la programmation orientée objet.
Apparues dans les années 1990, les bases de données objet-relationnel utilisent un modèle de données relationnel tout en permettant le stockage des objets. Dans ces bases de données les associations d’héritage des objets s’ajoutent aux associations entre les entités du modèle relationnel.
Type de bases données
Depuis leur apparition, les bases de données ont connu 4 évolutions majeures. Aujourd’hui, les bases de données relationnelles (la 3ème évolution) sont le type de base qui est le plus répandu.
– Les bases de données hiérarchiques
Les tous premiers programmes de bases de données permettaient de structurer l’information de façon hiérarchique : chaque enregistrement dépendait d’un seul enregistrement. Présenté sous forme d’arbre avec ses ramifications, cette façon de faire a très bien fonctionné pour certains projets (pour envoyer l’homme sur la lune avec les missions Apollo notamment).
Mais rapidement, les contraintes trop fortes de dépendance (un seul enregistrement parent) ont amené au deuxième type de base de données.
– Les bases de données réseau
Comment dire qu’un objet peut avoir plusieurs objets parents et plusieurs objets enfants ? Là où les bases de données hiérarchiques déclarent forfait, les bases de données réseau prennent le relais de façon très satisfaisante. En permettant les relations n-n (plusieurs parents / plusieurs enfants), les bases de données font un vrai bond en avant et permettent de mimer plus fidèlement le monde réel. D’une structure en arbre, les bases de données deviennent des graphes.
Ce type de base de données (qui valut le prix Turing à son inventeur C.W. Bachman) apporte une limitation non négligeable : une trop grande dépendance entre les données et les programmes. Ce défaut empêche la diffusion de ce type de base de données au plus grand nombre et introduit son remplaçant.
– Les bases de données relationnelles
C’est le type de bases que l’on connaît et que l’on pratique aujourd’hui. Basé sur l’algèbre relationnel Et les travaux de E.F. Codd, il permet de modéliser facilement et sans grosse contraintes les systèmes du monde réel et de créer des bases de données simples à maintenir, à faire évoluer et indépendantes de leur support.
Dans ce type de bases de données, les données sont organisées en tables. C’est la technologie majeure en bases de données depuis les années 1980.
– Les bases de données objet
Superbe promesse qui reste encore confidentielle et sujet de laboratoire, les bases de données objet Apportent de très beaux atouts aux bases de données relationnelles. La grande idée est ici de permettre « d’attaquer » la base de données de façon transparente via ses « objets ». Les objets sont un concept de programmation qui simplifie la création de logiciel et apporte de nombreux atouts aux projets informatiques importants. En ajoutant une couche d’abstraction supplémentaire aux bases de données (en les faisant apparaître comme des objets que les informaticiens manipulent déjà), le travail avec les bases de données est simplifié. L’outil à peu près commun aux différentes bases de données objet est aujourd’hui l’OQL (L’équivalent objet du SQL).
L’importance telle qu’ont prises les bases de données relationnelles semble indiquer qu’il n’y aura pas de 4ème révolution mais plutôt que les principes du modèle objet, une fois mûr et bien standardisés, rejoindront les bases de données relationnelles.
Généralité sur la sécurité des bases de données
On envisage souvent la sécurité sous un angle fermé, essentiellement celui de la confidentialité. Mais bien d’autres concepts sous-tendent la sécurité. Ils sont pratiquement tous applicables aux SGBD, tant il est vrai que ces deux domaines sont extrêmement recouvrant.
– Confidentialité : Tout n’est pas accessible à tout le monde ! Se connecter à l’OS ou à la base de données, donne un certain nombre de droits et de ressources en fonction d’un profil défini et maintenu par un administrateur. La granularité d’accès peut aller jusqu’à la vision unique d’un champ d’un enregistrement d’une table particulière.
– Disponibilité : Faculté de délivrer correctement un service en termes de délai et de qualité à l’utilisateur. Se mesure en pourcentage du temps de fonctionnement total. Une disponibilité de 100% est possible (temps de reprise nul) il suffit de s’en donner les moyens logiciels et matériels…
– Fiabilité : Des mécanismes de sauvegarde variés (physique, logique, off-line, on-line, totale, partielle, incrémentale), ainsi que des mécanismes de journalisation, et de reprise permettent de restaurer une information sans pratiquement aucune perte, dans tous les cas de problème matériel ou logiciel.
– Intégrité : Que les données soient réparties ou non –dans ce dernier cas les mécanismes mis en jeux seront plus complexes– elles doivent être cohérentes. Cela sous-entend, d’une part que les accès concurrents d’utilisateurs, notamment lors de mises à jour, ne doivent pas compromettre la cohérence des données et d’autre part que ces dernières satisfassent aux contraintes d’intégrité du modèle, et ou aux règles de gestion de l’entreprise.
– Traçabilité : en cas de problème important ou d’attaque du système, on peut recourir à l’analyse de traces ou de logs. Le niveau de détail de ces traces est paramétrable, et concerne soit les aspects système, soit réseau, soit l’accès aux données élémentaires elles-mêmes.
Maintenabilité : aptitude à la réparation, évolution, maintenance du système. Mesuré en temps de reprise après panne (Mean Time To Recover)
Généralité sur les SGBD et SQL SERVER 2016
Généralité sur les SGBD
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 (SGBD). 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.
Actuellement, la plupart des SGBD fonctionnent selon un mode client/serveur. Le serveur (sous-entendu 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 (voir le cours de réseau) ; le réseau étant Internet.
Une variante de ce modèle est le modèle ASP (Application Service Provider). 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.
Quel que soit le modèle, un des problèmes fondamentaux à prendre en compte est la cohérence des données. Par exemple, dans un environnement où plusieurs utilisateurs peuvent accéder concurremment à une colonne d’une table par exemple pour la lire ou pour l’écrire, il faut s’accorder sur la politique d’écriture. Cette politique peut être : les lectures concurrentes sont autorisées, mais dès qu’il y a une écriture dans une colonne, l’ensemble de la colonne est envoyé aux autres utilisateurs l’ayant lue pour qu’elle soit rafraîchie
Généralité sur SQL server
Définition de plan de reprise et de continuité d’activité
Définition d’un plan de reprise d’activité
Un plan de reprise d’activité (PRA) est un ensemble de procédures (techniques, organisationnelles, sécurité) qui permet à une entreprise de prévoir par anticipation, les mécanismes pour reconstruire et remettre en route un système d’information en cas de sinistre important ou d’incident critique.
En cas de sinistre, Le PRA permet de reconstruire les serveurs en leur affectant les données répliquées et ainsi de redémarrer les applications sous quelques minutes ou quelques heures, suivant les solutions retenues. Il existe plusieurs niveaux de capacité de reprise, et le choix doit dépendre des besoins exprimés par l’entreprise.
Les entreprises actuelles dépendant de plus en plus de leur informatique, elles ne peuvent donc plus se permettre de ne pas avoir une solution face à un incident informatique, qui pourrait leur être fatal ou entraîner une paralysie de l’activité professionnelle. Le plan de reprise d’activité a alors un rôle majeur pour assurer le redémarrage structuré des systèmes d’information. Ce plan peut être détenu par l’entreprise ou confié à un prestataire.
Le PRA est comme une assurance, tant qu’il n’y a pas d’accident, on ne voit pas l’intérêt. Aujourd’hui, la simple sauvegarde ne suffit plus. Voici quelques chiffres clés pour comprendre la mise en place du plan :
• 76 % des entreprises déclarent la perte de données informatiques sur les deux dernières années.
• 82 % des PME non préparées à un sinistre ne survivent pas à un important crash informatique.
Le plan de reprise d’activité (PRA) est à distinguer du plan de continuité d’activité (PCA) : ce dernier a pour objectif de poursuivre l’activité sans interruption du service et d’assurer la disponibilité des informations quels que soient les problèmes rencontrés. Le PRA en est un sous-ensemble, qui décrit hiérarchiquement l’ensemble des mesures qui doivent être mise en place lors de la survenue d’un sinistre ou d’un incident majeur ayant entraîné une interruption de l’activité. Le PRA définit les architectures, les moyens et les procédures nécessaires à mettre en œuvre pour assurer la protection des applications qu’il couvre.
Définition de plan de continuité d’activité
Le « Plan de continuité » est un document stratégique, formalisé et régulièrement mis à jour (et si possible testé via des exercices ad hoc) de planification de la réaction à une catastrophe ou à un sinistre grave. Il est de plus en plus associé à un système d’information. Dans certains domaines, il peut y avoir plusieurs plans de continuité, chacun dédié à une ligne métier, en identifiant bien les activités indispensables. La réalisation d’un Plan de Continuité d’Activité est généralement le résultat d’une analyse en Groupe de Travail, rassemblant les différentes compétences de l’entreprise.
Le PCA a 3 étapes :
• Une analyse de vulnérabilité, visant à évaluer le risque et les objectifs que l’on se fixe pour son niveau d’acceptation. De cette analyse découle une évaluation des besoins de continuité, du niveau de service minimum indispensable ainsi que de la durée d’indisponibilité maximale acceptable pour chaque service.
• La définition des actions préalables à mettre en place pour rester sous le seuil de vulnérabilité, qui se fait par le biais d’un plan de traitement.
• La définition et mise en œuvre d’un plan de survie, définissant les ressources et procédures requises en période de crise, pour rétablir les ressources critiques, jusqu’à la reprise de la situation normale.
Etude des Norme PRA PCA
La norme ISO 22301 « Sécurité sociétale – État de préparation et systèmes de gestion de la continuité – Exigences » a été publiée le 5 juin 2012. Elle était très attendue par les responsables de continuité d’activités et les risk managers.
Il existe déjà de nombreux standards édités par des organismes nationaux sur le sujet de la continuité (BPZ 74/700 de l’AFNOR en France, NFPA 1600 aux États-Unis, etc.), mais l’ISO22301 est le nouveau – et seul – standard international en la matière. S’aligner sur ses recommandations, c’est inscrire les Plans de Continuité d’Activités (PCA) dans un véritable cycle de vie et réussir, au-delà de l’avancement des actions relatives à sa construction, son maintien en conditions opérationnelles !
Règlementation et normes
La prise de conscience progressive des sociétés autour de l’importance fondamentale de la continuité d’activité dans les organisations pour atténuer les effets des incidents perturbateurs amène aujourd’hui le législateur et les régulateurs à se positionner sur le sujet.
Ainsi, une législation naissante vient poser un certain nombre d’exigences de continuité d’activité, en particulier pour les acteurs économiques fournissant un service public. Cela fournit l’assurance que ces acteurs sont dotés de dispositifs appropriés pour garantir la continuité des activités. Parallèlement, un référentiel normatif balise peu à peu le sujet et guide les organisations désireuses de le faire, dans la mise en place de leur continuité d’activité.
Référentiel normatif générique
La norme ISO 22301 (Sécurité Sociétale – Systèmes de Gestion de la Continuité des Activités –Exigences), parue en 2012, se pose comme le standard international de management de la continuité. Un référentiel reconnu des bonnes pratiques en gestion de continuité des activités était nécessaire Notamment à des fins de certification. Plusieurs pays avaient déjà soulevé cette problématique, et notamment le Royaume-Uni avec la norme britannique BS 25999 (British Standard : organisme de normalisation au Royaume-Uni, équivalent de l’AFNOR en France) qui avait pour objet d’aider à mettre en place un système de gestion de la continuité d’activité, et était la première du genre. La norme ISO 22301 vise à remplacer ce standard britannique, et a été élaborée en coopération et avec des contributions du monde entier. Elle a été développée pour permettre aux organisations de minimiser l’impact de sinistres majeurs.
Cette norme spécifie formellement un ensemble d’exigences pour mettre en place et maintenir, dans une logique d’amélioration continue, un dispositif de continuité d’activité, menant à une certification.
Les exigences spécifiées dans la norme sont génériques et prévues pour s’appliquer à toute organisation ou partie de celle-ci, indépendamment du type, de la taille et de la nature de l’organisation. Elle met notamment en exergue l’importance de comprendre les besoins de l’organisation et la nécessité de définir une politique et des objectifs de continuité, de déployer et mettre en œuvre les moyens nécessaires pour les atteindre et de surveiller et revoir le dispositif afin d’en assurer l’amélioration continue.
Dans le cas particulier de la continuité d’activité informatique et la mise en place d’un PSI, un référentiel normatif spécifique existe, ainsi que des bonnes pratiques internationales. En particulier, la norme britannique BS 25777 guide l’établissement d’un cadre organisationnel du PSI. Le British Standard propose également un recueil de bonnes pratiques pour réaliser les tests du PSI, notamment sur le data center. Cette norme a inspiré l’ISO pour créer la norme 27031 portant sur la continuité informatique.
L’intérêt pour une organisation de se conformer au référentiel proposé par la norme ISO 22301 pour mettre en place un PCA et la norme ISO 27031 pour en définir le PSI, au-delà de la guidance que cela fournit, est que cette certification prouve son respect des bonnes pratiques en la matière auprès des instances législatives et règlementaires, des clients potentiels et d’autres parties prenantes intéressées. En effet, conscients de leur interdépendance, les acteurs cherchent à s’assurer que leurs principaux fournisseurs et partenaires sont toujours en mesure de pouvoir fournir les produits et services critiques, même en cas d’incidents. Cette exigence peut être imposée par leur propre PCA. Certains actionnaires, soucieux de protéger leur fonds, peuvent également être sensibles à ce type de certifications. Enfin, certaines primes d’assurance diminuent pour l’entreprise à risque si elle est dotée d’un PCA certifié.
Cadre législatif et règlementaire spécifique
Les PCA sont obligatoires et règlementés dans certains secteurs d’activités, notamment les fournisseurs de services vitaux : Banques et assurances, santé publique, alimentation, énergie, transports, et télécommunications. Les secteurs d’activités d’importance vitale, ainsi que toutes les dispositions qui s’y rapportent, sont définies dans les articles R. 1332-2 et suivants du Code de la
Défense. Une base de données unique tenue et mise à jour par le secrétariat général de la défense nationale rassemble l’ensemble des informations spécifiques du dispositif de sécurité des activités d’importance vitale. Elle porte le nom de « DIVA » (Données d’Importance Vitales).
Les Aspects de SQL server qui traitent la question
Deux familles de technologies existent et peuvent en général être combinées, car elles couvrent des types de panne différents :
– La sauvegarde, effectuée à intervalles réguliers, permet de se prémunir contre la perte ou la corruption de données quelle qu’en soit la cause, mais avec une perte de données en général d’une journée, voire plus. Plusieurs jeux de sauvegarde permettent de revenir plus ou moins loin en arrière ;
– La réplication, effectuée en temps réel ou quasi réel, permet d’apporter une perte de données de 0, ou proche de 0, mais ne permet quant à elle que de protéger d’une perte de données liée à une panne, mais pas liée à une mauvaise manipulation, comme une suppression de fichiers, ni contre la corruption suite à un bug logiciel.
Définition et type de sauvegarde
En informatique, la sauvegarde (backup en anglais) est l’opération qui consiste à dupliquer et à mettre en sécurité les données contenues dans un système informatique. Certains utilisateurs ont pour objectif final de sauvegarder leurs fichiers dès le moment de leur enregistrement comme celui qui vient de saisir un texte de loi dans un traitement de texte.
Ils existent diffèrent types de sauvegarde sous SQL server :
Sauvegarde différentielle : Sauvegarde de données basée sur la dernière sauvegarde complète d’une base de données complète ou partielle ou d’un ensemble de fichiers de données ou de groupes de fichiers (base différentielle) et qui contient uniquement les données ayant changé depuis cette base.
Sauvegarde complète : Sauvegarde de données qui contiennent toutes les données d’une base de données particulière ou d’un jeu de groupes de fichiers ou de fichiers, ainsi qu’une partie suffisante du journal pour permettre la récupération de ces données.
Sauvegarde de fichier journal : Sauvegarde des journaux des transactions qui inclut tous les enregistrements des journaux qui n’ont pas été sauvegardés lors d’une sauvegarde de fichier journal précédente. (Mode de récupération complète)
Définition et types de réplication
En informatique, la réplication est un processus de partage d’informations pour assurer la cohérence de données entre plusieurs sources de données redondantes, pour améliorer la fiabilité, la tolérance aux pannes, ou la disponibilité. On parle de réplication de données si les mêmes données sont dupliquées sur plusieurs périphériques.
La réplication n’est pas à confondre avec une sauvegarde : les données sauvegardées ne changent pas dans le temps, reflétant un état fixe des données, tandis que les données répliquées évoluent sans cesse à mesure que les données sources changent.
Ils existent plusieurs de réplication on peut en cité
La réplication transactionnelle : commence en général avec l’instantané des objets et des données de la base de données de publication. Dès que l’instantané initial est effectué, les changements de données et les modifications de schémas effectués ensuite au niveau du serveur de publication sont en général transmis à l’Abonné à mesure qu’ils se produisent (presque en temps réel). Les changements de données sont appliqués à l’Abonné dans le même ordre et dans les mêmes limites de transaction que sur le serveur de publication ; c’est pourquoi, dans une publication, la cohérence des transactions est garantie.
La réplication transactionnelle est en général utilisée dans les environnements serveur à serveur. La réplication d’instantané est plus appropriée quand les modifications de données sont substantielles mais peu fréquentes. Par exemple, si une entreprise commerciale gère des tarifs de produits, et que ces tarifs sont tous mis à jour en même temps, une à deux fois par an, il est recommandé de procéder à une réplication de l’intégralité de l’instantané des données modifiées. Suivant certains types de données, des instantanés plus fréquents peuvent également être appropriés. Par exemple, si une table relativement petite est mise à jour sur le serveur de publication dans la journée mais qu’une certaine latence est tolérée, les modifications peuvent être remises pendant la nuit en tant qu’instantané.
Table des matières
Introduction Général
PARTIE I : CADRE DE REFERENCE ET APPROCHE METHODOLOGIQUE
I.1 Cadre de référence
I.2 Approche méthodologique
I.2.1 Problématique
I.2.2 Objectif
PARTIE II : GENERALITE SUR LES BASES DE DONNEES ET LE PLAN DE REPRISE ET DE CONTINUITE D’ACTIVITE
II.1 Définition et historique DE BASE DE DONNEES
II.1.1 Définition
II.1.2 Historique
II.2 Type de bases données
II.3 Généralité sur la sécurité des bases de données
II.4 Généralité sur les SGBD et SQL SERVER 2016
II.4.1 Généralité sur les SGBD
II.4.2 Généralité sur SQL server
II.5 Définition de plan de reprise et de continuité d’activité
II.5.1 Définition d’un plan de reprise d’activité
II.5.2 Définition de plan de continuité d’activité
II.6 Etude des Norme PRA PCA
II.6.1 Règlementation et normes
II.6. 2 Référentiel normatif générique
II.6.3 Cadre législatif et règlementaire spécifique
II.7 Les Aspects de SQL server qui traitent la question
II.7.1 Définition et type de sauvegarde
II.7.2 Définition et types de réplication
II.8 Choix de la solution
PARTIE III : ETUDE FONCTIONNELLE ET TECHNIQUE
III.1 Architecture de réplication
III.2 Installation de Windows server et de SQL server 2016
III.2 1 Installation de Windows server 2016
III.2 Installation de SQL server 2016
III.3 Mise en oeuvre du sauvegarde et réplication sous SQL server 2016
CONCLUSION
Bibliographie et webographie
