Foro de elhacker.net

Hola estoy enterandome sobre el Modelo entidad relacion para crear BBDD y me gustaría hacer que un usuario (Tabla usuarios) envíe mensajes a otro usuario que tiene como amigo, ¿Como se haria,sería una relacion reflexiva entre tabla usuarios y luego la tabla usuarios se haria una relación con una tabla de mensajes? Estoy hecho un lio espero que me puedan ayudar  :-\

Aunque no entiendo del todo tu peticion. Lo que he entendido es, que tienes dos tablas una de Usuarios (Amigos) y otra donde llegaran los Mensajes:

 
mysql> DESCRIBE Mensajes;
+-------------+--------------+------+-----+---------+-------+
| FIELD       | TYPE         | NULL | KEY | DEFAULT | Extra |
+-------------+--------------+------+-----+---------+-------+
| id_mensajes | tinyint(4)   | YES  |     | NULL    |       |
| id_amigo    | tinyint(4)   | YES  | MUL | NULL    |       |
| mensaje     | VARCHAR(100) | YES  |     | NULL    |       |
+-------------+--------------+------+-----+---------+-------+
3 ROWS IN SET (0.00 sec)
 
 
mysql> DESCRIBE Usuarios;
+----------+------------+------+-----+---------+----------------+
| FIELD    | TYPE       | NULL | KEY | DEFAULT | Extra          |
+----------+------------+------+-----+---------+----------------+
| id_amigo | tinyint(4) | NO   | PRI | NULL    | AUTO_INCREMENT |
| amigo    | CHAR(20)   | YES  |     | NULL    |                |
+----------+------------+------+-----+---------+----------------+
2 ROWS IN SET (0.00 sec)
 
 

Lo anterior es solo un ejemplo, 1 usuario (1 amigo) puede enviarle 1 mensaje a un amigo, y 1 amigo puede tener varios mensajes. (En el ejemplo que voy a exponerte)

La tabla Usuarios tiene los siguientes registros:

 
mysql> SELECT * FROM Usuarios;
+----------+----------+
| id_amigo | amigo    |
+----------+----------+
|        1 | Fernando |
|        2 | Mario    |
|        3 | Maritza  |
|        4 | Juan     |
|        5 | Juana    |
+----------+----------+
5 ROWS IN SET (0.00 sec)
 
 

Y puedes se le envia por ejemplo algunos mensajes a Fernando y Maritza:

mysql> INSERT INTO Mensajes VALUES(1,1,'Hola Fernando solamente pasaba a saludarte'), (1,1,'Hola Fer!, como vas');
 
mysql> INSERT INTO Mensajes VALUES(3,3,'Maritza no te olvides de sacar la basura'), (3,3,'Hola Maritza nos vemos manana'), (3,3,'Maritz Llamame pronto!!..Carlos');
 

Ahora la tabla Mensajes tendria:

mysql> SELECT * FROM Mensajes;
+-------------+----------+--------------------------------------------+
| id_mensajes | id_amigo | mensaje                                    |
+-------------+----------+--------------------------------------------+
|           1 |        1 | Hola Fernando solamente pasaba a saludarte |
|           1 |        1 | Hola Fer!, como vas                        |
|           3 |        3 | Maritza no te olvides de sacar la basura   |
|           3 |        3 | Hola Maritza nos vemos manana              |
|           3 |        3 | Maritz Llamame pronto!!..Carlos            |
+-------------+----------+--------------------------------------------+
5 ROWS IN SET (0.00 sec)
 
 

Donde id_amigo corresponde al id_amigo de la tabla Usuarios. Ahora para que Fernando y Maritza lean sus mensajes:

mysql> SELECT Usuarios.amigo, Mensajes.mensaje FROM Usuarios NATURAL JOIN Mensajes;
+----------+--------------------------------------------+
| amigo    | mensaje                                    |
+----------+--------------------------------------------+
| Fernando | Hola Fernando solamente pasaba a saludarte |
| Fernando | Hola Fer!, como vas                        |
| Maritza  | Maritza no te olvides de sacar la basura   |
| Maritza  | Hola Maritza nos vemos manana              |
| Maritza  | Maritz Llamame pronto!!..Carlos            |
+----------+--------------------------------------------+
 
 

