database - sinonimos - ¿Deberían las bases de datos OLAP ser desnormalizadas para el rendimiento de lectura?

normalizacion de bases de datos ejemplos

Question

Siempre pensé que las bases de datos deberían desnormalizarse para el rendimiento de lectura, ya que se hace para el diseño de la base de datos OLAP, y no exageró mucho más 3NF para el diseño OLTP.

PerformanceDBA en varias publicaciones, por ej., En Rendimiento de diferentes enfoques de datos basados ​​en tiempo defiende el paradigma de que la base de datos siempre debe estar bien diseñada por normalización en 5NF y 6NF (forma normal).

¿Lo he entendido correctamente (y qué entendí correctamente)?

¿Qué hay de malo con el enfoque de desnormalización tradicional / diseño de paradigma de bases de datos OLAP (por debajo de 3NF) y el consejo de que 3NF es suficiente para la mayoría de los casos prácticos de bases de datos OLTP?

Por ejemplo:

• "La simple verdad ... es que 6NF, ejecutado correctamente, es el almacén de datos" (PerformanceDBA)

Debo confesar que nunca podría comprender las teorías de que la desnormalización facilita el rendimiento de lectura. ¿Alguien puede darme referencias con buenas explicaciones lógicas de esto y de las creencias contrarias?

¿Cuáles son las fuentes a las que puedo referirme cuando trato de convencer a mis interesados ​​de que las bases de datos de OLAP / Data Warehousing deberían estar normalizadas?

Para mejorar la visibilidad, copié aquí de los comentarios:

"Sería bueno que los participantes agreguen (divulguen) cuántas implementaciones de almacén de datos en la vida real (sin proyectos científicos incluidos) en 6NF han visto o participado. Tipo de un grupo rápido. Me = 0". - Damir Sudarevic

El artículo de Data Warehouse de Wikipedia dice:

"El enfoque normalizado [frente a uno dimensional de Ralph Kimball], también llamado el modelo 3NF (Third Normal Form) cuyos seguidores se conocen como" Inmonites ", cree en el enfoque de Bill Inmon en el que se afirma que el almacén de datos debe ser modelado utilizando un modelo ER / modelo normalizado ".

Parece que el enfoque de almacenamiento de datos normalizado (por Bill Inmon) se percibe como no superior a 3NF (?)

Solo quiero entender cuál es el origen del mito (o creencia axiomática ubicua) de que data warehousing / OLAP es sinónimo de desnormalización.

Damir Sudarevic respondió que están bien enfocados. Permítanme volver a la pregunta: ¿Por qué se cree que la desnormalización facilita la lectura?

Answer 1

¿No debería una base de datos ser desnormalizada para el rendimiento de lectura?

De acuerdo, aquí va un total de "Su kilometraje puede variar", "Depende", "Use la herramienta adecuada para cada trabajo", la respuesta "Un tamaño no sirve para todos", con un poco de "No lo arregles si No está roto "arrojado en:

La desnormalización es una forma de mejorar el rendimiento de las consultas en ciertas situaciones. En otras situaciones, puede reducir el rendimiento (debido al aumento en el uso del disco). Ciertamente hace que las actualizaciones sean más difíciles.

Solo debe tenerse en cuenta cuando se presenta un problema de rendimiento (porque está dando los beneficios de la normalización e introduce complejidad).

Los inconvenientes de la desnormalización son un problema menor con los datos que nunca se actualizan o que solo se actualizan en trabajos por lotes, es decir, no en datos OLTP.

Si la desnormalización resuelve un problema de rendimiento que necesita resolver, y que las técnicas menos invasivas (como índices o cachés o comprar un servidor más grande) no resuelven, entonces sí, debe hacerlo.

Answer 2

El problema con la palabra "desnormalizado" es que no especifica en qué dirección debe ingresar. Se trata de intentar llegar a San Francisco desde Chicago alejándose de Nueva York.

Un esquema de estrella o un esquema de copo de nieve ciertamente no está normalizado. Y ciertamente funciona mejor que un esquema normalizado en ciertos patrones de uso. Pero hay casos de desnormalización en los que el diseñador no estaba siguiendo ninguna disciplina, solo componía tablas por intuición. A veces esos esfuerzos no funcionan.

En resumen, no te limites a desnormalizar. Siga una disciplina de diseño diferente si confía en sus beneficios e incluso si no está de acuerdo con el diseño normalizado. Pero no use la desnormalización como una excusa para un diseño casual.

Answer 3

La desnormalización y la agregación son las dos principales estrategias utilizadas para lograr el rendimiento en un almacén de datos. ¡Es una tontería sugerir que no mejora el rendimiento de lectura! Seguramente debo haber entendido mal algo aquí?

Agregación: considere una tabla con 1 billón de compras. Contraste con una tabla que contiene una fila con la suma de las compras. Ahora, ¿qué es más rápido? Seleccione la suma (cantidad) de la tabla de mil millones de filas o una cantidad seleccionada de la tabla de una sola fila? Es un ejemplo estúpido, por supuesto, pero ilustra el principio de agregación con bastante claridad. ¿Por qué es más rápido? Porque independientemente de qué modelo mágico / hardware / software / religión usemos, leer 100 bytes es más rápido que leer 100 gigabytes. Simple como eso.

