Base de données relationnelles d

Base de données Orientée Objet
Première Licence
Chef de Travaux Anaclet TSHIKUTU Bikengela
Année Académique 2020-2021

1
Chapitre 1 : Notions d'architecture client-serveur

1.1. Définitions1
L'environnement client-serveur désigne un mode de communication à travers un

réseau entre plusieurs programmes ou logiciels : l'un, qualifié de client, envoie des
requêtes ; l'autre ou les autres, qualifiés de serveurs, attendent les requêtes des clients et
y répondent. Par extension, le client désigne également l'ordinateur sur lequel est
exécuté le logiciel client, et le serveur, l'ordinateur sur lequel est exécuté le logiciel
serveur.
Le client serveur est avant tout un mode de dialogue entre deux processus. Le
premier appelé client demande l’exécution de services au second appelé serveur. Le
serveur accomplit les services et envoi en retour des réponses.
En général, un serveur est capable de traiter les requêtes de plusieurs clients. Un

serveur permet donc de partager des ressources entre plusieurs clients qui s’adressent à
lui par des requêtes envoyées sous forme de messages.
En général, les serveurs sont des ordinateurs dédiés au logiciel serveur qu'ils abritent, et
dotés de capacités supérieures à celles des ordinateurs personnels en termes de puissance
de calcul, d'entrées-sorties et de connexions réseau.
Les clients sont souvent des ordinateurs personnels ou des appareils individuels
(téléphone, tablette), mais pas systématiquement. Un serveur peut répondre aux
requêtes d'un grand nombre de clients.
1.2. Fonctionnement d'un système client/serveur
Figure 1-1 : Schéma de fonctionnement d'un système client/serveur
Un système client/serveur fonctionne selon le schéma suivant :
✓ Le client émet une requête vers le serveur grâce à son adresse et à son port, qui
désigne un service particulier du serveur
✓ Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine client
(et de son port)
Jean François Pillou, Tout sur les systèmes d'information, Dunod, Paris, 1996
1

2
Il existe une grande variété de logiciels serveurs et de logiciels clients en fonction des
besoins à servir : un serveur web publie des pages web demandées par des navigateurs
web ; un serveur de messagerie électronique envoie des mails à des clients de
messagerie ; un serveur de fichiers permet de stocker et consulter des fichiers sur le
réseau ; un serveur de données à communiquer des données stockées dans une base de
données, etc.
1.3. Exemples des modèles clients serveurs
✓ La consultation de pages sur un site web fonctionne sur une architecture client-
serveur. Un internaute connecté au réseau via son ordinateur et un navigateur
web est le client, le serveur est constitué par le ou les ordinateurs contenant les
applications qui délivrent les pages demandées. Dans ce cas, c'est le protocole de
communication HTTP ou XML socket qui est utilisé.
✓ Les courriels sont envoyés et reçus par des clients et gérés par un serveur de
messagerie. Les protocoles utilisés sont le SMTP, et le POP ou l'IMAP.
1.4. Avantages et Inconvénients du modèle client/serveur
a. Avantages
Le modèle client/serveur est particulièrement recommandé pour des réseaux

nécessitant un grand niveau de fiabilité, ses principaux atouts sont :
✓ Des ressources centralisées : étant donné que le serveur est au centre du réseau,
il peut gérer des ressources communes à tous les utilisateurs, comme par exemple
une base de données centralisée, afin d'éviter les problèmes de redondance et de
contradiction
✓ Une meilleure sécurité : Toutes les données sont centralisées sur un seul serveur,
ce qui simplifie les contrôles de sécurité, l'administration, la mise à jour des
données et des logiciels.
✓ Une administration au niveau serveur : les clients ayant peu d'importance dans
ce modèle, ils ont moins besoin d'être administrés
✓ Un réseau évolutif : grâce à cette architecture ont peu supprimer ou rajouter des
clients sans perturber le fonctionnement du réseau et sans modifications majeures
✓ La complexité du traitement et la puissance de calculs sont à la charge du ou des
serveurs, les utilisateurs utilisant simplement un client léger sur un ordinateur
terminal qui peut être simplifié au maximum.
✓ Recherche d'informations : les serveurs étant centralisés, cette architecture est
particulièrement adaptée et véloce pour retrouver et comparer de vaste quantité
d'information (moteur de recherche sur le Web).
b. Inconvénients
L'architecture client/serveur a tout de même quelques lacunes parmi lesquelles :

3
✓ Si trop de clients veulent communiquer avec le serveur au même moment, ce

dernier risque de ne pas supporter la charge (alors que les réseaux pair-à-pair
fonctionnent mieux en ajoutant de nouveaux participants).
✓ Si le serveur n'est plus disponible, plus aucun des clients ne fonctionne (le réseau
pair-à-pair continue à fonctionner, même si plusieurs participants quittent le
réseau).
✓ Les coûts de mise en place et de maintenance sont élevés.
✓ En aucun cas les clients ne peuvent communiquer entre eux, entrainant une
asymétrie de l'information au profit des serveurs.
1.5. Types de clients
1.5.1. Client léger
Le poste client accède à une application située sur un ordinateur dit « serveur »
via une interface et un navigateur Web. L'application fonctionne entièrement sur le
serveur, le poste client reçoit la réponse « toute faite » à la demande (requête) qu'il a
formulée.
1.5.2. Client lourd
Le poste client doit comporter un système d'exploitation capable d'exécuter en

local une partie des traitements. Le traitement de la réponse à la requête du client
utilisateur va mettre en œuvre un travail combiné entre l'ordinateur serveur et le poste
client.
1.5.3. Client riche
Une interface graphique plus évoluée permet de mettre en œuvre des

fonctionnalités comparables à celles d'un client "lourd". Les traitements sont effectués
majoritairement sur le serveur, la réponse "semi-finie" étant envoyée au poste client, où
le client "riche" est capable de la finaliser et de la présenter.
1.6. Différents types de c-s
Selon la nature des services accomplis par le serveur pour un client, différents
types de client-serveur ont été distingués.
Selon la répartition des fonctions de présentation graphique (affichage et saisie de
données à partir d'icônes graphiques par exemple), de gestion de données (accès aux
fichiers ou aux bases de données), d'exécution de code applicatif (calculs de
l'application), on distingue les types de client-serveur décrits ci-dessous.
1.6.1. C/S de présentation (Présentation CIS)

4
Type de client-serveur dans lequel un processus exécute seulement les fonctions

de dialogue avec l'utilisateur, l'autre gérant les données et exécutant le code applicatif.
1.6.2. C/S de données (Data CIS)
Type de client-serveur dans lequel un programme applicatif contrôlé par une

interface de présentation sur une machine cliente accède à des données sur une machine
serveur par des requêtes de recherche et mise à jour, souvent exprimée avec le langage
SQL.
Le serveur de données gère une ou plusieurs bases de données.

1.6.3. C/S de procédures ( Procédure CIS)
Type de client-serveur dans lequel un programme applicatif contrôlé par une

interface de présentation sur une machine cliente sous-traite l'exécution de procédures
applicatives à une machine serveur, ces procédures encapsulant souvent une base de
données.
1.6.4. C/S de données et procédures
La tendance est donc d'aller vers un système d'information du type client-serveur

de données et procédures. De plus en plus souvent, ce type de client-serveur permet de
mettre en commun des procédures communes autour de la base de données au niveau
du serveur, et donc de répartir les traitements entre client et serveur.
1.7. Architecture client-serveur par niveau
1.7.1. Architecture 2 niveaux
L'architecture à deux niveaux (aussi appelée architecture 2-tiers, tier signifiant

étage en anglais) caractérise les systèmes clients/serveurs dans lesquels le client demande
une ressource et le serveur la lui fournit directement. Cela signifie que le serveur ne fait
pas appel à une autre application afin de fournir le service.
Figure 1-2 : Architecture 2-tiers
1.7.2. Architecture à trois niveaux

5
Dans l'architecture à 3 niveaux (appelée architecture 3-tier), il existe un niveau

intermédiaire, c'est-à-dire que l'on a généralement une architecture partagée entre :
1. Le client : le demandeur de ressources

2. Le serveur d'application : le serveur chargé de fournir la ressource mais faisant
appel à un autre serveur
3. Le serveur secondaire : généralement un serveur de base de données, fournissant
un service au premier serveur
Figure 1-4 : Architecture 3-tiers
Remarque
Étant donné l'emploi massif du terme d'architecture à 3 niveaux, celui-ci peut parfois
désigner aussi les architectures suivantes :
• Partage d'application entre client, serveur intermédiaire, et serveur d'entreprise

• Partage d'application entre client, base de données intermédiaire, et base de
données d'entreprise
Comparaison des deux types d'architecture
L'architecture à deux niveaux est donc une architecture client/serveur dans laquelle le
serveur est polyvalent, c'est-à-dire qu'il est capable de fournir directement l'ensemble
des ressources demandées par le client.
Dans l'architecture à trois niveaux par contre, les applications au niveau serveur sont
délocalisées, c'est-à-dire que chaque serveur est spécialisé dans une tâche (serveur web
et serveur de base de données par exemple). Ainsi, l'architecture à trois niveaux permet
:
• Une plus grande flexibilité/souplesse

• Une plus grande sécurité (la sécurité peut être définie pour chaque service)
• De meilleures performances (les tâches sont partagées)
1.7.3. L'architecture multi-niveaux (N-tiers)

6
Dans l'architecture à 3 niveaux, chaque serveur (niveaux 1 et 2) effectue une tâche

(un service) spécialisée. Ainsi, un serveur peut utiliser les services d'un ou plusieurs autres
serveurs afin de fournir son propre service. Par conséquence, l'architecture à trois
niveaux est potentiellement une architecture à N niveaux.
Figure 1-5 : Architecture N-tiers
1.8. LES MIDDLEWARES (intergiciel)
1.8.1. Définition
Le middleware est ce logiciel du milieu qui assure les dialogues entre clients et
serveurs souvent hétérogènes. Le terme middleware vient de l’anglais middle (du milieu)
et software (logiciel), il désigne un ensemble de services logiciels nécessaires servant
d’intermédiaire entre les logiciels pour permettre et organiser la communication entre
les applications réparties ; ou un ensemble de services logiciels construits au-dessus d’un
protocole de transport afin de permettre l’échange de requêtes et des réponses associées
entre client et serveur d’une application de manière transparente.
Exemple de middlewares
✓ SQL*Net : Interface propriétaire permettant de faire dialoguer une application

cliente avec une base de données Oracle. Ce dialogue peut aussi bien être le
passage de requêtes SQL que l'appel de procédures stockées.
✓ ODBC (Open DataBase Connectivity) : Interface standardisée isolant le client du

serveur de données. C'est l'implémentation par Microsoft du standard CLI (Call
Level Interface) défini par le SQL Access Group. Elle se compose d'un gestionnaire
de driver standardisé, d'une API s'interfaçant avec l'application cliente (sous Ms
Windows) et d'un driver correspondant au SGBD utilisé.

7
✓ DCE (Distributed Computing Environment) : Mécanisme de RPC proposé par

l'OSF.) : Permet l'appel à des procédures distantes depuis une application.
Le choix d'un middleware est déterminant en matière d'architecture, il joue un grand

rôle dans la structuration du système d'information.
Les middlewares proposés par les fournisseurs de SGBD sont très performants et
permettent de tirer profit de l'ensemble des fonctionnalités du serveur de données pour
lequel ils ont été conçus. Par contre, ils ne permettent pas, le plus souvent, l'accès à
d'autres sources de données.
1.8.2. Rôle
Le middleware offre des services de haut niveau liés au besoin de communication

des applications (temps réel, sécurisation, sérialisation, transaction informatique, etc…)
appelé communication interprocessus (inter Process Communication, IPC). Elle vient se
situer dans le modèle OSI au-dessus de la couche de transport.
1.8.3. Les fonctions d’un Middleware
✓ Il indique la procédure d’établissement de connexion ;

✓ Il exécute des requêtes ;
✓ Il récupère des résultats ;
✓ Il initie des processus sur différents sites ;
✓ Il organise les services des répertoires (nommage) ;
✓ Il permet l’accès aux données à distance ;
✓ Il gère des accès concurrents ;
✓ Il garantit la sécurité et l’intégrité ;
✓ Il assure la terminaison des processus ;
1.9. Application : Création d’une application Client Serveur pas à pas avec C#
Dans cette partie, nous allons essayer de créer une application client-serveur avec C#.
Nous allons tenter d’établir une connexion à une base de données Access distante.
L’objectif de cette démarche est simplement d’essayer d’accéder à une base de données
distante via le réseau.
Principe
Nous aurons besoins d’au moins deux machines :
- Machine 1 (Serveur) : Partager le fichier de connexion (La base de données)

- Machine 2 (Client) : Etablir la connexion et effectuer des opérations
Etape 1 : Partager le fichier de la base de données (BDD.accdb)
- Créer un nouveau répertoire de partage dans D:\, (ex : EtudiantBD)

8
- Copier le fichier de la base de données (BDD.accdb) dans le répertoire de partage

D:\EtudiantBD
- Partager le répertoire D:\EtudiantBD
Faire un clic droit sur le dossier qui contient votre BDD,
Choisir « Propriétés ». Sur la fenêtre qui s’ouvre, aller sur l’onglet « Partager »
Cliquer sur le bouton « Partage avancé »

9
Cocher la case « Partager ce dossier » pour que les différentes zones de textes soient
activées. Cliquer ensuite sur le bouton « Autorisation »
Cocher les cases : « Autoriser Contrôle total » et « Autoriser Modifier », puis « Appliquer »
et « OK » Et le répertoire qui contient votre base de données est partagé.
Puis, copier votre chemin d’accès à la base de données via le réseau :

10
Etape 2 : Préparation de la chaine de connexion

