¿Son difíciles de entender los paradigmas de diseño? No, nos dieron un montón de fórmulas matemáticas en nuestros libros de texto universitarios. Por supuesto, no podemos entenderlos ni recordarlos. Muchos de nosotros simplemente no diseñamos bases de datos según el paradigma.
En esencia, los paradigmas de diseño se pueden expresar y comprender claramente en un lenguaje muy vívido y conciso. Este artículo explicará los paradigmas de una manera popular y tomará una base de datos de foro simple diseñada por el autor como ejemplo para ilustrar cómo aplicar estos paradigmas a proyectos reales.
Explicación de la forma normal
Primera forma normal (1NF): Los campos de la tabla de la base de datos son atributos únicos y no se pueden subdividir. Esta propiedad única consta de tipos básicos que incluyen números enteros, reales, caracteres, lógicos, fechas y más.
Por ejemplo, la siguiente tabla de base de datos se ajusta a la primera forma normal:
Campo 1 Campo 2 Campo 3 Campo 4
Y dicha tabla de base de datos no se ajustan a la primera forma normal:
Campo 1 Campo 2 Campo 3 Campo 4 Campo 3.1 Campo 3.2
Obviamente, en cualquier sistema de gestión de bases de datos relacionales (DBMS) actual, es imposible Es una tontería hacer un campo que no cumple con la forma normal de una base de datos porque estos DBMS no permiten dividir una columna de una tabla de base de datos en dos o más columnas. Por lo tanto, no se puede diseñar una base de datos en un DBMS existente que no se ajuste a la primera forma normal.
Segunda forma normal (2NF): los campos no clave no tienen una dependencia funcional parcial de ningún campo clave candidato en la tabla de la base de datos (la dependencia funcional parcial significa que ciertos campos en la palabra clave combinada determinan los campos no clave) , es decir, todos los campos que no son clave dependen completamente de cualquier conjunto de claves candidatas.
Supongamos que la tabla de relaciones de selección de cursos es SelectCourse (número de estudiante, nombre, edad, nombre del curso, calificaciones, créditos) y la palabra clave es una palabra clave combinada (número de estudiante, nombre del curso), porque hay la siguiente relación de decisión:
(Número de estudiante, nombre del curso)→(Nombre, edad, calificaciones, créditos)
Esta tabla de base de datos no satisface la segunda forma normal porque existen las siguientes relaciones decisivas:
(nombre del curso)→(créditos)
(número de estudiante)→(nombre, edad)
Es decir, hay campos en la palabra clave combinada para determinar la condición sin palabra clave.
Debido a que no cumple con 2NF, esta tabla de relación de selección de cursos tendrá los siguientes problemas:
(1) Redundancia de datos:
El mismo curso es utilizado por n estudiantes Seleccione, "crédito" se repite n-1 veces; el mismo estudiante ha tomado M cursos y su nombre y edad se repiten m-1 veces;
(2) Excepción de actualización:
Si se ajustan los créditos de un determinado curso, se deben actualizar los valores de "crédito" de todas las filas en la tabla de datos, de lo contrario el Aparecerán diferentes créditos del mismo curso.
(3) Insertar excepción:
Supongamos que se va a abrir un nuevo curso y nadie lo ha aprendido todavía. De esta manera, dado que no existe la palabra clave "número de estudiante", el nombre del curso y los créditos no se pueden registrar en la base de datos.
(4) Eliminar excepciones:
Supongamos que un grupo de estudiantes ha completado cursos optativos y estos registros optativos deben eliminarse de la tabla de la base de datos. Pero al mismo tiempo, también se eliminaron el nombre del curso y la información de crédito. Obviamente, esto también provocará excepciones de inserción.
Cambie la tabla de relaciones de selección de cursos a las siguientes tres tablas:
Estudiante: estudiante (número de estudiante, nombre, edad);
Curso: curso (curso nombre, créditos);
Relación de selección de curso: SeleccionarCurso (número de estudiante, nombre del curso, calificación).
Dicha tabla de base de datos cumple con el segundo paradigma, eliminando la redundancia de datos, las excepciones de actualización, las excepciones de inserción y las excepciones de eliminación.
Además, todas las tablas de una base de datos de una sola palabra clave están en segunda forma normal, ya que es imposible tener palabras clave combinadas.
Tercera forma normal (3NF): basada en la segunda forma normal, si los campos no clave no tienen dependencia funcional transitiva de ningún campo clave candidato, la tabla de datos se ajusta a la tercera forma normal. La llamada dependencia de la función de transferencia significa que si existe una relación decisiva de "A → B → C", entonces la función de transferencia de C depende de A. Por lo tanto, una tabla de base de datos que satisface la tercera forma normal no debe tener lo siguiente dependencias:
Campo clave → Campo no clave x → Campo no clave Y
Supongamos que la tabla de relaciones de estudiantes son estudiantes (número de estudiante, nombre, edad, universidad, ubicación de la universidad). , número de teléfono de la universidad), palabra clave Es una palabra clave única "número de estudiante" porque existe la siguiente relación de determinación:
(número de estudiante) → (nombre, edad, universidad, ubicación de la universidad, número de teléfono de la universidad) Esta base de datos se ajusta a 2NF, pero no a 3NF porque existe la siguiente relación decisiva:
(número de estudiante) → (universidad) → (ubicación de la universidad, número de teléfono de la universidad)
<. p>Es decir, los campos no clave "ubicación de la universidad" y "número de teléfono de la universidad" Función de transferencia que se basa en el campo clave "número de estudiante".También contará con redundancia de datos, anomalías de actualización, anomalías de inserción y anomalías de eliminación, que los lectores podrán analizar por sí mismos.
Divida la tabla de relación de estudiantes en las siguientes dos tablas:
Estudiante: (número de estudiante, nombre, edad, universidad);
Universidad: (universidad, universidad); ubicación, número de teléfono).
Dicha tabla de base de datos cumple con el tercer paradigma, eliminando la redundancia de datos, las excepciones de actualización, las excepciones de inserción y las excepciones de eliminación.
Forma normal de Bowes-Cod (BCNF): basada en la tercera forma normal, si algún campo no tiene dependencia funcional transitiva de ningún campo clave candidato, la tabla de la base de datos se ajusta a la tercera forma normal.
Supongamos que la tabla de relaciones de gestión del almacén es StorehouseManage (ID de almacén, ID de artículo de almacenamiento, ID de administrador, cantidad). Hay un administrador que solo trabaja en un almacén y puede almacenar varios artículos. Existen las siguientes relaciones decisivas en esta tabla de base de datos:
(ID de almacén, ID de artículo de almacenamiento) →(ID de administrador, cantidad)
(ID de administrador, ID de artículo de almacenamiento) →( ID de almacén, cantidad)
Por lo tanto, (ID de almacén, ID de artículo de almacenamiento) y (ID de administrador, ID de artículo de almacenamiento) son claves candidatas para StorehouseManage. El único campo que no es clave en la tabla es cantidad, que. Se ajusta a los Tres Paradigmas. Sin embargo, debido a la siguiente relación decisiva:
(ID de almacén) →(ID de administrador)
(ID de administrador) →(ID de almacén)
Es decir Hay situaciones en las que el campo clave determina el campo clave, por lo que no se ajusta al paradigma BCNF. Tendrá las siguientes excepciones:
(1) Excepción de eliminación:
Cuando se vacía el almacén, se elimina toda la información de "ID del artículo de almacenamiento" y "cantidad", y al final Al mismo tiempo, también se elimina la información de "ID de almacén" y "ID de administrador".
(2) Insertar excepción:
No se puede asignar un administrador a un repositorio cuando el repositorio no almacena nada.
(3) Excepción de actualización:
Si el almacén tiene un nuevo administrador, se modificarán los ID de administrador de todas las filas de la tabla.
La tabla de relaciones de gestión de almacén se descompone en dos tablas de relaciones:
Gestión de almacén: StorehouseManage (ID de almacén, ID de administrador
Almacén: almacén (Almacén); identificación, identificación del artículo almacenado, cantidad).
Dicha tabla de base de datos cumple con el paradigma BCNF y elimina las excepciones de eliminación, inserción y actualización.
Aplicación de ejemplo
Obtengamos paso a paso una base de datos del foro que incluye la siguiente información:
(1) Usuario: nombre de usuario, correo electrónico, página de inicio, teléfono número y dirección de contacto.
(2) Publicación: título de la publicación, contenido de la publicación, título de la respuesta, contenido de la respuesta.
Por primera vez, diseñamos la base de datos para que solo tuviera tablas:
Nombre de usuario, página de inicio de correo electrónico, dirección de contacto telefónico, título de la publicación, contenido de la publicación, título de la respuesta y contenido de la respuesta. .
La tabla de la base de datos se ajusta a la primera forma normal, pero ningún conjunto de palabras clave candidatas puede determinar la fila completa de la tabla de la base de datos, y el nombre de usuario del campo de palabra clave único no puede determinar completamente la tupla completa. Necesitamos agregar los campos "ID de publicación" e "ID de respuesta", es decir, modificar la tabla para:
Nombre de usuario Correo electrónico Teléfono de casa Dirección de contacto ID de publicación Título de la publicación Contenido de la publicación ID de respuesta Título de respuesta Contenido de respuesta
De esta manera, las palabras clave (nombre de usuario, ID de publicación, ID de respuesta) en la tabla de datos pueden determinar toda la fila:
(nombre de usuario, ID de publicación, ID de respuesta) → (Correo electrónico, página de inicio, número de teléfono, dirección de contacto, título de la publicación, contenido de la publicación, título de la respuesta, contenido de la respuesta)
Sin embargo, dicho diseño no se ajusta al segundo paradigma porque existen las siguientes relaciones decisivas:
(Nombre de usuario)→(correo electrónico, página de inicio, número de teléfono, dirección de contacto)
(ID de publicación) →(Título de publicación, Contenido de publicación)
(Responder ID) → (título de la respuesta, contenido de la respuesta)
Es decir, algunas funciones de los campos no clave dependen de los campos clave candidatos. Obviamente, este diseño generará mucha redundancia de datos y anomalías operativas.
Descomponemos la tabla de la base de datos en (palabras clave subrayadas):
(1) Información del usuario: nombre de usuario, correo electrónico, página de inicio, número de teléfono, dirección de contacto.
(2) Información de la publicación: ID de la publicación, título, contenido.
(3) Información de respuesta: ID de respuesta, título, contenido.
(4) Publicación: nombre de usuario, ID de publicación
(5) Respuesta: ID de publicación, ID de respuesta
Este diseño cumple con 1, 2 y 3 forma normal y los requisitos de la forma normal BCNF, pero ¿es este diseño el mejor?
No necesariamente.
Se observa que la relación entre "nombre de usuario" e "ID de publicación" en el elemento 4 es 1: n, por lo que podemos fusionar "publicación" en el elemento 2 "información de publicación" La relación; entre "ID de publicación" e "ID de respuesta" en el elemento "respuesta" también es 1: n, por lo que podemos fusionar "respuesta" en el tercer elemento "información de respuesta". Esto puede reducir la redundancia de datos hasta cierto punto. El nuevo diseño es: (1) Información del usuario: nombre de usuario, correo electrónico, página de inicio, número de teléfono, dirección de contacto.
(2) Información de la publicación: nombre de usuario, ID de la publicación, título, contenido.
(3) Información de respuesta: ID de publicación, ID de respuesta, título, contenido.
La tabla de base de datos 1 obviamente cumple con los requisitos de todos los paradigmas.
El campo clave "ID de publicación" en la tabla de base de datos 2 tiene algunos campos no clave "título" y "contenido" funcionales; La dependencia no cumple con los requisitos del segundo paradigma, pero este diseño no conducirá a redundancia de datos ni anomalías operativas.
En la tabla 3 de la base de datos, también existen algunas dependencias funcionales de los campos no clave "título" y "contenido" en el campo clave "ID de respuesta", que no cumplen con los requisitos de la segunda normalidad. forma, pero son similares a la tabla 2 de la base de datos, este diseño no causará redundancia de datos ni anomalías operativas.
Se puede observar que no necesariamente tiene que cumplir con los requisitos de forma formal. Para la relación de 1:n, cuando un lado de 1 se fusiona con el otro lado de N, el otro lado de N ya no satisface la segunda forma normal, ¡pero este diseño es mejor!
Para la relación M:N, un lado de M o un lado de N no se pueden fusionar con el otro lado, lo que conducirá al incumplimiento de los requisitos del paradigma, así como a anomalías operativas. y redundancia de datos.
Para una relación 1:1, podemos fusionar el 1 de la izquierda o el 1 de la derecha con el otro lado. El diseño no cumplirá con los requisitos del paradigma pero no dará lugar a operaciones anormales ni redundancia de datos.