Duda relaciones de entidades

sionoo · 17 Mayo 2010, 05:55 AM

Buenas noches.

Ya estoy un poco desesperado, baje el MySQL Workbrench para generar el EER (tablas) bueno pues cargo la base de datos y al momento de mostrar las relaciones las dos tablas no estan relacionadas.

La tabla1 tiene un PK (id_estado), pero la tabla2 no tiene PK solo un INDEX formado por (id_estado,id_departamento).

tabla1 estado:
id_estado (PK)
nombre
ubicacion
etc

tabla2 departamento:
id_departamento (PK)
id_estado
direccion
etc

al momento de ponerle una relacion manual me dice que la tabla departamento no tien un PK y que no las puede relacionar entonces utiliza la relacion NON Identifying Relationship (1:N) solo haci me deja hacer una relacion de las talbas pero me crea un nuevo indice en la tabla departamento.

La verdad ya estoy un poco desesperado por que no acabo de entender esta parte de las relaciones, las relaciones de los datos de mis tablas (MyISAM) las pensaba hacer con codigo (where o joins) pero cuando quice hacer el DER o MER me confundi y no se que hacer, espero me puedan ayudar gracias.

-------------Agrego

A esa base de datos solo se le haran consultas, habra inserciones o actualizaciones (pero seran por parte mia y no seran seguido), no importa la integridad referencial.

^Tifa^ · 17 Mayo 2010, 06:06 AM

Mira, yo no he utilizado nunca Workbench por lo cual no podria detallarte sobre estrellitas o marquitas que el te especifique, no manejo esta parte de esa aplicacion.

Tu pregunta siguiente, necesita una exposicion mas precisa para que comprendas.

Imaginate un residencial lleno de apartamentos, todos los apartamentos son identicos fisicamente (el mismo tamanio, color, pisos, etc). Ahora imaginate que todos esos apartamentos son tablas en MySQL, todos estan separados aunque visualmente sean identicos, que ocurre que en el apartamento 1 vive la familia Perez, en el apartamento 2 vive la familia Rodriguez, y asi sucesivamente, cada apartamento alberga una familia diferente. Imaginate que las familias son registros dentro de las tablas, ahora que ocurre todos los apartamentos al ser identicos tu necesitas saber cual es el apartamento de la familia Perez, para averiguar esto que necesitas? un identificador o numero o algo enfrente del apartamento que te especifique que ahi vive la familia 'Perez', imaginemos que ese identificador es un letrerito con la letra P gracias a este identificador (que en una tabla seria un PK o indice) ya sabes de todos esos apartamentos identicos cual es el de la familia Perez... pero ocurre algo, tu tienes que saber cual es el parqueo de la familia Perez, ya que los parqueos (mas tablas) estan frente a los apartamentos, pero los parqueos tambien son fisicamente identicos, que necesitas tu para saber cual es el parqueo de la familia Perez??? otro identificador o letrerito en el parqueo que tambien tenga la letra P pero si los parqueos tuvieran solamente un letrero ... y todos esos letreros estuvieran borrosos o vacios ... como sabes cual es el de la familia Perez???

(cuando te digo letreros vacios, imaginate que te hablo de campos en una tabla a los cuales no le has definido un PK o indice). Eso es lo que esta ocurriendo aca contigo, en la tabla2 definiste los campos (parqueos) pero no le escribiste al letrerito a que familia pertenecia (indices o PK) solamente colgaste el letrerito vacio. Entonces porque razon el apartamento que tiene el identificador P tiene que adivinar o saber cual de todos los parqueos con letreritos vacios le corresponde a la familia Perez?

Explicame

^Tifa^ · 17 Mayo 2010, 06:23 AM

CitarA esa base de datos solo se le haran consultas, habra inserciones o actualizaciones (pero seran por parte mia y no seran seguido), no importa la integridad referencial.

Enserio piensas eso???

volvemos a los apartamentos, las familias y los parqueos, entonces si la familia PEREZ se muda del residencial, no importa que manana se mude una familia nueva apellidada Ruiz, pueden perfectamente cambiarle al apartamento o al parqueo (pero no a los dos) el letrerito y colocar R en vez del antiguo P y me diras algo como, si si pero todos saben que la familia Perez ya se fueron asi que aunque el parqueo diga P la familia Ruiz puede parquearse alli... y llega un empleado nuevo a tu residencial, y lo mandan a limpiar el area de los parqueos de las familias que viven actualmente en los apartamentos, asi que ese empleaducho va y comienza a limpiar todos los parqueos de los apellidos que el conoce.. y de pronto se encuentra el apellido P y dira quienes rayos son 'P' no se quienes son, asi que estos no me daran nada de propina, y obvia limpiar ese parqueo porque el no sabe quien rayos es la familia P nadie se lo informo ni se lo dijo....

Ya me diras tu, cuando actualizes informacion de una tabla1 puedes perder completamente la relacion con la otra informacion de la tabla2. Siempre y cuando actualizes por el campo que los relaciona (o sea id_estado en este caso), si id_estado = 1 en la tabla1 lo actualizas a id_estado = 3 y la tabla2 no le haces nada, cuando consultes con WHERE y JOIN por el id_estado = 1 que te va a devolver? piensalo

