PROJET MIGRATION DES DONNÉES AppliFrais

http://www.reseaucerta.org © CERTA - février 2017 – v1.2 Page 1/3
PROJET MIGRATION DES DONNÉES
AppliFrais
Propriétés Description
Intitulé Réimplantation des données de l’ application de gestion des frais de déplacement
(AppliFrais) sur un nouveau SGBD.
Présentation
Rapide L'application permet d'établir une gestion précise et uniforme entre les entités
concernées du laboratoire.
Positionnement
>>>>
Durée estimée
en heures 16 heures
Savoir-faire SI
mobilisés en
priorité
Les savoir-faire de la phase d'étude du projet, auxquels s'ajoutent :
SI3 - Extraire et modifier les données d’une base de données
SI3 - Implémenter une base de données à partir d’un schéma existant
SI4 - Programmer à l’aide d’un langage de programmation structurée
SI4 - Programmer en utilisant des classes d’objet fournies
SI4 - Appliquer des normes de développement
SI6 - Valider et documenter une application
SI6 – Mettre à jour une documentation technique
SLAM1 – Modifier un schéma de données et l’implantation de la base de données
correspondante
SLAM1 – Utiliser un outil de génération et de rétro-conception de base de données
SLAM1 – Adapter une application exploitant une base de données à l’évolution de son
schéma
SLAM2 – Mettre au point un programme
Notions EDM
Documents joints Cahier des charges, base de données exemple et scripts de génération de contenu de
test, application AppliFrais en son état de développement initial.
Modalités de
réception Production d'un procédé opérationnel, éprouvé et testé - recette
Équipes Par équipe de ...  2  3  4
Planning

http://www.reseaucerta.org © CERTA - février 2017 – v1.2 Page 2/3
CAHIER DES CHARGES
Définition du besoin
Définition de l'objet
Le suivi des frais est actuellement géré par le biais de l’application AppliFrais en son état initial de
développement. Cette application exploite une base de données relationnelle MySQL.
Bien que libre et gratuit, le SGBD MySQL n’entre pas dans la politique actuelle des produits
recommandés par le schéma directeur.
Le laboratoire Galaxy Swiss Bourdin, par son cœur de métier gros consommateur de données, est lié
depuis de nombreuses années avec le fournisseur Oracle Corp, éditeur du SGBD Oracle. Pour cette
raison, pour tout développement pérenne où une base de données relationnelle est utilisée la politique
interne recommande d’utiliser Oracle comme SGBD support. En effet, une infrastructure de serveurs
Oracle dédiés est disponible sur le réseau quelque soit le site. Par ailleurs, les compétences
nécessaires à l’administration et à l’exploitation des bases de données Oracle sont aussi présentes au
sein de l’entreprise. Sans compter le contrat de support qui permet à l’organisation d’escalader les
dysfonctionnements non résolus localement auprès des spécialistes chez le fournisseur lui-même.
Forme de l'objet
Le module Visiteur de l'application Web Applifrais est en ligne, accessible depuis un ordinateur. Le
code source correspondant à ce module ainsi que sa base de données sont fournis en complément
de façon à pouvoir mettre au point un procédé de migration éprouvé, testé sur une copie opérante et
représentative de l’objet réel.
Le module Comptable de cette même application, et dont le développement est encore en cours, est
aussi concerné par cette étude du fait qu’il partage la même base de données. Si ce module impacte
la structure de la base de données, il sera nécessaire d’en tenir compte.
Besoin complémentaire
Afin d’améliorer certains traitements mais aussi de permettre un contrôle des données après
enregistrement, il est attendu que trois procédures stockées soient développées (ici des fonctions).
Pour une fiche de frais donnée, elles auront pour objet respectif de calculer :
 le montant total des frais hors forfait ;
 le montant total des frais forfaitisés ;
 le montant total à rembourser de la fiche.
Contraintes
Architecture
L’architecture applicative demeurera intacte et l’application ne devra être modifiée qu’à la marge afin
d’éviter tout effet de bord mal contrôlé et toute remise en cause forte de l’existant. Par modifications à
la marge, il faut entendre :
 Modifications des éléments de configuration qui permettent à l’application d’atteindre la base
de données sur le réseau Galaxy Swiss ;
 Modifications liées à d’éventuelles retouches faites à une structure de base de données jugée
déficiente (pertinence à justifier) ;
 Modifications liées à la centralisation de certains traitements qu’Oracle rendra possible par
l’emploi de triggers et/ou procédures stockées (pertinence à justifier).
 Les spécifications des cas d’utilisations demeureront impérativement inchangées.
Jeu de caractères
La base de données une fois migrée sous Oracle devra être encodée en UTF-8 pour préserver les
capacités à faire évoluer l’ensemble dans la modernité du moment. Les données ne devront subir
aucune altération durant le procédé de migration.

http://www.reseaucerta.org © CERTA - février 2017 – v1.2 Page 3/3
Environnement
Dans l’environnement Oracle, l’outil à privilégier pour mettre au point puis opérer la migration est SQL
Developer, édité par Oracle Corp.
Documentation
La documentation devra présenter la nouvelle structure de la base de données implantée sous
Oracle. Une attention particulière sera portée sur le descriptif détaillé des changements entre
l’ancienne base et la nouvelle. L’impact individuel de chacun des changements sera aussi à décrire.
Responsabilités
Le commanditaire fournira à la demande toute information sur le contexte nécessaire à la production
de l'application.
Le commanditaire fournira une documentation et des sources exploitables pour la phase de test :
base de données exemple, modélisation, etc.
Le prestataire est à l'initiative de toute proposition technique complémentaire.
Le prestataire fournira :
 un procédé de migration opérationnel ;
 un rapport de tests témoignant du caractère opérationnel
o de la migration ;
o de l’application après migration ;
 une documentation technique spécifiant les caractéristiques de tous les changements opérés ;
Structure de la base de données initiale