PDF de programación - Tema 6 - Sistemas de gestión de bases de datos

15/05/2012

1

Un comité de la organización ANSI (American National Standards Institute) aborda la
problemática del almacenamiento de datos para su procesamiento en aplicaciones
informáticas en 1975.

2

Como ya se comentó en el primer tema, los sistemas de archivo convencional, por aquel
entonces, mostraban ciertas carencias que desembocaron en la definición de la "crisis
crónica del software".

3

Estas carencias se pueden resumir, mucho, en estos aspectos.

4

El principal cambio en la forma de implementar sistemas de información mecanizados
consiste en la centralización de los datos que permite un mayor control sobre los mismos,
al tiempo que es necesario permitir vistas parciales puesto que aplicaciones de muy distinta
naturaleza necesitan sus propios datos, y todas acceden a esa descripción centralizada.
Estamos creando un interfaz entre las aplicaciones y el sistema operativo. Al tiempo,
estamos mejorando la seguridad de los datos, tendremos herramientas de análisis y
presentación de los datos, etc.

5

Al centralizar los datos (y estructurarlos según los distintos niveles de representación, los
esquemas que vienen en las siguientes diapositivas) se consigue mejorar la independencia,
integridad y seguridad de los datos. Lo de Batman … pues no sé qué tiene que ver, pero ahí
está 

6

En un principio, el estándar definió 3 niveles de representación que tenían distintas
finalidades según "quién" debía usarlos.

•El esquema conceptual sirve para que los humanos nos comuniquemos con el motor de la
base de datos. Es, entre otras cosas, el lenguaje que debemos usar para diseñar la base de
datos.

•El interno es el medio que tiene el motor de base de datos para comunicarse con el
sistema operativo y, por ende, con el almacenamiento primario y secundario.

•Los esquemas externos son los interfaces que conectan con los distintos lenguajes de
programación y, más concretamente, con las aplicaciones que acceden a la base de datos.



Esta arquitectura lógica (que no tiene por qué traducirse en una arquitectura física
literalmente igual) persigue conseguir dos tipos de independencia de datos: lógica y física.

•La independencia lógica hace que cambios en el esquema conceptual NO afecte a
esquemas externos que NO usan esos datos modificados. Es el ejemplo ya visto de cambiar
la longitud de una columna T.c. Si T.c se utiliza en un programa "nóminas" (que se
comunica con el SGBD mediante un esquema externo, más o menos ese subconjunto del
esquema conceptual que necesita para generar las nóminas) "nóminas" debe recodificarse
y, si fuera el caso, recompilarse. Sin embargo "correo", supongamos, no necesita T.c:
"correo" no se toca y funciona perfectamente aún a pesar de haber cambiado el esquema
conceptual.

•La independencia física viene a ser lo mismo pero entre el sistema operativo y el esquema
conceptual: si cambiamos el tamaño de un índice o hacemos que un fichero directo pase a
tener una organización hash, el esquema conceptual no necesita ser cambiado puesto que
estos detalles "físicos" no le afectan, yo solo veo tablas, no sé ni me interesa cómo la
guarda dentro de un archivo del SO.

7

No obstante, pronto se dieron cuenta de que era muy recomendable establecer un nivel de
representación adicional que fuera realmente independiente de la máquina y del SGBD. La
idea es que uno puede diseñar un sistema de información, describirlo, sin depender de una
máquina concreta o incluso de un SGBD. Es decir, primero nos centramos en el problema
y sus soluciones y, después, decidimos si lo traducimos a otro lenguaje que pueda entender
un ordenador. Evidentemente, eso no quiere decir que no utilicemos ordenadores para
todos ellos; por ejemplo, podemos diseñar en E-R y utilizando una herramienta informática
pero, una vez que tenemos dibujado, ese esquema nos vale tanto para obtener las tablas
correspondientes como para hacer una presentación a nuestro jefe, explicándole cómo va a
funcionar el sistema.

En realidad, cada esquema identifica una fase de diseño e implementación de un sistema de
información mecanizado.

8

Por tanto, este es el resumen de la función de cada esquema.

9

Una posible secuencias de decisiones sobre qué modelos de datos utilizar para cada crear
cada esquema.

10

En realidad, un SGBD es un conjunto de software bastante complejo por su extensión, no
es solo el módulo de consultas SQL. La idea es que hay ciertos módulos o conceptos
indispensables para el SGBD (los de dentro de la elipse) y otros de tipo herramienta
auxiliar.

11

Un concepto que se ha generalizado tanto con Internet que ahora casi ni se nombra por
asumido, aprovechar la red: un servidor puede atender varias peticiones, y un usuario
puede realizar varias consultas simultáneas a servidores distintos y esperar las respuestas,
en vez de hacer una consulta siempre después de haber recibido la respuesta a la anterior.
En especialmente muy aprovechado por los SGBD que deben compartir datos entre
muchos usuarios concurrentemente.

12

Un dato curioso sobre la gestión de las bases de datos es que toda la información de
funcionamiento (los metadatos, datos sobre los datos) se encuentra almacenada en forma
de tablas. Viene a ser algo así como los *.ini de cualquier programa. En general, la lectura
de estas tablas, salvo en datos sensibles, está permitida a todos los usuarios y, además, son
actualizadas siempre que hacemos algo (insertar, borrar, modificar, consultar). De hecho, el
SGBD sabe de qué estamos hablando en una select porque puede consultar aquí cómo se
llaman las columnas de una tabla concreta, avisarnos si nos hemos equivocado y esa tabla
o columna no existe, ejecutar la consulta, etc.

13

Una vista del catálogo MySQL desde MySQL Workbench. En realidad, el diccionario de
datos se guarda en la base de datos "mysql", information_schema se puede asociar a
"vistas" sobre las tablas de "mysql" que restringen la información visible a aquella sobre la
que tiene permisos el usuario que está accediendo.

14

La función del catálogo incluye el proporcionarnos información a nosotros como usuario.
En este caso, las restricciones sobre una tabla.

15

Como todas las listas de este tipo, la necesidad filosófica de analizar, generalizar y
clasificar el mundo, ahora el de las bases de datos. Que la realidad y el día a día son
bastante más complejos, nadie lo duda.

16

Uno de los aspecto primordiales, y objetivo inexcusable de cualquier administrador de base
de datos, es garantizar el rendimiento óptimo del motor de base de datos en casi cualquier
situación. Esta tarea, compleja donde las haya, se basa en una multitud de parámetros que
debemos controlar en los posible. Van desde los propios de configuración tanto de sistema
operativo como de sistema de base de datos, hasta la definición de índices (estructuras
auxiliares que, en general, se definen para acelerar la búsqueda y recuperación de datos
desde las tablas cuando se detecta cierto tipo de consultas como "muy frecuentes") y el
análisis y reescritura, automática o no, de consultas SQL.

17

Como decíamos, aspectos no directamente bajo la responsabilidad del SGBD afectan
extraordinariamente al rendimiento de la base de datos. Estos de aquí casi se puede decir
que son de sentido común.

18

Los índices son una de las herramientas de rendimiento más potentes de un SGBD.
Algunos se definen de forma automática (cuando creamos un clave primaria o ajena, por
ejemplo) y otros los podemos crear nosotros para disminuir el tiempo de respuesta. Son
estructuras más cercanas al esquema interno (aunque los definimos desde el propio SGBD)
y, por eso, tienen un efecto directo sobre cómo se organizan los archivos en
almacenamiento secundario.



Por otro lado, hay que ser cuidadoso en cuántos se definen y cómo, la creación de un
índice no garantiza de por sí que nuestras consultas vayan a ir mejor. Es evidente que no
deja de ser "un paso más" al que obligamos al SGBD a realizar para devolvernos los
resultados. Solo que a veces compensa dar ese paso adicional. También afecta el tipo de
claves que utilizamos para definir ese índice, por ejemplo.



19

Por otro lado, tipos de índice y función de los mismos hay muchos y para cada producto en
particular (MySQL no tiene por qué ofrecer los mismos tipos de índice que Oracle, por
ejemplo). Aquí vemos que MySQL utiliza árboles B y tablas hash.

20

Desde los albores del modelo relacional, se dieron cuenta de que había que encontrar un
modo de mejorar el tiempo que se tarda en lanzar una consulta SQL y obtener el resultado.
El optimizador de consultas es un módulo del SGBD indispensable. De hecho, hemos
escrito "...en casi todos los SGBD" más por prudencia que por convencimiento.



Resumiendo mucho, lo que hace es analizar la consulta, trocearla en subconsultas, evaluar,
por ejemplo, si se ganará algo ejecutándolas en uno u otro orden y, finalmente, decidir que
una de estas secuencias es la mejor y ejecutarla. Todo ello, claro, sin que el usuario se
entere ni note retardo alguno. Curiosamente, muchos optimizadores de consultas utilizan
álgebra relacional en alguna parte de sus algoritmos.

21

Esas secuencias alternativas de ejecución de los trozos obtenidos de una consulta a ejecutar
se traducen en planes de ejecución, que le sirven al SGBD para calcular, aproximadamente,
cuál va a ser el más rápido teniendo en cuenta una serie de variables.



Todos los SGBD tienen comandos para mostrarnos el plan de ejecución elegido por él. El
objetivo es que nosotros podamos decidir reescribir la consulta de otra forma o generar un
índice para ayudar, por ejemplo.

22

Esquema básico del optimizador de consultas.

23

Ejemplos básicos de acciones que podemos llevar a cabo nosotros mismos para acelerar
una consulta: eliminar paréntesis innecesarios, el from-where hace un producto cartesiano,
el join ¿