Cita: donde puedo comprender a fondo sql
Estás confundiendo temas... El problema que no conoces, no es el SQL (que en sí es un lenguaje de consultas y no una base de datos), sino los
fundamentos del diseño de bases de datos, que es un tema totalmente distinto, y para el cual hay que conocer algo de Análisis de Sistemas, más que de SQL.
El SQL es una herramienta para hacer consultas, pero mucho antes de eso se debió diseñar el modelo de datos. Allí es en el modelado de datos donde te falla el tema, por lo que se alcanza a entender.
El hecho de que tengas cuatro (4) formularios no es relevante, porque podrías tener 35 formularios, que solamente necesitaran seis (6) tablas (caso que he tenido), o bien tener un sólo formulario y afectar 57 tablas... como uno en el que trabajo ahora.
Lo que quiero que te quede claro es que
no es lo mismo lo que ve el usuario y lo que programas en la aplicación con lo que se necesita en estructura de bases de datos para darle soporte a todo eso.
Una factura, por dar un ejemplo, sólo requiere un formulario, y aparentemente no más de cuatro o cinco tablas.
Pues eso es un error. Para poder emitir una sola factura se pueden requerir más de treinta tablas, dependiendo de muchos factores, porque una enorme cantidad de cosas que se pueden inferir del problema afecta estructuras que son invisibles para el usuario.
En tu caso, esa sola tabla que ves al final, tan extensa, tiene no sólo datos redundantes, y que no deberían esta allí, sino además tiene una enorme falta de normalización que será difícil de resolver, sin tener que descartar tu modelo para empezar de nuevo.
Para darte una idea:
Enfermedades, Alergias, Examenes, Medicamentos (drogas es una subcategoría, no una entidad propia), CondicionesMedicas, Infecciones,
son todas entidades separadas y no atributos de una única tabla. Se vinculan en la de HistorialMedicoKid (que no has creado).
Faltan las tablas de HistorialMedico, las relacionales, las de Familiares, Telefono, MedicalCare (sistema medico del niño), Contactos, etc. Todas son entidades separadas, que se relacionan en un sistema complejo.
En el caso de los datos del niño en cuestión, Talla y Altura son datos redundantes según el país, ya que son sinónimos, y si se pone la fecha de nacimiento, la edad es irrelevante (se hace por cálculo), No se deben poner nombres de padres o madre, sino que eso surge de una tabla relacional entre Niño y Famila (Tabla Kid_Familar), donde también puede aparecer un atributo que diga "vínculo", o bien eso es una tabla paramétrica fija relacionada.
Creo que con lo que te estoy diciendo, ya te puedes ir dando una idea de que para ser una base de datos eficaz y eficiente, lo que tienes no sirve.
Pero todo dependerá de lo bien que quieras trabajar y cuánto desees aprender.
Mira este modelo, que sólo incluye los datos básicos:
Y esto sería un modelo de aplicacion para pacientes médicos:
Ahora trata de imaginar algo que combine ambas cosas y te estarás acercando...