Desnormalización: una dimensión de producto típica en un almacén de datos minorista tiene montones de columnas. Algunas columnas son cosas fáciles como "Nombre" o "Color", pero también tiene algunas cosas complicadas, como las jerarquías. Jerarquías múltiples (el rango de productos (5 niveles), el comprador previsto (3 niveles), materias primas (8 niveles), modo de producción (8 niveles) junto con varios números calculados, como el tiempo de entrega promedio (desde el inicio del año) , peso / medidas de embalaje, etcétera. He mantenido una tabla de dimensiones del producto con más de 200 columnas que se construyó a partir de ~ 70 tablas de 5 sistemas de fuentes diferentes. Es simplemente absurdo debatir si una consulta sobre el modelo normalizado (a continuación)

select product_id
  from table1
  join table2 on(keys)
  join (select average(..)
          from one_billion_row_table 
         where lastyear = ...) on(keys)
  join ...table70
 where function_with_fuzzy_matching(table1.cola, table37.colb) > 0.7
   and exists(select ... from )
   and not exists(select ...)
   and table20.version_id = (select max(v_id from product_ver where ...)
   and average_price between 10 and 20
   and product_range = ''High-Profile''

... es más rápido que la consulta equivalente en el modelo desnormalizado:

select product_id
  from product_denormalized
 where average_price between 10 and 20
   and product_range = ''High-Profile'';

¿Por qué? En parte por la misma razón que el escenario agregado. Pero también porque las consultas son simplemente "complicadas". Son tan desagradablemente complicados que el optimizador (y ahora me refiero a los detalles de Oracle) se confunde y arruina los planes de ejecución. Los planes de ejecución subóptimos pueden no ser tan importantes si la consulta se ocupa de pequeñas cantidades de datos. Pero tan pronto como comencemos a unirnos a las Big Tables, es crucial que la base de datos obtenga el plan de ejecución correcto. Habiendo desnormalizado los datos en una tabla con una única clave sintética (diablos, ¿por qué no agrego más combustible a este fuego en curso?), Los filtros se convierten en simples filtros de rango / igualdad en las columnas precocinadas. Después de haber duplicado los datos en nuevas columnas, nos permite recopilar estadísticas sobre las columnas que ayudarán al optimizador a estimar las selectividades y así proporcionarnos un plan de ejecución adecuado (bueno, ...).

Obviamente, el uso de desnormalización y agregación hace que sea más difícil acomodar los cambios de esquema, lo cual es algo malo. Por otro lado, proporcionan rendimiento de lectura, lo cual es algo bueno.

Entonces, ¿debería desnormalizar su base de datos para lograr un rendimiento de lectura? ¡Diablos, no! Agrega tantas complejidades a su sistema que no hay límite para la cantidad de maneras en que lo arruinará antes de que haya entregado. ¿Vale la pena? Sí, a veces debe hacerlo para cumplir con un requisito de rendimiento específico.

Actualización 1

PerformanceDBA: 1 fila se actualizaría mil millones de veces al día

Eso implicaría un requisito (casi) en tiempo real (que a su vez generaría un conjunto completamente diferente de requisitos técnicos). Muchos (si no la mayoría) data warehouses no tienen ese requisito. Escogí un ejemplo de agregación poco realista solo para aclarar por qué funciona la agregación. No quería tener que explicar las estrategias de rollup también :)

Además, uno tiene que contrastar las necesidades del usuario típico de un almacén de datos y el usuario típico del sistema OLTP subyacente. Un usuario que busca entender qué factores influyen en los costos de transporte, no podría preocuparse menos si falta el 50% de los datos actuales o si 10 camiones explotaron y mataron a los conductores. Llevar a cabo el análisis a lo largo de 2 años de datos aún llegaría a la misma conclusión, incluso si tuviera la información actualizada a su disposición.

Contraste esto con las necesidades de los conductores de ese camión (los que sobrevivieron). No pueden esperar 5 horas en algún punto de tránsito simplemente porque un proceso de agregación estúpido tiene que finalizar. Tener dos copias separadas de los datos resuelve ambas necesidades.

Otro obstáculo importante al compartir el mismo conjunto de datos para sistemas operacionales y sistemas de informes es que los ciclos de lanzamiento, preguntas y respuestas, implementación, SLA y lo que usted tiene, son muy diferentes. Nuevamente, tener dos copias separadas hace que esto sea más fácil de manejar.

Answer 4

La respuesta corta es ¡no arregles un problema de rendimiento que no tienes !

En cuanto a las tablas basadas en el tiempo, el paradigma generalmente aceptado es tener fechas valid_from y valid_to en cada fila. Esto sigue siendo básicamente 3NF ya que solo cambia la semántica de "esta es la única y única versión de esta entidad" a "esta es la única versión de esta entidad en este momento "

Answer 5

Las dos metodologías más populares para construir un data warehouse (DW) parecen ser las de Bill Inmon y Ralph Kimball.

La metodología de Inmon utiliza un enfoque normalizado, mientras que Kimball utiliza el modelado dimensional: esquema de estrella des-normalizado.

Ambos están bien documentados hasta en pequeños detalles y ambos tienen muchas implementaciones exitosas. Ambos presentan un "camino ancho y bien pavimentado" hacia un destino DW.

No puedo comentar sobre el enfoque de 6NF ni sobre Anchor Modeling porque nunca he visto ni participado en un proyecto de DW utilizando esa metodología. Cuando se trata de implementaciones, me gusta viajar por senderos bien probados, pero ese soy solo yo.

Entonces, para resumir, ¿debería DW normalizarse o des-normalizarse? Depende de la metodología que escoja: simplemente elija una y cúmplala, al menos hasta el final del proyecto.

EDITAR - Un ejemplo

En el lugar donde trabajo actualmente, teníamos un informe heredado que se ha estado ejecutando desde siempre en el servidor de producción. No es un informe simple, sino una colección de 30 subinformes enviados por correo electrónico a todos y a su hormiga todos los días.

Recientemente, implementamos un DW. Con dos servidores de informes y un montón de informes en el lugar, esperaba poder olvidarnos del legado. Pero no, el legado es un legado, siempre lo tuvimos, así que lo queremos, lo necesitamos, no podemos vivir sin él, etc.

El problema es que el desorden de un script python y SQL tomó ocho horas (sí, ocho horas) para ejecutarse todos los días. Huelga decir que la base de datos y la aplicación fueron construidos durante años por pocos lotes de desarrolladores, por lo que no es exactamente su 5NF.

Era hora de volver a crear el legado de DW. De acuerdo, para que quede corto, está hecho y lleva 3 minutos (tres minutos) producirlo, seis segundos por subinforme. Y tenía prisa por entregar, así que ni siquiera estaba optimizando todas las consultas. Esto es un factor de 8 * 60/3 = 160 veces más rápido, por no mencionar los beneficios de eliminar un trabajo de ocho horas de un servidor de producción. Creo que todavía puedo afeitarme de un minuto más o menos, pero ahora a nadie le importa.

Como punto de interés, he usado el método de Kimball (modelado dimensional) para el DW y todo lo que se usa en esta historia es de código abierto.

Creo que se trata de todo esto (data-warehouse). ¿Importa incluso qué metodología (normalizada o desnormalizada) se usó?

EDIT 2

Como punto de interés, Bill Inmon tiene un documento muy bien escrito en su sitio web: Una historia de dos arquitecturas .

Answer 6

Por "OLAP" entiendo que se refiera a una base de datos relacional / SQL orientada a temas utilizada para soporte de decisiones, también conocido como Almacén de Datos.

La forma normal (típicamente la 5ta / 6ta forma normal) es generalmente el mejor modelo para un almacén de datos. Las razones para normalizar un Almacén de Datos son exactamente las mismas que cualquier otra base de datos: reduce la redundancia y evita posibles anomalías de actualización; evita el sesgo incorporado y, por lo tanto, es la forma más fácil de admitir el cambio de esquema y los nuevos requisitos. Usar el formulario normal en un almacén de datos también ayuda a mantener el proceso de carga de datos simple y consistente.

No existe un enfoque de desnormalización "tradicional". Los buenos almacenes de datos siempre se han normalizado.

Answer 7

Primero mis opiniones, luego algunos análisis

Opiniones
La desnormalización se percibe como una ayuda para la lectura de datos porque el uso común de la palabra denormalización a menudo incluye no solo la ruptura de formularios normales, sino también la introducción de cualquier dependencia de inserción, actualización y eliminación en el sistema.

Esto, estrictamente hablando, es falso , vea esta question/answer , la desnormalización en sentido estricto significa romper cualquiera de las formas normales de 1NF-6NF, otras dependencias de inserción, actualización y eliminación se tratan con el Principio de Diseño Ortogonal .

Entonces, lo que sucede es que las personas toman el principio de compromiso de Espacio contra Tiempo y recuerdan el término redundancia (asociado con la desnormalización, que aún no es igual) y concluyen que usted debería tener beneficios. Esta es una implicación errónea, pero las implicaciones falsas no le permiten concluir lo contrario.

Romper formas normales de hecho puede acelerar la recuperación de algunos datos (detalles en el análisis a continuación), pero como regla, también será al mismo tiempo:

• favorecer solo tipos específicos de consultas y ralentizar todas las demás rutas de acceso
• aumentar la complejidad del sistema (lo que influye no solo en el mantenimiento de la base de datos en sí, sino que también aumenta la complejidad de las aplicaciones que consumen los datos)
• ofuscar y debilitar la claridad semántica de la base de datos
• punto principal de los sistemas de bases de datos, ya que los datos centrales que representan el espacio problemático deben ser imparciales al registrar los hechos, de modo que cuando los requisitos cambian no es necesario rediseñar las partes del sistema (datos y aplicaciones) que son independientes en realidad. poder hacer estas dependencias artificiales debería minimizarse: el requisito "crítico" de hoy en día de acelerar una consulta a menudo solo es marginalmente importante.

Análisis

Entonces, hice una afirmación de que a veces romper formas normales puede ayudar a la recuperación. Es hora de dar algunos argumentos

1) Rompiendo 1NF

