Diseño de BD: 1ra Forma normal y grupos repetitivos

Question

Para cumplir con la 1ra forma normal, una de las cosas que debe evitar es repetir grupos. Al igual que en vez de:

CustID Name Address  Phone1  Phone2  Phone3 

    102 Jerry 234 East.. 555-2342 555-9854  555-2986 

Debe crear una segunda tabla Número de Teléfono y luego en una unión que se obtendría:

CustID Name  Address  Phone 

102 Jerry 234 East.. 555-2342 
102 Jerry 234 East.. 555-9854 
102 Jerry 234 East.. 555-2986 

A veces, es un poco más ambiguo y es difícil decir cuando una grupo de encabezados de columna califica. Por ejemplo, digamos que tiene, por el momento, dos pruebas que ejecuta en cada pieza de hardware. Y su primer diseño DB proporciona el enfoque más horizontal:

Diseño 1

SN  Test1_Max Test1_Min Test1_Mean Test2_Max Test2_Min Test2_Mean 
2093  23   2   15   54   -24   45 

Obviamente, este es un grupo de repetición, que podría mucho más fácil ser representado como (en una unión entre "partes" y "pruebas"):

Diseño 2

SN  Test  Max Min Mean  
2093 1  23  2  15  
2093 2  54  -24  45  

Sin embargo, podría ir incluso más vertical:

Diseño 3

SN  Test Statistic Value 
2093 1  Max   23 
2093 1  Min   2 
2093 1  Mean   15  
2093 2  Max   54 
2093 2  Min   -24 
2093 2  Mean   45 

3 es el diseño necesario? ¿Cómo decides qué tan vertical para hacerlo? ¿Cuáles son los pros y contras entre el Diseño 2 y 3? Parece que ambos podrían seleccionarse o unirse fácilmente con SQL, con la ventaja dada al Diseño 3 porque podría agregar fácilmente una nueva Estadística sin modificar realmente la estructura de la tabla.

Pero antes de que alguien vaya y dice que cuanto más vertical es mejor, hay veces en que es más ambiguo. Al igual que:

Diseño 4

SN  AverageCurrent (mA) BatteryCapacity (mA) 
2093   200     540 

en su lugar podría ser:

Diseño 5

SN  mA_Measuremnt  Value 
2093 AverageCurrent  200 
2093 BatteryCapacity  540 

Si bien ambos atributos son del mismo dominio (mA), que representan cosas muy diferentes con respecto al componente. En este caso, ¿es mejor el Diseño 4 ya que no es estrictamente un grupo repetitivo? Creo que lo que estoy buscando es un criterio para saber cuándo dividirlo en más tablas y así hacerlo más vertical.

Para resumir este ridículamente largo pregunta, en caso de que sólo se retire y normalizar grupos repetitivos si son exacly el mismo dominio y tener exactamente el mismo significado?. Si ese es el caso, realmente solo el ejemplo de teléfono y probablemente las dos pruebas en el Diseño 1 cumplen con este criterio. Aunque parece que puede haber beneficios de diseño para el Diseño 3 y 5, a pesar de que las estadísticas de Diseño 3 tienen significados diferentes estrictamente hablando, y AverageCurrent y BatteryCapacity definitivamente tienen diferentes significados en el Diseño 5.

Answer 1

El Diseño 2 y el Diseño 4 son las mejores maneras de hacerlo siempre que los resultados no siempre estén presentes (también conocidos como NULL en Desigin 1). Si siempre se toman, entonces el primer diseño está bien.

Creo que repetir grupos en SQL sería en realidad si tiene una columna repleta de valores adicionales, p. Ej. Phone_Number contiene "123-444-4444,123-333-3334" etc.

De todos modos, los diseños posteriores no son óptimos, continúa llevándolos al último nivel y tiene la "Tabla de búsqueda única" http://www.dbazine.com/ofinterest/oi-articles/celko22 o entidad Atributo Valor http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056

