erdanblo, no se si estaría bien así el todo.
Qué te parece?
#30 todavía comentamos lo del DNI el otro día que no es único xD. No puedes poner DNI como UNIQUE en una DB porque estarás cometiendo un error. Si necesitas un identificador y no lo tienes lo creas (id => PK).
Gracias Gama!
Le has echado un ojo a la que subí?
Es distinta a la de erdanblo.
Fíjate en las relaciones. No tengo el DNI como PK
De lo que no me estoy muy seguro, es de si las relaciones estan bien.
Porque todas son de varios a uno?
Por ejemplo, se supone que en una asistencia sólo puede haber una categoría...
O lo interpreto mal... que una categoría puede estar en varias asistencias?
Me lio más con esto...
#33 Hombre, yo en cuanto a facilidad a la hora de acceder a los datos después resumiría:
"Fecha y hora de inicio" => "fecha_inicio"
"Fecha y hora de fin" => "fecha_fin
"Número de vuelo" => "num_vuelo"
"Tipo de solicitud" => "tipo"
Ya que cuando construyas las SQL te vas a acordar de los espacios 
. Con respecto a "DNI o Pasaporte" eso no es muy coherente, ya que cuando obtengas datos de la DB no sabes que tipo de documento es, más bien pondría un campo "tipo_doc" que si es 0 sea DNI y si es 1 sea pasaporte, logicamente también otro campo "documentacion" donde incluyera el nº de DNI o pasaporte. ¿Por qué digo esto? Porque cuando saques la info de la db puedes decir "Si el tipo_doc es 1 entonces lo que obtengas de documentacion es Pasaporte, en otro caso es DNI".
Otra solución a esto (en caso de que se puedan meter ambos documentos simultaneamente, sería crear una tabla nueva llamada documentacion, la cual tuviera los siguientes campos:
- ID_PMR (como FK a PMRS)
- Tipo_doc (Tipo de documento, 0 es DNI, 1 pasaporte)
- numero
Como PK puedes poner (ID_PMR,Tipo_doc) ya que así evitarás que un mismo PMR pueda tener 2 DNIs o 2 pasaportes, pero dejarás que pueda poner ambos documentos, ya que el tipo_doc variará.
Esto depende del problema que quieras resolver. Si te vale con 1 documento puedes usar el sistema de arriba, en otro caso necesitarás el de debajo, con una relación de PMRS a la nueva tabla, eso si, retirando el campo "DNI o Pasaporte". No te hace falta poner una referencia de PMRs hacia documentacion, ya que puedes hacer una select en documentación donde el ID_PMR sea el del cliente y obtendrás 0 salidas si no existe el PMR, 1 salida si tiene asociado 1 solo documento identificador o 2 salidas en caso de que tenga DNI y pasaporte metidos. Es imposible obtener más resultados, ya que tipo_doc solo tiene 2 posibles valores como dije antes.
Espero que te ayude
Gracias de nuevo Gama!
Lo de usar ambos tipos de documento, me parece muy buena idea, puesto que se atiende por igual a pasajeros españoles como extranjeros. Algunos tendrán DNI y otros pasaporte.
Hoy estuve probando el modelo E/R que puse más arriba, pero no me funciona bien.
El tipo de solicitud, creo que no puede ir en la tabla asistencias, porque sólo es un embarque o un desembarque, que a la hora de meter la ficha, se debería de seleccionar de un menu desplegable.
Estoy perdidísimo 
Cada vez que saco un modelo E/R, me falla por algún lado.
Podrías quizás crearme un esquema que pueda pasar a access?
Puesto que cada vez que sea crea una solicitud, hay que introducirlo a mano.
Aparte de que no se si las relaciones así a campos numéricos estan bien.
Yo la colgé ahí en mediafire. Bájatela y prueba meter algunos datos.
Veras que no cuadran!
Hombre si Tipo es el tipo de discapacidad que sufre si, de hecho debería estar en PMRs ya que cada PMRs tendrá su discapacidad o discapacidades y estas no dependen del vuelo, ni nada de eso.
Pero con respecto a lo de que solo ese campo se metía a mano no te debería extrañar, aún así puede estar correcto.
Usa SQL, es mejor y no hay tantos problemas.
Haces las tablas y relaciones con sus campos en una hoja a mano y luego lo pasas a SQL.
La cosa es que no tengo el modelo E/R bien...
Si alguien me puede echar una mano, lo agradezco. Porque estoy por dejarlo...
#39 es que Access no es la mejor alternativa, yo de hecho no tengo mucho conocimiento de dicho programa, me da tirria .
Lo que suelo usar es MySQL u Oracle. Yo de tí instalaría MySQL Server en la máquina que dé el servicio y luego puedes usar un editor se sentencias SQL como SQLYog, Navicat, etc... para crear las tablas y acceder a ellas.
De Access no te fies, yo el esquema lo veo (a priori) correcto. Trata de hacer lo que te comenté y verás como te irá mejor
Uso access, porque es lo más sencillo a la hora de trabajar.
Date cuenta, que tendrá que trabajar gente con la BD que no tiene ni idea.
Una vez creado el modelo E/R, ya creo las consultas y los formularios, para introducir directamente los datos.
Asi el usuario no ve todo lo que ay detrás. Mete datos en un formulario y listo.
Eso de SQLYog, Navicat, etc. lo veo muy complicado, sobre todo para un usuario que no tiene ni idea.
Pero la cosa es hacer la base de datos con un SGBD como MySQL (por ejemplo) y luego dar una aplicación web o de escritorio que realice las SQL necesarias para insertar, borrar o modifica la información. Por sencillo que sea si le das eso a alguien que no tiene ni idea además de que se va a liar hará cosas que no deba. Por ejemplo puede borrar asistencias en curso que no deberían poderse borrar, podrá insertar cosas mal dejando comprometida la integridad de la base de datos.
En definitiva, SQLYog/Navicat serán para ti, de cara a crear las tablas y generar las SQL para la aplicación web/escritorio en las cuales el usuario final (que no tiene ni idea) solo pueda hacer las cosas que TU le dejes .
Espero haberme explicado correctamente
Deberás hacerla personalizada. Hay dos opciones:
- Aplicación de escritorio
- Aplicación web
Te recomiendo hacerte una página web que interactue con la base de datos y unos cuantos campos input en los que tú le facilites la vida al usuario.
P.D: Ojo con insertar en la base de datos o actualizar algo directamente dado por el usuario, recuerda que existe el SQL inject.
Ej:
"SELECT * FROM usuarios WHERE nombre = '$usuario';"
y $usuario es una variable post puesta en un input del formulario web que contenía:
"Alicia';
DROP TABLE usuarios;
SELECT * FROM datos WHERE '-' = '-';"
Conclusión:
"SELECT * FROM usuarios WHERE nombre = 'Alicia';
DROP TABLE usuarios;
SELECT * FROM datos WHERE '-' = '-';"
Te tirarán una base de datos. Más info
En el lenguaje que uses trata de buscar funciones que añadan \ antes de " o de '. Supongo que lo sabrías, pero sino ya lo sabes
¡ Un saludo !
