Buenas Prácticas en Ambientes de Bases de Datos

Nota Aclaratoria: La siguiente publicación tiene como objetivo resumir el contenido de los capitulos 3, 4, 5 y 6 del libro de Craig S. Mullins: "Database Administration: The Complete Guide to Practices and Procedures".

Chapter 3. Data Modeling and Normalization

Para Mullins, el modelaje de datos consiste en documentar los distintos procesos de negocios involucrados en el diseño de la base de datos. No incluye siquiera entender el “¿cómo?”, sino el “¿qué?”, y es básicamente entender cuáles elementos de la organización son participantes y que son esenciales en el esquema de diseño de la base de datos.

Denota primordial importancia en la contribución de los administradores de bases de datos o de los analistas de datos para desarrollar un modelo que pueda ajustarse a los requerimientos establecidos. En muchas ocasiones, trabajar directamente con los desarrolladores de las aplicaciones y ver desde el punto de vista funcional de la aplicación los requerimientos deja de lado tan importante labor de diseño y modelado de la base de datos, que luego puede ser penalizado con problemas de rendimiento, incompatibilidad de tipos de datos, integridad, entre otros.

El modelado de los datos captura y envuelve los requerimientos de datos de la organización al mismo tiempo que aplica reglas de normalización que evitan la redundancia y mejoran el rendimiento, junto con esto, las mejoras de estabilidad y consistencia que van de la mano con el plano conceptual.

En este capítulo, Mullins destaca que un buen modelo de datos aporta a una mejor implementación, al mismo tiempo que pueden distinguir patrones de datos que pueden mejorar la estrategia de negocio y procesos de negocio en general.

Se recomiendan las siguientes formas de pensar, a la hora de diseñar un modelo de datos:

No pensar a nivel físico, sino conceptual.

No pensar en procesos, pensar en estructuras.

No pensar en navegación, pensar en relación.

En este último punto, se recalcan los diferentes enfoques para la creación de los modelos de datos, entre los que se menciona: el UML y el diagrama de Entidad-Relación (el autor enlista los diferentes métodos para los diagramas de Entidad-Relación en los que la cardinalidad es el principal diferenciador).

Al final del capítulo de detallan los principales componentes de un modelado de datos y las reglas de normalización, entre los que se mencionan:

1.      Las Entidades: Una persona, lugar, cosa, concepto o evento.

2.      Los Atributos: Lo que identifica, relaciona o describe las entidades.

3.      Las Llaves: Son los atributos que identifican y relacionan entidades.

4.      Las Relaciones: Describe como las distintas entidades están asociadas entre si

Y para las reglas de normalización:

1.      Primera Regla: Eliminar grupos repetitivos y atomizar datos.

2.      Segunda Regla: Asegurar que cada atributo de las entidades son dependientes.

3.      Tercera Regla: Asegurar que no existan atributos relacionados entre sí en cada entidad.

En general, el capítulo destaca las bases para el diseño de una base de datos. El modelado de los datos es una práctica que analiza los elementos de interés para la organización y cómo estos elementos están relacionados entre sí. Aunque es una práctica sencilla, se requiere tiempo para perfeccionar las diferentes técnicas, pero siempre sigue siendo de vital importancia. 

Chapter 4. Database Design

El modelo de lógico de los datos debería utilizarse como plano conceptual para el diseño y creación de la base de datos física. Antes de pasar al diseño de la base de a base de datos, se debe contar con el modelo lógico, sin embargo, también es necesario contar con un conocimiento profundo de las características del DBMS, de sus habilidades y limitaciones, de cómo almacena los datos, entre otros, incluyendo:

·        Objetos soportados, estructuras físicas y archivos requeridos.

·        Tratamiento de índices, integridad referencial, restricciones, etc.

·        Versiones.

·        Configuración necesaria.

·        Habilidades para manejar el lenguaje de definición de datos (DDL, en inglés) del DBMS.

A groso modo, el capítulo detalla los elementos que comprenden el diseño de la base de datos, en su esencia, asociados a los elementos creados previamente en el modelado de datos:

Entidades à Tablas

Atributos à Columnas

Dominios à Tipos de Datos

Llaves à Llaves Primarias

