INTRODUCCION A LOS SGBD

Parte Primera: INTRODUCCION A LOS SGBD Sistemas de Gestión de Bases de Datos Tabla Tabla Type Fila Tabla Type Fila Tabla text Fila Type Fila Fila text Type Fila Tabla Tabla Fila text Fila text Fila Fila Type Fila Fila Type Fila Fila text Fila text Fila Fila Fila Tabla Type Fila Tabla text Fila Type Fila Tabla Fila text Fila Type Fila Fila text Fila Fila 10

Capítulo 2 Arquitectura. Objetivo: Repasar ciertos conceptos base asociados al gestor para establecer un punto inicial de conocimiento, requerido para el seguimiento de la asignatura. Desarrollo: Introducción Conceptos base Instancia vs. Subsistema Base de Datos Esquema vs. BD Bufferpool LOGs = Bitácora Transacción vs. Batch El SGBD como subsistema Desarrollo de aplicaciones Preparación de programas con SQL 11

Tema 2 Arquitectura de un SGBD Objetivo: Repasar ciertos conceptos base asociados al gestor para establecer un punto inicial de conocimiento, requerido para el seguimiento de la asignatura. 12

Arquitectura de un SGBD Desarrollo: 1. Introducción 2. Conceptos base 3. El SGBD como subsistema 4. Desarrollo de aplicaciones 5. Preparación de programas con SQL 13

1. Introducción Las diversas plataformas utilizan distinto vocabulario. El SGBD es un subsistema integrado junto con otros subsistemas, bajo la supervisión del SO El desarrollo de aplicaciones contra un SGBD vía SQL presenta diversas opciones La preparación de programas con SQL requiere algo más que la compilación La Transacción es una Unidad Lógica de Trabajo Plataformas: - Mainframe/Host =>DB2 => SUBSISTEMAS de BBDD. - Sistemas medios/abiertos/distribuidos =>(Linux, Unix,Windows) => Oracle, DB2, SQLServer => INSTANCIA Subsistema integrado: Subs. Comunicaciones, Transaccional, Autorizaciones e Integridad, gestion archicos, gestion memoria intermedia. Desarrollo aplicaciones: SQL Estático : Se codifican sentencias SQL en el código del programa. EXEC SQL SELECT... END EXEC SQL ; SQL Dinámico: Es un interfaz estandar en el que se utilizan llamadas o métodos en los que el argumento son las sentencias SQL. Prepared statement ps = cx.preparestatement( SELECT ); Preparación de Programas: Precompilacion, Compilado, Enlazado y Vinculación. Transacción: Uso de ULT en la planificación de las tareas. 14

2. Conceptos base (1) Instancia vs. Subsistema Elemento de más alto nivel Dos instancias no comparten nada (salvo el software base, que se instala una sola vez) En una máquina puede haber varias instancias Tipos: Datos o Administración Instancia Datos 1 Instancia Datos 2 Instancia Admin. 1 En los sistemas Middleware y PCs se denomina Instancia, mientras que en los Mainframe hablamos de Subsistema. Al arrancar una instancia (mediante comando) se asignan los recursos necesarios de máquina (memoria, ejecutables, etc.) Si se para la instancia (vía comando) se paran previamente todas sus BDs. La instancia o subsistema es un programa que se tiene que arrancar directamente en el sistema operativo para que otras aplicaciones puedan acceder a los datos almacenados en dicha Una instancia o subsistema es un motor de BBDD o gestor de BBDD y por tanto es necesario arrancarlo. En ese momento se inician varios procesos asociados a dicha instancia o subsistema que obtendrán recursos del S.O. ( CPU y memoria) 15

2. Conceptos base (2) Base de Datos El nº de BD por instancia varía según el gestor: 1 BD / Instancia (Oracle) n BD / Instancia (DB2 UDB) Instancia Datos 1 Instancia Datos 2 Instancia Admin. 1 BD1 BD1 BD2 BD3 La BD es una asociación lógica de objetos. En los entornos Middleware y PC (Instancia), cada BD tiene su propio Bufferpool, LOG y Catálogo o diccionario de Datos. En los entornos Mainframe (subsistema) estos elementos son comunes en todo el subsistema. Iniciar instancia: star database manager db2start 16

