AO DEL CENTENARIO DE MACHU PICCHU PARA EL MUNDO

I.S.T ALAS PERUANAS

TEMA: INTEGRIDAD REFERENCIAL

NOMBRES Y APELLIDOS: Pedro Rolando Galarza Garcia ESPECIALIDAD: Computacion e Informatica CICLO: IV TURNO: Maana PROFESOR: Peter Nuez Gonzales

ICA - PERU

1

INTEGRIDAD REFERENCIALIntroduccin

La integridad referencial es un sistema de reglas que utilizan la mayora de las bases de datos relacionales para asegurarse que los registros de tablas relacionadas son vlidos y que no se borren o cambien datos relacionados de forma accidental produciendo errores de integridad. Primero repasemos un poco los tipos de relaciones.

Concepto de Integridad referencialLa integridad referencial es una propiedad deseable en las bases de datos. Gracias a la integridad referencial se garantiza que una entidad (fila o registro) siempre se relaciona con otras entidades vlidas, es decir, que existen en la base de datos. Implica que en todo momento dichos datos sean correctos, sin repeticiones innecesarias, datos perdidos y relaciones mal resueltas. Todas las bases de datos relacionales gozan de esta propiedad gracias a que el software gestor de base de datos vela por su cumplimiento. En cambio, las bases de datos jerrquicas requieren que los programadores se aseguren de mantener tal propiedad en sus programas.

Cuando se define una columna como clave fornea, las filas de la tabla pueden contener en esa columna o bien el valor nulo (ningn valor), o bien un valor que existe en la otra tabla, un error sera asignar a un habitante una poblacin que no est en la tabla de poblaciones. Eso es lo que se denomina integridad referencial y consiste en que los datos que referencian otros (claves forneas) deben ser correctos. La integridad referencial hace que el sistema gestor de la base de datos se asegure de que no hayan en las claves forneas valores que no estn en la tabla principal. La integridad referencial se activa en cuanto creamos una clave fornea y a partir de ese momento se comprueba cada vez que se modifiquen datos que puedan alterarla. Cundo se pueden producir errores en los datos? Cuando insertamos una nueva fila en la tabla secundaria y el valor de la clave fornea no existe en la tabla principal. insertamos un nuevo habitante y en la columna poblacion escribimos un cdigo de poblacion que no est en la tabla de poblaciones (una poblacin que no existe).

2

Cuando modificamos el valor de la clave principal de un registro que tiene 'hijos', modificamos el codigo de Valencia, sustituimos el valor que tena (1) por un nuevo valor (10), si Valencia tena habitantes asignados, qu pasa con esos habitantes, no pueden seguir teniendo el codigo de poblacin 1 porque la poblacin 1 ya no existe, en este caso hay dos alternativas, no dejar cambiar el codigo de Valencia o bien cambiar el codigo de poblacin de todos los habitantes de Valencia y asignarles el cdigo 10.

Cuando modificamos el valor de la clave fornea, el nuevo valor debe existir en la tabla principal. Por ejemplo cambiamos la poblacin de un habitante, tena asignada la poblacin 1 (porque estaba empadronado en valencia) y ahora se le asigna la poblacin 2 porque cambia de lugar de residencia. La poblacin 2 debe existir en la tabla de poblaciones.

Cuando queremos borrar una fila de la tabla principal y ese registro tiene 'hijos', por ejemplo queremos borrar la poblacin 1 (Valencia) si existen habitantes asignados a la poblacin 1, estos no se pueden quedar con el valor 1 en la columna poblacin porque tendran asignada una poblacin que no existe. En este caso tenemos dos alternativas, no dejar borrar la poblacin 1 de la tabla de poblaciones, o bien borrarla y poner a valor nulo el campo poblacion de todos sus 'hijos'. .

Ejemplo: Cmo funcionaSupongamos una base de datos con las entidades Persona y Factura. Toda factura corresponde a una persona y solamente una. Implica que en todo momento dichos datos sean correctos, sin repeticiones innecesarias, datos perdidos y relaciones mal resueltas. Supongamos que una persona se identifica por su atributo DNI (Documento nacional de identidad). Tambin tendr otros atributos como el nombre y la direccin. La entidad Facturadebe tener un atributo DNI_cliente que identifique a quin pertenece la factura. Por sentido comn es evidente que todo valor de DNI_cliente debe corresponder con algn valor existente del atributo DNI de la entidad Persona. Esta es la idea intuitiva de la integridad referencial. Asociada a la integridad referencial estn los conceptos de actualizar los registros en cascada y eliminar registros en cascada.

Actualizacin y borrado en cascadaEl actualizar y/o eliminar registros en cascada, son opciones que se definen cuando definimos la clave fornea y que le indican al sistema gestor qu hacer en los casos comentados en el punto anterior.

3

Actualizar registros en cascada: Esta opcin le indica al sistema gestor de la base de datos que cuando se cambie un valor del campo clave de la tabla principal, automticamente cambiar el valor de la clave fornea de los registros relacionados en la tabla secundaria.

Por ejemplo, si cambiamos en la tabla de poblaciones (la tabla principal) el valor 1 por el valor 10 en el campo codigo (la clave principal), automticamente se actualizan todos los habitantes (en la tabla secundaria) que tienen el valor 1 en el campo poblacion (en la clave ajena) dejando 10 en vez de 1. Si no se tiene definida esta opcin, no se puede cambiar los valores de la clave principal de la tabla principal. En este caso, si intentamos cambiar el valor 1 del codigo de la tabla de poblaciones , no se produce el cambio y el sistema nos devuelve un error o un mensaje que los registros no se han podido modificar por infracciones de clave. Eliminar registros en cascada: Esta opcin le indica al sistema gestor de la base de datos que cuando se elimina un registro de la tabla principal automticamente se borran tambin los registros relacionados en la tabla secundaria.

Por ejemplo: Si borramos la poblacin Onteniente en la tabla de poblaciones, automticamente todos los habitantes de Onteniente se borrarn de la tabla de habitantes. Si no se tiene definida esta opcin, no se pueden borrar registros de la tabla principal si estos tienen registros relacionados en la tabla secundaria. En este caso, si intentamos borrar la poblacin Onteniente, no se produce el borrado y el sistema nos devuelve un error o un mensaje que los registros no se han podido eliminar por infracciones de clave.

Tipos de relaciones.Entre dos tablas de cualquier base de datos relacional pueden haber dos tipos de relaciones, relaciones uno a uno y relaciones uno a muchos: Relacin Uno a Uno: Cuando un registro de una tabla slo puede estar relacionado con un nico registro de la otra tabla y viceversa. Por ejemplo: tenemos dos tablas una de profesores y otra de departamentos y queremos saber qu profesor es jefe de qu departamento, tenemos una relacin uno a uno entre las dos tablas ya que un departamento tiene un solo jefe y un profesor puede ser jefe de un solo departamento. Relacin Uno a Varios: Cuando un registro de una tabla (tabla secundaria) slo puede estar relacionado con un nico registro de la otra tabla (tabla principal) y un registro de la tabla principal puede tener ms de un registro relacionado en la tabla secundaria, en este caso se suele hacer referencia a la tabla principal como tabla 'padre' y a la tabla

4

secundaria como tabla 'hijo', entonces la regla se convierte en 'un padre puede tener varios hijos pero un hijo solo tiene un padre (regla ms fcil de recordar). Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y otra con los habitantes, una poblacin puede tener ms de un habitante, pero un habitante pertenecer (estar empadronado) en una nica poblacin. En este caso la tabla principal ser la de poblaciones y la tabla secundaria ser la de habitantes. Una poblacin puede tener varios habitantes pero un habitante pertenece a una sola poblacin. Esta relacin se representa incluyendo en la tabla 'hijo' una columna que se corresponde con la clave principal de la tabla 'padre', esta columna es lo denominamos clave fornea (o clave ajena o clave externa). Una clave fornea es pues un campo de una tabla que contiene una referencia a un registro de otra tabla. Siguiendo nuestro ejemplo en la tabla habitantes tenemos una columna poblacin que contiene el cdigo de la poblacin en la que est empadronado el habitante, esta columna es clave ajena de la tabla habitantes, y en la tabla poblaciones tenemos una columna codigo de poblacion clave principal de la tabla.

Relacin Varios a Varios: Cuando un registro de una tabla puede estar relacionado con ms de un registro de la otra tabla y viceversa. En este caso las dos tablas no pueden estar relacionadas directamente, se tiene que aadir una tabla entre las dos que incluya los pares de valores relacionados entre s. Por ejemplo: tenemos dos tablas una con los datos de clientes y otra con los artculos que se venden en la empresa, un cliente podr realizar un pedido con varios artculos, y un artculo podr ser vendido a ms de un cliente. No se puede definir entre clientes y artculos, hace falta otra tabla (por ejemplo una tabla de pedidos) relacionada con clientes y con artculos. La tabla pedidos estar relacionada con cliente por una relacin uno a muchos y tambin estar relacionada con artculos por un relacin uno a muchos.

5

Existen tres tipos de integridad referencial:

1. Integridad referencial dbil: si en una tupla de R todos los valores de los atributos de K tienen un valor que no es el nulo, entonces debe existir una tupla en S que tome esos mismos valores en los atributos de J; 2. Integridad referencial parcial: si en una tupla de R algn atributo de K toma el valor nulo, entonces debe existir una tupla en S que tome en los atributos de J los mismos valores que los atributos de K con valor no nulo; y 3. Integridad referencial completa: en una tupla de R todos los atributos de K deben tener el valor nulo o bien todos tienen un valor que no es el nulo y entonces debe existir una tupla en S que tome en los atributos de J los mismos valores que toman los de K.

Integridad referencial con PostgreSQLLa integridad referencial es una funcionalidad disponible en las bases de datos relacionales que garantiza la coherencia de datos entre relaciones aparejadas. Bajo mi punto de vista, es una de las caractersticas bsicas y ms importantes que una base de datos nos puede proporcionar y siempre se deberia de usar para garantizar la integridad de los datos. Es increible ver como muchisimos proyectos de sotfware libre que usan una base de datos, no usan para nada la integridad referencial disponible en la base de datos. Muchos de ellos intentan implementar cierta integridad en la aplicacin. Esto es lo mismo que intentar inventar la rueda de nuevo y por supuesto est a la merced de posibles fallos de programacin en la aplicacin. La integridad referencial se define con el uso combinado de claves primarias (primary keys) claves candidatas (candidate key) y clave forneas (foreign key). Las claves primarias y candidatas estn formadas por valores nicos y una clave fornea solamente puede estar asociada a una de estas para garantizar la existencia de un solo valor correcto. Las claves candidatas se pueden definir creando un ndice nico (CREATE UNIQUE INDEX ....) en la columna pertinente. Para poder usar esta funcionalidad es importante tener nuestra base de datos normalizada para:

6

Evitar la redundancia de los datos. Evitar problemas de actualizacin de los datos en las tablas. Proteger la integridad de los datos

Nada mejor que un simple ejemplo para ver como podemos implementar la teoria con unos simples comandos.

En nuestro ejemplo tenemos dos tablas. Una de clientes, con dos atributos, un nmero identificador y un nombre. Y otra tabla para facturas con el nmero de factura y el nmero de cliente. Si no utilizaramos integridad referencial, que ocurriria si:

Intentamos insertar una factura con un nmero de cliente que no existe? Borramos un cliente que tiene una factura asignada?

La respuesta es sencilla, las dos operaciones se podrian realizar sin problemas y tendriamos un sistema con unos datos en los que no podriamos confiar por la falta de consistencia de los mismos. Esto lo podemos arreglar con dos sencillas operaciones, creamos una clave primaria en el atributo ID de la tabla clientes y una clave fornea en el atributo CLIENTE de la tabla facturas. Esto lo podemos hacer cuando definamos la tabla con los siguientes comandos para la clave primaria: ALTER TABLE clientes ADD CONSTRAINT cliente_pk PRIMARY KEY (id); Y para la fornea, por ejemplo:

7

ALTER TABLE facturas ADD CONSTRAINT clientes_id_fk FOREIGN KEY (cliente) REFERENCES clientes(id) MATCH FULL ON DELETE RESTRICT ON UPDATE CASCADE; Esto seria suficiente para implementar integridad referencial en las dos tablas de nuestro ejemplo. Si intentamos hacer algo ilegal con nuestros datos, la base de datos nos lo prohibir y nos dar un error. postgres=# SELECT * from clientes; id | nombre ----+----------1 | nombre 1 2 | nombre 2 (2 rows) postgres=# SELECT * from facturas; facnum | cliente --------+--------0001 | 0002 | 0003 | (3 rows) postgres=# SELECT facturas.facnum, clientes.nombre AS cliente FROM clientes JOIN facturas ON (clientes.id = facturas.cliente) ORDER BY facnum; facnum | cliente --------+----------0001 | nombre 1 0002 | nombre 1 0003 | nombre 2 (3 rows) postgres=# INSERT INTO facturas (facnum,cliente) VALUES ('0004',3); ERROR: insert or update on table "facturas" violates foreign key constraint "clientes_id_fk" DETAIL: Key (cliente)=(3) is not present in table "clientes". 1 1 2

8

