Mastre Spcialis Management des Systmes dInformation Rpartis Promotion 2005

Bases de donnes rparties

Herv de MILLEVILLE
hdm@eisti.fr

Cas entreprise

Luc JACQUEMIN Agns LELEUX Adrien MACHADO

Mai 2004

Sommaire
INTRODUCTION........................................................................................................3 ENONCE DU CAS .......................................................................................................4 SCHMA GLOBAL DU SYSTME ................................................................................5 A. DIAGRAMME DES CLASSES UML ...................................................................................... 5 B. COMMENTAIRES .......................................................................................................... 6 C. PROCEDURE POUR LE PASSAGE EN BASE DE DONNEES PHYSIQUE.............................................. 6 SCHEMAS DES BASES DE DONNEES .........................................................................8 A. SCHEMA GLOBAL DES TABLES.......................................................................................... 8 B. DEFINITIONS ET HYPOTHESES ........................................................................................ 9 C. SCHEMA DE CHAQUE SITE .............................................................................................10 1. Sige ............................................................................................................................ 10 2. Usine............................................................................................................................ 10 3. Point de vente ............................................................................................................... 11 D. EXEMPLE DE REPARTITION DES DONNEES EN FONCTION DES HYPOTHESES RETENUES ..................12 1. Fragmentations horizontales ........................................................................................... 12 2. Fragmentations verticales............................................................................................... 12 3. Rplication .................................................................................................................... 12 4. Agrgation par vue ........................................................................................................ 13 SIMULATION DE L'UTILISATION ...........................................................................14 A. CREATION DE LA BASE DE DONNEES ................................................................................14 B. QUELQUES REQUETES DE TEST.......................................................................................14 CONCLUSION..........................................................................................................15 ANNEXES ................................................................................................................16 COMMENTAIRES SUR LE COURS DISPENSE A LEISTI ...............................................................16 1. Pdagogie et organisation .............................................................................................. 16 2. Contenu........................................................................................................................ 16

Bases de donnes rparties

-2-

Anne 2004

Introduction
Une base de donnes rpartie est un ensemble de donnes stockes sur plusieurs bases connectes par un rseau (moyen de communication entre sites) et gr par un SGBD (Systme de Gestion de Base de Donnes). Pour dcider de mettre en place un tel systme, il faut prendre en compte les critres de choix suivant : le cot installation (logiciel, matriel, formations), de communication (frais tlcoms), de sret (intgrit, vol de donnes) et de disponibilit (donnes toujours accessibles pour tous). Dans une base de donnes rpartie, lexcution des transactions est soit locale (accs aux donnes sur site), soit globale (accs sur plusieurs sites). Les donnes peuvent tre locales ou rparties. La cohrence des donnes doit tre assure (semantic data controler), ainsi que le contrle de concurrence (transaction manager) et la reprise aprs panne (recovery manager).Il est plus que jamais conseill doptimiser les requtes (query processor) pour amliorer les temps daccs et volume manipuls aux fins de restitutions de donnes. Enfin, linfrastructure (hardware et software) doit tre transparente pour lutilisation. Les avantages de ce type de systme rparti rsident dans une plus grande fiabilit (pannes matrielles non fatales lensemble de la population), de meilleures performances grce notamment la proximit des donnes et la scalabilit du systme. A linverse, les cots sont plus importants, une procdure de synchronisation efficace des donnes doit tre labore, la scurit est moindre et il existe des risques dinterblocages distribus (par exemple : une base sur un site attend une base dun autre site qui attend elle-mme la base en attente). Lors de la phase de conception darchitecture, il y a lieu de dterminer lquilibre que lon souhaite obtenir entre le degr dautonomie des sites et la fluidit des changes ou modes daccs intersites. Le client peut aussi communiquer avec tous les serveurs ou avoir pour interface un serveur unique (architecture 3 tiers). Contrairement cette logique client serveur, on peut aussi dcider de mettre en place une architecture peer-to-peer o toutes les machines ont le mme rle. On distingue deux processus de conception de bases de donnes rparties. La mthode top-down design o lon commence par dfinir un schma global (Global Conceptual Schema) que lon distribue vers des schmas locaux avant de raliser la fragmentation et lallocation des fragments. A linverse, la mthode bottom-up design part des schmas locaux quil convient de redsigner et consolider pour aboutir un schma global remani (mthode utile pour une reconception partir dun SI prexistant).