O para que solo Fernando vea sus mensajes:

mysql> SELECT Usuarios.amigo, Mensajes.mensaje FROM Usuarios INNER JOIN Mensajes WHERE Usuarios.id_amigo = 1 AND Mensajes.id_amigo = Usuarios.id_amigo;
+----------+--------------------------------------------+
| amigo    | mensaje                                    |
+----------+--------------------------------------------+
| Fernando | Hola Fernando solamente pasaba a saludarte |
| Fernando | Hola Fer!, como vas                        |
+----------+--------------------------------------------+
2 ROWS IN SET (0.00 sec)
 

Gracias por responder ;) aunque no entiendo bien la respuesta ya que todavía no sé mysql,lo aprenderé a partir de Enero,mas bien busco el Modelo Entidad-Relacion.
Lo que quiero hacer es que haya usuarios, y que cada uno de ellos puedan tener amigos (yo entiendo que esto seria una relación reflexiva en la tabla usuarios que sería relacion tipo NM porque un usuario puede tener varios usuarios o amigos y un usuario o amigo pueden tener varios usuarios).
Pero el problema viene a cuando quiero que entre los amigos se envien mensajes,y nosé bien donde poner una relación entre la tabla usuarios, la tabla amistades( ya que al ser tipo NM se generaría una tabla nueva a la que llamaria amistades) y la tabla mensajes..
¿Podríais ayudarme?Gracias

PD: Perdon por tardar tanto en responder pero no entendía lo que me habias puesto porque por el momento no sé mysql y al final sigo sin entenderlo bien

el n-n se resuelve asi:

usuario --< amistad >-- amigos

y suponiendo que solo se pueden enviar mensajes entre amigos:

amistad --< mensajes

Haber, un usuario puede tener varios amigos (una entidad puede relacionarse a varias entidades). Pero un amigo no puede tener varios usuarios  :-\  sino un solo usuario, cuando te registras en cualquier web se te asigna un usuario unico, no varios, lo que si se te permite es volver a registrar un usuario nuevo para tener mas de uno (Pero no tendria mucha logica ya que independientemente aunque yo tuviera 3 usuarios creados por ejemplo en este foro, cada uno seria independiente, unico y con sus caracteristicas individuales propias  :xD ). Entonces, seguiria mirando en tu caso la posibilidad de 3 tablas.

Usuarios
Mensajes
Amigos

Mi ejemplo expuesto (Aunque esta realizado en puro consultas SQL) podria servirte de base, lo que me parece que buscas es el 'Diagrama Entidad-Relacion' de eso que expuse mas arriba con consultas SQL.

Me temo que tengo una falla enorme con diagramar este tipo de situaciones y no soy muy amiga de los diagramas de flujo... pero mas o menos por ahi va el camino.

Usuario se relaciona a Mensajes y Amigos se relaciona a Mensajes.

Mensajes vendria siendo la tabla intermedio de relacion entre las dos (usuarios y amigos).

mensajes podria depender de una amistad, si no, seria la misma relación que define amistad pero no se puede tomar a mensajes como amistad

No me gustan los MER :¬¬

¿Así?

En el pasaje a tablas quedarían 3 tablas, Personas (clientes), Amistad (con los id y demás atributos determinantes de las Personas), y Mensajes :-\

Saludos

En estos problemas lo más importante es el enunciado, y aquí está muy poco claro, pero dado que yo entiendo los mensajes se envian entre amigos creo que sería:

-Entidad persona
-Amistad relación reflexiva simétrica de persona n-m
-Entidad Mensajes
Al añadir esta última se crearía una asociativa de mensajes con amistad 1-n

Siento no poder hacer el dibujito, pero se entiende.

Del modo anterior al pasar al modelo relacional quedaría:

Persona(dni, nombre, blablabla)
Amistad(dni,dni_amigo,donde_se_conocieron)
Mensajes(dni,dni_amigo,mensaje) donde dni,dni_amigo forana hacía Amistad

