15/05/2012

Un comit de la organizacin ANSI (American National Standards Institute) aborda la problemtica del almacenamiento de datos para su procesamiento en aplicaciones informticas en 1975.

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

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

El principal cambio en la forma de implementar sistemas de informacin mecanizados consiste en la centralizacin 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 descripcin centralizada. Estamos creando un interfaz entre las aplicaciones y el sistema operativo. Al tiempo, estamos mejorando la seguridad de los datos, tendremos herramientas de anlisis y presentacin de los datos, etc.

Al centralizar los datos (y estructurarlos segn los distintos niveles de representacin, 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

En un principio, el estndar defini 3 niveles de representacin que tenan distintas finalidades segn "quin" deba 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 disear 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 programacin y, ms concretamente, con las aplicaciones que acceden a la base de datos. Esta arquitectura lgica (que no tiene por qu traducirse en una arquitectura fsica literalmente igual) persigue conseguir dos tipos de independencia de datos: lgica y fsica. La independencia lgica 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 "nminas" (que se comunica con el SGBD mediante un esquema externo, ms o menos ese subconjunto del esquema conceptual que necesita para generar las nminas) "nminas" debe recodificarse y, si fuera el caso, recompilarse. Sin embargo "correo", supongamos, no necesita T.c: "correo" no se toca y funciona perfectamente an a pesar de haber cambiado el esquema conceptual. La independencia fsica viene a ser lo mismo pero entre el sistema operativo y el esquema conceptual: si cambiamos el tamao de un ndice o hacemos que un fichero directo pase a tener una organizacin hash, el esquema conceptual no necesita ser cambiado puesto que estos detalles "fsicos" no le afectan, yo solo veo tablas, no s ni me interesa cmo la guarda dentro de un archivo del SO.

No obstante, pronto se dieron cuenta de que era muy recomendable establecer un nivel de representacin adicional que fuera realmente independiente de la mquina y del SGBD. La idea es que uno puede disear un sistema de informacin, describirlo, sin depender de una mquina concreta o incluso de un SGBD. Es decir, primero nos centramos en el problema y sus soluciones y, despus, 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 disear en E-R y utilizando una herramienta informtica pero, una vez que tenemos dibujado, ese esquema nos vale tanto para obtener las tablas correspondientes como para hacer una presentacin a nuestro jefe, explicndole cmo va a funcionar el sistema. En realidad, cada esquema identifica una fase de diseo e implementacin de un sistema de informacin mecanizado.

Por tanto, este es el resumen de la funcin de cada esquema.

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 extensin, no es solo el mdulo de consultas SQL. La idea es que hay ciertos mdulos 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 simultneas a servidores distintos y esperar las respuestas, en vez de hacer una consulta siempre despus 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 gestin de las bases de datos es que toda la informacin 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, adems, 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 cmo 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 catlogo 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 informacin visible a aquella sobre la que tiene permisos el usuario que est accediendo.

14

La funcin del catlogo incluye el proporcionarnos informacin a nosotros como usuario. En este caso, las restricciones sobre una tabla.

15

Como todas las listas de este tipo, la necesidad filosfica de analizar, generalizar y clasificar el mundo, ahora el de las bases de datos. Que la realidad y el da a da son bastante ms 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 situacin. Esta tarea, compleja donde las haya, se basa en una multitud de parmetros que debemos controlar en los posible. Van desde los propios de configuracin tanto de sistema operativo como de sistema de base de datos, hasta la definicin de ndices (estructuras auxiliares que, en general, se definen para acelerar la bsqueda y recuperacin de datos desde las tablas cuando se detecta cierto tipo de consultas como "muy frecuentes") y el anlisis y reescritura, automtica o no, de consultas SQL.

17

Como decamos, 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 comn.

18

Los ndices son una de las herramientas de rendimiento ms potentes de un SGBD. Algunos se definen de forma automtica (cuando creamos un clave primaria o ajena, por ejemplo) y otros los podemos crear nosotros para disminuir el tiempo de respuesta. Son estructuras ms cercanas al esquema interno (aunque los definimos desde el propio SGBD) y, por eso, tienen un efecto directo sobre cmo se organizan los archivos en almacenamiento secundario. Por otro lado, hay que ser cuidadoso en cuntos se definen y cmo, la creacin de un ndice no garantiza de por s que nuestras consultas vayan a ir mejor. Es evidente que no deja de ser "un paso ms" al que obligamos al SGBD a realizar para devolvernos los resultados. Solo que a veces compensa dar ese paso adicional. Tambin afecta el tipo de claves que utilizamos para definir ese ndice, por ejemplo.

19

Por otro lado, tipos de ndice y funcin 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 haba 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 mdulo del SGBD indispensable. De hecho, hemos escrito "...en casi todos los SGBD" ms por prudencia que por convencimiento. Resumiendo mucho, lo que hace es analizar la consulta, trocearla en subconsultas, evaluar, por ejemplo, si se ganar algo ejecutndolas 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 ejecucin de los trozos obtenidos de una consulta a ejecutar se traducen en planes de ejecucin, que le sirven al SGBD para calcular, aproximadamente, cul va a ser el ms rpido teniendo en cuenta una serie de variables. Todos los SGBD tienen comandos para mostrarnos el plan de ejecucin 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 bsico del optimizador de consultas.

23

Ejemplos bsicos de acciones que podemos llevar a cabo nosotros mismos para acelerar una consulta: eliminar parntesis innecesarios, el from-where hace un producto cartesiano, el join no?, el orden de las tablas puede influir, select *, ....

24

...usar char en vez de varchar en los ndices acelera la recuperacin de datos, sustituir el join por una subconsulta (cuando sea posible)... Tngase en cuenta que estamos hablando de situaciones "lmite". Si tienes una base de datos con una tabla de 10 filas sera una tontera pensar en estas cosas.

25

conclusiones y fin

26

conclusiones y fin

27