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

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

Saludos

Lo dejamos en un empate hasta que se demuestre lo contrario xD, porque con el enunciado ese vete a saber
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!

Se que hay una mejor manera de estructurado  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)
 
 

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

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.