Boyce-Codd, cuarta y quinta forma normales
“Esta es la cuarta parte de la serie, las cinco formas normales. La forma normal de Boyce-Codd se abrevia BCNF. También se conoce como 3.5NF. 3.5 es 3½. Viene después de la tercera forma normal. La cuarta forma normal se abrevia 4NF y viene después de la forma normal de Boyce-Codd. La quinta forma normal se abrevia 5NF y viene después de la cuarta forma normal.
Este tutorial (artículo) es la cuarta parte de la serie tutorial, las cinco formas normales. Este tutorial explica BCNF, 4NF y 5NF.
Este tutorial sigue una historia de la siguiente manera: un padre ha muerto. Ha dejado algo de dinero para su hijo. Su hijo ha decidido usar el dinero para abrir (comenzar) una tienda de conveniencia. La tienda de conveniencia ya está almacenada y ha estado operando por algún tiempo. El hijo tiene algunos empleados, llamados empleados, en esta serie de tutoriales. El hijo es el propietario. Antes de que la tienda fuera operativa, tanto el propietario como los empleados no sabían las formas normales.
Usted, el lector, ha completado esta cinco series de tutoriales de formulario normal y también es un desarrollador de bases de datos. El hijo del difunto padre es tu amigo. Has visitado su tienda en los últimos tres días. El primer día los visitaste; Entrenó al propietario y sus empleados sobre cómo colocar una mesa de base de datos en 1NF. El segundo día, los entrenaste sobre cómo mover una mesa de 1NF a 2NF. Al tercer día, los entrenaste sobre cómo mover una mesa de 2NF a 3NF.
Hoy, el cuarto día, visitaste la tienda para capacitar solo al propietario en BCNF, 4NF y 5NF en su oficina."
Forma normal de Boyce-Codd
El problema BCNF ocurre cuando hay una clave primaria compuesta y un atributo de clave no primaria (columna), y la clave no primaria depende funcionalmente de la parte (E.gramo., uno) de los atributos clave primarios, mientras que la tabla ya está en la tercera forma normal.
Esto implica que la columna que no es de operación (clave no primaria) y la columna principal dependen de una entidad de formación y deben eliminarse como una tabla separada, donde la columna no privada será la clave principal. La otra parte de la clave primaria compuesta formará una nueva tabla con la columna no predominante, y la columna no predominante no será necesariamente parte de la clave principal. La otra parte de la clave primaria compuesta sigue siendo una clave primaria. Los posibles dependientes relacionados de la tabla principal acompañan adecuadamente las dos tablas de los niños.
La separación de tablas para la forma normal de Boyce-Codd no es realmente la misma que la separación de tablas en 2NF y 3NF.
Una tabla está en forma normal de Boyce-Codd si se obedecen las siguientes reglas:
- La tabla ya debe estar en la tercera forma normal.
- Ningún atributo que no sea de PRIME (columna) debe depender de la parte de la clave primaria compuesta.
Este segundo punto, como se cita, se simplifica.
Ejemplo
En la parte anterior de esta serie, la tabla Saledetails (con cierta modificación) se dio de la siguiente manera:
Saledetails (Saleid, Product, Numbersold, UnitslellingPrice, descuento)
Una tabla correspondiente con datos es:
El precio de venta de la unidad es de tipo, flotación o número. La clave principal en esta tabla es una clave compuesta que consiste en salado y producto.
Esta tabla está en 3NF. Se puede considerar que el número de productos vendidos depende del producto y no del Saleid. En otras palabras, una clave no predominante puede depender solo de la parte de la clave primaria compuesta. Esto no debería suceder; Y así, de estas tres columnas, las siguientes dos tablas podrían resultar:
Cantidad (Numberold, producto)
y
Saledetails (Saleid, Numbersold)
Para la tabla, cantidad, la clave principal es Numberold. Para la nueva tabla saledetails, la clave principal sigue siendo saladoid.
De la tabla de saledetails de los padres, el único dependiente para Numbersold es el producto. Desde la tabla Padre Saledetails, los dependientes de Saleid son números, unitslellingprice, descuento y sin producto. Y entonces las tablas deberían ser:
Cantidad (Numberold, producto)
y
Saledetails (Saleid, Numbersold, Numbersold, UnitslellingPrice, descuento)
En este punto, el propietario hace el siguiente comentario:
"No creo que querré saber la cantidad de un producto en particular vendido sin querer saber el Saleid, que depende del trío (comprando al cliente, vendiendo empleado y la fecha de transacción)."Usted, el desarrollador de la base de datos, responde de la siguiente manera:
“En ese caso, permitamos la tabla de cola de saledeta y orden de pedido en 3NF. Después de todo, muchas bases de datos comerciales no van más allá de 3NF, y las empresas se sienten cómodas. Sin embargo, siempre que desee saber que para una tabla similar, rompa la tabla principal en tablas BCNF."
Cuarta forma normal
1NF, 2NF, 3NF y BCNF dependen de la dependencia funcional. 4NF se basa en un tipo especial de dependencia funcional, que es bastante "inquietante", especialmente si no se entiende bien. Esta dependencia bastante inquietante se llama dependencia multivalida.
La dependencia funcional simplemente se llama dependencia. Sin embargo, la dependencia multivalizada no se llama simplemente dependencia, ya que eso traería confusión. Se llama dependencia multivalida.
Usted, el desarrollador de bases de datos le dice al propietario lo siguiente: “Debería interesarle que una tabla esté en 1NF, cada celda debe tener un valor único. Aquí ocurre un problema algo similar, pero con una tabla que ya está en BCNF después de 3NF. La dependencia multivalizada es con la clave primaria compuesta, y cada celda en toda la tabla ya tiene un solo valor. En el problema de 1NF, los valores múltiples en una celda no tienen que concierne a una clave. Con el problema de 4NF, hay al menos tres columnas. Si solo hay tres columnas, entonces las tres columnas forman la tecla compuesta primaria. En este caso, la primera columna de celdas puede determinar la segunda columna de celdas, pero la segunda columna es independiente de la tercera columna. 4NF no permite esto."
En otras palabras, el problema puede ser que la segunda columna depende de la primera columna, y la tercera columna aún depende de la primera columna y no tiene nada que hacer en términos de dependencia de la segunda columna. 4NF no permite esto.
Antes de continuar con la explicación de la dependencia multivalizada, se debe explicar el problema de la cuarta forma normal.
Cómo pueden surgir el número de 4NF con la tienda de conveniencia
Imagine que después de algún tiempo, ha tenido rivales (otras tiendas de conveniencia) en su vecindario, y no está vendiendo tanto como estaba vendiendo antes. Esto no se puede prever cuando comenzó la tienda de conveniencia.
Se le ocurre que si puede reducir sus precios, no por debajo del precio de costo, por supuesto, para sus clientes que compran más, entonces comprarán más, y sus ventas y ganancias aumentarán desde el nivel caído. Esto significa que debe saber dónde se van dichos clientes y sus direcciones (calles) para que incluso pueda entregar productos a sus casas. Una vez más, este problema no fue previsto al principio.
Y entonces se le ocurre la siguiente tabla, a la que trabajará, hasta BCNF, antes de que el tema de 4NF pueda mostrarse:
Entrega
Para usted, el propietario, su interés es la categoría del producto, el producto en sí que se entregará y la dirección para entregar a. Mirando la tabla completa, el resto de las secciones de la fila que comienzan desde el nombre personalizado hasta el extremo derecho determinar las primeras tres columnas. En otras palabras, las primeras tres columnas forman la clave principal para el resto de las columnas. Es decir, las primeras tres columnas dependen del resto de las columnas por filas. Y así, los primeros tres encabezados de columna deben subrayarse con líneas individuales. Con eso, esta tabla ahora está en su primera forma normal. Cada combinación de células horizontales en las primeras tres columnas es única.
Esta tabla también está en la segunda forma normal porque cada combinación de células horizontales en las primeras tres columnas es única, y no hay dependencia parcial (con grupos repetidos). Sin embargo, no está en la tercera forma normal porque las secciones de fila (piezas) que comienzan desde el nombre personalizado hasta el extremo derecho determinar el cliente (CustomerID depende de ellas). Entonces, todo lo que debe eliminarse, dejándolo con una copia del CustomerID. CustomerID ahora es tanto una clave extranjera como parte de la clave principal. La mesa ahora está en 3NF.
Antes de que usted, el desarrollador de la base de datos y el entrenador, pudiera continuar, el propietario dice: “En lugar de trabajar con la columna de categoría, columna de producto y columna de dirección, trabajaré con la columna de categoría, la columna del producto y la columna CustomerID, ya que una vez que el CustomerID Conocido, se puede conocer la dirección, y eso sería más conveniente, especialmente para la computadora."
Tu respuesta, "Eso es bueno, propietario. Estás en camino. Eso es lo que se hará."
Recuerde, la tabla de clientes ya existe. Esto se produjo en la parte anterior de esta serie tutorial. Entonces, la única tabla que producir ahora es una tabla que solo tiene las tres claves principales.
Permutaciones de entrega de categorías, por producto
Desafortunadamente, las columnas de esta clave primaria compuesta no están en 2NF entre ellas. Hay repeticiones de valores celulares que van hacia abajo, con dependencia parcial dentro de la clave compuesta. Estas repeticiones no son tan constructivas como parecen.
Observe que la confitería está asociada con el cliente 1, y también está asociado con el cliente 2. El refresco se asocia con el cliente 1, y también se asocia con el cliente 2.
Si el Cliente 1 ha pedido dulces hoy, pedirá chocolate mañana (no se muestra en la mesa). La confitería se asocia con el cliente 1 a través de dulces sobre la mesa, pero también se puede asociar con el cliente 1 a través de los chocolates en las entregas mañana. Si el Cliente 1 ha pedido Sprite hoy, pedirá a Coca-Cola mañana. El refresco se asocia con el cliente 1 a través de Sprite, en la mesa, pero también se puede asociar con el Cliente 1 a través de Coca-Cola. El mismo problema de entrega ocurre con el cliente 2. Este tipo de repetición se llama dependencia multivalida.
Observe que en la tabla anterior, la columna del producto no tiene repetición (al menos por ahora).
Para resolver este problema, es mejor poner primero estas repeticiones de los valores de la columna, de la clave primaria, en la primera forma normal para dar como resultado lo siguiente:
Permutaciones de entrega de categoría completas por producto
Permutación significa cambiar el orden de un acuerdo. En esta situación, significa dar todos los diferentes órdenes posibles de productos en la columna de productos. Ahora, hay más repeticiones (más redundancia) en esta tabla que en lo anterior. La buena noticia es que estas tres columnas ahora están bien, en primera forma normal. 2NF y 3NF deben estar previstos para estas tres columnas.
Recuerde que la entrega no fue prevista desde el principio cuando comenzó la tienda (fue operativa). Si hubiera sido previsto, entonces la primera tabla de transacciones en la primera parte de esta serie tutorial habría sido así:
Observe que los valores múltiples en cada célula en esta columna de producto tienen más factores que se tienen en cuenta que lo que sucedió en la primera tabla de transacciones en la primera parte de la serie. Llevar esta tabla a la primera forma normal daría como resultado la tabla anterior, que se reimpresa aquí, para una fácil referencia al lector, con algunas modificaciones en la columna del producto:
Las dos tablas de primera forma normal son las mismas porque la permutación en la columna del producto es relativa a la columna CustomerID. No olvide que cada cliente de cada cliente aquí identifica una fila en la tabla de clientes.
La definición de dependencia multivalizada significa que si hay tres columnas, x, y y z, y para una fila particular de valores x, y y z respectivamente, una dependencia multivalizada x ->> y, significa que si elegimos x x realmente ocurre en la tabla (llame a esta elección xC), y compile una lista de todas las xCCombinaciones de YZ que pueden ocurrir en la tabla, como se hizo anteriormente, encontraremos que xC está asociado con las mismas entradas Y, independientemente de la Z. Entonces, esencialmente, la presencia de Z no proporciona información útil para restringir los posibles valores de Y.
En la tabla anterior, xC, Por ejemplo, es confitería, y un valor Y correspondiente es dulce. La combinación de confitería y dulces no tiene nada que ver con la columna CustomerID, donde el valor tal vez 1 o 2 en las filas. Si se tome X como refrescos, un valor Y correspondiente sería sprite. La combinación de refrescos y sprite no tiene nada que ver con las columnas de CustomerID, donde el valor tal vez 1 o 2 en las filas.
Visto desde una segunda forma normal y puntos de vista de dependencia funcional, la columna de categoría depende de la columna del producto y también depende de la columna CustomerID, pero no depende de ambas columnas cuando se combina. Los valores en la columna del producto se repiten, determinando los valores en la columna de categoría; y los valores en la columna CustomerID se repiten, determinando los valores en la columna de categoría; pero ambas columnas juntas no determinan los valores en la columna de categoría.
Por lo tanto, la tabla debe dividirse en dos, con la categoría y las columnas de productos que van de una manera y las columnas de categoría y CustomerID van de la otra manera, de la siguiente manera:
Categoría-tabla de productos
Categoría - Tabla de clientes
Estas dos tablas para niños están ahora en 1NF, 2NF, 3NF, BCNF y lo más importante, 4NF. La tabla de productos de categoría tiene claves primarias compuestas. La tabla de categoría-cliente también tiene claves primarias compuestas. Cada una de las claves de la columna ya es una clave principal en alguna otra tabla de la base de datos, o es una clave extranjera en alguna otra tabla en la misma base de datos.
Estas dos tablas que reemplazan la tabla principal, no son las únicas tablas en toda la base de datos. De hecho, están relacionados con otras tablas en la base de datos. Por lo tanto, todavía hay algún trabajo de limpieza en el proyecto de diseño de la base de datos que se debe realizar con respecto a toda la base de datos y estas dos nuevas tablas.
Refiriéndose a la tabla de productos de categoría, recuerde que ya hay una tabla de productos en 4NF y una tabla de categoría en 4NF en la base de datos. Para que una tabla esté en cualquier forma normal, no debe violar ninguna de las reglas de esa forma normal. Los productos o la tabla de productos tienen ProductID como su clave principal y categoría o categoría como clave extranjera.
Por lo tanto, la tabla de productos de categoría producida aquí, en 4NF, debe abandonarse ya que las siguientes dos tablas, que están en 4NF, tienen toda su información (y más):
Categorías (categoryId, categoryName, Descripción)
Productos (ProductId, CategoryID, ProveyId, ProductName, UnitPrice, CantityInstock, ReorderLevel)
Por otro lado, la tabla de categoría-cliente en 4NF no puede ser abandonada, ya que viene con algunas relaciones nuevas en la entrega. De hecho, la tabla debería llamarse mejor, CategoryDelivery. Llamarlo a la entrega de productos sería engañoso para los programadores de bases de datos, pero no sería engañoso para los clientes, que son analfabetos en la base de datos. Así que llámalo categoría de entrega. En el formulario de notación de tabla, es:
CategoryDelivery (categoría, CustomerID)
Recuerde que cada clienteid se refiere a una fila en la tabla de clientes. La clave primaria compuesta es: categoría, customerID. Dado que ya hay una tabla de categorías con categoryID, esta tabla debería ser:
CategoryDelivery (categoryId, CustomerID, categoría)
donde categoryID depende de la categoría (nombre) y viceversa.
Entonces, la cuestión de la entrega trae en una tabla adicional en 4NF. El resto de las tablas en la base de datos ya están en 4NF, ya que no violan las reglas 4NF que se indican a continuación.
El problema de entrega no fue previsto antes de que la normalización en sus diferentes clases comenzara, al principio. Si se hubiera previsto como se indicó anteriormente, entonces la entrega de categorías habría llegado; en o antes de la tercera etapa de forma normal sin ninguna mención de 4NF.
Cuarta reglas de formulario normal
Una tabla está en 4NF si no viola las siguientes reglas:
- Ya está en forma normal de boyce-codd.
- La tabla no tiene ninguna dependencia de valor múltiple.
Esto significa que una tabla se puede diseñar la primera vez, y ya está en 4NF.
Quinta forma normal
5NF Las situaciones rara vez ocurren, pero cuando ocurren, se debe tener en cuenta la quinta forma normal para evitar cualquier problema contable conocido. La quinta forma normal también se conoce como la forma normal de la unión de proyección. Con la quinta forma normal, hay al menos tres columnas. Si solo hay tres columnas de interés, entonces hay una clave primaria compuesta, que se compone de las tres columnas.
Imagine que usted, el propietario, ha tenido hasta dos tiendas de conveniencia en la misma ciudad y que son suministrados por el mismo conjunto de proveedores. Llame a estas tiendas, Shop1 y Shop2. Los proveedores ven estas dos tiendas diferentes como dos clientes diferentes. Así que aquí, el cliente tiene un significado diferente. Significa comprar y no la persona. El significado del producto permanece igual.
Por lo tanto, hay una tabla con las claves principales: proveedor, producto y cliente. Eso es:
Tabla (proveedor, producto, cliente)
El problema de 5NF surge cuando un proveedor determinado puede suministrar un producto determinado a más de un cliente (las dos tiendas). Además, un cliente determinado puede recibir un producto determinado de más de un proveedor. Y un cliente determinado puede recibir de diferentes proveedores diferentes productos. Es decir, cualquiera de los tres socios puede hacer las mismas cosas a los otros dos socios.
Es decir, un proveedor puede corresponder a más de un cliente. Un cliente puede corresponder a más de un producto. Y un producto puede corresponder a más de un proveedor. Esto significa que pueden resultar las siguientes tres tablas binarias:
Tabla de proveedor-cliente
Tabla de productos al cliente
Tabla de proveedor de productos
Si una tabla principal se puede dividir en tres tablas más pequeñas sin pérdida o adición de información, y si cuando las tablas se unen hacia atrás, todavía no hay pérdida o adición de información, entonces la tabla principal debe desglosarse. Las tablas más pequeñas están en 5nf. En ese caso, se ha eliminado la dependencia de unión. Pérdida de información significa perder relaciones de fila, y la adición de información significa agregar nuevas relaciones de fila.
Si esto se descompone y volviendo a unir la pérdida o la adición de información, entonces la tabla no debe desglosarse. En ese caso, la tabla principal ya está en la quinta forma normal.
En este punto, usted, el desarrollador y el entrenador de la base de datos, dicen: “Propietario, dejo la colocación de datos en las tablas (tabla principal y tres tablas pequeñas) como un ejercicio para usted. Revisaré eso mañana."
Reglas de la quinta forma normal
Una tabla está en 5NF si no viola las siguientes reglas:
- Ya está en la cuarta forma normal.
- La tabla no tiene dependencia de unión.
Esto significa que una tabla se puede diseñar la primera vez, y ya está en 5NF.
Conclusión
Una tabla está en forma normal de Boyce-Codd si se obedecen las siguientes reglas:
- La tabla ya debe estar en la tercera forma normal.
- Ningún atributo que no sea de PRIME (columna) debe depender de la parte de la clave primaria compuesta.
Una tabla está en 4NF si no viola las siguientes reglas:
- Ya está en forma normal de boyce-codd.
- La tabla no tiene ninguna dependencia de valor múltiple.
Una tabla está en 5NF si no viola las siguientes reglas:
- Ya está en la cuarta forma normal.
- La tabla no tiene dependencia de unión.
El propietario ahora dice: "Esto requiere una gran celebración para los dos."
Usted, el desarrollador de la base de datos, responde: "¿Por qué no esperamos hasta mañana cuando junte todas las tablas y mejoraré en la tabla de productos??"
El propietario reacciona sonriendo: "¿Qué haría sin ti sin ti??"
Usted, el desarrollador de bases de datos, agregue, sonriendo: “Nos vemos mañana, entonces, en su oficina." y vete.