Supongamos que tiene registros financieros en 6NF. De esa base de datos seguramente puede obtener un informe sobre lo que es un saldo para cada cuenta para cada mes.

Suponiendo que una consulta que tendría que calcular dicho informe debería pasar por n registros, podría hacer una tabla

account_balances(month, report)

que mantendría los balances estructurados XML para cada cuenta. Esto rompe 1NF (ver notas más adelante), pero permite que una consulta específica se ejecute con un mínimo de E / S.

Al mismo tiempo, suponiendo que es posible actualizar cualquier mes con inserciones, actualizaciones o eliminaciones de registros financieros, el rendimiento de las consultas de actualización en el sistema podría verse ralentizado por un tiempo proporcional a alguna función de n para cada actualización . (el caso anterior ilustra un principio, en realidad tendría mejores opciones y el beneficio de obtener una E / S mínima traería tales penalidades que para el sistema realista que realmente actualiza los datos a menudo obtendría un mal rendimiento incluso para su consulta específica dependiendo de la tipo de carga de trabajo real; puede explicar esto con más detalle si lo desea)

Nota: Este es en realidad un ejemplo trivial y hay un problema con él: la definición de 1NF. La suposición de que el modelo anterior rompe 1NF depende del requisito de que los valores de un atributo '' contengan exactamente un valor del dominio aplicable ''.

