¿Cómo sumergirse en una base de datos fea?

Estoy seguro de que muchos de ustedes están / estaban tratando con una base de datos fea. Ya sabes, esa base de datos que no está normalizada en absoluto, esa base de datos donde tienes que hacer una gran y dolorosa consulta para obtener los datos más triviales, esa base de datos que está en producción y no puedes cambiar un poco ... ya sabes , "ese".

Mi pregunta es, ¿cómo lo manejas?

• ¿Intentas hacer una nueva base de datos?
• ¿Te rindes y lo dejas solo?
• ¿Qué consejo puedes dar?

• Lo primero que hago es crear un Diagrama de entidad-relación (ERD). A veces, simplemente puede describir los metadatos con herramientas de línea de comandos, pero para ahorrar tiempo hay algunas herramientas que pueden generar un diagrama automáticamente.

• En segundo lugar, examine cada tabla y columna para asegurarse de que entiendo el significado de lo que almacena.

• Tercero, examine cada relación y asegúrese de entender cómo se relacionan las tablas entre sí.

• Cuarto, lea cualquier vista o disparador para comprender la aplicación de integridad de datos personalizada o las operaciones en cascada.

• Quinto, lea los procedimientos almacenados. Lea también los privilegios de acceso SQL si los hay.

• Sexto, lea partes del código de la aplicación que usan la base de datos. Ahí es donde se aplican algunas reglas comerciales adicionales y reglas de integridad de datos.

actualización: acabo de leer un interesante artículo " 9 cosas que hacer cuando se hereda una base de datos " con una buena lista de verificación.

Resumen:

1. Copias de seguridad
2. Investigación (los pasos de documentación del esquema que menciono anteriormente)
3. Habla con los antiguos desarrolladores
4. Una base de datos de errores
5. Control de código fuente
6. Hable con los usuarios y / o dueños de negocios.
7. Establezca credibilidad con los usuarios arreglando algunas cosas o haciendo algunas mejoras
8. Crear un entorno de desarrollo.
9. Suelta objetos obsoletos

Esto no siempre es posible, pero una cosa que me ha funcionado en ciertas situaciones es reemplazar algunas de las tablas con vistas. A continuación, puede ordenar las tablas debajo y, en algunos casos, eliminar las vistas. Como dije, solo funciona en algunos casos.

El diccionario de datos es tu amigo. Además, pruebe la ingeniería inversa de la base de datos con la herramienta de ingeniería inversa en Visio y cree su propio conjunto de diagramas. Debido a que la ingeniería inversa es interactiva, usted construye los diagramas, es mucho más interesante que leer a través de un diccionario de datos. La actividad del proceso es su ventaja y me resulta bastante relajante hacerlo.

La mayor parte del trabajo que hago es en el almacenamiento de datos, donde hurgar en los esquemas de la base de datos del sistema fuente es una actividad central. He hecho este tipo de cosas en varias ocasiones y creo que funciona muy bien.

Visio pro no es tan costoso y el motor de modelado de Visio le permite compartir un modelo entre múltiples diagramas. Como beneficio adicional, puede agregar claves foráneas faltantes en los diagramas y obtener un conjunto útil de documentación para el sistema al final.

Además de las ideas de Bill Karwin, sugiero hablar con los usuarios; ocasionalmente, los usuarios saben bastante sobre para qué se utiliza su base de datos, especialmente si hacen algún informe al respecto.

Trato con uno muy feo para el software de un proveedor, que aparte de hacer sugerencias, no puedo hacer mucho para cambiarlo. Siempre estoy presionando para que las cosas cambien, pero como está fuera de mi control, estoy atrapado en la basura.

Una de las cosas que comencé a usar rápidamente, ya que la base de datos no tiene absolutamente ninguna relación, es una consulta de nombre general para el esquema:

--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

o

--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

Dado que algunas de las tablas tienen demasiadas columnas mal nombradas, y demasiadas columnas para buscar y encontrar lo que podría usar para formar relaciones entre la tabla.

Sé que esto no ayuda mucho en la parte de rediseño de la pregunta, pero es muy útil para comprender y descifrar el mal esquema.

SchemaCrawler es mi herramienta de descubrimiento de bases de datos que tiene un par de características que facilitan la exploración de una base de datos fea. SchemaCrawler tiene una funcionalidad similar a "grep", que le permite buscar tablas y columnas usando expresiones regulares. Por ejemplo, podría buscar tablas y columnas con "CUENTA" como parte de su nombre, y probablemente estarían relacionadas de alguna manera.