La chaine de connexion à utiliser dans notre programme sera
string chaine = @"Provider=Microsoft.ACE.OLEDB.12.0; Data Source=\\DESKTOP-
GA8BIKH\EtudiantBD\BDD.accdb";
Voici comment se présente l’interface de notre application :
Le code source de la méthode qui permet d’envoyer les données dans la BDD
...
//Méthode pour enregistrer
public void enregistrer()
{
//création d'un objet du type de la classe classlogin
classprod nouveauproduit = new classprod();
//Transfert des données du formulaire vers la classe
nouveauproduit.Id_Produit = int.Parse(txtcode.Text);
nouveauproduit.Libelle_Produit = txtdesign.Text;
nouveauproduit.PU = double.Parse(txtpu.Text);
nouveauproduit.Quantite_Stock = int.Parse(txtqte.Text);
// chaine de connexion

11
string chaine = @"Provider=Microsoft.ACE.OLEDB.12.0; Data Source=\\DESKTOP-

GA8BIKH\EtudiantBD\BDD.accdb";
// Création de l'objet de connexion

OleDbConnection con = new OleDbConnection(chaine);
// Création de l'objet de la classe Command (requete)
OleDbCommand requete = new OleDbCommand("insert into T_Produit values('" +
nouveauproduit.Id_Produit + "', '" + nouveauproduit.Libelle_Produit + "', '" +
nouveauproduit.PU + "', '" + nouveauproduit.Quantite_Stock + "')", con);
//Ouverture de la connexion
con.Open();
//Exécution de la réquete
requete.ExecuteNonQuery();
//Fermeture de la connexion
con.Close();
MessageBox.Show("Produit ajouté avec succès", "Gestion Vente Produit",
MessageBoxButtons.OK);
effacer();
...

12
Quelle prétention de prétendre que l'informatique est

récente : Adam et Eve avaient déjà un Apple !
Chapitre 2 : Les bases de données réparties
2.1. Définition
Une base de données repartie est un ensemble de bases de données gérées par
de sites différents et apparaissant à l’utilisateur comme une base unique.
Une base de données repartie peut aussi être vue comme une collection de bases de
données logiquement reliées, distribuées sur un réseau.
Une base de données répartie est un assemble de différente base de données mise en
relation les unes avec les autres à travers un réseau.
Figure 2-1 : Architecture d’une base de données réparties
2.2. Le SGBD reparti
Un système de gestion de bases de données réparties est donc un ensemble de

logiciel systèmes gérant des données réparties sur un ensemble de sites, intégrant des
modules clients et des modules serveurs. Clients et serveurs collaborent bien sûr par des
médiateurs spécifiques.
Un SGBD réparti doit rendre la répartition des bases des données transparentes aux
utilisateurs. La base de données étant répartie, il faut également répartir certaines
fonctionnalités du SGBD.
Nous précisons maintenant les composants essentiels nécessaires pour gérer des
données reparties. Le système de gestion de bases de données reparti (SGBDR) cache
aux applications l’existence de multiples bases. Il fournit aux clients SGBDR l’illusion que
l’ensemble des bases gérées par les serveurs du SGBDR est intégré en une base unique.

13
2.2.1. Quelques définitions de base
Un SGBD reparti est un système qui gère des collections de BD logiquement

reliées, distribuées sur un réseau, en fournissant un mécanisme d’accès qui rend la
répartition transparente aux utilisateurs.
Un client de SGBDR est une application qui accède aux informations distribuées
par les interfaces du SGBDR.
Un serveur de SGBDR est un SGBD gérant une base de données locale intégrée
dans une base de données répartie.
Au-delà des notions de client de SGBDR et de serveur, un calculateur gérant la base est
appelé nœud ou site. Un site peut être à la fois client et serveur du SGBDR : il exécute
l’application et gère une partie de la base. C’est sans doute le cas le plus fréquent.
Nœud ou site de SGBDR est un calculateur dans le réseau participant à la gestion d’une
base de données repartie.
En résumé, un SGBDR est donc un ensemble de logiciels systèmes gérant des données
reparties sur un ensemble de sites intégrant des modules clients et des modules serveurs.
2.2.2. OBJECTIFS DES SGBDR
Nous précisons les objectifs des SGBDR qui se résument aux aspects clés suivants :
✓ Multi clients multi serveurs ;

✓ Transparence à la localisation des données ;
✓ Meilleure disponibilité des données ;
✓ Autonomie locale des sites ;
✓ Support de l’hétérogénéité.
a. Multi clients multi serveurs
Dans le contexte du client serveur, un client peut demander l’exécution d’une

requête à un serveur. La requête, appelée requête distante peut par exemple être
exprimée en SQL. Bien un SGBDR doit permettre l’accès simultané de plusieurs clients
aux données. Pour assurer l’objectif multi clients, le SGBDR doit fournir des mécanismes
de contrôle de concurrence adapté, garantissant que l’effet de l’exécution simultanée
des transactions est le même que celui d’une exécution séquentielle : cette propriété est
appelée la sérialisabilité des transactions.
Au-delà un SGBDR doit permettre l’exécution de requête distribuée, mettant en jeu

plusieurs serveurs. Une transaction qui met en œuvre plusieurs serveurs et appelée
transaction distribuée. A noter qu’une transaction distribuée peut simplement être
composée de plusieurs requêtes distantes, chacune étant exécutée par un serveur
différent. Souvent, une transaction distribuée comportera des requêtes distribuées.

14
b. Transparence à la localisation des données
Un des objectifs clé de SGBDR est de permettre d’écrire des programmes

d’application sans connaître la localisation physique des données. Dans ce but, les noms
des objets (par exemple le nom des tables) doivent être indépendants de leurs
localisations. Les requêtes seront en général exprimées en SQL de manière similaire aux
requêtes locales. Elles référenceront des vues de la base repartie ; ces vues porteront un
nom ne concernant pas la localisation des données.
c. Meilleure disponibilité
Une des justifications essentielles d’un SGBDR est sans doute l’apport en matière de
disponibilité des données. Tout d’abord, la répartition permet de ne plus dépendre d’un
site central unique. Surtout, elle permet de gérer des copies, de se replier sur une copie
lorsqu’une autre est indisponible (site en panne), et même mettre à jour de manière
indépendante les copies.
Les copies deviennent alors des réplicas qui peuvent évoluer indépendamment pour
converger ultérieurement. Cette fonctionnalité appelée réplication.
Assurer une meilleure disponibilité des données, c’est aussi garantir l’atomicité des
transactions. Une transaction est en effet un ensemble de requêtes, dont certaines sont
des mises à jour. Ces requêtes plus particulièrement les mises à jour doivent être toutes
correctement exécutées ou aucune ne doit l’être. Dans le cas contraire, la base de
données repartie serait seulement partiellement mise à jour.
d. Autonomie locale
Un autre objectif des SGBDR est d’éviter la nécessité d’une administration centralisée
des bases. L’autonomie locale vise à garder une administration locale séparée et
indépendante pour chaque serveur participant à la BD répartie. Ainsi, les reprises après
panne doivent être accomplies localement et ne pas impacter les autres sites. Les mises
à niveau de logiciel sur un site doivent être possible sans impacter les autres les autres
sites. Bien que chaque base puisse travailler avec les autres, les gestions de schéma
doivent rester indépendantes.

15
Figure 2-2 : Autonomie Locale des sites

e. Hétérogénéité
Un SGBDR hétérogène doit être capable d’unifier modèles et langage comme

représenté Figure suivante. Ceci afin de gérer des bases fédérées. L’unification s’effectue
en général par un langage pivot afin de limiter le nombre de conversion de modèle à
réaliser.
Figure 2-3 : Hétérogénéité

Un système de bases de données réparties ne doit en aucun cas être confondu
avec un système dans lequel les bases de données sont accessibles à distance (selon le
principe client server). Il ne doit non plus être confondu avec un système multi base.
Dans ce dernier cas, chaque utilisateur accède à différentes bases de données en
spécifiant leur nom et adresse, et le système se comporte alors simplement comme un
serveur de bases données et n’apporte aucune fonctionnalité particulière à la répartition.
Au contraire, un système de bases de données réparties est suffisamment complet pour
décharger les utilisateurs de tous les programmes de concurrence, fiabilité, optimisation
de requêtes ou transaction sur plusieurs sites.
Par exemple, une banque peut posséder des agences à Lubumbashi et à Kananga. Dans
une base de données centralisée, le siège social de la banque gérerait tous les comptes

16
des clients et les agences devraient communiquer avec le siège social pour avoir accès
aux données.
Dans une base de données réparties, les informations sur les comptes sont distribuées
dans les agences celle-ci sont interconnectées (entièrement ou partiellement) afin qu’elles
puissent avoir accès aux données externes. Cependant, la répartition de la base de
données bancaire est invisible aux agences en tant qu’utilisateur, et la seule conséquence
directe pour elle est que l’accès à certaines données est beaucoup plus rapide.
2.2.3. Quelques SGBDR
Il existe plusieurs systèmes de gestion de bases de données répartie, parmi lesquels nous
pouvons citer :
✓ SQL Serveur
✓ Oracle
✓ Etc.
2.3. Conception d’une base de données répartie
La définition du schéma de répartition est la partie la plus délicate de la phase de

conception d'une BDR car il n'existe pas de méthode miracle pour trouver la solution
optimale.
L'administrateur doit donc prendre des décisions en fonction de critères techniques et
organisationnels avec pour objectif de minimiser le nombre de transferts entre sites, les
temps de transfert, le volume de données transférées, les temps moyens de traitement
des requêtes, le nombre de copies de fragments, etc...
Deux approches existent pour la conception des BDR, notamment : l’approche par
décomposition (Conception descendante) et l’approche par intégration (Conception
ascendante).
BDR
Décomposition
Intégration
BD1 BD2 BDn

…
Approches de conception d’une Base de données Répartie
2.3.1. Conception descendante ( top down design)
On commence par définir un schéma conceptuel global de la base de données

répartie, puis on distribue sur les différents sites des schémas conceptuels locaux.

17
La répartition se fait donc en deux étapes, en première étape la fragmentation, et en

deuxième étape l’allocation de ces fragments aux sites.
L’approche top down est intéressante quand on part du néant. Si les BDs existent déjà
la méthode bottom up est utilisée.
Figure 2-5 : Conception descendante
✓ Schéma conceptuel global

• Donne la description globale et unifiée de toutes les données de la BDR
(e.g., des relations globales)
• Indépendance à la répartition
✓ Schéma de placement
• Règles de correspondance avec les données locales
• Indépendance à la localisation, la fragmentation et la duplication
✓ Le schéma global fait partie du dictionnaire de la BDR et peut être conçu comme
une BDR (dupliqué ou fragmenté)
Exemple de schéma global
➢ Schéma conceptuel global

Client (nclient, nom, ville)
Cde (ncde, nclient, produit, qté)
➢ Schéma de placement
Client = Client1 @ Site1 U Client1 @ Site2
Cde = Cde @ Site3
2.3.2. Conception ascendante ( bottom up design)
L’approche se base sur le fait que la répartition est déjà faite, mais il faut réussir
à intégrer les différentes BDs existantes en une seule BD globale. En d’autres termes, les
schémas conceptuels locaux existent et il faut réussir à les unifier dans un s chéma
conceptuel global.

18
2.4. Fragmentation
La fragmentation est le processus de décomposition d'une base de donnée en un

ensemble de sous-bases de données. Cette décomposition doit être sans perte
d'information.
La fragmentation peut être coûteuse s’il existe des applications qui possèdent des besoins
opposés.
Les règles de fragmentation sont les suivantes :
1. La complétude : pour toute donnée d’une relation R, il existe un fragment Ri de

la relation R qui possède cette donnée.
2. La reconstruction : pour toute relation décomposée en un ensemble de fragments
Ri, il existe une opération de reconstruction.
2.4.1. Techniques de Fragmentation
Il existe plusieurs techniques de fragmentation, définies par l’unité de fragmentation.
a. Fragmentation horizontale
C’est la répartition des occurrence ou enregistrements des tables. Les occurrences d'une
même classe peuvent être réparties dans des fragments différents.
- L'opérateur de partitionnement est la sélection (σ)
- L'opérateur de recomposition est l'union (∪)
Dans l'exemple suivant, la table client peut être fractionnée en Client1 et

Client2 avec la fragmentation suivante
Client1 = σ[Ville = 'Kananga'] Client et Client2 = σ[Ville ≠ 'Kananga'] Client
La recomposition de Client est Client1 ∪ Client2
b. Fragmentation verticale
C’est la répartition des attributs ou champs des tables. Toutes les valeurs des
occurrences pour un même attribut se trouvent dans le même fragment. Une

19
fragmentation verticale est utile pour distribuer les parties des données sur le site où
chacune de ces parties est utilisée.
- L'opérateur de partitionnement est la projection (π)
- L'opérateur de recomposition est la jointure (*)
Soit le partitionnement de la table Commande en deux tables :
c. Fragmentation hybride
Répartition des valeurs. C'est la combinaison des deux fragmentations précédentes,

horizontale et verticale.
Les occurrences et les attributs peuvent donc être répartis dans des partitions différentes.
2.4.2. Allocation des fragments aux sites

Après allocation, les fragments peuvent être :
➢ Non-dupliquée
• Partitionnée : chaque fragment réside sur un seul site
➢ Dupliquée
• Chaque fragment sur un ou plusieurs sites
• Maintien de la cohérence des copies multiples
Exemple d'allocation de fragments

20
2.5. Notion de transaction répartie
2.5.1. Définition
Une transaction est un fragment de programme dont l’exécution fait passer une BD
d’un état cohérent à un autre état cohérent.
Une transaction est une suite d’événements dont chacun peut être :
✓ la lecture ou l’écriture d’une donnée,
✓ le verrouillage ou le déverrouillage d’une donnée,
✓ le démarrage ou l’arrêt de la transaction.
Une transaction désigne un ensemble de requête (au moins une) appliqué sur la base de
données et respectant les propriétés ACID (atomicité, cohérence, isolation, durabilité).
2.5.2. Evénements d’une transaction
Exemple de transaction

21
2.5.3. Propriétés des transactions
Une transaction est composée d’une suite de requêtes dépendantes de la base qui
doivent vérifier les propriétés d’atomicité, de cohérence, d’isolation et de durabilité,
résumées par le vocable ACID.
a. Atomicité
Une transaction doit effectuer toutes ses mises à jour ou ne rien faire du tout. En cas
d’échec, une transaction doit annuler toutes les modifications qu’elle a engagées.
✓ Soit toutes les modifications effectuées par une transaction sont enregistrées dans
la BD, soit aucune ne l’est.
✓ Si une transaction est confirmée (commit) toutes les modifications qu’elle a
effectuées sont enregistrées dans la BD et rendues visibles aux autres utilisateurs.
✓ Si une transaction est interrompue alors aucune de ces modifications n’est
enregistrée dans la BD.
Cette propriété signifie qu’une transaction est traitée comme une seule opération.
Toutes les actions d’une transaction sont donc menées à bien ou aucune d’entre elles.
C’est le tout ou rien.
b. Cohérence
Une transaction fait passer une BD d’un état cohérent à un autre état cohérent. Un état
cohérent est un état dans lequel les contraintes d’intégrité sont vérifiées.
En cas d’échec, l’état cohérent initial doit être restauré. La cohérence d’une transaction
est simplement sa correction. En d’autre terme, une transaction est un programme
correct qui amène la base de données d’un état cohérent à un autre état cohérent.
c. Isolation
Une transaction se déroule sans être perturbée par les transactions concurrentes :
tout se passe comme si elle se déroulait seule.
Les résultats d’une transaction ne doivent être visibles aux autres transactions qu’une fois
la transaction validée. Ceci permet d’éviter les interférences avec les autres transactions.
L’isolation est la propriété qui impose à chaque transaction en train de s’exécuter de ne
donc pas révéler ses résultats à d’autres transactions concurrentes (simultanées) avant
d’avoir d’effectuer son commit.
d. Durabilité
Une fois qu’une transaction a été confirmée le SGBD garantit qu’aucune modification
qu’elle a effectuée ne sera perdue quelque soient les accidents qui surviendront :
interruption, pannes du système d’exploitation, « crash » de disque, etc.

22
2.5.4. Protocole de Validation en deux phases.
a. Principe
Le protocole de validation en deux phases a été proposé afin de coordonner

l’exécution des commandes « COMMIT » par tous les sites participants à une transaction.
Le principe consiste à diviser la validation en deux phases.
✓ La phase 1 réalise la préparation de l’écriture des résultats des mises à jour dans
la BD et la centralisation du contrôle.
✓ La phase 2, réalisée seulement en cas de succès de phase 1 intègre effectivement
les résultats des mises à jour dans la BD répartie.
Le contrôle du système réparti est centralisé sous la direction d’un site appelé
coordinateur, les autres étant des participants.
Nous résumons ces concepts ci-dessous.
o Protocole de validation en deux étapes (TWO STEP commit) : C’est un protocole

permettant de garantir l’atomicité des transactions dans un système reparti.
Composé d’une préparation de la validation et de centralisation du contrôle et
d’une étape d’exécution.
o Coordinateur de validation (commit coordination) : Nœud d’un système réparti
qui dirige le protocole en centralisant le contrôle.
o Participant à la validation (commit participant) : Nœud d’un système réparti qui
exécute des mises à jour de la transaction et obéit aux commandes de
préparation, validation ou annulation du coordinateur.
b. Début et fin d’une transaction
La fin d’une transaction est définie par l’un des ordres ci-dessous : COMMIT ou
ROLLBACK.

23
Une transaction commence à l’ouverture de la session ou à la fin de la précédente

transaction, il est donc clair de voir que la première transaction débute au lancement du
programme, il n’existe pas donc d’ordre implicite pour le début de la transaction.
▪ COMMIT : termine une transaction par la validation des données. A ce niveau,

les modifications sont définitives, sauvegardé dans une base de données et
peuvent être accessibles par d’autres utilisateurs (tous).
▪ ROLLBACK : termine une transaction en annulant toutes les modifications de
données effectuées.
c. Structure d’une transaction
Il est possible de subdiviser en plusieurs étapes une transaction en sauvegardant les

modifications à la fin de chaque étape, tout en gardant la possibilité de valider ou
d’annuler une partie ou toutes les mises à jour à la fin de la transaction.
2.6. SQL Serveur par la pratique
2.6.1. Création d’une base de données avec SQL Serveur
On va essayer dans cette section de créer une base de données sur SQL Server 2008
à l'aide de SQL Server Management, et on va introduire des données dans cette base.
Ce document va permettre aux utilisateurs de facilité le travail sur SQL Server et leur
montre comment exploité les principales fonctionnalités de l'outil SQL Server
Management.
a. Présentation de la base de données à réaliser

On va créer une petite base de données qui sera utilisée pour trier des films selon leurs
genres et leurs réalisateurs.

24
Cette base comme le montre l'exemple comporte 3 tables, la table film, la table
réalisateur et la table genre (fig-1).
Fig-1
• Chaque réalisateur doit avoir un identifiant en plus de son nom et son prénom.
• On doit spécifier le genre du film et lui donner un identifiant.
• Pour chaque film on doit donner un identifiant, et un titre. Le genre et le
réalisateur du film doivent être indiqués dans la table « film ».
• Chaque film doit être réalisé par un seul réalisateur et un réalisateur peut réaliser
plusieurs films.
• Chaque film à un seul genre et un seul genre peut être attribué à plusieurs films.
b. Création de la base sur SQL Server
On commence d'abord par lancer le logiciel à partir de l'icône de SQL Server

Management.
Pour se connecter au serveur en clique sur « Connect » de la fenêtre ci-dessous (fig-2).
Fig-2
Une nouvelle fenêtre s'ouvre, elle représente l'interface initiale de l'outil (fig-3).

25
Fig-3
On voit que cette fenêtre est devisée en deux parties, la partie gauche ou la fenêtre «
Explorer » qui nous affiche tous les objets du serveur et nous permet de naviguer entre
ces différents composants, la partie droite est une autre fenêtre qui nous montre les
données et les informations sous forme de sommaire.
Pour créer notre table on doit cliquer avec le bouton droit sur « Databases » dans la
fenêtre « Explorer », puis on clique sur « New Database » (fig-4).
Fig-4
Dans la nouvelle fenêtre qui s'affiche, on va donner le nom « FILM » à notre base puis
on clique sur « Ok » (fig-5).

26
Fig-5
On peut voir maintenant à partir de la fenêtre « Explorer » que notre base est créée (fig-
6).
Fig-6
b.1. Création des tables
On sait que notre base doit contenir 3 tables, on va commencer de les créer maintenant.
Toujours dans la fenêtre « Explorer » on clique avec le bouton droit sur « Tables » dans
notre base « FILM», puis on clique sur « New Table » (fig-7).

27
Fig-7
A droite et à la même place de la fenêtre « Sommaire » une nouvelle fenêtre s'ouvre,
dans laquelle on doit saisir toutes les colonnes de la table (fig-8).
Fig-8
Après avoir saisie tous ces données on ferme cette fenêtre. Une nouvelle fenêtre s'ouvre
et nous demande si on veut enregistrer les changements effectués, on clique alors sur «
Yes » pour confirmer (fig-9).
Fig-9
Une autre fenêtre s'ouvre, dans laquelle on va saisir le nom de la table désirée puis on
clique sur « Ok » (fig-10).
Fig-10

28
On refait les mêmes étapes avec les tables « Réalisateur » et « Genre » comme le montre
les deux figures ci-dessous (fig-11) et (fig-12).
Fig-11
Fig-12
Nos trois tables sont maintenant créées, pour vérifier que la création est bien réalisée on
peut naviguer dans la fenêtre « Explorer et voir si nos trois tables existent vraiment (fig-
13).
Fig-13
On voit bien que les trois tables sont créées sur notre base.
✓ Clés primaires
Notre base est formée de 3 tables chacune des tables doit contenir une clé primaire.
Dans l'étape suivante on va créer ces clés.
Commençant par la table « Film », cette table a comme clé primaire la colonne « Id film
».
A partir de la fenêtre « Explorer » on va aller sur la colonne « Id film », un clic droit puis
on clique sur « Modify » (fig-14).

29
Fig-14
Cette table va s'afficher dans la fenêtre à droite, on sélectionne la colonne qu'on veut
définir comme clé primaire puis dans la barre en haut on doit cliquer sur .
On remarque qu'une petite clé jaune s'affiche à coté de cette colonne (fig-15).
Fig-15
Lorsqu'on ferme cette fenêtre une autre fenêtre s'affiche pour vérifier si on veut
enregistrer les changements, alors on clique sur « Yes » (fig-16).
Fig-16
Dans la fenêtre « Explorer » on peut vérifier si la création da la clé primaire est réalisée
correctement ou non (fig-17).

30
Fig-17 Alors voilà comment doit s'afficher la clé primaire.

On refait le même travail pour les autres tables (fig-18) (fig-19).
Fig-18
Fig-19 Voilà maintenant toutes les clés primaires sont créées.

✓ Clés étrangères
On sait que notre base contient 3 tables, mais uniquement la table « Film » contient des
clés étrangères.
On va voir maintenant comment créer une clé étrangère dans SQL Server.
On commence par un clic droit sur «Keys» dans la fenêtre « Explorer » puis on clique sur
«New Foreign Key » (fig-20).
Fig-20
Dans la nouvelle fenêtre qui s'ouvre, on va commencer par donner un nom à cette clé
étrangère « FK_Film_Réalisateur » (fig-21).

31
Fig-21
Apres on clique sur « Tables And Columns Specification », et une nouvelle fenêtre s'ouvre
dans laquelle on va définir la clé étrangère et la clé primaire puis on clique sur « OK »
(fig-22).
Fig-22
Lorsqu'on revient à la fenêtre suivante on peut modifier et mettre « en cascade »
pour les relations entre la clé étrangère et la clé primaire pour la suppression et les
mises à jour (fig-23) puis on clique sur « Close ».
Fig-23
On ferme cette table un message pour l'enregistrement s'affiche on clique alors sur « Yes
» et une autre fenêtre s'affiche pour nous informer qu'il a eu des changements dans deux
tables de notre base on clique sur « Yes » pour enregistrer (fig-24).

32
Fig-24
On peut vérifier maintenant, dans la fenêtre « Explorer », l'existence de notre clé
étrangère (fig-25).
Fig-25
On refait le même travail pour créer notre deuxième clé étrangère la clé « Id_Film_Genre
».
Notre table doit contenir à la fin une clé primaire et deux clés étrangères (fig-26).
Fig-26
On peut dire maintenant que notre base est complète et il ne reste qu'à saisir des
données dans cette base.
c. Saisir les données dans les tables
On va commencer par saisir les données dans la table genre.
Un clic droit sur la table « Genre » puis on clique sur « Edit Top 200 Rows » (fig-27).

33
Fig-27
La table va s'ouvrir à droite et on saisi les données comme dans l'exemple ci-dessous (fig-
28).
Fig-28
On remarque que notre base va comporter 4 genres de film à savoir : Action, Comédie,
Romantique et dramatique.
Les numéros de 1 à 4 sont les identificateurs de chaque genre.
Maintenant comme la table de genre est créée on va passer à la table de réalisateur.
Pour cela on va refaire le même travail et on saisi les données pour que la table se
présente de la façon suivante (fig-29).

34
Fig-29 Ainsi la liste des réalisateurs est prête.

Maintenant lorsqu'on remplit la table « Film » il faut juste préciser l'identificateur du
genre et celui de réalisateur.
Donc on refait les mêmes étapes pour saisir des données dans la table « Film » pour
qu'elle s'affiche de la façon suivante (fig-30).
Fig-30

35
d. Exemple de requêtes
On va voir maintenant comment on peut utiliser les requêtes sur SQL Server et exécuter
quelques exemples de ces requêtes.
On va essayer d'afficher les films réalisés par l'un des réalisateurs de notre table.
D'abord il faut trouver l'identifiant du réalisateur dans la table « Réalisateur », par

exemple le réalisateur « John Woo ».
On clique sur une nouvelle fenêtre s'ouvre à droite et on saisi la requête

suivante
SELECT * FROM
[FILM]. [dbo].[Réalisateur] where [Prénom]= 'John' and [Nom]= 'Woo' »
puis on clique sur

voir (fig-31).
Fig-31
En exécutant le résultat va s'affiché en bas (fig-32).
Fig-32
Maintenant on connait l'identifiant de ce réalisateur on peut alors chercher tous ses films
dans la table « Film » par la requête suivante « SELECT * from [FILM].[dbo].[Film]
WHERE [Id_réalisateur] = 2 » « fig-33 ».
Fig-33 Le résultat suivant s'affiche (fig-34).

36
Fig-34
2.6.2. Connexion C# et Sql Serveur
2.7. Introduction au Transact Sql
2.7.1. Qu'est-ce que Transact-SQL ?
Transact-SQL (ou encore appelé T-SQL) est un langage de programmation

procédural database. Il est le monopole de Microsoft, qui est utilisé dans SQL Server.
Le T-SQL (Transact Structured Query Langage) est un langage de communication avec
une base de données relationnelle SQL Server. Il définit une batterie « simple » mais
complète de toutes les opérations exécutables sur une base de données (lecture de
données, opérations d’administration du serveur, ajout, suppression et mises à jour
d’objets SQL - tables, vues, procédures stockées, déclencheurs, types de données
personnalisés … -).
Ce langage est composé d’instructions, réparties dans de 3 catégories distinctes :
✓ DML : Data Modification Language, soit langage de manipulation de données.

Dans cette catégorie, s’inscrivent les instructions telles que l’instruction SELECT
ou encore les instructions qui nous permettent la création, la mise à jour et la
suppression de données stockées dans les tables de la base de données. Il est
important de retenir que le DML sert simplement pour les données, et en aucun
cas pour la création, mise à jour ou suppression d’objets dans la base de données
SQL Server.
✓ DDL : Data Definition Language, soit langage de définition de données . Les

instructions de cette catégorie, permettent d’administrer la base de données, ainsi
que les objets qu’elle contient. Elles ne permettent pas de travailler sur les
données.
✓ DCL : Data Control Language, soit langage de contrôle d’accès . Cette catégorie
d’instructions nous permet de gérer les accès (autorisations) aux données, aux
objets SQL, aux transactions et aux configurations générales de la base.
Ces trois catégories combinées permettent que le langage T-SQL prenne en compte des
fonctionnalités algorithmiques, et admette la programmabilité. Le T-SQL est non
seulement un langage de requêtage, mais aussi un vrai langage de programmation à part
entière. Sa capacité à écrire des procédures stockées et des déclencheurs (Triggers), lui
permet d’être utilisé dans un environnement client de type .NET, au travers d’une
application en C# ou en VB.NET.
2.7.2. Quelques instructions DML

37
Pour toutes les instructions du DML, il existe dans SQL Server un outil simple pour
retrouver la syntaxe voulue rapidement (Pour des instructions simples, telle le SELECT,
UPDATE…). La démarche est simple. Via le menu contextuel d’une table, sélectionnez « Générer
un script de la table en tant que… ». Il nous est alors proposé de sélectionner l’action que nous
voulons accomplir : SELECT, INSERT, UPDATE ou DELETE. Cette action peut aussi être réalisée
sur d’autres objets SQL de la base de données.
a. Création, modification et suppression de données
a.1. L’instruction INSERT
L’instruction INSERT, comme son nom l’indique, va nous permettre d’ajouter

une ligne de données dans une table de la base de données. Le code générique, d’ajout
d’une ligne de données est la suivante :
Dans ce code générique, nous demandons à SQL Server d’ajouter un enregistrement à

la table Client, appartenant au schéma dbo dans la base de données Entreprise.
Pour préciser les colonnes pour lesquelles nous allons ajouter des données, il est
nécessaire de préciser le nom des colonnes, après l’instruction INSERT INTO.
Le mot clé VALUES nous permet de fournir des valeurs aux champs. Il est impératif que
les valeurs soient dans le même ordre que celui des colonnes, tout d’abord pour la
cohérence des données, mais aussi pour respecter la compatibilité des données avec le
type que vous avez assigné à votre table au moment de sa création.
Dans le cas où certaines de vos colonnes acceptent des valeurs NULL, il existe deux
méthodes pour obtenir cette valeur. La première, est d’omettre le nom de la colonne et
la valeur correspondante dans l’instruction. La seconde vise à laisser la colonne dans la
description, mais à préciser le mot clé NULL dans la clause VALUES.
Pour des chaines de caractères, il faut placer celles-ci entre simples cotes.
Dans le cas d’un champ de type identité (possédant une incrémentation automatique
grâce à la contrainte IDENTITY), il n’est pas nécessaire de spécifier ni le nom du champ,
ni sa valeur.

38
Procédons à un exemple pour mieux comprendre :
La fenêtre suivante s’ouvre :
C’est à nous de remplacer la partie « Values » par les éléments que nous voulons insérer
dans notre table.

39
Et ensuite cliquer sur le bouton « Exécuter ».
a.2. L’instruction UPDATE
L’instruction UPDATE, permet de mettre à jour un ou plusieurs enregistrements.

La syntaxe générique de cette instruction est la suivante :
Voici une instruction SQL permettant de modifier le nom de ce client dont le Id-Client
vaut 3 :
a. 3. L’instruction DELETE
L’instruction DELETE permet de supprimer des enregistrements. La syntaxe

générique est la suivante :

40
L’instruction DELETE FROM va permettre la suppression de données dans la table Client

de la base de données Entreprise, dans la seule condition que les contraintes dans
WHERE soient respectées. Voici une instruction permettant de supprimer
l’enregistrement de la table Client dont l’identifiant est 4 :
b. Lire et trier des données

b.1 L’instruction SELECT
L’instruction SELECT permet de sélectionner des données (tout ou partie

d’enregistrements), d’une ou plusieurs tables. Elle offre aussi la possibilité de les trier, et
de les regrouper. La syntaxe générale de cette instruction est la suivante :
Voici une instruction SELECT permettant de lire le Prénom et Numéro de tous les clients
(si notre but avait été de sélectionner toutes les colonnes, au lieu de lister toutes celles -
ci, il est possible d’indiquer que nous les sélectionnons toutes avec le simple caractère «
* ») :
b.2. Changer le nom des colonnes (ALIAS)

Par défaut, le nom de la colonne est celui du nom de la colonne dans la table. Il est
possible d’en changer en utilisant des alias. Voici un exemple d’utilisation d’alias :

41
c. La condition WHERE
Il est alors possible d’ajouter des conditions à notre recherche pour l’affiner, au
travers de la clause WHERE. Les restrictions servent à limiter le nombre
d’enregistrements à sélectionner. Les conditions contenues dans le WHERE sont des
expressions booléennes qui peuvent être composées de noms de colonnes, de
constantes, de fonctions, d’opérateurs de comparaison et d’opérateurs logiques.
Prenons un exemple concret :
Cette instruction SELECT sélectionne tous les champs de tous les enregistrements pour
lesquels la colonne Id_Client est égale soit à 1, 2, 3 et 6. On remarque alors que dans

42
notre code, nous avons utilisé la condition WHERE, une colonne, un opérateur de
comparaison et un opérateur logique.
L’instruction ci-dessus présente l’utilisation des clauses WHERE et BETWEEN, qui permet
de lire tous les enregistrements dont l’identifiant est compris entre 1 et 10 (bornes
incluses).
2.7.3. Le SQL Procédural

a. Les variables
Une variable est une zone mémoire caractérisée par un type et un nom, et
permettant de stocker une valeur respectant le type. Dans SQL Server, les variables
doivent être obligatoirement déclarées avant d’être utilisée.
Voici la déclaration d’une variable nommée Id_Client de type Int :
L’instruction suivante permet de valoriser cette variable via l’exécution d’une requête
scalaire :
Voici un bloc d'une déclaration simple, somme de deux nombres effectué en Transact
Sql:
Il suffit de faire un clic droit sur votre base de données et choisir « nouvelle requete »

43
Puis écrire le code suivant et l’exécuter:

44
b. La commande du marquage If-elsif-else
Syntaxe:
IF <condition 1> THEN

Job 1;
[ELSIF <condition 2> THEN
Job 2;
]
[ELSE
Job n + 1;
]
ENDIF;
Exemple:
c. La boucle WHILE
Syntax:
LOOP
-- Do something here
EXIT WHEN<Condition>;
ENDLOOP ;
Dans la boucle WHILE, vous pouvez utiliser BREAK afin de sortir de la boucle.
Utiliser CONTINUE pour sauter les déclarations dans le bloc WHILE et au-dessous de
lui, afin de continuer une nouvelle boucle.

45
Exemple :
d. Affecter des valeurs aux variables à partir de l'instruction Select
Les variables peuvent être affectées à la valeur d'une requête. Voici un exemple
illustratif:

46
2.7.4. Quelques Instructions DDL

a. Créer une table avec du Code T-SQL
L’ajout de tables peut se faire avec du code ou bien, avec l’interface graphique.
Nous allons cette fois ci utiliser du code T-SQL.
Le mot clé CREATE TABLE va bien entendu nous permettre de créer une table dans la
base de données dans laquelle nous nous sommes rendus au préalable.
Après cela, on placera entre parenthèses les colonnes que l’on veut créer, caractérisées
par leur nom et le type de données qu’elles supportent. Il est aussi nécessaire de spécifier,
si la colonne en question supporte ou non la valeur NULL. Lorsque vous aurez spécifié
toutes ces caractéristiques, vous pouvez compiler votre code en appuyant sur F5 ou en
cliquant sur la touche d’exécution du code. Vous aurez un message de validation de
votre requête.
Lors de la création de la table, il est possible de créer les contraintes d’intégrités,
conformément à une base de données relationnelle qui sont les différents types de clés,
mais aussi les contraintes telles que UNIQUE, IDENTITY…
✓ IDENTITY : Ce type de contrainte peut être affectée à une colonne par table, de
type numérique entier. Elle permet d’incrémenter les valeurs d’une colonne, ligne
après ligne. Par défaut, la contrainte IDENTITY part de 1, et a un pas d’incrément
de 1. Il est possible de changer la valeur de départ et le pas d’incrément.
✓ PRIMARY KEY : Cette contrainte permet de définir une clé primaire sur une ou
plusieurs colonnes d’une table. Il ne peut y avoir qu’une seule clé primaire par
table, et la ou les colonnes sur lesquelles elle est définie doivent être de type NOT
NULL. Il est important de noter que lorsque nous créons une clé primaire, un
index unique est créé, on peut donc considérer que les actions disponibles sur les
indexes sont aussi disponibles lors de la création d’une clé primaire.
✓ UNIQUE La contrainte UNIQUE comme son nom l’indique, va nous permettre

de préciser sur une colonne, si les valeurs contenues dans celle-ci ne doivent pas
être dupliquées dans plusieurs enregistrements. De ce fait, il ne sera pas possible
avec une contrainte unique d’avoir deux fois une même valeur pour une colonne
donnée. Enfin, contrairement à une table possédant une clé primaire, une table
peu avoir plusieurs colonnes concernées par une contrainte UNIQUE.
Lorsqu’une contrainte de ce type est définie, l’intégrité est gérée par un index de
type UNIQUE créé en simultané. La définition d’une contrainte UNIQUE est

47
simple avec du code T-SQL, puisque c’est de la même manière que nous avons
créé notre clé primaire.
b. Supprimer une table
La structure de suppression de table avec du code T-SQL est la suivante.
On indique que nous allons travailler dans la base de données Test.
On précise alors que dans cette table Test, grâce à l’instruction DROP TABLE, nous allons
supprimer la table Client dont le schéma est dbo. Après avoir exécuté ce code, on peut
remarquer que la table que nous avons précisée après l’instruction DROP TABLE n’existe
plus.
2.7.5. Les Transactions
Une transaction est caractérisée par le mot l’acronyme ACID (Atomic Consistency
Isolation Durability) :
✓ Atomique car la transaction constitue une unité indivisible de travail pour le

serveur.
✓ Consistance car à la fin d’une transaction, les données montrées sont soit celles
d’avant transaction (dans le cas d’une annulation de la transaction) soit celle
d’après transaction (dans le cas d’une validation).
✓ Isolation, car il est possible de verrouiller (isoler) les données pendant l’exécution
de la transaction (verrouillage en lecture, en écriture, …).
✓ Durée car les changements apportés sur des données par une transaction sont
durables (non volatiles).
La syntaxe générique d’une transaction est la suivante :

48
Pourquoi doit le traitement de la transaction ?
Voyons une situation :

Dans une transaction bancaire, une personne A transfère une somme de 100
dollars à personne B. À ce moment-là, dans la base de données, il y a deux
manipulations :
✓ Débit 100 dollars du compte d'une personne

✓ Crédit 100 dollars du compte de la personne B
Que se passerait-il si une seule manipulation réussissait ?
Voir un exemple :
Lorsque vous ajoutez un élève à une classe, vous devez mettre à jour le nombre d'élèves.
Si l'insertion de l'information des élèves échoue, mais le nombre d'élèves est ajouté 1,
intégralité des données est interrompue.
BEGIN
-- Dans cet exemple, les client dont les Id_Client sont = 1, 2 existent
actuemment dans la BD
-- Le champ Montan exist aussi

DECLARE @Id_A integer= 1;
DECLARE @Id_B integer= 2;
DECLARE @Somme int= 10;

-- Bank
DECLARE @Execute_Branch_Id integer= 1;
PRINT '@@TranCount = '+ CAST(@@Trancount AS varchar(5));
PRINT 'Begin transaction';
-- Begin transaction
BEGIN TRAN;
-- Error trapping.
BEGIN TRY
--

49
-- Subtract $10 from account A

UPDATE Client
SET Montan = Montan - @Somme
WHERE Id_Client = @Id_A;
-- Add $10 to Account B.
UPDATE Client
Montan = Montan + @Somme
WHERE Id_Client = @Id_B;
--
IF @@Trancount > 0
PRINT 'Commit Transaction';
COMMIT TRAN;
END TRY
-- If there are errors Catch block will be execute.
BEGIN CATCH
PRINT 'Error: '+ ERROR_MESSAGE();
PRINT 'Error --> Rollback Transaction';
IF @@Trancount > 0
ROLLBACK TRAN;
END CATCH;
END;
Ici, dans notre exemple, nous avons deux transactions imbriquées. Il est très important
de comprendre qu’une transaction est une unité indissociable, et que par conséquent, il
est nécessaire de terminer par un COMMIT ou ROLLBACK, la dernière transaction en
date.
La fermeture des transactions se fait donc celons un modèle LIFO (Last In First Out). La
dernière transaction écrite sera la première à devoir être fermée. Pour revenir à notre
exemple, on peu désormais dire que le nom client égal à Darell Ndaya sera changé par
Darell, du fait du COMMIT TRAN qui termine la transaction 2, alors que Nobla
Tshilumba ne sera pas changé par Gracia, dans transaction1, car celle-ci se termine par
un ROLLBACK TRAN.
Note Importante : Les instructions du DML doivent automatiquement comporter un

ROLLBACK TRAN pour être prises en compte et être appliquées, alors que les
instructions du DDL comportent un ROLLBACK TRAN implicite qui est opéré juste après
que l’instruction du DDL soit faite. Il faut donc faire très attention à la suite d’instructions
dans une transaction. Si jamais vous écrivez une transaction qui comporte deux
instructions, une du DML puis une du DDL, même si vous mettez un ROLLBACK à la
suite, les deux instructions seront « COMMIT », puisque les instructions du DDL
comporte ce ROLLBACK TRAN implicite dont nous avons parlé précédemment.

50
Chapitre 3 : Les Réplications
3.1. Définitions
La réplication est un Processus qui consiste à copier et à mettre à jour les
objets (tables, information, index, …) entre différents sites qui peuvent être éloigné
géographiquement. Cette mise à jour peut s’enclencher automatiquement ou
manuellement.
Un Réplica ou copie de données est un fragment horizontal ou vertical d’une
table stockée dans une base de données qui est copiée et transféré vers une autre base
de données. L’original est appelé la copie primaire et les copies sont appelées copies
secondaires.
Les applications clientes croient à l’existence d’une seule copie des données qu’ils
manipulent soit « logique » dans le cas d’une vue ou soit physique.
Les techniques de réplication permettent la gestion de copies multiples pouvant diverger
c’est – à – dire présenter des valeurs différentes à un instant donné, mais convergeant
vers les mêmes valeurs à termes. Nous examinons ci – dessous les différentes formes de
réplication possibles et les techniques de gestion de la cohérence des copies associées.
La réplication utilise la technologie de bd distribuées pour partager les données entre
multiples sites mais une bd répliquée et une bd distribuée sont différentes. Pour les bd
distribuées, les données sont disponibles à plusieurs endroits mais une table particulière
réside à un seul site. La réplication signifie que les mêmes données sont disponibles à
multiples endroits.
3.2. Forces et faiblesses de la réplication
3.2.1. Forces
La réplication améliore les performances et augmente la disponibilité des

données. Grâce à la réplication, les lectures sont exécutées sur le site disposant de la
copie la plus proche du client ce qui peut éviter des transferts inutiles, par exemple si le
client dispose d’une copie. Aussi bien pour les lectures que pour les écritures, la
réplication permet d’éviter le goulot d’étranglement que constitue le serveur unique en
partageant la charge. La réplication favorise aussi d’une part les lectures qui sont alors
locales, et d’autres par la résistance à la panne.
Du point de vu disponibilité, lors d’une panne d’un serveur, on peut se replier sur un
autre disposant d’une copie des données.
3.2.2. Faiblesses
Si la réplication présente de nombreux avantages, les problèmes soulevés sont

multiples. Tout d’abord, il faut assurer la convergence des copies. Si les copies peuvent
être différentes à un instant donné, elles doivent converger vers le même état cohérent
où toutes les mises à jour sont exécutées partout dans le même ordre. Ensuite, il faut
offrir la transparence de gestion aux utilisateurs. Les clients doivent croire à l’existence
d’une seule copie : en conséquence, le SGBD doit assurer la diffusion des mises à jour
aux copies et le choix de la meilleure copie lors des accès.

51
3.3. Exemple d’application de la réplication
En suivant ce principe, une entreprise disposant de plusieurs bureaux

régionaux pourra ainsi conserver les données du siège national. Les utilisateurs mobiles
équipés de pocket PC pourront travailler toute la journée, en étant déconnecté et
réaliser le soir une réplication dans le but de fusionner leur enregistrement avec ceux de
la base de données principale.
3.4. Types de réplication

Il y en a trois types de réplication :
✓ Réplication Multi- maître ;

✓ Réplication des clichés ;
✓ Réplication Hybrides.
3.4.1. La réplication multi - maîtres (encore appelée réplication peer-to-peer)
Elle permet à multiples sites, agissant comme des postes égaux, pour gérer des
groupes des objets de répliquées. Chaque site dans un environnement multi maître est
maître et chacun communique avec les autres sites maîtres ; les applications peuvent
mettre à jour n’importe quelle table répliquée à n’importe quel site dans la configuration
Ici une modification apportée sur un site (exemple : sur les données des tables) se
répercute directement sur tous les autres sites afin de préserver la cohérence des données
entre les bases.
Figure 3-1 : Réplication multi-maîtres

52
Exemple : Transaction bancaires, données météorologiques
3.4.2. Réplication des clichés
Elle consiste en l’utilisation de clichés (ang. snapshot). Un cliché représente un

état de la base de données à un instant donné.
Un site cliché ne peut être connecté qu’à un seul site maître. Ce dernier peut, suivant la
puissance de l’ordinateur, supporter plusieurs milliers sites clichés.
Figure 3-2 : Réplication des clichés

L’avantage de cette réplication est qu’elle peut contenir une copie complète ou partielle
(exemple : une table complète ou seulement quelques colonnes) des données d’une base
site maître à un instant donné.
Les mises à jour des clichés sur le site maître sont exécutées à un intervalle régulier.
Les variantes de ce type de réplication sont :
✓ Cliché en lecture seule (Read-Only materialized Views)

53
✓ Cliché modifiable (Updatable Materialized Views).

✓ Cliché en écriture (Writeable Materialized Views).
a. Cliché en lecture seule (Read-Only materialized Views)
C’est la forme la plus rencontrée et la plus basique car il s’agit d’une

réplication qui se déroule dans un seul sens. Ce type de cliché peut seulement être
interrogé et en aucun cas il ne peut être modifié par des ordres DML (data manipulation
language) (Update, delete, insert) ce qui donne l’avantage de ne pas avoir de conflit de
data entre les bases.
Force du cliché en lecture seul
Pas de conflit des données entre les bases ; le seul moyen de modifier les données
sur les clichés sur lecture seule est de modifier ces données sur la base maître, et c’est ce
dernier qui va se répercuter toutes ces données sur tous les sites.
b. Cliché modifiable (Updatable Materialized Views).
Permet aux utilisateurs d’insérer, de modifier et de supprimer des lignes de

table, grâce aux ordres DML du site maître en réalisant ces changements sur le cliché qui
propage ces modifications sur le site maître qui à son tour va provoquer des
modifications sur les sites maîtres éventuels.
b.1 Propriétés de la réplication par cliché modifiable :
✓ Elles s’appliquent toujours sur une seule table bien que plusieurs tables peuvent
être référencées dans la sous requête.
✓ Elles peuvent être rafraîchies de manière incrémentale.
b.2 Force de la réplication par clichés modifiables:
✓ Permet aux users d’effectuer des insert ou update sur le site répliqué même si la
connexion avec le site maître est coupée.
✓ Exige moins de ressources que pour la réplication multi maître même pendant les
mises à jour.
3.5. Mise à jour synchrone et asynchrone
Jusque-là, nous avons supposé que toute mise à jour de la base demandée depuis
un nœud fût effectuée en temps réel sur les autres nœuds, c'est-à-dire pour le compte
de la même transaction atomique. Ceci correspond au mode de mise à jour synchrone
qui s'avère souvent trop contraignant pour les applications.

54
3.5.1. Mise à jour synchrone
C'est le mode de distribution dans lequel toutes les sous opérations locales
effectuées suite à une mise à jour globale sont accomplies pour le compte de la même
transaction.
Dans le contexte des copies, ce mode de distribution est très utile lorsque les mises à
jour effectuées sur un site doivent être prises en compte immédiatement sur les autres
sites.
L'avantage essentiel de la mise à jour synchrone est de garder toutes les données au
dernier niveau de mise à jour. Le système peut alors garantir la fourniture de la dernière
version des données quel que soit la copie accédée.
Les inconvénients sont cependant multiples, ce qui conduit beaucoup d'application à

éviter la gestion de copies synchrones. Ce sont d'une part, la nécessité de gérer des
transactions multiples coûteuses en ressources et d'autre part, la complexité des
algorithmes de gestion de concurrence et de panne d'un site. C'est pour cela que l'on
préfère souvent le mode de mise à jour asynchrone (encore appelé mise à jour différée)
3.5.2. Mise à jour asynchrone
C'est le mode de distribution dans lequel certaines sous opérations locales

effectuées suite à une mise à jour globale sont accomplies dans des transactions
indépendantes en temps différé. Le temps de mise à jour des copies peut être plus au
moins différé : les transactions de report peuvent être lancées dès que possible ou à des
instants fixes, par exemple le soir ou en fin de semaine.
Les avantages sont la possibilité de mettre à jour en temps choisi des données, tout en
autorisant l'accès aux versions anciennes avant la mise à niveau.
Les inconvénients sont bien sûr que l'accès à la dernière version n'est pas garanti. Ce qui
limite les possibilités des mises à jour.
3.6. Technique de diffusion des mises à jour
La diffusion automatique des mises à jour appliquée à une copie aux autres copies
doit être assurée par le SGBD réparti. Plusieurs techniques de diffusion sont possibles
parmi lesquelles, on distinguera celles basées sur la diffusion de l'opération de mise à
jour, de celles basées sur la diffusion du résultat de l'opération.
Diffuser le résultat présente l'avantage de ne pas devoir ré exécuter l'opération sur le site
de la copie, mais l'inconvénient de nécessité un ordonnancement identique des mises à
jour en tous les sites afin d'éviter les pertes de mises à jour. Le report d'opération est
plus flexible, notamment dans le cas d'opérations commutatives.

55
3.6.1. Réplication asymétrique
Au-delà des techniques de diffusion des mises à jour se pose le problème du choix
de la copie sur laquelle appliquer les mises à jour. La réplication asymétrique rompt la
symétrie entre les copies en distinguant un site chargé de centraliser les mises à jour.
C’est une technique de gestion de copies basée sur un site primaire s eul autorisé à mettre
à jour et charger, de diffuser les mises à jour aux autres copies dites secondaires.
Le site primaire effectue les contrôles et garantit l’ordonnancement correct de mises à

jour. Ce mode de réplication convient bien aux applications à responsabilité centralisée.
Il permet la distribution de l’information centralisée, par exemple la diffusion des
catalogues, des listes de prix, etc. Il permet aussi la diffusion de données vers des
entrepôts pour l’aide au décisionnel et l’historisation.
Le choix d’une technique asymétrique est orthogonal au choix d’un mode de diffusion
synchrone ou asynchrone des mises à jour : on peut donc distinguer l’asymétrique
synchrone et l’asymétrique asynchrone.
La première technique (l’asymétrique synchrone) : Toute mise à jour est

d’abord appliquée à la copie primaire (site primaire), puis diffusée en temps réel vers les
sites secondaires.
Figure 3-3 : Mise à jour des copies asymétriques synchrones.
La deuxième (l’asymétrique asynchrone) : Toute mise à jour est d’abord

appliquée à la copie primaire (site primaire), puis diffusée en temps différé vers les sites
secondaires. Dans les deux cas, des problèmes surviennent lorsque le site primaire tombe
en panne.

56
Figure 3-4 : Mises à jour de copies asymétrie asynchrones.
Un problème de la gestion de copie asymétrique est donc la panne du site primaire.

Dans ce cas, il faut choisir un remplaçant si l’on veut continuer les mises à jour. Celui-ci
peut être fixé par l’administrateur ou élu par un protocole spécifique de vote
majoritaire.
On aboutit alors à une technique asymétrique mobile dans laquelle le site primaire
change dynamiquement selon des critères qui peuvent être liés à l’application. Le droit
de mise à jour se déplace de site en site, par exemple au fur et en mesure de l’évolution
des données.
3.6.2. Réplication symétrique
Technique de gestion de copies où chaque copie peut être mise à jour à tout
instant et assure la diffusion des mises à jour aux autres copies.
A l’opposé de la réplication asymétrique, la réplication symétrique ne privilégie aucune

copie. Elle permet les mises à jour simultanées de toutes les copies par les transactions
différentes.

57
Figure 3-5 : Exemple de symétrique synchrone.
Figure 3-6 : Exemple de symétrique asynchrone.
Convergence de copies symétriques
La convergence de copies asymétriques est assurée par le site maître. Celui – ci

règle les problèmes de concurrence et envoie les mises à jour dans l’ordre où ils les

58
appliquent aux sites secondaires. Encore faut – il que ces derniers appliquent les mises à
jours dans le bon ordre, ce qui peut présenter quelques difficultés facilement solubles.
Dans le cas de copies symétriques, la convergence est plus difficile à assurer. En effet, les
mises à jour simultanées risquent d’être accomplies dans un ordre différent sur une même
donnée. On obtient alors deux états différents : les copies divergent. La sérialisabilité de
l’exécution globale des transactions n’est pas respectée, d’où la divergence.
Des techniques applicables dans le cas de mise à jour synchrones découlent des
mécanismes de contrôle de concurrence étudiés ci – dessus. Ce sont :
✓ La prévention des conflits par verrouillage des copies : Le mécanisme consiste à

demander à toute transaction mettant à jour, d’obtenir un verrou en écriture sur
chacune des copies. Les risques de verrous mortels sont alors importants si
plusieurs transactions mettent à jour simultanément. Les verrous mortels peuvent
être prévenus en ordonnant l’ordre de visite des sites.
✓ La détection des conflits par ordonnancement des mises à jour :
L’ordonnancement s’effectue par un mécanisme d’estampillage ou de
certification comme vu ci – dessus. Le système doit alors utiliser des estampillages
synchronisés pour ne pas favoriser un site plutôt qu’un autre. Les risques de
reprises multiples de transactions sont importants.
Les deux mécanismes ci – dessus sont consommateurs en ressources et seulement

utilisables en synchrone.
En asynchrone, il est impossible de défaire des transactions validées. Les approches

proposées se contentent alors de détecter les conflits et de reporter ceux – ci vers
l’utilisateur qui doit alors mettre en œuvre une technique de résolutions de conflits.
3.7. Mise en œuvre de la réplication sous SQL Serveur 2
3.7.1. Installation de SQL Server

Les étapes présentées ci-dessous présentent une simplicité évidente pour une
installation assurément réussie. Méfiez-vous de clics, un moindre déraillement peut
mener à causer des échecs lors de la manipulation de certains services de SQL Server et
de certaines configurations.
Spécifications pour une installation réussie
Pour une installation et une manipulation de SQL Server 2008 assurément réussies,
veuillez trouver dans le tableau ci-dessus les spécifications par rapport aux matériels
minimums à avoir.
2
Cette présentation est tirée du support de cours du Prof. KAFUNDA, dans la partie des travaux pratiques réalisés
par les étudiants de l’Université KIM de Kinshasa.

59
C PU
- Processeur de 1GHz pour un Système d’Exploitation en 32
bit ;
- Processeur 1.6GHz pour un Système d’Exploitation en 64 bit.
Mais un processeur de 2 GHz est très vivement recommandé pour une bonne
performance et une rapidité de votre SQL Server
Mémoire
- Au minimum 512Mb, si SQL Server est le seul processus ; -
Sinon 1Gb de mémoire minimum est conseillé.
Pla ce disque dur

- Au minimum 1Gb pour seulement l’installation.
- Pour le stockage des bases de données, cela dépends de l’utilisation SQL
Server.
S ystème d ’exploitation
- Windows Vista
- Windows Xp 32-Bit, - Windows Server 2003 Sp2 - Windows Server
2008 32-Bit.
Il fonctionnera tout aussi bien sur des systèmes 64-Bit tels que :
- Windows Server 2003 - Windows Server 2008, - Windows XP Pro.
Ainsi sur les nouvelles versions de Windows :
- Windows 7
- Windows 8
Avant tout, signalons tout aussi que cette installation se déroule sur une machine dont
les propriétés sont les suivantes :
- Système d’Exploitation : Windows 7

- Processeur : Intel(R) Pentium(R) CPU B950 @ 2.10GHz 2.10 GHz
- Mémoire RAM : 4, 00 Go
- Type de système : 64 bits
De toutes manières, lors de l’installation, le programme d’installation, lui-même, va

vérifier la compatibilité de la version du SQL Server et la du système d’exploitation sur
lequel vous voulez l’installer.
Les étapes ne sont pas beaucoup commentées, car sur chaque interface des étapes, il y
a des explications inhérentes sur l’image.
a) Lancement de l’installation

60
b) Installation d’une nouvelle instance
Lorsque vous cliquerez sur le [2], vous trouverez un assistant qui vous permettra
d’installer une première instance de SQL Server, sinon d’en ajouter tant d’autres ou
des nouvelles fonctionnalités à une instance déjà existant.
c) Vérification de règles de support

61
d) Choisir la version de SQL Server
Et sur cette page, vous avez la possibilité de choisir les éditions que vous
voudrez bien installer :
Version :

62
- Entreprise Evaluation
- Expression
- Expression with advanced services
Chacune d’elle, offre certaines limites et avantages.

Mais quant à nous, on installe la version Entreprise Evaluation, celle dont la clé nous
est proposée.
e) Contrat de licence
f) Installation de fichiers de support du programme d’installation

63
g) Règles de support
Lisez ici pour comprendre ce que c’est ; Si simple !
On a deux alertes, mais qui, heureusement, ne peuvent pas endommager l’installation.

64
h) Choisir les composants ou services désirés pour installer
Vous pouvez par ici sélectionner les composants ou services dont vous aurez besoin
d’utilisation.
i) L’instance, Renommer !

65
j) Espace disque requis
k) Configuration du serveur - Sécurité

66
l) Sécurité
Cette configuration du serveur permet de mettre au point des comptes utilisateurs qui
seront utilisés pour exécuter SQL Server.
Alors, il faut choisir un de types de sécurités :
- AUTORITE NT\Système : pour utiliser les comptes utilisateurs du système sur

lequel est installé SQL Server, là vous spécifierez les éléments de sécurités de
comptes en question ;
- AUTORITE NT\Réseau : si vous avez dans votre réseau déployé l’Active
Directory, pour utiliser les comptes utilisateurs du réseau, …
Sinon, vous pouvez modifier après cette installation les types de sécurité :

67
Menu Démarrer -> Clic droit dur Ordinateur -> (Option) Gérer Ordinateur ; vous
verrez la fenêtre suivante :
Déroulez en [1], cliquez le [2], et faites en suite clic droit sur le service en [3], et option
propriétés, sinon sur autre service, et vous aurez la boite de dialogue suivante :
m) Choisir le mode d’authentification
Le mode d’authentification Windows vous permet d’accéder au serveur avec le

compte utilisateur Windows qu’il faut ajouter en (3), il y a moins de sécurité car il

68
n’exige plus de mot de passe, puis qu’il utilise le compte Windows. Le mode Mixte
– Authentification Windows et SQL Server – vous permet de balancer entrer les deux
; il crée par défaut un compte utilisateur SQL Server nommé « sa » : System
Administrator.
Puisque vous prenez le mode d’authentification Mixte en [1], en [2] vous veniez de
mettre le mot de passe pour le compte d’administrateur SQL Server (nommé « sa »,
sysadmin ou system administrator), vous devez aussi désigner le compte utilisateur
Windows de la machine courante en [3], ou sinon ajouter plusieurs autres qui seront
autorisés d’administrer le SQL Server
n) Ajouter l’utilisateur courant pour utiliser le SQL Server