Esto le permite decir que el dominio del informe de atributos es un conjunto de todos los informes posibles y que de todos ellos hay exactamente un valor y afirma que 1NF no está roto (similar al argumento de que el almacenamiento de palabras no rompe 1NF aunque es posible que tenga una relación de letters en algún lugar de su modelo).

Por otro lado, hay formas mucho mejores de modelar esta tabla, que sería más útil para una gama más amplia de consultas (por ejemplo, para recuperar saldos para una sola cuenta para todos los meses del año). En este caso, justificaría esa mejora diciendo que este campo no está en 1NF.

De todos modos, explica por qué las personas afirman que romper las NF podría mejorar el rendimiento.

2) Rompiendo 3NF

Asumiendo tablas en 3NF

CREATE TABLE `t` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `member_id` int(10) unsigned NOT NULL,
  `status` tinyint(3) unsigned NOT NULL,
  `amount` decimal(10,2) NOT NULL,
  `opening` decimal(10,2) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `member_id` (`member_id`),
  CONSTRAINT `t_ibfk_1` FOREIGN KEY (`member_id`) REFERENCES `m` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB

CREATE TABLE `m` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB

con datos de muestra (1M filas en t, 100k en m)

Supongamos una consulta común que quiere mejorar

mysql> select sql_no_cache m.name, count(*) 
       from t join m on t.member_id = m.id 
       where t.id between 100000 and 500000 group by m.name;
+-------+----------+
| name  | count(*) |
+-------+----------+
| omega |       11 |
| test  |        8 |
| test3 |   399982 |
+-------+----------+
3 rows in set (1.08 sec)

puede encontrar sugerencias para mover el name atributo a la tabla m que rompe 3NF (tiene un FD: member_id -> name y member_id no es una clave de t)

después

alter table t add column varchar(255);
update t inner join m on t.member_id = t.id set t.name = m.name;

corriendo

mysql> select sql_no_cache name, count(*) 
       from t where id 
       between 100000 and 500000 
       group by name;
+-------+----------+
| name  | count(*) |
+-------+----------+
| omega |       11 |
| test  |        8 |
| test3 |   399982 |
+-------+----------+
3 rows in set (0.41 sec)

notas: el tiempo de ejecución de la consulta anterior se reduce a la mitad , pero

• la mesa no estaba en 5NF / 6NF para comenzar
• la prueba se realizó con no_sql_cache, por lo que se evitaron la mayoría de los mecanismos de caché (y en situaciones reales desempeñan un papel en el rendimiento del sistema)
• el consumo de espacio se incrementa en aproximadamente 9x tamaño del nombre de la columna x 100k filas
• debería haber desencadenantes en t para mantener la integridad de los datos, lo que ralentizaría significativamente todas las actualizaciones para nombrar y agregar controles adicionales que las inserciones en t tendrían que pasar por
• probablemente se puedan obtener mejores resultados al soltar claves sustitutas y cambiar a claves naturales, y / o indexar, o rediseñar a NF más altas

La normalización es la forma correcta a largo plazo. Pero no siempre tiene la opción de rediseñar el ERP de la empresa (que, por ejemplo, ya es solo 3NF); a veces debe realizar ciertas tareas dentro de los recursos especificados. Por supuesto, hacer esto es solo una ''solución'' a corto plazo.

Línea de fondo

Creo que la respuesta más pertinente a su pregunta es que encontrará la industria y la educación usando el término ''denormalización'' en

• sentido estricto, para romper NF
• sin apretar, para introducir cualquier inserción, actualización y eliminación de dependencias ( comentarios originales de cotización de Codd sobre la normalización que dicen: '' indeseable (!) inserción, actualización y eliminación de dependencias'', ver algunos detalles question/answer )

Entonces, bajo definición estricta, la agregación (tablas resumen) no se considera denormalización y pueden ayudar mucho en términos de rendimiento (como cualquier caché, que no se percibe como desnormalización).

El uso libre abarca tanto la ruptura de formas normales como el principio del diseño ortogonal , como se dijo anteriormente.

Otra cosa que podría arrojar algo de luz es que hay una diferencia muy importante entre el modelo lógico y el modelo físico .

Por ejemplo, los índices almacenan datos redundantes, pero nadie los considera una desnormalización, ni siquiera las personas que usan el término de manera flexible y hay dos razones (conectadas) para esto.

• no son parte del modelo lógico
• son transparentes y garantizados para no romper la integridad de su modelo

Si no modela adecuadamente su modelo lógico, terminará con una base de datos inconsistente: tipos incorrectos de relaciones entre sus entidades (incapacidad para representar el espacio problemático), hechos contradictorios (capacidad de perder información) y debe emplear cualquier método que pueda para obtener un modelo lógico correcto, es una base para todas las aplicaciones que se construirán encima de él.

La normalización, la semántica ortogonal y clara de sus predicados, los atributos bien definidos, las dependencias funcionales identificadas correctamente juegan un papel importante para evitar las trampas.

