En este post vamos a profundizar en la normalización de bases de datos relacionales, un concepto fundamental para diseñar bases de datos eficientes, sin redundancias y con integridad de datos.
Vamos a ver:
- ✅ Qué es un RDBMS (Sistema de Gestión de Bases de Datos Relacionales) y sus beneficios.
- ✅ El proceso para crear una base de datos relacional desde el diseño hasta la implementación.
- ✅ Las formas normales (1NF, 2NF, 3NF) y cómo aplicarlas.
- ✅ Las 12 reglas de Codd para el modelo relacional.
- ✅ Los requisitos ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) y por qué son cruciales.
Puede que esta teoría te parezca muy abstracta ahora mismo. «¿Normalización? ¿Formas normales? ¿ACID? ¿Y todo esto para qué si todavía no sé hacer un Diagrama Entidad-Relación?»
Tranquilo, es normal sentirse así al principio. La teoría y la práctica van de la mano, pero la teoría siempre va un paso adelante.
💡 Lo importante que debes saber ahora: Los conceptos de normalización que vas a aprender hoy son los mismos que aplicarás cuando diseñes tu primera base de datos profesional, ya sea para una aplicación web con Flask, una app de escritorio con PyQt, o cualquier otro proyecto que maneje datos.
En los próximos posts, después de dominar esta teoría, pondremos manos a la obra:
- 📊 Diseñaremos un Diagrama Entidad-Relación paso a paso.
- 🛠️ Crearemos la base de datos en MySQL.
- 🔗 Conectaremos todo con Flask para que tu aplicación web sea 100% funcional.
Pero para que ese momento sea un éxito y no un dolor de cabeza, necesitas entender bien lo que vamos a ver hoy. Así que respira hondo, concéntrate, y vamos a por ello. 🐍🔥
Habiendo comprendido el funcionamiento del modelo relacional que vimos en el post anterior, es momento de conocer el concepto de normalización de bases de datos.
Para introducirte a la normalización, debes conocer primero el proceso para diseñar una base de datos. Como ya sabrás, las bases de datos son muy útiles para gestionar información de forma eficiente, ya sea en una empresa, pyme, o simplemente los datos de usuarios de un sitio web. El desarrollador debe diseñar la estructura de la base de datos siguiendo un conjunto de reglas a las relaciones de los datos.
Pasos para crear una base de datos relacional
Primeramente, antes de crear una base de datos relacional en algún gestor, se debe diseñar un boceto, un diagrama de cómo se relacionan los datos y donde se especificarán las relaciones, claves foráneas, claves primarias, etc.
De esta forma tendremos una vista previa de cómo estará organizada nuestra DB y cómo se estructuran los datos que vamos a almacenar dentro de ella.
Una vez creado este diagrama (Entidad – Relación), se procede a crear la base de datos utilizando un Gestor de Bases de Datos Relacionales (RDBMS o RDBG).
Entonces, repasemos los pasos para crear nuestra base de datos:
- 🎨 Crear un diagrama Entidad-Relación: El diagrama de entidad-relación es un clásico diagrama o modelo similar al diagrama de flujos que hemos visto anteriormente en programación en Python, pero con la diferencia de que ilustra cómo las entidades, personas, objetos, datos se relacionan entre sí dentro del sistema.
- 📤 Exportar nuestro diagrama a un RDBMS: Normalmente estos diagramas son realizados utilizando algún software diseñado específicamente para estos propósitos, como por ejemplo: Lucidchart, Workbench, etc. Mediante estos podemos exportar nuestro diseño a algún Relational Database Management System (RDBMS) como podría ser MySQL, SQLite, etc. Y aquí es donde abarca el concepto de Normalización, ya que son esas reglas que debemos respetar y definir claramente, desde el momento de diseñar nuestra base de datos creando un diagrama hasta que lo exportamos a nuestro RDBMS.
- 📥 Comenzar a añadir datos a nuestra base de datos respetando las reglas y relaciones establecidas anteriormente, protegiendo la integridad de los datos.
En este post aprenderemos primeramente las reglas de normalización para luego, en la siguiente entrada, aprender a crear nuestro diagrama de Entidad-Relación y exportar nuestra base de datos a MySQL en un servidor web.
Es importante que te concentres en aprender estas reglas y los beneficios que otorga respetarlas.
Pero antes, es importante comprender qué es un RDBMS y qué beneficios nos otorgan.
¿Qué es un RDBMS?
El modelo relacional es APARTE del gestor del sistema de bases de datos (Relational Database Management System, RDBMS de ahora en más). Podemos usar MySQL, PostgreSQL, SQLite, MariaDB, etc. (que son RDBMS de los cuales seguro habrás oído o manipulado).
Todos los RDBMS tienen sus pequeñas variaciones; sin embargo, nuestro modelo relacional basado en un diseño mediante el diagrama entidad-relación que veremos más adelante debe poder aplicarse a cualquier DBMS relacional (MySQL, SQL, PostgreSQL, etc.).
Si quieres profundizar en la diferencia entre SQL y NoSQL, te recomiendo leer nuestro post Relacional vs NoSQL.
Simplemente, un DBMS o DBGS es un software de gestión de bases de datos cuya función es servir de interfaz entre la base de datos, el usuario y las distintas aplicaciones utilizadas. Además de simplificarnos el manejo de los datos en conjunto y brindarnos numerosas herramientas que optimizan la creación, actualización, mantenimiento, consultas, etc. de información. En el caso de los que aplican al modelo relacional, se los denomina RDBMS (Relational Database Management System).
Para entender mejor la diferencia entre un modelo relacional y un RDBMS, imagina que el modelo relacional es el plano de una casa (cómo debe ser), y el RDBMS es el arquitecto y los materiales de construcción (quién lo construye y con qué herramientas). Puedes tener el mejor plano del mundo, pero si no usas un buen arquitecto, la casa se caerá.
Características y beneficios de los RDBMS
Un Software de gestión de bases de datos nos asegura:
- Independencia: De la información respecto de nuestro programa de aplicación.
- Seguridad de los datos: Además de una gestión segura, se nos permite realizar backups automáticos entre otras.
- Mínima redundancia: Evitar datos repetidos en lugares diferentes.
- Consistencia de la información: La información está completa, los datos se mantienen idénticos durante cualquier operación, como transferencia, almacenamiento y recuperación.
- Abstracción de la información sobre su almacenamiento físico: Poder aislar la información del contexto físico de almacenamiento, trasladarla a otro sistema, a otro servidor, etc.
- Adopción de medidas necesarias para mantener la integridad de la información: Nos proporciona y nos obliga a respetar ciertas normas que permiten mantener la información íntegra, sin inconsistencias.
- Medidas de seguridad y gestión de permisos de usuario: Admite y permite a más de un usuario leer, modificar, actualizar, mantener la información controlando sus privilegios y asegurando los beneficios anteriormente mencionados para cada uno de ellos.
- Nos brinda un lenguaje DCL (Lenguaje de control de datos): Así cada RDBMS tiene su lenguaje y variación del mismo, normalmente SQL que nos permite realizar acciones con los datos almacenados de forma segura, conjunta, ágil, y normalmente no está ligado a ningún proveedor específico. Por lo que aprender este lenguaje permite manejar muchos y diversos RDBMS.
Pero hay algo importante que debes saber: aunque los RDBMS nos dan todas estas herramientas, el modelo relacional está sujeto a ciertas restricciones, reglas y recomendaciones que debemos respetar a la hora de diseñarlo, manipularlo y mantenerlo. A estas reglas son las que llamamos normalmente Normalización de la base de datos.
Diagrama del proceso de creación de una base de datos y ventajas de la normalización
Como siempre, te aporto mis humildes diagramas para que comprendas mejor todo lo que estoy diciendo y logres ordenar estos conocimientos en tu mente. Y fíjate que también te permite tener un orden mental de lo que estás aprendiendo.
En este caso, veremos esos requerimientos que son explícitos, que están escritos por personas que quieren que no cometamos errores graves con el manejo de la información. Luego, cada paso del procedimiento de crear una base de datos consiste en respetar y tener en cuenta estos requerimientos explícitos y también los implícitos de cada software utilizado, entre otros.
El siguiente diagrama muestra el flujo completo: desde la idea inicial, pasando por el diseño conceptual (Diagrama ER), la normalización, la implementación en un RDBMS, hasta la gestión de los datos con reglas ACID y las 12 reglas de Codd.
La normalización de bases de datos explicada de forma sencilla
Al momento de diseñar nuestra base de datos relacional, debemos ir pensando en tablas y relaciones entre los datos, y para ello optamos por diseñar y seguir ciertas reglas y formas normales como ya te había explicado, para evitar redundancias e inconsistencias en los datos.
Como te dije también, existen varias reglas definidas como «formas normales» que, aunque resulta difícil, siempre debemos tratar de lograr seguir al menos las primeras tres. En el caso de que no lo hiciéramos, deberíamos prever posibles soluciones para los posibles datos redundantes, duplicados, o problemas en cuanto a relaciones, etc.
Si quieres profundizar en el concepto de normalización, te recomiendo leer el artículo de Wikipedia sobre normalización de bases de datos.
Reglas normales (Formas Normales)
Las formas normales pueden verse como niveles. Si se cumplen las tres primeras en una base de datos, podemos afirmar que esta está en la tercera forma normal.
Imagina que las formas normales son como los filtros de una piscina: cada filtro elimina un tipo de impureza (redundancia). Cuantos más filtros tengas, más limpia estará el agua (tus datos).
Primera forma normal (1NF)
Se dice que una base de datos relacional está en la «primera forma normal» si cumple que:
- Se eliminan grupos de repetición en tablas individuales.
- Se crea una tabla independiente para cada conjunto de datos relacionados.
- Identificamos cada conjunto de datos relacionados con una clave principal.
Esto, en criollo (como suelo explicar yo), refiere a que no habrá repeticiones de grupos de datos dentro de una misma tabla y se creará una tabla independiente para cada grupo o conjunto de datos que están relacionados.
Por ejemplo, sería lo normal tener una tabla Estudiantes con los nombres, edades, cursos, etc. Y no sería correcto tener una tabla donde un estudiante tenga varias materias en una misma columna separadas por comas.
💡 Ejemplo de violación de 1NF: Una tabla donde un estudiante tiene varias materias en una misma columna (materias: «Matemáticas, Historia, Ciencias»). Para cumplir la 1NF, debemos crear una tabla separada para las Materias y relacionarla con el estudiante mediante su ID_Estudiante.
Así, en lugar de tener una fila con varias materias, tendremos una fila por cada materia que curse el estudiante. Esto facilita las consultas y evita la redundancia.
Segunda forma normal (2NF)
Se dice que una base de datos está en segunda forma normal si cumple los requerimientos de la primera y además:
- Se crean tablas independientes para conjuntos de valores que se apliquen a varios registros.
- Se relacionan estas tablas mediante una clave externa (foránea).
Básicamente, eliminamos datos redundantes.
Nada difícil de interpretar, y como hemos hablado anteriormente, refiere a no almacenar un mismo valor en varias tablas. Por ejemplo, si un cliente hace varios pedidos, no tiene sentido guardar su dirección en cada pedido que realiza. Si la dirección cambia, tendríamos que actualizarla en todos los pedidos anteriores, lo que es un problema.
La solución es simple: creamos una tabla Clientes con su dirección, y en la tabla Pedidos solo guardamos una referencia (la clave foránea) al cliente correspondiente.
💡 Ejemplo de violación de 2NF: Una tabla que almacena pedidos donde la dirección del cliente se repite en cada pedido. Solución: crear una tabla Clientes con la dirección y relacionarla con Pedidos mediante una clave foránea (ID_Cliente).
Así, si Ana Pérez cambia de dirección, solo tenemos que actualizarla una vez en la tabla Clientes, y todos sus pedidos reflejarán automáticamente el cambio. ¡Mucho más eficiente y limpio!
Tercera forma normal (3NF)
Decimos que una base de datos está en tercera forma normal si cumple las dos primeras y además:
- Se eliminan los campos que no dependen de la clave.
Aplicar al 100% la tercera forma normal a veces resulta complejo y deriva en crear muchas tablas pequeñas que podría acarrear problemas de rendimiento. Pero básicamente consiste en que, si hay atributos que no tienen relación directa con la clave primaria, hay que eliminarlos y colocarlos en una tabla separada, relacionando ambas tablas por medio de una clave externa. Es decir, no debería haber ninguna dependencia transitiva.
Imagina que tienes una tabla de empleados y guardas el departamento al que pertenecen con toda su información (nombre, ubicación). El nombre y la ubicación del departamento dependen del departamento, ¡no del empleado! Si el departamento cambia de nombre o ubicación, tendrías que actualizar a todos los empleados de ese departamento.
💡 Ejemplo de violación de 3NF: Una tabla de Empleados que almacena id_departamento, nombre_departamento y ubicacion_departamento. El nombre y la ubicación dependen del departamento, no del empleado directamente.
La solución es simple: creamos una tabla Departamentos separada con toda la información del departamento, y en la tabla Empleados solo guardamos una referencia (id_departamento) al departamento correspondiente.
Así, si el departamento cambia de ubicación, solo tenemos que actualizarlo una vez en la tabla Departamentos, y todos los empleados lo reflejarán automáticamente. ¡Datos limpios y sin redundancias!
📊 Resumen: Las 3 formas normales de un vistazo
| Forma Normal | ¿Qué problema resuelve? | Regla clave | Ejemplo |
|---|---|---|---|
| 1NF Primera forma normal |
Eliminar grupos de repetición en una tabla | Cada celda tiene un solo valor | Estudiante con varias materias en una columna → Una fila por materia |
| 2NF Segunda forma normal |
Eliminar datos redundantes | Crear tablas independientes con clave foránea | Dirección del cliente repetida en cada pedido → Tabla Clientes separada |
| 3NF Tercera forma normal |
Eliminar dependencias transitivas | Los atributos deben depender solo de la clave primaria | Empleado con datos del departamento → Tabla Departamentos separada |
📌 Recuerda: Si tu base de datos cumple las 3 primeras formas normales, puedes decir que está «bien normalizada». Esto te asegurará datos limpios, sin redundancias y fáciles de mantener.
Representación gráfica del proceso de normalización cumpliendo las 3 formas normales.
Si te has quedado algo descolocado, no te preocupes que solo estoy exponiendo la teoría. Esto llevado a la práctica en realidad se hace aún más fácil de comprender y recordar. En las próximas entradas, cuando comencemos a diseñar bases de datos, recordaremos y aplicaremos estas formas normales.
Por lo pronto, he encontrado un blog que lo explica muy claro y me gustaría que lo leyeras para asegurarte una mejor comprensión de los conceptos y reglas de normalización: Formas normales en Wikipedia.
Las 12 reglas de Codd para el modelo relacional
Recordarás que Edgar Codd es el creador del modelo relacional. Este tipo vino a cambiar las cosas, pero al ver que muchos programadores y diseñadores de bases de datos cometían errores y eran muy «cochinos» (como decimos en Argentina), decidió solucionarles la vida una vez más especificando una docena de reglas que determinan un modelo relacional exitoso. Y nos evita futuros problemas de inconsistencia, redundancia y dolores de cabeza (o llamadas de la vecina de la suegra de la tía de tu ex novia, para que veas lo molestas que se pueden volver las relaciones 😂).
Las 12 reglas resumidas y explicadas con palabras «terricolas» dicen así:
- Información: En el modelo relacional, toda la información de la base de datos debe estar representada explícitamente en el esquema lógico. Nada de datos ocultos o «escondidos, implícitos, etc.». Toda la información debe estar en la base de datos.
- Acceso garantizado: Todo dato debe ser accesible conociendo el valor de su clave primaria y el nombre de la columna (atributo) que contiene el dato. No deben existir datos sin claves ni atributos que garanticen su rápido y fácil acceso.
- Tratamiento sistemático de valores nulos: El sistema debe permitir el tratamiento adecuado de los valores
NULL, especificando correctamente cuáles atributos los permiten y cuáles no. Una clave primaria jamás debe permitir NULL. - Catálogo en línea basado en el modelo relacional: Todos los datos del modelo deben soportar un catálogo basado en relaciones que permita al usuario acceder a la estructura relacional total del modelo.
- Sublenguaje de datos completos: El modelo debe contar con un sublenguaje (como SQL) capaz de manipular los datos de la base de datos.
- Actualización de vistas: Una vista (resultado de una consulta) debe mostrar la información más actualizada siempre.
- Inserciones, modificaciones, eliminaciones de alto nivel: Cualquier operación debe ser en conjunto de filas o registros, no registro a registro.
- Independencia física: Los datos deben poder ser accesibles desde la lógica de la BD aunque se modifique el almacenamiento físico.
- Independencia lógica: Los programas no deben verse afectados por cambios en los datos de la base de datos.
- Independencia de Integridad: Las reglas de integridad deben almacenarse en la base de datos (en el diccionario) y no en los programas de aplicación.
- Independencia de la distribución: Para el usuario que visualiza la base de datos, esta debe mostrarse íntegra a pesar de estar fragmentada en diferentes servidores.
- No subversión: Si un sistema relacional tiene un lenguaje de bajo nivel, ese bajo nivel no puede ser utilizado para violar las reglas de integridad y las limitaciones expresadas en el lenguaje relacional de alto nivel.
Estas reglas las debes respetar. Y no son las únicas: existen diversos requisitos a cumplir a la hora de trabajar con el modelo relacional.
Estas son las reglas que Edgar Codd definió para garantizar que un sistema de bases de datos sea verdaderamente relacional:
- 1️⃣ Información explícita
- 2️⃣ Acceso garantizado
- 3️⃣ Tratamiento de NULL
- 4️⃣ Catálogo en línea
- 5️⃣ Sublenguaje de datos
- 6️⃣ Actualización de vistas
- 7️⃣ Operaciones de alto nivel
- 8️⃣ Independencia física
- 9️⃣ Independencia lógica
- 🔟 Independencia de integridad
- 1️⃣1️⃣ Independencia de distribución
- 1️⃣2️⃣ No subversión
💡 En resumen: Codd nos enseñó que una base de datos relacional debe ser transparente, accesible, íntegra y consistente. Si respetas estas reglas, tus datos estarán siempre bajo control.
Requerimientos ACID: Características de las transacciones
⚠️ IMPORTANTE: Toda base de datos relacional debe cumplir estos requerimientos.
Atomicidad + Consistencia + Aislamiento + Durabilidad
Los requisitos ACID deben ser cumplidos por toda base de datos relacional con la que trabajemos. Es importante que lo comprendas a fondo, cada palabra.
Transacción: Interacción con una estructura de datos compleja que está compuesta por un conjunto de órdenes o instrucciones que se ejecutan una después de la otra, de una sola vez.
Podemos, en un principio (porque estamos recién comenzando con bases de datos), pensar en una transacción como un cambio mediante una instrucción o sentencia.
Las características ACID son un requerimiento muy normal a la hora de pensar en cambios de datos dentro de bases de datos mediante transacciones. No cumplirlos implica grandes conflictos que normalmente no son de fácil solución.
Sin embargo, la mayoría de los RDBMS mediante el lenguaje DCL (Lenguaje de control de datos, SQL) cumplen con estos requerimientos y nos obligan a cumplirlos.
Si quieres profundizar en el concepto ACID, te recomiendo leer el artículo de Wikipedia sobre ACID.
Atomicidad
La palabra se puede usar para referirse a agrupar, unificar. La atomización de la información consiste en tratarla como un conjunto. No cumplir la atomicidad de información sería como el ejemplo brindado cuando expliqué el modelo relacional: tener todos los datos regados por todas partes, dificultando su comprensión.
En el contexto de transacciones, cumplir el principio de atomicidad significa realizar esas transacciones u operaciones en forma de conjunto, «Todas o Ninguna».
O se ejecutan todas, o no se ejecuta ninguna.
Suponiendo que tenemos que actualizar diversas columnas de nuestra base de datos mediante una transacción y se produjera un error en una sola de ellas, nuestra base no debería sufrir ningún cambio. Por más que sea solo en una columna. En caso contrario, que la transacción completa se pudiera ejecutar sin errores, entonces sí, se ejecuta completa y se aplican los cambios.
Con esto queremos decir que si tienes un error en una línea de una transacción en SQL, no pasará nada. No vas a arruinar todo. Ahora, el problema surge cuando la transacción está mal diseñada, pero no contiene errores.
El clásico «Delete sin Where» (eliminar sin ninguna condición) es un meme. Y fíjate: si haces un DELETE sin WHERE pero surge algún error, no se ejecuta. ¡Y la atomicidad, propiedad de SQL y el RDBMS, te salva las papas!
Consistencia
La consistencia puede verse como «cualidad de estable, coherente». Y este requerimiento implica que cada modificación de nuestra base de datos debe asegurar la consistencia, llevando la base de datos de un estado «válido» a un estado «válido». Cualquier dato modificado, añadido o borrado debe ser de acuerdo a todas las reglas y requerimientos definidos para nuestra base de datos. (Esto doy mucha lata en mis posts)
Aislamiento (Isolation)
El aislamiento implica que cada transacción se debe ejecutar de forma secuencial (una tras otra) de tal manera que el estado intermedio de una transacción no sea visible por otra, y de esa manera se mantengan aisladas unas de otras. Lo cual podremos ver en profundidad más adelante a la hora de trabajar con transacciones en SQL. Pero básicamente hablamos de que no se superpongan solicitudes de cambios al mismo tiempo en el mismo dato.
Durabilidad
La durabilidad significa que una vez que se confirmó una transacción (COMMIT), quedará persistida, incluso ante eventos como pérdida de alimentación eléctrica, errores y caídas del sistema.
Por ejemplo, en las bases de datos relacionales, una vez que se ejecuta un grupo de sentencias SQL, los resultados tienen que almacenarse inmediatamente (incluso si la base de datos se cae inmediatamente después). Esto nos asegura que, si la transacción fue realizada, los cambios fueron guardados de forma persistente en la base de datos a pesar de posibles errores externos surgidos luego de aplicarlos.
«Todo o nada» – Si falla una parte, no se hace nada.
«De válido a válido» – Los datos siempre cumplen las reglas.
«Transacciones independientes» – No se mezclan entre sí.
«Persistencia garantizada» – Una vez guardado, no se pierde.
🎯 Conclusión: ¿Y todo esto para qué?
Puede que tanta teoría parezca abrumadora. «Normalización», «formas normales», «ACID», «12 reglas de Codd»… suenan a cosas de otro mundo. Pero déjame decirte algo: todo esto es la base de lo que hace que las aplicaciones funcionen.
Imagina que estás construyendo una aplicación con Flask para una tienda online. Tienes usuarios, pedidos, productos, direcciones de envío, facturas… Si no normalizas tu base de datos, el caos está garantizado.
❌ ¿Qué pasa si NO normalizas?
- 🔴 Datos duplicados: Dirección del cliente en 50 pedidos. Si se muda, actualiza 50 registros.
- 🔴 Inconsistencia: Un pedido con dirección vieja y otro con nueva. ¿Cuál es la correcta?
- 🔴 Rendimiento pobre: Tablas enormes con datos repetidos = consultas lentas.
- 🔴 Dificultad para mantener: Cambiar algo se convierte en una pesadilla.
✅ ¿Qué pasa si NORMALIZAS correctamente?
- 🟢 Datos limpios: Cada dato está en un solo lugar.
- 🟢 Actualizaciones fáciles: Cambias la dirección del cliente en un solo lugar y todos los pedidos la reflejan.
- 🟢 Consultas rápidas: Tablas bien estructuradas = consultas eficientes.
- 🟢 Escalabilidad: Tu base de datos puede crecer sin volverse un caos.
🐍 La normalización no es una teoría aburrida. Es la herramienta que te permite construir aplicaciones que no explotan cuando crecen.
En los próximos posts, vamos a poner toda esta teoría en práctica:
- 📊 Diseñaremos un Diagrama Entidad-Relación para una aplicación real.
- 🛠️ Crearemos la base de datos en MySQL.
- 🔗 Conectaremos todo con Flask para que tu aplicación web sea 100% funcional.
¡Te espero en el próximo post! 🐍🔥
📚 Serie de Bases de Datos – Sigue profundizando
Este es el cuarto post de la serie. Si quieres dominar las bases de datos desde cero hasta el nivel profesional, te recomiendo seguir estos posts en orden:
Conceptos básicos: datos, información, campos, registros y tablas.
Aprende las diferencias entre SQL y NoSQL, cuándo usar cada uno y sus características clave.
Profundiza en el modelo relacional: claves primarias, foráneas, relaciones y NULL.
(Este post) – Domina las reglas de normalización para diseñar bases de datos eficientes y sin redundancias.
🔥 ¿Y después? Una vez que domines estos conceptos, estarás listo para diseñar Diagramas Entidad-Relación, instalar MySQL en un servidor web y conectar tus aplicaciones Flask a bases de datos reales diseñadas por ti. ¡El cielo es el límite!
📖 Recursos externos para profundizar:
En estos posts de bases de datos hemos recorrido un largo camino: desde la introducción a los conceptos básicos, pasando por la diferencia entre modelos relacionales y no relacionales, hasta llegar a la normalización y las reglas ACID.
Si has llegado hasta aquí, ya tienes una base teórica sólida que muchos desarrolladores junior no tienen. Esto te permitirá no solo diseñar bases de datos eficientes, sino también entender por qué ciertas decisiones de diseño son mejores que otras.
En la actualidad, es muy común utilizar software automatizado para mejorar y facilitarnos casi todo el proceso, y estos abarcan y obligan a respetar la mayoría de estas reglas y conceptos. Pero como bien tú y yo sabemos, ningún software puede salvarnos de cometer errores humanos.
Así que si has comprendido medianamente y los tendrás presente en el futuro, es momento de comenzar a crear nuestra base de datos en la siguiente lección. 🙂
¡Ahora ve a contarle a tus amigos lo que has aprendido… NEEERD! 😂
📅 Última actualización: agosto 3, 2026