diseño de base de datos relacional (normalizador muchos-a-muchos mapeos)

Question

El siguiente es un ejemplo análogo (y simplificado) a la cuestión de diseño que se me presentan:

Supongamos que tenemos los estudiantes, clases y grados. Los estudiantes pueden ser de muchas clases diferentes. Cada clase tiene muchas estudiante diferente. Y cada (estudiante, clase) par tiene un grado.

¿Debo Esquema de la base de datos (base de datos MySQL) como:

Opción 1)

students table - (student_id, student_name)
classes table - (class_id, class_name)
students_classes table - (student_class_id, student_id, class_id)
grades table - (student_class_id, grade)

Opción 2)

students table - (student_id, student_name)
classes table - (class_id, class_name)
grades table - (student_id, class_id, grade)

O debe ser diseñada como algo más? Opción 2 parece más simple ahora, pero en el futuro, que podría necesitar otras estadísticas relacionadas con cada par (student_id, id_clase) (en cuyo caso, la opción 1 parece un poco mejor? Opción 1 todavía se siente un poco demasiado complicado, aunque).

¿Qué recomienda usted? Gracias.

Answer 1

Opción 3)

students table - (student_id, student_name)
classes table - (class_id, class_name)
students_classes table - (student_class_id, student_id, class_id, grade)

Grado siendo un atributo de clase de los estudiantes.

A menos que grado tiene la posibilidad de convertirse en una entidad de pleno derecho. En cuyo caso:

Opción 4)

students table - (student_id, student_name)
classes table - (class_id, class_name)
students_classes table - (student_class_id, student_id, class_id)
grades table - (grade_id, grade, student_class_id)

Answer 2

Me gustaría ir por la opción 2 personalmente. No hay nada malo con una clave principal compuesta para los grados y capturar la información que necesita en su modelo de datos.

En la opción 1, students_classes no sirve para nada, excepto para tener una clave sustituta.

Editar, después de ver otras respuestas:

• 2NF: grado (no clave) depende únicamente de los estudiantes / clase (clave)
• 3NF: no se aplica. Usted no tiene que no son clave en las dependencias que no son clave
• BCNF: no se aplica, usted tiene sólo una clave candidata

Answer 3

Opción 2 es correcta, excepto que debe ser llamado student_class , reflejando su n :: n función, o inscripción como una entidad. y (student_id, class_id)is el PK.

Grado (como lo han demostrado) es un 1 :: 1 dependencia de esa tecla compuesto (no en uno u otro elemento), y en nada más, por lo que es un atributo de student_class.

Y thereforestudent_classis en 3NF.

Si la gente no empezó pegando ciegamente columnas Idiot en todo lo que se movía, como lo hizo con la opción 1, que sería capaz de entender mejor los datos y así normalizar mejor. Eso (columna Idiot en la Opción 1 como punto de partida) interfería con su intuición de que the(student_id, class_id) fue el identificador; columna Idiot no adicional con su índice adicional era necesario. Luego, cuando se tiene en torno a evaluatinggrade, su dependencia de PK que es obvio.

columnas Idiot daña la capacidad relacional de la base de datos. Si usted tiene decir tres mesas en una jerarquía, y necesitas que consigan unas columnas de la parte superior e inferior mesas, que se ven obligados a pasar por la mesa de centro. Si tenías relacional Identificadores, en lugar de columnas Idiot, que obtiene de la tabla de abajo hacia la mesa principal con tener que leer la tabla media.

Es cierto que sólo la mitad hay tantas combinaciones en una base de datos "normalizado". La verdad es, ya que la base de datos no se normaliza correctamente, sí, que se ven obligados a muchos más se une a los que son necesarios. En una base de datos verdaderamente normalizada, con las mismas tablas, el código requiere mucho menos se une.

Aquí hay una > Modelo de datos para una Colegio < de una asignación reciente, versión simplificada.

> IDEF1X notación < para aquellos que necesitan explicación de los símbolos.

• Nota Se requiere sólo una clave sustituta.

  • Esto es porque en la alternativa, (Apellido + Nombre + Initials_BirthDate + BithDate) sería la PK persona, y que se llevaría a como FK en / mesas nieto 5 niño, que es de 81 bytes, y que no es sensible.
    .

• Ver si se puede apreciar que los identificadores (líneas continuas) se realizan a través de los hijos y nietos; que tienen, y transmitir el significado

• Sería estúpido para agregar sustitutos Claves para TeacherId, StudentId, StaffID, cuando tenemos una buena PERSONID perfectamente, que es la clave externa y ya único. (Las columnas se nombran como tal para identificar sus roles.)

• Todas las reglas de negocios se ejecutaron en DDL: Limitaciones FK; Las restricciones de comprobación; Normas.

  • habitación tiene una clave compuesta de 4 columnas; Ofreciendo tiene una clave Compuesto 3-columna; los dos juntos eliminar reservas dobles.

  • La Oferta y la PK PK Estudiante juntos forman el PK de inscripción (idéntica a esta pregunta, los PK se componen de diferentes columnas, eso es todo).

Answer 4

Soy un fan de la tercera forma normal, donde se tiene Estudiante separada, mesas clase y grado y vincularlos con muchos-a-muchos cuadros como ClassStudent y GradeClass.

Pero depende de cómo desea mantenerlo en el futuro. En última instancia, todo se reduce a una futura ampliación y facilidad de mantenimiento. Es por eso que prefiero 3NF.

Editar

es mucho mejor que la mía.

Answer 5

Todo depende, en realidad. La opción 1 es probablemente la forma más robusta de mantenimiento de la aplicación; la opción 2 podría llegue antes para esta iteración. Será el cambio de la opción 2 -> 1 que ser dolorosa en el futuro? ¿Qué tan seguro está de que se necesita que la flexibilidad adicional?

Yo recomendaría sólo va para la opción 1. Las consultas no será mucho más complicado y si está utilizando un ORM (como ActiveRecord de Rails, entre muchos), entonces la diferencia es prácticamente nula.