Podemos decir de manera simple que integridad referencial significa que cuando un registro en una tabla haga referencia a un registro en otra tabla, el registro correspondiente debe existir. Por ejemplo, consideremos la relaci�n entre una tabla cliente y una tabla venta.
+------------+ +-------------+
| cliente | | venta |
+------------+ +-------------+
| id_cliente | | id_factura |
| nombre | | id_cliente |
+------------+ | cantidad |
+-------------+
Para poder establecer una relaci�n entre dos tablas, es necesario asignar un campo en com�n a las dos tablas. Para este ejemplo, el campo id_cliente existe tanto en la tabla cliente como en la tabla venta. La mayor�a de las veces, este campo en com�n debe ser una clave primaria en alguna de las tablas. Vamos a insertar algunos datos en estas tablas.
Tabla cliente +------------+--------------+ | id_cliente | nombre | +------------+--------------+ | 1 | Juan penas | | 2 | Pepe el Toro | +------------+--------------+ Tabla venta +------------+------------+----------+ | id_factura | id_cliente | cantidad | +------------+------------+----------+ | 1 | 1 | 23 | | 2 | 3 | 39 | | 3 | 2 | 81 | +------------+------------+----------+
Hay dos registros en la tabla cliente, pero existen 3 id_cliente distintos en la tabla venta. Hab�amos dicho que las dos tablas se relacionan con el campo id_cliente, por lo tanto, podemos decir que Juan Penas tiene una cantidad de 23, y Pepe el Toro 81, sin embargo, no hay un nombre que se corresponda con el id_cliente 3.
Las relaciones de claves for�neas se describen como relaciones padre/hijo (en nuestro ejemplo, cliente es el padre y venta es el hijo), y se dice que un registro es hu�rfano cuando su padre ya no existe.
Cuando en una base de datos se da una situaci�n como esta, se dice que se tiene una integridad referencial pobre (pueden existir otra clase de problemas de integridad). Generalmente esto va ligado a un mal dise�o, y puede generar otro tipo de problemas en la base de datos, por lo tanto debemos evitar esta situaci�n siempre que sea posible.
En el pasado, MySQL no se esforzaba en evitar este tipo de situaciones, y la responsabilidad pasaba a la aplicaci�n. Para muchos desarrolladores, esta no era una situaci�n del todo grata, y por lo tanto no se consideraba a MySQL para ser usado en sistemas "serios". Por supuesto, esta fue una de las cosas m�s solicitadas en las anteriores versiones de MySQL; que se tuviera soporte para claves for�neas, para que MySQL mantenga la integridad referencial de los datos.
Una clave for�nea es simplemente un campo en una tabla que se corresponde con la clave primaria de otra tabla. Para este ejemplo, el campo id_cliente en la tabla venta es la clave for�nea. N�tese que este campo se corresponde con el campo id_cliente en la tabla cliente, en d�nde este campo es la clave primaria.
Las claves for�neas tienen que ver precisamente con la integridad referencial, lo que significa que si una clave for�nea contiene un valor, ese valor se refiere a un registro existente en la tabla relacionada.