Access - Error de novato?

Buenas, estoy de becario en una empresa y me pidieron que les hiciera una base de datos en access y estoy teniendo muchos problemas.

(les dejo el link a la imagen por si acaso: https://i.snag.gy/jmDxcT.jpg)

En el formulario para añadir una nueva Empresa , puedo añadir domicilio social por ejemplo pero sin poner el NIF de la empresa, ya que me dice que no hay ninguna empresa que se relacione con ese NIF
Pero no puedo añadir una Empresa porque el campo ID_DOMICILIO_SOCIAL es Mandatory(requerido)

Para solucionar esto se me ocurrió ir añadiendo todo lo necesario, domicilio social, representante legal etc. sin añadir el NIF de la empresa, y luego añadir un nuevo registro de empresa y tras esto, actualizar los registros de las tablas relacionadas y añadirles el NIF.
Pero no sé como hacer eso en el código, lo he intentado pero no hay manera.

He llegado a pensar en eliminar todas las tablas relacionadas con Empresa excepto Contratación, y poner todos los campos de las tablas "eliminadas" en Empresa para facilitar las cosas, ya que en el fondo en la BD que me han pedido solo necesitan los datos de la Empresa, no necesitan almacenar domicilios por separado, ni personas etc.

Qué me recomendáis? estoy bastante perdido

Mi formulario Dispone de botones que abren los correspondientes subformularios, aquí les dejo una imágen:


Los cuadros en blanco son pruebas para ver si todo funciona bien.



El botón de Guardar Empresa lo puse para intentar lo comentado anteriormente, de añadir registros en los subformularios sin poner el NIF y luego al darle a Guardar Empresa, añadir el NIF a los registros una vez agregada la empresa.

Muchas gracias por su tiempo

No veo optima esa distribución de datos .....

Si las empresas NO tienen sub-delegaciones (lo que podría dar lugar a diferentes localizaciones), los datos únicos y comunes de la empresa no seria preciso distribuirlos en varias tablas, de tener varias localizaciones, se generaría un nivel mas en que la empresa 'matriz' seria la primera de las delegaciones (primera delegación = central), asi podrían coexistir diferentes tipos de empresas.

Curiosamente los 'contactos' están en la tabla que define a la empresa, cuando estos datos son variables y deberían estar en tabla aparte

Los supuestos niveles (según mi punto de vista) deberían ser:
0.- Grupo empresas
1.- Delegaciones (la delegación 0 es la central en cualquier caso)
2.- ... en este nivel estarían los datos que no sean únicos de las empresas (sean trabajadores, contactos o clientes ... y por ejemplo bancos)

En esa construcción se aúnan el grupo 1 con alguno del 2 (limitara el crecimiento) y se llevan a un grupo del tipo 2 datos del grupo 1 (su dirección ... etc.)


Analiza el entorno real y modifica la estructura de esas tablas, que son el componente básico (el esqueleto) de todo el resto de la aplicación.

Si las empresas carecen de 'delegaciones', el grupo 0 (cuya única finalidad es aunar las delegaciones como conjunto) no seria necesario, pero se mantienen el resto de acotaciones.

¿Tiene sentido por ejemplo el poner una UNICA cuenta bancaria? .... normalmente hay varias en función de la competitividad de sus productos, de sus ubicaciones ... etc. (no deberían formar parte del nivel 1, sino de un nivel a partir del 2)

Muy buenas y gracias por responder,

Las empresas no tienen delegaciones, las empresas en realidad son clientes que contratan una Area Sumasa con un Tipo de contrato
y los datos de esa unión se almacenan en Contratación como puedes ver.

Los contactos y eso es simplemente para saber con quien hay que hablar para determinado asunto, por ejemplo, se le enviaría una carta o se haría una llamada a la persona de notificaciones para tramites ordinarios, pero para algo de mayor relevancia convendría contactar con el representante legal de la empresa.

El jefe me dijo que si podía que añadiera la cuenta bancaria, que no la suelen necesitar pero esta bien tenerla por si acaso, así que asumí que con 1 era suficiente, ya que suelen ser empresas pequeñas.

En la tabla EMPRESAS solamente se almacena el ID del contacto, no he entendido lo que has querido decir en referente a los contactos
Tampoco he acabado de entender los niveles

Muchas gracias por tu tiempo

Me ha creado confusión lo de 'empresas' cuando de lo que se trata es de un símil a 'cartera de clientes' y que los clientes sean empresas es un dato anecdótico .....

En esa ficha que define 'al cliente' deberían estar todos sus 'datos únicos', no tiene sentido que el domicilio este en una tabla aparte ¿acaso comparten la misma ubicación empresas diferentes o tendrán mas de un domicilio? ... esa seria la única razón para la existencia de esa tabla aparte.

Si es así (son clientes y punto) bastara con una sola cuenta para el banco (es a la única que en teoría se dirigirían los cargos pero siempre hay excepciones, los clientes son .... clientes).

Los niveles surgen del diseño de la aplicación (cuando se hace su esqueleto) para evitar crear dicotomías con los datos entre otras cosas como parece ser el presente caso.

Una idea simple de niveles, ejemplo una biblioteca ...
La información (o lo que realmente es útil de un libro) son las paginas

Si las agrupamos por capítulos, ya tenemos un nivel
Si agrupamos los capítulos otro nivel (al conjunto de capítulos ya se le puede considerar 'un libro')

A mayores resulta que se desea clasificar por autores para ubicarlos juntos (en el mismo estante por ejemplo)
Con lo que aparece un nuevo nivel y otro mas si planificamos una clasificación por temáticas (novela rosa, policiaca, ficción o técnicas diversas)

Y en esa planificación, no se separan las paginas de un libro para crear una dicotomía (por ejemplo todos los capítulos finales), porque 'aunque pudiera haber coincidentes' cada final es único y de su libro (aunque como siempre ganen 'los buenos' y se desee tener a los buenos en saco aparte).