Como sería la relacion entre Grado, seccion y alumno?

[poitofritoxd]

Buenas tardes quisiera saber si las relaciones que estoy haciendo entre mis tablas es la correcta. Aquí le muestro lo que he hecho.

CREATE TABLE TB_ALUMNO(
COD_ALU CHAR(10) NOT NULL PRIMARY KEY,
NOM_ALU VARCHAR(100) NOT NULL,
APEPAT_ALU VARCHAR(100) NOT NULL,
APEMAT_ALU VARCHAR(100) NOT NULL,
DIR_ALU VARCHAR(100) NOT NULL,
FEC_NAC DATE NOT NULL,
FEC_REG DATE NOT NULL,
FALTA_ALU INT NOT NULL,
COD_GRA CHAR(5) REFERENCES TB_SECCION(COD_GRA),
COD_SEC CHAR(5) REFERENCES TB_SECCION(COD_SEC)
);
CREATE TABLE TB_GRADO(
COD_GRA CHAR(5) NOT NULL PRIMARY KEY,
NIV_GRA VARCHAR(20) NOT NULL
)
;
CREATE TABLE TB_SECCION(
COD_GRA CHAR(5) REFERENCES TB_GRADO(COD_GRA),
COD_SEC CHAR(5) NOT NULL,
DESC_SEC CHAR(1) NOT NULL,
PRIMARY KEY(COD_GRA,COD_SEC)
)
;

Mi pregunta es. ¿Está bien lo que hecho hasta ahora?. Gracias por sus respuestas.

[oscarbt]

y a que te refieres con la seccion?..explica mejor de q se trata la base de datos...

[gnzsoloyo]

En realidad, NO, porque un Alumno es una persona, con atributos que lo identifican, pero su relación con Grado y Sección es de 1:N:N, ya que un mismo alumno pertenecerá a diferentes grados y secciones según vaya progresando en la escuela. Crear dependencias N:1 con Sección y N:1 con Grado hará que cada registro de un alumno sólo pueda estar relacionado con un único grado y una única sección.
Eso no es válido. La relación Alumno - Grado - Sección determina una tabla donde el discriminante es el año de la cursada.
Donde sí el alumno tendrá una relación 1:1 con Grado es en una posible tabla de Promocion, que expresa el Grado aprobado.

[poitofritoxd]

Hola gnzsoloyo gracias por la respuesta. En realidad te entendi mas o menos lo que me dijiste, crees que puedas modificar el script que puse y decirme como seria lo correcto?. gracias.

[gnzsoloyo]

Para darte el script me tienes que decir con qué DBMS estás trabajando, porque la sintaxis cambia entre algunos de ellos.
Con lo que te puse deberías poder resolverlo tu: Sólo necesitas eliminar las FK de TB_ALUMNO y crear una tabla con los tres códigos más un campo con el año y declarar la PK con los cuatro campos.

Agregale la tabla faltante a esto:

Código SQL:

CREATE TABLE TB_ALUMNO(
COD_ALU CHAR(10) NOT NULL PRIMARY KEY,
NOM_ALU VARCHAR(100) NOT NULL,
APEPAT_ALU VARCHAR(100) NOT NULL,
APEMAT_ALU VARCHAR(100) NOT NULL,
DIR_ALU VARCHAR(100) NOT NULL,
FEC_NAC DATE NOT NULL,
FEC_REG DATE NOT NULL,
FALTA_ALU INT NOT NULL);
 
CREATE TABLE TB_GRADO(
COD_GRA CHAR(5) NOT NULL PRIMARY KEY,
NIV_GRA VARCHAR(20) NOT NULL);
 
CREATE TABLE TB_SECCION(
COD_GRA CHAR(5) REFERENCES TB_GRADO(COD_GRA),
COD_SEC CHAR(5) NOT NULL,
DESC_SEC CHAR(1) NOT NULL,
PRIMARY KEY(COD_GRA,COD_SEC));
 

[poitofritoxd]

Ahora si te entendi a la perfeccion muchas gracias!. Solo me queda una duda con otras tablas q tengo que son la de Asistencia y Justificacion.
Este es mi script:

Código SQL:

CREATE TABLE TB_ESTADO_REVISION_JUSTIFICACION(
EST_REV_JUS CHAR(1) NOT NULL PRIMARY KEY,
DESC_EST_REV VARCHAR(20) NULL
)
;
CREATE TABLE TB_JUSTIFICACION(
FEC_ASI DATE REFERENCES TB_ASISTENCIA(FEC_ASI),
COD_ALU CHAR(10) REFERENCES TB_ASISTENCIA(COD_ALU),
COD_JUS INT NOT NULL,
DESC_JUS VARCHAR(1000) NULL,
FEC_REG DATE NULL,
EST_REV_JUS CHAR(1) REFERENCES TB_ESTADO_REVISION_JUSTIFICACION(EST_REV_JUS),
MOT_JUS VARCHAR(20) NOT NULL,
PRIMARY KEY(FEC_ASI,COD_ALU,COD_JUS)
)
;
CREATE TABLE TB_ASISTENCIA(
FEC_ASI DATE NOT NULL,
COD_ALU CHAR(10) NOT NULL REFERENCES TB_ALUMNO(COD_ALU),
EST_ASI VARCHAR(20) NOT NULL REFERENCES TB_ESTADO_ASISTENCIA(EST_ASI),
PRIMARY KEY(FEC_ASI,COD_ALU)
)
;
CREATE TABLE TB_ESTADO_ASISTENCIA(
EST_ASI VARCHAR(20) NOT NULL PRIMARY KEY,
DESC_ASI VARCHAR(20) NOT NULL
)
;
 

