Modelo ANSI/SPARC: Abstracción y Reglas de Integridad en Bases de Datos

Enviado por Chuletator online y clasificado en Informática y Telecomunicaciones

Escrito el en español con un tamaño de 6,78 KB

Modelo ANSI/SPARC

Una base de datos se puede ver de diferentes formas. Cada programa que accede a la base de datos manipula solo ciertos datos y estructuras. Así, cada programa posee una visión de la base de datos. La unión de todos los datos y sus relaciones forman el llamado esquema conceptual. Mientras que el esquema físico representa el almacenamiento de los datos y sus formas de acceso.

El SGBD es el encargado de realizar las traducciones para pasar del esquema conceptual al físico.

Desde el ANSI (Instituto de Estándares Americano) se creó una sección llamada SPARC dedicada a estándares de sistemas de información. Propusieron tres niveles de abstracción en las bases de datos:

Esquema Externo

Visión de la base de datos que ofrece cada aplicación. Lógicamente es distinta en cada aplicación. Representan vistas concretas de la base de datos.

Esquema Conceptual

Representación teórica de los datos y de sus relaciones. Representa la lógica de la base de datos.

Esquema Físico

Representa los datos según son almacenados en el medio físico (en los discos).

Independencia Lógico/Física

El esquema conceptual debe ser absolutamente independiente del físico. Esto significa:

1. Independencia Física de los Datos

Aunque el esquema físico cambie, el esquema conceptual no debe verse afectado. En la práctica, esto significa que, aunque se añadan o cambien discos u otro hardware, o se modifique el sistema operativo u otros cambios relacionados con la física de la base de datos, el esquema conceptual permanece invariable.

2. Independencia Lógica de los Datos

Significa que, aunque se modifique el esquema conceptual, la vista que poseen las aplicaciones (los esquemas externos) no serán afectados.

Reglas de Integridad

Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las reglas de integridad que los datos almacenados en dicha estructura deben cumplir para garantizar que son correctos.

Al definir cada atributo sobre un dominio, se impone una restricción sobre el conjunto de valores permitidos para cada atributo. A este tipo de restricciones se les denomina restricciones de dominios. Hay, además, dos reglas de integridad muy importantes que son restricciones que se deben cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las reglas se deben cumplir todo el tiempo). Estas reglas son la regla de integridad de entidades y la regla de integridad referencial.

Antes de definirlas, es preciso conocer el concepto de nulo.

Nulos

Cuando en una tupla (registro) un atributo es desconocido, se dice que es nulo. Un nulo no representa el valor cero ni la cadena vacía, estos son valores que tienen significado. El nulo implica ausencia de información, bien porque al insertar la tupla se desconocía el valor del atributo, o bien porque para dicha tupla el atributo no tiene sentido.

Ya que los nulos no son valores, deben tratarse de modo diferente, lo que causa problemas de implementación. De hecho, no todos los SGBD relacionales soportan los nulos.

Regla de Integridad de Entidades

La primera regla de integridad se aplica a las claves primarias de las relaciones base:

Ninguno de los atributos que componen la clave primaria puede ser nulo.

Por definición, una clave primaria es un identificador irreducible que se utiliza para identificar de modo único las tuplas. Que es irreducible significa que ningún subconjunto de la clave primaria sirve para identificar las tuplas de modo único. Si se permite que parte de la clave primaria sea nula, se está diciendo que no todos sus atributos son necesarios para distinguir las tuplas, con lo que se contradice la irreducibilidad.

Nótese que esta regla solo se aplica a las relaciones base y a las claves primarias, no a las claves alternativas.

Regla de Integridad Referencial

La segunda regla de integridad se aplica a las claves ajenas: si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos.

La regla de integridad referencial se enmarca en términos de estados de la base de datos: indica lo que es un estado ilegal, pero no dice cómo puede evitarse.

La cuestión es ¿qué hacer si, estando en un estado legal, llega una petición para realizar una operación que conduce a un estado ilegal? Existen dos opciones:

  1. Rechazar la operación.
  2. Aceptar la operación y realizar operaciones adicionales compensatorias que conduzcan a un estado legal.

Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres preguntas:

  • Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos?
  • Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la clave ajena?
    • Restringir: no se permite borrar la tupla referenciada.
    • Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la referencian mediante la clave ajena.
    • Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (solo si acepta nulos).
  • Regla de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave primaria de la tupla referenciada por la clave ajena?
    • Restringir: no se permite modificar el valor de la clave primaria de la tupla referenciada.
    • Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se propaga la modificación a las tuplas que la referencian mediante la clave ajena.
    • Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (solo si acepta nulos).

Reglas de Negocio

Además de las dos reglas de integridad anteriores, los usuarios o los administradores de las bases de datos pueden imponer ciertas restricciones específicas sobre los datos, denominadas reglas de negocio.

Por ejemplo, si en una oficina de la empresa inmobiliaria solo puede haber hasta veinte empleados, el SGBD debe dar la posibilidad al usuario de definir una regla al respecto y debe hacerla respetar. En este caso, no debería permitir dar de alta un empleado en una oficina que ya tiene los veinte permitidos.

Hoy en día aún existen SGBD relacionales que no permiten definir este tipo de restricciones ni las hacen respetar.

Entradas relacionadas: