¿Qué tan lejos tomar la normalización en el diseño de la base de datos?

Question

tengo estas tablas: (. "CreatedByID" es una foreign key para los empleados)

Projects(projectID, CreatedByID) 
Employees(empID,depID) 
Departments(depID,OfficeID) 
Offices(officeID) 

y tengo una consulta que tengo que correr para casi todas las instancias de una aplicación web que agarra todo proyectos en una oficina. ¿Es una mala práctica agregar una columna redundante de "OfficeID" a los proyectos para eliminar las tres uniones? ¿O debería hacer lo siguiente?

SELECT * 
FROM Projects P 
JOIN Employees E ON P.CreatedBY = E.EmpID 
JOIN Departments D on E.DepID = D.DepID 
JOIN Offices O on D.officeID = O.officeID 
WHERE O.officeID = @SomeOfficeID 

Hasta que vea algún problema de rendimiento?

En programación de aplicaciones, que siempre siguen la regla de "Escribir con las mejores prácticas primero y optimizar después", pero cuando se trata de diseño de base de datos y la normalización como esta Me preocupa porque los administradores de bases de datos siempre están advirtiendo sobre el costo de las combinaciones.

Answer 1

La desnormalización tiene la ventaja de SELECT s rápido en consultas grandes.

Las desventajas son:

• se necesita más de codificación y el tiempo para asegurar la integridad (que es más importante, en su caso)

• Es más lento en DML (INSERT/UPDATE/DELETE)

• se necesita más espacio

Como fo r optimización, puede optimizar para una consulta más rápida o para un DML más rápido (como regla, estos dos son antagonistas).

Optimizar para una consulta más rápida a menudo implica duplicar datos, ya sea desnormalización, índices, tablas adicionales de lo que sea.

En el caso de los índices, el RDBMS lo hace por usted, pero en caso de desnormalización, deberá codificarlo usted mismo. ¿Qué sucede si Department se mueve a otro Office? Tendrás que arreglarlo en tres tablas en lugar de una.

Así que, como puedo ver en los nombres de sus tablas, no habrá millones de registros allí. Entonces será mejor que normalices tus datos, será más simple de administrar.

Answer 2

El costo de las uniones no debería preocuparte demasiado en sí mismo (a menos que intentes escalar a millones de usuarios, en cuyo caso debes preocuparte).

Estaría más preocupado por el efecto en el código que está llamando a esto. Las bases de datos normalizadas son mucho más fáciles de programar, y casi siempre conducen a una mejor eficacia dentro de la propia aplicación.

Dicho esto, no se normalice más allá de los límites de la razón. He visto la normalización por el bien de la normalización, que generalmente termina en una base de datos que tiene una o dos tablas de datos reales, y 20 tablas rellenas con nada más que claves externas. Eso es claramente excesivo. La regla que normalmente uso es: si los datos en una columna se duplicarían, debería normalizarse.

Answer 3

DBA debe preocuparse si su base de datos no está normalizada correctamente para empezar. Después de medir cuidadosamente el rendimiento y determinar que tiene cuellos de botella puede comenzar a desnormalizar, pero sería extremadamente cauteloso.

Answer 4

Normalizar hasta que duela, a continuación, eliminar la normalización hasta que se trabaja

Answer 5

Si estás usando números enteros (o BIGINT) como el ID de y son la clave principal agrupada que debe estar bien.

Aunque parece que siempre será más rápido encontrar una oficina de un proyecto, ya que siempre está buscando claves principales, el uso de índices en las claves externas hará la diferencia mínima ya que los índices también cubrirán las claves principales .

Si alguna vez encuentra la necesidad de desnormalizar los datos, puede crear una tabla de caché en un programa o activador.

Answer 6

Siempre normalizar todo lo necesario para eliminar problemas de integridad de la base de datos (es decir, posibles datos duplicados o faltantes).

Incluso si hubo mejoras en el rendimiento debido a la desnormalización (que generalmente no es el caso), el precio de perder la integridad de los datos es demasiado alto para justificarlo.

Simplemente pregúntele a cualquiera que haya tenido que trabajar para solucionar todos los problemas ocultos de una base de datos heredada si preferirían buenos datos o aumentos de velocidad insignificantes (si los hubiera).

Además, como lo menciona John: si finalmente necesita datos desnormalizados (velocidad/informes/etc), créelo en una tabla separada, conservando los datos brutos.

Answer 7

Normalice para modelar los conceptos en su diseño y su relación. Piense en qué relaciones pueden cambiar y qué cambio significará en términos de su diseño.

En el esquema que publicó, hay algo que me parece un error evidente (que puede no ser un error si tiene un caso especial en términos de cómo funciona su organización): hay una suposición implícita de que cada el departamento está exactamente en una oficina, y todos los empleados que están en el mismo departamento trabajan en esa oficina.

¿Qué pasa si el departamento ocupa dos oficinas?

¿Qué pasa si un empleado nominalmente pertenece a un departamento, pero trabaja en una oficina diferente (suponiendo que se refiera a oficinas físicas)?

