Problema base de datos!

Pues la verdad es que si, que está mal el modelo E/R.
Te recomendaria que pusieras la cardinalidad para no liarte.
Te falta pasar las FK a las tablas respectivas (Por ejemplo, en pmrs tienes que pasar como FK la PK de tipo). Cuando hayas puesto la cardinalidad te saldrá solo el tema de FK
Con este modelo, tal como lo tienes no te van a salir las tablas normalizadas.

Dame un rato y te hago uno, pero tu enunciado no es que esté muy claro ^^ (vamos que hay cosas que no entiendo )

EDIT: Por cierto, la relacion pmrs - vuelo deberia ser de M:N, por lo que deberias sacar otra tabla entre medias (una llamada pmrs-vuelo mismo) y con eso incluso te podrias quitar las tablas llegadas y salidas

EDIT2: Por que la tabla "Tipo" tiene tantas columnas? no te conviene mas algo asi como "id_tipo/ descripcion" (para abreviar) donde descripcion sea el tipo de minusvalia?

EDIT3: que diferencia o que relacion tiene "fechas" con "llegadas" y "salidas"?

Coincido con #3.

Menudo cacao tienes ahí montado. Las relaciones se superponen, la verdad es que no tiene demasiado sentido lo que planteas. Deberías rehacerlo.

Te recomendaría ver ejemplos de diagramas E/R:

http://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n

Deberías anotar la cardinalidar y sobre todo no meter todas las relaciones a una relación que las agrupe hasta una tabla.

Cada relación une dos tablas o conjuntos de tablas si se trata de una relación ternaria, pero no pueden unificarse en una relación 40 relaciones distintas.

Eso quiere decir que si quieres que la tabla A y B se relacionen co C no unas las relaciones de A y B hasta C, sino que hagas una relación de A a C y otra de B a C.

Por cierto. Según has puesto eso ahí, la tabla TIPO no sirve de nada, pues no se relaciona con nada (o al menos su PK no está visiblemente relacionada en otra tabla). Si es tipo de aeronave debería relacionarse con vuelo y por tanto ID TIPO debería estar, o bien como FK en Vuelos o bien deberías crear una relación a parte (siendo 1:1 no hace falta) llamada TipoVuelo que relacione la ID Vuelo con ID Tipo.

No se si ese ID Tipo se refiere a otra cosa, pero como te digo ahí esa tabla no está haciendo nada :S

Esto se aprende haciéndolo.

"En el momento que se le empieza a atender es la hora de inicio de asistencia y se rellena una ficha con con dicha hora y la fecha del dia , su nombre y apellidos, asi como con los siguientes datos:"

Leyendo eso te falta un ID Fecha en la tabla del PMR o bien 3 campos más: fecha, hora inicio, hora fin (yo usaría 3 campos, es más veloz).

Por otro lado en la tabla Tipo no hacen falta tantos campos (e incluso te faltaría uno). Te faltaría el campo "observaciones" o "comentarios" y te sobran todos los que son acrónimos, deberías usar un campo que se llame algo así como "tara" en el que almacenes un código de la tara que posee. Normalmente cuando hay muchas posibilidades y pueden ocurrir todos a la vez lo mejor es guardarlo como binario:

WCHR -> 2⁰
WCHC -> 2¹
DPNA -> 2²
BLND -> 2³
DEAF -> 2⁴
MAAS -> 2⁵

Así si el individuo es ciego, necesita silla de ruedas y además está sordo puedes hacer:

011001 para indicar las 3 taras a la vez y ahorrar espacio, lo cual se traduciría en "25"

Eso en un Entidad relación no se podría plasmar directamente, necesitarías una nota indicándolo.

De todas formas no tienes relacionada dicha tara con nadie, cuando realmente debería estar asociado al PMR.

Por ello necesitas o bien incluir la PK de la tabla TIPO en la tabla PMRS como ID TIPO, o crear una tabla intermedia (esto ya depende de gustos). Si añades dicho campo a PMRS la tabla actualmente estaría como esto:

PMRS

ID PMR
Nombre
Apellido 1º
Apellido 2º
ID FECHA
ID TIPO

Luego haces una relación con la tabla TIPO de 1 a 1 y una con la tabla FECHA de 1 a 1 también.

Si usases los tres campos para fecha y horas no necesitarías relación con la tabla de fechas, eso a tu elección.

A la hora de implementar esto recuerda usar las FKs para las IDs externas como ID FECHA e ID TIPO para que en caso de borrar el PMRS se borren las fechas y tipos asociadas a este.

Por otro lado el vuelo debería asociarse al PMR también, pero como este puede pedir varios vuelos no podemos meter ID VUELO en PMRS, sino que necesitamos una relación por el medio que se transforme en tabla a la hora de implementar con dos campos, la PK de cada tabla que relaciona (ID VUELO e ID PMRS). La tabla puede llamarse VuelosPMRS por ejemplo e incluir esos dos campos para relacionar ambas tablas.

Con respecto a las tablas de llegadas y salidas tampoco es necesario dividirlas, se puede crear un campo en la tabla VUELOS que sea "tipo" en el que si es 0 es salida y si pone 1 es llegada, por ejemplo, lo cual reduce bastante el nº de tablas sin cargarse funcionalidad. Eso si la ID FECHA entonces ha de meterse en la tabla Vuelos, y quedaría así:

VUELOS

ID Vuelo
Tipo
Compañía
num_vuelo
ID Fecha

Esta tabla ya te digo que debería estar relacionada con PMRS por la tabla VueloPMRS (o similar)

De todas formas no veo 100% necesaria la tabla de fechas, ya que con cambiar ID Fecha en cada tabla por "fecha, hora_ini, hora_fin" vale y te ahorras meter una tabla de por medio.

Tampoco me lo he leido muy a fondo pero más o menos te ayudará lo que te he puesto.

P.D: ¿Para que és si puede saberse?

#8 De nada hombre, si te surge alguna otra duda ya me pasaré por aquí para intentar ayudar

No se que hace ID PWR en las salidas, de todos modos..., yo creo que asi quizás lo entiendas.

Aunque las BBDD no son lo mio (y ese ER no anda demasiado bien,pero bueno).

creo que FG se refiere a FK, Foreign Key

PMRS que es exactamente?

la tabla intermedia se coloca cuando la relacion entre PMRS - VUELOS es de N:M (Varios a Varios)

La tabl aintermedia te la divide en 2 relaciones de 1:N

Sí, FG = FK, FAIL!.

Lo que dice gama es cierto, de todos modos, mi esquema no es un ER, ya que no tiene entidades ni nada, es la tabla y los campos (lo que te saca Access cuando haces las relaciones vaya).

#18 no hay un modelo fijo par aun problema en cuestión.

Tu puedes hacer una BDD con 20 tablas, y si t epone skiskilloso, puedes sgeuir "afinando" y sacar otras 20, y asi hasta el infinito. Es bastante abstracto.

Es la mierda de las BBDD xD

mysql + Toad for mysql creo que es la mejor opcion

#20 Yo no he dicho que lo haga en Access.

Tenidno en cuenta la imagen esa de sin barreras, yo creo que con 3 tablas lo haces todo (cat. pmr son siempre las mismas no? y el tipo de embargue tb no?)

http://www.mediafire.com/download.php?gen25e2m5ty