Access - Problemas con un diagrama de access

Tengo un diagrama para un programa de visual Basic. La relación entre las ventas, Avisos y Seguros es porque los Avisos y los Seguros dependen de Ventas, pero la relación creada después de ambas con GastosIngresos me da error al tratar de Insertar datos, he probado los tres tipos de relaciones y el error persiste. Me puede explicar alguien como debo hacer dicha relación.
Adjunto diagrama.

Gracias y un saludo

• Diagrama.zip(171,1 KB)

Hola miguel descargare el archivo y tratare de ayudarte a solucionar tu problema..

Te paso la BD y datos de pruebas ya que el error es por la relaciones que tengo y si tratas de meter un dato salta el error. Te adjunto una explicación.

Gracias por tu ayuda

• Datos-de-las-relaciones.zip(10,7 KB)
• MP.zip(34,9 KB)

Miguel aquí te doy un ejemplo para que veas como se hace la correcta estructura y normalización de una base de datos tiene un documento de word con las especificaciones y una base de datos de ejemplo para que te guíes porque la verdad tu ejemplo tiene una estructura no correcta.

• Desktop.rar(316,2 KB)

Perdona Jhonattan pero no veo la forma para solucionar el problema. Te importaría hacerlo sobre la BD que te he enviado y me lo mandas.

Un cliente puede tener multiples ventas pero sale la relación de 1 : 1.
Una venta puede tener multiples Avisos y multiples Seguros.

Y GastoIngreso puede tener un registro por cada venta, por cada Aviso y por cada seguro.
Tambien puede darse el caso de que de una venta no cuelgue ni Avisos ni de Seguros.

Gracias y un saludo

Miguel, buenas tardes, no se si a estas alturas ya resolviste el problema. de puro curioso mire la BD q enviaste y creo q el problema es que tenes definido el IdCliente en la tabla Ventas como "Indexado SIN DUPLICADOS", por este motivo solamente podrias ingresar un unico Id de cliente en la tabal Ventas por lo tanto la relacion la arma 1 a 1 , revisa cada tabla donde tengas este problema y si necesitas un indice en la clave foranea debes declararla CON DUPLICADO.

( despues de hacer los cambios, por ejemplo en la tabla VENTAS le quitas el SIN DUPLICADO a IdCliente, debes eliminar la relacion y volver a crearla )

espero te ayude
Saludos

podrias subir tu archivo para analizarlo creo que mas o menos se lo que pasa pero para poder comprender lo que quieres hay que ver el programa funcionando para revisar de donde viene el error..

Aprecio una relación de uno a uno entre la tabla 'seguro' y 'avisos', ese tipo de relación es problemática y creo que innecesaria (ya existe entre ellas una relación indirecta mediante la tabla 'ventas').

Desconociendo las pretensiones de ambas tablas, esa relación (1--1) solo permitiría un único registro en ambas (lo fuerza esa relación) ¿es lo que se pretende lograr?.

Efectivamente se crea una relación de 1 : 1 pero no se cual es la razón ya que la tengo como 1 : infinito. De todas formas yo cuando voy hacer un programa diseño primero la BD y con datos de prueba compruebo que al ir cargando esos datos las relaciones funcionan correctamente y solo entonces comienzo a programar. Hasta llegar a ventas no hay problemas y si elimino las relaciones de Avisos y Seguro con GastoIngreso funciona correctamente. solo da los problemas al crear las relaciones de Avisos y Seguro con GastoIngreso y es la parte de programa que no he iniciado hasta que funcione con los datos de pruebas.

Un saludo y gracias por tu tiempo

Miguel revisaste el ejemplo que te pase allí esta la forma en como solucionarlo el detalle es que en operaciones repetidas no puedes crear relaciones de 1 a 1 porque aunque vayas a generar una nueva venta por asi decirlo access reconocera que el id de la clave primaria existe y si no te muestra el mensaje de que debes tener registros relacionados te mostrara el mensaje de registros duplicados

Mira yo me introduje en este mundillo cuando me jubile hace un año y entiendo los comentarios que ponéis pero la realidad es muy diferente. He subido la BD para que pudierais verla y a decir verdad la relación de 1: 1 ignoro porque sale pues yo puse la relación de 1:infinito, así que cuando trato de ver formas de cambiar alguna relación el Access salvo las tres formas que ofrece no meda más opciones.

De todas formas agradezco el tiempo que me habéis dedicado.

Gracias y un saludo

Las relaciones entre claves principales siempre serán de uno a uno (o no se cumple la lógica).

Los ID de las tablas definen a un registro único en todo el conjunto (repito) UNICO

Asi pues, si ambos son llave (cada uno en su tabla) ambos serán únicos en su tablas y si ambos son únicos: aparece la relación de uno a uno.

La solución es que uno de los dos (el de la tabla que ha de tener los repetidos) deje de ser llave para permitirle dejar de ser único

Miguel, buenas tardes, no se si a estas alturas ya resolviste el problema. de puro curioso mire la BD q enviaste y creo q el problema es que tenes definido el IdCliente en la tabla Ventas como "Indexado SIN DUPLICADOS", por este motivo solamente podrias ingresar un unico Id de cliente en la tabal Ventas por lo tanto la relacion la arma 1 a 1 , revisa cada tabla donde tengas este problema y si necesitas un indice en la clave foranea debes declararla CON DUPLICADO.

( despues de hacer los cambios, por ejemplo en la tabla VENTAS le quitas el SIN DUPLICADO a IdCliente, debes eliminar la relacion y volver a crearla )

espero te ayude
Saludos

