Problema con claves

Hola Alejandro,

On 7 dec, 00:57, Alejandro Mesa
wrote:

Carlos,

Mi error, cuando estava escribiendo el mensaje me retracte, pero no elimine
la primera oracion. Por eso la pregunta de porque tiene dos columnas
apuntando a la misma tabla, cosa que pudiera ser comun, pero primero queria
estar seguro sobre lo que se esta modelando.

Ah! Bueno... es que me tenía intrigado eso del normalizar.

En el caso de ejemplo que pones, una invitacion se puede considerar un
evento, por lo que podriamos usar algo como:

personas (persona_id, nombre, ...)
eventos (evento_id, nombre, ...)
rol(rol_id, nombre, ...)
personas_eventos(persona_id, evento_id, rol)

Como vez, no hace falta referenciar la misma tabla dos veces, pero claro
esta que despues de las primeras dos cervezas se pudiera cambiar este modelo
:-))

:-) Con este modelo ya se pueden registrar todas las cervezas
aparte, quien era el camarero, y a quienes hemos encontrado
por el camino. Yo solo trataba de modelar quien ha invitado
a quien (si o no) alguna vez :-)

Tu modelo tiene un efecto en mi parecido al de un par de cervezas :-)

Saludos,
Carlos

Hola Alejandro,

On 7 dic, 00:57, Alejandro Mesa
wrote:

En el caso de ejemplo que pones, una invitacion se puede considerar un
evento, por lo que podriamos usar algo como:

personas (persona_id, nombre, ...)
eventos (evento_id, nombre, ...)
rol(rol_id, nombre, ...)
personas_eventos(persona_id, evento_id, rol)

Como vez, no hace falta referenciar la misma tabla dos veces, pero claro
esta que despues de las primeras dos cervezas se pudiera cambiar este modelo
:-))

Pero este diseño tiene claras desventajas. Para establecer una
relación entre dos personas tienes que insertar varias filas en lugar
de una y antes había dos tablas y ahora hay 4.

Espero que tú no le llames normalizar a esto :-)

Está clarísimo que el no poder hacer lo que mooonk quiere es un
defecto de SQL Server que debería de ser arreglado. Y como no lo van a
arreglar en muchos años o nunca entonces lo mejor será usar un
trigger.



Saludos

Hola Alfredo, Hola Alejandro,


On 7 dec, 01:26, Alfredo Novoa wrote:

Hola Alejandro,

On 7 dic, 00:57, Alejandro Mesa

wrote:
> En el caso de ejemplo que pones, una invitacion se puede considerar un
> evento, por lo que podriamos usar algo como:

> personas (persona_id, nombre, ...)
> eventos (evento_id, nombre, ...)
> rol(rol_id, nombre, ...)
> personas_eventos(persona_id, evento_id, rol)

> Como vez, no hace falta referenciar la misma tabla dos veces, pero claro
> esta que despues de las primeras dos cervezas se pudiera cambiar este modelo
> :-))

Pero este diseño tiene claras desventajas. Para establecer una
relación entre dos personas tienes que insertar varias filas en lugar
de una y antes había dos tablas y ahora hay 4.

A mi lo primero que me saltó a la vista es que el OP dice que
tabla_2 'define una relacion entre dos registros de tabla_1'.

Dos registros (no necesariamente distintos) están relacionados
entre sí o no. Entendí también que está haciendo las cosas
bien y SQL Server no le deja. El problema no es su diseño,
sino SQL Server.

Espero que tú no le llames normalizar a esto :-)

Espero que no.

Está clarísimo que el no poder hacer lo que mooonk quiere es un
defecto de SQL Server que debería de ser arreglado. Y como no lo van a
arreglar en muchos años o nunca entonces lo mejor será usar un
trigger.

O pasarse a D4 (Dataphor) :-)
Me he molestado en montar un ejemplo con lo de la cerveza.
Alejandro, si no lo conoces, la sintaxis es parecida SQL y habla
por si sola. Espero que te parezca interesante. Lo importante es
que funciona como Dios manda.

