Estoy almacenando datos sobre las estadísticas de béisbol y me gustaría hacerlo con tres tablas: jugadores, bases de datos de bateo y estadísticas de lanzamiento. A los efectos de la pregunta, cada jugador tendrá estadísticas de bateo o estadísticas de pitcheo, pero no ambas.¿Cómo se normalizan las relaciones uno a uno o el otro?
¿Cómo normalizaría tal relación en 3NF?
playerId serían una clave externa en ambos BattingStats y mesas PitchingStats
[y recordar a poner un poco de dimensión temporal (estación, año, y otros) en las tablas de estadísticas]
y por cierto, esta es una mala suposición: por lo que yo sé, los lanzadores también pueden batear.
¿De verdad es necesario no utilizar más de 3 tablas. Normalization normalmente implica dividir un modelo no normalizado en muchas relaciones normalizadas.
Si usted puede tener más de 3 mesas, es posible que desee considerar lo siguiente (en 3NF):
Players: ([player_id], name, date_of_birth, ...)
Batters: ([batter_id], player_id)
Pitchers: ([pitcher_id], player_id)
Batting_Stats: ([batter_id, time_dimension], stat_1, stat_2, ...)
Pitching_Stats: ([pitcher_id, time_dimension], stat_1, stat_2, ...)
atributos en [] definen la clave principal, pero un surrogate key se pueden usar si se prefiere. El atributo player_id en Batters y Pitches debería tener un unique constraint, y también debería ser un foreign key para la relación Jugadores. Batting_Stats y Pitching_Stats también deben tener una clave externa para Batters y Pitching, respectivamente.
Sin embargo, tenga en cuenta que lo anterior no obliga a que un jugador sea solo un bateador o solo un lanzador.
ACTUALIZACIÓN:
Un método que soy consciente de hacer cumplir que un jugador es más que un bateador o solamente un lanzador, es a través de este modelo:
Players: ([player_id], name, date_of_birth, ...)
Roles: ([role_id, role_type], player_id)
Batting_Stats: ([role_id, role_type, time_dimension], stat_1, stat_2, ...)
Pitching_Stats: ([role_id, role_type, time_dimension], stat_1, stat_2, ...)
El role_type debe definir un lanzador o un bateador. Batting_Stats y Pitching_Stats deben tener una clave foránea compuesta para Roles usando (role_id, role_type). Una restricción única en player_id en Roles aseguraría que un jugador solo tenga un rol y solo uno. Finalmente agregue check constraints de modo que Batting_Stats.role_type = 'Batter' y Pitching_Stats.role_type = 'Pitcher'. Esta restricción de verificación garantiza que Batting_Stats siempre describa un bateador, y tenga en cuenta a un lanzador. Lo mismo aplica para Pitching_Stats.
No es inmediatamente obvio para mí cómo la inserción de las tablas Batters y Pitchers mejora el modelo de datos o lo hace más normal. Esas tablas solo parecen repetir los datos que estarían presentes si player_id se usara directamente en las tablas Batting_Stats y Pitching_Stats. –
@Larry: Esas tablas definen el conjunto de bateadores y el conjunto de lanzadores del "grupo de jugadores". Esa * es * información nueva. Entonces las estadísticas de bateo solo pueden referirse a un jugador del "set de bateo", y lo mismo para lanzar. –
Pero esa misma información estaría disponible al examinar la columna player_id en Batting_Stats y Pitching_Stats. Sin embargo, veo un caso adicional manejado por su diseño: definir el rol de un jugador en ausencia de cualquier estadística. Si eso es necesario, entonces las tablas adicionales cumplirían con esa necesidad (como lo haría una columna adicional role_type en Players). –
Sé cómo implementar esto desde una perspectiva práctica (crearía una vista UNIONed sobre las tablas disjuntas y pondría un índice único en la identificación del jugador, por lo tanto, solo pueden aparecer en una tabla).
O en la tabla de jugadores, registre qué tipo de estadísticas tienen, y luego incluya eso en la relación FK de las tablas de estadísticas.
Pero cualquiera de estos es probablemente más cercano al metal de lo que desea.
Ya tiene su solución. Use tres tablas como se describe en su pregunta, con las claves descritas por Steven A. Lowe, a continuación. Es posible que tenga más problemas de normalización _inside_ sus tablas de estadísticas, pero ha modelado correctamente la relación entre los jugadores y las estadísticas. –
@Steven, estoy de acuerdo en que los lanzadores batean (en la Liga Nacional y en el juego de interligas), pero esto es para una herramienta de béisbol de fantasía y las estadísticas de bateo de los lanzadores no cuentan. –