Mysql avanzado: especificaciones de diseño de bases de datos (1)

Especificaciones de diseño de bases de datos.

1. Por qué es necesario el diseño de bases de datos

El diseño de bases de datos consiste en organizar y gestionar datos de manera eficiente. Es un paso importante en la creación de un sistema de base de datos bien estructurado, eficiente y confiable. A continuación se presentan algunas razones por las que es necesario el diseño de bases de datos:

1. Organización de datos: el diseño de bases de datos nos ayuda a organizar los datos de acuerdo con una estructura determinada para que se puedan almacenar, acceder y administrar fácilmente. Esto mejora la disponibilidad y confiabilidad de los datos.
2. Coherencia de los datos: a través del diseño de la base de datos, podemos definir relaciones y restricciones entre los datos para garantizar la coherencia de los datos. Esto reduce la redundancia de datos y los errores y aumenta la precisión de los datos.
3. Seguridad de los datos: el diseño de la base de datos puede considerar la seguridad de los datos, incluido el control de acceso, el cifrado y las medidas de respaldo para proteger los datos contra el acceso no autorizado, el daño o la pérdida.
4. Rendimiento de los datos: un buen diseño de base de datos puede mejorar el rendimiento de la consulta y el procesamiento de datos. Al diseñar adecuadamente estructuras de tablas, índices y declaraciones de consulta, se puede acelerar la recuperación y el procesamiento de datos.
5. Escalabilidad de los datos: el diseño de la base de datos debe considerar la escalabilidad y las necesidades futuras. Al diseñar adecuadamente las estructuras y relaciones de las tablas, se pueden agregar fácilmente nuevas funciones y datos sin la necesidad de reconstruir toda la base de datos.

En resumen, el diseño de una base de datos tiene como objetivo mejorar la organización, la coherencia, la seguridad, el rendimiento y la escalabilidad de los datos. Es un paso crítico en la construcción de un sistema de base de datos eficiente y confiable.

2. Paradigma

2.1 Introducción al paradigma

En las bases de datos relacionales, los principios y reglas básicos para el diseño de tablas de datos se denominan paradigmas.

Puede entenderse como el nivel de un determinado estándar de diseño que debe cumplir la estructura de diseño de una tabla de datos. Para diseñar una base de datos relacional razonablemente estructurada, debe cumplir con un cierto paradigma.

2.2 ¿Qué incluye el paradigma?

Actualmente existen seis paradigmas comunes en las bases de datos relacionales, según el nivel de paradigma, de menor a mayor, son: primera forma normal (1NF), segunda forma normal (2NF), tercera forma normal (3NF), Buss-Code normal (BCNF), cuarta forma normal (4NF) y quinta forma normal (5NF, también conocida como forma normal perfecta).

2.3 Concepto de claves y atributos relacionados

Aquí hay dos tablas:

Tabla de jugadores (jugador): número de jugador | nombre | número de identificación | edad | número de equipo

Tabla del equipo (equipo): número del equipo | entrenador en jefe | ubicación del equipo

• Superclave: Para la mesa de jugadores, la superclave es cualquier combinación de número de jugador o número de identificación, como (número de jugador) (número de jugador, nombre) (número de identificación, edad), etc.

• Clave de candidato: Es la superclave más pequeña, para la mesa de jugadores, la clave de candidato es (número de jugador) o (número de cédula de identidad).

• Clave primaria: La elegimos nosotros mismos, es decir, elegimos una de las claves candidatas, como por ejemplo (número de jugador)

• Clave externa: número de equipo en la tabla de jugadores

• Atributos primarios y atributos no primarios: en la tabla de jugadores, el atributo principal es (número de jugador) (número de tarjeta de identificación), y otros atributos (nombre) (edad) (número de equipo) son atributos no primarios.

2.4 Primera forma normal (1.ª NF)

MySQL no tiene un concepto explícito de primera forma normal (1NF), porque 1NF es el principio básico de las bases de datos relacionales y se aplica a todos los sistemas de bases de datos relacionales, incluido MySQL.

