AYUDA!!!! Relacion 1:1 con 1 o con 2 tablas

mdromed · #1 (**permalink**) 16/09/2009, 09:15

Hola a todos.
Vereis tengo una tabla de usuarios y otra de paises.
1 Usuario solo puede pertenecer a 1 pais (aunque pensandolo bien 1 pais si que puede estar contemplado en varios usuarios).

Bueno, corregidme si me equivoco.

Hasta ahora, ante este caso, normalmente había hecho lo siguiente:

Crear 2 tablas: Una de usuarios y otra de paises. Ya se que en la misma tabla se podrian meter los 2 campos (pq es una relacion 1:1), pero como en la tabla paises quiero que tb vayan asociados el nombre del archivo de imagen de su banderita y otros campos propios del pais como su codigo de telefono, su idioma, ...

El caso es que dudo en si:

1º: Hacer con todo 1 sola tabla, en cuyo caso supongo que luego las consultas tardarán menos puesto que no tengo que hacer ningun join con ninguna otra tabla.
Quedaría asi:

TABLAUSUARIOS
_______________
idusuario
nombre
apellidos
nombrepais
banderapais
idiomapais
codtlfpai
etc...

o 2º: Hacerlo en 2 tablas, en cuyo caso se tardaría mas en hacer las consultas ya que necesito hacer un join entre las 2 tablas.
Pero la tabla de usuarios quedaria mas "limpia" ya que no tendria tantos campos del pais ahi en la misma tabla, sino que con un "idpais" podriamos cruzarla con la tabla de paises.
Quedaria asi:

TABLAUSUARIOS
_______________
idusuario
nombre
apellidos
idpais

TABLAPAISES
______________
idpais
nombrepais
banderapais
idiomapais
codtlfpais

BUENO, ESO ES TODO.
A ver que me podeis aconsejar.
Gracias!

huesos52 · #2 (**permalink**) 16/09/2009, 09:28

Realmente lo que tienes es una relación 1:N y te recomiendo lo hagas de la segunda forma.

un usuario solo pertenece a un pais, pero un pais puede tener registros de múltiples usuarios.
Si lo tuvieras como la primera opción, la información de países sería redundante en todos los casos. tendrías registros diferentes para un usuario de colombia o de Colombia, pudiendo centralizar la información en una tabla países con un único colombia.

Entiendes la idea?

saludos

mdromed · #3 (**permalink**) 16/09/2009, 09:44

Cita:

Iniciado por huesos52

Realmente lo que tienes es una relación 1:N y te recomiendo lo hagas de la segunda forma.

un usuario solo pertenece a un pais, pero un pais puede tener registros de múltiples usuarios.
Si lo tuvieras como la primera opción, la información de países sería redundante en todos los casos. tendrías registros diferentes para un usuario de colombia o de Colombia, pudiendo centralizar la información en una tabla países con un único colombia.

Entiendes la idea?

saludos

Estas seguro de que es una relacion 1:N?
Entonces ¿Me puedes dar un ejemplo de una relacion 1:1? Es que no encuentro ninguna entonces.

De todos modos no se crearían registros diferentes con "colombia" y "COLOMBIA" puesto que la web ya se encarga de normalizar esos valores para que se guarden siempre igual.

mdromed · #4 (**permalink**) 16/09/2009, 09:53

Ah va, ok huesos52 tienes razon. Tiene que ser una 1:N ya que he encontrado una 1:1 y sí que hay diferencia.

La relacion 1:1 sería por ejemplo: Usuarios ----> DNIs , es decir, 1 solo usuario tiene 1 solo DNI...... y solo 1 DNI pertenece a solo 1 usuario.
En este caso no tendria sentido tener 2 tablas ya que una relacion 1:1 es la misma tabla.

Ahora bien, tambien es cierto que siguiendo este mismo concepto entonces el "nombre" del usuario tambien deberia ser una relacion 1:N no? ya que 1 usuario solo puede tener 1 solo nombre (Ej: Juan), pero 1 nombre lo pueden tener N usuarios (Puede haber muchos Juanes).
En este caso que tendríamos que poner en la tabla de usuarios? un "idnombre" en lugar de escribir el nombre????

huesos52 · #5 (**permalink**) 16/09/2009, 09:59

Un ejemplo de una relación 1:1 sería la cedula con la huella dactilar.
1 cédula solo puede tener una huella. Y una huella, solo puede estar registrada a nombre de una cédula. La solución en este caso, sería poner ambos atributos en una única tabla. Se tiene la certeza que solo se requiere un registro para guardar dicha información.

con respecto a los pasises... si tenés una tabla usuarios con atributos como pais, se podría presentar esto:

