2009-11-03 12 views

Respuesta

2

Cuando comienza a preguntarse si una base de datos SQL necesita más normalización.

6

Cuando nota que tiene que repetir los mismos datos, o cuando comienza a usar campos individuales como matrices.

7

Echa un vistazo Wikipedia. El artículo habla sobre la normalización de la base de datos y las diferentes formas (primero, segundo, tercero, etc.). La mayoría de las veces debe apuntar al menos al third normal form. Hay momentos en los que desea relajar las reglas un poco (puede ser demasiado costoso juntar varias tablas, por lo que podría querer desnormalizar un poco) pero, en general, la tercera forma normal es buena.

+0

Realmente. tres formas normales se pueden definir en lenguaje formal. Y no necesita ninguna acción, excepto tomar reglas y aplicarlas. –

3

Si bien esta es una respuesta algo sarcástica, cuando descubres que los datos no están suficientemente normalizados. Hay muchos recursos en la web sobre los niveles (o, más propiamente, "formularios") de normalización, y describen los formularios más completamente que yo aquí. La primera y la segunda forma normal deberían ser bastante necesarias. Si no estás en tercera (o, realmente, cuarta) forma normal, necesitas tener una fuerte justificación de por qué.

Echa un vistazo a Wikipedia article on database normalization.

2

Siempre que tenga una base de datos relacional .... <grin/>

No, en realidad hay leyes, echa un vistazo a esta Wikipedia link.

se llaman las cinco formas normales o algo así. Originario del hombre que inventó las bases de datos relacionales en los años 50/60, E. F. Codd.

"La clave de toda la clave y nada más que la clave, por lo que me ayuda Codd"

Esta es una sinopsis:

  1. primera forma normal (1NF) Tabla representa fielmente una relación y no tiene grupos repetitivos
  2. segunda forma normal (2NF) No no prime atributo en la tabla es funcionalmente dependiente de una parte (subconjunto propio) de una clave candidata
  3. forma normal Tercera (3NF) Cada atributo no prime es no transitivamente dependiente de cada clave de la tabla Cada dependencia funcional no trivial en la tabla es una dependencia de una superclave
  4. cuarta forma normal (4NF) Cada no trivial dependencia multivalor en la tabla es una dependencia de un superclave
  5. forma normal Quinta (5NF) Cada no trivial unirse a la dependencia en la tabla es implicado por los superclaves de la tabla. Dominio/clave forma normal (DKNF) Ronald Fagin (1981) [19] Toda restricción en la tabla es una consecuencia lógica de las restricciones de dominio y de la tabla
  6. Sexta forma normal (6NF) Características de la tabla no unión no trivial dependencias en todo (con referencia a generalizarse unirse operador)
+0

¡Hah! ¿De dónde vino eso? ¡Thz! –

0

¿Qué nivel de normalización que está actualmente en? Si no puede responder eso, supongo que su base de datos es un desastre desagradable. Siempre utilizo la 3ª normal en el diseño inicial y desnormalizo o normalizo aún más si es necesario.

-1

Cuando tiene que buscar a través de grandes cantidades de datos solo para extraer algo de información básica, es decir, qué tipo de categorías de productos hay o algo así.

1

3NF es generalmente todo lo que necesita y se sigue tres reglas:

Cada columna de la tabla debería depender de:

  • la tecla (1NF),
  • la totalidad clave (2NF),
  • y nada más que la clave (3NF) (así que me ayuda Codd es la forma en que la cita suele terminar).

Puede menudo "degradar" a 2NF por razones de rendimiento, proporcionado a entender las implicaciones y sólo cuando se golpea problemas, pero 3NF debe ser el objetivo inicial para todos sus diseños ..

1

Como todos los demás han dicho, sabes cuando empiezas a tener (demasiadas) columnas duplicadas en varias tablas.

Dicho esto, a veces es útil tener columnas redundantes en varias tablas. Esto puede reducir la cantidad de JOIN que debe hacer en consultas complicadas. Solo tenga cuidado de mantener sincronizadas todas las tablas, o simplemente está buscando problemas.

+1

Sí, la desnormalización a 2NF es perfectamente aceptable para obtener rendimiento. Los desencadenantes son una bendición para garantizar que estas columnas redundantes estén sincronizadas. – paxdiablo

0

supongo que estamos hablando de una base de datos transaccional apoyar una aplicación interactiva, sino por lo que vale la pena ...

bases de datos OLAP se utilizan exclusivamente para la presentación de informes y sólo actualizados por procesos ETL pueden beneficiarse de una estructura menos normalizada . En estas aplicaciones, acepta el costo del almacenamiento redundante de datos y la duplicación para el beneficio de rendimiento de menos combinaciones y la mayor facilidad de uso para analistas de datos y analistas de negocios (a veces menos técnicos).

Las bases de datos transaccionales siempre deben normalizarse en la medida de lo posible (al menos 3 NF) y luego se deben desnormalizar selectivamente solo según sea necesario. Y la necesidad de desnormalizar debería idealmente basarse en los resultados reales de las pruebas de rendimiento.

2

Otras personas le han señalado las reglas formales para la normalización. Aquí hay algunas pautas informales que utilizo:

  1. Si tiene columnas en una tabla los nombres de los que sólo se diferencian por un número (por ejemplo Teléfono1 y PHONE2).

  2. Si tiene alguna columnas en una tabla que debe ser llenado sólo cuando otra columna de la tabla se llena.

  3. Si la actualización de un "hecho" en la base de datos (como una dirección de calle) requiere más de una ACTUALIZACIÓN.

  4. Si la misma pregunta pudiera obtener dos respuestas diferentes dependiendo de la tabla de la que obtenga su información.

  5. Si la respuesta a cualquier pregunta no trivial se puede obtener de la base de datos sin unir al menos dos tablas.

  6. Si tiene restricciones de cantidad en la base de datos que no sean "solo 1 de algo permitido" (es decir, "solo se permite una dirección" está bien, pero "solo se permiten dos direcciones" indica una problema de normalización).

Cuestiones relacionadas