Revista NTEK

La mayor parte de los lectores han vivido probablemente esté cliché en muchas ocasiones, incluso, realmente quieren hacer todo lo necesario para evitar el repetir el trabajo. Obviamente repetir el trabajo involucra pérdida de productividad y la necesidad de re trabajar, implica que los resultados iníciales fallaron gracias a la falta de conocimiento de las necesidades de los negocios o de los usuarios.

Este artículo describe los errores que los equipos de desarrolladores pueden cometer en los proyectos de desarrollo de aplicaciones y la implementación de modelos de datos lógicos y físicos. He encontrado muchas veces estas situaciones a lo largo de los más de 15 años. El objetivo del artículo es tratar de enseñarles de las experiencias de otras personas para incrementar las oportunidades de éxito desde el primer intento. Mi experiencia se ha concentrado en bases de datos de Oracle, así que la mayor parte de las recomendaciones técnicas son en Oracle.

Aunque pareciera obvio que varias de las recomendaciones parecerán evidentes, podrás reconocer en tus proyectos algunos de estos errores. Aunque sería reconfortante saber que estás en buena compañía, como estos errores son más que comunes, aun sean Oracle o cualquier otro sistema de base de datos relacional han estado disponibles desde hace años.

Oracle es un sofisticado sistema de administración relacional de base de datos, mientras exista una gran flexibilidad en el modelo de construcción de los datos, muchas de las opciones del lenguaje de de definición de datos Data Definition Language (DDL) tienen selecciones por default, que provoca la tentación de solamente construirla y listo, concentrémonos exclusivamente en la funcionalidad lógica de la aplicación sin la planeación de la de la operación física de la base de datos, sin embargo la complejidad también requiere de algún avance de planeación, permitir el adecuado desempeño de la aplicación en una escalabilidad de miles o millones de registros de usuarios, o cientos de gigabytes de almacenamiento. La siguiente tabla resume los errores más comunes y los problemas que puede provocar.

Fallas para direccionar el crecimiento a largo plazo

Lógicamente, todo lo que es necesario para construir un modelado de datos es CREAR TABLAS, CREAR ESTRUCTURA y otros comandos relacionados. Usando estos comandos, tus entidades lógicas llegan a ser tablas físicas, lo has hecho con modelos de datos ¿Es correcto? Sin embargo las operaciones que trabajan bien con pequeñas tablas pueden desempeñarse inadecuadamente cuando el tamaño de la producción de una tabla crece. He visto varias bases de datos de las cuales, alguien ha creado espacios de tablas con unos cuantos gigabytes y entonces estos creadores tienen que lidiar con crisis eternas de espacios de las tablas que nos son lo suficientemente grandes. Tales crisis son cada vez más agudas, cuando se soluciona ese espacio involucra forzosamente la adquisición de más discos, desde el procedimiento, hasta la instalación del disco y raramente es lo suficientemente rápido para resolver la crisis.

Para evitar esto se debe concentrar en el almacenamiento físico de las grandes tablas durante el diseño del modelado de datos.

Estimar tanto el tamaño de la tabla, como el patrón de crecimiento a largo plazo. No es necesaria una precisión extrema, pero la estimación se debería basar a las actuales necesidades de toda la tabla. Una tabla existe para almacenar información del mundo real, así que subraya las necesidades de negocio de la tabla para producir un modelo simple (probablemente en una hoja ampliada) estimando un número de filas. El dominio de los expertos de negocios deben proveer la entrada de estos procesos. ¿Cuántos usuarios, clientes, o pacientes residirán ahí? ¿Cómo será el crecimiento de la población conforme pase el tiempo? ¿Cuántas cuentas, órdenes, recibos, pagos, y demás formatos tendrá el cliente con el paso del tiempo? ¿Cuántos registros detallados promedio están en una clave parental dada? ¿Cuánto tiempo deberá ser retenida la información? Contestar estás preguntas, podría ser difícil en el caso de nuevos negocios o aplicaciones, pero frecuentemente hay suficiente experiencia en el negocio para proveer por lo menos un estimado (por supuesto es mejor equivocarse de más que de menos).