Cuando se trata de implementación física, las cosas se relajan más en un sentido que la columna computada, bien materializada, que depende de la no clave podría estar rompiendo 3NF, pero si hay mecanismos que garanticen consistencia, está permitida en el modelo físico de la misma manera que los índices están permitidos, pero tiene que justificarlo muy cuidadosamente porque normalmente la normalización arrojará las mismas o mejores mejoras en todos los ámbitos y tendrá un impacto negativo o negativo y mantendrá el diseño claro (lo que reduce los costos de desarrollo y mantenimiento de la aplicación) resultando en ahorros que puede gastar fácilmente en la actualización de hardware para mejorar la velocidad incluso más de lo que se logra con la ruptura de NF.

Answer 8

Simplificación:

Una base de datos OLTP debe ser normalizada (hasta donde tenga sentido).

Un almacén de datos OLAP debe denormalizarse en tablas de hechos y dimensiones (para minimizar las uniones).

Answer 9

Mitología

Siempre pensé que las bases de datos deberían desnormalizarse para su lectura, ya que se hace para el diseño de la base de datos OLAP, y no exageró mucho más 3NF para el diseño OLTP.

Hay un mito en ese sentido. En el contexto de la Base de Datos Relacional, he reimplementado seis "bases de datos" muy grandes llamadas "des-normalizadas"; y ejecutó más de ochenta tareas corrigiendo problemas en otros, simplemente normalizándolos, aplicando estándares y principios de ingeniería. Nunca he visto ninguna evidencia del mito. Solo personas repitiendo el mantra como si fuera una especie de oración mágica.

Normalización vs no normalizada

("Desnormalización" es un término fraudulento; me niego a usarlo).

Esta es una industria científica (al menos la que ofrece software que no se rompe, que pone a la gente en la Luna, que ejecuta sistemas bancarios, etc.). Se rige por las leyes de la física, no de la magia. Las computadoras y el software son todos objetos finitos, tangibles y físicos que están sujetos a las leyes de la física. De acuerdo con la educación secundaria y terciaria que recibí:

• no es posible que un objeto más grande, más gordo y menos organizado funcione mejor que un objeto más pequeño, más delgado y más organizado.

• La normalización produce más tablas, sí, pero cada tabla es mucho más pequeña. Y a pesar de que hay más tablas, de hecho hay (a) menos combinaciones y (b) las uniones son más rápidas porque los conjuntos son más pequeños. Se requieren menos índices en general, porque cada tabla más pequeña necesita menos índices. Las tablas normalizadas también producen tamaños de fila mucho más cortos.

• para cualquier conjunto de recursos dado, tablas normalizadas:

  • ajustar más filas en el mismo tamaño de página
  • por lo tanto, ajuste más filas en el mismo espacio de caché, por lo tanto, se aumenta el rendimiento general)
  • por lo tanto, coloque más filas en el mismo espacio de disco, por lo tanto, se reduce el número de E / S; y cuando se solicita I / O, cada E / S es más eficiente.
    .
• no es posible que un objeto que está muy duplicado funcione mejor que un objeto que se almacena como una única versión de la verdad. P.ej. cuando eliminé la duplicación de 5 x en el nivel de tabla y columna, todas las transacciones se redujeron en tamaño; el bloqueo reducido; las Anomalías de actualización desaparecieron. Esa contención sustancialmente reducida y por lo tanto un mayor uso concurrente.

El resultado global fue, por lo tanto, un rendimiento mucho, mucho mayor.

En mi experiencia, que está entregando tanto OLTP como OLAP desde la misma base de datos, nunca ha habido una necesidad de "normalizar" mis estructuras Normalizadas, para obtener una mayor velocidad para las consultas de solo lectura (OLAP). Eso es un mito también.

• No, la "des-normalización" solicitada por otros redujo la velocidad, y fue eliminada. No me sorprende, pero una vez más, los solicitantes se sorprendieron.

Muchos libros han sido escritos por personas que venden el mito. Se debe reconocer que estas personas no son técnicas; ya que están vendiendo magia, la magia que venden no tiene base científica, y evitan convenientemente las leyes de la física en su discurso de venta.

(Para cualquiera que desee disputar la ciencia física anterior, simplemente repetir el mantra no tendrá ningún efecto, por favor proporcione evidencia específica que respalde el mantra).

¿Por qué el mito es prevalente?

Bueno, primero, no es frecuente entre los tipos científicos, que no buscan formas de superar las leyes de la física.

Según mi experiencia, he identificado tres razones principales para la prevalencia:

1. Para aquellas personas que no pueden normalizar sus datos, es una justificación conveniente para no hacerlo. Pueden referirse al libro de magia y, sin ninguna evidencia de la magia, pueden decir reverentemente "ver a un escritor famoso que valida lo que hice". No hecho, más exactamente.

2. Muchos codificadores SQL solo pueden escribir SQL de un solo nivel. Las estructuras normalizadas requieren un poco de capacidad SQL. Si ellos no tienen eso; si no pueden producir SELECT sin usar tablas temporales; si no pueden escribir Subconsultas, se pegarán psicológicamente a la cadera en archivos planos (que es lo que las estructuras "des-normalizadas" son), que pueden procesar.

3. A la gente le encanta leer libros y discutir teorías. Sin experiencia. Especialmente re magia. Es un tónico, un sustituto de la experiencia real. Cualquiera que haya realmente normalizado una base de datos correctamente nunca ha declarado que "la desnormalización es más rápida que lo normalizado". Para cualquiera que diga el mantra, simplemente digo "muéstrame la evidencia", y nunca han producido ninguno. Entonces, la realidad es que la gente repite la mitología por estos motivos, sin ninguna experiencia de normalización . Somos animales de manada, y lo desconocido es uno de nuestros mayores temores.

   Es por eso que siempre incluyo SQL "avanzado" y tutoría en cualquier proyecto.

