MIF24 - TD 1

Conception de BDR
UCBL - Département Informatique de Lyon 1 – 2018

L’objectif de ce TD est de vous familiariser avec les principes de conception d’une base de données
répartie à partir d’une base centralisée existante. A la fin de ce TD, vous devez maîtriser le principe
de la migration, de la réplication et les différentes stratégies de fragmentation (horizontale, horizontale
dérivée, verticale, mixte) que ce soit avec selon la méthodologie basée sur les données ou celle basée sur
les requêtes.

Contexte
La base de données du confiseur ’BANNOT’ implanté en région Auvergne-Rhône-Alpes est définie
selon le schéma suivant :

Secteur (dept,nom, zone) est une relation stockant les secteurs de commercialisation et de fabri-
cation des confiseries, avec :
— dept est le numéro du département de la région Auvergne-Rhône-Alpes,
— nom désigne le nom d’un département de la région Auvergne-Rhône-Alpes,
— zone désigne l’appellation de la zone : Auvergne, Lyonnais, Dauphiné, Savoie.
Confiserie (idC, nom, typeC, descr) est une relation stockant le catalogue de confiseries, avec :
— idC est un entier qui identifie une confiserie,
— nom désigne le nom de la confiserie,
— typeC représente le type de confiserie tel que ’chocolat’, ’caramelConfiseries’, ’guimauve’ . . .
— descr désigne la description de la confiserie incluant les ingrédients.
Usine (idU, adr, ville, #dept, resp) est une relation stockant les différentes usines de production
de bonbons, avec :
— idU est un entier qui identifie une usine,
— adr désigne l’adresse postale de l’usine,
— ville désigne le nom de la ville où est implantée l’usine,
— dept désigne le numéro du département où est implantée l’usine,
— resp désigne le nom suivi du prénom du responsable de l’usine.
ChaineProd (#idU , #idC, resp, tel, prixUnit) est une relation stockant les informations sur
les chaînes de production de confiseries, avec :
— idU référence l’usine dans laquelle se trouve la chaîne de production,
— idC référence la confiserie qui est produite dans la chaîne de production,
— resp désigne le nom suivi du prénom du responsable de la chaîne de production,
— tel désigne le numéro de téléphone permettant de contacter la chaîne de production,
— prixUnit désigne le prix unitaire exprimé en euro de la confiserie produite dans la chaîne de
production.

1
 Stock (#idU, #idC, dateF, dateP, qte) est une relation stockant les informations relatives au
stock disponible d’une confiserie par rapport à un chaîne de production, avec :
— idU référence une usine,
— idC référence la confiserie stockée,
— dateF désigne la date de fabrication de la confiserie dans la chaîne de production,
— dateP désigne la date de péremption de la confiserie produite,
— qte désigne la quantité de confiseries ’idC’ fabriquée en date du ’dateF’ et stockée dans l’usine
’idU’.
Boutique (idB, nom, ville, typeB, mail, CAmoyen) est une relation stockant les informations
relatives aux boutiques distribuant les confiseries produites, avec :
— idB est un entier identifiant la boutique,
— nom désigne le nom de la boutique,
— ville désigne le nom de la ville où se trouve la boutique,
— typeB désigne le type de boutique considéré : Usine, Franchisé, Dépôt. . .
— mail désigne le mail permettant de contacter la boutique,
— CAmoyen désigne le chiffre l’affaire moyen de la boutique sur les 5 dernières années.
Vente (#idU, #idB, dateV, montant, remise) est une relation stockant les différentes ventes
effectuées par l’usine (idU) pour approvisionner la boutique (idB), avec :
— idU référence l’usine ayant vendu les confiseries,
— idB référence la boutique ayant acheté les confiseries,
— dateV désigne la date de la transaction,
— montant désigne le montant total de la transaction exprimé en euros,
— remise désigne le rabais effectué exprimé en pourcentage en fonction des quantités de confiseries
commandée. Pour les boutiques de type ’Usine’ correspondant au magasin d’usine la remise est de
100%.
Detail(#idU, #idB, dateV, #idC, qte) est une relation stockant le détail d’une vente, avec :
— idU,idB,dateV référence une vente,
— idC référence la confiserie achetée,
— qte désigne la quantité de confiserie (idC) achetée.

Exercice 1 : Quelques requêtes

L’objectif de cet exercice est de vous familiariser avec le modèle centralisé de la base de données ’BAN-
NOT’.
Écrire en SQL, les requêtes suivantes :
1. Donner les ventes qui ont été effectuées en 2014 et qui concernent des confiseries de type guimauve
issues des usines localisées dans le secteur lyonnais.
2. Donner le nom et la ville des boutiques n’ayant jamais distribué de confiserie de type chocolat.

Approche orientée données

Exercice 2 : Répartition des données

L’objectif de l’exercice est d’analyser les contraintes proposées sous forme d’hypothèses pour en déduire
une décomposition de la base de données.

2
 On considère les quatre sites : ’Lyon’ , ’Clermont-Ferrand’, ’Valence’ et ’Annecy’ et on considère les
hypothèses suivantes :

H1. Le site de Lyon gère les usines du secteur ’Lyonnais’ ; le site de Clermont-Ferrand gère les usines du
secteur ’Auvergne’ ; le site de Valence gère les usines du secteur ’Dauphiné’ ; le site d’Annecy gère les
usines du secteur ’Savoie’.

H2. Les chaînes de production sont gérées sur les mêmes sites que les usines auxquelles elles sont ratta-
chées.

H3. Les données relatives aux coordonnées des boutiques (nom, ville, typeB, mail) sont gérées de la
manière suivante :
— le site de Clermont-Ferrand gère les boutiques de type ’Franchisé’,
— le site de Valence gère les boutiques de type ’Usine’,
— toutes les autres boutiques sont gérées sur le site d’Annecy.
H4. Les données relatives au chiffre d’affaires des boutiques sont confidentielles et elles sont centralisées
sur un serveur sécurisé à Lyon.

H5. Les données relatives aux confiseries n’évoluent que très peu et elles sont nécessaires sur tous les sites.

H6. Les données sur les stocks évoluent en permanence et sont nécessaires sur tous les sites.

H7. Les ventes sont réparties selon leur montant. Le site de Valence ne stocke que les ventes d’un montant
inférieur ou égal à 500e et le site d’Annecy ne stocke que les ventes de montant strictement supérieur
à 500e.

H8. Les détails des ventes sont gérés sur les sites qui gèrent les ventes associées.

1. Spécifier le traitement (migration, réplication ou fragmentation horizontale, horizontale dérivée,

verticale) à appliquer à chaque table de la base ’BANNOT’ pour effectuer une décomposition de
la base respectant les hypothèses H1. ... H8..
2. A partir des hypothèses H1. ... H8., proposer une décomposition sous la forme de définitions
algébriques des tables ’Secteur’,’Usine’, ’ChaineProd’, ’Confiserie’ et ’Boutique’ de la base de
données ’BANNOT’ sur les sites de Lyon, Clermont-Ferrand, Valence et Annecy en fonction des
hypothèses données précédemment.
Pour simplifier la notation et gérer de manière implicite l’allocation des fragments, vous pourrez
indexer vos fragments par un 1 quand ils sont alloués au site de Lyon, par un 2 quand ils sont
alloués au site de Clermont-Ferrant, par un 3 quand ils sont alloués au site de Valence et par un
4 quand ils sont alloués au site d’Annecy.

Exercice 3 : Reconstruction d’une vue globale sur les données

L’objectif de cet exercice est de montrer le caractère reconstructible de votre décomposition.

Définir algébriquement les vues nécessaires pour accéder (selon le schéma initial de la base de données)
aux données des fragments définis dans l’exercice 2 pour les tables ’Usine’, ’ChaineProd’, ’Confiserie’
et ’Boutique’.

Exercice 4 : Implantation sous Oracle

L’objectif de cet exercice est de distinguer les différentes structures nécessaires pour implanter les frag-
ments dans la base de données répartie.

3
 1. Expliquer et justifier le choix de structure que vous ferez en TP, pour implanter :
— Usinei i=1,2,3,4
— Confiseriei i=1,2,3,4
— ChaineProd de l’exercice 3.

Approche orientée requêtes

Exercice 5 : Fragmentation
Pour la suite, on suppose que la majorité des requêtes interrogeant la base sont les requêtes suivantes :
− R1 : SELECT adr , r e s p FROM Usine WHERE r e s p LIKE ’T%’ ;
− R2 : SELECT idU , r e s p FROM Usine WHERE v i l l e = ’ Lyon ’ ;
− R3 : SELECT ∗ FROM Usine WHERE r e s p LIKE ’T%’ AND v i l l e != ’ Lyon ’ ;

1. A partir des requêtes R1, R2 et R3, proposer une fragmentation de la table Usine.
2. On suppose maintenant que le site de Lyon émet régulièrement la requête R1 et R2, le site
de Valence émet régulièrement la requête R2 et R3 et le site d’Annecy émet régulièrement les
requêtes R3 et R1. Proposer un plan d’allocation des fragments définis à la question précédente.