ciclos o múltiples rutas al Crear DRI sobre 3 Tablas

Antes de nada saludos a todos los integrantes de este comunidad. soy nuevo en
el mundo MSSQL y como veran con
muchas dudas. Gracias a todos de antenamano . Y bueno necesitaría que
si alguien me podría orientar en un error en el diseño de una BD. Utilizo:
Lenguaje: VB 6.0
SGBD: MS Sql Express 2005 .
Administrador SGBD: SQL Server Management Studio Express.

Tablas:
Provincias
ID_PROV (CP)
……….

Promotores
ID_PROM (CP)
ID_PROV (CF)
………….

Socios
ID_SOCIO (CP)
ID_PROM (CF)
ID_PROV (CF)
………….

Relación:
1) Provincia – 1:M – Socios (Una "Provincia" tiene Muchos "Socios")
(Update en Cascada; Delete No Action)

2) Provincia – 1:M – Promotor (Una "Provincia" tiene Muchos "Promotores")
(Update en Cascada; Delete No Action)

3) Promotor – 1:M – Socios (Un "Promotor" tiene Muchos "Socios")
(Update en Cascada; Delete No Action)

Todo marcha bien hasta la generación de la relación Nº 3. Me entrega
el siguiente error:

- No se puede crear la relación 'FK_Socios_Promotores'.
Si especifica la restricción FOREIGN KEY 'FK_Socios_Promotores' en la
tabla 'Socios', podrían producirse ciclos o múltiples rutas en
cascada. Especifique ON DELETE NO ACTION o UPDATE NO ACTION, o bien
modifique otras restricciones FOREIGN KEY.
No se pudo crear la restricción. Consulte los errores anteriores.

(A tener en cuenta, EL ID_PROV (Id de provincia) del promotor no es el mismo
a la de la persona que el mismo asocio).
La verdad yo use estas relaciones en Ms Access y MySQL y no tuve
problema en la generación de las mismas. La verdad no se si me perdí
de algún concepto, pero bueno, sigo buscando info en los buscadores.
Por alli vi que hay dos maneras de implementar la integridad referencial
una de ellas es la forma clasica, como la estoy intentando yo y la otra es a
partir de disparadores. La verdad no conozco la ventaja de uno sobre otro. Si
alguien tiene alguna idea/opinión les agradecería. Desde
ya Muchisimas Gracias. Saludos Pablo N.

Hola Pablo,

Es preferible usar integridad referencial declarativa (DRI), siempre y
cuando sea posible, pues de esta forma el motor es quien se encarga de
enforzar la restriccion. Cuando usas disparadores o procedimientos
almacenados, estas forzando la integridad de forma procedural, por lo que si
multiples aplicaciones / batches / scripts / etc. llevan a cabo la accion,
todos ellos deben chequear que se fuerze la integridad.

Logicamente que aqui tienes una relacion circular.

|--
Provincia -- Promotor
|--

|
|
| | |

|--
Provincia -- Socio
|--

Puedes tratar de ver como romper esa relacion para que puedes usar acciones
en cascada, de lo contrario, te recomiendo uses un procedimiento almacenado
para llevar a cabo esas acciones y darle acceso a los clientes a llevar a
cabo estas solo mediante el uso del procedimiento almacenado.


AMB

"Pablo N" wrote:

> Antes de nada saludos a todos los integrantes de este comunidad. soy nuevo en
> el mundo MSSQL y como veran con
> muchas dudas. Gracias a todos de antenamano . Y bueno necesitaría que
> si alguien me podría orientar en un error en el diseño de una BD. Utilizo:
> Lenguaje: VB 6.0
> SGBD: MS Sql Express 2005 .
> Administrador SGBD: SQL Server Management Studio Express.
>
> Tablas:
> Provincias
> ID_PROV (CP)
> ……….
>
> Promotores
> ID_PROM (CP)
> ID_PROV (CF)
> ………….
>
> Socios
> ID_SOCIO (CP)
> ID_PROM (CF)
> ID_PROV (CF)
> ………….
>
> Relación:
> 1) Provincia – 1:M – Socios (Una "Provincia" tiene Muchos "Socios")
> (Update en Cascada; Delete No Action)
>
> 2) Provincia – 1:M – Promotor (Una "Provincia" tiene Muchos "Promotores")
> (Update en Cascada; Delete No Action)
>
> 3) Promotor – 1:M – Socios (Un "Promotor" tiene Muchos "Socios")
> (Update en Cascada; Delete No Action)
>
> Todo marcha bien hasta la generación de la relación Nº 3. Me entrega
> el siguiente error:
>
> - No se puede crear la relación 'FK_Socios_Promotores'.
> Si especifica la restricción FOREIGN KEY 'FK_Socios_Promotores' en la
> tabla 'Socios', podrían producirse ciclos o múltiples rutas en
> cascada. Especifique ON DELETE NO ACTION o UPDATE NO ACTION, o bien
> modifique otras restricciones FOREIGN KEY.
> No se pudo crear la restricción. Consulte los errores anteriores.
>
> (A tener en cuenta, EL ID_PROV (Id de provincia) del promotor no es el mismo
> a la de la persona que el mismo asocio).
> La verdad yo use estas relaciones en Ms Access y MySQL y no tuve
> problema en la generación de las mismas. La verdad no se si me perdí
> de algún concepto, pero bueno, sigo buscando info en los buscadores.
> Por alli vi que hay dos maneras de implementar la integridad referencial
> una de ellas es la forma clasica, como la estoy intentando yo y la otra es a
> partir de disparadores. La verdad no conozco la ventaja de uno sobre otro. Si
> alguien tiene alguna idea/opinión les agradecería. Desde
> ya Muchisimas Gracias. Saludos Pablo N.
>

