Ya podemos tener una única metodología para modelar bases de datos indiferentemente del motor de base de datos que vayamos a usar.
¿Por qué seguimos con el mismo modelo propuesto por Edgar Codd en ~1970 para bases de datos relacionales?
Sigo viendo muchos programadores, profesionales, que modelan sus bases de datos siguiendo el mismo patrón, ya sea directa o indirectamente, y lo peor de todo es que lo hacen mal.
Normalizar una base de datos tiene seis formas normales con tres casos especiales intermedios.
Si bien es cierto que todos los casos no fueron propuestos por Edgar Codd las tres primeras formas normales y el lenguaje único propuesto por él, lenguaje que ahora conocemos como SQL sí.
Hoy tenemos motores de bases de datos que no responden a ese lenguaje de consulta llamado NoSQL, y que tampoco tienen implementado un sistema de tablas denominado relacional.
Tenemos bases de datos NoSQL que responden a través de API y que no requieren de un esquema definido.
Ahora sí empecemos abriendo con la siguiente pregunta:
¿Cuales son las estructuras de datos que usan las bases de datos?
Hago esta pregunta para empezar a establecer las bases de lo que quiero proponer como metodología única de diseño.
Los que hemos sido, y los que son ingenieros de datos sabemos que hay varios pero los usados por el 99% de los motores de bases de datos son:
B+ Tree | Heaps | Graph
Hash | ISAM
Y pueden haber combinaciones como por ejemplo DynamoDB de AWS que es de tipo Hash y B+ Tree.
Pero en general todas usan o un sistema de Índices o un sistema de Nodos y Bordes tipo árbol.
La siguiente pregunta es de las más trascendentales para esta nueva propuesta de metodología y es:
¿Qué motivo a Edgar Codd para redactar en ~1970 su paper:
A Relational Model of Data for Large Shared Data Banks
Muy contrario a lo que muchos piensan en el paper Edgar Codd menciona varias motivaciones ordenadas por importancia:
- Independencia de las aplicaciones
- Representación de los datos
- Aumento en el número de tipos de datos
- Inconsistencia de datos
- Redundancia y Consistencia
Cada una de las preocupaciones y propuestas de Edgar Codd ya están resueltas de manera intrínseca en los motores de bases de datos modernas, aún así seguimos usando su propuesta de normalización de bases datos para crear los modelos asociados a las aplicaciones.
Ahora si la propuesta que denomino:
Metodología de modelado de bases de datos por análisis entrópico.
Entropía: Mide el número de microestados compatibles con el macroestado de equilibrio; también se puede decir que mide el grado de organización del sistema.
Esa definición es la que se le da en física a la entropía la cual entro a explicarles por qué la he llamado así y la importancia que tiene en la propuesta de diseño único de bases de datos.
Pero primero aclaremos algo el CRUD:
En la metodología que propongo no existe ni UPDATE ni tampoco DELETE solo existe CREATE y READ
Y esto por algo muy importante, los siguientes dos elementos claves en mi propuesta:
El primer elemento clave son los patrones de acceso:
Estos definen como obtienes los datos de la base de datos el READ.
El segundo elemento clave son los patrones de escritura:
Estos definen como los datos entrán en relación con el resto dentro del modelo el CREATE.
Esto tiene unas implicaciones importantes, y es la secuencia ordenada de los datos, tanto por orden alfabético como orden cronológico, algo que si o si en esta metodología debes tener en cuenta a la hora de modelar.
Volvamos a la entropía: Microestados compatibles con el macroestado.
Cuando modelas una base de datos en su etapa inicial tienes control de todo lo que se va a representar y la compatibilidad de estos, es decir, la relación entre los diferentes patrones de acceso.
Y la segunda parte de entropía habla de medir el grado de organización del sistema.
Y esto esta más relacionado en mi propuesta con el sistema de pruebas, cuando aparece un nuevo patrón de acceso o patrón de escritura denominado microestado o nuevo estado.
Cuando diseñas una serie de mecanismos para probar el rendimiento y la escalabilidad de la base de datos según el modelo definido, un nuevo microestado o nuevo estado debe ser fácil de incorporar porque no puede de ninguna forma romper el macreoestado.
Indiferentemente del motor de base de datos se va a tener un núcleo o core, ya sea un nodo, o una tabla.
A partir de ahí se plasman todos los patrones de escritura. Los patrones de acceso en parte van directamente sobre ese núcleo, y parte van a ir a índices o espejos (vistas)
Esta metodología busca tener el menor número de tablas el ideal es una, o el menor número de arboles lo ideal uno que supla todas las necesidades actuales como futuras.
Aunque puedo listar una serie de posibles ventajas, me gustaría mencionar una desventaja importante.
A nivel de arquitectura de software hay un trade-off dado que esta propuesta de metodología entra en conflicto con la agilidad, dado que debes invertir un tiempo importante en la definición de todo lo que la metodología pide.
Mi propuesta tiene muchas más partes, más detalladas, pero estas las quiero ir validando a través de la maestría en ingeniería de software que empezaré el próximo año, puede que termine siendo un paper, o un libro.