¿Tres paradigmas principales de bases de datos?
El paradigma de diseño de la base de datos es la especificación que el diseño de la base de datos debe cumplir. Una base de datos que cumple con estas especificaciones es concisa y tiene una estructura clara al mismo tiempo, inserción, eliminación y actualización (insertar). ), la operación de eliminación (eliminar) y actualización (insertar) es anormal. Por el contrario, es un desastre, que no sólo crea problemas a los programadores de bases de datos, sino que también parece desagradable y puede almacenar una gran cantidad de información redundante innecesaria.
¿Es difícil entender los paradigmas de diseño? No, por supuesto que no podemos entender ni recordar un montón de fórmulas matemáticas que nos dan en los libros de texto universitarios. Muchos de nosotros no diseñamos bases de datos según ningún paradigma.
En esencia, los paradigmas del diseño se pueden explicar clara y claramente con palabras muy vívidas y concisas. Este artículo explicará los paradigmas de una manera popular y tomará una base de datos de foro simple que el autor una vez diseñó como ejemplo para explicar cómo aplicar estos paradigmas a proyectos reales.
Descripción de la norma
Primera forma normal (1NF): Los campos de la tabla de la base de datos tienen un único atributo y no se pueden subdividir. Este único atributo consta de tipos básicos, incluidos entero, real, de carácter, lógico, de fecha, etc.
Por ejemplo, la siguiente tabla de base de datos se ajusta a la primera forma normal:
Campo 1 Campo 2 Campo 3 Campo 4
Pero dicha tabla de base de datos no ajustarse 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, ningún tonto puede hacerlo. Es posible crear una base de datos que no se ajuste a la primera forma normal, porque estos DBMS no permiten subdividir una columna de la tabla de la base de datos en dos o más columnas. Por lo tanto, le resulta imposible diseñar una base de datos que no se ajuste a la primera forma normal del DBMS existente.
Segunda forma normal (2NF): no existe una dependencia funcional parcial de los campos no clave en ningún campo clave candidato en la tabla de la base de datos (la dependencia funcional parcial se refiere a la existencia de ciertos campos en las palabras clave combinadas que determinan campos no clave), es decir, todos los campos no clave dependen completamente de cualquier conjunto de palabras clave 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 las palabras clave son palabras clave combinadas (número de estudiante, nombre del curso), porque existe 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 existe la siguiente relación de determinación:
(nombre del curso) → (créditos)
(número de estudiante) → (nombre, edad)
Es decir, existe una situación en la que los campos de las palabras clave combinadas determinan las palabras no clave.
Dado 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 tomado por n estudiantes, "crédito" se repite n-1 veces; el mismo estudiante toma 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 En los créditos de una misma asignatura se presentarán situaciones diferentes.
(3) Excepción de inserción:
Supongamos que se va a abrir un nuevo curso y nadie lo ha realizado todavía. De esta manera, dado que no existe la palabra clave "ID de estudiante", el nombre del curso y los créditos no se pueden registrar en la base de datos.
(4) Excepción de eliminación:
Suponiendo que un grupo de estudiantes haya completado cursos optativos, estos registros optativos deben eliminarse de la tabla de la base de datos. Sin embargo, al mismo tiempo, también se eliminaron los títulos de los cursos y la información de créditos. Obviamente, esto también provocará excepciones de inserción.
Cambie la tabla de relación de selección de cursos SelectCourse a las siguientes tres tablas:
Estudiante: Estudiante (número de estudiante, nombre, edad
Curso: Curso (); nombre del curso, créditos);
Relación de selección de cursos: SeleccionarCurso (número de estudiante, nombre del curso, calificaciones).
Dicha tabla de base de datos cumple con la segunda forma normal, eliminando la redundancia de datos, las anomalías de actualización, las anomalías de inserción y las anomalías de eliminación.
Además, todas las tablas de bases de datos de una sola palabra clave se ajustan a la segunda forma normal, porque no hay posibilidad de palabras clave combinadas.
Tercera forma normal (3NF): basada en la segunda forma normal, la tabla de datos se ajusta a la tercera forma normal si no existe una dependencia funcional transitiva de los campos no clave en ningún campo clave candidato. La llamada dependencia de la función de transferencia significa que si existe una relación de decisión 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 las siguientes dependencias:
Campo clave → campo no clave x → campo no clave y
Supongamos que el estudiante La tabla de relaciones es Estudiante (número de estudiante, nombre, edad, universidad, ubicación de la universidad, número de teléfono de la universidad), la palabra clave es la palabra clave única "número de estudiante", porque existe la siguiente relación de determinación:
(estudiante número) → (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 de determinación:
(Número de estudiante) → (Universidad) → (Ubicación de la universidad, número de teléfono de la universidad)
Es decir, existe una función de transferencia que depende de los campos no clave "ubicación de la universidad" y "número de teléfono de la universidad" en el campo clave "estudiante". número".
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,); ubicación, número de teléfono).
Dicha tabla de base de datos cumple con la tercera forma normal, eliminando la redundancia de datos, las anomalías de actualización, las anomalías de inserción y las anomalías de eliminación.
Forma normal de Bois-Code (BCNF): basada en la tercera forma normal, si no hay una dependencia funcional transitiva de ningún campo en ningún campo clave candidato en la tabla de la base de datos, se ajusta a la tercera forma normal. .
Supongamos que la tabla de relaciones de administración del almacén es StorehouseManage (ID de almacén, ID de artículo de almacenamiento, ID de administrador, cantidad) y hay un administrador que solo trabaja en un almacén y puede almacenar varios artículos; La siguiente relación de decisión existe 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) → (Almacén ID, cantidad)
Entonces, (ID de almacén, ID de artículo de almacenamiento) y (ID de administrador, ID de artículo de almacenamiento) son palabras clave candidatas para StorehouseManage. El único campo que no es clave en la tabla es cantidad. es consistente con la tercera forma normal. Sin embargo, debido a la siguiente relación de decisión:
(ID de almacén) → (ID de administrador)
(ID de administrador) → (ID de almacén)
Es decir Hay casos en los 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, toda la información de "ID del artículo almacenado" y "cantidad" se elimina al mismo tiempo. ," También se ha eliminado la información "ID de almacén" e "ID de administrador".
(2) Excepción de inserción:
Cuando el almacén no almacena ningún artículo, no se puede asignar un administrador al almacén.
(3) Excepción de actualización:
Si el almacén cambia de administrador, se deben modificar los ID de administrador de todas las filas de la tabla.
Descomponga la tabla de relaciones de gestión de almacén en dos tablas de relaciones:
Gestión de almacén: StorehouseManage(ID de almacén, ID de administrador);
Almacén: Almacén( ID de almacén , ID del artículo almacenado, cantidad).
Dicha tabla de base de datos se ajusta al paradigma BCNF, eliminando excepciones de eliminación, excepciones de inserción y excepciones de actualización.
Aplicación paradigma
Vamos a crear gradualmente una base de datos del foro con la siguiente información:
(1) Usuario: nombre de usuario, correo electrónico, página de inicio, número de teléfono, 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 exista en tablas:
Nombre de usuario correo electrónico página de inicio 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
Esta tabla de 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 base de datos. la única clave El campo nombre de usuario tampoco determina 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 página de inicio teléfono dirección de contacto ID de publicación título de publicación contenido de publicación ID de respuesta título de respuesta contenido de respuesta
De esta manera, las palabras clave en la tabla de datos (nombre de usuario, ID de publicación, ID de respuesta) 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 existe la siguiente relación de decisión:
(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 la publicación, contenido de la publicación)
(respuesta ID) → (título de respuesta, contenido de respuesta)
p>
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 de funcionamiento.
Descomponemos la tabla de la base de datos en (los subrayados son palabras clave):
(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 la respuesta, título, contenido
(4) Publicación: nombre de usuario, ID de la publicación
(5) Respuesta: ID de publicación, ID de respuesta
Este diseño cumple con los requisitos del primer, segundo y tercer paradigma y el paradigma BCNF, pero ¿cuál es el mejor?
No necesariamente.
Se puede ver a partir de la observación que la relación entre "nombre de usuario" e "ID de publicación" en el elemento 4 "publicación" es 1:N, por lo que podemos fusionar "publicación" en el elemento 2 " "Información de publicación "; el "ID de publicación" y el "ID de respuesta" en el quinto elemento "Respuesta" también están en una relación 1:N, por lo que podemos fusionar "Responder" 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, publicación. ID, título, contenido
(3) Información de respuesta: ID de publicación, ID de respuesta, título, contenido
La tabla 1 de la base de datos obviamente cumple con los requisitos de todos los paradigmas;
En la tabla 2 de la base de datos, existe una dependencia funcional parcial de los campos no clave "título" y "contenido" del campo clave "ID de publicación", es decir, no cumple con los requisitos de la segunda forma normal, pero este diseño no conducirá a redundancia de datos ni excepción de operación;
La Tabla 3 de la base de datos también tiene una dependencia funcional parcial del campo clave "ID de respuesta" de los campos no clave "Título" y "Contenido", que no cumple con los requisitos de la segunda forma normal, pero similar a la tabla 2 de la base de datos, este diseño no provocará redundancia de datos ni anomalías operativas.
De esto se puede ver que no es necesario cumplir por la fuerza los requisitos del paradigma. Para la relación 1:N, cuando un lado de 1 se fusiona con el lado N, el lado N no. ya no satisface el Es un segundo paradigma, ¡pero este diseño es en realidad mejor!
Para la relación M:N, un lado de M o un lado de N no se pueden fusionar con el otro lado. Esto conducirá al incumplimiento de los requisitos del paradigma, así como a operaciones y datos anormales. redundancia.
Para una relación 1:1, podemos fusionar el 1 de la izquierda o el 1 de la derecha en el otro lado. El diseño no cumple con los requisitos del paradigma, pero no conduce a. funcionamiento anormal y redundancia de datos.