De hecho, comencé a poner una respuesta juntos, pero tuve complicaciones, porque (bastante comprensiblemente) quiero un ejemplo simple. El problema es múltiple.
En primer lugar, no tengo una buena idea de su nivel real de experiencia en bases de datos relacionales y 5NF; No tengo un punto de partida para abordar y luego discutir los detalles de 6NF,
En segundo lugar, al igual que cualquiera de los otros NF, es variado. Puedes apenas pisarlo; puedes implementar 6NF para las tablas de certan; puedes ir al máximo en cada mesa, etc. Seguro que hay una explosión de tablas, pero luego lo normalizas y matas la explosión; esa es una implementación avanzada o madura de 6NF. No sirve de nada proporcionar los niveles completos o parciales de 6NF, cuando está pidiendo el ejemplo más sencillo y directo.
Confío en que comprenda que algunas tablas pueden estar "en 5NF" mientras que otras están "en 6NF".
Así que puse uno para usted. Pero incluso eso necesita una explicación.
Ahora SQL apenas admite 5NF, no admite 6NF en absoluto (creo que dportas dice lo mismo en otras palabras). Ahora implemento 6NF en un nivel profundo, por razones de rendimiento, pivoteo simplificado (de tablas enteras, todas las columnas, no la función PIVOT tonta en MS), acceso en columnas, etc.Para eso necesita un catálogo completo, que es una extensión del catálogo SQL, para admitir el 6NF que SQL no admite, y mantener la integridad de los datos y las Reglas comerciales. Entonces, realmente no desea implementar 6NF por diversión, solo lo hace si tiene una necesidad, porque tiene que implementar un catálogo. (Esto es lo que la multitud EAV no lo hacen, y esta es la razón por la mayoría de los sistemas de EAV tienen problemas de integridad de datos. La mayoría de ellos no utilizar el declarativa Referencial & integridad de los datos que SQL tiene.)
Pero la mayoría de la gente quienes implementan 6NF no implementan el nivel más profundo, con un catálogo completo. Tienen necesidades más simples y, por lo tanto, implementan un nivel más bajo de 6NF. Entonces, tomemos eso, para proporcionar un ejemplo simple para usted. Comencemos con una tabla de Producto ordinaria que se declara en 5NF (y no discutamos sobre qué es 5NF). La empresa vende diferentes tipos de productos, la mitad de las columnas son obligatorias y la otra mitad son opcionales, lo que significa que, según el tipo de producto, ciertas columnas pueden ser nulas. Si bien pueden haber hecho un buen trabajo con la base de datos, los nulos son ahora un gran problema: las columnas que deben ser no nulas para ciertos tipos de productos son nulas, porque la declaración indica NULL y su código de aplicación es tan bueno como el siguiente .
Así que deciden ir con 6NF para solucionar ese problema, porque el subtítulo de 6NF establece que elimina el problema nulo. La sexta forma normal es la forma normal irreductible, no habrá más NF después de esto, porque los datos no se pueden normalizar más. Las filas se han normalizado al máximo grado. La definición de 6NF es:
una tabla está en 6NF cuando la fila contiene la clave principal y, como máximo, un atributo.
Tenga en cuenta que según esa definición, millones de tablas en todo el planeta ya están en 6NF, sin tener esa intención. P.ej. tablas de Referencia o Búsqueda típicas, con solo un PK y una Descripción.
Derecha. Bueno, nuestros amigos miran su tabla Producto, que tiene ocho atributos que no son clave, de modo que si crean la tabla Producto 6NF, tendrán ocho tablas de subproductos. Luego está el problema de que algunas columnas son claves externas a otras tablas, y eso lleva a más complicaciones. Y notan el hecho de que SQL no es compatible con lo que están haciendo, y tienen que crear un pequeño catálogo. Ocho tablas son correctas, pero no sensatas. Su propósito era deshacerse de Nulls, no escribir un pequeño subsytem alrededor de cada mesa.
Simple 6NF Example
Los lectores que no están familiarizados con la Norma para el modelado de bases de datos relacionales pueden encontrar IDEF1X Notation útil para la interpretación de los símbolos en el ejemplo.
Por lo general, la Tabla de productos conserva todas las columnas obligatorias, especialmente las FK, y cada columna Opcional, cada columna Nullable, se coloca en una tabla de subproductos separada. Esa es la forma más simple que he visto. Cinco mesas en lugar de ocho. En el Modelo, las cuatro tablas de subproductos están "en 6NF"; la tabla principal del Producto está "en 5NF".
Ahora realmente no necesitamos todos los segmentos de código que SELECCIONA del Producto para tener que averiguar qué columnas debe construir, en función del Tipo de Producto, etc., entonces proporcionamos una Vista, que esencialmente proporciona la "vista" 5NF de el clúster de la tabla Producto.
Lo siguiente que necesitamos son los rudimentos básicos de una extensión del catálogo SQL, para asegurarnos de que las reglas (integridad de datos) para los diversos tipos de productos se mantienen en un lugar, en la base de datos y no dependen en el código de la aplicación. El catálogo más simple que puedes salirte con la tuya. Eso se elimina de ProductType, por lo que ProductType ahora forma parte de esa Metadata. Usted puede implementar esa estructura simple sin un catálogo, pero yo no lo recomendaría.
actualización
Es importante señalar que implemento todos reglas de negocio en la base de datos. De lo contrario, no es una base de datos (la noción de reglas de implementación "en el código de la aplicación" es extremadamente graciosa, especialmente hoy en día, cuando tenemos floristas trabajando como "desarrolladores"). Por lo tanto, todas las reglas, etc. se implementan antes que nada como declaraciones SQL, restricciones CHECK, funciones, etc. Esto conserva toda la integridad referencial declarativa y la integridad declarativa de los datos. La extensión del catálogo SQL cubre el área en la que SQL no tiene declaraciones para, y luego se implementan como SQL. Al ser un buen diccionario de datos, hace mucho más. P.ej. No escribo Vistas cada vez que cambio las tablas o agregue o cambie columnas o sus características, se crean directamente desde el catálogo + extensión usando un generador de código simple.
Una nota más muy importante. No puede implementar 6NF (o EAV correctamente, para el caso), sin completar un ejercicio de Normalización completo y fiel, a 5NF. El problema que veo en cada sitio es que no tienen un verdadero estado de 5NF, tienen una mezcolanza de normalización parcial o ninguna normalización, pero están muy apegados a eso. Crear 6NF o EAV a partir de eso es un desastre. Crear EAV o 6NF a partir de ese sin todas las reglas comerciales implementadas en el SQL declarativo es un desastre nuclear, que arde durante años. Tienes lo que pagas.
Fin de la actualización.
Finalmente, sí, hay al menos cuatro niveles adicionales de normalización (la normalización es un principio, no una mera referencia a un formulario normal), que se pueden aplicar a ese clúster simple de productos 6NF, proporcionando más control, menos tablas , etc. Cuanto más nos adentramos, más extenso es el catálogo. Y niveles más altos de rendimiento. Cuando esté listo, solo pregunte, ya he erigido los modelos y publicado detalles en otras respuestas.
"6NF significa que cada relación consiste en una clave candidata más no más de otro atributo (no clave)". ¿Me puede dar una referencia a esta definición? – shababhsiddique
Pago y envío "Diseño e implementación de bases de datos relacionales: Jan Harrington, 3ª edición, Página Nº125". (* El resultado es tablas que no se pueden descomponer más; en la mayoría de los casos, las tablas incluyen la clave principal y -key atributo. *) – Shinchan