La primera forma normal significa que cada columna de la base de datos es atómica, es decir, no se puede subdividir. Específicamente, cada columna debe contener solo un valor, no varios valores ni valores duplicados. Esto garantiza la coherencia y precisión de los datos.

En MySQL, podemos cumplir con los requisitos de la primera forma normal a través de los siguientes aspectos:

1. Cada tabla debe tener una clave principal que identifique de forma única cada registro.
2. Cada columna debe contener solo un valor y no debe almacenar múltiples valores ni valores duplicados. Si necesita almacenar varios valores, considere utilizar varias tablas y relaciones para representarlos.
3. Evite el uso de columnas duplicadas y, si tiene datos duplicados, considere dividirlos en una tabla separada.

2.5 Segunda forma normal (2.º NF)

En MySQL, podemos cumplir con los requisitos de la segunda forma normal a través de los siguientes aspectos:

1. Asegúrese de que cada tabla tenga una clave principal y que la clave principal sea un identificador único.
2. Establezca una relación directa entre las columnas de clave no principal y la clave principal, es decir, cada columna de clave no principal depende completamente de la clave principal. Si existe una dependencia parcial entre las columnas de clave no principal y la clave principal, estas columnas se pueden dividir en una tabla independiente para garantizar que cada columna de clave no principal tenga una relación directa con la clave principal.
3. Evite almacenar datos redundantes en tablas. Si hay datos duplicados, se pueden dividir en una tabla independiente y vincularla a la tabla principal mediante una relación.

2.6 Tercera Forma Normal (3.° NF)

Modelo de datos después de ajustarse a 3NF En términos sencillos, 2NF y 3NF generalmente se resumen en esta oración: "Cada atributo que no es clave depende de la clave, depende de la clave completa y no hay nada más que la clave".

3. Desnormalización

3.1 Descripción general

Normalización versus rendimiento

1. Para cumplir ciertos objetivos comerciales, el rendimiento de la base de datos es más importante que normalizar la base de datos.
2. Mientras se normalizan los datos, el rendimiento de la base de datos debe considerarse de manera integral.
3. Reduzca drásticamente el tiempo necesario para buscar información en una tabla determinada agregando campos adicionales
4. Inserte columnas calculadas en una tabla determinada para facilitar las consultas.

En MySQL, la desnormalización es una técnica de optimización utilizada para mejorar el rendimiento de las consultas de la base de datos. Viola el principio de normalización y reduce la complejidad de las consultas de bases de datos y mejora el rendimiento de las consultas al agregar datos redundantes o fusionar tablas.

La desnormalización se puede utilizar en las siguientes situaciones:

1. Realice con frecuencia operaciones de unión complejas: si las consultas en la base de datos a menudo requieren operaciones de unión entre varias tablas, y estas operaciones de unión causarán una degradación del rendimiento, puede considerar la desnormalización para reducir las operaciones de unión y mejorar el rendimiento de las consultas.
2. Operaciones de agregación frecuentes: si las consultas en la base de datos a menudo requieren operaciones de agregación (como SUM, AVG, COUNT, etc.) y estas operaciones calculan una gran cantidad de datos, puede considerar precalcular y almacenar los resultados de la agregación mediante la desnormalización para mejorar el rendimiento de la consulta.
3. Hay muchas más operaciones de lectura que de escritura: si los datos de la base de datos se utilizan principalmente para operaciones de lectura y menos operaciones de escritura, considere desnormalizar para mejorar el rendimiento de las operaciones de lectura. Al fusionar datos relacionados en una tabla, se pueden evitar uniones y operaciones de consulta frecuentes.

Cabe señalar que la desnormalización puede dar lugar a la existencia de datos redundantes y aumentar la complejidad y el riesgo de las actualizaciones de datos. Por lo tanto, al utilizar la desnormalización, es necesario sopesar la relación entre el rendimiento de la consulta y la coherencia de los datos, y garantizar que se mantengan la integridad y precisión de los datos.

En resumen, la desnormalización es una técnica utilizada para mejorar el rendimiento de las consultas en circunstancias específicas. Se requiere una cuidadosa consideración al utilizar la desnormalización y asegurarse de equilibrar las necesidades de rendimiento de las consultas y coherencia de los datos.

Cuando la información redundante sea valiosa o pueda mejorar en gran medida la eficiencia de las consultas, adoptaremos la optimización antiparadigma.

5. Cuarto paradigma

En las bases de datos relacionales, la Cuarta Forma Normal (4NF) es un principio de normalización adicional que se utiliza para eliminar dependencias multivaluadas no triviales. Sin embargo, en MySQL, no existe un concepto explícito de cuarto paradigma porque, como base de datos relacional, MySQL sigue los principios de normalización, incluido el cuarto paradigma.

La cuarta forma normal requiere la eliminación de dependencias multivaluadas no triviales sobre la base de satisfacer la tercera forma normal. Dependencia multivalor no trivial significa que cuando una columna de clave no principal de una tabla depende de parte de la clave candidata de la tabla en lugar de toda la clave candidata, existe una dependencia multivalor no trivial.

Elimine las dependencias de valores múltiples no triviales descomponiendo una tabla en dos o más tablas y conectándolas a través de una relación de asociación. Esto reduce la redundancia de datos y mejora la coherencia y precisión de los datos.

En MySQL, podemos minimizar las dependencias multivalor no triviales siguiendo los requisitos de la tercera forma normal. Asegúrese de que cada columna de clave no principal dependa directamente de la clave principal para evitar dependencias entre claves candidatas parciales.

En resumen, la cuarta forma normal es un principio de normalización adicional para bases de datos relacionales que se utiliza para eliminar dependencias multivaluadas no triviales. En MySQL, podemos maximizar los requisitos de la cuarta forma normal siguiendo los requisitos de la tercera forma normal para mejorar la coherencia y precisión de los datos.

Ejemplo 1: tabla de empleados (número de empleado, nombre del hijo del empleado, cursos electivos del empleado).

En esta tabla, el mismo empleado puede tener varios nombres secundarios de empleados. De manera similar, el mismo empleado también puede tener varios cursos electivos para empleados, es decir, aquí hay hechos de múltiples valores, lo que no se ajusta al cuarto paradigma.

Si desea cumplir con la cuarta forma normal, solo necesita dividir la tabla anterior en dos tablas para que tengan solo un hecho multivalor, por ejemplo: Tabla de Empleados 1 (número de empleado, nombre del hijo del empleado), Tabla de Empleados 2 (número de empleados, cursos electivos de empleados), ambas tablas tienen solo un hecho multivaluado, por lo que se ajustan a la cuarta forma normal.

6. Quinta forma normal, forma normal de clave de dominio

Además de la cuarta forma normal, también tenemos la quinta forma normal más avanzada (también llamada forma normal perfecta) y la forma normal de clave de dominio (DKNF).
Sobre la base de satisfacer la cuarta forma normal (4NF), se eliminan las dependencias de conexión no contenidas en las claves candidatas. Si cada dependencia de conexión en el esquema relacional R está implícita en una clave candidata de R , se dice que el esquema relacional se ajusta a la quinta forma normal.

La dependencia funcional es un caso especial de dependencia multivalor, y la dependencia multivalor es en realidad un caso especial de dependencia de conexión. Sin embargo, a diferencia de las dependencias funcionales y las dependencias multivalor, que pueden derivarse directamente de la semántica , las dependencias de unión se reflejan en las operaciones de unión relacional . Los modelos relacionales con dependencias de conexión aún pueden encontrar problemas como redundancia de datos y excepciones de inserción, modificación y eliminación.

El quinto paradigma se ocupa del problema de las conexiones sin pérdidas . Este paradigma básicamente no tiene sentido porque las conexiones sin pérdidas rara vez ocurren y son difíciles de detectar. El paradigma de clave de dominio intenta definir un paradigma último que considere todo tipo de dependencias y restricciones, pero tiene un valor práctico mínimo y solo existe en la investigación teórica.