Arquitectura de base de datos

Existen dos grandes tipos de arquitecturas en lo que refiere a un sistema de gestión de base de datos. Por un lado tenemos las arquitecturas centralizadas y por el otro las arquitecturas cliente-servidor. Este es un compendio con las características de cada una de ellas.

Arquitecturas centralizadas

El avance de las arquitecturas de sistemas de computadoras supuso también una revisión de otro tipo de arquitecturas, entre ellos la de los sistemas de gestión de base de datos (de ahora en más y por razones obvias SGBD o DBMS).

Las primeras arquitecturas eran llamadas Arquitecturas centralizadas y contaban con un macrocomputador o mainframe que proporcionaban el procesamiento principal a todas las funciones del sistema. Esto incluía programas de aplicación, interfaces de usuario, sumado a toda la funcionalidad de un SGBD.

Los usuarios accedían al sistema mediante terminales, que solamente mostraban en pantalla información. Se llamaban terminales tontas, dado que su única función era la de visualización. Todo el procesamiento se hacía de manera remota en el mainframe, que cuando concluía de procesar y se proponía desplegarle algo al usuario, debía comunicarse con ese terminal enviándole la información y los controles de pantalla. Dicha comunicación entre el computador central y los terminales “tontos” se hacía mediante algún tipo de red de computadores.

Los precios de Hardware habían descendido notoriamente, surgen las PC’s y la mayoría de los usuarios cambia los terminales que tenían por los nuevos PC’s dado que eran relativamente baratos, y generalmente se rompían poco. En un primer momento, la arquitectura de los sistemas no varió, se seguía usando un SGBD centralizado con PC’s remotas que se conectaban a una determinada máquina que era la encargada de realizar todas las funciones del SGBD.

Poco a poco los SGBD fueron evolucionando y la arquitectura centralizada comenzaba a ser una limitante en cuanto al procesamiento que el usuario exigía, lo cual llevó a las arquitecturas SGBD Cliente-Servidor.

Arquitecturas cliente-servidor

Las arquitecturas cliente-servidor se diseñan para manejar los nuevos entornos de cómputo, en los que hay muchos PC’s y estaciones de trabajo, servidores de ficheros, etc interconectados por medio de una red. Existen factores ajenos al desarrollo propio de la arquitectura, que son inherentes a la evolución de la tecnología en sí misma y que potencian el crecimiento de las arquitecturas cliente-servidor, como por ejemplo el bajo costo del hardware y las nuevas PC’s, o el desarrollo importante que tuvieron las redes de computadoras en ese último tiempo. Dado que las tareas se dividen en una arquitectura cliente-servidor, los requerimientos de los servidores bajan notoriamente respecto a lo que eran los mainframes.

La idea principal es definir servidores especializados con funciones específicas. Es decir, conectar un cierto número de estaciones de trabajo o PC’s como clientes de un servidor de ficheros que se encarga de mantener los ficheros de la máquina cliente. Por ejemplo supongamos un servidor de impresoras, que posee un conjunto n de impresoras que debe gestionar. Pone a disposición de los clientes la impresora y cuando llega una petición de impresión el servidor es quién la recibe y la despacha a la impresora que considere más adecuada. Esto es extensible a todo tipo de servidores especializados dado que los recursos del servidor están a disposición de los clientes.

Por otra parte el cliente, le proporciona al usuario las interfaces adecuadas para poder usar los servidores, así como también la potencia para el procesamiento para las aplicaciones locales.

La misma idea puede también aplicarse al software, donde puede almacenarse un determinado software en una máquina y ponerlo a disposición de los clientes.

La arquitectura cliente-servidor tiene una estructura con varios PC’s y menos mainframes, todos interconectados entre sí mediante algún tipo de red de computadoras. El cliente, provee capacidades de interfaz de usuario y procesamiento local. Si alguno de los clientes solicita cierta funcionalidad adicional, entonces la máquina cliente le conecta con un servidor que proporcione dicha funcionalidad. Un servidor es una máquina que puede proporcionar servicios ya sea de impresión, de ficheros, de acceso a una base de datos, etc.

Arquitectura cliente-servidor en un SGBD