Le cas qui va tre prsent consiste mettre en uvre les mthodes et les techniques de dfinition et de mise en place dune base de donnes rpartie laide dun cas dcole. La mthode utilise est celle du top-down design . Nous allons donc commencer par vous prsenter le schma global, c'est--dire le diagramme des classes UML de tout le systme. Nous prsenterons ensuite le schma des tables dcoulant de ce diagramme et celui des bases de donnes que nous souhaitons mettre en uvre sur chaque site.

Bases de donnes rparties

-3-

Anne 2004

Enonc du cas
1- L'entreprise et sa demande Il s'agit d'une entreprise qui fabrique et vend des biens de consommation. Elle dispose : - De plusieurs usines de fabrication - De plusieurs points de vente - D'un sige social Il faut dfinir et installer la base de donnes rpartie qui permette de grer toutes les activits de l'entreprise. 2- Les usines La base de donnes rpartie doit permettre aux diffrents responsables d'usines : 1) De grer les fournisseurs. 2) De grer les produits et matires premires. 3) De grer les commandes provenant des points de vente. 4) De grer le quotidien des salaris de l'usine. 5) De pouvoir consulter le stock des autres usines 3- Les points de vente La base de donnes rpartie doit permettre aux diffrents responsables des points de vente : 1) De grer les clients 2) De grer les commandes des clients 3) De grer le quotidien des salaris du point de vente. 4- Le sige social La base de donnes rpartie doit permettre aux diffrents responsables du sige social : 1) De grer la carrire des salaris de toute l'entreprise 2) D'avoir des tableaux de bord propos de l'activit de production et commerciale de l'entreprise 3) De grer le quotidien des salaris du sige social

Bases de donnes rparties

-4-

Anne 2004

Schma global du systme

Avant de penser la rpartition, nous avons commenc par modliser lensemble du systme en UML avec laide du logiciel Rational Rose. Compte tenu de lobjet du cours, nous nous sommes limits la cration dun diagramme des classes que nous allons prsenter et commenter. Il sera la base pour le passage aux schmas des bases de donnes.

A. Diagramme des classes UML

Sal arie (from general) nom prenom dateembauche DateFonction (from general) 1 date 1..* 1 Site (from general) nom adresse Usine (from general) 1 1 1..* CommandeFourni sseur (from general) date 1..* 0..* 1..* Element (from general) reference prix 0..* StockUsine (from general) date quantite 1..* ReapprovisionnementPointDeVente (from general) quantite Siege (from general) 1 ActiviteSalarie 1..* (from general) heuresup congespri s

FonctionSalarie (from general) indicesalarial ni veauhierarchique 1 regimehoraire salairemensuel

Mois (from general) mois

QuantiteMP (from general) quantitemp 1 Fournisseur (from general) 1 1

Produit 0..* (from general) 0..n 1..* QuantiteProduit (from general) quantitep

0..*

Poi ntDeVente (from general)

MatierePremiere (from general)

Client (from general) Partenaire (from general) nom adresse datecreation 1 0..* 0..* CommandeClient (from general) date couttotal 0..*

Bases de donnes rparties

-5-

Anne 2004

NB : lobjectif du cas ntant pas la ralisation dune application, nous navons indiqu dans le logiciel ni les oprations, ni les attributs daccs (private, public, protected), ni les libells des relations et des rles, ni les types des attributs (qui auraient pourtant t repris lors du passage en schma de tables). De mme, nous navons pas tudi la possibilit de crer des packages pour regrouper les lments ayant les mmes fonctionnalits (ex : package production, package vente et package siege).

B. Commentaires
La lecture de lnonc nous a permis de distinguer 21 classes pour pouvoir grer les besoins formuls dans le cahier des charges. Les classes Site, Element et Partenaire ont t cres pour gagner en gnricit. Ces dernires sont des super-classes qui regroupent les attributs (et oprations) communes aux classes hritires . Nanmoins, nous pouvons remarquer que ces classes filles nont pas dattributs particuliers. Cela pourrait tre vu comme contraire la thorie de lhritage mais nous avons conserv ces gnralisations dans un but dvolutivit du logiciel. Pour exprimer les connexions smantiques entre ces classes, nous avons cr des relations classiques et une agrgation. Celle-ci indique que nos produits sont constitus de matires premires (et non composs puisque la matire premire nexiste plus dans sa forme dorigine dans le produit final). Remarque : L'agrgation et la composition sont des vues subjectives qui ne reprsentent pas obligatoirement la ralit mais servent ajouter de la smantique au modle. Pour certaines relations, nous avons choisi de crer des classes dassociations qui stockent les attributs en rapport avec la relation. Par exemple, la relation entre un salari et un site est caractrise par une fonction, pour laquelle nous gardons dailleurs un historique pour la gestion des carrires. Enfin, nous avons indiqu les cardinalits pour informer sur le nombre dinstances qui participent la relation.

C. Procdure pour le passage en base de donnes physique

Dans le diagramme des classes, nous modlisons le systme tel quil fonctionnera. Ceci permettra de crer lapplication mais aussi la base de donnes. En effet, les classes persistantes auront une dure de vie suprieure celle de la session. Dans ce cas, les informations devront tre sauvegardes dans une base de donnes. Voici la dmarche qui nous a permis de crer nos tables dans Rational Rose. Indiquer, dans les spcifications des classes qui devront tre stockes dans une base de donnes, lattribut persistent et non transient (par dfaut). Cette caractristique est indiquer dans longlet Detail des Specifications dune classe. Faire ensuite un clic-droit sur chaque package (chacun donnera un schma de tables) et choisir Data Modeler puis Transform to Data Model . On va alors crer un modle de la base de donnes dans le schma dont on indique le nom. Dans notre cas, on ne prcise pas de base de donnes (dj existante) et on indique le prfixe des noms des tables (par rapport

Bases de donnes rparties

-6-

Anne 2004

au nom des classes UML). On voit alors apparatre le schma relationnel dans l'arborescence de Rose. Pour visualiser nos tables cres, on les fait glisser dans un diagramme de modle de donnes. Celui-ci est cr en faisant sur le schma un clic-droit Data modeler new Data model diagram. On peut alors visualiser nos tables et leurs relations.

Bases de donnes rparties

-7-

Anne 2004

Schmas des bases de donnes

A. Schma global des tables
Voici page suivante, le schma des tables gnr par Rational Rose pour notre cas.

T_Salarie nom : SMALLINT prenom : SMALLINT dateembauche : SMALLINT T_Salarie_ID : INTEGER T_Site_ID : INTEGER

T_ActiviteSalarie <<Non-Identifying>>
1

1 1 <<Non-Identifying>> 0..*

1..*

heuresup : SMALLINT congespris : SMALLINT T_ActiviteSalar ie_ID : INTEGER T_Salarie_ID : INTEGER

<<Non-Identifying>>

<<Identifying>>

<<Non-Identifying>> 1..*

0..* T_Mois mois : SMALLINT T_Mois_ID : INTEGER T_ActiviteSalarie_ID : INTEGER T_Salarie_ID : INTEGER

0..* T_F onctionSalarie indicesalarial : SMALLINT niveauhierarchique : SMALLINT regimehoraire : SMALLINT salairemensuel : SMALLINT T_FonctionSalarie_ID : INTEGER T_Site_ID : INTEGER T_Salarie_ID : INTEGER T_DateFonction_ID : INTEGER <<Non-Identifying>> 1 1 T_DateFonction date : SMALLINT T_DateFonction_ID : INTEGER T_Salarie_ID : INTEGER T_Site_ID : INTEGER <<Identifying>> 0..* 1