Mi respuesta

Esta respuesta va a ser ridículamente larga si respondo cada parte de su pregunta o si respondo a los elementos incorrectos en algunas de las otras respuestas. P.ej. lo anterior ha respondido solo un elemento. Por lo tanto, responderé a su pregunta en total sin abordar los componentes específicos, y tomaré un enfoque diferente. Trataré solo en la ciencia relacionada con su pregunta, en la que estoy calificado y con mucha experiencia.

Déjame presentarte la ciencia en segmentos manejables.
El modelo típico de las seis asignaciones completas de implementación a gran escala.

• Estas eran las "bases de datos" cerradas que comúnmente se encuentran en las pequeñas empresas, y las organizaciones eran grandes bancos
• muy agradable para una mentalidad de primera generación, obtener la aplicación, pero un fracaso completo en términos de rendimiento, integridad y calidad
• fueron diseñados para cada aplicación, por separado
• los informes no eran posibles, solo podían informar a través de cada aplicación
• ya que "desnormalizar" es un mito, la definición técnica precisa es que no estaban normalizados
  • Para "desnormalizar" uno debe Normalizar primero; luego revertí el proceso un poco en todos los casos en que la gente me mostró sus modelos de datos "des-normalizados", el hecho simple era que no se habían normalizado en absoluto; por lo que la "des-normalización" no fue posible; simplemente no estaba normalizado
• ya que no tenían mucha tecnología Relacional, o las estructuras y el control de las Bases de Datos, pero fueron pasados ​​como "bases de datos", coloqué esas palabras entre comillas
• como está científicamente garantizado para estructuras no normalizadas, sufrieron múltiples versiones de la verdad (duplicación de datos) y, por lo tanto, una alta contención y baja concurrencia, dentro de cada uno de ellos
• tenían un problema adicional de duplicación de datos en las "bases de datos"
• la organización estaba tratando de mantener todos esos duplicados sincronizados, por lo que implementaron la replicación; que por supuesto significaba un servidor adicional; ETL y scripts de sincronización para ser desarrollados; y mantenido; etc
• no hace falta decir que la sincronización nunca fue suficiente y lo cambiaron para siempre
• con toda esa contención y bajo rendimiento, no fue ningún problema justificar un servidor por separado para cada "base de datos". No ayudó mucho.

Entonces contemplamos las leyes de la física y aplicamos un poco de ciencia.
Implementamos el concepto estándar de que los datos pertenecen a la corporación (no a los departamentos) y la corporación quería una versión de la verdad. La base de datos era puramente relacional, normalizada a 5NF. Pure Open Architecture, para que cualquier aplicación o herramienta de informe pueda acceder a ella. Todas las transacciones en procs almacenados (a diferencia de las cadenas no controladas de SQL en toda la red). Los mismos desarrolladores de cada aplicación codificaron las nuevas aplicaciones, después de nuestra educación "avanzada".

Evidentemente, la ciencia funcionó. Bueno, no era mi ciencia privada ni mi magia, era ingeniería ordinaria y las leyes de la física. Todo se ejecutó en una plataforma de servidor de base de datos; dos pares (producción y DR) de servidores fueron dados de baja y entregados a otro departamento. Las 5 "bases de datos" que totalizan 720 GB se normalizaron en una base de datos que sumaba 450 GB. Se normalizaron alrededor de 700 tablas (muchos duplicados y columnas duplicadas) en 500 tablas no duplicadas. Se realizó mucho más rápido, como en general 10 veces más rápido y más de 100 veces más rápido en algunas funciones. Eso no me sorprendió, porque esa era mi intención, y la ciencia lo predijo, pero sorprendió a la gente con el mantra.

Más normalización

Bien, habiendo tenido éxito con la Normalización en cada proyecto, y la confianza con la ciencia involucrada, ha sido una progresión natural para Normalizar más , no menos. En los viejos tiempos 3NF era lo suficientemente bueno, y las NF posteriores aún no se habían identificado. En los últimos 20 años, solo entregué bases de datos que tenían cero anomalías de actualización, por lo que resulta que según las definiciones actuales de NF, siempre he entregado 5NF.

Del mismo modo, 5NF es genial, pero tiene sus limitaciones. P.ej. La rotación de tablas grandes (conjuntos de resultados no pequeños según la extensión MS PIVOT) fue lenta. Entonces, yo (y otros) desarrollamos una forma de proporcionar tablas normalizadas de modo que el pivoteo fuera (a) fácil y (b) muy rápido. Resulta que ahora que se ha definido 6NF, esas tablas son 6NF.

Dado que proporciono OLAP y OLTP desde la misma base de datos, he encontrado que, de acuerdo con la ciencia, las estructuras más normalizadas son:

• cuanto más rápido realizan

• y pueden usarse de más maneras (por ejemplo, Pivots)

Así que sí, tengo una experiencia consistente e invariable, que no solo se normaliza mucho, mucho más rápido que lo normalizado o "desnormalizado"; más Normalizado es incluso más rápido que menos normalizado.

Un signo de éxito es el crecimiento en la funcionalidad (el signo de la falla es el crecimiento en tamaño sin crecimiento en la funcionalidad). Lo que significaba que inmediatamente nos pidieron más funcionalidades de informes, lo que significaba que normalizamos aún más , y proporcionamos más de esas tablas especializadas (que años más tarde resultaron ser 6NF).

