Ces données éparpillées doivent être maintenant rassemblées dans une base centrale

Dans quel but ?

Que toutes les applications utilisent cette base centrale, ou bien seulement pour faire des statistiques et sortir des rapports ?

Ok... dans ce cas, il faut prévoir un serveur de base de données assez costaud pour supporter la charge.

Il faut essayer d'évaluer le nombre de connexions SQL simultannées, la quantité de données reçu/envoyée par les différentes applications, évaluer les volumes de données,

pour essayer de voir quel type de serveur acheter (puissance CPU ? RAM ? capacité disque dur ?)

Prévoie également les backups
(sur quel support, à quelle fréquence ?)

Prévoir l'infrastructure réseau pour supporter tout ce traffic (où sont situées les applications qui accèderont à la base (même site ou pas ?) etc.


Choisir un serveur de base de données capable de supporter une bonne charge (PAR mySQL, PAS access, mais plutôt Oracle ou Posgresql, voir MS SQL Server...)


Contacter aussi les responsable du développement de chaque application, et voir s'il est possible de changer leur base de données actuelle avec celle que tu aura choisie (et SI c'est possible !).


Et j'en oublie...


Bref... tu vois, y'a pas une recette miracle et absolue pour ce genre de chose.
Il faut évaluer les besoins, les contraintes et trouver la meilleure solution.

les bases devront être oubliées

Comment ça, "oubliées" ?


Tu veux dire que une fois que les rapports sur la qualité des données seront sortis, il ne faudra pas conserver la copie des bases d'origine ?

Dans ce cas, il suffit de supprimer la base aggrégée.

Non, ce que je veux dire est que la société peut souhaiter que ce soit la base centralisée qui sert de support pour toutes les applications, dés qu'elle est fonctionnelle

Dans ce cas, ça ne colle pas du tout avec le datawarehouse.

De rien :-)

Je voudrais avoir les schemas de l'architectures matérielle et fonctionnelle de l'OCB283