none
Diseño de BD llave compuesta RRS feed

  • Pregunta

  • buenas tardes les adjunto la imagen del diseño de la base de datos

    como pueden ver la tabla HumanResourceRecords  guarda los datos de un recurso o una persona

    la tabla course guarda cursos y tiene el id de humanResource para la relacion

    lo mismo con las tablas certificates y academicTitles esto por que un recurso puede tener n cursos y n certificaciones

    y n titulos

    con eso puedo discrimar funciona lo que quiero, la duda es es correcto este diseño???

    y la otra duda las llaves primarias de la tabla course, certificates y academicTitles deberian seri llaves compuestas

    entre el ID de HumanResourceRecords y el id de cada tabla???

    martes, 5 de diciembre de 2017 23:30

Respuestas

  • Sí, es un diseño válido, y de hecho es bastante común. Por ejemplo, no es raro encontrar aplicaciones que tienen una tabla de Clientes y otra de Proveedores y ambas contienen un IdTercero apuntando a una tabla de terceras personas, y cosas por el estilo. En este sentido no hay problema.

    Sin embargo, nótese que este diseño úncamente te permita saber a partir de una persona, qué cursos, certificados y títulos tiene esa persona. Pero no te conserva ninguna relación que te diga qué curso dio lugar a qué certificados o a qué títulos. Si necesitases conservar esta información, requerirías un diseño distinto.

    En cuanto a las llaves primarias de la tabla course, certificates y academicTitles tienes dos opciones. Una es usar como clave primaria un identificador único (por ejemplo, un identity o un GUID), en cuyo caso no sería compuesta. La otra alternativa es usar una llave compuesta consistente en el idHumanResource más un número secuencial (u otro valor específico) por recurso. Por ejemplo, para la persona 1 tienes tres cursos numerados del 1 al 3 y esos dos valores forman la clave primaria. Yo personalmente me inclino por la primera opción; la segunda se usaría cuando el secuencial es significativo, como por ejemplo en una tabla de líneas de factura, cuya clave es la combinación de número de factura más número de línea.

    • Marcado como respuesta niqel jueves, 7 de diciembre de 2017 6:32
    miércoles, 6 de diciembre de 2017 12:20

Todas las respuestas

  • Sí, es un diseño válido, y de hecho es bastante común. Por ejemplo, no es raro encontrar aplicaciones que tienen una tabla de Clientes y otra de Proveedores y ambas contienen un IdTercero apuntando a una tabla de terceras personas, y cosas por el estilo. En este sentido no hay problema.

    Sin embargo, nótese que este diseño úncamente te permita saber a partir de una persona, qué cursos, certificados y títulos tiene esa persona. Pero no te conserva ninguna relación que te diga qué curso dio lugar a qué certificados o a qué títulos. Si necesitases conservar esta información, requerirías un diseño distinto.

    En cuanto a las llaves primarias de la tabla course, certificates y academicTitles tienes dos opciones. Una es usar como clave primaria un identificador único (por ejemplo, un identity o un GUID), en cuyo caso no sería compuesta. La otra alternativa es usar una llave compuesta consistente en el idHumanResource más un número secuencial (u otro valor específico) por recurso. Por ejemplo, para la persona 1 tienes tres cursos numerados del 1 al 3 y esos dos valores forman la clave primaria. Yo personalmente me inclino por la primera opción; la segunda se usaría cuando el secuencial es significativo, como por ejemplo en una tabla de líneas de factura, cuya clave es la combinación de número de factura más número de línea.

    • Marcado como respuesta niqel jueves, 7 de diciembre de 2017 6:32
    miércoles, 6 de diciembre de 2017 12:20
  • Tendrias un ejemplo

    de como generar una llave primaria compuesta en la tabla course que se componga de el IdHumanResource y un autonómico de la tabla course, esto lo quiero hacer por que tengo la impresión de que cuando creé ese modelo de datos en EF si es una llave foranea el modelo de EF se genera diferente y mejor, cuando uno usa llaves compuestas

    hay esa es una duda tambien, cambia el modelo del Entity framework cuando son llaves compuestas y llaves simples

    como crearía una llave compuesta de el idHiumanResource y un autonumerico de course

    miércoles, 6 de diciembre de 2017 14:58
  • Como lo indica Alberto cualquiera de las 2 opciones serían válidas, aunque algunos puristas consideran que la segunda opción refleja mayor claridad de lo que se está diseñando.

    Respecto a la manipulación con EF, casi siempre he trabajado con la primera forma (llave simple), se marca la propiedad ID con la anotación Key (o se establece  a través de fluent Api) y para el caso de un motor SQL Server la columna se marca como Identity, para el caso de Oracle se crea un Secuenciador y un Trigger que va incrementando el Secuenciador en cada Insert para la tabla en cuestión.

    Me gustaría saber cómo trabaja EF para el caso de llaves compuestas. Por ejemplo con ADO yo habría creado una función que incrementa los Cursos, Certificados o Títulos por cada Recurso.

    Saludos.

    miércoles, 6 de diciembre de 2017 17:16