Relación uno a uno

pinguina · #1 (**permalink**) 29/03/2006, 16:50

Quizás no tenga solo relación con SQL Server, como puedo implementar una relación uno a uno?

Myakire · #2 (**permalink**) 29/03/2006, 18:02

Normalmente una relación 1 a 1 es un campo de la misma tabla.

TolaWare · #3 (**permalink**) 29/03/2006, 19:22

a que le llamas implementar? no entiendo tu pregunta?

Myakire · #4 (**permalink**) 29/03/2006, 19:52

Supongo a lo que se refiere es en relacionar dos tablas con una cardinalidad de 1 a 1, es decir, que en la tabla A, a cada registro solo le corresponda un registro de la tabla B.

TolaWare · #5 (**permalink**) 30/03/2006, 08:57

se implementa exactamente igual que una relacion 1 a muchos. Salvo que quiera colocar una restriccion explicita sobre esta relación, aunque creo que eso es responsabilidad de la capa de reglas de negocio de la aplicacion.

uamistad · #6 (**permalink**) 30/03/2006, 09:05

Para la relación uno a uno, podrías estar tentado a meter todo en la misma tabla y ahorrarte la relación, pero no es conveniente desde el punto de vista del diseño y el mantenimiento.

Mantener las entidades independientes te permitirá expandir y/o modificar el sistema cuando lo requieras.

Por otro lado, para implementar 1:1, mira quién depende de quién y propaga el ID de el 'padre' en el 'hijo'. Así, el hijo llevará un Foreign Key que indica quién es su padre, pero el padre no tiene ni idea (visto como entidad) de quién es su hijo.

(nota, está mal empleado el termino padre-hijo, debido a qeu se puede suponer que un padre tiene muchos hijos y eso ya corresponde a uno a muchos, 1:N)

pinguina · #7 (**permalink**) 30/03/2006, 11:47

ok, asi lo he hecho, pero eso no implica que la intancia de una entidad1 no pueda tener muchas intancias de entidad2 asociadas, esa era mi pregunta si se puede representar esa restriccion...
o quizas no he entendido??..

.seb · #8 (**permalink**) 30/03/2006, 12:11

Si pones integridad referencia y a la vez ambos son claves de sus respectivas tablas tienes el problema solucionado, habría que ver tu caso si es posible.

Lo otro que se me ocurre es integridad refrencial entre ambas tablas y check constraints en la tabla "hija".

uamistad · #9 (**permalink**) 30/03/2006, 12:18

Cita:

habría que ver tu caso si es posible.

Exacto, además habría que ver tu caso particular para ver si es un buen diseño.

axlkanon7 · #10 (**permalink**) 29/05/2010, 18:14

Cita:

Iniciado por Myakire

Normalmente una relación 1 a 1 es un campo de la misma tabla.

me podrian colaborar con el codigo den relacion uno auno

pierrre18 · #11 (**permalink**) 02/06/2010, 21:58

general mente cuando hay una relacion de uno a undo se considera como iun atributo de la tabla.

aporte de eso alguien puede ayudarme a modelar una base de datos para un un sistema de matricula y ontrol de pensiones de un colegio
suayuda me seria muy util

-rommel_ · #12 (**permalink**) 03/06/2010, 11:28

Pierre18 si podriamos ayudarte... pero no te vamos a dar el diseño... pon tu diseño en la Web y cada uno cual su experiencia obtenida te orientamos... Saludos y exito!

FgBeto · #13 (**permalink**) 20/07/2010, 13:24

hola!!!
las relaciones muchos a muchos cuales son los problemas que a la larga te ocasionan.

es mejor establecer relaciones uno a varios o hacerlo aun mas detallado con relaciones uno a uno

espero y puedan ayudarme!!!!!

iislas · #14 (**permalink**) 20/07/2010, 14:35

FgBeto

Las relaciones MUCHOS-A-MUCHOS, en SQL Server se resuelven colocando una tabla (entidad) que relaciona a ambas, los problemas son de MANTENIMIENTO.

FgBeto · #15 (**permalink**) 27/07/2010, 11:53

Cita:

Iniciado por iislas

FgBeto

Las relaciones MUCHOS-A-MUCHOS, en SQL Server se resuelven colocando una tabla (entidad) que relaciona a ambas, los problemas son de MANTENIMIENTO.

mmm!! entonces tu que me recomiendas, que cambie el esuqema de mi BD, para no utilizar estas relaciones, o asi la termino?

iislas · #16 (**permalink**) 27/07/2010, 12:00

Nop, solo comente la forma de solucionar la relacion MUCHOS-A-MUCHOS y es completamente valida

FgBeto · #17 (**permalink**) 03/08/2010, 12:07

iislas...

gracias por el comentario, y ps ya ermine de desarrollar la BD, solo tengo que hacerla amigable (bonita), para el usuario xD

-rommel_ · #18 (**permalink**) 03/08/2010, 13:17

y tu BD sobre que es??? de que es??? para que es??? SOLo para imaginarnos pues

jordan99 · #19 (**permalink**) 25/08/2010, 01:25

Tengo un caso especifico. Es un proceso de sorteo.

Por ejemplo tengo una tabla sorteo que se relaciona de uno a uno con otra tabla formulario. Es decir, solo un formulario se debe relacionar con un sorteo.

Como implementaria este caso?

iislas · #20 (**permalink**) 25/08/2010, 10:28

La tabla sorteo, debe tener una PK (llave primaria), que en formulario, se convertira en un FK (Foreing Key), a su vez, en esta tabla, creas un INDICE UNIQUE por esa columna