Entidad que pertenece a varias categorias (o entidades)

[gabiango]

Muy buenas señores, estoy diseñando por primera vez una bases de datos y estoy elaborando el diagrama ER. Me encuentro con el siguiente problema:

Tengo una entidad principal (que en el mundo fisico es un objeto) que puedes encontrar en varios sitios. Lo puedes enconontrar en la playa, en la ciudad, en la montaña, etc... Cada uno de esos sitios lo necesito interpretar como entidades separadas ya que cada uno tiene sus propios atributos.

¿Como puedo relacionar mi entidad principal (el objeto) con los distintos sitios donde encontrarlo? ¿He de crear una entidad auxiliar (por ejemplo sitio_donde_encontrarlo) que haga de puente entre las dos?

Muchas gracias

[huesos52]

Si te entiendo bien, tienes un objeto que puede estar en muchos lugares, y un lugar que purde tener muchos objetos. Esto sería una relación n-m.

Si es así, tienes razón, es necesaria otra tabla para relacionarlas. (Aunque no la llamaría auxiliar).

Un saludo.

[gabiango]

Muchas gracias por la respuesta. Pero agradeceria un monton un ejemplo de como seria esa tabla. Expongo la forma de mis entidades con sus atributos:

Entidad principal ==> Objeto

OBJETO
======
id_objeto (Primary key)
nombre
id_sitio_donde_enecontrarlo

Entidades de sitio ==> Playa, montaña y ciudad

PLAYA
=====
id_playa (PK)
nombre
tipo_de_playa

MONTAÑA
=======
id_montaña (PK)
nombre
hectareas

CIUDAD
======
id_ciudad (PK)
nombre
numero_de_barrios

En este momento tengo una entidad (OBJETO) que debe relacionarse con las otras entidades (PLAYA, MONTAÑA y CIUDAD). De alguna manera el atributo id_sitio_donde_encontrarlo debe servirme para hacer la relacion.

Gracias

[gnzsoloyo]

Creo que según el modelo E-R es evidente: Cada una de esas entidades es una entidad débil, cuya existencia depende de la entidad fuerte. En ese contexto, una entidad débil contiene la PK de la entidad fuerte.
De todos modos, el modelo que estás planteando no se ajusta a una definición simplemente de entidades fuertes y débiles: El modelo que tienes delante es una generalización (jerarquía) donde las débiles heredan atributos de la entidad primaria, con algunos atribuutos que le son propios.
En tu ejemplo, la entidad madre es OBJETO, que contiene la clave (PK) y el nombre. El resto contienen la misma PK y sus propios atributos
No tienes que perder de vista que esto es el diseño lógico (DER) y no el físico (Tablas), por lo que aún resta el paso entre los dos.

[gabiango]

El problema es que no se me ocurre la manera de conectar las dos tablas sin usar a través de condiciones. La verdad es que me gustaría relacionarlas simplemente a nivel de bases de datos.

Por ejemplo, En el momento que se haga una búsqueda de un OBJETO, ¿como lo puedo montar para que me diga a cual de las entidades (PLAYA, MONTAÑA o CIUDAD) pertenece?

Lo que está claro es que PLAYA, MONTAÑA y CIUDAD han de ser entidades independientes porque cada una tiene sus propios atributos (aunque tengan atributos en comun...)

[javi_cassi]

Hola gaviano, lo mejor, pienso yo, es que te crees 3 tablas:

OBJETOS: en esta estan todos los objetos, su descripcion, etc etc etc. PRIMARY-KEY: id_objeto
LUGARES: en esta están los sitios, Es decir, Montaña, playa, ciudad... con todos su atributos. PRIMARY-KEY: id_lugar
OBJETOS_LUGARES: aqui relacionass los objetos con los lugares en los que estan.PRIMARY-KEY: id_objeto, id_lugar (en esta tabla no necesitas mass campos)