En SQL Server para los on update cascade esto daría problemas
hasta con los triggers para poder identificar que registros en
la tabla deleted van con que registros en la tabla inserted.

Pongo resultados intermedios de consultas como comentario en el
codigo para que se vean los efectos de los updates y deletes.

create table Personas
{
codigo : Integer,
nombre : String,

key { codigo }
};

create table InvitaACerveza
{
malhechor : Integer,
victima : Integer,

key {malhechor, victima},
reference invita_malhechor_persona { malhechor }
references Personas { codigo } update cascade delete cascade,
reference invita_victima_persona { victima }
references Personas { codigo } update cascade delete cascade
};

insert table { row { 1 codigo, 'Pepe' nombre },
row { 2, 'Pedro' },
row { 3, 'Juan' },
row { 4, 'Manolo' },
row { 5, 'Paco' } }
into Personas;

insert table { row { 1 malhechor, 2 victima},
row { 1, 3 },
row { 2, 3 },
row { 3, 4 },
row { 3, 5 },
row { 4, 5 } }
into InvitaACerveza;

update Personas set { codigo := 13 } where codigo = 3;

select Personas;

/* Resultado:
codigo nombre

1 Pepe
2 Pedro
4 Manolo
5 Paco
13 Juan
*/

select InvitaACerveza;

/* Resultado:
malhechor victima
-
1 2
1 13
2 13
4 5
13 4
13 5
*/

delete Personas where codigo = 13;

select Personas;

/* Resultado
codigo nombre

1 Pepe
2 Pedro
4 Manolo
5 Paco
*/

select InvitaACerveza;

/* Resultado:
malhechor victima
-
1 2
4 5
*/

drop table InvitaACerveza;

drop table Personas;


Saludos,
Carlos

Alfredo Novoa,

Espero que tú no le llames normalizar a esto :-)

Entonces te pregunto como le debo llamar?

empleados(empleado_id,...,numero_celular_1, numero_celular_2,
numero_celular_3)

Cuando ??????, quedaria:

empleados(empleado_id)
empleado_telefonos(empleado_id, numero_telefono, tipo)


AMB


"Alfredo Novoa" wrote:

Hola Alejandro,

On 7 dic, 00:57, Alejandro Mesa
wrote:

> En el caso de ejemplo que pones, una invitacion se puede considerar un
> evento, por lo que podriamos usar algo como:
>
> personas (persona_id, nombre, ...)
> eventos (evento_id, nombre, ...)
> rol(rol_id, nombre, ...)
> personas_eventos(persona_id, evento_id, rol)
>
> Como vez, no hace falta referenciar la misma tabla dos veces, pero claro
> esta que despues de las primeras dos cervezas se pudiera cambiar este modelo
> :-))

Pero este diseño tiene claras desventajas. Para establecer una
relación entre dos personas tienes que insertar varias filas en lugar
de una y antes había dos tablas y ahora hay 4.

Espero que tú no le llames normalizar a esto :-)

Está clarísimo que el no poder hacer lo que mooonk quiere es un
defecto de SQL Server que debería de ser arreglado. Y como no lo van a
arreglar en muchos años o nunca entonces lo mejor será usar un
trigger.



Saludos

Hola Alejandro,

El Sun, 7 Dec 2008 08:26:01 -0800, Alejandro Mesa escribió:

Espero que tú no le llames normalizar a esto :-)

Entonces te pregunto como le debo llamar?

Pues cambiar el diseño o algo así.

Pero desde luego no normalizar. Normalizar no significa aumentar el número
de tablas sin más, sino que significa modificar un diseño para hacer que
las "tablas" estén en formas normales superiores.

empleados(empleado_id,...,numero_celular_1, numero_celular_2,
numero_celular_3)

Esto está en 5NF (si no hay cosas raras en los puntos suspensivos).

Otra cosa es si este diseño es bueno o no, y no lo parece mucho.

Cuando ??????, quedaria:

empleados(empleado_id)
empleado_telefonos(empleado_id, numero_telefono, tipo)

Y esto también está en 5NF. No has alcanzado una forma normal superior, por
lo tanto no has normalizado nada.



Saludos
Alfredo