Mejores prácticas para rediseñar una base de datos

Conozco algunas de las mejores prácticas generales al diseñar una base de datos para una aplicación, pero ¿qué pasa con el rediseño?

Estoy en un equipo encargado de rediseñar una aplicación comercial interna, aunque a pesar de que yo diga "interno", desafortunadamente estoy lejos de tener contacto con los usuarios reales del sistema.

El programa actual está en Oracle Forms, disperso en un montón de tablas no normalizadas, a veces con múltiples tablas casi duplicadas que contienen ligeras variantes en los datos de los demás. Las restricciones a menudo se presentan en forma de procedimientos almacenados mal aplicados. Incluso los tipos no parecen estar almacenados correctamente. He encontrado todo tipo de datos incorrectos que Oracle parece ignorar pero le dio ajustes (y con razón) al Asistente de importación / exportación de SQL Server. (Por ejemplo, ¡los enteros de dos dígitos no constituyen una fecha y hora completa!)

El programa original probablemente se remonta a veinte años, y todos los desarrolladores originales se han retirado hace tanto tiempo que incluso las personas mayores aquí no tienen idea de quiénes eran. Como resultado, tampoco hay requisitos limpios para cumplir: solo se supone que debemos duplicar la funcionalidad de la aplicación existente y mantener sus datos existentes.

El resultado final de la reescritura será una versión basada en web que se ejecute en ASP.NET con MS SQL Server para el back-end.

Mis otros dos compañeros de equipo de desarrolladores son mucho, mucho mayores que yo, ambos con experiencia en negocios / MIS, mientras que el mío es CS. La experiencia del miembro senior ha sido casi exclusivamente formularios de Oracle y el otro miembro ha trabajado principalmente en aplicaciones comerciales en Visual Basic. Aunque mi experiencia en bases de datos se ha limitado a diseñar nuevas bases de datos para proyectos en MySQL o SQLite, principalmente para mis clases de pregrado, parece que soy el único con experiencia en el diseño de bases de datos.

Ya he escrito un pequeño programa en C # que lee todos los datos existentes en un formato neutral, listo para ser relanzado y colocado en una nueva base de datos. Planeo escribir el código de carga después de que se diseñe la base de datos de destino, de modo que los datos se puedan dividir adecuadamente en las nuevas tablas normalizadas, agregadas en el orden correcto para seguir las nuevas restricciones, etc. El mismo programa podría ejecutarse nuevamente más tarde para copiar los datos de producción al rediseño terminado real recién desplegado. Esto deja el rediseño real de la base de datos como lo más importante para descubrir.

Entonces, el corazón de mi pregunta: ¿cuáles son algunas de las mejores prácticas para hacer un rediseño desde el nivel de base de datos de una aplicación existente?

Creo que ya sabes cómo normalizar una base de datos.

Lo que necesita son estrategias para minimizar el riesgo al mover todo el software a la nueva base de datos.

Lo que sugiero es más trabajo como compensación por menos riesgo.

Normalice la base de datos y cree un proceso para llenar la base de datos normalizada con datos de la base de datos original. La base de datos original será la base de datos para inserciones, actualizaciones y eliminaciones. La base de datos normalizada será la base de datos de consultas solo durante la conversión.

Su proceso de rellenado tendrá que ejecutarse con la frecuencia necesaria para la consulta de datos. Si los datos de un día son aceptables, puede ejecutar un proceso de llenado nocturno. Si necesita más datos actuales, debe ejecutar un proceso de llenado continuo.

Cree la parte de consulta de su nuevo sistema ASP.NET, apuntando a la nueva base de datos normalizada.

Los resultados de la consulta de su nuevo sistema deben compararse con los resultados de la consulta del sistema original.

Podrías parar en este punto. Esa es una decisión comercial, no una decisión técnica.

En su tiempo libre, puede crear nuevas funciones de inserción / actualización / eliminación en su nuevo sistema ASP.NET. A medida que crea la nueva funcionalidad, apaga las partes del sistema original que corresponden. En algún momento, no queda nada del sistema original.

Las ventajas de convertir de esta manera son la reducción del riesgo al construir primero la parte de la consulta. En general, las funciones de consulta son simples en comparación con la lógica empresarial integrada en la funcionalidad de inserción / actualización / eliminación.

Convierte la funcionalidad de inserción / actualización / eliminación un proceso a la vez. Si hay un problema con la incomprensión de la lógica empresarial, se puede solucionar mientras los usuarios usan el sistema original.

No hay que decir que es mejor que su proceso de población sea absolutamente coherente.

Trate de convencerlos de contratar el desarrollo del nuevo sistema a una compañía externa, hay muchas buenas compañías de desarrollo que tienen los recursos para desarrollar adecuadamente las aplicaciones más rápido y mejor que su equipo limitado. Una buena compañía de desarrollo también podrá obligar a sus superiores a hacer cosas que quizás no hagan si usted lo solicitó, el primer ministro de la compañía, al que se le paga mucho dinero para desarrollar una aplicación, tiene mucha más atracción para involucrar a los usuarios que el chico de TI muchos niveles por debajo de la autoridad administrativa para organizar tales cosas.