Código mysql:

Ver originalmysql> select *from usuario;
+---------+-----------+
| nombre  | pais      |
+---------+-----------+
| daniel  | mexico    |
| daniela | Mejico    |
| angela  | Mexico DF |
+---------+-----------+
3 rows in set (0.00 sec)
 
mysql>

de la segunda forma, controlas que mexico solo hay uno y está identificado con un código. De esta forma los usuarios reciben el código del pais al que pertenecen y se mantiene la consistencia del sistema.

EDITO: tu mismo lo dijiste.

mdromed · #6 (**permalink**) 16/09/2009, 10:46

ok pero que me dices de esto:

"Siguiendo este mismo concepto entonces el "nombre" del usuario tambien deberia ser una relacion 1:N no? ya que 1 usuario solo puede tener 1 solo nombre (Ej: Juan), pero 1 nombre lo pueden tener N usuarios (Puede haber muchos Juanes).
En este caso que tendríamos que poner en la tabla de usuarios? un "idnombre" en lugar de escribir el nombre???? "

Tambien deberia haber 2 tablas no? ya que es una relacion 1:N.
Una primera tabla de usuarios con el campo "idnombre" y otra tabla de nombres a la que hace referencia no?

TABLAUSUARIOS
_____________
idusuario
idpais
idnombre
dni
codigohuella

TABLAPAISES
___________
idpais
pais
bandera
idioma

TABLANOMBRESDEPERSONAS
_______________________
idnombre
nombre

huesos52 · #7 (**permalink**) 16/09/2009, 10:55

La tabla nombres personas no es necesaria.
solo pon el nombre en la tabla personas al lado del id.

mdromed · #8 (**permalink**) 16/09/2009, 11:53

Cita:

Iniciado por huesos52

La tabla nombres personas no es necesaria.
solo pon el nombre en la tabla personas al lado del id.

Yo tambien lo veo innecesario pero si nos fijamos al pie de la letra en las normas de las relaciones de las bases de datos deberían ir en tablas diferentes como te he comentado no?

1000 Gracias por tu ayuda.

huesos52 · #9 (**permalink**) 16/09/2009, 12:20

No mdromed...
Las relaciones se analizan de acuerdo a la situación.
El campo nombre es un campo que si es relativo. Una persona se puede llamar stephanie o stefany y se debe respetar dicha acción. No tiene sentido tener una tabla para almacenar todos los posibles nombres que existan.

Solo es necesario tener 2 tablas. El campo nombre va dentro de la tabla usuarios.

saludos

mdromed · #10 (**permalink**) 16/09/2009, 13:39

Cita:

Iniciado por huesos52

No mdromed...
Las relaciones se analizan de acuerdo a la situación.
El campo nombre es un campo que si es relativo. Una persona se puede llamar stephanie o stefany y se debe respetar dicha acción. No tiene sentido tener una tabla para almacenar todos los posibles nombres que existan.

Solo es necesario tener 2 tablas. El campo nombre va dentro de la tabla usuarios.

saludos

O sea que solo se usa otra tabla con los valores "normalizados" para evitar que se pueda dar el caso de insertar el mismo valor en la tabla pero escrito de maneras diferentes y por lo tanto podrian crear duplicidad no?

gnzsoloyo · #11 (**permalink**) 17/09/2009, 15:14

Pidiendo perón por meter bocadillo...

En el caso de tu ejemplo, la separación el nombre de la persona de su(s) apellido(s) tiene una función práctica, pero no es una estructura por definición.
En realidad el atributo nombre tiene por dominio la denominación que la persona recibe, que es únca para todo caso en relación a la persona. Una misma persona no puede tener (al menos en nuestra civilización) dos nombres simultáneamente (los alias o pseudónimos no cuentan). No es parte de los atributos derivables a otra relación, porque no existe otro atributo de la misma persona que permita definir un determinante de esos atributos.
En todo caso, el nombre es, junto a otros atributos, una clave candidata, y por tanto es parte de los determinantes de la persona.
La normalización de las relaciones tiene límites, y esos límites están dados precisamente por el nivel de atomicidad que puede darse a la información sin perder consistencia ni volverse exageradamente compleja la estructura de relaciones.
Por darte un ejemplo, si se tratase de empresas, y consideramos un nombre imaginario: "Compañía Mexicana de Relojes Digitales", no podemos separar las cuatro palabras en tablas distintas, porque no son atributos compuestos. Es un sólo atributo.
Lo mismo pasa con las personas.
Entonces, ¿hasta dónde normalizar?. Depende del nivel de complejidad de la relación a normalizar. Habitualmente un 3FN es suficiente, y en otras ocasiones es buena idea una 4FN, o una FNBC.