Avanzando en ese tema. Siempre fui un especialista en bases de datos, no un especialista en almacenamiento de datos, por lo que mis primeros proyectos con almacenes no fueron implementaciones en toda regla, sino que fueron asignaciones de ajuste de rendimiento sustanciales. Estuvieron en mi ámbito, en productos en los que me especialicé.
No nos preocupemos por el nivel exacto de normalización, etc., porque estamos viendo el caso típico. Podemos considerar que la base de datos OLTP estaba razonablemente normalizada, pero no era capaz de OLAP, y la organización había comprado una plataforma OLAP completamente separada, hardware; invertido en desarrollar y mantener masas de código ETL; etc. Y después de la implementación, pasó la mitad de su vida administrando los duplicados que habían creado. Aquí se debe culpar a los escritores y vendedores de libros por el desperdicio masivo de hardware y licencias de software de plataforma separadas que hacen que las organizaciones compren.

• Si aún no lo ha observado, le pediría que notara las similitudes entre la "base de datos" típica de primera generación y el almacén de datos típico.

Mientras tanto, de vuelta en la granja (las bases de datos 5NF arriba) seguimos agregando más y más funcionalidades OLAP. Seguro que la funcionalidad de la aplicación creció, pero eso fue poco, el negocio no había cambiado. Piden más 6NF y es fácil de proporcionar (5NF a 6NF es un paso pequeño; 0NF a cualquier cosa, y mucho menos 5NF, es un gran paso, una arquitectura organizada es fácil de ampliar).

Una diferencia importante entre OLTP y OLAP, la justificación básica del software de la plataforma OLAP independiente es que el OLTP está orientado a filas, necesita filas transaccionalmente seguras y rápido; y a OLAP no le importan los problemas transaccionales, necesita columnas y es rápido. Esa es la razón por la que todas las plataformas de BI o OLAP de alta gama están orientadas a columnas, y es por eso que los modelos OLAP (Star Schema, Dimension-Fact) están orientados a columnas.

Pero con las tablas 6NF:

• no hay filas, solo columnas; servimos filas y columnas a la misma velocidad deslumbrante

• las tablas (es decir, la vista 5NF de las estructuras 6NF) ya están organizadas en Dimension-Facts. De hecho, están organizados en más Dimensiones que cualquier otro modelo OLAP podría identificar, porque todas son Dimensiones.

• El pivote de tablas completas con agregación sobre la marcha (a diferencia del PIVOT de un pequeño número de columnas derivadas) es (a) código sencillo y sin esfuerzo y (b) muy rápido

Lo que hemos estado suministrando durante muchos años, por definición, son las bases de datos relacionales con al menos 5NF para el uso OLTP y 6NF para los requisitos OLAP.

• Tenga en cuenta que es la misma ciencia que hemos utilizado desde el principio; pasar de las "bases de datos" no normalizadas típicas a la base de datos corporativa 5NF . Simplemente aplicamos más de la ciencia comprobada y obtenemos órdenes superiores de funcionalidad y rendimiento.

• Observe la similitud entre la base de datos corporativa 5NF y la base de datos corporativa 6NF

• Se elimina todo el costo de hardware OLAP, software de plataforma, ETL, administración y mantenimiento por separado.

• Solo hay una versión de los datos, sin anomalías de actualización ni mantenimiento de los mismos; los mismos datos servidos para OLTP como filas, y para OLAP como columnas

Lo único que no hemos hecho es comenzar con un nuevo proyecto y declarar 6NF puro desde el principio. Eso es lo que he alineado a continuación.

¿Qué es la Sexta Forma Normal?

Suponiendo que maneja la Normalización (no voy a definirla aquí), las definiciones no académicas relevantes para este hilo son las siguientes. Tenga en cuenta que se aplica a nivel de tabla, por lo tanto, puede tener una combinación de tablas de 5NF y 6NF en la misma base de datos:

• Quinta forma normal : todas las dependencias funcionales resueltas en la base de datos
  • además de 4NF / BCNF
  • cada columna no PK es 1 :: 1 con su PK
  • y para ningún otro PK
  • Sin anomalías de actualización
    .
• Sexta forma normal : es la NF irreductible, el punto en el que los datos no pueden ser reducidos o normalizados (no habrá un 7NF)
  • además de 5NF
  • la fila consta de una clave principal y, a lo sumo, una columna que no es clave
  • elimina el problema nulo

¿Cómo se ve 6NF?

Los Modelos de Datos pertenecen a los clientes y nuestra Propiedad Intelectual no está disponible para publicación gratuita. Pero asisto a este sitio web y proporciono respuestas específicas a las preguntas. Necesita un ejemplo del mundo real, por lo que publicaré el Modelo de datos para una de nuestras utilidades internas.

Este es para la recopilación de datos de supervisión del servidor (servidor de base de datos de clase empresarial y SO) para cualquier número de clientes, para cualquier período. Usamos esto para analizar problemas de rendimiento de forma remota y para verificar cualquier ajuste de rendimiento que realicemos. La estructura no ha cambiado en más de diez años (agregada a, sin cambios en las estructuras existentes), es típica del 5NF especializado que muchos años después se identificó como 6NF. Permite un pivoteo completo; cualquier tabla o gráfico que se dibuje, en cualquier Dimensión (se proporcionan 22 Pivotes, pero ese no es un límite); Parte y pica; mezclar y combinar Tenga en cuenta que son todas las dimensiones.

