¿Cómo se determina hasta qué punto normalizar una base de datos?

Question

Al crear una estructura de base de datos, ¿cuáles son buenas pautas a seguir o buenas formas de determinar hasta qué punto se debe normalizar una base de datos?¿Debería crear una base de datos no normalizada y dividirla a medida que avanza el proyecto?¿Debería crearlo completamente normalizado y combinar tablas según sea necesario para el rendimiento?

Answer 1

Quiere comenzar a diseñar una base de datos normalizada hasta la tercera forma normal.A medida que desarrolla la capa de lógica de negocios, puede decidir que debe desnormalizarse un poco, pero nunca nunca vaya debajo del tercer formulario.Siempre cumpla con el 1er y 2do formulario.Desea desnormalizar por simplicidad del código, no por rendimiento.Utilice índices y procedimientos almacenados para eso :)

La razón por la que no se "normaliza sobre la marcha" es que tendría que modificar el código que ya ha escrito cada vez que modifique el diseño de la base de datos.

Hay un par de buenos artículos:

http://www.agiledata.org/essays/dataNormalization.html

Answer 2

@GrizzlyGuru Un hombre sabio me dijo una vez "normaliza hasta que duela, desnormaliza hasta que funcione".

Aún no me ha fallado :)

No estoy de acuerdo con comenzar con ella en una forma no normalizada; sin embargo, en mi experiencia, ha sido más fácil adaptar su aplicación para manejar una base de datos menos normalizada que una más normalizada.También podría conducir a situaciones en las que funciona "lo suficientemente bien" como para que nunca puedas normalizarlo (¡hasta que sea demasiado tarde!)

Answer 3

La normalización significa eliminar datos redundantes.En otras palabras, una base de datos no normalizada o desnormalizada es una base de datos donde la misma información se repetirá en varios lugares diferentes.Esto significa que debe escribir una declaración de actualización más compleja para asegurarse de actualizar los mismos datos en todas partes; de lo contrario, obtendrá datos inconsistentes, lo que a su vez significa que el resultado de las consultas no es confiable.

Este es un problema bastante grande, por lo que yo diría que la desnormalización duele, y no al revés.

En algunos casos, puede decidir deliberadamente desnormalizar partes específicas de una base de datos, si considera que el beneficio supera el trabajo adicional de actualización de datos y el riesgo de corrupción de datos.Por ejemplo, con los almacenes de datos, donde los datos se agregan por motivos de rendimiento y, a menudo, los datos no se actualizan después de la entrada inicial, lo que reduce el riesgo de inconsistencias.

Pero, en general, tenga cuidado con la desnormalización del rendimiento.Por ejemplo, el beneficio de rendimiento de una unión desnormalizada normalmente se puede lograr mediante el uso vista materializada (también llamado vista indexada), que será tan rápido como consultar una tabla desnormalizada, pero aún protege la coherencia de los datos.

Answer 4

Jeff tiene una descripción bastante buena de su filosofía en su blog: Quizás la normalización no sea normal.La cosa principal es:No exageres con la normalización.Pero creo que un punto aún más importante a destacar es que probablemente no importe demasiado.A menos que esté ejecutando el próximo Google, probablemente no notará mucha diferencia hasta que su aplicación crezca.

Answer 5

La normalización de bases de datos creo que es una forma de arte.

No querrás normalizar demasiado tu base de datos porque tendrás demasiadas tablas y eso hará que tus consultas, incluso de objetos simples, tarden más de lo debido.

Una buena regla general que sigo es normalizar la misma información repetida una y otra vez.

Por ejemplo, si está creando una aplicación de gestión de contactos, tendría sentido tener una dirección (calle, ciudad, estado, código postal, etc.)..) como su propia mesa.

Sin embargo, si solo tiene 2 tipos de contactos, comerciales o personales, ¿necesita una tabla de tipos de contactos si sabe que solo tendrá 2?Para mí no.

Primero comenzaría averiguando los tipos de datos que necesita.Utilice un programa de modelado para ayudar como Visio.No desea comenzar con una base de datos no normalizada porque eventualmente la normalizará.Comience colocando objetos en agrupaciones lógicas; cuando vea datos repetidos, llévelos a una nueva tabla.Continuaría con ese proceso hasta que sienta que tiene la base de datos diseñada.