SchemaCrawler también infiere relaciones de clave externa, incluso cuando no hay claves externas. Lo hace mediante la búsqueda de "asociaciones débiles" utilizando convenciones de nomenclatura comunes, como que las tablas son nombres que generalmente son plurales, pero los nombres de columna no lo son y los nombres de columna pueden tener un prefijo _ID. Puede encontrar tablas relacionadas utilizando estas relaciones inferidas.

Depende de lo feo que sea y de cuánto control tengas sobre el diseño y qué interactúa con él. He tenido que interactuar con varias bases de datos feas a lo largo de los años en mi trabajo actual, y así es como las he tratado:

Datos del empleado

Existe la base de datos que contiene los datos de los empleados. Es una base de datos de proveedores, por lo que no tengo control sobre ella. (¿Un?) Afortunadamente, no tengo acceso directo a él. Tengo un vertedero de DTS todas las mañanas.

Lo mejor que he podido administrar es escribir un script que elimine la entrada del volcado de la mañana (sí, esa elección de palabras fue intencional) y migrarla a un formato más útil, y trabajar desde los datos depurados.

Incluso si pudiera cambiarlo, probablemente no lo haría, solo porque hay una gran cantidad de otros programas que dependen de que se configure de la manera en que está, y no puedo forzar un cambio en ellos.

Datos de entrenamiento en línea

Este fue un desastre de mi propio diseño. Lo construí recién salido de la universidad sin un mentor que me ayudara ... Desde entonces lo he estado arreglando poco a poco. Como controlo el único programa que accede a los datos, a medida que actualizo partes del sitio, "actualizaré" la configuración de la base de datos. Escribiré un script de transformación y lo probaré vigorosamente en una copia para asegurarme de que se realicen todos los cambios que deben realizarse.

Ha sido un proceso largo, pero va muy bien.

Datos de entrenamiento en el aula

Mi proyecto piloto ha estado integrando datos de 3 bases de datos diferentes, todas diseñadas de manera ligeramente diferente por mi predecesor ... que era una enfermera educadora que tomó una o dos clases de programación.

Ese ha sido otro proceso lento. Como tengo control total sobre los programas que acceden a los datos, los he ido modificando poco a poco como los datos de capacitación en línea.

En retrospectiva, este habría sido un candidato ideal para comenzar de cero ... la vista trasera siempre es 20/20.

En el final...

No sé cuán útil ha sido esto, y puedo elaborar más (hasta cierto punto, yada yada legal de la compañía y todo). La respuesta final es "depende".

Entonces, después de leer todas tus respuestas, te doy las mías:

Primero busco la "Tabla maestra", luego, con lápiz y papel, comienzo a mapear las relaciones con otras tablas, después de eso, si hay algún código de aplicación para mirar, empiezo a hacer algunos bocetos en bruto sobre cómo fluyen los datos.

Después de obtener una buena imagen de cómo funciona la base de datos, empiezo a buscar lugares donde cambiar las cosas. Eso es.

No sé por qué, pero prefiero el papel sobre cualquier software de modelado de bases de datos.

Debido a que lo usa una aplicación externa, no puede cambiar la "interfaz" de la base de datos. No sé qué tipo de base de datos está utilizando (oracle, mysql, mssql), pero veo esto como una de las formas:

• crear una interfaz de base de datos utilizando tipos de objetos como procedimientos de vista y almacenados.
• refactorización paso a paso (normalización, cambio de nombre de campo ...)
• cambiar la aplicación del cliente (si es necesario)

Las vistas, los procedimientos almacenados ocultarán las modificaciones (cambios) de las bases de datos internas.

Además de descubrir la estructura de la base de datos, descubrí que también es importante observar la calidad de los datos . Una vez que comprenda el significado de cada columna, puede buscar cualquier lugar donde falten muchos valores. A medida que se familiarice con los datos, también puede examinar dónde hay inconsistencias entre los valores en diferentes columnas.

Depende de cómo tengas que interactuar. Para escenarios de uso donde el procesamiento por lotes es aceptable, a menudo he encontrado que es más rentable (en términos de tiempo de desarrollo y, por lo tanto, costo para el cliente) agrupar los datos en una estructura más amigable y trabajar en contra de eso.

