Comment plonger dans une base de données laide?

Je suis sûr que vous êtes nombreux à avoir affaire à une base de données laide. Vous savez, cette base de données qui n'est pas du tout normalisée, cette base de données où vous devez faire une grande requête douloureuse pour obtenir les données les plus triviales, cette base de données qui est en production et vous ne pouvez pas changer un peu ... vous savez , "celui-là".

Ma question est, comment gérez-vous cela?

• Essayez-vous de créer une nouvelle base de données?
• Vous abandonnez et le laissez tranquille?
• Quels conseils pouvez-vous donner?

• La première chose que je fais est de créer un diagramme entité-relation (ERD). Parfois, vous pouvez simplement décrire les métadonnées avec des outils en ligne de commande, mais pour gagner du temps, certains outils peuvent générer automatiquement un diagramme.

• Deuxièmement, examinez chaque table et chaque colonne pour vous assurer que j'apprends la signification de ce qu'elle stocke.

• Troisièmement, examinez chaque relation et assurez-vous que je comprends la relation entre les tableaux.

• Quatrièmement, lisez toutes les vues ou déclencheurs pour comprendre l'application personnalisée de l'intégrité des données ou les opérations en cascade.

• Cinquièmement, lisez toutes les procédures stockées. Lisez également les privilèges d'accès SQL s'il en existe.

• Sixièmement, lisez les parties du code d'application qui utilisent la base de données. C'est là que certaines règles métier et règles d'intégrité des données supplémentaires sont appliquées.

mise à jour: Je viens de lire un article intéressant " 9 choses à faire lorsque vous héritez d'une base de données " avec une bonne liste de contrôle.

Sommaire:

1. Sauvegardes
2. Recherche (les étapes de documentation du schéma que je mentionne ci-dessus)
3. Parlez aux anciens développeurs
4. Une base de données de bogues
5. Contrôle du code source
6. Parlez aux utilisateurs et / ou aux propriétaires d'entreprise
7. Établissez la crédibilité auprès des utilisateurs en corrigeant certaines choses ou en apportant des améliorations
8. Créer un environnement de développement
9. Déposer des objets obsolètes

Ce n'est pas toujours possible, mais une chose qui a fonctionné pour moi dans certaines situations est de remplacer certaines tables par des vues. Vous pouvez ensuite ranger les tables en dessous et, dans certains cas, éventuellement éliminer les vues. Comme je l'ai dit, ne fonctionne que dans certains cas.

Le dictionnaire de données est votre ami. Essayez également de procéder à la rétro-ingénierie de la base de données avec l'outil de rétro-ingénierie sur Visio et de créer votre propre ensemble de diagrammes. Parce que l'ingénierie inverse est interactive - vous créez les diagrammes - c'est beaucoup plus engageant que de lire un dictionnaire de données. L'activité du processus est son avantage et je trouve cela très relaxant de le faire.

La plupart du travail que je fais est dans l'entreposage de données, où fouiller les schémas de base de données du système source est quelque chose d'une activité principale. J'ai fait ce genre de choses à plusieurs reprises et je trouve que cela fonctionne très bien.

Visio pro n'est pas si cher et le moteur de modélisation Visio vous permet de partager un modèle entre plusieurs diagrammes. En prime, vous pouvez ajouter des clés étrangères manquantes dans les diagrammes et vous obtenez un ensemble utile de documentation pour le système à la fin.

En plus des idées de Bill Karwin, je suggère de parler aux utilisateurs - occasionnellement, les utilisateurs savent un peu à quoi sert leur base de données, surtout s'ils en font des rapports.

J'en ai un très moche pour le logiciel d'un fournisseur, à part faire des suggestions, je ne peux pas faire grand-chose pour le changer. J'essaie toujours de faire changer les choses, mais comme c'est hors de mon contrôle, je suis coincé avec la camelote.

L'une des choses que j'ai rapidement commencé à utiliser, car la base de données n'a absolument aucune relation, est une requête de nom générale pour le schéma:

--Find Column named like 'blah' in a specific table
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V') AND O.Name like '%TableName%'
ORDER by O.Name

ou

--Find all Columns in DB with name like 'blah'    
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V')
ORDER by O.Name

Étant donné que certaines tables ont trop de colonnes mal nommées et beaucoup trop de colonnes à parcourir pour trouver ce que je pourrais utiliser pour former des relations entre les tables.

Je sais que cela n'aide pas beaucoup dans la partie de la refonte de la question, mais c'est très utile pour comprendre et déchiffrer le mauvais schéma.

SchemaCrawler est mon outil de découverte de base de données qui possède quelques fonctionnalités qui facilitent l'exploration d'une base de données laide. SchemaCrawler possède une fonctionnalité de type "grep", qui vous permet de rechercher des tables et des colonnes à l'aide d'expressions régulières. Par exemple, vous pouvez rechercher des tables et des colonnes avec "COMPTE" dans leur nom, et elles seraient probablement liées d'une manière ou d'une autre.

