Architecture de base de données un nouveau programmeur

Architecture de base de données est le premier de deux cours qui présente un système de développement de base de données de niveau entreprise. L’objectif premier de ce cours est d’introduire l’étudiant aux divers objectifs et outils qui font partie d’un serveur de base de données extensible.Les étudiants vont utiliser Microsoft SQL Server pour apprendre l’architecture d’une base de données.

L’étudiant appliquera les concepts de bases de données relationnelles pour créer et manipuler une base de données à l’aide d’outils offert par SQL Server.L’administrateur de SQL Server ou le concepteur de base de données utilise des boites de dialogue, des assistants, des outils et le langage de programmation T-SQL (Transact SQL) pour travailler avec le serveur de base de données. Tout au long de ce cours, l’étudiant apprendre à utiliser les divers outils pour créer et manipuler une base de données.

Le modèle Client / ServeurIl existe essentiellement deux modèles différents sur lesquels on peut baser les systèmes de bases de données: un système de bureau et un modèle Client / Serveur. SQL Server peut être employé dans les deux instances pour stocker les données et permettre l’interaction avec les applications.Un modèle Client / Serveur divise les éléments d’une base de données en deux (ou plusieurs) composants distincts qui s’exécutent sur deux ou plusieurs ordinateurs.

Le composant Client est responsable de l’interface utilisateur et présente les données aux utilisateurs de façon conviviale. Cette interface peut prendre la forme d’une interface traditionnelle Windows ou une interface Internet basée sur HTML. Le serveur est responsable du stockage des données et de la manipulation des données. Cette approche divise le traitement et donc la charge de travail entre le client, le serveur et, dans certains cas, d’autres ordinateurs.Le modèle Client / Serveur prend la forme d’un nombre d’ordinateurs clients qui accèdent à une base de données centralisée et hébergée sur un serveur de base de données. En d’autres termes, le modèle Client / Serveur est une connexion entre un programme client s’exécutant sur un autre poste de travail qui demande un service ou des données (requête) à un serveur.

Lorsque l’application cliente a besoin de certaines données, elle effectue une demande auprès du serveur. L’application serveur effectue la recherche dans sa base de données pour trouver les informations demandées selon les critères envoyés par l’application cliente. Lorsque l’application serveur trouve les enregistrements correspondants aux critères de recherche, elle renvoie les résultats à l’application cliente.De cette façon, seulement les informations requises sont retournées au client. Ceci permet aussi un accès à de multiples utilisateurs contrairement aux applications de bureau qui donnent accès à un seul utilisateur à la fois. La figure ci-dessous illustre ce processus.

Dans une architecture de bureau (non Client / Serveur), la base de données réside sur le système client. Le client traite la requête localement à même la base de données pour trouver les enregistrements voulus.

Ce processus gaspille beaucoup d’espace disque et rend difficile l’implémentation d’un environnement multi-usagers.

Le serveur prend en charge les éléments de concurrence, de sécurité et la sauvegarde des données. L’application du coté client possède généralement une interface conviviale et peut contenir des requêtes et formulaires prédéterminés. Les rôles de chaque ordinateur ne sont pas coulés dans le béton.

Dépendamment des interactions nécessaires dans un système, plusieurs ordinateurs peuvent y participer. Le processus de division du traitement parmi plusieurs systèmes ou ordinateur crée un environnement multi niveaux. Chaque niveau joue un rôle spécifique dans le système complet.Le développement de l’application client et le choix du modèle d’architecture est une phase de transition entre le développement logique et l’implémentation de la structure physique de la base de données. Parfois, le nombre de niveaux dans la structure est déterminé avant l’implémentation physique. D’autres fois, c’est le contraire, la structure physique dicte l’architecture qui sera adopté. Aucune de ces deux méthodes n’est absolument correcte ou incorrecte, il est nécessaire d’avoir une bonne idéedu modèle avant de déterminer la structure physique.Les systèmes à un et deux niveauxUn système à un niveau sur un environnement PC date d’environ 30 à 35 ans, à un temps où la seule façon de partager des données consistait à la création de plusieurs copies des données et de distribuer manuellement ces copies parmi les divers utilisateurs. Cette approche causait plusieurs ennuis aux gens qui essayaient tant bien que mal d’implanter un système ou environnement multiutilisateur. Il était particulièrement difficile de consolider les mises à jour des multiples copies des données.Dans une approche à un niveau, un ordinateur effectue tous les traitements requis pour visualiser, mettre à jour et stocker les données. Plusieurs produits utilisent cette technique pour des petits systèmes de bases de données à un seul utilisateur. Cette technique devient inefficace lorsque plusieurs utilisateurs ont besoin des données qui sont partagées par tous les utilisateurs. Dans un tel cas, un système à deux niveaux avec une base de données centralisée et hébergée sur un serveur approprié offre un meilleur rendement.Une architecture à deux niveaux place l’interface utilisateur et les données sur des ordinateurs différents. L’application cliente envoi les requêtes via le câblage réseau au serveur où le moteur de base de données s’exécute. Le serveur traite la requête, trouve les données appropriées et renvoi le résultat au client via le câblage du réseau. Il existe deux implémentations possibles pour un système à deux niveaux: un client légerou un client lourd.Dans l’approche du client léger, l’application cliente ne fait pratiquement aucun traitement des données. Le client léger présente les données à l’utilisateur et, lorsque nécessaire, communique avec le serveur de base de données pour y transmettre les requêtes. L’approche de client léger fonctionne bien dans les situations où le nombre d’utilisateurs concurrents qui accèdent les données peut demeurer à un très bas niveau. Le serveur, étant responsablede tous les traitements, de la validation et toutes autres manipulations des données, fait souvent face à un haut débit de traitement. L’approche du client léger est une bonne approche au niveau de la maintenance du système. Si vous avez besoin de mettre à jour les logiciels, vous n’avez pas à le faire pour 1000 clients. Cette approche fonctionne bien aussi avec les applications Internet.L’approche du client lourd transfert une partie de la validation et des traitements de données du serveur au client. Dans cette approche, le client utilise des règles de validation et de traitement pour déterminer si les données sont valides où si elles peuvent être envoyées au serveur. Cette approche permet l’accès aux données par un plus grand nombre d’utilisateurs concurrents. Le désavantage de cette approche est que la maintenance de l’application cliente est plus complexe et les ressources matérielles du client doivent être plus performantes.Malgré le fait qu’une architecture à deux niveaux offre une meilleure flexibilité et permet un plus grand nombre d’utilisateurs concurrents, elle ne peut servir qu’aux plus petits environnements. Lorsqu’un grand nombre d’utilisateurs concurrents doivent être pris en charge, une architecture à n-niveau ou même une architecture Internet représente un meilleur choix

Vous aimerez aussi...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Résoudre : *
11 + 12 =