Estimado de las tablas de tamaño físico. Nuevamente la precisión extrema no es requerida pero el resultado debe estar alineado con la realidad, algo tan sencillo como una suma o un promedio de ancho de columnas en número de veces de una fila, adicional a una PCTFREE, cederá por lo menos un orden de razonable magnitud. Obviamente, si ya existe la base de datos, entonces las tablas actuales puede ser utilizada como un preciso gauge de las necesidades de almacenamiento, pensado para extrapolar crecimientos futuros.

Recordemos estimar el tamaño físico de la estructura. Es más complicado que las estimaciones del tamaño de las tablas debido a que el tamaño actual depende de que tan compactan sean las claves de almacenamiento no bloqueado. No obstante un estimado burdo es mejor que nada, un buen comienzo sería la estructura promedio de longitud de columnas de acuerdo con el número de filas, más el sobrestimado de PCTFREE. Para estructurar el mapa de bits, una estimación adecuada sería conocer el número de veces en las filas divididas por los bits por bloque de valores únicos de las columnas estructuradas. Aquí me permito dar un tip, en mi experiencia las estructuras pueden consumir el doble de espacio que los modelos simples que se describirían, puedes probar en tu base de datos para estar seguro.

Utiliza la información para estimar la necesidad de espacio de disco tanto en ese momento como después de varios años. Realmente no ayuda en mucho conocer el tamaño actual de la base si se triplicaría en los próximos 3 años. Modelar el crecimiento permitirá a los constructores de DBA construir espacios de tablas para adecuar el tamaño sin necesidad de reaccionar ante cualquier reducción de espacio, lo que es más, te permite localizar de forma adecuada el tiempo de las actividades de mantenimiento,  tales como respaldos o actualizaciones, desde el tiempo requerido para estás actividades que es proporcional al tamaño de la base de datos. Podría revelar que las necesidades de la base regular para archivar o limpiar las tablas.

Durante el desarrollo, validar las predicciones comparando los bits predichos por fila, contra el tamaño actual de la fila, de las tablas y e índices en el desarrollo de las pruebas de ambientes y ajustar de acuerdo a la predicción del modelo. Aquí es especialmente importante para los índices, para los cuales se utiliza el espacio actual el cual puede diferir desde las predicciones tanto como al doble.

No existe rutina para limpiar los datos viejos

Algunas partes de nuestros datos pueden estar citados y tendrán un ciclo limitado de vida dependiendo las necesidades del negocio, es probable que las necesidades del negocio para mantener las órdenes o pagos en línea durante 3 años, y los logs de los usuarios, los últimos 3 meses. Constantemente los programadores se concentrarán en la rutina de la operación de una aplicación y pondrán mucha atención los módulos que insertan nuevos registros. Ahora bien la aplicación en sí misma no toma una acción específica de eliminación de datos viejos, así que a nadie le concierne lo que se hace con la eficiencia si es que existe alguna. Naturalmente este crecimiento en una gran tabla, puede generar  un verdadero desastre. Cuando no existe un plan de limpieza de los datos viejos, las operaciones de la base de datos responderán típicamente con acciones de emergencia de espacios así como revolver una gran cantidad de números de las filas o agregando espacios en la base ad hoc, ninguna de estas son soluciones a largo plazo.

En Oracle, las operaciones de DELETE se realizar por medio de transacciones de soporte en línea, es lo más eficiente para un número pequeño de filas, por cada fila borrada tanto los bloques de las tablas las tablas como los estructura  deben ser leídos, grabados en un segmento de rollback, donde el log es modificado, escrito y rehecho y reescribirlo nuevamente en el disco. Que es esencial para salvaguardar la integridad de la bases de datos, sin embargo esto no es eficiente en limpieza a gran escala de una gran tabla, además el monto de rollback y producción de rehacer incrementará el número de logs archivados lo cual incrementará el tiempo requerido para la recuperación del respaldo. La solución de Oracle de este problema es el rango de partición que no es más que una tabla físicamente separada en varias particiones distintas, que automáticamente agregan filas a cada partición en particular con base en el valor de una fila y columna especifica. Cada partición acepta los valores en un rango específico y los rangos de las particiones son consecutivos y no se empalman, son varias las ventajas de particionar grandes tablas:

Todas las filas en un rango dado pueden ser eliminadas con una simple transacción. Todas las filas de un rango dado pueden ser eliminadas con una simple transacción DDL arrojándolas o por una partición truncada