De cualquier manera, es casi siempre una mala cosa. Aunque es posible que compartan un tipo de datos/dominio común, el significado es diferente - por lo tanto deben permanecer atributos individuales (maxtemp, mintemp, etc.)

Answer 2

Cuando esté seguro de que una 'prueba' solo tendrá (Máx) Mínimo, Mínimo y Medio -> use diseño 2. Sin embargo, si es posible que haya una nueva 'estadística' en el futuro , es mejor utilizar el diseño 3.

Una respuesta a:

debe sólo quitar y normalizar los grupos repetitivos si son exacly el mismo dominio y tener exactamente el mismo significado?

Aunque en muchos libros, parece que estas formas normales están estrictamente definidas, no lo son. Debería ver para su propia aplicación cuál es la mejor solución ... Normalizar demasiado no siempre es la mejor solución, especialmente cuando ve que siempre une todos los datos nuevamente.

Answer 3

pienso (y que se enseñaba) 1NF como 'todas las filas deben estar la misma longitud 'en lugar de' no grupos repetitivos '. Con esa vista, puede tomar una decisión un poco más fácil de lo siguiente:

En el diseño 1, ¿ambas pruebas SIEMPRE están presentes? Si es así, entonces no es realmente un grupo repetitivo. ¿Están todos los promedios siempre presentes en el diseño 2? ¿Podría haber más (o menos) en una fila determinada?

En el diseño 4, ¿están ambos valores siempre presentes? Si es así, está bien. Si no, entonces se debe usar el diseño 5.

Answer 4

Sugiero mover grupos de repetición solo a tablas separadas si tienen una longitud variable. Si alguna vez tiene solo Phone1, Phone2 y Phone3, no hay necesidad de separarlos. En el otro caso, si el número de repeticiones varía, el mejor diseño es una tabla separada.

Y su concepto de exactamente el mismo dominio y significado no es muy intuitivo porque depende del nivel de abstracción. Phone1 no es exactamente lo mismo que Phone2, pero ambos son números de teléfono. También puede crear una tabla AddressDetails y mover los números de teléfono allí. Pero también el nombre, la calle y la ciudad: todos son detalles de la dirección. Debe encontrar un camino entre los pares genéricos de valores clave y solo las columnas dedicadas.

Answer 5

El diseño 1 está realmente en 1NF si tiene un PK en CustID. Puede ser en 3NF si no hay datos que dependan de otra cosa que la PK, p. Ej. Phone1 no se repite para otro CustID.

No puede decidir sobre el modelo sin los casos comerciales que está tratando de resolver.Entonces, el Diseño 1 podría ser un modelo lógico perfectamente válido.

Answer 6

Ésta es la regla en los grupos de repetición - lo que es funcionalmente dependiente?

Si el valor estadístico es funcionalmente dependiente de SN, Prueba y Nombre de la estadística, a continuación, usted tiene tres elementos clave y un elemento de valor. (SN, Test, Statistic -> Value)

En este caso específico - datos agregados (media, suma, min, max) - tiene ambigüedad porque no se trata de objetos atómicos, se trata de agregados. Estrictamente hablando, no debe almacenar agregados, debe calcularlos. (Sí, sé que no es práctico, pero esa es la teoría relacional.)

Para otros casos, generalmente es obvio cuál es la clave y cuál es el valor para repetir grupos. En este caso, sin embargo, estás en el borde oscuro porque almacenas datos derivables.

Para sus ejemplos, siga el diseño del almacén de datos para localizar una prueba más pragmático:

¿Le picadillo por la otra llave?

Piense en su hecho estadístico como un punto rodeado por tres dimensiones: (SN, de prueba, Estadística). Es esto valido? (. Con los datos de resumen, a menudo es turbia)

En su lugar, vamos a ver los datos de detalle que debería haber guardado: SN, prueba, la puntuación. Claramente hay dos dimensiones (SN, Prueba) y una medida (puntaje) en la intersección de esas dos dimensiones. Podemos derivar cualquier número de estadísticas detalladas de estos datos utilizando ambas dimensiones (SN o de prueba)

