He creado una tabla llamada STUDENT que consta de IDENTIFICADOR Único, como los de CLAVE PRINCIPAL, junto con otros atributos relacionados como Name, Addr, Gender etc….

Ya no quiero aumentar el tamaño de la tabla de la STUDENT, he creado un débil entidad denominada ACADEMIC RECORDS que almacena el anterior expediente Académico del estudiante.Pero en esta tabla sólo he creado una CLAVE PRINCIPAL Unique ID que hace referencia a la Unique ID del estudiante. y no hay ningún otro atributo junto con Unique ID en la debilidad de la entidad ACADEMIC RECORD Tabla.

Como me llegó a través de la definición DE UNA ENTIDAD DÉBIL que definir su clave principal como una combinación de la debilidad de la entidad atributo y el propietario de la clave principal de la tabla(en este caso STUDENT)

Es mi método de creación de una clave externa como la única clave principal en la tabla ACADEMIC RECORD correcto??

STUDENT Table  
**UID**  NAME  GENDER  ADDRESS  PHNO.

ACADEMIC RECORD Table  
**UID**  HighschoolMarks  GradSchoolMarks
InformationsquelleAutor S_anand | 2010-07-14

2 Comentarios

  1. 5

    No hay nada necesariamente malo con tener una clave primaria que también es totalmente una clave externa. Es una forma común de implementar algo como ‘base de las clases, cuando una entidad tiene una fila en una tabla de base, y puede tener una fila en una o más mesas de extensión (de uno o de cero relación).

    No estoy seguro de que es el más adecuado esquema de lo que estás haciendo, aunque. Si realmente hay una exactamente uno-a-uno de la relación entre academic_records y los estudiantes, parece que son parte de la misma entidad a mí.

    Caso en el cual a partir de una normalización punto de vista de las columnas del registro debe ser parte de la principal de la tabla de alumnos. Tal vez hay una eficiencia razón para denormalise, pero «no quiero aumentar el tamaño de la tabla» normalmente no es una razón suficiente. Las bases de datos pueden hacer frente a grandes tablas.

    • Buen punto sobre la posible uno-a-uno. Yo supuse (tal vez erróneamente), que la razón para la división de las mesas, para permitir una relación de uno a muchos relación entre los estudiantes y los registros académicos.
    • Puede usted explicar cómo este diseño es ‘denormalised’? El ACADEMIC_RECORD mesa parece estar en 5NF a mí. También, se me ocurre que una persona se puede inscribir sin haber completado todos los cursos, por lo tanto «expediente académico» no es un atributo de un «estudiante». Una tabla debe de modelo de cualquiera de las entidades o relaciones y a mí me parece que «expediente académico» es un relación entre un estudiante y los cursos que toman.
    • Es, presumiblemente, no es posible que un estudiante de la universidad para inscribirse sin alta y de la escuela de posgrado de registros. Si bien es discutible si un expediente académico deben ser almacenados en este formulario y si debería ser opcional, el OP parece asumir que una sola academic_record es, de hecho, una parte necesaria de la estudiante de la entidad, y así la división de ellos sería un denormalisation.
    • «Es, presumiblemente, no es posible que un estudiante de la universidad para inscribirse sin alta y de la escuela de posgrado de registros» — «presumiblemente»? Lo que si pasan de un participante examen o da créditos base en la experiencia de trabajo? Para un curso de postgrado, los requisitos previos sería e.g requiere de licenciatura y grado, quizás de una universidad distinta. Cuántas columnas que aceptan valores null se tarda antes de ver la redundancia en el diseño propuesto…?
    • «y así la división de ellos sería un denormalisation» — ¿Qué quieres decir con «un denormalisation»? Usted entiende que la normalización es un proceso, derecho? Puedo proceso de la OP del dos diseño de la tabla de la derecha a través 5NF. Por favor específicos: en el que la forma normal de hacer pensar a las dos de la tabla de diseño se detiene? Puede al menos estamos de acuerdo que está en 1NF (en.wikipedia.org/wiki/1NF)? Si es así, tomar desde allí y decirle a donde crees que se detenga (2NF, 3NF, etc). Gracias de antemano.
    • +1 para explicar uno a uno / cero de la relación. Esto resultó ser mi pensamiento original en evitar un sustituto clave en mi base de datos. Gracias!

  2. 1

    No estoy completamente claro sobre lo que usted está pidiendo, pero suena como que usted está utilizando el método correcto.

    Su STUDENT mesa requiere de una clave primaria para proporcionar una referencia única para cada fila.

    Su ACADEMIC_RECORD tabla también se requiere de una clave primaria para proporcionar una referencia única para cada fila.

    Cada estudiante puede tener cero o más registros académicos, y desea identificar al estudiante para que cada expediente académico pertenece. Puede hacer esto mediante la adición de una columna en la ACADEMIC_RECORD tabla que contiene los id (la clave principal) de la estudiante:

    STUDENT      ACADEMIC_RECORD
                 id
    id <-------> student_id
    name         high_school_marks
    gender       grade_school_marks
    address
    phone_no

    Suponga que tiene tres estudiantes: Alice, Bob y Dave. Alice y Dave tiene tres registros académicos, y Bob tiene dos. Las tablas que se vería algo como esto (he omitido algunas columnas para hacer las cosas más claras):

    STUDENT
    id    name
    1     Alice
    2     Bob
    3     Dave
    
    ACADEMIC_RECORD
    id    student_id
    1     1
    2     1
    3     1
    4     2
    5     2
    6     3
    7     3
    8     3
    • m la creación de una UNIVERSIDAD de la BASE de datos y la tabla ALUMNO tenía muchos atributos así que pensé que en lugar de abarrotar más tal vez voy a crear un débil entidad ACADÉMICA REGISTROS que almacenan los Puntajes de los estudiantes que se matriculen como la Escuela secundaria de las Puntuaciones y de la escuela de Posgrado de las puntuaciones (si se inscribe para Maestros)…y sólo se puede hacer referencia por el UNIQUE_ID del ESTUDIANTE….se preguntaba si podía proceder como este sin tener que preocuparse acerca de la NORMALIZACIÓN de Problemas….
    • Si cada estudiante siempre tendrá exactamente un conjunto de registros académicos para la escuela secundaria y de la escuela de posgrado, entonces usted realmente no necesita para dividir las tablas, puede almacenar toda la información en una tabla. Por supuesto, que puede dividir las tablas si te gusta, si usted siente que esto le da un limpiador de diseño. Sin embargo, si el número de registros académicos para cada estudiante varía (algunos no tienen ninguno, algunos tienen uno, algunos tienen más de uno, y así sucesivamente), entonces la división de las tablas es que vale la pena. Véase la respuesta por bobince, y las observaciones que siguen, para más información sobre esto.

Dejar respuesta

Please enter your comment!
Please enter your name here