T_Site nom : SMALLINT adresse : SMALLIN T T_Site_ID : INT EG ER 1 1

1 <<Identifying>>

0..1 T_Siege T_Site_ID : INTEGER

<<Identifying>> 0..1 <<Identifying>> T_ReapprovisionnementPointDeVente T_Usine 1 <<Non-Identifying>> 1 <<Identifying>> T_CommandeFournisseur date : SMALLINT T_CommandeFournisseur_ID : INTEGER T_Site_ID : INTEGER COL_13 : INTEGER T_Element_ID : INTEGER COL_14 : INTEGER T_Partenaire_ID : INTEGER COL_15 : INTEGER 0..* << Non- Identi fy >> ing 1 0..* 0..* 0..* 0..1 0..* <<Identifying>>
1 1

T_Site_ID : INTEGER

<<Non-Identifying>>

0..*

quantite : SMALLIN T T_Site_ID : INT EG ER COL_12 : INTEGER T_Element_ID : IN TEGER

0..*

0..*

<<Non-Identifying>> 0..*

1 T_PointDeVente T_Site_ID : INT EGER

0..*

T_StockUsine date : SMALLINT quantite : SMALLINT T_Element_ID : INTEGER T_Site_ID : INTEGER <<Non-Identifying>> 0..* <<Identifying>> 1 << Identi fy >> ing

1 T_Fournisseur T_Partenaire_ID : INTEGER 0..1 <<Identify ng>> i

<<Identifying>> <<Non-Identifying>> 1
1

<<Non-Identifying>>

<<Non-Identifying>>

0..* 1 T_QuantiteMP quantitemp : SMALLINT T_QuantiteMP_ID : INTEGER COL_14 : INTEGER T_CommandeFournisseur_ID : INTEGER 1 <<Identifying>>
1

T_Element reference : SMALLINT prix : SMALLINT T_Element_ID : INTEGER <<Identifying>> 1

1
1

1 0..1 T_Produit 1
1

<<Identifying>>

T_Element_ID : INTEGER 1 << Identi fy >> ing

T_Partenaire nom : SMALLINT adresse : SMALLINT datecreation : SMALLINT T_Partenaire_ID : INTEGER

1

0..1 T_MatierePremiere

<<Non-Identifying>> 0..*

0..*

T_Element_ID : INTEGER COL_14 : INTEGER 0..*

<< Identifying >> 0..1 1

0..* T_CommandeClient <<Non-Identifying>>

T_Client T_Partenaire_ID : INTEGER 1 0..*

date : SMALLINT couttotal : SMALLINT T_CommandeClient_ID : INTEGER T_Site_ID : INTEGER T_Partenaire_ID : INTEGER

1 <<Identifying>>0..*
1

T_QuantiteProduit quantitep : SMALLINT T_CommandeClient_ID : INTEGER T_Element_ID : INTEGER

Bases de donnes rparties

-8-

Anne 2004

Chaque classe persistante a donn une table. Chacun des attributs a donn un champ dans la table. Rose a cr un champ supplmentaire dans la table parent pour accueillir une cl primaire gnre par numrotation automatique (paramtrage par dfaut). Le logiciel a aussi insr une cl trangre dans la table fille correspondante. Les relations dans le diagramme des classes ont t traduites en relations classiques notes non Identifying . Les agrgations ont donn des relations de type Identifying . Pour renforcer le fait quun fils ne peut exister sans un pre, la cl trangre du fils vers le pre est aussi un lment de la cl primaire du fils. Notons que Rose ne sachant pas grer les classes d'association, il faut crer les relations entre nos tables la main dans le schma. On utilise alors licne qui permet de crer des "Identifying relationship" ou des "Non Identifying relationship" (agration ou non). On clique alors sur la classe concerne et on relche le bouton sur la classe dassociation.