2. Conceptos base (3) Esquema vs. BD Objetos creados por un mismo usuario CREATE TABLE creador.tabla CREATE INDEX creador.índice Se confunde con BD si el gestor sólo permite 1 BD por instancia Bufferpool Memoria dedicada a Datos del SGBD LOGs = Bitácora Registro de modificaciones sobre los datos y otros eventos. Necesario para recuperación. En los gestores en los que sólo existe más de una BD por instancia, se suele recurrir al esquema para agrupar lógicamente los objetos. Esquema: Permite el agrupamiento lógico de los objetos. Siendo el esquema, el nombre del usuario que ejecuta la creación de la tabla. En una misma base de datos no se puede repetir el mismo nombre de tabla con el mismo creador o esquema. Pero si se puede repetir el mismo nombre de tabla con diferente creador o esquema. Bufferpool: Son las áreas de memoria gestionadas por el SGBD. Cuando se invocan datos mediante sentencias SQL, el SGDB lleva dichos datos de disco a memoria. Estas son las áreas de memoria donde se dejan dichos datos a disponibilidad de las transacciones o procesos. Log s: Es el repositorio donde se van almacenando los registros de modificaciones de los datos. Es crítico ya que continuamente está siendo utilizado por el SGBD y este es necesario para la recuperación ante una caída o problema. 17

2. Conceptos Base (4) Transacción vs. Batch Transacción Unidad lógica de trabajo (LUW) Batch Una o Varias LUWs Identifica una operación mínima de negocio Corta duración Diurno Identifica un proceso complejo de negocio Larga duración Nocturno Una transacción debe cumplir los siguientes requisitos: Atomicidad. Consistencia Durabilidad 18

2. Conceptos base (5) Existe 4 tipos de usuarios: Usuario normal Programador aplicaciones. Usuarios avanzados. ADM Existen diferentes tipos de usuarios distinguiéndose por la forma en que interactúan con el sistema. Para los cuales se diseñan diferentes tipos de interface. Usuario normal: Son usuarios no avanzados que interactúan con el sistema mediante el uso de programas de aplicación escritos previamente. Programador de aplicaciones: Son aquellos que escriben los programas de aplicación que acceden alas BD s. Usuarios avanzados: Interactúan con el sistema formulando consultas en un lenguaje de consulta de BD s ADM: Tiene el control y la gestión de los datos del SGBD, y programas que puedan acceder a ellos. Definición y modificación del esquema de BD. Definición de la estructura y organización física. Concesión de autorizaciones. Mantenimiento. (Copias de seguridad, espacio libres disco o buffer, supervisión de trabajos etc) 19

3. El SGBD como subsistema Distribuído SG. Comunicaciones S.O. Batch SG.Transaccional Transacción SGBD El SGBD es un subsistema más. El único sistema es el Sistema operativo, y todos acaban invocando sus funciones. Cada subsistema es especialista en un área, y determinadas funciones las realiza mejor que el SO al disponer de información detallada. Finalmente una llamada al S.O. es la que permite ejecutar la función. Ejemplo: la paginación de tablas. La conexión con el gestor se establece abriendo una vía (thread). La petición proviene del S.O. si es un Batch, del S.G. Transaccional si es una transacción, o del S.G. Comunicaciones si es externa. El SGBD es el más profundo o lejano en la máquina, por lo que cualquier información incorporada a una tabla relacional, que realmente no sea tal, implica más tiempo de ejecución. Desde el S.O. se pueden lanzar programas (en general batch). Se abren vías con el SGBD. Si hay un gran número de vías querrá decir que hay muchos usuarios. Se podrán realizar más transacciones pero estas tardarán más ye podrán producirse bloqueos entre ellas, ya que los recursos y datos son compartidos. Es necesario limitar la capacidad de procesamiento, limitando por ejemplo el número de vías. Es posible que el SG Transaccional y el SGBD estén en máquinas diferentes. Si un SGBD necesita datos de otro SGBD remoto entra en comunicación de manera distribuida. 20