Cuesta mucho dinero por adelantado, pero valdrá la pena tener los recursos adecuados para el desarrollo y la implementación. Si logra obtener una RFP, apostaría a que las ofertas que reciba indiquen que lo que está tratando de hacer es mucho más complicado de lo que piensan sus gerentes.

Diseñe la base de datos normalizada que necesita con los tipos de datos que necesita. Entonces la parte más difícil es migrar los datos. Primero debe tener un plan de cómo va a mapear de lo antiguo a lo nuevo y qué hará con los datos que no cumplan con la nueva estructura. Por ejemplo, es posible que tenga datos que ahora no se pueden identificar si no tenía las restricciones de integridad adecuadas. Es posible que simplemente no quiera mover esos datos o que necesite moverlos, pero adjuntarlos a un nuevo registro primario llamado "Desconocido". Si una fecha no es realmente una fecha real, ¿puede poner un valor nulo en el campo al migrar? Necesitará respuestas a ese tipo de preguntas. Le sugiero que haga que algunos de los desarrolladores trabajen en cambiar la interfaz gráfica de usuario para usar la nueva estructura de la base de datos y otros para que trabajen estrictamente en la migración. La migración es una tarea enorme, requerirá mucha habilidad y mucho tiempo. No lo dejes como una idea de último momento.

Como está utilizando SQL Server, puede realizar la migración real a través de SSIS.

Cree un buen conjunto sólido de casos de prueba para que pueda comparar que los resultados con el sistema anterior son los mismos con el nuevo sistema.

Debido a que tiene tantos años de datos, es posible que desee migrar en dos partes. Primero migre la mayoría de los datos y luego, cuando sea el momento de ponerlo en funcionamiento, solo migre los datos modificados. Por supuesto, necesitaría establecer controles en la base de datos para poder encontrar datos modificados que aún no tiene. También puede considerarlo en este momento si desea archivar algunos datos.

Me enfrento al rediseño del esquema de la base de datos casi a diario debido al soporte y al desarrollo adicional de varias aplicaciones heredadas que nacieron como archivos de MS Access (.mdb) y luego crecieron en grandes bases de datos con varios cientos de tablas ahora ubicadas en MS SQL Servidor pero sigue teniendo los "fallecimientos infantiles" del diseño original. Aquí hay algunas prácticas que me resultaron útiles:

Intente minimizar la superficie disponible públicamente de su esquema de base de datos.

Esto significa que debe intentar diseñar alguna API pública que ponga a disposición de aplicaciones externas. Normalmente trato de implementar los datos estáticos como vistas (incluso si solo se basan en una sola tabla) y los datos dinámicos como vistas parametrizadas o como procedimientos almacenados. Para consultas de datos donde solo un valor es suficiente, también se pueden usar funciones escalares.

Solo estos (vistas, procedimientos almacenados y funciones escalares) son visibles para aplicaciones externas (a través de ORM o directamente) y se utilizan para todas las operaciones CRUD. Este esquema se congela por completo, mientras que internamente puede cambiar las tablas subyacentes, mejorar sus procedimientos, etc., esto no romperá la compatibilidad con su aplicación.

Intente optimizar para criterios del mundo real, no para aquellos de libros.

La normalización es un gran tema en cada libro sobre diseño de bases de datos. Pero en la vida real hay casos en que la normalización no le traerá mucho o incluso ralentizará su base de datos, por ejemplo, si tiene algunos datos que se repiten, pero el porcentaje de repeticiones es muy bajo, etc. No estoy en contra de la normalización, Lo que intento decir aquí es que hay que abordarlo con cierto escepticismo y prudencia.

Grabe la sesión de perfil y analícelos.

El rediseño de la base de datos basado únicamente en el esquema de la base de datos no está completo. Mire su base de datos en su dinámica, intente encontrar los cuellos de botella durante las pruebas de carga y aborde esos. En el caso de MS SQL Server, hay un Asesor de ajuste especial que puede generar algunas recomendaciones sobre el seguimiento de la actividad registrada.

Aquí está mi respuesta:

1. Primero, comprenda el sistema de base de datos actual tanto como pueda. Necesita conocer todos los usos de estos sistemas, así como los usuarios. Debe conocer todas las fuentes del sistema, así como los sistemas que podría estar sirviendo como su sistema fuente.

2. Debe identificar todos los diferentes usos del sistema, ya sea para operaciones, informes o ambos. Identifique las aplicaciones y el sistema ascendente que podrían estar utilizando la base de datos. Al hacerlo, conocerá los elementos de la base de datos actual que están obsoletos y ya no son necesarios.

3. También analice y comprenda el proceso ETL actual que carga datos en la base de datos y extrae datos de la base de datos.

4. Comprenda todos los elementos de datos de la base de datos y si puede construir una matriz de caja que pueda ayudarlo a identificar elementos duplicados.

5. Una vez obtenida toda la información, puede abordar el rediseño como si estuviera diseñando la base de datos por primera vez con la información que ha reunido como parte de su recopilación de requisitos.

6. ¡Buena suerte!