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.

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....

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.

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.