si la tabla1 ya no tiene mas id_estado = 1 pero la tabla2 si....

sionoo · 17 Mayo 2010, 06:35 AM

ok a lo de

Citar...no importa la integridad referencial.

me refieria a que los cambios de la tabla 1 (id_estado) lo hiba a reflejar en la tabla2 con triggers.

Bueno ya te mande un MP, espero me entiendas ya te explique lo que me pedias.

^Tifa^ · 17 Mayo 2010, 06:46 AM

Ya entiendo lo que tu dices, (se suele usar mucho lo que propones, en formularios webs donde 1 usuario puede tener varias preferencias de varias cosas a la vez 'viajes, tecnologia, lectura, etc..') efectivamente se crean 2 INDEX en una tabla, pero recuerda que id_estado aunque puedas incluirle varias opciones, debe el valor de id_estado siempre pertenecer al registro al cual haces referencia en la tabla1)

Por ejemplo si tabla1 tuviese:

ID Nombre Apellidos
1 Juan Sanchez
2 Maria Perez

Y la tabla2 tuviese:

ID CODIGO
1 1
1 2
2 1

Y una tabla3 que detalle el campo CODIGO a que gusto personal se refiere:

CODIGO DETALLE
1 Futbol
2 Viajes
3 Tecnologia
4 Moda

Asi, con el ejemplo anterior el usuario 'Maria' que le corresponde el ID = 2 en la tabla2 dice que 'Maria' solamente tiene una preferencia y es el 'Futbol', pero 'Juan' con ID = 1 en la tabla1 dice la tabla2 que a 'Juan' le gusta el Futbol y los Viajes.

Aunque claro puedes obviar la tabla auxiliar (la 3ra tabla) pero por normalizacion, por estetica y por organizacion hay personas que lo estructuran como esta con 3 tablas. En caso que decidieras obviar la tercera tabla, tienes que colocar DETALLE dentro de la segunda tabla y con su respectivo CODIGO en cada categoria.

No puedo decirte como implementar un diagrama entidad-relacion con 2 tablas (que aunque es posible con 2 tablas realizar lo que te explique anteriormente dentro del motor de BD, para un diagrama se complicaria para exponerlo al menos) ahora con las 3 tablas, fuera mas entendible de exponer el diagrama entidad-relacion.

Seria algo mas o menos...

tabla1 tabla2 tabla3
data1 -----------------> data1 -------------------> data1

Obvio sustituyendo data1 por los respectivos campos de cada tabla, pero yo creo que para mayor entendimiento visual, el diagrama deberia hacerse con las 3 tablas la auxiliar y las otras 2 porque si aplicas todo (categoria y indice) en 2 tablas (aunque es posible para la BD) como te decia, visualmente se vera engorroso y confuso en el diagrama al menos.... aunque es solo mi percepcion.

Otra cosa no se como Workbench maneje esto de las relaciones, y me puedo equivocar (No utilizo IDE para trabajar con BD) pero ten pendiente que quieres relacionar un PK con un doble INDEX, los PK no aceptan valores nulos ni repetidos (ademas que es 1 solo campo en el caso que lo haz definido), y el INDEX acepta repetidos, acepta nulos en este caso (no agregaste not null) y son 2 campos no 1 solo, asumo Workbench querra 2 campos PK tambien y querra que se cumplan las condiciones previamente mencionadas aunque no se si de manera obligatoria.

sionoo · 17 Mayo 2010, 07:01 AM

De hecho en la tabla1 tenia la PK y el la tabla2 un INDEX, al hacer la relacion en Workbrench creo un nuevo indice para poder relacionar la tablas (Aun que el indice que creo y el que tenia es el mismo).

Me puso una linea punteada y dice Non-Identifying Relationship y si no hay datos nulos en el indice aun que si repetidos.

tabla1 -||-------------|< tabla2 (1:N)

PK INDEX

^Tifa^ · 17 Mayo 2010, 07:23 AM

Como te decia chico no trabajo con Workbench

(nisiquiera lo conozco la verdad

) ni ningun IDE de esos para BD.

Pero, hay que ver si Workbench exhige o aplica algun estricto que exhiga que se cumplan los CONSTRAINTS, sabemos que PK no acepta Nulos ni valores repetidos, sin embargo INDEX si acepta valores repetidos y nulos, y acabo de verificar en MySQL, el indice INDEX aunque le coloques el atributo NOT NULL continua siendo un indice MUL (con MUL quiere decir que acepta valores repetidos, que aunque no acepte mas NULLS si acepta valores repetidos, entonces sabemos que PK no acepta valores repetidos sino unicos. Si el indice en cuestion fuese UNIQUE de forma natural es un indice de tipo MUL tambien (No porque acepte valores repetidos como tal, pero si acepta valores NULLS repetidos

) ahora si le colocamos el atributo NOT NULL, ese indice UNIQUE pasase de MUL a PRI (PK) porque ya ni acepta valores repetidos, ni acepta nulos.

Hay que ver si Workbench esta respetando todo lo anterior expuesto y estas condiciones forman parte de su funcionalidad.