Sino se podría quitar la asociativa y que amistad fuera entidad, sería un esquema entidad/relación equivalente y el modelo relacional sería el mismo.

Saludos!

Si esta buscando el 'dibujito' que me parece que eso es lo que el inicialmente esta buscando el diagrama de entidad-relacion de su peticion.

El de Novlucker le podria servir de modelo  :-*

A mi tampoco me gustan para nada los diagramas.

Este es mi dibujito, sin dibujito:
Con esto ya es trivial dibujarlo.

Pero ya puestos:
(http://i.elhacker.net/i?i=SUx8jysB6pfXndglHQ96TGVo) (http://i.elhacker.net/d?i=SUx8jysB6pfXndglHQ96TGVo)

 :laugh:

La otra opción que comento sería substituyendo la asociativa por entidad normal.


Y el modelo relacional que ya había puesto:Que NO es lo mismo que la estructura de las tablas en sql como se suele confundir :P

Pues en realidad a mi me gustan bastante, es el modo más claro y cómodo para diseñar una base de datos

Saludos!

Ese dibujo es como el mio, ese dibujo es como el mío! ;-) .. bueno .. casi XD, la diferencia esta en que relacionas MENSAJES con AMISTAD, y yo lo había sacado de PERSONA, lo que si proponia eran esas tablas tal cual :P

Y si, no es que los MER no gusten, pero en parte es una de las cosas más complicadas a la hora de crear una BBDD, el analizar la realidad, identificar las entidades y sus relaciones, no por algo hay personas que estan especificamente pa' ESO :P

Saludos

Se que no es lo mismo, pero a mi particularmente me queda mas sencillo y facil hacer el estructurado de las tablas sin nisiquiera pasar por el diagrama entidad relacion inicial... (Y reconozco que el diagrama es muchisimo mas simple de realizar que la otra manera).

Nunca he sido partidaria de los diagramas ni de base de datos, ni en programacion (diagrama de flujo) aveces me colocaban tarea en vivo en un aula en programacion en algun lenguaje y me decian hazlo ahora mismo... y ufff tiraba el codigo en unos pocos minutos y funcionaba y todo al compilarse, pero cuando el profesor me decia ok, y el diagrama de flujo de eso que acabas de hacer donde esta si eso debio ser lo primero que debiste hacer? y me quedo como plop  :-\  ahhhh no se. Y me han dicho hazme el diagrama ahora, y lol me pasan 2 horas y me vez con una hoja vacia pensando por donde comenzar a dibujar el dichoso diagrama  :xD

Sera cuestion de adaptacion, yo me lio con diagramas pero si me piden estructurado me manejo mas rapido. Pero a la larga creo no estoy segura, pero creo que si, que lo que el usuario que inicio el post buscaba era el diagrama no el estructurado de las tablas.

:laugh: :laugh: Lo dejamos en un empate hasta que se demuestre lo contrario xD, porque con el enunciado ese vete a saber :laugh: :laugh:
Esque claro si fallas en el diagrama ya el error va a ser de diseño y siempre es más complicado de corregir

Yo también era de empezar a picar código cuanto antes mejor pero en mi último trabajo me lo exigian y creo que cuando le pillas la costumbre merece la pena por lo claro que te queda el concepto de un solo vistazo, además si te piden una mejora en un futuro ves más claro el impacto que tendrá en la aplicación y ya por último los imprevistos que te ahorras porque ya tienes "todo planeado" antes de empezar a picar una sola tecla.
Aunque claro, todo es discutible y hay quien considera que es hacer el trabajo dos veces xDD

Saludos!

Bueno leyendo este hilo me ha surgido una duda:

Si queremos tener un portal tipo tuenti, es decir, que por cada usuario registrado pueda tener una lista de amigos (se van añadiendo sobre la marcha), como lo hariais con tablas?

gracias  :-*

Se que hay una mejor manera de estructurado  :xD y no culpo al que quiera jalarme las orejas por ello... pero esto es un mero ejemplo  ;)

 
mysql> SELECT * FROM relacion;
+------+--------+-----------+ 
| id   | codigo | nombre    | 
+------+--------+-----------+ 
|    1 |      2 | Winder    | 
|    1 |      3 | Napk      | 
|    2 |      4 | Randomize | 
|    3 |      1 | ^Tifa^    | 
|    6 |      1 | ^Tifa^    | 
|    6 |      2 | Winder    | 
|    6 |      3 | Napk      | 
+------+--------+-----------+ 
7 ROWS IN SET (0.00 sec)      
 