Y ya esta. A partir de aqui ya puedes buscar todos los objetos de un determiandos sitio. Para ello usaras siemrpe las tabla OBJETOS_LUGARES. Si luego quires sacar las descripciones de los mismos, pues basta con que unas esta tabla con la de objetos por un lado (por el id_objeto) y con la de LUGARES por otro.


Aclarado???


saludos

[gnzsoloyo]

El problema es que no se me ocurre la manera de conectar las dos tablas sin usar a través de condiciones.

No te confundas. Cuando hablas de entidades, estás hablando del modelo lógico, es el análisis del sistema; las tablas todavía no existen ni en los sueños. Estás en una etapa diferente.

Lo que está claro es que PLAYA, MONTAÑA y CIUDAD han de ser entidades independientes porque cada una tiene sus propios atributos (aunque tengan atributos en comun...)

No es así. Si tienen atributos en común que son fundamentales para la identidad, entonces estás ante una jerarquía y no ante objetos de diferentes clases (UML...). Las diferencias entonces son atributos propios, pero los heredados provienen en ese caso de una superclase... con lo que ya no estás hablando de otra cosa que de jerarquías.
El tema es que (como te propone javi_assi), el esquema del DER logico, al transformarse a táblas puede hacer que incluso las entidades se fusionen (no es el caso), pero también que aparezcan tablas nuevas, ya que las relaciones de tipo N:N se transforma siempre en tablas... lo que no se manifiesta en el diseño en el nivel que estás planteando.
Este aspecto de las transformaciones es un poco críptico para los analistas y los programadores, porque la visión de los los arquitectos de datos es mucho más abarcativa y mas sintética que la de los arquitectos de aplicaciones y la de los analistas... No es que sean erradas, es que desde el punto de vista de los datos, los DBA miramos las cosas de otro ángulo. Por esa razón es que en UML el diagrama de clases, el de dominio y el de datos son distintos...

[gabiango]

Hola Javi!

Iniciado por javi_cassi

Hola gaviano, lo mejor, pienso yo, es que te crees 3 tablas:

OBJETOS: en esta estan todos los objetos, su descripcion, etc etc etc. PRIMARY-KEY: id_objeto
LUGARES: en esta están los sitios, Es decir, Montaña, playa, ciudad... con todos su atributos. PRIMARY-KEY: id_lugar
OBJETOS_LUGARES: aqui relacionass los objetos con los lugares en los que estan.PRIMARY-KEY: id_objeto, id_lugar (en esta tabla no necesitas mass campos)

La question es que a mi entender no puedo crear una sola entidad LUGARES ya que cada lugar tiene sus propios atributos. no?

[gnzsoloyo]

No se puede con una sola. El tema es no confundir que uno posea un tipo de dato (INTEGER, CHAR, VARCHAR, etc.), a que el dominio del atributo sea el mismo. Tener un campo numérico no habilita para guardar en el diferentes cosas, y agregarle uno más que sólo se necesita en ciertos casos es deshacer el concepto de normalización.
El dominio de un atributo es el campo de existencia del dato; si yo en un dato voy a guardar el tipo de playa (caracteres), no puedo el nombre de la montaña (caracteres), por más que entre. Las búsquedas de las consultas darán información inconsistente, errónea. Por ello se debe respetar el dominio de un atributo,,,

Para mantener el esquema de un diseño de una jerarquía tienes una tabla madre que es LUGARES(lugar_id, lugarnombe, ...), luego de eso aparecen los componentes de la jerarquía: MONTAÑA(lugar_id, montañanombre), PLAYA(lugar_id, tipo_playa), CIUDAD(lugar_id, barrios_cantidad).
Destaco lo siguiente: las tablas dependientes no tienen clave primaria propia, usan la clave primaria de la tabla madre.

[gabiango]

Iniciado por gnzsoloyo

Para mantener el esquema de un diseño de una jerarquía tienes una tabla madre que es LUGARES(lugar_id, lugarnombe, ...), luego de eso aparecen los componentes de la jerarquía: MONTAÑA(lugar_id, montañanombre), PLAYA(lugar_id, tipo_playa), CIUDAD(lugar_id, barrios_cantidad).
Destaco lo siguiente: las tablas dependientes no tienen clave primaria propia, usan la clave primaria de la tabla madre.

