cuando usar un Trigger?

"Jorge" escribió en el mensaje
news:4821ca59$0$12979$
Mostrar la cita

Tengo la siguiente inquietud,
Contamos con una Tabla Maestra "CasosJudiciales" que tiene un campo tipo
varchar(20) llamado "NumerodelCaso"
esta table tiene muchas tablas hijas y por proposito de reportes
duplicamos dicho campo "NumerodelCaso" en cada tabla hija (si ya sabemos
que esto rompe las reglas de estandarizacion)
ocurre que el usuario a veces se equivoca al escribir el numero del caso y
las tablas hijas no son actualizadas correctamente asi que ellas quedan
con el numero del caso errado, la pregunta es podriamos emplear Triggers
para actualizar el "numerodelcaso" en las tablas hijas? estuve leyendo
hacerca de los trigger y por lo que visto puedo crear uno al momento del
update de dicho campo.
El hecho es que no tenemos acceso a los fuentes de la aplicacion y
queremos darle una solucion a ese problemita.

Hola, Jorge:

Ante todo, la aplicación debería asegurar que fuera imposible escribir mal
el número de caso.

Entiendo que el Número de Caso no es la clave primaria de la tabla
CasosJudiciales, ya que de ser así, cumpliría la función de clave foránea en
las tablas hijas, y no estarías rompiendo ninguna "regla de
estandarización".

Pero si hablas de "tablas hijas", supongo que debe existir una clave
principal en la tabla de CasosJudiciales y una clave foránea en cada una de
las tablas hijas, que permita la relación entre ellas.

Podrías usar un trigger, pero en este caso me parece más procedente un
conjunto de reglas de integridad referencial, que establezcan la
actualización en cascada desde CasosJudiciales.NumeroDelCaso sobre cada una
de las tablas hijas.

"Romper la estandarización" fue el primer mal paso, y estás a punto de dar
el segundo (si es que no ha habido otros que no vienen a cuento).

En estas condiciones no hay buen consejo que valga: si no querías definir
los reportes sobre una consulta dinámica basada en la relación entre las
tablas "hijas" y la maestra, podrías haber creado vistas y definido los
reportes sobre éstas.


Salud!

Gracias por tu respuesta Leonardo,
cuando te refieres a un conjunto de reglas de integridad referencial: te
refieres a desarrollarlas mediante SQL o mediante el aplicativo?
podrias elaborar un breve ejemplo? solo necesito tener la idea para poder
"arreglar" esta situacion
de nuevo muchas gracias.
jorge

"Leonardo Azpurua" <l e o n a r d o [arroba] m v p s [punto] o r g> wrote in
message news:
Mostrar la cita

"Jorge" escribió en el mensaje
news:4821ca59$0$12979$
Mostrar la cita

Tengo la siguiente inquietud,
Contamos con una Tabla Maestra "CasosJudiciales" que tiene un campo tipo
varchar(20) llamado "NumerodelCaso"
esta table tiene muchas tablas hijas y por proposito de reportes
duplicamos dicho campo "NumerodelCaso" en cada tabla hija (si ya sabemos
que esto rompe las reglas de estandarizacion)
ocurre que el usuario a veces se equivoca al escribir el numero del caso
y las tablas hijas no son actualizadas correctamente asi que ellas quedan
con el numero del caso errado, la pregunta es podriamos emplear Triggers
para actualizar el "numerodelcaso" en las tablas hijas? estuve leyendo
hacerca de los trigger y por lo que visto puedo crear uno al momento del
update de dicho campo.
El hecho es que no tenemos acceso a los fuentes de la aplicacion y
queremos darle una solucion a ese problemita.

Hola, Jorge:

Ante todo, la aplicación debería asegurar que fuera imposible escribir mal
el número de caso.

Entiendo que el Número de Caso no es la clave primaria de la tabla
CasosJudiciales, ya que de ser así, cumpliría la función de clave foránea
en las tablas hijas, y no estarías rompiendo ninguna "regla de
estandarización".

Pero si hablas de "tablas hijas", supongo que debe existir una clave
principal en la tabla de CasosJudiciales y una clave foránea en cada una
de las tablas hijas, que permita la relación entre ellas.

Podrías usar un trigger, pero en este caso me parece más procedente un
conjunto de reglas de integridad referencial, que establezcan la
actualización en cascada desde CasosJudiciales.NumeroDelCaso sobre cada
una de las tablas hijas.

"Romper la estandarización" fue el primer mal paso, y estás a punto de dar
el segundo (si es que no ha habido otros que no vienen a cuento).

En estas condiciones no hay buen consejo que valga: si no querías definir
los reportes sobre una consulta dinámica basada en la relación entre las
tablas "hijas" y la maestra, podrías haber creado vistas y definido los
reportes sobre éstas.


Salud!

Hola Leonardo,

On Wed, 7 May 2008 11:16:57 -0430, "Leonardo Azpurua" <l e o n a r d o
[arroba] m v p s [punto] o r g> wrote:

Mostrar la cita

Ante todo, la aplicación debería asegurar que fuera imposible escribir mal
el número de caso.

Ante todo el SGBD debería asegurar que fuese imposible que se guardase
mal el número de caso :-)

Mostrar la cita

Entiendo que el Número de Caso no es la clave primaria de la tabla
CasosJudiciales, ya que de ser así, cumpliría la función de clave foránea en
las tablas hijas, y no estarías rompiendo ninguna "regla de
estandarización".

Ya, pero si Número de caso es un dato redundante como creo haber
entendido entonces estaría rompiendo las reglas de normalización.

Mostrar la cita

En estas condiciones no hay buen consejo que valga: si no querías definir
los reportes sobre una consulta dinámica basada en la relación entre las
tablas "hijas" y la maestra, podrías haber creado vistas y definido los
reportes sobre éstas.

Aun está a tiempo de convertir las tablas en vistas y normalizar la
base de datos.


Saludos
Alfredo

"Jorge" escribió en el mensaje
news:4821d840$0$12933$
Mostrar la cita

Gracias por tu respuesta Leonardo,
cuando te refieres a un conjunto de reglas de integridad referencial: te
refieres a desarrollarlas mediante SQL o mediante el aplicativo?
podrias elaborar un breve ejemplo? solo necesito tener la idea para poder
"arreglar" esta situacion
de nuevo muchas gracias.

Hola.

Entiendo que no tienes acceso al codigo fuente de la aplicación.

No describes muy bien en qué condiciones "se equivoca" el operador. Supongo
que altera indebidamente el identificador de un caso y que al hacer esto
deja un número de caso inconsistente en las tabals hijas, que por otra parte
sí que tienen una referencia correcta a otra clave del mismo caso (que
enredo!).

Pero hay un hecho, y es que si F es una fila de una tabla hija, entonces
debería haber otra fila C de la tabla de casos tal que F.IdCaso = C.IdCaso,
sólo que esa relación no se está forzando.

Para crear una regla de identidad referencial puedes hacer algo como esto:

ALTER TABLE <TablaHija>
ADD CONSTRAINT <nombreRegla>
FOREIGN KEY (<columnaClave>)
REFERENCES <TablaMaestra> (<columnaClaveTM>)
ON UPDATE CASCADE

Un ejemplo concreto:

ALTER TABLE IncidenciasCasos
ADD CONSTRAINT FK_Casos_Incidencias
FOREIGN KEY (NumeroDelCaso)
REFERENCES CasosJudiciales (NumeroDelCaso)
ON UPDATE CASCADE

si quieres que al borrar el caso se lleve consigo todas las incidencias,
puedes agregar la clausula ON DELETE CASCADE. Pero el ejemplo hará que cada
vez que se modifique el NumeroDelCaso de una fila de CasosJudiciales, los
NumeroDelCaso de la tabla IncidenciasCasos asuman el nuevo valor
automáticamente.

Para poder definir esta restricción, es necesario que el NumeroDeCaso de
cada fila de la tabla IncidenciasCasos contenga un valor que exista en la
celda NumeroDelCaso de alguna fila de la tabla CasosJudiciales.

Debes agregar una regla semejante para cada una de las "tablas hijas".


Salud!

Muchisimas gracias, con respecto al disenho me reservo los comentarios, soy
conciente del HORROR (por no decir Error) pero bueno que posicion debo tomar
cuando me enfrento a este tipo de situaciones? el Numero de Caso no es un
dato trivial es muy importante y no se pueden cometer errores al momento de
ingresarlo, si el operador lo escribe mal tiene que ser corregido
inmediatamente y si las tablas hijas no son actualizadas con el dato
correcto se arma.. .la grande. Igual tengo que ver que mas cosas se le ha
escapado a este disenho.

"Leonardo Azpurua" <l e o n a r d o [arroba] m v p s [punto] o r g> wrote in
message news:
Mostrar la cita

"Jorge" escribió en el mensaje
news:4821d840$0$12933$
Mostrar la cita

Gracias por tu respuesta Leonardo,
cuando te refieres a un conjunto de reglas de integridad referencial: te
refieres a desarrollarlas mediante SQL o mediante el aplicativo?
podrias elaborar un breve ejemplo? solo necesito tener la idea para poder
"arreglar" esta situacion
de nuevo muchas gracias.

Hola.

Entiendo que no tienes acceso al codigo fuente de la aplicación.

No describes muy bien en qué condiciones "se equivoca" el operador.
Supongo que altera indebidamente el identificador de un caso y que al
hacer esto deja un número de caso inconsistente en las tabals hijas, que
por otra parte sí que tienen una referencia correcta a otra clave del
mismo caso (que enredo!).

Pero hay un hecho, y es que si F es una fila de una tabla hija, entonces
debería haber otra fila C de la tabla de casos tal que F.IdCaso =
C.IdCaso, sólo que esa relación no se está forzando.

Para crear una regla de identidad referencial puedes hacer algo como esto:

ALTER TABLE <TablaHija>
ADD CONSTRAINT <nombreRegla>
FOREIGN KEY (<columnaClave>)
REFERENCES <TablaMaestra> (<columnaClaveTM>)
ON UPDATE CASCADE

Un ejemplo concreto:

ALTER TABLE IncidenciasCasos
ADD CONSTRAINT FK_Casos_Incidencias
FOREIGN KEY (NumeroDelCaso)
REFERENCES CasosJudiciales (NumeroDelCaso)
ON UPDATE CASCADE

si quieres que al borrar el caso se lleve consigo todas las incidencias,
puedes agregar la clausula ON DELETE CASCADE. Pero el ejemplo hará que
cada vez que se modifique el NumeroDelCaso de una fila de CasosJudiciales,
los NumeroDelCaso de la tabla IncidenciasCasos asuman el nuevo valor
automáticamente.

Para poder definir esta restricción, es necesario que el NumeroDeCaso de
cada fila de la tabla IncidenciasCasos contenga un valor que exista en la
celda NumeroDelCaso de alguna fila de la tabla CasosJudiciales.

Debes agregar una regla semejante para cada una de las "tablas hijas".


Salud!