Para las consultas que tienen una partición limitada a la clave del valor de partición, ENTRE el lazo bajo y el más alto, el optimizador de consulta puede saltar varias particiones que no tendrán reducción de fila que hacen match, en su defecto requerirán de un proceso llamado partition pruning (desecho de partición).

El mantenimiento de las operaciones puede proceder de particiones individuales mientras que el resto de la tabla está disponible al soporte de los usuarios. Para conocer todos los beneficios de partición muchas elecciones son una verdadera ventaja:

¿Cuál será la columna clave para usar la partición?

¿Cuáles intervalos se usan para las claves de partición?

¿Cuál partición se hará en la estructura?, y si es así, ¿Cómo hacerlo?

¿Cuándo agregar nuevas particiones y tirar las viejas? Existen una gran cantidad de recursos como consejos en la toma de decisiones, no obstante el punto principal es que tenemos que recordar que, particionar es por mucho, la forma más eficiente de manejar grandes tablas que deben ser limpiadas en una base de datos con regularidad.

Sobreutilización de claves Sintéticas

Cómo tú bien sabes, la clave principal es uno o un conjunto de atributos los cuales en cada fila de la tabla hay un valor único. Cuando esos atributos son cosas que se utilizan de forma rutinaria en los negocias, esos son llamados claves naturales. Por ejemplo podemos incluir los números de seguro, los números de identificación de licencias, identificación del usuario paciente. Ahora bien, ocasionalmente una tabla no tiene claves naturales por que tienen demasiadas columnas. Los diseñadores de bases de datos frecuentemente crean un generador de secuencia, el cual es llamado clave sintética, debido a que sirve a los propósitos de la clave principal pero no tiene significado real para el negocio. Algunos diseñadores de base de datos utilizan el término “surrogate key” en los materiales de referencia.

He visto modelado de datos en los cuales cada tabla en todo el esquema tiene claves sintéticas, existen razones validas para utilizar una clave sintética, he aquí las razones:

Existen tablas por las cuales las claves sintéticas no sirven a ningún propósito. La estructura de la clave primaria es una pérdida de espació y de servidor, que deberá desperdiciar tiempo actualizando la estructura mientras se cierran y se borran. Por ejemplo en una tabla de entradas es probable que no se necesite en lo absoluto una clave. Otro ejemplo es el detallado de una base en una relación maestra detallada, el detalle de los registros están típicamente en el ciclo de la ejecución de la instrucción de la clave maestra, existe un pequeño beneficio en dar los detalles de las filas en su propia clave sintética.

Las transacciones simultáneas que se insertan en la seriación de nuevas filas en un generador de secuencias deben ser serializados de forma tal que cada turno obtenga nuevas claves de valores. Si existen docenas o cientos de transacciones corriendo en paralelo en el sistema OLTP.

Así que ¿Cuándo debes usar una clave sintética? Me he encontrado en situaciones par a las cuales las claves sintéticas son útiles:

Una clave natural es aquella que podría cambiar conforme pase el tiempo por ejemplo el número de licencia, es decir puede permanecer fija aun cuando otros atributos cambien.

Las claves naturales tienen muchas columnas y existen muchos lugares en tu aplicación donde un programa debe llamar a una sola fila por cada valor. Una clave sintética permitiría a la aplicación identificar una fila por un solo valor.

Las claves naturales tienes varias columnas, y la tabla es el objetivo de referencias externas, generalmente no es práctica para repetir todas las columnas naturales clave en las tablas infantiles, como una clave sintética permite la creación de referencias externas con solamente una columna.

Puedes encontrar otras razones para usar claves sintéticas. Pero más allá de la habitual definición de clave sintética para cada tabla, es Buena idea estar seguro que los beneficios de la clave de una columna y sopesar con el costo de la estructura y la consabida generación de secuencia numérica.

Planeación inadecuada de Estructuras

Una de las tareas más retadoras es la creación de un modelo de datos lógico, es decidir cuáles columnas incluir, desafortunadamente no existen criterios mágicos que garanticen cuales estructuras son necesarias y cuáles no, pero existen algunas reglas que pueden servir como puntos de partida. Se requiere de un conocimiento general adecuado de la forma que las tablas serán accesadas por los programas de las aplicaciones, los programas de reportes y si es posible por los análisis ad hoc. Va más allá del panorama de este artículo explorar todas las situaciones por las cuales una estructura es o no una buena idea.

