Entrados ya en los modelos de datos basados en Database NoSQL, que, resumen, no requieren un Modelo de Datos “Tradicional” no olvidaremos que, no siempre, se puede tirar hacia estas arquitecturas. Por ejemplo para los sistemas más operacionales, anteriormente llamados “Transaccionales”, deberemos tener un claro Modelo de Datos. Que sin duda alguna será nuestro lastre para mucho tiempo… si no lo hacemos bien.
¿Modelos de Bases de Datos?
Es por ello que deberemos seguir algunos de los diseños y sus “normas” para poder crear buenos Modelos de Datos, podemos tener estos ejemplos:
- Modelo plano: teniendo un conjunto único y bidimensional de los elementos de datos.
- Modelo jerárquico: a partir de registros que contienen campos y conjuntos que definen una jerarquía padre/hijo.
- Modelo de red: similar al modelo jerárquico que permite las relaciones de uno a muchos usando un mapeo de tablas de “enlaces” (unión).
- Modelo relacional: colección de predicados sobre un conjunto finito de variables definidas con ciertas restricciones sobre los valores posibles y sus combinación de valores.
- Modelo de esquema de estrella: tablas de hechos y dimensiones normalizadas que eliminan atributos de cardinalidad con una baja agregaciones de datos.
- Modelo de Data Vault: mediante registro de datos históricos a largo plazo de múltiples fuentes de datos usando un sistema hub, distintos satélites y tablas de enlaces.
Ciclo de Vida de las Bases de Datos
No debemos olvidar que, una vez creada la Database, esta sigue creciendo y es por ello que la recomendación es poder tener una serie de premisas que nos pueden servir para continuar con su Ciclo de Vida, podrían ser:
- Adaptabilidad: crear esquemas que soporten la mejora o la corrección.
- Capacidad de expansión: creación de esquemas que superen sus expectativas.
- Fundamentalidad: crear esquemas que ofrezcan funciones y funcionalidades.
- Portabilidad: crear esquemas que pueden hospedarse en sistemas dispares.
- Explotación: crear esquemas que maximizen la tecnología del host/cloud.
- Almacenamiento eficiente: creación de un sistema de huellas (trazabilidad) en disco para optimizar los esquemas.
- Alto rendimiento: crear esquemas optimizados que nos permitan sobresalir.
Optimización de los esquemas
Muchas veces “solo” nos centramos en la construcción de las arquitecturas (cloud) o en el diseño de la base de datos, dejando de lado la topología lógica de la base de datos, por ejemplo, podemos ver, a continuación, algunos problemas que se nos pueden presentar:
- Utilizar claves primarias compuestas rara vez son efectivas o apropiadas, sin duda hay algunas excepciones dependiendo del nuestro modelo de datos.
- Claves primarias erróneas, por lo general: datetime y/o cadenas de texto (excepto un GUID o hash) son inapropiadas.
- Tener una indexación, podría relantizar nuestro rendimiento.
- Los tipos de datos de columna cuando solo se necesita un entero/entero largo (aquellos que se requieren en una relación o una combinación) en una clave principal.
- La asignación de almacenamiento desconsiderando el tamaño de los datos y el potencial de crecimiento.
- Referencias circulares donde una tabla A tiene una relación con la tabla B, la tabla B tiene una relación con la tabla C, y la tabla C tiene una relación con la tabla A: esto es simplemente es un mal diseño.
¿Framework como Modelo de Datos?
Si, hay muchos y distintos entre ellos, pero me centraré en el DoDAF (Department of Defense Architecture Framework) del cual podréis tener más información mediante éste enlace.
DoDAF proporciona una arquitectura abierta para crear productos basados en técnicas de análisis y diseño estructurados. Utilizando sus técnicas/características para describir la arquitectura de un sistema complejo. El objetivo, principal, es poder definir conceptos y modelos utilizables en los seis procesos centrales de toda (casi) organización, como pueden ser:
- Integración y Desarrollo de Capacidades.
- Planificación, Programación, Presupuestación y Ejecución.
- Sistemas de adquisición.
- Ingeniería de Sistemas.
- Planificación de operaciones.
- Capabilities Portfolio Management.
Para ello define una série de modelados de datos, dividos en diferentes niveles, lo podemos ver en la figura siguiente:
Estos tres niveles nos vienen a decir que:
- El nivel conceptual o el Modelo conceptual de datos (MDL) define la construcción de los datos de alto nivel a partir de las cuales se crean descripciones arquitectónicas en términos no técnicos, de modo que los departamentos de negocio, puedan comprender la base de datos a partir de su descripción arquitectónica.
- El Modelo de datos lógicos (LDM) agrega información técnica, como atributos al MDL y, cuando es necesario, aclara las relaciones en una definición de uso inequívoca.
- La especificación de intercambio físico (PES) usa los tipos de datos generales especificados anteriormente como los atributos de implementación (por ejemplo: fuente, fechas) agregados, y luego se genera un fichero XML resultante.
Podéis encontrar más información sobre DoDAF en:
