Hola N4X.
De antemano te habia hecho la sugerencia que efectivamente hay tablas que se pueden reducir o compenetrar con otra. Pero no puedo especificarte de antemano cuales serian porque aunque te explicas (disculpa que aun no entienda 100% del todo tu aplicacion final).
Es relativo separar o dejar 1 sola tabla con muchos campos y separarse de la normalizacion de datos. Aveces si es mas efectivo desnormalizar una tabla para optimizar tu aplicacion ya que para el motor es mucho mejor y mas rapido acceder a la data dentro de una sola tabla que conseguir una data buscando en 2,3,4 o mas tablas, tu entenderas que para una aplicacion de gran tamano (digase miles o millones de registros) es mas forsozo para el motor tener que sacar varios registros de un JOIN de 2 o 3 o mas tablas, pero si esos miles o millones estuviesen en 1 sola tabla todos, el proceso es mas rapido. Pero aunque algunas veces es bueno apoyarse en la desnormalizacion no te fies siempre de ello.. ya que desnormalizar implica tener logs, datafiles mucho mas grandes en un solo archivo no distribuido en varios archivos como si tuvieramos normalizacion.. entre otras cosas. Tu conoces el tipo de proyecto que debes realizar si es un proyecto pequeno o mediano-pequeno, puedes darte el permiso de desnormalizar algunas tablas para optimizar, pero procura elegir tablas que tu sepas que en un futuro no va a afectar los registros que tengas dentro por alguna actualizacion que debas hacer, que esto no afecte la relacion.
Ahora, sobre considerar los valores NULL en los campos no te lo recomendaria ni en modelo normalizado ni desnormalizado. La razon? recuerda que NULL no es un tipo de dato es nada.. vacio, nisiquiera es 0 o espacio vacio es nada. Sin embargo todos los campos que tu declaras en un motor de DB tienen un tipo (integer, char, varchar, text, etc) cuando tu creas un campo y le asignas un tipo de dato, le estas diciendo al motor que cuando reciba un registro reserve memoria para ese tipo de dato recibido (sea texto, numero, decimales, fechas, etc) pero si tu ingresas un dato NULL cuando el motor reserva memoria para un INTEGER por ejemplo.. a la hora que haces una consulta a una tabla donde existe ese NULL por ejemplo, el motor cuando llegue al registro donde existe ese NULL se detendra unos segundos a analizar que realmente en ese espacio reservado hay un valor NULO cuando el esperaba encontrar un INTEGER, despues que el analiza esto entonces sigue su recorrido.
Es como por ejemplo, que yo tenga 20 botellas de plastico para guardar agua y te diga N4X sal de este departamento pero antes de que tu salgas verificame de las 20 botellas cuales tienen agua, y tu pasas caminando vas con los pies tentando y sabes que tienen agua sigues de largo, pero de repente si toqueteas una y la sientes liviana te detendras unos segundos al menos para verificar que dicha botella no tiene agua... esta vacia, asi mas o menos reacciona el motor.
Toma eso en cuenta, coloca cualquier valor ya sea 'espacio' o cero pero no consideres los nulos.
Otra cosa si tu de antemano sabes, que llegara un punto donde deberas relacionar todas las tablas a traves de 1 tabla padre, ve considerando agregar 1 indice que contenga el mismo valor y relacione todas las tablas que sospechas llegara un punto que se van a relacionar.
De antemano te habia hecho la sugerencia que efectivamente hay tablas que se pueden reducir o compenetrar con otra. Pero no puedo especificarte de antemano cuales serian porque aunque te explicas (disculpa que aun no entienda 100% del todo tu aplicacion final).
Es relativo separar o dejar 1 sola tabla con muchos campos y separarse de la normalizacion de datos. Aveces si es mas efectivo desnormalizar una tabla para optimizar tu aplicacion ya que para el motor es mucho mejor y mas rapido acceder a la data dentro de una sola tabla que conseguir una data buscando en 2,3,4 o mas tablas, tu entenderas que para una aplicacion de gran tamano (digase miles o millones de registros) es mas forsozo para el motor tener que sacar varios registros de un JOIN de 2 o 3 o mas tablas, pero si esos miles o millones estuviesen en 1 sola tabla todos, el proceso es mas rapido. Pero aunque algunas veces es bueno apoyarse en la desnormalizacion no te fies siempre de ello.. ya que desnormalizar implica tener logs, datafiles mucho mas grandes en un solo archivo no distribuido en varios archivos como si tuvieramos normalizacion.. entre otras cosas. Tu conoces el tipo de proyecto que debes realizar si es un proyecto pequeno o mediano-pequeno, puedes darte el permiso de desnormalizar algunas tablas para optimizar, pero procura elegir tablas que tu sepas que en un futuro no va a afectar los registros que tengas dentro por alguna actualizacion que debas hacer, que esto no afecte la relacion.
Ahora, sobre considerar los valores NULL en los campos no te lo recomendaria ni en modelo normalizado ni desnormalizado. La razon? recuerda que NULL no es un tipo de dato es nada.. vacio, nisiquiera es 0 o espacio vacio es nada. Sin embargo todos los campos que tu declaras en un motor de DB tienen un tipo (integer, char, varchar, text, etc) cuando tu creas un campo y le asignas un tipo de dato, le estas diciendo al motor que cuando reciba un registro reserve memoria para ese tipo de dato recibido (sea texto, numero, decimales, fechas, etc) pero si tu ingresas un dato NULL cuando el motor reserva memoria para un INTEGER por ejemplo.. a la hora que haces una consulta a una tabla donde existe ese NULL por ejemplo, el motor cuando llegue al registro donde existe ese NULL se detendra unos segundos a analizar que realmente en ese espacio reservado hay un valor NULO cuando el esperaba encontrar un INTEGER, despues que el analiza esto entonces sigue su recorrido.
Es como por ejemplo, que yo tenga 20 botellas de plastico para guardar agua y te diga N4X sal de este departamento pero antes de que tu salgas verificame de las 20 botellas cuales tienen agua, y tu pasas caminando vas con los pies tentando y sabes que tienen agua sigues de largo, pero de repente si toqueteas una y la sientes liviana te detendras unos segundos al menos para verificar que dicha botella no tiene agua... esta vacia, asi mas o menos reacciona el motor.
Toma eso en cuenta, coloca cualquier valor ya sea 'espacio' o cero pero no consideres los nulos.
Otra cosa si tu de antemano sabes, que llegara un punto donde deberas relacionar todas las tablas a traves de 1 tabla padre, ve considerando agregar 1 indice que contenga el mismo valor y relacione todas las tablas que sospechas llegara un punto que se van a relacionar.
si es lo segundo propuesto por mi o N4X iras bien 1 sola linea de consulta SQL.
me explico, observa este ejemplo.
uno de antemano puede imaginarse y mas o menos suponer las entidades y relacion entre las llamadas y un empleado (Como el ejemplo expuesto por Shell Root) pero todo va a depender bastante de la organizacion que lleve X empresa para entonces tu hacer tu analisis y estructurar tus tablas...
pero que bien que pudiste deducir finalmente cual era el inconveniente. Aunque en otros casos suele influir la variable que menciono pero solo para el motor DB.