normalization - react - state merge
Me gustaría entender 6NF con un ejemplo (4)
Acabo de leer los argumentos de @ PerformanceDBA re: 6NF y EAV. Estoy intrigado. Anteriormente había sido escéptico de 6NF, ya que se presentó como "simplemente" pegar algunas columnas de marca de tiempo en las tablas.
Siempre he trabajado con un diccionario de datos y no es necesario convencerme para usar uno o para generar código SQL. Así que espero una respuesta que requiera un diccionario (o catálogo) que se utiliza para generar código.
Entonces me gustaría saber cómo 6NF se ocuparía de un ejemplo extremadamente simple. Una tabla de artículos, descripciones y precios. Los precios cambian con el tiempo.
De todos modos, ¿cómo se ve la tabla Items cuando se convierte a 6NF? ¿Cuál es la "explosión de tablas"? que pasa aqui?
Si el ejemplo no funciona con una tabla así de simple, siéntase libre de agregar lo que sea necesario para transmitir el punto.
Anteriormente había sido escéptico de 6NF, ya que se presentó como "simplemente" pegar algunas columnas de marca de tiempo en las tablas.
No estoy seguro de dónde proviene este error aparente. ¿Quizás el hecho de que 6NF se introdujo para el libro "Datos temporales y el modo relacional" por fecha, Darwen y Lorentzos? De todos modos, espero que las otras respuestas aquí hayan aclarado que 6NF no está limitado a las bases de datos temporales.
El punto que quería hacer es que, aunque 6NF es "académicamente respetable" y siempre alcanzable, puede no conducir necesariamente al diseño óptimo en todos los casos (y no solo cuando se considera la implementación con SQL). Incluso los descubridores y defensores de 6NF antes mencionados parecen estar de acuerdo, por ejemplo
Chris Date : "A efectos prácticos, cumpla con 5NF (y 6 NF)".
Hugh Darwen : "la descomposición de 6NF en torno a Date [¡no a la persona!] Sería excesivo ... un diseño óptimo para el club de fútbol es ... 5-y-bit-NF!"
Hugh Darwen : "estamos en 5NF pero no en 6NF, y de nuevo 5NF es suficiente" (varios ejemplos similares).
Por otra parte, también puedo encontrar evidencia de lo contrario:
Chris Date : "Darwen y yo sentimos desde hace un tiempo que todas las actualizaciones de base deberían estar en 6NF".
En una nota práctica, recientemente extendí el esquema de SQL de uno de nuestros productos para agregar una característica menor. Adopté un 6NF para evitar columnas con nulos y terminé con seis nuevas tablas donde la mayoría (¿todos?) De mis colegas habrían usado una tabla (o tal vez ampliado una tabla existente) con columnas con nulos. A pesar de que probé varios procesos "auxiliares" almacenados y una VIEW "desnormalizada" con activadores INSTEAD OF , cada codificador que ha tenido que trabajar con esta característica en el nivel SQL se ha salido de su camino para maldecirme :)
Empecé a poner una respuesta juntos, pero tuve complicaciones, porque (bastante comprensiblemente) quiero un ejemplo simple. El problema es múltiple.
Primero, no tengo una buena idea de su nivel de experiencia real 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 las otras 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 ti. Pero incluso eso necesita una explicación.
Ahora SQL apenas admite 5NF, no admite 6NF en absoluto (creo que dportas dice lo mismo en diferentes 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 en MS), acceso a columnas, etc. Para eso necesita un catálogo completo, que es un extensión al 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 de EAV no hace, y esta es la razón por la cual la mayoría de los sistemas EAV tienen problemas de integridad de datos. La mayoría de ellos no usan la Integridad Referencial y de Datos declarativa que SQL tiene).
Pero la mayoría de las personas que 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 .
Entonces 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 haber tenido 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.
Los lectores que no están familiarizados con el Estándar para Modelar Bases de Datos Relacionales pueden encontrar que la Notación IDEF1X es útil para interpretar 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 que cada segmento de código que SELECCIONE del Producto tenga que descubrir qué columnas debe construir, en función del Tipo de Producto, etc., entonces proporcionamos una Vista, que esencialmente proporciona la "vista" de 5NF del clúster de la tabla Producto .
Lo siguiente que necesitamos son los rudimentos básicos de una extensión del catálogo SQL, de modo que podamos 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 del 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. Puede implementar esa estructura simple sin un catálogo, pero yo no lo recomendaría.
Actualizar
Es importante tener en cuenta que implemento todas las reglas de negocios 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 de SQL cubre el área para la que SQL no tiene declaraciones , 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 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 eso sin todas las reglas de negocio implementadas en SQL declarativo es un desastre nuclear que arde por años. Tienes lo que pagas.
Fin de la actualización
Finalmente, sí, hay al menos otros cuatro niveles de normalización (la normalización es un principio, no una mera referencia a un formulario normal), que se puede aplicar a ese clúster simple de productos 6NF, proporcionando más control, menos tablas, etc. más profundo vamos, 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.
En pocas palabras, 6NF significa que cada relación consiste en una clave candidata más no más de otro atributo (clave o no clave). Para tomar su ejemplo, si un "artículo" es identificado por un Código de producto y los otros atributos son Descripción y Precio, entonces un esquema de 6NF consistiría en dos relaciones (* indica la clave en cada una):
ItemDesc {ProductCode*, Description}
ItemPrice {ProductCode*, Price}
Este es un enfoque potencialmente muy flexible porque minimiza las dependencias. Esa es también su principal desventaja, especialmente en una base de datos SQL. SQL hace que sea difícil o imposible aplicar muchas restricciones de tablas múltiples. Con el esquema anterior, en la mayoría de los casos no será posible hacer cumplir una regla comercial de que cada producto siempre debe tener una descripción Y un precio. Del mismo modo, es posible que no pueda aplicar algunas claves compuestas que deberían aplicarse (porque sus atributos podrían dividirse en varias tablas).
Entonces al considerar 6NF, tiene que sopesar qué dependencias y reglas de integridad son importantes para usted. En muchos casos, puede resultarle más práctico y útil adherirse a 5NF y no normalizar más allá de eso.
Estos chicos lo tienen mal: Anchor Modeling . Excelentes trabajos académicos sobre el tema, combinados con ejemplos prácticos. Sus escritos finalmente me han llevado al límite para considerar construir un DW en 6nf en un próximo proyecto. El trabajo de POC que he hecho ha validado (al menos para mí) que los enormes beneficios de 6nf no superan los costos.