Como normalizar esto? (parece facil pero yo no pude)

[enridp]

Hola! hace ya un buen rato que estoy tratando de encontrar la mejor "normalizacion" para el siguiente ejemplo y no pude llegar a algo que me convenza.

Supongamos una simple tabla USUARIOS, con los campos clasicos, no importa.
Si queremos definir los usuarios que son HERMANOS, cual es la mejor manera?

Obviamente poner una columna "hermanos" dentro de usuarios no.
Pero tampoco me convence crear una tabla HERMANOS que tenga 2IDs a la tabla USUARIOS.
Porque en este ultimo caso podria haber datos "repetidos". Por ej: una fila en la tabla HERMANOS con 1,2 y otra con 2,1 estarian diciendo las dos que 1 y 2 son hermanos.

Este mismo problema se puede plantear en otras situaciones (por ejemplo comercios con sucursales, etc).

Existe alguna solución más efectiva?

[Thumper]

Explica porque colocar una columna "hermanos" no es la solución???

Tal vez colocar el dato a colocar es lo q no tienes claro, yo le aumentaria esa columna y el valor q le pondría no sería un "Id de Usuario" sino un "Id de Grupo":

id - usuario - hermano
1 - usuario1 - 1
2 - usuario2 - 1
3 - usuario3 - 2
4 - usuario4 - 2
5 - usuario5 - 1

Por ejemplo todos los usuario q tengan en el campo "hermano" 1 son hermanos ( usuario1, usuario2 y usuario5) así mismo los q tienen el valor 2 son hermanos( usuario3 y usuario4 )

saludos

[enridp]

No habia pensado en esa alternativa, pero que pasa si no tiene hermanos?
Ademas que al hacerlo como una columna no tendriamos control sobre la integridad (no existirian claves foraneas que controlar).

Supongo que si no tiene hermanos el valor de esa columna seria NULL, pero esto segun las reglas de normalización no es una buena idea por lo general, sobre todo si tenemos en cuenta que podria haber GRAN cantidad de usuarios sin hermanos (y por lo tanto casi toda esa columna podria tener valor NULL).
Por eso preguntaba cual es la mejor estrategia de normalización.

En principio me agrada mas tu solucion que la de crear una tabla donde los valores puedan estar repetidos y la busqueda sea un poco mas complicada. Pero no estoy seguro de cual es el mejor diseño.

[gnzsoloyo]

La solución surge de la misma definición de la relación que podemos definir como "es hermano de".

La cosa es así: Tienes una entidad denominada Usuario, la cual tiene una relación consigo misma que se define como "un usuario puede tener uno o más hermanos, que a su vez son otros usuarios".

Esto implica que en la relación un usuario puede tener cero o muchos hermanos y cada uno de esos hermanos a su vez puede tener cero o muchos hermanos.

Esto es lo que se denomina relación N:N, y por definición del modelo relacional, toda relación N:N entre entidades genera una tabla en el modelo de datos.

Entonces, tienes dos tablas: Usuario y Es_Hermano_de, exactamente como lo planteaste originalmente. Esa es la forma correcta.

Ahora bien, lo que a tí te llama la atención es que eventualmente tendrás que una vinculación aparentemente duplicada, cuando el hermano 1 y el 2 aparezcan en dos claves como (1, 2) y (2, 1). Bueno, eso es absolutamente irrelevante, porque no son claves iguales, y además la semantica de la relación está balando de dos cosas diferentes cuando se menciona ambas claves: el origen de la relación en un caso el el hermano 1 y en el otro es el 2. Desde el punto de vista del análisis de datos es diferente...

¿Se comprende?

Piensalo a nivel de búsquedas: SI quiero encontrar a los hermanos de María, no es lo mismo que si quiero encontrar a las hermanas de Juan... No estoy buscando lo mismo y por tanto la consulta no se escribe igual, según el orden de los campos de que figuran en esa relación...

¿Ahora lo visualizas?

Esa es la idea.

Tip final: No sirve poner una columna para "hermano" en la tabla Usuario, porque en esa columna sólo podrías poner una PK, lo que implicaría que el usuario sólo podría tener un hermano, lo que es irreal. Y no puedes poner múltiples valores en un campo, porque eso es una violación al modelo relacional y lo único que conseguirías es hacer a las consultas enormemente complejas.

[enridp]

Hola gonzalo, lo que proponia Thumper no es poner en la columna Hermano el ID del usuario sino otro numero cualquiera, que represente un "numero de grupo", asi todos los que tengan el mismo valor en la columna Hermanos serian hermanos.

Estoy de acuerdo con lo que dices de la tabla "es_hermano_de" pero entonces tendria que asegurarme que TODO este duplicado para que funcione correctamente no?
Es decir, cada vez que se agrega un "hermano" ponerlo de las dos formas en la tabla.
Supongamos, si tenemos usuario "1" y se agrega el usuario "2" y es hermano de 1, en la tabla agregar 2 filas:
2,1
1,2
Si ahora se agrega 3 y es hermano tambien de 1, agregar:
3,1
1,3
3,2
2,3

El UPDATE_CASCADE y DELETE_CASCADE funcionaran bien en una tabla asi? si borro/cambio el usuario 1 me borra/cambia tanto el 1,2 como el 2,1?

[gnzsoloyo]

Estoy de acuerdo con lo que dices de la tabla "es_hermano_de" pero entonces tendria que asegurarme que TODO este duplicado para que funcione correctamente no?
Es decir, cada vez que se agrega un "hermano" ponerlo de las dos formas en la tabla.
Supongamos, si tenemos usuario "1" y se agrega el usuario "2" y es hermano de 1, en la tabla agregar 2 filas:
2,1
1,2
Si ahora se agrega 3 y es hermano tambien de 1, agregar:
3,1
1,3
3,2
2,3

Eso es una decisión basada en las reglas del negocio, más que en la lógica de los datos. No se trata de algo mandatorio, aunque resulte obviamente lógico.
Miralo desde esta óptica: ¿Y si uno de los usuarios no quiere declarar su parentezco con la otra persona, qué? ¿Lo pondrás de todos modos?
A menos que sea un asunto de administración interna, no puedes. No te olvides que el diseño del modelo de datos no puede exceder los límites del análisis del sistema realizado, es decir, no puedes poner cosas que no hayan sido tomadas del relevamiento, o que no surjan de los requerimientos.
Cualquier duda, hay que consultar al cliente.

El UPDATE_CASCADE y DELETE_CASCADE funcionaran bien en una tabla asi? si borro/cambio el usuario 1 me borra/cambia tanto el 1,2 como el 2,1?

No hay ninguna razón para que no funcione bien. Absolutamente ninguna. Recuerda que el ON DELETE CASCADE sólo afecta a la tabla Es_Hermano_De... Si el usuario 1 es eliminado, se borra todo registro que lo vincule con el usuario 2, TODOS. Lo que no se hace es borrar al usuario 2. Eso es tema aparte.

[enridp]

Si me queda mas claro, gracias gnzsoloyo!