Solicitar información del paradigma de la base de datos
Puede que sea un poco largo y complicado. Espero que puedas leerlo con atención. ¡Creo que tendrás una comprensión más profunda del paradigma!
Un paradigma de diseño (paradigma, paradigma de diseño de bases de datos, paradigma de diseño de bases de datos) es una colección de patrones relacionales que se ajustan a un cierto nivel. Se deben seguir ciertas reglas al construir una base de datos. En una base de datos relacional, esta regla es la forma normal. Las relaciones en bases de datos relacionales deben cumplir ciertos requisitos, es decir, satisfacer diferentes paradigmas. Actualmente existen seis paradigmas en bases de datos relacionales: primera forma normal (1NF), segunda forma normal (2NF), tercera forma normal (3NF), cuarta forma normal (4NF), quinta forma normal (5NF) y sexta forma normal (6NF). . La forma normal que cumple con los requisitos mínimos es la primera forma normal (1NF). La que además cumple con más requisitos según la primera forma normal se llama segunda forma normal (2NF), y así sucesivamente para las otras formas normales. En términos generales, la base de datos solo necesita cumplir con la tercera forma normal (3NF). A continuación presentamos ejemplos de primera forma normal (1NF), segunda forma normal (2NF) y tercera forma normal (3NF).
En el proceso de creación de una base de datos, la normalización es el proceso de convertirla en tablas. Este método puede hacer que los resultados obtenidos de la base de datos sean más específicos. Esto puede crear datos duplicados en la base de datos, lo que resultará en la creación de tablas redundantes. La normalización es el proceso de refinamiento que sigue al trabajo inicial de identificar elementos de datos y relaciones en una base de datos, y definir las tablas y elementos requeridos en cada tabla.
El siguiente es un ejemplo de normalización Artículo comprado por el Cliente Precio de compra Camisa Thomas $40 Tenis María $35 Camisa Evelyn $40 Pantalón Pájaro $25
Si se utiliza la tabla anterior para guardar el precio de el artículo, y si deseas eliminar uno de los clientes, debes eliminar un precio al mismo tiempo. La normalización es para solucionar este problema. Puedes transformar esta tabla en dos tablas, una para almacenar información sobre cada cliente y los artículos que compró, y la otra para almacenar información sobre cada producto y su precio. De esta forma, agregar o eliminar operaciones. a una tabla no afectará a la otra tabla.
Introducción a varios paradigmas de diseño de bases de datos relacionales
1 Primera forma normal (1NF)
En cualquier base de datos relacional, la primera forma normal (1NF) es For Según los requisitos básicos del modelo relacional, una base de datos que no cumple con la primera forma normal (1NF) no es una base de datos relacional.
La llamada primera forma normal (1NF) significa que cada columna de la tabla de la base de datos es un elemento de datos básico indivisible. No puede haber varios valores en la misma columna, es decir, un atributo en. la entidad no puede tener múltiples valores. Los valores o atributos no pueden tener duplicados. Si aparecen atributos duplicados, es posible que necesite definir una nueva entidad. La nueva entidad se compone de atributos duplicados. Existe una relación de uno a muchos entre la nueva entidad y la entidad original. En la primera forma normal (1NF), cada fila de la tabla contiene información sobre una sola instancia. Por ejemplo, para la tabla de información de empleados en la Figura 3-2, la información de los empleados no se puede mostrar en una columna, ni se pueden mostrar dos o más columnas en una columna; cada fila de la tabla de información de empleados solo representa una información de empleado. La información de un empleado solo aparece una vez en la tabla. En resumen, la primera forma normal es una columna sin duplicados.
2 Segunda Forma Normal (2NF)
La segunda forma normal (2NF) se establece en base a la primera forma normal (1NF), es decir, satisface la segunda forma normal forma (2NF) Primero debe satisfacer la primera forma normal (1NF). La segunda forma normal (2NF) requiere que cada instancia o fila en una tabla de base de datos sea distinguible de forma única. Para lograr la diferenciación, normalmente es necesario agregar una columna a la tabla para almacenar el identificador único de cada instancia. Como se muestra en la Figura 3-2, se agrega una columna de número de empleado (emp_id) a la tabla de información de empleado. Debido a que el número de empleado de cada empleado es único, cada empleado se puede distinguir de manera única. Esta columna de atributos únicos se llama clave primaria o clave primaria o clave primaria.
La Segunda Forma Normal (2NF) requiere que los atributos de una entidad dependan completamente de la clave primaria. La llamada dependencia completa significa que no puede haber un atributo que solo dependa de parte de la clave primaria. Si existe, entonces este atributo y esta parte de la clave primaria deben separarse para formar una nueva entidad. uno a muchos con la entidad original.
Para lograr la diferenciación, normalmente es necesario agregar una columna a la tabla para almacenar el identificador único de cada instancia. En resumen, la segunda forma normal significa que los atributos no primarios no dependen parcialmente de la clave primaria.
3 Tercera forma normal (3NF)
Para satisfacer la tercera forma normal (3NF), primero debes satisfacer la segunda forma normal (2NF). En resumen, la tercera forma normal (3NF) requiere que una tabla de base de datos no contenga información de clave no primaria que ya esté contenida en otras tablas. Por ejemplo, hay una tabla de información de departamento, en la que cada departamento tiene el número de departamento (dept_id), el nombre del departamento, el perfil del departamento y otra información. Luego, una vez que los números de departamento aparecen en la tabla de información de los empleados en la Figura 3-2, los nombres de los departamentos, los perfiles de los departamentos y otra información relacionada con los departamentos no se pueden agregar a la tabla de información de los empleados. Si la tabla de información del departamento no existe, debe construirse de acuerdo con la tercera forma normal (3NF); de lo contrario, habrá mucha redundancia de datos. En resumen, la tercera forma normal significa que los atributos no dependen de otros atributos no primarios.
Análisis de ejemplos de aplicación de los tres paradigmas del diseño de bases de datos
El paradigma de diseño de la base de datos es la especificación que debe cumplir el diseño de la base de datos. Una base de datos que cumpla con estas especificaciones es concisa. y tiene una estructura clara. Al mismo tiempo, no se producirán excepciones para las operaciones de inserción, eliminación y actualización. 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 del paradigma
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 En 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 actual ( DBMS), es imposible que un tonto cree una base de datos que no se ajuste a la primera forma normal, porque estos DBMS no le permiten dividir 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 al primer paradigma de un 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.
Suponga 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 existe la siguiente relación de determinación:
(nombre del curso) → (créditos)
(número de estudiante) → (nombre, edad)
Es decir, hay una situación donde 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; 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 "número 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 del curso: SelectCourse (número de estudiante, nombre del curso, calificaciones).
Una tabla de base de datos de este tipo 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
Suponga 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 se ajusta 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 dependencia de la función de transferencia entre los campos no clave "ubicación de la universidad" y "número de teléfono de la universidad" 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); , ubicación, 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 del código Boyce (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. .
Suponga 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 determinació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)
Por lo tanto, (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. lo cual 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 de paradigma
Construyamos gradualmente una base de datos del foro, que tiene 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 tenga 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 la 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 la publicación Contenido de la publicación ID de respuesta Título de la respuesta Responder contenido
De esta manera, las palabras clave (nombre de usuario, ID de publicación, ID de respuesta) en la tabla de datos pueden determinar la fila completa:
(nombre de usuario, ID de publicación, ID de respuesta) → (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)
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 publicación, contenido de publicación)
( ID de respuesta) → (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á una gran cantidad de datos. redundancia y anomalías de operación.
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.
La observación muestra que existe una relación 1:N entre el "nombre de usuario" y el "ID de publicación" en el cuarto elemento "Publicar", por lo que podemos fusionar "Publicar" en el "segundo elemento" "Publicar". Informació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 publicaciones: nombre de usuario, ID de publicación, 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 paradigmas;
En la tabla 2 de la base de datos, existe una dependencia funcional parcial de los campos no clave "título" y "contenido" en el campo clave "ID de publicación", es decir, no cumple con los requisitos. requisitos de la segunda forma normal, pero este diseño no provocará redundancia de datos ni anomalías operativas
También existen dependencias funcionales parciales entre los campos no clave "título" y "contenido" en; el campo clave "ID de respuesta" en la tabla 3 de la base de datos, 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.
Conclusión
Un diseño de base de datos que cumpla con los requisitos del paradigma esté claramente estructurado y evite la redundancia de datos y anomalías operativas. Esto no significa que un diseño que no cumpla con los requisitos del paradigma deba ser incorrecto. En el caso especial de una relación 1:1 o 1:N en la tabla de la base de datos, el incumplimiento de los requisitos del paradigma provocó. por la fusión es razonable.
Cuando diseñamos una base de datos, siempre debemos considerar los requisitos del paradigma