69
o) Configuration de Reporting Service
p) Création de rapports d’erreurs et d’utilisation à Microsoft

70
q) Règles d’installation

71
r) Prêt pour l’installation
s) Installation en cours
t) Installation terminée

72
Et maintenant que l’installation est bien finie, vous pouvez alors vous en servir, mais
le service exploité dans ce document, c’est le moteur de Base de Données avec
certains services au tour de ce dernier.
Dès à présent, vous avez donc la possibilité de soit ajouter une nouvelle instance, soit
supprimer une ancienne, donc désinstaller :
- Pour ajouter une nouvelle instance, aller dans le « Centre d’Installation SQL
Server : Menu Démarrer -> Tous le Programme -> Microsoft SQL Server
2008 -> Outils de configuration
Une fois que vous cliquez sur « Centre de configuration SQL Server », la fenêtre suivante
va apparaître :

73
Vous pouvez ainsi ajouter en [2] une nouvelle instance.
- Pour supprimer, aller carrément dans le Panneau de Configuration ->

Programmes (Désinstaller) et cliquer pour désinstaller l’élément « Microsoft
SQL Server (64-bit) » et vous verrez la boite suite :
Si vous cliquez sur « Supprimer », vous verrez les fenêtres similaires à celles du processus
d’Installation, et le reste d’étape est intuitif, il ne suffit que de lire et faire.
3.7.2. Mise en œuvre de la Réplication sous SQL SERVER

1) Configurations initiales
SQL Server n’est avant tout qu’un SGBD ; quand il est installé sur une
machine, il a cette possibilité de pouvoir communiquer avec d’autres dans le réseau
si la machine est connectée à un réseau. Ainsi, de cette manière, l’ensemble de SQL
Servers connectés forme un SGBBR (Réparti), c’est-à-dire, donnant cette possibilité
de déployer des Bases de Données Réparties.
a) Le Pare-Feu

74
Le pare-feu (firewall) intégré à Windows vous permet d’empêcher les utilisateurs ou

logiciels nom autorisés (comme les vers) d’accéder à votre ordinateur depuis un
réseau ou Internet.
Cela étant, il va empêcher donc que des instances de SQL Server installées sur
différentes machines du réseau se communiquent. Pour ce faire, il faut soit le
désactiver (ce qui est dangereux), soit créer un tunnel de communication, c’est-à-
dire, autoriser un programme à recevoir et émettre bien que le Pare-Feu est
activité…
Là, à ce niveau le Pare-feu est activé, et puis on va chercher à autoriser SQL Server à
communiquer avec l’extérieur.
Cliquer sur [Autoriser un autre programme] :
(1) Cliquer sur [Modifier Les Paramètres], et puis il deviendra inaccessible.