mysql> SELECT * FROM usuarios;
+------+------------+----------------------------------+
| id   | nombre     | contrasena                       |
+------+------------+----------------------------------+
|    1 | ^Tifa^     | 202cb962ac59075b964b07152d234b70 |
|    2 | Winder     | 81dc9bdb52d04dc20036dbd8313ed055 |
|    3 | Napk       | 81dc9bdb52d04dc20036dbd8313ed055 |
|    4 | Randomize  | 698d51a19d8a121ce581499d7b701668 |
|    5 | Festor     | 81dc9bdb52d04dc20036dbd8313ed055 |
|    6 | seba123neo | 81dc9bdb52d04dc20036dbd8313ed055 |
|    7 | Tux        | c20ad4d76fe97759aa27a0c99bff6710 |
+------+------------+----------------------------------+
7 ROWS IN SET (0.00 sec)                           
 
mysql> SELECT a.nombre AS usuario,b.nombre AS relacion FROM usuarios a INNER JOIN relacion b USING(id) WHERE b.id = 6;
+------------+----------+
| usuario    | relacion |
+------------+----------+
| seba123neo | ^Tifa^   |
| seba123neo | Winder   |
| seba123neo | Napk     |
+------------+----------+
3 ROWS IN SET (0.00 sec)
 
mysql> SELECT a.nombre AS usuario,b.nombre AS relacion FROM usuarios a INNER JOIN relacion b USING(id) WHERE b.id = 1;
+---------+----------+
| usuario | relacion |
+---------+----------+
| ^Tifa^  | Winder   |
| ^Tifa^  | Napk     |
+---------+----------+
2 ROWS IN SET (0.00 sec)
 
 

Exacto, en teoría así podría ser.

Tifa, está súper bien tus explicaciones, aunque por el motor que estáis usando no tienes las relaciones creadas, me imagino que es myisam. No tengo la total seguridad pero para este tipo de casos creo es mejor usar innodb, no?

Si estan las relaciones creadas  ;)  basadas en el modelo tradicional Entidad-Relacion. Recuerda que antes no existian motores de almacenamientos transaccionales (Me refiero cuando nacio Oracle alla por los inicios del ochenta) no existia una implementacion que manejase de forma automatica una relacion entre 2 o mas tablas, entonces utilizan este modelo que viste en mi ejemplo, y que mencionan con constancia otros usuarios que han respondido a este post, y el modelo continua hoy dia siendo bastante efectivo  :D y todavia se utiliza.

Cuando nacio InnoDB como motor de almacenamiento transaccional, este utiliza ese mismo modelo que has venido observando, la diferencia es... que este motor continue funcionalidades y mejoras internas que no posees si utilizas el modelo de relacion tradicional. Entre estas funcionalidades de InnoDB esta que no permite violacion de llaves foraneas, lockeo de filas en vez de toda la tabla, uso de indices clustered, entre otras cositas, que tu sabes que en el tipo de relacion tradicional no es aplicable entonces lo que se suele hacer es crear triggers para manejar este tipo de cosas que InnoDB internamente ya porta (el trigger es para evitar que se viole la llave foranea de la tabla padre) obviamente implica mas esfuerzo y mas cosas que realizar y que InnoDB implementa de forma automatica. Pero, por otro lado todo dependera de que te conviene por optimizacion sobretodo, y aun no me han dado Base de Datos en la Universidad pero estoy consciente que el modelo que exhigen es el modelo tradicional, no el moderno con InnoDB que hace todo por ti y el estudiante no se entera realmente porque eso funciona asi, como y debido a que.

es que el modelo tradicional que muestras en realidad es un modelo aplicado a la base de datos en un motor no transaccional, lo que vendría siendo un modelo físico y no coneptual, que sería la abstracción de tu ejemplo