Lo que intento hacer es relacionar la tabla TB_ASISTENCIA con la tabla TB_JUSTIFICACION, en donde una justificación se le pueda asignar a una o MUCHAS asistencias con el estado 'AUSENTE'. Mi criterio fue el siguiente: como solo en el caso de que las asistencias tengan el estado ausente se le puedan asignar una justificacion, entonces la entidad justificacion sería débil y por eso es que la llave primaria de la tabla TB_ASISTENCIA (FEC_ASI y COD_ALU) ahora son tambien parte de la llave primaria de la tabla TB_JUSTIFICACION. Mi pregunta es:
¿Es esto correcto?¿Está bien que la tabla Justificacion sea débil?

Te agradezco un monton.

[gnzsoloyo]

¿Es esto correcto?¿Está bien que la tabla Justificación sea débil?

Desde esa visión, si, porque para existir un registro de esa tabla, debe forzosamente existir un registro en asistencia que determine una inasistencia. Si la inasistencia no existe, la justificación tampoco.
En este tipo de cosas se entremezcla la aplicación (donde se controla el estado de inasistencia), con la base (donde se dan de alta los registros). Son las zonas grises de la interaccion aplicación - datos.

[poitofritoxd]

Pero el problema me surge cuando intento ingresar los datos. Te doy el ejemplo:

Tengo estos 2 registros en la tabla TB_ASISTENCIA:

1º registro:
2009-12-12
a0001
'AUSENTE'

2º registro:
2009-12-13
a0001
'AUSENTE'


La tabla TB_JUSTIFICACION tiene como llave primaria (FEC_ASI,COD_ALU,COD_JUS), lo que quiero es asignarle una justificacion a estas dos inasistencias ingresando un solo registro a la tabla TB_JUSTIFICACION, pero veo que no puedo, una alternativa creo que seria poner como FK el COD_JUS en la tabla TB_ASISTENCIA, pero de esa manera la tabla TB_JUSTIFICACION ya no sería debil y ahi está el problema.

[gnzsoloyo]

La tabla TB_JUSTIFICACION tiene como llave primaria (FEC_ASI,COD_ALU,COD_JUS), lo que quiero es asignarle una justificacion a estas dos inasistencias ingresando un solo registro a la tabla TB_JUSTIFICACION, pero veo que no puedo, una alternativa creo que seria poner como FK el COD_JUS en la tabla TB_ASISTENCIA, pero de esa manera la tabla TB_JUSTIFICACION ya no sería debil y ahi está el problema.

No inventes cosas que violan el modelo relacional, o que no tienen justificaciones, solamente para ahorrarte trabajo de programación en la interfase.
No puedes poner dos justificaciones, que son para dos fechas diferentes, insertando un sólo registro en Justificaciones. Eso es imposible, porque la fecha a ingresar es única por alumno y es parte de la clave primaria.
Estás confundiendo el modelo de datos con los procesos de carga. No son la misma cosa. Una es bases de datos y la otra aplicaciones de usuario.
Si estás ingresando las inasistencias, las mismas deben estar en la tabla antes de intentar ingresar sus justificaciones. El que puedas ingresarlas todas en un formulario, nada tiene que ver con la bases de datos. Es en la aplicación en la que estableces la secuencia de ingresos, respetando el modelo de datos, o de lo contrario tendrás problemas de integridad y consistencia.

Para que quede claro: No se puede, ni usando triggers, hacer que se ingrese un registro en Justificación al mismo tiempo que estás ingresando la inasistencia. No solamente por problemas de integridad, sino porque tampoco puedes mandarle a una tabla datos para columnas que no tiene, a fin de que en un trigger las ponga en otra tabla. Por lo mismo, no puedes mandarle dos fechas a la tabla Justificación, cuando la misma tiene solo una columna para usar...
No hay DBMS que te lo admita.

[poitofritoxd]

Tienes razon en todo lo que dices, pero yo no quiero asignar una justificacion al mismo tiempo que se ingresa la asistencia, lo que quiero es que luego de haber varias inasistencias por parte de un alumno, otra persona por ejemplo el Padre, desde una lista de inasistencias, seleccione las que desee y a esas inasistencias registrarles una justificación. No se si me dejo entender

[gnzsoloyo]

Si. Se entiende mejor. El tema es que eso es un asunto procedimental que se debe resolver en la aplicación.
En general, eso implica 2 pasos respecto de la base de datos:
1. Lectura de la tabla con los datos necesarios.
2. Envío de un insert múltiple a la base.

Los INSERT múltiples son simplemente instrucciones INSERT de varios grupos de VALUES separados por comas:

Código SQL:

INSERT INTO tabla(a, b, c, d)
VALUES(a1, b1, c1, d1), (a2, b2, c2, d2),...(an, bn, cn, dn);
 

De esa forma se envía una sola instrucción INSERT con todos los valores a poner.
Eso sería lo más cercano a lo que necesitas. Toda otra opción dependerá del lenguaje de programación elegido, como por ejemplo los .Net, que permiten interactuar directamente con objetos de la base a través de ADO.
De todos modos, todo insert múltiple debe ser creado dinamicamente en la aplicación para luego ser enviado a ejecución.