(2) Et autoriser un programme.

75
Si le programme n’est pas sur la liste, cliquer sur [Parcourir…], pour aller le trouver …

76
Aller dans le répertoire suivant :

C:\Program Files\Microsoft SQL Server\MSSQL10.LASOURCESERVER\MSSQL\Binn\
sqlservr.exe
Et c’est déjà bon…
b) Configurer SQL Server pour fonctionner dans le Réseau
Menu Démarrer -> Tous les Programmes - > Microsoft SQL Server 2008 -> Outils de
Configuration - > Gestionnaire de Configuration SQL Server

77
Voici la fenêtre qui va s’afficher
Là, par exemple, nous avons tous les services disponibles de SQL Server, les états et
autres informations.
Il est à signaler que c’est ici que l’on fait aussi l’administration des services de SQL
Server.
Pour configurer la possibilité de communiquer dans un réseau, on a :

78
Faire en (2) un clic droit -> Propriété, et on aura cette boite de dialogue
Ici c’est pour activer les adresses et ports TCP/IP et autres

79
Ici, il faut mettre l’adresse IP de la machine et le numéro de port, par lesquels SQL
Server de cette machine peut être repérable dans le réseau !
A la fin de toutes ces configurations, il faut redémarrer les services.

80
2) Un cas d’exemple
a) Enoncé du problème
L’Université Notre-Dame du Kasayi – UKA veut informatiser son système d’inscriptions
de ses nouveaux étudiants pour chaque nouvelle année académique.
Voici comment, en quelque sort, les informations circulent au sein de l’université :

Soit le bureau de l’Appariteur Général ou une Cellule chargée d’inscription reçoit les
dossiers de candidatures des étudiants, il s’y passe la saisie des informations basiques
des étudiants, telles que son identité, sa faculté, sa promotion du départ, et autres
informations circonstancielles et importantes. Alors chaque Faculté devra recevoir,
au niveau de son bureau de l’Appariteur Facultaire, uniquement les informations
des étudiants inscrits dans cette Faculté.
Nota : Les étapes qui vont suivre, permettent de pouvoir mettre au point une base de
données réparties.
b) Schéma Global
C’est concrètement le modèle logique de données (MLD), dans MERISE, ou le modèle
de classes dans UML.
Votre schéma est censé être global, il est ainsi du fait qu’il ne concerne plus un seul
site pour qu’il ne soit particulier qu’à ce dernier, mais plutôt tous les sites participant
dans la circulation de l’information, d’où il doit être global.
C’est si simple de construire le schéma ou le modèle global de votre Base de
Données, il sera juste question d’étendre les spécificités que vous prendriez pour le
modèle concernant un seul site aux spécificités étendues qui incluent plusieurs sites,
c’est simplement modéliser en tenant compte de tous les sites participant dans la
circulation de l’information.
Voici notre schéma ou modèle global.

81
Etudiant
PK Matricule _Et
Noms _Et
Sexe _Et
Inscription
Date _ Naissance _Et
PK ID _Num _Insc
Matricule _ Etudiant _ Insc

Faculté
ID _Faculté _Insc
PK ID _Fac
ID _Année _Insc
Libellé _ Fac
ID _Promotion _ Insc
Année _Académique
PK ID _An
Autre _ Info _ Année
Promotion
PK ID _Promo
Libellé _ Promo
Nota : Ci-haut, il est question de la conception descendante, où il n’y existe pas

encore une base de données répartie. Mais si c’est le cas où il existe déjà des bases
de données dans différents sites ; conception ascendante ; il faut trouver seulem ent
les informations communes que pourraient partager les différentes bases de données
et mettre au point un mécanisme de communication ; et au finish, ça donne la même
chose : un schéma global.
c) Identification des Sites

Voici les sites qui participent dans la circulation de l’information :
- Le Bureau de l’Appariteur Général : ou la cellule chargée des inscriptions

- Les Bureaux de l’Appariteur Facultaire : de chaque faculté
Nota : Dans notre exemple, nous allons prendre le cas de la faculté de Sciences.
Donc, nous aurons deux (2) sites :
- SITE I : Bureau de l’Appariteur Général

- SITE II : Bureau de l’Appariteur Facultaire de la Faculté de Sciences.
d) Besoins, Fragmentations et Allocations

Avant de pouvoir fragmenter le schéma global, il faudrait pouvoir recenser les besoins
en information de chaque site.
Besoins des Sites

82
- SITE I : enregistre toutes les informations des étudiants ; c’est d’où commence
tout.
- SITE II (Faculté de Sciences) : récupère du SITE I les informations sur tous les
étudiants inscrits à la Faculté de Sciences
Fragmentation et type de fragmentation
La fragmentation est un processus de découpage du schéma global selon le besoin

de chaque site ; elle précède l’allocation, qui est le fait d’allouer ces fragments aux
sites en besoin.
On fragmente donc en fonction du besoin, or le besoin d’un site est alimenté ou
assouvi par un autre qui détient ces informations :
- De « SITE I » vers « SITE II » : Fragment contenant les étudiants inscrits seulement

pour la Faculté de Sciences :
SELECT
Matricule_Etudiant_Insc,
Insc.ID_Annee_Insc,
Insc.ID_Promotion_Insc
FROM Inscription
WHERE
(ID_Faculte_Insc = ‘f-sc’)
Cette requête permet d’illustrer la fragmentation hybride (Verticale + Horizontale)
Problèmes
Il faut savoir que le plus grand fragment, c’est une table ; et que la fragmentation
du schéma global revient tout simplement à appliquer la fragmentation sur une table
ou mieux sur chaque table pour soit soutirer une partie de donnée de la table soit
toute la table ; on ne peut donc pas l’appliquer sur deux (2) tables à la fois même si
elles sont reliées.
Cette manière de faire impose et pose un problème, par exemple, quand c’est une
table qui ne garde principalement que les informations de clés étrangères et les vraies
ou les reste d’informations se trouveraient dans d’autres tables (comme le cas de la
table Inscription), il sera donc difficile en appliquant la fragmentation sur la table
Inscription (comme montré dans la requête ci-haut), de se retrouver avec toutes les
données dans les fragments, il y manquera certaines informations, par exemple, sur
l’Etudiant (nom, sexe, etc.)

83
Puisque, ce problème est de même persistent même lors de la mise au point de la

réplication ( Technologie SQL Server ), il faudrait déjà avant tout, apprêter au sein
d’une table l’ensemble de données désirées (c.-à-d., celles qu’on voudra fragmenter
puis allouer), soit grâce aux techniques de déclencheur ou procédures stockées.
Pour notre cas de la table Inscription, on voudra créer une nouvelle table nommée
EtudiantsInscrits avec les colonnes suivantes :
(ID_Num_Insc, Matricule_Etudiant_Insc, Noms_Eutiant_Insc,

Sexe_Etudiant_Insc, Date_Naissance_Etudiant_Insc,
ID_Faculte_Insc, ID_Annee_Insc, ID_Promotion_Insc) ;
Ceci pour avoir au sein d’une même table toutes les données après le filtrage suivant
(WHERE ID_Faculte_Insc = ‘f-sc’).
Pour alimenter cette table, nous mettrons en place un déclencheur au niveau de la

table Inscription dont les requêtes iront récupérer le reste d’informations dans
d’autres tables et les agréger dans une même table EtudiantsInscrits .
CREATE TRIGGER [dbo].[EtudiantsInscrits_Trigger]

ON [dbo].[Inscription]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
--
DECLARE @id_insc INT, @mat NCHAR(10), @annee NCHAR(10)
DECLARE @fac NCHAR(50), @promo NCHAR(10), @sex NCHAR(10)
DECLARE @nom NVARCHAR(max), @datenaiss DATE
--
SELECT
@id_insc = ID_Num_Insc,
@mat = Matricule_Etudiant_Insc,
@annee = ID_Annee_Insc,
@fac = ID_Faculte_Insc,
@promo = ID_Promotion_Insc
FROM inserted
--
SELECT
@sex = Sexe_Et,
@nom = Noms_Et,
@datenaiss = Date_Naissance_Et
FROM Etudiant WHERE Matricule_Et = @mat;
--
INSERT INTO ETudiantsInscrits(ID_Num_Insc, Matricule_Etudiant_Insc,

Noms_Eutiant_Insc, Sexe_Etudiant_Insc, Date_Naissance_Etudiant_Insc,
ID_Faculte_Insc, ID_Annee_Insc, ID_Promotion_Insc)
VALUES(@id_insc, @mat, @nom, @sex, @datenaiss, @fac, @annee, @promo);

84
--
END
GO
❖ Allocation
Dans cette étape, on montre comment les fragments obtenus dans la précédente seront
placés donc alloués dans différents sites.
Les fragments sont naturellement l’ensemble de données se rapportant à une faculté

(un bureau d’appariteur, un Site), pour notre cas, on avait pris la Faculté de Sciences,
ce sont logiquement eux qui seront délocalisés vers les sites les attendant.
Donc, pour le Site II (Faculté de Sciences), seul le fragment obtenu de la table

EtudiantsInscrits , avec comme critère ‘f-sc’ se retrouvera dans le Site II.
C’est par ici que commence déjà la phase d’implémentation ;
SITE I SITE II
Toutes les tables (y compris la Ici, nous aurons 1 table
nouvelle) se trouveront dans le
Site I
Etudiant EtudiantsInscrits
Faculté
Année_Académique
Promotion
Inscription
EtudiantsInscrits
❖ Implémentation
Après avoir fini de parcourir les étapes précédentes, vous avez maintenant
connaissance de ce qui doit être fait.
Pour réaliser une Base de Données Réparties sous SQL Server, on utilise la technologie
de la Réplication.
Sachant que la Réplication se réalise dans le processus Publication – Distribution –

Abonnement, ces trois opérations sont effectuées par des serveurs, ce sont des rôles
qu’ils peuvent jouer, comme dit tantôt.
Chaque Site aura un SGBD dit Réparti, c.-à-d. un SGBD capable de communiquer avec
d’autres dans le Réseau, celui-ci gérera des bases de données en son sein, en local ;

85
un site peut contenir dans son SGBD toutes les tables et en avoir tous les droits
(Ecriture et Lecture), c’est que c’est un Site principal.
Si un Site a un besoin en information détenue par un autre, le processus de copie

commence de par le Site détenteur de l’information, ce dernier mettra au point une
publication contenant des articles (tables, fragment de table, vues, etc.) selon le
besoin de l’autre site. Cette publication sera disponible dans le serveur de
distribution, qui va interagira avec la base de données d’Abonnement en deux(2)
modes (pull ou push) :
- pull : lorsque l’abonné tire ou sollicite à tout moment le serveur de distribution,

pour savoir s’il y a des nouveaux articles ou des mise-à-jour dans la publication
dont elle est abonnée ;
- push : lorsque le serveur de distribution lui-même rend disponible les articles
(nouveaux ou mis-à-jour) chez l’abonné.
Nous allons expliciter sur le processus Publication – Distribution – Abonnement dans

le point suivant.
Architecture
L’architecture, c’est l’agencement, la structure, le mode de fonctionnement et le rôle à

jour des composants d’un système.
Logiquement, les Bases de Données Réparties sont une application de Système

Distribué, elles profitent aussi de leur architecture (Client-Serveur ou Pair-à-Pair), …
Mais, en fait, il faut le signaler tout de suite que cette architecture s’applique plutôt
aux SGBD, ainsi on appelle ce dernier Serveur de Base de Données.
Une Base de Données Répartie est une collection des Bases de Données se trouvant
dans différents SGBDs de chaque Site et reliées entre elles via un réseau informatique
en vue de se communiquer et de se mettre à même niveau de données communes
(cohérence).
L’architecture entre les Serveurs de Bases de Données, c’est le Pair-à-Pair, c.-à-d. selon
le contexte d’une communication donnée ou selon le contexte de Réplication un
SGBD peut se trouver Serveur et pour une autre communication client. Quant aux
Bases de Données, en tant que ressources que consomment ou fournissent les SGBD,
elles ne peuvent pas être en architecture Client-Serveur ou Pair-à-Pair, elles sont plutôt
en Maître-Esclave ou en Principal et Secondaire ; vous vous souviendrez que dans la
théorie de type de Réplication on parle bien d’ailleurs de la copie maître ou principale
et la copie esclave ou secondaire.

86
3) Réplication sous SQL Server 2008

a) Lancement du Microsoft SSMS – SQL Server Management Studio
b) Authentification
- Choisir le type de serveur : Moteur de Base de Données

- Choisir le Nom du Serveur : ici parmi les instances installées
- Choisir le mode d’authentification : Windows ou SQL Server
Nous sommes dans la machine « LASOURCEPLUS-PC » et le nom du Serveur est «

LASOURCESERVER ».
c) Dans le Serveur

87
Nous allons exploiter plus les deux onglets : [Bases de Données] et [Réplication]
d) La Base de Données à Répliquer : Agents_BD
e) Configurer la Réplication
Il y a lieu de configurer le Serveur de distribution avant. Le même serveur de

publication peut jouer aussi le rôle de celui de distribution.
Clic droit sur l’onglet Réplication

88
Clic sur Configurer la distribution :
- Serveur de Distribution
-
Vous pouvez soit choisir le serveur-ci comme serveur de distribution soit choisir un
autre dans le réseau ou dans la machine.
Faites [Suivant] :
Le Dossier de captures instantanées :

C:\Program Files\Microsoft SQL
Server\MSSQL10.LASOURCESERVER\MSSQL\ReplData

89
- Base de Données de Distribution
- Serveurs de Publication : On peut ajouter des serveurs de publication pouvant

utiliser ce serveur de distribution.

90
Configuration fini avec succès !
On vient de configurer le Serveur de Distribution.
On passe maintenant à Publication :
Clic droit sur l’onglet Réplication -> Publications -> Nouvelle Publication

91
f) Sélectionner la Base de Données à Répliquer : Agents_BD
g) Sélectionner le type de Réplication selon le besoin

92
Nous avons donc choisi, la capture instantanée, le snapshop.
• Publication de capture instantanée :
Le serveur de publication envoie une capture instantanée des données publiées aux
Abonnés, à des intervalles planifiés.
• Publication transactionnelle :
Le serveur de publication diffuse les transactions aux Abonnés une fois qu'ils
ont reçu une capture instantanée initiale des données publiées.
• Publication transactionnelle avec abonnements pouvant être mis à jour :
Le serveur de publication diffuse les transactions aux Abonnés SQL Server une fois
qu'ils ont reçu une capture instantanée initiale des données publiées. Les
transactions en provenance des Abonnés sont appliquées sur le serveur
de publication.
• Publication de fusion :
Le serveur de publication et les Abonnés peuvent mettre à jour les données

publiées de manière indépendante, une fois que les Abonnés ont reçu une
capture instantanée initiale des données publiées. Les modifications sont
fusionnées périodiquement. Microsoft SQL Server Compact Edition ne peut
s'abonner qu'aux publications de fusion.

93
Ces types de publications permettent de concrétiser les architectures client-serveur et

pair-à-pair :
- Client-Serveur : Publication avec capture instantanée et transactionnelle ;

- Pair-à-Pair : Publication transactionnelle avec abonnements pouvant être
mis à jour, et de fusion
h) Sélectionner les articles de la Publication
Ainsi peut se faire la Fragmentation verticale sur les tables (cocher les colonnes)
i) Problème d’article : Apparaît lorsqu’il y a une Vue dans la Publication