Si puede segmentar el problema en problemas en los que pueda envolver su cerebro, puede atacarlos uno a la vez. A veces, el solo hecho de saber que hay una mesa en la que no todo está lleno puede darle una cabeza de playa para trabajar. De esta manera, extiende su "punto limpio" para abarcar más de la base de datos en fragmentos.

Si tiene Visio (parte de Microsoft Office) puede probar la función de ingeniería inversa . No es bonito, pero al menos te dará un comienzo (a una fracción del costo de herramientas "reales" como Rational Rose).

Schema Spy es una herramienta realmente buena para generar un ERD.

Bill dio una excelente respuesta. Agregaría que iniciaría sesión en la interfaz de usuario como usuario de prueba y trataría de comprender exactamente qué hacen los usuarios con los datos. Le ayudará a comprender el por qué detrás de algunos de los procesos o diseños almacenados. Comprender lo que significan y para qué se utilizan los datos es fundamental para comprender una base de datos.

Si la base de datos se encuentra en una función comercial o materia con la que en general no está familiarizado (digamos que hace la planificación del vuelo y anteriormente solo ha trabajado en aplicaciones financieras), solicite a los usuarios material de lectura sobre la materia o vaya a la biblioteca usted mismo o busque en Internet sobre el tema. Pregunte a los usuarios si hay problemas legales o reglamentarios que debe conocer. Una vez más, algunos de estos antecedentes del tema pueden explicar lo que parecen ser elecciones de diseño extrañas.

Si se trata de una base de datos de proveedores (y he visto algunas realmente malas), todo lo que puede hacer es quejarse con el proveedor al respecto.

En el caso de las aplicaciones que se crean internamente, por lo general solo requiere algo de educación para los desarrolladores y puede comenzar a cambiar el esquema para que mejore el rendimiento. Lleva tiempo, y generalmente es un proceso lento.

En mi experiencia, construir una nueva base de datos no es realmente una opción, ya que mover cientos de GB o TB de datos no es tan factible.

Dejarlo solo tampoco suele ser una opción. A medida que crece la cantidad de datos en la base de datos, el rendimiento empeorará (otorgado para cuando vea los problemas, generalmente son bastante malos). Finalmente, los usuarios no podrán usar la aplicación porque el rendimiento es muy malo.

Ah ... la base de datos fea, la gran empresa es la base de datos más antigua que encontraremos.

• Afinando el rendimiento, las personas no se quejan de tales bases de datos hasta que encuentran problemas de rendimiento. Entonces, en nuestra organización identificamos consultas individuales y las ajustamos como un parche.
• Limitando los datos ahora sabemos dónde está la basura apestosa, así que trate de evitar el flujo de datos a través de dichas bases de datos. Cree bases de datos provisionales y redirija sus datos a esas tablas para comenzar y use las antiguas como volcados de datos.
• Evitar el acaparamiento de datos Archivar / truncar datos antiguos que ya no son necesarios. Debe haber un equipo que decida cuánto tiempo se requieren los datos en una base de datos. Después de eso, puede moverlo a archivos planos o incluso a unidades de cinta.
• Elimínelo una vez que pueda lograr la redirección y el truncamiento de datos. Convencer a los otros equipos para comenzar a usar la nueva base de datos.

No siempre funciona, pero si no nos esforzamos, empeorará. Intento rediseñar las bases de datos junto con las aplicaciones, podría agregarme más trabajo con la migración de datos, pero el rendimiento es un truco de magia que siempre saco de mi sombrero.

Buena suerte con tu fea amiga;)

Vea si la opción de una sesión de Transferencia de conocimiento está disponible para usted y, de ser así, aproveche al máximo.

Además, muchos DBMS incluyen herramientas que le permiten dibujar / imprimir el esquema de la base de datos con información útil (es decir, claves externas).

Además, (robado de NXC) puede realizar ingeniería inversa de la base de datos a través de herramientas como Visio.

Me gusta activar un generador de perfiles de consulta y ver lo que sucede en un sistema de producción. Me da una idea de qué tablas son "populares" y el tipo de consultas que hay en contra de ellas.

Coloque una copia de seguridad en un servidor de espacio aislado y luego comience a escribir y ejecutar consultas de prueba. Siempre encuentro un sistema complejo más fácil de entender si puedo tenerlo en mis manos y no preocuparme por romperlo.

Además, me gusta tener The Daily WTF abierto en una ventana del navegador. Asumir el diseño de otra persona generalmente implica muchos momentos de "No puedo creer que lo hayan hecho {WTF}", y ayuda tener un lugar donde ir donde la gente entienda su dolor.