3. El SGBD como subsistema Usuarios Programadores Usuarios avanzados ADM Interface de aplicaciones Programas de aplicación Herramientas de consulta Interface de administración Código objeto de los Programas de aplicación Compilador y enlazador Consultas LMD Compilador del LMD Interprete LDD Motor de evaluación de consultas y organizador Procesador de consultas Gestor de memoria intermedia Gestor de archivos Gestor de autorización e integridad Gestor transaccional Gestor de almacenamiento Índices º Datos Diccionario Estadísticas Los componentes funcionales de un SGBD se pueden dividir a grandes rasgos en dos componentes: El Sistema Gestor de Almacenamiento y el Procesador de Consultas. El Gestor de Almacenamiento es un módulo de programa que proporciona la interfaz entre los datos del SGBD y los programas de aplicación y las consultas lanzadas al sistema. Coordina el almacenamiento interactuando con el gestor de archivos. Los datos se almacenan en disco usando un sistema de archivos disponible por el sistema operativo. Traduce las diferentes instrucciones LMD a órdenes del sistema de archivos del S.O. Siendo responsable del almacenamiento, recuperación y actualización de los datos en la BD s. Sus componentes son: Gestor de autorización e integridad: Comprueba que satisfagan las restricciones de integridad y autorizaciones de los usuarios para acceder a los datos. Gestor de transaccional: Asegura que la base de datos quede en un estado consistente a pesar de los fallos que puedan ocurrir y que las ejecuciones concurrentes de transacciones ocurran sin conflictos. Gestor de archivos: Gestiona la reserva de espacio en disco y las estructuras de datos para su representación en disco. 21

Gestor de memoria intermedia: Es responsable de traer los datos del disco a memoria principal y decidir qué datos tratar en memoria intermedia (buffer). Es una parte crítica del SGBD ya que permite que la base de datos maneje tamaños de datos que son mucho mayores que el tamaño de la memoria principal. El procesador de consultas interpreta y evalúa las consultas realizadas sobre el sistema. Sus componentes son: Interprete del LDD: Interpreta las instrucciones del LDD y registra las definiciones en el diccionario de datos. Compilador del LMD: Traduce las instrucciones del LMD a un plan de ejecución con instrucciones de bajo nivel que entiende el motor de evaluación de consultas. Una consulta puede traducirse en varios planes de ejecución alternativos que proporcionan el mismo resultado pero con distinto coste, eligiendo la alternativa meno costosa. Motor de evaluación de consultas: Ejecuta las instrucciones de bajo nivel generadas por el compilador del LMD. 22

4. Desarrollo de aplicaciones Métodos de Programación SQL embebido (precompilado) SQL llamable SQL estático SQL dinámico SQL dinámico Cobol C CLI (C) C Cobol ODBC (C) Java JDBC (JAVA) SQLJ SQL estático: EXEC SQL SELECT NOMBRE, APELLIDOS FROM CLIENTES; SQL dinámico: Statement sentencia1 = conexion.createstatement(); String query = "SELECT NOMBRE, APELLIDOS FROM CLIENTES"; ResultSet resultado1 = sentencia1.executequery(query); 23

5. Preparación de programas Sintaxis Fuente Precompilación SQL gestor DBRM.BND,.Dbrmlib BIND Fuente modificado Compilación Plan Catálogo Paquete Catálogo Objeto Link-Edit Ejecutable.exe,.Loadlib Al ejecutar un programa, se carga el ejecutable. En el primer acceso SQL, se abre una vía con el SGBD (desde el SG. Transaccional si es una Transacción, o desde el SO si es un Batch) para cargar el Plan o Paquete residente en el Catálogo del gestor. En ese momento se comprueban los Timestamp; si no son idénticos el gestor retorna un SQLCODE negativo. Si en una ejecución no se pasa por ninguna sentencia SQL, no se abre la vía con el SGBD. El lenguaje en el que esta escrito el programa no reconoce las sentencias SQL, luego el compilador daría un error. Para evitarlo es necesario realizar un proceso de precompilación para extraer del código fuente las sentencias SQL. El precompìlador es suministrado por el SGBD que se este utilizando. Con la precompilacion se obtiene el código fuente modificado, donde las sentencias SQL son comentadas y modificadas con llamadas a funciones. También se genera un fichero DBMR (con extensión bnd), es un módulo que contiene todas las sentencias SQL extraídas del fuente original. El fichero DBMR hay que darlo a conocer al gestor mediante una operación de vinculación (BIND), este proceso dará lugar a la creación de dos ficheros. Un PLAN que contiene el nombre del ejecutable y el plan de acceso para la resolución de las consultas y un PAQUETE con el timestamp y los programas para la ejecución de las sentencias. 24

Con SQL estático se resuelven las sentencias antes de ejecutar el programa. En el momento de la precompilación se le asigna un timestamp al código fuente. El timestamp del ejecutable y del paquete han de ser iguales. Si se modifica el código fuente, al precompilarlo el timestamp se modifica. Si no se hace la operación de BIND posteriormente, el timestamp del ejecutable y del paquete son distintos y el SGBD lanzará un error (SQLCODE -818), ya que las modificaciones realizadas no han sido vinculadas y refrescadas en la base de datos. 25