Meilleures pratiques pour la refonte d'une base de données

Je connais quelques bonnes pratiques générales lors de la conception d'une base de données pour une application, mais qu'en est-il de la refonte?

Je fais partie d'une équipe chargée de reconcevoir une application métier interne, même si je dis «interne», je suis malheureusement très loin de tout contact avec les utilisateurs réels du système.

Le programme actuel est dans Oracle Forms, dispersé sur un tas de tables non normalisées, parfois avec plusieurs tables presque en double contenant de légères variantes sur les données des autres. Les contraintes prennent souvent la forme de procédures stockées mal appliquées. Même les types ne semblent pas être stockés correctement. J'ai rencontré toutes sortes de mauvaises données qu'Oracle semble ignorer, mais a donné raison (et à juste titre) à l'assistant d'importation / exportation de SQL Server. (Par exemple, des nombres entiers à deux chiffres ne constituent pas une date / heure complète!)

Le programme d'origine remonte probablement à vingt ans, et tous les développeurs d'origine ont pris leur retraite il y a si longtemps que même les personnes âgées ici n'ont aucune idée de qui elles étaient. En conséquence, il n'y a pas non plus vraiment d'exigences claires à respecter - nous sommes simplement censés dupliquer les fonctionnalités de l'application existante et conserver ses données existantes.

Le résultat final de la réécriture va être une version Web exécutée sur ASP.NET avec MS SQL Server pour le back-end.

Mes deux autres coéquipiers développeurs sont beaucoup, beaucoup plus âgés que moi, tous les deux issus du milieu des affaires / MIS alors que le mien est CS. L'expérience du membre senior a été presque exclusivement des formulaires Oracle et l'autre membre a principalement effectué des applications métier en Visual Basic. Bien que mes antécédents en matière de bases de données se soient limités à la conception de nouvelles bases de données pour des projets dans MySQL ou SQLite, principalement pour mes cours de premier cycle, il semble que je sois le seul à avoir réellement conçu des bases de données.

J'ai déjà écrit un petit programme en C # qui lit toutes les données existantes dans un format neutre, prêt à être re-casté et placé dans une nouvelle base de données. Je prévois d'écrire le code de chargement après la conception de la base de données de destination, afin que les données puissent être correctement réparties entre les nouvelles tables normalisées, ajoutées dans le bon ordre pour suivre les nouvelles contraintes, etc. Le même programme pourrait ensuite être exécuté de nouveau plus tard pour copier les données de production dans la vraie refonte terminée récemment déployée. Cela laisse la refonte réelle de la base de données comme la principale chose à comprendre.

Donc, le cœur de ma question: quelles sont les meilleures pratiques pour effectuer une refonte à partir du niveau de la base de données d'une application existante?

Je pense que vous savez déjà comment normaliser une base de données.

Vous avez besoin de stratégies pour minimiser les risques lors du déplacement de tous les logiciels vers la nouvelle base de données.

Ce que je suggère, c'est plus de travail comme compromis pour moins de risques.

Normalisez la base de données et créez un processus pour remplir la base de données normalisée avec les données de la base de données d'origine. La base de données d'origine sera la base de données pour les insertions, les mises à jour et les suppressions. La base de données normalisée sera la base de données de requête uniquement pendant la conversion.

Votre processus de remplissage devra être exécuté aussi souvent que le besoin de données de requête. Si des données anciennes sont acceptables, vous pouvez exécuter un processus de remplissage nocturne. Si vous avez besoin de données plus récentes, vous devez exécuter un processus de remplissage continu.

Générez la partie requête de votre nouveau système ASP.NET, en pointant vers la nouvelle base de données normalisée.

Les résultats de la requête de votre nouveau système doivent être comparables aux résultats de la requête du système d'origine.

Vous pouvez vous arrêter à ce stade. C'est une décision commerciale, pas une décision technique.

À votre guise, vous créez de nouvelles fonctionnalités d'insertion / mise à jour / suppression dans votre nouveau système ASP.NET. Lorsque vous créez la nouvelle fonctionnalité, vous désactivez les parties du système d'origine qui correspondent. À un moment donné, il ne reste rien du système d'origine.

Les avantages de la conversion de cette manière réduisent les risques en créant d'abord la partie requête. Généralement, les fonctions de requête sont simples par rapport à la logique métier intégrée dans la fonctionnalité d'insertion / mise à jour / suppression.

Vous convertissez la fonctionnalité d'insertion / mise à jour / suppression un processus à la fois. S'il y a un problème de mauvaise compréhension de la logique métier, il peut être résolu pendant que vos utilisateurs utilisent le système d'origine.

Il va sans dire que votre processus de remplissage doit être absolument cohérent.

Essayez de les convaincre de confier le développement du nouveau système à une entreprise extérieure, il existe de nombreuses bonnes sociétés de développement qui ont les ressources pour développer correctement des applications plus rapidement et mieux que votre équipe limitée. Une bonne entreprise de développement sera également en mesure de forcer vos supérieurs à faire des choses qu'ils ne pourraient pas faire si vous en faisiez la demande, le PM de l'entreprise payé beaucoup d'argent pour développer une application a beaucoup plus d'attrait pour obtenir la participation des utilisateurs que l'informatique de nombreux niveaux en dessous de l'autorité de gestion pour organiser de telles choses.