Exactooooo mi querido tomás, es que tifa no tiene como tal las relaciones... hasta donde sé se crean en el schema, no?, aún así gracias por tu explicación.

SI existe relacion entre el ejemplo que coloque, fijate bien en el campo ID de ambas tablas y el resultado que este retorna en base a una consulta.

O lo desgloso para que sea mas entendible:

mysql> SELECT * FROM usuarios;
+------+------------+----------------------------------+
| id   | nombre     | contraseña                       |
+------+------------+----------------------------------+
|    1 | ^Tifa^     | 202cb962ac59075b964b07152d234b70 |
|    2 | Winder     | 81dc9bdb52d04dc20036dbd8313ed055 |
 

Tomare de ejemplo yo y Winder.

ID ^Tifa^ = 1
ID Winder = 2

Ahora fijate la tabla relacion, que usuarios son amigos de ^Tifa^? los siguientes:

mysql> SELECT a.nombre AS usuario,b.nombre AS relacion FROM usuarios a INNER JOIN relacion b USING(id) WHERE b.id = 1;
+---------+----------+
| usuario | relacion |
+---------+----------+
| ^Tifa^  | Winder   |
| ^Tifa^  | Napk     |
 
 

Segun la consulta dice que Winder y Napk ambos son amigos de ^Tifa^ ahora se confirma, en la tabla relacion correspondiente al ID = 1 que es ^Tifa^ que usuarios son amigos?

 
mysql> SELECT * FROM relacion;
+------+--------+-----------+ 
| id   | codigo | nombre    | 
+------+--------+-----------+ 
|    1 |      2 | Winder    | 
|    1 |      3 | Napk      | 
 
 

ID = 1 (Que es ^Tifa^) tiene dos amigos con nombre Winder y Napk

Pero posiblemente para que sea mas entendible, andas solicitando el modelo Entidad-Relacion:

Usuario -> ID -> Relacion

Esa es la relacion de estas 2 tablas.

Habran ocasiones que tendras que utilizar este tipo de modelado, por ejemplo un formulario WEB donde el usuario pueda elegir una o varias categorias de loquesea, digamos gustos particulares (Donde el usuario debe elegir que le gusta la informatica, la PC, la tecnologia, los procesadores, etc)... entonces vas a necesitar 2 indices en vez de 1 y uno de esos 2 tendra que repetirse para poder relacionar 1 usuario con varias categorias que este usuario eliga en su formulario...

Ahora preguntate como en InnoDB que es un motor transaccional, tu puedes implementar el tipo de relacion anterior y expuesto en mi ejemplo con tan solo usando 1 indice por tabla. Si vas a responderme diciendome que puedes usar un campo ENUM no es valido, ya que si tu tienes 10 categorias y en un futuro tienes que agregarle mas... que vas a hacer? tener una tabla del tamanio de un libro por el mero hecho de no disenarla desde un inicio con 2 indices en vez de 1?

Imagina que tengo estas 2 Tablas con los siguientes datos:

mysql> SELECT * FROM relacion;
+------+--------+--------+    
| id   | codigo | nombre |    
+------+--------+--------+    
|    1 |      2 | Luis   |    
|    1 |      3 | Marta  |    
|    2 |      4 | Jose   |    
|    2 |      1 | Marian |    
+------+--------+--------+    
4 ROWS IN SET (0.00 sec)      
 
mysql> SELECT * FROM usuarios;
+----+--------+               
| id | nombre |               
+----+--------+
|  1 | Marian |
|  2 | Luis   |
|  3 | Marta  |
|  4 | Jose   |
+----+--------+
4 ROWS IN SET (0.00 sec)
 

Y yo quiero controlar que cuando actualize o elimine un dato de la tabla usuarios se aplique en la tabla relacion
justo como lo haria las tablas si usase un motor de almacenamiento transaccional como InnoDB, la diferencia es que
estas 2 tablas estan bajo el motor no transaccional Myisam... entonces como tu controlas esto? con la creacion de
triggers como te venia comentando:

mysql> delimiter /
mysql> CREATE TRIGGER trigo
    -> after UPDATE ON usuarios
    -> FOR each ROW            
    -> BEGIN                   
    -> UPDATE relacion SET id = NEW.id WHERE id = OLD.id;
    -> END;                                              
    -> /                                                 
Query OK, 0 ROWS affected (0.06 sec)  
mysql> delimiter ;
 
mysql> UPDATE usuarios SET id = 6 WHERE id = 1;
Query OK, 1 ROW affected (0.04 sec)
ROWS matched: 1  Changed: 1  Warnings: 0
 
mysql> SELECT * FROM relacion;
+------+--------+--------+
| id   | codigo | nombre |
+------+--------+--------+
|    6 |      2 | Luis   |
|    6 |      3 | Marta  |
|    2 |      4 | Jose   |
|    2 |      1 | Marian |
+------+--------+--------+
4 ROWS IN SET (0.00 sec)
 
mysql> SELECT * FROM usuarios;
+----+--------+
| id | nombre |
+----+--------+
|  6 | Marian |
|  2 | Luis   |
|  3 | Marta  |
|  4 | Jose   |
+----+--------+
4 ROWS IN SET (0.00 sec)
 

Viste como actualice data en la tabla usuarios y automaticamente se aplico en la tabla relacion
como si estuviesen bajo un motor de almacenamiento transaccional, cuando no lo esta?
Ahora si quisieras aplicar el 'ON DELETE CASCADE' por ejemplo que si eliminas una fila en
la tabla usuarios tambien se elimine de forma automatica en la tabla relacion.

mysql> CREATE TRIGGER trigo1
    -> after DELETE ON usuarios
    -> FOR each ROW
    -> BEGIN
    -> DELETE FROM relacion WHERE id = OLD.id;
    -> END;
    -> /
Query OK, 0 ROWS affected (0.40 sec)
 
mysql> delimiter ;
 
mysql> DELETE FROM usuarios WHERE id = 2;
Query OK, 1 ROW affected (0.00 sec)
 
mysql> SELECT * FROM usuarios;
+----+--------+
| id | nombre |
+----+--------+
|  6 | Marian |
|  3 | Marta  |
|  4 | Jose   |
+----+--------+
3 ROWS IN SET (0.00 sec)
 
mysql> SELECT * FROM relacion;
+------+--------+--------+
| id   | codigo | nombre |
+------+--------+--------+
|    6 |      2 | Luis   |
|    6 |      3 | Marta  |
+------+--------+--------+
2 ROWS IN SET (0.00 sec)
 
 

Lo anterior expuesto, no fuese posible de realizar sino existiera una relacion de identidad iguales de campos entre el campo ID de ambas tablas. Los datos no tienen que estas de manera obligatoria sobre tablas con motor InnoDB para poder funcionar (A nivel de relacion) como un motor transaccional lo haria. Pero especifico a nivel de relacion de campos no al nivel de todas las funcionalidades que posee un motor transaccional real como son los indices clustered en vez de b-tree, el lockeo de filas en vez de toda la tabla, entre otras cositas internas que poseen los motores transaccionales que no sera aplicable en motores no transaccionales, pero... en el caso que pides no es requerido exponer esto ni abundar tanto, lo que pides se puede controlar con TRIGGERS en motores no transaccionales como puedes ver... y obviamente asi como controlas que campos se actualizan y eliminan de la tabla relacion cuando hacemos algo en la tabla usuarios, puedes crear TRIGGERS que impidan que se actualice o elimine campos sobre relacion sino se ha aplicado nada en la tabla usuarios.

MMMM a ver.. no estoy entendiendo... según yo no las tienes creadas, ya que myisam no te las crea, de hecho no existen con ese motor... mira, con innodb:

mysql> SELECT * FROM `vendor_comment` PROCEDURE ANALYSE ( );
+---------------------------------+-----------------------------+------------------------------+------------+------------+------------------+-------+-------------------------+--------+---------------------------------------------------------------------------------------------------------------+
| Field_name                      | Min_value                   | Max_value                    | Min_length | Max_length | Empties_or_zeros | NULLS | Avg_value_or_avg_length | Std    | Optimal_fieldtype                                                                                             |
+---------------------------------+-----------------------------+------------------------------+------------+------------+------------------+-------+-------------------------+--------+---------------------------------------------------------------------------------------------------------------+
| vsi.vendor_comment.id_vendor    | 1                           | 3                            |          1 |          1 |                0 |     0 | 2.0000                  | 0.8165 | ENUM('1','2','3') NOT NULL                                                                                    |
| vsi.vendor_comment.id_buyer     | 1                           | 1                            |          1 |          1 |                0 |     0 | 1.0000                  | 0.0000 | ENUM('1') NOT NULL                                                                                            |
| vsi.vendor_comment.comment      | Buyer 1 comment TO CocaCola | Buyer 1 comment TO Microsoft |         27 |         31 |                0 |     0 | 28.6667                 | NULL   | ENUM('Buyer 1 comment to CocaCola','Buyer 1 comment to Ideas de Web','Buyer 1 comment to Microsoft') NOT NULL |
| vsi.vendor_comment.registration | 2009-12-31                  | 2009-12-31                   |         10 |         10 |                0 |     0 | 10.0000                 | NULL   | ENUM('2009-12-31') NOT NULL                                                                                   |
+---------------------------------+-----------------------------+------------------------------+------------+------------+------------------+-------+-------------------------+--------+---------------------------------------------------------------------------------------------------------------+
4 ROWS IN SET (0.00 sec)
 
 

No se en que punto todavia no te aclaras....

En las tablas que yo he creado de ejemplo, hay una relacion el campo ID de ambas tablas, vamos que no es tan dificil de ver  :xD

Dejame intentar desglosar porque creo que tienes una pekena confusion en cuanto a las relaciones de entidades y si un motor es o no transaccional. Basandome en la manera como tu percibes cuando unos datos estan o no relacionados en varias tablas (que para ti solo aplican si el motor es transaccional) el ejemplo posteado por mi, y por casi todos los demas (sino todos) tambien estan erroneos. Porque ellos se basaron en el modelo entidad-relacion de datos, ellos no se han basado de si el motor es o no transaccional, son dos cosas distintas.

Cuando te dicen que un motor de almacenamiento es transaccional te estan diciendo que tiene unas funcionalidades (No las voy a describir todas aqui que conste, solo las basicas para ver si te aclaras un poco) dentro de estas funcionalidades existe el control de forma automatica entre 2  o mas tablas, donde hay una tabla 'padre' y una tabla 'hijo' este control lo que hace es precisamente, que si se actualiza o elimina un dato en la tabla padre aplica automaticamente a la tabla hijo (Siempre y cuando pusieras dicha condicion a la tabla hijo con ON UPDATE y ON DELETE) ahora, si te fijas bien yo te he recreado de forma basica esa mismita funcionalidad en 2 tablas bajo motor NO transaccional, como lo hice?? con los TRIGGERS que te postee. Estoy en este caso haciendo lo mismo que si ambas tablas fuesen transaccionales (En este unico punto ojo que no quiero personas que asuman que estoy comparando transaccional vs no transaccional) lo unico que yo misma cree la condiciones con 2 TRIGGERS, mientras un motor transaccional como InnoDB lo hace ya por defecto de forma automatica porque esta programado a funcionar asi.

Cuando te dicen un motor No transacional, te estan diciendo que las funcionalidades de las cuales carece este motor es precisamente el control automatico de lo que ocurre entre la tabla padre o la tabla hijo (Hay mas diferencias que conste, pero no aplica extenderlas para lo que requieres aclararte). Por esta razon si yo tomo este modelo y lo coloco bajo un motor no transaccional, como yo controlo las transaciones de ahi me vere obligada a implementar de alguna manera las funcionalidades basicas que controlen los cambios de una tabla padre a una tabla hijo, por eso viste que cree 2 TRIGGERS sencillos que me manejaran los UPDATE y DELETE de la tabla padre hacia la tabla hijo.

Las relaciones entre tablas se basan por las entidades que componen las tablas llamase campos, no es obligatorio que este en un motor transacional o no, las relaciones de datos es una cosa, la funcionalidad de control sobre esos datos es otra cosa y te lo he expuesto mas arriba.