En un comienzo las bases de datos relacionales eran arquitecturas centralizadas. Con el paso del tiempo poco a poco esa arquitectura fue transformándose en una cliente-servidor. Los primeros aspectos que pasaron del lado del cliente fueron los programas de aplicación y la interfaz de usuario. De esta manera, y debido a que SQL estableció un lenguaje estándar que dividía lógicamente el cliente del servidor, las funcionalidades de transacción y consulta permanecen del lado del servidor, a menudo llamado servidor SQL o de consulta.

En una arquitectura de este tipo, los programas de aplicación y la interfaz de usuario pueden ejecutarse en el cliente. Cuando un usuario solicita acceso al SGBD, se establece una conexión con el servidor mediante el protocolo ODBC (Open Data Base Connectivity) el cuál proporciona interfaces API para que las aplicaciones del lado del cliente puedan llamar al SGBD y comunicarse correctamente. La mayoría de los proveedores de SGBD proporcionan drivers ODBC. Java tiene otro estándar llamado JDBC, que cumple una función similar.

En los sistemas de base de datos orientados a objetos se dividen los módulos del SGBD entre cliente y servidor. De esta manera el servidor se encarga de los módulos de manejo de almacenamiento de los datos en páginas de disco, recuperación, control de concurrencia, movimiento de páginas a disco y funcionalidades similares. Por otra parte, el cliente cuenta con funciones que corresponden a los módulos de gestión de interfaz de usuario, funciones de diccionario de datos, interacción entre el compilador de un determinado lenguaje y el SGBD.

Nota final:

Si se quiere puede investigarse más sobre lo referente a las arquitecturas cliente – servidor existen más tipos que requieren conceptos adicionales como por ejemplo las arquitecturas C-S de tres niveles, o incluso las base de datos distribuídas.

*Fundamentos de sistemas de base de datos, 3a edición, R. Elmasri – S. Navathe

*Sistemas de base de datos, 5a edición, Volúmen 1, C.J.Date

Catálogo de un sistema de base de datos

Acá va un material teórico que escribí hace un tiempo en el viejo blog.
Es un breve resumen que puede servir para la facultad en materias como Base de datos.
Espero les sirva!

El catálogo de un sistema de base de datos no es más que una base de datos en sí misma a veces llamada metabase. Los contenidos de dicha base de datos son llamados metadatos. La función principal del catálogo es almacenar los esquemas de las bases de datos que el sistema mantiene. Mantiene una descripción de todos los niveles (véase arquitectura de tres esquemas o niveles) tanto del esquema interno como del externo y el conceptual.

Esencialmente se guardan objetos que puedan resultar de interés para el sistema, como por ejemplo tablas, vistas, índices, usuarios, planes de aplicación, privilegios de acceso, etc. La información contenida en el catálogo es indispensable para que el sistema se comporte de manera adecuada. El conocer los índices que existen por ejemplo, facilitaría o influiría sin dudas en la planificación de la estrategia en una determinada consulta. El subsistema de autorización, chequeará por ejemplo que cada operación que intente realizar el usuario esté permitida. De manera que también vemos que el catálogo sirve para chequear la validez de una sentencia y mantener la integridad y la coherencia de los datos.

Las consultas al catálogo pueden realizarse con las mismas sentencias que se consulta cualquier base de datos o tabla. Sin embargo las actualizaciones al catálogo (INSERT, DELETE, UPDATE) no son posibles. Pensemos un segundo que pasaría si permitiéramos aplicar estas sentencias en el catálogo. Podríamos por ejemplo, borrar una línea de la tabla syscolumns (tabla que contiene una fila por cada columna en alguna tabla del sistema). Si esto sucediera estaríamos eliminando una columna del catálogo y para el sistema esa columna no existiría más. De manera que cualquier intento por recuperar datos de esa columna fracasaría.

En contraposición a estas sentencias existen otras proposiciones de definición de datos, como son CREATE TABLE, CREATE INDEX, DROP y ALTER. Cuando hacemos un CREATE TABLE, solamente se hace un ingreso en la tabla systables(tabla que contiene todas las tablas del sistema) del catálogo, sino que también se dan ingresos en la tabla syscolumns a todas las columnas que contiene la nueva tabla a crear.

De manera similar el DROP equivale al DELETE y el ALTER al UPDATE.

*Fundamentos de sistemas de base de datos, 3a edición, R. Elmasri – S. Navathe

*Sistemas de base de datos, 5a edición, Volúmen 1, C.J.Date