Duda sobre relacionamiento entidad fuerte débil.

[karateonline]

Estoy estudiando normalización que la verdad no se me da muy bien y surge de ahí la siguiente duda:
¿Cómo tratar a las tablas que son sub-tipo de una entidad fuerte?
Tratare de ilustrarlo con un ejemplo…
Supongamos que tengo una tabla personas

# Id_persona
Nombre
Apellido
Documento
Fecha_nacimiento
Dirección

Ahora, de las personas también me interesa saber por ejemplo su teléfono, que bien podría extenderse a un correo electrónico o una url personal… en fin hay varias cosas que podrían ser…
El asunto es que una persona puede tener más de un teléfono que de hecho es lo que sucede en la realidad práctica. Así que hago una tabla teléfonos y nacen mis dudas.
A) ¿Esta tabla teléfonos es la tabla teléfonos que alojara todos los teléfonos de la base de datos?
A.1) ¿En caso esta tabla teléfonos ser especifica, es decir teléfonos_ por_ personas, lleva clave primaria? A.2) ¿O al ser un atributo heredados de otra entidad ya hereda el atributo clave y no necesita una clave?

B) ¿Alguien me puede mostrar un ejemplo en SQL de cómo escribir la consulta para ver estos teléfonos unidos a los datos de la persona?

Bueno agradezco a quien me pueda ayudar a resolver esta duda que me tiene atrapado.

[PosProdukcion]

Iniciado por karateonline

A) ¿Esta tabla teléfonos es la tabla teléfonos que alojara todos los teléfonos de la base de datos?

Sí, a no ser que tú quieras crear otra para otro tipo de teléfonos.

Iniciado por karateonline

A.1) ¿En caso esta tabla teléfonos ser especifica, es decir teléfonos_ por_ personas, lleva clave primaria? A.2) ¿O al ser un atributo heredados de otra entidad ya hereda el atributo clave y no necesita una clave?

Sí, debería llevar clave primaria, ya que al poder tener una persona varios teléfonos, el valor de FK_PERSONA se puede repetir para varios teléfonos, por tanto debes crear una clave ID_TELEFONO

Iniciado por karateonline

B) ¿Alguien me puede mostrar un ejemplo en SQL de cómo escribir la consulta para ver estos teléfonos unidos a los datos de la persona?

Por ejemplo,

Código MySQL:

Select P.nombre, P.apellido, P.Documento, T.numero
From Personas P
Left Join Telefonos T on T.FK_PERSONA = P.ID_PERSONA
 

Usar Left Join en lugar de Join te asegura que si una persona no tiene ningún teléfono también saldrá en esta query, si solo usas Join solo saldrán las personas con algún número de teléfono.

De todas formas, en el caso concreto de teléfonos o email suele ser más sencillo (a mi parecer) tener tres o cinco columnas de la tabla personas (telefono1, telefono2, telefono3, etc.), en otros casos más complejos si se justifica tener una tabla de detalle.

[alphaville99]

Distinguido PosProdukcion:

Recien Lei tu respuesta acerca de la pregunta "Duda sobre relacionamiento entidad fuerte débil."

en la cita:

Cita:

--------------------------------------------------------------------------------

Iniciado por karateonline (Mensaje 3635025)
A.1) ¿En caso esta tabla teléfonos ser especifica, es decir teléfonos_ por_ personas, lleva clave primaria? A.2) ¿O al ser un atributo heredados de otra entidad ya hereda el atributo clave y no necesita una clave?

--------------------------------------------------------------------------------


Sí, debería llevar clave primaria, ya que al poder tener una persona varios teléfonos, el valor de FK_PERSONA se puede repetir para varios teléfonos, por tanto debes crear una clave ID_TELEFONO

---------------------------------------------------------------------------------


En este caso, a mi parecer no seria util tener un ID_TELEFONO, ya que suficiente con tener el FK_PERSONA se puede saber que telefonos tiene la persona. Aunque se estaria rompiendo una regla de la normalizacion, que indica que toda TUPLA de una tabla debe tener un ID que lo identifique unicamente.


Es decir, dando otro Ejemplo:

tenemos la tabla "Empleado", con los campos:
ID_emp (key)
des_emp
cargo_emp
sueldo_emp

entonces la tabla dependiente "Hijos_a" a mi parecer seria:

ID_emp (FK)
nom_hijo
edad_hijo
obs_hijo
(OBS: esta tabla no tiene key)


o como tu dices: "Hijos_b"

ID_emp (FK)
ID_hijo
nom_hijo
edad_hijo
obs_hijo

con key(ID_emp,ID_hijo) //como se recomienda.


Mi duda es... Por qué esta tabla DEPENDIENTE debe tener un KEY, por que a mi parecer no veo util su inclusión, o en que casos por ejemplo, seria util tener el campo ID_hijo.