B. Dfinitions et hypothses
Tableaux de bord : Les tableaux de bord (TdB) sont mensuels. les TdB de l'activit commerciale contiennent : . la quantit de produits vendus . le CA mensuel . le nombre de nouveaux clients . le panier moyen d'un client (nombre moyen de produits, CA moyen par client) Les TdB de l'activit de production contiennent : . l'tat du stock produit en fin de mois . l'tat du stock MP en fin de mois . la quantit de MP commande sur le mois . la quantit totale de produits commands par point de vente Gestion du quotidien des salaris : Dans chaque site, point de vente et usine, la gestion du quotidien des salaris correspond la gestion de leur temps de travail et congs. Gestion des produits : La gestion des stocks est ralise dans les usines, par contre, le catalogue produit et la description des produits sont raliss au niveau du sige social. Gestion des salaris : L'laboration de toutes les feuilles de paye est faite au sige puis retransmise par courrier aux points de ventes et usines. Mcanisme de rapprovisionnement des points de vente : A un point de vente correspond une unique usine vers laquelle les commandes de rapprovisionnement sont mises. Dans le cas o la commande dpasse le niveau du stock disponible dans cette usine, c'est celle-ci de dcider si elle lance une chane de production pour honorer la commande ou si elle puise dans le stock d'autres usines.

Bases de donnes rparties

-9-

Anne 2004

C. Schma de chaque site

Pour arriver aux schmas suivants avec Rose, nous avons dupliqu le schma gnral pour avoir autant de copies qu'il y a de types de sites. Ensuite, on supprime les tables qui ne sont pas voulues dans chacun des schmas (par rapport ce que l'on veut sur le site). 1. Sige Le sige, en raison des tableaux de bord dont il a besoin, possde le schma complet de la base de donnes. Par contre, les donnes pourront tre physiquement sur les sites, selon les fragmentations dtailles ci-aprs. 2. Usine
T_Salarie nom : SMALLI NT prenom : SMALLIN T dateembauche : SMALLINT T_Salar ie_ID : INTEGER T_Site_ID : INT EGER <<Non-Identifying>> 1
1

T_ActiviteSalarie heuresup : SMALLINT congespris : SMALLINT T_ActiviteSalarie_ID : INTEGER T_Salarie_ID : INTEGER

1..*

1 <<Non-Identifying>> 0..*
1

<<Non-Identifying>>

Fragmentation horizontale : chaque site ne voit que ses salaris

<<Non-Identifying>> 1..* T_Mois

0..*

mois : SMALLINT T_Mois _ID : INT EGER T_ActiviteSalar ie_ID : INTEGER T_Salarie_I D : INTEGER

T_Site nom : SMALLINT adresse : SMALLINT T_Site_ID : INTEGER 1 1

<<Identifying>> 0..1 <<Identifying>> T_ReapprovisionnementPointD eVente quantite : SMALLINT T_Site_ID : INTEGER COL_12 : INTEGER T_Element_ID : INTEGER

T_Usine 1 <<Non-Identifying>>
1

T_Site_ID : INTEGER 1

<< Non- Identify ing> >

0..*

<<Identifying>> T_CommandeFournisseur date : SMALLINT T_CommandeFournisseur_ID : INTEGER T_Site_ID : INTEGER COL_13 : INTEGER T_Element_ID : INTEGER COL_14 : INTEGER T_Partenaire_ID : INTEGER COL_15 : INTEGER 0..* <<Non-Identifying>> 1 0..* 0..* 0..* 0..1 0..* << Identifying >>
1 1

0..*

<< Non- Identi fy ing> > 0..*

1 T_PointDeVente T_Site_ID : INTEGER

T_StockUsine date : SMALLIN T quanti te : SMALLIN T T_Element_ID : INTEGER T_Site_ID : INT EGER 0..* <<Identifying>>