De acuerdo, entonces tendremos la tabla madre LUGARES y las tablas dependientes PLAYA, MONTAÑA y CIUDAD. Ahora la cuestion es: para realizar consultas de donde se encuentra un objeto determinado, necesitare buscar tanto en PLAYA, como MONTAÑA y CIUDAD. Por otro lado, cuando quiera escribir en las tablas ( si el objeto introducido pertenece a playa por ejemplo, ¿cual seria la consulta?

Como puedo escribir estas dos consultas a nivel de BBDD sin usar php???

[gnzsoloyo]

En el primer caso, no te olvides que la cantidad posible de tablas conteniendo tipos de sitio, es siempre limitada. Esto significa que no importa cuanta imaginación uses, los tipos de paisaje geográfico son limitados y aparecen en el diccionario o en los manuales de geografía o turismo. Solo requiere hacer una tabla por cada tipo (¿cuántos puedes tener? ¿5 básicos?, ¿10? ).
Se puede pensar, incluso en un modelo donde los tipos son parte del contenido de otra tabla, pero eso tal vez implique cambios en el modelo expuesto.
Además, no te olvides que ese tipo de consultas esquematizadas te conviene siempre resolverlas por VIEWs, y no armando las consultas (como agregado, de esa forma también aumentas la seguridad de la base).
En cuanto a la inserción, la única regla es no olvidar que una inserción de un tipo e una de esas tablas, debe estar precedida siempre por la inserción en la tabla madre, o sino el dato no podrá ingresa (restricción de clave foránea).

[gabiango]

Iniciado por gnzsoloyo

En el primer caso, no te olvides que la cantidad posible de tablas conteniendo tipos de sitio, es siempre limitada. Esto significa que no importa cuanta imaginación uses, los tipos de paisaje geográfico son limitados y aparecen en el diccionario o en los manuales de geografía o turismo. Solo requiere hacer una tabla por cada tipo (¿cuántos puedes tener? ¿5 básicos?, ¿10? ).

En efecto! la cantidad de sitios esta totalmente definida

Además, no te olvides que ese tipo de consultas esquematizadas te conviene siempre resolverlas por VIEWs, y no armando las consultas (como agregado, de esa forma también aumentas la seguridad de la base).

Ok, no conozco esto de las views pero lo miraré

En cuanto a la inserción, la única regla es no olvidar que una inserción de un tipo e una de esas tablas, debe estar precedida siempre por la inserción en la tabla madre, o sino el dato no podrá ingresa (restricción de clave foránea).

mmm...

Conclusion: tendremos la tabla madre y las tablas dependientes. Las consultas que realice las haré usando las VIEWS y respecto a la insercion de elementos no me ha quedado del todo claro... podrias ejemplificarmelo?

Muchisimas gracias por toda tu ayuda!

[gnzsoloyo]

La existencia de una resricción de clave foránea significa que para ingresar un registro en una tabla donde hay un campo que es FK referida a otra tabla, antes de ingresarlo, el valor que se pretende poner en ese campo debe forzosamente existir como clave primaria en su tabla de origen.
Sea el caso de una tabla que en este caso es MONTAÑA(lugar_id, montañanombre). Sabemos que montaña tiene un ID de LUGAR y una denominación propia de la montaña. Voy a imaginar el cerro llamado Uritorco, que se encuentra en la ciudad de Capilla del Monte, Córdoba, Argentina. Si quiero ingresar los valoers 1 (lugar_id) y nombremontaña (Uritorco), previo a eso debo llenar el registro de LUGAR(lugar_id, lugarnombe, provincia_estado, pais) con los valores 1 (lugar_id), Capilla del Monte (lugarnombre) , Córdoba (provincia_estado) y Argentina (pais).
Esto es así porque lo primero que hará al intentar ingresar el registro de la montaña es verificar si el ID que le estoy poniendo existe o no en la tabla madre. Si no existe no medejará ingresarlo...
¿Se compende la idea?
En este sentido, el sistema de tablas referenciales tiene el inconveniente de requerir el ingreso de datos en secuencias fijas, producto de las restricciones. Eso hace que sea relativamente más "lento" en las altas de datos, pero eso se compensa con los enormes beneficios a la hora de las consultas y de la consistencia de la información, aunque ello implique hacer dos INSERTS distintos para un sólo dato.

[gabiango]

Ok!

el problema es que me interesa que la clave primaria de la tabla madre sea autoincremental, por lo que a la hora de insertar valores en dicha tabla, dejaré ese atributo null para que automaticamente se incremente: el comando sql seria el siguiente

INSERT INTO montaña (id_lugar, nombre) VALUES ('NULL', "Uritorco");

A continuacion tenemos que rellenar la tabla Objeto, rellenando el campo id_lugar con el mismo valor que le ha asignado en la tabla montaña

INSERT INTO objeto (id_objeto, nombre_objeto, id_lugar) VALUES ('NULL', "tenedor", mismo_valor_que_en_la_tabla_montaña);

¿Como podría hacer esto?

Por cierto, todo esto lo integro dentro de php, así que supongo que la cosa va por guardar ese atributo como una variable, pero... ¿como?

Gracias!!!!!!!!!

[gabiango]

YA ESTÁ!!!

Al fin he encontrado la manera de hacerlo:

Enunciado: Tengo una tabla madre y una serie de tablas dependientes de esa tabla. La tabla madre es objeto y las otras tablas son los lugares donde se puede encontrar dicho objeto (montaña, ciudad y playa). Lo que se pretende hacer es unir las dos tablas para hacer inserción de datos.

Solución: Las tablas dependientes disponen cada una de ellas el atributo id_sitio que es PK y autoincremental. La tabla madre dispone de el atributo id_sitio como FK y de otro atributo tipo_sitio que será un VARCHAR que apuntará al nombre de las tablas dependientes (valdrá montaña, ciudad o playa).

Pues bien, usando php podemos hacer el insert en las tablas de la siguiente manera (ejemplo de objeto que pertenece a montaña):

1 - rellenamos la tabla montaña con todos sus atributos con la consulta INSERT
2 - utilizamos la consulta LAST_INSERT_ID() para recuperar el último id autoincremental que se ha metido ( es decir, el último id_sitio de la tabla montaña). Guardamos dicho valor en una variable
3 - Ahora debemos hacer el insert en la tabla Objeto mediante otro INSERT y en el momento de poner el valro al atriibuto id_sitio usaremos la variable anterior

Voilà!!! Ya hemos hecho una inserción de datos en tablas relacionadas.

Saludos!!!

[gnzsoloyo]

Bueno. Me alegra que hayas comprendido finalmente cómo es el esquema de ingresos en tablas relacionales, y que lo hayas adaptado a tu modelo de datos.
En esencia es lo mismo que yo decía, con la salvedad de que mi visión del modelo del sistema es distinta, porque desde mi óptica es el sitio geográfico el que contiene las montañas, y no al revés... pero eso es una cuestión de análisis de sistemas y no de bases de datos (los DBA debemos implementar lo que los analistas inventan, por más que en ocasiones nos parezcan poco razonables).
Una de las cosas que me enseñaron al cursar precisamente Análisis de Sistemas I, fue que un modelo relacional podía estar bien para un analista y mal para otro, simplemente porque el ángulo de visión era diferente entre ambos. Lo importante no era eso, sino que el esquema fuese coherente en sí mismo y respetase las dependencias y estructuras relacionales.

Para el caso, el esquema es siempre así: Si una ID es autoincremental en una tabla primaria, ésta siempre se debe llenar antes y recuperar el ID creado para ingresarlo en la tabla secundaria.
Ocasionalmente, todo esto se puede preparar en un Stored Procedure, con lo que lo resuelves internamente y simplemente le mandas al SP los parámetros con los que trabajará.

Suerte.
Sigue adelante.