¿Te gustaría aprender Análisis y Diseño de Bases de datos con MySQL desde cero?
Tenemos los cursos que necesitas.¡Haz clic aquí!
Normalización de la base de datos
Una vez que tengas un diseño preliminar para tu base de datos, puedes aplicar reglas de normalización para asegurarte de que las tablas estén estructuradas correctamente. Piensa en estas reglas como los estándares de la industria.
Dicho esto, no todas las bases de datos son buenas candidatas para la normalización. Generalmente, las bases de datos de procesamiento de transacciones en línea (OLTP), en las que los usuarios se encargan de la creación, lectura, actualización y eliminación de los registros, deberían estar normalizadas.
Las bases de datos de procesamiento analítico en línea (OLAP) que favorecen el análisis y la generación de informes funcionarían mejor con un grado de desnormalización, ya que el énfasis está en la velocidad de cálculo. Estas incluyen aplicaciones de soporte de decisiones en las que los datos se deben analizar rápidamente, pero no deben modificarse.
Cada forma, o nivel de normalización, incluye las reglas asociadas a las formas inferiores.
Aquí puedes ver la primera parte de este artículo: https://url.miapp.io/GiYRc
La primera forma normal
La primera forma normal (abreviada como «1FN») especifica que cada celda de la tabla puede tener un solo valor, nunca una lista de valores. Por lo tanto, una tabla como esta no cumple con los requisitos:
| ID del producto | Color | Precio |
|---|---|---|
| 1 | marrón, amarillo | $15 |
| 2 | rojo, verde | $13 |
| 3 | azul, naranja | $11 |
Quizás pienses que la mejor solución sea dividir los datos en columnas adicionales, pero eso también rompería las reglas: una tabla con grupos de atributos repetidos o estrechamente relacionados entre sí no cumple con la primera forma normal. Por ejemplo, la tabla a continuación no cumple con los requisitos:
En cambio, divide los datos en múltiples tablas o registros hasta que cada celda contenga solo un valor y no halla columnas adicionales. En este punto, se dice que los datos son «atómicos», es decir que se dividen en partes útiles lo más pequeñas posibles. Para la tabla anterior, podrías crear una tabla adicional llamada «Datos de ventas», que haría coincidir productos específicos con ventas. Así, «Ventas» tendría una relación 1:M con «Datos de ventas».
La segunda forma normal
La segunda forma normal (2NF) establece que todos los atributos deben ser totalmente dependientes de toda la clave primaria. Eso significa que cada atributo debería depender directamente de la clave primaria, en lugar de indirectamente a través de algún otro atributo.
Por ejemplo, se considera que el atributo «edad» que depende de «fecha de nacimiento», que a su vez depende de «ID de estudiante» tiene una dependencia funcional parcial; y una tabla que contenga estos atributos no cumpliría con la segunda forma normal.
Además, una tabla con una clave primaria compuesta de múltiples campos viola la segunda forma normal si uno o más de los otros campos no dependen de cada parte de la clave.
Por lo tanto, una tabla con estos campos no respetaría la segunda forma normal porque el atributo «Nombre del producto» depende del ID del producto, pero no del número de pedido:
- Número de pedido (clave primaria)
- ID de producto (clave primaria)
- Nombre del producto
La tercera forma normal
La tercera forma normal (3NF) agrega a estas reglas el requisito de que cada columna que no sea de clave sea independiente de las demás columnas. Si modificar el valor en una columna que no sea de clave hace que cambie otro valor, entonces esa tabla no cumple con los requisitos de la tercera forma normal.
Esto evita que almacenes cualquier dato derivado en la tabla, tal como la columna «Impuestos» a continuación, que depende directamente del precio final del pedido:
| Pedido | Precio | Impuestos |
| 14325 | $40.99 | $2.05 |
| 14326 | $13.73 | $.69 |
| 14327 | $24.15 | $1.21 |
Se han propuesto formas adicionales de normalización, incluidas la forma normal de Boyce-Codd, la cuarta, quinta y sexta forma normal, y la forma normal de dominio/clave, pero las primeras tres son las más comunes.
Si bien estas formas explican las buenas prácticas que se deben seguir generalmente, el grado de normalización depende del contexto de la base de datos.
Aquí puedes ver la primera parte de este artículo: https://url.miapp.io/GiYRc
Datos multidimensionales
Algunos usuarios quizás deseen acceder a múltiples dimensiones de un único tipo de dato, especialmente en las bases de datos OLAP. Por ejemplo, quizás deseen conocer las ventas por cliente, estado y mes. En esta situación, lo mejor es crear una tabla de datos central que actúe de referencia para las otras tablas de cliente, estado y mes, de este modo:
Reglas de integridad de datos
También deberías configurar tu base de datos para validar los datos en función de las reglas adecuadas. Muchos sistemas de gestión de base de datos, como Microsoft Access, ejecutan automáticamente algunas de estas reglas.
La regla de integridad de la entidad afirma que la clave primaria nunca puede ser NULL. Si la clave está compuesta por múltiples columnas, ninguna de ellas puede ser NULL. De lo contrario, podría no identificar de forma única al registro.
La regla de la integridad referencial requiere que cada clave externa que aparece en una tabla se corresponda con una clave primaria de la tabla a la que hace referencia. Si la clave primaria cambia o se elimina, esos cambios deberán implementarse donde sea que esté la referencia a esa clave en toda la base de datos.
Las reglas de la integridad lógica de negocios garantizan que los datos se adecúen a determinados parámetros lógicos. Por ejemplo, el horario de una cita deberá fijarse dentro de las horas laborales normales.
Agregar índices y visualizaciones
Un índice es, en esencia, una copia ordenada de una o más columnas, con valores dispuestos de forma ascendente o descendente. Agregar un índice permite a los usuarios encontrar los registros más rápidamente. En lugar de reordenar cada consulta, el sistema puede acceder a los registros en el orden que especifica el índice.
Si bien los índices aceleran la recuperación de datos, pueden enlentecer la inserción, actualización o eliminación, ya que el índice debe rediseñarse cada vez que se modifica un registro.
Una visualización es simplemente una consulta almacenada sobre los datos. Puede unir datos de múltiples tablas de manera útil o bien mostrar parte de una tabla.
Propiedades extendidas
Una vez que hayas finalizado la disposición básica, puedes refinar la base de datos con propiedades extendidas, como el texto instructivo, la máscara de entrada y las reglas de formato que se aplican a un esquema, visualización o columna determinada. La ventaja es que, como estas reglas están almacenadas en la misma base de datos, la presentación de los datos será consistente en todos los programas que accedan a los mismos.
SQL y UML
El lenguaje unificado de modelado (UML) es otra forma visual de expresar sistemas complejos creados en un lenguaje orientado a objetos. Muchos de los conceptos mencionados en esta guía se conocen en UML con distintos nombres. Por ejemplo, una entidad se llama «clase» en UML.
Hoy en día no se usa el UML con tanta frecuencia como antes. En la actualidad, se emplea en entornos académicos y en las comunicaciones entre diseñadores de software y sus clientes.
Sistemas de gestión de bases de datos
Muchas de las elecciones de diseño que tomarás dependen del sistema de gestión de base de datos que elijas. Algunos de los sistemas más comunes incluyen:
- Oracle DB
- MySQL
- Microsoft SQL Server
- PostgreSQL
- IBM DB2
Cuando puedas elegir, selecciona un sistema de gestión de base de datos en función del costo, los sistemas operativos, las funciones y más.
Te esperamos en los próximos artículos en donde hablaremos más acerca de estos temas que hoy en día son de importancia e interés en el mundo de la tecnología.
¿Te gustaría aprender Análisis y Diseño de Bases de datos con MySQL desde cero?
Tenemos los cursos que necesitas.¡Haz clic aquí!