postgres=# DELETE FROM clientes WHERE id = 1; ERROR: update or delete on table "clientes" violates foreign key constraint "clientes_id_fk" on table "facturas" DETAIL: Key (id)=(1) is still referenced from table "facturas". postgres=# UPDATE clientes SET id = 3 where id = 1; UPDATE 1 postgres=# SELECT * from clientes; id | nombre ----+----------2 | nombre 2 3 | nombre 1 (2 rows) postgres=# SELECT * from facturas; facnum | cliente --------+--------0003 | 0001 | 0002 | (3 rows) postgres=# SELECT facturas.facnum, clientes.nombre AS cliente FROM clientes JOIN facturas ON (clientes.id = facturas.cliente) ORDER BY facnum; facnum | cliente --------+----------0001 | nombre 1 0002 | nombre 1 0003 | nombre 2 (3 rows) 2 3 3

9

Hay tres parametros cuando definimos una clave fornea que son muy importantes y que definen como la base de datos se va a comportar para salvaguardar la integridad de nuestros datos. Estos parametros son:

MATCH tipo ON DELETE accion ON UPDATE accin

En donde tipo puede tener estos valores:

FULL: No permite que una columna tenga el valor NULL en una clave fornea compuesta por varias columnas SIMPLE: Permite que una columna tenga el valor NULL en una clave fornea compuesta por varias columnas

Y accion puede tener estos valores:

NO ACTION: Produce un error indicando que un DELETE UPDATE crear una violacin de la clave fornea definida. RESTRICT: Produce un error indicando que un DELETE UPDATE crear una violacin de la clave fornea definida. CASCADE: Borra actualiza automticamente todas las referencias activas SET NULL: Define las referencias activas como NULL SET DEFAULT: Define las referencias activas como el valor por defecto (si est definido) de las mismas

En nuestro ejemplo hemos definido que ninguna columna de nuestra clave fornea puede ser NULL, que no se pueda borrar una clave fornea con referencias activas y que en caso de actualizar el valor de una clave fornea, se actualicen tambien todas las referencias a la misma automticamente. Esto es todo en esta introduccin a la integridad referencial en nuestra base de datos. En nuestro ejemplo tenemos dos tablas. Una de clientes, con dos atributos, un nmero identificador y un nombre. Y otra tabla para facturas con el nmero de factura y el nmero de cliente. Si no utilizaramos integridad referencial, que ocurriria si:

Intentamos insertar una factura con un nmero de cliente que no existe? Borramos un cliente que tiene una factura asignada?

10

La respuesta es sencilla, las dos operaciones se podrian realizar sin problemas y tendriamos un sistema con unos datos en los que no podriamos confiar por la falta de consistencia de los mismos. Esto lo podemos arreglar con dos sencillas operaciones, creamos una clave primaria en el atributo ID de la tabla clientes y una clave fornea en el atributo CLIENTE de la tabla facturas. Esto lo podemos hacer cuando definamos la tabla con los siguientes comandos para la clave primaria: ALTER TABLE clientes ADD CONSTRAINT cliente_pk PRIMARY KEY (id); Y para la fornea, por ejemplo: ALTER TABLE facturas ADD CONSTRAINT clientes_id_fk FOREIGN KEY (cliente) REFERENCES clientes(id) MATCH FULL ON DELETE RESTRICT ON UPDATE CASCADE; Esto seria suficiente para implementar integridad referencial en las dos tablas de nuestro ejemplo. Si intentamos hacer algo ilegal con nuestros datos, la base de datos nos lo prohibir y nos dar un error. postgres=# SELECT * from clientes; id | nombre ----+----------1 | nombre 1 2 | nombre 2 (2 rows) postgres=# SELECT * from facturas; facnum | cliente --------+--------0001 | 0002 | 0003 | (3 rows) postgres=# SELECT facturas.facnum, clientes.nombre AS cliente FROM clientes JOIN facturas ON (clientes.id = facturas.cliente) 1 1 2

11

ORDER BY facnum; facnum | cliente --------+----------0001 | nombre 1 0002 | nombre 1 0003 | nombre 2 (3 rows) postgres=# INSERT INTO facturas (facnum,cliente) VALUES ('0004',3); ERROR: insert or update on table "facturas" violates foreign key constraint "clientes_id_fk" DETAIL: Key (cliente)=(3) is not present in table "clientes". postgres=# DELETE FROM clientes WHERE id = 1; ERROR: update or delete on table "clientes" violates foreign key constraint "clientes_id_fk" on table "facturas" DETAIL: Key (id)=(1) is still referenced from table "facturas". postgres=# UPDATE clientes SET id = 3 where id = 1; UPDATE 1 postgres=# SELECT * from clientes; id | nombre ----+----------2 | nombre 2 3 | nombre 1 (2 rows) postgres=# SELECT * from facturas; facnum | cliente --------+--------0003 | 0001 | 0002 | (3 rows) 2 3 3