94
j) Filtrage des Données
[Ajouter] : Vous permet d’ajouter un filtre dans les données de tables, c’est ici que se
réalise la Fragmentation Horizontale.

95
k) La politique de la capture
[Modifier] : Pour aller planifier la politique de la Publication. Puis valider [OK]

96
l) La sécurité de l’Agent de Capture
[Paramètre de sécurité] : Pour aller configurer.

97
Mettre le Compte Windows de la machine dont SQL Server traite la Publication en

cours
Compte : LASOURCEPLUS-PC\Lasourceplus et son mot de passe. Puis valider [OK]
Et il y a la partie [Connexion au Serveur de publication] ; si vous avez un autre serveur

SQL Server dédié qu’à la charge de publications, alors vous devez renseigner ses
informations, sinon si c’est celui en cours, laisser [En imitant le compte de processus]
m) Nommer la Publication
n) Création d’une Publication : Avec Succès

98
o) Publication créée dans le Serveur : Celle qui est sélectionnée
A) Lancement d’une deuxième Instance

Elle se trouve dans une autre machine [KAYEMBALASOURCE], mais qu’on va accéder
à partir de ce même SSMS, seulement possible parce qu’on avait configuré les SQL
Server dans les deux sites de pouvoir se communiquer dans le Réseau.

99
A partir de la boite d’Authentification, au niveau du nom du serveur, aller à

parcourir…, et on aura le boite suivante : dans l’onglet [Serveurs Réseaux]
apparaissent tous les serveurs dans le Réseau. Faire le choix et valider [OK]
B) Authentification

10 0
Le « sa » System Administrator, accéder avec ce compte ou un autre mais sous le mode

SQL Server, pour plus de sécurité.
Et nous voilà dedans !

[KAYEMBALASOURCE\LASOURCESERVER (SQL Server 10.0.1600 - sa)] :
[Nom_Machine\Nom_Serveur_SQL Server (SQL Server 10.0.1600 – Compte-
Connexion)] :
C) Création de l’Abonnement
C’est de loin mieux de créer l’Abonnement à partir de la Publication, alors on y va,

clic droit sur la Publication concernée -> Nouveaux abonnements

10 1
D) Sélectionner la Publication concernée
E) Emplacement de l’Agent de Distribution
Fixer la synchronisation de donnée, il y a Push et Pull, leur description respective

est décrite juste dans la boite en dessous.

10 2
F) Ajouter un Abonné (SQL Server)
[Ajouter un Abonné] : et là la boite d’authentification pour l’abonné désiré.

10 3
Et voilà !
G) Sélectionner la BD d’arriver, celle qui attend les données de la Réplication

10 4
H) Sécurité de l’Agent de Distribution
[…] : Cliquer pour aller configurer la sécurité, et on a la boite suivante. Puis valider
[OK] [LASOURCEPLUS-PC\Lasourceplus] : On constate que le compte Windows qui
était l’agent de Capture est encore lui-même l’Agent de Distribution. Cela peut aussi se
passer autrement, c’est-à-dire, un autre compte Windows pouvait bien être l’Agent de
distribution.

10 5
Et au niveau du secteur [Connexion à l’Abonné] :
Ici, il faudrait mettre le nom du compte SQL Server (connexion) du SQL Server qui
possède la BD Abonnée, et son mot de passe.
I) Planification de Synchronisation : Choisir

10 6
J) Initialiser les abonnements : Choisir
K) Terminer la création de l’Abonnement : avec succès !

10 7
L) Base de Données Abonnée : Agent_BD_Replica
Dans [KAYEMBALASOURCE\LASOURCESERVER]

10 8
M) Vérification de la cohérence de données Table : t_agent Serveurs :

[KAYEMBALASOURCE\LASOURCESERVER] [LASOURCEPLUS-
PC\LASOURCESERVER]
- [LASOURCEPLUS-PC\LASOURCESERVER] : 6 enregistrements (t_agent)
- [KAYEMBALASOURCE\LASOURCESERVER] : 6 enregistrements (t_agent)

10 9
N) Vérification avec mise-à-jour
Serveur : [LASOURCEPLUS-PC\LASOURCESERVER]
Table : t_agent – Ajout de [k94s – essele – madika - 33]
Serveur : [KAYEMBALASOURCE\LASOURCESERVER]
Table : t_agent : [k94s – essele – madika - 33] répliqué

110

111
Chapitre 4 : Introduction aux bases de données No SQL
L’utilisation des systèmes d’informations se généralise de plus en plus dans le monde

et de plus en plus de 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 du shoping,

faire ses consultations sanitaires et que sais-je encore sur Internet. Cette situation a
conduit progressivement la plupart des entreprises à ouvrir leur système d’information
(S.I) au web, c’est-à-dire de doter leur S.I d’une interface web.
Une fois cette ouverture faite, il fallait désormais pour ces entreprises dites web
relever le pari de la disponibilité de service et faire face à la montée en charge qui en
résulte.
Les systèmes de stockage et de manipulation des données utilisés jusqu’ici ne pouvant

plus répondre à ces nouvelles exigences, les entreprises se voient progressivement et
inéluctablement, tout au moins pour celles qui désirent rester compétitives obligées de
migrer leur système d’information vers de nouvelles architectures.
Aussi, l’accroissement exponentiel des données, la prise en compte des données

faiblement structurées et les avancées technologiques sont autant d’arguments qui
poussent les entreprises principalement les géants du web à faire le choix de la migration
de leur système d’information des SGBD classiques vers de nouvelles bases de données
de type NoSQL, c’est-à-dire les moteurs de données qui n’utilisent pas le standard SQL.
Ces nouvelles bases offrent une meilleure disponibilité des données, des capacités de
stockage gigantesques en s'affranchissant de contraintes induites par les propriétés ACID
(Atomicité, Cohérence, Isolation, Durabilité). Elles sont largement utilisées et
commencent à se faire une place dans les infrastructures IT (Information Technology).
Au regard de la maturité et de la bonne réputation dont jouissent les bases de données

classiques, on peut se poser la question de savoir ce qu’offrent ces nouvelles bases de
données pour justifier une migration (un abandon du relationnel).
En d’autres termes, quelles sont les limites des systèmes relationnels devant les
contraintes de disponibilité (de montée en charge) dont fait l’objet la plupart des
services web et l’augmentation du volume de données ? On peut également poser la
question de la nécessité de la migration vers ces nouvelles approches de stockage et de
manipulation de données au regard du coût et de la complexité d’une telle opération
pour les entreprises.
S’agissant de la migration vers les bases de données NoSQL, quelques géants du web
comme Google avec Bigtable, Facebook avec Cassandra et Twitter ont réussi leur
migration vers le NoSQL ; chacun y allant de ses besoins, ses contraintes et de ses
méthodes.

112
4.1. Les Bases des Données 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. Cette situation de leadership
technologique peut facilement être expliquée par plusieurs facteurs.
Tout d’abord, SQL est un langage standardisé. Bien que chaque fournisseur de base
de données ait implémenté quelques variantes, il n’en demeure pas moins que ce socle
commun est bien connu par les développeurs.
Pour une entreprise, investir dans une technologie SQL s’avère donc moins coûteux
sur le plan de la formation que toute autre technologie. Cela explique sans doute l’échec
des bases de données objets que l’on a vu fleurir autour des années 2000 et qui n’ont
jamais véritablement percé, malgré une approche novatrice.
Ensuite, SQL embarque de nombreuses fonctionnalités importantes, adaptées aux

besoins des entreprises, en particulier la gestion de l’intégrité des données et
l’implémentation de transactions, indispensables pour bon nombre d’applications de
gestion. Dans un monde où l’informatique de gestion a représenté une part très
importante des besoins durant ces dernières décennies, ces fonctionnalités sont devenues
attendues et indispensables dans une base de données.
Enfin, les outils permettant l’exploitation de ce type de bases de données sont

matures. Que l’on se place au niveau des outils de développements (IDE graphiques,
intégration dans les langages et les frameworks, …) ou d’exploitation (outils de
sauvegarde, monitoring, …), les solutions existent et sont prêtes depuis déjà un certain
temps. On peut donc considérer SQL comme un standard de fait pour toute
problématique ayant trait au stockage et à la manipulation de données.
Pourtant, un certain nombre de limitations importantes sont apparues au fil des

années. Les premiers acteurs à buter sur ces limites furent les fournisseurs de services en
ligne les plus populaires, tels que Yahoo, Google ou plus récemment les acteurs du web
social comme Facebook, Twitter ou LinkedIn. Le constat était simple : les SGBD
relationnels ne sont pasadaptés aux environnements distribués requis par les volumes
gigantesques de données et par les trafics tout aussi gigantesques générés par ces
opérateurs.
Les besoins majeurs identifiés par ces acteurs sont les suivants :
- Capacité à distribuer les traitements sur un nombre de machines important afin

d’être en mesure d’absorber des charges très importantes. On parlera de scaling
des traitements.
- Capacité à répartir les données entre un nombre important de machines afin d’être
en mesure de stocker de très grands volumes de données. On parlera plutôt de
scaling des données.
- La distribution de données sur plusieurs datacenters afin d’assurer une continuité
de service en cas d'indisponibilité de service sur un datacenter. Cette approche doit

113
par ailleurs permettre que les données soient au plus proche des personnes qui les
utilisent.
- Une architecture qui fonctionne sur du matériel peu spécialisé et donc facilement
remplaçable en cas de panne.
4.1.1. Limites des SGBD relationnels dans les architectures distribuées 3
Malgré l’appellation NoSQL, ce n’est pas tant le langage SQL en lui-même qui est
inadapté mais les grands principes sur lesquels il a été construit : le modèle relationnel
et transactionnel. En effet, les bases de données relationnelles mettent à la disposition
des développeurs un certain nombre d’opérations de relations entre les tables :
- Un système de jointure entre les tables permettant de construire des requêtes

