Creando base de datos

[matheo]

Hola . Es la primera vez que creo una base de datos usando "phpMyadmin". Resulta que he creado todas las tablas. El esquema es tal que así:


Usuario (DNI_usuario, Tipo_usuario, Nombre, Apellidos, Pais, CP,
Direccion, Poblacion, Provincia, Email, Fecha_nacimiento, Password)

//Estos son los tipos de usuario

Administrador (DNI_usuario)

Medico (DNI_usuario)

*Lo subrrayado atributos clave.
*Lo negrita atributos heredados.


Mi duda es , despues de crearlos en MySQL si quisiera insertar un nuevo usuario y quiero que eso se vea reflejado en la tabla del Administrador, es decir, que herede el DNI_usuario automaticamente. ¿Se puede hacer eso retocando algo en la base de datos en MySQL? ¿O eso esta despues en la funcionalidad del programa?

Espero haberme explicado bien.

[gnzsoloyo]

Si tienes en cuenta que el mismo ID es PK en dos tablas distintas, no hay forma que puedas crear un trigger que actualice ninguna de las dos porque no tienes ningun dato en Usuario que determine eso (y no puedes enviarlo como parte del insert porque no pertenece a la tabla), entonces sólo te queda cargar directamente el dato con un INSERT a nivel programático.

En realidad los esquemas de tablas de ese tipo suelen abarcar tres tablas, pero siendo elas: USUARIO, CARGO y ASIGNACION, para el caso de que cada usuario pueda tener varios cargos (relación N:N), o de dos tablas (USUARIO y CARGO) si sólo pueden tener uno (Relación 1:N)

Esto significaría algo así:

Caso 1:

USUARIO(DNI_usuario, Tipo_usuario, Nombre, Apellidos, Pais, CP,
Direccion, Poblacion, Provincia, Email, Fecha_nacimiento, Password)

ASIGNACION(DNI_usuario, ID_Cargo)

CARGO(DNI_ID_CArgo, NombreCargo)
En este caso la consulta debe cruzar las tres tablas para darte qué usuarios son Médicos y cuáles Administrativos. La ventaja es que Tiene más flexibilidad en cuanto a los cargos, pero requiere llenado de la tabla CARGO primero y dos INSERT todas las veces.

Caso 2:

USUARIO(DNI_usuario, Tipo_usuario, Nombre, Apellidos, Pais, CP,
Direccion, Poblacion, Provincia, Email, Fecha_nacimiento, Password, ID_Cargo)

CARGO(ID_CArgo, NombreCargo)

Este caso es más simple: Sólo cruza dos tablas. Pero un usuario sólo puede ser Administrativo o Medico. No ambos. La ventaja es Que sólo debes insertar a los usuarios y el cargo queda en ese momento establecido sin otro INSERT. La tabla CARGO , por su parte, se carga sólo una vez y sufre pocas modificaciones.

[quimfv]

...
Caso 2:

USUARIO(DNI_usuario, Tipo_usuario, Nombre, Apellidos, Pais, CP,
Direccion, Poblacion, Provincia, Email, Fecha_nacimiento, Password, ID_Cargo)

CARGO(DNI_ID_CArgo, NombreCargo)

Este caso es más simple: Sólo cruza dos tablas. Pero un usuario sólo puede ser Administrativo o Medico. No ambos. La ventaja es Que sólo debes insertar a los usuarios y el cargo queda en ese momento establecido sin otro INSERT. La tabla CARGO , por su parte, se carga sólo una vez y sufre pocas modificaciones.

Habria una tercera solución más simple aún


USUARIO(DNI_usuario, Tipo_usuario, Nombre, Apellidos, Pais, CP,
Direccion, Poblacion, Provincia, Email, Fecha_nacimiento, Password, ID_Cargo)

Tipo_usuario fk referida a idTipousuario

TIPOUSUARIO(idTipo,NombreTipo)

TIPOUSUARIO
idTipo:NombreTipo
1:::::::Administrador
2:::::::Medico

o una cuarta más simple aún

USUARIO(DNI_usuario, Tipo_usuario, Nombre, Apellidos, Pais, CP,
Direccion, Poblacion, Provincia, Email, Fecha_nacimiento, Password, ID_Cargo)


donde se define Tipo_usuario como enum('Administrador','Medico') al crear la tabla.


Estas siempre para el caso en que un usuario puede ser de uno y solo un tipo.

Quim

[gnzsoloyo]

Quimfv:

Habria una tercera solución más simple aún


USUARIO(DNI_usuario, Tipo_usuario, Nombre, Apellidos, Pais, CP,
Direccion, Poblacion, Provincia, Email, Fecha_nacimiento, Password, ID_Cargo)

Tipo_usuario fk referida a idTipousuario

TIPOUSUARIO(idTipo,NombreTipo)

TIPOUSUARIO
idTipo:NombreTipo
1:::::::Administrador
2:::::::Medico

Es lo mismo que esto:

Caso 2:

USUARIO(DNI_usuario, Tipo_usuario, Nombre, Apellidos, Pais, CP,
Direccion, Poblacion, Provincia, Email, Fecha_nacimiento, Password, ID_Cargo)

CARGO(ID_CArgo, NombreCargo)

La cuarta opción tiene el problema que una modificación de la cantidad de opciones requiere la redefinición de la tabla es decir una modificación a la base, mientras que la anterior solamente agregar un registro.
Como opción es válida, pero traería dolores de cabeza de migración, full-backups y en el caso de transacciones remotas.

[quimfv]

Totalmente de acuerdo gnzsoloyo el caso 2 tuyo y 3 mio son iguales una vez corregido ...

CARGO(DNI_ID_CArgo, NombreCargo)

y seria la mejor opción.

Quim

[matheo]

Muy bien , muchas gracias, pero en mi opinión me parece mejor la opción 4º. Ya que un usuario solo puede ser médico o administrador y no va a cambiar nunca o casi nunca su tipo de usuario a lo largo de la vida del sistema. ¿No?

Una pregunta ¿A que os referis cuando escribis "fk" o "PK"? No lo entiendo.

[gnzsoloyo]

PK es el acrónimo de PRIMARY KEY o clave primaria.
FK lo es de FOREIGN KEY, o clave foránea (externa, extranjera o ajena, como quieras llamarla).

En lo que respecta del ejemplo, el problema debes resolverlo analizando el modelo del negocio (Análisis de Sistema básico): ¿El usuario SOLAMENTE puede ser o médico o administrativo? ¿No existe NINGUN caso en que la persona cumpla funciones de médico Y de administrativo? Entonces hazlo de esa forma.

Pero, si por cualquier razón el sistema requerirá a futuro un ajuste porque el rango de cargos de los usuarios se amplía (aunque fuese a un sólo cargo más), el modelo no te servirá. Tendrás que modificar la estructura de la tabla y resolver las inconsistencias de datos consecuentes A MANO.

Algunos sabios consejos que te dan los profesores:
- Tienes que preparar la base lo suficientemente flexible como para soportar todas las tonterías que puedan imaginar los programadores.
- Tienes que observar bien los datos que pretenden aportarte. Es posible que haya información relevante que no te están dando y después te pedirán que resuelvas.

Y el más fundamental:
- Diseña la base para el peor de los escenarios posibles. Siempre tendrás que agregar alguna cosa más, a último minuto, que a los analistas o a los programadores se les ocurrió.

[matheo]

Ok. Muchas gracias por todo.