Alejandro, antes de nada gracias por su respuesta. Unas pregunta. ¿La manera
con las que definí las DRI, es errónea? ¿Me perdí de algún concepto de como
relacionar tablas y de definir restricciones en las relaciones?. Estas
preguntas rondan en mi cabeza ya que, como dije con anterioridad, las mismas
pude generaralas en BD como Ms Access o MySQL. Gracias.
Pablo N.


"Alejandro Mesa" wrote:

> Hola Pablo,
>
> Es preferible usar integridad referencial declarativa (DRI), siempre y
> cuando sea posible, pues de esta forma el motor es quien se encarga de
> enforzar la restriccion. Cuando usas disparadores o procedimientos
> almacenados, estas forzando la integridad de forma procedural, por lo que si
> multiples aplicaciones / batches / scripts / etc. llevan a cabo la accion,
> todos ellos deben chequear que se fuerze la integridad.
>
> Logicamente que aqui tienes una relacion circular.
>
> |--
> Provincia -- Promotor
> |--
>
> |
> |
> | | |
>
> |--
> Provincia -- Socio
> |--
>
> Puedes tratar de ver como romper esa relacion para que puedes usar acciones
> en cascada, de lo contrario, te recomiendo uses un procedimiento almacenado
> para llevar a cabo esas acciones y darle acceso a los clientes a llevar a
> cabo estas solo mediante el uso del procedimiento almacenado.
>
>
> AMB
>
> "Pablo N" wrote:
>
> > Antes de nada saludos a todos los integrantes de este comunidad. soy nuevo en
> > el mundo MSSQL y como veran con
> > muchas dudas. Gracias a todos de antenamano . Y bueno necesitaría que
> > si alguien me podría orientar en un error en el diseño de una BD. Utilizo:
> > Lenguaje: VB 6.0
> > SGBD: MS Sql Express 2005 .
> > Administrador SGBD: SQL Server Management Studio Express.
> >
> > Tablas:
> > Provincias
> > ID_PROV (CP)
> > ……….
> >
> > Promotores
> > ID_PROM (CP)
> > ID_PROV (CF)
> > ………….
> >
> > Socios
> > ID_SOCIO (CP)
> > ID_PROM (CF)
> > ID_PROV (CF)
> > ………….
> >
> > Relación:
> > 1) Provincia – 1:M – Socios (Una "Provincia" tiene Muchos "Socios")
> > (Update en Cascada; Delete No Action)
> >
> > 2) Provincia – 1:M – Promotor (Una "Provincia" tiene Muchos "Promotores")
> > (Update en Cascada; Delete No Action)
> >
> > 3) Promotor – 1:M – Socios (Un "Promotor" tiene Muchos "Socios")
> > (Update en Cascada; Delete No Action)
> >
> > Todo marcha bien hasta la generación de la relación Nº 3. Me entrega
> > el siguiente error:
> >
> > - No se puede crear la relación 'FK_Socios_Promotores'.
> > Si especifica la restricción FOREIGN KEY 'FK_Socios_Promotores' en la
> > tabla 'Socios', podrían producirse ciclos o múltiples rutas en
> > cascada. Especifique ON DELETE NO ACTION o UPDATE NO ACTION, o bien
> > modifique otras restricciones FOREIGN KEY.
> > No se pudo crear la restricción. Consulte los errores anteriores.
> >
> > (A tener en cuenta, EL ID_PROV (Id de provincia) del promotor no es el mismo
> > a la de la persona que el mismo asocio).
> > La verdad yo use estas relaciones en Ms Access y MySQL y no tuve
> > problema en la generación de las mismas. La verdad no se si me perdí
> > de algún concepto, pero bueno, sigo buscando info en los buscadores.
> > Por alli vi que hay dos maneras de implementar la integridad referencial
> > una de ellas es la forma clasica, como la estoy intentando yo y la otra es a
> > partir de disparadores. La verdad no conozco la ventaja de uno sobre otro. Si
> > alguien tiene alguna idea/opinión les agradecería. Desde
> > ya Muchisimas Gracias. Saludos Pablo N.
> >

Hola Pablo,

No, no es erronea la forma en que definistes las restricciones de integridad
referencial. Quizas el problema sea de SQL Server por no soportar este tipo
de relaciones, o al menos de no soportar las acciones en cascada para este
tipo de relaciones, como por ejemplo cuando una tabla se relaciona mas de una
vez con otra tabla, referenciando la clave primaria en la segunda mas de una
vez.

t1(c1 primary key)
t2(c1 references t1(c1), c2 references t1(c2))

En este tipo de relacion, tampoco podemos definir una accion en cascada.
Igual pasa cuando tenemos una tabla que se auto referencia.

Casi siempre, cuando se tiene una referencia circular, es porque en alguna
parte del diseño se nos paso algo. Por ejemplo, esa relacion pudiera ser asi:

Provincias
ID_PROV (CP)

Promotores
ID_PROM (CP)
ID_PROV (CF)

Socios
ID_SOCIO (CP)
ID_PROM (CF)

Osea, la provincia del Socio, esta determinada pro la provincia del promotor.

AMB

"Pablo N" wrote:

> Alejandro, antes de nada gracias por su respuesta. Unas pregunta. ¿La manera
> con las que definí las DRI, es errónea? ¿Me perdí de algún concepto de como
> relacionar tablas y de definir restricciones en las relaciones?. Estas
> preguntas rondan en mi cabeza ya que, como dije con anterioridad, las mismas
> pude generaralas en BD como Ms Access o MySQL. Gracias.
> Pablo N.
>
>
> "Alejandro Mesa" wrote:
>
> > Hola Pablo,
> >
> > Es preferible usar integridad referencial declarativa (DRI), siempre y
> > cuando sea posible, pues de esta forma el motor es quien se encarga de
> > enforzar la restriccion. Cuando usas disparadores o procedimientos
> > almacenados, estas forzando la integridad de forma procedural, por lo que si
> > multiples aplicaciones / batches / scripts / etc. llevan a cabo la accion,
> > todos ellos deben chequear que se fuerze la integridad.
> >
> > Logicamente que aqui tienes una relacion circular.
> >
> > |--
> > Provincia -- Promotor
> > |--
> >
> > |
> > |
> > | | |
> >
> > |--
> > Provincia -- Socio
> > |--
> >
> > Puedes tratar de ver como romper esa relacion para que puedes usar acciones
> > en cascada, de lo contrario, te recomiendo uses un procedimiento almacenado
> > para llevar a cabo esas acciones y darle acceso a los clientes a llevar a
> > cabo estas solo mediante el uso del procedimiento almacenado.
> >
> >
> > AMB
> >
> > "Pablo N" wrote:
> >
> > > Antes de nada saludos a todos los integrantes de este comunidad. soy nuevo en
> > > el mundo MSSQL y como veran con
> > > muchas dudas. Gracias a todos de antenamano . Y bueno necesitaría que
> > > si alguien me podría orientar en un error en el diseño de una BD. Utilizo:
> > > Lenguaje: VB 6.0
> > > SGBD: MS Sql Express 2005 .
> > > Administrador SGBD: SQL Server Management Studio Express.
> > >
> > > Tablas:
> > > Provincias
> > > ID_PROV (CP)
> > > ……….
> > >
> > > Promotores
> > > ID_PROM (CP)
> > > ID_PROV (CF)
> > > ………….
> > >
> > > Socios
> > > ID_SOCIO (CP)
> > > ID_PROM (CF)
> > > ID_PROV (CF)
> > > ………….
> > >
> > > Relación:
> > > 1) Provincia – 1:M – Socios (Una "Provincia" tiene Muchos "Socios")
> > > (Update en Cascada; Delete No Action)
> > >
> > > 2) Provincia – 1:M – Promotor (Una "Provincia" tiene Muchos "Promotores")
> > > (Update en Cascada; Delete No Action)
> > >
> > > 3) Promotor – 1:M – Socios (Un "Promotor" tiene Muchos "Socios")
> > > (Update en Cascada; Delete No Action)
> > >
> > > Todo marcha bien hasta la generación de la relación Nº 3. Me entrega
> > > el siguiente error:
> > >
> > > - No se puede crear la relación 'FK_Socios_Promotores'.
> > > Si especifica la restricción FOREIGN KEY 'FK_Socios_Promotores' en la
> > > tabla 'Socios', podrían producirse ciclos o múltiples rutas en
> > > cascada. Especifique ON DELETE NO ACTION o UPDATE NO ACTION, o bien
> > > modifique otras restricciones FOREIGN KEY.
> > > No se pudo crear la restricción. Consulte los errores anteriores.
> > >
> > > (A tener en cuenta, EL ID_PROV (Id de provincia) del promotor no es el mismo
> > > a la de la persona que el mismo asocio).
> > > La verdad yo use estas relaciones en Ms Access y MySQL y no tuve
> > > problema en la generación de las mismas. La verdad no se si me perdí
> > > de algún concepto, pero bueno, sigo buscando info en los buscadores.
> > > Por alli vi que hay dos maneras de implementar la integridad referencial
> > > una de ellas es la forma clasica, como la estoy intentando yo y la otra es a
> > > partir de disparadores. La verdad no conozco la ventaja de uno sobre otro. Si
> > > alguien tiene alguna idea/opinión les agradecería. Desde
> > > ya Muchisimas Gracias. Saludos Pablo N.
> > >