Deje que las pruebas le indiquen si necesita combinar tablas.Una consulta bien escrita puede cubrir cualquier normalización excesiva.

Answer 6

Creo que comenzar con una base de datos no normalizada y avanzar hacia la normalizada a medida que avanza suele ser la forma más fácil de comenzar.A la pregunta de hasta qué punto normalizar, mi filosofía es normalizar hasta que empiece a doler.Esto puede parecer un poco frívolo, pero generalmente es una buena manera de evaluar hasta dónde llegar.

Answer 7

Tener una base de datos normalizada le brindará la mayor flexibilidad y el mantenimiento más sencillo.Siempre comienzo con una base de datos normalizada y luego la desnormalizo solo cuando hay un problema de la vida real que debe abordarse.

Veo esto de manera similar al rendimiento del código, es decir.escriba código mantenible y flexible y haga concesiones en cuanto al rendimiento cuando saber que hay un problema de rendimiento.

Answer 8

El cartel original nunca describió en qué situación se utilizará la base de datos.Si va a ser cualquier tipo de proyecto de almacenamiento de datos en el que en algún momento necesitará cubos (OLAP) que procesen datos para algún front-end, sería más prudente comenzar con un esquema en estrella (tablas de hechos + dimensión) en lugar de investigar. normalización.Los libros de Kimball serán de gran ayuda en este caso.

Answer 9

Estoy de acuerdo en que normalmente es mejor comenzar con una base de datos normalizada y luego desnormalizarla para resolver problemas muy específicos, pero probablemente comenzaría en Forma normal de Boyce-Codd en lugar de la tercera forma normal.

Answer 10

La verdad es que "depende". Depende de muchos factores que incluyan:

• Código (codificado manualmente o impulsado por herramientas (como paquetes ETL))
• Aplicación principal (procesamiento de transacciones, almacenamiento de datos, informes)
• Tipo de Base de Datos (MySQL, DB/2, Oracle, Netezza, etc.)
• Arquitectura de base de datos (tabular, columnar)
• Calidad DBA (proactiva, reactiva, inactiva)
• Calidad de datos esperada (¿quiere imponer la calidad de los datos a nivel de aplicación o de base de datos?)

Answer 11

Estoy de acuerdo en que se debe normalizar tanto como sea posible y solo desnormalizar si es absolutamente necesario para el rendimiento.Y con vistas materializadas o esquemas de almacenamiento en caché, esto a menudo no es necesario.

Lo que debe tener en cuenta es que al normalizar su modelo le está dando a la base de datos más información sobre cómo restringir sus datos para que pueda eliminar el riesgo de anomalías de actualización que pueden ocurrir en modelos no completamente normalizados.

Si desnormaliza, entonces deberá vivir con el hecho de que puede obtener anomalías de actualización o deberá implementar la validación de restricciones usted mismo en el código de su aplicación.Esto elimina muchos de los beneficios de utilizar un DBMS que le permite definir estas restricciones de forma declarativa.

Entonces, suponiendo la misma calidad de código, es posible que la desnormalización no brinde un mejor rendimiento.

Otra cosa que hay que mencionar es que el hardware es barato hoy en día, por lo que dedicar potencia de procesamiento adicional al problema suele ser más rentable que aceptar los costos potenciales de limpiar datos corruptos.

Answer 12

A menudo, si normalizas todo lo que tu otro software te permite, habrás terminado.

Por ejemplo, cuando utilice la tecnología de mapeo objeto-relacional, tendrá un rico conjunto de semántica para varias relaciones de muchos a uno y de muchos a muchos.Debajo del capó, esto proporcionará tablas de unión con efectivamente 2 claves principales.Si bien es relativamente poco común, la verdadera normalización a menudo brinda relaciones con 3 o más claves primarias.En casos como este, prefiero seguir con el O/R y ejecutar mi propio código para evitar las diversas anomalías de la base de datos.

Answer 13

Intenta usar el sentido común.

Además, algunos dicen, y tengo que estar de acuerdo con ellos, que, si te encuentras uniendo 6 tablas (el número mágico) en la mayoría de tus consultas, sin incluir las relacionadas con informes, entonces podrías considerar desnormalizar un poco.

Answer 14

no lo olvides La madre de todos los debates sobre la normalización de bases de datos en Coding Horror (resumido en el blog de Alta Escalabilidad).