Fragmentation horizontale : chaque usine ne voit que son point de vente (rappel : nous avons suppos qu' un point de vente correspond uen usine unique)

1 T_Fournisseur T_Par tenai re_ID : INTEGER 0..1 <<Identifying>>

<<Identifying>> <<Non-Identifying>>
1

Fragmentation horizontale : chaque usine ne voit que son stock

<<Non-Identifying>>

0..*
1

1
1

T_Element reference : SMALLINT prix : SMALLIN T T_Element_ID : INTEGER <<Identifying>>

1

T_Partenaire nom : SMALLINT adresse : SMALLINT datecr eation : SMALLINT T_Par tenai re_ID : INTEGER
1 1

T_QuantiteMP quantitemp : SMALLINT T_QuantiteMP_ID : INTEGER COL_14 : INTEGER T_CommandeFournisseur_ID : INTEGER

1 0..1 T_MatierePremiere

<< Identifying >>

0..*

T_Element_ID : INTEGER COL_14 : INTEG ER

<<Identifying>> 0..1 1

T_Client T_Partenaire_ID : INTEGER

Bases de donnes rparties

- 10 -

Anne 2004

3. Point de vente
T_Salari e nom : SMALLINT prenom : SMALLINT dateembauche : SMALLINT T_Salarie_ID : INTEGER T_Site_ID : INTEGER <<Non-Identif y ing>>
1

T_Activ iteSalarie heuresup : SMALLINT congespris : SMALLINT T_Activ iteSalarie_ID : INTEGER T_Salarie_ID : INTEGER

1 1

1..*

<<Non-Identif y ing>> 0..*

<<No n-I dent if y ing >> 0..*

Fragmentation horizontale : chaque site ne v oit que ses salaris

<<Non-Identif y ing>> 1..*

T_Mois mois : SMALLINT T_Mois_ID : INTEGER T_Activ iteSalarie_ID : INTEGER T_Salarie_ID : INTEGER

1 T_Sit e nom : SMALLINT adresse : SMALLINT T_Site_ID : INTEGER 1 <<Identif y ing>> 0..1 <<Identif y ing>> T_Reapprov isionnementPointDeVente T_Usine T_Site_ID : INTEGER
1

<<Non-Identif y ing>> 0..*

quantite : SMALLINT T_Site_ID : INTEGER COL_12 : INTEGER T_Element_ID : INTEGER

0..* 0..1 <<Identif y ing>> Fragmentation horizontale : chaque point de v ente ne v oit que son usine (rappel : nous av ons suppos qu' un point de v ente correspond uen usine unique) 1 T_PointDeVente T_Site_ID : INTEGER
1

0..*

<<Identif y ing>>

<<Non-Identif y ing>>

T_Element ref erence : SMALLINT prix : SMALLINT T_Element_ID : INTEGER

1

1 1 <<Identif y ing>> 0..1 T_Pro duit T_Element_ID : INTEGER

T_Partenaire no m : SMALLINT ad ress e : SMALLIN T da tecreat io n : SMALLIN T T_ Part enaire _ID : INTEG ER 1 <<Identif y ing>> 0..1 T_CommandeClient T_Client T_Partenaire_ID : INTEGER
1 1

1 <<Identif y ing>>

0..* 0..*

<<Non-I dent if y ing>> 1 0..*

date : SMALLINT couttotal : SMALLINT T_CommandeClient_ID : INTEGER T_Site_ID : INTEGER T_Partenaire_ID : INTEGER

<<Identif y ing>> 1 0..*

1

T_QuantiteProduit quantitep : SMALLINT T_CommandeClient_ID : INTEGER T_Element_ID : INTEGER

Fragmentation horizontale : chaque point de v ente ne v oit que ses commandes et ses clients

Bases de donnes rparties

- 11 -

Anne 2004

D. Exemple de rpartition des donnes en fonction des hypothses retenues

Les principes appliqus sont les suivants : essayer de ne faire que des consultations (select...) entre les sites essayer de ne faire que des modifications (insert...) sur les bases de donnes locales (si ce nest pas possible, il faut rviser la fragmentation). 1. Fragmentations horizontales La fragmentation horizontale est une slection qui permet de dporter les donnes sur un site, de faon ce que lon nait pas besoin daccder aux liens tlcoms pour raliser des actions (consultation et mises jour) sur ses donnes. Table des salaris (T_Salarie) et table des activits des salaris (T_ActiviteSalarie) : Nous considrons que ces tables doivent tre fragmentes horizontalement pour que chaque site puisse accder en local aux informations des salaris qui lui sont rattachs. Il est cependant souhaitable que le sige conserve une vue sur lensemble de ces tables. Gestion des stocks et des produits : Nous retenons le choix dune fragmentation horizontale de la table des stocks usine (T_StockUsine). Cette table est accessible par les autres usines, pour autoriser les transferts de stocks par exemple, et le sige social par une consultation sur le rseau, sans rplication. 2. Fragmentations verticales La fragmentation verticale est une projection. Elle permet de ne rpartir sur chaque site que les champs ncessaires, pour acclrer les accs aux informations concerns et rpartir le moins possible les informations. En effet, dans ce cas, lors dun insert, il faut lancer un trigger dans les tables des autres types de site (cest dire le reste de la table d'origine) afin de vrifier lunicit de la cl, etc. Nous navons pas russi reprsenter ces fragmentations verticales dans Rose, la suppression de lattribut dans un schma le supprimait dans tous. Table des fonctions des salaris (T_FonctionSalarie) : Nous considrons que cette table doit tre locale au sige social avec cependant une fragmentation verticale sur le champ rgime horaire afin de permettre chaque site point de vente et usine dy accder afin de grer le quotidien de ses salaris en termes de suivi du temps de travail. 3. Rplication Le principe est de recopier sur un ou plusieurs sites une relation. Son intrt est daugmenter la disponibilit des donnes (on reste en effet sur le rseau local) et le paralllisme en lecture et de diminuer le cot impos par les transmissions. Ses inconvnients sont par contre, la difficult dassurer la cohrence des diffrentes copies et la propagation des mises a jour, ainsi que le besoin en espace de stockage. Gestion des stocks et des produits : Le catalogue produit est local au sige pour une gestion centralise du rfrencement. Chaque site point de vente et usine possde une copie rplique de ce catalogue. La frquence de mise jour de la rplication est hebdomadaire.

Bases de donnes rparties

- 12 -

Anne 2004

Gestion des fournisseurs (T_Fournisseurs) : Un fournisseur pouvant fournir plusieurs usines, il est justifi que la table des fournisseurs soit gre au sige de manire centralise. Par contre, il nous parat indispensable que celle-ci soit rplique de faon diffrentielle sur chaque site usine (transmission des modifications uniquement), les mises jour trs occasionnelles depuis les usines pouvant tre ralises par accs rseau. 4. Agrgation par vue Une agrgation par vue permet de faire des consolidation entre les donnes de tous les sites. Ceci est trs utile (surtout pour du dcisionnel) mais implique la rcupration de beaucoup de donnes (grand besoin en espace de stockage) de tous les sites (ce qui augmente les frais tlcoms). Dans ce cas, la diffrentiation des cls de chacun des sites se fait avec un prfixe pour chaque site (pour que la commande n10 de Toulouse soit bien diffrente de la n10 de Lyon pour le sige social qui voit toutes les commandes). Ce prfixe peut tre paramtr dans la rgle de cration des cls dans les bases ou on indique un libell lors de la cration de la vue "select 'toulouse'||cle ". Par exemple, le sige a une vue de toutes les commandes pour faire des tableaux de bord, mais sur lesquelles il ne peut pas faire de modification.

Bases de donnes rparties

- 13 -

Anne 2004

Simulation de l'utilisation

A. Cration de la base de donnes

Rational Rose permet de crer le fichier SQL correspondant aux bases de donnes modlises. Il sobtient en faisant un clic droit sur le diagramme et en choisissant Data Modeler Forward engineer . On prcise alors ce que l'on veut dans le fichier, notamment les noncs drop table qui permettent de recrer la totalit de la base simplement durant la priode de dveloppement. Dans ce fichier, on peut remarquer en particulier que les noncs permettant de crer les cls sont gnrs automatiquement partir de ce qui est indiqu dans le schma. Dans ce fichier, il faut remplacer no action par cascade car "no action" n'est pas un mot cl de la norme SQL 92 et n'est donc pas reconnu par oracle

B. Quelques requtes de test

Pour simuler plusieurs clients, on va ouvrir plusieurs sessions sous SQL PLUS (puisque nous n'avons pas encore d'interface graphique pour le logiciel). Pour se connecter, on indique le login, le mot de passe et la chane de connexion (ou alias ou encore host string ). Ici, nous indiquons : BDD1. Elle fait rfrence au service oracle cr lors de l'installation avec le logiciel Oracle orant8i -> Networkadministration -> Net8EasyConfig. On indique alors le protocole de communication sur le rseau (TCP/IP), ladresse IP de la machine sur laquelle se trouve le serveur de BDD Oracle, sur quel port TCP et le noyau oracle de la base de donnes concern, cest dire lidentifiant de l'instance de base de donnes Oracle. Oracle nous permet de crer des "Liens de base de donnes" qui sont des triplets : nom, user et host string. Ils permettent de prciser dans une requte SQL quelle base de donnes est destine la commande. Dans notre cas, il faut crer des liens pour permettre les requtes entre base de donnes des diffrents sites. Example : select * from salarie@linksiegeusine1 si linksiegeusine1 est le nom du lien entre la base de sige et celle de lusine 1. On crera alors une session dans la base de donnes (avec les informations indiques dans le lien) pour faire la requte. Les droits d'accs la table indique dans la requte doivent aussi permettre l'utilisateur indiqu dans le lien de BDD de faire la requte. Dans notre cas, il faut crer des liens pour permettre au sige daccder aux informations des bases prsentes sur chaque site par exemple. Remarque : un utilisateur est propre une BDD dans Oracle. L'administrateur de la BDD devra donc crer des utilisateurs avec les mmes informations pour chacune des bases.

Bases de donnes rparties

- 14 -

Anne 2004

Conclusion
La manire de faire expose prcdemment est certes pdagogique et didactique, mais elle ne sera vraisemblablement bientt plus dactualit dans la pratique lorsque XML SGBD grera tout ceci en automatique ! Restera toujours aux humains raliser la conception initiale, matire noble sil en est !

Bases de donnes rparties

- 15 -

Anne 2004

Annexes

Commentaires sur le cours dispens lEISTI

1. Pdagogie et organisation Il nous apparat avec le recul que le cas trait aurait pu tre retenu comme fil rouge pour lensemble des cours consacrs lESSEC et lEISTI aux bases de donnes, requtes SQL, utilisation de Business Object, pratique de Rational Rose. Il aurait ainsi apport le lien pratique continu indispensable pour repositionner clairement les diffrents lments thoriques entre eux au fil dune construction de solution globale telle quelle sappliquera dans les faits en entreprise. En termes dorganisation, nous regrettons comme notre professeur que les travaux pratiques en gnral (mais ctait particulirement criant pour ce cas) se fassent en classe complte (seule exception pour BO) alors quune rpartition en demi-groupes permettrait au professeur daccompagner efficacement les stagiaires, ou en tous les cas de leur consacrer un peu plus de temps et dexplications par quipe de TP. 2. Contenu Sur le cas lui-mme et le contenu du cours associ, nous navons pas de remarque particulire formuler, mais des remerciements pour les apports thoriques et pratiques ainsi que pour la qualit dcoute nos questions et interrogations.

Bases de donnes rparties

- 16 -

Anne 2004