Para el ejemplo de la batería, es probable que hace quieren crear una base de datos como EAV en lugar de una base de datos relacional más típica. Sus medidas (AvergaeCurrent y BatteryCapacity) le dan buenas razones para usar un diseño de base de datos Entity-Attribute-Value.

Tenga en cuenta que todo el diseño relacional es una tensión entre las relaciones más largas y triples EAV. Siempre debe equilibrar el "¿esto es clave?" O "¿es esto una columna?" Porque siempre puede etiquetar todo como una clave de atributo y usar un diseño de EAV.

Answer 7

el diseño debe ser determinado por los escenarios de casos de uso y el tipo de consultas que anticipar. ¿Vas a hacer muchas lecturas, escrituras o muchas actualizaciones? ¿Desea obtener todos los datos de prueba para un candidato o desea obtener solo la mejor prueba o algo así? ¿Qué consulta va a ejecutar con más frecuencia?

Diseño 1

SN  Test1_Max Test1_Min Test1_Mean Test2_Max Test2_Min Test2_Mean 
2093  23   2   15   54   -24   45 

Este es el mejor en términos de rendimiento. No requiere JOINs. Si el número de campos es determinista y no arbitrario (ejemplo, cada persona tiene como máximo dos puntajes de prueba), esto es mejor aunque más rígido si decide asociar más de dos puntajes de prueba a una persona. Dado que SN es unique aquí para cada fila, el motor de la base de datos puede devolver tan pronto como encuentre una coincidencia, que es otra razón por la que el rendimiento es mejor.

Diseño 2

SN  Test  Max Min Mean  
2093 1  23  2  15  
2093 2  54  -24  45  

Esto es útil si SN 2093 puede tener pruebas de N en su perfil.De manera similar, si el número de pruebas es, por ejemplo, 10 m, entonces este diseño también es mejor que tener 30 columnas. Cada consulta y comparación será bastante pesada. Esto también es útil si su aplicación requiere consultas en las que quiere obtener la prueba de mejor rendimiento para el alumno 2093 o si desea hacer algunos análisis e informar sobre los puntajes de las pruebas. Esto es más flexible aunque un poco más lento que el anterior. Prefiero esto porque tengo la corazonada de que probablemente te interesen las estadísticas de las pruebas y que los alumnos puedan tener más de dos pruebas cada una.

Diseño 3

SN  Test Statistic Value 
2093 1  Max   23 
2093 1  Min   2 
2093 1  Mean   15  
2093 2  Max   54 
2093 2  Min   -24 
2093 2  Mean   45 

Esto es útil si sus consultas estaban interesados ​​en valores más que nada. Por ejemplo, si está interesado en cuántos valores eran mayores que 80, esto sería rápido. En su escenario, esto no tiene sentido. Terminarás haciendo demasiadas autoinscripciones. ¡Las lecturas serán lentas! Sin embargo, las escrituras probablemente sean más rápidas porque puede ACTUALIZAR rápidamente la puntuación máxima para SN 2093 y Test 2 (suponiendo que la columna Estadística sea una enumeración en lugar de una cadena porque las comparaciones de cadenas pueden ser costosas).

Diseño 4

SN  AverageCurrent (mA) BatteryCapacity (mA) 
2093   200     540 

Diseño aplican 5

SN  mA_Measuremnt  Value 
2093 AverageCurrent  200 
2093 BatteryCapacity  540 

mismos argumentos. Realmente depende de si tiene la intención de optimizar las lecturas o escrituras. Para las aplicaciones web, por ejemplo, si puede salirse con la suya, prefiero Design 1. Por ejemplo, generalmente sabré que un usuario solo tendrá como máximo 3 números de teléfono, por lo que los convertiré en un campo dentro de la columna de usuario y evitar uniones Las lecturas son rápidas, aunque escribir requerirá configurar algunos campos para anular.