Answer 8

En el ejemplo dado, los índices configurados correctamente en las tablas deben permitir que las uniones ocurran extremadamente rápido y se escalarán bien a los 100,000 de filas. Este suele ser el enfoque que tomo para evitar el problema.

Hay ocasiones en que los datos se escriben una vez y se seleccionan durante el resto de su vida en los que realmente no tiene sentido hacer una docena de combinaciones cada vez.

Answer 9

Es mejor mantener ese esquema en Tercera Forma Normal y dejar que su DBA se queje sobre el costo de las uniones.

Answer 10

Me preocupan más los DBA que le advierten sobre el costo de las uniones, a menos que se encuentre en una situación altamente patológica.

Answer 11

No debe considerar la desnormalización antes de haber intentado todo lo demás.

¿Es el rendimiento de esto realmente un problema? ¿Su base de datos tiene alguna característica que pueda usar para acelerar las cosas sin comprometer la integridad? ¿Se puede aumentar el rendimiento mediante el almacenamiento en caché?

Answer 12

No desnormalizar.

Diseñe sus tablas de acuerdo con principios de diseño simples y sólidos que harán que sea fácil implementar el resto de su sistema. Fácil de construir, poblar, usar y administrar la base de datos. Fácil y rápido para ejecutar consultas y actualizaciones en contra. Fácil de revisar y extender el diseño de la mesa cuando la situación lo requiera, e innecesario por razones livianas y transitorias.

Un conjunto de principios de diseño es la normalización. La normalización genera tablas que son fáciles y rápidas de actualizar (incluidas las inserciones y eliminaciones). La normalización evita las anomalías de actualización y evita la posibilidad de una base de datos que se contradice a sí misma. Esto evita una gran cantidad de errores al hacerlos imposibles. También evita una gran cantidad de cuellos de botella de actualización haciéndolos innecesarios. Esto es bueno.

Existen otros conjuntos de principios de diseño. Conducen a diseños de mesa que están menos que completamente normalizados. Pero eso no es "desnormalización". Es solo un diseño diferente, algo incompatible con la normalización.

Un conjunto de principios de diseño que conduce a un diseño radicalmente diferente de la normalización es el diseño del esquema en estrella. El esquema de estrella es muy rápido para consultas. Incluso se pueden realizar uniones y agregaciones a gran escala en un tiempo razonable, dado un buen DBMS, buen diseño físico y suficiente hardware para realizar el trabajo. Como era de esperar, un esquema de estrella sufre anomalías de actualización. Debe programar estas anomalías cuando mantiene la base de datos actualizada. En general, necesitará un proceso ETL cuidadosamente controlado y cuidadosamente creado que actualice el esquema en estrella desde otras fuentes de datos (tal vez normalizadas).

El uso de datos almacenados en un esquema de estrella es dramáticamente fácil. Es tan fácil que al usar algún tipo de OLAP y motor de informes, puede obtener toda la información necesaria sin escribir ningún código y sin sacrificar demasiado el rendimiento.

Se necesita un análisis de datos bueno y algo profundo para diseñar un buen esquema normalizado. Los errores y omisiones en el análisis de datos pueden dar como resultado dependencias funcionales no descubiertas. Estos FD no descubiertos resultarán en desvíos involuntarios de la normalización.

También se necesita un análisis de datos bueno y algo profundo para diseñar y construir un buen esquema de estrella. Los errores y las omisiones en el análisis de datos pueden dar como resultado elecciones desafortunadas en dimensiones y granularidad. Esto hará que ETL sea casi imposible de construir, y/o hará que la capacidad de carga de información de la estrella sea inadecuada para las necesidades emergentes.

El análisis de datos bueno y algo profundo no debe ser una excusa para la parálisis del análisis. El análisis debe ser correcto y razonablemente completo en un corto período de tiempo. Más corto para proyectos más pequeños. El diseño y la implementación deberían poder sobrevivir algunas adiciones tardías y correcciones al análisis de datos y a los requisitos, pero no a un torrente constante de revisiones de requisitos.

Esta respuesta se amplía a su pregunta original, pero creo que es relevante para el diseñador de la base de datos.

Answer 13

Normalización: es una decisión de calidad.

Denormalización: es una decisión de rendimiento.

Por eso se dice -

Normalizar hasta que duela, de considerarse algo normal hasta que se trabaja.

---

Las siguientes decisiones de calidad dicen que es el menos forma normal que se puede vivir con:

1. ¿Cuánto no redundancia es importante para las tablas?
2. ¿Qué tan rápido desea la administración de datos?
3. ¿Qué tan clara quiere la relación entre sus tablas?

las siguientes decisiones de rendimiento dicen lo que es el más alto Forma Normal aceptable para sus clientes/usuarios/aplicaciones:

1. es la respuesta de mi base de datos lo suficientemente rápido?
2. ¿Hay demasiadas uniones que causan una desaceleración?

Después de haber fijado la menor y la forma normal más alta aceptable en su caso, designe la forma normal en cualquier lugar entre.