Buenas tardes gracias por contactar. De momento si he corregido la relación de Clientes a Ventas modificando el Indexado. De Ventas, Avisos y Gastos tienen que ser de 1 a infinito, pero de Ventas, Avisos y Seguro tiene que ser de 1 : 1 con GastoIngreso.
Tanto Ventas como Avisos y Seguros dejando la relación de una de ellas con GastoIngreso funcionan. He probado a poner Indexado - No y Indexado sin duplicados en GastoIngreso y da error de todas formas. Así que estoy desesperanzado.
Subo la BD y si tienes un rato y puedes dilucidar el problema te quedaría agradecido.
Los datos para pruebas son :
Ventas Id=2
Seguros Id=4
Avisos Id=3
Las claves de Cod se generan con una función al igual que IdClien y Ref.

Gracias y un saludo

• MP.zip(41,3 KB)

Ok, mas tarde reviso y veo si puedo ayuarte

El problema esta en la estructura de la base de datos eso influye mucho las relaciones de 1 a 1 deben asignarse cuidadosamente hay que estar muy seguro del porque quieres implementar ese tipo de relación.

Cuando vas a hacer muchas transacciones utilizando el atributo de una entidad es mejor hacer las relaciones de 1 a n y con código visual basic application se resuelven otros temas pero la estructura y el diseño de la base de datos debe ser la forma mejor elaborada porque son como las bases de un edificio si están mal construidas el edificio colapsa, lo mismo sucede en esto si las tablas están mal relacionadas el sistema colapsa

Jhonattan ahora tienes la BD con todas las relaciones de 1: n. Veras si cargas datos de pruebas que tampoco funciona, así que dime ahora cual es el problema.

Gracias y un saludo

• MP.zip(41,5 KB)

La única forma que veo de funcionar es creando una tabla por cada uno de los casos, decirme si esto os da alguna pista yo soy incapaz de sacar una conclusión.

Gracias por vuestro tiempo.

• MP.zip(43,4 KB)

Hola miguel ok revisare y te respondo después de analizar el diseño

estimado Miguel me temo que hasta que no analices bien lo que quieres hacer sera imposible ayudarte a solucionar el problema que tienes, puesto que he analizado en todos los aspectos ese diseño que tienes y la verdad no se entiende acá te dejo 3 imágenes para que veas algo en las dos tablas que te muestro y en el diagrama de las relaciones a continuación se puede observar que una de las tablas no tiene la dependencia de la otra es decir es como si no estuviera relacionada, ademas en el diseño de las relaciones tienes relacionados campos como por ejemplo id con cod y eso así lo que hace es crearte confusiones por lo tanto te pido que mejores eso si un campo en la tabla A se llama id en la tabla B debe llamarse id tambien. lo otro es que debes definir cual sera la tabla que debe llenar primero, cual se debe llenar de segu


ndo, cual se debe llenar de tercero y cual va a contener datos de las 3 anteriores

Hola Matias he probado con relaciones de 1:n y con todas las que permite Access y solo funcionan de una en una.Me explico si tengo solo la relación de Ventas a GastoIngreso funciona y lo mismo pasa teniendo solo Avisos y GastoIngreso e igualmente con Seguro y GastoIngreso.

• MP.zip(41,5 KB)

La única forma que veo de funcionar es creando una tabla por cada uno de los casos, decirme si esto os da alguna pista yo soy incapaz de sacar una conclusión.

Gracias por vuestro tiempo.

• MP.zip(43,4 KB)

Miguel, estoy de acuerdo con los comentarios de Jhonatan, el gran problema q tienes es q estas normalizando mal los datos y te estas creando mucha confusion, el problema de tus relaciones es lo q te mencione anteriormente , si intentas hacer una relacion entre dos tablas con dos campos que son unicos, por ejemplo en la tabla principal por ser clave y en la tabla secundaria por estar declarado como SIN DUPLICDOS es obvio que automaticamente te armara una relacion de 1 a 1 , podes comprobarlo en cada caso, donde se encuentra la clave foranea declararla CON DUPLICADOS, luego eliminas TODAS las relaciones de esa tabla y las vuelves a crear y veras q reliza la relacion 1 a N q estas buscando , pero eso no resuelve de ninguna manera tu problema.
es imposible ayudarte ya que no conocemos que es lo q debe hacer tu sistema, deberias refrescar un poco tus conocimientos de normalizacion, es muy importante lo que dice Jhonatan, si vas a crear una relacion entre dos tablas la clave foranea al menos debe llamarse igula q en la tabla principal esto te da una idea de que informacion lleva . hay algunas relaciones q no alcanzo a entender por ejemplo entre VENTAS y AVISOS , en la tabla avisos hay un cod q aparentemente es el Id_Venta pero no se bien q es.
Otro concejo, no deberias tener campos calculabes almacenados, como por ejemplo Total en varias tablas
No se bien porque incluis en la Tabla VENTAS datos heredados del cliente como Provincia, Cp, Municipio, etc ... eso no es necesario y es un erro de normalizacion ..
en fin para poder ayudarte deberias replantear tu analisis de datos y luego si podriamos despejar algunas dudas pero no creo q vas por buen camino si decide seguir adelante con ese modelo de datos

Saludos

Con todo el respeto del mundo, creo que tienes un problema conceptual.

Si unos determinados datos tienen que ir asociados a un determinado (y único) registro y esos datos solo pueden existir una única vez (la relación 1-1) ....

No seria lo lógico que 'esos datos' formasen ¿parte de la misma tabla?

Para verlos como 'algo independiente' o similar a una tabla, bastaría una simple consulta de selección (que para eso están y han sido diseñadas: conformar orígenes de datos)

Básicamente una relación de uno a uno es la relación que tienen todos los campos de una tabla con su ID, crear una tabla y generar esa relación es un símil a expandir la tabla cuando los (mas de 200) campos de esta son insuficientes (y no creo que sea el caso presente)