Niveles de Abstracción, Arquitecturas y Condiciones de Integridad en Bases de Datos

Niveles de Abstracción (Arquitectura ANSI/SPARC)

Nivel Interno

Constituye la representación de la base de datos más cercana a la estructura de almacenamiento físico. Es la capa donde se establece la forma en que se implementan las estructuras de datos que organizan los niveles superiores.

Nivel Conceptual

Supone una abstracción global de la base de datos que integra y aglutina todas las percepciones que los usuarios tienen de ella.

Nivel Externo

A este nivel se definen todas las percepciones particulares de la base de datos por parte de los usuarios. Cada usuario puede tener su propia visión de la base de datos.

Transformaciones

Conceptual/Interna

Cómo se organizan las entidades lógicas del nivel conceptual en términos de registros y campos almacenados en el nivel interno. Independencia física: varía el nivel interno, cambia la correspondencia y no varía el nivel conceptual.

Externa/Conceptual

Describe un esquema externo en términos del esquema conceptual subyacente. Independencia lógica: varía el nivel conceptual, cambia la correspondencia y no varía el nivel externo.

Externa/Externa

Algunos SGBD permiten describir esquemas externos en términos de otros esquemas externos. Independencia lógica: varía el esquema externo subyacente, cambia la correspondencia y no varía el esquema definido.

Sublenguaje DSL

DDL (Sublenguaje de Definición de Datos)

Subconjunto del DSL destinado a la definición de estructuras de datos y esquemas de la base de datos.

DML (Sublenguaje de Manipulación de Datos)

Subconjunto del DSL mediante el que podemos introducir datos en los esquemas, modificarlos, eliminarlos y consultarlos. También debe permitir consultar la estructura de los esquemas definidos en la base de datos.

DCL (Sublenguaje de Control de Datos)

Permite gestionar los requisitos de acceso a los datos y otras tareas administrativas sobre la base de datos. (ANSI/SPARC recomienda disponer de un DDL, un DML y un DCL para cada nivel de la arquitectura; en la práctica, todos estos se presentan bajo una única implementación. La industria ha seguido un camino diferente: lenguajes de datos estándares.)

Lenguaje Anfitrión o de Aplicación

Desarrollo de aplicaciones en el sistema operativo que trabajen sobre la base de datos.

• De propósito general: C/C++, Java, C#.
• Herramientas de desarrollo específicas: Developer de Oracle, Delphi de Borland. Proporciona procesamiento avanzado de datos y gestión de la interfaz de usuario.

Acoplamiento

Débilmente Acoplado

Lenguajes de propósito general. El programador puede distinguir sentencias propias del lenguaje y sentencias dispuestas para acceder a la base de datos a través del DSL.

Fuertemente Acoplado

Lenguajes y herramientas de propósito específico. Se parte del DSL como elemento central y se le incorporan características para facilitar el desarrollo de aplicaciones.

Alternativas para Implementar el Acoplamiento

Para el débil: APIs de acceso a base de datos. DSL inmerso en el código fuente del lenguaje anfitrión.

Para el fuerte: diversas propuestas, PL/SQL de Oracle. Ejecución de Java sobre una máquina virtual implantada en el propio SGBD.

El Administrador de la Base de Datos (DBA)

• Elaboración del esquema conceptual.
• Decidir la estructura de almacenamiento en el nivel interno.
• Conexión con usuarios.
• Definir las restricciones de integridad.
• Definir e implementar la política de seguridad.
• Definir e implementar la estrategia de recuperación frente a fallos.
• Optimización del rendimiento.
• Monitorizar el SGBD.

Arquitectura Centralizada

Toda la carga de gestión y procesamiento de información recaía en servidores centrales (grandes computadores) a los que el usuario accedía mediante terminales. En el ordenador principal estaba instalado y ejecutándose tanto el SGBD como los programas de aplicación. El usuario obtenía el soporte para sus actividades interactuando con el computador principal mediante un terminal desde el que encadenaba la ejecución de los programas de aplicación.

Problemas: Elevado coste de los ordenadores principales y la aparición del PC.

Solución: Desplazar la ejecución de los programas de usuario y la interacción hasta los PCs, reducción de costes en hardware.

Arquitectura Cliente/Servidor

El SGBD se desliga en un servidor y un servicio de escucha de peticiones originadas desde PCs conectados con el servidor. El servicio sirve de enlace entre PCs y servidor. Del lado del cliente disponemos de los programas de aplicación y de un servicio de enlace cliente entre estos y el servidor.

Problemas: Coste de mantenimiento de los PCs (instalación, configuración y actualización).

Solución: Separar en las aplicaciones la parte que interactúa con el usuario y la parte de ejecución lógica del programa.

Arquitectura en 3 Niveles de Procesamiento

Nivel de Servidor de Datos

(Posiblemente distribuido, el SGBD permite organizar la información de la empresa como una base de datos global y las peticiones de datos formuladas desde una sede se traducen de forma transparente a peticiones en las sedes donde se encuentran esos datos.)

Nivel de Servidor de Aplicaciones

Facilitan los programas de aplicación a clientes ligeros que disponen de entornos de ejecución de aplicaciones usando estándares (protocolos de red TCP/IP, navegador HTTP, etc.).

Nivel de Cliente

PCs ligeros dotados de configuraciones basadas en estándares abiertos. Basadas en el carácter portable con que se distribuyen las aplicaciones desde los servidores de aplicaciones. Dependencia del hardware y del sistema operativo a la hora de abordar la ejecución de las aplicaciones.

Problemas: Mayor complejidad en la configuración y administración de los servidores de aplicaciones y en el desarrollo de las aplicaciones conforme a este modelo distribuido.

Ventajas: Reducción significativa en cuanto al mantenimiento de los clientes y mayor facilidad y flexibilidad para el usuario.

Condiciones de Integridad

Normas que mantienen la corrección semántica de una base de datos. Nos centraremos en la integridad genérica: depende del papel que juegue un atributo en el diseño de la tabla (son metareglas).

Integridad de Entidad

No se debe permitir que una entidad sea representada en la base de datos si no se tiene una información completa de los atributos que son claves de la entidad: la clave primaria, o una parte de la misma, no puede ser un valor nulo.

Clave externa: conjunto de atributos en una relación que es una clave en otra relación.

Integridad Referencial

Una base de datos en la que todos los valores no nulos de una clave externa referencian valores reales de la clave referenciada en la otra relación cumple la regla de integridad referencial. La integridad referencial mantiene las conexiones en las bases de datos relacionales.

Integridad de Entidad (en Operaciones)

Se debe comprobar que los atributos que forman parte de una clave primaria son no nulos y que el valor conjunto de ellos no está repetido en proceso de inserción/actualización.

• Inserción: Comprobar que el valor de la clave externa es nulo o concuerda con un valor de la clave primaria.
• Actualización: Si se actualiza la clave externa: comprobar las condiciones de clave externa. Si se actualiza la clave primaria: actualizar en cadena la clave externa.
• Borrado: Si se borra la clave primaria: borrado en cadena o valor nulo en cadena de la clave externa.