Cap_ 2 - Arquitectur..

Parte Primera:
INTRODUCCION A LOS SGBD
Sistemas de Gestión de Bases de Datos
Tabla
Fila
Type Tabla
Type
Fila
text
Fila
Tabla text
Fila
Fila
Fila Fila
Type
Fila
text
Fila
Tabla
Tabla
Fila Tabla
Type
Fila
Type
Fila
text
Tabla text
Fila
Fila
Fila Fila
Type
Fila
text
Fila
Tabla
Fila
Type
Fila
Type
Fila
text
Tabla text
Fila
Fila
Fila Fila
Type
Fila
text
Fila
UPCO - Sistemas de Gestión de Bases de Datos
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.
UPCO - Sistemas de Gestión de Bases de Datos
12
Arquitectura de un SGBD
•
Desarrollo:
1.
2.
3.
4.
5.
Introducción
Conceptos base
El SGBD como subsistema
Desarrollo de aplicaciones
Preparación de programas con SQL
UPCO - Sistemas de Gestión de Bases de Datos
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
UPCO - Sistemas de Gestión de Bases de Datos
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
UPCO - Sistemas de Gestión de Bases de Datos
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
UPCO - Sistemas de Gestión de Bases de Datos
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.
UPCO - Sistemas de Gestión de Bases de Datos
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
•
•
Batch
Unidad lógica de
trabajo (LUW)
•
Una o Varias LUWs
•
Identifica una
operación mínima de
negocio
•
Identifica un proceso
complejo de negocio
•
Corta duración
•
Larga duración
•
Diurno
•
Nocturno
UPCO - Sistemas de Gestión de Bases de Datos
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
UPCO - Sistemas de Gestión de Bases de Datos
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
SG. Comunicaciones
S.O.
Batch
SG.Transaccional
Distribuído
SGBD
Transacción
UPCO - Sistemas de Gestión de Bases de Datos
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
y organizador
Motor de evaluación
de consultas
Gestor de memoria
intermedia
Gestor de archivos
Interprete LDD
Procesador de consultas
Gestor de autorización
e integridad
Índices
ºDatos
Gestor transaccional
Gestor de almacenamiento
Diccionario
Estadísticas
UPCO - Sistemas de Gestión de Bases de Datos
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 estático
SQL llamable
SQL dinámico
SQL dinámico
Cobol
C
CLI (C)
C
Cobol
ODBC (C)
Java
JDBC (JAVA)
SQLJ
UPCO - Sistemas de Gestión de Bases de Datos
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
Fuente
Sintaxis
Precompilación
DBRM
Fuente modificado
.BND, .Dbrmlib
SQL gestor
BIND
Plan
Paquete
Catálogo
Catálogo
Compilación
Objeto
Link-Edit
Ejecutable
.exe, .Loadlib
UPCO - Sistemas de Gestión de Bases de Datos
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