Consulta sobre diseño de DB

[angelsds]

Bueno primero que nada, agradezo a esta pagina ya que he aprendido mucho aquí pero hasta ahora fue que me registré para colaborar/preguntar sobre cosas de programacion web, trabajo actualmente como programador web (novato) y uso Jquery y tambien BD MySQL, mi duda es la sig:

Estoy diseñando una base de datos y tengo 2 tablas: tramites y analistas
El administrador del sistema debe asignarle un analista a un tramite por lo uqe tengo el siguiente diseño (no definitivo ya que debo comprobar si necesito mas datos):

Tabla

tramites:
cod_tramite (PK NotNull AI)
nombre de tramite
fecha
status: (puede ser por agisnar y asignado)
empresa (que solicito el tramite)


tabla
Analista
cod_analista (PK notnull AI)
nombre
cedula de identidad

tabla tramite_analista
id_asignacion (PK not null AI)
cod_tramite (FK)
cod_analista (FK)
fecha_asignacion


mi pregunta es, la 3era tabla que cree es una tabla auxiliar, hice bien creando esa tabla? o hay una forma mas optima de hacer el diseño?

De antemano muchas gracias

[Heimish2000]

Depende. ¿Un trámite siempre va a un único analista o puede ir a varios? Una vez que el tramite está asignado a un analista, ¿se puede cambiar la asignación a otro? Si es que sí, ¿Quieres guardar un histórico de asignaciones a analistas o no te hace falta?

[gnzsoloyo]

Una tabla relacional (N:N) no requiere ID propio a menos, y solo en ese caso, que esa relación pueda tener cardinalidad N.
En tu caso sería si y sólo si el mismo trámite se le asigna al mismo analista más de una vez.
Lo correcto sería:

tabla tramite_analista
cod_tramite (PK - FK)
cod_analista (PK - FK)
fecha_asignacion

Es decir: La PK de la tabla está formada por ambas FK.

[angelsds]

Iniciado por Heimish2000

Depende. ¿Un trámite siempre va a un único analista o puede ir a varios? Una vez que el tramite está asignado a un analista, ¿se puede cambiar la asignación a otro? Si es que sí, ¿Quieres guardar un histórico de asignaciones a analistas o no te hace falta?

Sí amigo, un tramite para un único analista, si "deberia poder" asignarselo a otro en dado caso que el analista que se le asigno se desaparezca del mapa y si quiero tener un histórico de las asignaciones por eso agregué el campo fecha




Con respecto a gnzsoloyo

Muchas gracias entiendo lo que dices, pero ese tramite se le asigna solo a UN analista es decir tengo el tramite 008 y se lo asigné al analista 003 por lo tanto ningun otro analista puede obtener dicho tramite

entonces, el diseño que yo hice con el PK está bien? O debo seguir tu recomendacion?

[Heimish2000]

Entonces tu diseño está bien porque puedes sacar un histórico y ver el analista actual, incluso con la PK por si un trámite pasa dos veces por el mismo analista.

[gnzsoloyo]

Muchas gracias entiendo lo que dices, pero ese tramite se le asigna solo a UN analista es decir tengo el tramite 008 y se lo asigné al analista 003 por lo tanto ningun otro analista puede obtener dicho tramite

En ese contexto, el campo id_asignacion no tiene razón de existir, porque jamás un mismo trámite se dará más de una vez al mismo analista.
El diseño es que te lo planteo: Sólo tres campos, dos que son FK de su tabla y PK en la tabla relacional, más el de fecha.
Poner ese ID autoincremental como entrada y la fecha y hora también termina siendo lógicamente redundante.

Además, con la fecha como discriminante en esa tabla, ese diseño soportaría incluso, que un trámite pueda asignarse más de una vez al mismo analista en diferentes momentos del tiempo. Sólo requeriría que la PK tomase los tres campos.

No necesitas ese ID.

¿Qué parte no se entiende?