complexes faisant intervenir plusieurs entités (les tables en l'occurrence)
- Un système d’intégrité référentielle permettant de s’assurer que les liens entre les
entités sont valides
La mise en œuvre de tels mécanismes à un coût considérable dès lors que l’on se
trouve dans le contexte d’un système distribué. Sur la plupart des SGBD relationnels, il
convient de s’assurer en permanence que les données liées entre elles sont placées sur le
même nœud du serveur. Lorsque le nombre de relations au sein d’une base augmente,
il devient de plus en plus difficile de placer les données sur des nœuds différents du
système.
Outre leur modèle relationnel, la plupart des moteurs de S.G.B.Ds relationnels sont
transactionnels ce qui leur impose le respect des contraintes Atomicity Consistency
Isolation Durability, communément appelé par son acronyme ACID.
Dans un contexte centralisé, les contraintes ACID sont plutôt aisées à garantir. Dans
le cas de systèmes distribués, il est en revanche nécessaire de distribuer les traitements
de données entre différents serveurs. Il devient alors difficile de maintenir les contraintes
ACID à l’échelle du système distribué entier tout en maintenant des performances
correctes. Comme on le verra, la plupart des SGBD de la mouvance NoSQL ont donc
été construits en faisant fi des contraintes ACID quitte à ne pas proposer de
fonctionnalités transactionnelles.
Il existe par ailleurs, une limitation plus théorique à ce que peuvent réaliser les bases
de données relationnelles distribuées qui est décrite par le théorème de CAP
(ConsistencyAvailibilityPartition tolerance).
Le théorème de CAP stipule qu’il est impossible d’obtenir ces trois propriétés en même
temps dans un système distribué et qu'il faut donc en choisir deux parmi les trois :
Les bases de données relationnelles implémentent les propriétés de Cohérence et de

Disponibilité (système AC).
3 FAUCRET A., NoSQL, Une nouvelle approche du stockage et de la manipulation des données , Smile Livres
Blancs, Paris, 2013, p 8-9.

114
Les bases de données NoSQL sont généralement des systèmes CP (Cohérent et Résistant
au partitionnement) ou AP (Disponible et Résistant au partitionnement).
4.2. Le NoSQL, une nouvelle approche de stockage et de manipulation de données.
Depuis quelques années (2009), de nouvelles approches du stockage et de la gestion

des données sont apparues, qui permettent de s’astreindre de certaines contraintes, en
particulier de scalabilité, inhérentes au paradigme relationnel. Regroupées derrière le
vocable NoSQL, ces technologies auraient très bien pu être nommées “NoRel” comme
le suggère lui-même l’inventeur du terme NoSQL, Carl Strozzi.
Plus que des technologies de remplacement intégral des outils relationnels, le NoSQL
correspond le plus souvent à des approches qui complètent les outils existants, pour en
combler les faiblesses. Ainsi, on observe de plus en plus souvent la traduction “Not Only
SQL” au lieu de “No SQL”.
Les axes principaux du NoSQL sont une haute disponibilité et un partitionnement

horizontal des données, au détriment de la consistance. Alors que les bases de données
relationnelles actuelles sont basées sur les propriétés ACID (Atomicité, Consistance,
Isolation et Durabilité). NoSQL signifie “Not Only SQL”, littéralement “pas seulement
SQL”.
Ce terme désigne l’ensemble des bases de données qui s’opposent à lanotion

relationnelle des SGBDR. La définition, “pas seulement SQL”, apporte un début de
réponse à laquestion “Est ce que le NoSQL va tuer les bases relationnelles?”.
En effet, NoSQL ne vient pas remplacerles BD relationnelles mais proposer une

alternative ou compléter les fonctionnalités des SGBDR pourdonner des solutions plus
intéressantes dans certains contextes.
4.2.1. Les concepts forts du NoSQL
Les bases de données NoSQL reposent essentiellement sur plusieurs aspects qui font
leurs forces et justifient leur usage aujourd’hui des géants du web. Il s’agit principalement
du partitionnement horizontal des données, du fait que ces bases sont sans schéma et
donc une grande flexibilité du schéma de données.
a. Scalabilité maîtrisée à travers le partitionnement horizontal
La Scalabilité désigne la capacité d'un produit à s'adapter à un changement d'ordre de

grandeur de la demande ( montée en charge), en particulier sa capacité à maintenir ses
fonctionnalités et ses performances en cas de forte demande. 4
Ces bases de données NoSQL proposent ainsi une nouvelle représentation de

l’information. En s’affranchissant des contraintes ACID du modèle SQL, elles ont le très
gros avantage de fournir une architecture technique où il suffit de rajouter des serveurs
pour gagner en performance sans trop se poser de questions. Cette technique consiste
4http//wikipedia/scalability, consulté le 04 Décembre 2014.

115
lorsque la charge des traitements ou des données devient très importante au niveau d’un
ou de plusieurs serveurs à ajouter un ou plusieurs serveurs qui se partagent les données
et les traitements : c’est ce que nous avons évoqué plus haut sous les termes de scaling
de données et de scaling de traitements.
Cette approche de stockage permet d’avoir des bases de données performantes et

une disponibilité que les SGBD classiques ne peuvent égaler même en multipliant les
serveurs miroirs.
Un SGBDR pour répondre aux exigences de performance face aux gros volumes de
données, doit se retourner vers du matériel de plus en plus rapide et à l'ajout de
mémoire. Le NoSQL, pour sa part, pour gérer la “montée en charge" se réfère à la
répartition de la charge sur les systèmes de Cloud Computing. Il s'agit-là du composant
de NoSQL qui fait d'elle une solution peu coûteuse pour les grands ensembles de
données.
b. Meilleure gestion des données faiblement structurées

A part être une nouvelle technologie, le NoSQL permet de stocker les informations
d’une manière qui colle mieux à leur représentation.
Exemple :
- Les bases de données orientées document s'adaptent au stockage des données

non planes (type profil utilisateur) ;
- Les bases de données orientées colonne s'adaptent très bien au stockage de listes
(messages, posts, commentaires, etc.…) ;
- Les bases de données orientées graphe permettent de mieux gérer des relations
multiples entre les objets (comme pour les relations dans les réseaux sociaux).
La première rupture est inhérente au modèle de données non relationnel qui ne

dispose pas des méthodes efficaces permettant d’effectuer des opérations de jointure.
Dans le modèle relationnel, la pratique courante est d’utiliser les données sous forme
normalisée et de procéder à des jointures entre les tables.
Sur le sujet de la normalisation, les théoriciens de la mouvance NoSQL prônent une
approche pragmatique guidée par l’utilisation qui est faite des données :
✓ Dans certains cas les données seront embarquées dans la donnée parente
(la manière de procéder dépend du paradigme utilisé). C’est notamment le cas
lorsque le volume de données est faible et que celle-ci est peu mise à jour. Il se
pose alors la problématique de la mise à jour des données.
✓ Dans les autres cas, on stockera simplement les identifiants permettant

d’accéder aux données comme on le ferait dans le modèle relationnel. La
différence réside dans le fait que c’est le plus souvent à l’application de procéder
par la suite aux jointures.
L’engouement pour les bases NoSQL est la conclusion logique de l’ère Web 2.0. Les
données stockées sont aujourd’hui beaucoup plus importantes qu’elles n’ont pu l’être

116
avant, et les besoins ont changé. On a aujourd’hui besoin de pouvoir stocker ou lire très
rapidement des millions de données (prenez l’exemple de Facebook par exemple) mais
aussi, avec le Cloud, d’avoir des systèmes “scalable” ou élastiques.
4.2.2. Les Types de bases de données NoSQL
Il existe différents types de bases de données NoSQL spécifiques à différents besoins,

en voici quelques-uns avec le nom des solutions ou moteurs associés :
- Orientées colonnes : HBase, Hyper table, Cassandra et BigTable ;

- Orientées graphes (Euler) : Neo4J ;
- Orientées clé-valeur : Voldemort, Dynamite et Riak ;
- Orientées document : CouchDB5.
a. Bases de données orientées colonne
Traditionnellement, les données sont représentées en ligne, représentant l'ensemble

des attributs. Le stockage orienté colonne change ce paradigme en se focalisant sur
chaque attribut et en les distribuant. Il est alors possible de focaliser les requêtes sur une
ou plusieurs colonnes, sans avoir à traiter les informations inutiles (les autres colonnes).
Stockage orienté colonnes
Cette solution est très adaptée pour effectuer des traitements sur des colonnes comme
les agrégats (comptage, moyennes, co-occurences...). D'une manière plus concrète, elle
est adaptée à de gros calculs analytiques. Toutefois, cette solution est beaucoup moins
appropriée pour la lecture de données spécifiques comme pour les clés/valeurs.
Qui fait de l'orienté-colonnes ?
• BigTable (Google)
• HBase (Apache, Hadoop)
• Spark SQL (Apache)
• Elasticsearch (elastic) -> moteur de recherche
5 ROGER M., synthèse d’étude et projets d’intergiciels: bases NoSQL, Paris, Smile Livres Blancs, 2013, p87.

117
Quelques exemples d'applications : Comptage (vote en ligne, compteur, etc),

journalisation, recherche de produits dans une catégorie, reporting à large échelle.
b. Bases de données orientées graphes
Les trois autres familles NoSQL n'adressent pas le problème de corrélations entre les
éléments. Prenons l'exemple d'un réseau social : dans certains cas, il devient très
complexe de calculer la distance entre deux personnes non directement connectées. Et
c'est ce type d'approche que résolvent les bases orientées Graphe.
Stockage orienté graphe
Dans la base orientée graphe, les données stockées sont : les nœuds, les liens et des
propriétés sur ces nœuds et ces liens. Les requêtes que l'on peut exprimer sont basées sur
la gestion de chemins, de propagations, d'agrégations, voire de recommandations.
Toutefois, contrairement aux solutions précédentes la distribution des nœuds sur le
réseau n'est pas triviale.
Quelles SGBDs gèrent de gros graphes ?
• Neo4j : eBay, Cisco, UBS, HP, TomTom, The National Geographic Society
• OrientDB (Apache) : Comcast, Warner Music Group, Cisco, Sky, United Nations,
VErisign
• FlockDB (Twitter) : Twitter
c. Bases de données orientées clé-valeurs
Il arrive parfois que l'on n'ait besoin que de retrouver des valeurs étant donné une
clé. Par exemple, si votre application a besoin de retrouver le dossier d'un étudiant en
n'utilisant que son code étudiant, alors une base de données de type clé-valeur sera
idéale. Elles tendent à être plus rapides et plus simples que les bases de données
relationnelles.
On les utilise, notamment, pour stocker des pages web précalculées afin d'accélérer
certains sites web. Dans un tel cas, la clé peut être, tout simplement, l'hyperlien de la
page.

118
Stockage Clé/Valeur
d. Bases de données orientées document
Les bases orientées documents ressemblent sans doute le plus à ce que l'on peut faire
dans une base de données classique pour des requêtes complexes. Le but de ce stockage
est de manipuler des documents contenant des informations avec une structure
complexe (types, listes, imbrications). Il repose sur le principe du clé/valeur, mais avec
une extension sur les champs qui composent ce document.
Stockage orienté document
L'avantage de cette solution est d'avoir une approche structurée de chaque valeur,
formant ainsi un document. De fait, ces solutions proposent des langages d'interrogation
riches permettant de faire des manipulations complexes sur chaque attribut du document
(et sous-documents) comme dans une base de données traditionnelles, tout en passant
à l'échelle dans un contexte distribué.
Quelles SGBDs pour gérer vos documents :
• MongoDB (MongoDB) : ADP, Adobe, Bosch, Cisco, eBay, Electronic Arts,

Expedia, Foursquare
• CouchBase (Apache, Hadoop) : AOL, AT&T, Comcast, Disney, PayPal, Ryanair
• DynamoDB (Amazon) : BMW, Dropcam, Duolingo, Supercell, Zynga
• Cassandra (Facebook -> Apache) : NY Times, eBay, Sky, Pearson Education

119
BIBLIOGRAPHIE
[1] S. Spaccapietra, C. Vingenot, Bases de données réparties,

http://lbdwww.epfl.ch/f/teaching/courses/slidesBDA/BDR/BDR_se.
pdf
[2] M. T. Özsu & P. Valduriez, Principles of Distributed Database Systems,
Prentice Hall 1999.
[3] D. Kossmann, The State of the Art in Distributed Query Processing,
http://www.db.fmi.uni-passau.de/~kossmann
[4] D. Donsez, Les SGBDs Parallèles,
http://www.adele.imag.fr/~donsez/cours/
[5] D. Donsez, Répartition, Réplication, Nomadisme, Hétérogénéité dans
les SGBDs, http://www.adele.imag.fr/~donsez/cours/ [6] Chapitre 8:
La gestion des transactions, http://medias.obsmip.
fr/cours/concept/chap8.htmJ. Durbin, L. Ashdown, Oracle8i :
Distributed Database Systems, Oracle Press, 1999.
http://sunsite.eunnet.net/documentation/oracle.8.0.4/server.804/a
58247.pdf
[7] K. Loney, M. Theriault, Oracle8i DBA Handbook, Oracle Press 2000.
[8] Oracle8 Product Documentation Library, http://wwwrohan.
sdsu.edu/doc/oracle/
[9] I. Ben-Gan, T. Moreau, Advanced Transact-SQL for SQL Server 2000,
Chapitre 13 p.459: Horizontally Partitionned Views, a!Press.
[10] B. Ducourthial, Les bases de données réparties,
http://wwwhds.utc.fr/~ducourth/TX/BDD/
[11] M. Gertz, ORACLE/SQL Tutorial, http://www.db.cs.ucdavis.edu.
[12] Oracle Parallel Query, http://www.tafora.fr/wp/pqo.doc.html.

120
Table des matières

Chapitre 1 : Notions d'architecture client-serveur ....................................................................... 1
1.1. Définitions .................................................................................................................... 1
1.2. Fonctionnement d'un système client/serveur ............................................................... 1
1.3. Exemples des modèles clients serveurs ......................................................................... 2
1.4. Avantages et Inconvénients du modèle client/serveur ................................................. 2
b. Inconvénients ............................................................................................................... 2
1.5. Types de clients ............................................................................................................ 3
1.6. Différents types de c-s ................................................................................................... 3
1.7. Architecture client-serveur par niveau.......................................................................... 4
1.7.2. Architecture à trois niveaux .................................................................................. 4
Remarque............................................................................................................................. 5
Comparaison des deux types d'architecture......................................................................... 5
1.7.3. L'architecture multi-niveaux (N-tiers) .................................................................... 5
1.8. LES MIDDLEWARES (intergiciel)................................................................................... 6
1.9. Application : Création d’une application Client Serveur pas à pas avec C# ................ 7
Chapitre 2 : Les bases de données réparties...............................................................................12
2.1. Définition.........................................................................................................................12
2.2. Le SGBD reparti...............................................................................................................12
2.3. Conception d’une base de données répartie ..................................................................16
2.4. Fragmentation.................................................................................................................18
2.5. Notion de transaction répartie....................................................................................20
2.6. SQL Serveur par la pratique ........................................................................................23
2.6.1. Création d’une base de données avec SQL Serveur .............................................23
2.6.2. Connexion C# et Sql Serveur ...............................................................................36
2.7. Introduction au Transact Sql .......................................................................................36
2.7.1. Qu'est-ce que Transact-SQL ? ....................................................................................36
2.7.2. Quelques instructions DML ......................................................................................36
c. La boucle WHILE.............................................................................................................44
d. Affecter des valeurs aux variables à partir de l'instruction Select .......................................45
2.7.4. Quelques Instructions DDL .......................................................................................46
a. Créer une table avec du Code T-SQL..............................................................................46
2.7.5. Les Transactions........................................................................................................47
Pourquoi doit le traitement de la transaction ? ..................................................................48
Chapitre 3 : Les Réplications......................................................................................................50
3.1. Définitions ...........................................................................................................................50

121
3.2. Forces et faiblesses de la réplication................................................................................50

3.3. Exemple d’application de la réplication..........................................................................51
3.4. Types de réplication........................................................................................................51
3.5. Mise à jour synchrone et asynchrone..............................................................................53
3.6. Technique de diffusion des mises à jour .........................................................................54
3.7. Mise en œuvre de la réplication sous SQL Serveur .........................................................58
3.7.1. Installation de SQL Server .........................................................................................58
Spécifications pour une installation réussie .........................................................................58
3.7.2. Mise en œuvre de la Réplication sous SQL SERVER .................................................73
1) Configurations initiales .......................................................................................................73
2) Un cas d’exemple...............................................................................................................80
3) Réplication sous SQL Server 2008 .....................................................................................86
Chapitre 4 : Introduction aux bases de données No SQL ........................................................ 111
4.1. Les Bases des Données Relationnelles ............................................................................ 112
4.1.1. Limites des SGBD relationnels dans les architectures distribuées ................................ 113
4.2. Le NoSQL, une nouvelle approche de stockage et de manipulation de données. ....... 114
4.2.1. Les concepts forts du NoSQL .................................................................................. 114
4.2.2. Les Types de bases de données NoSQL .................................................................. 116
a. Bases de données orientées colonne ......................................................................... 116
b. Bases de données orientées graphes.......................................................................... 117
c. Bases de données orientées clé-valeurs ..................................................................... 117
d. Bases de données orientées document ...................................................................... 118
BIBLIOGRAPHIE....................................................................................................................... 119

Base de données relationnelles d

Transféré par

Droits d'auteur :

Formats disponibles

Base de données relationnelles d

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Base de données relationnelles d

Transféré par

Droits d'auteur :

Formats disponibles

Base de données Orientée Objet

Chef de Travaux Anaclet TSHIKUTU Bikengela

Année Académique 2020-2021

Chapitre 1 : Notions d'architecture client-serveur

L'environnement client-serveur désigne un mode de communication à travers un

En général, un serveur est capable de traiter les requêtes de plusieurs clients. Un

1.2. Fonctionnement d'un système client/serveur

Figure 1-1 : Schéma de fonctionnement d'un système client/serveur

Un système client/serveur fonctionne selon le schéma suivant :

Base de données Orientée Objet

1.3. Exemples des modèles clients serveurs

1.4. Avantages et Inconvénients du modèle client/serveur

Le modèle client/serveur est particulièrement recommandé pour des réseaux

L'architecture client/serveur a tout de même quelques lacunes parmi lesquelles :

Base de données Orientée Objet

✓ Si trop de clients veulent communiquer avec le serveur au même moment, ce

1.5. Types de clients

1.5.1. Client léger

1.5.2. Client lourd

Le poste client doit comporter un système d'exploitation capable d'exécuter en

1.5.3. Client riche

Une interface graphique plus évoluée permet de mettre en œuvre des

1.6. Différents types de c-s

1.6.1. C/S de présentation (Présentation CIS)

Base de données Orientée Objet

Type de client-serveur dans lequel un processus exécute seulement les fonctions

1.6.2. C/S de données (Data CIS)

Type de client-serveur dans lequel un programme applicatif contrôlé par une

Le serveur de données gère une ou plusieurs bases de données.

Type de client-serveur dans lequel un programme applicatif contrôlé par une

1.6.4. C/S de données et procédures

La tendance est donc d'aller vers un système d'information du type client-serveur

1.7. Architecture client-serveur par niveau

1.7.1. Architecture 2 niveaux

L'architecture à deux niveaux (aussi appelée architecture 2-tiers, tier signifiant

Figure 1-2 : Architecture 2-tiers

1.7.2. Architecture à trois niveaux

Base de données Orientée Objet

Dans l'architecture à 3 niveaux (appelée architecture 3-tier), il existe un niveau

1. Le client : le demandeur de ressources

Figure 1-4 : Architecture 3-tiers

• Partage d'application entre client, serveur intermédiaire, et serveur d'entreprise

Comparaison des deux types d'architecture

• Une plus grande flexibilité/souplesse

1.7.3. L'architecture multi-niveaux (N-tiers)

Base de données Orientée Objet

Dans l'architecture à 3 niveaux, chaque serveur (niveaux 1 et 2) effectue une tâche

Figure 1-5 : Architecture N-tiers

1.8. LES MIDDLEWARES (intergiciel)

✓ SQL*Net : Interface propriétaire permettant de faire dialoguer une application

✓ ODBC (Open DataBase Connectivity) : Interface standardisée isolant le client du

Base de données Orientée Objet

✓ DCE (Distributed Computing Environment) : Mécanisme de RPC proposé par

Le choix d'un middleware est déterminant en matière d'architecture, il joue un grand

Le middleware offre des services de haut niveau liés au besoin de communication

1.8.3. Les fonctions d’un Middleware

✓ Il indique la procédure d’établissement de connexion ;

- Machine 1 (Serveur) : Partager le fichier de connexion (La base de données)

Base de données Orientée Objet