Los datos de monitoreo o Métricas o vectores pueden cambiar (cambios en la versión del servidor, queremos retomar algo más) sin afectar el modelo (puede recordar en otra publicación que EAV es el hijo bastardo de 6NF; bueno, esto es 6NF completo, el padre no diluido, y por lo tanto proporciona todas las características de EAV, sin sacrificar ningún estándar, integridad o poder relacional); simplemente agrega filas.

▶ Monitorear el modelo de datos estadísticos ◀ . (demasiado grande para en línea, algunos navegadores no pueden cargar en línea, haga clic en el enlace)

Me permite producir estos ▶ Gráficos como este ◀ , seis pulsaciones de teclas después de recibir un archivo de estadísticas de supervisión sin procesar del cliente. Observe el mix-and-match; Sistema operativo y servidor en el mismo gráfico; una variedad de Pivots. (Usado con permiso)

Los lectores que no están familiarizados con el Estándar para Modelar Bases de Datos Relacionales pueden encontrar ▶ Notación IDEF1X ◀ útil.

6NF Data Warehouse

Esto ha sido validado recientemente por Anchor Modeling , ya que ahora presentan 6NF como el modelo OLAP de "próxima generación" para data warehouses. (No proporcionan el OLTP y el OLAP a partir de la versión única de los datos, eso es solo nuestro).

Experiencia de almacén de datos (solamente)

Mi experiencia con Data Warehouses solamente (no con las bases de datos 6NF OLTP-OLAP anteriores), ha sido varias asignaciones importantes, a diferencia de proyectos de implementación completos. Los resultados fueron, no es sorpresa:

• consistente con la ciencia, las estructuras normalizadas se realizan mucho más rápido; son más fáciles de mantener; y requiere menos sincronización de datos. Inmon, no Kimball.

• consistente con la magia, después de que normalizo un grupo de tablas, y entrego un rendimiento sustancialmente mejorado mediante la aplicación de las leyes de la física, las únicas personas sorprendidas son los magos con sus mantras.

Las personas con mentalidad científica no hacen eso; no creen ni confían en balas de plata y magia; usan y trabajan arduamente la ciencia para resolver sus problemas.

Justificación válida del almacén de datos

Es por eso que he indicado en otras publicaciones, la única justificación válida para una plataforma de Data Warehouse, hardware, ETL, mantenimiento, etc., separada es donde hay muchas bases de datos o "bases de datos", todas fusionadas en un almacén central, para informar y OLAP.

Kimball

Se necesita una palabra sobre Kimball, ya que él es el principal defensor de la "desnormalización del rendimiento" en los almacenes de datos. Según mis definiciones anteriores, él es una de esas personas que evidentemente nunca se han normalizado en sus vidas; su punto de partida no estaba normalizado (camuflado como "desnormalizado") y simplemente lo implementó en un modelo de Dimensión-Hecho.

• Por supuesto, para obtener cualquier interpretación, tenía que "desnormalizar" aún más, crear más duplicados y justificar todo eso.

  • Por lo tanto, es cierto, de una manera esquizofrénica, que las estructuras "no normalizadas" que no están normalizadas, al hacer copias más especializadas, "mejoran el rendimiento de lectura". No es verdad cuando el todo está tomando en cuenta; es verdad solo dentro de ese pequeño asilo, no afuera.

  • Asimismo, es cierto, de esa manera loca, que donde todas las "mesas" son monstruos, que "las uniones son costosas" y algo que debe evitarse. Nunca han tenido la experiencia de unir mesas y conjuntos más pequeños, por lo que no pueden creer el hecho científico de que más tablas más pequeñas son más rápidas.

  • tienen experiencia en que la creación de "tablas" duplicadas es más rápida, por lo que no pueden creer que la eliminación de duplicados sea aún más rápida.

• sus Dimensiones se agregan a los datos no normalizados. Bueno, los datos no están normalizados, por lo que no se muestran las dimensiones. Mientras que en un modelo Normalizado, las Dimensiones ya están expuestas, como parte integral de los datos, no se requiere ninguna adición .

• ese camino bien pavimentado de Kimball conduce al acantilado, donde más lemmings caen a la muerte más rápido. Los lemmings son animales de manada, siempre que caminen juntos por el camino y, muriendo juntos, mueran felices. Los lemmings no buscan otros caminos.

Todas son historias, partes de una mitología que se juntan y se apoyan mutuamente.

Tu misión

Deberías elegir aceptarlo. Te pido que pienses por ti mismo y que deje de entretener cualquier pensamiento que contradiga la ciencia y las leyes de la física. No importa cuán comunes o místicos o mitológicos sean. Busca evidencia de cualquier cosa antes de confiar en ella. Sea científico, verifique nuevas creencias para usted mismo. Repetir el lema "desnormalizado para el rendimiento" no hará que su base de datos sea más rápida, sino que simplemente lo hará sentir mejor al respecto. Como el niño gordo sentado al margen diciéndose a sí mismo que puede correr más rápido que todos los niños en la carrera.

• sobre esa base, incluso el concepto "normalizar para OLTP" pero hacer lo contrario, "desnormalizar para OLAP" es una contradicción. ¿Cómo pueden las leyes de la física funcionar como se indica en una computadora, pero funcionan al revés en otra computadora? La mente se confunde. Simplemente no es posible, el trabajo de la misma manera en cada computadora.

¿Preguntas?