12

postgres=# SELECT facturas.facnum, clientes.nombre AS cliente FROM clientes JOIN facturas ON (clientes.id = facturas.cliente) ORDER BY facnum; facnum | cliente --------+----------0001 | nombre 1 0002 | nombre 1 0003 | nombre 2 (3 rows)

Hay tres parametros cuando definimos una clave fornea que son muy importantes y que definen como la base de datos se va a comportar para salvaguardar la integridad de nuestros datos. Estos parametros son:

MATCH tipo ON DELETE accion ON UPDATE accion

En donde tipo puede tener estos valores:

FULL: No permite que una columna tenga el valor NULL en una clave fornea compuesta por varias columnas SIMPLE: Permite que una columna tenga el valor NULL en una clave fornea compuesta por varias columnas

Y accion puede tener estos valores:

NO ACTION: Produce un error indicando que un DELETE UPDATE crear una violacin de la clave fornea definida. RESTRICT: Produce un error indicando que un DELETE UPDATE crear una violacin de la clave fornea definida. CASCADE: Borra actualiza automticamente todas las referencias activas SET NULL: Define las referencias activas como NULL SET DEFAULT: Define las referencias activas como el valor por defecto (si est definido) de las mismas

En nuestro ejemplo hemos definido que ninguna columna de nuestra clave fornea puede ser NULL, que no se pueda borrar una clave fornea con referencias activas y que en caso de actualizar el valor de una clave fornea, se actualicen tambien todas las referencias a la misma automticamente.

13

Esto es todo en esta introduccin a la integridad referencial en nuestra base de datos. Qu es la integridad referencial? Con Microsoft Access La integridad referencial es un sistema de reglas que utiliza Microsoft Access para garantizar que las relaciones entre los registros de tablas relacionadas son vlidas y que no se eliminan ni modifican accidentalmente datos relacionados. Puede establecer la integridad referencial cuando se cumplen todas las condiciones siguientes: El campo coincidente de la tabla principal es una clave principal o tiene un ndice nico. Los campos relacionados tienen el mismo tipo de datos. Existen dos excepciones: un campo Autonumrico puede estar relacionado con un campo Numrico con la propiedad Tamao del campo establecida a Entero largo, y un campo Autonumrico con la propiedad Tamao del campo establecida a Id. de rplica puede estar relacionado con un campo Numrico con la propiedad Tamao del campo establecida a Id. de rplica. Ambas tablas pertenecen a la misma base de datos de Microsoft Access. Cuando se exige la integridad referencial, deben observarse las reglas siguientes: No puede introducir un valor en el campo de clave externa de la tabla relacionada que no exista en la clave principal de la tabla principal. No puede eliminar un registro de una tabla principal si existen registros coincidentes en una tabla relacionada. No puede cambiar un valor de clave principal en la tabla principal si ese registro tiene registros relacionados. Si desea que Microsoft Access exija esas reglas para una relacin, seleccione la casilla de verificacin Exigir integridad referencial al crear la relacin. Si se exige la integridad referencial e infringe una de las reglas con las tablas relacionadas, Microsoft Access muestra un mensaje y no permite el cambio. Puede anular las restricciones sobre la eliminacin o la modificacin de registros relacionados y an as conservar la integridad referencial mediante la activacin de las casillas de verificacin Actualizar en cascada los campos relacionados y Eliminar en cascada los registros relacionados. Cuando la casilla de verificacin Actualizar en cascada los campos relacionados est activada, el cambio de un valor de clave principal en la tabla principal actualiza automticamente el valor coincidente en todos los registros relacionados. Cuando la casilla de verificacin Eliminar en cascada los registros relacionados est activada, la eliminacin de un registro en la tabla principal elimina todos los registros relacionados en la tabla relacionada.

La integridad referencial en juegoCuando se crea una nueva instancia de Factura, la integridad referencial exige que el atributo DNI_cliente coincida con el atributo DNI de alguna instancia de la entidadPersona. En caso contrario, no se permite la operacin.

14

Cuando se intenta eliminar una instancia de Persona, la integridad referencial exige que no exista ninguna factura asociada, es decir, se comprueba que no existe ninguna instancia deFactura cuyo atributo DNI_cliente coincida con el atributo DNI de la instancia a borrar. En caso contrario, no se permite la operacin.

Restricciones de IntegridadSolucin Definicin de dominios restriccin de unicidad, restriccin de valor no nulo definicin de clave primaria definicin de claves ajenas. restricciones de integridad generales. Se especifican junto con el esquema de la base de datos y el responsable de que se cumplan es el SGBD.

15