En muchos casos los desarrolladores están tentados a aplicar reglas sencillas a todos los lineamientos a lo largo de todo el modelado de la base de datos sin ningún tipo de consideración ya sea que la estructura resultante sea útil o no.

Claves Externas de Estructuras

Algunas herramientas de modelado de datos tienen opciones para crear estructuras en todas las claves externas, algunos pueden estar tentados a sencillamente encender esa opción, después de todo los lineamientos dicen que estructurar columnas que son utilizadas en uniones ¿De acuerdo? En realidad una clave externa es de utilidad solamente si por lo menos uno de los siguientes aspectos es verdadero:

Cuando un plan de consulta en el comienzo de la aplicación por medio de las filas en una tabla parental, las respuestas de los ciclos de respuesta en el inicio de la tabla de la clave externa. En ese caso una clave externa podrá ayudar. Date cuenta que unir el orden y los métodos de búsqueda son igualmente importantes, si el plan comienza con una tabla inicial, o se utilice un escaneo completo de la clave principal del inicio de la base de datos, la clave externa de no te sirve para nada.

Cuando una aplicación borra las filas en la tabla parental, las claves de actualización de las columnas en la tabla parental también se borran.

En caso que ninguna de estas situaciones aplique, entonces estructurar las claves externas es un desperdicio de espacio y tiempo, aun más si las claves externas se encuentran en la primera columna, entonces la estructura separada de la clave externa sería redundante y por lo tanto totalmente innecesario.

Columnas de baja cardinalidad

Para las columnas de baja cardinalidad, si realmente necesitas de un estructura, podrías considerar un estructura de mapa de bits, lo cual podría traer muchos beneficios cuando tratas con columnas de este tipo. No obstante debido a un block en la estructura de un mapa de bits es posible que contenga miles de filas, la concurrencia puede provocar un problema durante las inserciones o borrados. La única manera de asegurarse es tratar de hacer un benchmarket realista con y sin estructura.

Orden de las columnas estructuradas

El orden de la estructura de las columnas también puede afectar su completa utilización, es un asunto de características menores si se tiene una versión actualizada, por en lo general las columnas que tienen alta cardinalidad por ejemplo muchos valores distintos de una tabla, están usando las clausulas WHERE que generalmente son las primeras en la estructuración. La idea es permitir la consulta de procesamiento de búsqueda para encontrar las filas que quieres buscando lo menos blocks posibles.

Para comprender este concepto, considera un directorio telefónico como ejemplo. La estructura se ordena por apellido, nombre, calle y número de la casa. Cuando estás en la búsqueda de una persona por el apellido, la organización alfabética te permite proceder en la línea correcta muy rápidamente. Pero no te ayuda en lo absoluto si tú estás realizando una búsqueda por calle, el tercer campo en el orden de acomodo, en su lugar necesitarías de un directorio donde la calle sea la primera opción de acomodo.

Revisando las definiciones de estructura

Durante el desarrollo, es importante imaginar cuales vas a leer y cuáles no. Evita hacer está actividad hasta que no termines el proceso de despliegue.

La estructura determina la necesidad de checar los planes de consulta, para consultas importantes de las aplicaciones, asegúrate que la estructura sea adecuada para soportar esas consultas.

La estructura determina la utilidad de tu aplicación, que debe correr en condiciones reales con todas las características que empleas en una producción.

El único propósito de la estructura es estimular (la clave Principal única y la clave externa) y mejorar el desempeño de las consultas. Cualquier estructura que no contenga alguna estas dos cosas, desperdicia espacio y desperdicia tiempo de servidor durante las operaciones DML

Te podrás dar cuenta que en esta discusión acerca de la estructura no tiene muchas reglas rígidas, que te dirán que la estructura dada es o no una Buena idea. Ahora bien el punto principal es que no aplicar estás reglas indiscriminadamente, debes probar tu base de datos para corroborar, la utilidad de la estructura como la posible inutilidad.

Fuente: Glenn Goodrum