Cela coûte beaucoup d'argent à l'avance, mais cela rapportera beaucoup de temps d'avoir les ressources appropriées pour le développement et la mise en œuvre. Si vous parvenez à faire publier une demande de propositions, je parierais que les offres que vous recevez indiquent que ce que vous essayez de faire est beaucoup plus compliqué que vos gestionnaires ne le pensent.

Concevez la base de données normalisée dont vous avez besoin avec les types de données dont vous avez besoin. Ensuite, la partie la plus difficile est la migration des données. Vous devez d'abord avoir un plan sur la façon dont vous allez mapper de l'ancien vers le nouveau et ce que vous allez faire avec des données qui ne correspondent pas à la nouvelle structure. Par exemple, vous pouvez avoir des données qui ne sont plus identifiables si vous ne disposez pas de contraintes d'intégrité appropriées. Vous pouvez simplement ne pas déplacer ces données ou vous devrez peut-être les déplacer mais les joindre à un nouvel enregistrement parent appelé "Inconnu". Si une date n'est pas vraiment une date réelle, pouvez-vous mettre une valeur nulle dans le champ lors de la migration? Vous aurez besoin de réponses à ce genre de questions. Je suggère que certains des développeurs travaillent sur la modification de l'interface graphique pour utiliser la nouvelle structure de base de données et d'autres pour travailler strictement sur la migration. La migration est une tâche énorme, cela prendra beaucoup de compétence et beaucoup de temps. Ne le laissez pas après coup.

Puisque vous utilisez SQL Server, vous pouvez effectuer la migration réelle via SSIS.

Créez un bon ensemble solide de cas de test afin de pouvoir comparer les résultats avec l'ancien système avec le nouveau système.

Parce que vous avez tant d'années de données, vous voudrez peut-être migrer en deux parties. Migrez d'abord la plupart des données, puis lorsque le moment est venu de les mettre en ligne, ne migrez que les données modifiées. Bien sûr, vous devrez mettre en place des contrôles sur la base de données pour pouvoir trouver des données modifiées que vous ne possédez pas encore. Vous pouvez également envisager à ce moment si vous souhaitez archiver certaines données.

Je suis confronté à une nouvelle conception du schéma de base de données presque quotidiennement en raison de la prise en charge et du développement de plusieurs applications héritées qui sont nées sous forme de fichiers MS Access (.mdb), puis qui ont grandi en grandes bases de données avec plusieurs centaines de tables maintenant situées sur MS SQL Serveur mais ayant toujours les "décès infantiles" de la conception originale. Voici quelques pratiques que j'ai trouvées utiles pour moi:

Essayez de minimiser la surface accessible au public de votre schéma de base de données.

Cela signifie que vous devez essayer de concevoir une API publique que vous mettez à la disposition des applications externes. J'essaie normalement d'implémenter les données statiques en tant que vues (même si elles ne sont basées que sur une seule table) et les données dynamiques en tant que vues paramétrées ou en tant que procédures stockées. Pour les requêtes de données où une seule valeur suffit, on peut également utiliser des fonctions scalaires.

Seuls ces éléments (vues, procédures stockées et fonctions scalaires) sont visibles pour les applications externes (via ORM ou directement) et utilisés pour toutes les opérations CRUD. Ce schéma est ensuite complètement gelé, tandis qu'en interne, vous pouvez modifier les tables sous-jacentes, améliorer vos procédures, etc. - cela ne rompra pas la compatibilité avec votre application.

Essayez d'optimiser pour les critères du monde réel, pas pour ceux des livres.

La normalisation est un grand sujet dans chaque livre sur la conception de bases de données. Mais dans la vraie vie, il y a des cas où la normalisation ne vous apportera pas beaucoup ou même ralentira votre base de données, par exemple si vous avez des données qui sont répétées, mais que le pourcentage de répétitions est très faible, etc. Je ne suis pas contre la normalisation, ce que j'essaie de dire ici, c'est que vous devez y faire face avec un certain scepticisme et prudence.

Enregistrez la session de profilage et analysez-les.

La reconception de la base de données basée uniquement sur le schéma de la base de données n'est pas terminée. Regardez votre base de données dans sa dynamique, essayez de trouver les goulots d'étranglement lors des tests de charge et corrigez-les. Dans le cas de MS SQL Server, il existe un conseiller de réglage spécial qui peut générer des recommandations sur la trace d'activité enregistrée.

Voici ma réponse:

1. Commencez par comprendre le système de base de données actuel autant que possible. Vous devez connaître toutes les utilisations de ces systèmes ainsi que les utilisateurs. Vous devez connaître toutes les sources du système ainsi que les systèmes qu'il pourrait servir de système source.

2. Vous devez identifier toutes les différentes utilisations du système, que ce soit pour le fonctionnement, le reporting ou les deux. Identifiez les applications et le système en amont qui pourraient utiliser la base de données. Ce faisant, vous connaîtrez les éléments de la base de données actuelle qui sont obsolètes et dont vous n'avez plus besoin.

3. Analysez et comprenez également le processus ETL actuel qui charge les données dans la base de données et extrait les données de la base de données.

4. Comprenez tous les éléments de données de la base de données et si vous pouvez créer une matrice de boîtes qui peut vous aider à identifier les éléments en double.

5. Après avoir obtenu toutes les informations, vous pouvez aborder la refonte comme si vous conceviez la base de données pour la première fois avec les informations que vous avez recueillies dans le cadre de la collecte de vos besoins.

6. Bonne chance!