AitorLopez · #12 (**permalink**) 17/09/2009, 15:23

Hola.

Por si os sirve de algo, mi experiencia dice que se debe normalizar depende del tamaño de la bd. Me explico. Si es una bd con pocas tablas (3, 4, 5) con normalizar hasta la 3FN es mucho mas que suficiente, aunque haya campos del tipo telefono, provincias, etc.

Si la bd es de un tamaño considerable (30, 35, 40 tablas) es mejor y casi obligatorio formalizar como mínimo hasta la 3FN, y sobre todo separar todos los campos posibles en tablas. Por lo que si yo tengo una sola tabla proveedor con los campos nombre, direccion, telefono. De aqui me saldrían cuatro tablas. Porque?, porque despues puede haber clientes con direcciones, telefonos, etc. Puede haber trabajadores con direcciones, telefonos, etc. Puede haber contactos con direcciones, telefonos, etc.

Bueno, en cualquier caso, a lo que iba, depende mucho del trabajo que se vaya a realizar, para saber como realizarlo.

Un saludo.

zurd0 · #13 (**permalink**) 17/09/2009, 15:36

ayudaaa ya que tocan el tema d 1:1 1:N quien me puede ayudar estoy realizando un sistema para asignar horario a alumnos prof. en secciones y carreras segurito tengo las tablas carrera,seccion,prof,alumno no se si crear la tabla hora y dias o trabajar eso con la prog. debido aque de todo ese mollejero tiene q poderse asignar horario tanto a prof. cmo alumnos la secciones tiene que cerrarse a deteminado num d alumnos inscrito a ella ejem. seccion con 40 a lo que 40 alumnos inscriban esa seccion se debe cerrar tambien tambien una seccion con mayor numero de alumno que lo disponible en un aula ejem seccion:40 alumnos inscrito aula q soporte 30 esa aula no puede ser asignada en fin lo que quiero preguntar.... pa no escribir tanta paja como cuantas tablas necesitaria ya que no soy muy bueno diseñando bases logicament claro ayuda!!!!! si quiere un link a una imag. lo que he hecho escribanm:P

AitorLopez · #14 (**permalink**) 17/09/2009, 15:40

Hola.

A que llamas "estoy realizando un sistema para asignar horarios a alumnos prof. en secciones y carreras" etc, etc, etc.

Nos lo puede explicar, por favor.

Un saludo.

mdromed · #15 (**permalink**) 18/09/2009, 10:01

Cita:

Iniciado por gnzsoloyo

Pidiendo perón por meter bocadillo...

En el caso de tu ejemplo, la separación el nombre de la persona de su(s) apellido(s) tiene una función práctica, pero no es una estructura por definición.
En realidad el atributo nombre tiene por dominio la denominación que la persona recibe, que es únca para todo caso en relación a la persona. Una misma persona no puede tener (al menos en nuestra civilización) dos nombres simultáneamente (los alias o pseudónimos no cuentan). No es parte de los atributos derivables a otra relación, porque no existe otro atributo de la misma persona que permita definir un determinante de esos atributos.
En todo caso, el nombre es, junto a otros atributos, una clave candidata, y por tanto es parte de los determinantes de la persona.
La normalización de las relaciones tiene límites, y esos límites están dados precisamente por el nivel de atomicidad que puede darse a la información sin perder consistencia ni volverse exageradamente compleja la estructura de relaciones.
Por darte un ejemplo, si se tratase de empresas, y consideramos un nombre imaginario: "Compañía Mexicana de Relojes Digitales", no podemos separar las cuatro palabras en tablas distintas, porque no son atributos compuestos. Es un sólo atributo.
Lo mismo pasa con las personas.
Entonces, ¿hasta dónde normalizar?. Depende del nivel de complejidad de la relación a normalizar. Habitualmente un 3FN es suficiente, y en otras ocasiones es buena idea una 4FN, o una FNBC.

Muchas gracias por la explicacion.
Se nota que tienes mucha experiencia en BBDD.

explicative · #16 (**permalink**) 06/10/2009, 09:31

La segunda forma es la apropiada...

karmish · #17 (**permalink**) 09/10/2009, 13:34

Hola
Como todo dicen depende como quieras trabajar la BD, por otro lado tu tienes rason, tambien puede existir una tabla con un ID y en nombre de la personas, pero como hay mas de 1.000.000.000.000 nombres tendrias que colocar todo esos en la tabla, por lo cual se omite esa tabla y simplemente se considare el nombre como un campo de texto, asi tambien es mas facial modificar el nombre del usuariao por si te equivocaste en escribirlo o tiene alguna diferencia con los demas .