SchemaCrawler déduit également des relations de clés étrangères, même en l'absence de clés étrangères. Pour ce faire, il trouve des «associations faibles» à l'aide de conventions de dénomination communes, telles que les tableaux sont des noms sont généralement pluriels, mais les noms de colonnes ne le sont pas, et les noms de colonnes peuvent avoir un préfixe _ID. Vous pouvez trouver des tableaux associés à l'aide de ces relations inférées.

Cela dépend de sa laideur, du contrôle que vous avez sur la conception et de ce qui interagit avec elle. J'ai dû interagir avec un certain nombre de bases de données laides au fil des ans dans mon emploi actuel, et voici comment je les ai traitées:

Données sur les employés

Il y a la base de données qui contient les données des employés. C'est une base de données de fournisseurs, donc je n'ai aucun contrôle dessus. (Un?) Heureusement, je n'y ai pas accès directement. Je reçois un vidage DTS tous les matins.

Le mieux que j'ai pu gérer est d'écrire un script qui nettoie les entrées du vidage du matin (oui, ce choix de mots était intentionnel) et le migre dans un format plus utile, et travaille à partir des données nettoyées.

Même si je pouvais le changer, je ne le ferais probablement pas - uniquement parce qu'il existe un grand nombre d'autres programmes qui dépendent de sa configuration telle qu'elle est, et je ne peux pas forcer un changement en eux.

Données de formation en ligne

C'était un gâchis de ma propre conception. Je l'ai construit tout juste sorti de l'université sans mentor pour m'aider ... Depuis, je le répare un peu à la fois. Puisque je contrôle le seul programme qui accède aux données, comme je mets à niveau des parties du site, je "mets à niveau" la configuration de la base de données. J'écrirai un script de transformation et le testerai vigoureusement sur une copie afin que je puisse m'assurer que toutes les modifications qui doivent être apportées soient effectuées.

Ça a été un long processus, mais ça avance bien.

Données de formation en classe

Mon projet pilote a été d'intégrer des données de 3 bases de données différentes, toutes conçues légèrement différemment par mon prédécesseur ... qui était une infirmière enseignante qui a suivi un ou deux cours de programmation.

Cela a été un autre processus lent. Depuis que j'ai un contrôle total sur les programmes qui accèdent aux données, je les modifie petit à petit comme les données de formation en ligne.

Rétrospectivement, cela aurait été un candidat idéal pour commencer propre ... la vue arrière est toujours de 20/20.

À la fin...

Je ne sais pas à quel point cela a été utile, et je peux en dire plus (jusqu'à un certain point, yada yada juridique d'entreprise et tout). La réponse finale est "Ça dépend".

Donc, après avoir lu toutes vos réponses, je vous donne les miennes:

Je cherche d'abord la "table principale", puis, avec un stylo et du papier, je commence à mapper les relations avec d'autres tables, après cela, s'il y a du code d'application à regarder, je commence à faire des croquis bruts sur le flux des données.

Après avoir obtenu une belle image sur le fonctionnement de la base de données, je commence juste à vérifier les endroits où changer les choses. C'est ça.

Je ne sais pas pourquoi mais je préfère le papier à tout logiciel de modélisation de base de données.

En raison de son utilisation par une application externe, vous ne pouvez pas modifier "l'interface" de la base de données. Je ne sais pas quel type de base de données vous utilisez (oracle, mysql, mssql), mais je vois cela comme l'une des façons:

• construction d'une interface de base de données en utilisant des types d'objets comme vue et procédures stockées.
• refactoring pas à pas (normalisation, changement de nom de champ ...)
• changer la demande du client (si nécessaire)

Les vues, les procédures stockées masquent les modifications (modifications) des bases de données internes.

En plus de découvrir la structure de la base de données, j'ai constaté qu'il est également important de regarder la qualité des données . Une fois que vous avez compris la signification de chaque colonne, vous pouvez rechercher les endroits où il y a beaucoup de valeurs manquantes. Au fur et à mesure que vous vous familiarisez avec les données, vous pouvez également examiner où il existe des incohérences entre les valeurs des différentes colonnes.

Cela dépend de la façon dont vous devez interagir. Pour les scénarios d'utilisation où le traitement par lots est acceptable, j'ai souvent trouvé qu'il était plus rentable (en termes de temps de développement et donc de coût pour le client) de regrouper les données dans une structure plus conviviale et de travailler contre cela.

Si vous pouvez segmenter le problème en problèmes que vous pouvez envelopper votre cerveau, vous pouvez les attaquer un à la fois. Parfois, le simple fait de savoir qu'il y a une table qui n'est pas toute enculée peut vous donner une tête de pont pour travailler. De cette façon, vous étendez votre "espace propre" pour englober plus de la base de données en morceaux.

Si vous avez Visio (qui fait partie de Microsoft Office), vous pouvez essayer la fonction de rétro-ingénierie . Ce n'est pas joli, mais cela vous donnera au moins un début (à une fraction du coût des "vrais" outils comme Rational Rose).

Schema Spy est un très bel outil pour générer un ERD.

Bill a donné une excellente réponse. J'ajouterais que je me connecterais à l'interface utilisateur en tant qu'utilisateur de test et essayer de comprendre exactement ce que les utilisateurs font avec les données. Cela vous aidera à comprendre pourquoi derrière certains des proc ou de la conception stockés. Comprendre ce que les données signifient et sont utilisées est essentiel pour comprendre une base de données.

Si la base de données concerne une fonction commerciale ou un sujet que vous ne connaissez généralement pas (par exemple, elle fait de la planification de vol et que vous n'avez auparavant travaillé que sur des applications financières), demandez aux utilisateurs du matériel de lecture sur le sujet ou allez à la bibliothèque. vous-même ou recherchez sur Internet le sujet. Demandez aux utilisateurs s'il existe des problèmes juridiques ou réglementaires dont vous devez être conscient. Encore une fois, certains de ces antécédents peuvent expliquer ce qui semble être des choix de conception étranges.

S'il s'agit d'une base de données de fournisseurs (et j'en ai vu de très mauvaises), tout ce que vous pouvez faire est de vous en plaindre auprès du vendeur.

Pour les applications qui sont construites en interne, il suffit généralement de quelques informations aux développeurs et vous pouvez commencer à modifier le schéma afin d'améliorer les performances. Cela prend du temps et c'est généralement un processus lent.

D'après mon expérience, la création d'une nouvelle base de données n'est pas vraiment une option, car le déplacement de centaines de Go ou de To de données n'est pas tout à fait possible.

Le laisser seul n'est généralement pas une option. Au fur et à mesure que la quantité de données dans la base de données augmente, les performances vont de pire en pire (accordées au moment où je vois les problèmes, elles sont généralement sacrément mauvaises). Finalement, les utilisateurs ne pourront pas utiliser l'application car les performances sont si mauvaises.

Ah ... la base de données laide, plus l'entreprise est grande, plus nous trouverons de bases de données héritées.

• Optimisation des performances Les utilisateurs ne se plaignent pas de ces bases de données tant qu'ils n'ont pas détecté de problèmes de performances. Ainsi, dans notre organisation, nous identifions les requêtes individuelles et les peaufinons en tant que correctif.
• Limiter les données maintenant, nous savons où se trouvent les ordures puantes, alors essayez d'éviter le flux de données à travers de telles bases de données. Créez des bases de données intermédiaires et redirigez vos données vers ces tables pour commencer et utiliser les anciennes comme vidages de données.
• Évitez la thésaurisation des données Archivez / tronquez les anciennes données qui ne sont plus nécessaires. Il devrait y avoir une équipe qui décide combien de temps les données sont nécessaires dans une base de données. Après cela, vous pouvez le déplacer vers des fichiers plats ou même vers des lecteurs de bande.
• Éliminez-le une fois que vous pouvez réaliser la redirection et la troncature des données. Convaincre les autres équipes de commencer à utiliser la nouvelle base de données.

Cela ne fonctionne pas toujours, mais si nous ne faisons pas d'efforts, cela ne fera qu'empirer. J'essaie de repenser les bases de données avec les applications, cela pourrait ajouter plus de travail pour moi avec la migration des données, mais les performances sont un tour de magie que je retire toujours de mon chapeau.

Bonne chance avec ta vilaine petite amie;)

Voyez si l'option d'une session de transfert de connaissances est à votre disposition, et si oui, profitez-en pleinement.

De plus, de nombreux SGBD sont livrés avec des outils qui vous permettent de dessiner / imprimer le schéma de la base de données avec des informations utiles (par exemple, des clés étrangères).

De plus, (volé à NXC), vous pouvez effectuer une rétro-ingénierie de la base de données via des outils comme Visio.

J'aime lancer un profileur de requêtes et regarder ce qui se passe sur un système de production. Me donne une idée des tables qui sont «chaudes» et du type de requêtes qu'il y a contre elles.

Placez une copie de sauvegarde sur un serveur sandbox, puis commencez à écrire et à exécuter des requêtes de test. Je trouve toujours un système complexe plus facile à comprendre si je peux mettre la main dessus et ne pas m'inquiéter de le casser.

De plus, j'aime que The Daily WTF soit ouvert dans une fenêtre de navigateur. Prendre en charge la conception de quelqu'un d'autre implique généralement beaucoup de moments "Je ne peux pas croire qu'ils ont fait {WTF}", et il est utile d'avoir un endroit où aller où les gens comprennent votre douleur.