Relaciones à Restricciones Referenciales

Sin embargo, el diseño de la base de datos no es solo una cuestión de mapear los elementos del modelo lógico al modelo físico. Se deben manejar algunos de los problemas más comunes, como lo son el tema de almacenamiento y el de rendimiento de la base de datos.

Mullins afirma que para el DBA poder llevar a cabo un diseño completo de la base de datos, debe tomar en cuenta los distintos factores que puedan afectar el almacenamiento físico, esto es, archivos físicos de índices, encabezados de página, punteros, etc. Se debe tomar en cuenta el overhead que pueda ser causado por estos elementos a partir de la estimación del tamaño de las tablas, contabilizando el tamaño de cada fila por el tipo de datos y proyectándolo al número de filas que se esperaría tener y creando tablespaces. Por otro lado, podría considerarse también utilizar técnicas de compresión de datos, sin embargo esto también puede ser penalizado con el procesamiento de CPU.

El siguiente enfoque sería el rendimiento. El administrador de base de datos debe empezar a considerar cómo la base de datos va a interactuar con las aplicaciones cuando se hagan solicitudes para acceder o modificar los datos.

Uno de los principales elementos a tomar en cuenta es el mantenimiento de los índices. Los índices ayudan al DBMS a encontrar los datos fácilmente. Sin embargo, la falta de índices o su mala gestión puede conllevar al motor a escanear toda la tabla, validando registro por registro en una solicitud que no lo requiera. Normalmente, se aplican índices a tablas con gran cantidad de registros y que son accedidas regularmente con las mismas consultas repetitivamente. 

Entre las principales categorías de índices que menciona Mullins están el b-tree, bitmap, reverse-key, partitioned key y clustered key. Todos estos, a lo largo de sus definiciones proveen funcionalidad complementaria a nivel de rendimiento para el motor.

A lo largo del tema de acceso de datos y desempeño del DBMS, también se abarcan conceptos como el hashing, clustering, datos intercalados, “desnormalización” y vistas, que se aplican como técnicas de distribución, almacenamiento y consumo de los datos de manera eficaz para escenarios específicos.

Al fin y al cabo, existen muchas decisiones que se deben tomar en cuenta a partir de ciertas consideraciones antes de empezar a crear estructuras dentro de la base de datos. En muchas ocasiones, se pueden necesitar desviaciones del modelo lógico pero basándose en el conocimiento profundo de las capacidades del DBMS y del ambiente físico donde la base de datos existirá.

 

Chapter 5. Application Design

Para Mullins, el diseño de la aplicación va más allá de escribir solicitudes hacia la base de datos por medio de una interfaz; involucra también aspectos de integridad de los datos con los que interactúa e incluso cuestiones de rendimiento. Al mismo tiempo, es importante que el DBA promueva el conocimiento de estos factores y que al mismo tiempo logre canalizar los esfuerzos de diseño de aplicaciones de manera eficiente para que no tengan que ser necesariamente re-diseñadas o re-codificadas en el futuro.

Esto va de la mano de aplicaciones que requieran del almacenamiento de datos persistentes en la base de datos o de usuarios que requieran realizar consultas para reportes, etc. Para los desarrolladores, es importante que conozcan las capacidades del lenguaje de consulta SQL. El autor hace especial énfasis en el lenguaje como el estándar para acceder a las base de datos relacionales que provee un grado de abstracción más alto de los lenguajes normales.

SQL especifica qué datos son necesarios, sin embargo no especifica como extraerlos. El modelo conceptual del lenguaje que se detalla en el capítulo, establece un paradigma de procesamiento de los datos donde una o varias tablas son accedidas para extraer 1, varios o ningún registro. El DBMS se encargará de determinar la mejor forma de extraer esos datos.

También se mencionan algunas de las APIs más comunes en el ámbito de desarrollo de aplicaciones que ayudan a interactuar con la base de datos, entre los que se detallan el ODBC, JDBC, SQLJ y OLDB.

En el tema de orientación a objetos, Mullins deja muy claro que, aunque puede resultar en un buen retorno de inversión para programas de desarrollo, las aplicaciones y la base de datos relacional no serán orientadas a objetos en el sentido estricto de la palabra.

Existen otros factores a la hora de trabajar con SQL, la definición de las transacciones. En este caso, se recomienda que sigan las propiedades de atomicidad, consistencia, aislamiento  y durabilidad (ACID, en inglés). Bajo este mismo contexto, se deben estandarizar la secuencia de las transacciones en los distintos programas o incluso dentro de la misma aplicación para evitar caer en deadlocks o bloqueos de tablas, entre otros.

En general, el diseño de las aplicaciones es una labor de los analistas de sistemas y programadores de aplicación. Sin embargo, el DBA debe estar involucrado en el proceso cuando los programas son codificados para acceder a la base de datos.

 

Chapter 6. Design Reviews

Durante todas las etapas anteriormente mencionadas, se toman decisiones tanto en el diseño de la base de datos como en el desarrollo de la aplicación. La revisión de diseño tiene como propósito asegurarse de que dichas decisiones son las adecuadas, y que siguen el enfoque de efectividad, eficiencia y exactitud, a un costo seguro y si no, poder hacer las correcciones que sean necesarias.

Las reuniones de revisión de diseño buscan estandarizar ciertos factores que se componen a base de la experiencia o referencias que respaldan a los participantes del mismo. En estas reuniones posiblemente haya confortamientos y discusiones a base de los distintos puntos de vista, pero lo importante es que no es una interacción combativa, sino que se busca llegar a un consenso que llegue a ser el mejor para el diseño del mismo.

Una vez establecidas las reglas de la reunión de revisión de diseño, es importante conocer el tipo de participantes, entre los que se mencionan:

·        El líder

·        El escribiente (toma nota)

·        El mediador (negocia los argumentos)

·        Los participantes (compañeros, DBAs, supervisores, etc.)

Independientemente del tipo de participante, es importante que todos cuenten con suficiente conocimiento técnico (por ejemplo, el conocimiento de SQL a nivel respectivo a su puesto) y por su puesto buena comunicación y habilidades interpersonales.

Una vez conocidas estas partes, es importante recalcar que a lo largo del ciclo de vida de desarrollo de la aplicación pueden existir varios tipos de revisiones de diseño. En ese sentido, por ejemplo, el autor menciona los siguientes tipos de revisiones de diseño en las distintas etapas:

·        Diseño Conceptual (Recolección de requerimientos)

·        Diseño Lógico (Analisis – Diseño)

·        Diseño Fïsico (Diseño)

·        Diseño Organizacional (Diseño – Desarrollo)

·        SQL y Código de Aplicación (Desarrollo – Testeo)

·        Pre-Implementación (Testeo)

·        Post-Implementación (Operaciones)

Estableciendo el enfoque sistemático en la revisión de diseño es muy probable que se implementen aplicaciones óptimas. La documentación de estas revisiones y su seguimiento con las apropiadas correcciones aseguran la creación de una aplicación exitosa.

Conclusiones y Recomendaciones

En el contexto de los capítulos resumidos en este documento, se destacan los principales factores que componen las bases de diseño de una base de datos. El modelado de los datos y sus técnicas remiten la importancia de contar con la documentación que pueda socorrer la implementación e incluso la operación de las bases de datos.

Al mismo tiempo, hay que tomar en cuenta que la implementación del diseño físico no solo es una labor de mapear los elementos del modelo lógico a la base de datos (creación de tablas y relaciones). Sino también es una labor que involucra la revisión de los patrones de rendimiento y de almacenamiento del DBMS.

Bajo el contexto de desarrollo de aplicaciones, el DBA debe estar involucrado en el proceso de diseño de la aplicación para poder dar testimonio de los elementos clave a tomar en cuenta cuando se requiera interactuar con la base de datos para extraer o actualizar datos persistentes. Esto por cuestiones que puedan ser un problema como compatibilidad en tipos de datos o de rendimiento que terminen en la recodificación o rediseño de la aplicación.

Por último, es importante contar con sesiones de revisión de diseño con los expertos en el área para poder hacer las correcciones necesarias a tiempo y siempre a lo largo del ciclo de vida de desarrollo de la aplicación, garantizando la implementación de un sistema eficiente, efectivo y exacto.